mlfh

I guess technically the source is inside the compressed tarball, which if nothing else is a very fun and exciting new way to use version control

No, most of these existed pre-AI, and are just being discovered in large volumes by AI.

In most cases these days, “iptables” is just a compatibility layer for nftables, translating iptables commands and syntax to nftables rules.

That’s good, that’s the whole point - if there were nothing wrong with android/google worth picking a fight over, graphene wouldn’t need to exist in the first place.

I want my graphene/EFF/etc teams rabid, angry, picking fights, and armed with bazookas.

which honestly defeats the point of a “stable” distribution if the software provided is EoL, doesn’t it?

Again, the point of a stable release model is that its packaged software doesn’t have breaking changes for the lifetime of the release. Install something from those repos and it’s guaranteed to run in the same way for the full lifecycle while still getting minor and security updates. So if the software you’re externally layering on top of that suddenly requires new dependencies that you have to install externally too, and you don’t like that, that’s more a problem based on a misunderstanding of Debian than a problem with Debian.

You’re coming into a discussion about two different linux release models misunderstanding both their established terminology and their purposes, and then claiming one of them is “bad” because you tried to use Debian in a way it wasn’t intended to be used.

Your nvme drive has a partition table, but the backup table isn’t at the end of the disk, and none of the partitions are loaded (only the parent disk, nvme0n1, shows up with lsblk, where it should show nvme0n1p1-3 under it). The partition table at the beginning is readable, but the rest might not be. Looks like it might be a failed/failing disk as you suggested, which luckily is a simple fix.

Run dmesg and look for errors related to the nvme device (dmesg | grep nvme for a quick filter).

Definitely keep troubleshooting before you spend a bunch of money on new hardware while hardware costs are astronomical.

Omarchy is just a bunch of dotfiles in a Hugo Boss trenchcoat pretending to be a linux distribution.

tl;dr: AI-repackaged void linux with security theater window dressing. Just use void linux.

tl;dr: AI-repackaged void linux with security theater window dressing. Just use void linux.

I use this too and it works great

I was really curious about the possibilities here for a re-usable “saved hibernation state”, and did a lot of digging around and testing in exploration of that idea. Please note that the following is wacky as hell and is not a good way to run a server at all, but is possible:

1. Set up a swap partition that can fit your full system memory.
2. Enable swap and set up hibernation (https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibernation )
3. Hibernate your system to the swap partition in the state you want to use as your perpetual checkpoint.
4. Boot from a live usb, NOT your regular system (when the linux kernel boots with the resume=uuid=xxxx parameter which enables hibernation/resume, it checks that partition for a hibernation signature and immediately clears it, preventing multiple boots of the same hibernated state. You need to preserve this signature).
5. From the live usb system, copy the swap partition that contains your main system’s hibernated state to an .img file on a filesystem mounted from one of your main disks.
6. Reboot into your main system.
7. Set up a scheduled job that triggers every time your system resumes (could use a systemd service with After=hibernate.target and WantedBy=hibernate.target) that does the following:
   1. Disables swap on the swap partition you set up (keeping the resume=uuid=xxxxx kernel parameter that points to it).
   2. Writes the .img file to that partition
8. Use your system as you want, and power it off when done (do not suspend or hibernated again).

The next time you boot, the kernel will load the saved hibernation state from the partition specified in the resume= parameter, as if it had just been hibernated instead of halted.

Now for the downsides:

• It’s very dangerous to resume a system’s memory to one state with storage in a different state (the official kernel docs for this have a giant red warning banner saying “If you touch anything on disk between suspend and resume… …kiss your data goodbye.” https://docs.kernel.org/power/swsusp.html ).
• Resuming from hibernation isn’t really that much faster than cold booting a lean system, if speed is your primary goal.
• The scheduled write job will hit you with a bunch of heavy io every time you boot/resume, probably negating any speed benefits of the whole thing anyway.

Anyway, now that we know it’s possible, if you really can’t suspend/resume in a non-wacky way I recommend instead just booting normally and trying to make the boot process as fast as possible. A good guide here: https://wiki.archlinux.org/title/Improving_performance/Boot_process

If booting quickly to a static state is the goal, alpine diskless mode might be a good option: https://wiki.alpinelinux.org/wiki/Diskless_Mode

Tl;dr: one project written by one person that does everything on every platform.

(edit - this is a huge red flag, if that wasn’t obvious)

This is a week-old repo with a 163,000-line initial commit, and the test repo that init was dumped in from is filled with hundreds of claude/codex co-author commits. Regardless of whether it’s to hide the ai co-authoring, it’s shady to obscure a repo’s initial work like that.

I could be wrong, of course, but this smells like yet another overambitious ai-slop project that’ll get abandoned in a month.

I’ve always hated the gap in cumbersomeness between creating cronjobs and systemd timers, and always wished I could set a timer up as easily as I can stick a new line in the crontab. Having something bridge that gap would be the best of both worlds.

Very very cool! Would love to see it all in the case once you design and print it.

I’m working on this exact problem at home now, and finding 24GB of ddr4, a 6th-gen i7, and an old 8GB rx580 is more than enough to run pretty capable models up to ~35B parameters just fine, and equivalent MoE models shockingly fast. Not exactly cheap, with the price of everything so crazy right now, but certainly cheaper altogether than I’d imagined.

The one recurring unsolveable problem I run into is not being able to kill a process that’s stuck in D state. If something has broken in the layers between that process and hardware (not uncommon when working with old cheap “box of scraps” hardware, as I like to do), it can get stuck forever and you have to kill the whole system, sometimes forcibly. Not the end of the world, but it sucks when it happens.