- This topic has 43 replies, 11 voices, and was last updated Jun 18-6:44 pm by anti-apXos.
-
Posts
-
anticapitalista
@Dave – turnstile is not essential on antiX.
You can remove it if you wish without any issues occuring.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Robin
I must be extremely dense… Have been looking for the “why” since it was mentioned that turnstile is essential.
Precisely same here.
You can remove it if you wish without any issues occuring.
Thanks for clarifying that. Still, this doesn’t answer the core question raised in this thread a couple of times already. What is this thing actually good for? I have still no clue what all this is about.
The description found in the package is pretty abstract, meaning nothing to me, besides mentioning that turnstile is an extraction of some parts of systemd. But why should antiX want that to have included systemd parts at all, and why by default?
Description: A session/login tracker providing service-manager-agnostic way to manage per-user services Turnstile is a work in progress effort to create a session/login tracker to serve as a fully featured alternative to the logind subproject from systemd, and to provide a neutral API to both our session tracker and to logind itself.What is tracked, for what purpose, and for whom, who can access the collected data (e.g. via active scripting in browsers)? Is this another approach of some sort for fingerprinting?
_________________________
P.S.: Currently working hard on the update of the .desktop translations harvester script to get ready with the needed resource update for antiX 26.1 at transifex. Currently stuck in some quirks with proper handling of diversions for the few .desktop files installed by the package itself, which can’t be treated the same way like all the others, due to the restrictions of dpkg-divert in connection with its –package flag. Otherwise I’d have researched myself more deeply already about this turnstiled thing.- This reply was modified 3 months, 1 week ago by Robin. Reason: P.S.:
Windows is like a submarine. Open a window and serious problems will start.
valera
Thanks for clarifying that. Still, this doesn’t answer the core question raised in this thread a couple of times already. What is this thing actually good for?
What is the main problem with Systemd? This is a complex monolithic code that controls the system and it is very difficult to understand what it turns off, turns on, monitors. In many ways, its functionality is redundant for easy use by the user. That’s where Turnstile comes in, as a simple, modular and straightforward system. All functionality is regulated in /etc/turnstile/ and it is not tied to a single initialization system.
For example, for antiX, it is enough to use Turnstile to run user services, and for MXD, this is a full-fledged replacement for Systemd with sufficient functionality. You are free to choose and regulate its use – it is quite simple.- This reply was modified 3 months, 1 week ago by valera.
olsztyn
For example, for antiX, it is enough to use Turnstile to run user services, and for MXD, this is a full-fledged replacement for Systemd with sufficient functionality.
I am not sure anymore but my understanding was that turnstile on antiX is fully implemented for dinit only. For other inits is a work in progress. Perhaps not accurate statement anymore though…
Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersWhat is the main problem with Systemd?
Hi Valera, From my experience systemd outpowers and extremely slows down any OS running on 32 bit hardware, like on my notebook. And that’s a really stern issue. If now porting all this functionality into a replacement, will this approach not take the same resources?
it is very difficult to understand what it turns off, turns on, monitors.
That’s the next issue. antiX is designed to keep things simple and understandable, not disguising each and everything inside a miraculous black box. So, well, you said turnstiled brings all this (what precisely?) modularised. Question is still: Why should I want to have it at all? Didn’t the systems work before systemd was introduced? This is what needs to be explained to the users.
All functionality
What functionality? This is what me and others here in this thread try to get an answer for, for months, but seems nobody can actually explain what this thing is good for. Besides the fact that it copies systemd components (of which I also have to admit: I still have no clue why I should want to have and use them).
To put all the questions into a nutshell: What advantages brings this turnstiled for antiX ?
Windows is like a submarine. Open a window and serious problems will start.
To put all the questions into a nutshell: What advantages brings this turnstiled for antiX ?
My understanding, perhaps incorrect:
Depending what level of sophistication you want to bring antiX to. If the user wants antiX simple as caan be, just like in the past, then no need or advantages to make it more complex. The user can remove turnstile altogether, as @anticapitalista said. However if the user wants to bring antiX to a level of sophistication to handle user services, as an example, then turnstile brings this capability.
With antiX 26 a decision was made to bring turnstile onboard, which opens these new capabilities, although I am still not sure if only for dinit. In result antiX can be made very simple as in the past or more complex to match systemd in functionality of services.Live antiX Boot Options (Previously posted by Xecure):
http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
Dave
To put all the questions into a nutshell: What advantages brings this turnstiled for antiX ?
Exactly. To add: in comparison with older antiX versions where turnstile / systemd components were not used or thought of.
To state comparisons to user services and continuous relation to systemd mystery components is of no help. Especially considering most people here already deemed overall that systemd components are not needed and have become largely ignorant to systemd components / development.
Personally I have spent alot of time trying to research all these new init setups to weigh the pros/cons of each, the licensing of each, read through the code of the variations needed in the antiX system to make each init work as well as the various additional supporting manager and helper scripts, additional programs (such as turnstile) to similarly review, etc. At the end feeling wow why, to much to review and not enough time…
Thus likely skipping version 26.
Do not have the time for all the various kinds of laundry; checking the old for damage, stains, or replacement and additionally the new for fit. Just feel need to shove it all together in the wash, let it go through the cycle, and see what comes out of the wash in the end. Then determine if I have any clothes to wear
- This reply was modified 3 months, 1 week ago by Dave.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
I have to agree with you, all this is redundant and complicates the system. Then the point of Turnstile is only to run without Systemd. In Mate, LXQT, XFCE, KDE and Gnome – you can’t do without such a manager.
- This reply was modified 3 months, 1 week ago by valera.
- This reply was modified 3 months, 1 week ago by valera.
anti-apXos
It seemed clear enough to me from @ProwlerGr’s responses in this thread that turnstiled has two functions on antix-26:
1) it launches a user-owned instance of your init’s service manager so that you can have user-level services
2) it sets and creates the XDG_RUNTIME_DIR in /run/user that applications use for stowing their necessary runtime files
These are both things that desktop-session also does, though in somewhat different ways, so turnstile is not really necessary. The same could be said of seatd, for instance, though, which manages access to system resources, but can also just be replaced by adding the user to some groups like input. Or I guess it could be said of desktop-session since we can use alternatives (including turnstiled) to do the things it does. This all seems like the opposite of systemd to me. We have tools with very narrow scopes that can easily be replaced by other tools.
I think the usefulness of user-level services managed by the init is kind of undercut by the init diversity concept. User services could in theory provide a simple way for users/developers to manage user daemons with just drop-in scripts, but since each of the different inits requires totally different user-service scripts, it would actually ends up being more complicated to support than other methods that are available. If there was just one init being targeted, it would probably make more sense.
I disabled turnstiled when I first installed antix-26 and it hasn’t made any difference to me that I can see. User services are still not used by any packages that I know of and desktop-session will just set up the XDG_RUNTIME_DIR in /tmp if turnstiled doesn’t set it up in /run. I also disabled seatd, sshd, saned, cupsd, dhcpcd, gpm, cron, smartd, acpid, and bluetoothd, so clearly antix comes with a lot of services enabled by default that are not essential but might nevertheless be useful to some people. turnstiled is just another on that list as far as I see.
- This reply was modified 3 months, 1 week ago by anti-apXos.
"--"
anticapitalX
Thanks @anti-apXos for the clean summary — those two functions you listed (launching a user-owned service-manager instance, and creating XDG_RUNTIME_DIR) are exactly the practical bits I ended up dealing with myself, but from the opposite direction: a build that has neither turnstiled nor desktop-session installed at all.
A bit of context on the setup, since it’s relevant here: I purged slimski entirely, and disabled seatd (couldn’t purge it without losing xorg-server). The graphical session starts with startx directly from tty1, triggered by a script in ‘/etc/dinit.d/boot.d/tty1’, with IceWM as the window manager. No display manager, no desktop-session, no turnstiled.
That’s about as minimal as it gets, and it ran straight into the exact gap @anti-apXos described. With turnstiled gone and desktop-session never in the picture, nothing ever sets ‘XDG_RUNTIME_DIR’. I only noticed because ‘app-select’ crashed outright with an unhandled ‘KeyError’ on that variable, since the script assumes it always exists.
My first fix was a workaround rather than a real solution: a small dinit service to recreate ‘/run/user/1000’ on boot (since ‘/run’ is tmpfs and won’t survive a reboot), plus an export line in ‘~/.bash_profile’. It worked, but it felt like patching around the gap rather than closing it properly.
@Dave’s pointer to the ‘desktop-session-xdg-dirs.sh’ script in the desktop-session-antix repo turned out to be the cleaner answer. I stripped out the ‘echo_variable’, ‘say’ and ‘warn’ calls (which depend on the rest of desktop-session and would fail standalone), saved the result as ‘/usr/local/lib/desktop-session-xdg-dirs.sh’, and source it from ‘~/.xinitrc’ right before ‘exec icewm-session’. That sets all the XDG variables in one consistent place, exactly when the session needs them, instead of splitting the logic between a dinit service and bash_profile.
So from where I sit, this thread’s conclusion matches what I found in practice. Turnstiled is genuinely not essential — @anticapitalista is right that nothing breaks without it — but it is doing real, useful work for anyone who isn’t also running desktop-session. Without either one, ‘XDG_RUNTIME_DIR’ has to be set explicitly by hand, and at least one application (‘app-select’) will hard-fail with an unhandled exception rather than degrading gracefully when it’s missing.
For what it’s worth, none of the other services @anti-apXos mentioned disabling caused me any issues either. Alongside turnstiled, I’m currently running with all of the following turned off:
- seatd
- sshd
- saned
- cupsd
- dhcpcd
- gpm
- cron
- smartd
- acpid
- bluetoothd
The init-diversity approach really does hold up under this kind of stress-testing: each of these pieces is narrow enough in scope that you can pull it out and patch the one specific gap it leaves (in this case, just the runtime dir), rather than losing a whole stack of functionality at once.
Let's accept antiX as it is
Pure and Elegant by its natureFollowing on from my reply above, a question occurred to me that seems worth raising directly in this thread: why do we need user-level service managers at all? Couldn’t we just write plain dinit services — system-level, running as a given user — and skip the whole turnstiled/desktop-session layer?
Having thought it through on my own setup, I think the honest answer is: it depends entirely on how many users and sessions you expect on the box.
For a genuinely single-user, single-session machine — which describes my own install pretty well — you can absolutely skip it. That’s effectively what I already did for ‘XDG_RUNTIME_DIR’: one system-level dinit service running at boot, hardcoding ‘/run/user/1000’, owned by one known user. Nothing about that needs to be session-aware, because there is only ever one session to begin with.
Where it stops working is anywhere the “one session” assumption breaks down:
- Multiple concurrent logins of the same user — a TTY session plus an SSH session at the same time, for example — each conventionally wants its own ‘XDG_RUNTIME_DIR’ scope, D-Bus session bus, and runtime services. A single static dinit service can’t fan out into one instance per active session the way turnstile’s per-login spawning does.
- Multiple different users on the same machine (fast user switching, multiple seats) each need their own runtime dir and their own copy of every service, parameterized by UID. Plain dinit services are static unit files; you’d be hand-writing and maintaining a service file per user account rather than getting that for free.
- Lifecycle tied to login/logout. A system-level dinit service starts at boot and keeps running until something explicitly stops it. Turnstile’s pam_turnstile hook ties the start to “this user just logged in” and the stop to “this user just logged out,” so things like pipewire, wireplumber and dbus actually get torn down when nobody’s using them. A boot-time dinit service has no concept of “logged out” — you’d either run things permanently regardless of session state, or build your own login/logout hooks to start and stop it, which at that point is reinventing turnstile by hand.
- Self-service without root. One real feature of user-level services is that an unprivileged user can drop their own service definitions into their own home directory and manage them without touching anything under ‘/etc’. Plain system dinit services live under root-owned ‘/etc/dinit.d’, so a non-admin user managing their own service set needs sudo for every change — a real loss of separation on any box with more than one person using it.
So what we’d lose by porting everything straight into init services is mostly generality: multi-user support, multi-session correctness, and unprivileged self-management. For a personal, single-user, single-session install like mine, none of that buys anything, so the minimal route — a plain dinit boot service, a manual ‘XDG_RUNTIME_DIR’ export, and a script sourced from ‘~/.xinitrc’ — is a legitimate simplification rather than a hack. It just wouldn’t scale to a shared or multi-seat machine without re-implementing the session-aware parts of turnstile by hand.
That lines up with what @anti-apXos already said about the init-diversity philosophy: narrow, replaceable pieces. Turnstile’s narrow scope is specifically session-tracking and per-session service spawning. If your use case never has more than one session, that scope is empty for you, and dropping it costs nothing.
Let's accept antiX as it is
Pure and Elegant by its natureanticapitalista
@anticapitalX – I’m surprised you can start X with seatd running
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
I have disabled seatd .
but I can’t purge it .
it breaks the system .demo@antix1:~ $ sudo dinitctl status seatd dinitctl: service not loaded. demo@antix1:~ $ sudo dinitctl list [[+] ] boot [{+} ] tty1 (pid: 1573) [{+} ] loginready (has console) [{+} ] mount [ {X}] root-rw [{+} ] mount-all [{+} ] fsck [{+} ] udevd [{+} ] pseudofs [{+} ] udev-settle [{+} ] udev-trigger [{+} ] hwclock [{+} ] populate-run [{+} ] cgroups [{+} ] tmpfs [{+} ] tty2 (pid: 1572) [{+} ] acpid (pid: 1411) [{+} ] binfmt [{+} ] cleanup [{+} ] connmand (pid: 1574) [{+} ] dbus (pid: 1571) [{+} ] hostname [{+} ] kmod-static-nodes [{+} ] modules [{+} ] networking [{+} ] urandom [{+} ] xdg-runtime demo@antix1:~ $ cat ~/.xinitrc exec icewm-session demo@antix1:~ $ cat /etc/dinit.d/boot.d/tty1 type = process #command = /sbin/agetty --noclear --autologin demo tty1 38400 linux command = /sbin/agetty --noclear --autologin demo tty1 38400 linux restart = true depends-on = loginready termsignal = HUP smooth-recovery = true inittab-id = 1 inittab-line = tty1 demo@antix1:~ $linuxfs size 640 Mb and I still feel like many things are odd and wrong in my setup .
Let's accept antiX as it is
Pure and Elegant by its natureslimski starts the X session as root, so seatd isn’t necessary at all for the standard antix setup as far as I see.
If you want to start X as a non-root user, it does still work without seatd, but you don’t have any keyboard or mouse unless you add your user to the input group.
"--"
- You must be logged in to reply to this topic.