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, <dng-request@???> wrote:
> Send Dng mailing list submissions to
> dng@???
>
> 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
> dng-request@???
>
> You can reach the person managing the list at
> dng-owner@???
>
> 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 <simonzwise@???>
> To: dng@???
> Subject: Re: [DNG] systemd is haunting me
> Message-ID: <56B0213B.2070107@???>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 02/02/16 00:13, Simon Hobson wrote:
> > Florian Zieboll<f.zieboll@???> 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 <simonzwise@???>
> To: dng@???
> Subject: Re: [DNG] systemd is haunting me
> Message-ID: <56B024FF.2080008@???>
> 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 <simonzwise@???>
> To: dng@???
> Subject: Re: [DNG] Sound [Was: systemd is haunting me]
> Message-ID: <56B0475D.1040600@???>
> 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 <f.zieboll@???>
> To: dng@???
> Subject: Re: [DNG] Semi OT: Mailman, Lurker and referencing messages
> Message-ID: <20160202104139.32da970d.f.zieboll@???>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 1 Feb 2016 13:55:20 +0000
> hellekin <hellekin@???> 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 <jaromil@???>
> To: dng@???
> 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 <hellekin@???> 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 <jaromil@???>
> To: dng@???
> 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
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
> ------------------------------
>
> End of Dng Digest, Vol 17, Issue 6
> **********************************
>
::
Re: [DNG] Dng Digest, Vol 17, Issue…
