You wrote that Wayland is the future of X. That's as ridiculous as suggesting a bridge in Alaska is the future of Miami.
So you still don't understand that X is the future of Y does not mean that they share anything other than once Y will be deprectated X will take over it's place and function even though I now have written that three times? Very great for some one who claims that others fuck up...
No. One guy who worked on two X extensions and another guy that did a port to a Debian variant is a tiny drop in the bucket of the developers of X.
I just did a quick look at the changelog from X.org at https://www.x.org/releases/X11... and cross checked names with people who contributed code to the Wayland project and stopped after finding these 7 names: Jesse Barnes, Kristian Høgsberg, Peter Hutterer, Daniel Stone, Gaetan Nadon, Jeremy Huddleston and Josh Triplett. The first three on this list also seams to be the major contributors to X.org in terms of code so hardly the "tiny bucket" that you describe. The most active X.org dev is Alan Coopersmith and he seams to be all in for X.org at the moment though.
You did worse than that, you wrote the following lie:
However the "X sux" is said by the X developers
Why are you trying to start a fight over a topic you know absolutely nothing about? Wayland is not X.
You do realise that the "X sux" part was a direct quote from your text and not my opinion? And nowhere have I claimed that Wayland is X in any way, shape or form
No they don't. The clock is quite unimportant for the HFT crowd. All they care and look at are the incoming orders and changes in price, the importance of the clock is only important for later record keeping by firms allowing clients to trade via their accounts (aka stock brokers) since they have to prove to the authorities later that they gave their clients the best price available at the time from the various exchanges that they trade on but that is also not a problem since you then simply aggregate the log of each exchange as you see orders coming from them (it does not matter if the clocks on the exchanges differ since what is important is the order in which you received each message, i.e that is what defines when your system could see the best price).
See, my concern are those "other things", which would boil down to de-facto interweaving the formerly separate projects, adding dependencies from project A to project B, and project B to project A, which means, as you certainly know, that it's really more one project AB. I'll admit I'm not tracking changes to the systemd source repository, so maybe my concern has not become reality yet, but I think it's not very far fetched that this will happen, if it didn't already.
I mean what would you do, if you want to implement a fancy feature in your $pet_project, but unfortunately it requires $pet_project specific support in $dependent_project, and $dependent_project happens to be inside your own repository. Don't tell me that the reasoning would be "oh yeah, we better hold on and think of a implementation-agnostic approach to this particular issue rather than just committing this little patch". Not for most programmers, and especially not for special expert L.P.
Well that is what they have done so far (i.e going the implementation-agnostic approach), you might not like DBUS but for all the warts it does make for a implementation-agnostic approach so as long as the competition support the same DBUS messages then everything should work. You might not like that the different projects use interprocess communication like this but that would happen regardless of them sharing a code repository or not (just look at how i.e gnome depends on some DBUS messages from systemd-logind)
If Linux is being made ready for the masses, and, looking at the current process of windowsification, it certainly is headed in that direction, it will become just that, another windows. yay.
I don't see the windosification, in fact the "new" interface that Microsoft has put into Windows was first seen in Gnome3 and I have yet to see anything new in Linux resemble how things work in Windows. I know that a lot of trolls have claimed that systemd mad init work like it does in Windows, but those people have obviously never used the Windows System Services or programmed one (or the shitfest that is the EventViewer for that matter). If anything I think that GUI wise both Linux and Windows are looking more at Apple and Android than each other.
Well to be honest, putting different projects into a single code repository [...] is not really my definition of "absorbing software" or an "integrated do-everythig approach".
Then what is?
That would be if they really absorbed all that software, i.e deprecate each individual project and merge their code with systemd, but that is not what they have done, they have simply put all the different projects into the same git repository so that they (among other things) more easily can make simultaneous releases.
Well we can all think what we want about the modern desktop but there is where the majority of the users will be, tyranny of the majority so to speak. And since that will be the new playing field we better have a display server that can fill that space well.
Funny, huh? I used to dislike the items even when systemd was the only item on that list that's part of the systemd repository. Not my fault systemd keeps absorbing software like that. That'd be ONE of the reasons I dislike systemd, since you were asking. If I want the integrated do-everything approach, I might just as well switch to Windows.
Well to be honest, putting different projects into a single code repository and putting common code into shared libraries is not really my definition of "absorbing software" or an "integrated do-everythig approach".
pulseaudio: significant CPU usage, overly complex, written by the systemd guy (that's guilt by precedent (postcedent?), not by association)
I've heard about the high CPU usage before but have not experienced it myself, have never seen it go above 0,x% on any of my systems. Compiz, X.Org or Firefox on the other hand (and that on idle!). Don't know if you remember the old days prior to pulse when every single project had their own incompatible sound server and how painful it was to get two programs to work together (oh so you use Amarok to play music, well then of course any flash-content from now on until you reboot will be completely silent).
avahi: thinks it owns the network stack. creates a pseudo interface even when it's not needed, assigns a link-local address and potentially brings it up. have seen it confuse the boot process on debian in nasty ways. Also written by our special friend, par for the course.
All those issues sounds like the zero conf functionality have been enabled on your system for some reason, since they are handled by a separate deamon (avahi-autoipd) it's probably started by something else like NetworkManager, avahi by itself should not bring this up afaik.
dbus: grown, not designed. used to connect desktop crap together, now abused as a general purpose IPC. doing IPC in userland is a shitty idea, mainly because of the possibility that the ipc userland daemon might not be running. even the systemd special experts have realized this and thus are pushing for kdbus.
Yes dbus is not something that I have ever liked, even though the main idea was somewhat good (reminds me about the Rexx interface we have on the Amiga) but the implementation does look way to overly complicated.
iproute2: reason for existance: Linux's ifconfig is ill-designed and grew over the years to be pretty 802.3 specific. Instead of designing ifconfig and the driver interface cleanly, additional programs were thrown into the mix. iwconfig, iw, you name it. Meet iproute2 and command lines like "ip link set up dev tap0". In case you're missing the irony here, they redesigned it, but apparently intentionally chose the one actually annoying artifact from ifconfig - the nonstandard (non-getopt) invocation syntax. So cool. then there's the exit code issue that i've talked about in our other conversation.
Yes and there are lot's of other linux-specific commands that use the same strange syntax, like mdadm. Have not really been that bothered by it though, possibly by having been put into how these commands work by both mdadm and svn so I always do the Cisco recursive command lookup style with "ip" and then "ip route help". Having worked with Ciscos IOS for years also probably have conditioned my into accepting this syntax.
udev: actually i don't know udev very much, it's just unnecessary stuff i tend to dispose of on linux systems. i get that it's useful for people who don't know how to load a driver into the kernel. or what drivers they need, for that matter.
Well I for one would not like to go back to the old days of the static
wayland: i'm mostly meh about it. seems to me like its main selling point is that it's something new, and X11 is old. so far i see no reason why i could possibly want it. maybe when i feel like using something less flexible for a change.
The problem is not that X11 is old but that the X protocol is not designed for how modern desktops render graphics, and X seams to be a complete nightmare for the X11-developers to work with and improving the situation for developers will usually lead to better end results (not always of course). For other points I think that this article on Phoronix is a good introductory piece: https://www.phoronix.com/scan....
rust: is actually a nice language and prevents programmer error and world will be safe. C's days are counted. provides universal basic income too.
Well I don't know, I'm probably too old but C is the only language that I use on a regular basis today and is also what we have deemed to be the language used throughout our entire company. The only exception is the web sites that the www guys do in PHP but all the web services are done in pure C.
gnome: huge, complicated beast. also i hate it for making me migrate my parents from gnome 2 to KDE.
Well I would say that KDE is a far more complicated beast since Gnome tends to remove features with every release
Yes, thank you!
A sine curve goes off to infinity, or at least the end of the blackboard. -- Prof. Steiner