I highly recommend to read this great evaluation of upstart and systemd and the discussion around it.

For me as an upstream who wants to integrate with systemd it's valuable information. My idea so far is that a Plasma on Wayland shell needs to be brought up by systemd. Especially I consider using socket activation to start the KWin session compositor. That's something I want to discuss in detail with +Àlex Fiestas at the next Plasma sprint and try to prototype the unit files for it. My assumption here is that any system which can run Wayland also uses or provides systemd (BSDs don't run Wayland). As the Wayland shell is new technology depending on new technology I so far do not see a compelling reason to not rely on the awesome technology provided by systemd or to provide multiple implementations.

Of course a legacy startup will still be around to bring up Plasma on X11. So for the BSDs nothing would change. They can start Plasma on X11 without systemd. But everybody on Linux would benefit from using systemd and Wayland.

What about Ubuntu and everybody else who might consider systemd as the tool of evil? Well there is nothing to stop Ubuntu from shipping systemd and to a large part they are already doing it. Whether the init system is used should not be relevant to us.
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]. Bug#727708: init system other points, and conclusion. To: 727708@bugs.debian.org; Subject: Bug#727708: init system other points, and conclusion; From: Russ Allbery ; Date: Sun, 29 Dec 2013 16:10:10 - ...
57
3
Cameron Norman's profile photoJay Payne's profile photoLiang Suilong's profile photoJustin Wong's profile photo
46 comments
 
As long as activation is centralized in one place (library, process manager, collection of activation config files, whatever) and not spread between multiple binaries I also don't see the problem. It would be asked for future porting problems (because systemd won't last forever, ~nothing in Linux does it seems) to sprinkle systemd dependencies throughout the codebase, but that doesn't seem necessary.

Good luck with bringing a proper startup sequence to Plasma Workspaces.
 
I'd prefer to see no hard dependency on it, to be honest. So far KDE always was very good in providing ways which don't rely on a specific system out of multiple ones, e.g. KDE still works fine without pulse audio or without network manager. 

