Retro computer enthusiasts tend to use the "real" MsDOS or other era correct DOSses, so this isn't really a market where FreeDOS is used much.

Also, you don't need a different DOS for newer computers. As long as it has a BIOS compat mode, most flavors of x86 DOS will run just fine. This might change is the 16bit mode gets finally removed. If something can't run DOS, then it's technically not a spec-compliant PC.

As for reliability, well, that's your problem now, good luck!

> point some metal out of their window and the neighborhood would be happy?

You might, but the FCC won't

Neither that or the plane powerplant are unsolavle problem, it's more of a "why would we invest this much to solve something this silly". Apparently the russians are trying to resurrect their SLAM clone and tested one. How much of this is a realistic military project versus propaganda isn't super clear to me. It's up there along with the manned military space stations in the scale of pointless deterrent PR.

In an elliptical orbit, you can cross the Van Hallen belt and magnetic fields over and over again. Then after a couple years return those samples to earth for study. This gives you valuable data to build better satellites in the future.

For examples, the gyros flywheel on the Hubble and it's sibling spy telescope failed over and over until they realized the radiations caused some arcing in the bearings which degraded them much faster than predicted. When you spend billions on individual satellites, this isn't the kind of thing you want to discover in orbit.

There is no such things. Unless they remove xorg from the repository, then it's just an entry in the session login screen as it always was.

> Also, any pointers to the 80% attempts?

Waycooler rewrite 2 and rewrite 3 are close enough. There's some private implementations that are more recent and more complete, but not released and probably wont ever be. Being a FLOSS maintainer these days isn't very enjoyable (disclaimer: opinions are my own), I can relate to their reticence to open the floodgates. There's one based on wlroot FFI floating around on Discord.

Then there's a bunch of doomed attempts by people who just made the same mistakes as the ones before them, but had too much ego/enthusiasm to acknowledge how it was going to end. The problem with Wayland is that it's hype-y. People who fall into the hype tend to fall into all the hyped techs at the same time. Which means shiny Rust frameworks and edgy code generators. Then all those things are dead a couple months later and whatever depends on them also die. The only way a working AwesomeWM Wayland port can be made is using boring old glib event loops and boring old service-client architecture of xorg. Anything else will not be compatible, so the plugins and existing configs wont work, thus nobody will use it even if it was somehow internally usable. People with a lot of time and grand ideas don't tend to like boring/mature/old techs and backward compatibility. I can't blame them either, why would they.

I/we were never very fond of releases to be honest. All it does is to fragment the number of version in the various LTS distribution, which makes support a pain (vs "the official version" and "git-master"). Also, I don't have that much time these days, so getting a release out is impractical. I am aiming for the Ubuntu 24.04 cutoff for packages.

> Is there an ongoing documentation of API changes?

`git log` ;). But also, just compare the official release doc with the development one. There's over 1k changes. The largest one being the documentation itself. Then a rewrite of the notification and wallpaper APIs are also rather large improvements. Everything is backward compatible, so there should not be any nasty surprises.

> Yup that was exactly the problem and how I solved it too. If I remember correctly if workspace1 has client A and B, and workspace2 has client B and C (B is common), global stack means if I switch from 1 to 2 while focus was on A, while in 2 if I ever switch focus to B, then I when I come back to 1 I would find that focus moved from A to B, which can be annoying.

Annoying, but also like >10k lines of code/tests/doc to "fix". It will take a lot of effort to get this PR merged without behavior changes or regressions... That global stack goes back 15 years and everything depends on it's exact behavior. It's as ossified as it gets.

I was working on fixing some of those bugs last weekend. Can you clarify which annoys you the most so I can add unit test later this evening? tl;dr; The main problem is that the z-index stack and client ordering list are global and this cause changes to one tag to affect another. I am moving those structure into per-tag trees rather than global stacks.

From the point of view of tiling, Sway is an i3 clone for wayland.

For AwesomeWM as a programming sandbox WM, it is much tougher to get something identical. A lot of AwesomeWM work goes into APIs, CI and documentation. Making a scriptable WM using wlroot isn't the end of the world. Making one with mature APIs, backward compatibility, high test coverage, an active userbase large enough to sustain a plugin ecosystem and extensive documentation is much harder.

Making AwesomeWM 100% wayland compatible has been attempted a bunch of time, getting 80% working has been done a few time too, but the last 20% is like 95% of the effort or something and those projects keep stalling. From my side, I put the little free time I have for this into actually realistic features and maintenance work, at least until there's an actual reason to move away from X11. Most users at this point have been using it for years or even over a decade. They want their setup to keep working the next morning over #newshiny.

The main case for it at this point is retro computing. Most retro computing enthusiasts run era correct OS (MacOS7-9, Mac OS X, Win9x, DOS, AIX/IRIX/SunOS/HPUX, BeOS, Amiga 3x, etc). Those are not getting security updates either.

I put it in the same category as Haiku, Visopsys, AROS and ReactOS, fun toy for older computers. Not very relevant as day-to-day. I still have and expand a collection of live CDs for the P3/PR era laptop. Again, those don't get security updates, but are fun to explore.

Personally, I am more into Linux window managers (and AwesomeWM maintainer) to recreate the interesting concepts from those OS rather than rice 90s silicon. However I really enjoyed using a Pentium1 laptop full time for a few months in university in the late 00's just to prove a point. But for that I compiled my own OS rather than use a distro. If you want to get the most out of these machine, that's the way.

One of the person who testified in exchange for not being jailed was "Mr. 3%", a member of the office who approve (public) construction projects. He took 3% of the project total cost (in bribes) from the top 30 contractors in exchange for making sure their permits requests never got in these artificial rejection loops.

The bureaucracy, just like the old taxi industry, is about keeping smaller players out, not enforcing the codes.

About `mock`, the problem is the ABI. If you don't build the packages in the "perfect" order, the ABI degrades over time. For example, some libraries might accidentally add something in the middle of a struct. The API is 100% compatible. It will also run without any warning, but all pointers in the application using the libraries provided by those packages will now have an offset. A boolean might now point to in integer or something like this. If you don't have the tooling to detect this and don't have the tooling to ensure you build packages in the right order (and rebuild when needed), then you will eventually get some of these problems. Mostly on point releases. To solve this, the "trivial" way is to follow the RHEL build ordering, which requires some tools. The "correct" way is to use `libabigail`, `libsolv`, `libdnf` and other binary tooling and keep track of these things.

There are more of these little papercuts left and right you get when you build a RHEL clone. You can always cut corners and manually build everything, but you will payback the time you save in outages. RedHat has the test suite, the clones only have a small part of it, they have to be extra careful.