c0l0

Quite clearly from the "solution looking for a problem" dept.

If one ever happenes to casually find 'several petabytes of old logs that were not deleted', whoever's in charge should consider having several people fired over that.

I think it's often a mistake to insist on a third-party font if an environment-/OS-native font family does a good enough job already - it's just more data transferred, text often "jumping" around when the font data has finally been processed and is ready to render, and (often, in real-world use) data needlessly exfiltrated to some font-hosting CDN operator.

The only third-party font I'd consider using (for reasons of superior accessibility, not style) on websites and the like is the [Atkinson Hyperlegible Font](https://brailleinstitute.org/freefont), which is free to use and redistribute.

I write a wee bit of custom (GUI/desktop) software, both for personal use and for use at my employer, using FreePascal/Lazarus. Despite the somewhat clunky syntax - I have more of a UNIX/Shell/C and Python background - I feel very productive with it. I've come to consider knowing to use it (in the proper context and when it's the right tool/language) a hidden superpower ;)

They do, on a per-session basis - but it's an optional feature (that's supported by ~100% of all imap server implementations).

This project's scope is rather impressive, and from what I've gleaned from skimming its docs, it might be the perfect solution for people who want to self-host email.

It tries to have most of the advanced/difficult things (like getting DKIM set up right) taken care of for the postmaster, as far as that is possible within a single application. I love that it will print the DNS records you'll need to set up in your zone during setup.

If I were to start over my personal email setup (postfix with postscreen, dovecot with fts, opendkim, amavis/spamassassin), I sure would try it with this.

Not really a problem in the age of DKIM, _if_ you want to solve it.

Having been a part-time postmaster for more than a decade by now, I fully agree, and would even go further: Ingress spam is pretty much a solved problem if you play your cards right. ChatGPT et al. might change that again - but the mechanisms you can deploy today are very effective against the current UBE landscape.

The _real_ problem is reliably getting your 100% legit mail into your consenting recipients' inboxes.

Yes!! I would so like to have a fontconfig option to just disable ligatures altogether, but afaik, one would have to enumerate ALL fonts that one would like to disable them for in the config file - and that's not feasible. So I mostly live with it, and shake my fist in helpless anger whenever somethings f_cks up my otherwise beautifully monospaced flow with this most damned misfeature of digital typesetting.

All I can say is that I love this man.

... if you want to foster and ensure the existence of proprietary software. Fair enough, I guess - but not something I would personally feel compelled to do.

Also note that the document never takes into account the needs of the eventual user of the appropriately licensed software, but only ever its (or other) developer(s).

At $oldjob, we once got an extortion email of dubious credibility from an unidentifiable party, claiming they would DDoS our (a lucrative commercial web enterprise with lots of daily users) infrastructure, if we refused to pay 100 BTC (the BTC<->USD rate was a lot lower back then than what it is now ;)). As the infrastructure lead, I used this as an opportunity (albeit in a bit of a hurry ;)) to strengthen our resilience against this kind of threat, also on the DNS level.

The pair of authoritative nameservers, which we were self-hosting at the colo space we rented, was based on PowerDNS, with a replicated PostgreSQL database behind it. A "shadow master" postgresql instance was were control over zone data could be exercised, and that postgres instance used streaming replication to shuttle its dataset to read-only secondaries over a purpose-specific SSH tunnel (nowadays, we'd probably be using wireguard instead). There, powerdns authoritative DNS server instances picked up the zone data from the host-local postgres databases, and served that up by means of DNS.

This setup proved very easily extensible (spinning up a new, additional secondary was a matter of a few minutes via a simple ansible playbook that set up a new SSH tunnel, a postgres hot standby, and a new pdns instance that drew its zone data from the local postgres instance), and we chose to deploy two additional nameservers at dedicated server providers in nearby Europe to host our tertiary and quaternary authoritative DNS servers. The only remaining, but tedious task left was updating all the glue records for the domains we handled on these nameservers.

In the end, the entire threat proved hollow, as the deadline passed with zero impact on any of our infra. We never learnt if it was just empty to begin with, or if the adversary decided not to bother attacking a visibly well-prepared site. But the resilience-improved DNS infrastructure was a nice thing to be able to rely on in the coming years, and I think pretty much the same architecture/setup is still in operation to this day.

Yes sure, the "successor" system that was eventually implemented to redundantly host BLOBs of all kinds used a very similar scheme - it's a well-known and effective technique for, e.g., on-disk caching in popular HTTP server implementations. The problem that kept us from doing something like this with out pile of 1.2M images was that there were several different codebases (and even a hand full of remote sites which had code that we knew relied on this assumption, and that we could not directly affect or change) that tied into this flat directory full of image junk in various ways (via the local filesystem, NFS, over HTTP, and I think even FTP was in use for a while after I had originally joined), which made it very hard to push through any breaking changes, no matter how architecturally sound they would have been.

Enumerating all images in the system over the network is what took a few seconds. "Pulling up an image" worked nigh-instantly, because contemporary filesystems have (and had) efficient indexes for the file(name)->data mapping(s) involved.

At $oldjob, taking care of a busy and successful web estate that is now close to 25 years old, one of the ugliest and longest-standing warts was the "image store". That was a simple, flat directory on a single node, shared over NFS, which had accumulated more than 1.2 million (yes, 1_200_000) inodes/files in a single directory. No-one wanted (read: dared) to properly fix the code to rid it of this once-convenient assumption and (lack of) hierarchy, so I tried to work around the ever-growing pain by tuning the filesystem, the host's kernel (a buffed dentry cache size goes a long way at making this kind of abuse more tolerable, for instance), and the NFS server and clients involved to mitigate emerging problems as much as possible. In the end, a readdirplus()/getdents()-chain invoked over NFS only took a few seconds to finish. It's pretty amazing what Linux can cope with, if you make it have to :)

