mid-kid

It's really jarring to still be pinning this on Microsoft, when Google and Apple have been doing the same for free, for years, in iOS, Android and ChromeOS.

Cronie has a mechanism for this, called "anacron", which is called hourly by cron (on my system, /etc/cron.hourly/0anacron), and performs all the /etc/cron.{daily,weekly,monthly} tasks, no matter if the earliest possible schedule was missed (and with a configurable random delay). You can modify /etc/anacrontab to create custom schedules.

To do this at the user level, you can add something like "@hourly anacron -t /path/to/anacrontab -S /path/to/spooldir" to the user's crontab, though I've never tried this.

Many cron implementations have a similar mechanism.

It already is, though? I've been using dash as /bin/sh for years, openrc is using that.

It's a shame that this article focusses on Omarchy being "just some dotfiles" when I feel it's the weakest of the points it makes against Omarchy (there's many valid reasons to have issues with it!).

Omarchy isn't any more "just some dotfiles" (henceforth, "default configurations") than any other derivative distribution seeks to be. Distributions always ship some kind of default configuration, be it embedded in the programs themselves, installed in /etc or otherwise patched in. Of course, some distributions, especially base distributions, focus on just shipping the packages, but more involved ones, for example Ubuntu, tweak the default configurations of many programs to provide a cohesive experience.

I've always found it a shame how difficult it is to reproduce some of the r/unixporn screenshots, to see if they actually function nicely, use for a bit and see what I like and can backport to my own configurations. Even when the author provides some links, it's usually really hard to set up, and you're never quite sure what the author might've glossed over or configured out-of-band. I always wished there were more of these highly opinionated linux respins with heavily tweaked dotfiles, so at some point I also made my own to add to the pile: https://github.com/mid-kid/RocketISO/blob/master/docs/RELEAS...

Seeing this article, and how much webextensions manage to mess up the browser, I'm wondering how bad this experiment would've been with the legacy XUL extensions. Maybe they had a point in getting rid of them...

I see what happened, I was replying to a different comment, that did mention the GBA audio, when I wrote that, but somehow ended up replying to this one.

This comment explains it better than I could: https://news.ycombinator.com/item?id=47708201

gah, you're right, I was thinking of memory protection (as in, marking the relevant regions as read-write and read-execute) when I wrote MMU.

It's of course optional, and you can ignore it for trivial examples, but most games and SDKs will tweak it all the time when loading additional code modules from the cartridge.

It's just another way in which the DS is more complex to use properly without an SDK to do this for you - there's just more to think about. At least compared to how the GBA lacks all of this and the entire cartridge is mapped into memory at all times.

I've never coded for SNES, but the GBA having access to a mainline, modern C compiler is a massive buff. Also, emulators for it have always been available on practically any computer, console and mobile phone, and there's many so-called "emulation handhelds" that bring its (and similar) form-factor handheld devices to the market. If you really need an upgraded OG experience, many upgrade kits for the handheld exist as well.

None of this fixes the audio, but it sure gets damn close.

I'd say the GBA is the sweet spot for this.

The DS has you dealing with two cores you need to write a firmware for that have to communicate to do anything useful, a cartridge protocol to fetch any extra code or assets that wouldn't all fit into RAM at runtime, instruction and data caches, an MMU, ... And that's without mentioning some of the more complex peripherals like the touch screen and wifi.

All official games used the same firmware for one of the cores, a copy of which is embedded into every single cartridge ROM. There's some homebrew firmwares included in the respective SDKs, but they aren't well documented for standalone use.

Granted, all of the above isn't completely impossible, but if you think of how much code you'd need to get a simple demo (button input, sprite moving across the screen), especially for a beginner, the DS requires a nontrivial amount of code and knowledge to get started without an SDK. Meanwhile, you can do something similar in less than 100 lines of ASM/C for GBA.

Same reason all the other mario flash games haven't, not a critical enough mass.

Not a Go dev, but I typically set up a CI with the oldest toolchains I support (usually a debian release), and only bump those versions when I really need something from the latest versions. Locally I build with the most recent tools. This ensures good enough coverage for very little work, as I notice when I start using something that's newer and can bump the toolchain accordingly.

I could've sworn firefox had an "all tabs" preview button that looked like 4 blocks in a grid, before the Australis era. Can't find any pictures/video footage of it in action however.

Best I could find is: https://www.askvg.com/how-to-enable-ie-like-quick-tabs-featu... But I'm not sure if this landed, or if it ended up functioning differently.

I just think it goes to show how little the window management of desktop OSes has improved over the years that desktop applications have had to up the ante...

I also think the differing behaviour between different apps implementing split panes (e.g. keyboard controls for creating/switching) is very annoying. Somtimes this flies in the face of any desktop's native window splitting or tab support as e.g. an app stops supporting multiple windows. For example, current browsers don't have a good way to configure usage without tabs, and at some point removed support for setting the window icon to the site's favicon.

Yeah. I'm surprised this along with the money thing are listed in the article at all. These are the sort of things you learn within the first month of writing assembly, and were widely used across the industry at the time (and times prior). The bit shifting optimization is performed by GCC even at -O0, and likely already was at the time, as it's one of the simpler optimizations to make. It's like calling "xor eax, eax" a masterful optimization tactic for clearing a register.

Looking at the macro-level optimizations like the rest of the article does is significantly more interesting.

What other options are there?

This happened for a while with VRChat, though I don't know what it's like now.

It's worth noting that while these videos may have been unintentional, this was also an era when youtube was still inventing itself. Sure, there was real content creation, but the structures of sponsors and ad revenue that can be a real income today weren't there. Let's plays were just starting to dominate the platform, and people were still figuring out how to make money off of that.

As a result, there was a lot of this type of content: barely edited, poorly performed, honest moments of real life, amateurish creations of any kind, be that digital animation, music, acting, etc. I feel these IMG_xxxx videos reflect some of the vibe of the era. Now, sharing videos with people is easy enough in group chats, and youtube content feels so manufactured that people feel it's less appropriate to share this sort of thing via youtube.

How do you back up and restore things without root? I've found that even with root, these days many backups are useless thanks to using hardware-backed encryption...

How do you use buildah? with dockerfiles?

I find that buildah is sort of unbearably slow when using dockerfiles...

The point of TOR is that while it can be detected, at the entry nobody knows what you're sending to whom, and at the exit nobody knows who is sending what. The fed sniffing my TOR connection can't really do anything with it.

Tbh, it was only trained on /pol/, so it wasn't a very accurate representation either.

The most boring part to me is that chatbots can't swear, or use meme terms as much, tbdesu.

Control over your data is part of anonymity. Sure, everyone will know the service belongs to you, but you'll be in total control over who knows what exactly. To most people not in the eye of the law, that is most of the anonymity they require.

Also, services like TOR exist. Both on the hosting and user side.

Either adding your script directory in front of the PATH, or creating `alias` that provide a full path to your script where a conflict exists, makes a whole lot more sense to me.

I've never had this collision problem yet, despite appending my script directory to the end, but I'll use either of the above solutions if that ever becomes a problem.

I think they mean you don't need ruffle if you can just export to web. The programming environment can be anything, but adding ruffle in the middle when it really doesn't need to be there, does indeed feel a bit tacky. Flash used to be necessary to add functions to browsers that were otherwise impossible, but these days you can do anything in a browser.

I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...

I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.

eudev was just a copy of the udev part of systemd, with some patches to build on musl, and work without systemd. All of that has been upstreamed now, LFS has instructions on how to build udev from the latest systemd release, without building systemd itself.

The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certain program that now depends on it.

This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.