(You are, of course, free to be as myopic as you wish -- just as everyone else is.)

The dam may well be broken, Congress has proven to be full of cowards and the next aspirational autocrat might well win and do better.

Instructions that deliberately lack specificity, like "Drill a hole for the switch and then mount it" work fine in meatspace whether those instructions are issued by a bot or a human teammate.

Sure: Going all-in on the bot with the hypothetical sorter and pick-and-place delta robot and the soldering machine? That's never going to be cheap.

But one doesn't have to go all-in. The bot (potentially along with an army of subagents) can ingest a goal and a list of parts on-hand and their specifications. Like an army of bots that is instructed to write code, it can sit there and iterate on designs like a thousand monkeys with a thousand typewriters until it finds one that actually works.

The humans (remember the humans?) can sit back and have a beer while this happens, and then start the physical process of hacking the thing together once the bot gives them direction.

Look at this list of suggested concepts:

  -  Building a ridiculous Apple II application
  -  Turning a fax machine into a social media network
  -  Turning a Game Boy Advance into a Bloomberg terminal
  -  Making an LLM-driven cash register that can feel love and pain
  -  An AI voice-activated microwave

Except zvols present as real-live block devices that can do block-device things instead of regular-file things, and that's important for some stuff.

But AFAICT, iSCSI targets on Linux are not one of those things. They don't care; they work the ~same whether backed by files or block devices.

And on the performance benchmarks I find that compare performance of zvols-vs-files on ZFS, files usually win.

> Why use zvols?

Probably for the same reasons that people recommended separate disk partitions for /var, /usr, and such as was the case ~30 years ago when I got started with desktop *nix systems.

That reason seemed to boil down to: "If it was good for a Sun/3 in 1986, then it must also be good for a Linux box in 1996." It was a dumb reason.

tl;dr, folklore. :)

ext2 disk corruption, especially on power failure or a crash, was a common threat in the 1990s. Not merely to the point of requiring fsck and a bunch of orphaned files (which was inevitable on an unclean shutdown), but just totally fubar'd, requiring a reformat. The only thing worse was then trying to reinstall Slackware from the floppy disks, at least one of which had a better than even chance of corruption from just sitting in the drawer since the last reinstall, requiring another long night nursing a download over the 2400 baud modem.

I use OpenBSD, and while FFS2 has been far more robust than 1990s Linux ext2, smart partitioning is still warranted, not just for minimizing blast radius, but also for managing backups, etc. I haven't had the chance to use ZFS, and it might be the only filesystem I might consider skipping partitioning for on a workhorse system, but even if you trust the design and code quality of ZFS, it's running unprotected alongside a bunch of horribly buggy kernel subsystems and drivers, so....

It could get worse than reinstalling Slackware, again, from floppies. I didn't get to experience corrupted floppies; I instead had a habit of recycling my Slackware disksets for other purposes after the system was up and running. So any complete re-install started by booting up MS-DOS to run Telemate to start downloading them fresh from Sunsite...again.

But at least it was Telemate, so I could manage files to free up more floppy disks while this process slowly continued at [I guess I was fortunate] 9600 or 14.4kbps. ;)

I don't recall much difficulty with ext2 being fragile (though I can provide horror stories about OS/2's HPFS). If I had issues with it, they didn't leave any scars.

But I accept your correction. It may have been the case that splitting the filesystem into different partitions made sense because ext2 was fickle, and I was just very lucky in deliberately ignoring that advice after the first time I misjudged the partition sizes at install and ran out of space in some directory or other.

Hard drives seemed so small back then. Installing a real OS meant a serious tradeoff in the ratio between user data and system data.

---

Anyway, ZFS. The ZFS way is that it owns the whole disk -- for a long time, the preferred method didn't even use partitions at all. Nowadays OpenZFS does create one partition for itself by default, but it uses the whole disk just the same.

