yjftsjthsd-h

If you're used to a "normal" network with a router, it's a revelation that you can go direct.

I am 95% confident you don't actually need to assign IPs. Do this:

  # ping all link-local devices on an interface:
  ping ff02::1%eth0

And then do your socat/rsync/whatever to the only IP that responds.

As the article says,

> Removable storage is quite slow unless you are willing to spend a lot of money.

An SSD good enough to copy tens of GB quickly is not cheap.

Losing the back half of the achieve doesn't lose your directory list. (Truth be told, I prefer the approach of sticking a copy on the front and back for redundancy, but I appreciate that that's a very specific tradeoff)

It's a trade between size and speed. If you want fast lookup, it's not a waste.

I don't think CPython targets those, though; that seems more like a micropython thing?

> RISC-V is now officially supported by CPython as a tier 3 platform!

That's significant, but tier 3 is still a caveat. Still allowed to break without blocking anything or being fixed as a priority.

I always assumed you could work around this by pre-allocating a large enough header space to hold a reasonable sized directory tree. You could even then append a supplementary directory if you run out of space and just stick a pointer in the first one. I'm pretty sure that's just reinventing an actual filesystem, but if it works...

I still have a computer that produces slightly different noise (coil whine?) depending what it's doing. Fascinating behavior.

> GitHub assigns CVEs for the advisories. Before the AI apocalypse they took 2-3 days for an assignment but now it they are running at 3-4 weeks so I have to send the point releases out with CVE-PENDING in the changelog which isn't ideal.

A strange bottleneck; anyone know why that would be so slow?

I do tend to agree that in an deal world it should be possible to cross-build flatpaks, but:

1. You can't then test the output to make sure it even works.

2. As a practical point, you could just do it in a VM

> The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.

You can use a pretty big portion of the sandbox separately, because it's just bubblewrap.

Nix doesn't sandbox applications, flatpak can.

If you have a rooted phone, download malware, and hit the allow button to give the malware root access, then it can do whatever it wants.

If you have a nominally unrooted phone on an old Android version and download malware, it can exploit a kernel bug and give itself root access and do whatever it wants.

Protecting against the first case and not the second is at best security theater.

This appears to be 5 years and 1 major LFS version out of date. Although, I suspect it wouldn't be hard to adapt to current, other than maybe the switch to systemd.

Look, I try to avoid bringing up nix in unrelated conversations. But.

> The only two options I have is a) do a factory reset and reinstall software from scratch and spend time configuring things again, or b) live with all of the extra garbage that has been excreted by the software on my systems just so that I can keep the data that I actually want to keep.

NixOS solves this.

> My ideal system would separate data that was written because of me (non-default config values, bookmarks, etc) from documents etc made by me, from garbage that the program wants to write that I absolutely do not care about and do not want to know about.

And NixOS with https://github.com/nix-community/impermanence does this, forcefully. Actually normal nix might solve it depending on how far you want to go.

Again, I wouldn't usually try to evangelize it, but you have described your ideal system, and it exists.

Yes, that is one of the particular reasons I'd much prefer a single ro binary that gets handed one data dir per instance at runtime:) There's also (at least) a security angle and the question of how you reset to a known-working state if it mutates itself.

> We can collapse not only a complete distribution but all the state for every application into a single file, alleviating the need for /var/ or /tmp/ or /home/ or any other filesystem. The program can store its own state in the same file it is running from, and it can do so transactionally.

On the one hand: I don't think I want that. Including static content with the binary makes sense, certainly. However, storing writable run-time data there feels messy; I prefer a read only binary which is handed a writable state directory (it is worth saying that I've spent a lot of time with nix and other immutable distros).

On the other hand: This is the coolest, most fun thing I've seen in a good while, and I absolutely want to see it taken 1000% further. Who cares about perfectly operationalized immutable deployments when the hacker spirit is in the air?

I'll bet you could use this to run with another thing APE does: fat binaries. If program text lives in a database, what's one more row? Just

  SELECT text FROM executable WHERE arch = $(uname -m)

and off we go:)

Edit: actually on further consideration this feels perfect for smalltalk; you can put the VM and image in a single file

> Even then, you could attack it from the next level up, with some fancy optics and a display, or something like that.

The analog hole is alive and well:)

Or escape them;)

What's the hardware situation to get OBD data?

If it's trying to convert it to italics, you may have to use a backslash to escape them

What does "LEAN" mean in this context? (I'm not familiar and 10 seconds of duckduckgo didn't answer)

But it also has 8GB of RAM.

> Support for double-wide GPUs (Up to 450W)

I wonder how the driver situation is. From Jeff Geerling's work on running "big" GPUs on Raspberry Pis, my impression is that often less-common platforms should work but are littered with papercuts in practice.

My understanding is that yes Android build requirements are... significant. Given that a gentoo system can self-host in like <10% of that space, I am somewhat mystified how it got here, but yes that's "normal".

I'd also very strongly recommend F-Droid. TBH I can't really speak to the quality of music apps on it - I just use VLC - but it doesn't require an account and it has lots of good apps.

In hindsight, it's my opinion that wayland, if it had to exist at all, should have been implemented like this:

1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.

2.a. Implement weston as a standalone compositor.

2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.

3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.

> You can set per-hostname exceptions if you like! CTRL + I > Permissions

1. Thank you, that's very nice to know about.

2. I really wish this was exposed more directly, probably from the permissions button that is already in the address bar. I can't believe Chrome does this better.

It's adequate, but it is a little cramped