Note that some distributions do not rely on other solutions than systemd because it is "a tool of evil"  (honestly, given your debate around Mir/Wayland I would have expected less populistic and provocating wording from your side. Didn't you vote for a more technical and pragmatic discussion, instead of people starting religious wars?), but rather because these distributions not only provide a GNU/Linux userland and kernel, and they prefer to have the same solution for all of them (e.g. OpenRC). An example aside from debian would be gentoo, where systemd is available but completely optional. It would be nice if KDE would leave this, and not pull in such dependencies.
 
+Christian Loosli sorry for missing the <irony> around tool of evil. I sometimes forget that people on the Internet don't know me good enough to interpret such things they way it is meant to be.

Concerning a hard dependency. Well we also have a hard dependency on X11 and/or Wayland. We have a hard dependency on Qt. We have a hard dependency on many other things. If someone doesn't like it, he is more than welcome to provide the patches and maintain them.

Otherwise I just think it makes sense to use what is available. Please note that I'm not looking for systemd because of random political reason, but because of features not provided by anything else. E.g. socket activation and proper integration of cgroups. Both are things I want to use for Plasma 2 on Wayland. It might be possible to live without it, but in that case it might be that important features are missing (I do hope that we can use socket activation to survive crashes of the session compositor) or that security is not as optimal as it should be. No other system provides such features.

Oh and I hope we all agree that we want kdbus, no matter which init system is used.

And that's why I pointed to the mailing list thread. It's no longer the question which init system is to be used. Systemd is more than an init system and most parts are already an important part of the stack - like logind or kdbus.
 
It's not about knowledge, it is about the lack of emotions a text has, which is why there are these tags and emoticons. It's always easy to mark something as irony or humour afterwards, and this just provokes the discussions you don't seem to like.

As for the dependencies: the difference there is, that it is either "no alternatives" (X11) or  "you can't really support multiple at once"  (toolkit), so I'd say that these are different from the situation with initd systems / replacements, where currently a couple of alternatives are not only available but also widely used. Forcing people to use one there might be a bad idea. As a little experiment of thought I suggest you think about what would happen if you make pulse mandatory for KDE on linux.

As for the "possible to live without it": apparently, as not only it is possible right now, but also in other environments. Of course if you do plan to implement something in a specific way, living without it might not be possible. Which is why I ask you to think about this. It might have quite an effect, which could worst case just put some distributions in the situation of dropping KDE support.

In addition to that, and what Aaron already pointed out: Linux is terrible when it comes to things like logind or kdbus. If you look at the past years with what we technologies we had   (HAL, devicekit, udisk/upower, polkit, policykit, consolekit) I guess that choosing a and relying on a specific technology might cause quite a lot of rework as soon as something else comes, which definitely will happen. So choosing something right in the middle of a debate on what to take is quite brave, and the people who are finally affected by this are your users.  
 
+Christian Loosli it would not force anyone to use systemd as the init system. It forces to use parts of systemd, but one can still use openrc or sysVinit as the init system. It's important to separate those things.

Of course I am not interested in making anything in a way that it ties us to systemd. And even if I did there are people like +Aaron Seigo who rightly yell in such cases. Especially in the area of mandatory dependencies Aaron and I have very often opposite standpoints and I think that is very healthy for discussions and decisions (and I am quite sure that we both take a more extreme point in such discussions than we actually want). Still the point remains: I want to have socket activation and that's just not provided by any other solution. This feature will depend on systemd in practice but in theory any system allowing socket activation would work. And it will still be possible to just start KWin without systemd support - I will need that for development. One will be able to use that, but important features will be missing then. I'm sure other projects welcome patches to make that possible.
 
+Martin Gräßlin: Yes, I did read that part, but it still pulls it in as a dependency. And as far as I am informed (and can see), these are not really modularized, so you basically pull in a whole init system that you don't need.

My side is that you as the developer have a certain responsability. As said, you can choose to implement something in a certain way so it only works with X, but then you are responsible for the consequences. And this is why I ask you to think of other possible ways, since, as I pointed out, choosing (and relying on) one side here is imo, at least in the current state the debate/decision making is in, brave at best.

Of course it is always easy to rely on patches from others, but here again I like to take the pulse example. Think about how certain people would react if you'd say  "no, kmix and phonon-* work with pulse only, if someone wants direct ALSA or OSS suppor tthey have to provide patches themselves".  This was also a decision, it was also solved without having to rely on one implementation (which does provide quite a feature set compared to the others). Of course this increases the maintenance efforts needed, but that is a balance. And you decide about it. And since you do publish your thoughts about it on a public place like G+, people as I will probably throw their arguments in.
 
+Christian Loosli do you see any way to have socket activation without systemd? You can still use KWin without it and thus the dependency will be optional, but those features will be missing.
 
+Martin Gräßlin: That seems to be something Kai Mast is interested in. The question is probably not "do you have X with Y", but rather "can you implement X with Y", which might be a different implementation. But then I am neither that much into the details of systemd/upstart (I also currently use neither) nor do I know what exact feature you need and why. But I am already glad that you are now looking for possible other solutions :)
 
