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.

(AwesomeWM co-maintainer here)

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.

It's using DHT like BitTorrent magnet links to find people using public keys.

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.

Would you rather have `.rpm`s build by someone on the command line using `rpmbuild` or `mock` or something built by a CI with proper bootstraping and "nearer" to reproduceable builds. Also, by cutting corners on the CI, you risk introducing mild ABI problems which wont crash, but causes instabilities and potential security vulnerabilities. If they say they needed time to do it properly, I respect that.

Qt (the legacy Qt::Widget variant) is quite productive for quick and dirty GUIs. You can do 95% of basic dialogs in QtDesigner and then connect the signals to your code and vice versa. The code can be Python or C++. It can also be mapped 1:1 into SQLite tables without any external libraries, which is handy for basic forms or data apps.

QML also has GUI design tools, but it takes much longer to learn and isn't very good at simple GUIs. However it's better when you need to deploy on Android (iOS requires the paid version).

One thing to keep in mind if the LGPL3 license. If the app isn't distributed, then it's fine, but if distributed, it has to be dynamically linked with some ways of swapping the .so/.dylib/.dll

AppImages are only as self-contained as the author put effort into making them self-contained. There's also upper limits to how self-contained they are. While some terminal and bitmap only X11 app can be compiled as static binaries, anything that depends on system libraries needs to be compiled with an older version of glibc. The best example is libGl (GLX or EGL) for hardware 3D acceleration or libvdpau for hardware media decoding. You can't just bundle those, you have to use the system ones. Using any system library forces you to use glibc (AppImage don't work on Alpine). OpenSSL and a few other a libs you usually want to use the system one and have a built-in fallback because of security concerns.

Making perfect AppImages is often possible, but the automated tooling isn't smart enough. A proper AppImage (this one is by me) look like this: https://github.com/Elv13/reclaimail/blob/master/docker-edito... . Obviously this doesn't scale very well to projects with 300 dependencies like Digikam. My NeoVIM appimage linked above "really, really" bundles all dependency and compile your NeoVIM config to luajit bytecode. It's 3.9mb compared to the upstream one which is 15mb without any config. Note than 0.7mb of that 3.9 is the spellcheck dictionary, 0.4 my enormous config, 0.5 the AppImage overhead and 0.7 all the legacy plugins still written in vimscript.

A PC is ideal as long as there is only one. Once you start adding machines, it is time to move to a rack. Otherwise you end up with a giant ball of wires. Racks have rails like drawers, so the units are easy to service. Thats not the case with a heap of ATX towers. Also, your "collection" remains self contained and doesn't grow. Past some scale, you start to also make use of other rack mountable accessories like UPSes, PDUs, patch panels and switches. In the past, you had to move pretty early because older consumer machines like Pentium4 could only do so much, so you needed many of them even for a basic setup like a LAMP server or render/compile cluster.

Yeah, if you started using `git-master` around ~7 years ago, it hasn't broken ever since. The last breaking release was v4.0 in 2016, but it was in development for years before that in the git-master branch. 3.5->4.0 was a pretty nasty upgrade process since we had to nuke a lot of the unsustainable things one last time (https://awesomewm.org/apidoc/documentation/17-porting-tips.m...).

Glad it works for you!

Just a little note that we (AwesomeWM team) have stable APIs since 4.0 and each releases no longer break the API. We also have reached 90% code/behavior coverage (from 0% in < 4.0 days).

From a maintainer PoV, this is often a pain since AwesomeWM exposes most of its internal guts, but with enough compatibility code and Android style API levels, we still manage compatibility pretty well.

you can't provide a dedicated GUI for them

You could expose enough GTK bits to expose an event loop to the LGI lua library. It's gobject-introspection for Lua. Since you already use these libs, it would not make Ardour any bigger.

I am not saying it's a great idea to mix GUI and a realtime DSP in the same thread, but it would be supported in you see some demand there.

vxworks claimed that title. Unfortunately, Linux never was the "only OS with an installed base covering several planets".

And if you never heard of vxworks or QNX, that's the point. They just work and that's the point.

A process which doesn't exist cannot hold memory

Not quite. Some leaks are across processes. If your process talk to a local daemon and cause it to hold memory then quitting the client process wont necessarily free it. In a similar way, some application are multi-process and keep some background process active even when you quit to "start faster next time" (of act as spywares). This includes some infamous things like Apple updater that came with iTunes on Windows. It's also possible to cause SHM enabled caches to leak quite easily. Finally, the kernel caches as much as it can (file system content, libraries, etc) in case it is reused. That caching can push "real process memory" into the swap.

So quitting a process does not always restore the total amount of available memory.

It runs like crap, that's why it isn't supported. But if really, really want to make it work, you can have your app make a surface, put a cairo surface in it, then render GTK there. I suggest you don't waste any time on this. Mozilla, Google and Samsung had many people _each_ assigned to fix it at some point. The Google gave up, bought Skia. Then Mozilla also gave up and used the now Open Source Skia. Samsung somehow kept poking at it for a few more years until they dissolved their Open Source division and scaled down Tizen. At some point Samsung make a Vulkan backend for unknown reasons.

With Qt 4/5, there is an environment variable, to play with. It sill runs like crap and is now deprecated.

edit: Of course, GTK4 have "real" backends for both Vulkan and OpenGL. They implement scene graphs like QtQuick rather than building a big bitmap like GTK2, GTK3 and QtWidgets.