It's Now Easier Running Wayland Under GNOME-Session

[bkor]

It is not upstream's job to deal with insane hacks. And you know it.

Indeed, I've said several times that we don't like the current situation. However, from the loads of people who complain about choice (gentoo-dev mailing list as well as debian-devel), the amount of people making this possible is about 5 or so. Those 5 are the packagers, whom are busy enough as it is.

So jump up and down and demand things all you want. I'll jump up and down with you (I'm not a coder). It won't make a difference for logind.

I'll say it plainly again: more contributions from non-systemd people very welcome! Especially if they can track git head closely.

[bkor]

The OpenRC case is interesting since it's also portable to the BSDs, I would like to see more effort put into that init system rather than lumping everything into the logind basket and making 'THE END IS NIGH BECAUSE BITROT' sensationalisms.
Perhaps the Gnome team should donate some of their development time to non-systemd solutions such as this.

I'm clearly stating that there is a need for more contributions from non-systemd developers because almost all GNOME developers use distributions which use systemd. We do loads of infrastructural work. Why would GNOME need to maintain an init system? There are loads and loads of desktop environments. We still support non-systemd. In the case of Wayland we unfortunately rely on logind, which depends on systemd.

Why do you at the same time really badly demand choice, while putting in 0 effort, while stating others should put in a lot of effort?

[valeriodean]

Because logind is not portable to non-Linux systems, furthermore the LGPL licensing would prevent it from being uptaken by projects that only want to carry code that is permissively licensed.
Seems ironic that the MIT licensed Wayland and Weston will have to depend on a LGPL component to function.

And it's not just the BSDs that are suffering, it's OpenSolaris and its derivatives, Minix and any Linux distribution that doesn't want to carry systemd for design or compatibility such as Gentoo, Slackware and Puppy Linux just to name a few.
This forced adoption of systemd only serves to force Linux distributions who want to migrate away from X11 to either use systemd or get left out in the dust.
There is nothing fair about that.

Wayland is a protocol and doesn't dipend by systemd.
About Weston, it's just a reference compositor and probably the wayland's devs have decided to utilize others project as possible to avoid to reinvent the wheel and instead focus on the matters they really care about.
If you are compliant with the wayland protocol then you have a wayland compositor no matter if you use systemd or not.
In any case, wayland uses a lot of linux-ish that you need to replace if you want to port it outside the linux world, ins't it?

[jrch2k8]

well to compliment a bit here, lots of people cry in gentoo mailing list but systemd is perfectly functional and available in gentoo, you just add systemd to your make.conf and edit default/grub to point at systemd and voila. at worst you need to extract systemd units from certain packages from Arch repo if you are lazy and don't wanna customize your systemd, in my case i preffer do it by hand because i love have many demons to spawn when needed only and die after i stop using them, like mysql or nginx for example.

about systemd cries i found them a bit over rated, for example

1.) systemd force cgroups OMG: well Cgroups turned out to be an evil way to bypass or expose without proper security parts of the kernel exploited by lazy people looking for an easy way , read more here http://www.h-online.com/open/news/it...e-1911611.html, systemd and cgroups maintainer are working togheter to fix this flaw and allow systemd to control cgroups access to avoid those usecases[note is not discarded other init deamons can do the same, only systemd so far steped up to do so]

2.) systemd journal is pure evil: is it? it start way before any other logging tool[syslog, syslog-ng,rsyslog,etc] ever think possible and has more precise information and is very easy to use plus is indexed, aka a lot faster than grep/sed all distro variant of log output files from XsyslogX.

3.) yeah but journal is binay!!!: so what, if you machine breaks early enough to stop systemd journal from spawn you have a toasted piece of hardware mate and in this case syslog won't be able to spawn either, aka in either case you loose the ability of read text files[or inquire systemd journals] putting the drive in other PC because it was too early for either so neither catched the issue.

4.) but im pretty sure i can find a doom case!!: i think so too, no one is saying sytemd is fail proof. just make a good report case in the bug report so it can be fixed

