HN user

throwaway9d0291

788 karma
Posts0
Comments250
View on HN
No posts found.

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.

[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

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?

Sure, it can be simple.

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 disagree.

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.

[0] https://www.hiwin.com/pdf/linear_guideways_1.pdf

[1] https://www.cnccookbook.com/choose-best-cnc-control-2017-cnc...

[2] https://edingcnc.com/

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.

[0] https://www.bloomberg.com/news/articles/2019-07-29/crypto-ex...

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.

[0] https://www.signal.org/blog/asynchronous-security/

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.

[0] https://shop.watterott.com/

[1] https://shop.watterott.com/CO2-traffic-light-Plus-version-Wi...

[2] https://github.com/watterott/CO2-Ampel

[3] https://learn.watterott.com/breakouts/co2-ampel/

[4] https://github.com/mariolukas/Watterott-CO2-Ampel-Plus-Firmw...

[5] https://esphome.io/

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.

[0] https://rmtplusstoragesenseair.blob.core.windows.net/docs/pu...

[1] https://rmtplusstoragesenseair.blob.core.windows.net/docs/De...

[2] https://esphome.io/

[3] https://github.com/nkitanov/iaq_board

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.

No, I don't use Magisk because my phone isn't rooted.

Google Pay won't work even if SafetyNet passes because it depends on Google Play Services APIs that aren't implemented as part opf MicroG.

I haven't had any issues with any of my banking apps despite SafetyNet failing. They don't like root but they don't seem to care about SafetyNet.

Yes, I have a bunch of Apple devices as well.

I find that iOS itself and its first-party apps are fantastic from a privacy perspective, especially compared to Google. Most of the apps I mentioned using on Android have an Apple-provided alternative that's vastly superior to Google in regards to privacy. For example Apple asks you when you set up your device whether you want to allow analytics and easily allows you to opt-out. Apple also allows you to use basically every service other than Siri and the App Store without storing any data on their servers.

It's not all sunshine and rainbows though. Unlike Android, there isn't a strong open-source/privacy culture among iOS developers, so there are few privacy-respecting or open-source third-party apps (while on Android, F-Droid is full of them). And there's no app sideloading and the OS itself is locked-down and closed-source.

Still, I'd say that as far as stock mobile OS go, iOS is the clear winner in terms of privacy.

When it comes to non-stock though, Android is much better, with the right device. There are devices (mainly Nexus/Pixel) that allow you to re-lock the bootloader after flashing a custom ROM by adding your own system verification key. With these, you can build AOSP, LineageOS, GrapheneOS or whatever takes your fancy, sign it with your own key, flash it to your device and then bootloader lock it. GrapheneOS also has verifiable builds.

With that, you get all the advantages of a locked device but you don't have to accept the backdoor that is Google Play services.

I've been using a custom AOSP build with MicroG for a few months now and it actually works pretty well _if your goal is to avoid Google_.

What I mean by that is that if your goal is to use Android Pay, Chrome, Gmail, Google Maps, Google Drive, Google Fi etc. and somehow retain some level of privacy, MicroG isn't going to help. It doesn't fully implement _all_ of Play Services' APIs.

The point of MicroG is to make Android usable without having Play Services installed. With neither MicroG nor Play Services, many third-party apps fail to function. For example Lyft and Uber depend on the Play Services API for maps and many other apps depend on Google's network location service. If you try to use these apps without some replacement, the apps complain and shut down. MicroG gives you a way around that.

I'm quite happy with my MicroG-based phone but I use:

- OSMAnd or the open-source equivalent of Maps.me for maps

- My country's public transport app for public transit directions

- FairEmail for email

- Element for messaging

- Slide for Reddit

- Firefox for web browsing

And actively avoid all of Google's apps and services (except the occasional search and YouTube).

Blender 2.91 6 years ago

If you personally don't want to use the NURBS pieces, then feel free to ignore them. But please don't block other people from doing so. :)

I'm not saying NURBS shouldn't be fixed/updated, I'm just debating whether "so that Blender can be a CAD/CAM package" is a reasonable motivation for it.

Blender 2.91 6 years ago

Does it really make sense to use Blender as a CAD/CAM package?

CAD is all about building mechanical parts with features that match needed specifications. For example you need a block with holes in it with particular spacing, particular diameter and particular depth. CAD packages like Fusion 360, SolidWorks, FreeCAD etc. are all dedicated to this task and make features like constraints and measurements front and center.

Blender on the other hand is, at least in my experience of it, all about bringing somebody's artistic vision into a 3D environment. It's usually not important to somebody's vision that parts meet dimensional constraints, it's more important that it looks "right". And so Blender is full of tools that allow humans to change things to arbitrary dimensions.

