Mike Bird wrote: 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

Michael Howard wrote: 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

Michael Howard wrote: 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

Dr. Nikolaus Klepp wrote: 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 at 7:13 PM, Mike Bird <mgb-trinity(a)yosemite.net> wrote: 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.

zlists(a)ns.sympatico.ca composed on 2017-05-04 19:09 (UTC-0300): 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. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

deloptes composed on 2017-05-05 10:22 (UTC+0200): 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? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, May 5, 2017 at 9:56 AM, deloptes <deloptes(a)gmail.com> wrote: 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.

On Friday 05 of May 2017 10:41:39 Felix Miata wrote: 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

On Tuesday 09 of May 2017 23:02:10 Felix Miata wrote: 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

On Wednesday 10 of May 2017 02:24:20 Felix Miata wrote: 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 -- Slávek

On Thu, May 4, 2017 at 20:19 (+0200), deloptes wrote: 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 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.