+Kai Mast I don't know whether upstart supports what I want to achieve and in case of upstart I don't care (that means I will not investigate time into it, because it's a one distribution solution (Ubuntu only, Chrome OS is irrelevant) from my point of view). After what happened in 2013 I think everybody understands that I'm not interested in Canonical technology and keeping compatibility with it - others can do that, I won't.
 
Meh, so it seems to be more political than technical. Hypothetical question: what if Debian does decide to go with upstart? That would not change the fact that it is "Canonical Technology", but it would no longer be a "one distribution solution". Would you then be interested in supporting it, or would the fact that it is from Canonical be more important than the amount of distributions using it?
 
I think I read somewhere that Ubuntu will use systemd's socket activation... I can be wrong though.
 
+Christian Loosli no, that's not political. It's about me not wanting to have anything to do with Ubuntu (yes I don't like being called names and I haven't forgotten that). It's not political, it's just that I'm still hurt in that point. Which means that I'm not interested in working on it, but I won't stand in the way if someone else wants to work on it. Classic scratch your own itch issue.

+Kai Mast uh, oh that's a game changer. If it only supports TCP it's pretty much useless for our use cases (no TCP socket here).
 
Here comes the obligatory rant from the grey-haired UNIX guy...
I would really appreciate it if  the KDE SC would not adopt a hard dependency on SystemD. Even while I understand and respect your reasoning about "single-distro implementations" +Martin Gräßlin , from a distro packager perspective I would like to make the choices myself.
In Slackware, and particularly with KDE, we have been walking a fine line between remaining true to core UNIX principles and allowing for more user-friendliness. We succeeded so far, not in the least thanks to a KDE developer community that has proven very capable of abstracting the desktop from the OS core. We try hard not to rely on components in our OS that are exclusive to Linux - Slackware is a multi-function tool and someone who would try to create a SlackBSD will get my full support.
If parts of KDE will require SystemD in future that could become a breaking point for us. I want to experiment with Wayland but that would currently rule out a future for KDE since I am not prepared to experiment with SystemD. On the other hand I am glad to read that you are willing to provide continued support for X.Org without depending on SystemD. That would be very much appreciated.
 
+Eric Hameleers I'm sorry but I have to say that I hardly consider arguments as valid if systemd is incorrectly spelled (see http://www.freedesktop.org/wiki/Software/systemd/ section Spelling). In my humble opinion it just shows that you have an opinion on that software without having properly investigated it (that is not even read the main wiki page). The same is to say about anything about "UNIX" - please see http://0pointer.de/blog/projects/the-biggest-myths.html Myth 10. To me this looks like Slackware hasn't really evaluated the option of using parts of systemd properly.
 
+Martin Gräßlin could you please try not to alienate people by dismissing their arguments based on spelling? That seems rather arrogant to me.
Back to topic: I think giving people/distributions the choice to either go for Wayland + systemd or stick with X should be enough for now (unless a significant number of distributions who want to use Wayland + initscripts or whatever start cropping up).
 
Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal:

* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for *BSDs. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.

* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it.
 
+Elias Probst No, I think it is perfectly clear that one does not have to use systemd as the init system, but still people don't want it as a dependency. Reasons for that can include things like  "It's simply unneeded to pull it in" (especially interesting on self-compile systems, but of course also for packagers) up to "It's simply not available on our distribution/platform/whatever".
 
+Thomas Pfeiffer I hope I do not alienate people by that. Unfortunately systemd is a very political topic and many people have an opinion on it without having any clue about it. You will very often see that those misspell it. For me this is a sign that the person hasn't looked into it yet and thus cannot have proper arguments. In the case above the main argument is UNIX, which Lennart has discussed very often.

+Elias Probst thanks
 
+Christian Loosli I'm a heavy user of one of these "self-compile systems" (using Gentoo since nearly 12 years) and I don't see much of a problem pulling in systemd as dependency. systemd itself doesn't have much/heavy dependencies and the package itself isn't heavyweight in any way.
"Simply not available on our distribution/platform/whatever" is IMHO no valid reason anymore: it is available as package on nearly every distribution (even on Debian) and for the rare exceptions where it isn't or it isn't wanted by the "self-compiler", there's still the "old X11 way".
 
+Christian Loosli undestood from my side, but please understand that I don't consider such arguments as extremely valid, since Gentoo complained about KWin removing the build option for OpenGL. Optional dependencies can be a good thing, but if it goes in the direction of having things optional BECAUSE WE CAN! it starts to get stupid. That's the experience I made with Gentoo :-(
 
Hi +Martin Gräßlin , thanks for responding so fast. I fail to see how a choice of spelling is an indication of being knowledgeable though. It is not uncommon to use Pascal Casing in programming (you use it for instance), and I was just carrying it through into my post as a writing habit.
Contrary to your rash conclusion, I have read SystemD design documents, I did read the full article with which you started this post, and I have digested much, much more. I have extensively followed the line of discussions between yay- and nay-sayers and formed my own opinion of SystemD.
It is not a smart goal to try and adopt only parts of SystemD - it is obvious when you look at where it came from and its evolution to date, that SystemD is meant to be embraced in full. Parts of it will be deprecated without allowing for legacy (udev). And pointing to Lennart Poettering's own posts about debunking myths is hardly what I would have expected from you. Do I have to believe the one person who is responsible for SystemD when judging the options? Rather I would like to have seen real argments from a neutral party.
The people involved with Slackware have actually discussed the consequences of using of (parts of) SystemD. This was not done by cutting open a goat and reading its entrails. My judgement is based on facts as much as you do. Only, my viewpoint is different.
So, let's not fight over semantics, and let's not discuss here what's so good - or bad - about SystemD. Instead, my post was meant to (1) radiate a positive sentiment toward your work, and (2) to establish enough levels of trust that we will be able to maintain our KDE packages as part of the Slackware core.
I am not sure if the trust-establishing part has worked out well.
 
+Martin Gräßlin If you start to not see things as valid when they come from distributions you had issues with in the past  (Gentoo complaining about a build option, Ubuntu due to the disputes with Mark etc., ...) and from users who misspell things, and from ... then at one point everything aside from your opinion / thoughts will be invalid. And while it is completely up to you as a developer to decide, I see this as dangerous in the FOSS world.

Anyway, this gets distracted to many side discussions, it seems that you did hear my (and other people's) complains and reasons, I do hope that you will consider them.

Kind regards
 
+Eric Hameleers thanks for your feedback and clarification. That helps me to consider your feedback properly - sorry for applying my filter. I can only suggest to consider adopting parts of systemd or at least make it possible for your users to use it. I'm surprised that you don't think Lennart is the most knowledged person about systemd. For me he is the absolute instance for anything about systemd. He is a great engineer and I trust his blog posts and myth-debunking about systemd. The same way I assume that you would trust me stating anything about KWin.

Personally I doubt that there is anybody who is neutral in the discussions about systemd. There is way too much political in it and way too much FUD. Threatening upstreams to give them the kick in case they decide for systemd is certainly not a good way to improve the situation ;-)

Of course like with everything: if you want to have solutions without systemd: patches welcome. Given how many people wrote here that they don't like it, there should be enough people around to implement this. It doesn't have to be me or anybody else upstream who does it.
 
+Christian Loosli no, I have to evaluate the feedback. If it comes from Gentoo I just have to consider that they want everything with as many build options as possible. I have to put that in the right context. I have to evaluate whether the cost on our side is not too high for supporting this specific distro need. Ubuntu is of course a different topic, as that unfortunately went into an extreme personal level and I think it's understandable that I don't want to have anything to do with it. Luckily this personal level only applies to me and I'm not the only KDE developer. The spelling issue has been resolved and that feedback is considered.
 
+Martin Gräßlin Although I don't know about the specific request from one of the Gentoo KDE devs wrt keeping OpenGL optional, I can see where the idea behind it comes from. Gentoo has always been about being extremely flexible and leaving a lot of choices to the user. The sudden disappearance of the "OpenGL option" probably just caused a sudden fear of losing control over kwin's build-time options, but since there's a proper upstream decision to do so, IMHO all is well.
Usually the Gentoo KDE devs are quite aware of technical upstream decisions and have in most cases a good reason to intervene, but this case was probably just due to some misinformation.
 
+Martin Gräßlin
I agree that "patches welcome" is indeed the right attitude here. I know you don't like to accept patches for a single distro, but since this is an issue which is likely to affect more than one distro, it absolutely makes sense that those people who want to build KWin on Wayland without systemd write and upstream the patches to make it happen. That's how F/OSS works!
It would be bad if you rejected the patches (unless they are of poor quality or cause problems, of course), but people cannot just say "But he has to write KWin so that it works with my distribution / systems!".
 
@the general sd discussion: Having options just to have options is a bad thing, in the same way that having abstraction layers over abstraction layers is bad, because you always have to make compromises to create a good abstraction (and in the end you have a solution which is much less powerful than any of the modules you abstracted, and you can't really use the power of the things which have been abstracted). (...Phonon, cough (I am a bit biased about that ^^))
So, if there is a good technical reason for not hard-depending on systemd-init, something it does worse than it's predecessor sysvinit, abstraction makes sense. In any other case, hard-depend it on Linux, and handle !Linux cases differently.
The final goal should be technical excellence, IMHO, and not being able to choose every combination of Linux plumbing layer parts, no matter if it makes sense or not.
What Martin suggests is IMHO acceptable for everyone, because !Linux and !Wayland platforms will still be supported :-)
 
These discussions are best served with stark clarity and accuracy, otherwise it becomes too difficult to reach anything resembling consensus. So let's try for that:

** KDE SC?

This is not about "KDE SC". It is about Plasma 2, and this limits the scope considerably.

Firstly, it means we're talking about the KDE Frameworks 5 era in which the libraries are not shipped in one big chunk as they are in KDE SC 4.x. As a result, we would expect installing Krita would not pull in a systemd dependency. It probably should also mean that only when installing a Plasma workspace (e.g. Desktop) that you'd get such a dependency.

** Added dependencies

There are a lots of hard dependencies in Plasma Desktop right now. Want integrated networking config? You get to use Network Manager. Bluetooth? BlueZ. Start a graphical session at all? x.org. Of course, it also all relies on Qt.

In some of these cases there are no alternatives (e.g. BlueZ); there are for others however. There are alternatives to Network Manager, for instance. What happened there? Well, nobody stepped up to support anything other than Network Manager, even though it was possible, so now the Network plasmoid only supports Network Manager. This could still happen now thanks to the modular nature of Plasma but it hasn't. Well, sort of: we wrote a small Plasma widget for conman that was used with the first couple of versions of Plasma Active on Mer OS .. until Mer OS switched to Newtork Manager removing our need for it.

How about Qt? Well, we needed to choose something, and ~15 years ago someone did. Qt it was, and Qt it remains.

So hard dependencies are not in and of themselves horrible. Complaining about dependencies is complaining about capabilities. With no dependencies we can have a small and utterly featureless system, but we don't want that. This isn't 1990 when disk was expensive and CPUs horribly constrained.

To make a good selection, we need to be reasonable and ask ourselves a few questions:

* Can we reasonably make the support optional?
* Should we use an in-house solution or outsource it?
* Can we reasonably support more than one option from the perspective of technical design?
* Is there manpower available to implement and maintain support for more than one?

So let's start with a definition of what the need is:

A Plasma workspace needs a way to start different processes as fast as possible while ensuring that dependencies between them are met. Sounds like an init system right? :)

Additionally, Plasma workspace has several processes that must be long-running and be guaranteed to restart if something goes wrong (crashes).

Turns out with a well designed init system, you can get the second need for free.

So .. let's take the questions in light of those needs:

* Can we reasonably make support for this optional?

No: we need to start sessions. So there will be an init system somewhere.

Currently it is in the kde-workspace module. It takes the form of a shell script (!) that's been in constant use for a long, long time and while it works it is neither fast nor does it have any capacity to order the startup beyond the fixed order of things in the script and the semi-random nature of xdg autostart and session restoration.

We have another one that we built for Plasma Active and it does basic dependency management. (I suppose very few people know that we have two different init systems for Plasma Workspaces?)

So it isn't optional.

* In-house or outsourced?

Our experience with session starting is that it is non-trivial. If there is a solution that already works, that would be fantastic, saving both developers time and users from dealing with bugs.

Moreover, using an external system used by more than just us opens doors for better system integration.

Right now there is only one target platform that has done any real work in this area: Linux. So guess who gets to call the shots there? :)

