Re: [OT, deeply] Guix
> So why not use it as an install tool? Then your entire configuration > is recorded in and driven by a pretty simple text file. That's all you > need, so we can pre-seed that config file for automatic installs. And > we can customise that SAME file for installs configured in real-time, > because salt has excellent templating capability in the config files. I'm not interested in *installing*: I'm interested in evolving an already installed system. AFAIU Puppet can do that, don't know about the other tools you mentioned. Stefan
Re: [OT, deeply] Guix
On Mon 08 Nov 2021 at 22:16:20 (-0500), Stefan Monnier wrote: > >> >> In contrast, with NixOS/Guix that list is available in a plain text > >> >> editable file. > > I'm not sure I'd call scheme a "plain text". > > Interesting. What I mean is a file that's intended to be manipulated by > a text editor rather than by some other program. It might *also* be > manipulated by other programs, but often it makes things more complicated. > > It usually means that its visual presentation is intended to be > human-readable (e.g. with indentation and comments to help understand > the structure and intention). > [ That's what makes it hard to manipulate with other programs, since > you need to preserve layout and comments whose meaning relates to > intentions (i.e. hard to formalize) and hence difficult to preserve > other than by another human. ] That's rather a stretch. If the text is /structured/, it's not Plain Text. Sure, it's a text file and not binary, but that's usual for Linux OSes. Here (Guix), it's actually source code written in guile, a scheme variant AIUI. (For Nix, it's some other language.) Earlier, > I would love to see Debian move towards a model like that of NixOS or > Guix. One of the main benefits I see of those systems is that it has > a declarative description of what the system should contain. I can't see the point. You can have the Guix package manager¹ now, as it allegedly installs on top of "foreign distros" (their term). It appears to me that you need well-resourced machines to benefit by its ability to have different versions of packages for the system, and yet more for individual users. I'm not typically in that position. And I don't see how you track security with all those versions around. I'll be sticking with APT for the time being. ¹ I think it's misguided to call the package manager and the OS? / Distribution? / whatever it is by the same name. Cheers, David.
Re: [OT, deeply] Guix
On Mon, Nov 8, 2021 at 9:22 PM Stefan Monnier wrote: > > language to do it. Here are some of those ways: > > Saltstack, Puppet, chef, ansible, AWS Cloudformation, XML > > I hear you, and you're probably right (save for XML: not sure what it > has to with the subject). > Simply that it could be accomplished with XML at base, with no other larger framework being used. If it looks like the right way to go. > This same thought crossed my mind while I was writing my > previous message. > All great minds think alike. I think some ancient Greek with a great mind said that :-) > Maybe what I want is simply for these to be better integrated > into Debian's package management, or just be more often used by "single > user admins" so there's lots of documentation and experience to help > get started. > That's pretty much what I thought. We don't need to remove the older mechanisms, we build on top of them. So no reason the old one can't be kept current. Example: Saltstack is really big in terms of lines-of-code. Could the right parts of it be shoe-horned into a running installer? Or it's libraries used so we can "script" even a local installation? It's possible to configure using saltstack itself on the server it runs on. Read that twice :-) So why not use it as an install tool? Then your entire configuration is recorded in and driven by a pretty simple text file. That's all you need, so we can pre-seed that config file for automatic installs. And we can customise that SAME file for installs configured in real-time, because salt has excellent templating capability in the config files. > Stefan > >
Re: [OT, deeply] Guix
On 2021-11-08, Nicholas Geovanis wrote: >> >> I thought plain text meant "a pure sequence of character codes" without >> any formatting information attached to it (e.g. HTML) or something. As >> > > Here's the thing. We already have many ways to install debian and any other Here's yet another thing: your delightfully confident diatribe has little or nothing to do with my post.
Re: [OT, deeply] Guix
On Mon, Nov 8, 2021 at 9:55 AM Curt wrote: > On 2021-11-08, David Wright wrote: > >> >> In contrast, with NixOS/Guix that list is available in a plain text > >> >> editable file. > > > > I'm not sure I'd call scheme a "plain text". Or do you mean something > > other than the file that commences with: > > > > (operating-system > > ;; ... > > > >> > in Debian there is /var/lib/apt/extended_states > >> > > I thought plain text meant "a pure sequence of character codes" without > any formatting information attached to it (e.g. HTML) or something. As > Here's the thing. We already have many ways to install debian and any other kind of linux-like OS in a completely declarative way. We don't need to learn a programming language to do it. Here are some of those ways: Saltstack, Puppet, chef, ansible, AWS Cloudformation, XML And we're at the point where the upfront learning of those tools pays-off later EVEN for single servers and desktops. Cause installation can be a pain sometimes, on slightly oddball platforms especially, your install tool config becomes a backup mechanism cause your desktop is too big to backup :-) etc. etc. Why not embrace the monster? Ship debian to be autoconfigged, not installed Just thinking out loud :-)
Re: [OT, deeply] Guix
On 2021-11-08, David Wright wrote: >> >> In contrast, with NixOS/Guix that list is available in a plain text >> >> editable file. > > I'm not sure I'd call scheme a "plain text". Or do you mean something > other than the file that commences with: > > (operating-system > ;; ... > >> > in Debian there is /var/lib/apt/extended_states >> I thought plain text meant "a pure sequence of character codes" without any formatting information attached to it (e.g. HTML) or something. As very much opposed to binary, of course. Then again, Wikipedia opines plain text is a "loose term." Anyhow, scheme is probably pretty plain for Stefan because I think he's a Lisp hacker in another life.
Re: [OT, deeply] Guix
On Sun 07 Nov 2021 at 08:58:23 (-0500), Stefan Monnier wrote:
> didier gaumet [2021-11-07 03:16:12] wrote:
> > Le mardi 26 octobre 2021 à 09:25 -0400, Stefan Monnier a écrit :
> > [...]
> >> Think of it this way: currently, you can more or less figure out
> >> which
> >> packages you decided to install on your machine by going through the
> >> list
> >> of installed packages and filtering out all those that are marked as
> >> "automatically" installed.
> >>
> >> But you can only manipulate this list indirectly, via `apt install`
> >> and
> >> `apt remove`.
> >
> > to have the list of all automatically installed packages:
> > # apt-mark showauto
> >
> > to have the list of all manually installed packages:
> > # apt-mark showmanual
> >
> > to verify if the package PACKAGE have been automatically installed
> > # apt-mark showauto $PACKAGE
> >
> > to verify if the package PACKAGE have been manually installed
> > # apt-mark showmanual $PACKAGE
>
> I'm not sure exactly what you mean to say with the above.
> Of course, we can extract some kind of description of the current state
> with APT commands, but it's quite different from having it inside a text
> file that you edit.
>
> The differences include:
>
> - The list is "in your face". When I look at `apt-mark showmanual`, for
> about half of the packages I vaguely remember explicitly installing
> them at some point but don't need them any more, others I'm pretty sure
> I never (consciously) installed manually.
I look at the list of packages I actually installed by using the
command (that I keep up my sleeve):
$ zgrep -i -h -e commandline $(reverse $(sort99 /var/log/apt/history*)) | \
grep -v -e 'upgrade$' -e 'autoremove$' | \
sed -e 's/Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o
APT::Keep-Fds::=6 -q -y --no-remove/[d-i]/;s/Commandline: apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6
-q/[d-i]/;s/Commandline: apt-get -y/[bas]/;s/Commandline: apt-get/[man]/;' | \
less
(Sorry about the long line.)
It does depend on having sufficient history:
$ grep -A1 log /etc/logrotate.d/apt
/var/log/apt/term.log {
rotate 60
--
/var/log/apt/history.log {
rotate 60
$
The reverse() and sort99() just deal with the sort-order of rotated
logs¹, grep removes uninteresting commands, and the sed filter tidies
the output by taking advantage of the stereotype commands used at
various stages: the installer, my personal list of "base" packages,
and later, casual installs.²
It's not the neatest output, but it would be simple to edit into
a file that could replicate a system, or act as the basis for
installing a new system from the next Debian revision. It certainly
saves having to remember to update my Christensen-style machine log
every time I install a package.
> - The list file naturally lends itself to extensions:
> - It could contain comments, so you could easily remove a package but
> keeping a note about it so it's easy to re-add.
> - It could contain conditional elements, so the same file could be
> used on different machines that need slightly different
> packages installed.
> - It could contain additional information per package, such as whether
> to install the recommended dependencies, some config information so you
> don't get queried during install, some file renamings, a list of
> "overrides" (to ignore a specific dependency and/or allow installing
> officially mutually-exclusive packages), ...
>
> It fundamentally changes the way you think about it, I think.
>
> >> In contrast, with NixOS/Guix that list is available in a plain text
> >> editable file.
I'm not sure I'd call scheme a "plain text". Or do you mean something
other than the file that commences with:
(operating-system
;; ...
> > in Debian there is /var/lib/apt/extended_states
>
> Not a fun read, tho. AFAICT it's just a verbose way to keep the set of
> not-manually-installed packages, so it includes all the info I want to
> be implicit ;-)
>
> Also, regarding "editable", I suspect that if you edit this file by hand
> and introduce an error in there you're probably not going to get much
> support ;-)
I would agree. I did post a script last year that attempted to
construct a list of top-level packages using dpkg-query. (It could be
improved, I'm sure, by someone who knows their way around apt and dpkg
introspection better than I do.) But it's obviously easier to
construct/maintain a list of packages intentionally installed
than to guess/"deduce" it from manipulation of the system's package
list and dependencies.
> > Perhaps (not sure) comparing on each machine the results of
> > # apt-cache unmet
> > could give you valuable info
>
> Thanks, I didn't know about this one.
I'd not met unmet either. I'm not sure whether it meets any
requirement for me. For example, it tells me:
Package parl-desktop-world version 1.9.18 has an unmet dep:
Depends: firefox-esr-l10n-as
Depends: firefox-esr-l10n
Re: [OT, deeply] Guix
Le mardi 26 octobre 2021 à 09:25 -0400, Stefan Monnier a écrit : [...] > Think of it this way: currently, you can more or less figure out > which > packages you decided to install on your machine by going through the > list > of installed packages and filtering out all those that are marked as > "automatically" installed. > > But you can only manipulate this list indirectly, via `apt install` > and > `apt remove`. to have the list of all automatically installed packages: # apt-mark showauto to have the list of all manually installed packages: # apt-mark showmanual to verify if the package PACKAGE have been automatically installed # apt-mark showauto $PACKAGE to verify if the package PACKAGE have been manually installed # apt-mark showmanual $PACKAGE > In contrast, with NixOS/Guix that list is available in a plain text > editable file. in Debian there is /var/lib/apt/extended_states > And in order to add a package or remove a package you > can edit that list and then say something akin to "make" which will > add/remove the needed packages to bring the system to the state > described in the file. > > Another, slightly more subtle, benefit is that you'll always get the > same system state from a given description. In contrast, with > Debian, > I have several Debian `testing` machines on which I have installed > and > removed over the years the same set of packages, but not exactly in > the > same order, and with a different interleaving of `apt upgrade`, and > the > result is that they don't all have exactly the same packages > installed, > and some suffer from problems that I don't see in the others. > Perhaps (not sure) comparing on each machine the results of # apt-cache unmet could give you valuable info > With the NixOS/Guix approach, it's much easier to make sure the > systems > are truly identical. > > It's not been enough to convince me to switch, but I do wish Debian > would try and take some of those ideas. I think part of it could be > done all within a new APT-like tool without any change to Debian > itself > (the part that decides which packages should be installed and removed > based on some text file describing the desired configuration of the > system). > > > Stefan "happy Debian user since 2003" > >
Re: [OT, deeply] Guix
> I stumble upon this article about (supposedly) Guix's > characteristics/advantages: [...] > , and was curious about the opinions of the educated Debian people on the > matter. I haven't read that article, but here's my opinion: I would love to see Debian move towards a model like that of NixOS or Guix. One of the main benefits I see of those systems is that it has a declarative description of what the system should contain. Think of it this way: currently, you can more or less figure out which packages you decided to install on your machine by going through the list of installed packages and filtering out all those that are marked as "automatically" installed. But you can only manipulate this list indirectly, via `apt install` and `apt remove`. In contrast, with NixOS/Guix that list is available in a plain text editable file. And in order to add a package or remove a package you can edit that list and then say something akin to "make" which will add/remove the needed packages to bring the system to the state described in the file. Another, slightly more subtle, benefit is that you'll always get the same system state from a given description. In contrast, with Debian, I have several Debian `testing` machines on which I have installed and removed over the years the same set of packages, but not exactly in the same order, and with a different interleaving of `apt upgrade`, and the result is that they don't all have exactly the same packages installed, and some suffer from problems that I don't see in the others. With the NixOS/Guix approach, it's much easier to make sure the systems are truly identical. It's not been enough to convince me to switch, but I do wish Debian would try and take some of those ideas. I think part of it could be done all within a new APT-like tool without any change to Debian itself (the part that decides which packages should be installed and removed based on some text file describing the desired configuration of the system). Stefan "happy Debian user since 2003"
Re: [OT, deeply] Guix
On Monday, 25 Oct 2021 at 20:43, riveravaldez wrote: > I stumble upon this article about (supposedly) Guix's > characteristics/advantages: The author loses me at the point where the article discusses programming languages and cites, amongst others, Octave and LaTeX as re-inventing the wheel and being /too-limiting/, implying that LISP is the only way to go (and I like LISP). -- Eric S Fraga via Emacs 28.0.60 & org 9.5 on Debian 11.1