5.) doesnt work outside Linux OMG: so what? zones and jails are solaris/bsd specific, solaris have an solaris only init system, BSD have an BSD specific init system too and they don't port their tools to linux either, they both have their own specific licenses[BSD/CDDL], they make their own exclusive drivers, etc. So why a linux tool have to underperform or not use linux specific goodies to support platforms that don't give a flying fuck about linux?

6.) yeah but gnome/kde/etc?: well to be honest is not their problem since BSD/genode/solaris/amiga/hurd/beos/etc have their own specific session systems and login infrastructure, if non-linux systems want to support a DE they should provide their patches to upstream for their platforms and fix their init systems to fulfill the needs of that DE, at worst DE just need to provide an abstraction layer for Session management API and let those whose care implement plugins for their platforms.

7.) logind is evil!!!: well is not systemd fault that no other init system wants to provide cgroups hierarchy control, isn't it? is not systemd fault that no other init system move a finger in prepare a replacement for VT, isn't it? is not systemd fault that no other init system provide a nice API and policykit integration for a secure and easy to audit session/multiseat hierarchy, isn't it?, so instead of blaming systemd for do things first instead talk your favorite init system developer to catch up or you take the task of doing so

[bwat47]

well to compliment a bit here, lots of people cry in gentoo mailing list but systemd is perfectly functional and available in gentoo, you just add systemd to your make.conf and edit default/grub to point at systemd and voila. at worst you need to extract systemd units from certain packages from Arch repo if you are lazy and don't wanna customize your systemd, in my case i preffer do it by hand because i love have many demons to spawn when needed only and die after i stop using them, like mysql or nginx for example.

about systemd cries i found them a bit over rated, for example

1.) systemd force cgroups OMG: well Cgroups turned out to be an evil way to bypass or expose without proper security parts of the kernel exploited by lazy people looking for an easy way , read more here http://www.h-online.com/open/news/it...e-1911611.html, systemd and cgroups maintainer are working togheter to fix this flaw and allow systemd to control cgroups access to avoid those usecases[note is not discarded other init deamons can do the same, only systemd so far steped up to do so]

2.) systemd journal is pure evil: is it? it start way before any other logging tool[syslog, syslog-ng,rsyslog,etc] ever think possible and has more precise information and is very easy to use plus is indexed, aka a lot faster than grep/sed all distro variant of log output files from XsyslogX.

3.) yeah but journal is binay!!!: so what, if you machine breaks early enough to stop systemd journal from spawn you have a toasted piece of hardware mate and in this case syslog won't be able to spawn either, aka in either case you loose the ability of read text files[or inquire systemd journals] putting the drive in other PC because it was too early for either so neither catched the issue.

4.) but im pretty sure i can find a doom case!!: i think so too, no one is saying sytemd is fail proof. just make a good report case in the bug report so it can be fixed

5.) doesnt work outside Linux OMG: so what? zones and jails are solaris/bsd specific, solaris have an solaris only init system, BSD have an BSD specific init system too and they don't port their tools to linux either, they both have their own specific licenses[BSD/CDDL], they make their own exclusive drivers, etc. So why a linux tool have to underperform or not use linux specific goodies to support platforms that don't give a flying fuck about linux?

6.) yeah but gnome/kde/etc?: well to be honest is not their problem since BSD/genode/solaris/amiga/hurd/beos/etc have their own specific session systems and login infrastructure, if non-linux systems want to support a DE they should provide their patches to upstream for their platforms and fix their init systems to fulfill the needs of that DE, at worst DE just need to provide an abstraction layer for Session management API and let those whose care implement plugins for their platforms.

7.) logind is evil!!!: well is not systemd fault that no other init system wants to provide cgroups hierarchy control, isn't it? is not systemd fault that no other init system move a finger in prepare a replacement for VT, isn't it? is not systemd fault that no other init system provide a nice API and policykit integration for a secure and easy to audit session/multiseat hierarchy, isn't it?, so instead of blaming systemd for do things first instead talk your favorite init system developer to catch up or you take the task of doing so