Within the Linux world, those that have moved away from shell-scripts-in-etc init systems have gone in two directions: upstart and systemd. Which brings us to:

* Can we support more than one?

It should absolutely be possible. This is what I alluded to in my first posting. This is a feature set for which all the implementation should be kept in one central location rather than sprinkled across the entire codebase. That means it would be replaceable.

Furthermore, I imagine Plasma will keep the startkde shell script around for legacy purposes offering two ways to run the system: an old and less featureful/reliable mechanism, and a better system.

If the better system becomes overwhelmingly used by our users then perhaps startkde will die. I would hope that Plasma Workspaces would still keep the session management code centralized to allow for future adaptation to changes in the underlying system(s) used. This is one reason why having something like Solid, even if it has only one backend on a given system, is so useful.

so:

* Is there manpower to support more than one?

No. Not because there couldn't be in theory, but because there isn't in practice. The proof is that nobody has stepped up outside the core group, and even that interest has been sparse. It's been ~1 year since first attempts at this started, and ~2 for the Plasma Active init system (which was built and then put into maintenance almost immediately). There just isn't the interest.

So we have to prioritize. Obviously, we should satisfy the majority of our user's needs first and work on minority group needs later (or wait for people within them to step up and do the work).

The majority of our users are either on sysv init style systems (startkde for them, then) or systemd systems. Red Hat, SUSE, Arch and others have moved to systemd and this seems to be picking up. For Plasma Active, we focus on Mer OS which happens to also have moved to systemd. Note that Red Hat used to use upstart, but moved away from it due to limitations, creating systemd in the process.

