I don't understand what you're suggesting. To put the work into the ALSA userland, you would make an additional daemon on top of it and put features there, which is exactly what Pulseaudio and jackd are.
The only real option for a high-end Unix workstation with heavily integrated software that still exists seems to be the Mac Pro. Linux is really not comparable to IRIX.
People keep saying that Wayland needs to be more of an X replacement but it's never clear what that means. You want 3D graphics over the network, that currently means Vulkan, and if you were going to do that, there doesn't seem to be much reason to tie it to any particular window system.
It's not clear what else it is that you'd want. The MIT license seems to get used because it's short and to the point in stating priorities: Here's the software, do what you want with it, but don't take credit and don't come after us if it doesn't work for your use case or if it causes your CPU to explode. If your issue is with the "legalese," it wouldn't be any less meaningful if you stated it differently.
Gentoo still has their own init, some distributions still use sysvinit, and both can run GNOME. Upstart is a dead project AFAIK, and the developer dropped it and said it was strictly inferior to systemd. ALSA is just the kernel layer, there is a limit to what you can put there, so some of it has gone into another layer in userspace, that's by design in the kernel. I won't comment on the display system, everything that needs to be said there has already been said in the other 700 comments here. I also wish this stuff went faster but unfortunately it takes time to do real work.
I'm not sure what you mean by consensus, if there was consensus on everything then we wouldn't have so many Linux and BSD distributions. We'd probably have just one or two, and you'd probably be more annoyed about "wagging the dog" if that was the case.
Not really, AFAIK this is the only part of systemd that really caused an issue, and it was because this is a capability that really needs to be provided by the OS and can't realistically be maintained as part of a desktop environment.
I remember that too and the main issue was that BSD didn't have an answer to logind and it took them a while to port later versions of GNOME 3 because of it. You can't seriously expect Red Hat or some other Linux distribution to drop everything and figure out the best way to get new features to work on all the BSDs before they release something, that's something only the BSD developers can do. If the "dog" here is supposed to be BSD, the wagging is not working on them.
What you are saying is a borderline conspiracy theory and is not true. GNOME still works outside of systemd, and the distributions that want to use it outside of systemd are maintaining the parts that they need, which in reality are pretty small. (I can give some more technical details if you want, but the short answer is: elogind)
To be clear, I was mostly referring to low-or-zero-cost products mentioned previously like gmail, outlook or excel, or any random zero-cost piece of open source you can download on github. If you depend on that stuff then it is your problem, that's a signal that you won't pay the extra cost for stability. The businesses that can afford the extra stability are not using the consumer offering, they pay Google/Microsoft for a long term support contract. (And yes, Xorg, Wayland, GNOME, KDE, and all the other open source Linux desktops are all under the category of random free project on github)
You're preaching to the choir. I wouldn't work on such a project again, but when you say "manage expectations" what usually happens there is the customer realizes it doesn't match their expectations and then goes somewhere else and finds something that's in their price range. The point is, there is a class of customers that aren't going to pay for this. Ever. They either can't afford it or have decided it's not valuable.
I agree with you, but still someone has to convince the customers to pay for that, and sometimes they won't. I've been on far too many projects where the customer won't even pay for unit tests and gets angry at the suggestion.
Hey, if you have the kind of money that medical companies spend on testing and stability, and you want to spend that on Linux desktop environments, I won't complain. Although it probably is better to spend that on developing life saving devices than it is on fixing outdated desktop paradigms.
>The team that did not make stability a priority did a lot of market building for the ones who did.
I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.
See the protocol extension I linked, there are absolutely exceptions and escapes that can fall back on the X11 way of doing things, and could even work with such X11 client isolation, but somebody would have to take the time to actually design and implement them and figure out how to get them to work with the security model used by the Wayland implementations. That is really the problem, it's only an implementation detail if you choose to do it by hacking the X server or you choose to make a new D-Bus API for it, or whatever. (i.e. there is no real reason XWayland needs extra extensions, it could call a D-Bus API if necessary, and that may even be desirable because the D-Bus API would be forward-compatible with newer Wayland applications)
In wlroots they probably won't implement it because that requires a GUI toolkit and they don't want to depend on any particular toolkit.
The push behind wayland happened specifically because the desktop environments wanted to implement their own display server, and it was becoming problematic to try to make it happen transparently. It's actually somewhat of the reverse of what you're saying, desktop environments can only wash their hands of things and push them off to the X server for so long before it becomes untenable.
The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
I'm not sure what are the changes in the X11 server implementation you're talking about, but if they do indeed meet every single possible use case, then maybe someone can bring them over to Wayland? I'm sorry to say, but you have to acknowledge these are novelty applications and are really not driving progress right now, the main focus is in getting all the other applications to work.
What I quoted isn't a law, this is something that authors have to deliberately put in their licenses/contracts for the specific work in question. If you wish to have other obligations with your open source software that you believe are less wrong, it would be wise to get those in writing.
I don't know, last time I tried stock Ubuntu I found it to be pretty similar to current macOS with the launchpad and mission control. In any case, the answer to those problems you're describing would be more and more breaking changes, not less.
That's great when the feature set you're talking about has already been validated by the market. When it's not, it's a mistake to focus on that. I believe we call that "premature optimization."
I don't expect the community to be happy, I would say I more expect a community of engineers to be realistic. The ship has unfortunately sailed long ago and it's not coming back.
For debugging purposes, the display server can just dump the screen to a file or a serial port itself. The only reason you would need this in the protocol is so other arbitrary applications could capture the screen.
If you read the fine print there is, quite literally, no obligation at all. From the MIT license:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
You will find that most other FOSS licenses contain a similar clause.
I have no idea why it has become so common on here to dog on GNOME for being "user-hostile" because they targeted a different kind of user than the average HN engineer/startup person. You can use one of the "GNOME 2 revival" type desktop environments if that's your fancy.
I'm sure you know this, but memory perf and stability are secondary to supporting the hard business requirements. For low-cost products intended for mass consumption, a small feature that brings in millions of new users from a new audience is usually going to be more worth it to the business than optimizing for old hardware that doesn't bring in money anymore.
It actually is feasible to sandbox X11 in that way, I believe this is what security-focused distributions like Qubes and Whonix do. But yeah, it is essentially working around the problems with X11 and not really suitable for ordinary use.
To me the real progress needed is that applications need to move to using sandbox-friendly APIs so they don't break when put in the sandbox, and moving to Wayland is a key part of that. Applications built around the X11 idea of always having full access to everything will need changes regardless of what sandboxing solution is in use.