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.
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?
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.
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.
I think one important bit of context that may be missing here is that Hydro Quebec is technically also a public research (graduate) university. You can get PhD there when working on these projects (how this is implemented is confusing, but it's a de-facto stand alone university). It's not "just" a power company. It's also one of the larger income/export source for the the government.
To be fair, "old hardware" is kind of frozen in time by definition. DSL is what it is. If you want to play with hardware with 32mb of ram, it does what it does. It isn't really an OS you want to "use" or "expand upon". I would not suggest to connect it to the Internet or expect any kind of updates, security or otherwise.
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.
It was 3% as long as you were part of the conspirator and make it extra painful to everybody else. What the conspirators wanted out of this was to control the number of players so they could limit supply and control rates. Paying people to do nothing while you wait for the permits is how you bankrupt small contractors.
There was a (government) public investigation / shame campaign a few years ago ago the construction industry in Montreal, Canada.
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.
For the record, I am not saying something is wrong with Alma. I am saying if Rocky says they need time to get it right, then I see this as a good sign.
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.
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.