Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Hendrik Boom: > Given the mix, I'd prefer to hear him out rather than ban him. You-plural should _most_ certainly ban me if Dng cannot accomodate occasional polite mocking of what I see as ideological ranting and tunnel vision that notably fails to get anything done. I couldn't help noticing that my friend Mr. Litt -- the man who insisted you hear all about my views (I didn't) -- spent vast amounts of time posting impassioned stump-speeches on debian-user and accomplishing nothing at all. By contrast, when I finally got around to grappling with the indeed troubling and serious problems in Debian 8 'Jessie', I spent two days finding good workarounds and documenting them (along with their limits) on a Web page pro bono publico. Which approach do _you_ think accomplishes more? (Please note I did _not_, and would not, denigrate Devuan Project's actual _work_, just the dumb ranting stuff. That work is something I expect will accomplish a great deal more and help a lot more people.) > ...deniable. I believe you are crediting me with a _great_ deal more subtlety than anyone who knows me would _ever_ attribute to yr. humble servant, who's about as subtle as his garden's habanero chilis, and whose writings aim to clarify what he _thinks_, not play tiresome games to rile up strangers. I seek _clarity_. If you insist on being offended, that is not my remit. (However, I _am_ still waiting to hear about the Tory of the Blind Man and the Elephant, at our UK friend's earliest convenience. If he feels trolled over that, I'm sorry he can't take a joke.) So, I'd be glad to settle for people gradually ceasing attempting to enforce software religion here and more consistently behave like a software project. I don't like fanatical religion. It killed my friend and congressman, Leo Ryan, at Jonestown, after all, so I tend to take it rather personally and stomp hard on it when I see it. But if you'd prefer to ban me for not singing in that particular choir, that works, too. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Sat, Jul 30, 2016 at 02:01:31PM +0200, info at smallinnovations.nl wrote: > On 29-07-16 21:39, Jaromil wrote: > > > >I think most people clashing with Rick here may want to stop for a > >moment and realise Devuan does not need fan-boys, converted people or > >preachers as much as critical and constructive minds that go across > >all what we are doing and, besides encouraging it, also envisions > >flaws and limits. This is what we always need to encourage if we don't > >want to end up like Debian today. The capacity to listen to critical > >postures is what makes us different from the dynamics surrounding the > >systemd avalanche. > > > >Rick is a seasoned contributor to all sorts of good developments in > >gnu/linux world, he is provocative and witty, definitely not a > >troll. > > Your "definitely not" is not mine. If it looks like a duck, swims like a > duck, quacks like a duck it probably is a duck. > So i will take him for a troll until the opposite has been proven. I think he *is* a troll. He is also a competent, knowledgable, experienced technical person who has a lot to offer us. The combination is quite rare. Given the mix, I'd prefer to hear him out rather than ban him. What I won't do is respond to his provocations. They are always subtle, and deniable. Sometimes I don't even notice them until someone responds in anger. But I'm like that. I tend to concentrate on facts rather than emotions. Rick concentrates on facts, too. But he tends to word the facts in ways that make others feel slighted, this inciting long, and eventually futile discussions with those who are too easily offended. Not that there aren't a number of us here who easily feel denigrated. My advice to all is: * Don't take it personally. * Have impeccable with your words. * ask questions * do your best. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 29-07-16 21:39, Jaromil wrote: I think most people clashing with Rick here may want to stop for a moment and realise Devuan does not need fan-boys, converted people or preachers as much as critical and constructive minds that go across all what we are doing and, besides encouraging it, also envisions flaws and limits. This is what we always need to encourage if we don't want to end up like Debian today. The capacity to listen to critical postures is what makes us different from the dynamics surrounding the systemd avalanche. Rick is a seasoned contributor to all sorts of good developments in gnu/linux world, he is provocative and witty, definitely not a troll. Your "definitely not" is not mine. If it looks like a duck, swims like a duck, quacks like a duck it probably is a duck. So i will take him for a troll until the opposite has been proven. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Simon Hobson writes: > Rick Moen wrote: > >> I have a better question: Is there something about empiricism that many >> people on this mailing list cannot cope with? >> >> Back when I had newly joined this mailing list and all of these idle >> allegations and rhetorical questions started being posted, I decided to >> do that thing What's it called? Oh, right: 'Checking.' > > I too did some checking. From practical experience, one of the ClamAV > packages (IIRC it's clamd) has a hard dependency on libsystemd0. Using > dpkg --force-depends to install only that package without having > libsystemd0 installed results in ... it failing at startup because it > can't open the library. > > I opened a bug, which was very quickly and quite abusively closed as > "won't fix", and was also told that "it doesn't work like that" when I > asked if (especially as it was supposedly only one call they ever made > on non-systemd systems) why they couldn't do "if exists libsystemd0 > then ..." - something which I now know is possible if the dev/packager > cares about it. It's possible but the point of libsystemd0 is reportedly putting this logic (wrt systemd itself) into a library which can then be used by all applications. Metaifying this to the next degree would ultimatively mean create a libsystemd00 (ups --- still hard depedency), libsystemd000 (strangely, nothing changed), libsystemd (still tied to systemd - quel surprise) and so on. A technical solution for this could be to create a way to interact with 'the service manager' in a way which doesn't require inserting calls to functions provided by said service manager into applications, eg, by executing a program (distant thump as systemd developer fainting upon the supposition to fork and exec hits the floor) or by sending a message in a documented format to some well-known address. An AF_UNIX datagram socket would suggest itself for that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Walter (si...@gikaku.com): > First of all, if my words mean nothing to you, you should ignore > them. OK, ignoring the rest. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/30/2016 03:55 PM, Rick Moen wrote: Quoting Simon Walter (si...@gikaku.com): Isn't that what's being discussed? When did I say the things you said were opposition for the Devuan Project? 'disagree with a fork of Debian'. I've made clear what I said, and what it meant and didn't mean. You've attempted to distort that into an attack on the Devuan Project, which is crazy talk and fanaticism -- as Jaromil was kind enough to acknowledge specifically -- and I've said we have nothing more to discuss on that matter. _And_, the kicker, one of the things I was known for earliest in the Linux community is an essay on forking explaining why forking is a necessary and important right. Which you should be aware of because it's been mentioned here. You are wasting your time and mine. First of all, if my words mean nothing to you, you should ignore them. Don't answer a fool - me being the fool in this instance. Secondly, I should not be aware because I don't read everything you write here because it's too wordy for me. I've enjoyed some of your writings in proper, but wasn't aware of that particular one. I look forward to reading it. Thirdly, I've already said, I don't disagree with what you said. I just don't like how you come across sometimes and tried to explain how you might make someone feel. My attempts at satire and explaining social matters have backfired and left my foot in my mouth. Now you think I am trying to distort what you say. I wouldn't dare and apologize if that is how it was understood. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Walter (si...@gikaku.com): > Isn't that what's being discussed? When did I say the things you > said were opposition for the Devuan Project? 'disagree with a fork of Debian'. I've made clear what I said, and what it meant and didn't mean. You've attempted to distort that into an attack on the Devuan Project, which is crazy talk and fanaticism -- as Jaromil was kind enough to acknowledge specifically -- and I've said we have nothing more to discuss on that matter. _And_, the kicker, one of the things I was known for earliest in the Linux community is an essay on forking explaining why forking is a necessary and important right. Which you should be aware of because it's been mentioned here. You are wasting your time and mine. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/30/2016 02:57 PM, Rick Moen wrote: Quoting Simon Walter (si...@gikaku.com): Which is why it could be construed that you disagree with a fork of Debian - a for of Debian as in "A fork of Debian that could be said to have been started because the default init system in Debian became systemd." - that fork of Debian - not a theoretical fork. You know, if you are going to call 'In my opinion, the goals of this project could have been achieved through less-arduous means' _opposition_ to the project -- a project I explicitly like and appreciate -- then that is fanaticism, IMO, and we have nothing more to discuss. Isn't that what's being discussed? When did I say the things you said were opposition for the Devuan Project? Trying to explain why *some* people might see you a certain way after you express that you don't understand why said people see you said way is a little different than saying you are that way. But never mind. You seem offended. So it was a bit pointless for me to try. Sorry dude - (if I can call you that). Obviously I don't disagree with what you said or we would be discussing those details and not what appears to me to be social matters. Where there is passion, there may be fanaticism. What am I doing trying to explain any further? I must be insane. ;) Fortunately, I am reasonably certain you don't speak for the Devuan Project in this regard. Fortunately, I do not speak for the Devan Project in any regard except as a recommendation to some other admins who have utter curses towards systemd within ear shot. A good day/night to you sir! Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Walter (si...@gikaku.com): > Which is why it could be construed that you disagree with a fork of > Debian - a for of Debian as in "A fork of Debian that could be said > to have been started because the default init system in Debian > became systemd." - that fork of Debian - not a theoretical fork. You know, if you are going to call 'In my opinion, the goals of this project could have been achieved through less-arduous means' _opposition_ to the project -- a project I explicitly like and appreciate -- then that is fanaticism, IMO, and we have nothing more to discuss. Fortunately, I am reasonably certain you don't speak for the Devuan Project in this regard. -- Cheers, Grossman's Law: "In time of crisis, people do not rise to Rick Moen the occasion. They fall to the level of their training." r...@linuxmafia.com http://linuxmafia.com/~rick/lexicon.html#grossman McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/30/2016 04:18 AM, Rick Moen wrote: Quoting Steve Litt (sl...@troubleshooters.com): In all fairness to Rick, he was making his statements on SVLUG, and then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion, and only then did he repeat his assertions here. And my assertions stated that I like Devuan and appreciate it. All I said that threw you into a tizzy was that I estimated that its objectives could also have been achieved through lesser means. Which is why it could be construed that you disagree with a fork of Debian - a for of Debian as in "A fork of Debian that could be said to have been started because the default init system in Debian became systemd." - that fork of Debian - not a theoretical fork. People who insist on treating me like an enemy are being rather stupid. Those who persist in attributing to me statements I've never made and views I don't hold are being _very_ stupid. Of course I should be more sensitive, but hopefully I didn't make you feel like an enemy. I am merely trying to help explain why you might appear to some people that way, but now there is no point in me chewing on my foot any longer, is there? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Jaromil (jaro...@dyne.org): [much snipped] Jaromil, you are a prince. Yes, I am sarcastic and inclined to mock when I think something is fanatical and/or purblind. I am often wrong, and all too often woefully undercaffeinated. I also have a nasty habit of backing people into corners, which I need to stop doing. Which is to say, all too human (or perhaps I'm a commentbot masquerading as a human), but not the enemy of anyone here, and not posting just to provoke or annoy. > At last, I for one need to recognise my error in interpreting Rick's > article as a denigration of Devuan. Well, I perfectly understand the urge to initially say 'Oh, not another net.random slagging us unfairly'. You're busy; I don't expect you to drop everything just because I put up a Web page. Actually, I applaud your having until today worked on Devuan rather than reading my doodlings. It's a lot more important. > But also I think: Rick you may want to update it now that the > systemd-shim is falling unmaintained (see golinux mail), since a lot > of the assumptions you put forward won't be really sustainable anymore > on the long term. That's a good idea. I'll do that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Fri, 29 Jul 2016, Rick Moen wrote: > Quoting Simon Walter (si...@gikaku.com): > > If you really think Devuan is wrong, then flight it harder. > > Um, excuse me, but I like Devuan. I look forward to using what it > produces, either by borrowing packages from its repos or by running it. > This is why, for example, my OpenRC Conversion page suggests access to > Devuan's repos to solve package problems. I think most people clashing with Rick here may want to stop for a moment and realise Devuan does not need fan-boys, converted people or preachers as much as critical and constructive minds that go across all what we are doing and, besides encouraging it, also envisions flaws and limits. This is what we always need to encourage if we don't want to end up like Debian today. The capacity to listen to critical postures is what makes us different from the dynamics surrounding the systemd avalanche. Rick is a seasoned contributor to all sorts of good developments in gnu/linux world, he is provocative and witty, definitely not a troll. I'm personally glad he is here. I can hardly read everything that passes through these days, but the prose is generally pleasing and ironical and civil. All of us can make mistakes, lets try to avoid them by thinking how we would act in your area of expertise: sure we get excited about things now and then, but if we really are experts in the fields we'll always spot some debatable flaws and put forward some intuitions, perhaps controversial, sometimes wrong, but all helps to improve the shared consciousness of what we are doing. What I'm trying to say is that it would be stupid to expect people with Rick's expertise come here to praise Devuan like a fan-boy without any articulation or criticism. Similar frictions happened in the past with Reiner, who is also a respectable expert in the field and quite caustic at times. We all need to contextualise and understand this and get over personalisation, noone excluded, more or less experts in different fields. In my activist experience I've never seen an expert stepping into an occupy style assembly and being pleased of what was being approximately shouted about his/her own area of expertise. In the history of Devuan we may have such experts stepping in now and then and they may well be opinionated and perhaps even dissent with the majority. We need to understand this not as a threat to our project. At last, I for one need to recognise my error in interpreting Rick's article as a denigration of Devuan. I finally read it and I don't think it was such. But also I think: Rick you may want to update it now that the systemd-shim is falling unmaintained (see golinux mail), since a lot of the assumptions you put forward won't be really sustainable anymore on the long term. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Steve Litt (sl...@troubleshooters.com): > In all fairness to Rick, he was making his statements on SVLUG, and > then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion, > and only then did he repeat his assertions here. And my assertions stated that I like Devuan and appreciate it. All I said that threw you into a tizzy was that I estimated that its objectives could also have been achieved through lesser means. People who insist on treating me like an enemy are being rather stupid. Those who persist in attributing to me statements I've never made and views I don't hold are being _very_ stupid. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Walter (si...@gikaku.com): > Rick, that's exactly what I was talking about. You might be well > intentioned, but in so many words you are saying that you disagree > with a fork of Debian. Um, excuse me, but I didn't say that. > If you really think Devuan is wrong, then flight it harder. Um, excuse me, but I like Devuan. I look forward to using what it produces, either by borrowing packages from its repos or by running it. This is why, for example, my OpenRC Conversion page suggests access to Devuan's repos to solve package problems. > You seem like a smart guy and seem well intentioned. Others may be > able to use your good advice. So maybe try and appear a little more > open minded and others might open up a bit too. Here's an idea: Stop attributing to me views I don't hold and never expressed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting info at smallinnovations.nl (i...@smallinnovations.nl): > On 29-07-16 01:43, Rick Moen wrote: > >Quoting info at smallinnovations.nl (i...@smallinnovations.nl): > > > >>I am a sysadmin myself and why in hell would i like to rebuild local > >>packages? > > >One of my worst and most annoying habits is to give reasoned and > >useful answers to rhetorical questions. > > Hardly, you act like a troll quite a long time now. In the name of saving time, I'll just acknowledge that I'm an awful person in every conceivable way, so we can move on to possibly more interesting matters of software and host administration. Unless you're just much more comfortable with personal abuse than you are with system adminstration, in which case please plow right ahead. > >Great, so answer me a question: How are you getting a system without > >libsystemd0 today? > Waiting for Devuan or using something else then Linux as i told in > the part of my message you did not quote. Ah, so today you _have_ no solution. Well, I documented a number of them that interested parties can use today. Which brings me back to where we were before, except for some reason you are complaining about those solutions and asking why-would-I-use them. I suppose you would use one of them if you wanted to have a solution today. If you don't want a solution today, you would not. As it turns out, apparently you do not want a solution today, but wish to do nothing today and wait for someone to provide you a solution tomorrow. I understand. I do _not_ understand why you are annoyed at my providing ones that might suffice for many _until_ Devuan has that better way (which I will welcome), but some people just seem to like to complain. Enjoy the killfiling. Perhaps if you'd done that earlier, you'd have been spared being angry at someone who's done you no harm. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/29/2016 06:27 PM, Simon Hobson wrote: I wrote: ... and in a place where "the IT world starts and ends with Windows" (or more or less did when I started here) that's not a bad result. And bear in mind that when I started here and pointed out that as a Mac user, half of our internal systems didn't work properly* - the lead developer told me in no uncertain terms that it was my fault for not using IE6 on Windows and no they had no intention of "fixing" anything. My suggestion that this was a rather short sighted approach fell of deaf ears ... for a while - they've had to change their tune these days ! * For years I had to fire up an XP VM just to do my timesheet. As a parting gift, another dev just before he left had a look and fixed the one missing or superfluous (can't remember which) ";" in some javascript that broke this particular system on anything but Windows/IE6 :-/ Oh man, it sounds the same all over the world. (face palm) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
I wrote: > ... and in a place where "the IT world starts and ends with Windows" (or more > or less did when I started here) that's not a bad result. And bear in mind that when I started here and pointed out that as a Mac user, half of our internal systems didn't work properly* - the lead developer told me in no uncertain terms that it was my fault for not using IE6 on Windows and no they had no intention of "fixing" anything. My suggestion that this was a rather short sighted approach fell of deaf ears ... for a while - they've had to change their tune these days ! * For years I had to fire up an XP VM just to do my timesheet. As a parting gift, another dev just before he left had a look and fixed the one missing or superfluous (can't remember which) ";" in some javascript that broke this particular system on anything but Windows/IE6 :-/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
info at smallinnovations.nl wrote: >> Great, so answer me a question: How are you getting a system without >> libsystemd0 today? > Waiting for Devuan or using something else then Linux as i told in the part > of my message you did not quote. This. Plus in the meantime, using a systemd-free supported distro (ie sticking with Debian Wheezy on LTS). I'm not a programmer, so what I can do I do - 'evangelise' Devuan when I have the opportunity, support other users of the packages I use where I can, 'evangelise' GNU/Linux & FOSS where I can. Of course, those later two are not Devuan specific ... And, I think this is a big one (though in a way it's a form & result of evangelism), I've been able to demonstrate at work that FOSS (and specifically GNU/Linux) can "do stuff" and do it well - and in a place where "the IT world starts and ends with Windows" (or more or less did when I started here) that's not a bad result. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/29/2016 01:28 PM, Steve Litt wrote: On Fri, 29 Jul 2016 10:49:32 +0900 Simon Walter wrote: On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote: On 29-07-16 01:43, Rick Moen wrote: If you can suggest an additional method, I'll be glad to amend my list of suggestions. Otherwise, I'm not sure what your point is. Your point is quite clear: you do not want a fork of debian and that is the whole point of you being vocal on this list is it not? I suppose you are quite good in Debian politics. Adding you to my blacklist now. Rick, that's exactly what I was talking about. You might be well intentioned, but in so many words you are saying that you disagree with a fork of Debian. So of course people here will not see you as well intentioned and a quite possibly many other negative things. In all fairness to Rick, he was making his statements on SVLUG, and then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion, and only then did he repeat his assertions here. Yup, I saw the show. ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Fri, 29 Jul 2016 10:49:32 +0900 Simon Walter wrote: > On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote: > > On 29-07-16 01:43, Rick Moen wrote: > >> If you can suggest an additional method, I'll be glad to amend my > >> list of suggestions. Otherwise, I'm not sure what your point is. > > Your point is quite clear: you do not want a fork of debian and > > that is the whole point of you being vocal on this list is it not? > > I suppose you are quite good in Debian politics. > > > > Adding you to my blacklist now. > > Rick, that's exactly what I was talking about. You might be well > intentioned, but in so many words you are saying that you disagree > with a fork of Debian. So of course people here will not see you as > well intentioned and a quite possibly many other negative things. In all fairness to Rick, he was making his statements on SVLUG, and then, on DNG, *I* referenced the SVLUG archive of the SVLUG discussion, and only then did he repeat his assertions here. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/29/2016 10:00 AM, info at smallinnovations.nl wrote: On 29-07-16 01:43, Rick Moen wrote: If you can suggest an additional method, I'll be glad to amend my list of suggestions. Otherwise, I'm not sure what your point is. Your point is quite clear: you do not want a fork of debian and that is the whole point of you being vocal on this list is it not? I suppose you are quite good in Debian politics. Adding you to my blacklist now. Rick, that's exactly what I was talking about. You might be well intentioned, but in so many words you are saying that you disagree with a fork of Debian. So of course people here will not see you as well intentioned and a quite possibly many other negative things. If you really think Devuan is wrong, then flight it harder. Be more evangelical about it. Why not write a diatribe about it on your website and post the link wherever you like? But please don't hide your disdain for Devaun in intellectualism. You think we are idiots? Just call us idiots and be done with it. I get labeled an idiot every time I walk out my door. It doesn't mean much to me. You seem like a smart guy and seem well intentioned. Others may be able to use your good advice. So maybe try and appear a little more open minded and others might open up a bit too. That's my unsolicited advice. m(__)m ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 29-07-16 01:43, Rick Moen wrote: Quoting info at smallinnovations.nl (i...@smallinnovations.nl): I am a sysadmin myself and why in hell would i like to rebuild local packages? One of my worst and most annoying habits is to give reasoned and useful answers to rhetorical questions. Hardly, you act like a troll quite a long time now. So: You might decide to rebuild a local package lacking a dependency on libsystemd0 if you feel a need for it and what you want isn't available in any even-easier fashion. I simply want a distro without systemd. But wanting it doesn't _get_ you that -- NOR does it get you a system without libsystemd0, either. Thus my point. There are more distros then Debian as you well know. When i cannot get one i will start pinning or rebuild local packages but not one moment earlier. Great, so answer me a question: How are you getting a system without libsystemd0 today? Waiting for Devuan or using something else then Linux as i told in the part of my message you did not quote. To my knowledge, you would need to follow one of the suggestions currently included on my OpenRC Conversion page's list of 'overcoming dependency obstacles' tips, which are (a) equivs, (b) find a third-party repo with a rebuilt (or differently built) package, (c) wait for Devuan to produce one, (d) rebuild the package locally, or (e) construct a deb package using the upstream source tarball using debhelper. (I also mentioned on this mailing list the creative idea of overwriting the problematic library with a nearly null-function one, to fool apps claimed to merely see if a library can be opened without being particular about what's in it.) Is there an additional way of achieving that result today? Or are you merely saying you really, really, really want one? You 'cannot get one' today for a number of packages including (according to one poster here) ClamAV. So, how are you achieving it _today_, sir? If you can suggest an additional method, I'll be glad to amend my list of suggestions. Otherwise, I'm not sure what your point is. Your point is quite clear: you do not want a fork of debian and that is the whole point of you being vocal on this list is it not? I suppose you are quite good in Debian politics. Adding you to my blacklist now. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (si...@thehobsons.co.uk): > So when someone states that "it's just a library, it doesn't do > anything" then that needs taking with a pinch of salt because once > anything calls one of it's functions, then that library can do lots of > stuff. On the other hand, when the person says 'it's just a library; it doesn't do anything'[1], _and_ accompanies that with the crucial detail that the reason this _particular_ library doesn't do anything is that it's merely interface code to something else you have deliberately left out, _and_ went to the trouble of explaining that a library can do anything except be directly invoked as an executable, _and_ scrupulously referred you to good documentation on libraries so you can learn what they are if you honestly do system administration but don't know what a library is --- then maybe you should keep the salt in its box, because you never know when you might need salt for something other than failing to understand information in context. > So the point I've been making before is that, even if libsystemd0 > "does nothing" now, we can't be complacent that it won't change. And package maintainers are evil corrupt collaborators who wouldn't catch this and reject the change, and the entire Linux community would be incompetent to notice and take remedial action. Of course! How did I miss that? > OK, this many be paranoia No, really? [1] That person endeavours to not write run-on sentences, so would in fact use a semicolon rather than a comma. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Steve Litt (sl...@troubleshooters.com): > > Who's the Tory of the Blind Man and the Elephant? Theresa May? ;-> Quoted to remind people that I never learned who this mysterious Conservative Party MP is. Curious Minds Want to Know.[tm] > Which brings us full circle. Simon doesn't want to keep playing these > games, wondering what kind of workaround he'll need next, as Lennart > decides to subsume yet another Linux functionality, or Debian's "DDs" > make yet another poor decision on dependencies. So he chose to go with > the fork. Great, he 'doesn't want'. Now that that's settled, what is he going to _do_, to achieve what he says he _does_ want. And when I say 'do', I don't mean the ranting-on-mailing lists part, but rather actually do. > I don't have the tech chops to know all the various ways Lennart can > screw up my life, nor do I have the technical chops to know (without > huge experimentation) how to work around Lennart's latest incursion. Well, gosh, you _could_ read my Web page. That's what I wrote it for. However, cannot lead the horse to water, of course. > I know the incursions will keep on coming Yes, the sky is always falling. News at 11. > And then there's this: I don't know anything about Simon's feelings, > but Debian's actions of 2014 disgust me. That's nice. Me, I'm a bit busy managing systems. Which involves mostly dealing with software and making things work. There have been times in the past when you've written a few things about that, too. > For me, continuing to use Debian is an impossibility. Yes, we know you're a Void Linux user. Thus all the extremely impassioned Devuan fervour. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting info at smallinnovations.nl (i...@smallinnovations.nl): > I am a sysadmin myself and why in hell would i like to rebuild local > packages? One of my worst and most annoying habits is to give reasoned and useful answers to rhetorical questions. So: You might decide to rebuild a local package lacking a dependency on libsystemd0 if you feel a need for it and what you want isn't available in any even-easier fashion. > I simply want a distro without systemd. But wanting it doesn't _get_ you that -- NOR does it get you a system without libsystemd0, either. Thus my point. > When i cannot get one i will start pinning or rebuild local packages > but not one moment earlier. Great, so answer me a question: How are you getting a system without libsystemd0 today? To my knowledge, you would need to follow one of the suggestions currently included on my OpenRC Conversion page's list of 'overcoming dependency obstacles' tips, which are (a) equivs, (b) find a third-party repo with a rebuilt (or differently built) package, (c) wait for Devuan to produce one, (d) rebuild the package locally, or (e) construct a deb package using the upstream source tarball using debhelper. (I also mentioned on this mailing list the creative idea of overwriting the problematic library with a nearly null-function one, to fool apps claimed to merely see if a library can be opened without being particular about what's in it.) Is there an additional way of achieving that result today? Or are you merely saying you really, really, really want one? You 'cannot get one' today for a number of packages including (according to one poster here) ClamAV. So, how are you achieving it _today_, sir? If you can suggest an additional method, I'll be glad to amend my list of suggestions. Otherwise, I'm not sure what your point is. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Though I suspect no one is going to give you the car you'd like, the > devuan developers are solving _his_ problems for him. The fork is > going to help some people. I suspect there are enough of these people > to make the fork worthwhile. Of course I haven't taken a census, and I > don't really know. Those people are likely to include the guy I shave (yr. humble servant), so you-plural will have my profound thanks. And that includes if you help me get libsystemd0 off my system with minimal effort, which would be cool even if I don't think it's all that important -- so thanks in advance! On the other hand, complaining on mailing lists isn't coding. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Arnt Gulbrandsen wrote: > A library can do anything the executable can. Which is what I thought. So when someone states that "it's just a library, it doesn't do anything" then that needs taking with a pinch of salt because once anything calls one of it's functions, then that library can do lots of stuff. "It wouldn't make sense" for a library to do anything when the main system component isn't installed - but don't most of us think that little the systemd guys do makes sense anyway ? So the point I've been making before is that, even if libsystemd0 "does nothing" now, we can't be complacent that it won't change. Just imagine if a few devs started talking along the lines of "well if systemd isn't installed, doing X is a little harder" - I would not be in the least surprised to find "stuff to do X" getting shifted from "systemd" to libsystemd0. OK, it's not going to be an init system, and I imagine it would be quite hard (or would it ?) to get a well built daemon running, but is there anything to stop them (say) putting all the binary logging stuff in there so devs can use the systemd logging instead of using syslog ? And thus, the presence of libsystemd0 then allows parts of systemd itself to pervade non-systemd systems. OK, this many be paranoia - but I'm sure that was said about the threat of systemd when it's inclusion was being considered. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 2016-07-28 10:16, Steve Litt wrote: On Thu, 28 Jul 2016 00:48:12 -0700 Rick Moen wrote: Quoting Simon Hobson (li...@thehobsons.co.uk): > I too did some checking. From practical experience, one of the > ClamAV packages (IIRC it's clamd) has a hard dependency on > libsystemd0. Using dpkg --force-depends to install only that > package without having libsystemd0 installed results in ... it > failing at startup because it can't open the library. Out of curiosity, then, what happens if a file exists and can be opened but isn't libsystemd0? [Late addendum: The ClamAV developer _already gave you a better and cleaner solution_, which you haven't bothered to mention here. Any special reason why you omitted that? I'll fill that in below, in more late-addendum comments.] Like, find the tiniest lib with fewest functions you can, and cp it to /lib/[$ARCH]/libsystemd.so.[version] ? It would be interesting to find whether this package actually _uses_ anything within libsystemd0 -- which would AFAIK be futile if systemd isn't present -- or whether it merely (a) checks that a library exists and is openable (dlopen) or whether (b) it looks up symbols/functions inside the library (dlsym). One of the ClamAV upstream developers claims it's in effect (a), saying 'it doesn't do anything if systemd isn't the active init system'. But you already knew this because the person he said it to was you. http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html [Late addendum: And, oh, wait: The same developer _also_ already told you that you could make the problem go away by using the 'equivs' trick -- which I have discussed before. http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html So, basically, you're claiming this is a huge unsolvable problem even though the developer handed you a solution on a platter, that you're not bothering to mention here. I see. Meanwhile, let's go on with the reply as I originally drafted it:] If the above test works, and I strongly suspect it would, then it's probably not hard to come up with smoother and more automatable ways. However, if I _did_ need package clamav (which I don't), _and_ if I were feeling paranoid about libsystemd0 (which I don't), then I'd just grab the package source and rebuild it using the debuild utility to omit the pointless and annoying library dependency and work around the packaging bullshit. And using debuild is not exactly brain surgery; a link to a page that walks you through that is part of my OpenRC conversion page. Please note that I do _not_ assert in any way that it's A Good Thing that you might be driven to do this (if you are paranoid about libsystemd0, which I consider a bit irrational). I'd certainly prefer if you didn't. Fortunately, short of that, rebuilding packages locally is a pretty easy second way. > I opened a bug, which was very quickly and quite abusively closed as > "won't fix", and was also told that "it doesn't work like that" > when I asked if (especially as it was supposedly only one call they > ever made on non-systemd systems) why they couldn't do "if exists > libsystemd0 then ..." - something which I now know is possible if > the dev/packager cares about it. [Late addendum: The upstream developer's attitude is annoying, but on the other hand you also didn't tell the whole truth about your discussion with him, did you, now? I also note in passing that you portrayed this as a problem with the ClamAV 'package', which is a bit misleading, as the origin of your problem wasn't with a distro packaging policy but rather upstream.] > So after all this, I think I see where some of this division comes > from ... You *appear* to have been working on the basis that it's a > "non problem" because the testing you did showed it to be so - for > your use case. No, that is _not_ what I said -- and I have said it quite a number of times and am getting rather tired of having to repeat it. I perceive it to be not a problem worth spending time on (which is not the same as 'non problem') because the specific contents of this library mean it is completely innocuous on a system lacking systemd, in pretty much exactly the same way that the Kerberos libraries -- pulled in by an essentially bogus library dependency of package ssh-client on my Kerberos-less system -- are completely innocuous on a system lacking Kerberos because of their specific contents. (The self-parodying bullshit objection of 'In the future, horrible evil things might be put into the library because of horrible evil package maintainers colluding with horrible evil upstream and the inability of the entire Linux community to discover what has happened' has already been addressed upthread.) > Some of us have been working on the basis that it *is* a problem > because our testing shows it to be so - for our use cases. At the risk of speaking a bit sharply for a moment: Looks to me like you've also not bothered how to figure out how to do basic d
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 28-07-16 11:33, Rick Moen wrote: 'Building custom packages' is a rather inventively melodramatic exaggeration of auto-rebuilding a .deb with one spurious lib dependency disabled, and the 'live grenade' imagery in that specific context is patently ridiculous. But hey, if you'd rather sit on your tochis and wait for someone else to do it for you, I'll not deter you. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I am a sysadmin myself and why in hell would i like to rebuild local packages? I simply want a distro without systemd. When i cannot get one i will start pinning or rebuild local packages but not one moment earlier. And I am quite comfortable with one of the BSD's too so it will take a very long time before that to happen. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Thu, Jul 28, 2016 at 02:33:31AM -0700, Rick Moen wrote: > > But I'm getting the vibes that you are uninterested in 'overcoming > dependency obstacles' through local system administration. You'd rather > that someone else solves your problem. > > I understand. I'd like someone else to solve _my_ problems, too. And > I'd also like a Caterham, by the way. (British Racing Green, like > Patrick McGoohan's Lotus Super 7. One of the ones with a Ford Zetec > 1.4L engine is perfectly fine. Right-hand drive is also fine; I'll > sweet-talk the automotive grand panjandrums into letting me use it.) Though I suspect no one is going to give you the car you'd like, the devuan developers are solving _his_ problems for him. The fork is going to help some people. I suspect there are enough of these people to make the fork worthwhile. Of course I haven't taken a census, and I don't really know. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Steve Litt wrote: > Which brings us full circle. Simon doesn't want to keep playing these > games, wondering what kind of workaround he'll need next, as Lennart > decides to subsume yet another Linux functionality, or Debian's "DDs" > make yet another poor decision on dependencies. So he chose to go with > the fork. > > I don't have the tech chops to know all the various ways Lennart can > screw up my life, nor do I have the technical chops to know (without > huge experimentation) how to work around Lennart's latest incursion. I > know the incursions will keep on coming, so why in the world would I > subject myself to them? Therefore, to my limited ability, I help the > guys who made the fork, and recommend the fork to those not compatible > with Void or Funtoo or PC-BSD (and most Linux users aren't compatible > with those). What he said :-) ^^^ > And then there's this: I don't know anything about Simon's feelings, > but Debian's actions of 2014 disgust me. For me, continuing to use > Debian is an impossibility. Stupid technology comes and goes, but > betrayal is forever. They got arrogant, they got forked, and the > resulting Devuan community is one of the best I've ever belonged to. And that. Except it's not so much disgust, but disappointment - that a distro which had such high regard should allow itself to be dragged down this route. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Thu, 28 Jul 2016 00:48:12 -0700 Rick Moen wrote: > Quoting Simon Hobson (li...@thehobsons.co.uk): > > > I too did some checking. From practical experience, one of the > > ClamAV packages (IIRC it's clamd) has a hard dependency on > > libsystemd0. Using dpkg --force-depends to install only that > > package without having libsystemd0 installed results in ... it > > failing at startup because it can't open the library. > > Out of curiosity, then, what happens if a file exists and can be > opened but isn't libsystemd0? [Late addendum: The ClamAV developer > _already gave you a better and cleaner solution_, which you haven't > bothered to mention here. Any special reason why you omitted that? > I'll fill that in below, in more late-addendum comments.] > > Like, find the tiniest lib with fewest functions you can, and cp it > to /lib/[$ARCH]/libsystemd.so.[version] ? > > It would be interesting to find whether this package actually _uses_ > anything within libsystemd0 -- which would AFAIK be futile if systemd > isn't present -- or whether it merely (a) checks that a library exists > and is openable (dlopen) or whether (b) it looks up symbols/functions > inside the library (dlsym). > > One of the ClamAV upstream developers claims it's in effect (a), > saying 'it doesn't do anything if systemd isn't the active init > system'. But you already knew this because the person he said it to > was you. > http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html > > [Late addendum: And, oh, wait: The same developer _also_ already > told you that you could make the problem go away by using the > 'equivs' trick -- which I have discussed before. > http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html > So, basically, you're claiming this is a huge unsolvable problem even > though the developer handed you a solution on a platter, that you're > not bothering to mention here. I see. Meanwhile, let's go on with > the reply as I originally drafted it:] > > > If the above test works, and I strongly suspect it would, then it's > probably not hard to come up with smoother and more automatable ways. > However, if I _did_ need package clamav (which I don't), _and_ if I > were feeling paranoid about libsystemd0 (which I don't), then I'd > just grab the package source and rebuild it using the debuild utility > to omit the pointless and annoying library dependency and work around > the packaging bullshit. And using debuild is not exactly brain > surgery; a link to a page that walks you through that is part of my > OpenRC conversion page. > > Please note that I do _not_ assert in any way that it's A Good Thing > that you might be driven to do this (if you are paranoid about > libsystemd0, which I consider a bit irrational). I'd certainly prefer > if you didn't. Fortunately, short of that, rebuilding packages > locally is a pretty easy second way. > > > > I opened a bug, which was very quickly and quite abusively closed as > > "won't fix", and was also told that "it doesn't work like that" > > when I asked if (especially as it was supposedly only one call they > > ever made on non-systemd systems) why they couldn't do "if exists > > libsystemd0 then ..." - something which I now know is possible if > > the dev/packager cares about it. > > [Late addendum: The upstream developer's attitude is annoying, but on > the other hand you also didn't tell the whole truth about your > discussion with him, did you, now? I also note in passing that you > portrayed this as a problem with the ClamAV 'package', which is a bit > misleading, as the origin of your problem wasn't with a distro > packaging policy but rather upstream.] > > > > So after all this, I think I see where some of this division comes > > from ... You *appear* to have been working on the basis that it's a > > "non problem" because the testing you did showed it to be so - for > > your use case. > > No, that is _not_ what I said -- and I have said it quite a number of > times and am getting rather tired of having to repeat it. > > I perceive it to be not a problem worth spending time on (which is not > the same as 'non problem') because the specific contents of this > library mean it is completely innocuous on a system lacking systemd, > in pretty much exactly the same way that the Kerberos libraries -- > pulled in by an essentially bogus library dependency of package > ssh-client on my Kerberos-less system -- are completely innocuous on > a system lacking Kerberos because of their specific contents. > > (The self-parodying bullshit objection of 'In the future, horrible > evil things might be put into the library because of horrible evil > package maintainers colluding with horrible evil upstream and the > inability of the entire Linux community to discover what has > happened' has already been addressed upthread.) > > > > Some of us have been working on the basis that it *is* a problem > > because our testing shows it
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > OK, to start with, "sysadmin" is only a small part of ${dayjob} - so > many things which full time admins may consider "simple" are not thing > that I've ever had the time (and generally need) to deal with. I've > never claimed to be a particularly experienced admin, even if my > colleagues consider me some sort of guru (everything is relative). I'm sure you're fine. The point is, though, there are some quite simple aspects of running any deb-based system, including ones I mentioned at least in passing in my OpenRC Conversion essay, that I hope you will find useful in, among other things (as the subheader puts it), 'Overcoming Dependency Obstacles'. If you'd rather not, that's fine by me, but I notice that just complaining on mailing lists has done rather little, and maybe some, y'know, work using fairly basic Linux technology might do more. > But the main thing is, a big part of using a packaged system is to > make things "simpler". So, complain on mailing lists, then? ;-> > The moment anyone starts building custom packages then you've tossed a > live grenade in the system with a tripwire on the pin. 'Building custom packages' is a rather inventively melodramatic exaggeration of auto-rebuilding a .deb with one spurious lib dependency disabled, and the 'live grenade' imagery in that specific context is patently ridiculous. But hey, if you'd rather sit on your tochis and wait for someone else to do it for you, I'll not deter you. > I did look at equivs - but the information (or links) presented to me > then implied something very different to the "simple" stuff that's > been presented (IIRC) in this thread. Your phrase 'the information (or links) presented to me' is meaninglessly vague. Some people here seem to do that a lot, I notice. http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html walks through a specific case, and is pretty much by the numbers. I have no idea what you looked at, but either you didn't bother to start with the above (which is the link from my essay), or you have IMO rather extreme hopes and expectations. With which, I will hasten to add, I would still wish you all the best. > Then (from what I vaguely recall reading) I was under the impression > that equivs involved more than just a "pretend that this package is > installed" instruction to apt as the recent reference here suggested > to me. But from empirical observation, just telling apt to "pretend > libsystemd0 is installed even though it isn't" won't work when the > program "blows up" during startup when the linker can't open a library > it's been told is needed by this program. The upstream ClamAV developer _asserted_ that exactly that would work. So, was he correct in so saying, or was he incorrect? Did it ever occur to you to check? No? Why not? Allergic to empiricism? Broken thumbs? Highly selective phobias? Cat dragged off your computer? Personally, in your shoes -- if I had an irrational paranoia about libsystemd0, which I currently do not -- I would want to know. Wanting to know, I would indulge my personal affection for empiricism. E.g., when the relevant question is 'Is $FOO true?', I would investigate $FOO. If the upstream ClamAV developer's assertion is incorrect, then the other (rather obvious, I thought) trick I mentioned would be extremely likely to suffice in its place. But I'm getting the vibes that you are uninterested in 'overcoming dependency obstacles' through local system administration. You'd rather that someone else solves your problem. I understand. I'd like someone else to solve _my_ problems, too. And I'd also like a Caterham, by the way. (British Racing Green, like Patrick McGoohan's Lotus Super 7. One of the ones with a Ford Zetec 1.4L engine is perfectly fine. Right-hand drive is also fine; I'll sweet-talk the automotive grand panjandrums into letting me use it.) > So look at it from my PoV. When I'm done looking at it from my own, sure. You might have to wait a few decades, though. I believe I still have some miles left on my warranty. ;-> Looking at it from my own, I see that I've documented ways to deal overcome dependency obstacles, but you don't want to do them. Fair dinkum, as the Aussies say. You aren't obliged. But I _did_ provide them. > Incidentally, after the exchange referred to, someone contacted me > offlist with the comment "if that's the customer service department, > I'd hate to see the complaints department" - so it would appear at one > other person sees my PoV. That was on-list. It's about four posts down the archived thread. Whose link I provided. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/28/2016 05:50 PM, Simon Hobson wrote: ... but personally I consider it unethical to leave booby traps in systems for anyone that comes along to manage it after me. ... > That, for the most part, is why I've gone to great lengths to only use distro packaged software on the systems - even when it would have been easier at times (thinking more about CGI stuff rather than compiled programs) to grab the upstream and manually install it. ... Good man! Some of the best paying (read: stressful) jobs I've done were figuring out some custom system and port it over to something standard/out-of-the-box/maintainable. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: > If the above test works, and I strongly suspect it would, then it's > probably not hard to come up with smoother and more automatable ways. > However, if I _did_ need package clamav (which I don't), _and_ if I were > feeling paranoid about libsystemd0 (which I don't), then I'd just grab > the package source and rebuild it using the debuild utility to omit the > pointless and annoying library dependency and work around the packaging > bullshit. And using debuild is not exactly brain surgery; a link to a > page that walks you through that is part of my OpenRC conversion page. OK, to start with, "sysadmin" is only a small part of ${dayjob} - so many things which full time admins may consider "simple" are not thing that I've ever had the time (and generally need) to deal with. I've never claimed to be a particularly experienced admin, even if my colleagues consider me some sort of guru (everything is relative). Similarly, I don't claim to be a programmer (I can hack a bit of Bash these days, but that's about it) - even though a 1/4 century ago I was writing code commercially (in PL/M 51 if you're interested https://en.wikipedia.org/wiki/PL/M). But the main thing is, a big part of using a packaged system is to make things "simpler". The moment anyone starts building custom packages then you've tossed a live grenade in the system with a tripwire on the pin. So anyone coming along to admin these systems after me - whether that's because I've moved on or fallen under the proverbial bus - is put in a situation where a simple and innocuous operation could "blow up" the system. OK, so it wouldn't be me that had to worry about that, but personally I consider it unethical to leave booby traps in systems for anyone that comes along to manage it after me. Either I fudge with version numbers so that an apt-get upgrade will never try and replace my customer package (leaving someone scratching their head as to why), or I don't and an apt-get upgrade does strange things (most likely failing with misleading errors due to pinning and it not being able to satisfy dependencies). And I can absolutely 100% guarantee that anyone else in the company that might have to take over is a long way off the skillset for things like building customer packages, and I do mean a very loong way off that. That, for the most part, is why I've gone to great lengths to only use distro packaged software on the systems - even when it would have been easier at times (thinking more about CGI stuff rather than compiled programs) to grab the upstream and manually install it. I did look at equivs - but the information (or links) presented to me then implied something very different to the "simple" stuff that's been presented (IIRC) in this thread. Then (from what I vaguely recall reading) I was under the impression that equivs involved more than just a "pretend that this package is installed" instruction to apt as the recent reference here suggested to me. But from empirical observation, just telling apt to "pretend libsystemd0 is installed even though it isn't" won't work when the program "blows up" during startup when the linker can't open a library it's been told is needed by this program. So look at it from my PoV. I've been told that I could build an equivs package to provide the library and empty functions to keep the program happy - and I've been told that equivs is just a short recipe to apt that makes it "pretend" the library is installed. I've been told that no you can't just open the library if it exists, and I've been told that it's really easy to do. I've been told that equivs (as in the latter) will let a program start even if the library isn't there, and I've shown by experiment that the program "blows up" at start if the library is missing. Confused :-/ Incidentally, after the exchange referred to, someone contacted me offlist with the comment "if that's the customer service department, I'd hate to see the complaints department" - so it would appear at one other person sees my PoV. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > I too did some checking. From practical experience, one of the ClamAV > packages (IIRC it's clamd) has a hard dependency on libsystemd0. Using > dpkg --force-depends to install only that package without having > libsystemd0 installed results in ... it failing at startup because it > can't open the library. Out of curiosity, then, what happens if a file exists and can be opened but isn't libsystemd0? [Late addendum: The ClamAV developer _already gave you a better and cleaner solution_, which you haven't bothered to mention here. Any special reason why you omitted that? I'll fill that in below, in more late-addendum comments.] Like, find the tiniest lib with fewest functions you can, and cp it to /lib/[$ARCH]/libsystemd.so.[version] ? It would be interesting to find whether this package actually _uses_ anything within libsystemd0 -- which would AFAIK be futile if systemd isn't present -- or whether it merely (a) checks that a library exists and is openable (dlopen) or whether (b) it looks up symbols/functions inside the library (dlsym). One of the ClamAV upstream developers claims it's in effect (a), saying 'it doesn't do anything if systemd isn't the active init system'. But you already knew this because the person he said it to was you. http://lists.clamav.net/pipermail/clamav-users/2015-June/001592.html [Late addendum: And, oh, wait: The same developer _also_ already told you that you could make the problem go away by using the 'equivs' trick -- which I have discussed before. http://lists.clamav.net/pipermail/clamav-users/2015-June/001601.html So, basically, you're claiming this is a huge unsolvable problem even though the developer handed you a solution on a platter, that you're not bothering to mention here. I see. Meanwhile, let's go on with the reply as I originally drafted it:] If the above test works, and I strongly suspect it would, then it's probably not hard to come up with smoother and more automatable ways. However, if I _did_ need package clamav (which I don't), _and_ if I were feeling paranoid about libsystemd0 (which I don't), then I'd just grab the package source and rebuild it using the debuild utility to omit the pointless and annoying library dependency and work around the packaging bullshit. And using debuild is not exactly brain surgery; a link to a page that walks you through that is part of my OpenRC conversion page. Please note that I do _not_ assert in any way that it's A Good Thing that you might be driven to do this (if you are paranoid about libsystemd0, which I consider a bit irrational). I'd certainly prefer if you didn't. Fortunately, short of that, rebuilding packages locally is a pretty easy second way. > I opened a bug, which was very quickly and quite abusively closed as > "won't fix", and was also told that "it doesn't work like that" when I > asked if (especially as it was supposedly only one call they ever made > on non-systemd systems) why they couldn't do "if exists libsystemd0 > then ..." - something which I now know is possible if the dev/packager > cares about it. [Late addendum: The upstream developer's attitude is annoying, but on the other hand you also didn't tell the whole truth about your discussion with him, did you, now? I also note in passing that you portrayed this as a problem with the ClamAV 'package', which is a bit misleading, as the origin of your problem wasn't with a distro packaging policy but rather upstream.] > So after all this, I think I see where some of this division comes > from ... You *appear* to have been working on the basis that it's a > "non problem" because the testing you did showed it to be so - for > your use case. No, that is _not_ what I said -- and I have said it quite a number of times and am getting rather tired of having to repeat it. I perceive it to be not a problem worth spending time on (which is not the same as 'non problem') because the specific contents of this library mean it is completely innocuous on a system lacking systemd, in pretty much exactly the same way that the Kerberos libraries -- pulled in by an essentially bogus library dependency of package ssh-client on my Kerberos-less system -- are completely innocuous on a system lacking Kerberos because of their specific contents. (The self-parodying bullshit objection of 'In the future, horrible evil things might be put into the library because of horrible evil package maintainers colluding with horrible evil upstream and the inability of the entire Linux community to discover what has happened' has already been addressed upthread.) > Some of us have been working on the basis that it *is* a problem > because our testing shows it to be so - for our use cases. At the risk of speaking a bit sharply for a moment: Looks to me like you've also not bothered how to figure out how to do basic distro-centric system administration. If you'd like to learn a bit of that, my OpenRC Conv
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: > I have a better question: Is there something about empiricism that many > people on this mailing list cannot cope with? > > Back when I had newly joined this mailing list and all of these idle > allegations and rhetorical questions started being posted, I decided to > do that thing What's it called? Oh, right: 'Checking.' I too did some checking. From practical experience, one of the ClamAV packages (IIRC it's clamd) has a hard dependency on libsystemd0. Using dpkg --force-depends to install only that package without having libsystemd0 installed results in ... it failing at startup because it can't open the library. I opened a bug, which was very quickly and quite abusively closed as "won't fix", and was also told that "it doesn't work like that" when I asked if (especially as it was supposedly only one call they ever made on non-systemd systems) why they couldn't do "if exists libsystemd0 then ..." - something which I now know is possible if the dev/packager cares about it. So after all this, I think I see where some of this division comes from ... You *appear* to have been working on the basis that it's a "non problem" because the testing you did showed it to be so - for your use case. Some of us have been working on the basis that it *is* a problem because our testing shows it to be so - for our use cases. And we've all failed to pick up on this - a bit like the tory of the blind men and the elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, 27 Jul 2016 16:23:46 -0700, Rick wrote in message <20160727232346.gh10...@linuxmafia.com>: > Quoting Arnt Karlsen (a...@iaksess.no): > > > ..re-running your tests now, do you still get the same results > > now, as back then when you first checked? > > > root@mini:/tmp# cd /lib/x86_64-linux-gnu/ > root@mini:/lib/x86_64-linux-gnu# chmod 000 libsystemd.so.0.3.1 > root@mini:/lib/x86_64-linux-gnu# rc-service apache2 start > [] Starting Apache httpd web server: apache2AH00558: apache2: > Could not reliably determine the server's fully qualified domain > name, using 127.0.0.1. Set the 'ServerName' directive globally to > suppress this message . ok root@mini:/lib/x86_64-linux-gnu# > cd /var/log/apache2/ root@mini: /var/log/apache2# ls -l total 4 > -rw-r- 1 root adm 0 Jul 27 16:05 access.log > -rw-r- 1 root adm 279 Jul 27 16:11 error.log > -rw-r- 1 root adm 0 Jul 27 16:05 other_vhosts_access.log > root@mini:/var/log/apache2# cat error.log > [Wed Jul 27 16:11:07.683444 2016] [mpm_event:notice] [pid 4687:tid > 140400470632320] AH00489: Apache/2.4.23 (Debian) configured -- > resuming normal operations [Wed Jul 27 16:11:07.683444 2016] > [core:notice] [pid 4687:tid 140400470632320] AH00094: Command line: > '/usr/sbin/apache2' root@mini:/var/log/apache2# exit > > > That's from a GNU script 'typescript' session log file, so I've done a > bit of touchup to remove control characters and similar spurious > artifiacts, session-logging of my typoes, and that sort of thing. > > Default index page loads using lynx. > > This is just a smoke-test, of course; I'm sure much more elaborate > testing would be possible if I pondered this for a while, and I > vaguely recall doing more the first time but can't remember exactly > what. ..aye, the perils of not keeping records of what you did. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Arnt Karlsen (a...@iaksess.no): > ..re-running your tests now, do you still get the same results > now, as back then when you first checked? root@mini:/tmp# cd /lib/x86_64-linux-gnu/ root@mini:/lib/x86_64-linux-gnu# chmod 000 libsystemd.so.0.3.1 root@mini:/lib/x86_64-linux-gnu# rc-service apache2 start [] Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message . ok root@mini:/lib/x86_64-linux-gnu# cd /var/log/apache2/ root@mini: /var/log/apache2# ls -l total 4 -rw-r- 1 root adm 0 Jul 27 16:05 access.log -rw-r- 1 root adm 279 Jul 27 16:11 error.log -rw-r- 1 root adm 0 Jul 27 16:05 other_vhosts_access.log root@mini:/var/log/apache2# cat error.log [Wed Jul 27 16:11:07.683444 2016] [mpm_event:notice] [pid 4687:tid 140400470632320] AH00489: Apache/2.4.23 (Debian) configured -- resuming normal operations [Wed Jul 27 16:11:07.683444 2016] [core:notice] [pid 4687:tid 140400470632320] AH00094: Command line: '/usr/sbin/apache2' root@mini:/var/log/apache2# exit That's from a GNU script 'typescript' session log file, so I've done a bit of touchup to remove control characters and similar spurious artifiacts, session-logging of my typoes, and that sort of thing. Default index page loads using lynx. This is just a smoke-test, of course; I'm sure much more elaborate testing would be possible if I pondered this for a while, and I vaguely recall doing more the first time but can't remember exactly what. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, 27 Jul 2016 13:17:40 -0700, Rick wrote in message <20160727201740.gf10...@linuxmafia.com>: > Quoting Simon Hobson (li...@thehobsons.co.uk): > > > And won't you then find that all those packages with gratuitous > > libsystemd0 dependencies will stop working ? > > I have a better question: Is there something about empiricism that > many people on this mailing list cannot cope with? > > Back when I had newly joined this mailing list and all of these idle > allegations and rhetorical questions started being posted, I decided > to do that thing What's it called? Oh, right: 'Checking.' > > I did a quick smoke test on my test VM by chmod'ing > /lib/x86_64-linux-gnu/libsystemd.so.0.3.1 to 000, starting Apache, > making sure it appeared to work OK, and skimming its logs looking for > anything amiss. Nothing wrong that I was able to see. > > If I ever get to worrying about this in production after attending to > all the myriad _real_ concerns I have, I suppose I'd more-carefully > check various things that might have screwy problem and might not. > Meanwhile, I also would expect none, simply on grounds of the known > facts of what's in the damned thing. > > Now, you guys presumably all have Linux systems. Why pose the > question? Why not just check, if you want to know? ..re-running your tests now, do you still get the same results now, as back then when you first checked? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 27/07/16 21:21, Rick Moen wrote: Quoting Rainer Weikusat (rweiku...@talktalk.net): these are obviously not identical: The subjects differ. I repeat: I really did not understand what you were saying, and I still don't. Therefore, I summarised my best guess, apologised for probably being dense and overly fond of the specific and concrete, and attempted to suggest giving up said discussion, especially given that mostly you seemed to be devoted to finding fault with me personally. Is there some reason this is not a good idea? I continue to think it is. I'm bored with this. I don't care. Stop it. As soon as I have finished my current Android project using my main laptop running debian sid anything that has 'systemd' as part of its name goes. And that will mean goodbye to debian, hopefully hello devuan, but there's all those BSDs out there... DaveT - looking forward to a weekend spent converting the Harley from EFI to carb. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweiku...@talktalk.net): > these are obviously not identical: The subjects differ. I repeat: I really did not understand what you were saying, and I still don't. Therefore, I summarised my best guess, apologised for probably being dense and overly fond of the specific and concrete, and attempted to suggest giving up said discussion, especially given that mostly you seemed to be devoted to finding fault with me personally. Is there some reason this is not a good idea? I continue to think it is. -- Cheers, Saturday night in Toledo, Ohio Rick Moen Is like being nowhere at all. r...@linuxmafia.com All through the day as the hours rush by youtube.com/watch?v=XZUGSSYlPYI You sit in the park and you watch the grass die. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > And won't you then find that all those packages with gratuitous > libsystemd0 dependencies will stop working ? I have a better question: Is there something about empiricism that many people on this mailing list cannot cope with? Back when I had newly joined this mailing list and all of these idle allegations and rhetorical questions started being posted, I decided to do that thing What's it called? Oh, right: 'Checking.' I did a quick smoke test on my test VM by chmod'ing /lib/x86_64-linux-gnu/libsystemd.so.0.3.1 to 000, starting Apache, making sure it appeared to work OK, and skimming its logs looking for anything amiss. Nothing wrong that I was able to see. If I ever get to worrying about this in production after attending to all the myriad _real_ concerns I have, I suppose I'd more-carefully check various things that might have screwy problem and might not. Meanwhile, I also would expect none, simply on grounds of the known facts of what's in the damned thing. Now, you guys presumably all have Linux systems. Why pose the question? Why not just check, if you want to know? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Hendrik Boom writes: > On Wed, Jul 27, 2016 at 10:34:55AM -0700, Rick Moen wrote: >> By the way, what specifically does 'entangle it with unwanted >> systemd-isms' actually _mean_, and what does that have to do with >> whatever-the-heck-it-was that Rainier said? Once again, it seems to me, >> there's vagueness in unfortunate parts of this narrative. > > It obviousy depends on what is wanted and what is not wanted. That > depends on the user and system administrator. libsystemd on its own doesn't entangle anyhting with anything else as it's just a runtime link library providing systemd API symbols (as I've written quite a few times already). But its presence enables people to 'entangle' unrelated applications (like apache) with systemd-specific function calls (of no use to anyone but systemd users): Weren't it for libsystemd, UNIX(*) application which were 'enhanced' with systemd API calls like sd_notify wouldn't run on systems without systemd anymore. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting dev (devua...@gmail.com): > On systems where security and stability are important, needless > dependencies and pointless software expose a broader attack surface. Generically, yes. I definitely always appreciate having less unwanted code on my system, particularly code that ever runs with elevated privilege. Short of Gentoo-style local building of packages and tweaking build options, it's non-trivial to do that, though. I've covered a couple of the ways to do that. If you have practical suggestions rather than just vague philophising, I'm still waiting to hear them. > On server systems, it's considered best practice to install the > minimal amount of software needed for the running services, and no > more. You're aware that I'm a sysadmin, right? Just checking. > Historically speaking, most Linux distros easily strip-down this > way. Yeah, right. Thus the Kerberos libraries for /usr/bin/ssh. *headdesk* > Systemd seems well on it's way to reverse that. I would say > that is most certainly of "particular importance" We weren't talking about that, though, only libsystemd0. (Seriously, guys, you do need to FAQ that.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: > ... then I'll be replacing libsystemd0 with an 'equivs' > recipe about two minutes later. And won't you then find that all those packages with gratuitous libsystemd0 dependencies will stop working ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Wed, Jul 27, 2016 at 10:34:55AM -0700, Rick Moen wrote: > > By the way, what specifically does 'entangle it with unwanted > systemd-isms' actually _mean_, and what does that have to do with > whatever-the-heck-it-was that Rainier said? Once again, it seems to me, > there's vagueness in unfortunate parts of this narrative. It obviousy depends on what is wanted and what is not wanted. That depends on the user and system administrator. -- hendrik > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Hendrik Boom writes: > On Tue, Jul 26, 2016 at 11:01:04AM -0700, Rick Moen wrote: >> Quoting Rainer Weikusat (rweiku...@talktalk.net): >> > Rick Moen writes: >> > > Quoting Rainer Weikusat (rweiku...@talktalk.net): >> > > >> > >> To re-iterate this: >> > > >> > > [more very strangely worded, difficult-to-parse prose, seemingly alleging >> > > that library libsystemd0 can be used to insert 'calls' into unrelated >> > > applications -- which assertion in my view does not seem correct, if I >> > > am parsing this odd claim correctly] >> > > >> > >> I honestly understand why stating this as it is causes hostile >> > >> reactions. >> > > >> > > I cannot recall having said anything hostile to you, >> > >> > Replacing >> > >> >Because of libsystemd, a systemd sub-project, technically >> >gratuitious calls to systemd-specific functions >> >can be inserted into unrelated applications. [as it provides the >> >required symbols] >> > >> > with >> > >> >libsystemd can be used to insert 'calls' into unrelated >> >applications >> > >> > won't win you any prices for objectivity. >> > >> > But this kind of 'discussion' is as tiresome as it is useless. >> >> Rainer, I did not, and do not, understand how the mere presence of >> libsystemd0 can insert 'calls to systemd-specific functions' >> into related applications. > > Once again, it is a matter of trust, not technical content. Do you > trust the maintainers of libsystemd0 not to entangle it with unwanted > systemd-isms? You evidently do. Rainer does not. If you look at simplified, abstracted version of my sentence, you'll note that it basically says X enables Y to do Z while Moen's sentence is X does Z these are obviously not identical: The subjects differ. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Hendrik Boom (hend...@topoi.pooq.com): > Once again, it is a matter of trust, not technical content. Do you > trust the maintainers of libsystemd0 not to entangle it with unwanted > systemd-isms? You evidently do. Rainer does not. I'm certainly willing to consider the possibility that the upstream coders are evil _and_ the package maintainers are evil _and_ that nobody I read including the entire brain trust of LWN.net can figure that out and tell me. If those two extremely coincidentally evil parties collaborate _and_ everyone completely fails to notice, then I'm indeed in trouble. If those two extremely coincidentally evil parties collaborate and someone _does_ notice, then I'll be replacing libsystemd0 with an 'equivs' recipe about two minutes later. Incidentally, if both extremely coincidentally evil parties collaborate and nobody notices, I am probably in trouble on far more significant matters than libsystemd0, and I'd have extremely just cause to start getting deeply paranoid about every single one of the... $ dpkg -l | grep '^ii' | wc -l 685 $ ...685 package on my server, all of which would suddenly become very threatening. If your point is merely that one ends up bestowing (conditional) trust onto the developers of all distro packages one runs, that is true but banal and obvious. If you wish to assert that I have some particular and pronounced reason I should distrust a distro packager of libssytemd0 _and_ that the entire Linux community would utterly fail to notice this betrayal, I have yet to hear it, and wait with polite anticipation (but I'm not holding my breath waiting). By the way, what specifically does 'entangle it with unwanted systemd-isms' actually _mean_, and what does that have to do with whatever-the-heck-it-was that Rainier said? Once again, it seems to me, there's vagueness in unfortunate parts of this narrative. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/26/2016 12:37 PM, Rick Moen wrote: It _was_ indeed an unnecessary build dependency. Precisely my point. A point which could be made about systemd in general: A lot of unnecessary. agree that it's 'problematic' in the sense that I'd rather not have it on my systems, but it's not of particular importance. On systems where security and stability are important, needless dependencies and pointless software expose a broader attack surface. On server systems, it's considered best practice to install the minimal amount of software needed for the running services, and no more. Historically speaking, most Linux distros easily strip-down this way. Systemd seems well on it's way to reverse that. I would say that is most certainly of "particular importance" ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Tue, Jul 26, 2016 at 11:01:04AM -0700, Rick Moen wrote: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > > > Rick Moen writes: > > > Quoting Rainer Weikusat (rweiku...@talktalk.net): > > > > > >> To re-iterate this: > > > > > > [more very strangely worded, difficult-to-parse prose, seemingly alleging > > > that library libsystemd0 can be used to insert 'calls' into unrelated > > > applications -- which assertion in my view does not seem correct, if I > > > am parsing this odd claim correctly] > > > > > >> I honestly understand why stating this as it is causes hostile > > >> reactions. > > > > > > I cannot recall having said anything hostile to you, > > > > Replacing > > > > Because of libsystemd, a systemd sub-project, technically > > gratuitious calls to systemd-specific functions > > can be inserted into unrelated applications. [as it provides the > > required symbols] > > > > with > > > > libsystemd can be used to insert 'calls' into unrelated > > applications > > > > won't win you any prices for objectivity. > > > > But this kind of 'discussion' is as tiresome as it is useless. > > Rainer, I did not, and do not, understand how the mere presence of > libsystemd0 can insert 'calls to systemd-specific functions' > into related applications. Once again, it is a matter of trust, not technical content. Do you trust the maintainers of libsystemd0 not to entangle it with unwanted systemd-isms? You evidently do. Rainer does not. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 26/07/2016 13:28, fsmithred a écrit : On 07/25/2016 06:09 PM, Didier Kryn wrote: Le 25/07/2016 23:35, fsmithred a écrit : Either way, it looks like libsystemd is passively providing code for something else to use. Calling a function does not mean that this function passively provides code to the caller. What happens is (simplified) the program counter (the address from which instructions are fetched) jumps to the called function, and, when the function has finished execution (encountering the return instruction, returns to the caller, just one instruction after the initial jump. Didier Thanks. I had to read that a few times before it sunk in, but it makes sense, and it's consistent with what I know about shell programming. It is just about the concept of active or passive things. One could say the only active thing in the computer is, to simplify, the processor cores. In that sense all instructions are passive, wether they are in the main program or in a subprogram and wether this subprogram belongs to a static or dynamic library does not change it. But it is a common shortcut to speak of instruction as if *they* do something, and, in that sense also, it is the same if they belong to a subprogram. People working on compilers, linkers and that sort of things refer to the machine instructions as "text". I think it is because it is the text read and executed by the cpu, a text written in the language of the cpu. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Tue, 26 Jul 2016 11:35:25 -0400 Hendrik Boom wrote: > On Tue, Jul 26, 2016 at 07:58:19AM -0500, dev wrote: > > > Systemd isn't going to stop at just init. There are far to many > > opportunities to embrace, extend and extinguish entire > > distributions. > > A point of grammar: Wrong verb tense. > > Systemd hasn't stopped at just init, As I once said on Debian-User, Redhat won't be satisfied until cat requires systemd. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Tue, Jul 26, 2016 at 07:58:19AM -0500, dev wrote: > Systemd isn't going to stop at just init. There are far to many > opportunities to embrace, extend and extinguish entire distributions. A point of grammar: Wrong verb tense. Systemd hasn't stopped at just init, -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweiku...@talktalk.net): > Rick Moen writes: > > Quoting Rainer Weikusat (rweiku...@talktalk.net): > > > >> To re-iterate this: > > > > [more very strangely worded, difficult-to-parse prose, seemingly alleging > > that library libsystemd0 can be used to insert 'calls' into unrelated > > applications -- which assertion in my view does not seem correct, if I > > am parsing this odd claim correctly] > > > >> I honestly understand why stating this as it is causes hostile > >> reactions. > > > > I cannot recall having said anything hostile to you, > > Replacing > > Because of libsystemd, a systemd sub-project, technically > gratuitious calls to systemd-specific functions > can be inserted into unrelated applications. [as it provides the > required symbols] > > with > > libsystemd can be used to insert 'calls' into unrelated > applications > > won't win you any prices for objectivity. > > But this kind of 'discussion' is as tiresome as it is useless. Rainer, I did not, and do not, understand how the mere presence of libsystemd0 can insert 'calls to systemd-specific functions' into related applications. I _also_ did not understand what your phrase 'systemd-specific functions' refers to in this context. Are you referring to the interface glue code in libsystemd0? If so, given that, AFAIK, it doesn't actually do anything in the absence of systemd, what is the importance, the real-world significance of those functions? What are they going to -do- on a systemd-less system, and how, by what means, are they going to do it? I said upthread that I was not following what you were saying, and would appreciate a specific example because I really didn't understand this overly abstract and non-specific discussion. I apologised for probably being obtuse on this matter, and for my preference for concrete specifics when things seem suspiciously vague. You then seemed to accuse me of bad faith, and I said, well, maybe this conversation is doomed and we'd have better luck on some other conversation on a different occasion. Now, you're coming back and saying I lack objectivity. Maybe so -- or maybe I just didn't fully understand a very strangely worded and somewhat vague passage. And maybe I need more coffee. Or maybe this conversation is doomed and we'd have better luck on some other conversation on a different occasion -- which is what I strongly suspect. Anyway, if you wish to be more clear and specific, that would be perhaps useful and I would read what you say with interest. I don't promise to comment, because my recent experience attempting to engage with you has been frustrating and rather unpleasant, and my masochism has limits. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting dev (devua...@gmail.com): > On 07/26/2016 04:26 AM, Rick Moen wrote: > > >libsystemd0's status as a bundle of interface code that does nothing in > >the absence of systemd is not because it's a library -- obviously -- but > >rather because all it _contains_ is interface code that does nothing in > >the absence of systemd > > Well now, if that were true, it would not need to be there at all > and the apache common lib could be installed without needing that > systemd dependency. Correct? I notice you're not citing specific package names and dependencies. Forgive an old cynic, but this means you're not bothering to gather data and check facts, right? Because that's for other people? So, instead, you post vague rhetorical questions about 'the apache common lib', not bothering to say what you're talking about, and checking nothing. And you expect me to spend time on this. Well, maybe I'm bored or a masochist, but I'll spend time on it. ;-> I was just looking up the matter. There was previously a package in Debian 8 'Jessie' called apache2-common that had an apparently spurious build dependency on library package libsystemd0. It got replaced by tranaitional package apache2.2-common (https://packages.debian.org/jessie/apache2.2-common), which then went away as part of the transition to Apache httpd 2.4. In a quick check through the dependency chains of current package 'apache2' (Apache httpd 2.4), I no longer see any chain that resolves to libsystemd0. I could have missed it, but... well, hold on. Easy to check that. On my Debian 8 'Jessie' test VM, doing 'apt-cache --no-pre-depends --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances rdepends libsystemd0' returns a list of 126 packages that no longer include any part of Apache2 httpd. If you want, I can send that output to Pastebin for you to use in your {COUGH} careful research {COUGH}. Let's talk about the previous package apache2-common, which is what I believe your lazy hand-wave probably was intending to talk about. It had an pointless library dependency on libsystemd0. Certainly _if_ you were to recompile/rebuild former package apache2-common to eliminate that dependency, then it would have been installable without dragging in libsystemd0. By the way, did you notice that your largely incoherent question appears to make the non-sequitur conclusion that _because_ the former apache2-common package required libsystemd0 as a dependency, that made it incorrect to assert (as I did) that libsystemd0 is interface code that does nothing in the absence of systemd? Probably not. > It seems I cannot have a functioning Apache system on Debian 8 > without installing at least some minimal facet of systemd and that's > problematic if not for any other reason than simply being an > unnecesary dependency. It _was_ indeed an unnecessary build dependency. My quick check suggests the package maintainers made it go away, for whatever that's worth. Of course, there are quite a few others that also have it. I agree that it's 'problematic' in the sense that I'd rather not have it on my systems, but it's not of particular importance. > What this all really illustrates is the > insidious nature of systemd assimilation and how far things have > gone, and how far they will continue to go. No, what it illustrates is that many packages have overly broad and in many cases pointless library and other dependencies. This is a _general_ problem, and I have been collecting techniques to deal with it, and documenting them. Something tells me I'll get no help from you, as all you've offered is lazy handwaves and time-wasting advocacy rhetoric. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Didier Kryn writes: > Le 25/07/2016 23:35, fsmithred a écrit : >> Either way, it >> looks like libsystemd is passively providing code for something else to >> use. > Calling a function does not mean that this function passively > provides code to the caller. But the library does that (or at least, that's how its function could be described). After compiling the following program, #include int main(void) { puts("Hello?"); return 0; } - the resulting ELF binary records the name of the C library in its DT_NEEDED section, [rw@doppelsaurus]/tmp#objdump -p a.out | grep NEEDED NEEDED libc.so.6 and its symbol table contains an 'undefined' entry for puts [rw@doppelsaurus]/tmp#objdump --syms a.out | grep puts F *UND* puts@@GLIBC_2.2.5 When starting the program, the dynamic linker loads the needed libraries and then tries to resolve any undefind symbols: [rw@doppelsaurus]/tmp#LD_DEBUG=libs,symbols,bindings ./a.out 2>&1 3922: find library=libc.so.6 [0]; searching 3922: search cache=/etc/ld.so.cache 3922: trying file=/lib/x86_64-linux-gnu/libc.so.6 [...] 3922: symbol=puts; lookup in file=./a.out [0] 3922: symbol=puts; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 3922: binding file ./a.out [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `puts' [GLIBC_2.2.5] This means in order to start the program, both the library file and the actual symbol definition is needed. The dynamic symbol table of the library provides the address of the entry point in the function, [rw@doppelsaurus]/tmp#objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep puts 00068e90 gDF .text 01b2 GLIBC_2.2.5 _IO_puts 00068e90 w DF .text 01b2 GLIBC_2.2.5 puts And this address is then used to 'connect' calls made by the program to the code provided by the library. The code of the function can be found by running objdump -d /lib/x86_64-linux-gnu/libc.so.6 | less and searching for address recorded in the dynamic symbol table (with leading zeroes omitted, ie, 68e90). > What happens is (simplified) the program > counter (the address from which instructions are fetched) jumps to the > called function, and, when the function has finished execution > (encountering the return instruction, returns to the caller, just one > instruction after the initial jump. This is what happens after the program was started if a from the library is actually called. The following program -- #include int main(void) { printf("%p\n", puts); return 0; } --- uses the puts symbol without calling the function. A program may also load a library (shared object, actually) at run time and perform all these steps with explictly written code instead of relying on the dynamic linker (containing similar code). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
dev wrote: << It seems I cannot have a functioning Apache system on Debian 8 without installing at least some minimal facet of systemd and that's problematic if not for any other reason than simply being an unnecesary dependency. What this all really illustrates is the insidious nature of systemd assimilation and how far things have gone, and how far they will continue to go. >> SystemD is an "excuse", disguised as progress, to replace most of GNU software, by assuming the interests of a portion of desktop users, should come first. This is one reason that explains what is causing the creep. The other reason is intentionally making packages dependent on systemd to make it harder for alternatives to survive. Grounds tinfoil hat to discharge dangerous voltage levels. -- Those who abuse me will be banned immediately from my email account. Here, I am communicating with supposedly intelligent adults who are responsible for their actions. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/26/2016 09:58 PM, dev wrote: On 07/26/2016 04:26 AM, Rick Moen wrote: libsystemd0's status as a bundle of interface code that does nothing in the absence of systemd is not because it's a library -- obviously -- but rather because all it _contains_ is interface code that does nothing in the absence of systemd Well now, if that were true, it would not need to be there at all and the apache common lib could be installed without needing that systemd dependency. Correct? It seems I cannot have a functioning Apache system on Debian 8 without installing at least some minimal facet of systemd and that's problematic if not for any other reason than simply being an unnecesary dependency. What this all really illustrates is the insidious nature of systemd assimilation and how far things have gone, and how far they will continue to go. Systemd isn't going to stop at just init. There are far to many opportunities to embrace, extend and extinguish entire distributions. You are not kidding me? Is that because of mod_systemd? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/26/2016 04:26 AM, Rick Moen wrote: libsystemd0's status as a bundle of interface code that does nothing in the absence of systemd is not because it's a library -- obviously -- but rather because all it _contains_ is interface code that does nothing in the absence of systemd Well now, if that were true, it would not need to be there at all and the apache common lib could be installed without needing that systemd dependency. Correct? It seems I cannot have a functioning Apache system on Debian 8 without installing at least some minimal facet of systemd and that's problematic if not for any other reason than simply being an unnecesary dependency. What this all really illustrates is the insidious nature of systemd assimilation and how far things have gone, and how far they will continue to go. Systemd isn't going to stop at just init. There are far to many opportunities to embrace, extend and extinguish entire distributions. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/25/2016 06:09 PM, Didier Kryn wrote: > Le 25/07/2016 23:35, fsmithred a écrit : >> Either way, it >> looks like libsystemd is passively providing code for something else to >> use. > Calling a function does not mean that this function passively provides > code to the caller. What happens is (simplified) the program counter (the > address from which instructions are fetched) jumps to the called function, > and, when the function has finished execution (encountering the return > instruction, returns to the caller, just one instruction after the initial > jump. > > Didier > Thanks. I had to read that a few times before it sunk in, but it makes sense, and it's consistent with what I know about shell programming. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen writes: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > >> To re-iterate this: > > [more very strangely worded, difficult-to-parse prose, seemingly alleging > that library libsystemd0 can be used to insert 'calls' into unrelated > applications -- which assertion in my view does not seem correct, if I > am parsing this odd claim correctly] > >> I honestly understand why stating this as it is causes hostile >> reactions. > > I cannot recall having said anything hostile to you, Replacing Because of libsystemd, a systemd sub-project, technically gratuitious calls to systemd-specific functions can be inserted into unrelated applications. [as it provides the required symbols] with libsystemd can be used to insert 'calls' into unrelated applications won't win you any prices for objectivity. But this kind of 'discussion' is as tiresome as it is useless. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/25/2016 05:57 PM, Rick Moen wrote: > If you ever feel like trying a less-brittle Desktop Environment ('DE'), > consider LXQt or Enlightenment. (A more-radical step would be no DE at > all, which is my personal preference. To me, a DE is a goulash of apps I > want with ones I don't, so I see no value in the ensemble. But as > Prince Orlovsky said in 'Die Fledermaus', Chacun à son goût: > https://www.youtube.com/watch?v=l6uEmtn56M0 ) > I did try both of those, and we clearly have different tastes. My first impressions of LXQt are that it's as pretty as IceWM (pretty ugly) at twice the ram, but at least it has graphical configuration tools that are easy to find. I know it's still young, so I've promised to give it another chance. I liked lxde and used it for a while. There was an early version of Refracta that had e-17 on Lenny (before I inherited the project.) I was impressed with how much it could do with so little. I even pulled some memory sticks out of the computer to see how small it could get, and I was able to operate the desktop with terminal, file manager and text editor with only 64MB. The first systemd-free version of Refracta had openbox with lxpanel and spacefm. I could see going back to that, but I have to answer to users, and it looks like we're sticking with xfce for the time being. It really is quite workable and should not be put in the same category as Gnome or KDE. I don't have the patience (or hardware resources) for those two. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > And you've gone on to keep extrapolating that "that's all a library does". No, that's all that _this_ library does. And, no, I did not 'extrapolate' anything. If you think so, you didn't read what I wrote correctly, and ought to fix that. libsystemd0's status as a bundle of interface code that does nothing in the absence of systemd is not because it's a library -- obviously -- but rather because all it _contains_ is interface code that does nothing in the absence of systemd -- according to people who keep an eye on such things, and also that's what it's documented to be. If you want to determine whether those people are correct or not, you're welcome to learn to read code and do likewise. Personally, I'm glad to rely on those who do. And, pending my getting the library off my system, I'm not going to waste time worrying about it any more than I waste time worrying about the Kerberos libraries. If _you_ wish to do so, on the other hand, feel free and have fun. I'm sorry you did not understand the phrase 'it's just a library' and erroneously overread that as a claim that libraries qua libraries cannot do anyting. Perhaps if you bothered to read some basic documentation, such as I recommended, you would not have encountered this problem. > I have not at any point disputed that that may be all it does now - > yes you persist in wording your replies in a manner which (whether > deliberate or not) implies that all such a library can do is > "nothing". I did not say, and would not say, that a libarary does nothing on grounds of it being a library. What is well established is that _this_ library is just interface code for systemd, and therefore does nothing in its absence because of the particular contents the library has. And I don't expect the Kerberos 5 libraries to suddenly start attacking my system because of the particular contents _they_ have. Either one _could_ be caused by a collaboration between evil upstream developers and evil distribution packagers to attack my system. But that's extremely low on my list of things to worry about. Your paranoia priorities differ? Great, have fun. > Now lets settle this once and for all, the thing is that this is > supposed to be about choice. I really don't care whether you are happy > or not having libsystemd0 on your system - that's your choice, based > on your priorities, policies, etc, etc. Are you talking to _me_ because you think I'm somehow in your way? If so, you are greatly in error, and I'd appreciate it if you would direct your rants at someone else who actually is in your way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: >> OK, that's what I thought, which is at odds with some comments that have >> been made. > > Well, if you're referring to 'comments that have been made' about > libsystemd0, the more useful (IMO) comments characterised what is > actually present in that library, that it contains just interface code > that absent systemd does[1] nothing And you've gone on to keep extrapolating that "that's all a library does". I have not at any point disputed that that may be all it does now - yes you persist in wording your replies in a manner which (whether deliberate or not) implies that all such a library can do is "nothing". Now lets settle this once and for all, the thing is that this is supposed to be about choice. I really don't care whether you are happy or not having libsystemd0 on your system - that's your choice, based on your priorities, policies, etc, etc. It is *MY* choice that I don't want it on my systems. It's not just the "what could they slip in" bit - there are a number of more philosophical reasons. I really don't care if *YOU* think it's paranoid - it's *MY* choice (which happens to be shared by others). Please respect that, because your tone throughout this thread suggests that you don't respect that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 25/07/2016 23:35, fsmithred a écrit : Either way, it looks like libsystemd is passively providing code for something else to use. Calling a function does not mean that this function passively provides code to the caller. What happens is (simplified) the program counter (the address from which instructions are fetched) jumps to the called function, and, when the function has finished execution (encountering the return instruction, returns to the caller, just one instruction after the initial jump. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting fsmithred (fsmith...@gmail.com): > Yeah, that was me, and it was based on partially incorrect testing. I set > the permissions to 000 on the wrong target. The test with the dummy > libsystemd0 package worked great to fulfill the package dependency and > allowed me to install gvfs, but gvfs wouldn't make the drive icons. > > I repeated the permissions test on the correct target with the real > libsystemd (chmod 000 /lib/i386-linux-gnu/libsystemd.so.0.3.1) > and I got the same result. If libsystemd is not readable, gvfs won't show > the drive icons. Let me take a moment to thank you for going to the effort. I respect seeking meaningful data rather than just posting advocacy, so I appreciate that. No worries about the mistake; if I had to pay a penny for every technical mistake or erroneous characterisation I made, I'd be poor indeed. > So yes, I agree with you that it looks like it's gvfs that's doing > something, and the something it's probably doing is using code in > libsystemd. Or maybe it's telling something else to do it. Either way, it > looks like libsystemd is passively providing code for something else to > use. If the code is being used by some program, that's doing something. > > Is there another interpretation of these results? My guess is and was that gfvs merely checks for existence/nonexistence of a function inside gvfs, and does disable/enable based on what it finds. If you ever feel like trying a less-brittle Desktop Environment ('DE'), consider LXQt or Enlightenment. (A more-radical step would be no DE at all, which is my personal preference. To me, a DE is a goulash of apps I want with ones I don't, so I see no value in the ensemble. But as Prince Orlovsky said in 'Die Fledermaus', Chacun à son goût: https://www.youtube.com/watch?v=l6uEmtn56M0 ) -- Cheers, "My opinions may have changed, Rick Moen but not the fact that I'm right." r...@linuxmafia.com -- Ashleigh Brilliant McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/25/2016 01:35 PM, Rick Moen wrote: > Quoting Simon Hobson (li...@thehobsons.co.uk): > >> Thanks, a bit heavy going for me at this time in the morning ! > > Well, if you want to learn the subject, there's an irreducible minimum > of complexity, you know, but it was mostly a citation I gave as an > accuracy cross-check on my ultra-quick extemporaneous description. > I.e., you needn't take my word for this bit; here's a decent write-up. > >> OK, that's what I thought, which is at odds with some comments that have >> been made. > > Well, if you're referring to 'comments that have been made' about > libsystemd0, the more useful (IMO) comments characterised what is > actually present in that library, that it contains just interface code > that absent systemd does[1] nothing -- and the way one knows that is to > either read the source code or rely on the characterisations of those > who have. The fallback paranoia position then inevitably gets trotted > out, of 'Yes, but evil nasty upstream in collusion with evil nasty > distro packagers could _in the future_ add code that steals my lunch, > sends my e-mails to the FSB, and opens a subspace channel to V'ger.' > > The same is of course possible for the contents of every other Linux > distribution package. And the distro installers. And maybe even the > documentation, etc. > > Far be it from me to recommend less paranoia, but I might make the > modest and mild suggestion that unfocussed paranoia wastes time. > > Upthread, I quite seriously suggested libsystemd0 package dependency > should have long ago been FAQed, and, fellahs, you really ought to. > This topic should have gotten put to rest years ago, rather than > rehashed over and over. > > [1] Someone disputed this characterisation by citing the GNOME gvfs > code in XFCE4 providing or not providing 'drive icons' depending on > whether libsystemd0 is present or not. The poster claimed this was > libsystemd0 'doing something'. To me, it looked like GNOME gvfs 'doing > something', and further proof of GNOME being a fragile dependency > hairball, as if that were needed. But make up your own mind. > Yeah, that was me, and it was based on partially incorrect testing. I set the permissions to 000 on the wrong target. The test with the dummy libsystemd0 package worked great to fulfill the package dependency and allowed me to install gvfs, but gvfs wouldn't make the drive icons. I repeated the permissions test on the correct target with the real libsystemd (chmod 000 /lib/i386-linux-gnu/libsystemd.so.0.3.1) and I got the same result. If libsystemd is not readable, gvfs won't show the drive icons. So yes, I agree with you that it looks like it's gvfs that's doing something, and the something it's probably doing is using code in libsystemd. Or maybe it's telling something else to do it. Either way, it looks like libsystemd is passively providing code for something else to use. If the code is being used by some program, that's doing something. Is there another interpretation of these results? -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > Thanks, a bit heavy going for me at this time in the morning ! Well, if you want to learn the subject, there's an irreducible minimum of complexity, you know, but it was mostly a citation I gave as an accuracy cross-check on my ultra-quick extemporaneous description. I.e., you needn't take my word for this bit; here's a decent write-up. > OK, that's what I thought, which is at odds with some comments that have been > made. Well, if you're referring to 'comments that have been made' about libsystemd0, the more useful (IMO) comments characterised what is actually present in that library, that it contains just interface code that absent systemd does[1] nothing -- and the way one knows that is to either read the source code or rely on the characterisations of those who have. The fallback paranoia position then inevitably gets trotted out, of 'Yes, but evil nasty upstream in collusion with evil nasty distro packagers could _in the future_ add code that steals my lunch, sends my e-mails to the FSB, and opens a subspace channel to V'ger.' The same is of course possible for the contents of every other Linux distribution package. And the distro installers. And maybe even the documentation, etc. Far be it from me to recommend less paranoia, but I might make the modest and mild suggestion that unfocussed paranoia wastes time. Upthread, I quite seriously suggested libsystemd0 package dependency should have long ago been FAQed, and, fellahs, you really ought to. This topic should have gotten put to rest years ago, rather than rehashed over and over. [1] Someone disputed this characterisation by citing the GNOME gvfs code in XFCE4 providing or not providing 'drive icons' depending on whether libsystemd0 is present or not. The poster claimed this was libsystemd0 'doing something'. To me, it looked like GNOME gvfs 'doing something', and further proof of GNOME being a fragile dependency hairball, as if that were needed. But make up your own mind. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 25/07/2016 16:26, Simon Hobson a écrit : I don't think even Poettering cold get away with deprecating the existing syslog call - force EVERY binary to change to not use syslog ? I bet this is already done. I mean there's no need to use another API than syslog. There are already several alternative syslog servers all using the same API. Systemd can do the same; it is not complicated: just read the syslog socket. The problem is then for the admin to browse the f. binary logs. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
To expand a bit on what I wrote earlier - now it's finally condensed into something resembling a coherent thought. Suppose, with SystemD running they decided to break normal syslog calls. Ie, they made it so that a program could not call syslog, but instead had to use a SystemD call. Given the way they are prepared to ride roughshod over anything that's in the way, it's not inconceivable that they'd try. As a developer, you now have to sprinkle your code (or add a routine) to wrap every logging call with a "if systemd then ... else syslog" block. Devs might start moaning a bit about that, so then the next logical step is to add to libsystemd all the code needed to be able to log on non-systemd systems - so an application only needs to use the systemd logging call. It might start off as just a simple "if systemd then ... else syslog" routine, but then they can change it to just incorporate the logging from systemd altogether. So now there's a bit of systemd, the much reviled logging system, that's now infiltrated the system. OK, it's a bit made up, and I don't think even Poettering cold get away with deprecating the existing syslog call - force EVERY binary to change to not use syslog ? But it's an example of the process I could see them being happy to use to infiltrate their code onto systems, only "to be helpful" of course. I'm sure others could come up with more likely functions they might have a go at. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Hendrik Boom wrote: >> OK, so what makes libsystemd different from libc, which comes from the same >> source? libc is stored in the same directory on the same debian servers... > > It is a matter of trust, not of what is technically feasible. Exactly > Does one trust the libc developers more than the libsystemd developers? That's not a hard question is it. One library comes from a team with a good track record, building a "tool to do specific things - not include the kitchen sink", and with respect for others' work. The other ... ermm ... the least said the better. So is it paranoid to want to keep off your system a block of code written and maintained by "a bunch of vandals" ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 25-07-16 15:22, Hendrik Boom wrote: It is a matter of trust, not of what is technically feasible. Does one trust the libc developers more than the libsystemd developers? -- hendrik ___ That question is not very hard to answer. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 25/07/2016 15:17, Arnt Gulbrandsen a écrit : OK, so what makes libsystemd different from libc, which comes from the same source? Not the same source: libc comes from GNU (and there are alternatives), while libsystemd comes from Lennart and the Red Hats. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Mon, Jul 25, 2016 at 02:17:01PM +0100, Arnt Gulbrandsen wrote: > Hendrik Boom writes: > >Just linking isn't enough, unless there's something about the loading > >process that I don't know. (Maybe C++ has something special for module > >initialization?) > > No, nothing that special. > > >But if an application is linked with libsystemd, it is likely to call one > >of the libsystemd functions. If so, putting a printf("Hello world!") into > >that function would suffice. > > OK, so what makes libsystemd different from libc, which comes from the same > source? libc is stored in the same directory on the same debian servers... It is a matter of trust, not of what is technically feasible. Does one trust the libc developers more than the libsystemd developers? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Hendrik Boom writes: Just linking isn't enough, unless there's something about the loading process that I don't know. (Maybe C++ has something special for module initialization?) No, nothing that special. But if an application is linked with libsystemd, it is likely to call one of the libsystemd functions. If so, putting a printf("Hello world!") into that function would suffice. OK, so what makes libsystemd different from libc, which comes from the same source? libc is stored in the same directory on the same debian servers... Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On Mon, Jul 25, 2016 at 07:37:12AM +0100, Arnt Gulbrandsen wrote: > Hi Rainer, > > could you describe how this could be used to, say, make all applications > that link with libsystemd print "Hello world!" in addition to their normal > function? Just linking isn't enough, unless there's something about the loading process that I don't know. (Maybe C++ has something special for module initialization?) But if an application is linked with libsystemd, it is likely to call one of the libsystemd functions. If so, putting a printf("Hello world!") into that function would suffice. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Relax ;) Devuan pulls libc from debian. The next version of libsystemd could do anything, but some of the same people can put the same code in debian's libc. And libc is a great deal more difficult to audit, too. For the record, I think getting rid of libsystemd is a good thing. It's tidy. Bugs happen and every thing you don't have installed won't be a possible source of trouble. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Arnt Gulbrandsen wrote: > A library can do anything the executable can. Which is what I thought. So when someone states that "it's just a library, it doesn't do anything" then that needs taking with a pinch of salt because once anything calls one of it's functions, then that library can do lots of stuff. "It wouldn't make sense" for a library to do anything when the main system component isn't installed - but don't most of us think that little the systemd guys do makes sense anyway ? So the point I've been making before is that, even if libsystemd0 "does nothing" now, we can't be complacent that it won't change. Just imagine if a few devs started talking along the lines of "well if systemd isn't installed, doing X is a little harder" - I would not be in the least surprised to find "stuff to do X" getting shifted from "systemd" to libsystemd0. OK, it's not going to be an init system, and I imagine it would be quite hard (or would it ?) to get a well built daemon running, but is there anything to stop them (say) putting all the binary logging stuff in there so devs can use the systemd logging instead of using syslog ? And thus, the presence of libsystemd0 then allows parts of systemd itself to pervade non-systemd systems. OK, this many be paranoia - but I'm sure that was said about the threat of systemd when it's inclusion was being considered. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Simon Hobson writes: Yes, the latter wouldn't make much sense, but it's possible ? It's possible. Simplfying a little, an executable on linux is just a shared library that contains a function called main() (yes I know I'm simplifying, PLEASE let's not argue these details). A library can do anything the executable can. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: >> With a lib, is there any code or is it *JUST* a set of symbols ? > This is a pretty good introduction to how libraries work and what they > can contain: > http://www.skyfree.org/linux/references/ELF_Format.pdf Thanks, a bit heavy going for me at this time in the morning ! > Generically, a library can do just about anything, potentially. A > library is simply a set of compiled program routines that the get called > by executables (call to function dlopen) that invoke particular > functions within the libraries, and access symbols (call to function > dlsym). To know what's inside a _specific_ library, you need to look at > that library's source code. OK, that's what I thought, which is at odds with some comments that have been made. So basically, if I have a subsystem "foobar" and a library "libfoobar0", and in that library I have a call called "init_foobar" then that call could do : At one extreme, just recognise that foobar isn't installed and return a code to indicate that. At the other extreme, do a whole load of stuff, even if foobar itself isn't installed - basically anything up to and including forking a persistent process ? Yes, the latter wouldn't make much sense, but it's possible ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
A library is code, data, fixups (I think that's the wrong word, sorry) and a little bit of red tape for the file format. Fixups are changes to be made at runtime by the dynamic linker in order to make sure the code and calls work correctly at the runtime-assigned address(es). It may include loading subsidiary libraries. (The compiler/linker may optimise the library for a particular address, but the address-independency work is still done in principle.) Data is static variables, values of constant strings and such. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Simon Hobson (li...@thehobsons.co.uk): > I think what he means, is that it allows devs/packagers to insert > these calls and still have something that runs when systemd itself > isn't installed. Not that the lib itself installs such calls. First, thanks. (I seriously wasn't trying to ignore anyone's contributions, FWIW. I merely saw a conversation that seemed ill-omened, hence sought to gracefully exit it.) Second, I'd be curious to see real-world specific examples of whatever-this-is. > With a lib, is there any code or is it *JUST* a set of symbols ? Generically, a library can do just about anything, potentially. A library is simply a set of compiled program routines that the get called by executables (call to function dlopen) that invoke particular functions within the libraries, and access symbols (call to function dlsym). To know what's inside a _specific_ library, you need to look at that library's source code. This is a pretty good introduction to how libraries work and what they can contain: http://www.skyfree.org/linux/references/ELF_Format.pdf ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen wrote: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > >> To re-iterate this: > > [more very strangely worded, difficult-to-parse prose, seemingly alleging > that library libsystemd0 can be used to insert 'calls' into unrelated > applications -- which assertion in my view does not seem correct, if I > am parsing this odd claim correctly] I think what he means, is that it allows devs/packagers to insert these calls and still have something that runs when systemd itself isn't installed. Not that the lib itself installs such calls. One thing I am not clear about ... With a lib, is there any code or is it *JUST* a set of symbols ? Ie, when a package makes one of these gratuitous calls (because systemd insists on doing stuff the hard way) to the library ... Is it what I'd consider a call (ie a jump into a routine executing real machine instructions) but that the code there is minimal and basically just returns "nah, systemd not installed mate" ? Or is there some sort of "magic" that makes the "call" returns something but there's no code in there ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Hi Rainer, could you describe how this could be used to, say, make all applications that link with libsystemd print "Hello world!" in addition to their normal function? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweiku...@talktalk.net): > To re-iterate this: [more very strangely worded, difficult-to-parse prose, seemingly alleging that library libsystemd0 can be used to insert 'calls' into unrelated applications -- which assertion in my view does not seem correct, if I am parsing this odd claim correctly] > I honestly understand why stating this as it is causes hostile > reactions. I cannot recall having said anything hostile to you, but repeat that perhaps some other, future discussion will go better -- and that I see no point in continuing discussion. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen writes: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > >> I didn't expect you to stop the attempt to get a 'religious angle' into >> this just because I pointed out that your interpretation was completely >> wrong. > > I honestly don't understand the hostility, Rainier: To re-iterate this: At the most basic level, a shared library enables resolution of symbol references by the runtime linker with the ultimate goal to get a program to run despite other files than the program file itself are needed for this: Because of libsystemd, a systemd sub-project, technically gratuitious calls to systemd-specific functions can be inserted into unrelated applications. I honestly understand why stating this as it is causes hostile reactions. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweiku...@talktalk.net): > I didn't expect you to stop the attempt to get a 'religious angle' into > this just because I pointed out that your interpretation was completely > wrong. I honestly don't understand the hostility, Rainier: It seems like anything I say you interpret as bad faith, where I was merely expressing a preference for specifics and distrusting abstract discussion of 'purposes' in a discussion of software mechanics. If I've erred, you are certainly welcome to explain where. And, if I failed to comprehend and do justice to your thoughts, which is quite possible, I apologise: I'm entirely too fallible, and often caffeine-deficient. Other that to stress those things, and express my regret for my own failings and for this having not been a better sub-thread, I see no point in continuing discussion. Perhaps some other, future discussion will go better. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Didier Kryn (k...@in2p3.fr): > Here, AFAIU, systemd is different, it requires daemons to > communicate with it using its own library, so that it forces itself > into all the daemons. I am reasonably confident that systemd in its role as an init can start and stop services that have no dependency on its libraries. (However, I am not well informed on that subject however, because I've mostly avoided systemd.) > I'm sure we agree, just cheating on details :-) D'accord. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen writes: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > >> That's neither 'abstract' nor 'teleological' as you yourself nicely >> demonstrated by immediately coming up with an equivalent but different >> term after reinterpreting my statement in a way it clearly wasn't meant >> to be understood by exploiting ambiguities inherent in natural language. > > Seems pretty darned teleological and abstract to me. I didn't expect you to stop the attempt to get a 'religious angle' into this just because I pointed out that your interpretation was completely wrong. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 24/07/2016 23:55, Rick Moen a écrit : The several init systems I've used such as SysVInit, OpenRC, and runit do not require that 'applications' (services) talk to the init system using glue libraries. In fact, they don't need to talk to the init system at all, unless I'm misremembering something. Here, AFAIU, systemd is different, it requires daemons to communicate with it using its own library, so that it forces itself into all the daemons. Somehow, I'm getting the feeling we're communicating at cross-purposes, but I don't understand exactly how that happened. Somehow we got from libsystemd0 to... a discussion I don't entirely understand. I'm sure we agree, just cheating on details :-) Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Didier Kryn (k...@in2p3.fr): > Would it make any sense to have systemd with no application > talking to it? Someone (not me, but someone) might want it as an init system. ;-> (Infamously, the thing aspires to be many more things, but somewhere inside that mess there _is_ an init system: This was the entire point of V.R.'s / The Initfinder General's uselessd proof of concept.) The several init systems I've used such as SysVInit, OpenRC, and runit do not require that 'applications' (services) talk to the init system using glue libraries. In fact, they don't need to talk to the init system at all, unless I'm misremembering something. Somehow, I'm getting the feeling we're communicating at cross-purposes, but I don't understand exactly how that happened. Somehow we got from libsystemd0 to... a discussion I don't entirely understand. Anyhow, I concur with your upthread point that it would be good to know effective and reasonable ways to elminate unwanted library dependencies on a package-managed Linux system. Rebuilding packages to reduce build dependencies is one way, alternative packages with fewer library dependencies is another -- and there may be other ways I'm not currently recalling. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 24/07/2016 23:29, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Don't remember which package depends on some libkerberos5. Assuming it's openssh or some component of pam. Package openssh-client. $ ldd $(which ssh) linux-gate.so.1 => (0xb76ec000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7672000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb751a000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7516000) libz.so.1 => /usr/lib/libz.so.1 (0xb7502000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74d3000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb738c000) /lib/ld-linux.so.2 (0xb76ed000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb72da000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb72b7000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb72b4000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ad000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb72a9000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb729) $ On a system that actually uses Kerberos, pam_krb5.so also gets involved, and I don't remember how that actually works. (I've done some Kerberos in setting up Hadoop on CentOS 6, but not much more than just getting it going.) This raises a fundamental problem of distros. openssh and pam must be able to make use of as many authentication protocols as possible to cover the needs of all users. How can you reach this goal without linking them to the corresponding libraries? It is indeed a thorny problem. One common answer is the Gentoo-style one where you employ USE flags or equivalent, and recompile & rebuild packages to trim build dependencies. It's certainly possible to carry out a similar action on a deb-packaged distro by locally rebuilding deb packages, tweaking the 'rules' file before compiling to reduce build dependencies. Or, as you say, there could be regular packages with several different flavours, some with more dependencies, some with fewer. The case of libsystemd0 is different. In an OS proposing systemd, it is normal to have libsystemd0, but not in a system which excludes it completely. Here is the choice Devuan faces: if systemd is installable, then many packages must depend on libsystemd, if no package depends on it, then systemd is not installable. I followed you all the way to the last sentence, which I'm pretty certain is simply not correct. E.g., on my dest Debian 8 'Jessie' VM system (if I were to remove the current embargoing of system from /etc/apt/preferences), I could remove all packages that depend on libsystemd0, but then systemd would most certainly be nonetheless installable. Would it make any sense to have systemd with no application talking to it? Doesn't it imply it couldn't start any service. Therefore no DE, no ssh, no ntp, maybe even no login... Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Didier Kryn (k...@in2p3.fr): > Don't remember which package depends on some libkerberos5. > Assuming it's openssh or some component of pam. Package openssh-client. $ ldd $(which ssh) linux-gate.so.1 => (0xb76ec000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7672000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb751a000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7516000) libz.so.1 => /usr/lib/libz.so.1 (0xb7502000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74d3000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb738c000) /lib/ld-linux.so.2 (0xb76ed000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb72da000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb72b7000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb72b4000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ad000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb72a9000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb729) $ On a system that actually uses Kerberos, pam_krb5.so also gets involved, and I don't remember how that actually works. (I've done some Kerberos in setting up Hadoop on CentOS 6, but not much more than just getting it going.) > This raises a fundamental problem of distros. openssh and pam must be > able to make use of as many authentication protocols as possible to > cover the needs of all users. How can you reach this goal without > linking them to the corresponding libraries? It is indeed a thorny problem. One common answer is the Gentoo-style one where you employ USE flags or equivalent, and recompile & rebuild packages to trim build dependencies. It's certainly possible to carry out a similar action on a deb-packaged distro by locally rebuilding deb packages, tweaking the 'rules' file before compiling to reduce build dependencies. Or, as you say, there could be regular packages with several different flavours, some with more dependencies, some with fewer. > The case of libsystemd0 is different. In an OS proposing > systemd, it is normal to have libsystemd0, but not in a system which > excludes it completely. Here is the choice Devuan faces: if systemd > is installable, then many packages must depend on libsystemd, if no > package depends on it, then systemd is not installable. I followed you all the way to the last sentence, which I'm pretty certain is simply not correct. E.g., on my dest Debian 8 'Jessie' VM system (if I were to remove the current embargoing of system from /etc/apt/preferences), I could remove all packages that depend on libsystemd0, but then systemd would most certainly be nonetheless installable. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 24/07/2016 22:26, Rick Moen a écrit : Personally, I'm aiming to get the lib off my systems as somewhere in my long priority list -- but I don't see it as being substantially worse in the meantime than the Kerberos5 libraries also hauled in by overbroad package dependencies but likewise doing nothing at all. Don't remember which package depends on some libkerberos5. Assuming it's openssh or some component of pam. This raises a fundamental problem of distros. openssh and pam must be able to make use of as many authentication protocols as possible to cover the needs of all users. How can you reach this goal without linking them to the corresponding libraries? Maybe there's another method I don't know of? The alternative might be to have as many openssh or pam packages as there are combinations of the various available authentication systems, but it would lead to an enormous number of packages. The case of libsystemd0 is different. In an OS proposing systemd, it is normal to have libsystemd0, but not in a system which excludes it completely. Here is the choice Devuan faces: if systemd is installable, then many packages must depend on libsystemd, if no package depends on it, then systemd is not installable. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Rainer Weikusat (rweiku...@talktalk.net): > That's neither 'abstract' nor 'teleological' as you yourself nicely > demonstrated by immediately coming up with an equivalent but different > term after reinterpreting my statement in a way it clearly wasn't meant > to be understood by exploiting ambiguities inherent in natural language. Seems pretty darned teleological and abstract to me. More to the immediate point, the bigger problem is that it distracts from _process_: In my experience computing is fundamentally about process -- about what things _actually do_ -- and arguing over 'purposes' doesn't get the work done, and smells rather suspiciously of ideological advocacy. > The purpose of a door handle is to enable people to open doors. That's > technical and not 'teleological'. Sometimes, the 'purpose' of a door handle is to be something I hang my coat from. However, _clearly_ the purpose of eyeglasses is to support embezzling. ;-> (If you think the latter example is fanciful, consider prosecutors who decree that convicted computer criminals must be banned from using computers and the Internet because those are analogous to burglar tools -- in the jargon are 'instrumentalities of crime'. I have seen this happen in a number of cases, advised one such overzealous prosecutor, during a debate about public policy, that moral consistency would require him to _also_ ask the court to confiscate eyeglasses from convicted embezzlers. Both are items with a large variety of functions, not just as tools for committing crimes.) > > As has been abundantly documented, without systemd itself present, > > /lib/[$ARCH]/libsystemd.so.0 does basically nothing at all, as it cannot > > do anything. > > Likewise, the base purpose (or function) of a shared library is to > enable the runtime linker to resolve certain symbols so that a program > requiring them can be started. Fine, let's take that as assumed true. IMO, you are getting onto more solid ground, here, as you are speaking of what things _do_ rather than their 'purposes'. So, I appreciate that. > Take sd_notify as an example. That's > > , > | int sd_notify(int unset_environment, const char *state); > | > | sd_notify() may be called by a service to notify the service manager > | about state changes. > ` > https://www.freedesktop.org/software/systemd/man/sd_notify.html > > Calls to sd_notify are not useful to anyone except people using 'service > managers' implementing the complementary functionality, IOW, to anyone > not using systemd. libsystemd enables them to be inserted into > applications without openly compromising support for systems without > systemd as it provides the required symbols. So, without systemd, that call is vestigial, i.e., it _does nothing_. Which confirms what we believed that we knew before. > Regarding systemd as a documented API, libsystemd is nothing but an > alternate implementation of it and an alternate implementation created > and maintained by the exact same people. Your phrase 'an alternative implementation of it' appears murky to this easily confused system administrator. I'm not entirely clear on what the 'it' in this context is -- perhaps 'API'? If so, concepts like 'API' strike me as needlessly abstract and unclear in this context, thus risking a shortage of clarity -- doubtless me being annoyingly literal and overfond of the concrete and specific. To the best of my imperfect understanding, you have once again, as in many other semi-dissections of this library I vaguely recall from pro/anti-system disputations around 3-4 years ago, traced out glue code in libsystemd0 that without systemd does nothing at all. Which is the inevitable end-result of such discussion in my experience after one casts aside rhetorical maneouvering. Personally, I'm aiming to get the lib off my systems as somewhere in my long priority list -- but I don't see it as being substantially worse in the meantime than the Kerberos5 libraries also hauled in by overbroad package dependencies but likewise doing nothing at all. Frankly, I consider udev more significant by a country mile -- or, make that a country kilometre, since we're now living in the 21st Century. -- Cheers, Luftputebåten min er full av ål. Rick Moen r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Rick Moen writes: > Quoting Rainer Weikusat (rweiku...@talktalk.net): > >> The purpose of libsystemd0 is to enable packages whose code has been >> 'enhanced' with spurious systemd depedencies to work on systemd-less >> systems. That's absolutely not harmless. > > Your implied concept of 'purpose' is IMO a bit problematically abstract > and teleological for my taste. What I find more connected to the real > world, clearer in reference to my experience, is the concept of > _function_, i.e., what things do. That's neither 'abstract' nor 'teleological' as you yourself nicely demonstrated by immediately coming up with an equivalent but different term after reinterpreting my statement in a way it clearly wasn't meant to be understood by exploiting ambiguities inherent in natural language. The purpose of a door handle is to enable people to open doors. That's technical and not 'teleological'. > As has been abundantly documented, without systemd itself present, > /lib/[$ARCH]/libsystemd.so.0 does basically nothing at all, as it cannot > do anything. Likewise, the base purpose (or function) of a shared library is to enable the runtime linker to resolve certain symbols so that a program requiring them can be started. Take sd_notify as an example. That's , | int sd_notify(int unset_environment, const char *state); | | sd_notify() may be called by a service to notify the service manager | about state changes. ` https://www.freedesktop.org/software/systemd/man/sd_notify.html Calls to sd_notify are not useful to anyone except people using 'service managers' implementing the complementary functionality, IOW, to anyone not using systemd. libsystemd enables them to be inserted into applications without openly compromising support for systems without systemd as it provides the required symbols. Regarding systemd as a documented API, libsystemd is nothing but an alternate implementation of it and an alternate implementation created and maintained by the exact same people. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Le 18/07/2016 14:54, fsmithred a écrit : With a dummy equivs libsystemd0, I get a trash icon that works, but the removable drives don't show up on the desktop. When I remove the dummy package and install the real libsystemd0, removables show up and mount/eject work as expected. I would consider a good thing to not have the crapy trash bin, but I definitely like to see the removable media and to be able to mount/umount them on mouse-click. gvfs is yet another Gnome stuff Xfce4 depends on. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
On 07/16/2016 05:12 AM, Rick Moen wrote: > You probably wouldn't even like removing libsystemd0 entirely and > replacing it with an 'equivs' recipe, which could also be done if one > really, really, really were concerned. > > But, for those interested in that technique, see: 'How To Satisfy > Debian Dependencies Without Installing The Stupid Package' on > http://shallowsky.com/blog/linux/install/blocking-deb-dependencies.html Pretty cool trick. I tried it and got mixed results. I'm running without libsystemd0 here, so I can't have gvfs-daemons. That means there's no trash icon on the desktop and removable drives don't show up on the desktop when they're plugged it. With a dummy equivs libsystemd0, I get a trash icon that works, but the removable drives don't show up on the desktop. When I remove the dummy package and install the real libsystemd0, removables show up and mount/eject work as expected. I don't have time right now to complete the test, but I'd like to try Adam Borowski's repackaged gvfs. I'm guessing it will work. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why Debian 8 Pinning is (or isn't) pointless
Quoting Dragan FOSS (dragan.f...@gmx.com): > >The purpose of libsystemd0 is to enable packages whose code has been > >'enhanced' with spurious systemd depedencies to work on systemd-less > >systems. That's absolutely not harmless. > > So, why not remove it? ;> > TRIOS == excellence in simplicity :) Very nice! Thanks for offering that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng