gldrk

>Who are these people like “idk might switch to Windows because of Apple’s failed AI strategy” making this an actual problem?

It’s not about users but about investors who rely on the greater fool theory. If Apple is not adopting the current thing, people won’t FOMO in, so it’s better to buy other stock.

I don’t believe GNU invented the AT&T syntax for x86. System V probably targeted x86 before GNU did (Richard Stallman didn’t think highly of microcomputers). They used some kind of proprietary toolchain at the time that gas must have copied.

Every few years they break all links to The Old New Thing. There is no job Microsoft can't botch.

DEI is no longer in vogue (or a thing) thanks to 10/7. Its former backers are funding the White House ballroom right now.

‘Democrats are the real racists’ in 2025?

>I don’t care at all: the tone of your skin, where you come from, who you sleep with or what hole you piss from

That sounds like a sad, shallow, deracinated existence. It is human nature to care about these things. You never hear this boomercon cringe in healthy societies.

Just wait until someone leaks an internal SOTA model. Would be deeply ironic given how much AI robber barons ‘respect’ others’ copyright and trade secrets.

The big difference is that Algol 68 is set in stone. This is what allows a single dedicated person to write the initial code and for it to keep working essentially forever with only minor changes. The Rust frontend will inevitably become obsolete without active development.

Algol 68 isn’t any more useful than obsolete Rust, however.

>Yes, in a very superficial sense, you can't literally route a packet over the internet backwards to a host behind NAT without matching a state entry or explicit port forwarding.

Don’t forget source routing. That said, depending on your threat model, it’s not entirely unreasonable to just rely on your ISP’s configuration to protect you from stuff like this, specifically behind an IANA private range.

>This is a lot different than say OSS vs ALSA.

ALSA is an absolute nightmare to work with infinitely worse than Wayland. At best 10% of it is ‘documented’ through Doxygen. For the rest the only reference is the source code. This is one reason applications don’t tend to support ALSA anymore.

Okay. KDE is absolutely comparable to Firefox according to https://openhub.net/p/kde. Tiny fraction of the expenditure. I’m not even sure what their selling point is, but it’s a lot better than Mozilla’s.

>Firefox replaces more code in a month than Rusts' entire codebase even contains.

Point taken. Rust + LLVM is almost half of Firefox though, and probably at least equivalent in terms of necessary skill. It is also not clear how much of that code could be removed without much loss of functionality.

>Rusts' expenses are massively subsidized by donated staff time from over a dozen major tech companies.

This is called having a selling point. If Firefox offered anything besides not being Chromium, people would work on it without getting paid by Mozilla.

>The major comparables in online user fundraising are Wikipedia, which AFAIK is the largest annual online fundraising drive in the world and it raises less than 50% of what search licensing gets.

All this shows is that Mozilla is even less efficient than Wikimedia! There are projects such as Rust and LLVM that rival Firefox in complexity with 1/10 the combined expenses. Of course Rust has a selling point and Firefox doesn’t, but whose fault is that really?

>I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked.

Do RSS readers and browsers send the same Accept header?

Unless you are targeting Atari 2600, immediate mode still retains state in the form of a frame buffer. Your video game should not repaint if nothing has changed since last frame, e.g. when paused, let alone a text editor.

>systemd-networkd, iwd, timers etc. The base usage barely touches 350 MiBs.

That’s absurdly high for a headless system that’s doing nothing. There are countless millions of embedded devices doing useful work today with 1/10 the RAM. They run modern Linux just fine without the ridiculous bloatware.

As should be clear from the reset vector, the 80286 and its successors actually boot in unreal mode. On the 80386, the base address of the code segment is 0xffff0000, which cannot be obtained by shifting the 16-bit CS register by 4. The descriptor cache simply gets loaded with the correct value at reset. Writing to CS in real mode overwrites the cached value with CS * 16.

Linux is GPLv2, there is no tivoization protection. In fact most tivoized devices run Linux.

That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.

Come to think of it, I think the original idea can be salvaged with an acknowledgment signal. Send bit, wait for acknowledgment, send next bit or retransmit accordingly. Actually you would need a handshake before each bit.

UNIX signals *do not* queue. If two or more signals with the same number are sent faster than the receiving thread handles them (due to the signal being blocked and/or the thread not being scheduled), all but the last will be lost irrevocably. There is no mechanism to prevent this.

https://ldpreload.com/blog/signalfd-is-useless

You are right. There is a third-party DTD that should be mostly compatible (https://sgmljs.sgml.net/docs/html5.html).

In reality, HTML4 was never implemented to the letter by user agents, because people do things like putting -- inside comments.

HTML uses a ton of SGML features not part of XML (sometimes erroneously though to be non-standard ‘tag soup’, not to mention self-closing tags). You need either a specialized parser or an SGML processor + DTD.

Windows NT has a native console API that every non-Cygwin program used until a few years ago, when Microsoft finally implemented terminal emulation. See, for example, https://github.com/vim/vim/blob/e7c765fe5997daa845222351e114.... It’s just that there is little interest in TUIs from Windows users.

Terminals are full of legacy bloat, but TUIs don’t have to be. I don’t think Borland IDEs used ANSI.SYS.

How is graphical vim even different from TUI vim? At least Emacs can render images.

The irony is that web standards didn’t move fast enough either, so the browser developers simply bypassed the standards body in favor of their own post-hoc ‘living standard’.

IE didn’t fight anything; it merely existed. There was no constant barrage of features that you ‘had to’ make use of to ‘keep up with the times’. Microsoft correctly decided that the Web was done in ~1999. They even had ‘Electron’ in the form of HTAs, except it wasn’t remotely as bad.

The web was a much better place when it had to support IE6.

>even with LDTs, segments will not function with the legacy 16-bit wraparound

Yes, this is why KERNEL exports __AHSHIFT and __AHINCR.

>Despite that entire conversation happening almost a week ago.

It’s difficult enough to find correct information about this stuff. There is no harm in providing corrections.

Properly written Win16 applications are agnostic with respect to memory protection. Windows 3.0 could run in real mode (8086+), standard mode (80286+), or enhanced mode (80386+). Enhanced mode used V86 mode, which didn’t exist on the 80286, to support DOS console windows. In standard mode, Windows suspended itself to allow running DOS applications.

Real mode support was in fact dropped in Windows 3.1, so any program that runs under that is guaranteed to run under Linux/Wine (though not guaranteed not to crash because of some unimplemented API).

In protected mode, all Win16 code runs in ring 1 or 3, including all drivers and application programs, as well as the so-called ‘kernel’, which is just a shared library that provides support for coroutines, among other things. The actual kernel that runs in ring 0 is the DPMI host.

Memory segmentation is 100% supported on AMD64 in compatibility mode. This is entirely independent of the default operand size: it is purely a historical coincidence that 32-bit code segments tend to go hand-in-hand with flat memory models.