According to Nix v. Hedden, 149 U.S. 304 (1893) a tomato is a vegetable, so the riourous may need to account for that in the appropriate jurisdictions, especially if tarrifs are on the line, or at least to rember to have bigger lawyers than the competition. Also a carrot is a fruit (in EU, for purposes of jam classification), "I can't believe that superhero doll is not a doll", etc.
King Louis XIV lost a bunch of his land to astronomers able to more accurately measure said land. This is the sort of thing that can happen when you want to turn your country into a world leader in science.
A confused user once stopped by, they had a blank terminal, so I showed them how to select all which revealed the helpfully black on black text. These days I compile colour support out of st, or set *colorMode:false for xterm. "But you can customize the colours" is a typical response, to which one might respond that one has grown weary of pushing that particular rock, and moreover one may be busy with other things at a drag-out monitor in a server room at three in the morning that has helpfully dark blue text on a black console, or worse if some high-minded expert has gone and rubbed the backside of a unicorn everywhere so that they may improve the "legibility".
And of course XML libraries haven't had any security issues (oh look CVE-2025-49796) and certainly would not need to make random network requests for a DTD of "reasonable" complexity. I also dropped XML, and that's after having a website that used XML, XSLT rendering to different output forms, etc. There were discussions at the time (early to mid 2000s) of moving all the config files on unix over to XML. Various softwares probably have the scars of that era and therefore an XML dependency and is that an embiggened attack surface? Also namespaces are super annoying, pretty sure I documented the ughsauce necessary to deal with them somewhere. Thankfully, crickets serenade the faint cries of "Bueller".
The contrast with only JSON is far too simplistic; XML got dropped from places where JSON is uninvolved, like why use a relational database when you can have an XML database??? Or those config files on unix are for the most part still not-XML and not-JSON. Or there's various flavors of markdown which do not give you the semi-mythical semantic web but can be banged out easily enough in vi or whatever and don't require schemas and validation or libraries with far too many security problems and I wouldn't write my documentation (these days) using S-expressions anyhow.
This being said there probably are places where something that validates strictly is optimal, maybe financial transactions (EDIFACT and XML are different hells, I guess), at least until some cheeky git points out that data can be leaked by encoding with tabs and spaces between the elements. Hopefully your fancy and expensive XML security layer normalizes or removes that whitespace?
> This is also a good reason to log everything all the time in a human readable way. You can get services up and then triage at your own pace after.
Unless, hypothetically, the logging velocity tickles kernel bugs and crashes the system, but only when the daemon is started from cron and not elsewhere. Hypothetically, of course.
Or when the system stops working two weeks after launch because "logging everything" has filled up the disk, and took two weeks to so do. This also means important log messages (perhaps that the other end is down) might be buried in 200 lines of log noise and backtrace spam per transaction, which in turn might delay debugging and fixing or at isolating at which end of the tube the problem resides.
Yeah, and then it probably isn't the developers job to fix that but rather the DevOps engineer's one.
Also saying "the developer has to fix this" is something we tried to abolish when talking about DevOps. What about shared responsibility? Bridging the knowledge gap.
Electric cars were a failure, their market share tanked back in the 1910s. So a vague "electric cars failed in the market" is technically true. However, that past failure is quite distinct from the current electric car thing.
Some drunks in a gnu-shaped echo chamber concluded that the world is gnu-shaped. That's not much a joke, if there is one here. Such presently popular axioms as "unix means linux" or "the userland must be gnu" or "bash is installed" can be shown as poor foundations to reason from by using a unix system that violates all those assumptions. That the XCDD comic did not define what a unix system is is another concern; there are various definitions, some of which would exclude both linux and OpenBSD.
> This completely explains why so many engineers are skeptical of AI while so many managers embrace it: The engineers are the ones who understand it.
Curiously some Feynman chap reported that several NASA engineers put the chance of the Challenger going kablooie—an untechnical term for rapid unscheduled deconstruction, which the Challenger had then just recently exhibited—at 1 in 200, or so, while the manager said, after some prevarications—"weaseled" is Feynman's term—that the chance was 1 in 100,000 with 100% confidence.
Right now? John McCarthy invented the term in order to get a grant, or in other words it was a marketing buzzword from day zero. He says so himself in the lighthill debate, and then the audience breaks out into hoots and howls.
> Anyway, I’d remind everyone that “using” RAM doesn’t mean “would not function with less RAM.”
Except when something really does need more RAM, and fails. LLVM for example having, somehow, become a bit chonky and now fails to compile on 32-bit OpenBSD systems because it wants more memory than is available. Less bloated software of course does not suffer from this problem, and continues to run on still functional 32-bit systems.
> Many applications just use a lot if it’s available.
Xorg is using 92M, irssi 21M (bloated, but I've been lazy about finding something leaner), xenodm 12M. That's the top three. Oh, Windows? Yeah. About that. Best you can hope for is not to catch too much of the splatter. (What passes for Mac OS X these days also seems fairly dismal.)
> RAM is not really something you explicitly ration.
Paperclips were hung on the rack doors to make it easier to poke the wee little red reset button when some poorly written software went all gibblesquik (as poorly written software is wont to do) and the OOM killer could not cope and, whelp, reset time. Elsewhere, RAM is explicitly rationed—perhaps certain aspects of timesharing have been somewhat forgotten in this benighted era of bloat?—and malloc will return NULL, something certain programmers often fail to check for, which is generally followed by the kernel taking the error-ridden code out back and shooting it.
reply