I finally found a use case for my Raspberry Pi Model B+
ounapuu.ee
ounapuu.ee
It's a great use-case for it as it's not very demanding, and essentially doesn't require networking aside from NTP to keep the clock up to date.
Are you using speakers or headphones? If headphones, wired or wireless? If speakers, where do you place them and is strange sound localization an issue?
I recently tried sleeping with inexpensive Bluetooth headband headphones, which was a great expensive. I liked the feel around my head, but am curious about the speaker option.
My friend was using a much nicer stereo setup for much higher realism for the rain sounds.
ATtiny85 are dinky little chips to use.
It's instant-on and off, and I don't have to worry about corrupting anything, or some upgrade quirk like I do with the RPi. I was still using my original RPi on a permanent basis until recently. RPis are not obsolete if your requirements are modest. Try running X-Windows and Firefox and you're in for trouble, though.
It has since acquired a snazzier encasement using balsa wood. I bought some wire mesh for the front of the speaker, to give it protection.
If you want to do day/night timing (although I personally think that's overkill) , you could think about adding a DS3231 clock. I recommend steering clear of those really cheap Chinese modules (DS1307, if memory serves). They're a complete waste of time.
Have fun!
I might use it, but instead my wife and I just turn the air purifier to maximum to get a lot of brown noise .
It boots in about 10s now too.
And I don't need much, just 32MB would be enough, I would just boot linux using using a read only SD card.
It's a major flaw, I don't understand why they did not find a fix yet.
I have /var/log and /var/tmp on tmpfs tho
(I'm not blaming you, it's hard to have a pure RO FS, that would help a lot - and a standalone RPi doesn't need a lot of stuff that comes by default)
Every month or two, disable the overlay (again using raspi-config), reboot, apply updates, re-enable the overlay, and you are good to go.
Also, if you are using a PI4, switch to booting from a USB stick and just forget about the SDcard.
(I've been running openwrt on a pi just because it had an overlay filesystem - I could run raspbian now)
Never had trouble with the 3 that was a Kodi box and latterly has been used for some electronics experiments, the 4 that is my current Kodi box, or the 400 that has been playing as router+firewall+VPN since early this year (at the time getting a 3 or 4 for the job would have been either expensive or near impossible, and I didn't want to try a potentially less well supported option, but I spotted a nice offer on a 400).
[0] https://www.adafruit.com/product/1497
We ended up replacing the Pi(s) by an Intel NUC, which was just over 100 Euro in 2018 without memory and storage. For relatively low cost, you get SATA speeds (or NVMe if you are willing to spend a bit more) and an AES-NI capable CPU. Our current NUC has been humming along for 4 years.
Ps. Syncthing is not backup, even with a read-only node. You are just one Syncthing bug or sysadmin failure away from erasing your data. Having the files on btrts on a single SSD only makes it worse.
Just get some redundant block storage somewhere that supports object lock (to prevent accidental deletion or ransomware encrypting all your files) and do incremental backups with something like Arq or Restic. There are some good services where 100GB storage costs $1 monthly.
Re ransomware, how do you prevent it from deleting remote backups?
Of course finding the bugs in firmware and writing a custom replacement is not trivial. It is conceptually possible though.
The only safe answer is a device in a vault without power. Of course once you retrieve it from the vault you risk whatever erased your data in the first place returning to get this too.
Good luck, you get to decide how paranoid you want go be.
It works really nicely, I can't even remove my own data with my own credentials. It's really a nice additional security layer.
Big security issue, and honest people will just apply for a bug bounty or otherwise responsible disclosure. Most honest people are not actively looking for such bugs though, so evil people are more likely to find them. An evil person is can make even more money from a successful ransom. (there are also honest people looking, but many wrote the code so they may be too close to the problem to see it)
Re ransomware, how do you prevent it from deleting remote backups?
It can't, locks on objects cannot be removed in compliance mode. They can only expire.
https://www.backblaze.com/b2/docs/file_lock.html
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object...
Making something someone else's problem doesn't magically make the problem go away.
I hope we can at least agree that it is 3-4 orders of magnitude more likely that an SSD with btrfs and no RAID attached to a Pi to lose data within a given time period than, say S3?
But what if that has a bug?
Multiple write-only DVDs are clearly the only option per your logic.
You also can't just add on backups indefinitely or your costs will also approach infinity given enough time. There has to be a mechanism for deleting things, be it on DVD or on object lock cloud hype.
Personally, I think a backup is just that: a reserve copy. It should be reliable, but so long as you test your backups regularly, you can be confident that there won't suddenly be a bug when the primary copy fails. I, too, like to have two independent backups instead of one (happened to me before that, due to a niche mechanical failure called little brother, an external backup drive failed very soon after the primary), but saying one shouldn't use normal sync software "because it's one bug/misclick away from erasure" is silly. There can always be bugs and misclicks. They even mentioned using a read-only mode. It's a matter of how certain you want to be, and most people don't have any (automated) backups in the first place. Syncthing or similar software wouldn't be (isn't) my choice of backup software either, but I wouldn't dismiss a simple solution that works fine for them.
Object locks have a configurable expiration date.
But what if that has a bug?
Again, this is yet another typical HN discussion. We are now comparing a consumer grade SSD taped to a Raspberry PI without ECC memory to a theoretical bug that might be in S3's or B2's object lock implementation. They have stored petabytes of data and there are virtually no reports of data loss ever, nor has anyone bypassed object lock, even if it's a high-value target.
Many people forget that the Pis have a wealth of peripherals accessible on the GPIO headers.
I suppose those interested in EEPROM programming and IIC, SPI, and UART probably know this though, and probably (like myself) have dedicated devices for that task.
Still, I have about 10-15 Pis from B+ to 4B sitting in drawers, the Pi Zero (2)s are the devices I find the most use for, so I'd love to bring some back into commission but OPs solution isn't it for me; I have powerful hardware with a plethora of storage and redundancy for that.
Once upon a time, with my OG Pi, I had a GSM "HAT" (before they were called that), and wrote a little API in C/C++ that would text me, so when my UPS detected power down/power restored I'd get a text, followed by another with my new IP address (because it wasn't static). I still have the Pi and "HAT" but don't really need the SMS part anymore.
The parallel and serial ports on a PC used to serve the same purpose. But many modern systems don't have them. You can use USB converters, but latency is usually terrible due to USB overhead. The 3.3 V logic on the Raspberry Pi is also easier to use than 5 V TTL level or 12 V RS-232 logic level.
"Overkill" tends to disappear when you consider the cost of your time. You are not penalized for not using all, or even most, of a platform's capability. Silicon is cheap, programmers are expensive.
The pi shines at doing complex tasks that involve physical I/O when the device is manufactured in low unit volumes. e.g., a few years ago, I built a machine to do a proof of concept for a physician. It was based on a Pi 2B solely because he wanted a touchscreen. The entire thing could have been built with an Arduino, but the hardware cost to do it on a Pi was only about $40 more than on an Arduino. That difference was more than an order of magnitude less than I would have had to charge to do the touchscreen software on an arduino.
When I was working for an engineering services company, there many applications that we could have put a Pi or a Pi Compute Module into, even at larger volumes but for one reason or the other the company would suggest a ground-up CPU board design to the customer...
In short, it's a low-power tiny linux server which I'm satified to tinker with, and I assume other good SBCs like BananaPi/ODroid/etc will serve the same perpose well also.
Looks like popularity also has its costs.
I'm loathe to have the drives regularly spin down. That sounds like a good way to make them wear out quicker. Though spinning up twice a day might not be too bad.
This gives me an idea; I might see if I can run some thermal testing on all of the Pis I have using my Flir to get some thermal images and put together a little write-up.
I've done a bit of experimentation previously when I'd build a little 1U server case with 3 Pi 4B in and added a custom fan controller (using an ESP32) to stick in my network rack, and it was running Kubernetes, but I didn't keep it long.
For RPI4, firmware update is requried to improve rpi performance and decrease temps.
EDIT: What that post is missing, is a comparison of all generations of the Pi; We know the Pi4 is hot, but I haev every previous generation sitting in the drawer, might be interesting (for me at least) to do some comparison.
Services: syncthing to sync photos and videos on my phone, SMB, nfs, FTP (accessible from internet), a web file explorer (on docker, exposed to the internet with basic auth), a torrent client (on docker, exposed with basic auth), caddy (for reverse proxy with https).
It's not the fastest you can have, but it works ok for what I need.
I have a separate pi4 box with Kodi from which I can view photos and films on the telly.
I used to run syncthing on B+ for a few years, it was quite ok.
recently i found a strange issue. i can access rustdesk on a device connected at home which goes through pihole. so the pc says no internet connection, triangle on the network icon (win10) and firefox does not work. restarting didn't help either.
it was troubling because i could use rustdesk just fine, only problem was the machine thought it could not access internet.
checked pihole address and it was not responding. sent remote hands to unplug and plug pi-zero to the router usb itself and everything worked.
(yeah yeah, I know, you can’t parse html with regexes. For a super tightly controlled web page like this one it works just fine.)
edit: it’s a 2 B, the first one wouldn’t be able to run Home Assistant, I think
Why can't they even add 64MB of flash memory to store a bit of user data? That can't be expensive, or maybe I don't know how electronics work?
I can disable writing on a SD card to improve its lifespan, but honestly the RPi is pointless if there is no durable way to store data on it.
I love the concept of the RPi, but this is a major flaw and it's still not fixed.
I think there are some more distros with larger ecosystems that use just RAM, but picore has met my needs and is a piece of cake to set up.
> Why can't they even add 64MB of flash memory to store a bit of user data?
What you're describing is a pretty niche requirement, as 1GB isn't enough to store much of anything these days (and 64MB?). They do make the Compute Module, which is available with 8, 16, or 32 GB of onboard storage.
> I can disable writing on a SD card to improve its lifespan, but honestly the RPi is pointless if there is no durable way to store data on it.
A quality portable SSD attached via USB (and not relying on a SATA dongle) works great. A good one will cost you at least as much as the Pi board itself, which sometimes rubs people the wrong way.
Looking at stats, my SBCs take between 9-30 GiB of writes a month. So that's already 1-2TiBs of total writes. That doesn't sound like much. Like 30-60 total overwrites of the SD card. I'd expect the card to take 200-500 complete overwrites.
Basically infinite lifetime with this amount of write load. PSU will probably stop working before the SD cards will.
I also set it as "receive only", so any accidental deletes don't cascade.
I have a similar set up. I have a NextCloud server set up in my house, running as a docker container. A cron job shuts it down in the middle of the night and runs a full, true backup process up to AWS, and restarts it when done. The convenience of file sync techs with the safety of backup.
(The main utility of docker to me in this case is just being able to assert with absolute certainty, "here are all the directories NextCloud is storing data in". There's nowhere for unbacked-up state to be hiding.)
If I were running this at scale, I'd have some things to worry about, but at this scale, it's fine.
I don't disagree that Syncthing is not ideal as a backup solution but it can be a pretty decent one depending on your use-case.
File versioning / version history would help, if you have sufficient disk space for all the versions. But you can be more confident in the backup integrity if it is taken offline once completed - eg cloning a drive to an external drive, and then unplugging that external drive and putting it in storage until needed.
A pi is actually a great solution because it's quiet and tiny, so you can place it at a friend's place and use physical access whenever you need to work on it. No need for the backed-up (potentially ransomed) system to have any access to it, ever, beyond the append-only encryption/authentication key for adding new backup data.
The author describes how he takes immutable filesystem snapshots.
Once upon a time, Summer 2019 I got this https://www.friendlyelec.com/index.php?route=product/product...
and something between their NanoPi Neo2, but with 1GB Ram,
and NanoPi Neo2 Black, but without the EMMC the Black has.
I've put Armbian on it, and it works since then, slow but stable.
It even "speaks" https://en.wikipedia.org/wiki/USB_Attached_SCSI so not even that slow :-)
2TB internal, 4TB 3,5" external with own powersupply, attached only for Backups.
Runs between 400Mhz and 1Ghz on demand. Does only storage.
No firewalling, routing, adblocking. I've got other gadgets for those.
I can saturate about half of my feeble 45Mbit/s uplink with it, which is enough for my needs. So far...
Some software existed, like duplicity with pgp, but it had major downsides that I had ideas about how to do better. I was pretty proud of the chunking algorithm that I had adapted from rsync, and I got really good performance by using python for the logic and C for the code that actually operated on the files, but that's also where the interest started to wane.
Restic with rest-server in append-only mode is a nice solution, but I'm not aware of anyone packaging this in a pre-configured image you can just flash. You'd also have to balance who backs up to whom. If that could somehow dynamically balance, that would absolutely be a dream.
They do warn that this feature is in beta/testing, so I wouldn't trust it with super critical data.
I always wished they would offer a less affordable, substantially more powerful (sufficiently to handle the YouTube and similarly heavy websites without so much pain, also having more PCIe/USB3 lanes perhaps) model. I wouldn't even mind if it was overpriced i.e. extra premium billed to subsidize the budget version or other charitable projects. Unfortunately 3-rd party clones are not a perfect solution because they don't have the said community and are not perfectly compatible. Or is there already a clone capable of running the original Raspberry PI OS?
Odroid seems to have the most powerful hardware in the SBC space currently, support varies by project.
I just want the "modern web" to work Okay (YouTube and alike websites feel slowww, I mean not the actual video playback but the page itself) while keepig it being a Raspberry Pi in all the rest of the aspects (except the price - thanks G-d I can afford it cost more).
For example Raspberry Pi comes with community-standard GPIO also usable for extension "hats", uniform format (so a whole chassis market emerged for it), free Mathematica, well-supported Kodi and Lakka packages, numerous alternative distributions treating it as a first-class target.
By the way, the latter seemes especially intriguing to me. I imagined (before the supply chain apparently broke) Raspberry Pi becoming a standard hardware platform for all sorts of alternative OSes, potentially letting projects like like Haiku, ReactOS, Serenity etc out of the virtual boxes.
If your system cost can absorb it, this gives you a huge amount of flexibility and capability.
x86-based mini-PCs that are abundant on the used market, pack quite a punch, and generally use around 10-12W idling.
And with the current Raspberry Pi 4 pricing, they are actually a better deal.
- diy: https://www.flightradar24.com/build-your-own
- preassembled receiver: https://www.flightradar24.com/apply-for-receiver/
It also runs HomeBridge which also runs rock solid. I can now control my mini-split and pool equipment straight from Apple Home, which is way faster and easier than the crappy apps that they came with.
What are the recommended data storage file systems nowadays?
In this setup with a single SSD, it has no role in preventing data loss if the SSD itself fails, but it should prevent data loss in case of user error.
If possible, use ZFS, and in case that isn't an option, use BTRFS if you need the data integrity guarantees and at least some protection against faulty hardware in mirror/RAID-like scenarios. That's my two cents.
Benefits in this context would include checksumming, compression, snapshot + incremental send, built-in kernel support (which is why I use it as root filesystem even on machines that use ZFS for data integrity), very flexible RAID1 setups, the option for DUP data on an SDcard (still unclear to me if this would improve odds of recovery in case or error or just increase the odds of corruption in the first place).
ZFS may be king in many / most scenerios, but I've been very happy with my Pi on BTRFS root that I've used with Ubuntu server, Raspbian, and now NixOS[0], on Pi 2/3/4.
The fact that Pi is so underpowered that it cannot even make full use of the SSD is probably a contributing factor to the overall stability.It's absolutely mine and that's what I love.
Of course, could be the USB wifi more reliable.
I have never used the WiFi on newer Pi-s that shipped with it, so I cannot say how reliable that was. The USB WiFi adapter seems to work quite well, assuming you have the firmware packages present (included out of the box on Raspberry Pi OS).
like most people, i ended up using it as a "server" because i stopped using its GPIO ports. currently using it for sync and exit node.
most people should just get an old pc or repurpose existing old pc/phones for most of their needs than to contribute to the RPi supply issues. linux works everywhere*, remember?
That makes me cringe. If a server's purpose involves serving files, those files should go in /srv.
https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.htm...
If I read the docs right, if a database needs to keep data permanently, /srv seems to be an ideal place. It's not restricted to static files being served on a network, just where data (regardless of format or transformations) should be stored.
More abstractly, if any daemon, service, or file share needs to store any data that is read/written to/from a network, that data should be in /srv. Probably.