Elv13

(one of AwesomeWM core dev here)

Vicious is getting quite old. We put tons of effort in AwesomeWM to be perfectly backward compatible all the way back to the 3.5.0 API (ok, 4.0 had documented breaking changes, but still had compat code to minimize the porting work), like bug-compatible level using a **ton of `if` in the code. I really can't blame any effort to implement wayland to nuke that compat code mess when it blocks them. The older Vicious most people use is also using blocking code in the main thread, it it locks the entire WM when its calling a shell command. AwesomeWM had async APIs for that kind of stuff for a decade now. IMHO, using some LLM call to port the widget to use the declarative widget API, which AFAIK SomeWM supports, is probably worth it for performance alone, even if you keep using AwesomeWM.

Debian (and thus Ubuntu) has full support for automated installs since the 90's. It's built into `dpkg` since forever. That include saving or generating answer to install time questions, PXE deployment, ghosting, CloudInit and everything. Then stuff like Ansible/Puppet have been automating deployment for a long time too. They might have added yet another way of doing it, but full stack deployment automation has been there for as long as Ubuntu existed.

It was tried before (gimpshop)

Well, the stories goes that's actually an Al Capone gift to society

Not really. Maemo/N900 and OpenMoko existed and worked well enough. The problem I think is more than Meego/Mer/Moblin was supposed to be equally open, but a customer ready version of that idea. It was delayed over and over again. By the time it existed, it was no longer a pure X11 based Linux distribution and more of an (too) early take on Wayland. It was also so late Microsoft made a powergrab and managed to kill it. Ubuntu mobile (and to some extent BlackBerry10/WebOS) then came and tried to take that crown, but by that time iOS and Android were too entrenched. Ubuntu mobile was also MIR/LibHybris, you can't really build your own DE/WM on it since its a monolith. So the FLOSS community waited/wasted 6 years waiting for some building blocks (and the hardware to go with them) to be ready and were left with nothing. By that time the ship had sailed and the world depended on "apps" to interact with everything and FLOSS can't challenge it.

A lot of vendor tools (think firmware flasher, diagnostic tools) for older hardware used DOS boot images (CD, floppy, USB, netboot, etc) because it gives lower level access to hardware. Some software/hardware combo is also "real time" which was "easy" in DOS compared to higher level managed operating systems. Shipping those tools as a boot disk required a DOS license. So this is a market FreeDOS took over a long time ago (like parallel port CNCs). Another niche is the emulators for old games. They still need "a DOS". Until recently there was no open source release of MsDOS, so using it was technically piracy, which make some otherwise legal things hard to redistribute (think a legit website selling roms). I have seen it "in prod" in small business when I was younger where they would have it in a VM to access their old accounting and CRM from the 80's when they had to look up some things because the file formats were obscure and proprietary (think 5-10 employees shops which have been doing the same thing for decades, like food processing or wood mills)

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.

The phone part is no different. It's easy to run your own FreeSWITCH or Asterisk server at home and connect a cellphone using Wireguard. It costs ~0.5$ US per month to get nearly unlimited everything. Calls and SMS work just fine. The problem is always mobility. You need either Wifi or some of those odd reseller brand ultra cheap pre-paid plans (like "1$ for the first 200mb" plans). Then you need to make sure only the voice/sms is allowed to use the data and you get a 2$ nationwide working cellphone. You can also share someone else plan by having them leaving their Phone wifi hotspot on.

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

I am pretty sure material science went a long way. No need to put a foot of lead behind the reactor. The space race provided quite a bit of funding toward lightweight protection. It was too late for those plane project as they were already ramping down in the mid 60's.

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.

There was plans in the 50s/60s to have a fleet of nuclear aircraft staying airborne for 2 months. That job ended up being taken by submarines, some staying in mission for 6 months. So the logistic of keeping people and a few ICBM in a metal tube for months is pretty much sorted out. With the hypersonic craze, the money is back to fund scramjets tech too. Nuclear planes are a terrible idea, don't get me wrong, but it's not impossible to build them, it has never been. The problem is radioactive exhaust for the direct cycles ones (the easy one) or reliability for the indirect cycle (the "good" ones).

It actually make some sense if their official explanation for the purpose of the vehicle is true. If the main reason for the X-37b is to bring material to orbit and study the long term effect of being in space, then going higher make sense.

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.

> I’ll be left stranded if the rest of the Linux ecosystem moves on.

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.

> While I have you here, do you think 4.4 is still years away?

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.

> It's a little buggy in the 4.3 tree

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.