Re: xen bootcamp (was: xen: was Challenge to you: Voice your concerns regarding systemd) upstream
Hi. On Tue, Sep 30, 2014 at 04:16:41PM -0400, Steve Litt wrote: On Tue, 30 Sep 2014 17:57:41 +0400 Reco recovery...@gmail.com wrote: Ok, ok. We all got it already. S*stemd in Debian = bad. S*stemd in Fedora = good. Fedora has no xen, hence = bad. Debian has xen, hence = good. Reco Reco, help me understand something: I don't understand why it matters what distro you chose for your xen dom0, or why it makes a distro better to have a dom0 xen kernel... Sure. Once upon a time there was Xen. Then Xen was bought by Citrix. Since then there's Citrix's Xen (aka Xenserver), Red Hat's Xen (nixed in favor of qemu-kvm), Novell's Xen (nixed by Attachmate, a subsidiary of M$ who bought Novell), Debian's Xen, Oracle's Xen (aka OracleVM) and NetBSD's Xen. There're also a non-public versions of Xen, such as Amazon's one. My understanding of xen is it sits between the metal and your guest operating system(s). My understanding is there is a Linux host operating system, but its sole purpose is support of xen, and that's all it does. Here's a list of operating systems with xen dom0 kernels: http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen By the way, the preceding page states that Fedora, from v16 on, has a dom0 xen kernel. Xen is a microkernel, and there's two major versions of such microkernel - 3 and 4. Debian currently uses version 4, about the only one who uses version 3 today is Oracle. Xen's microkernel is a free software. But there's more to that as there's Xen's API made for controlling domUs, in fact, there's two sets of Xen's API - xm (made by human beings for human begins), and its successor xl (made by our friends from Mars for robots). Again, Xen's API is a free software. But using Xen's API directly is not the thing that Joe the average admin would do. Hence, there're tools which use Xen's API: - venerable xm toolset - hipster xl toolset - RedHat's pet libvirt - that thingie they put into XenServer - an abomination they put into OracleVM - that secret thing they in at Amazon Hence a choice of distribution depends on a Xen toolset of choosing and a huge portion of a personal taste. To my way of thinking, the dom0 OS isn't really being used as an OS at all: It's just an enabler for xen, and to my way of thinking, that means it has way fewer challenges than a normal OS. So if it uses systemd, so what? It's not like you have to worry about running Gimp or Gnome or KDE or various authentication facilities directly on it: It's a vehicle for xen, no more, no less. On a typical virtualization server - yes, dom0 is used for managing domUs, and not much more. But, if you need to run X - things are very different, as you use dom0 as a conventional PC. Because - it's *very* difficult to force Xen to transfer control of your video card to domU. Possible, but very difficult, and hardware specific. I went to a Xen talk, and as I remember the guy said Xen is developed and tested on Ubuntu, so that's your best bet. Yeah, Ubuntu will have systemd, but if it works for the xen people, it should work for us all. That guy does not seem to know what he's talking about. Xen is developed by Xen Project (xen.org), Citrix and Oracle (they like to say so, at least). Ubuntu merely builds Xen from the source, as others do. If one absolutely wants to avoid systemd, NetBSD has a xen kernel available. So they say. They also say that NetBSD was the first, and it is the most portable of BSDs. But the reality is that BSD people say you 'it runs on this platform' that usually means they give you so called 'base system' and a toolchain. And if you have *a lot* of free time, you can build any software you like as long as it's ported. Debian (I need to compare BSD with something, do I?) says that 'it runs on this platform' only once most (90% IIRC) software from the main archive is actually built *and* runs on said platform. Summing it up - I don't know current status of Xen on NetBSD, and whenever Xen is in the 'base system' or 'ports'. Unless I'm vastly misinformed, once your dom0 xen is installed, you can now install domU hosts of any type you want, with or without systemd, and use them to your heart's content. Am I understanding the situation right? Yes, that's correct. To run so called 'fully virtualized OS' (i.e. not modified to work with Xen) you'll need to have Intel VT-d CPU flag (or an appropriate AMD equivalent), but that's all that required. Convincing domU to use a real hardware is entirely different story. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001082029.GA10379@x101h
Re: xen bootcamp (was: xen: was Challenge to you: Voice your concerns regarding systemd) upstream
On Mi, 01 oct 14, 12:20:31, Reco wrote: So they say. They also say that NetBSD was the first, and it is the most portable of BSDs. But the reality is that BSD people say you 'it runs on this platform' that usually means they give you so called 'base system' and a toolchain. And if you have *a lot* of free time, you can build any software you like as long as it's ported. Debian (I need to compare BSD with something, do I?) says that 'it runs on this platform' only once most (90% IIRC) software from the main Actually it's 98% according to https://release.debian.org/jessie/arch_policy.html archive is actually built *and* runs on said platform. Built, yes, runs... its always good if a package has tests (either from upstream or as part of DEP 8 http://dep.debian.net/deps/dep8/) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: xen bootcamp (was: xen: was Challenge to you: Voice your concerns regarding systemd) upstream
On Wed, 1 Oct 2014 12:20:31 +0400 Reco recovery...@gmail.com wrote: Hi. Hi Reco, This is outstanding information. Thank you! On Tue, Sep 30, 2014 at 04:16:41PM -0400, Steve Litt wrote: On Tue, 30 Sep 2014 17:57:41 +0400 Reco recovery...@gmail.com wrote: Ok, ok. We all got it already. S*stemd in Debian = bad. S*stemd in Fedora = good. Fedora has no xen, hence = bad. Debian has xen, hence = good. [snip history of xen] Xen is a microkernel, and there's two major versions of such microkernel - 3 and 4. Debian currently uses version 4, about the only one who uses version 3 today is Oracle. Xen's microkernel is a free software. But there's more to that as there's Xen's API made for controlling domUs, in fact, there's two sets of Xen's API - xm (made by human beings for human begins), and its successor xl (made by our friends from Mars for robots). Again, Xen's API is a free software. But using Xen's API directly is not the thing that Joe the average admin would do. Hence, there're tools which use Xen's API: - venerable xm toolset - hipster xl toolset - RedHat's pet libvirt - that thingie they put into XenServer - an abomination they put into OracleVM - that secret thing they in at Amazon Hence a choice of distribution depends on a Xen toolset of choosing and a huge portion of a personal taste. So what do you think of the toolset that comes with Debian? Hypothetically, if you were a person who hated the concept of systemd, in the case of using Debian for dom0 and dom0 only, with no X, would you care whether or not the dom0 initted from systemd? At that point, isn't the Linux distro just a well-segregated piece of xen dom0? To my way of thinking, the dom0 OS isn't really being used as an OS at all: It's just an enabler for xen, and to my way of thinking, that means it has way fewer challenges than a normal OS. So if it uses systemd, so what? It's not like you have to worry about running Gimp or Gnome or KDE or various authentication facilities directly on it: It's a vehicle for xen, no more, no less. On a typical virtualization server - yes, dom0 is used for managing domUs, and not much more. But, if you need to run X - things are very different, as you use dom0 as a conventional PC. Because - it's *very* difficult to force Xen to transfer control of your video card to domU. Possible, but very difficult, and hardware specific. All I know of xen is what I've overheard in discussions and seen in that one guy's presentation, but my impression was that the way to use xen is to have xen on a server and access its domU guest OS's on a client machine. Is that true? I went to a Xen talk, and as I remember the guy said Xen is developed and tested on Ubuntu, so that's your best bet. Yeah, Ubuntu will have systemd, but if it works for the xen people, it should work for us all. That guy does not seem to know what he's talking about. Xen is developed by Xen Project (xen.org), Citrix and Oracle (they like to say so, at least). Ubuntu merely builds Xen from the source, as others do. I probably heard wrong or interpreted wrong. The guy seemed very knowledgeable, not just to me, but to the other hundred or so people in the room who were asking lots of questions. It's probable I just got confused. [snip netBSD stuff] Unless I'm vastly misinformed, once your dom0 xen is installed, you can now install domU hosts of any type you want, with or without systemd, and use them to your heart's content. Am I understanding the situation right? Yes, that's correct. To run so called 'fully virtualized OS' (i.e. not modified to work with Xen) you'll need to have Intel VT-d CPU flag (or an appropriate AMD equivalent), but that's all that required. Isn't that VM support built into all desktop mobo/CPU systems built in the last 3 years? Convincing domU to use a real hardware is entirely different story. Personally, I wouldn't want to use real hardware, for much the same reason as my objections to systemd: Modularity. If I'm going to use xen as a layer beneath my (perceived) OS, I want all my calls to go to that layer, not the hardware beneath it. Unless, of course, there's a huge performance advantage kind of like the DOS days when you wrote to B800 instead of using the BIOS write to screen, in order to speed up screen write by a factor of five or ten. But my understanding is that if the machine with dom0 has VM speedup built into the CPU/mobo, it goes fast enough. Just one more question: What's your opinion of Debian as a vehicle to deploy a xen dom0? Thanks, SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001095547.73166...@mydesq2.domain.cxm
Re: xen bootcamp (was: xen: was Challenge to you: Voice your concerns regarding systemd) upstream
Hi. On Wed, Oct 01, 2014 at 09:55:47AM -0400, Steve Litt wrote: Xen is a microkernel, and there's two major versions of such microkernel - 3 and 4. Debian currently uses version 4, about the only one who uses version 3 today is Oracle. Xen's microkernel is a free software. But there's more to that as there's Xen's API made for controlling domUs, in fact, there's two sets of Xen's API - xm (made by human beings for human begins), and its successor xl (made by our friends from Mars for robots). Again, Xen's API is a free software. But using Xen's API directly is not the thing that Joe the average admin would do. Hence, there're tools which use Xen's API: - venerable xm toolset - hipster xl toolset - RedHat's pet libvirt - that thingie they put into XenServer - an abomination they put into OracleVM - that secret thing they in at Amazon Hence a choice of distribution depends on a Xen toolset of choosing and a huge portion of a personal taste. So what do you think of the toolset that comes with Debian? They don't give you xm anymore. Pain, horror, sadness and all that. I miss Debian etch. xl is ok, as long as you don't have to use it directly. Dealing with UUIDs is something I prefer to avoid unless I'm paid to do so. libvirt is in a good shape in both stable and backports, and has very good maintainer team. Upstream are reasonable guys too. A personal experience for both. The usage of libvirt has the following caveats: 1) One *must* be prepared to editing xml in a text editor. Justification - it's the only way of uncovering most libvirt possibilities. Avoid anything that's built on libvirt like plague, unless you're happy with GNOME 3. 2) One *must* be prepared to stomach a typical Red Hat userspace product. I.e. it's enterprisey, it expects a typical Red Hat's userland (OpenBSD's netcat is a requirement, for example). As a typical Red Hat's userland it has its share of integration with dbus and that-not-shall-be-named-pid1-process. Integration is optional, as far as stable is concerned. 3) One *must* be prepared to funny libvirt's habits to touch the most unusual parts of server's setup. I.e. libvirt's own set of iptables rules? Check. Creating own bridges? Check. Trying to manage said bridges with own set of ebtables rules? Check. Trying to create own cgroup sets just for the fun of it? Check. Did I mention that it's all configured via XML? Most of the annoying stuff can be disabled (or worked around), but it has to be done. Still, while libvirt can give you a load of trouble - accept no substitutes. Hypothetically, if you were a person who hated the concept of systemd, in the case of using Debian for dom0 and dom0 only, with no X, would you care whether or not the dom0 initted from systemd? If I was such person, I would take all steps nessesary to remove said init system from the dom0. Because, hate is irrational. But, since I'm a different person (I only hate carefully chosen humans, not software :) - I can tolerate any init as long as it does not jeopardize boot, shutdown and reboot processes. Especially because I don't boot, shutdown or reboot servers often. At that point, isn't the Linux distro just a well-segregated piece of xen dom0? Yes and no. There're things you do differently in dom0 comparing to the run-of-the-mill server. Time synchronizing comes to the mind immediately. Monitoring CPU, IO and memory come second. But, for the most part it's still the usual 'apt-get update apt-get upgrade' routine. Barring the initial setup process, of course. To my way of thinking, the dom0 OS isn't really being used as an OS at all: It's just an enabler for xen, and to my way of thinking, that means it has way fewer challenges than a normal OS. So if it uses systemd, so what? It's not like you have to worry about running Gimp or Gnome or KDE or various authentication facilities directly on it: It's a vehicle for xen, no more, no less. On a typical virtualization server - yes, dom0 is used for managing domUs, and not much more. But, if you need to run X - things are very different, as you use dom0 as a conventional PC. Because - it's *very* difficult to force Xen to transfer control of your video card to domU. Possible, but very difficult, and hardware specific. All I know of xen is what I've overheard in discussions and seen in that one guy's presentation, but my impression was that the way to use xen is to have xen on a server and access its domU guest OS's on a client machine. Is that true? That's one way to do it. domU is basically indistinguishable from the real server as long as you're talking to it via the network only. But, there're people who view a virtualization as a way to install a certain non-free OS (with funny four-colored banner logo), isolate it from the outside world, and use said non-free OS to run all kinds of non-free games. And said non-free games usually require 3D
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ahoj, Dňa Wed, 1 Oct 2014 02:05:42 +0300 Andrei POPESCU andreimpope...@gmail.com napísal: On Du, 28 sep 14, 20:04:22, Slavko wrote: BTW, what you recommends is to change the DE due systemd, strange solution. I want the exact opposite solution - i want to change the (now default) init system due DE. And if you dont know why, then i will tell you - because most of my work is done in DE, then change DE is bigger change, than change the init system, which my system needs *only* at start. Have you even considered trying systemd? Don't worry, the first try is always free :) Dear Andrei, in another thread you suggest to read whole posts, please apply this to self too. I will not repeat all here again, but yes, i tried it and not only once! For now, i am very disappointed how a where the things in Debian goes and how changes here are introduced. For more than 10 years i can see, that changes was doing with more caution on consequences, which any change (can) made. But now it seems, that the bull has red flag before eyes. My trust to Debian developer's decisions descends and i expect new Debian's random numbers generator. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Mi, 01 oct 14, 18:27:29, Slavko wrote: in another thread you suggest to read whole posts, please apply this to self too. I will not repeat all here again, but yes, i tried it and not only once! I do usually read very carefully the post I'm replying to and it wasn't mentioned in it (I just checked). Also, I'm not trying very hard to keep track of who is running what, especially since I'm quite a bit behind with reading -user. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco recovery...@gmail.com writes: Hi. On Tue, Sep 30, 2014 at 12:11:01AM +0200, lee wrote: Reco recovery...@gmail.com writes: About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I didn't have a server back then --- and software to run on my computer which worked fine until some change was made and it suddenly didn't work anymore. Curious. Can you remember the name of this software? yes Package managers told me that the problem won't be fixed and to install packages from experimental which wouldn't have solved the problem and couldn't be installed without more or less upgrading my system to experimental. They call it multiarch, I call it brokenarch. IIRC, that was before current stable was relased, and there was no chance that the problem would be fixed with the next stable release. The description is somewhat vague, and I can only assume that it was one of those funny packages contained i386 binaries marked as _amd64 arch. And you manage to hit an exact moment of transition from (in)famous ia32-libs blob to the multiarch. Painful, but those things don't happen in stable. The problem hasn't been fixed in stable. I'd have had to turn the system into some sort of hybrid with all kinds of problems and would have been better off with completely going back to a 32bit system, which isn't an option. Ok, ok. We all got it already. S*stemd in Debian = bad. S*stemd in Fedora = good. Fedora has no xen, hence = bad. Debian has xen, hence = good. Huh? If you think like that, you are mistaken. -- Hallowed are the Debians! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhoz4bkw@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Steve Litt sl...@troubleshooters.com writes: We had an operating system, somebody vastly altered it, some of us see the vast alterization basically breaking the software, and we bitched about having someone, even though they're developers, break our software. We didn't bitch about it, we made bug reports and the bugs were not fixed. So we realised that the attitude of the developers had changed from trying to make a good distribution to not caring anymore. Time (like 3 or 4 years) will tell whether we were spot on or whether we were Chicken Little, but if we were right, Debian will *never* be able to assume its former role, It already has lost this role. and as a matter of fact, the way things are going, that can be said for all of Linux. We'll see :/ -- Hallowed are the Debians! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppeb4bx9@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco writes: Hi. On Mon, Sep 29, 2014 at 11:28:55AM -0400, The Wanderer wrote: Header files are arch-agnostic, it's the .la files that case all the trouble. I'm afraid that's not always the case. I've encountered specific cases where the headers are different between architectures. Hmm. Kernel headers come to mind, but for typical userspace headers that's unusual. I admit that I skipped most of the discussion, but consider that this statement is true if and only if for userspace headers you refer to /usr/include and such files. These header do refer to the local architecture (both HW and SW), henceforth there are not architectural differences. In my experience the header files in the source of a program are the place where you deal with architecture (HW/SW) difference. -- /\ ___Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_ African word //--\| | \| | Integralista GNUslamicomeaning I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso...Debian Warning: gnome-config-daemon considered more dangerous than GOTO -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21546.22637.760610.277...@mail.eng.it
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Tue, Sep 30, 2014 at 12:11:01AM +0200, lee wrote: Reco recovery...@gmail.com writes: About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I didn't have a server back then --- and software to run on my computer which worked fine until some change was made and it suddenly didn't work anymore. Curious. Can you remember the name of this software? Package managers told me that the problem won't be fixed and to install packages from experimental which wouldn't have solved the problem and couldn't be installed without more or less upgrading my system to experimental. They call it multiarch, I call it brokenarch. IIRC, that was before current stable was relased, and there was no chance that the problem would be fixed with the next stable release. The description is somewhat vague, and I can only assume that it was one of those funny packages contained i386 binaries marked as _amd64 arch. And you manage to hit an exact moment of transition from (in)famous ia32-libs blob to the multiarch. Painful, but those things don't happen in stable. Hence I needed a replacement for Debian and switched to Fedora. Leaving users stranded like this is a big no and has destroyed 15+ years of trust into Debian. Now they are planning to do something like that again by forcing systemd upon their users, proving me right in what I've been thinking when they suddenly enforced brokenarch: That something causing trouble to such an extend is likely to cause further trouble sooner than later. Ok, ok. We all got it already. S*stemd in Debian = bad. S*stemd in Fedora = good. Fedora has no xen, hence = bad. Debian has xen, hence = good. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140930135740.GA25948@x101h
xen: was Challenge to you: Voice your concerns regarding systemd upstream
On Tue, 30 Sep 2014 17:57:41 +0400 Reco recovery...@gmail.com wrote: Ok, ok. We all got it already. S*stemd in Debian = bad. S*stemd in Fedora = good. Fedora has no xen, hence = bad. Debian has xen, hence = good. Reco Reco, help me understand something: I don't understand why it matters what distro you chose for your xen dom0, or why it makes a distro better to have a dom0 xen kernel... My understanding of xen is it sits between the metal and your guest operating system(s). My understanding is there is a Linux host operating system, but its sole purpose is support of xen, and that's all it does. Here's a list of operating systems with xen dom0 kernels: http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen By the way, the preceding page states that Fedora, from v16 on, has a dom0 xen kernel. To my way of thinking, the dom0 OS isn't really being used as an OS at all: It's just an enabler for xen, and to my way of thinking, that means it has way fewer challenges than a normal OS. So if it uses systemd, so what? It's not like you have to worry about running Gimp or Gnome or KDE or various authentication facilities directly on it: It's a vehicle for xen, no more, no less. I went to a Xen talk, and as I remember the guy said Xen is developed and tested on Ubuntu, so that's your best bet. Yeah, Ubuntu will have systemd, but if it works for the xen people, it should work for us all. If one absolutely wants to avoid systemd, NetBSD has a xen kernel available. Unless I'm vastly misinformed, once your dom0 xen is installed, you can now install domU hosts of any type you want, with or without systemd, and use them to your heart's content. Am I understanding the situation right? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140930161641.257ab...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Du, 28 sep 14, 20:04:22, Slavko wrote: BTW, what you recommends is to change the DE due systemd, strange solution. I want the exact opposite solution - i want to change the (now default) init system due DE. And if you dont know why, then i will tell you - because most of my work is done in DE, then change DE is bigger change, than change the init system, which my system needs *only* at start. Have you even considered trying systemd? Don't worry, the first try is always free :) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
It is boiling hot here for days, and if you consider other similar topics, well then, for decades! I like that. It this going to bring some change to status que? Best ， He who is worthy to receive his days and nights is worthy to receive* all else* from you (and me). The Prophet, Gibran Kahlil On Mon, Sep 29, 2014 at 8:59 AM, Jeff Bauer jwba...@charter.net wrote: On Sun, 28 Sep 2014 18:57:12 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Change is life. There is nothing static in life. So all the fuss about wearing those grounded, anti-static wrist straps is just a hoax? -- hangout: ##b0rked on irc.freenode.net diversion: http://alienjeff.net - visit The Fringe quote: The foundation of authority is based upon the consent of the people. - Thomas Hooker -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5428aed6.8060...@charter.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Monday, September 29, 2014 2:40:02 AM UTC+5:30, Steve Litt wrote: On Sun, 28 Sep 2014 18:57:12 +0200 Martin Steigerwald wrote: Change is life. There is nothing static in life. How Eastern Philosophical. I may have to climb a mountain and fast for a month to reach your level of enlightenment. Heraklitus is the name usually associated with that philosophy. You consider him an Eastern philosopher? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d8863092-b141-4764-8f0c-f2ecb9dc2...@googlegroups.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Sun, Sep 28, 2014 at 03:21:13PM +0200, Slavko wrote: Ahoj, Dňa Sun, 28 Sep 2014 10:56:08 +0200 Martin Steigerwald mar...@lichtvoll.de napísal: But my challenge to all of you who don´t want systemd as default in Debian still is this: *Stop* complaining and *start* acting. You are right. For now it seems, that there is no chance to get DE without systemd in debian and no change is expected (at least) in near future. There's [1] at least. Not in Debian main archive currently, sadly. There's also [2] in testing, but it requires dbus (hence, parts of systemd). [1] http://sourceforge.net/p/cdesktopenv/wiki/LinuxBuild/ [2] https://packages.debian.org/jessie/e17 Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929094319.GA21917@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929094939.GB21917@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Monday, September 29, 2014 3:40:01 PM UTC+5:30, Reco wrote: Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). A recent question of mine: https://lists.debian.org/debian-user/2014/08/msg01394.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2b4d32af-17b9-439f-a490-3e6631e06...@googlegroups.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 05:49 AM, Reco wrote: Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know about him, but although I'm a big supporter of multiarch in general, I do know of one major thing which broke with the transition from the old arrangement: x86 builds on amd64 hosts. Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and ia32-libs-dev provided the matching header files. (Separate lib*32 packages provided other libraries, and matching -dev packages provided the matching header files for those other libraries.) With both of those together, and compiler options like 'gcc -m32', it was possible to compile code against 32-bit libraries in a 64-bit environment and then run the result in that same environment. Under multiarch, lib*:i386 packages provide the x86 libraries, and there is nothing which provides the matching header files. That sort of compilation task is no longer possible, at least not in a remotely trivial or automated fashion. Most of this isn't a problem in practice since you can build in 32-bit chroots and transfer the result to the amd64 host environment. But anything which needs to compile against both 32-bit and 64-bit libraries (such as a full-functionality Win32+Win64 Wine build) just isn't a thing anymore, AFAICT. I don't think that's sufficient justification for calling multiarch broken; it's just incomplete, and it has been acknowledged as such, and there has been progress (at least at the how-to-do-it-right spec level) towards addressing that deficiency. I therefore suspect that lee is referring to some other type of breakage which resulted, which I'm not aware of; it's not impossible that that breakage could, indeed, be addressed by just reading appropriate documentation. But that is one example of a complaint caused by (the in-practice Debian implementation of) multiarch which is not solved so simply, or indeed AFAICT at all without the cooperation of a multitude of library-package maintainers. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUKUd9AAoJEASpNY00KDJrG+AQAIeMcPNZ9zzW3mB3Nx3WY81g EDWGJ3kTuqnMQ6agA2j58fYEjvbBVQ5HniT4j/IwztbwX1bKCs2J+sSrj7E0nYZ2 BIx/1QRtknTK2Np1OTAWkszfxEW3rZTsTY6LIzmA3Q/e43AwipOk1Z1SwDEuVb6x 1x79gpnRodw2tAznQNU4Inpi1LhLXyE7rPuBSQP6mKahU677PQw/DuAmgS/ePihb DDE/hoI7/820C/DhEKzpPASFz5mscq8bjlCh6lUIXf+Ul4gVWxG0Q7oWKTCGdBmX +OQBjkCv6B+4DK3D0z8uB5x9WDj4j8i7EaXLQTVUXjZWY97g3lUbOXEgtREPHa8K JHsxegDSQmPaYCt2Sm432MjmMC8gKIzjbvUzkkTAvFJy+0GAVf/NOluTNT/yn2Hc 5lV1x+xJMwpmguLqGkpQ89r/PVgf2H5u/YHWEkQwbGc+TeVHPA1LibP0T/O4+8aa LtEWMOYLQPqkerDlkdIVpJDKo99OUIwodygqS9hKMFGJPXCGl0EX2eOsw/zi+Y0L bfHOCexe7bBQeYJv4fs4S//1dWluPjLI4QRKQ0E+FGMTIzf+lvlSEzmgE+FbR280 vtHl9RjRN/wl+DwNDaHW3GoWlQAiGf4bye6Hj+XUNfcgmpM+0TgYDk4jJ/7K7nRy P/jt12g/mqxb/K37jRjc =xYl2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5429477d.7030...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Mon, Sep 29, 2014 at 03:21:47AM -0700, Rusi Mody wrote: On Monday, September 29, 2014 3:40:01 PM UTC+5:30, Reco wrote: Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). A recent question of mine: https://lists.debian.org/debian-user/2014/08/msg01394.html A fine example of dependency bug, if you ask my option. I'd report a bug against a package which caused such abnormal dependency (i.e. same package with two different arches). Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929121633.GA24676@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
This came across another list, in relation to Apple's latest iOS update. It just seems so appropriate to the systemd discussion: However, for iOS major releases, almost immediately you start to see app updates that require the new iOS release. So at least for iOS, you're almost forced into major updates if you want to keep up with app updates. What a dynamic! Change all your plumbing or your electricity will soon stop working. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54294d7f.2060...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 05:49 AM, Reco wrote: Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know about him, but although I'm a big supporter of multiarch in general, I do know of one major thing which broke with the transition from the old arrangement: x86 builds on amd64 hosts. Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and ia32-libs-dev provided the matching header files. (Separate lib*32 packages provided other libraries, and matching -dev packages provided the matching header files for those other libraries.) With both of those together, and compiler options like 'gcc -m32', it was possible to compile code against 32-bit libraries in a 64-bit environment and then run the result in that same environment. Under multiarch, lib*:i386 packages provide the x86 libraries, and there is nothing which provides the matching header files. That sort of compilation task is no longer possible, at least not in a remotely trivial or automated fashion. Header files are arch-agnostic, it's the .la files that case all the trouble. Still, you're raising a valid point - compiling for several arches was possible before multiarch, and it's not possible now without chroots. I prefer chroots for this (less strange dependencies in the 'base' system), but YMMV. About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929144946.GB5206@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 10:49 AM, Reco wrote: Hi. On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote: On 09/29/2014 at 05:49 AM, Reco wrote: What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know about him, but although I'm a big supporter of multiarch in general, I do know of one major thing which broke with the transition from the old arrangement: x86 builds on amd64 hosts. Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and ia32-libs-dev provided the matching header files. (Separate lib*32 packages provided other libraries, and matching -dev packages provided the matching header files for those other libraries.) With both of those together, and compiler options like 'gcc -m32', it was possible to compile code against 32-bit libraries in a 64-bit environment and then run the result in that same environment. Under multiarch, lib*:i386 packages provide the x86 libraries, and there is nothing which provides the matching header files. That sort of compilation task is no longer possible, at least not in a remotely trivial or automated fashion. Header files are arch-agnostic, it's the .la files that case all the trouble. I'm afraid that's not always the case. I've encountered specific cases where the headers are different between architectures. Still, you're raising a valid point - compiling for several arches was possible before multiarch, and it's not possible now without chroots. I prefer chroots for this (less strange dependencies in the 'base' system), but YMMV. If I'm reading you right, strange dependencies only matter when you're going to install what you've compiled on a machine other than the one where the build was done. For the use case of test-building (and test-running, and in some cases installing and actively using) the upstream development tree, that doesn't particularly matter; there are exceptions, but for the most part, doing that type of build on a different machine from where the resulting binary will be used is pretty much unheard of. About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I did say that I didn't think lee was referring to this same type of breakage. This was just an example of a multiarch complaint such as you said you had not seen so far; there's nothing saying it's the only such. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUKXq3AAoJEASpNY00KDJrsIgP/1Rw4F1yf17n04XXSKwqfphv KMfgANZKQUD55ykm0jxYEfpXVVTaCCP1c+Y8wIrdqAwX7nIGrZX2I7jF4PmEDVG+ FQK1xvrz/uMYag0xDNUYxRmxMO7/gMQF5AXmfFbWNDdJ8/DqdCMw7ZMRi7Prt/Dc a22gjUA6K+CLsBqj78Xm7/3qzBihQ/wIJ+kfixTC260v7OKDA/Vmd1Kg+5JeANW6 VfaZKc8M7eXwtb9KD9n+woykPRw/FqTY4YeUCYmnoPUVFPV8avOUrMV8siW/p27c p8HOvyfRf+8lN90zBxSFupUb/6b69nLGsyslBA2pCoDhMWYlCbLch4FHxme2jQfp lFaDKyYe5o8KHDSaGRMT6ar/y/LFEDAq0Cmd+kqWQT/9dOuQTEH7WT5d5x0EcfgS EyPLC2JSkRK1PA8CR3m4woyvac34B66zjU3lBQWx7mNHjOC08l1HVhERmjT+r+Ws sd5crbxWLIe7tTOXtRVhURhJpfZTZYdS7PM4nzAeAKNAgtNVmWzUA2MrzybeY7qB gJJtOxiOKlX93aGCqymHh9744+XMmiKX2h3YqM6b7Bl/YHGZA71pBCsrAs+uzt5G TJSodZzThnFXtZSzqIUkitWmckSV4OSM6xE8X5SGPl/V1Lc/+8aTWznVcXT7h1hr odNsAzlCKqUCUT4QOx5o =ISaH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54297ab7.90...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco wrote: Hi. On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 05:49 AM, Reco wrote: Hi. On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know about him, but although I'm a big supporter of multiarch in general, I do know of one major thing which broke with the transition from the old arrangement: x86 builds on amd64 hosts. Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and ia32-libs-dev provided the matching header files. (Separate lib*32 packages provided other libraries, and matching -dev packages provided the matching header files for those other libraries.) With both of those together, and compiler options like 'gcc -m32', it was possible to compile code against 32-bit libraries in a 64-bit environment and then run the result in that same environment. Under multiarch, lib*:i386 packages provide the x86 libraries, and there is nothing which provides the matching header files. That sort of compilation task is no longer possible, at least not in a remotely trivial or automated fashion. Header files are arch-agnostic, it's the .la files that case all the trouble. Still, you're raising a valid point - compiling for several arches was possible before multiarch, and it's not possible now without chroots. I prefer chroots for this (less strange dependencies in the 'base' system), but YMMV. About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I do it all the time. Packaging of some of the things we run on our list and web servers tends to run behind upstream, sometimes by quite a bit. ./configure; make install is pretty much as easy as apt-get install As a general rule, I find that I use packaged software for all of our base capabilities (utilities, dns, time, and so forth), and build from upstream source for the production systems. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54297dec.1090...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Mon, Sep 29, 2014 at 11:28:55AM -0400, The Wanderer wrote: Header files are arch-agnostic, it's the .la files that case all the trouble. I'm afraid that's not always the case. I've encountered specific cases where the headers are different between architectures. Hmm. Kernel headers come to mind, but for typical userspace headers that's unusual. Still, you're raising a valid point - compiling for several arches was possible before multiarch, and it's not possible now without chroots. I prefer chroots for this (less strange dependencies in the 'base' system), but YMMV. If I'm reading you right, strange dependencies only matter when you're going to install what you've compiled on a machine other than the one where the build was done. Yup. That's my usual 'modus operandi' since I've learned how to build a Debian package. For the use case of test-building (and test-running, and in some cases installing and actively using) the upstream development tree, that doesn't particularly matter; there are exceptions, but for the most part, doing that type of build on a different machine from where the resulting binary will be used is pretty much unheard of. On the contrary, it's a viable practice once you take into account a simple fact - there's more than one processor architecture, and sometimes you use several of them. For example, try compiling a kernel on ARM system. Try cross-compiling the same kernel on a conventional x86 system. Compare build times. Unless you have an Intel Atom instead of CPU - cross-compilation wins. About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I did say that I didn't think lee was referring to this same type of breakage. This was just an example of a multiarch complaint such as you said you had not seen so far; there's nothing saying it's the only such. Point taken. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929160352.GA9410@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi. On Mon, Sep 29, 2014 at 11:42:36AM -0400, Miles Fidelman wrote: About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I do it all the time. Packaging of some of the things we run on our list and web servers tends to run behind upstream, sometimes by quite a bit. ./configure; make install is pretty much as easy as apt-get install Well, 'make install' was always easier compared to the 'apt-get install'. 'apt-get upgrade' and 'apt-get purge' are usually hard to implement Slackware-style :) As a general rule, I find that I use packaged software for all of our base capabilities (utilities, dns, time, and so forth), and build from upstream source for the production systems. I hear you, but your example is somewhat incomplete. How often do you run into problems that can be attributed to the multiarch? Is there any valid usecase in mixing binaries from different architectures on a single server (without virtualization, of course)? Is there anything in current Debian's multiarch implementation that contradicts your current compile-from-the-source practice? Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929161210.GB9410@x101h
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 12:03 PM, Reco wrote: Hi. On Mon, Sep 29, 2014 at 11:28:55AM -0400, The Wanderer wrote: Header files are arch-agnostic, it's the .la files that case all the trouble. I'm afraid that's not always the case. I've encountered specific cases where the headers are different between architectures. Hmm. Kernel headers come to mind, but for typical userspace headers that's unusual. It's been long enough since I was working with this (due to the same lack of multiarch support for it) that I've forgotten the details of which libraries were involved, unfortunately. I think libjpeg was one of them, but I can't swear to that. Still, you're raising a valid point - compiling for several arches was possible before multiarch, and it's not possible now without chroots. I prefer chroots for this (less strange dependencies in the 'base' system), but YMMV. If I'm reading you right, strange dependencies only matter when you're going to install what you've compiled on a machine other than the one where the build was done. Yup. That's my usual 'modus operandi' since I've learned how to build a Debian package. Whereas I'd pretty much never consider building a .deb for an upstream-development-tree compile, rather than just 'update_vcs_command ; ./configure --options ; make ; make install'. The extra intermediary steps to get a functional debian/ directory in place in the VCS tree, and maintain it against changes in upstream code, just make any potential advantages not worth the trouble for potentially-frequent test builds, IMO. For the use case of test-building (and test-running, and in some cases installing and actively using) the upstream development tree, that doesn't particularly matter; there are exceptions, but for the most part, doing that type of build on a different machine from where the resulting binary will be used is pretty much unheard of. On the contrary, it's a viable practice once you take into account a simple fact - there's more than one processor architecture, and sometimes you use several of them. For example, try compiling a kernel on ARM system. Try cross-compiling the same kernel on a conventional x86 system. Compare build times. Unless you have an Intel Atom instead of CPU - cross-compilation wins. That's one of the exceptions I was talking about. It doesn't apply nearly as much in the x86 vs. amd64 case, however, which is the main one I was dealing with. (That case is also special in other ways, since it's one of the few where you can reliably expect to run the foreign-arch code directly on the host where you do the build.) - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUKYorAAoJEASpNY00KDJrO1MP/RbhuTBdi360doHIvHl780DS wpr2rCQxO7gCas0HAa0LQUVaiXrF2snp3q6pPfP2x3qsLxZkBgaLSR3ghaCnZNlR ZWuWXF94JoGcBdGZI3/dAtQ4cpbXPqH39vh3cSAgAbMM6zaOE0wW2gAZlqyfuSNN CW7w1leEx/Kv3/DY3JollJOzta69wue4AUUqOHYNgjvqj3Rom3HTC2Ifq4BYj3xW 70lugxKY53R1pHWU/0uKeu4M47qLcbs09cyP0FPbUzSxITyLMy96Cob9mcx3lN4o ChJq+MKpJ0Rc2aE8Yx2kn9lR6BBAl3Wxh3SfNU/Ug6o8yYA6ap/gEcQvWYCA8is2 JwvUtc+uDHH7keeEvHhOs3cYBx5QzNh4ZtAv+M1TL8lIAW4chEsi3v0Lxq5mrDqG EwqkIGmOxUkYI5ZfdB9CQptzHBPzmohvec56yi3ZNAkfjqf8ZCoZ7uUY3Rc7M/7E Z19tIl7dvBbQX4Cuq6mt6pVBRib6JemRhjdxA2JilXV9KTg/5NEse6lsrvWHZC+q cjLMEloAJvGaazRy8XsBlLTPXBCFqrSegmf8n6JrhcxDqe7qDX7tpIPL98Rc0/Fe 0iTX2TeDISC2ZyC46RM0pR/k5Os+EAcmcKlmbe4ytuzEcMZpJNzRAoVfOrf9HUR2 SGMoYEPVHyxsdxkCURfC =J4e8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54298a2b.6010...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco wrote: Hi. On Mon, Sep 29, 2014 at 11:42:36AM -0400, Miles Fidelman wrote: About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I do it all the time. Packaging of some of the things we run on our list and web servers tends to run behind upstream, sometimes by quite a bit. ./configure; make install is pretty much as easy as apt-get install Well, 'make install' was always easier compared to the 'apt-get install'. 'apt-get upgrade' and 'apt-get purge' are usually hard to implement Slackware-style :) As a general rule, I find that I use packaged software for all of our base capabilities (utilities, dns, time, and so forth), and build from upstream source for the production systems. I hear you, but your example is somewhat incomplete. How often do you run into problems that can be attributed to the multiarch? Is there any valid usecase in mixing binaries from different architectures on a single server (without virtualization, of course)? Is there anything in current Debian's multiarch implementation that contradicts your current compile-from-the-source practice? Well.. it's mostly irrelevant, since I compile on the machine that I run on. Pretty much anything that's been built with the gnu tools will detect and deal with architectural dependencies. The real downside of compiling from source is manually dealing with dependencies. Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54298eee.10...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/28/2014 06:00 PM, Chris Bannister wrote: On Sun, Sep 28, 2014 at 01:48:47PM -0700, koanhead wrote: On 09/25/2014 05:00 PM, Chris Bannister wrote: On Thu, Sep 25, 2014 at 03:15:36PM -0700, koanhead wrote: I'm aware of BSD-style init, but the mailing-list thread [1] I posted [1] reference is missing. Yikes. Sorry about that. Here it is: https://lists.debian.org/debian-bsd/2014/02/msg00135.html indicates that Debian GNU/kFreeBSD doesn't use it but instead uses sysvinit ... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m0coau$5p7$1...@news.albasani.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/28/2014 09:28 AM, Nate Bargmann wrote: * On 2014 28 Sep 08:23 -0500, Liam Proven wrote: On 27 September 2014 03:45, Joel Rees joel.r...@gmail.com wrote: edumaction? I saw that and checked the headers, because what you are writing here seems a bit out of character. If this is a spoof, the headers are done better than I want to bother checking, unless you tell me so. Typo, I think. Naww, self deprecating humor. - Nate Thanks Nate! You get the prize behind door number 2! :) Ric -- My father, Victor Moore (Vic) used to say: There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome. R.I.P. Dad. Linux user# 44256 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5429ecb1.2070...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco recovery...@gmail.com writes: What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know what the current state of either is other than that there are a lot of packages in Debian that depend on some multiarch package for unknown reasons. It doesn't matter anyway because the current state won't make any better what happened. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mvq9jxm@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ansgar Burchardt ans...@43-1.org writes: If you don't want to use Debian then don't. But if you don't even want to use it, making lots of complaints about it seems uncalled for... There is a difference between using something because it works and using something because you want to use it. In none of the cases there is any particular reason not to point out disadvantages of what you're using or to complain that someone complains in order to shut them up. When you look at [1], you even find people claiming that there has been a takeover of Debian and an abuse of the technical committee, and that silencing of people questioning systemd and Debians' ways is going on. [1]: http://www.debianuserforums.org/viewtopic.php?f=63t=3031 Yeah, probably the same person as [2] and [3]. Shocking that he gets banned time and time again... Who knows ... [2] https://lists.debian.org/debian-ctte/2014/03/msg3.html [3] https://lists.debian.org/debian-ctte/2014/02/msg00394.html -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ul29k2r@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Reco recovery...@gmail.com writes: About the only thing that I'm missing here is why would anyone should compile anything on a production server, Xen's dom0 specifically (as it seems to be the main lee's concern). I didn't have a server back then --- and software to run on my computer which worked fine until some change was made and it suddenly didn't work anymore. Package managers told me that the problem won't be fixed and to install packages from experimental which wouldn't have solved the problem and couldn't be installed without more or less upgrading my system to experimental. They call it multiarch, I call it brokenarch. IIRC, that was before current stable was relased, and there was no chance that the problem would be fixed with the next stable release. Hence I needed a replacement for Debian and switched to Fedora. Leaving users stranded like this is a big no and has destroyed 15+ years of trust into Debian. Now they are planning to do something like that again by forcing systemd upon their users, proving me right in what I've been thinking when they suddenly enforced brokenarch: That something causing trouble to such an extend is likely to cause further trouble sooner than later. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjdi84cq@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Mon, 29 Sep 2014 23:46:04 +0200 lee l...@yagibdah.de wrote: Ansgar Burchardt ans...@43-1.org writes: If you don't want to use Debian then don't. But if you don't even want to use it, making lots of complaints about it seems uncalled for... There is a difference between using something because it works and using something because you want to use it. Not only that, but this is an unusual case. It's not like we did our shopping, didn't like what we saw, and bitched about it. We had an operating system, somebody vastly altered it, some of us see the vast alterization basically breaking the software, and we bitched about having someone, even though they're developers, break our software. Time (like 3 or 4 years) will tell whether we were spot on or whether we were Chicken Little, but if we were right, Debian will *never* be able to assume its former role, and as a matter of fact, the way things are going, that can be said for all of Linux. So actually, I hope I'm wrong. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929213517.75aa2...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2014 at 05:49 PM, lee wrote: Reco recovery...@gmail.com writes: What's wrong with the current multiarch implementation in your option? I'm really curious as all multiarch complains I've seen so far (barring actual package limits) were easily solved just by reading an appropriate man page (or Debian wiki page). And, IMO, Debian's current multiarch is way more flexible than current Fedora's one. I don't know what the current state of either is other than that there are a lot of packages in Debian that depend on some multiarch package for unknown reasons. Can you give any examples? I thought cross-arch package dependencies were still forbidden, as of the last time the subject came up on -devel or -policy, largely for the reason that you can't guarantee that the foreign architecture in question will be enabled on any given user's system. It doesn't matter anyway because the current state won't make any better what happened. I'd be interested in details of what you saw happen when multiarch was introduced, beyond the still limited summary form you've provided in another mail. It doesn't seem to match anything I saw, or anything I've previously seen anyone report having seen. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUKhwEAAoJEASpNY00KDJr8pYP/0qJCiXOcUmnHQcs1Cw5w6fa MU7xfkR8yDXUfA5fzCCj18HU7xNJRsT/FM2c4S/bhGNfWlkL+1BOeTAdJ1Ay+Hfc /PQDW9UzcfjZ0Bhtbxa3YY1E+ovcJYcn0s8PfFmRDqbi+Z26z25a0BBlByqZ8v/C gcJjNzakpaNk/PIlMVa6x59OpoEWi7efPhu/4yiMCXDmtNfVf4k+eRJh0eIAbbXt IkvkvmHWbRoo5DvFtgCyFtmKlzDjnwOBpXquqKaMa7ONOT+TAfWJcfuQ0rpZCEv5 pv4y0NqEtEpJbUThDYFnm52ZmD2ePKUHSmB6LjKZfRjtg30WI9+rUsXaZVWv5iWV nd3Xr7L6e3j/02XXJYjr8y4wTVA0Dq0u7HQrxDIy9e/8w1IV87dvb5A63nYPW+uO k8W5ykg8KSltgsxyRHa1cxL83LQpFWzF3wGoa3Cf9eUZn0DkyOBtyD3q/QxkiZVu Wc/TIBsE0yPilyHJETnGM4ulsEd65pdjg6R0SDj/PFoXdg53MMymGjOhnA1Ee8vl ofq9YbXTQobi18ajx76KWU34d80hgiQO4HUjhW2JgTKVwJFqal7u6AKoxRf9lKw1 m27+JOKVRlsq+vdLO98+o3uT5weF/Fx47GiCHHV2RhJDE/VfFQSORgIfRxNlWmEc nmd7gQohtSnlvZLQdibJ =VaKM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542a1c04.9060...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Mon, 29 Sep 2014, Rusi Mody wrote: A recent question of mine: https://lists.debian.org/debian-user/2014/08/msg01394.html This is because upower is architecture:any, but cannot be co-installed with another version of upower. If the dependency on upower is reasonable, but as long as upower is installed for any architecture, it works, then upower might need to be made Multi-Arch: foreign. But this is a recommends anyway, so it can be safely ignored. -- Don Armstrong http://www.donarmstrong.com Because, Fee-5 explained patiently, I was born in the fifth row. Any fool would understand that, but against stupidity the very Gods themselves contend in vain. -- Alfred Bester _The Computer Connection_ p19 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929182032.gb14...@rzlab.ucr.edu
Re: Challenge to you: Voice your concerns regarding systemd upstream
Hi Miles, Am Freitag, 26. September 2014, 11:09:07 schrieb Miles Fidelman: Martin Steigerwald wrote: Am Donnerstag, 25. September 2014, 01:45:50 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Am Montag, 22. September 2014, 23:50:46 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Do you really think they will be able to prevent all the other software from depending on a particular init system or parts of it? Well… thats to be taken upstream, isn´t it? Then why don't the developers or the distributions do just that? Nobody cares when one user or another questions whether it's a good idea to depend on systemd, and it might be much different if a lot of developers and/or whole distributions would, in the interest of their users, question this dependency and refuse their support eventually until the issues systemd and software depending on it brings about. […] Fedora does already depend on systemd --- and I would say completely. Or do you see a choice here? And exactly *how* is this relevant to Debian? And still I think its important to take this upstream. Upstream, from the users point of view, are the makers of the distribution in the first place. I can't very well make a bug report against systemd directly because Debian has decided to support it, can I. That's not a problem of systemd. To get involved with everything seems to have been a design decision of systemd. What do you expect will happen when I make a bug report directly against systemd, explaining them that it's broken by design? Or should I make a bug report against the X server because it depends on systemd? Or the other way round? Or perhaps against cups instead? Or to *help*. Make a logind that does not depend on systemd. Offer it to the upstreams that need it. I'm sure it would be ignored or rejected --- even if I had the knowledge to make anything like that and was able to keep up with what other ppl are doing. I do think that you don´t want change. You expect distro developers to fix it for you. You are not willing to take things upstream. So let's see: - the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers - systemd seems to have some rather frequently changing APS's - to the extent that systemd-shim lags well behind - but the resulting impacts should be taken up with each and every upstream developer? Somehow that doesn't sound right. On any account: If you think its better to bring this up with debian developers, by all means do it. If you think its better to do xyz instead of my suggestion, by all means do it. But my challenge to all of you who don´t want systemd as default in Debian still is this: *Stop* complaining and *start* acting. For the reasons I explained in what I think crystal clear words that I do not feel like repeating here again. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1989516.SXxv4O1Ouh@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Freitag, 26. September 2014, 14:51:01 schrieb Miles Fidelman: John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Oh, the same way I could say: I am forced to write init scripts for a package. As I recently just did: And guess what: On writing a debianized variant of the atopacctd initscript where the upstream initscript actually caused lintian warnings I clearly learned about the limitations of it. Look at it [1] and tell me how you like that it unconditionally kills any process named atopacctd and the PIDFILE variable is not even used anywhere in the script. I´d have a clear word for that: crap. Now you can argue upstream needs to implement PID file handling for a double forking daemon. But I make is a case now that systemd needs *less* care of upstream, rather than more. It forces *less* on upstream than sysvinit for best practice. With systemd upstream doesn´t have to change the actual implementation of the daemon. And even without a service file it will just use the initscript anyway, with the same limitation then. [1] https://github.com/teamix/atop-debian/blob/master/debian/atopacct.init Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4908539.RHXGUvsFBi@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Freitag, 26. September 2014, 13:08:50 schrieb The Wanderer: On 09/26/2014 at 12:44 PM, Martin Read wrote: On 26/09/14 16:09, Miles Fidelman wrote: - but the resulting impacts should be taken up with each and every upstream developer? As far as I can see, the issue that people are suggesting should be taken up with upstream developers is application XYZ has annoying and seemingly unnecessary dependencies on interfaces of systemd, making it hard to keep systemd off my systems. The trouble with recommending to take that upstream is that it's entirely legitimate for a program to depend on externally-provided interfaces, and indeed in the conceptual ideal a program should neither know nor care what provides those interfaces. It would be better, from a design perspective, to fix the unnecessary dependency problems at the core - that is, in systemd - rather than requiring all of the upstreams to make changes in response to changes in systemd. Only if systemd upstream will be uncooperative, and refuse to fix the problems, would taking it to the multiple upstreams make sense - and even then, forking systemd or providing another source for the systemd interfaces would probably be a better solution. (Though still not as good as fixing the design at the core.) I didn´t suggest to take this upstream to projects utilizing systemd only. I just suggested taking it upstream. Whatever upstream seems approbiate to take it, by all means do it. Also if the upstream is systemd. I started a thread voicing my concerns about the polarity and resistance systemd seems to create. But again: If you just insist on complaining here *only*, *nothing* and I repeat *nothing* will ever change about anything what you dislike about systemd. So if you *really* want change, you *act*. Its *that* *simple*. Take is upstream with systemd, take it upstream with GNOME for logind, take it upstream with ConsoleKit developers if there are any left. Help uselessd developers, test their variant of systemd, help systembsd people, offer to package it for Debian, organize a vote and present the hypothetical big majority for not having systemd as a default in Debian to debian developers… … but by any means if you really want change, do something that facilitates it. Now I will talk myself into stopping replying here. I made my point and I think it is best for me to filter the threads and hope that the group (thread) ignore feature in KMail works okay now, or report a bug about it, if it does not. If you want to continue to misunderstand me or take my words too literally, if you want to continue to rationalize in order to resist going farer than just complaining, thats your choice, but please leave me alone with it. (Well thats my job, and I work on it. By trying out the group ignore feature next.) -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1817112.SdLmvI8TFu@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Freitag, 26. September 2014, 19:08:13 schrieb Ric Moore: On 09/26/2014 05:08 PM, green wrote: Ric Moore wrote at 2014-09-26 14:18 -0500: Change is certainly needed when any pimple face kid can edit and hide his doings from a text log with nano. I think the change is necessary to harden up our systems. Otherwise, Microsoft will become the only secure server OS, as they don't mind hiding things at all. So, all other things being equal, binary logs are more secure than plain text logs. Is that actually what you are saying? Yes. The benefit of using a binary log is the lesser vulnerability to an external attack from an intruder. That huge security flaw was mentioned on a recent PBS video regarding the new day Hackers and how simply they removed/edited text-log files to hide their tracks of what they did. I think I read on uselessd site, that rsyslog has a signing feature meanwhile. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/17453900.1PNaJrGDDq@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Samstag, 27. September 2014, 22:04:38 schrieb lee: Andrei POPESCU andreimpope...@gmail.com writes: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? https://bugzilla.redhat.com/show_bug.cgi?id=990177 Thank you for sharing that actually did something about an issue you had with systemd. I found systemd closing bug reports, I thought to be valid, but OTOH they also fixed an issues that Michael Biebl brought to them from one of my Debian bug reports. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/47086284.FMK7snKTYd@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Samstag, 27. September 2014, 22:13:21 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. Your assumption is wrong. I appreciate change for the better, not for the worse, and in case of systemd, I don't believe that there is any way to change anything about it. So you just complain here over and over again to vent your frustration? If you do not believe systemd upstream is willing to help with the change you want to see, there are endless other ways to help to facilitate changes. I listed some here in other posts: Organize a vote and present result to upstream developers, install systemd-shim and cgmanager and test it, install init-select and test it, install openrc and test it, help systembsd people, help packaging it for Debian once ready or help find a packager… start affirming daily for changes to happen and… and… and… So I still stand by it: If you remain in *complaining* and continue to resist *something* about what you want to see as a change… you effectively don´t want change. Your bug report regarding systemd is a start. There are other options. I repeated them here again. And no, I don´t want to hear rationalizations why none of my suggestion can work at all. This is still free software, this is still open source, this is still forkable, there are *tons* of option for helping change. Maybe some my not be as comfortable as you wish… but helping with change often needs *some* effort. Go ahead and prove me wrong. Why? Why do think I would waste my own time like this? I decided to give systemd a chance on my systems and see what this brings me. I decided for a practical approach. And so far the systems I installed it on didn´t explode or anything like this. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2613725.LTvWzHUfLG@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Samstag, 27. September 2014, 22:55:36 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Why do I think that you do not want change from the *current* situation? Cause what you do, in my oppinion does not facilitate change. I think I see why you think so. What makes you think that anything you or I could do would change anything? Cause I believe you are as powerful as anyone else here. Really powerful. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2028624.Sbgz5xjMjs@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Sonntag, 28. September 2014, 04:35:03 schrieb lee: Martin Read zen75...@zen.co.uk writes: On 27/09/14 21:04, lee wrote: https://bugzilla.redhat.com/show_bug.cgi?id=990177 Your complaint about the interface is reasonable. The systemd developers' decision to not change the interface in response to your complaint was also reasonable. I never said it was totally unreasonable. I'm saying it would probably be easy to fix and that they simply don't want to. If they wanted to, they could and would. It is still *one* bug report tough. Yes, I know there are others, systemd developers closed as won´t fix. Yet, look around a bit: That is true for *any* bigger software project I have seen so far. Lots of won´t fix bug in KDE´s bugzilla as well for example. And I do not always agree with the decisions. So acting for change, you may meet resistance. But that initially resistance is just that… an initial response towards change. A even natural response. Yet it does not mean that change is impossible. Quite the opposite is true. I have seen systemd upstream and also systemd debian developers acting on bugs and fixing them. Yes, I was frustrated with some of the reactions of Michael Biebl for example, closing bugs quickly without resolving them, but first I found my tone at that time to be contributing to that outcome, and second after I pleaded to him in one bug report not to close it immediately, he didn´t close it… and… we worked together on some other issues. He told me what about he needs and I gave it to him. Was it an easy ride for me? No. For him? I bet not. But that way I have facilitated some change. It may also be true that systemd upstream won´t be willing to implement the change you want to see. But if you choose to keep your power with yourself, instead of giving it to others, you are still powerful, even in that case. An there are other options to create change. I also still believe that if systemd developers did completely off the limits think, they would quickly be forked. I also believe that if Linus messed up horribly with Linux developers, someone would start a Linux kernel fork. So I believe there is quite some peer review with systemd stuff and there is some real agreeing to they way it implements thing. And there are alternatives of which you may to choose any of them. A co-worker goes with sysvinit, systemd and cgmanager cause he dislikes systemd. I encouraged him to. This way I find bugs in systemd stuff as I chose to give it a chance, and he finds bugs in the alternative. You are free and powerful to do something like that and I highly encourage you to do it. Its still about choice in Debian. Jessie will support alternative init systems. And you can help with that. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7263586.nK0vUN3ayF@merkaba
Re: systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
Am Freitag, 26. September 2014, 23:21:36 schrieb martin f krafft: also sprach Steve Litt sl...@troubleshooters.com [2014-09-26 18:26 +0200]: If systemd was just a PID1 with the features you enumerate above, I'd be dancing in the street, not looking for a way out. Beautiful. I had to: https://twitter.com/martinkrafft/status/515611660128903170 ;) Concern noted, and agreed I am also vary of the sheer size of the systemd executable. 1,3 MiB are you serious? I want to ask and probably will ask on systemd devel. But it for sure would help I think if I weren´t the only one debian-user subscriber voicing concerns there. And again I suggest to look at uselessd. Maybe you want to package it? I may even try it out. I am not sure I feel experienced enough yet to package it myself. And I decided to give systemd a chance. To take my partly theoretical concerns like oh this is big and does a lot aside for a moment and actually *experience* first how it behaves in practice. And to that I had much less issues than I had with PulseAudio. On my own systems still no PulseAudio, as I still have problems when I use PulseAudio that simply *go away* on purging it. Last was with OpenAL games sound with gaps in it. And I voiced quite some of my issues partly loudly to PulseAudio upstream and there I much more had the impression that I get thats not a usual usecase, go away kind of answers, than so far I had with systemd debian packagers and systemd upstream. I even think: systemd debian packagers have quite some pressure to prove now that systemd as a default is going to work nicely for Jessie. I think this is an invitation to file any bug or erraneous behaviour you see. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/28/2014 at 05:34 AM, Martin Steigerwald wrote: It may also be true that systemd upstream won´t be willing to implement the change you want to see. But if you choose to keep your power with yourself, instead of giving it to others, you are still powerful, even in that case. An there are other options to create change. I also still believe that if systemd developers did completely off the limits think, they would quickly be forked. The trouble with that is that some (many?) people think they already *have* done completely off-limits things, and yet many other people are arguing that those things are not completely off-limits, and/or that their benefits outweigh that beyond-the-pale status. As I've said from fairly early on (on debian-devel, not here), there are fundamental philosophical differences about software design between the sides here - under and below any differences in what currently-manifesting practical behaviors each side does or does not consider a problem. (Those differences go beyond just people who object to systemd vs. the systemd developers, by the way. They also extend to people who object to systemd vs. people who think there's nothing wrong with systemd, and/or people who may see things wrong with systemd, but don't think there's anything wrong with its being (made the default / installed automatically), et cetera.) - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUJ/YxAAoJEASpNY00KDJrNToP/1Bn/etiQtZZwuCUfFLatnNG LTuYdn5Ar8T9lhxhkQh2brdiBorx1mBlJh93/xQm83YcHtv8P2PJz6gA9h1UDG3q HYiL4uV2Dvol7rNboG0N51C5/1UtRP6YDOt143pbZWgXP5C3mK/8XKJa0gsOp4Ul Cr5s3ju+AhTKatHMfUiqjL9Oh7SnpOpFPxRuBNKZWCIv76WY9GXS1MQyR2LRZ98W UJhURFgS0EtgD8z1DuMvHkTzj0/ZQadDk6dagElTSzu9cCRDeD1aGIRAc0Ht91/B PCku5O+TKSLXozbRGFLHrAkNolUOFRkKVgmql4QlgmD7BM6yjsCARdQZ0F3C/AKc LwZU2AIq72FwVyPuB93ZGxCq4NeqDuHEwlVt0uix9Ilgl2sOfnUcmZk29AOoC15t Ly2zY6r1taq9bX6br7lNCtua5+TVLCVMzq62xIkRCxg+LiYLzAqHT89/cmVQFdFd NQEYK+nunCFR5Ni8YXnbTpUIVKrPu96HY9NTLXzKyUpdTsXQa7E1e5UwkZIeyISk 06KC6hQ8npeC57xqK7uhLRaMl53beld1NiaTJvaElgmKjOpyVJv7rRKSO67TbGUh y2Jr1GvINQE7TCjP8U9YGW5xQIZIC/hYw5JHh0g8ZTDxqPkTaySxUjGPg37QesZL a2Nz2XDGRkh4dNHuBC1Y =dhNI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5427f632.4090...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Sonntag, 28. September 2014, 07:51:14 schrieb The Wanderer: On 09/28/2014 at 05:34 AM, Martin Steigerwald wrote: It may also be true that systemd upstream won´t be willing to implement the change you want to see. But if you choose to keep your power with yourself, instead of giving it to others, you are still powerful, even in that case. An there are other options to create change. I also still believe that if systemd developers did completely off the limits think, they would quickly be forked. The trouble with that is that some (many?) people think they already *have* done completely off-limits things, and yet many other people are arguing that those things are not completely off-limits, and/or that their benefits outweigh that beyond-the-pale status. As I've said from fairly early on (on debian-devel, not here), there are fundamental philosophical differences about software design between the sides here - under and below any differences in what currently-manifesting practical behaviors each side does or does not consider a problem. (Those differences go beyond just people who object to systemd vs. the systemd developers, by the way. They also extend to people who object to systemd vs. people who think there's nothing wrong with systemd, and/or people who may see things wrong with systemd, but don't think there's anything wrong with its being (made the default / installed automatically), et cetera.) I believe that if there are enough people with those concerns who decide to act, there will be an alternative to systemd. Its as simple as that. It always worked this way in free software. So it always comes back to the challenge I called out for. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2215491.86l1WybV0M@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 27 September 2014 03:45, Joel Rees joel.r...@gmail.com wrote: edumaction? I saw that and checked the headers, because what you are writing here seems a bit out of character. If this is a spoof, the headers are done better than I want to bother checking, unless you tell me so. Typo, I think. http://www.urbandictionary.com/define.php?term=edumacation http://www.urbandictionary.com/define.php?term=Edumacated http://www.urbandictionary.com/define.php?term=edumacate -- Liam Proven • Profile: http://lproven.livejournal.com/profile Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camtenchroof2upw8wzgm5qnqjfkqjof2odovny++cgdenc_...@mail.gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ahoj, Dňa Sun, 28 Sep 2014 10:56:08 +0200 Martin Steigerwald mar...@lichtvoll.de napísal: But my challenge to all of you who don´t want systemd as default in Debian still is this: *Stop* complaining and *start* acting. You are right. For now it seems, that there is no chance to get DE without systemd in debian and no change is expected (at least) in near future. Then i test two scenarios now: 1. switch to another distro - for now i am testing funtoo, if is here possible to have all my apps chain without systemd and it seems, that it is possible (BTW it is my first attempt with sourced distro) 2. stay on debian and maintain own versions of the packages, which (useless for me) depends on the systemd – i tried it with dbus and it is possible, but i afraid, if my system's knowledge will be enough with all needed packages. I afraid too, that the 2. will not be a temporary task and number affected packages will be grow, then i don't think, that it is real solution for me. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
* On 2014 28 Sep 08:23 -0500, Liam Proven wrote: On 27 September 2014 03:45, Joel Rees joel.r...@gmail.com wrote: edumaction? I saw that and checked the headers, because what you are writing here seems a bit out of character. If this is a spoof, the headers are done better than I want to bother checking, unless you tell me so. Typo, I think. Naww, self deprecating humor. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928132857.gp4...@n0nb.us
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sun, 28 Sep 2014 11:02:35 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Am Freitag, 26. September 2014, 14:51:01 schrieb Miles Fidelman: John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Oh, the same way I could say: I am forced to write init scripts for a package. As I recently just did: The difference being that the Linux *you* originally moved *to* required init scripts. Nobody changed everything on you. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928111822.08305...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201409281635.09993.lisi.re...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sun, 28 Sep 2014 15:21:13 +0200 Slavko li...@slavino.sk wrote: Ahoj, Dňa Sun, 28 Sep 2014 10:56:08 +0200 Martin Steigerwald mar...@lichtvoll.de napísal: But my challenge to all of you who don´t want systemd as default in Debian still is this: *Stop* complaining and *start* acting. You are right. For now it seems, that there is no chance to get DE without systemd in debian and no change is expected (at least) in near future. Then i test two scenarios now: 1. switch to another distro - for now i am testing funtoo, if is here possible to have all my apps chain without systemd and it seems, that it is possible (BTW it is my first attempt with sourced distro) 2. stay on debian and maintain own versions of the packages, which (useless for me) depends on the systemd – i tried it with dbus and it is possible, but i afraid, if my system's knowledge will be enough with all needed packages. I afraid too, that the 2. will not be a temporary task and number affected packages will be grow, then i don't think, that it is real solution for me. regards Don't forget to try the various BSDs. As long as your BSD can run qemu or another VM, you can use Debian for that one or two programs that don't work under your chosen BSD. I think that with a bind mount you can even read and write the same filesystem your BSD writes, but am not sure. For me, Funtoo just seemed like too much work, not just at install time, but every time I added new software. Also, unlike Mandrake, Mandriva, Ubuntu and Debian, with Funtoo you *really need to* pay attention to every upgrade notice, or you could totally mess up your system. For those of us wanting a desktop to do lots of non-IT things, that's just too much maintenance time. I'm working on an experimental with PC-BSD sometimes, late at night. A little slow, but pretty good. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928113816.25550...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 28/09/14 16:35, Lisi Reisz wrote: On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. The Trinity Desktop Environment is not, as far as I can readily determine, available *in* Debian, only *for* Debian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542830e9.3050...@zen.co.uk
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ahoj, Dňa Sun, 28 Sep 2014 11:38:16 -0400 Steve Litt sl...@troubleshooters.com napísal: Don't forget to try the various BSDs. As long as your BSD can run qemu or another VM, you can use Debian for that one or two programs that don't work under your chosen BSD. I think that with a bind mount you can even read and write the same filesystem your BSD writes, but am not sure. For now, i want to stay on Linux yet, more precise, i will stay on Debian until next stable go out and things about next direction will be more clear. For now i have hold systemd (and related) packages in versions, where my home (and testing) system works, but i am preparing myself to change, when it will needed. For me, Funtoo just seemed like too much work, not just at install time, but every time I added new software. Also, unlike Mandrake, Mandriva, Ubuntu and Debian, with Funtoo you *really need to* pay attention to every upgrade notice, or you could totally mess up your system. For those of us wanting a desktop to do lots of non-IT things, that's just too much maintenance time. Yes, it is time consuming - especially in learning stage (and in VBox) :-P But with Debian (testing) you need to take care about updates too - my daughter can tell what happens, when she did updates without care - some packages was uninstalled due dependencies changes, but yes, not whole system was damaged, only some things was not working. But what i noticed, in funtoo is very simple to set the gnome and systemd (and many other things) out of system by the USE flags, then these functions (and libraries) are not compiled at all and this i see as big advantage (which is close to my - install only what you are using), which cannot be simple accomplished with Debian. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Sonntag, 28. September 2014, 11:18:22 schrieb Steve Litt: On Sun, 28 Sep 2014 11:02:35 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Am Freitag, 26. September 2014, 14:51:01 schrieb Miles Fidelman: John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Oh, the same way I could say: I am forced to write init scripts for a package. As I recently just did: The difference being that the Linux *you* originally moved *to* required init scripts. Nobody changed everything on you. Well with that I can argue to better never change *anything*. I wonder what developers of the Linux kernel, of KDE, or you-name-what would say to this idea. I no what I self would say to it: I want change. Change is life. There is nothing static in life. Except God, as much as you believe in it, or as I believe even if you do not believe in it. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1957711.VCDzImNO8t@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Steve Litt wrote: On Sun, 28 Sep 2014 15:21:13 +0200 Slavko li...@slavino.sk wrote: Ahoj, Dňa Sun, 28 Sep 2014 10:56:08 +0200 Martin Steigerwald mar...@lichtvoll.de napísal: But my challenge to all of you who don´t want systemd as default in Debian still is this: *Stop* complaining and *start* acting. You are right. For now it seems, that there is no chance to get DE without systemd in debian and no change is expected (at least) in near future. Then i test two scenarios now: 1. switch to another distro - for now i am testing funtoo, if is here possible to have all my apps chain without systemd and it seems, that it is possible (BTW it is my first attempt with sourced distro) 2. stay on debian and maintain own versions of the packages, which (useless for me) depends on the systemd – i tried it with dbus and it is possible, but i afraid, if my system's knowledge will be enough with all needed packages. I afraid too, that the 2. will not be a temporary task and number affected packages will be grow, then i don't think, that it is real solution for me. regards Don't forget to try the various BSDs. As long as your BSD can run qemu or another VM, you can use Debian for that one or two programs that don't work under your chosen BSD. I think that with a bind mount you can even read and write the same filesystem your BSD writes, but am not sure. And the new crop of Solaris based distros. SmartOS looks awfully sweet for servers. Lack of Xen support is the primary thing holding me back. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54283f36.4050...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sunday 28 September 2014 17:01:45 Martin Read wrote: On 28/09/14 16:35, Lisi Reisz wrote: On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. The Trinity Desktop Environment is not, as far as I can readily determine, available *in* Debian, only *for* Debian. That isn't what Salvko specifuied. He said that you can't have a DE in Debian without systemd. You can. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201409281808.39377.lisi.re...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald wrote: Am Sonntag, 28. September 2014, 11:18:22 schrieb Steve Litt: On Sun, 28 Sep 2014 11:02:35 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Am Freitag, 26. September 2014, 14:51:01 schrieb Miles Fidelman: John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Oh, the same way I could say: I am forced to write init scripts for a package. As I recently just did: The difference being that the Linux *you* originally moved *to* required init scripts. Nobody changed everything on you. Well with that I can argue to better never change *anything*. Backwards compatibility is a wonderful thing - particularly when it comes to platforms. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54284366.5020...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald mar...@lichtvoll.de writes: Am Sonntag, 28. September 2014, 04:35:03 schrieb lee: Martin Read zen75...@zen.co.uk writes: On 27/09/14 21:04, lee wrote: https://bugzilla.redhat.com/show_bug.cgi?id=990177 Your complaint about the interface is reasonable. The systemd developers' decision to not change the interface in response to your complaint was also reasonable. I never said it was totally unreasonable. I'm saying it would probably be easy to fix and that they simply don't want to. If they wanted to, they could and would. It is still *one* bug report tough. Yes, I know there are others, systemd developers closed as won´t fix. Yet, look around a bit: That is true for *any* bigger software project I have seen so far. Lots of won´t fix bug in KDE´s bugzilla as well for example. And I do not always agree with the decisions. Yes, making bug reports about KDE is futile. I haven't tried KDE in quite a while, yet I'm sure they still haven't even fixed the scroll bars. So acting for change, you may meet resistance. But that initially resistance is just that… an initial response towards change. A even natural response. Yet it does not mean that change is impossible. Quite the opposite is true. I don't think it's natural that resistance against change comes up when a bug is discovered and reported in some software. If that would happen with software I wrote, I'd be interested in fixing the bug. I have seen systemd upstream and also systemd debian developers acting on bugs and fixing them. Sure, sometimes bug are fixed. How often does that happen? At least bugs reported about systemd get some attention. Yes, I was frustrated with some of the reactions of Michael Biebl for example, closing bugs quickly without resolving them, but first I found my tone at that time to be contributing to that outcome, and second after I pleaded to him in one bug report not to close it immediately, he didn´t close it So nowadays you have to fall on your knees and pray to the great developer to not ignore a bug, and you even take that for natural? … and… we worked together on some other issues. He told me what about he needs and I gave it to him. Of course I'm willing to help with fixing a bug I reported as much as I can. That is usually being ignored, with very few exceptions. It may also be true that systemd upstream won´t be willing to implement the change you want to see. But if you choose to keep your power with yourself, instead of giving it to others, you are still powerful, even in that case. An there are other options to create change. Power not being used is usually taken and used by others. I also still believe that if systemd developers did completely off the limits think, they would quickly be forked. I also believe that if Linus messed up horribly with Linux developers, someone would start a Linux kernel fork. So I believe there is quite some peer review with systemd stuff and there is some real agreeing to they way it implements thing. Then why aren't the concerns of those who disagree not taken into account? Its still about choice in Debian. Jessie will support alternative init systems. And you can help with that. You believe in it, I don't. We will see what happens. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ul3hk55@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald mar...@lichtvoll.de writes: Am Samstag, 27. September 2014, 22:55:36 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Why do I think that you do not want change from the *current* situation? Cause what you do, in my oppinion does not facilitate change. I think I see why you think so. What makes you think that anything you or I could do would change anything? Cause I believe you are as powerful as anyone else here. Really powerful. I'm merely a user, and my interests are being ignored or not, just like the interests of any other user. Maybe look at [1]. Perhaps I have the ability and time to fix it myself or not. If I fix it, I'll make the fix available. In any case, it was a waste of time to make this bug report. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762626 -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mvrhjq8@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald mar...@lichtvoll.de writes: Am Samstag, 27. September 2014, 22:13:21 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. Your assumption is wrong. I appreciate change for the better, not for the worse, and in case of systemd, I don't believe that there is any way to change anything about it. So you just complain here over and over again to vent your frustration? I'm merely participating in the discussion and haven't entirely made up my mind what the issue actually is and what I should do. Systemd is working fine here ever since I'm using Fedora, which is since F17. Since then I have *never* had a freeze or crash of the system caused by buggy software, which is unprecedented in this way. Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. I also need to replace Fedora with something else because my experience is that the makers of Fedora act like Nazis. Besides that I don't want to have any part of their attitude, it's a recipe for future problems the same way as Debian is. Systemd is merely another annoying player in the mess. Finally, I have gathered that it actually has some advantages besides its disadvantages. I can see it working fine every day with no problems whatsoever. The things I personally don't like about it are not all too important. So what should I do? My server is running fine, so I can sit things out for quite a while, or until it doesn't. My desktop is working fine, so I'm in no hurry to replace Fedora. I might give Gentoo a try next weekend, though they'll probably also switch to systemd sooner or later. Besides, I have a long list of other things to do. If you do not believe systemd upstream is willing to help with the change you want to see, there are endless other ways to help to facilitate changes. I listed some here in other posts: Organize a vote and present result to upstream developers, I suggested doing this here and was told that there's no point in doing it. It's probably true, yet I might still do that just for curiosity. install systemd-shim and cgmanager and test it, install init-select and test it, install openrc and test it, help systembsd people, help packaging it for Debian once ready or help find a packager… start affirming daily for changes to happen and… and… and… This is all Debian specific, and Debian is deprecated. I don't have a solution to fixing Debians' issues or to systemd having taken over, and I don't see any reason to jump to blind activism. The best course of action seems to be to observe while sitting things out and to try to not be affected by whatever explosion will sooner or later occur. And no, I don´t want to hear rationalizations why none of my suggestion can work at all. This is still free software, this is still open source, this is still forkable, there are *tons* of option for helping change. Maybe some my not be as comfortable as you wish… but helping with change often needs *some* effort. When I have a good idea for something to do, I might just do it. Go ahead and prove me wrong. Why? Why do think I would waste my own time like this? So I take it that you don't want change. Why do you think I would waste my own time with fighting windmills, knowing that I cannot win? I decided to give systemd a chance on my systems and see what this brings me. I decided for a practical approach. And so far the systems I installed it on didn´t explode or anything like this. See. It would be much easier if systemd didn't work at all. Still systemd not working wouldn't fix Debians' issues. When you look at [1], you even find people claiming that there has been a takeover of Debian and an abuse of the technical committee, and that silencing of people questioning systemd and Debians' ways is going on. [1]: http://www.debianuserforums.org/viewtopic.php?f=63t=3031 -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ahoj, Dňa Sun, 28 Sep 2014 18:08:39 +0100 Lisi Reisz lisi.re...@gmail.com napísal: On Sunday 28 September 2014 17:01:45 Martin Read wrote: On 28/09/14 16:35, Lisi Reisz wrote: On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. The Trinity Desktop Environment is not, as far as I can readily determine, available *in* Debian, only *for* Debian. That isn't what Salvko specifuied. He said that you can't have a DE in Debian without systemd. You can. aptitude search ~dtrinity -w 50 p trinity - system call fuzz tester p trinity:i386 - system call fuzz tester Which from these two packages are for you mentioned DE? Or my search missing something? Or you want to play with words only? BTW, what you recommends is to change the DE due systemd, strange solution. I want the exact opposite solution - i want to change the (now default) init system due DE. And if you dont know why, then i will tell you - because most of my work is done in DE, then change DE is bigger change, than change the init system, which my system needs *only* at start. But it seems, that here are people, which can do anything, to accomplish, that the systemd is best. Sad... regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 28/09/14 18:57, Martin Steigerwald wrote: I want change. Change is life. There is nothing static in life. That's a nice kitchen philosophy (as we would call it in German), and one that the sellers of novelties of all kind will appreciate. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m09ive$3r2$1...@ger.gmane.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
lee l...@yagibdah.de writes: I'm merely participating in the discussion and haven't entirely made up my mind what the issue actually is and what I should do. [...] Debian already lost me (after over 15 years) when they came up with their brokenarch and left users stranded with no possible fix for the things they broke. The only reason I'm here is because I have it running on my server, and the only reason I have it on my server is because it was the only distribution of those I tried with which I could get xen to work. I really didn't want to use Debian. If you don't want to use Debian then don't. But if you don't even want to use it, making lots of complaints about it seems uncalled for... When you look at [1], you even find people claiming that there has been a takeover of Debian and an abuse of the technical committee, and that silencing of people questioning systemd and Debians' ways is going on. [1]: http://www.debianuserforums.org/viewtopic.php?f=63t=3031 Yeah, probably the same person as [2] and [3]. Shocking that he gets banned time and time again... [2] https://lists.debian.org/debian-ctte/2014/03/msg3.html [3] https://lists.debian.org/debian-ctte/2014/02/msg00394.html Ansgar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g0nmvzo@deep-thought.43-1.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sunday 28 September 2014 19:04:22 Slavko wrote: Ahoj, Dňa Sun, 28 Sep 2014 18:08:39 +0100 Lisi Reisz lisi.re...@gmail.com napísal: On Sunday 28 September 2014 17:01:45 Martin Read wrote: On 28/09/14 16:35, Lisi Reisz wrote: On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. The Trinity Desktop Environment is not, as far as I can readily determine, available *in* Debian, only *for* Debian. That isn't what Salvko specifuied. He said that you can't have a DE in Debian without systemd. You can. aptitude search ~dtrinity -w 50 p trinity - system call fuzz tester p trinity:i386 - system call fuzz tester Which from these two packages are for you mentioned DE? Or my search missing something? Or you want to play with words only? https://www.trinitydesktop.org/ BTW, what you recommends is to change the DE due systemd, strange solution. I want the exact opposite solution - You do like nonsense and FUD. You said that you couldn't have a DE in Debian without systemd. You can. Now you say that you want a particular DE, and can't have that. Tough. Lisi i want to change the (now default) init system due DE. And if you dont know why, then i will tell you - because most of my work is done in DE, then change DE is bigger change, than change the init system, which my system needs *only* at start. But it seems, that here are people, which can do anything, to accomplish, that the systemd is best. Sad... regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201409282110.46854.lisi.re...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sun, 28 Sep 2014 18:57:12 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Am Sonntag, 28. September 2014, 11:18:22 schrieb Steve Litt: On Sun, 28 Sep 2014 11:02:35 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Am Freitag, 26. September 2014, 14:51:01 schrieb Miles Fidelman: John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Oh, the same way I could say: I am forced to write init scripts for a package. As I recently just did: The difference being that the Linux *you* originally moved *to* required init scripts. Nobody changed everything on you. Well with that I can argue to better never change *anything*. I wonder what developers of the Linux kernel, of KDE, or you-name-what would say to this idea. KDE is every bit the trash systemd is, and more. The difference is, you simply discard KDE, its libraries, and all the executables depending on its libraries, and go about your business. As far as the kernel, they day they start taking marching orders from Gnome and Redhat, you can remind me of this. I don't recall the kernel ever doing anything within three orders of magnetude as stupid as systemd. I no what I self would say to it: I want change. Yep, you want any change, at any cost. Bust anything, it doesn't matter, it's exciting. Change is life. There is nothing static in life. How Eastern Philosophical. I may have to climb a mountain and fast for a month to reach your level of enlightenment. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928164452.2d780...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/25/2014 05:00 PM, Chris Bannister wrote: On Thu, Sep 25, 2014 at 03:15:36PM -0700, koanhead wrote: can't use. I brought this up once on #offtopic and was told that sysvinit doesn't work on bsds (that's a paraphrase using the same words, not a quote) and then ridiculed. It's not that sysvinit doesn't work on bsds, it might, it's that the BSD's use different init systems. https://www.usenix.org/legacy/events/usenix01/freenix01/full_papers/mewburn/mewburn_html/ I'm aware of BSD-style init, but the mailing-list thread [1] I posted indicates that Debian GNU/kFreeBSD doesn't use it but instead uses sysvinit (otherwise they wouldn't care so much about bitrot among sysvinit scripts nor cite stay with sysvinit as among their options.) In the context of a discussion about Debian, I don't care so much what the other BSD variants do. On 09/26/2014 Andrei POPESCU wrote: As you can see, systemd is available for all CPU architectures currently supported by Debian (including arm64 and ppc64el which are still racing to make it in time for Jessie). Yes, I see that now. Thanks very much for the clarification :^) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m09s7m$8kf$1...@news.albasani.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sun, Sep 28, 2014 at 01:48:47PM -0700, koanhead wrote: On 09/25/2014 05:00 PM, Chris Bannister wrote: On Thu, Sep 25, 2014 at 03:15:36PM -0700, koanhead wrote: can't use. I brought this up once on #offtopic and was told that sysvinit doesn't work on bsds (that's a paraphrase using the same words, not a quote) and then ridiculed. It's not that sysvinit doesn't work on bsds, it might, it's that the BSD's use different init systems. https://www.usenix.org/legacy/events/usenix01/freenix01/full_papers/mewburn/mewburn_html/ I'm aware of BSD-style init, but the mailing-list thread [1] I posted [1] reference is missing. indicates that Debian GNU/kFreeBSD doesn't use it but instead uses sysvinit (otherwise they wouldn't care so much about bitrot among sysvinit scripts nor cite stay with sysvinit as among their options.) In the context of a discussion about Debian, I don't care so much what the other BSD variants do. You wrote above: ... told that sysvinit doesn't work on bsds ... It reads as though you were referring to the BSD variants. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140929003515.GC8956@tal
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sun, 28 Sep 2014 18:57:12 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Change is life. There is nothing static in life. So all the fuss about wearing those grounded, anti-static wrist straps is just a hoax? -- hangout: ##b0rked on irc.freenode.net diversion: http://alienjeff.net - visit The Fringe quote: The foundation of authority is based upon the consent of the people. - Thomas Hooker -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5428aed6.8060...@charter.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/26/2014 08:48 PM, Scott Ferguson wrote: I'd appreciate an insight into the reductive reasoning you used to arrive at your belief? I was going to reply with links, pictures, and graphs. Then I figured what for? Tell ya what ...this time next year, we'll re-visit this topic and we'll see what we will see! My POV, for the record, is that all of the security break-ins poses a real threat to our country's security, and that SystemD will prove to be an important player towards making Linux much =safer= than it is with SystemV. You and I both know that the only truly safe server is the one plugged in to nothing and stored in a forgotten bank vault. I posit that the decision to utilize SystemD will be found it was made to make Linux a LOT more secure than it ever has been. We'll see! I'm going to install it to my Proxmox clusters running Wheezy soonest. There, I'm putting my money where my mouth is, and then I will have a new learning curve. BTW, I turn 65 in Nov. yet I have that much more to learn. Next year Scott! We have a date! :) Ric -- My father, Victor Moore (Vic) used to say: There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome. R.I.P. Dad. Linux user# 44256 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54265ea2.9030...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
John Hasler wrote: Miles Fidelman writes: Again, in the real world of operations - not all code is installed from packages. There's an awful lot of ./configure; ./make install That has nothing to do with Debian. How can your difficulties installing some tarball be construed as Debian imposing anything on upstreams? Debian is a platform, as much as anything else. Change fundamental things - file layouts, APIs, core services - that impacts anything that runs on it. We have things like the LSB precisely to provide a standard platform. Changing the platform impacts everyone who writes stuff to run on the platform. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5426c61e.4090...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
Miles Fidelman writes: We have things like the LSB precisely to provide a standard platform. And Debian has an LSB package. Install it and your LSB-compliant software will run (assuming dependencies are satisfied: those are your problem if you are not using the packaging system). If you know of any counterexamples file bugs. Debian's adoption of Systemd as the default init does not obligate any upstream developer to write Systemd into her software. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oau16rxw@thumper.dhh.gt.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
Le 27/09/2014 01:08, Ric Moore a écrit : On 09/26/2014 05:08 PM, green wrote: Ric Moore wrote at 2014-09-26 14:18 -0500: Change is certainly needed when any pimple face kid can edit and hide his doings from a text log with nano. I think the change is necessary to harden up our systems. Otherwise, Microsoft will become the only secure server OS, as they don't mind hiding things at all. So, all other things being equal, binary logs are more secure than plain text logs. Is that actually what you are saying? Yes. The benefit of using a binary log is the lesser vulnerability to an external attack from an intruder. That huge security flaw was mentioned on a recent PBS video regarding the new day Hackers and how simply they removed/edited text-log files to hide their tracks of what they did. That's completely false. Binary or text can be modified just as easily. You just use some other tool. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5426eaa0.8000...@rail.eu.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald mar...@lichtvoll.de writes: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. Your assumption is wrong. I appreciate change for the better, not for the worse, and in case of systemd, I don't believe that there is any way to change anything about it. Go ahead and prove me wrong. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sijckeji@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald mar...@lichtvoll.de writes: Why do I think that you do not want change from the *current* situation? Cause what you do, in my oppinion does not facilitate change. I think I see why you think so. What makes you think that anything you or I could do would change anything? -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhp4kcl3@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Andrei POPESCU andreimpope...@gmail.com writes: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? https://bugzilla.redhat.com/show_bug.cgi?id=990177 -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq8okey1@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 27/09/14 21:04, lee wrote: https://bugzilla.redhat.com/show_bug.cgi?id=990177 Your complaint about the interface is reasonable. The systemd developers' decision to not change the interface in response to your complaint was also reasonable. (The Fedora users mailing list thread you linked to suggests that I am not the only person outside the systemd development team who thinks that the interface was not sufficiently suboptimal to justify change.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54274456.4030...@zen.co.uk
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 28/09/14 06:13, lee wrote: Martin Steigerwald mar...@lichtvoll.de writes: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. Your assumption is wrong. I appreciate change for the better, not for the worse, and in case of systemd, I don't believe that there is any way to change anything about it. Go ahead and prove me wrong. Prove a negative? Normally I'd say it was impossible - but you've just done it in a 6 word sentence. 2 cups of tolerance, a large bowl of pity the fools, and 3 slices of embrace the disenfranchised was clearly insufficient preparation for today. Incredible. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54274a00.6030...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Read zen75...@zen.co.uk writes: On 27/09/14 21:04, lee wrote: https://bugzilla.redhat.com/show_bug.cgi?id=990177 Your complaint about the interface is reasonable. The systemd developers' decision to not change the interface in response to your complaint was also reasonable. I never said it was totally unreasonable. I'm saying it would probably be easy to fix and that they simply don't want to. If they wanted to, they could and would. Anyway, it gives me to think that such a misunderstanding has come up to begin with and that it hasn't been fixed long ago. Someone who doesn't understand what disabled means is programming an init system: What other misunderstandings might have gone into it? Why obfuscate things and mislead and confuse the users? It may be only a little piece in a big puzzle. Look at the documentation and you find more such pieces. With such pieces, what would make me think that the authors of systemd actually know what they're doing or that they have some appreciation for their users? -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tqwiim9@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
Scott Ferguson scott.ferguson.debian.u...@gmail.com writes: On 28/09/14 06:13, lee wrote: Martin Steigerwald mar...@lichtvoll.de writes: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. Your assumption is wrong. I appreciate change for the better, not for the worse, and in case of systemd, I don't believe that there is any way to change anything about it. Go ahead and prove me wrong. Prove a negative? Normally I'd say it was impossible - but you've just done it in a 6 word sentence. Have you achieved a change? -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761g8ij0g@yun.yagibdah.de
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Jo, 25 sep 14, 15:15:36, koanhead wrote: On 09/25/2014 03:30 AM, martin f krafft wrote: ... the Universal Operating System should also cater to non-desktops. And not only to other-than-desktop, but also to ports and architectures other than i386/amd64. I don't have a problem with systemd per se. I have used it before on Fedora containers, and beyond the initial learning-curve it was without any problems that I noticed. My problem with systemd *as default in Debian* stems from the fact that systemd only works with Linux, and is only known (to me) to work on the aforementioned arches. $ rmadison systemd debian: systemd | 44-11+deb7u4 | wheezy-security | source, amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc systemd | 44-11+deb7u4 | wheezy | source, amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc systemd | 204-14~bpo70+1 | wheezy-backports | source, amd64, armel, armhf, i386, ia64, mips, mipsel, powerpc, s390, s390x, sparc systemd | 208-8 | jessie | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, s390x systemd | 208-8+b1 | jessie | ppc64el systemd | 215-4 | sid | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc new: As you can see, systemd is available for all CPU architectures currently supported by Debian (including arm64 and ppc64el which are still racing to make it in time for Jessie). It does indeed not work on !Linux due to its use of cgroups which is a Linux only feature. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Freitag, 26. September 2014, 01:58:44 schrieb lee: Or to *help*. Make a logind that does not depend on systemd. Offer it to the upstreams that need it. I'm sure it would be ignored or rejected --- even if I had the knowledge to make anything like that and was able to keep up with what other ppl are doing. I do think that you don´t want change. I don't mind changing to a different default init system or letting users decide which one they want to use. The more the default init system is a bad choice, the more the users need to be able to choose another one. With systemd, they won't have a choice. You expect distro developers to fix it for you. You are not willing to take things upstream. I expect the distribution developers not to break things for me and to make better decisions than supporting systemd like they do. Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. If they are unaware of the issues, then how could Debian ever decide to support systemd? That doesn´t create change. Change for the sake of change isn't necessarily a good thing. Systemd is not a change for the better unless it's one more choice becoming available, and I'm not creating it. You misunderstood me. I do not think that you want any change from the *current* situation where systemd is default in Debian. You say, you want, but I do not believe you. I didn´t just restate that you don´t want systemd in Debian, I *got* that, you made it *pretty* obvious. Why do I think that you do not want change from the *current* situation? Cause what you do, in my oppinion does not facilitate change. Cause what you do, in my oppinion strengthens the status quo. You give energy to the status quo by remaining in complaining about it. Or otherwise said: I know people who are complaining a lot, yet complaining never ever created a change. I know it from myself: Whenever I complained about something it didn´t create the slightest bit of change. I always created change as I stopped complaining and did something more productive. I never ever saw complaining creating change. Never ever. It can´t. It is the mere essence of complaining that it always strengtens what you complain about. What you resists, persists. Is this what you want? With complaining you only drag yourself down, and others who choose to let themselves be dragged down by it. So I repeat my challenge to you and others who do not want to have systemd in Debian: Stop complaining and act towards your dreams, towards what you want to see in Debian. And now I challenge myself to do something more productive than letting myself being dragged down by this negativity. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13197327.OAIlATT7Zt@merkaba
systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
Hi! Am Donnerstag, 25. September 2014, 22:53:09 schrieb The Wanderer: On 09/25/2014 at 06:09 AM, martin f krafft wrote: But dependency creep is unfortunately nothing new ever since we declared next year the Year of Linux of the Desktop and forgot that the Universal Operating System should also cater to non-desktops. In the debian-devel discussions prior to the raising of the TC bug, some of the Debian developers arguing for systemd included among their arguments ones making the case that it would be much better for servers (including the ones which they run) than sysvinit. So it's not that they forgot that, so much as that they have a different perspective and conclusion on whether or not systemd does effectively so cater. Actually systemd has quite some features which benefits server use. For example: 1) It groups services and shell sessions into process control cgroups and shields them against each other CPU usage wise. On a systemd system you can run stress -c 1, thus having stress try to hog 1 CPU cores with nonsense calculations, *yet* *still* log in and work on a SSH sessions *as if nothing* happened. This is especially cool if some service tries to create havoc. Heck, I even demonstrated that a systemd based system even can survive an agressive work bomb aka perl -e fork while fork. Yes, I needed to find a killall command that does not need to be loaded from disk, a participant of one of my trainings knew one fortunately, cause I don´t load anything to disk due to no memory to load any executable. But with that builtin killall I was able to stop the fork bomb *without* rebooting the system. 2) It is really good at catching the PIDs of the services it runs, no matter what funny things they do like double forking. So it exactly stops these PIDs and no others. With init script you can basically forget about reliably to handle a double forking daemon that doesn´t create a PID file. 3) Compare systemctl service status with /etc/init.d/service status. Its obvious that the systemctl output is way more useful to administrators. Can these be implemented elsewhere? I´d say yet for 1. Yet 2 and partly 3 I think is the core of an init system. Again, I see advantages. It has some. I need to put my hands before my eyes to avoid seeing these. I won´t. Its neither completely black nor completely white. But of course one can only see the advantages if one actually *looks* at what systemd provides. You don´t need to love it for that. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2957035.QR1JWz0JpO@merkaba
Re: Challenge to you: Voice your concerns regarding systemd upstream
Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. As he so far I read here refuses any and all suggestions to *act* towards change. I may have missed something here as I didn´t do myself the harm to read every post of every systemd related thread here, so if I did, mea culpa. But from what I read so far, Lee don´t want change. He prefers to put his energy into complaining about status quo instead. That leaves no energy for facilitating change. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Steigerwald wrote: Am Donnerstag, 25. September 2014, 01:45:50 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Am Montag, 22. September 2014, 23:50:46 schrieb lee: Martin Steigerwald mar...@lichtvoll.de writes: Do you really think they will be able to prevent all the other software from depending on a particular init system or parts of it? Well… thats to be taken upstream, isn´t it? Then why don't the developers or the distributions do just that? Nobody cares when one user or another questions whether it's a good idea to depend on systemd, and it might be much different if a lot of developers and/or whole distributions would, in the interest of their users, question this dependency and refuse their support eventually until the issues systemd and software depending on it brings about. […] Fedora does already depend on systemd --- and I would say completely. Or do you see a choice here? And exactly *how* is this relevant to Debian? And still I think its important to take this upstream. Upstream, from the users point of view, are the makers of the distribution in the first place. I can't very well make a bug report against systemd directly because Debian has decided to support it, can I. That's not a problem of systemd. To get involved with everything seems to have been a design decision of systemd. What do you expect will happen when I make a bug report directly against systemd, explaining them that it's broken by design? Or should I make a bug report against the X server because it depends on systemd? Or the other way round? Or perhaps against cups instead? Or to *help*. Make a logind that does not depend on systemd. Offer it to the upstreams that need it. I'm sure it would be ignored or rejected --- even if I had the knowledge to make anything like that and was able to keep up with what other ppl are doing. I do think that you don´t want change. You expect distro developers to fix it for you. You are not willing to take things upstream. So let's see: - the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers - systemd seems to have some rather frequently changing APS's - to the extent that systemd-shim lags well behind - but the resulting impacts should be taken up with each and every upstream developer? Somehow that doesn't sound right. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54258193.3070...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw9m8izt@thumper.dhh.gt.org
Re: systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
On Fri, 26 Sep 2014 12:03:57 +0200 Martin Steigerwald mar...@lichtvoll.de wrote: Hi! Am Donnerstag, 25. September 2014, 22:53:09 schrieb The Wanderer: On 09/25/2014 at 06:09 AM, martin f krafft wrote: But dependency creep is unfortunately nothing new ever since we declared next year the Year of Linux of the Desktop and forgot that the Universal Operating System should also cater to non-desktops. In the debian-devel discussions prior to the raising of the TC bug, some of the Debian developers arguing for systemd included among their arguments ones making the case that it would be much better for servers (including the ones which they run) than sysvinit. So it's not that they forgot that, so much as that they have a different perspective and conclusion on whether or not systemd does effectively so cater. Actually systemd has quite some features which benefits server use. For example: 1) It groups services and shell sessions into process control cgroups and shields them against each other CPU usage wise. On a systemd system you can run stress -c 1, thus having stress try to hog 1 CPU cores with nonsense calculations, *yet* *still* log in and work on a SSH sessions *as if nothing* happened. This is especially cool if some service tries to create havoc. Heck, I even demonstrated that a systemd based system even can survive an agressive work bomb aka perl -e fork while fork. Yes, I needed to find a killall command that does not need to be loaded from disk, a participant of one of my trainings knew one fortunately, cause I don´t load anything to disk due to no memory to load any executable. But with that builtin killall I was able to stop the fork bomb *without* rebooting the system. 2) It is really good at catching the PIDs of the services it runs, no matter what funny things they do like double forking. So it exactly stops these PIDs and no others. With init script you can basically forget about reliably to handle a double forking daemon that doesn´t create a PID file. 3) Compare systemctl service status with /etc/init.d/service status. Its obvious that the systemctl output is way more useful to administrators. Can these be implemented elsewhere? I´d say yet for 1. Yet 2 and partly 3 I think is the core of an init system. Again, I see advantages. It has some. I need to put my hands before my eyes to avoid seeing these. I won´t. Its neither completely black nor completely white. But of course one can only see the advantages if one actually *looks* at what systemd provides. You don´t need to love it for that. Martin, I don't think anybody's complaining about those features. Those are excellent features that should be done in PID 1. The only *technical* thing people are griping about is the gratuitous entanglement with all sorts of other things, including user programs and GUI window managers/desktop environments. If systemd was just a PID1 with the features you enumerate above, I'd be dancing in the street, not looking for a way out. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140926122630.36639...@mydesq2.domain.cxm
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 26/09/14 16:09, Miles Fidelman wrote: So let's see: - the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers The technical committee has no authority (and limited soft power) with respect to what *upstream* developers (i.e. the people who write the software that Debian members then choose to package for inclusion in Debian) do or don't do. It has bounded authority and power to decide what work is expected to be done or not done in Debian, and thus over what is provided *downstream* (i.e. to Debian's users). And a sizeable chunk of the upstream work for *compatibility with systemd* has already been done in response to events in Fedora, Arch, OpenSUSE, etc. At this point, it seems to me that any upstream who hasn't already done something to improve their software's compatibility with systemd (if it even needs any work to achieve such a thing) is more likely to say bug reports only reproducible on systemd are your problem, not mine than oh, well, if Debian has gone with it as well maybe I'll have a look. - systemd seems to have some rather frequently changing APS's - to the extent that systemd-shim lags well behind My impression is that systemd-shim's task is not implement all of /lib/systemd/systemd's interfaces but implement enough of /lib/systemd/systemd's interfaces that other parts of systemd-the-suite such as systemd-logind can operate acceptably without needing to run /lib/systemd/systemd. systemd-shim broke with respect to systemd suite versions = 205 because systemd-logind's dependencies on interfaces of /lib/systemd/systemd expanded for reasons related to compatibility with the single writer, single hierarchy version of the Linux kernel's cgroups interface. - but the resulting impacts should be taken up with each and every upstream developer? As far as I can see, the issue that people are suggesting should be taken up with upstream developers is application XYZ has annoying and seemingly unnecessary dependencies on interfaces of systemd, making it hard to keep systemd off my systems. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542597d4.8020...@zen.co.uk
Re: Challenge to you: Voice your concerns regarding systemd upstream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/26/2014 at 12:44 PM, Martin Read wrote: On 26/09/14 16:09, Miles Fidelman wrote: - but the resulting impacts should be taken up with each and every upstream developer? As far as I can see, the issue that people are suggesting should be taken up with upstream developers is application XYZ has annoying and seemingly unnecessary dependencies on interfaces of systemd, making it hard to keep systemd off my systems. The trouble with recommending to take that upstream is that it's entirely legitimate for a program to depend on externally-provided interfaces, and indeed in the conceptual ideal a program should neither know nor care what provides those interfaces. It would be better, from a design perspective, to fix the unnecessary dependency problems at the core - that is, in systemd - rather than requiring all of the upstreams to make changes in response to changes in systemd. Only if systemd upstream will be uncooperative, and refuse to fix the problems, would taking it to the multiple upstreams make sense - and even then, forking systemd or providing another source for the systemd interfaces would probably be a better solution. (Though still not as good as fixing the design at the core.) If you're saying to take the problem to the individual upstreams, then you are effectively saying that you believe that systemd upstream already is uncooperative, and already is refusing to fix the problems. Which doesn't seem consistent with the other positions I think I've seen taken by the people I think I recall seeing advocate that these issues be taken to the individual upstreams. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUJZ2iAAoJEASpNY00KDJrmZAP/jTNNbVghAGReG8O1dVVrbnZ TQe1w2+m/XyycZYrRX9+48KBXM404IuY6uD7InlxAIJPubQxl4cuI96aG7e8Zi1t EkOvfpxlL1HvC4dtw1C7fmhR1weXBOL4YoYFPYsq0LLNg+CIei4KQFuXkUk5i8+N 2XsqMBvJ9K/G+vkV4ky6IGoFCNS0B0l/TErrC/ZzzUV2gljEGr3kppPhKVV+4x9N 84dc8WKNDAeXpVgMx+HMxedJnoKKPTTq0ZdQ7+V5w3LeYkwOlm+xYnO2hv869bpu 9RFFVAtdA1P5UESb1HXWfzRGOe7EKb+9tLlK+7dgMYVipzgMNJzMPY7WQiQCogCu HAr4KTbBkQM9cTORFmJmkQz4Cev6GYhzNdBz/avG/T6RoyebRdlzyEJ5XeuqAKeb 1pq09H5YWj5Fn9kD3u4u421IE2Sbf/FZ8Z4NHm0IbW5kGYeFzLPbP+tHj6tXyXXS 3gDqe6JScWEPvPn+CwBakaFRF1m39nu7YaNovJV9mRbfIg+ErERae6/nUCnFXQyn KMMh2XXgMwMPrT7qSVWnxqxVTuKQ9YxofoWaFtmDtwBAqLBbnYeXUEEVORqTLDAP QbMhJ9iaJyo2YgMvzwYQ8oH0muMBsljdax/9ifbK/R+TufNO7JijsoqIjjsv24/C DGAOGATp1DMdAWWl76+4 =QWrw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54259da2.2080...@fastmail.fm
Re: Challenge to you: Voice your concerns regarding systemd upstream
The Wanderer writes: If you're saying to take the problem to the individual upstreams, then you are effectively saying that you believe that systemd upstream already is uncooperative, and already is refusing to fix the problems. I get the distinct impression that systemd upstream views these problems as features. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioka8ea2@thumper.dhh.gt.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
Martin Read wrote: On 26/09/14 16:09, Miles Fidelman wrote: So let's see: - the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers The technical committee has no authority (and limited soft power) with respect to what *upstream* developers (i.e. the people who write the software that Debian members then choose to package for inclusion in Debian) do or don't do. It has bounded authority and power to decide what work is expected to be done or not done in Debian, and thus over what is provided *downstream* (i.e. to Debian's users). And a sizeable chunk of the upstream work for *compatibility with systemd* has already been done in response to events in Fedora, Arch, OpenSUSE, etc. At this point, it seems to me that any upstream who hasn't already done something to improve their software's compatibility with systemd (if it even needs any work to achieve such a thing) is more likely to say bug reports only reproducible on systemd are your problem, not mine than oh, well, if Debian has gone with it as well maybe I'll have a look. And the next step is to stop paying attention to old style init scripts. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5425b60d.5080...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
John Hasler wrote: Miles Fidelman writes: the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers Where the hell do you get that from? Isn't that effectively what happened? If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Sure, it's voluntary - but not really. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5425b595.9040...@meetinghouse.net
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 09/26/2014 06:06 AM, Martin Steigerwald wrote: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. As he so far I read here refuses any and all suggestions to *act* towards change. I may have missed something here as I didn´t do myself the harm to read every post of every systemd related thread here, so if I did, mea culpa. But from what I read so far, Lee don´t want change. He prefers to put his energy into complaining about status quo instead. That leaves no energy for facilitating change. Change is certainly needed when any pimple face kid can edit and hide his doings from a text log with nano. I think the change is necessary to harden up our systems. Otherwise, Microsoft will become the only secure server OS, as they don't mind hiding things at all. Yes, it is a work in progress, but I think the main goal is signed binaries that discourage the Black Hats ...at least for awhile. What is telling is that no one is talking about that. Linux does indeed run the majority of the web servers, so consider that if every major Linux Distro is working in concert for a change, there has to be compelling reasons behind it, and that we may not be privy to their reasonings for security's sake. The Net has been proven to be as secure as Swiss Cheese lately, and that makes Linux look very bad, if not half-assed. :/ Ric -- My father, Victor Moore (Vic) used to say: There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome. R.I.P. Dad. Linux user# 44256 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5425bc15.9020...@gmail.com
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ahoj, Dňa Fri, 26 Sep 2014 14:53:01 -0400 Miles Fidelman mfidel...@meetinghouse.net napísal: Martin Read wrote: On 26/09/14 16:09, Miles Fidelman wrote: So let's see: - the technical committee selects takes a vote that essentially imposes systemd on all of the upstream developers and packagers The technical committee has no authority (and limited soft power) with respect to what *upstream* developers (i.e. the people who write the software that Debian members then choose to package for inclusion in Debian) do or don't do. It has bounded authority and power to decide what work is expected to be done or not done in Debian, and thus over what is provided *downstream* (i.e. to Debian's users). And a sizeable chunk of the upstream work for *compatibility with systemd* has already been done in response to events in Fedora, Arch, OpenSUSE, etc. At this point, it seems to me that any upstream who hasn't already done something to improve their software's compatibility with systemd (if it even needs any work to achieve such a thing) is more likely to say bug reports only reproducible on systemd are your problem, not mine than oh, well, if Debian has gone with it as well maybe I'll have a look. And the next step is to stop paying attention to old style init scripts. Yes, then next step is go away from Debian. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Challenge to you: Voice your concerns regarding systemd upstream
Ric Moore wrote at 2014-09-26 14:18 -0500: Change is certainly needed when any pimple face kid can edit and hide his doings from a text log with nano. I think the change is necessary to harden up our systems. Otherwise, Microsoft will become the only secure server OS, as they don't mind hiding things at all. So, all other things being equal, binary logs are more secure than plain text logs. Is that actually what you are saying? signature.asc Description: Digital signature
Re: systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
also sprach Steve Litt sl...@troubleshooters.com [2014-09-26 18:26 +0200]: If systemd was just a PID1 with the features you enumerate above, I'd be dancing in the street, not looking for a way out. Beautiful. I had to: https://twitter.com/martinkrafft/status/515611660128903170 ;) -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems the word yellow wandered through his mind in search of something to connect with. -- hitchhiker's guide to the galaxy digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Challenge to you: Voice your concerns regarding systemd upstream
Miles Fidelman writes: If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Very few packages need init scripts. When they are the Debian package maintainer writes them no matter what init system is in use. In any case, Systemd reads sysvinit scripts. Debian's choice of Systemd as default init imposes no requirements whatever on upstreams. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a95m80z8@thumper.dhh.gt.org
Re: Challenge to you: Voice your concerns regarding systemd upstream
On Sat, Sep 27, 2014 at 4:18 AM, Ric Moore wayward4...@gmail.com wrote: On 09/26/2014 06:06 AM, Martin Steigerwald wrote: Am Freitag, 26. September 2014, 10:43:14 schrieb Andrei POPESCU: On Vi, 26 sep 14, 01:58:44, lee wrote: Again, I consider it to be totally futile to try to convince the makers of systemd to fix the issues it brings about. They cannot be unaware of them, so obviously they don't want to fix them. I've seen for myself that they don't want to fix even little bugs which would be easy to fix from the bug report I made about their misunderstanding of what disabled means. Could you please provide a link to that? Lee´s comments like this completely prove to me that Lee does not want any change from status quo. As he so far I read here refuses any and all suggestions to *act* towards change. I may have missed something here as I didn´t do myself the harm to read every post of every systemd related thread here, so if I did, mea culpa. But from what I read so far, Lee don´t want change. He prefers to put his energy into complaining about status quo instead. That leaves no energy for facilitating change. The above is an argument about self-help attitudes. If you want change, you have to be willing to enable the changes you want by your choices, as well as support change by your actions. It's an argument that is only relevant on the list as a reminder to individual users that they (we) participate with the developers. Change is certainly needed when And the argument from here is about a specific kind of change. Huge leap in logic. Leaps in logic can be enlightening, in some cases, not so much in other cases. any pimple face kid can edit ... edit what? Be specific. I'm tempted to assume you mean ** system files ** or maybe just ** logs **, but you might be meaning ** their own pimple-faced files under their own pimple-faced login accounts ** . And why pimple-faced? Isn't that one of those expressions that falsely and disparagingly characterizes a group of individuals who may or may not have anything particular in common? Would it be that much worse to refer to skin color? But that isn't the biggest problem. If you do mean system files or logs or other people's settings, then the problem is not one that can or should be solved at pid 1. The problem, if not in the kernel and libraries, is in the system administrators refusing to do their jobs. and hide his doings from a text log with nano. Why nano? Why not hexedit? Or any of several tools a good sysadmin should be familiar with and not surprised by, should an intruder of any complexion, age, gender, race, or religion gain access to system resources he or she should not have access to. I think the change is necessary to harden up our systems. No, systemd just moves the problems, and actually makes the most intractable problems worse. You can't fix unfortunate kernel features or design at pid 1. You can't protect the system from bad system libraries at pid 1. If the kernel provides an intrusion path from user libraries, that's not something you can successfully stave off at pid 1. Otherwise, Microsoft will become the only secure server OS, Get serious, ... as they don't mind hiding things at all. ... the willingness to hide stuff is irrelevant to security. Yes, it is a work in progress, but I think the main goal is signed binaries that discourage the Black Hats But you are a black hat. In other words, it's essential for a sysadmin to assume the POV of a potential intruder to see the holes he or she is leaving in his or her walls, and it's just as essential for a sysdmin to recognize that he or she could well be the intruder, or in collusion with the intruders, if he or she fails to take the responsibility seriously. Talking about the Black Hats is yet another way of continuing the Us vs. Them arguments that basically ignore the real problems and keep the status quo. ...at least for awhile. Whether you are referring to the escalation of cryptology or the inherent limits in systems, if you use those as an argument for improperly engineered pid 1 level attempts to plug the leaks, you might as well be in collusion with the National Security organizations and black market cartel organizations in the world. The problem is that the new features of systemd are things that cannot be safely done at pid 1. What is telling is that no one is talking about that. You're talking about it. Pretty much every conversation that promotes systemd starts with security issues as an assumption, if not specifying them directly. Which is very ironic. Linux does indeed run the majority of the web servers, so consider that if every major Linux Distro is working in concert for a change, there has to be compelling reasons behind it, and that we may not be privy to their reasonings for security's sake. If we can't read the code, we have problems. Linus himself told us that it is not safe to depend on him to
Re: Challenge to you: Voice your concerns regarding systemd upstream
John Hasler wrote: Miles Fidelman writes: If I'm an upstream developer, and I want my stuff to run on Debian, I now have to include systemd init scripts (or the packagers do). Very few packages need init scripts. First of all, that's simply not true in the server world. Pretty much everything on our systems has init scripts. When they are the Debian package maintainer writes them no matter what init system is in use. Again, in the real world of operations - not all code is installed from packages. There's an awful lot of ./configure; ./make install In any case, Systemd reads sysvinit scripts. In theory, and with limitations. Plus, I've seen an awful lot of bug reports in that regard. http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ makes for some disconcerting reading, not the least of which is that it closes with: Note that there are some areas where systemd currently provides a certain amount of compatibility where we expect this compatibility to be removed eventually. And is dated 10/2013. Debian's choice of Systemd as default init imposes no requirements whatever on upstreams. Right off the bat, the can't expect things to work the way they do now. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5425f170.30...@meetinghouse.net
