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
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
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] How can I help ?
Hi Karl, On 07/25/2016 09:16 AM, "dev1fanboy" wrote: There is none really so far, I did start some instructions a little while ago but there is a problem with the gitlab at the moment stopping the viewing of that page. https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/maintainer-walkthrough This is badly written and incomplete just now but keep an eye on it as I'm likely to improve it. Some knowledge of git is required to package for Devuan, but otherwise the packaging process is similar to debians. https://www.debian.org/doc/manuals/maint-guide/ An issue you may run into it is an "empty" SVN source repo on tracker.debian.org, but you're on your own for instructions on converting these at the moment. Cheers, chillfan On Thursday, July 14, 2016 5:06 PM, Karl Zomo wrote: >Hello, > >I'm tired of the packages that depend on systemd without really needing >it. > >I was trying to compile some packages without that dependency, with >little >success. > >Are there any written instructions how to do? > >It's worth doing it separately from what they are doing in the >distribution? I recommend you to begin packaging in the native source format, and using dpkg-buildpackage. As an exercise, you can download the sources of simple-netaid: https://git.devuan.org/edbarx/netman.git The source format is located in debian/source/format. Maybe i'll write a guide about how to package in devuan/debian in the future. In any case, it'll not be in the short term... But here we are to help you :) Good luck, Aitor. ___ 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] How can I help ?
Hi Karl, I am the person who wrote simple-netaid. If you want, I offer to help you. Edward -- 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] Wirth's law
Le 25/07/2016 01:29, Rainer Weikusat a écrit : Sleeping on a contended mutex is implemented in this way. But that's supposed to be an exceptional case. This is why, while advertizing itself as a cool "don't care" feature, a mutex is problematic: the programmer should make sure contention is exceptional and there is no risk of dead-lock. This leads, in my opinion, to a rather restrictive usage of mutexes. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] suspend / hibernate with KDE
On Mon, 25 Jul 2016 07:39:58 +0200, Klaus wrote in message <5fcaf78f-839d-05dc-04ab-750e0d35b...@arcor.de>: > Arnt Karlsen schrieb am 25.07.2016 um 00:18: > > ..I'm on ascii with daemon-version: 0.99.4, and it's been stuck > > there for a few months, do I need to downgrade or some such? > > Devuan 1.0 ships with upower 0.9.23. AFAIK newer daemon versions only > support systemd-based installations. ..thanks, that settles it. ;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
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
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
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] Wirth's law
Le 25/07/2016 00:55, Steve Litt a écrit : On Sun, 24 Jul 2016 23:30:47 +0200 Didier Kryn wrote: Le 24/07/2016 22:37, Jaromil a écrit : nowadays the closures paradigm (basically fifo pipes of pointers to stateless functions) is used much more than all that mutex and semaphore old stuff. i.e. golang adopted closures since the beginning with great success. ciao Don't know what a closure is, although I heard of it long ago on this list. According to Wikipedia, it is "a record containing a function and its environment". Hi Didier, I've never encountered closures as described by Jaromil, but they're a pretty handy thing easily done in many languages, with Lua leading the list. Here's something that might help explain a little bit: http://troubleshooters.com/codecorn/lua/luaclosures.htm Thanks, Steve. It confirms my further reading of Wikipedia's article. In languages like C, C++ or Ada, it is impossible to use a function to create a closure, because they store variables local to the subprogram (then creator function) in the stack. It is well known that Java allocates everything from the heap, making this easier. However there are tricks to do it in really many languages: https://rosettacode.org/wiki/Closures/Value_capture In Ada this resorts to instantiate a special type of object for every closure and then initialize it by a special kind of invocation. This special object, behind the scene, contains a mutex :-(, but this one could cause contention only when initializing the closure, which has no reason to happen. Nevertheless it looks contorted. 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 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
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 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
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] Wirth's law
On Mon, 25 Jul 2016, Didier Kryn wrote: > Le 25/07/2016 00:55, Steve Litt a écrit : > >On Sun, 24 Jul 2016 23:30:47 +0200 > >Didier Kryn wrote: > > > >>Le 24/07/2016 22:37, Jaromil a écrit : > >>>nowadays the closures paradigm (basically fifo pipes of pointers to > >>>stateless functions) is used much more than all that mutex and > >>>semaphore old stuff. i.e. golang adopted closures since the > >>>beginning with great success. > >>> > >>>ciao > >> Don't know what a closure is, although I heard of it long ago on > >>this list. According to Wikipedia, it is "a record containing a > >>function and its environment". > >Hi Didier, > > > >I've never encountered closures as described by Jaromil, but they're a > >pretty handy thing easily done in many languages, with Lua leading the > >list. Here's something that might help explain a little bit: > > > >http://troubleshooters.com/codecorn/lua/luaclosures.htm > > Thanks, Steve. It confirms my further reading of Wikipedia's article. > > In languages like C, C++ or Ada, it is impossible to use a function to > create a closure, because they store variables local to the subprogram (then > creator function) in the stack. In C++ is possible, made easier using the "Factory" approach we have this implemented in FreeJ https://github.com/dyne/FreeJ/blob/aa73398f752ced835d57e3012866512d55de252d/src/include/closure.h This can be done also in C, but I never need it there. The new C++11 standard makes it even easier with the introduction of lambda functions. I've been always very intrigued by concurrency stuff BTW. nowadays, I'm get all warm and cuddly whenever I get to spend time with Prismatic Plumbing https://github.com/plumatic/plumbing and Clojure in general has some really amazing things. I can well understand the passion for Ada here and think you may well like it. 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
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] How can I help ?
thanks for the tips Last week I made a deb network-manager without systemd and I have it running in xfce or kde. If interested, I can provide the diffs to devuan. I will try with simple-netaid, but this is different to rebuild an existing package. Regards 2016-07-25 6:42 GMT-03:00 Edward Bartolo : > Hi Karl, > > I am the person who wrote simple-netaid. If you want, I offer to help you. > > Edward > > -- > 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
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
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] Wirth's law
On Fri, 22 Jul 2016 12:21:00 -0400 Brian Nash wrote: > This describes a problem I used to have perfectly. > > For example, when I discovered multithreading, all my programs used it > in some way, even when it was unnecessary. > > This might be the root of all the problems we are facing with > computers today: If we see a cool new feature, we have to find some > way to use it. Brian's branch of this thread later went on to spawn discussions of mutexes, closures, and other stuff. But I'd like to bring it back to Brian's mention of multithreading. By agreeing with him... I've never written any multithreading code in my life. Some might attribute that to my not knowing how (and in fact I don't know how). But those of you who know me know I never let not knowing how stop me from getting the necessary things done. No, the real reason I don't write multithreading code is because it's complex. Everything involved must be thread safe. It must be written right. And it's quite a bit more complex than other forms of multitasking, such as those depending on separate processes. Complexity has costs that must be paid. Before including any complexity, I ask myself "can I pay the freight?" Can I afford the decreased repairability? Can I afford the decreased readability? Am I ready to document how it works, so a well meaning future maintenance programmer knows which variables are out of bounds for him to change? And if I *can* afford it, is that expense needed? Would things like forking be as expensive? On a web server handling thousands of connections, the answer is "probably." On my home workstation, the answer is "of course not." In a lot of cases, worrying about extra processes is a lot like worrying about your car's fuel economy and what will happen to it if you let your car's alternator charge your cell phone. In summary: Complexity has a cost. Be cost conscious. 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
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] Wirth's law
Le 25/07/2016 18:06, Steve Litt a écrit : Complexity has costs that must be paid. Before including any complexity, I ask myself "can I pay the freight?" Can I afford the decreased repairability? Can I afford the decreased readability? Am I ready to document how it works, so a well meaning future maintenance programmer knows which variables are out of bounds for him to change? And if I*can* afford it, is that expense needed? Would things like forking be as expensive? On a web server handling thousands of connections, the answer is "probably." On my home workstation, the answer is "of course not." I think I am doing the same carefull analysis as you before starting to write an application. Note that, for the case of a web server, different groups have made different choices. AFAIK Apache runs one thread per client while Nginx uses epoll() to serve multiple clients per thread. Nginx has the reputation to have a much smaller footprint and to be faster. 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 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
[DNG] Ugly, ugly news
Hi all, This is a screenshot of my buddy's kernel menuconfig: https://sanitarium.net/x.png 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
[DNG] I've seen this post and want to share...
http://entornosgnulinux.com/2016/07/25/como-instalar-bunsenlabs-hydrogen-en-devuan-gnulinux-1-0-jessie/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On Mon, Jul 25, 2016 at 02:07:07PM -0400, Steve Litt wrote: > This is a screenshot of my buddy's kernel menuconfig: > > https://sanitarium.net/x.png Whose kernel tree is this? Not in Linus', and googling that phrase shows nothing. -- An imaginary friend squared is a real enemy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On 25-07-16 20:07, Steve Litt wrote: Hi all, This is a screenshot of my buddy's kernel menuconfig: https://sanitarium.net/x.png 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 Luckily we have a BSD alternative if all linuxen fail. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On Mon, Jul 25, 2016 at 09:41:44PM +0200, Adam Borowski wrote: > On Mon, Jul 25, 2016 at 02:07:07PM -0400, Steve Litt wrote: > > This is a screenshot of my buddy's kernel menuconfig: > > > > https://sanitarium.net/x.png > > Whose kernel tree is this? > > Not in Linus', and googling that phrase shows nothing. Gentoo's patch, they probably don't have their unpacked sources anywhere on the web for googlebot to pick up. Actually, it's pretty nice. It's a metaselection that depends on config settings needed by particular programs. A copy of this patch for your reading attached. -- An imaginary friend squared is a real enemy. --- a/Kconfig 2016-07-01 19:22:17.117439707 -0400 +++ b/Kconfig 2016-07-01 19:21:54.371440596 -0400 @@ -8,4 +8,6 @@ config SRCARCH string option env="SRCARCH" +source "distro/Kconfig" + source "arch/$SRCARCH/Kconfig" --- /dev/null 2016-07-01 11:23:26.087932647 -0400 +++ b/distro/Kconfig 2016-07-01 19:32:35.581415519 -0400 @@ -0,0 +1,134 @@ +menu "Gentoo Linux" + +config GENTOO_LINUX + bool "Gentoo Linux support" + + default y + + help + In order to boot Gentoo Linux a minimal set of config settings needs to + be enabled in the kernel; to avoid the users from having to enable them + manually as part of a Gentoo Linux installation or a new clean config, + we enable these config settings by default for convenience. + + See the settings that become available for more details and fine-tuning. + +config GENTOO_LINUX_UDEV + bool "Linux dynamic and persistent device naming (userspace devfs) support" + + depends on GENTOO_LINUX + default y if GENTOO_LINUX + + select DEVTMPFS + select TMPFS + + select MMU + select SHMEM + + help + In order to boot Gentoo Linux a minimal set of config settings needs to + be enabled in the kernel; to avoid the users from having to enable them + manually as part of a Gentoo Linux installation or a new clean config, + we enable these config settings by default for convenience. + + Currently this only selects TMPFS, DEVTMPFS and their dependencies. + TMPFS is enabled to maintain a tmpfs file system at /dev/shm, /run and + /sys/fs/cgroup; DEVTMPFS to maintain a devtmpfs file system at /dev. + + Some of these are critical files that need to be available early in the + boot process; if not available, it causes sysfs and udev to malfunction. + + To ensure Gentoo Linux boots, it is best to leave this setting enabled; + if you run a custom setup, you could consider whether to disable this. + +config GENTOO_LINUX_PORTAGE + bool "Select options required by Portage features" + + depends on GENTOO_LINUX + default y if GENTOO_LINUX + + select CGROUPS + select NAMESPACES + select IPC_NS + select NET_NS + select SYSVIPC + + help + This enables options required by various Portage FEATURES. + Currently this selects: + + CGROUPS (required for FEATURES=cgroup) + IPC_NS (required for FEATURES=ipc-sandbox) + NET_NS (required for FEATURES=network-sandbox) + SYSVIPC (required by IPC_NS) + + + It is highly recommended that you leave this enabled as these FEATURES + are, or will soon be, enabled by default. + +menu "Support for init systems, system and service managers" + visible if GENTOO_LINUX + +config GENTOO_LINUX_INIT_SCRIPT + bool "OpenRC, runit and other script based systems and managers" + + default y if GENTOO_LINUX + + depends on GENTOO_LINUX + + select BINFMT_SCRIPT + + help + The init system is the first thing that loads after the kernel booted. + + These config settings allow you to select which init systems to support; + instead of having to select all the individual settings all over the + place, these settings allows you to select all the settings at once. + + This particular setting enables all the known requirements for OpenRC, + runit and similar script based systems and managers. + + If you are unsure about this, it is best to leave this setting enabled. + +config GENTOO_LINUX_INIT_SYSTEMD + bool "systemd" + + default n + + depends on GENTOO_LINUX && GENTOO_LINUX_UDEV + + select AUTOFS4_FS + select BLK_DEV_BSG + select CGROUPS + select DEVPTS_MULTIPLE_INSTANCES + select EPOLL + select FANOTIFY + select FHANDLE + select INOTIFY_USER + select NET + select NET_NS + select PROC_FS + select SIGNALFD + select SYSFS + select TIMERFD + + select ANON_INODES + select BLOCK + select EVENTFD + select FSNOTIFY + select INET + select NLATTR + + help + The init system is the first thing that loads after the kernel booted. + + These config settings allow you to select which init systems to support; + instead of having to select all the individual settings all over the + place, these settings allows you to select all the settings at once. + + This particular setting enables all the known requirements for systemd; + it also enables suggested optional settings, as the package suggests to. + +endmenu + +endmenu ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.or
Re: [DNG] suspend / hibernate with KDE
On Mon, Jul 25, 2016 at 07:39:58AM +0200, Klaus Fuerstberger wrote: > Arnt Karlsen schrieb am 25.07.2016 um 00:18: > > ..I'm on ascii with daemon-version: 0.99.4, and it's been stuck > > there for a few months, do I need to downgrade or some such? > > Devuan 1.0 ships with upower 0.9.23. AFAIK newer daemon versions only > support systemd-based installations. I believe checking power levels does still work in 0.99, although I can't check right now (my only laptop is a flaky piece of arm with quirky vendor kernels that has power management working only on Android). What they did drop was suspend and hibernate, moving them to systemd. An alternative is to patch things relying on dropped parts of upower to use pm-utils instead. -- An imaginary friend squared is a real enemy. ___ 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 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
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] Ugly, ugly news
On 07/25/2016 06:07 PM, Steve Litt wrote: > Hi all, > > This is a screenshot of my buddy's kernel menuconfig: > > https://sanitarium.net/x.png > Support for init systems, system and service managers: [*] OpenRC, runit and other script based systems and managers [ ] systemd This looks like a huge troll against systemd. Steve, do you know the author? Can we reuse it? Definitely can illustrate the Init Freedom page :) https://devuan.org/os/init-freedom Cheers, == hk -- _ _ We are free to share code and we code to share freedom (_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On Mon, Jul 25, 2016 at 10:06:09PM +, hellekin wrote: > On 07/25/2016 06:07 PM, Steve Litt wrote: > > This is a screenshot of my buddy's kernel menuconfig: > > > > https://sanitarium.net/x.png > > Support for init systems, system and service managers: > > [*] OpenRC, runit and other script based systems and managers > [ ] systemd > > This looks like a huge troll against systemd. That setting being deselected means exactly nothing. It's the same state as on Debian, Devuan or even systemd-only Red Hat. All that Gentoo did was adding a convenience switch that, when triggered, turns on everything needed to use systemd. These settings happen to be on on any general-purpose distribution as, tight embedded excepted, you want stuff like fanotify or being able to run containers. -- An imaginary friend squared is a real enemy. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] suspend / hibernate with KDE
On Mon, 25 Jul 2016 23:05:35 +0200, Adam wrote in message <20160725210535.gc15...@angband.pl>: > On Mon, Jul 25, 2016 at 07:39:58AM +0200, Klaus Fuerstberger wrote: > > Arnt Karlsen schrieb am 25.07.2016 um 00:18: > > > ..I'm on ascii with daemon-version: 0.99.4, and it's been stuck > > > there for a few months, do I need to downgrade or some such? > > > > Devuan 1.0 ships with upower 0.9.23. AFAIK newer daemon versions > > only support systemd-based installations. > > I believe checking power levels does still work in 0.99, although I > can't check right now (my only laptop is a flaky piece of arm with > quirky vendor kernels that has power management working only on > Android). > > What they did drop was suspend and hibernate, moving them to > systemd. An alternative is to patch things relying on dropped parts > of upower to use pm-utils instead. ..thanks, a quick demo dump: root@celsius:/var/cache/apt/archives# upower -d Device: /org/freedesktop/UPower/devices/line_power_AC native-path: AC power supply: yes updated: Mon 25 Jul 2016 11:23:55 PM CEST (12578 seconds ago) has history: no has statistics: no line-power warning-level: none online: yes icon-name: 'ac-adapter-symbolic' Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: SMP model:DELL MP4928C serial: 201 power supply: yes updated: Tue 26 Jul 2016 02:51:55 AM CEST (98 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: fully-charged warning-level: none energy: 86.58 Wh energy-empty:0 Wh energy-full: 86.58 Wh energy-full-design: 86.58 Wh energy-rate: 0.0111 W voltage: 12.623 V percentage: 100% capacity:24.0513% technology: lithium-ion icon-name: 'battery-full-charged-symbolic' Device: /org/freedesktop/UPower/devices/DisplayDevice power supply: yes updated: Mon 25 Jul 2016 11:25:55 PM CEST (12458 seconds ago) has history: no has statistics: no battery present: yes state: fully-charged warning-level: none energy: 86.58 Wh energy-full: 86.58 Wh energy-rate: 0.0111 W percentage: 100% icon-name: 'battery-full-charged-symbolic' Daemon: daemon-version: 0.99.4 on-battery: no lid-is-closed: no lid-is-present: yes critical-action: [Invalid UTF-8] No protocol specified xprop: unable to open display ':0' root@celsius:/var/cache/apt/archives# root@celsius:/var/cache/apt/archives# upower -h Usage: upower [OPTION...] UPower tool Help Options: -h, --help Show help options Application Options: -e, --enumerate Enumerate objects paths for devices -d, --dump Dump all parameters for all objects -w, --wakeupsGet the wakeup data -m, --monitorMonitor activity from the power daemon --monitor-detail Monitor with detail -i, --show-info Show information about object path -v, --versionPrint version of client and daemon root@celsius:/var/cache/apt/archives# -- ..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] Ugly, ugly news
On 07/26/2016 08:03 AM, Adam Borowski wrote: On Mon, Jul 25, 2016 at 10:06:09PM +, hellekin wrote: On 07/25/2016 06:07 PM, Steve Litt wrote: This is a screenshot of my buddy's kernel menuconfig: https://sanitarium.net/x.png Support for init systems, system and service managers: [*] OpenRC, runit and other script based systems and managers [ ] systemd This looks like a huge troll against systemd. That setting being deselected means exactly nothing. It's the same state as on Debian, Devuan or even systemd-only Red Hat. All that Gentoo did was adding a convenience switch that, when triggered, turns on everything needed to use systemd. These settings happen to be on on any general-purpose distribution as, tight embedded excepted, you want stuff like fanotify or being able to run containers. I was thinking... We have sites like: http://without-systemd.org It would be nice to have a list of software that is dedicated to using systemd and software that has optional integration. Along with that software. We also need to have a list of news with the findings that we keep bringing up on this list to track systemd creep. We need to drive a wedge into the FOSS community and separate the desktop users from the professionals. I am sorry to be divisive, but the water is under the bridge and the damage has already been done. We need to know who shit in the sandbox so professionals can avoid the turds. It's been going like this ever since you have these evangelicals and journalists screaming for "the year of the linux desktop". I have a question about what Simon Richter said on his blog(http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html): "Here's the thing: most users will be entirely happy with fully uncustomized systemd. It will suspend your laptop if you close the lid, and even give your download manager veto power. I fully support Debian's decision to use systemd as the default init for new installs, because it makes sense to use the default that is good for the vast majority of users." Is that really the case? Did the Debian leadership do a poll to find out what their users wanted and who were their typical users? Desktop/personal vs. server/professional? Did they consult their package survey stats? I wasn't participating in those discussions. Maybe I should have. For that, my friends, I am sorry. I am sorry to open a can of worms of perhaps what is a sensitive issue with those of you who were involved in the discussion and the exodus. The reason I want to know about that is because if most Debian users are desktop users, perhaps it's for the better that they went with systemd as the default. It gives more credence to Devuan as the professional choice. Kind regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On 26/07/16 10:27, Simon Walter wrote: Is that really the case? Did the Debian leadership do a poll to find out what their users wanted and who were their typical users? Desktop/personal vs. server/professional? Did they consult their package survey stats? I wasn't participating in those discussions. Maybe I should have. For that, my friends, I am sorry. I am sorry to open a can of worms of perhaps what is a sensitive issue with those of you who were involved in the discussion and the exodus. My gut feeling is that discussion is a waste of time. You won't influence the politics, you won't actually learn anything from the discussion and you'll divert time and energy away from moving in the forward direction. The reason I want to know about that is because if most Debian users are desktop users, perhaps it's for the better that they went with systemd as the default. It gives more credence to Devuan as the professional choice. I'd rather just keep doing what we're doing and working on a credible alternative. The results will speak for themselves rather than more rattling of empty tins. Let's keep our eyes on the ball. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
On 07/26/2016 12:28 PM, Brad Campbell wrote: On 26/07/16 10:27, Simon Walter wrote: Is that really the case? Did the Debian leadership do a poll to find out what their users wanted and who were their typical users? Desktop/personal vs. server/professional? yes/no? Did they consult their package survey stats? yes/no? I wasn't participating in those discussions. Maybe I should have. For that, my friends, I am sorry. I am sorry to open a can of worms of perhaps what is a sensitive issue with those of you who were involved in the discussion and the exodus. My gut feeling is that discussion is a waste of time. I think you misunderstand. I want a yes or no answer. There is nothing to discuss. ... The reason I want to know about that is because if most Debian users are desktop users, perhaps it's for the better that they went with systemd as the default. It gives more credence to Devuan as the professional choice. I'd rather just keep doing what we're doing and working on a credible alternative. The results will speak for themselves rather than more rattling of empty tins. I don't want rattling. Rattling is annoying anywhere including on my car. Does anyone know? Let's keep our eyes on the ball. Of course. But I still want to know who to avoid and who can be trusted. I am running their code on my systems and I don't have time to review it all. Are you saying that I should go scour mail archives? I just want to know if it really was the case that Debian leadership used statistics to decide on a systemd default - or not. If someone knows, please answer me off list and perhaps be so kind as to provide a reference. No discussion intended. Thank you, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] suspend / hibernate with KDE
Adam Borowski schrieb am 25.07.2016 um 23:05: >> Devuan 1.0 ships with upower 0.9.23. AFAIK newer daemon versions only >> support systemd-based installations. > > I believe checking power levels does still work in 0.99, although I can't > check right now (my only laptop is a flaky piece of arm with quirky vendor > kernels that has power management working only on Android). > > What they did drop was suspend and hibernate, moving them to systemd. An > alternative is to patch things relying on dropped parts of upower to use > pm-utils instead. I was speaking about 0.9.23 where powermanagement should be working without systemd/libsystemd0. But it does not suspend in devuan and KDE. Anyone knows why? Klaus ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ugly, ugly news
Friends, This is the most determining battle. If Devuan wins, nothing will defeat us. Edward -- 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] Ugly, ugly news
On Tue, 26 Jul 2016 11:27:20 +0900 Simon Walter wrote: > We need to drive a wedge into the FOSS community and separate the > desktop users from the professionals. I am sorry to be divisive, but > the water is under the bridge and the damage has already been done. You might find it interesting that I'm a desktop user, or perhaps a workstation user. And I've known plenty of professional admins who not only liked systemd, but swore up and down they were the recipients of all systemd's good things, and wondered why desktop people cared one way or the other. If I were you, I'd take help wherever you find it. Your proposed wedge would split Devuan as much as anything else. [snip] > Is that really the case? Did the Debian leadership do a poll to find > out what their users wanted and who were their typical users? Hell no! As a matter of fact, they made it a point not to listen to their users. > Desktop/personal vs. server/professional? It didn't break down that way. > Did they consult their > package survey stats? Doubtful. It was an agenda driven kangaroo court. > > I wasn't participating in those discussions. Maybe I should have. For > that, my friends, I am sorry. I am sorry to open a can of worms of > perhaps what is a sensitive issue with those of you who were involved > in the discussion and the exodus. We're not the ones to tell you. Sign up for Debian-User mailing list, https://lists.debian.org/debian-user/, and ask those questions. Be prepared for people with 1/10 your IQ to tell you the hundred different reasons you're wrong just to ask the question. Say hi to Don Armstrong for me, and tell him how much I miss him. > The reason I want to know about that is because if most Debian users > are desktop users, perhaps it's for the better that they went with > systemd as the default. It gives more credence to Devuan as the > professional choice. I wouldn't split it desktop/server or desktop/professional. It didn't split that way. Very truthfully, it split smart guys vs dumb guys, with the dumb ones remaining in Debian. 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] Ugly, ugly news
Le 26/07/2016 04:27, Simon Walter a écrit : "Here's the thing: most users will be entirely happy with fully uncustomized systemd. It will suspend your laptop if you close the lid, and even give your download manager veto power. I fully support Debian's decision to use systemd as the default init for new installs, because it makes sense to use the default that is good for the vast majority of users." I would rather say (eg) "most of Ubuntu users...", not Debian users. Because Debian has always been a distro for geeks. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
