I've been running a raspberry 3 with a cheap sandisk sd card for years now without any SD Card issues. It runs a DNS based ad-blocker and a vpn.
I am logging everything to ram instead of writing it to the card and that's about it. I never encountered any issue with SD Card reliability, despite me sometimes just pulling the plug instead of properly shutting it down.
I do have a couple of other raspberries for other uses (e.g. a small rc car) which are also running on their first SD card. Might be just luck, but I do think that it's not necessary to go to extreme lengths to have them run reliably.
Many problems with SD cards are actually rooted in power issues (bad power source or usb device that eats power). Ever since I took proper measures to ensure stable enough power I've had no issue (Pi 3B here)
> Many problems with SD cards are actually rooted in power issues
Does anyone have any info on this that's more substantial than hearsay? Experiments, measurements or at least a more technical explanation than "bad power source"?
I'm persistently hearing this story that power supply quality affects SD card life. As an electrical engineer, and given what I know about R. Pi design, I fail to see how an SD card could get physically damaged by any reasonable power supply that would otherwise run the rest of the R.Pi.
I suspect people are confusing filesystem corruption due to brownouts/OS not shutting down cleanly with physical damage to the flash (i.e. unreadable sectors on SD card)
> I'm persistently hearing this story that power supply quality affects SD card life
Not SD card life indeed (in my case at least), merely IO failing, hosing the filesystem long term because of b0rked writes. The SD card is fine, it's just the data that eventually becomes inconsistent garbage.
I noticed the power LED showed the undervoltage behaviour, measured the power output which indeed showed the voltage not being stable on power spikes, so bought a better power supply, problem gone. Got the same kind of issue with greedy USB devices, so either went the powered hub route or used self-powered hard disks.
I can second this. My previous company runs a few hundred Pi units across loads of separate locations; the locations where we had constant corruption issues were also the ones experiencing dodgy site power-supply issues. We did try various alternatives to cheap SD cards but ultimately running them off PoE from a switch attached to a UPS was a pretty good solution to the issue.
Just get a good-behaved power supply that doesn't drop voltage too much on power/intensity spikes. Power supplies made for charging don't care about that (even high-amp ones).
Also get better-behaved USB devices and/or power them by other means than the Pi itself.
I believe the reply was focussed towards the gig economy and the use of venture capital to scale aggressively.
I agree with a lot of points op is making, but when it comes to e.g. the gig economy and using vc funds to scale b2c businesses by undercutting competitors, I'm very happy that we have a different situation in Germany.
Actually you can. A few years ago, when paying with a German bank card, very often the transaction was turned into a direct debit transaction, because they used to be cheaper.
This used to be very common in supermarkets. Every time you had to sign the receipt this was happening. It's not as common nowadays as the fees are now more or less the same.
Please also check this twitter thread, according to the Medical University of Vienna and the German Robert Koch Institute this is not confirmed. WhatsApp messages with a similar message (and a “quote” of the Medical University of Vienna) are deemed to be fake news.
They send it to Google Colab. It allow you to run model over a powerful server for free. 6 GB of download at this crazy bandwidth cost would still be cheap versus offering themselves that kind of beast of a server to 60k persons each day. I remember when I tried it I saw that it used 10 GB of memory, that was crazy!
You'd save on transferring the bytes around, but now you would have to self-host jupyter and the GPUs it uses. That is going to be even more expensive than IP transit because now you have to have 60,000 12GB GPUs in your datacenter.
Like I said before, this is one of those things that wouldn't exist without the Cloud. If you run things on your user's computers, you have to send them a lot of bits. If you run things on your own computers, you're spared that bandwidth, but now have to have enough "computers" to satisfy your users. It's simply something that's not super cheap to run these days.
I will admit that it is surprising that Google <-> Google traffic is billed at the normal egress rates, but the reasoning does make sense -- a 30Gbps flow is nothing to sneeze at. That is using some tangible resources.
If you need more than 2TB it's quite likely that you are using the product in a professional context. Thus, they are able to charge more. The smaller tiers are cheap to be attractive to end consumers.
There are a few things mentioned in [0] and [1], unfortunately in german:
- The contracts are based on Irish law and contain rules that violate German employment laws.
- They have to pay for water on the flight, in addition to lots of other things (e.g. health checks, mandatory simulator hours). These costs can sometimes be deducted, but they argue the airline should pay for it in the first place.
- When they are sick, they have to come to the office/airport and state their symptoms in writing.
- Lots of Pilots are hired as contractors, not as full time employees. That would also violate German employment laws.
1) The trains go every 30 minutes to Munich, so I don't have to wait that long.
2) The price structure of trains vs planes. The standard DB train ticket is flexible, i.e. you can use any train at the given date. Booking a flight on the same day is very expensive (and might be impossible if all seats are taken). There are discount tickets that are not flexible, but the price of the flexible ticket doesn't increase to enormous sums just because I book it on the same day - it's always the same.
On the other hand, in my experience the cheaper inflexible advance tickets stay cheap for longer for flights than for trains. I guess it depends on whether you travel for business or leisure.
I am logging everything to ram instead of writing it to the card and that's about it. I never encountered any issue with SD Card reliability, despite me sometimes just pulling the plug instead of properly shutting it down.
Here is a simple guide: https://raspberrypi.stackexchange.com/a/62536
I do have a couple of other raspberries for other uses (e.g. a small rc car) which are also running on their first SD card. Might be just luck, but I do think that it's not necessary to go to extreme lengths to have them run reliably.