Ok I've had Artix installed a few days now and during that time I also decided it was about time I removed years and years of cruft from my install. I did consider doing a clean install but in the end migrated.
While de-crufting I went through the tree and renamed any folder 'systemd' to systemd.bak. Nothing seemed to break so I deleted them. But I noticed there was one under /run. Which seemed odd at first as its on tmpfs so was being recreated at boot. I came to the conclusion that elogind was creating this.
In these few days of using Artix I've also done a lot more reading about systemd and it's encroachment into the Linux ecosystem and I'm slightly embarrassed that although I knew it was a 'thing' I had no idea how bad it was/is
Which also make me wonder about the aims, methods & approach of a project such as this. I have looked though the forum and tried to digest as much as possible but I am still a bit confused. Shouldn't elogind be one of the first things to try and replace ? eudev I get. That came before and was assimilated into systemd.
And with my tinfoil hat on I wonder why it seems so many packages abandoned support for what came before systemd when over the years I've noticed packages continuing to support all sorts of legacy alternatives to what is in vogue. Like all the media players that still support OSS sound. Does anyone use that anymore ?
I've been using linux for quite a long time. I just went on LFS partly to see what came before Consolekit. Happily back in the day I registered with their user counter so I could see that I first built a LFS system in around 2002. From a quick scan it appears that nothing really compared to Consolekit back then ? I could be wrong.
And it seems that a lot of the reason for the dependence on elogind is this concepts of ''seats' and 'sessions' ? I can't quite fathom why it's not possible to have a ./configure option of --disable-multiseat on programs which depend on (e)logind. What % of linux users have multiple keyboards and mice etc. attached to their boxes ? There must be more to it but I don't know what it is ?
What would happen if elogind was omitted and not replaced with something with similar functionality. Just something simple that said "One seat's all you are having, username and password please. Thanks you're logged in". How many current programs would break ? Mainly DM's and WM's I guess but I truly don't know.
And from what I can gather one of the aims of this project is to build all packages in core, extra, community, multilib on a systemd-free install and on a post I read you'd done about a 1000 out of 9000 (not sure how old the post was ?)
Surely there must be some way of automating a large part of this ? Greping code and linked libs to separate packages that can be rebuilt fully automated from those which will require a closer look and changes or patches ?
Anyway I could go on (and probably will at some point) but it's bed time soon.
None of this is meant to be critical of what you've already achieved, far from it. I'm just trying to get my head around it all.
And I'd like to help if I can. I can't program (I can hack a patch together a little) but I do have experience messing around with PKGBUILD's. I used to maintain a load of them for my ODROID XU and then XU3 as I was not satisfied that Arch Linux ARM disabled NEON extensions across the board so redid all the packages that could make use of NEON. A few people on the odroid forum used to use them (eg https://github.com/gripped/odroid-xu3-pkgbuilds). Abandoned as I no longer use the boards.( I wish I'd known back then I could have just put my repo at the top of pacman.conf, would have saved all the renaming and conflicts= )
So if I can help in this way let me know but I'm not often very time rich unfortunately.
TLDR
I don't blame you :)
We are at about 1800 PKGBUILDs now, which amounts to roughly 2000+ binary packages.
We already build packages fully automated with jenkins.
What caps the amount of packages is hardware resources and manpower to maintain them, some packages such as browsers won't build on our server due to lack of more server resources.
We also do not aim to fully reproduce the entire arch package set, because not all arch packages have a systemd depends and thus work with artix as well. Typical case is for example desktops, kde, its free of systemd and just works.
Regarding elogind, why would you want to drop it? Its a drop in replacement for systemd's logind. Consolekit2 is dead and lacks features compared to elogind.
Thanks for the reply. As I said, but will say again, I'm just trying to get my head around it all.
The last thing I want to do is appear critical. As a starting point lets say that I fully accept that I am probably wrong every-time.
I just came across
https://gitea.artixlinux.org/artix/documentation/src/branch/master/Notes%20for%20packagers.markdown
which has helped me to understand some of the methods you are using.
I'm still unclear how you decide which packages to target for inclusion in your repos ? I've seen another post that mentioned it's difficult as systemd is often not included in a PKGBUILD's 'requires= ' as it's expected to be present on every Arch install anyway.
So I'm interested in how you are identifying which packages do need repackaging and including in your repo and which do not ?
I believe I came across a post where a dev did state that the intention was to repackage everything in Arch repo's but may be mistaken.
As to (e)logind it is systemd created. A small part of it but a part of it nonetheless. I not saying "This must be removed" but curious as to why you are not concerned it remains ? Surely in the long run it would be better if there were alternatives to it so that other projects would not just expect, and rely on it , being there ?
Got to go to work now for a bit.
Any more "semi random thinkings out loud" I have I'll add to the thread and please ignore or reply as you see fit
Unless you're one of the suckless-types (hey, dmenu is pretty nice at least!), there's not really a reason to drop elogind. It's actually pretty easy to patch projects to build with elogind instead of systemd/logind. You really don't have to have it installed (same with something like dbus), but it just makes things easier if you do use it. Artix doesn't have the manpower to offer alternate builds of certain software with consolekit or something.
If, and thats the if and answer. There are no alternatives, as said, ck2 is dead and lacks behind, producing tons of headaches with packages that require a session tracker.
it is an uneeded security nightmare and it should be eliminated. longind was stupid and elongind is an extension of the stupidity
Everything runs through PAM anyway
How does logind/elogind make security worse?
Right, its also technically not really desirable, because you would need specifically patched ck desktop packages, whereas these just work out of box with elogind.
Consolekit2 in the repos would drastically complicate everything, and frankly, that's not worth the headache, given ck is the precursor of logind, and we have elogind, which has by now also upstream support for often used packages, eg polkit, NM, dbus.
elogind is the better choice in the structure we have and use.
Just as a followup
I'm yet again embarrassed by how little I know about how some of these things actually work , what they provide, what they do.
Reading that made me wonder what happens if I just remove elogind. Answer in my case is not a lot.
tty logins work. Lightdm complains
WARNING: Failed to get list of logind seats: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.login1 was not provided by any .service files
But then creates a seat and works. Other DM's may not be so accommodating ?
KDE/Plasma still works
Creating a 2nd Xserver with unified monitors for games still works.
So in my case I don't appear to need elogind.
I created and installed an empty package that does nothing other than provides('elogind') to stop it reappearing on upgrades.
This is just for me. I'm not saying no-one needs elogind. Or the distro doesn't need it.
But so far it appears that I don't need it, so I see no reason to keep it. There's probably no real reason to remove it either. But I'm just playing around :)
Have you checked if polkit works, eg priv granting via polkit?
To fix the lightdm to work properly, you need to adjust your /etc/pam.d/lightdm* and replace pam_systemd.so with pam_elogind.so in your lightdm pam files. Lightdm comes from arch repos, and its pam is configured for systemd.
Btw, you will definetely need elogind when the switch to wayland default comes.
In the rare case of a single user system how do you start a desktop or the xserver without a DM?
From the little that I have tried it was only possible through ck2, but I have no idea how valid and global this is. I use openbox.
On the other hand ck2 without a DM took slightly more ram to start than elogind and sddm.
Thanks to the good people at freedesktop they have nothing to do with ck2 development now :)
It seems that the last commit for ck2 was Dec 2017. :(
This elogind package tracker (https://github.com/elogind/elogind/issues/70) might be of interest.
Note, this is cross distro.
If you remove elogind, and you use a desktop and display manager, don't blame artix if any of the listed packages do not work properly or cause packages that depend on the listed ones stop working properly.
Are you familiar with security? Do you know what a vector surface is and what happens when you can a user space programing to your log in authentiation chain? By definition you have decreased your security.
How does login and polkit suck... let me count the ways!
- It increases the attack vector
- It exposed the attack vector to user space
- It allows for moron package managers to ship systems that allow for sudo to work with any random password (this was in manjaro openrc btw)
- It allows for systems to be shutdown without root permissions
- It bypasses Unix architectural security models
- It carves a HUGE hole is security by non-privileged processes to communicate with privileged ones which is what one does when they want to create a worm.
- It execute commands with elevated privileges including unmoutning and mounting attached and remote file systems
- It can alter your networking without root permisions
I find logind for the aims it wantsto achieve ok, problem is, its tied to systemd in its source. Xorg is mature, but has shortcomings, wayland is the thing they want to replace it with, and this needs a session tracker etc, for which logind is sufficient and eventually made for.
I dislike polkit, and since you mentioned it, you can prevent normal users to shutdown with logind by setting polkit rules.
If we used the BSD or Gentoo packages for X and etc, all these can be replaced. Everytone of these packages are heartburn.
Network Manager is the firs thing that should go.
pambase can just be borrowed since PAM hasn't fundementally changed in a decade.
gvfs and dbus spins out of control when it can't find its happy mimetype app... it is screwed.
pulseaudio is a huge pia and a security hole big enough for a M1 Tank
and nothing inherent in X needs polkit. That is the hardest one and you would likely need to use a supported BSD x configutation
especially with that garbage wayland coming...
The point is, I don't like to go into a discussion about the general direction linux has been taking.
We got to make the best of what is available, elogind closed the gap logind created, but artix is not BSD.
Usually I don't likwe to spout because you guys are working your asses off and it amazing that this thing works at all, but logind and polkit is broken in its very design becuse it slices through the linux kernels core security archeticture (not to mention that it treats the user like an idiot).
As for polkit, It is not needed at all and therefor I don't need to ask it permision to not be a huge security hole... it can just be deleted and blocked from the /etc/pam.d/ configurations
The problem here, Artoo, is that you are going to pump 15 years of work into this and then find out that systemd is not extractable because it is a huge worm (and I mean that... it is a security worm) ... which that now become a dependency for every user space application from the aplay to zsh
They are cementing you into the wall, brick by brick.
:(
Yeah - I understand. Sorry. I send you and your family and your team all of my love.
Hope, this day never comes.
Also, isn't elogind too overengineered for the purpose it serves?
It will when arch make that switch, we gonna follow.
I really don't care, either we want desktops and DMs working or not, there is no alternative to elogind afaik, ck2 is not an option.
With regard to this, I find it is a false choice. We've had desktops that have worked without root level authorization driven into the desktop going back to Xerox Park. It is not necessary to have longind and policy kick in order to have functioning desktops. Sun did it, BSD did to SuSE did it, Slackware did it, Red Hat did it. VA Linux did it, Raster and Enlightment did it, WebOS, INDYK, HP-Unix did it etc etc. This has been a bad design choice since Pottering begged Nat Friedman to ditch their existing login system for systemd's logind. If the goal of the FreeDesktop people to make Linux OS's more like Windows (which has been the relentless drumbeat for nearly 20 years), well that is a crap idea. A systemdless system can default to X11 and wmaker and wicd, vixie dhcpcd for a laptop set up and just simplify the entire system in a KISS design. If someone wants KDE, let them back port it to their hearts delight. Why burden yourself to support such a complex infrastructure that is broken by design?
Now, I know that you more likely mean that going forward, as these desktops are wrapped up with policykit and logind, and wayland, you feel the path of least resistance is to follow. No doubt that they are steamrolling themselves right into that systemd dependency nightmare...
or maybe not since FreeDesktop.org seem to change their mind ever 6 months, depending on the hot tech is from Apple and Microsoft.. when they then get the fun of breaking everything all over again. They are worst that the Ford Pinto with their built in obsolescence without regard to the safety of the end users.
This comes down to the question, why is Linux not successful on the desktop.... the real answer has always been, it IS successful, and has been for 20 years. What it is not is commercialized and forced on OEM contracts with hardware, to do insecure things, and to work in an obstructive manner.
If you have limited resources, the project is likely to be better situated to keep everything as simple as possible and not be hitched to a wagon train where every client program will have systemd hooks. Your looking at it and you know that you can not possibly be responsible for every client program that comes along, which is indirectly what happens when you just swap out systemd policykit and logind for elongind and faux systemd. The positive of what is being done is that in theory you can leverage the entire arch ecosystem, but the reality is that your a mouse in a maze with a mousetrap in the end. This is a giant Nigelah. Your position, as Goergi Laforge once said, should be, "The hell with the cheese, just let me out of the trap".
I would end by saying, just think about it. But I know you already have weighed this, and continue to do so every day.
xdm? I dm has nothing to do with starting it anyway. You can (or you used to be able) to just type startx
man xinit. Of course they broke that because they insist that X has to be "derooted" and run through .... systemd.
Yep, bottom line is, we do us no favor ripping it all out, it would amount to more work and more complaints.
I told you alreadey once, what you seek you will find with gentoo, which is a source distro and you easily control what you build with the use flags.
Simply said, I am not going to try to square the circle on a binary rolling distro, which is permamently moving, even more so, since the systemd octopus spread its many tentacles.
Next bottleneck will be dbus-broker they push after their kdbus disaster.
@mrbrklyn @artoo Since *dbus and gentoo were mentioned you would probably find this project/discussion interesting.
https://sysdfree.wordpress.com/232 Make sure you read through the comments which some are more interesting than the article content.
In an arch based system disabling dbus made many things fall apart all at once.
Sway (https://github.com/swaywm/sway) actually works without logind/elogind (although I build it with elogind support of course). Those guys have made Wayland very usable for me and honestly more stable than my experience with Xorg at this point.
I have X running for 20+ years. How is it more stable?
Kirill Timofeev is a troll
I have had to delete xgd-open manually to prevent it from crashing my box. It is a disaster.
X is a giant mess of hacks that works... mostly. There was that bug not too long ago that crashed Xorg on nouveau drivers, but not Wayland. X itself is also a bit of a security nightmare given that clients can freely talk to each other (not the case in Wayland). Wayland certainly has its drawbacks. It's more bareboned, so you're more reliant on whoever writes the compositor to do a good job (the wlroots guys have done a fantastic job so far). But in the end you have a simpler, more efficient protocol that cuts out a ton of pointless middleman cruft Xorg does. I can't speak for other compositors (like whatever Gnome or KDE uses), but wlroots is really nice, impressive work.
I think the big final switch to Wayland is pencilled in for the same date as the big final switch to ipv6..............
After consideration I decided not to post the more detailed reply I made, or to follow it up with the long laudry list of shortcomings of wayland, but in its design and in its securiy. I'm sick of hearing jaargon though, and I reconcongize that I am in in a bad mood, and you don't deserve to be unloaded on. In the general let me keep this simple.
I reject your arguments and find them lacking in substance and I don't want Wayland. Things like, X is a giant mess that works..mostly, is misinformation. I am aware of the shortcomings in X and they have been honed over decades of coding, and it the arguments against it lack substance. However when I say, I have been using it 24/7 for over 20 years without a problem, that is a substantial and weighty record in favor of X that was not addressed.
I will also just add that I actually use Linux exclussively for all my computing, and have done so since 1996. I have a little bit of expertise on what a linux desktop is capable of.
I'm not really sure this discussion is worth continuing at this point (and probably not really appropriate for this thread who knows). But you are bringing up the experience argument, it's worth pointing out that Xorg developers (the guys that have more experience with X than anyone else) themselves are pushing for Wayland. They have extensively pointed out multiple, fundamental flaws in X's design and how window managers constantly have to work around the dumb things X does. Maybe you hate Wayland for whatever reason, but I don't think someone could really argue that Xorg is well-designed, good software (assuming your criteria is more than just "it works").
I can log into my remote desktop from upstairs and control the desktop completely, and all the hardware and monitor the activities of the user on the system. That is what I do routinely and it is built into X11 and it is more than Wayland will ever ever do. In fact, that is the security problem they conjoured up.
Working is the most important thing software does and it is annoying to hear about the security problems with X11 from a userbase that thinks that client software should be allowed to shutdown hardware, and that run email readers that execute random code.
X is complicated and it does breed security issues, and that is how things are. Complex systems need to mature and have to be hammered down, often continually when faced with constantly changing hardware specifications and extentions.
X's usability has already been compromised by systemd integration. My problem with wayland isn't ill-defined. It is very specifically that it is missing important networking capabilities and it is riddled with freedesktop.org hooks and systemd dependendcies.
You could have just said "I absolutely need network transparency no matter what" and it would have made this conversation easier. No, Wayland intentionally doesn't have network transparency in the same way Xorg does. I will grant you that it can be useful for LAN at your house, but over big networks stuff like VNC performs much better. Of course, this doesn't mean that Wayland doesn't/won't ever support remote desktop. There's some APIs for that at the moment, but they're all still experimental and I haven't seen much beyond demos for this. So you are right that if you absolutely need remote desktop, then Wayland isn't ready for you yet. If you specifically need network transparency in the display protocol (let's be honest, it's debatable whether or not that should be in the display protocol), then you will probably never like Wayland.
You don't see why it might be a problem that any X client can freely talk to one another? It's one of the reasons why keylogging in X is so trivial. Now yes in practice this isn't a big deal because the user has a brain and uses good FOSS from his distro, but it's not a "conjured up" security issue.
I complete disagree with that bolded statement. Things should work, but that's only step one. You need to make sure it's an efficient solution, the design is reasonable, the codebase is readable, etc. Systemd is something that definitely works. I don't think too many people here would consider it good software (I certainly don't at any rate). And I don't do the latter things (unprivileged software bringing down the system or execute javascript in my email).
I'm not sure what you mean by "freedesktop.org hooks," but no wayland doesn't have any dependencies on any other freedesktop projects or systemd. This is just flatout untrue. After all, I am literally using it right now on Artix.
(http://www.mrbrklyn.com/purim_2006/crossfire/dsc00162.jpg)
This is a picture of my son sshing upstairs to the server and running crossfire down to an old system in the kitchen
This is the kids explaining how they do it and how they change desktops at will
http://www.nylxs.com/images/Safir1.mov
http://www.nylxs.com/images/Safir3.mov
THis is me acting like an ass
http://www.nylxs.com/images/safir2.mov
Really? Maybe I am misinformed and all the updates I am reading are misdirecting me. Does wayland need lognind? Can it be started from the commandline?
What does this mean?
udev is not a fredesktop archetecture?
So where are we at now?
You know instead of doing this you might as well give up Linux and use Windows 10 or Tandy Deskmate on freeDos
FWIW - this is not the first time around on this discussion ;)
https://forum.manjaro.org/t/wayland-and-x11/11681/18
https://tech.slashdot.org/story/14/07/17/1455228/xorg-server-116-brings-xwayland-glamor-systemd-integration
derooting X itself, has been a major PIA. I lost socket control and systemd went and rebooted X clients when they crashes (even with killall -9), spinning the system out of control and even without systemd you get stupid stuff like this: crashed xterms:
[ruben@www2 ~]$ xterm
xterm: warning, error event received:
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 104 (X_Bell)
Serial number of failed request: 502
Current serial number in output stream: 503
[ruben@www2 ~]$
It is just so much fun to play with things that have worked for decades that suddenly are broken
and then there is the screwed up cut and paste because everything bypasses the X11 clipboard
No it doesn't. I already linked a wayland window manager that can compile without logind.
Of course. For me, it's literally just "sway" and there you go. The reference compositor that everyone knows, weston, is literally just 'weston-launch.' It's actually even simpler than 'startx' since there's less configuration files you have to worry about.
You have your dependencies backwards. Libinput depends on Wayland (and also eudev/udev). Wayland doesn't depend on libinput or udev/eudev.Libinput is merely an input stack that can be used by Wayland compositors to help handle input devices. There is absolutely nothing about Wayland that says you must use it. You could always write your own thing to handle input devices if you really wanted to, but there's no actual reason to duplicate work. You already use libinput right now since xorg depends on it in Artix (unless you went out of your way to compile it with just xinput or something which I'm not even sure is possible anymore).
Look it's not my fault you irrationally hate everything associated with freedesktop. They're not some evil organization that is out to pollute FOSS. It's just a loose collection of popular FOSS stuff. Do they have some crap software? Of course, don't use them. But don't pretend that the different projects necessarily have anything to do with each other.
Have you even looked at the software (https://www.freedesktop.org/wiki/Software/) they host? The chances of you not using any of them is essentially 0 if you're using linux on a desktop. You don't use cairo? You don't use DRI? You don't use mesa?
If you don't like Wayland because it doesn't support network transparency like Xorg, then that's fine. Don't use it. However, don't spread misinformation about it having secret systemd dependencies or evil freedesktop hooks. That's just not true.
Sidenote: Okay I guess DRI/DRM is freedeskop so there you go you got me there. Better uninstall xorg as well if that dependency is unacceptable to you.
The problem of most of freedesktop software is that it sucks a lot. Honestly, all software sucks (c) but there some programs which suck more or less. Unfortunately, we're forced to use a lot of crap software just to make computer usable.
Hatiing badly thought out and insecure software that is contantly being rewritten is not irrational.