Subject: Re: [DNG] Systemd at work: rm -rf EFI - made The Register http://www.theregister.co.uk/2016/02/02/delete_efivars_linux/
On Tue, Feb 2, 2016 at 5:48 AM, <[email protected]> wrote: > Send Dng mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dng digest..." > > > Today's Topics: > > 1. Re: systemd is haunting me (Simon Wise) > 2. Re: systemd is haunting me (Simon Wise) > 3. Re: Sound [Was: systemd is haunting me] (Simon Wise) > 4. Re: Semi OT: Mailman, Lurker and referencing messages > (Florian Zieboll) > 5. Re: Semi OT: Mailman, Lurker and referencing messages (Jaromil) > 6. Re: Systemd at work: rm -rf EFI (Jaromil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 02 Feb 2016 14:23:39 +1100 > From: Simon Wise <[email protected]> > To: [email protected] > Subject: Re: [DNG] systemd is haunting me > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/02/16 00:13, Simon Hobson wrote: > > Florian Zieboll<[email protected]> wrote: > > > >> For the fun of it, I just ran an "apt-get install --install-recommends > >> --no-install-recommends" and it chose to not install the recommends. > >> The same with contradicting lines in apt.conf(.d/*): > >> > >> APT::Install-Recommends "0"; > >> APT::Install-Recommends "1"; > >> > >> This will install the recommends, the other way around it won't. > >> Apparently there's still some behavior left in modern Linux that is > >> coherent with an autistic mindset, hahaha. > > > > Makes sense to me too - first entry sets/resets option, next entry > resets/sets the same option - the last one taking effect. > > that is simply the apt.conf syntax ... like many, but not all, such files > the > last setting you give overrides all previous, and the file is read top to > bottom, in a well-defined position wrt other config locations. > > Any config system needs some rule on this, reading man pages should tell > the > specific details for a program ... and if (as is typical) there is more > than one > place to add configurations then the order they are read is also carefully > defined for each. > > For example many tools read the ENV, accept options as args, have a per > user > config and a system wide default. This is complicated, but I would not > want to > lose any of them. So it is very likely that some of these will contradict > the > others. So a definition that "the last value read overrides all previous" > makes > sense. Then it may be necessary to add some special options to be able to > prevent reading some local options. > > Debian adds to this with a .d/ directory of file snippets that read and > included > in the standard .conf file, in lexical order, at the same time as a single > .conf > in that location would be. Hence those numbers at the start of those files > to > determine order transparently and consistently ... there are debian tools > provided to read this directory so that this behaviour is predictable, it > is > also consistent in many many debian packages. Packages sometimes use a > master > .conf file with an 'include' copying all the little files, or sometimes do > this > reading the snippets directly simply increasing the number of available > files to > configure so that individual packages have one each. > > Simon > > > ------------------------------ > > Message: 2 > Date: Tue, 02 Feb 2016 14:39:43 +1100 > From: Simon Wise <[email protected]> > To: [email protected] > Subject: Re: [DNG] systemd is haunting me > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 01/02/16 22:47, Didier Kryn wrote: > > Le 01/02/2016 12:09, Florian Zieboll a écrit : > >> florian@nulldevice:~$ cat /etc/apt/apt.conf.d/01norecommend > >> APT::Install-Recommends "0"; > >> APT::Install-Suggests "0"; > >> #APT::AutoRemove::RecommendsImportant "0"; > >> > >> Synaptic will override this setting, if the relevant option is checked. > > > > Apparently synaptic keeps its config in its own config file > > /etc/apt/apt.conf.d/99synaptic. Do you mean synaptic reads all config > files in > > order, and since 99synaptic is the last, it can override all previous > settings? > > I must confess I don't understand how this set of config files is > processed; > > there are quite a lot of files in etc/apt/apt.conf.d/. There's a man for > > apt.conf, which doesn't exist and no man for apt.conf.d, which exists! > > > the command tool for finding relevant man pages on your system is apropos > ... > > $ apropos apt > > <snip> > > apt (1) - annotation processing tool > apt (8) - Advanced Package Tool > apt-cache (8) - query the APT cache > apt-cdrom (8) - APT CD-ROM management utility > apt-config (8) - APT Configuration Query program > apt-extracttemplates (1) - Utility to extract debconf config and tem... > apt-file (1) - APT package searching utility - command-line ... > apt-forktracer (8) - a utility for managing package versions > apt-ftparchive (1) - Utility to generate index files > apt-get (8) - APT package handling utility - - command-line... > apt-key (8) - APT key management utility > apt-listbugs (1) - Lists critical bugs before each apt upgrade/i... > apt-mark (8) - mark/unmark a package as being automatically-... > apt-move (8) - move cache of Debian packages into a mirror h... > apt-offline (8) - Offline APT Package manager > apt-secure (8) - Archive authentication support for APT > apt-show-versions (1p) - Lists available package versions with distr... > apt-sortpkgs (1) - Utility to sort package index files > apt-zip (8) - Use apt with removable media > apt-zip-inst (8) - Use apt with removable media > apt-zip-list (8) - Use apt with removable media > apt.conf (5) - Configuration file for APT > apt_preferences (5) - Preference control file for APT > > <snip> > > so looking at apt.conf I see as the very first text 'DESCRIPTION' > > /etc/apt/apt.conf is the main configuration file shared by all > the tools in the APT suite of tools, though it is by no means > the only place options can be set. The suite also shares a > common command line parser to provide a uniform environment. > > When an APT tool starts up it will read the configuration > files in the following order: > > 1. the file specified by the APT_CONFIG environment variable > (if any) > > 2. all files in Dir::Etc::Parts in alphanumeric ascending > order which have either no or "conf" as filename extension > and which only contain alphanumeric, hyphen (-), > underscore (_) and period (.) characters. Otherwise APT > will print a notice that it has ignored a file, unless > that file matches a pattern in the > Dir::Ignore-Files-Silently configuration list - in which > case it will be silently ignored. > > 3. the main configuration file specified by Dir::Etc::main > > 4. the command line options are applied to override the > configuration directives or to load even more > configuration files. > > > Dir::Etc::Parts is in fact apt.conf.d/ > > as seen by going to the FILES section at the end of the manpage, either > with a > search for Dir::Etc::Parts or because you know a FILES section usually > exists: > > FILES > /etc/apt/apt.conf > APT configuration file. Configuration Item: > Dir::Etc::Main. > > /etc/apt/apt.conf.d/ > APT configuration file fragments. Configuration Item: > Dir::Etc::Parts. > > > > so certainly finding this out does require a little familiarity with the > linux > documentation system, but it is all there and in exactly the discoverable > places. There is a lot of information available, tool tips or a few help > paragraphs could not come close to providing it. That is why very > simplified GUI > configurations eliminating all the uncommon settings are so popular. > > Simon > > > > ------------------------------ > > Message: 3 > Date: Tue, 02 Feb 2016 17:06:21 +1100 > From: Simon Wise <[email protected]> > To: [email protected] > Subject: Re: [DNG] Sound [Was: systemd is haunting me] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/02/16 08:49, Ian Zimmerman wrote: > > On 2016-02-01 22:02 +0100, Didier Kryn wrote: > > > >> If you do a lot of sound manipulation, this is an area in which I > can't help. > >> Linux sound is a nightmare to me and I never found a sensible > description of it all, > >> so using pulseaudio by default because it mostly works out of the box. > But there was > >> a thread about it one or two weeks ago... > > > > I use straight ALSA and it's quite usable to me, if somewhat > > intimidating on first approach. What are the nightmarish aspects, maybe > > I can help? > > > > Serious linux audio is very configurable, sophisticated and flexible, this > makes > it complex. > > Some hardware manufacturers don't care to support a smallish market, > leaving the > end user to deal with integration into the system. > > A lot of serious linux audio setups are within the context of a large > installation with serious in-house expertise and quite specific needs .. > so DIY > as they wish, and deal with the complexity as the price of configurability. > > Some very serious linux audio is sold as part of top-end integrated > hardware and > carefully set up by those vendors, again they favour configurability over > ease > of setup. > > The software based smaller digital audio workstation end attracts many > people > interested in the underlying algorithms, often programmers as well as > musicians. > They are seeking the flexibility to at least script if not actually program > certain parts of their setup. They are often interested in a system putting > together a lot of small, specific tools of their choice which follow the > unix > philosophy of do one thing and do it well as opposed to wishing for a > ready to > play fully integrated audio application. Because of this they are prepared > to > deal with complexity for the same reasons as the previous two types of > serious > audio user. > > Thus serious linux is a very attractive tool for a few, and best avoided > for > many. If you know the stakes ... it is not a nightmare, it is a tremendous > opportunity. > > The Linux Audio Users email list is a great resource if you want to take > it up. > > So are the lists of most of the tools you want to use. > > Other musicians are often much more interested in choosing one big > application > that caters for most of their needs (then all of them, once they prune > ambitions > to match the workflow they learn). This is quite understandable and they > are > very well catered for by commercial offerings, usually in commercial > operating > systems, so they don't generally bother with linux. They find the cash > required > if they can. There are options in linux but this does require actively > seeking > them out, and the serious ones can be quite expensive if they are > commercial > tools. The big businesses in this field depend heavily on actively chasing > the > musicians ... to sell them stuff ... and focus on platforms that are also > big > business, and familiar to the biggest number of potential buyers. > > So serious linux audio ends up not at all suitable for plug and play > desktop use. > > Pulseaudio goes a long way to solving this, autoconfiguring everything to > suit > the expected desktop usage patterns without asking any questions. It is > much > more acceptable now that it will allow jack as a backend between it and > alsa, > rather than insisting it controls alsa itself, since now the usual desktop > audio > stuff can be fed into the serious audio chain, or just to the speakers > when you > want to use skype or something, and does not need to be disabled. > > Pulseaudio is sensible choice if you are after simple audio on the > desktop, it > isn't a nightmare unless you try to do more than the standard stuff. It > will of > course drag in all the autoconfigure black-box stuff that devuan tries to > avoid > ... it must, to integrate with that whole black box ... that is why it > exists. > DIY is always a bit more work. You will need to learn about audio as well > as > linux to get anywhere. > > > Simon > > > ------------------------------ > > Message: 4 > Date: Tue, 2 Feb 2016 10:41:39 +0100 > From: Florian Zieboll <[email protected]> > To: [email protected] > Subject: Re: [DNG] Semi OT: Mailman, Lurker and referencing messages > Message-ID: <[email protected]> > Content-Type: text/plain; charset=US-ASCII > > On Mon, 1 Feb 2016 13:55:20 +0000 > hellekin <[email protected]> wrote: > > > I guess we can investigate and find out how to generate these from > > mailman, and then have a nice URL like: > > https://lurker.devuan.org/<some-hash> to redirect to the relevant > > lurker message. This would also make Devuan Editors' lives easier > > when working on the newsletter. > > Another loose thought on this: To spare the mailing list machine(s) the > additional burden of hashing, wouldn't it be sufficient to add a simple > counter to mailman and make it inject the count (plus perhaps some list > and/or machine ID) as a new header to the mail before passing it to the > archiver? > > Florian > > > > ------------------------------ > > Message: 5 > Date: Tue, 2 Feb 2016 10:45:22 +0100 > From: Jaromil <[email protected]> > To: [email protected] > Subject: Re: [DNG] Semi OT: Mailman, Lurker and referencing messages > Message-ID: <20160202094522.GA2461@reflex> > Content-Type: text/plain; charset=utf-8 > > On Tue, 02 Feb 2016, Florian Zieboll wrote: > > > On Mon, 1 Feb 2016 13:55:20 +0000 > > hellekin <[email protected]> wrote: > > > > > I guess we can investigate and find out how to generate these from > > > mailman, and then have a nice URL like: > > > https://lurker.devuan.org/<some-hash> to redirect to the relevant > > > lurker message. This would also make Devuan Editors' lives easier > > > when working on the newsletter. > > > > Another loose thought on this: To spare the mailing list machine(s) the > > additional burden of hashing, wouldn't it be sufficient to add a simple > > counter to mailman and make it inject the count (plus perhaps some list > > and/or machine ID) as a new header to the mail before passing it to the > > archiver? > > I haven't look at any existing solution, but I believe that a good > approach would be to use the actual message-id: in the headers, which is > also an identifier to retrieve email from lurker. But I have no idea if > that header is exported as a variable for mailman's templates. > > ciao > > > > ------------------------------ > > Message: 6 > Date: Tue, 2 Feb 2016 10:49:10 +0100 > From: Jaromil <[email protected]> > To: [email protected] > Subject: Re: [DNG] Systemd at work: rm -rf EFI > Message-ID: <20160202094910.GB2461@reflex> > Content-Type: text/plain; charset=utf-8 > > On Tue, 02 Feb 2016, Wim wrote: > > > [2]https://github.com/systemd/systemd/issues/2402 > > Well, you've probably guessed the answer - Won't fix. > > meanwhile, on the background, the usual bullying goes on among the > systemd hooligans, sarcastically liquidating the concern with some > cynical remarks, as if it would be a deserved punition for users > caught into a bricked laptop rather than an erased filesystem: > > http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory > > this gives a pretty good picture on how most similar concerns have been > dismissed in the years of the systemd avalanche. > > ciao > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > ------------------------------ > > End of Dng Digest, Vol 17, Issue 6 > ********************************** >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
