I find the CollapseOS approach unrealistic and somewhat self-indulgent. In a real collapse scenario, having a portable Forth environment for arbitrary microcontrollers wouldn’t put us meaningfully ahead. The primary value of computers wouldn’t be to run new minimalistic programs from scratch for stuff we only automate in a situaton where we are living in economic and technical abundance, but to access and preserve existing information systems and whatever remains of digital infrastructure, especially libraries, CAD/CAM systems, etc.
A more practical strategy would be maintaining simple yet complete computing environments that can operate on salvaged hardware. NetBSD is a good example: it supports a wide range of hardware, has a relatively straightforward codebase, and provides a full source-based system with a usable graphical userland, with a wide variety of tools available.
In a “collapse computing” context, it is far more plausible to repair and reuse an x86-compatible machine than to rely on extremely minimal custom setups that can barely run a Forth interpreter. With salvaged x86 hardware, one could install a robust OS like NetBSD and immediately run a broad set of existing tools, which is likely to be far more useful than rebuilding a software ecosystem from near-zero on constrained microcontrollers.
This is why having a NetBSD and pkgsrc mirror is my approach to collapse computing instead of fantasizing on building from scratch.
Your reasoning is sound, but is already covered by Collapse OS' manifesto. It refers to two stages of collapse, Collapse OS being for the second.
As long as we have working modern machines, self-contained modern open source OSes, NetBSD being one, are good choices.
One problem there is with such system is their overall complexity. Sure, you can use them, and they're pretty flexible for the user. However, when necessity forces you to crack the kernel open, the learning curve is pretty big.
For example, let's imagine a computer with a broken SATA controller. How would NetBSD behave on it? Hard to say, NetBSD developers don't develop with that target machine in mind. Usually, when you have such a machine, you replace it or repair it. But what if you can't? Maybe you'll have to play in the kernel to manage to do something with that machine, route around it. Maybe it will work, but maybe you'll be stuck, and maybe that in that particular situation, it's going to have tragic consequences.
Exactly, DuskOS is for maintaining a somewhat degraded level of civilization and perhaps rebuilding, while salvaged machines are still common. CollapseOS is there if things get even worse, to retain a minimal level of computing capability during the transition to whatever comes next. It’s hard to imagine the need for CollapseOS while things are still working, but in some horrible future where it’s the only system keeping the water system running, people will appreciate it.
The additional value in Collapse OS is that — as the hardware capable of running even Dusk OS (let alone a more complicated 32+-bit operating system) continues to break down and dwindle in supply — you still have an option such that you can reasonably-comfortably use those more constrained systems for simple tasks and free up the complicated hardware for complicated tasks. You don't need a multicore 64-bit CPU to keep a typical water system running; an 8-bit microcontroller is typically enough, and having a software stack already ready to go (including an ease of adapting to whatever specific hardware might be wired to that microcontroller's pins) is a pretty big deal even long before the point where we're shooting each other over the last Z80s and PICs.
I just hope they have robust backups and disaster-recovery plans, as Gentoo Wiki once had a terrible data loss, and it was like the burning of the Alexandria Library, I feel that put the distro to a decline. I don't use Arch (I used Gentoo in those times), but these collaborative knowledge bases are too precious to be lost.
It's a wiki. Maybe you lose the edit history and stuff like that, but the actual content which is what matters should be very easy to recreate from those sources.
Even siri got worse, when I say call <nickname of my gitfriend> now it does some location based search, and calls sonebody, when near home it is a doctor, when on the other side of the river it is a flower shop, at othe rplaces other random non-contacts, with a contact having the sting it used for search, as her nickname is always part of the called person… It used to work flawlessly as expected…
I would be fine with Siri actually if if could handle simple fixed phrase based task, no AI, as it could a few years ago.
The most frustrating aspect of Siri's quality decline is that super-basic things inexplicably stop working. For years I have been able to say "call <wife's name>" and Siri called my wife. A couple weeks ago she started dialing another contact I haven't talked to in 15 years with a similarly-pronounced name (but different spelling). I had to delete the old contact to stop that behavior from happening.
I mainly use Siri for cooking timers, I really enjoyed the brief period of time where it started flipping 50 minutes and 15 minutes. And then went back, for some reason, but not after I started using things like 14 minutes and 59 seconds or 51 minutes to make it think just a little harder.
My Siri just forgets to confirm the timer. So I go to find my phone swearing at it just to figure out it did set a timer, but for the wrong time. It simply didn't tell me.
I'll sometimes ask Siri to take me to a local address, and it'll instead pick some random address in a city 2500+ miles away and start routing me there like that's obviously what i wanted
Watt is a measure of power, that is a rate: Joule/second, [energy/time]
> The watt (symbol: W) is the unit of power or radiant flux in the International System of Units (SI), equal to 1 joule per second or 1 kg⋅m2⋅s−3.[1][2][3] It is used to quantify the rate of energy transfer.
So what? Why is it important to have 24/7 solar, that you cannot have on the ground? On the ground level you have fossil fuels.
I wonder if you were thinking about muh emissions for a chemical rocket launched piece of machinery containing many toxic metals to be burnt up in the air in 3-5 years... It doesn't sound more environmentally friendly.
So what? Just build some nuclear power plants if AI data centers are so important. It can even work at night when it is infinitely as effective as solar on the ground!
Also I'm astounded how important AI data centers are when we are running out of freshwater, to mention a thing we could easily solve with focusing our efforts on it instead of this. But yeah, surely the Space AI Data Centers (aka. "SkyNet") is the most important we must build...
So DuckDB was developed to allow queries for bigish data finally without the need for a cluster to simplify data analysis... and we now put it to a cluster?
I think there are solutions for that scale of data already, and simplicity is the best feature of DuckDB (at lest for me).
> "So DuckDB was developed to allow queries for bigish data finally without the need for a cluster to simplify data analysis... and we now put it to a cluster?"
This is a fair point, but I think there's a middle ground. DuckDB handles surprisingly large datasets on a single machine, but "surprisingly large" still has limits. If you're querying 10TB of parquet files across S3, even DuckDB needs help.
The question is whether Ray is the right distributed layer for this. Curious what the alternative would be—Spark feels like overkill, but rolling your own coordination is painful.
Big fan of this push back, because there are alot of projects that have that smell over engineering with the wrong base. (especially with vibecoding now) Thought there are use cases where some have lots of medium-sized data divided up. For compliance, I have a lot of reporting data split such that duckdb instances running in separate processes work amazing for us especially with lower complexity to other compute engines in that environment. If I wanted to move everything into somewhere a clickhouse/trino/databrick/etc would work well the compliance complexity skyrockets and makes it so we have to have perfect configs and tons of extra time invested to get the same devex
I'm on board with the feelings of the mentioned classmate about nihilism, but to be honest, reading The Sirens of Titan from Vonnegut, which is considered a comic novel for some reason, has the same impression on me, and that is an all-American classic. Neither are bad books per se, and also I can understand the reasons also why Vonnegut had such a bleak view on affairs, as he had gone through a lot, and was in a hard situation at the time of writing, but it is not a comedy, and not funny.
Note: The interpretation on the difference between American and British view of affairs is almost Eastern-European (/me Hungarian), but you can set up that relation to Britain and Eastern Europe also, so this may be related geographic longitude :)
the beauty of beancount (and other plain text accounting ledgers) is the ability to automate them. I also have to go over my accounts in my bank app's automatic categorization and revise them every month, as some transactions get mislabeled.
Did you ever do a barbecue? You first burn the light, hydrogen-rich substances of the firewood, with a large beautiful flame; that flame would burn down the meat, but it burns off quickly. What remains is charcoal, the source of most heat in the firewood; it does no produce a visible flame, but emits a lot of heat. It is mostly carbon.
A more practical strategy would be maintaining simple yet complete computing environments that can operate on salvaged hardware. NetBSD is a good example: it supports a wide range of hardware, has a relatively straightforward codebase, and provides a full source-based system with a usable graphical userland, with a wide variety of tools available.
In a “collapse computing” context, it is far more plausible to repair and reuse an x86-compatible machine than to rely on extremely minimal custom setups that can barely run a Forth interpreter. With salvaged x86 hardware, one could install a robust OS like NetBSD and immediately run a broad set of existing tools, which is likely to be far more useful than rebuilding a software ecosystem from near-zero on constrained microcontrollers.
This is why having a NetBSD and pkgsrc mirror is my approach to collapse computing instead of fantasizing on building from scratch.
reply