On Sun, Apr 30, 2017 at 21:23 (+0200), deloptes wrote:
Keith Daniels wrote:
My bias is anti systemd, just so you know.-- scant documentation and there has never been a security review of its package.
Meanwhile the situation has improved . There are many things improved including documentation. What I can recommend is the "systemd cheat sheet" which can be found in different flavors around.
Just few examples.
https://wiki.debian.org/systemd/CheatSheet https://gist.github.com/mbodo/8f87c96ce11e91f80fbf6175412a2206
My personal experience is ... after looking into it I used systemd free debian for some time until I was ready to move my system to systemd. It took me few hours ... mainly fixing some custom networking logic (scripts that would execute on certain conditions) and migrating few scripts.
Since than I can not complain. I moved all systems from init to systemd - no issue.
I can just conclude that the main problem is the unwillingness to grow.
I don't know whether that is merely a poorly-thought out idea or a deliberately abrasive obnoxious over-generalization. There is a lot of debate about the merits of systemd, and some people have come to the conclusion (rightly or wrongly) that they would prefer to not use it in their system.
Of course I can understand this - why fixing something again after some 10-15y when it was working flawlessly ...
Are you talking about ("somethign") SysV (or BSD) init scripts? 10-15 years? Perhaps more like 40 years.
but guys this is called evolution - for good or for bad.
So if it is possibly bad, why would we want to evolve in that direction?
I use Slackware, and the guy in charge has made the conscious decision to not use systemd, and it seems like he is unlikely to change that any time soon. There are currently other distros with similar strategies. Do people working on Trinity really want to alienate people who use systemd-free distros? That seems like a bad idea to me, but that is just my opinion.
Jim
zlists@ns.sympatico.ca composed on 2017-05-04 13:24 (UTC-0300):
Do people working on Trinity really want to alienate people who use systemd-free distros?
Of course not, but resources are limited. Someone competent would have to come forward and commit to handle the extra work that supporting multiple init systems entails.
On Thu May 4 2017 09:39:44 Felix Miata wrote:
zlists@ns.sympatico.ca composed on 2017-05-04 13:24 (UTC-0300):
Do people working on Trinity really want to alienate people who use systemd-free distros?
Of course not, but resources are limited. Someone competent would have to come forward and commit to handle the extra work that supporting multiple init systems entails.
It seems extraordinarily unlikely that Tim would make such a mistake but if TDE broke sysvinit support or required systemd we would be unable to continue with TDE, just as we now use Devuan instead of Debian.
--Mike
Mike Bird wrote:
It seems extraordinarily unlikely that Tim would make such a mistake but if TDE broke sysvinit support or required systemd we would be unable to continue with TDE, just as we now use Devuan instead of Debian.
The fact is that TDE does not care much. I switched to systemd completely few months ago with no issues. I had only one script that would run the firewall when in public LAN and I was instructed to put it under /etc/network/if-up.d/. This worked great - about 20min of work to adapt the script and it was over. On the server I have like 10 custom scripts in init.d and all work independent of systemd. On a custom firewall (exotic hardware) I add the boot option init=/lib/sysvinit/init and let systemd install. Works also great!
I really don't understand what is this frustration about systemd. It has good and bad sides, but IMO to the user it is transparent and no one should care. And we should have some trust in the debian team and respect their decisions.
TDE works just great with systemd, the same as without systemd ... so why the discussion?
Back to the original topic. I installed some time ago Stretch and TDE on top of it - just to see if all works. It works great! No issues! I must admit I installed TDE 14.1 (devel), but I think it is not that relevant.
[tdebuildsycoca] Reusing existing tdesycoca. tdebuildsycoca: ERROR: tde-applications.menu not found in (/tmp/0246141687/.config/menus/,/etc/xdg/menus/) [dcopserver] DCOP Cleaning up dead connections.
It looks like there was some problem from before ... no idea what you did.
/opt/trinity/etc/xdg/menus/tde-applications.menu
is the file in place - did you install/update/remove something
regards
On 04/05/2017 19:39, deloptes wrote:
Mike Bird wrote:
It seems extraordinarily unlikely that Tim would make such a mistake but if TDE broke sysvinit support or required systemd we would be unable to continue with TDE, just as we now use Devuan instead of Debian.
The fact is that TDE does not care much. I switched to systemd completely few months ago with no issues. I had only one script that would run the firewall when in public LAN and I was instructed to put it under /etc/network/if-up.d/. This worked great - about 20min of work to adapt the script and it was over. On the server I have like 10 custom scripts in init.d and all work independent of systemd. On a custom firewall (exotic hardware) I add the boot option init=/lib/sysvinit/init and let systemd install. Works also great!
I really don't understand what is this frustration about systemd.
First and foremost, choice. With debian, you no longer have one. There is more too it of course, but I'm done with the flame wars, I've turned to devuan .....
Michael Howard wrote:
First and foremost, choice. With debian, you no longer have one. There is more too it of course, but I'm done with the flame wars, I've turned to devuan .....
sorry for replying to this, not that it is that important, but the argument is a bit funny. What choice did you have before systemd? As if I am missing something.
regards
On 04/05/2017 22:09, deloptes wrote:
Michael Howard wrote:
First and foremost, choice. With debian, you no longer have one. There is more too it of course, but I'm done with the flame wars, I've turned to devuan .....
sorry for replying to this, not that it is that important
Then why reply?
Like I said, done with flame wars, it's all out there if you care to look. Oh, and I'm not sorry for replying.
Michael Howard wrote:
Like I said, done with flame wars, it's all out there if you care to look. Oh, and I'm not sorry for replying.
The question was what choice did you have before systemd?
But I understand you mean the choice of using or not using systemd. I am not advocating for systemd. In fact I do learn through this discussion and your arguments more and more.
regards
Am Donnerstag, 4. Mai 2017 schrieb deloptes:
Mike Bird wrote: I really don't understand what is this frustration about systemd. It has good and bad sides, but IMO to the user it is transparent and no one should care. And we should have some trust in the debian team and respect their decisions.
Trust in debian? I guess you are too young to know ...
Nik
Dr. Nikolaus Klepp wrote:
Trust in debian? I guess you are too young to know ...
what do you mean - I am using it since 2002 - it improved a lot and the philosophy as far as I know it is OK. I am open to learn
regards
On Thu May 4 2017 11:39:56 deloptes wrote:
And we should have some trust in the debian team and respect their decisions.
If Debian had not tried to force users to move to KDE4 before it was even ready a lot of work in spinning off TDE might have been avoided.
There are a heck of a lot of good DDs doing good work and they mostly fly below the radar. And then there are the loud political people who abuse Debian's processes to "force" users to use certain software by making it much harder to use alternatives.
Systemd is bad bad bad design. It deliberately removes choice and is thus bad bad bad for the whole libre software ecosystem. Without choice new and better alternatives cannot evolve within the ecosystem.
And that is why people have had to put in much greater effort - much of which should have been unnecessary - to develop new ecosystems such as TDE and Devuan outside the poisoned old ecosystems.
--Mike
On Thu, May 4, 2017 at 7:13 PM, Mike Bird mgb-trinity@yosemite.net wrote:
On Thu May 4 2017 09:39:44 Felix Miata wrote:
zlists@ns.sympatico.ca composed on 2017-05-04 13:24 (UTC-0300):
Do people working on Trinity really want to alienate people who use systemd-free distros?
Of course not, but resources are limited. Someone competent would have to come forward and commit to handle the extra work that supporting multiple init systems entails.
It seems extraordinarily unlikely that Tim would make such a mistake but if TDE broke sysvinit support or required systemd we would be unable to continue with TDE, just as we now use Devuan instead of Debian.
likewise i would no longer be able to recommend the use of TDE, nor would i be able to install it or maintain it for my clients. i would be forced to go to the drastic measure of setting up a chroot environment to run an older version of TDE, along with a fixed snapshot of an OS, with a view to keeping that chroot environment pretty much forever, and to run all other applications in some abortion-of-a-method (firefox, libreoffice) with up-to-date binaries.
the fact that TDE *HAS NOT* been affected by one of the saddest and most damaging events ever to occur in the history of free software is one of its saving graces.
l.
On Thu, May 4, 2017 at 12:39 (-0400), Felix Miata wrote:
zlists@ns.sympatico.ca composed on 2017-05-04 13:24 (UTC-0300):
Do people working on Trinity really want to alienate people who use systemd-free distros?
Of course not, but resources are limited. Someone competent would have to come forward and commit to handle the extra work that supporting multiple init systems entails.
Sure. And not being familiar with the code base, I will admit to having no idea whether that extra work is large or small.
But given that, presumably, the code to handle SysV/BSD init scripts is already part of Trinity, perhaps it is more an issue of "not deleting code" as opposed to "designing and implementing new code".
Cheers.
zlists@ns.sympatico.ca composed on 2017-05-04 19:09 (UTC-0300):
On Thu, May 4, 2017 at 12:39 (-0400), Felix Miata wrote:
...resources are limited. Someone competent would have to come forward and commit to handle the extra work that supporting multiple init systems entails.
Sure. And not being familiar with the code base, I will admit to having no idea whether that extra work is large or small.
But given that, presumably, the code to handle SysV/BSD init scripts is already part of Trinity, perhaps it is more an issue of "not deleting code" as opposed to "designing and implementing new code".
Changes generally need to be tested whether additions or subtractions, lest unforeseen consequences manifest. Not infrequently I have doubts that code rippers did any testing at all.
Felix Miata wrote:
Changes generally need to be tested whether additions or subtractions, lest unforeseen consequences manifest. Not infrequently I have doubts that code rippers did any testing at all.
I have not heard of an discussion in TDE to drop anything that worked. From what I know and I have seen, and what I like in TDE, is that things are changed/improved to work. As using TDE on daily basis I have never been confronted with something related to systemd. I still do not understand this discussion.
I also do not understand the subject of this thread.
regards
deloptes composed on 2017-05-05 10:22 (UTC+0200):
Felix Miata [the OP] wrote:... I also do not understand the subject of this thread.
The definition of multi-user.target as I remember it is that a display manager, aka login manager or greeter, is not included. Yet, on Stretch, TDM is nevertheless started even though graphical.target is not reached or desired, and multi-user.target is the configured default. The login manager elsewhere than in Stretch is the sole characteristic normally distinguishing multi-user.target from graphical.target.
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
Felix Miata wrote:
Thank you Felix for the explanation
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
If it does something that is not expected, it is obviously not normal. Someone log a bug, add a patch and it is done.
Perhaps no one tested multi user aka no graphical.target ... For example if I install TDE, I expect it to come up with login manager ... why would I still expect a console login, when I have installed TDE?
It looks like a non trivial use case, but still the issue is valid. If I set up "multi-user" it should do "multi-user", so follow up would be - file bug - fix - done.
Just my thoughts on the subject.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, May 5, 2017 at 9:56 AM, deloptes deloptes@gmail.com wrote:
Felix Miata wrote:
Thank you Felix for the explanation
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
If it does something that is not expected, it is obviously not normal. Someone log a bug, add a patch and it is done.
Perhaps no one tested multi user aka no graphical.target ... For example if I install TDE, I expect it to come up with login manager ... why would I still expect a console login, when I have installed TDE?
because something may go wrong with the login manager. filesystem corruption could result, meaning that the login manager completely fails and will not permit a login of any kind (i have actually genuinely had this happen: it turned out to be that /home was not writeable), and you would otherwise need to take the drastic action of rebooting into "init 1" to recover...
BUT...
let's assume that there are mission-critical files still being served up from the machine: other users (over a network) are connected to something on the machine (its printers, whatever doesn't matter) so you CAN'T just reboot it...
i would expect under these circumstances to just be able to press "Ctrl-Alt-F1" and to log in at a text console as root.
if that's *not possible* then it's a severe bug.
l.
Luke Kenneth Casson Leighton wrote:
i would expect under these circumstances to just be able to press "Ctrl-Alt-F1" and to log in at a text console as root.
if that's *not possible* then it's a severe bug.
From the OP I understand it is about starting TDM, when expected is to spawn console only.
I must admit I have never tried it. I either have workstation (TDM expected) or have a server (no UI).
Instead complaining and stiring up dust around systemd, raise a bug so it may be properly investigated and fixed. There might be adjustment needed in some part of tdm.
regards
On Friday 05 of May 2017 10:41:39 Felix Miata wrote:
The definition of multi-user.target as I remember it is that a display manager, aka login manager or greeter, is not included. Yet, on Stretch, TDM is nevertheless started even though graphical.target is not reached or desired, and multi-user.target is the configured default. The login manager elsewhere than in Stretch is the sole characteristic normally distinguishing multi-user.target from graphical.target.
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
Now I've checked that tdm.service is installed in /lib/systemd/system/ and nowhere is explicitly stated whether to be at the level multi-user.target or graphical.target. The level should therefore be as defined for Debian's "display manager".
Cheers
Slávek Banko composed on 2017-05-06 17:39 (UTC+0200):
Felix Miata wrote:
The definition of multi-user.target as I remember it is that a display manager, aka login manager or greeter, is not included. Yet, on Stretch, TDM is nevertheless started even though graphical.target is not reached or desired, and multi-user.target is the configured default. The login manager elsewhere than in Stretch is the sole characteristic normally distinguishing multi-user.target from graphical.target.
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
Now I've checked that tdm.service is installed in /lib/systemd/system/ and nowhere is explicitly stated whether to be at the level multi-user.target or graphical.target. The level should therefore be as defined for Debian's "display manager".
Where does one find or make the definition of 'Debian's "display manager"'?
Why is tdm running in the following conditions on host big31?
# cat /etc/debian_version 9.0 # grep RETT /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" # ll /etc/X11/def* -rw-r--r-- 1 root root 21 May 9 16:32 /etc/X11/default-display-manager # cat /proc/cmdline ro root=LABEL=hcs5stretch net.ifnames=0 ipv6.disable=1 noresume plymouth.enable=0 vga=791 video=1024x768@60 # cat /etc/X11/def* /opt/trinity/bin/tdm # systemctl get-default multi-user.target # systemctl status display-manager tdm.service - Trinity Display Manager Loaded: loaded (/lib/systemd/system/tdm.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:tdm-trinity(1) # systemctl status tdm tdm.service - Trinity Display Manager Loaded: loaded (/lib/systemd/system/tdm.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:tdm-trinity(1) # ps -A | grep dm 528 ? 00:00:00 rpc.idmapd 644 ? 00:00:00 tdm 902 ? 00:00:00 tdm 904 ? 00:00:02 tdm_greet
On Tuesday 09 of May 2017 23:02:10 Felix Miata wrote:
Slávek Banko composed on 2017-05-06 17:39 (UTC+0200):
Felix Miata wrote:
The definition of multi-user.target as I remember it is that a display manager, aka login manager or greeter, is not included. Yet, on Stretch, TDM is nevertheless started even though graphical.target is not reached or desired, and multi-user.target is the configured default. The login manager elsewhere than in Stretch is the sole characteristic normally distinguishing multi-user.target from graphical.target.
So, the subject question is whether this absence of difference between multi-user.target and graphical.target using TDE on Stretch is expected and normal?
Now I've checked that tdm.service is installed in /lib/systemd/system/ and nowhere is explicitly stated whether to be at the level multi-user.target or graphical.target. The level should therefore be as defined for Debian's "display manager".
Where does one find or make the definition of 'Debian's "display manager"'?
Why is tdm running in the following conditions on host big31?
# cat /etc/debian_version 9.0 # grep RETT /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" # ll /etc/X11/def* -rw-r--r-- 1 root root 21 May 9 16:32 /etc/X11/default-display-manager # cat /proc/cmdline ro root=LABEL=hcs5stretch net.ifnames=0 ipv6.disable=1 noresume plymouth.enable=0 vga=791 video=1024x768@60 # cat /etc/X11/def* /opt/trinity/bin/tdm # systemctl get-default multi-user.target # systemctl status display-manager tdm.service - Trinity Display Manager Loaded: loaded (/lib/systemd/system/tdm.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:tdm-trinity(1) # systemctl status tdm tdm.service - Trinity Display Manager Loaded: loaded (/lib/systemd/system/tdm.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:tdm-trinity(1) # ps -A | grep dm 528 ? 00:00:00 rpc.idmapd 644 ? 00:00:00 tdm 902 ? 00:00:00 tdm 904 ? 00:00:02 tdm_greet
I think there may be one more problem - a service for systemd is called 'tdm', while 'classical' init script is called 'tdm-trinity'. I think in your case tdm can be run by a classical init script. This would correspond to the fact that tdm service is 'inactive'.
Maybe it's time to rename 'classical' init script to 'tdm' instead of the current 'tdm-trinity'. Thanks to the earlier renaming of 'kdm' => 'tdm', there is no longer any conflict if the init script is to be briefly named 'tdm'. It is only necessary to test whether this will help :)
Cheers
Slávek Banko composed on 2017-05-10 01:28 (UTC+0100):
I think there may be one more problem - a service for systemd is called 'tdm', while 'classical' init script is called 'tdm-trinity'. I think in your case tdm can be run by a classical init script. This would correspond to the fact that tdm service is 'inactive'.
Maybe it's time to rename 'classical' init script to 'tdm' instead of the current 'tdm-trinity'. Thanks to the earlier renaming of 'kdm' => 'tdm', there is no longer any conflict if the init script is to be briefly named 'tdm'. It is only necessary to test whether this will help :)
I renamed /etc/init.d/tdm-trinity /etc/init.d/tdm, then rebooted several times. This has resulted in expected behavior whether or not 3 or 5 or neither is included on kernel cmdline, and whether graphical.target or multi-user.target is set to systemd default. Now startx can open a TDE session on :0 instead of :1 in Stretch just like in Fedora and openSUSE! :-D
On Wednesday 10 of May 2017 02:24:20 Felix Miata wrote:
Slávek Banko composed on 2017-05-10 01:28 (UTC+0100):
I think there may be one more problem - a service for systemd is called 'tdm', while 'classical' init script is called 'tdm-trinity'. I think in your case tdm can be run by a classical init script. This would correspond to the fact that tdm service is 'inactive'.
Maybe it's time to rename 'classical' init script to 'tdm' instead of the current 'tdm-trinity'. Thanks to the earlier renaming of 'kdm' => 'tdm', there is no longer any conflict if the init script is to be briefly named 'tdm'. It is only necessary to test whether this will help :)
I renamed /etc/init.d/tdm-trinity /etc/init.d/tdm, then rebooted several times. This has resulted in expected behavior whether or not 3 or 5 or neither is included on kernel cmdline, and whether graphical.target or multi-user.target is set to systemd default. Now startx can open a TDE session on :0 instead of :1 in Stretch just like in Fedora and openSUSE! :-D
Thanks for performing the test - renaming was done in tde-packaging git in commit 70d1e404 (master) and 5fc04fc9 (r14.0.x). Updated packages are already available in Preliminary Stable Builds repository.
Cheers
zlists@ns.sympatico.ca wrote:
Are you talking about ("somethign") SysV (or BSD) init scripts? 10-15 years?
10-15y I say roughly, because I think there are not much older systems out there. Or do you use scripts that are 15+y old?
regards
On Thu, May 4, 2017 at 20:19 (+0200), deloptes wrote:
zlists@ns.sympatico.ca wrote:
Are you talking about ("somethign") SysV (or BSD) init scripts? Â 10-15 years?
10-15y I say roughly, because I think there are not much older systems out there. Or do you use scripts that are 15+y old?
I'm getting the idea that you are not thinking through your postings very well, or perhaps not expressing yourself well.
In the part of the message which you deleted, you said > I moved all systems from init to systemd - no issue. > ... > Of course I can understand this - why fixing something again > after some 10-15y when it was working flawlessly ... This seems to make it look like you think that init has only been around for 10 or 15 years. I was pointing out that it has been around for much, much longer.
And you think there are no systems older than 10-15 years? Seriously? Perhaps, as another person commented, you are too young to appreciate the history here.
zlists@ns.sympatico.ca wrote:
This seems to make it look like you think that init has only been around for 10 or 15 years. I was pointing out that it has been around for much, much longer.
And you think there are no systems older than 10-15 years? Seriously? Perhaps, as another person commented, you are too young to appreciate the history here.
my be I am not expressing myself correctly.
On Thu, May 4, 2017 at 5:24 PM, zlists@ns.sympatico.ca wrote:
On Sun, Apr 30, 2017 at 21:23 (+0200), deloptes wrote:
There is a lot of debate about the merits of systemd, and some people have come to the conclusion (rightly or wrongly)
stop. you've just made yourself judge and jury of other people's right to self-determination by adding the qualifying adjectives "rightly or wrongly" to the word "conclusion".
i trust that this was an oversight.
l.
On Fri, May 5, 2017 at 01:10 (+0100), Luke Kenneth Casson Leighton wrote:
On Thu, May 4, 2017 at 5:24 PM, zlists@ns.sympatico.ca wrote:
On Sun, Apr 30, 2017 at 21:23 (+0200), deloptes wrote:
There is a lot of debate about the merits of systemd, and some people have come to the conclusion (rightly or wrongly)
stop.
Too late. I had finished my message by the time you typed that.
you've just made yourself judge and jury of other people's right to self-determination by adding the qualifying adjectives "rightly or wrongly" to the word "conclusion".
i trust that this was an oversight.
No, I think it was a serious misunderstanding of the language I used. In fact, I added "rightly or wrongly" to indicate that I was not expressing any opinion about whether these peoples' various conclusions were justified or not. How you manage to twist that into the idea that I am questioning anyone's self-determination is beyond me.
Not that I am questioning your right to self-determination in making bizarre and unwarranted interpretations of other peoples' writing. Have at it. Fill your boots. Go wild.
-
deloptes -
Dr. Nikolaus Klepp -
Felix Miata -
Luke Kenneth Casson Leighton -
Michael Howard -
Mike Bird -
Slávek Banko -
zlists＠ns.sympatico.ca