Blast radius is limited by having different datasets (think "filesystem-light"), and read-only snapshots, and easy, consistent backups (if you have a compatible device or service to send them to -- otherwise, it's ~the same backup dance as any other filesystem with snapshots).

It's a different way of doing things, like a subsystem in and of itself. It keeps its own caches and generally wants to be as close to the metal as it can be. Which sounds scary, but meh: Almost everything worth doing gets done with two commands, zfs and zpool, and the syntax has been consistent enough over the years that old documentation from Sun still has value.

I've been using it for most of a decade now and I find it to be ridiculously good. My only wish is that it could be a first-rate player on Linux, but license incompatibilities be that way sometimes.

- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...

But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.

After all: Why would zvols exist at all if they weren't superior in important ways?

> it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance

It's important to note that additional datasets are essentially free on ZFS; it's no big deal to have lots of them (millions of millions of them is A-OK), and datasets don't have a pre-determined size like zvols do.

Although zvols can also be grown and shrunk, just as files [within datasets] can be.

Both datasets and zvols make the same kind of mess out of zfs list's unfiltered output.

But zvols introduce a new concept, while anyone who uses ZFS is already familiar with datasets that contain files.

I think this part is a wash, and that it comes down to operator preference.

> avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage

Maybe? Again, the benchmarks I found (hours ago now and tabs long-closed; I'll find more if anyone insists) suggested that files were faster than zvols, which suggests reduced overhead. (It's very possible that the tests I found were naively implemented, but then: It's also possible for any of us to do something naive.)

Anyway, it's interesting to think about.

It seems like the right answer is to test with one's own workload and find the best fit, instead of assume that one way is better than the other.

For its part, ZFS should handle a zvol and a file-on-a-dataset with equal stoicism and reliability.

As a reminder: Broadly speaking, RF-based TPMS systems on cars transmit their unique identities in the clear to anyone within earshot as part of how they work. (Not all use RF, but many do.)

Also: The tires themselves frequently have RFID embedded in them, as part of the inventory management systems used in their production and distribution.

In this way: You drive by with your noisemaking-device, and it records that noise along with the presence of your license plate.

It won't take a senior data analyst to correlate the bursts of noise with your proximity. Instead, you'll stand out like a sore thumb and they'll see you coming even before they have optical line-of-sight.

(It could scale, but as a practical matter it simply won't. Most people aren't interested in this kind of obfuscation; it'd be amazing to me if even 1/10,000 people were to actually adopt it. This level of rarity would identify you as one of the 0.01% of troublemakers.)

My wife calls it paranoia but I call it protest.

I wish I felt better about this idea, but it seems like it'll be very trivial to erase.

(But that doesn't mean you shouldn't do it!)

That's the behavior that is desired, yes. And in a neat world of frictionless pulleys and ropes that don't stretch, perhaps that is what happens.

In reality, the root reasoning for filesystems to detect bitrot is simpler: It's irrational to expect that a device which is already failing is going to behave in a predictable way.

I've gone ahead and moved this week's meeting, which happens to be tonight, to your place.

We'll be there soon.

Strictly speaking, the grooves only need to be cut as close as necessary in order for music to fit, while remaining far-enough apart that they don't interact too much.

Packing as many grooves (and thus as much material) as possible onto one side of a disk isn't always a goal, although it can be a goal.

> But the spiral isn't fixed, it's adjusted dynamically. Quiet sections can be packed close together.

Aye. Or the whole thing can be made quieter. Or dynamically-compressed first, and then made quieter. Or if it's a relatively short work, it can tolerate being louder and/or more-dynamic even though that takes up more physical space. There's lots of knobs here, and all of these knobs can be turned.

> That means that before cutting, the machine needs to know how much physical space it needs for the audio it's about to put on the disk.

That's not quite right. The process should ideally know this in advance, but that process can include a skilled human operator. And since we still have humans, it is not necessary for the machine itself to figure all of this out on its own.

Like many other kinds of machine work, a lot of it can be boiled down to some moral equivalent of speeds and feeds. There's a good chance that you've worked with this at home with a 3D printer by winding things up or down manually as a print progresses and observing the results. (Except: This is subtractive instead of additive, and we hear the results instead of seeing them.)

I see nothing that suggests that this record lathe can't be manually controlled. Instead, I see suggestion (based on the snippet about locked grooves being possible) that very fine, deliberate control is exactly what it is made to allow.

One can therefore add whatever knobs they want at whatever layer the combination of this device and one's skills permit, and send it. If the process fails, then learn from that and try again.

It's OK when it fails. Fucking things up is a time-honored tradition: At most stages of the recording/mixing/mastering/distribution process, it's pretty uncommon to one-shot anything.

Blank discs aren't necessarily expensive. It's OK to fuck them up.

Like: I suck at code. But I've known how to walk around in *nix systems and use things like bash to chain together commands like awk, grep, and sed for ~30 years. Maybe I'd even toss in some badly-cooked perl or python (or both!), when that seemed necessary.

For a very long time, I've been able to get some things done, but my skillset was focused on doing these things with real computers with live filesystems and real user interfaces, not MCUs.

So, some years ago: When I wanted to turn a window fan on and off based on some network-retrieved weather conditions, I didn't even consider an MCU. I didn't want to learn a new way of doing things; I just wanted a computer to get some data and decide whether to turn the fan on and off. And I wanted that done sooner instead of later.

I accomplished this with a Raspberry Pi Zero W -- with the whole OS. I didn't cross-compile anything. I didn't have to target some weird-looking external environment, or learn a new way of doing things.

Setting up the dev environment was very familiar: Dump a binary onto an SD card, boot it, get it onto the network, and use it.

I just SSH'd into that tiny little computer like I would any other Linux box and wrote my stupid little cobbled-up scripts right there, in-situ, on the final device that would be performing the work -- with a familiar interactive shell.

The end result worked very well. I'm not ashamed of any of this at all.

---

Later, I switched from networked weather reports to an RTL-SDR dongle and software decoding to listen for over-the-air broadcast reports from someone else's nearby APRS weather station, and used that as a source of weather data instead.

Can we even get that done in MCU land? (Should we even try to do so for just one window fan?)

I get the familiar angle of using a Pi Zero. But don’t be intimidated by the Pico. Especially these days with the help of an LLM, you’re not slowed down too much. The version of Python they run feels very familiar. The tooling is good. They’re awesome!

And because I still suck at code: If I want to create something myself, then I still get to do that with a Linux box using unix methods.

That all said: I do enjoy working with RP2040 PIO assembler sometimes. The combination of its severe limitations and robustly resolute timing makes it both approachable, and fun. :)

Anyway, I think all methods are OK. There's no reason to judge them. (I think it's also OK to just use a computer to read Facebook, or as a porn machine, or to become an Amish leatherworker and leave all of this digital nonsense behind.)

Party I am petitioning for passersby who might be wincing at the new prices for Pi 5s etc. for starter electronics/programming projects when they could save a ton of money with a Pico. I have to assume that a huge chunk of Pi 5 purchases from consumers end up with the computer either stuck in a drawer, having been used for a couple days, or running a workload they are completely overpowered for. Every time I see the new prices I wonder how much lower they would be if the consumers were better informed and demand was more appropriately redirected.

To give a specific example of a misused Pi, I've seen an RFID access system made by a hobbyist (low stakes, no need for professional/commercial solutions) running on a Pi 3. When the system glitches (another matter entirely - messy code) and needs to be rebooted you need to wait a minute or two for Linux to start up. I'm planning to replace this system with a Pico 2W. All it needs to do is handle a couple of buttons, a small LCD screen, and an RFID reader. We can handle all of that and a WiFi-accessible web admin interface using a microcontroller. Not only is it wasteful (for whatever that's worth) to have a quad core CPU, 1GB of RAM, and a whole Linux OS to perform such a trivial task. It's also leading to issues with complexity and performance.

Perhaps they'd cost even more if the ones sitting in drawers were never purchased at all.

And, I mean... I'm not here optimize anyone else's money. It's theirs, and they can spend it however they want.

As a specific example: Back before the literal-shortages several years ago, I'd see people buying 8GB Pi4s to run OpenWRT or Klipper. "I want the very best," they'd proclaim. "I don't want any bottlenecks."

I'd try to steer them to what I felt was a more-efficient path. "Yeah, but OpenWRT uses less than a hundred megs of RAM. And Klipper is pretty light, too -- that's kind of the whole point of this kind of software. The smallest [2GB] version is already complete and utter overkill for these purposes now, and will remain so in any future it is likely to ever see."

And what I found, over and over again, was that these folks didn't reason themselves into this position to begin with, and that they thus couldn't be reasoned out of it.

So I stopped trying to change their ways, and started accepting it instead. I'm happier this way.

Consider common consumer wireless indoor/outdoor thermometers which have a temperature sensor you place outside and a display you place inside. Most of these use a much simpler radio protocol than WiFi or Bluetooth, and have nowhere near the compute power or memory resources to come anywhere near running Linux.

On the transmit side they typically have a fixed frequency oscillator (commonly near 433 MHz or a little over 900 MHz) connected to an antenna through a transistor. They send data by turning that transistor on and off. There are a variety of ways they might do this. Some might do it as pulses with different widths for 1 and 0. Some might do it by having have say 200 us on followed by 200 us off mean 1 and 200 us off followed by 200 us on mean 0. There are many more.

For home built stuff you can by cheap transmit modules to help with this, such as this one [1]. I'm linking to Sparkfun because they have good documentation, but you can find these all over the place.

On the receive side they use a simple receiver tuned to the same frequency (but with enough tolerance that it isn't a problem that both sides are probably using cheap oscillators that aren't very stable or accurate). Here a receiver module for home built stuff [2].

From what I've read the ways these work is that they automatically adjust the gain to have a constant high output level, but there is some lag in that. If there is nobody transmitting the output is just amplified background noise.

Then when someone starts transmitting the gain gets turned down so it is just enough for their signal to have max output. Let's say they are sending 1s as a pulse of 200 us on, 100 us off and 0s as 100 us on, 200 us off. With the gain set so the on level is at maximum output the off level will be quite a bit below that. As long as the gain adjustment is slow enough that it doesn't turn up the gain too much during that up to 200 us off, the next on will still be readily distinguished.

In that example the transmitter is sending 1 bit every 300 us. The firmware in the receiver can look for high/low and low/high transitions in the radio output, looking for the pattern of several consecutive 300 us intervals with 100 us on/200 us off or 200 us on/100 us off. Interpret that is a bit string, and make sure when you design your protocol your transmissions start with some kind of signature so you can tell you are actually listening to the right sender, and it should work. If you designed the radio protocol reasonably you should be able to do the recognition with some kind of efficient state machine.

[1] https://www.sparkfun.com/rf-link-transmitter-434mhz.html

[2] https://www.sparkfun.com/rf-link-receiver-4800bps-434mhz.htm...

And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

(I know, I know. It's terrible. It even feels something like betrayal sometimes. But that's how it be, anyway -- and you and I are powerless to do anything about it.)

Strong doubt. What's lower friction, "visit this address in your browser and login to start configuring" vs. "go download this app, open it, possibly log in and register an account, add 'your' device, and only then start to configure it"?

Let's also not forget the possible chicken-and-egg situation of needing the Internet to download an app to setup your new router to access the Internet...

Point your phone at the QR sticker on the router, click open, boom you’re on the config page!

That’s a faster experience, doesn’t require any searching, doesn’t require wondering if you downloaded the right app, doesn’t require you sign up, etc.

Your claim people prefer apps to QR codes is highly doubtful.

I claimed what?

Ie, what normal people use regularly every day.

On the other hand: A thing that requires a web browser for setup does not necessarily allow strictly-local configuration; it often gets shaped that way, but it does not have to be that way.

There's no rule or law that says that these things have to be one way or another. It's a moot distinction.

> Hard requiring app setup for a router is a play to sell usage and location data,

Speaking of moot points: It's a router. And by "router," I mean: It's a whole-ass black-box computer with some Ethernet ports, a collection of radios, and an Internet connection. If/when companies decide to be in the business of selling usage and location data, they don't need an app to do that. They can just package it up and send it forth. (Location? From wifi? Yeah, that's been a solved problem for a long time now. It was first demonstrated to me in 2008 with the OG iPod Touch, which lacked both GPS and Bluetooth, but did an amazingly-good job of delivering the beholder's location using a combination of observed wifi signals and a central database.)

---

Moving on:

I guess we can talk about things like web browsers, IP addresses, QR codes, and SSIDs, and setting up routers using our pocket supercomputers.

Old way: Fire up router, manually connect to its SSID (it used to be wide-open; these days, there's usually a password printed on a label instead), set it up with a browser, and then at the right points manually connect to the newly-configured SSID instead, and [optionally] manually go to the new address (if chosen) to continue configuration (if necessary). Manually remove the old factory SSID for cleanliness. (I cut my teeth on this method and I like it just fine, but I'm one of those computer people.)

QR+browser way: Fire up router. Connect to its SSID with a QR code. Connect to its web interface by scanning another QR code. Configure the thing. Connect to the new SSID manually (or perhaps invent a workflow to scan and use a QR code using only 1 pocket supercomputer). Optionally continue configuration by remembering the name/IP of the device, or maybe printing a QR code or something. Manually remove the old factory SSID for cleanliness. (Login to third-party server at some stage? Yeah, maybe. See above.)

App way: Fire up router. Download app using familiar processes (perhaps including a QR code). App temporarily connects to router's default SSID. User uses app to configure router. At the right times, the app automatically disconnects from the old SSID, adds the new SSID to the network list, and reconnects using the new address (if selected). Optionally, continue configuring the device using the app. (Login to third party server at some point? Yeah, maybe. Again, see above.)

A Cisco 2501 is a router.

But words can mean more than one thing. Both in the common vernacular and in the context of these Motorola-branded devices: A router is a thing that routes, and also includes radios, and SSIDs, and switching.

What is this FUD?

For whatever it's worth, I associate the term FUD with crypto bros. Both of you simply stated an assertion at fact and then flipped out when someone deigned to defy that. Maybe argue your points properly?

That's two things they ruined.

While we're at it, I think them claiming the term Web 3.0 is very self-aggrandizing.

Yup. But as a broad signal, is the person getting uppity about FUD usually making a valid point or safe to ignore?

For a router? This is the device that you will often not have internet access with which to download an app until after it's configured. Many people have wired internet specifically because they live somewhere with poor cellular reception. Meanwhile the device can give out DHCP and use the standard captive portal mechanisms to automatically direct any client device to its configuration page.

I didn't say that I thought it was right, or fair, or just. I didn't say I liked it, or that I agree with it.

In fact, I think it's a pretty ugly state of affairs when a person in an area of poor connectivity needs to climb the hill/go into town/otherwise make plans before they can get their shiny new router to work.

I can accept that things are the way they are, or I can pretend that they're different.

Acceptance seems to be a lot more honest.

The implication that there is nothing anyone can do to improve the existing state of affairs is also incorrect.

I did not.

> That claim is in error.

My motivation to further discuss a hallucination is insignificant.

This is the exact quote:

> And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

What good does it do you to dispute that you implied it as a justification for the status quo when your error is contained in the part you're not disputing?

> implied

Any implied meanings are your own creations, not mine.

I assure you that if I had meant something different than what I wrote, then I would have written something different instead.

I'm not shy.

Be well.

Unfortunately the only tech stack that can do this is the web, (serial/remote shell comes close).

In fact I regard this as the major failure of the app method of program deliverance. Why do you need to install them at all? It should be like the web, hit an address load the app. It is why I am thankful that the web was not developed as a commercial project. No for-profit entity would have let it escape their control like that. It would have been designed exactly like the app system for phones is. enforced central blessed "app-stores" and manual install processes.

If the default was something else I suspect people would accept that too, especially if it was lower friction.

I'd say typing a few characters into an address bar (or scanning a QR code) is, at the least, not higher friction than downloading an app and creating an account.