Upstart is used by Ubuntu and some of their derivatives. The vast majority of those provide environments other than Plasma to their users. Ubuntu itself is becoming harder and harder to target as they maneuver their stack further away from other offerings (c.f. Mir). The primary Ubuntu based OS's I know of that people use KDE with are Kubuntu and Linux Mint KDE.

Those are the difficult ones, indeed. Should Debian move to systemd, then perhaps it becomes easier for Kubuntu.

In any case, there is a schism here and we need to prioritize. systemd will hit more of our user base on more systems than upstart would, and startkde can fill the needs for the non-systemd systems.

When we add to this that systemd has relevant features and integration upstart does not currently provide, the decision becomes more evident. In fact, upstart tends to pull in features from systemd .. so picking upstart would mean picking both elements of systemd and upstart. Those worried about dependencies should be able to do the math there.

So lacking manpower, the answer is self-evident imho: systemd, with a shell script (starkde) fallback.

If done "right", the init management will be centralized and a hardworking, enthusiastic person could replace that component with one that uses upstart. Just like someone could create an implementation for a network stack other than Network Manager.

The rest of the discussion about politics, dependencies, OS support, etc. are moot compared to the above imho.
 
+Martin Gräßlin "even if I did there are people like +Aaron Seigo who rightly yell in such cases."