I was a very happy KDE user during the 3.3 to 3.5 days. I tried sticking with the desktop after the 4.0 release (there were SO MANY changes and grand new ideas under the hood!), but lost patience soon after the 4.2 release - it just wasn't ready for day-to-day use; all the rough edges made me bleed every day. So I made the plunge to Xfce, and didn't look back for more than a decade.

Until some three months ago, when I had to set up a new, additional machine at home, and I decided to try the new (really: current :)) Plasma Desktop on Arch Linux for funsies. By now, all may Xfce machines, except the one at work, have been migrated to KDE. Now even my wife uses it on her personal desktop - she's especially fond of Okular, KDE Connect, and digiKam.

I've seen pretty much the opposite close to a decade ago with a number of AMD Opteron/15h-based servers we had, where the BMC could end up in a bad state that made the ipmi-driver-spawned kernel thread handling it burn a whole core for no good reason.

Take a look at https://github.com/LineageOS/lineage_wiki/blob/master/_data/... - it's the length of the 'maintainers' list.

If you're looking to buy a LineageOS-compatible phone and are unsure which model(s) to consider, I try to generate an automated buying recommendation (updated daily) from LineageOS's wiki data, available here: https://johannes.truschnigg.info/tmp/lineageos_device_toplis...

The ranking is an expression of my personal preference - with a recently-released phone, it's more likely to receive firmware- and driver-level fixes in proprietary bits that make the phone tick. The number of devs (hopefully) translates into continued support by the project even in the face of single developers abandoning a particular device they maintain.

Regarding mainline: No, not really - but I think we're in for a decent future with much-expanded mainline support.

The difference between the bastardized stuff from the Pi Foundation and everyone else's is that the former has enough momentum behind it that it's safe to assume it doesn't simply wither away, which makes enough difference for me not to experiment with others that almost certainly will. (I have a small drawer full of SBCs without any remaining software support at home from a past where I did not live/buy by that standard.)

No matter any given SBC's hardware platform's apparent attractiveness: Give me mainline Linux support for all included devices/features, or give me (this particular product's eventual) death.

Is there any info on how this make and model fares? The spec sheet speaks of "Debian / OpenWRT / Andriod" (sic!), but two misspellings in three names don't exactly inspire confidence... If I can only ever hope to install some manufacturer-bastardized spin of Ubuntu 14.04 with a heap of custom patches on top, I'll have to forever stick to Raspberry Pis instead, unfortunately.

Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?

OpenWrt upgrades can be made MUCH more convenient by installing extra packages that enable "Attended Sysupgrade" - check https://openwrt.org/docs/guide-user/installation/attended.sy... for more info, and please spread the word if you like it! :)

> It was a masterpiece in Excel but a disaster in reality.

I feel you.

It will get worse when the manufacturers of the best performing hardware will be the cloud providers themselves :) I am afraid Amazon will slowly drown out independent CPU (and eventually other gear, but with CPUs the playbook is most evident) manufacturers.

Today, Intel (and probably also AMD et al.) offer them exclusive deals on and even exclusive models of their hardware, due to the insane volumes "hyper-scalers" procure. In parallel, Amazon offers their own CPU arch (Graviton) cheaper than x86 cores to users of their platform in order to make it more attractive - at the insane margin AWS operates at, it can make these instances a loss leader, no problem. As a result, those in the x86 market that do not have a cloud business attached will grow weaker and weaker in comparison, and most cloud-native developer mindshare will shift to the cheaper option (since most engineering work in cloud envs is about reducing cost, period), which is AWS/GCP/... custom CPUs. And you, the random shmuck with an appetite for powerful on-prem hardware, will be left with worse products to buy for a higher price.

A few generations of DevOps teams down the road, no-one will be able to understand the ineffable contraptions of YAML-serialized control flow that somehow, magically, manage to stand up infrastructure made of reams of incomprehensible Cloud 4.0 service components that will be, at the very minimum, absolutely required to host a static website.

But it won't matter, since our benevolent robotic AI overlords will create them for you, the certified IBM Project Wisdom(TM) Prompt Engineer, dual-classed to Tech-Priest (but without any Warp to go mad in - that, you will have IT for).

Doesn't really matter - the pre-sales checkbox mumbling something about "encrpytion" was ticked, so Compliance, Legal, and SecOps are OK with it. Nothing to see here, move along :-)

System firmware can (but not always does) include a mapping between DIMM identifiers as exported by the Linux EDAC subsystem, and DIMM sockets on the mainboard. In absence of such a mapping, you can provide on yourself via `edac-ctl --register-labels`. Of course, someone will have to have figured out what that mapping actually is (but one can do that oneself, given a little patience) first :)

Anyone who uses ECC DIMMs definitely MUST monitor what the memory controllers report to make optimal use of it.

However, you can also set a policy what the Linux kernel will/should do on its own when an ECC error condition has been detected: The `edac_core` module has options such as `edac_mc_panic_on_ue`, which, if set, will trigger a kernel panic upon detecting an Uncorrectable Error in system memory. Depending on your use case, this can be better or worse than just logging it.

I have a script to relay new dmesg events into my (xfce) desktop session using libnotify. I figure others may find it useful, too:

https://paste.debian.net/1257030/

It gets started via xdg autostart here, and will tell me about new "stuff" that happens. For it to work, your user will have to have permission to read the kernel event log/debug ringbuffer. I achieve that by setting the appropriate sysctl:

    kernel.dmesg_restrict = 0

Back when the stack had been introduced to the game rules, and combat damage still used the stack to resolve/apply, is when the rules were the most fun to me.