badsectoracula

GP most likely meant it was a solved problem from the user's perspective. Autotools might be "horrifying" for the programmer (IMO that is an exaggeration, AT isn't that bad, with the potential exception of libtool) but it provides by far the best UX for a user (that knows how to use a command line and what building from code is, not your average grandma :-P) compared to everything else out there.

However one important aspect here is that there is no reason for Autotools to be what provides the `./configure && make && make install` UX - the GNU standards (not sure the exact name) describe the UX itself without mentioning anything about Autotools so any other approach to implementing it would be just as valid. However in practice whenever you find a configure script in the wild it is either Autotools or a hand-made one (that more often that not misses some of the GNU standard stuff).

IIRC Borland released the C++ version specifically as PD later on their FTP server, it isn't based on the version from Turbo C++ physical releases. The history is (very briefly) mentioned in the Free Vision wiki page at the FPC wiki[0] (note that the wiki needs cleanup, e.g. it mentions 64bit clean support as a todo item but FV has been 64bit clean for a very long time now). It also mentions that somewhere between the C++ version and the Pascal conversion, TV/FV was converted to use graphics instead of text mode and it was ported back to text mode -- considering all the conversions, i'm surprised the API remained largely the same so that even now the best way to learn Free Vision is to read Turbo Vision docs/tutorials/books :-P.

[0] https://wiki.freepascal.org/Free_Vision

Amusingly, Free Vision (the Free Pascal version of Turbo Vision) is based on a manual translation of the C++ version because that was released on public domain at some point and someone ported it back from C++ to Object/Free Pascal.

Free Vision, included with Free Pascal is basically that. The text mode IDE[0] uses Free Vision.

The main issue is that Free Vision (and Turbo Vision) uses the original "object" types introduced in Turbo Pascal 5.5 instead of "class" types introduced in Delphi which make a lot of things easier (e.g. the "class" RTTI allows for enough reflection to implement automatic serialization of objects, but "object" types do not have that and Free/Turbo Vision require manual serialization with registration of the VMT pointer -accessed via a fixed offset in object pointers- as a means to distinguish at runtime between different types). Free Pascal adds a few of the niceties of "class" types to "object" types (like private/protected/public sections -TP objects are all public- and properties) but Free Vision doesn't use those as it implements the original Turbo Vision API.

[0] https://wiki.lazarus.freepascal.org/images/1/19/Userscreen.p...

> They should be separated kernel modules in their own tree.

The main issue with this is that by being on a separate tree they do not benefit from the API breakage updates in the kernel. After all the main benefit that kernel devs mentioned over the years for keeping drivers in the kernel instead of separate trees is that the code gets updated whenever internal APIs change.

I wonder if it supposedly knows the code so well, is it possible to use Cursor to make a port to Avalonia or some other cross-platform GUI toolkit for C#.

FWIW that depends on the stores you're looking at. There are three models from different manufacturers available here in a few shops. The prices are a bit ouchier than what i paid for mine around Christmas 2024 though (i got mine on a sale).

You can compile it from source, all you need to do is clone the repository and do a `cmake -B build -DGGML_VULKAN=1` (add other backends if you want) followed by a `cmake --build build --config Release` and then you get all the llama tools in the `build/bin` (including `llama-server` which provides a web-based interface). There is a `docs/build.md` that has more detailed info (especially if you need another backend, though at least on my RX 7900 XTX i see no difference in terms of performance between Vulkan and ROCm and the former is much more stable and compatible -- i tried ROCm for a bit thinking it'd be much faster but only ended up being much more annoying as some models would OOM on it while they worked on Vulkan -- if you or NVIDIA hardware all this may sound quaint though :-P).

> At the time I had no idea it resembled NeXTStep, but it was great.

I used (and still use) Window Maker for almost a decade before learning what NeXTSTEP actually was (i heard about the name occasionally but never looked into it), then for several years before even trying one. I remember having a heavy sense of uncanny valley because the thing in front of me looked almost exactly like what i was using for years but it behaved in very odd ways (and lacked most of the window management features i came to expect) :-P. It made me realize what people who were used to Mac OS X felt when they tried the various Aqua GNOME/KDE themes that were popular on Linux desktops some years ago.

> The "single buffer with invalidation" model of Win16 (I cannot remember how it works in X)

Same way, they both come from Macintosh (which, if i remember the apocrypha correctly, was Bill Atkinson's idea based on what he thought Xerox Smalltalk was doing even if it turned out it wasn't working like that).

There are forks though. The only version i don't think that has a fork is GNOME 1 but... the code is out there (and there is an actively maintained GTK1-based toolkit that was posted here not too long ago, though you may need to make some modifications to the GNOME 1 code to work with it as IIRC it isn't backwards compatible).

People made CDE to work on modern systems and IIRC CDE wasn't even compatible with Linux when the code was first released.

With KDE1 is was most likely "Not yet implemented" :-)