As you know, I won't be there to do this anymore. Plasma needs to rely on others for this kind of balancing input and stewardship, and I hope it gets it.
 
I read a lot about the portability concerns on the Debian mailing list, but I feel like there is not a properly solution. I feel like you have no changes to make everyone happy, so at the end, you must take a decision. 
Image a project that for lack of resources remains blocked on the same features/capabilities for years, 2 or 5 or 10 years.
On the other hand you have a vibrant project able to implement features and fix bugs speedily like the hell. 
What happens? If you try to be portable on both the projects, then you are forced to follow the develop ratio of the slowest project. Can be acceptable for the first years, with just some differences between the two, but considering the development speed ratio between the projects, after some years you are forced to take a decision:
- implement the last and coolest features from the vibrant project
- renounce to that features and to the improvement that can reach your project for the sake of portability.
More time pass, more that renounce became a cost.

Short story: about projects with evident different development speed and resources (i.e. linux vs. non linux kernel), initially you can try to be portable, but with the time this came back with more trouble than sodisfation, and then, I think, you will need to take a decision. 
 
FreeBSD at least is interested in wayland, and trying to figure out what to do about it given that linux is [probably] leaving xorg behind.  Xorg lacks manpower worse than kde for various reasons: once they get wayland the default on most distros I expect that X11 will die: new video cards won't get working drivers. (I'm not sure what this means exactly)
 
This such a non-issue... Martin want Kwin to be as good as it can be. He made a technical decision. It will require a dependency. If people don't want to use that dependency... it is not Martins fault.

If you don't want to use systemd.. then don't. It will render in a less experience than what it could.. but that is your decision.

Read the Debian discussion. It is very good. Russ have really done his homework. Also.. if you feel portability is of such importance.. no one would stop you from forking it. I don't really see the point of that as BSD already have a init system.. but it's up to you if you want to waist your time.
 