Does it really make sense to try and fit both of these use-cases into one tool? I can't help but think that Blender would come out worse for it.

And that's CAD, I really can't come up with any reason why CAM would make sense in Blender.

Is there something I'm missing?

Show HN: Zfs.rent 6 years ago

I'm not aware of another service that offers a turnkey remote full filesystem (ie not just an object store) that you can access over SSH.

I know it's not what you meant but keep in mind that as-described, that's every single server provider.

And I think including what you meant (e.g. ZFS set up), it's literally a one-line command to create a new zpool on a new server.

I'm not saying that rsync.net is worthless but it's certainly not worth the price it's charging for anyone who cares about the price.

Your Hetzner numbers are impressive, but I don't think there's anything available in the US for a similar cost.

When I was in the US I came to the same conclusion, so went with colocation.

However OVH has a datacenter just over the border in Canada and its brands Kimsufi, SoYouStart and OVH [0-2] can get you down to $5/TBmonth.

And it looks like they actually have a couple of US datacenters now, which is new. A quick look shows that you can get a 16TB server for $92/month [3], which is $5.75/TBmonth.

But overall it looks like the dedicated server market in the US is still super expensive. You can always keep your bulk data in Europe.

[0] https://www.kimsufi.com/us/en/servers.xml

[1] https://www.soyoustart.com/us/essential-servers/

[2] https://us.ovhcloud.com/

[3] https://us.ovhcloud.com/bare-metal/advance/adv-stor-1/

Show HN: Zfs.rent 6 years ago

a Hetzner storage box

I think the better comparison would be an SX-line dedicated server from Hetzner [0] and this server isn't too far off that.

This service: $10 for 8TB, or $1.25/TB.

Hetzner SX62: 64€ for 40TB, or €1.6/TB ($1.9 USD).

rsync.net

Rsync.net is ridiculously overpriced. Even at their cheapest tier, 1TBmonth costs $15, for which you can buy 7.9TB at Hetzner. Even if you created 3 redundant copies at Hetzner, you'd be paying only half what rsync.net would charge.

[0] https://www.hetzner.com/de/dedicated-rootserver/matrix-sx?co...

Every IAQ CO2 meter

For example, suppose I buy two CO2 meters from Amazon

It sounds like you're looking at retail consumer products, which I think is the problem.

The Sensirion SCD30 _sensor_ [0] for example allows forced recalibration [1] to an arbitrary concentration.

Also, since you call it an "IAQ" CO2 meter, it might be that these aren't CO2 meters at all. They could be VOC meters that make up a projected CO2 reading based on the presence of other chemicals in the air. You need to make sure the sensor is NDIR-based and actually measures CO2.

If you want accuracy, don't buy retail sensors that don't come with spec sheets. I'd find the sensor you want first then find or build a meter based on it. For example the SCD30 can be connected to an ESP32 and connected to WiFi using ESPHome [2], which can be set up with some YAML files.

self-calibration

Just by the way, self-calibration is what you want. Real CO2 sensors drift over time and you definitely want them recalibrated at least once a year. Auto-calibration takes away that pain and when implemented in a suitable way, really works. Many calibration routines are not suitable for residential environments as they're based on the assumption that they will see pure fresh air at least once a day. This is a safe assumption in a business environment because most AC systems have an overnight fresh air purge. In a residential environment though, someone might not open the window once a day.

Again referencing Sensirion, their auto-calibration cycle looks for two, hour-long valleys in the CO2 readings over the previous two weeks that are within a few percent of each other and uses those as a fresh air reference. In my experience, this works well at home.

Another downside to this difficulty in testing is that it's hard to truly evaluate a particular meter's performance. Which seriously limits side-by-side comparisons of different models, and makes it harder to hold manufacturers / retailers accountable for poor performance.

You "just" need a reference to compare to. If you have a look at academic literature, they typically use a lab-grade setup to compare. You're right though, it's difficult for a regular home user to evaluate a sensor like this.

[0] https://www.sensirion.com/en/environmental-sensors/carbon-di...

[1] https://www.sensirion.com/fileadmin/user_upload/customers/se...

[2] https://esphome.io/

That's not necessarily an invalid comparison. From a technical perspective, NVIDIA's NVENC encoders for example have been able to compress H.264 with similar efficiency to x264's slow preset at several times the speed for a few years now.

And there's also the fact that for many purposes, it simply doesn't matter. Filmmakers often don't want an impeccably compressed, low-bitrate output ready for streaming directly, they want an output with the highest quality they can get, as fast as they can get it and don't really care how high the bitrate is as long as it's reasonable.

In use-cases like that, a faster render/encode is what's valuable and it doesn't really matter which processor is used to produce it.