Slashdot Mirror
X.Org Server 1.16 Brings XWayland, GLAMOR, Systemd Integration
An anonymous reader writes The much anticipated Xorg Server 1.16 release is now available. The X.Org "Marionberry Pie" release features XWayland integration, GLAMOR support, systemd support, and many other features. XWayland support allows for legacy X11 support in Wayland environments via GL acceleration, GLAMOR provides generic 2D acceleration, non-PCI GPU device improvements, and countless other changes.
The systemd integration finally allows the X server to run without root privileges, something in the works for a very long time. The non-PCI device improvements mean System-on-a-Chip graphics will work more smoothly, auto-enumerating just like PCI graphics devices do. As covered previously, GLAMOR (the pure OpenGL acceleration backend) has seen quite a bit of improvement, and now works with Xephyr and XWayland.
there will be no usable X, at least not from X.org, outside of poetterix.
I really hope it is not a requirement and will never be on for X.org. Otherwise, I will end up having to make my Linux-servers X-less and probably use Windows as terminal. After all, with systemd, windows-like levels of intransparency, insecurity, complexity and developer arrogance have already been reached. One system with that is quite enough, I do not need to deal with that crap on Linux as well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So, to me it sounds like they are moving to being Linux only. As someone who supports multiple UNIX flavors (AIX, Solaris, HP UX, IRIX, and FreeBSD), all of which are running some form of X (and several of them running X.Org), I am displeased with the trend towards all of the primarily Linux dependencies for a lot of software - GNOME 3, Wayland, and now features of X11.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
I can tell you I feel similiarly.
But until and unless a large percentage of the community starts coughing up money to directly pay devs otherwise, they're going to do what their corporate masters (primarily redhat, but also other tech incumbents) choose to do.
It's the same reason lots of other tech has made it into the linux kernel but taken years to a decade to make it into BSD. If the community isn't ponying up the cash to keep the development in a direction they desire, then some corporation will coopt it and pervert it into something we hate.
It's not the first nor last piece of software we'll see this happening with.
So what particular one thing does SysV init do well in your opinion? I honestly can't think of a single thing. It's crappy at managing services, it's crappy at running shell scripts (as witness by the non-standardness of init.d scripts), it's shit at managing running services with interdependencies (inittab), it's shit at dynamically reconfiguring systems (e.g. network reconfiguration for Wifi.), etc. etc.
There's a reason alternatives were created, y'know.
HAND.
Totally agree. When I read his analogy it initially made sense to me, but only because I implicitly switched the order of Systemd and SysV init because that makes sense. "abomination that does "everything" complexly and half-assed" perfectly describes the hell that was init scripts.
I don't think SysVinit is particularly good at anything, especially considering it's SysV's complete lack of functionality that caused the emergence of 9 different ways to do network config (Debian way, RHEL way, Gentoo way, and many others); 9 different ways to do logging (syslog, rsyslog, syslog-ng, etc.); and so on with starting daemons, yada yada.
That said, I'm really somewhat disappointed that, as powerful of a unifying force within the Linux distro world Poettering's contributions have been, they completely neglect non-Linux FOSS operating systems. I've been a RHEL/Debian hand for years and years, but recently I've started falling in love with SmartOS, which is based on Illumos/OpenIndiana/OpenSolaris. It actually has a REALLY good built-in init system called SMF, which, like all init systems, sucks at some things but is really really nifty at others. One thing I can say for certain about SMF is it kicks SysVinit's ass from one side of the world to the other. It's always disappointing when a project team for something other than systemd, which previously compiled fine on SmartOS, decides to add a hard dependency on Systemd. It basically guarantees that your project will be forked for all the people out there who aren't using Systemd.
Looks like Xorg doesn't strictly require systemd, which is the CORRECT way to integrate Systemd into a project: make it an OPTIONAL dependency. I have absolutely no qualms with a project ADDING support for Systemd while maintaining support for non-Systemd systems, such as non-Linux OSes. I have a problem when something I need on SmartOS is basically hard-locked to the Linux kernel by indirection to hard-depending on Systemd.
It's crappy at managing services,
init doesn't manage services. Services are either managed by inetd or by themselves. init only has to start the services.
it's crappy at running shell scripts (as witness by the non-standardness of init.d scripts),
That's proof of how good it is at running shell scripts. It just runs the script.
it's shit at managing running services with interdependencies (inittab)
Init doesn't need to be good at that. You can use a tool to create your runlevels which can figure it out. The only problem I see is the lack of parallelism. I suspect that this could have been fixed without replacing init.
it's shit at dynamically reconfiguring systems (e.g. network reconfiguration for Wifi.),
Why in the love of all that is Unix would you expect init to handle network configuration? Its job is to start and stop things, not to reconfigure your NIC. This mindset is exactly how we got systemd when we didn't really need it. We should have been able to use selinux to run X without root.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Are you able to explain more?
My impression is that there were 2 issues with non-root X - mode setup and input device management. KMS and DRI2/DRI3 take care of the former, and I'm under the impression that systemd-logind takes care of the latter. But ultimately these are all just kernel interfaces - if systemd-logind has a root-helper and makes a series of kernel calls to manage the input devices, then that same job could be done by some other piece of software.
Again, do you understand the base mechanism at work here?
The living have better things to do than to continue hating the dead.
Actually, a lot of us, including Linus Torvalds, do submit bug reports and patches to various groups (such as GNOME) that get promptly ignored or rejected because of politics.
And in my case, it's "I was using Linux happily until I tried other operating systems, and realized how horrible the GNU/Linux setup really is"
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Bullshit propaganda from an AC, no less. Either you are lying or you have no clue what is going on. In any case you are being dishonest and follow just the usual patterns of lying, cheating, and ad Hominem that is so prevalent in systemd circles whenever anybody dares to say something negative.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Is Lennart paid by Redhat or by Microsoft?
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
He's accurately describing the reasons for systemd and the reasons so many of us use it.
He's giving the main, standard party line. It is not "propaganda," it is how people with a different view than you really feel about it.
Compare that to your hyperbole that misrepresents the choice, and ask yourself who is producing propaganda!