I never used KDE2, KDE3.x was rock solid though. It wasn't until KDE4 where things took a massive nosedive and everything was crashing if you looked at it wrong - something that lasted until most of KDE5's lifetime, though by late KDE5 and now KDE6 it seems to be fine.

Well, "fine", for some reason Wayland sessions crash and restart the entire session whenever i press any key (doesn't happen with Xorg sessions), so i guess there are still some minor bugs to be fixed :-P

I think this is just doing things differently, not fixing them - and IMO not for the better either.

I've been playing with making a chatbot with llama.cpp and FLTK[0] and FLTK's default behavior is actually to add a newline in the multiline editor when pressing Enter even if a 'Return button' is in the form (Return buttons are buttons activated when you press Enter or Return though Return is also handled kinda differently). And i have a big Submit 'Return button' there.

And TBH it annoyed me a LOT that i have to move the mouse and press the button to submit or that Enter adds newlines instead of submitting so that i explicitly added code so that pressing Enter is not handled by the editor (letting the Return button submit the input) and pressing Shift+Enter is what adds the newline (Ctrl+Enter also works, this comes from FLTK's behavior, but i've been used to Shift+Enter myself).

Which is basically how pretty much every chat interface (be it AI chatbot or something like Discord or whatever) that i've used in recent times works. And TBH it makes sense to me that the simplest/easiest shortcut (Enter) is what does the most common thing (send text) in a chat interface whereas the more involved shortcut (Shift+Enter or Ctrl+Enter) is used for the exceptional/less common case. In such an interface, the multiline editing is there as an exception (for when you want to paste some stuff and even then often Ctrl+V by itself can be enough), but most interactions are going to be single line submissions (often wordwrapped to look like multiple lines but still a single line).

[0] https://i.imgur.com/K3m9KAD.png

> Windows has this thing called digital signing with certificates that Linux users like to pretend doesn't exist

...or, much more likely, any potential benefits are not worth the negatives.

FWIW sometimes when making games it helps to have everything in one place, even though later you may want to split things up for later projects :-P so sometimes you get big balls of mud with lots of checks everywhere for the actions you want.

As an example, most of the gameplay logic for Post Apocalyptic Petra[0] (a 3D platformer/adventure/riddle solving game i made for an MSDOS game jam a few years ago) is in the entity class for the player character[1] - including things like collisions, etc :-P. It is a bit hacky, but it works.

Though if i ever made that sequel i wanted to where i want to have an extra character following you around, i'd need to move a bunch of things to other more generic places so that they can be shared by both the player character and the AI.

[0] https://bad-sector.itch.io/post-apocalyptic-petra

[1] https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o...

Nobody said it was by accident. They had deals with PC manufacturers for decades where they sold licenses based on the number of PCs sold by the manufacturer regardless of if the PC used MSDOS or another OS (like DRDOS), making all other options more expensive unless the client asked for them.

But the important thing is that the clients pretty much never asked for other OSes because all of their software worked on MSDOS - and later Windows. People bought computers to run their software, so if the software they wanted to run needed MSDOS or Windows, they'd buy the machines that ran that OS.

And by extension, if the software they wanted to run wouldn't run on the next version of MSDOS or Windows, they wouldn't have a reason to upgrade MSDOS or Windows. But from a user's perspective MSDOS/Windows was the best choice because everything supported it.

Microsoft didn't rely on just backwards compatibility (especially since the idea of "backwards compatibility" relies on something to be compatible with in the first place) but it was an incredibly important aspect of their strategy.

Some time ago i was wondering if the common "me at foobar dot com" you still see a lot of people do actually helps at all, especially now with LLMs, so i searched for some common "obfuscation" techniques and found this site (not the 2026 update, but the previous - it was a few months ago). Then i wrote a simple LLM query with a bunch of examples from the site[0] (the tool is just a frontend for a commandline program that uses llama.cpp and Mistral Small 3.1 in Q4_K_M quantization since it loads relatively fast and is fine for simple prompts). AFAICT it could reveal anything that wasn't relying on CSS tricks or JavaScript.

Like others mentioned, though, personally i haven't bothered by email harvesting for years now since spam filters seem to do a decent job. I have my email posted in plaintext here (which i bet is harvested very often) and in various other places and the occasional spam i get is eclipsed from "spam" from services i've actually signed up for (coughlinkedincough).

[0] https://i.imgur.com/ytYkyQW.png

The thing is, Microsoft got its position of dominance exactly because they did that - and that was because by doing this, the users' programs kept working. Remember that users outnumber developers by far and the last thing Microsoft wanted was for people to not upgrade Windows because they broke their previously working programs.

This was even more important at a time when Microsoft had actual competition in the OS space and people weren't able to just go online and download updates.

There was (and still is) VerInstallFile, however this was introduced in Windows 3.1 and it is possible installers wanted to also support Windows 3.0 (since there wasn't much of a time gap between the two many programs tried to support both) so they didn't use it.

TBH i think a more likely explanation is that they needed to somehow identify separate instances of that data structure and they thought to store some ID or something in it so that when they encountered it next they'd be able to do that without keeping copies of all the data in it and then comparing their data with the system's.

FWIW a two digit amount of MB is usually at least 16MB (though with low hundreds of MHz it was probably at least 32MB if not 64MB) and most such systems could easily do 1024x768 at 16bit, 24bit or 32bit color. At least my mid-90s PC could :-P (24bit color specifically, i had some slow Cirrus Logic adapter that stored the framebuffer in triplets of R,G,B, probably to save RAM but at the cost of performance).

You can do a lot of stuff with the system as it is since it does expose a lot of its internals (and when you need to replicate functionality, there isn't that much in there to replicate so it is perfectly doable), but my point is that it wasn't as flexible or capable as Windows 1.0.

It wasn't just Microsoft's marketing skills that made Windows overshadow GEM, it was also that Windows was genuinely a better product - both from a technical and a functional perspective.

> Proprietary software needs a stable ABI.

Open source software also needs a stable ABI because:

a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions)

b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place

c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API

There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).

[0] https://github.com/Open-Wine-Components/umu-launcher

Wine devs do not want to work with people who have looked at ReactOS[0] (see at the end) so any collaboration is one-way (or by ignoring the guidelines) and the likelihood of the two projects merging is zero.

[0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...

> One could argue DRI bowed out too soon. Then again, it’s questionable whether it would have won against Windows anyway. Microsoft was the larger company and had OEM agreements with all of the major PC makers.

Well, it is also that Windows even at version 1.0 was much more capable than GEM. Better documentation, better tools, better API and better functionality.

GEM was really just a shell over DOS and applications were actually DOS programs that called a special interrupt handler to make API calls. While this allowed any language that could make EXE files and call interrupts to be used to make GEM apps, it also meant that GEM inherited all the limitations from DOS, like the inability to run multiple applications at the same time (DR did eventually make GEM/XM that allowed switching between applications but it was still only one application active at any given time). Windows meanwhile not only could run multiple applications, but it also had a software-based virtual memory system that allowed applications to swap in/out both data and code to fit in the available memory (this required custom compiler support so, unlike GEM, you couldn't use any old compiler but on the other hand it you could make more complex applications).

The GEM API was also very barebones, you could create windows but all you could do with them was to draw inside. Dialog boxes were a completely separate thing that could take a tree of "objects" to draw inside them but even then the functionality was limited (the object types are hardcoded and while there is a "custom" type, all it does is provide a callback for drawing). You could work around some of the functionality by implementing some of it yourself - for example there is a call to draw an object tree (object trees are actually a flat array of fixed size structures where the first three fields define 16bit indices inside the tree for each object - this probably saved some bytes of memory at the cost of flexibility loss and TBH the extra bytes added for the code to work with the tree probably ate back those saved bytes, if not made things worse) so i think (never tried it) you could draw buttons, etc in a window when you receive the WM_REDRAW message but there is no event message propagation.

Meanwhile on Windows everything is a "window" in a window tree with a consistent approach to how things are handled. On GEM everything is a special case.

I get the impression that the GEM developers basically had some idea of what their desktop would look like and implement the functionality to do just that and nothing else with little room for flexibility or later expandability.

EDIT: also the graphics functionality was very limited, e.g. with hardcoded colors. Here are some GEM API docs in case anyone is interested:

https://www.seasip.info/Gem/vdi.html (low level API, draw graphics, input devices, etc)

https://www.seasip.info/Gem/aes.html (relatively high level API, make windows, define dialogs, messages, etc)

https://www.seasip.info/Gem/aestruct.html (some structures)

https://www.seasip.info/Gem/aesmsg.html (event message types)

> The GCWZero was a MIPS console too

There have been a couple of GCWZero clones made in more recent years (e.g. from Anbernic) running the same (or a derivative) Linux-based OS with JZ4770 MIPS SoC and software compatibility. Too bad Ingenic never released any successor to the SoC though.

I don't think i ever have something fully maximized (aside from games, though even then sometimes i play in windowed mode). Even when i do maximize a window (which isn't often but some programs like Krita work better like that), the dock and miniwindows (i'm using Window Maker as my window manager) still take their own space and the background shows through. Also i often have a bunch of terminal windows minimized, then i forget about them and open new ones until at some point i go and garbage collect them :-P

One neat bit with Codeberg however is because they're using (actually developing) Forgejo (a Gitea fork which itself is a Gogs fork) you can easily clone the entire thing locally or on your own VPS to have as a backup.

Forgejo is even trivial to set up as it is a single self-contained binary you can throw somewhere and it'd work.

Well the point of this is to have a distro that contains "everything" (or at least a large number of stuff) since i can't know ahead of time what i'd need.

I think it is still possible to use jigdo to make Bluray disks, but i do not have a bluray drive :-P