Quote for truth, I agree with everything you said. I think you are one of the few sensible people left on this forum :/

I am an arch linux user, and IMO systemd was the best thing to happen to it, it made managing my system far easier and robust. Good riddance to manually dicking around with daemons in rc.conf .

I don't get this argument people have about systemd that its "hostile to bsd". Why should systemd developers give a crap about bsd? Its a linux project, being developed by linux developers. They have no obligation to support bsd, nor should they. And they are certainly not openly hostile towards it, they just happen to use various linux specific features. Why have all these great features in linux if we can't have projects use them without being 'anti-bsd'?

99% of the systemd hate I see is pure ridiculous FUD.

And regarding consolekit/logind, as was mentioned earlier in this thread, consolekit has been totally dead upstream for quite a while now, and systemd stepped in with a maintained [and technically superior] alternative, or course DE's are going to start relying it. Why rely on a project thats dead?

[jrch2k8]

Quote for truth, I agree with everything you said. I think you are one of the few sensible people left on this forum :/

I am an arch linux user, and IMO systemd was the best thing to happen to it, it made managing my system far easier and robust. Good riddance to manually dicking around with daemons in rc.conf .

I don't get this argument people have about systemd that its "hostile to bsd". Why should systemd developers give a crap about bsd? Its a linux project, being developed by linux developers. They have no obligation to support bsd, nor should they. And they are certainly not openly hostile towards it, they just happen to use various linux specific features. Why have all these great features in linux if we can't have projects use them without being 'anti-bsd'?

99% of the systemd hate I see is pure ridiculous FUD.

And regarding consolekit/logind, as was mentioned earlier in this thread, consolekit has been totally dead upstream for quite a while now, and systemd stepped in with a maintained [and technically superior] alternative, or course DE's are going to start relying it. Why rely on a project thats dead?

i don't know lennart seems to be the kind of guy everyone hates for no reason, the thing is now that im used to manage my systems with systemd i can't understand how i tolerated other init daemons before and is not like i hate write bash scripts tho. now what i love the most is the DBUS API and polkit integration are just wonderful if you are a developer and using DBUS was smart to make it language independant.

well but whatever if there are masochist outhere wanting to use consolekit with polkit be my guess and you sir have my respect

[blackout23]

Quote for truth, I agree with everything you said. I think you are one of the few sensible people left on this forum :/

I am an arch linux user, and IMO systemd was the best thing to happen to it, it made managing my system far easier and robust. Good riddance to manually dicking around with daemons in rc.conf .

I don't get this argument people have about systemd that its "hostile to bsd". Why should systemd developers give a crap about bsd? Its a linux project, being developed by linux developers. They have no obligation to support bsd, nor should they. And they are certainly not openly hostile towards it, they just happen to use various linux specific features. Why have all these great features in linux if we can't have projects use them without being 'anti-bsd'?

99% of the systemd hate I see is pure ridiculous FUD.

And regarding consolekit/logind, as was mentioned earlier in this thread, consolekit has been totally dead upstream for quite a while now, and systemd stepped in with a maintained [and technically superior] alternative, or course DE's are going to start relying it. Why rely on a project thats dead?

Quoted for truth, again. Seriously systemd is a joy to use, especially journalctl. How could anyone want SysVInit instead of systemd?

[jrch2k8]

Quoted for truth, again. Seriously systemd is a joy to use, especially journalctl. How could anyone want SysVInit instead of systemd?

i guess is the classical phenomenon of "lennart is in the project, it has to be evil for sure so lets hate that project guts without even use it for no rational reason at all" and in this case i think gnome must show some balls, i mean if you find your product/project is better with this tech then follow that path because trying to please god and the devil at the same time will make your project a mess.

for 3.12 guys just make an plugin API and a systemd plugin, if anyone else wanna run gnome outside that norm they can perfectly fine write a proper plugin for they wahtever desired platform/init system and you don't have to keep that salad to please every human being choice of OS on the planet because that is the works of distro maintainers not upstream