It works until it doesn't.

To be fair, it kind off started off as a large iPod Touch. It took a few years for iPad to really differentiate itself from iOS devices.

Yes there are different energy retailers in different markets offering hourly priced tariffs, Tibber being an example. The deployment of the required smart metering varies widely between countries.

The Unifi Dream Machines allow you to set them up without a cloud account since the latest update: https://community.ui.com/releases/UniFi-OS-Dream-Machines-1-...

The Dream Router falls within your price range but is hard to get ahold of right now: https://eu.store.ui.com/products/dream-router-ea

Should be able to set it up and manage it over the local network via their mobile apps or via browser.

How I wish it had native Vulkan support.

It usually takes 1-2 years for AWS to roll out their latest updates to the regions I use and by then Terraform is stable.

Line separated JSON has its uses, for example when streaming data.

Ok, but what if you want to transmit two streams? You'd get something like Interlaced-newline-delimited-JSON. And so the list of required file formats knows no end.

If you're transmitting two streams you use two streams to transmit. I don't see the problem?

Two streams over the same channel.

I don't see why this is a problem with ndjson anymore than it is a problem with other stream text encodings (like CSV).

ndjson seems to be about how to format the content of the stream, not about how to multiplex multiple streams over a single channel. Use http2, zeromq, raw tcp or whatever else you like for that.

The only reason people care about newlines for a stream is because they've arbitrarily chosen to fetch bytes from the stream until the next newline sequence (readline instead of read). But you could just as easily look for a different sequence, like the ASCII record separator character which was invented exactly for this task, and then you wouldn't have to destructively strip newlines from your input.

I'll switch from \n to \x1E when cat, head, text editors, etc. start supporting the latter as a synonym for the former.

We tell our customers our streaming API uses jsonlines for documentation purposes, but we actually just decode in a loop until EOF, and 400 at the first decode error. No separators necessary at all.

can you explain why my question was downvoted

thanks for link couldn't find it on their webpage

You could literally google this and get 10 answers.

They were probably promoted a few times for hitting their targets then exited to join executive teams in various companies.

I agree. I have run quite a few Raspberry Pi over the years and so many of them died because of SD card corruption. Eventually I got a NanoPC T4 with built in eMMC and it’s been tugging along for a good 2 years with zero issues.

I've never experienced this SD card corruption, even when power goes down to the Pi. I believe it happens, but I wonder what my unique circumstances are. Is it that I always use Samsung or SanDisk SD cards with the Pi?

> Is it that I always use Samsung or SanDisk SD cards with the Pi?

Quite possibly! Flash memory is absolutely not all the same. I wish someone would do for SD cards what Backblaze does for hard drives.

> Is it that I always use Samsung or SanDisk SD cards with the Pi?

Oddly enough, Samsung, SanDisk, and Sony are the three brands I've had die on me. I had a GoPro eat two Sony cards in less than a year, I switched to SanDisk Endurance and it's been plugging along for about 2 years now. I've had one Samsung and a couple SanDisk SD cards die in Raspberry Pi's. I'm currently using MicroCenter, AData and one other lower tier brand that have held up much better than the name brands.

Those will still eventually die due to log being written to the card using all available read/write cycles.

You mean /var/log or filesystem log? What about using non-journaling filesystems or keeping /var/log on a ramdisk?

That's a problem that will eventually affect any flash solution -- SD card, SSD, or USB flash.

They usually just stop accepting writes (silently). It's a bit of a head scratcher at first. But at least it doesn't lead to a complete data loss.

> I have run quite a few Raspberry Pi over the years and so many of them died because of SD card corruption

The Pi themselves don't die because of a SD corruption. Only the SD cards do (and they can be recovered).

I've had a raspberry with SD card for more than 3 years now, still working fine. YMMV obviously

Had similar and switched to a cheap used desktop. I was running Home Assistant [1] and my guess is the constant writing of state history into the database slowly killed the card.

[1]: https://www.home-assistant.io/