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.
I had a N900 and was very fond of it, but it was really a prototype. Part done before its time, part a type of system that wouldn't have worked for normal people long term.
The N900 was more or less a tiny computer running Debian. With 256MB RAM, and swapping on flash.
It was way too low spec to run reliably like that, you quickly ran into swap death. And it had none of the niceties of Android's memory management, having apps designed to be stopped as needed.
Security-wise it was also bad, it was just a normal Linux box, so banking apps would be a terrible idea.
If it didn't get killed, I wonder how would they have polished it up for public consumption.
But it had some features that modern phones lack sorely. E.g. incremental reboot-free (or reboot-only-on-kernel-updates) updates ala Debian, such that patching wasn't a big deal or a 1GB download twice a week.
Those are a pretty bad idea as well, and you see some distros like Fedora move away from them by introducing a reboot/update/reboot cycle.
Yes, on Linux you can replace binaries and libraries in use, but then you're not actually running the new code until you restart the program and are still vulnerable to any security issue that it fixed.
And with things like runtime loading of plugins that now may be incompatible, and programs not expecting stuff changing underneath, online updates can be troublesome.
The online model works well enough for a command line usage where applications are transient, or a server usage where you remember to restart a service or two. But for a desktop user with long lived, huge apps like a browser it's not that good of an idea anymore.
checkrestart doesn't tell you to reboot after a microcode/kernel update, or restart a Python program after a module gets an update. needrestart is a better alternative to that.
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.
> 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.
As a retro enthusiast (and a FOSS supporter - full disclosure), I disagree. Whatever the project calls for, is what I would use - if a real era-correct DOS is called for, then I use that. If I want to use FreeDOS and it works well for that project, then I use that. I’m sure I’m not alone on this one.
> 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.
Manufacturers have been shipping devices without Compatibility Support Module for several years now, so I have many x86(-64) devices that can't boot into an DOS.
I suppose in theory a UEFI+CSM firmware could be flashed, but I'm not aware of anyone adding back in CSM support on devices shipped without it.
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?
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).
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.
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 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.
> 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.
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.
While I have you here, do you think 4.4 is still years away? Is there an ongoing documentation of API changes?
> 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.
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.
Thanks for the response, and thanks for all the effort towards an awesome WM :-) I can totally appreciate your priorities.
My use of Wayland (and for a lot of users , I suspect) is mostly just flowing with all the upstream distribution defaults. Do you expect the number of awesome-on-X users to dwindle or continue for the foreseeable future? My main concern with regards to switching to AwesomeWM would be whether I’ll be left stranded if the rest of the Linux ecosystem moves on.
> 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.
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.
reply