+Henry Miller cool to hear that, though I disagree on your fear about X11. I expect that it will be around for at least one to two decades (yeah NETWM would replace Motif, wouldn't it?).
 
+Martin Gräßlin Unlike Motif, x.org requires non-trivial drivers and I think that will make all the difference.

Within 3-5 years of Wayland reaching a critical massof users, I doubt we'll see much effort put into x.org drivers. If you can bring up Wayland just by using the openGL stack, why would a vendor go through the effort of writing and maintaining a whole x.org driver stack?

Reaching critical mass imples that the primary environments and applications are available for Wayland. But once there, I suspect we'll soon see new GPUs coming out without X.org support. This will screw over x11-only applications, but that should be nearing zero by then.

I mean: most use Qt or Gtk+ these days. Blender doesn't, but there's already a Wayland backend for it. LibreOffice is apparently ready for Wayland with the work done leading up to being able to support Gtk3+.. There is the Wayland-Ozone backend for Chromium (and therefore Chrome). fltk and other such smaller toolkits are probably in a worse situation, so it won't be perfect.

The Linux desktop user base is so small that if GPU vendors can get away with having a well support openGL stack "only", then I bet they will. It would even let them re-use a lot of their work for Android.

This would mean that "legacy" x11-only applications will probably end up having to be run in a VM or using some poor fb driver with xwayland.

In the ARM world, btw, this is already how it is. It is often easier to get accelerated Wayland up with libhybris and the Android openGL stack than it is to find a well maintained hardware accelerated X.org server for the GPU.
 
+Aaron Seigo it depends on how important it is for large GPU vendors. If $largecustomer pays for the support of their very old glx based CAD software, it will continue to be supported. After all there seem to be enough customers wanting such drivers for non-Linux systems.

Also with things like glamor and generic egl drivers and no more development in the x server it might be possible to just run X on standard drivers or a very clever generic driver.

Otherwise I hope you are right. If it will no longer be possible to bring up an X-Server on modern hardware we can remove all the support code except the KWin-XWayland bridge from the workspaces.
 
It's obvious that Système D is Lennartware™ and so it must be dismissed, as hundreds of redditors are asking for... </sarcasm>
 
+Kai Mast AFAIR the upstart Socket thing misses (at least) the following features:
– IPv6
– UDP
– Multiple Sockets (like listening on eth0 and tun0, but not on eth1)

There are some similarities, but no feature parity between upstart and systemd ;)
 
It is a complete and utter lie that Wayland is a "linux only thing". It is a portable codebase and protocol, and porting to FreeBSD has already begun. Furthermore, BSD interest in hardware accelerated desktops has risen recently, and Linux's KMS stack has recently been ported to FreeBSD 10 and OpenBSD current.
 
So startkde still works under Upstart, launchd, OpenRC, etc, right? And it will be available under Wayland? Why would systemd be requirement then?
 
+Martin Gräßlin  "it would not force anyone to use systemd as the init system. It forces to use parts of systemd, but one can still use openrc or sysVinit as the init system. It's important to separate those things."

I am heavily confident that to use systemd as a session init (as you describe) requires that systemd is PID1. Please double check before requiring systemd for kde's session on Wayland. Edit: yes, it will req that systemd is PID 1. Just confirmed with someone on #systemd.
 
+Stefan Betz Those just need to be implemented, the basic infrastructure is already there. IPv6 and UDP should be especially easy.
 
+Cameron Norman About Wayland, you say that it is not a "linux only thing", but reading the architecture page, it seems that, instead of X, Wayland takes advantage about all the interfaces and features provided by the Linux kernel in order to avoid to reproduce existing stuff again and stay only on their competencies .
So Wayland taken that decision despite that some Linux features are (were?) Linux-only. 
Isn't true that Wayland is a Linux only thing until someone port that Linux's features (KMS?) to other kernel also?
Is this not the same for Kwin or Gnome? They want some features and that features existing right now, but at the moment some of them are systemd-only. Like KMS until its port.
Seems the same song, then "enjoy to port" seems be the answer.
 
Wayland does not depend on KMS, and never will. Weston depends on KMS, but a Wayland compositor can use any type of driver or mode setting API.

Nevertheless, KMS has been ported to OpenBSD and FreeBSD, so Mutter and KWin should technically be able to run on *BSD.
 
+Cameron Norman You are right, Wayland is the protocol. It's my bad habit to call the protocol and its C implementation under the same name.

So, coming back to the problem, the only concern still alive about the systemd+wayland combo for the linux users is the possibility to start KDE on Wayland also for *BSD through a legacy startup like startkde?
  
Add a comment...