mlfh

Crontabs can live in different places on different systems, but generally when you run crontab -e you’re editing the crontab of the current user, which is generally placed in /var/spool/cron/{username}. If you do sudo crontab -e that edits the crontab/file for root. There can be other files nested in /etc/cron.d, /etc/cron.hourly, /etc/cron.daily et cetera as well.

To find out where those old cronjobs are still defined, you can recursive grep the name of that unique log file you mentioned (if the log file is part of the command in the crontab). grep -r "{unique log file name}" /etc and /var/spool should find it. If the log file name isn’t in the command, grep for some other unique string from that cronjob that would stand out amidst everything else in /etc.

To add timestamps to log output, you can pipe it through ts.

What the hell is even this

Running a constant arp poisoning attack on a whole network trying to mitm the dns server just to block ads is going to be unreliable as hell, and it’ll screw with more than just dns traffic.

If you control the network, it’s far simpler and more reliable to point clients to a dns server that blocks ads. And if you don’t control the network, probably shouldn’t be attacking it this chaotically.

Like, magically?

You don’t, is the short answer. Especially when the thing from github is unmaintained and unsupported on the current version of qubes:

Please note I currently do not have time to maintain Liteqube, it is not updated to support Qubes 4.2.

If you’re just using qubes for funsies though and safety/security doesn’t really matter, the qubes docs provide a very hacky method for copying files to dom0 (prefaced with a long “you really shouldn’t do this” warning): https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-copy-from-dom0.html#copying-to-dom0

Not a disk issue, but looks instead like an issue with power management on that thunderbolt root port at 0000:80:1b.4. See this thread for proxmox-specific writeup: https://forum.proxmox.com/threads/kernel-7-0-x-regression-acs-violation-on-pcie-port-80-1b-4-causes-vm-freeze-—-arrow-lake-thunderbolt-5-intel-arc-b50-passthrough.184312/

And here for more: https://github.com/minisforum-docs/MS-02-Ultra/issues/10

Looks like you can resolve it for now by either reverting to 6.17.x kernel or creating a udev rule for the device.

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.

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

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.

The demo video is the most ridiculous thing I’ve ever seen, I love it

I run the immich container stack on a vm with 4GiB memory and 2 cores, with db on local disk and external libraries over smb, and it runs perfectly fine. I offload the machine learning jobs to another sometimes-on machine, sometimes, but don’t really need to unless I’m dumping thousands of new images into the external library at a time and want it all to process quickly.