I'm not sure what you're asking for specifically. The Swiss data protection act is here [0] and is reasonably comprehensive, especially compared to the US, in which data protection is essentially nonexistent.
As for it being tested, I can assure you that it's taken very seriously. One ruling that demonstrates that is [1], in which Switzerland's highest court ruled that an individual's right to privacy has higher precedence than a copyright-owner's right to police copyright infringement.
There's also a constitutional right to privacy [2], though the Swiss constitution is a little different to the American one.
One notable and enormous hole in Switzerland's record however is the BÜPF [3], which, as I understand it, requires ISPs to log DNS requests, among other things. That shouldn't be relevant here though, so long as Quad9 doesn't become a telecommunications provider.
Deepl [0] is available in English but doesn't seem well-known outside of the non-Anglophone Western European countries. It's essentially Google Translate but generally has better quality translations for the languages it supports.
I'd go even further and recommend GrapheneOS [0] on a Pixel.
It has some extra security improvements on top of AOSP and most importantly, the builds are signed and the device can be locked after you install the ROM.
Doesn't the same argument apply to basically every security and privacy feature?
"No no no. The problem isn't unencrypted network connections, it's companies and people who use them in evil ways. I would rather handle that even if it's much harder."
Should we not have introduced HTTPS? Permission models on modern operating systems? 2-factor authentication?
What about Javascript makes it different to the problems solved by these other features?
To give you a less clear example, think about writing a library that sends telemetry to some cloud service. The telemetry could be readings from a sensor attached to a microcontroller with 512K of RAM or it could be readings from a server sitting in a datacenter with 256GB of RAM.
You need some helper library to handle the protocol and there's a really nice full-featured library that comes with a bunch of handy debugging tools but it's too memory-hungry for that tiny microcontroller.
Another option is a minimalist library that uses very little memory but also has less flexibility in say TLS.
If you pick just one, one of your platforms ends up suffering needlessly.
Adding the options allows the user to decide what's best for them.
I watch a lot of both American-made movies and TV shows as well as a lot of Japanese anime.
One thing I find curious is how different the models for time travel usually are.
In American media, it seems more often than not, time travel is modelled as if the past and the future are simultaneously existing parallel worlds, where the future is affected by the past in "real-time", e.g. Back to the Future's Marty gradually fading as the chances of his birth diminish, or Timeless's people in the future "watching" people arrive in the past and making sure their own team leaves "in time" to catch them.
These models don't really offer a solution to the grandfather paradox.
In anime however, time travel is near universally modelled with timelines, where time travel essentially creates a new parallel world each time. If you travel back in time and kill your grandfather, you simply create a timeline in which you were not born, but can continue to exist, because you are from a timeline where you were born.
I'm by no means suggesting that either model is unique to America/Japan (Rick and Morty for example uses the branching timeline model), I just find it interesting how they differ.
I've been running a small CNC for a while now and though I've had skipped steps, they've never been the cause of a failure. When they've failed, it's been because:
- I stalled the spindle and I'm trying to plow the no-longer-rotating endmill straight through my stock (and if steps weren't skipped, the tool would break)
- I forgot to turn on the spindle and I'm trying to plow the endmill straight through my stock (and if steps weren't skipped, the tool would break)
- I've somehow forced the machine to try to push through its limits and crashed an axis into the chassis (and if steps weren't skipped, the machine would be seriously damaged)
Basically, the only time the steppers have failed is when not doing so would lead to much greater damage, so I'd go so far as to say that skipping steps are a feature, not a bug.
If your steppers are failing in the middle of a job where nothing has gone wrong, either your steppers or your drivers are messed up but it's not because steppers are inherently bad.
I'd recommend servos for applications that are demanding on torque, power, speed and/or accuracy. I wouldn't recommend them for your first DIY machine because of the additional risk, expense and complexity they add.
This is a really good starting place but as someone in the middle of retrofitting a commercial CNC, it's missing _a lot_ as well. My highlights while reading:
- For an Aluminium frame, you could also use solid Aluminium bar or plate. Depending on your location, it might be cheaper/easier to acquire. One benefit is that plate especially can be purchased pre-milled, so you can get it very flat, which is good for things like mounting linear rails, which require high-tolerances from their mounting surfaces.
- Missing from the "Linear guides" section is the varying tolerances and rigidity specifications of the various options. Linear rails can have some crazy high ratings for stiffness (e.g. page 27 of [0]) and high degrees of parallelism and overall precision. Shafts are often unspecified. However a tradeoff here is that linear rails also require high tolerances from the surfaces they're mounting, otherwise they're out of spec and can wear out quicker. It also misses that rails can be quite expensive. I'd also add that though the rails are low-profile, if you want more clearance you can always elevate them.
- Missing from the "Linear actuation" section is how much stuff and expense goes into a proper ballscrew setup. In addition to the ballscrew and nut (which usually have to be purchased pre-assembled together), you also need a fixed support to hold the motor-end of the screw (this keeps the axial load off the motor), a floating support at the opposite end of the screw, some kind of mount to hold the stepper motor concentric with the screw and a coupler to connect the screw to the motor shaft. Ballscrews can also be expensive.
- I'd actually add a whole section for the stepper drivers. 3D printing in particular has led to some interesting options that can be applicable to smaller DIY CNCs. Trinamic stepper drivers for example are able to drive stepper motors silently, even with high current.
- I'd add accuracy to the pros of servos. They're typically limited by the resolution of the attached encoder, which can be obscenely high.
- The controller section is focused on Arduino-based or derived controllers which aren't much seen in much of the DIY CNC community. The most popular options by far are [1] Mach 3 and LinuxCNC/PathPilot. Personally, I really like EdingCNC [2] but it seems to see limited success outside the German-speaking parts of Europe.
Why would they pay the owner for "seizure of property"?
The owner of the bird is responsible for the bird. Therefore, the owner is responsible for the bird illegally entering Australia in violation of local customs laws, just as a dog owner would be responsible should their dog bite somebody.
I'm all for returning the bird to the owner but from Australia's perspective, the owner committed a crime. It's ridiculous to suggest that the owner should be compensated for the consequences.
The bird should be returned upon payment of a fine and reimbursement for the costs of finding, capturing and transporting the bird back to the US.
> The New York Attorney General proved in court they had at least 95% in cash deposit backing.
I think that's a deceptive mischaracterisation of what the NYAG has done, unless you have more information than what I found.
The NYAG has accused [0] Bitfinex/Tether of misappropriating up to $900M (which I'm guessing where your missing 5% comes from) of Tether's reserves to cover up some other dodgy stuff they were doing.
But absence of lawsuits covering the other 95% doesn't mean that the NYAG has "proven" that the rest of the money is there.
> Please put your money where your mouth is, no one seems willing to do so these days and I truly wonder why.
> Shorting bitcoin tether is literally a few clicks away for everyone on the planet, why not go bet everything you have on it.
Speech isn't pay-to-win. Nobody has to bet their life savings shorting Bitcoin futures in order to participate in a discussion.
> Folks that are privacy concious are equally deluded. It's marketing and you're falling for it.
At the very least, if you use providers other than Google, you can decentralize it. You can give one company your search history and a different company your emails. Even if both companies are equal to Google in terms of privacy, you still end up with better overall privacy because tehy can't join the two datasets.
> ProtonMail doesn't have stellar record for privacy (or any Swiss company in general).
Can you back that up with some references? I live in Switzerland and Swiss data protection law is certainly better than American.
From the Whitepaper: "Due to the inherently asynchronous nature of mobile messengers, providing reliable Forward Secrecy on the end-to-end layer is difficult. Key negotiation for a new chat session would require the other party to be online before the first message can be sent."
That's not a problem for voice calls because voice calls inherently require both participants to be online.
Though I am curious why Signal's approach [0] wouldn't work for Threema.
I think you're reaching about about Switzerland being the problem here.
> Threema was launched in 2013
> WhatsApp was bought by Facebook in 2014
So a year after Threema's launch, it was competing with a multi-billion dollar global corporation which already had a user count in the billions.
> Signal to launch an iOS app in 2014
Signal is free (which a lot of casual users care about) and open-source (which a lot of privacy/security-conscious users care about).
> Why? I'm guessing because the founders lacked the experience or the right people to guide them from startup into massive growth [...] sadly Switzerland lacks the people with that kind of experience.
Can't the same be said of other European tech startups like Spotify and Skype?
Plus, ProtonMail, another startup in a similar space, based in Switzerland, has managed to become basically "the" secure email provider.
I think the real story here is much simpler: Threema is a small company and came into a competitive space where it had to compete on multiple fronts: tech giants on one, open-source on the other. As a paid _messaging_ app, it had a difficult future ahead of it whatever it did, no matter where it was based.
And for Switzerland in general, remember that it's a small country that has fewer than 9M people. Don't take the absence of unicorns to indicate that they're impossible.
EDIT: One more thing that occurred to me - what's the alternative? I'd suggest that a good part of the reason why Threema got the success it did in the German-speaking world was that it was from Switzerland. If it came from say the US, I suspect it wouldn't be trusted.
Any CO2 sensor (part) that gives you the ability to turn off ASC should work just fine and most of them do, you just need to trigger it.
Personally, after trying out a bunch of sensors, I use the Sensirion SCD30.
As for devices, I'm not aware of a consumer device that I'd recommend. If you're willing to do at least a little bit of DIY, Watterott [0] sells an SCD30 hooked up to an Arduino-compatible MCU with WiFi, a red/green/blue indication of CO2 levels and ASC disabled by default [1].
It's an open-source hardware design and software [2] and has a few reference firmwares [3], including one [4] for MQTT.
If you want to go a little bit further, I'd recommend an ESP32 with an SCD30 and ESPHome [5]. That's what I use myself, mostly because I already had the sensors prior to Watterott's product existing.
I've seen references to this sensor before and find it a bit concerning that there's no information about how to properly use the CO2 sensor.
This sensor uses a SenseAir S8, which like most CO2 sensors, has an automatic baseline calibration algorithm enabled [0], which expects to see pure, undiluted fresh air at least once every 8 days. The only way to disable it is explicitly, through the MODBUS interface [1].
Leaving it enabled makes perfect sense in a business or businesslike environment because these environments will be completely unoccupied overnight and have air conditioning, which usually does a daily fresh-air purge, ensuring that the sensor will have regular exposure to fresh air.
However in a residential environment, the auto baseline calibration often doesn't make sense, especially in winter. When the windows are closed and/or people or pets are around, it's very rare for the sensor to see uncontaminated fresh air, so it will see say 500ppm of CO2 and assume it's fresh air when it really isn't. I have measured this and it's a real problem.
In a residential environment, unless you're sure you have good, frequent exposure to pure fresh air, you're better off doing a fixed calibration once a year or so.
AirGradient also seems to be a hardware-only design. The ESPHome project [2] has great software support for a variety of sensors (including the SenseAir S8, so it should be compatible with the AirGradient hardware) as well as a very well-documented hardware project [3]. After trying my own Arduino-based software and then ESP-IDF, I find esphome much more pleasant to work with.
> nowadays raw (or indeed the ever-shouting all-caps “RAW”) is primarily a marketing term used to denote lossily processed data left and right (ProRes RAW, BRAW, Sony’s “raw” .arw files that in fact come lossy from some cameras)
That does happen but I don't agree that it's "primarily" used that way. Canon and Nikon are still dominant and still use it to refer to uncompressed raw images.
> There's no way to provide access to the social graph in a privacy preserving way. It's not okay to allow a third party to access the data your friends have shared with you without your friends consenting.
If the API is open and there's forced interoperability, the client device can call the service's API directly with the user's own credentials. No need for a third-party middleman, so no need to give a third-party access to the data.
It can work the same way IM applications like Pidgin work: one app, multiple accounts.
As for it being tested, I can assure you that it's taken very seriously. One ruling that demonstrates that is [1], in which Switzerland's highest court ruled that an individual's right to privacy has higher precedence than a copyright-owner's right to police copyright infringement.
There's also a constitutional right to privacy [2], though the Swiss constitution is a little different to the American one.
One notable and enormous hole in Switzerland's record however is the BÜPF [3], which, as I understand it, requires ISPs to log DNS requests, among other things. That shouldn't be relevant here though, so long as Quad9 doesn't become a telecommunications provider.
[0]: https://www.fedlex.admin.ch/eli/cc/1993/1945_1945_1945/en
[1]: https://www.swissinfo.ch/eng/privacy-triumphs-in-internet-pi...
[2]: https://www.fedlex.admin.ch/eli/cc/1999/404/en#art_13
[3]: https://www.fedlex.admin.ch/eli/cc/2018/31/en