Hi,
Justin B Rye wrote:
> Holger Wansing wrote:
> >> Comments below; meanwhile I should go and have a look at the full FAQ.
> >> Yes, its answers badly need revising; but in principle we ought to be
> >> doing something much more invasive, replacing Questions that are no
> >> longer Frequently Asked.
> >
> > Removing some of that questions would be good indeed.
>
> Or indeed adding new ones. Newcomers probably have questions these
> days about things the FAQ is too old to know anything about, like
> systemd, or wifi firmware, or multiarch, or even Ubuntu.
Yes, but a complete new creation of texts is ATM not the primary scope of
this review.
> >> I think /dev/dsp is a relic from the days before ALSA; these days it's
> >> /dev/snd/*, and the access rights are increasingly handled via ACLs
> >> managed by logind.
> >
> > Yes, /dev/dsp is not existing on my Jessie system.
> > So we could use "/dev/sda" instead, as owned by group "disk".
>
> Yes, that example still works, but it would be unusual to add a user
> to that group... is "cdrom" still useful, perhaps?
"/dev/sr0 belongs to cdrom group" is already included in that paragraph.
> > That should be rephrased then, to document the new behaviour.
> > Has someone with the relevant knowledge a small proposal for this?
> > (I'm lacking knowledge here, sorry.)
>
> The trouble is, systemd has essentially deprecated all the advice
> given in this section. Mind you, I don't really understand why the
> FAQ was explaining it, since it's in no way specific to Debian or even
> Linux.
So maybe completely drop that question...
> >>> -Where/how can I get the Debian installation
> >>> disks?
> >>> +Where/how can I get the Debian installation disks?
> >>
> >> The problem with "disks" is that we're now using it mostly as a
> >> coverterm for optical media (e.g. compact discs) and SSDs (e.g. USB
> >> thumbdrives), and neither of those are technically "disks"!
> >>
> >> We could say "installation media", but then there's a danger of
> >> singular agreement problems.
> >
> > Maybe use "installation images"?
>
> Well, it says you get the *disks* by downloading the appropriate
> *files*, so I was imagining that it was making a careful distinction
> beteween installation *media* and installation *software* (and that
> maybe later it would mention the possibility of getting disks some
> other way). But looking at it again I don't think so.
>
> Taking a step back, it no longer really makes any sense for this
> section to be separate from the one about installing Debian from
> CDs. And why point at "http://www.debian.org/mirror/list";?
>
> The questions seem to me to be, very roughly:
>
> Q) How do I install Debian?
> A) Easy: get an appropriate form of Debian-Installer image, put it on
> a CD or USB thumbdrive, and boot off that to start the install
> process.
>
> Q) What do you mean by "appropriate"?
> A) That's where it gets complicated. See https://get.debian.org!
This page starts with something like "information about installing
Debian can be found in the Debian installation guide".
So we could assume, that information available in the above guide
is not needed here. Or something like that.
Moreover, I fear that we have to refuse most of the old content in the
Debian FAQ, if we aim to set standards at a too high level ...
> >>> @@ -377,8 +376,7 @@
> >>>
> >>> How do I put a package on hold?
> >>>
> >>> -There are three ways of holding back packages, with dpkg, aptitude
> >>> -or with dselect.
> >>> +There are two ways of holding back packages, with dpkg or aptitude.
> >>>
> >>> With dpkg, you have to export the list of package selections, with:
> >>>dpkg --get-selections \* > selections.txt
> >>
> >> Oh, and you can now also use "apt-mark (un)hold"...
> >
> > Good point, added.
>
> I hope you remembered to reset it to "three ways".
Yes I did.
> >>> Index: uptodate.sgml
> >>> ===
> >>> --- uptodate.sgml (Revision 11091)
> >>> +++ uptodate.sgml (Arbeitskopie)
> >>> @@ -68,13 +68,13 @@
> >>> For details, see the manual page ,
> >>> and the file /usr/share/aptitude/README.
> >>>
> >>> -apt-get, dselect and apt-cdrom
> >>> +apt-get and apt-cdrom
> >>>
> >>> An alternative to >>> APT-based command-line tool (described previously in ).
> >>>
> >>> -Both >>> packages, and
> >>> - >>> packages.
> >>> + >>> +provides a simple, safe way to install and upgrade packages.
> >>
> >> This repeats "APT-based command-line tool". Ideally we'd rewrite it
> >> to talk about apt as the "primary" interface and things like apt-get
> >> and aptitude as alternatives to that.
> >
> > Starting with Stretch, apt-get and apt-cache calls are changed and
> > can also be called directly simply via apt:
>
> /usr/bin/apt is in Jessie (with all the options listed below), and I'm
> not aware of any changes to apt-get and apt-cache.
>
> > apt update
> > apt upgrade
> > apt full-
