Hello, I have a Thinkpad carbon X3 2015 model, which I am pretty happy with. As of several days ago, it no longer sleeps when I close the lid with Gnome. The trigger was moving to Brisbane, in Melbourne it was fine. Hasn't come good since moving back to Melbourne however. If I manually type in "sudo systemctl start systemd-suspend" then it goes to sleep fine. So I suspect this isn't the typical issue of suspend not working, it is more like suspend isn't even getting triggered. Looking at /var/log/auth.log I see events being generated by systemd-login for "Lid closed" and "Lid opened" - how do I debug why these aren't getting turned into sleep events? It is possible this problem come about as a result of upgrading from a 4.0 kernel to a 4.1 kernel, however I couldn't get get reproducible results under 4.0. As in if I make a random change to the system, it can start working and after a reboot it stops working. Thanks
On 4/08/2015 5:53 PM, Brian May wrote:
I have a Thinkpad carbon X3 2015 model, which I am pretty happy with.
As of several days ago, it no longer sleeps when I close the lid with Gnome. The trigger was moving to Brisbane, in Melbourne it was fine. Hasn't come good since moving back to Melbourne however.
If I manually type in "sudo systemctl start systemd-suspend" then it goes to sleep fine. So I suspect this isn't the typical issue of suspend not working, it is more like suspend isn't even getting triggered.
Okay, yet another systemd fail ... nothing new, I rally against systemd too as you would surely know. ;-) A.
On Wed, 5 Aug 2015 at 07:28 Andrew McGlashan < andrew.mcglashan@affinityvision.com.au> wrote:
Okay, yet another systemd fail ... nothing new, I rally against systemd too as you would surely know. ;-)
Not convinced this is a systemd failure, the systemd command is what I use to get it to work. I think the command I used is just a wrapper to writes a value to /sys/power/state
On 5/08/2015 12:32 PM, Brian May wrote:
On Wed, 5 Aug 2015 at 07:28 Andrew McGlashan <andrew.mcglashan@affinityvision.com.au <mailto:andrew.mcglashan@affinityvision.com.au>> wrote:
Okay, yet another systemd fail ... nothing new, I rally against systemd too as you would surely know. ;-)
Not convinced this is a systemd failure, the systemd command is what I use to get it to work. I think the command I used is just a wrapper to writes a value to /sys/power/state
I am convinced, systemd want to control everything, including power doesn't it? A.
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I am convinced, systemd want to control everything, including power doesn't it?
Nah, upower wants to control power. PolKit wants to control process permissions. systemd-logind wants to control login and 'seat' access to consoles. D-Bus wants to control chatter among processes. udisks2 wants to control access to storage. pm-utils and HAL want to control suspend/resume. And all of them want to convince you that all the others are essential because they're all part of the Freedesktop.org stack. But they won't hurt you if you don't believe in them. -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com - Om I. Baud McQ! (4x80)
On 5/08/2015 7:32 PM, Rick Moen wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I am convinced, systemd want to control everything, including power doesn't it?
Nah, upower wants to control power.
PolKit wants to control process permissions. systemd-logind wants to control login and 'seat' access to consoles. D-Bus wants to control chatter among processes. udisks2 wants to control access to storage. pm-utils and HAL want to control suspend/resume.
And all of them want to convince you that all the others are essential because they're all part of the Freedesktop.org stack. But they won't hurt you if you don't believe in them.
Fair enough, the whole Lennart package then... same end result. Cheers A.
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Fair enough, the whole Lennart package then... same end result.
For the _whole_ Lennart package, you'd have to also add Avahi and Pulse Audio. ;-> (Seriously, Lennart isn't responsible for the whole Freedesktop.org stack, he just works with others who manage some of the other pieces.)
On Wed, 5 Aug 2015, Rick Moen wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I am convinced, systemd want to control everything, including power doesn't it?
Nah, upower wants to control power.
PolKit wants to control process permissions. systemd-logind wants to control login and 'seat' access to consoles. D-Bus wants to control chatter among processes. udisks2 wants to control access to storage. pm-utils and HAL want to control suspend/resume.
And all of them want to convince you that all the others are essential because they're all part of the Freedesktop.org stack. But they won't hurt you if you don't believe in them.
Won't hurt? Getting a laptop to do any action upon lid close used to be so easy - pop a script in /etc/acpi somewhere. Power removed and want to spin the HD down more aggressively? Trivial! But then some idiots came along, who though gnome was the entire world, and now it's impossible to not get it to stomp on your feet when you want to tell suspend-on-lid-close to fsck right off to where it belongs. -- Tim Connors
BTW: This is an example of the philosophical difference between FreeBSD and Linux. Linux distributions lost the KISS principle. It really hurts to have a server system with a multitude of "to difficult to explain, to difficult to understand, just trust me" services running. It is not reliable and it is not safe because the admin looses the ability to understand what's going on - and the system is never just as complex as necessary. My servers do not need a lid closed, don't scan for wireless, don't wait for a USB stick coming in.. simply said: I do not need event-driven hardware management. They also do not boot five times the day. If I need it, there could be tools to _replace_ parts of it to serve _another_ purpose (e.g. your laptop). Fine. But instead Linux went the way of having tools designed for GUI, reoccurring boots and laptop users now running on every server in this universe. What is the share of desktops running Linux/Gnome? 2 or 3 percent. What is the share of servers running Linux? More than 50 percent in some areas I guess. How many of them need polkit/systemd/dbus/NetworkManager..? None. This is simply not explainable by stupidity anymore.. Who has interest in complex and therefor unsafe Internet servers, embedded systems etc..? Regards Peter On Thu, Aug 6, 2015 at 11:45 AM, Tim Connors <tim.w.connors@gmail.com> wrote:
On Wed, 5 Aug 2015, Rick Moen wrote:
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
I am convinced, systemd want to control everything, including power doesn't it?
Nah, upower wants to control power.
PolKit wants to control process permissions. systemd-logind wants to control login and 'seat' access to consoles. D-Bus wants to control chatter among processes. udisks2 wants to control access to storage. pm-utils and HAL want to control suspend/resume.
And all of them want to convince you that all the others are essential because they're all part of the Freedesktop.org stack. But they won't hurt you if you don't believe in them.
Won't hurt? Getting a laptop to do any action upon lid close used to be so easy - pop a script in /etc/acpi somewhere. Power removed and want to spin the HD down more aggressively? Trivial!
But then some idiots came along, who though gnome was the entire world, and now it's impossible to not get it to stomp on your feet when you want to tell suspend-on-lid-close to fsck right off to where it belongs.
-- Tim Connors _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
What is the share of servers running Linux? More than 50 percent in some areas I guess.
How many of them need polkit/systemd/dbus/NetworkManager..? None.
NetworkManager isn't very useful for servers and hardly any have it installed. There's no dependency issues forcing it to be installed. The fast boot of systemd is good for servers. It's been quite a while since the login system of Linux became more complex (well before systemd became popular).
This is simply not explainable by stupidity anymore..
Who has interest in complex and therefor unsafe Internet servers, embedded systems etc..?
There's a lot of complexity in SysVInit scripts. It's interesting to note some recent work in making them less complex driven by the "lack of complexity" as a selling point for old fashioned init systems. The init situation was a lot simpler before SysVInit was introduced to Linux, strangely there weren't many complaints when SysVInit was introduced. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Thu, 6 Aug 2015, Russell Coker wrote:
On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
What is the share of servers running Linux? More than 50 percent in some areas I guess.
How many of them need polkit/systemd/dbus/NetworkManager..? None.
NetworkManager isn't very useful for servers and hardly any have it installed. There's no dependency issues forcing it to be installed.
Tripwire alerted me to a change to consolekit files on a headless DMZ server this morning. I investigated removing consolekit - dependencies dictated that yum was going to then remove 20 or 30 packages that I really didn't want on DMZ servers, and so I was very happy. But then it wanted to remove emacs too :( Probably some bloody dbus integration - I remember talks about that on the emacs-devel list. OK, true, I really should be using emacs on my local node which then connects through tramp to sudo@root@remote, but I'm lazy.
The fast boot of systemd is good for servers. It's been quite a while since the login system of Linux became more complex (well before systemd became popular).
/etc/rc.d/ complex? Repeatable and reliable, I would say. -- Tim Connors
Under FreeBSD my real "servers" were physical machines - which were started maybe two times a year (after a kernel security issue was patched). They were loading the kernel modules, mounted the ZFS, getty,were running rsyslog and ntpd. That's it. How complex does your init system has to be? Inside were jails - they simply started usually _one_ service. There is no need for any more complexity. For the record,, SysV is not a Linux invention. I never liked it that much but.. FreeBSD has /etc/rc.d scripts, they get enabled by <script_enable> in /etc/rc.conf, and rcorder is ordering them according to dependencies at startup time. For servers actually hard to beat, I think. Nobody says you cannot _replace_ it with something else when you feel the need - all what you need is changing /etc/rc. It's a shell script, after all. Regards Peter On Thu, Aug 6, 2015 at 2:12 PM, Russell Coker <russell@coker.com.au> wrote:
On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
What is the share of servers running Linux? More than 50 percent in some areas I guess.
How many of them need polkit/systemd/dbus/NetworkManager..? None.
NetworkManager isn't very useful for servers and hardly any have it installed. There's no dependency issues forcing it to be installed.
The fast boot of systemd is good for servers. It's been quite a while since the login system of Linux became more complex (well before systemd became popular).
This is simply not explainable by stupidity anymore..
Who has interest in complex and therefor unsafe Internet servers, embedded systems etc..?
There's a lot of complexity in SysVInit scripts. It's interesting to note some recent work in making them less complex driven by the "lack of complexity" as a selling point for old fashioned init systems.
The init situation was a lot simpler before SysVInit was introduced to Linux, strangely there weren't many complaints when SysVInit was introduced.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russel Coker wrote: On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
I probably believed it in 1999 when I was working in a Linux desktop environment. Major technology decisions are _not_ made on technical merits, that is my simple conclusion of decades of observations. Regards Peter On Thu, Aug 6, 2015 at 2:12 PM, Russell Coker <russell@coker.com.au> wrote:
On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
What is the share of servers running Linux? More than 50 percent in some areas I guess.
How many of them need polkit/systemd/dbus/NetworkManager..? None.
NetworkManager isn't very useful for servers and hardly any have it installed. There's no dependency issues forcing it to be installed.
The fast boot of systemd is good for servers. It's been quite a while since the login system of Linux became more complex (well before systemd became popular).
This is simply not explainable by stupidity anymore..
Who has interest in complex and therefor unsafe Internet servers, embedded systems etc..?
There's a lot of complexity in SysVInit scripts. It's interesting to note some recent work in making them less complex driven by the "lack of complexity" as a selling point for old fashioned init systems.
The init situation was a lot simpler before SysVInit was introduced to Linux, strangely there weren't many complaints when SysVInit was introduced.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Russell Coker (russell@coker.com.au):
The fast boot of systemd is good for servers.
The fast boot, deterministic behaviour, absence of dependency hairballs involving peculiar Freedesktop.org desktop software, and ability to debug problems of OpenRC is _terrific_ for servers.
There's a lot of complexity in SysVInit scripts.
Well, that's because it emerged from System V, which was a bureaucratic AT&T nightmare. About the only advantage it had over BSD-style inits was that an edit error in a single service script could (usually) not render the system inoperable as with the BSD rc.inet1 script, etc. What the world needed was something that abandoned baroque AT&T cruft, was capable of fielding asynchronous uevent and hotplug messaging, and at the same time wasn't a monstrous construct from people who think binary logging is a good idea and who've never met a superfluous dependency they didn't like. For example, OpenRC. Which fortunately is very easy to converge systems onto -- and is also portable, transparent, and stable. Touting systemd because it isn't an 'old-fashioned init system' and comparing it only to SysVInit is pretty much the same thing DJB fanboys do when they tout Qmail as better than an 'old-fashioned MTA system' like sendmail. I.e., it's a fake and artificial comparision, comparing only against one antique while ignoring modern, current competitors. For example, OpenRC.
The init situation was a lot simpler before SysVInit was introduced to Linux, strangely there weren't many complaints when SysVInit was introduced.
Actually, there were plenty. The problem was that few reasonable alternatives existed _at that time_. Fortunately, now we have such things as (to pick a few examples somewhat arbitrarily) Epoch, nosh, perp, runit, OpenRC, s6, uselessd -- which is actually a rather diverse collection: Epoch: Single-threaded init system designed for minimal footprint, compatibility and unified configuration. nosh: init scheme, somewhat DJB-ish perp: service manager/supervisor runit: init scheme _with_ service manager/supervisor OpenRC: dependency-based and event-driven init, BSD-ish s6: service manager/supervisor, DJB-ish a la daemontools monit: service manager/supervisor uselessd: truly modular and sanely scoped init forked from systemd v208 (in part to make the point using code about what's wrong with systemd's design, but in part to make lemonade from a lemon) My friend Steve Litt has posted a taxonomy. (http://www.troubleshooters.com/linux/init/features_and_benefits.htm) Like, suppose you don't want your init to toss decisions about whether someone is permitted to carry out an action to PolKit? Suppose you thought socket activation was cute in inetd/xinetd but there's a good reason we don't use it generally elsewhere and only an idiot like Poettering would put it as an init default? Suppose you have no confidence in system software from a desktop coder so dumb he thinks binary logging is a step forward? Suppose you want process supervision only for _selected_ processes and think it's dumb as a default? Suppose you think a cgroups manager is a great idea, but think it's dumb for such complex code to be part of process #1 when it doesn't need to be? You might want a lightweight, debuggable init that suited to task, rather than some code hairball from the author of Pulse Audio. OpenRC on Debian 8.0 Jessie is particularly nice, in my experience.
On Wed, Aug 05, 2015 at 10:31:17PM -0700, Rick Moen wrote:
Touting systemd because it isn't an 'old-fashioned init system' and comparing it only to SysVInit is pretty much the same thing DJB fanboys do when they tout Qmail as better than an 'old-fashioned MTA system' like sendmail. I.e., it's a fake and artificial comparision, comparing only against one antique while ignoring modern, current competitors. For example, OpenRC.
or Postfix. the other problem with this line of argument is that systemd is NOT just an init system, it does lots of other things as well, taking over functions that an init system has no business interfering with. and it's particularly annoying that when critics point this out that the response from systemd-pushers is "but it's a great init system, better than sysvinit". even conceding that point just for the sake of the argument (personally i see nothing wrong with sysvinit and find the systemd scare campaign against shell scripts both offensive and neo-luddite) that does not justify all of the other things that systemd does a half-arsed job of. as you say, if sysvinit really needs replacing, there are other alternatives like openrc that confine themselves to just being an init, without all the other bullshit. craig -- craig sanders <cas@taz.net.au>
Hello Craig, On Thu, 2015-08-06 at 16:45 +1000, Craig Sanders wrote:
On Wed, Aug 05, 2015 at 10:31:17PM -0700, Rick Moen wrote:
Touting systemd because it isn't an 'old-fashioned init system' and comparing it only to SysVInit is pretty much the same thing DJB fanboys do when they tout Qmail as better than an 'old-fashioned MTA system' like sendmail. I.e., it's a fake and artificial comparision, comparing only against one antique while ignoring modern, current competitors. For example, OpenRC.
or Postfix.
the other problem with this line of argument is that systemd is NOT just an init system, it does lots of other things as well, taking over functions that an init system has no business interfering with.
Exactly what I have noted from the discussion, fortunately not yet had the "experience", but that is one reason I no longer touch Microsoft software, if at all possible.
and it's particularly annoying that when critics point this out that the response from systemd-pushers is "but it's a great init system, better than sysvinit".
even conceding that point just for the sake of the argument (personally i see nothing wrong with sysvinit and find the systemd scare campaign against shell scripts both offensive and neo-luddite) that does not justify all of the other things that systemd does a half-arsed job of.
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience. There was a reason for Unix, and all successors, to use text configuration and logging. Binary log files are a excellent way of obfuscating the very information I will need, when I cannot get at software that will decode. Text is readable!
as you say, if sysvinit really needs replacing, there are other alternatives like openrc that confine themselves to just being an init, without all the other bullshit.
I noted that it is possible to put openrc on Debian 8. I shall need to do a bit of research. Some notes from you and/or Rick Moen would be very appreciated.
craig
Regards, Mark Trickett
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger. (Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
I noted that it is possible to put openrc on Debian 8. I shall need to do a bit of research. Some notes from you and/or Rick Moen would be very appreciated.
apt-get install openrc Reboot. apt-get remove --purge --auto-remove systemd Note that said command will remove these Debian packages if they are present: o 5 GNOME packages that directly on systemd: gnome-bluetooth, gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility. (This is essentially the GNOME requirement for systemd-logind for 'seat' login credentials, which has become problematic to satisfy without systemd because the Freedesktop.org coders orphaned ConsoleKit, and ConsoleKit2 isn't yet usable last I heard.) o 10 debian-installer* packages that depend directly on systemd because the Debian 8.0 default installer provides systemd o 1 WindowMaker dock applet for shutting down a machine by clicking a button (wmshutdown). o 5 packages that depend on systemd because they're systemd-related: (live-config-systemd, libpam-systemd, systemd-dbg, systemd-sysv, libpam-systemd). o 1 GNOME-affiliated display manager that requires either libpam-system or consolekit (lightdm). o 6 assorted other packages that require that systemd _or_ something else be present (mate-power-manager, solaar, libguestfs0, sogo, ligthttpd, lxsession). Details omitted here but you can look them up in package metadata. o 2 packages from the core Freedesktop.org stack -- the guys responsible for most of the furious code churn in GNOME -- that depend on libpam-systemd (policykit-1, udisks2). o 1 wireless/Bluetooth network manager from GNOME that depends on libpam-systemd (network-manager). o pcmanfm, daisy-player, and a couple of other obscure apps that require policykit-1 that in turn requires systemd One depending on policykit-1 that is not at all obscure, is a rather infuriating and pointless dependency hairball, and merits rebuilding the package if you need it (hplip). Measures to keep systemd from being installed in the future: echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd If your system uses multiarch (32 and 64bit packages), do this too, to pin the 64bit version of systemd: echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package: echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd Above is from my notes of changeover conducted on a virtual machine, so I'm reasonably confident they're complete and correct. Getting rid of udev/libudev1 and getting any replacement (eudev, mdev, vdev) to work with the latest xserver-xorg packages is an experiment I've not yet undertaken. A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
Written by Rick Moen
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening. All major Linux distributions have systemd now at its core, and I do not see any hope that it becomes easier to run Linux without it. The smartphone segment is more or less monopolised by Google-controlled Androids. So it's not much different than, lets say, OpenSolaris, which was practically controlled by Sun, and with Oracle taking over, game over. Yes, it's not exactly dead but it's a fringe community which works on "the leftovers". Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment. For me, it leaves FreeBSD as the "largest company independent open source operating system" (well, maybe not very good wording but you may get what I mean). I know there are things out there "just for Linux". But for many many things you can use FreeBSD and it works as well, or often better, than Linux does. Not to mention things you can hardly do with the same quality under Linux now. E.g. the current setup where I work now, with VMware ESXi and CentOS, is simply inferior to the way I could manage FreeBSD/ZFS/jails over the last years. Regards Peter On Fri, Aug 7, 2015 at 5:40 AM, Rick Moen <rick@linuxmafia.com> wrote:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
I noted that it is possible to put openrc on Debian 8. I shall need to do a bit of research. Some notes from you and/or Rick Moen would be very appreciated.
apt-get install openrc
Reboot.
apt-get remove --purge --auto-remove systemd
Note that said command will remove these Debian packages if they are present:
o 5 GNOME packages that directly on systemd: gnome-bluetooth, gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility. (This is essentially the GNOME requirement for systemd-logind for 'seat' login credentials, which has become problematic to satisfy without systemd because the Freedesktop.org coders orphaned ConsoleKit, and ConsoleKit2 isn't yet usable last I heard.)
o 10 debian-installer* packages that depend directly on systemd because the Debian 8.0 default installer provides systemd
o 1 WindowMaker dock applet for shutting down a machine by clicking a button (wmshutdown).
o 5 packages that depend on systemd because they're systemd-related: (live-config-systemd, libpam-systemd, systemd-dbg, systemd-sysv, libpam-systemd).
o 1 GNOME-affiliated display manager that requires either libpam-system or consolekit (lightdm).
o 6 assorted other packages that require that systemd _or_ something else be present (mate-power-manager, solaar, libguestfs0, sogo, ligthttpd, lxsession). Details omitted here but you can look them up in package metadata.
o 2 packages from the core Freedesktop.org stack -- the guys responsible for most of the furious code churn in GNOME -- that depend on libpam-systemd (policykit-1, udisks2).
o 1 wireless/Bluetooth network manager from GNOME that depends on libpam-systemd (network-manager).
o pcmanfm, daisy-player, and a couple of other obscure apps that require policykit-1 that in turn requires systemd One depending on policykit-1 that is not at all obscure, is a rather infuriating and pointless dependency hairball, and merits rebuilding the package if you need it (hplip).
Measures to keep systemd from being installed in the future:
echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
If your system uses multiarch (32 and 64bit packages), do this too, to pin the 64bit version of systemd:
echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package:
echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
Above is from my notes of changeover conducted on a virtual machine, so I'm reasonably confident they're complete and correct. Getting rid of udev/libudev1 and getting any replacement (eudev, mdev, vdev) to work with the latest xserver-xorg packages is an experiment I've not yet undertaken.
A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Fri, 7 Aug 2015, Peter Ross wrote:
Written by Rick Moen
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening.
All major Linux distributions have systemd now at its core, and I do not see any hope that it becomes easier to run Linux without it.
The smartphone segment is more or less monopolised by Google-controlled Androids.
So it's not much different than, lets say, OpenSolaris, which was practically controlled by Sun, and with Oracle taking over, game over. Yes, it's not exactly dead but it's a fringe community which works on "the leftovers".
Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment.
For me, it leaves FreeBSD as the "largest company independent open source operating system" (well, maybe not very good wording but you may get what I mean).
I know there are things out there "just for Linux". But for many many things you can use FreeBSD and it works as well, or often better, than Linux does.
I've been shat off with Linux's virtual memory management since at least 2001. A whole bunch of things have started shitting me off more in the past few years. But everytime I try to install kfreebsd or the like, I hit the mundane realities of hardware support and the like. It feels like Linux circa 1998. What do you mean I can only have 1024x768 on my 1920x1200 laptop and it takes a minute to draw an xterm? Blah, time to take up motorcycle mechanic courses. -- Tim Connors
But everytime I try to install kfreebsd or the like, I hit the mundane realities of hardware support and the like. It feels like Linux circa 1998.
Well, I am running FreeBSD servers since 1999 - and only remember one problem with server hardware (a new revision of a Broadcom card on a Dell server a few years ago). The problem was fixed after a few e-mails with the maintainer of the driver. Took probably two or three weeks.
What do you mean I can only have 1024x768 on my 1920x1200 laptop and it takes a minute to draw an xterm?
Well, I do not run laptops often with FreeBSD but the PC-BSD 10 laptop on a Samsung netbook works as expected. Yes, I needed xrand under Fluxbox but that's the same now when I Debian and Fluxbox on another machine. But I am really not an "experienced desktop user" - I always buy $500 hardware for glorified terminal multiplexers. Anyway, I think that's were the problem starts: with the comparison of FreeBSD and Linux on territory which is most unfavorable for it. You may appreciate a real 4WD a bit better when you leave the road for once. Until then it's probably just an ugly bulky car. These days the Poetterings want me to use their Porsche for everything.. Regards Peter On Fri, Aug 7, 2015 at 10:33 AM, Tim Connors <tim.w.connors@gmail.com> wrote:
On Fri, 7 Aug 2015, Peter Ross wrote:
Written by Rick Moen
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening.
All major Linux distributions have systemd now at its core, and I do not see any hope that it becomes easier to run Linux without it.
The smartphone segment is more or less monopolised by Google-controlled Androids.
So it's not much different than, lets say, OpenSolaris, which was practically controlled by Sun, and with Oracle taking over, game over. Yes, it's not exactly dead but it's a fringe community which works on "the leftovers".
Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment.
For me, it leaves FreeBSD as the "largest company independent open source operating system" (well, maybe not very good wording but you may get what I mean).
I know there are things out there "just for Linux". But for many many things you can use FreeBSD and it works as well, or often better, than Linux does.
I've been shat off with Linux's virtual memory management since at least 2001. A whole bunch of things have started shitting me off more in the past few years. But everytime I try to install kfreebsd or the like, I hit the mundane realities of hardware support and the like. It feels like Linux circa 1998. What do you mean I can only have 1024x768 on my 1920x1200 laptop and it takes a minute to draw an xterm?
Blah, time to take up motorcycle mechanic courses.
-- Tim Connors
Quoting Peter Ross (petrosssit@gmail.com):
Well, I am running FreeBSD servers since 1999 - and only remember one problem with server hardware (a new revision of a Broadcom card on a Dell server a few years ago).
With cards based on Broadcom chips, I personally favour immolation therapy. ;-> (I'm geographically blessed with the ability to make rude gestures whenever I pass by the headquarters of Broadcom Corporation. If I'm ever in Bermuda, I'll make time to do likewise for Marvell Technology Group, Ltd. Not quite Wowbagger the Infinitely Prolonged, but it's a start.)
Hello Rick, On Thu, 2015-08-06 at 19:28 -0700, Rick Moen wrote:
Quoting Peter Ross (petrosssit@gmail.com):
Well, I am running FreeBSD servers since 1999 - and only remember one problem with server hardware (a new revision of a Broadcom card on a Dell server a few years ago).
With cards based on Broadcom chips, I personally favour immolation therapy. ;->
Please elucidate why. Broadcom have backed the Raspberry Pi in various ways. I am aware of some bits being proprietary, whch I would prefer were open and documented, but for the price point, I think they did remarkably well. I am aware that they used a relatively cheap existing SOC, with some very good graphics. That also brought in some licenced proprietary material that makes the RPi quite such an attractive item to the children, and to hackers, for example as a Media Center PC running XBMC or similar. I am also aware that the chip supported (S)VGA, and that the latest revisions can connect to and drive a VGA monitor via a daughter board.
(I'm geographically blessed with the ability to make rude gestures whenever I pass by the headquarters of Broadcom Corporation. If I'm ever in Bermuda, I'll make time to do likewise for Marvell Technology Group, Ltd. Not quite Wowbagger the Infinitely Prolonged, but it's a start.)
I am aware that all too many networking chip companies do the chip revision of the week, without distinguishing ID's, and not necessarily compatible at any level. That does not deserve immolation, more that the management who push for that to live a long life, 1,000 years, with spinal cancer, and no pain killers. Regards, Mark Trickett
Quoting Mark Trickett (marktrickett@gmail.com):
Please elucidate why.
Oh, I was just being judgemental and only symbolically bloodthirsty -- just like when I recently went on a guided tour of Boeing Company's Everett and Renton assembly plants wearing, as a semi-private joke for my wife's and my benefit, this t-shirt.[1] Both Broadcom and Marvell have been totally uncooperative with open source driver coders, possibly out of inability to focus on business in at least one of those two companies' cases.[2] Consequently, the open source community must do more than the usual amount of work reverse-engineering new chipsets they introduce. (Fortunately, in most cases, the newer chips turn out to be minor variations on older ones, but then there are always problematic exceptions, too.
Broadcom have backed the Raspberry Pi in various ways.
I indeed hear they have. Might be that an old dog learns new tricks on occasion. Of course, that's mostly their ARM SoC, right? Not their network chips that have been the occasional source of low-level pain for kernel people. But I'll confess in advance that I'm vague on details. [1] Dad was a Pan American World Airways captain until his life ended early on Dec. 26, 1968 courtesy of a defective-from-manufacture Boeing 707. So, Inigo's always been a personal favourite. And, yeah, sorry, morbid humour's been my thing for a long time, too. [2] http://www.theregister.co.uk/2007/07/16/broadcom_ceo_charges/
Sorry, forgot the link.
Oh, I was just being judgemental and only symbolically bloodthirsty -- just like when I recently went on a guided tour of Boeing Company's Everett and Renton assembly plants wearing, as a semi-private joke for my wife's and my benefit, this t-shirt.[1]
http://www.amazon.com/Princess-Bride-Montoya-Heather-T-shirt/dp/B00TII2CJW (One of the Boeing employees working at the Everett assembly plant spotted the shirt and said 'Hey, it's Inigo Montoya!' I brightly replied 'Yes, it really is -- and you don't have six fingers.')
On 8/08/2015 5:41 AM, Rick Moen wrote:
Sorry, forgot the link. http://www.amazon.com/Princess-Bride-Montoya-Heather-T-shirt/dp/B00TII2CJW
A better link, this is much easier to read ;) http://www.thinkgeek.com/product/9f70/ A.
Quoting Peter Ross (petrosssit@gmail.com):
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening.
In the case of Red Hat, Inc. and some others, it's primarily because they wanted a comprehensive cgroups manager for cloud computing, and systemd was there and qualified. I doubt very much that Red Hat cared about practically any other part of systemd's feature set. They don't even care about desktop computing that forms the core of Lennart and his Freedesktop.org friends' obsessions.
All major Linux distributions have systemd now at its core...
Well, I'm sorry, but I have to take issue with your basic assumption that an init is at the core of a Linux distribution. (systemd's octopus-like feature set does aspire to be a great deal more than an init, but let's talk about init functionality for the time being for simplicity's sake, and also because those other aspiring bits of scope-creep are _not_ widely implemented by distros.) If you tell a Unix user his/her preference of init is about to be banned by law, he/she will grumble a bit, make new arrangements to stop/start about a dozen startup processes and system daemons, and that matter's done. Other than that, any PID1 process capable of fork-exec to start new processes and adopting orphan processes is a fungible replacement. Certainly, the PID 1 process is _important_ to a system, but choice of init per se is significant only to those dozen-per-system system services, and changing from one to another is not at all difficult, just slightly annoying.
...and I do not see any hope that it becomes easier to run Linux without it.
To the contrary, in my recent experience, it's trivial to run Linux without it -- on Debian 8.0 Jessie. Just 'apt-get install openrc' and a reboot changes the system over. Removing the systemd package thereafter is a problem on Debian Jessie really only for users of GNOME and NetworkManager, to whom I would say 'Don't Do That, Then.' I haven't tried removing the brain damage from RHEL7/CentOS7, let alone recent Fedora. I wouldn't be least surprised if that's more difficult.
The smartphone segment is more or less monopolised by Google-controlled Androids.
Which, by the way, defaults to a custom Google-written init. It comprises three programs: init, ueventd, and watchdogd (all of which hook into the basename of the argv[0] of the init program, meaning that the latter two are usually accessed as symlinks to init).
So it's not much different than, lets say, OpenSolaris, which was practically controlled by Sun, and with Oracle taking over, game over. Yes, it's not exactly dead but it's a fringe community which works on "the leftovers".
OpenSolaris's SMF is actually freely usable by other Unixen, but it's so dreadful and peculiar that nobody else wants to. The same is true of Apple Darwin's / OS X's launchd. (I once tried to figure out how to get OS X to autostart Unbound as a network service on a laptop, in order to have a local recursive nameserver. You quickly get lost in a horrid mess of underdocumented XML undergrowth. And, of course, the Macintoy user community is useless for that, because their attitude is 'If we'd been intended to have local recursive nameservers, the Church of Steve would have issued them.')
For me, it leaves FreeBSD as the "largest company independent open source operating system" (well, maybe not very good wording but you may get what I mean).
You're forgetting the many Linux distros where something other than systemd can be used with only trivial effort even if it's default upon installation (such as Debian 8.0 Jessie), and others that pointedly avoid it out of distaste: Gentoo/Funtoo, Manjaro, Slackware, Zenwalk, SourceMage, Sorceror Linux, Salix, Vector Linux, etc. Personally, I'd rather stick with Debian, where, as mentioned, eschewing systemd continues to be trivially easy (provided you're not enamoured of GNOME or NetworkManager, in which case you'll have the same big problem on Debian or anywhere else). One of my friends encountered problems on the new-ish OpenSUSE release that he blamed on systemd. He threw a fit in numerous online screeds, then blew his system away and installed Manjaro, which he says he's very happy with. I suspect he massively overreacted, but have not kept up on OpenSUSE to say for certain.
But for many many things you can use FreeBSD and it works as well, or often better, than Linux does.
I was a FreeBSD guy before I started using Linux in 1993, and I was a 386BSD guy before that, so you don't need to tell _me_ it's a fine and usable system. I already know that. (I do wish you luck with breadth and recentness of hardware support. You may need it.)
E.g. the current setup where I work now, with VMware ESXi and CentOS, is simply inferior to the way I could manage FreeBSD/ZFS/jails over the last years.
Yeah, FreeBSD jails are an excellent thing. Linux could get there with a good cgroups manager that doesn't insist it needs to be PID 1 and doesn't aspire to take over the world.
On Fri, 7 Aug 2015 10:13:20 AM Peter Ross wrote:
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening.
Sinister? LOL
Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment.
Too disruptive for open-minded? Do we need censorship to protect us?
E.g. the current setup where I work now, with VMware ESXi and CentOS, is simply inferior to the way I could manage FreeBSD/ZFS/jails over the last years.
If FreeBSD works better for you then why don't you just use it? Why don't you run a training session for other LUV members? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Too disruptive for open-minded? Do we need censorship to protect us?
I cannot follow you. Maybe my wording let me down. I was not talking about censorship at all. The beauty (and longevity) of Unix is its modular approach with clearly defined APIs. Systemd is the oppposite. A quite central project, an init, which practically unpredictable development direction, which makes it more and more difficult to replace it by something else. I can easily replace Linux with a Windows desktop. It's booting pretty fast and it logs so you can read it with an Event viewer. And you have a registry which is faster to read then configuration text files. If you want Unix utilities, install CygWin on it.It's not great but.. well, you have to make allowances to have such a beautiful init process which does nearly everything the developers could think of. Occasionally it fails to boot or crashes and nobody understands why .. but it is really booting fast. (</Irony>.. just in case you missed it.
If FreeBSD works better for you then why don't you just use it?
For the same reason I am writing this on a Windows computer.
Why don't you run a training session for other LUV members?
I suggested to prepare a demonstration of its capabilities in server automation. I am afraid I am not a very good source of wisdom if it comes to 'FreeBSD on the laptop'. As I tried to explain, it is as presenting a 4WD and demonstrating its capabilities as a racing car.. It is not a good racing car and I am not a good Formula 1 driver. I spent many hours to discourage friends and acquaintances to ask me how to fix and configure their (often Windows) laptop/tablet/smartphone;-) Regards Peter On Fri, Aug 7, 2015 at 2:51 PM, Russell Coker <russell@coker.com.au> wrote:
On Fri, 7 Aug 2015 10:13:20 AM Peter Ross wrote:
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening.
Sinister? LOL
Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment.
Too disruptive for open-minded? Do we need censorship to protect us?
E.g. the current setup where I work now, with VMware ESXi and CentOS, is simply inferior to the way I could manage FreeBSD/ZFS/jails over the last years.
If FreeBSD works better for you then why don't you just use it? Why don't you run a training session for other LUV members?
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Peter Ross (petrosssit@gmail.com):
The beauty (and longevity) of Unix is its modular approach with clearly defined APIs.
Efforts to have this discussion tend to be doomed in advance because people mean various things when they use the word 'modular' (no kidding). See: http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ It's good to review that page before launching arguments on this matter. But, that having been said, your point is an excellent one. If I need to replace my MTA with a different implementation, my sshd with a different one, my command shell with a different one, my choice of awk, my choice of grep, my choice of window manager, my choice of httpd, my choice of ftpd, I can do so without limitation because of clean, well-defined, modest, non-tangled programming interfaces that face towards other code. Poetteringware has over the years shown an increasing tendency to ignore and eschew that virtue, and systemd does so with a vengeance. And I, for one, intend to laugh heartily whenever I hear that there's a problem with some systemd module that cannot be avoided by switching to a compatible replacement because none exist. -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com - Om I. Baud McQ! (4x80)
On Fri, 7 Aug 2015 04:14:57 PM Rick Moen wrote:
But, that having been said, your point is an excellent one. If I need to replace my MTA with a different implementation, my sshd with a different one, my command shell with a different one, my choice of awk,
It's been a long time since there were multiple choices for sshd. MTAs vary in support for Milters and the various obscure command line options for the sendmail program. If all you want from your MTA is basic /var/mail or procmail local delivery for a single domain then you can switch them fairly easily. If you need more than that then it becomes very difficult. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Russell Coker (russell@coker.com.au):
It's been a long time since there were multiple choices for sshd.
{chuckle} Through rotten luck, you made that claim to the person who maintains the master list for the Internet of SSH software for all platforms.[1] I recommend Dropbear to your attention particularly. http://linuxmafia.com/ssh/unix.html
MTAs vary in support for Milters and the various obscure command line options for the sendmail program.
Hey, man, I remember milters! I remember sendmail, even. Man, that'd be nostalgic if it hadn't been so awful. If I were forced to pretend it's still 1985, I could even run it the way I did for a decade or so. You assertion is correct but irrelevant to the point. Being a senior system administrator, I can reimplement what I do in any of exim4, postfix, Courier-MTA, or several proprietary MTAs for *ix in any of the others in about an hour or two.
If you need more than that then it becomes very difficult.
No, I do not find that to be the case. However, effective antispam is difficult (and necessary) on any MTA. [1] Honestly, that catalogue has become increasingly pointless, but I was motivated to create its original version by hearing the stunning claim in the early 2000s on a University of California at Santa Cruz Linux mailing list that it was absolutely necessary to continue using unencrypted telnet for remote logins around the university network because no ssh implementation existed for OpenVMS. Rather than respond as expected, that it's ridiculous to compromise everyone's security for an obsolete and insignificant operating system, I researched the factual claim and found that there were actually _multiple_ implementations for OpenVMS: http://linuxmafia.com/ssh/openvms.html
MTAs vary in support for Milters and the various obscure command line options for the sendmail program. If all you want from your MTA is basic /var/mail or procmail local delivery for a single domain then you can switch them fairly easily. If you need more than that then it becomes very difficult.
I can install SSMTP for a server with basic needs and it does not break the GUI desktop. For the sinister part: The threat of surveillance is not a made up fantasy. Snowden sits in Russia for a reason and Assange is stuck in London as well. The work is done on two fronts, through law (make it legal that all citizen are suspects and do not deserve privacy) and introduction of unsafe software. If open source software is a problem, fork it (until it talks to Google) and obfuscate it until it is impossible to scrutinize. Things never happen without a reason and not out of pure malice or stupidity. It's always worth asking who benefits. Regards Peter On Fri, Aug 7, 2015 at 4:55 PM, Russell Coker <russell@coker.com.au> wrote:
On Fri, 7 Aug 2015 04:14:57 PM Rick Moen wrote:
But, that having been said, your point is an excellent one. If I need to replace my MTA with a different implementation, my sshd with a different one, my command shell with a different one, my choice of awk,
It's been a long time since there were multiple choices for sshd.
MTAs vary in support for Milters and the various obscure command line options for the sendmail program. If all you want from your MTA is basic /var/mail or procmail local delivery for a single domain then you can switch them fairly easily. If you need more than that then it becomes very difficult.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Sat, 8 Aug 2015 09:41:44 AM Peter Ross wrote:
For the sinister part: The threat of surveillance is not a made up fantasy. Snowden sits in Russia for a reason and Assange is stuck in London as well.
The work is done on two fronts, through law (make it legal that all citizen are suspects and do not deserve privacy) and introduction of unsafe software.
Time for a reality check. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 8/08/2015 1:01 PM, Russell Coker wrote:
On Sat, 8 Aug 2015 09:41:44 AM Peter Ross wrote:
For the sinister part: The threat of surveillance is not a made up fantasy. Snowden sits in Russia for a reason and Assange is stuck in London as well.
Time for a reality check.
Yes, this above is very true, that's a reality check in itself! A.
Reality: - Apple products, Android systems and Microsoft systems are highly insecure devices if you take your privacy seriously - The spying on all electronic data transfers is happening - The majority of communications go through a few hands which are constantly subjected of surveillance But instead of being concerned we happily invite all these cool devices in our daily life which makes us the best-tracked animal species on Earth. It's all for your own good my little pigeons.. Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions. Okay, half time is over, back to watch the pigeons. Regards Peter On Sat, Aug 8, 2015 at 1:01 PM, Russell Coker <russell@coker.com.au> wrote:
On Sat, 8 Aug 2015 09:41:44 AM Peter Ross wrote:
For the sinister part: The threat of surveillance is not a made up fantasy. Snowden sits in Russia for a reason and Assange is stuck in London as well.
The work is done on two fronts, through law (make it legal that all citizen are suspects and do not deserve privacy) and introduction of unsafe software.
Time for a reality check.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Peter Ross (petrosssit@gmail.com):
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights. Marauding three-letter agencies need to be kicked out, period. We of the open source community _should_ be responding to the Snowden challenge by caution, careful scrutiny, and paring down of software complexity -- particularly on server systems, with or without distro help. For that reason alone, among other things, inits prone to make black-box queries to weird and reliable desktop software (e.g., PolKit) to decide on what actions are permitted on the host, are plainly unacceptable as antithetical to deterministic system operation. -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com -- Om I. Baud McQ! (4x80) https://thc.org/root/phun/unmaintain.html
On 8/8/15, Rick Moen <rick@linuxmafia.com> wrote:
Quoting Peter Ross (petrosssit@gmail.com):
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights.
Marauding three-letter agencies need to be kicked out, period. We of the open source community _should_ be responding to the Snowden challenge by caution, careful scrutiny, and paring down of software complexity -- particularly on server systems, with or without distro help. For that reason alone, among other things, inits prone to make black-box queries to weird and reliable desktop software (e.g., PolKit) to decide on what actions are permitted on the host, are plainly unacceptable as antithetical to deterministic system operation.
Thanks. I think you stated clearly what I think and what I hope for. An apology to the original poster for sidetracking. Unfortunately I am not the right person to help with the closing lid. Regards Peter
On Sat, 8 Aug 2015 05:14:21 PM Rick Moen wrote:
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights.
What Snowden showed us is that too many people have been too complacent about the political process. Politics matters and the big 2 parties (in the US, here, and other places) don't offer the answers. The "lesser of 2 evils" will still support spying. The Snowden revelations have included little about OS level compromise and a lot about compromise of hardware that the vast majority of Linux users (including me) don't have the skill to oppose. Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init. As much as people like to complain about systemd being supposedly bloated it's a tiny fraction of the size of any desktop environment and has much less interaction with the outside world. A hostile party who compromises your MUA or web browser (both of which routinely and predictably process data from potentially hostile sources on the Internet) can probably do all the damage that they want to do to your system without root access. If a hostile party wants to gain root access to your PC what they will probably do is compromise your MUA or web browser and then try a local root exploit. The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Spying ... as a topic? It's a far greater problem than just that. On 9/08/2015 3:32 PM, Russell Coker wrote:
On Sat, 8 Aug 2015 05:14:21 PM Rick Moen wrote:
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights.
It is not just about infrastructure; it is far larger than that. Something as ordinary as a USB device (or cable) or a monitor cable can be a problem. And inside your hardware, do you know what each and every device is doing? Inside your Intel CPU ... are you so sure that the binary blob doesn't add more insecurities than it might fix? That hugely complicated i7 or lesser CPU ... it's random number generator suspect? What else? This is massive. You can't trust Cisco, even if it isn't entirely their fault. You can't trust Juniper, again even if it isn't their fault. You can't trust Lenovo and this is THEIR own fault. I'm sure that this is just the tip of the iceberg though. It's hard to trust Google, Apple or Microsoft -- all of which has strong US presence and even with their outward rants that they will stand up to the government; well some of the actions have proved otherwise, they are too supportive of the government. Heck, even MS gives NSA exploit details before they are patched anywhere. Today, it's gotten to the point where you can't trust hardware, you can't trust software, you can't trust Google, Apple or Microsoft; and that's just for starters. Now, when you get to the Linux kernel.... is it perhaps trying to do too many things for too many situations such that it isn't modular enough, it is super huge and won't run on some hardware now in standard forms, contains many binary blobs (even as a last resort), is so bloated that is is another openssl or bind bucket of huge code that is at least somewhat suspect at best; you are only as good as your weakest link after all. The code base of systemd may be small, but the impact is huge and it's interrelation to kernels and other packages is far too great.
What Snowden showed us is that too many people have been too complacent about the political process. Politics matters and the big 2 parties (in the US, here, and other places) don't offer the answers. The "lesser of 2 evils" will still support spying.
Don't forget that the Snowden revelations were over 2 years ago, that's an awful long time in IT terms; chances are that things are far more invasive of privacy today, even with the relevations. Politics; heck even the radio gives bias all the time, as do the media. The level of Abbott cheer squadism has been at extreme levels. The ordinary person that doesn't pay attention is bound to form views that are often presented with a very tarred brush of bias. Ummm, metadata -- the Labor opposition was /tricked/ in to the legislatino that gave law enforcement access to metadata; a loophole that the LNP engineered in allowed them to reclassify border security as "law enforcement", thus giving them access. Potentially changes to the Australian Constitution are going to provide similar "loopholes" to allow governments to over reach even more in to our private lives. This is why it is so dangerous to support ANY changes to the Australian Constitution; not for Aboriginal recognition, not for local governance issues, not for ANYTHING.
The Snowden revelations have included little about OS level compromise and a lot about compromise of hardware that the vast majority of Linux users (including me) don't have the skill to oppose.
It has revealed far too much on the software side of things; ssl compromise as just one area. Skill and resource to attack some implement ions of encryption; and also outright poisoning of default protocols (thanks RSA [IN]security company!).
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init. As much as people like to complain about systemd being supposedly bloated it's a tiny fraction of the size of any desktop environment and has much less interaction with the outside world. A hostile party who compromises your MUA or web browser (both of which routinely and predictably process data from potentially hostile sources on the Internet) can probably do all the damage that they want to do to your system without root access.
NO, I think the vast majority of Linux systems are Linux SERVERS (not desktops) and servers having no need for a lot of extra cruft and increased security risk or interference in handling system admin tasks. Such servers tend to have very few users have real interaction with the underlying OS; perhaps thousands or more interacting with services provided by the server, but no need for anything like systemd in the life of a Linux server on the whole. Actually I think that the systemd movement is one to /try/ to advance the idea of "Linux Desktop" for the masses as all other attempts have completely failed to date. To that end, perhaps there is a case for a systemd infected environment to become the desktop environment for the masses and to leave the majority of Linux usage clean from systemd for real server work. Given that Windows is going down the same track as Apple OS X to some extend and also Google's ecosystems; it is now more than ever before that we need more secured systems with [hopefully] less complexity and therefore less risk for end user privacy as well as security. Windows 10 with the default settings is a privacy nightmare -- it might just suit a user that uses a PC 100% for business tasks... but it might still put them at much greater risk just the same; if you are a private person, setting up Windows 10 with the /best/ settings is still going to be a risk, particularly if you are a person whom doesn't understand the ramifications of each setting that can effect you adversely and how it can do so. For those that love "Google Now" and/or "Siri", then "Cortana" on Windows 10 is going to be a god send; but for those that abhor such invasions of privacy and don't need such "interferences" and overbearance in to our private lives ... well this is just another nightmare. Oh and Win10 on Xbox with Kinect always watching, always listening. Amazon world with their "Echo" system too. Security cameras everywhere, facial recognition everywhere. Heck I've even seen a demonstration of an app on an iPad that can simply look at you and determine your heart rate and breathing patterns! The technology is well and truly there, 1984 is well past, but it is HERE right now today and it is only getting more and more invasive in to our private lives. Is there no area of modern life that we can avoid such high levels of big brother? We need personal security, we need air-gapped computers -- but even then they are often subject to other interferences and spying due to the radio signals that they are able to listen to and naturally emit.
If a hostile party wants to gain root access to your PC what they will probably do is compromise your MUA or web browser and then try a local root exploit. The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
Yes, again the Linux kernel is so bloated these days that it, in itself, presents a huge risk; much more that should be reasonable. Browsers... well, sure they are an easy target, so is Adobe (any product it seems, but particularly Flash). All the tracking with websites too, I hate web developers whom /have/ to bog down websites with scripts from everywhere to track every user of the website, let alone other scripts for "prettiness" or other reasons. Email, run your own server -- heck, we've been hit with bash, openssl, bind and loads of other problems ... and that is just in the *nix world. What's worse, there is every chance that more serious vulnerabilities are in the wild that may never come to light. So, here's a start [1] for /some/ privacy, it's a good start, but it isn't going to help with so many systems in place [many completely outside the control of our own systems] that we cannot even have ANY right or ability to avoid in normal day to day life. Running Tails isn't going to help as much as I would like either; there are always critical updates which invalidate all previously considered safe versions. What's more, some Tails settings are made to make it easier for the average Joe at the expense of security. Do we all wear Guy Fawkes masks? Note that that won't help much as there are other ways to get the "signature" of a person via electrical, electronic and other surveillance measures that don't rely on having to "see" a face. Hitler would have a ball with today's tech ... and how well the Kremlin will be doing now? [1] https://privacytools.io "Privacy? I don't have anything to hide." Glenn Greenwald: Why privacy matters Over the last 16 months, as I've debated this issue around the world, every single time somebody has said to me, "I don't really worry about invasions of privacy because I don't have anything to hide." I always say the same thing to them. I get out a pen, I write down my email address. I say, "Here's my email address. What I want you to do when you get home is email me the passwords to all of your email accounts, not just the nice, respectable work one in your name, but all of them, because I want to be able to just troll through what it is you're doing online, read what I want to read and publish whatever I find interesting. After all, if you're not a bad person, if you're doing nothing wrong, you should have nothing to hide." Not a single person has taken me up on that offer. Glenn Greenwald in Why privacy matters - TED Talk A. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXHETMACgkQqBZry7fv4vvg1gD/VExuGnqPWc1fwL0E120MZ/Ms fWGTwJhuCJhwwGMtxLIA/jEPea7VhCcq6oz0YedaL9U/WHAS72RLU1wMccf7+nPf =46ht -----END PGP SIGNATURE-----
Quoting Russell Coker (russell@coker.com.au): [a great deal of energetically missing the point, snipped]
The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
The security problem primarily raised by systemd has very little to do with the init or its ancillary and unneccessary daemons (hostnamed, timedated, localed, logind, etc.) and utilities and a great deal more to deal with its ridiculously bloated _external_ dependencies, e.g., routing all process privilege decisions through PolKit, one of the several badly engineered, ever-changing[1] bits of Freedesktop.org codebases to which systemd ties your system operation -- pointlessly and unecessarily, as the creator of the uselessd fork (abstracted, cleaned up, and properly modularised from systemd 208) pointed out by example. The feature creep and intrusive functionality of systemd itself is annoying and a sufficient reason to look elsewhere, but is not security related as such. Anyway, with reasonable luck, it'll have about as long an ascendency as HALd and devfsd, as it's certainly about as popular. [1] http://www.jwz.org/doc/cadt.html -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com -- Om I. Baud McQ! (4x80) https://thc.org/root/phun/unmaintain.html
Anyway, with reasonable luck, it'll have about as long an ascendency as HALd and devfsd, as it's certainly about as popular.
Which probably proves the point that it is all quite half-backed. There are a few groups more competing with ideas which worked for them, and one wins. And after a while the house of cards falls apart, and then we start again. Instead of interested and experienced people sit together, figure out what is needed, have a look around how others make it work, come up with a good design and then start implementing. systemd is the clear result of a people and ideas excluding work style instead of inclusive cooperation.. It's "work for me and I do not care about your concerns". Gnome, btw, was not a Linux-only desktop.. I had it working on Solaris desktops more than 10 years ago. FreeBSD was going from a one file /etc/rc to /etc/rc.d and rcorder - because the developers saw the limitations, saw SysV init and took the best from it without being stuck with static /etc/rc?.d/S?? numbering. It also went from static /dev to devfs - but only once, and it looks sensible, and there is /etc/devfs.rules (and /etc/defaults/devs.rules to look for. That's it - and it seems to work (as long as you are not dealing with Gnome) Regards Peter On Mon, Aug 10, 2015 at 4:01 AM, Rick Moen <rick@linuxmafia.com> wrote:
Quoting Russell Coker (russell@coker.com.au):
[a great deal of energetically missing the point, snipped]
The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
The security problem primarily raised by systemd has very little to do with the init or its ancillary and unneccessary daemons (hostnamed, timedated, localed, logind, etc.) and utilities and a great deal more to deal with its ridiculously bloated _external_ dependencies, e.g., routing all process privilege decisions through PolKit, one of the several badly engineered, ever-changing[1] bits of Freedesktop.org codebases to which systemd ties your system operation -- pointlessly and unecessarily, as the creator of the uselessd fork (abstracted, cleaned up, and properly modularised from systemd 208) pointed out by example.
The feature creep and intrusive functionality of systemd itself is annoying and a sufficient reason to look elsewhere, but is not security related as such.
Anyway, with reasonable luck, it'll have about as long an ascendency as HALd and devfsd, as it's certainly about as popular.
[1] http://www.jwz.org/doc/cadt.html
-- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com -- Om I. Baud McQ! (4x80) https://thc.org/root/phun/unmaintain.html
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Mon, 10 Aug 2015 04:01:45 AM Rick Moen wrote:
[a great deal of energetically missing the point, snipped]
No I'm just making a point that you want to ignore.
The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
The security problem primarily raised by systemd has very little to do with the init or its ancillary and unneccessary daemons (hostnamed,
Which is still a minor issue compared to web browsers, MUAs, and other programs which directly and predictably accept data from potentially hostile sources. On Mon, 10 Aug 2015 07:44:29 AM Peter Ross wrote:
I find your argumentation quite weird.. "even if there is an issue, there are others in the system". With your background, it is certainly astonishing.
If there is a problem with a flimsy door lock it does not matter whether the windows are secured by metal bar. The burglar looks for weak spots.
Where the flimsy door lock is your typical web browser or MUA and systemd is a window that has bars that aren't as thick as you like. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Russell Coker (russell@coker.com.au):
On Mon, 10 Aug 2015 04:01:45 AM Rick Moen wrote:
[a great deal of energetically missing the point, snipped]
No I'm just making a point that you want to ignore.
In that case, you were furiously attempting to refute an allegation nobody made, while purporting to respond to my posting, in a manner indistinguishable from either completely missing my point or deliberately attempting to sidestep it while pretending to not have changed the subject. Let's pretend (as you do here) as if I'd been talking about the and its ancillary and unneccessary daemons (hostnamed, timedated, localed, logind, etc.) and utilities -- which I was not -- just for the sake of discussion, and proceed from there to your change of subject (which I infer probably means you lack the background to discuss what I was _actually_ talking about):
The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
The security problem primarily raised by systemd has very little to do with the init or its ancillary and unneccessary daemons (hostnamed,
Which is still a minor issue compared to web browsers, MUAs, and other programs which directly and predictably accept data from potentially hostile sources.
I'm willing to wager AUS $100 about your inability to compromise root on either my Linux server (which runs mutt for me) via compromise of my MUA or my copy of one-line Iceweasel on my Linux workstation, which you would prove by revealing the contents of an ASCII file in /root called 'secret' . I would place my workstation directly on completely unfirewalled IP for the duration of this wager. If you accept this wager in principle, we would then set up a 7 day period for your planned attack and root exploit of either host. You would be required to reveal in detail your application exploit and excalation path to root authority. I have taken no particular security measures and would not do so for the duration of the wager. If you fail, I would expect your immediate tendering of AUS $100. If you succeed, the reverse payment. Hint: Your much bigger problem than the theoretical ability to send Internet-facing application software malformed input, the very non-impressive, non-threatening history of which on Linux I discuss in part on my personal FAQ pages concerning malware and Linux security, is the escalation path. -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com -- Om I. Baud McQ! (4x80) https://thc.org/root/phun/unmaintain.html
On Wed, 12 Aug 2015 12:50:41 PM Rick Moen wrote:
attack and root exploit of either host. You would be required to reveal in detail your application exploit and excalation path to root authority. I have taken no particular security measures and would not do so for the duration of the wager. If you fail, I would expect your immediate tendering of AUS $100. If you succeed, the reverse payment.
Why not have a $100 bet about your ability to perform the type of compromise that you think is the big problem? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Quoting Russell Coker (russell@coker.com.au):
Why not have a $100 bet about your ability to perform the type of compromise that you think is the big problem?
Was it you or some _other_ Russell Coker who claimed that the issue I actually _did_ describe -- which you then misrepresented -- was a 'minor issue compared to web browsers, MUAs, and other programs which directly and predictably accept data from potentially hostile sources'? Because, I call bollocks, sir. And I gather that you refuse to put your money where your mouth is. Now, as to _a_ security problems caused by calls from systemd to other badly written Freedesktop.org software, I can give you a particular type of example immediately, as it is well known, albeit it is not a root compromise or anything quite like that: My friend Jim Dennis, who was a co-worker at Linuxcare in 1999 when he co-wrote a book on Linux system administration (http://www.amazon.ca/Linux-System-Administration-M-Carling/dp/1562059343) has a saying that 'Security is the implementation of policy.' By a functional definition, if a system runs the processes of authorised users and not those of unauthorised ones, that is good security. In typical current systemd-based GNOME systems[1], including recent Arch Linux ones, systemd intercepts and refuses the superuser's directive to shutdown or reboot the system if a Freedesktop.org codebase called PackageKit, to which systemd communicates over D-Bus (as it does with a thundering herd of other Freesdesktop.org plumbing) unilaterally decides that shutdown/reboot ought to be non-negotiably deferred because package operations are underway. Now, it's doubtless possible to disable that behaviour one way or another, but the point is that this behaviour, considered normal with systemd and the Freedesktop.org suite it continally communicates with, overrides the judgement of the superuser to shut down. In my book, the only thing that ought to be more definitive than the root user wielding the /sbin/shutdown utility is the root user yanking the mains cord. The superuser needs to be able to shut down NOT and know that it will happen, for any of a number of reasons. Beyond that, if you actually choose to believe that systemd and ancillary code (including without limitation all the Freedesktop.org stuff it chatters with all the time over D-Bus) doesn't have a vastly greater attack surface than other modern inits, I will regard that position as self-parodying and don't think I need to demonstrate anything. [1] Judging by a recent post in this space, this seems perhaps no longer likely to happen on Debian Jessie, which would be a step forward.
What a waste of energy this discussion / passive argument is. Supermarkets... hold more threat to your personal ability to operate effectively with privacy and choice. While you guys prattle endlessly and without end on architectural changes with an OS that has always been your choice to use or not, the real threats to your freedom and choice are being eroded by by the "memes" that just love you continuing to argue...cos you don't really have a practical/pragmatic answer...just piss and wind :-P Fuck sake... its an Open Source world...if you don't like it... spend your energies on change, the code is there...make a change, get some support and fucking do it..... not bullshit never ending discussions with pseudo intellectual quotes and debate that leads absolutely nowhere. Do what YOU think is the right way to go? Answer the problem yourself, and gain support and do what is necessary to make it happen. Hint: Complaining that the "man" and whatever else evil org you chose to lay blame on is a fault really sux. YOU HAVE A CHOICE! Exercise that choice and stop wasting time and effort. The more you blow passive intellectual raspberries at each other and extend such hopeless and energy sucking political debate ... the more your head will slip up your own ass! Last time my head was stuck up my bum I discovered that breathing was, to say the least, difficult. BW On Wed, Aug 12, 2015 at 3:21 PM, Rick Moen <rick@linuxmafia.com> wrote:
Quoting Russell Coker (russell@coker.com.au):
Why not have a $100 bet about your ability to perform the type of compromise that you think is the big problem?
Was it you or some _other_ Russell Coker who claimed that the issue I actually _did_ describe -- which you then misrepresented -- was a 'minor issue compared to web browsers, MUAs, and other programs which directly and predictably accept data from potentially hostile sources'?
Because, I call bollocks, sir. And I gather that you refuse to put your money where your mouth is.
Now, as to _a_ security problems caused by calls from systemd to other badly written Freedesktop.org software, I can give you a particular type of example immediately, as it is well known, albeit it is not a root compromise or anything quite like that: My friend Jim Dennis, who was a co-worker at Linuxcare in 1999 when he co-wrote a book on Linux system administration (http://www.amazon.ca/Linux-System-Administration-M-Carling/dp/1562059343) has a saying that 'Security is the implementation of policy.' By a functional definition, if a system runs the processes of authorised users and not those of unauthorised ones, that is good security.
In typical current systemd-based GNOME systems[1], including recent Arch Linux ones, systemd intercepts and refuses the superuser's directive to shutdown or reboot the system if a Freedesktop.org codebase called PackageKit, to which systemd communicates over D-Bus (as it does with a thundering herd of other Freesdesktop.org plumbing) unilaterally decides that shutdown/reboot ought to be non-negotiably deferred because package operations are underway.
Now, it's doubtless possible to disable that behaviour one way or another, but the point is that this behaviour, considered normal with systemd and the Freedesktop.org suite it continally communicates with, overrides the judgement of the superuser to shut down. In my book, the only thing that ought to be more definitive than the root user wielding the /sbin/shutdown utility is the root user yanking the mains cord. The superuser needs to be able to shut down NOT and know that it will happen, for any of a number of reasons.
Beyond that, if you actually choose to believe that systemd and ancillary code (including without limitation all the Freedesktop.org stuff it chatters with all the time over D-Bus) doesn't have a vastly greater attack surface than other modern inits, I will regard that position as self-parodying and don't think I need to demonstrate anything.
[1] Judging by a recent post in this space, this seems perhaps no longer likely to happen on Debian Jessie, which would be a step forward. _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Wed, 12 Aug 2015 07:23:36 PM Brent Wallis wrote:
What a waste of energy this discussion / passive argument is.
+lots - I'm getting close to the point of unsubscribing. :-( -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, 12 Aug 2015 at 21:42 Chris Samuel <chris@csamuel.org> wrote:u
On Wed, 12 Aug 2015 07:23:36 PM Brent Wallis wrote:
What a waste of energy this discussion / passive argument is.
+lots - I'm getting close to the point of unsubscribing. :-(
This thread should have got moved to luv-talk ages ago, I think. It isn't anything to do with Linux or free software.
On Wed, 12 Aug 2015 09:45:12 PM Brian May wrote:
This thread should have got moved to luv-talk ages ago, I think. It isn't anything to do with Linux or free software.
Agreed. Can I ask everyone involved in this thread to please keep it on topic or move it to luv-talk. Additionally I would appreciate it if you could all try to treat each other with respect even where there is disagreement. Thanks, Andrew
Quoting Brent Wallis (brent.wallis@gmail.com):
Supermarkets... hold more threat to your personal ability to operate effectively with privacy and choice. [...]
It's a splendid and spirited rant, but I think you must have me confused with someone else, as I see zero threat from some piece of Poetteringware to my personal ability to operate effectively with privacy and choice. In fact, I tend to severely mock the 'systemd is being forced on me' crowd, as they are delusional and a bit pathetic. I'm the guy who pointed out exactly how to (trivially) not use it on Debian 8.0 Jessie, right here in this space, when asked how to do so.
Hint: Complaining that the "man" and whatever else evil org you chose to lay blame on is a fault really sux. YOU HAVE A CHOICE!
Yes, and I detailed the exact apt-get commands to exercise that choice. _Right here._ Perhaps you were sleeping?
Do what YOU think is the right way to go?
I'm going to go enjoy a splendid cup of Scandinavian-strong coffee.
On 2015-08-12 04:50, Rick Moen wrote:
Quoting Russell Coker (russell@coker.com.au):
On Mon, 10 Aug 2015 04:01:45 AM Rick Moen wrote:
[a great deal of energetically missing the point, snipped] No I'm just making a point that you want to ignore. In that case, you were furiously attempting to refute an allegation nobody made, while purporting to respond to my posting, in a manner indistinguishable from either completely missing my point or deliberately attempting to sidestep it while pretending to not have changed the subject. <snip> He always does that. Russell's had innumerable arguments on these lists over the years; every time it goes against him he introduces a non sequitur and pretends it's a counter argument. We've probably all been guilty of that at times but Russell's a serial offender.
Anders.
If the current state of software security gets y'all this excited, I can't wait to see the reaction when the penny drops about hardware security. I'm definitely going to need more popcorn. On 12 Aug 2015 2:51 pm, "Anders Holmström" <anders.sputnik@gmail.com> wrote:
On 2015-08-12 04:50, Rick Moen wrote:
Quoting Russell Coker (russell@coker.com.au):
On Mon, 10 Aug 2015 04:01:45 AM Rick Moen wrote:
[a great deal of energetically missing the point, snipped]
No I'm just making a point that you want to ignore.
In that case, you were furiously attempting to refute an allegation nobody made, while purporting to respond to my posting, in a manner indistinguishable from either completely missing my point or deliberately attempting to sidestep it while pretending to not have changed the subject. <snip>
He always does that. Russell's had innumerable arguments on these lists over the years; every time it goes against him he introduces a non sequitur and pretends it's a counter argument. We've probably all been guilty of that at times but Russell's a serial offender.
Anders.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Rick Moen <rick@linuxmafia.com> writes:
e.g., routing all process privilege decisions through PolKit
I have systemd v215 on Debian 8 working, without policykit-1. libpolkit* are installed, but AFAIK that's "mostly harmless".
From the manpages, it looks like you can do e.g.
hostnamectl -P foo instead of pkexec hostnamectl foo sudo hostnamectl foo su -c 'hostnamectl foo' But if you're already root, it doesn't matter. In fact, on Debian 8 the -P option is in the manpage, but it appears to be compiled out by a ./configure choice: root@het:~# hostnamectl --help |& grep privileged root@het:~# hostnamectl --privileged status hostnamectl: unrecognized option '--privileged' This is no worse than the crazy shit where systemctl runs SSH for you: systemctl -H example.net restart ssh.service becomes ssh example.net systemctl restart ssh.service Likewise systemctl --root=/target disable dev-mqueue.mount is almost but not quite the same as chroot /target systemctl disable dev-mqueue.mount The only other reference to polkit I can find is in systemd-logind, which seems to be saying If fred says "shutdown the system", I'll ask polkit if fred is allowed to do that. Having said that, my experience with recent GNOME & XFCE code is that when they need escalated privileges (e.g. to umount /media/Porn\x20USB\x20Key), the only mechanism they choose to implement is polkit. i.e. you can't tell them Dude, don't bother sending an umount XML-IPC request to the polkit dbus service, just run "sudo umount". TRUST ME, it'll work. AFAICT the reason for this is that password prompting without a tty was really ugly in gksudo and polkit is... less ugly. >SHRUG<
Anyway, with reasonable luck, it'll have about as long an ascendency as HALd and devfsd, as it's certainly about as popular.
Last time I looked, I got the strong impression that upower & udisks codebases were *literally* just copy-and-pasted from hal codebase, i.e. badge engineering. (Apart from the bits that merged into udev, that is.)
Hi Russell, I find your argumentation quite weird.. "even if there is an issue, there are others in the system". With your background, it is certainly astonishing. If there is a problem with a flimsy door lock it does not matter whether the windows are secured by metal bar. The burglar looks for weak spots. A subsystem which starts and stops networks, adds keyboards or mounts USB sticks, logs all information and shuts down the system is quite important and I do not like it when it is difficult to configure and may not work as expected or even worse not deterministic. These days it takes a half-day course just to figure out how to stop DHCP and give a static IP address on a Linux live CD. Compare it to a basic; "kill <dhcp_pid>, ifconfig <if> .." on a FreeBSD live CD. Worked since I used FreeBSD in 1999 (and I guess much longer). Or how to disable a mousepad on a laptop: some weird XML file under /etc/hal2000/conf.d/NotANameIremember.conf. Of course it has to be XML because this is most easy to ready for humans (or better: an adaptation of human life to the way machines like it presented) I simply find hardware configuration on Linux systems disgusting. And it is not really good if things are "too hard to understand" and quite often not really documented, and just have an air of "just trust me" around them. It's also unsafe then. No sysadmin should put up with this crap. Regards Peter On Sun, Aug 9, 2015 at 3:32 PM, Russell Coker <russell@coker.com.au> wrote:
On Sat, 8 Aug 2015 05:14:21 PM Rick Moen wrote:
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights.
What Snowden showed us is that too many people have been too complacent about the political process. Politics matters and the big 2 parties (in the US, here, and other places) don't offer the answers. The "lesser of 2 evils" will still support spying.
The Snowden revelations have included little about OS level compromise and a lot about compromise of hardware that the vast majority of Linux users (including me) don't have the skill to oppose.
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init. As much as people like to complain about systemd being supposedly bloated it's a tiny fraction of the size of any desktop environment and has much less interaction with the outside world. A hostile party who compromises your MUA or web browser (both of which routinely and predictably process data from potentially hostile sources on the Internet) can probably do all the damage that they want to do to your system without root access.
If a hostile party wants to gain root access to your PC what they will probably do is compromise your MUA or web browser and then try a local root exploit. The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Peter Ross <petrosssit@gmail.com> writes:
These days it takes a half-day course just to figure out how to stop DHCP and give a static IP address on a Linux live CD.
On Debian 8 Live, live-boot(7) indicates you do it the same way you did when ipconfig was built into the kernel in like 1997: ip=[DEVICE]:[CLIENT_IP]:[NETMASK]:[GATEWAY_IP]:[NAMESERVER][,[DEVICE]:[CLIENT_IP]:[NETMASK]:[GATEWAY_IP]:[NAMESERVER]] This is because it uses klibc-utils' ipconfig(8), which is admittedly a TERRIBLE THING. Also: live-boot/live-config manpages tend to proactively descibe features that haven't actually been written yet; don't trust them :-)
Or how to disable a mousepad on a laptop: some weird XML file under /etc/hal2000/conf.d/NotANameIremember.conf.
Untested: cat >/etc/xorg.conf.d/no-touchpad-kthx.conf Section "InputClass" Identifier "Touchpad" MatchIsTouchpad "yes" Driver "synaptics" Option "TouchpadOff" "1" EndSection Based on synaptics(4) & https://wiki.debian.org/SynapticsTouchpad I do it with "syndaemon -Rdtk" in ~/.xsession, which disables it only while typing.
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init.
systemd takes care of Linux containers which provide or can provide user/application separation. A flaw in this leaves you with a false sense of security, in case you use it. That is actually quite critical. After all, I still have not come up with something explaining Linux containers and security as clearly as the jail(8) manpage states: http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=0&manpath=Fr... The best I could fined so far is http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security and it gives me the impression: Do not rely on Linux containers, you have to add other measures to make it safe (no root user, SELinux, capabilities etc.) There is nothing wrong with adding additional layers, of course. But the basic design is maybe not as good if I have to rely on these additions. Until now I am not convinced to have a similar clear process separation as I have with FreeBSD's jail. Which makes Docker containers a bit of a gamble I am not willing to take if it comes to security. (Additional comment very welcome.. at the moment I just don't know better) Things like this are quite scary: http://www.zdnet.com/article/dropbox-google-drive-onedrive-files-man-cloud-a... "The attack works by grabbing the password token, a small file that sits on a user's devices for convenience (which saves the user from entering their password each time)." Taking away 'convenience' (yes, it is convenient for attackers to have access to private keys without a password;-) .. this is easily preventable if you run a DropBox service (or whatever) in the jail and other apps as well, and there is a clear separation of data for all services running. So, we (technicians) know how to do it.. Question: Why does it not work that way? Regards Peter On Sun, Aug 9, 2015 at 3:32 PM, Russell Coker <russell@coker.com.au> wrote:
On Sat, 8 Aug 2015 05:14:21 PM Rick Moen wrote:
Open Source is the only chance not to lose privacy forever, and the biggest player, Linux, has crucial software replaced by a quite unruly mob. It will make it quiet hard to implement light-weight and safe IT solutions.
Snowden showed we've been far too complaisant about critical infrastructure security. The only way I know to improve that situation is attending to fundamentals: excess complexity/functionality, excess privilege, unnecessary trust, unnecessary code, lack of enforced policy, lack of well-planned and documented functionality and interconnections, default-permit, lack of alert monitoring, lack of roles with planned and defined rights.
What Snowden showed us is that too many people have been too complacent about the political process. Politics matters and the big 2 parties (in the US, here, and other places) don't offer the answers. The "lesser of 2 evils" will still support spying.
The Snowden revelations have included little about OS level compromise and a lot about compromise of hardware that the vast majority of Linux users (including me) don't have the skill to oppose.
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init. As much as people like to complain about systemd being supposedly bloated it's a tiny fraction of the size of any desktop environment and has much less interaction with the outside world. A hostile party who compromises your MUA or web browser (both of which routinely and predictably process data from potentially hostile sources on the Internet) can probably do all the damage that they want to do to your system without root access.
If a hostile party wants to gain root access to your PC what they will probably do is compromise your MUA or web browser and then try a local root exploit. The Linux kernel is much larger than systemd and has many more interfaces to sources of hostile data.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Mon, 10 Aug 2015 03:25:30 PM Peter Ross wrote:
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init.
systemd takes care of Linux containers which provide or can provide user/application separation. A flaw in this leaves you with a false sense of security, in case you use it.
People say that about every improvement to Linux security. But the usual case is that people don't rely on such measures as a single level of security. Usually Unix permissions are the first level and containers etc are only used as a fallback. This is different to the case where a jail is used instead of a virtual machine. Adding containers to the basic functionality of an init only improves things. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
"Adding containers to the basic functionality of an init only improves things." Adding a /etc/rc.d/jail script improves security;-) There are 2 things: 1. To add more functionality in the same tool increases complexity. Complexity never increases security. That is so obvious that it is hard to believe that someone would argue otherwise. Do everything once, do not make it more complex as needed, and do it right. 2. Linux has cgroups and namespaces but some Linux design decisions are in the way of using them as _secure_ containers. Procfs is an example for it. It's simply not designed with security in mind, and the access to it is difficult to restrict. Page 40 of http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security mentions it, says "needs to be fixed" and offers workarounds. The spread of Docker in such an environment( which can be only described as "hopefully safe enough") is a worry. FreeBSD jail(8) is in use for many years and can be considered as safe. The pitfalls are known, disabled in the default setup, well documented, and there are no 'hopefully safe"s in it. "Which is still a minor issue compared to web browsers, MUAs..' They do not run on my servers, and they should not be an excuse to run other software which is overly complex because Russell considers it as a "lesser evil";-) To go to your own stuff, e.g. SELinux: A jail script can be subject to SELinux policies so jails can be restricted that way. This would apply to all jails, and nothing else. If this is part of a larger binary which does all of init: SELinux cannot be applied in a similar way. Regards Peter On Wed, Aug 12, 2015 at 11:52 AM, Russell Coker <russell@coker.com.au> wrote:
On Mon, 10 Aug 2015 03:25:30 PM Peter Ross wrote:
Finally the vast majority of Linux systems are single user. That means Android phones/tablets and desktop PCs running GNOME, KDE, etc. There is no need to compromise init.
systemd takes care of Linux containers which provide or can provide user/application separation. A flaw in this leaves you with a false sense of security, in case you use it.
People say that about every improvement to Linux security. But the usual case is that people don't rely on such measures as a single level of security. Usually Unix permissions are the first level and containers etc are only used as a fallback. This is different to the case where a jail is used instead of a virtual machine.
Adding containers to the basic functionality of an init only improves things.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Fri, 14 Aug 2015 04:18:28 PM Peter Ross wrote:
There are 2 things:
1. To add more functionality in the same tool increases complexity.
Complexity never increases security.
That depends on what you do and how you do it. If you add some complexity to one central place and remove it from many other places that's often an overall benefit.
Do everything once, do not make it more complex as needed, and do it right.
Which is the benefit of replacing /etc/init.d/ script functionality with code in systemd.
2. Linux has cgroups and namespaces but some Linux design decisions are in the way of using them as _secure_ containers.
Greater use of cgroups and namespaces by systemd should be an incentive for development of better kernel support.
FreeBSD jail(8) is in use for many years and can be considered as safe. The pitfalls are known, disabled in the default setup, well documented, and there are no 'hopefully safe"s in it.
I agree that having functionality like jail in the Linux kernel would be a good thing. This is not related to systemd though.
"Which is still a minor issue compared to web browsers, MUAs..'
They do not run on my servers, and they should not be an excuse to run other software which is overly complex because Russell considers it as a "lesser evil";-)
Systemd is optional and as Rick has demonstrated any sysadmin who doesn't want it on Debian can remove it with ease. It's less optional on GNOME and most desktop sysadmins won't even try removing it if they run KDE. So I think that these supposed security risks should be considered in the context of desktop users.
To go to your own stuff, e.g. SELinux:
A jail script can be subject to SELinux policies so jails can be restricted that way. This would apply to all jails, and nothing else.
That's usually not what you want. You probably want to have multiple jails with different security contexts.
If this is part of a larger binary which does all of init: SELinux cannot be applied in a similar way.
Sure it can. The init system could request different contexts for each of the jails (this can be added to systemd unit files if it isn't already there) or the executables to run in the jails could have different contexts. I wrote policy for multiple chroot environments many years ago but it got deleted in the change to the modular "reference" policy. But it would be possible to do that again if there was demand. On Linux Xen performance is really good. The only situation where something like Docker would be a good idea is if you have ZFS storing all the data and don't want to be hobbled by poor NFS performance to the virtual machine. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Linux Xen performance is really good.
I am used to setup and configure jails from the host system while I can seamlessly write to the ZFS because it is under /zpool/jails/<myjail>/<timestamp> So an upgrade is simply a stop of the jail with the old <timestamp> directory and start the new one. A /var/db/mysql gets "transferred" by changing the mountpoint. The filesystem is shared, no voodoo to increase a disk image needed. (I can use quota if there is a need) The same goes for the memory, no pre-allocation and slicing needed (resource management via rctl possible if needed). I safe diskspace because the jail filesystems are simply cloned from a template (only deltas of the filesystems per jail are written) An exact copy of the jail can be mirrored quickly on another box via zfs snapshot, zfs send | ssh zfs receive. To bring it up is a oneliner (more automagic with CARP or VRRP and heartbeats if you want) The kernel cannot be patched dynamically, that's true. But with 2 or 3 kernel security issues per year it is a bit less of a worry for many environments. 30 minutes downtime per year isn't too bad, and it's realistic without high-availability added yet. It's more than 99.99% availability. I am using VMware ESXi and CentOS7 now. It's a huge step backwards. Regards Peter On Fri, Aug 14, 2015 at 8:16 PM, Russell Coker <russell@coker.com.au> wrote:
On Fri, 14 Aug 2015 04:18:28 PM Peter Ross wrote:
There are 2 things:
1. To add more functionality in the same tool increases complexity.
Complexity never increases security.
That depends on what you do and how you do it. If you add some complexity to one central place and remove it from many other places that's often an overall benefit.
Do everything once, do not make it more complex as needed, and do it right.
Which is the benefit of replacing /etc/init.d/ script functionality with code in systemd.
2. Linux has cgroups and namespaces but some Linux design decisions are in the way of using them as _secure_ containers.
Greater use of cgroups and namespaces by systemd should be an incentive for development of better kernel support.
FreeBSD jail(8) is in use for many years and can be considered as safe. The pitfalls are known, disabled in the default setup, well documented, and there are no 'hopefully safe"s in it.
I agree that having functionality like jail in the Linux kernel would be a good thing. This is not related to systemd though.
"Which is still a minor issue compared to web browsers, MUAs..'
They do not run on my servers, and they should not be an excuse to run other software which is overly complex because Russell considers it as a "lesser evil";-)
Systemd is optional and as Rick has demonstrated any sysadmin who doesn't want it on Debian can remove it with ease. It's less optional on GNOME and most desktop sysadmins won't even try removing it if they run KDE. So I think that these supposed security risks should be considered in the context of desktop users.
To go to your own stuff, e.g. SELinux:
A jail script can be subject to SELinux policies so jails can be restricted that way. This would apply to all jails, and nothing else.
That's usually not what you want. You probably want to have multiple jails with different security contexts.
If this is part of a larger binary which does all of init: SELinux cannot be applied in a similar way.
Sure it can. The init system could request different contexts for each of the jails (this can be added to systemd unit files if it isn't already there) or the executables to run in the jails could have different contexts.
I wrote policy for multiple chroot environments many years ago but it got deleted in the change to the modular "reference" policy. But it would be possible to do that again if there was demand.
On Linux Xen performance is really good. The only situation where something like Docker would be a good idea is if you have ZFS storing all the data and don't want to be hobbled by poor NFS performance to the virtual machine.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Peter Ross <petrosssit@gmail.com> writes:
After all, I still have not come up with something explaining Linux containers and security as clearly as the jail(8) manpage states:
http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=0&manpath=Fr...
The best I could fined so far is http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security
and it gives me the impression: Do not rely on Linux containers, you have to add other measures to make it safe (no root user, SELinux, capabilities etc.)
The slightly longer explanation is: 1. Linux doesn't give you jail(8). Linux gives you the tools to *build* jail(8): cgroups and namespaces. 2. Since about 2009, you can DIY jail(8) out of those components. It's easy to make it work at all. It's hard to make it work securely. 3. Since about 2012, you can just use existing middleware to do (2). 4. If you believe (3) was built by security-nerd kernel experts who always choose security over convenience, then it's "safe". 5. I don't believe that. It's not safe.
On Sat, 2015-08-08 13:01:40 +1000, Russell Coker wrote:
On Sat, 8 Aug 2015 09:41:44 AM Peter Ross wrote:
For the sinister part: The threat of surveillance is not a made up fantasy. Snowden sits in Russia for a reason and Assange is stuck in London as well.
The work is done on two fronts, through law (make it legal that all citizen are suspects and do not deserve privacy) and introduction of unsafe software.
I _fully_ agree with the two statements above.
Time for a reality check.
Russell, why do you think all the sinister secrets disclosed by Snowden and Assange are not real?
On Sat, 8 Aug 2015 05:23:40 PM Aníbal Monsalve Salazar wrote:
Russell, why do you think all the sinister secrets disclosed by Snowden and Assange are not real?
Please can this discussion be taken to luv-talk please? I don't think this is related to helping Brian with his query about why his laptop won't sleep when he shuts its lid. Thanks, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Sat, 8 Aug 2015 at 18:23 Chris Samuel <chris@csamuel.org> wrote:
I don't think this is related to helping Brian with his query about why his laptop won't sleep when he shuts its lid.
Getting back on topic, I reported it as a Debian bug: http://bugs.debian.org/794744 They referred me to this bug: https://github.com/systemd/systemd/issues/451 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788400#92 Unfortunately, while I am clearly affected by this bug - which looks like a kernel bug to me with a work around in latest versions of systemd, it doesn't explain why suspend won't work after a reboot. I also found I can manually force suspend without sudo: systemctl suspend Still, might be worth trying the latest version of systemd and seeing if it does help or not. At the very least I might get more debugging information.
On Sun, 9 Aug 2015 at 11:02 Brian May <brian@microcomaustralia.com.au> wrote:
Unfortunately, while I am clearly affected by this bug - which looks like a kernel bug to me with a work around in latest versions of systemd, it doesn't explain why suspend won't work after a reboot.
Looks like the problem has come good by itself. Strange. Wonder if it was anything to do with my upgrade to Windows 10, followed by an update of Lenovo stuff including the BIOS. I suspect the BIOS upgrade may have done something. (I did not change/update systemd in anyway) Fingers crossed it stays working.
Russell Coker <russell@coker.com.au> writes:
On Fri, 7 Aug 2015 04:14:57 PM Rick Moen wrote:
But, that having been said, your point is an excellent one. If I need to replace my MTA with a different implementation, my sshd with a different one, my command shell with a different one, my choice of awk,
It's been a long time since there were multiple choices for sshd.
I have three in production right now: GNU ssh, Dropbear, and OpenSSH.
Rick Moen <rick@linuxmafia.com> writes:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
Please provide details on this. Debian rsyslog is configured to read from /run/systemd/journal/syslog instead of /dev/log by default, if it detects systemd is running. AFAIK it is *not* trivially possible to opt out of journald; You can have either journald alone, or syslog chained off journald. busybox-syslogd in debian 8 does not work at all while journald is in place, because it (debian busybox) is compiled without CONFIG_SYSLOGD, and without that there is no way to tell busybox-syslogd to read from /run/systemd/journal/syslog, so syslogd effectively receives no logs.
echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
Suggest printf(1); echo -e breaks if dash is your login shell.
A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
Agree. I think that is primarily to handle socket-based startup & logging to journald instead of /dev/log. In such code I have looked at, it is typically laid out thusly: if /run/systemd exists, [new behaviour] otherwise [traditional behaviour]
Quoting Trent W. Buck (trentbuck@gmail.com):
Rick Moen <rick@linuxmafia.com> writes:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
Please provide details on this.
I was going by comments from the Debian systemd packager during the huge debian-devel debate of a few years ago. Which it's entirely possible that I didn't understand correctly or have misremembered over the years since then. Personally, I have stepped carefully sideways and simply avoided having it on systems I administer, so all I could tell you from personal and certain knowledge is how Debian Jessie systems behave with systemd banished and a different init in its place. Maybe what the guy said amounted to systemd-logind will still be there but in the Debian packaging is designed to co-exist with syslog. [After doing a bit of remedial reading via Web-searching:] I note this Josh Triplett comment in debian-devel (https://www.mail-archive.com/debian-devel@lists.debian.org/msg332843.html): Hideki Yamane wrote:
We've switched to systemd and I've noticed that journald feature is not enabled. I can easily do it as README.Debian suggested, but wonder why logging by journald is not enabled by default.
Is there any reason? (just a curious)
The in-memory non-persistent journal (/run/log/journal) is enabled; if you run journalctl you can see the logs from the current boot. The on-disk persistent journal (/var/log/journal) is disabled because at the moment, Debian systems use syslog by default (via rsyslog), and enabling the persistent journal would result in two copies of log messages. Since the journal is capable of capturing messages sent to syslog, I'm hoping that at some point the systemd source package will build a binary package that installs /var/log/journal and Provides the system-log-daemon and linux-kernel-log-daemon virtual packages. (As well as a non-default one that provides the same virtual packages but doesn't provide the persistent journal directory, for systems that want transient in-memory logging only.)
Suggest printf(1); echo -e breaks if dash is your login shell.
Good point. Noted. Thanks for your further details on a matter that I ignored when it was a hot topic, and dug into only deeply enough to move sideways to OpenRC when it became personally relevant.
Hello Rick, On Thu, 2015-08-06 at 12:40 -0700, Rick Moen wrote:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
Thank you for this response. It contains most of what I will need when I do an install of Jessie. One query, what window managers have you tried without systemd, and what you find particularly good or bad. For myself, I find the older desktop metaphor more effective and productive.
I noted that it is possible to put openrc on Debian 8. I shall need to do a bit of research. Some notes from you and/or Rick Moen would be very appreciated.
apt-get install openrc
Reboot.
apt-get remove --purge --auto-remove systemd
The basics are remarkably simple, but the completeness that follows is very appreciated.
Note that said command will remove these Debian packages if they are present:
o 5 GNOME packages that directly on systemd: gnome-bluetooth, gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility. (This is essentially the GNOME requirement for systemd-logind for 'seat' login credentials, which has become problematic to satisfy without systemd because the Freedesktop.org coders orphaned ConsoleKit, and ConsoleKit2 isn't yet usable last I heard.)
Interesting, on what has been done, and what has not been done. Does make changing desktops from Gnome a necessity. I have found the changed direction of Gnome less productive for me, but some of the lighter ones with more traditional workflows more to my preference.
o 10 debian-installer* packages that depend directly on systemd because the Debian 8.0 default installer provides systemd
o 1 WindowMaker dock applet for shutting down a machine by clicking a button (wmshutdown).
o 5 packages that depend on systemd because they're systemd-related: (live-config-systemd, libpam-systemd, systemd-dbg, systemd-sysv, libpam-systemd).
o 1 GNOME-affiliated display manager that requires either libpam-system or consolekit (lightdm).
o 6 assorted other packages that require that systemd _or_ something else be present (mate-power-manager, solaar, libguestfs0, sogo, ligthttpd, lxsession). Details omitted here but you can look them up in package metadata.
o 2 packages from the core Freedesktop.org stack -- the guys responsible for most of the furious code churn in GNOME -- that depend on libpam-systemd (policykit-1, udisks2).
o 1 wireless/Bluetooth network manager from GNOME that depends on libpam-systemd (network-manager).
So it also removes NetworkManager? There are alternate ways of coping with changing networks, I need to find references again. I have found the way NetworkManager tries to handle the connections is not the way I use my PC or notebook. There are bits that work, but also bits which it ripe royally leaves me up the proverbial creek without a paddle.
o pcmanfm, daisy-player, and a couple of other obscure apps that require policykit-1 that in turn requires systemd One depending on policykit-1 that is not at all obscure, is a rather infuriating and pointless dependency hairball, and merits rebuilding the package if you need it (hplip).
This is of significance. I have HP LJ4L and LJ4P printers, although needing a bit of servicing, and a HP LJ4Plus. The latter runs under Postscript, so may be less of an issue. It is a significant package for many of us.
Measures to keep systemd from being installed in the future:
echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
If your system uses multiarch (32 and 64bit packages), do this too, to pin the 64bit version of systemd:
echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package:
echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
This is valuable admin information, and a good example that I can use for related things where I want to effect changes.
Above is from my notes of changeover conducted on a virtual machine, so I'm reasonably confident they're complete and correct. Getting rid of udev/libudev1 and getting any replacement (eudev, mdev, vdev) to work with the latest xserver-xorg packages is an experiment I've not yet undertaken.
A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
Thanks again. Regards, Mark Trickett
Hello Rick, Another nitpick with Gnome and Cannonical. Really need to migrate off this IBM A20m Thinkpad, in the process of doing, when have next computer hardware sorted, and software install, along with transferring wanted data, but not inappropriate configurations. It is still on Ubuntu 8.04, well out of date, and not fully updated. Went to remove the excess old kernels and modules and removed in wrong order, so packages are jammed, but looking to next PC. Anyway, printing emails from Evolution reverts to US Letter size paper, not A4 which is my system setting for paper size. I did report a bug, but it was never fixed, just closed as the version in question was no longer supported. I think Evolution uses Evince for Postscript rendering, and I suspect the real fault lies somewhere in Evince. I have found trying to set the paper size to A4 does not hold, there is a setting, but it keeps reverting to US Letter. Next "interesting" task, trying to transfer the 25K+ email archive to whichever email reader I next use. I am finding it less than easy to get my head around setting up Mutt, at least at this stage. Thunderbird would be easyish, but there are issues there also, including certain aspects to inlining attachments under certain circumstances, which can confuse recipients who "expect" a separate attachment, and have trouble "seeing" it when it is inlined. Regards, Mark Trickett
On 08/08/15 22:05, Mark Trickett wrote:
Thunderbird would be easyish, but there are issues there also, including certain aspects to inlining attachments under certain circumstances, which can confuse recipients who "expect" a separate attachment, and have trouble "seeing" it when it is inlined.
There is a configuration in Thunderbird to change the behaviour of attachments. preferences->advanced->config_editor mail.content_disposition_type=1 Setting the value to 0 will inline anything not explicitly handled by mimeTypes.rdf (typically text and images will be inlined). Setting the value to 1 will force non-inlined attachments. How the recipient sees the attachments can depend on their email client software. Some mail clients may show the content of even non-inlined text and image attachment types. Glenn -- sks-keyservers.net 0x6d656d65
On 6/08/2015 2:12 PM, Russell Coker wrote:
On Thu, 6 Aug 2015 12:28:08 PM Peter Ross wrote:
What is the share of desktops running Linux/Gnome? 2 or 3 percent.
Hopefully increasing. Features like multi-seat support should allow some significant increases. The cost savings for schools and corporations with multi seat can be significant.
Multi seat pre-dated systemd by years.... why is it needed now? A.
Quoting Tim Connors (tim.w.connors@gmail.com):
On Wed, 5 Aug 2015, Rick Moen wrote:
[...]
And all of them want to convince you that all the others are essential because they're all part of the Freedesktop.org stack. But they won't hurt you if you don't believe in them.
Won't hurt? Getting a laptop to do any action upon lid close used to be so easy - pop a script in /etc/acpi somewhere. Power removed and want to spin the HD down more aggressively? Trivial!
But then some idiots came along, who though gnome was the entire world, and now it's impossible to not get it to stomp on your feet when you want to tell suspend-on-lid-close to fsck right off to where it belongs.
Tim -- It's possible that my sense of humour might be a bit dry. (Cue the tumbleweeds.) -- Cheers, "I don't need to test my programs. Rick Moen I have an error-correcting modem." rick@linuxmafia.com - Om I. Baud McQ! (4x80)
On Thu, Aug 06, 2015 at 11:45:59AM +1000, Tim Connors wrote:
But then some idiots came along, who though gnome was the entire world, and now it's impossible to not get it to stomp on your feet when you want to tell suspend-on-lid-close to fsck right off to where it belongs.
i was annoyed when systemd did a hostile takeover of power management on my little debian laptop last year (largely because it caused a shutdown in the middle of the ssh apt-get upgrade that installed the version of systemd that perpetrated the takeover, and made it impossible to remotely fix the problem)....but when i figured out what the problem was (systemd taking over power mgmt) it wasn't hard to disable it. the solution is to edit /etc/systemd/logind.conf and change it to have: HandleLidSwitch=ignore i have NFI why systemd's authors think that handling the lid switch has *anything* at all to do with logind and i would have preferred systemd not take over power mgmt at all, but it was pretty easy to undo the damage in this particular case. craig -- craig sanders <cas@taz.net.au>
Craig Sanders <cas@taz.net.au> writes:
On Thu, Aug 06, 2015 at 11:45:59AM +1000, Tim Connors wrote:
But then some idiots came along, who though gnome was the entire world, and now it's impossible to not get it to stomp on your feet when you want to tell suspend-on-lid-close to fsck right off to where it belongs.
i was annoyed when systemd did a hostile takeover of power management on my little debian laptop last year
Apropos warning! An artefact of Debian 7's sysvinit scripts render halt(8) and poweroff(8) behaviour identical. Either BOTH cut power, or NEITHER. (The behaviour is configured under /etc/default). Under systemd, they are different: halt will never cut power after stopping the OS. poweroff will always cut power after stopping the OS. This means if, like me, you got into the habit of typing "halt" because it's shorter, you'll be making some trips to the server room. Also: "shutdown" without arguments in Debian 7 sysvinit is an error. Under Debian 8 systemd, it's equivalent to "shutdown -h +60".
Brian May writes:
As of several days ago, it no longer sleeps when I close the lid with Gnome. The trigger was moving to Brisbane, in Melbourne it was fine. Hasn't come good since moving back to Melbourne however.
If I manually type in "sudo systemctl start systemd-suspend" then it goes to sleep fine. So I suspect this isn't the typical issue of suspend not working, it is more like suspend isn't even getting triggered.
Looking at /var/log/auth.log I see events being generated by systemd-login for "Lid closed" and "Lid opened" - how do I debug why these aren't getting turned into sleep events?
It is possible this problem come about as a result of upgrading from a 4.0 kernel to a 4.1 kernel, however I couldn't get get reproducible results under 4.0. As in if I make a random change to the system, it can start working and after a reboot it stops working.
Per logind.conf(5), * is HandleLidSwitch set to "suspend"? (the default) * is a userland daemon inhibiting systemd? e.g. XFCE4.10 doesn't; allegedly XFCE4.12 does. I assume gnome3 inhibits by default. If you don't want that, HibernateKeyIgnoreInhibited=true in logind.conf. OR Configure gnome's power stuff, somehow. * "Only input devices with the "power-switch" udev tag will be watched for key/lid" You can determine this in /run/udev/tags/power-switch, maybe also udevadm info/monitor. FWIW I cannot make the power button work in Debian 8 with either no GUI, or XFCE4.10, unless I *also* install acpid and use its default event handler. I haven't determined why that is yet, but it's not any of the above for me. I am not using systemd on any hosts with lids. I am not using systemd on any hosts with gnome. I am using Debian 8's versions of systemd & linux (v215 & 3.16). If you solve this issue, I would like to know the details about how.
On Fri, Aug 07, 2015 at 11:46:08AM +1000, Trent W. Buck wrote:
Per logind.conf(5),
* is HandleLidSwitch set to "suspend"? (the default)
* is a userland daemon inhibiting systemd? e.g. XFCE4.10 doesn't; allegedly XFCE4.12 does.
in fedora 22 it seems laptop lid handling works fine as long as you leave things to logind/systemd. xfce 4.12 messes it up. everything about systemd has always "just worked" for me for as long as I've had this laptop (f20 -> f22) and laptop lid stuff only broke when I opened up the xfce power settings panel yesterday, out of curiousity about this thread. restoring one of my older (<= fedora 21) xfce power config xml's makes the laptop lid work. ie. logout, switch to a vt, then % cd ~/.config/xfce4/xfconf/xfce-perchannel-xml/ % cp xfce4-power-manager.xml xfce4-power-manager.xml.new_and_broken % cat > xfce4-power-manager.xml << EOF <?xml version="1.0" encoding="UTF-8"?> <channel name="xfce4-power-manager" version="1.0"> <property name="xfce4-power-manager" type="empty"> <property name="power-button-action" type="uint" value="3"/> <property name="lid-action-on-ac" type="uint" value="1"/> <property name="critical-power-action" type="uint" value="2"/> <property name="lid-action-on-battery" type="uint" value="1"/> <property name="brightness-switch-restore-on-exit" type="int" value="0"/> <property name="brightness-switch" type="int" value="0"/> </property> </channel> EOF and that fixes it for me. I suspect the above config is detected as being as in a previous format by xfce4-power-manager and that causes power to be managed in a different (non-overriding systemd?) way. if you fire up the xfce settings -> power panel then there are 4 or 5 more fields added (including one about logind) and laptop lid no longer works. there seems to be a bunch of freedesktop power manager bugs open.
I am using Debian 8's versions of systemd & linux (v215 & 3.16).
If you solve this issue, I would like to know the details about how.
v219 systemd, 4.1.3 kernel, few years old powerbook, fedora 22, xfce 4.12, xfce4-power-manager-1.4.4-1.fc22.x86_64 pretty different from your setup, but HTH anyway. cheers, robin
participants (17)
-
Anders Holmström -
Andrew McGlashan -
Andrew Pam -
Aníbal Monsalve Salazar -
Brent Wallis -
Brian May -
Chris Samuel -
Craig Sanders -
Glenn McIntosh -
Mark Trickett -
Peter Ross -
Rick Moen -
Robin Humble -
Russell Coker -
thelionroars -
Tim Connors -
trentbuck＠gmail.com