Re: [DNG] gvfs depends on libsystemd0

[Stephanie Daugherty]

On Mon, Apr 10, 2017 at 11:28 PM, marc  wrote:

> >   You still should use sudo, with a password - the user's own password.
> > Using root password many times, every day, is bad for security (the more
> > times you type it the higher the chances are it will be captured) and it
> > instills the desire of an easy to remember and fast to type password.
>
>

As an aside here, avoid using sudo to allow untrusted or minimally trusted
users to mount filesystems.  There is a "user" option as well as an "owner"
option in /etc/fstab, and default installations of /bin/mount are setuid
root, allowing them to mount filesystems configured to be user-accessible
according to administrator-determined settings without su or sudo.

While this probably isn't completely secure, the attack surface is much
smaller and it's much more secure than most mere mortals will be able to
achieve with sudo, as correctly configuring sudo to limit the range of
possible inputs is difficult to understand and prone to human error, where
mount is instead rigidly limited to the approved mountpoints, devices,
filesystem types, and options by design. Making a filesystem user mountable
via fstab even implies noexec, nosuid, and nodev!

There are still the potential security issues of a buggy /bin/mount
executable and a buggy filesystem, but this approach at least eliminates a
wide range of creative ways through which /bin/mount or the shell could be
tricked into running a second executable with root permissions via sudo.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vim8

[Stephanie Daugherty]

If at all possible, get it from backports instead of testing. If that's not
possible, your options are to backport it yourself (preferable), to upgrade
to testing, or to set up pinning to limit how much of testing you pull in.

While it's strongly warned against, so long as you pay attention and have
pinning in place to make sure you don't accidentally upgrade other packages
dependencies (especially core packages), any breakage would be minor and
easily recoverable.


On Wed, Mar 15, 2017 at 6:31 PM, Antonio Trkdz.tab 
wrote:

> Hi All,
>
> I have few questions.
>
> I am on (devuan) jessie..
> Given that "mixing stable and testing branches is recipe for disaster", is
> it safe to apt install vim version 8 from ascii?
>
> I pinned the ascii packages to priority 50 in preferences and I get:
>
> # apt-get install -t ascii vim
> ...
> The following extra packages will be installed:
>   libncurses5 libncurses5:i386 libncurses5-dev libncursesw5 libtinfo-dev
>   libtinfo5 libtinfo5:i386 ncurses-bin vim-common vim-runtime vim-tiny xxd
> Suggested packages:
>   ncurses-doc ctags vim-doc vim-scripts indent
> Recommended packages:
>   libgpm2:i386
> The following NEW packages will be installed:
>   vim vim-runtime xxd
> The following packages will be upgraded:
>   libncurses5 libncurses5:i386 libncurses5-dev libncursesw5 libtinfo-dev
>   libtinfo5 libtinfo5:i386 ncurses-bin vim-common vim-tiny
> 10 upgraded, 3 newly installed, 0 to remove and 1298 not upgraded.
> Need to get 8703 kB of archives.
> After this operation, 30.6 MB of additional disk space will be used.
> ...
>
> Would it be better to install from source?
> Can I remove vim.tiny after (or before) installing vim?
>
> Thanks!
>
> Antonio
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] pepperflashplugin-nonfree

[Stephanie Daugherty]

They won't be using it much longer. Chrome and Firefox are well on track to
phase Flash out entirely over the next year or two.

On Fri, Aug 5, 2016 at 6:01 AM richard lucassen <mailingli...@lucassen.org>
wrote:

> On Thu, 04 Aug 2016 22:17:04 +
> Stephanie Daugherty <sdaughe...@gmail.com> wrote:
>
> > As a side note, attempting to use an outdated version would be an
> > extremely bad idea, Flash seems to have a new remote hole every other
> > hour, so, you;d just be giving every website you visit a backdoor
> > into your computer.
>
> I know. But webdesigners still use flash on websites. And users want to
> use that content.
>
> For that reason I run the browser as a different user that has no
> access to my home directory. Sometimes it's annoying, but grosso modo
> it works fine.
>
> --
> richard lucassen
> http://contact.xaq.nl/
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] IRC Channel

[Stephanie Daugherty]

Ugh, the formatting seems to be fucked in
http://www.irchelp.org/irchelp/irctutorial.html
Sorry about that, I'll have to look into that today.

On Wed, Aug 3, 2016 at 8:59 AM aitor_czr  wrote:

>
> Hi Katolaz,
>
> On 08/03/2016 02:00 PM, KatolaZ 
>  wrote:
>
> On Wed, Aug 03, 2016 at 11:25:21AM +0200, aitor_czr wrote:
>
> > > Hi golinux,
>
> > > On 08/03/2016 10:27 AM, Go Linux   
> > > wrote:
>
> > >>>  >Hi all,> >>>  >  I recently wrote a message in the IRC Channel 
> > >>> #devuan, but> >>>  it doesn't appear.> >>>  >  Am i doing something 
> > >>> wrong..., or something well?> >>>  >Aitor.
>
> > >> >  What is 'recently'?  Have 
> > >you checked to see if it's in the botbot logs or if you posted during and 
> > >outage?> >> >golinux
>
> > > I just sent another one at 11:20 h. in spain.> > 
> > > http://gnuinos.org/Screenshot%20-%2008032016%20-%2011:18:29%20AM.png> > 
> > > I'm a novice in the IRC :(>
>
> Aitor, according to the screenshot, you are connected to "DALnet",
> which is the wrong network. You should connect to to the freenode
> network:
>
> host: irc.freenode.org
> port: 6667 (or  if you want to use SSL - recommended)
>
> then once you are in, join the channel "#devuan" and/or
> #debianfork.
>
> Since you said you are an IRC novice, I guess you might find this
> tutorial useful:
>
>   http://www.irchelp.org/irchelp/irctutorial.html
>
>
> My2Cents
>
> KatolaZ
>
>
> Thanks for the link :)
>
>
>   Aitor.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] IRC Channel

[Stephanie Daugherty]

Assuming you are in #devuan on freenode, I don't see any current settings
on the channel that would be likely to stop you from speaking there.

On Tue, Aug 2, 2016 at 7:26 PM aitor_czr  wrote:

> Hi all,
>
> I recently wrote a message in the IRC Channel #devuan, but it doesn't
> appear.
>
> Am i doing something wrong..., or something well?
>
>Aitor.
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Mini init script written in Perl boots.

[Stephanie Daugherty]

When recovering from systermd-related breakage while first trying out
Debian jesse, I ended up booting with init=/bin/bash  a lot.

You can rather easily bring up a fully functional system that way, at least
for long enough to fire up a browser, find the problem, and then recover.

My process for doing so was fairly simple.
- boot into bash
- remount / rw
- mount the rest of the filesystems
- start up udev (this was early in unstable or testing I think when it
wasn't merged with systemd yet)
- start up screen
- bring up network interfaces
- start up "important" system services (cron, syslog, and friends)
- fire up a display manager (not strictly required, but easy enough to do,
so why not)

I'd suggest that this is a really good way to understand what's actually
necessary to bring up the system, without writing a bit of cod, and
reproducing the steps by hand provides the level of understanding that a
sysadmin needs to have of init IMHO.



On Sun, Jun 19, 2016 at 2:30 AM Edward Bartolo  wrote:

> Hi,
>
> System initialisation is NO religiously enshrined mystery that is
> highly claimed to be beyond human comprehension. I can understand the
> position help by anyone that an init is so central to an OS that it
> must be coded scrupulously. And, given time, I think, I will
> eventually come back with something that can be said to be a
> functional and stable init.
>
> My current task if of trapping system wide events like requests for
> shutdown and reboot. My init will be used to call various scripts or
> executables depending on the type of event.
>
> Edward
>
> On 18/06/2016, Rainer Weikusat  wrote:
> > Lars Noodén  writes:
> >> On 06/17/2016 09:36 PM, KatolaZ wrote:
> >> [snip]
> >>> Unfortunately, system initialisation is really a bit more complicated
> >>> than that, whether you like it or not.
> >> [snip]
> >>
> >> Is there a concise summary somewhere of what system initialization
> >> entails?  Or is it dependent on accumulated experience and not codified?
> >
> > This depends heavily on what the system is supposed to do. Eg, something
> > fairly specialized running a single application could just run the
> > application as sole process instead of init. For something more general,
> > there'll be a static initialization step which will usually include
> > creating an initial filesystem namespace by mounting some set of
> > filesystems (some virtual, eg, proc and sys, others residing on real
> > devices) and my also include configuring some set of network
> > interfaces. Afterwards, a set of programs performing various functions
> > is started, eg, web server, name server, ssh server or so-called gettys
> > enabling interactive logins without going over a network.
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] secure boot

[Stephanie Daugherty]

In most cases right now, we have either the option to disable secure boot,
or there is a version of GRUB that is signed, therefore permitting booting
into other operating systems. For right now, investigate before buying to
make sure you have the option to boot your operating system of choice.

At some point though, as those options start to go away, we will probably
have to fight this in the courts under grounds that it is an
anti-competitive process.

Searching for, and advocating for motherboards that support coreboot is
another important strategy, because only when free firmware is available
can we be sure there will be no dirty tricks.

On Sun, Jun 12, 2016 at 7:52 AM Adam Borowski  wrote:

> On Sun, Jun 12, 2016 at 12:21:14PM +0100, KatolaZ wrote:
> > On Sun, Jun 12, 2016 at 06:35:11AM -0400, Hendrik Boom wrote:
> > > How *do* we deal with secure boot?  I am terrified of buying a new
> > > machine because  I'm afraid I won't get to install anything on it
> > > wxcept for an OS from one of the big companies that have
> > > sweetheart deals with Microsoft.
> >
> > I think that so far secure boot can be disabled. I confirm I was able
> > to disable it in my laptop. This does not mean that it would be
> > optional forever, though.
>
> The ability to disable secure boot was a requirement for the Windows 8 Logo
> program (obviously to stave off accusations from the EU).  It is gone for
> Windows 10 Logo, and thus you can expect hardware vendors to drop it --
> such
> features cause development and support costs.  This would be the case even
> with no underhanded policies, and know that "no underhanded policies" goes
> strictly against Microsoft volume licensing policy.
>
> --
> An imaginary friend squared is a real enemy.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Artistic decisions - keyboard mappings

[Stephanie Daugherty]

On Wed, May 18, 2016 at 8:13 PM Joel Roth  wrote:

> Hi,
>
> Having handled many of the issues relating to init system
> to the point of being able to release Devuan jessie beta,
> I wonder if Devuan community is ready to support action on
> other scourges of the linux on personal computer ecosystem.
>
> I am thinking specifically of three key mapping bugaboos:
>
> 1) CAPSLOCK key under console and X, should be mapped to Control
>

Capslock and control may be on dumb places on most modern keyboards, but
above almost everything else, computers should do what the user expects.
The key has caps lock printed on it, it should be a caps lock key unless
the user takes action of their own accord to change that.


>
> 2) Terminate X via Ctrl-Alt-Backspace
>
>Seems like an easy, useful, historic way to kill a malfunctioning X.
>

Strongly agree here. This was a useful function, and the decision to
disable this by default was shortsighted. There were security arguments for
disabling it - but for the most part, those arguments were about edge cases
like kiosks and shared workstations.


>
> 3) Disable Print key
>
>All my uses have been unintentional. Does anyone use it deliberately
>

I personally have it set to launch a screenshot tool and have found that to
be a common configuration in a lot of desktop environments.

>
> My other wishlist items are:
>
> 4) No display manager by default
>
>I think the community shouldn't coocoon naive users from
>the console. The passing familiarity with the terminal
>that comes with Learning to type username, password, startx
>and Ctrl-Alt-Backspace (to terminate X) will help the user
>if and when they ever have trouble with X.
>

I think this is a battle that has been already lost, and for good reason.
If someone's installing on a desktop, they want to use it as a desktop
system. That means a GUI and a graphical login, even if the purpose of that
GUI is just to arrange more terminal windows onto their screen. We have a
better chance of easing people into using command line interfaces than we
do of forcing them into them these days, because that environment is
totally foreign to most people.

That's not to say we should ignore the console, but these days there's a
huge association between the console and Things Going Horribly Wrong, and
we're well past the point of changing that attitude.

 In a server environment that's a different story - there's an expectation
that if you are using Linux as a server platform, you know what you are
doing, don't need GUIs, and are going to manage the system via ssh anyway.


On the subject of people that get thrown into the console for the first
time when something breaks, there's a lot of room to improve here. What I'd
like to see is something reasonably consistent with the curses installer
that provides a limited degree of handholding. Rather than throw people
into this automatically, it should be advertised in the default MOTD, and
it should have fallback to a simple set of prompts in case someone's using
a broken terminal. The audiences for this are both complete newcomers, who
know absolutely nothing beyond what little the /etc/issue and /etc/motd are
telling them, as well as the experienced sysadmin who finds themselves on a
system where basic facilities like networking are down, and needs to
restore those easily.

- Network configuration wizard to temporarily set up Internet access,
including bringing up a connection to a WPA2 wireless network, or
autoconfiguring a network interface via DHCP.
- Disk mounting wizard to easily and temporarily mount thumb drives.
- Diagnostic wizard to view hardware details, diagnostics, and logs and to
copy to a mounted thumb drive to look at from another, more functioning
system
- Access to a friendly package manager that automatically discovers
packages on a mounted thumb drive. (this is for users that end up in this
position because of needing packages to make the network work)
- Tools to troubleshoot the display manager.
- Backrup & Restore utilities
- Easy access to tutorials and documentation.on the local system, and
internet.
- Easy access to appropriate new-user IRC channels.
- A split screen environment, where documentation can be easily browsed on
half the screen, and a terminal is available on the other half.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Stephanie Daugherty]

Process supervision is something I'm very opinionated about. In a number of
high availability production environments, its a necessary evil.

However, it should *never* be an out of the box default for any
network-exposed service, Service failures should be extraordinary events,
and we should strive to keep treating them as such, so that we continue to
pursue stability. Restarting a service automatically doesn't improve
stability of that software, it works around an instability rather than
addressing the root cause - it's a band-aid over a festering wound.

The failure of a service is analogous in my eyes to the tripping of a
circuit breaker - it happened for a reason, and that underlying reason is
probably serious. Circuit breakers in houses generally don't reset
themselves, and either should network-facing services.

The biggest concern in any service failure is that a failure was caused by
an exploit attempt - attacks which exploit bad memory-management tend to
crash whatever they are exploiting, even on a failed attempt. In an
environment where such an event has been reduced to routine, and automatic
restarts are the norm, that attacker gets as many attempts as they need,
reducing one of the first signs of an intrusion to barely a blip on the
radar if the systems are even being monitored at all.


The second reason is that it will reduce the number of high-quality bug
reports developers receive - if failure is part of the routine, it tends
not to get investigate very thoroughly, if at all.

A third reason is convention and expectation. We've lived without process
supervision in the *nix world for almost 4 decades now, those decades of
experienced admins generally expect to be able to kill off a process and
have it stay down.

Please consider these factors in any implementation of process supervision
- while it's certainly it's a needed improvement for many organizations,,
it's not something that should just be on by default.





On Wed, May 4, 2016 at 12:35 PM Steve Litt 
wrote:

> On Tue, 3 May 2016 22:41:48 -1000
> Joel Roth  wrote:
>
> > We're not the first people to think about supporting
> > alternative init systems. There are collections of the
> > init scripts already available.
> >
> > https://bitbucket.org/avery_payne/supervision-scripts
> > https://github.com/tokiclover/supervision
>
> Those can serve as references and starting points, but I don't think
> either one is complete, and in Avery's case, that can mean you don't
> know whether a given daemon's run script and environment was complete
> or not. In tokiclover's case, that github page implies that the only run
> scripts he had were for the gettys, and that's pretty straightforward
> (and well known) anyway.
>
> As I remember, before he had to put it aside for awhile, Avery was
> working on new ways of testing whether needed daemons (like the
> network) were really functional. That would have been huge.
>
> Another source of daemon startup scripts his here:
>
> https://universe2.us/collector/epoch.conf
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Stephanie Daugherty]

I assume "penetration testing", and seems like a shortsighted view.

On Tue, May 3, 2016 at 1:57 PM Steve Litt  wrote:

> On Tue, 3 May 2016 09:05:03 + (UTC)
> Go Linux  wrote:
>
>
> > 
> >
> > Linux = Pen testing
> > Windows = everything else
>
> What is pen testing? Am I out of touch, or is this guy making up words?
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Files .udeb

[Stephanie Daugherty]

udeb files (aka micro-deb) are stripped down packages only used in building
the installer and loading installer components into memory via a network
connection - they are explicitly intended for tightly constrained
environments such as the installation environment and embedded systems, and
not meant to be installable on a standard system.

On Mon, May 2, 2016 at 10:59 AM Ismael L. Donis Garcia <
sli...@citricos.co.cu> wrote:

> what are the .udeb files?
>
>
> correcting error translating...
>
> I'm trying to create a local repository, but I do not download the files
> .udeb
> as you could download these files?
>
> #!/bin/sh
> ARQUITECTURA=i386,amd64
> METODO=http
> RAMA=jessie
> HOST=packages.devuan.org
> DIR_MIRROR=/mnt/datos/sistemas/linux/devuan/merged
> SECCIONES=main,contrib,non-free
>
> echo
> "=="
> echo "Actualizando los repositorios DEVUAN 'merged'; main, contrib,
> non-free"
> echo
> "=="
> echo ""
> debmirror -a ${ARQUITECTURA} \
> -s ${SECCIONES} \
> -h ${HOST}/merged \
> -d ${RAMA} -r / --progress \
> -e
> ${METODO} --postcleanup --ignore-small-errors --ignore-missing-release
> --ignore-release-gpg
>  --nosource --allow-dist-rename \
> --diff=none \
> ${DIR_MIRROR}
>
>  Best Regards
>  
>  | ISMAEL |
>  
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What do we want for ascii ?

[Stephanie Daugherty]

I'd like to see a long term focus on removing the entanglement with other
invasive dependencies, particularly those which are likely to be folded
into systemd in the future, and on staying true to the Unix philosophy.

DBUS and PulseAudio are freedesktop backed technologies which are likely to
be folded entirely into systemd in the future.

Further down the line, make it possible to do a guided install directly
from an existing Linux environment - similar in function to debtakeover but
perhaps with a bit more handholding.

In the much longer term, I'd like to see a more sensible approach to
getting current software, with a LTS approach to essential "core" packages,
and an aggressive release schedule for everything else - so that the core
system would be on a yearly release cycle with 3 years of support, but
rapidly changing things like browsers might see a monthly release cycle
with only 3 months of support.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] suspend and hybernate

[Stephanie Daugherty]

Correct. The hibernation image would be for the old kernel, and on the next
boot, the new kernel would choke on it, effectively making it an unclean
shutdown.

On Wed, Apr 13, 2016 at 11:22 AM Steve Litt 
wrote:

> On Wed, 13 Apr 2016 12:20:49 +0200
> richard lucassen  wrote:
>
>
> > Beware of kernel changes, do not hibernate after a kernel change.
>
> Can I safely assume you mean don't hybernate after a new kernel which
> I've never before booted to?
>
> Thanks,
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] On the wisdom on netboot installer images

[Stephanie Daugherty]

One of the biggest improvements I'd like to see in the installer in
general, including the netboot installer, is the ability to easily install
a newer version than the ISO was created for. I know it can be done
manually with debootstrap, and such, but being able to "self-update" the
entire installation process to a newer version would mean being able to
keep using the CD for a long period of time, instead of only getting a
single use out of it in many cases.



On Mon, Mar 21, 2016 at 10:09 PM Boruch Baum  wrote:

> On 03/21/2016 09:50 PM, Adam Borowski wrote:
> > On Mon, Mar 21, 2016 at 05:19:33PM -0400, Boruch Baum wrote:
> >> 1] For a day-to-day changing alpha release it makes plenty of sense to
> >> keep the initial download as small as possible, since so much is
> >> expected to change as part of the development process.
> >>
> >> 2] OTOH, a developer wants to encourage people to test the install and
> >> the release often, so it makes sense to have an initial iso download
> >> packed with the stable and large software packages that aren't central
> >> to the what the distribution is innovating. Any time a user runs a
> >> second test, she incurs a bandwidth burden of an entire new install.
> >>
> >> 3] One complicated solution would be to not destroy
> >> /var/cache/apt/archive on the target when re-installing. It could be
> >> done by having the installer suggest to mount that folder on its own
> >> partition, and then have the installer refer to it at the download
> stage.
> >
> > Trusting /var/cache/apt/archive on the target would risk way too many
> modes
> > of breakage, let's not go there.
> >
> > If you're doing frequent installs, you'd better install apt-cacher-ng (or
> > one of its competitors) on a box on the local network, and use that
> whenever
> > asked for a mirror.
> >
> > The apt source will then be:
> >   deb http://$YOUR_CACHE_BOX:3142/ftp.$COUNTRY.debian.org/debian/
> > or
> >   deb http://$YOUR_CACHE_BOX:3142/packages.devuan.org/merged
> >
> > This way you download any package, binary or source, at most once.
> >
>
> Good. But the point was to have that function folded into the installer,
> with a fallback for a network download, in a manner simple for the
> largest group of testers to use. Your suggestion seems to me in practice
> to require of the user many more manual steps before, during, and after
> each install. I've never used the technique, but you seem to also be
> saying that it requires extra hardware, in the form of a local network
> and a second box to host apt-cacher-ng.
>
> Come to think of it, I challenge your starting point contention: "would
> risk way too many modes of breakage", so let's do go there, if only for
> a bit. What are all those "too many modes" and how bad are the risks?
> What's the worst downside, worse than a failed keysign check?
>
> --
> hkp://keys.gnupg.net
> CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Stephanie Daugherty]

I would argue vdev belongs in  / rather than /usr because it is likely to
be necessary to mount filesystems and such.

The split is somewhat arbitrary these days but historically things needed
during the boot process and to repair the system have gone in / while less
essential bits have gone into /usr

People do still partition that way sometimes so it's a good idea not to
break the system for them :)

On Sat, Mar 19, 2016, 14:14 Rainer Weikusat 
wrote:

> aitor_czr  writes:
> > By default, PSTAT (a dependency of VDEV) is installed in "/usr/local",
> > just as VDEV.
> >
> > As Daniel Raurich explained in another thread:
> >
> > [...] the "/usr/local" directory is for non-packaged local stuff [...]
> >
> > So, should i change this configuration for those packages, or should i
> > skip debhelper's "dh_usrlocal" script adding:
> >
> > binary:
> > dh binary --before dh_usrlocal
> > dh binary --after dh_usrlocal
> >
> > to debian/rules?
>
> To which degree this actually makes a difference would be a good
> question but the convention-so-far has been that distribution provided
> stuff goes into / or /usr and that /usr/local can be used as seen fit by
> whoever controls/ administrates a particular installation. If the
> packaged vdev is supposed to become an integral part of the OS/
> distribution, it should honour the existing convention unless there's a
> good reason for not doing this.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Microsoft upgrades Windows 7 to 10 without permission

[Stephanie Daugherty]

At this point, if they are so insistent on getting everyone over to win 10,
they've be better off to just declare it to be a "service pack" to Windows
7. It would be less toxic to their reputation than the underhanded shit
they are doing.now.

On Tue, Mar 15, 2016 at 4:29 PM Steven W. Scott 
wrote:

> I made the mistake of upgrading to 10, and it breaks all broadcom BT. It
> appears they simply chose not to support any Broadcom BT devices in Win 10.
>
> I Dropped back to 7, created a .exe that simply returns to OS, and then
> replaced c:\Windows\system32\GWX\GWX.exe and c\Windows\SysWOW64\GWX\GWX.exe
> with my NOP code.
>
> It doesn't bug me or try to pull win10 anymore. MS tried to 'update' it
> back to their version after a week or so, but I overlayed it again and not
> a peep for weeks now.
>
> And 7 can continue as my gaming platform. HUZZAH!
>
> SWS
> On Mar 15, 2016 4:03 PM, "Didier Kryn"  wrote:
>
>> Le 15/03/2016 14:10, Mitt Green a écrit :
>>
>>>
>>> https://www.reddit.com/r/technology/comments/4a0asv/warning_windows_7_computers_are_being_reported_as/
>>>
>>>
>> This happened to my son last summer. 2 or 3 weeks after that,
>> windows10 refused to boot anymore. Therefore the laptop became available to
>> install Devuan Jessie :-)
>>
>> Didier
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] The repository has old OpenSCAD package.

[Stephanie Daugherty]

You can also try cherry picking packages from ascii or ceres, or upgrading
to these testing/unstable releases, but this is probably the worst option
as unstable really is unstable right now with the ongoing efforts to
disentangle from systemd and its related malware.

On Fri, Mar 11, 2016 at 6:48 PM Stephanie Daugherty <sdaughe...@gmail.com>
wrote:

> The version in Devuan Jessee will be the version that was currently
> packaged at the time Debian Jessie was frozen. Devuan adheres to the same
> release model as Debian - updates to a package which modify its
> functionality in any way whatsoever are forbidden for the life of the
> distribution, and security/stability fixes from a newer upstream must be
> backported to the version released with Devuan.
>
> Your options for more current packages are (in general order of
> preference):
> * See if the jessie-backports repository has the newer version you need.
> (jessie-backports is a repository of newer packages compiled against
> released dependancies so as to be usable with jessie. It's recommended that
> you set up pinning im such a manner as to only install from backports if
> explicitly told to do so, otherwise you may upgrade more than you'd like
> and possibly even break things)
> * Find a third party repository compatible with jessie that has a current
> version
> * Build your own, current version of the package
> * Build from source, install into /usr/local (if you go this route,
> strongly consider using stow to manage your /usr/local hierarchy - this
> doesn't register the package with dpkg, so if you need it to satisfy a
> dependency in another package, it's not a good option)
>
>
>
> On Fri, Mar 11, 2016 at 12:11 PM Hughe Chung <janpeng...@riseup.net>
> wrote:
>
>> Hi,
>>
>> The latest stable version of OpenSCAD is 2015.03-3.
>> When I installed openscad, it was old version.
>> openscad:amd64/jessie 2014.03+dfsg-1 uptodate
>>
>> Regards,
>> Hughe
>>
>> PS: Are there any 3D Printer users?
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Is Devuan Jessie secure enough?

[Stephanie Daugherty]

On Wed, Mar 9, 2016 at 5:11 PM Steve Litt  wrote:

> One man's opinion: *NO* computer is secure enough for an individual's
> banking or investments.
>
>
>
It's really a mixed bag. On one hand, you can't completely trust any
computer, on the other, you can't really trust the computers that handle
check/credit card/debit transactions either, and in fact, you can probably
trust them a lot less.

For reasonably careful, reasonably competent people, I'd expect the overall
risk reduction from the increased transaction scrutiny afforded by use of
online banking to far outweigh the risks accessing sensitive financial
information from one's PC/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dependency Hell: was leveldb support proposal

[Stephanie Daugherty]

There's a fairly elegant, but seldom used solution to this problem,. GNU
Stow, which is designed to basically be a "package manager" for locally
installed packages.

It works by using symlinks, so that a "package" foo might be installed into
/usr/local/stow/foo and have bin/  and lib/ and all the other expected
subdirectories. Stow will then install that "package" into the  /usr/local
hierarchy proper on command by symlinking each file into the proper place,
and as an intended side effect of this design, Stow, or even a simple
she'll script can easily find all the symlinks to remove later, since they
all point to the actual installed files in the package installation
directory.

On Wed, Mar 2, 2016, 12:05 Edward Bartolo  wrote:

> Hi,
>
> On 02/03/2016, Steve Litt  wrote:
> > I'm not recommending this for every app. But I've got to tell you, when
> > you think about installation by package manager, with its pinnings and
> > exclusions and dependencies and conflicts, not to mention sabotage of
> > packaging by the poetterists and their ilk, installation by directory
> > starts to have its own charm, for certain applications.
> >
> > SteveT
>
> However, does copying a directory tree to install a program go against
> conventions where various parts of an installation should be placed?
>
> Edward
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] A heads up about xfce's future

[Stephanie Daugherty]

Just to clarify about "default" desktop environment and what that actually
means.

The "default" desktop environment is the one that gets squeezed onto the
first CD/DVD of a set of installation media, as well as the one that's
installed if you just click "desktop environment" in tasksel without
specifying. As far as Debian has been concerned, that's all it means. It
provides a strong suggestion to live CD/DVD creators of what desktop to
include, but no guarantee anyone will follow that suggestion. I'm assuming
the same thing will hold true for Devuan.

The constraint of "what fits on the first installation disk" may not matter
to the bulk of users, but it's an important one for people with metered
internet, intermittent internet connectivity, or no internet connectivity
at all. This means the first disk should be able to produce a working,
fully functional desktop or server installation for as many users and
situations as possible, with or without internet connectivity.

Now, as to criteria for a default desktop environment, that's a bit more
subjective, but I personally believe in the following

- an interface that is instantly familiar to the broadest possible number
of users - that means a start/applications menu, taskbar, and system tray,
icons on the desktop, maximize/minimize/close buttons on windows, etc
- compact enough to not squeeze out other things that we really want on the
first installation disc
- should not pull in unwanted or bulky dependencies
- does it pass the "phone support test"  - how hard will it be to walk your
90 year old technophobe hard of hearing grandmother through fixing wifi
over a phone line with heavy static?

It's very important to remember that criteria for a default desktop
environment are not necessarily criteria for *your* preferred desktop
environment. A "least common denominator" choice here is probably the best
choice, because whatever we choose as default needs to work for ALL users,
not just technical ones.







On Mon, Feb 29, 2016 at 10:04 AM hellekin  wrote:

> On 02/28/2016 07:38 PM, Hendrik Boom wrote:
> >
> > I suggest we use this mailing list for communication, and label each
> > post with the word DE in capital letters on the subject line.
> > Thus they'll end up arriving as [DNG] DE ...
> >
>
> We can do that, or use Mailman topics: so if you put [DE] in your
> Subject, you are filtered.  That way people who want can subscribe to a
> subset of the list.  The main issue with this process is that it forces
> you to include the tag in the Subject every time.
>
> Anyway a month or two from now, Discourse will be ready to surpass
> Mailman as a mailing list manager, thanks to a grant the Discourse team
> received for that purpose [0].  This is great news for people allergic
> to Web forum, as you will be able to do everything without ever opening
> a Web browser.
>
> On the Gitlab there's no group yet for Desktop.  If enough people are
> interested in configuring, customizing, and finding commonalities
> between Desktop Environments that could be interesting.
>
> ==
> hk
>
> [0]:
>
> https://blog.discourse.org/2015/12/discourse-selected-for-mozilla-open-source-support-program/
>
> --
>  _ _ 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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ad filtering and blocking

[Stephanie Daugherty]

On Sun, Jan 24, 2016 at 7:55 AM, Edward Bartolo  wrote:

> Hi,
>
> Thanks for your reply. I am noticing that since some time ago websites
> are starting to 'brainwash' users to use cookies. This is often done
> by displaying a high contrast banner at the top threatening that by
> using their website one MUST also enable cookies.
>
> Is there a way to avoid this new 'cool feature'?
>



My understanding is this is actually some EU privacy law where they have to
disclose cookie use.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lilo development has ended

[Stephanie Daugherty]

the plethora of numbered config files is a consequence of debian policy
(config files have to be owned by exactly one package, and that's the only
package which can automatically touch them) rather, than any design of
grub2 itself. Split configs is the way that Debian works around this policy
while still allowing packages to automate configuration - the kernel
package owns a file with the bits needed to enable that kernel, the
memtest86 package own a file with the bits to add memtest86, and so on, so
that there are no turf wars

The same pattern exists in many other Debian packages, it's not a grub2
thing at all.

On Tue, Jan 19, 2016 at 2:13 PM, Edward Bartolo  wrote:

> Hi All,
>
> On this machine I am using right now on which I developed netman, I
> have grub2 installed. Since I never agreed with how grub2 should be
> managed, I opted to use a manual method to update grub.cfg. This
> machine has about 9 Debian/Devuan installations installed to separate
> partitions on a GPT formatted disk. The first partition is the one
> dedicated to maintain grub2 with only a terminal and root as a user. I
> found that grub.cfg uses an easy syntax that I can adopt to manually
> edit the file to achieve more or less the same ease of use I used to
> enjoy with grub1. In case grub2 overwrites grub.cfg, I keep a backup
> so as to easily restore it to the prior state. All other installations
> do not have a bootloader installed so that the primary bootloader
> would always continue to load the correct manually written grub.cfg as
> I wanted.
>
> My setup prevents any installation from modifying grub.cfg without my
> knowledge. It also makes it impossible for any installation to modify
> the primary bootloader except the one with grub2 installed that I
> almost seldom boot. In fact, there is no grub menu entry for the
> installation that I use to manage grub2. When I need to do that, I
> press 'e' as soon as the grub2 menu is displayed and edit the menu
> entry's stanza as appropriate.
>
> Although it may sound complicated, this setup saved me quite a lot of
> headaches about changing menus without my approval.
>
> Edward
>
> On 19/01/2016, Joel Roth  wrote:
> > Steve Litt wrote:
> >> On Tue, 19 Jan 2016 17:20:10 +0100
> >> Adam Borowski  wrote:
> >>
> >> > On Tue, Jan 19, 2016 at 11:02:17AM -0500, Steve Litt wrote:
> >> > > Grub is the systemd of bootloaders. It's all about pretty colors,
> >> > > nice images, and hiding the fact that processes are being
> >> > > instantiated.
> >> >
> >> > Grub is complex, but that's caused by what it tries to do (read the
> >> > kernel image from real filesystems instead of a blockmap like lilo).
> >> > It doesn't go beyond its scope, unlike systemd.
> >>
> >> The preceding paragraph was much more true of Grub1 than its gargantuan
> >> spawn, Grub2.
> >>
> >> Grub1 read filesystems just fine. Grub2 has prioritized all sorts of
> >> pretty, and the simplicity of Grub1 has been lost.
> >
> > The grub developers wrote that they began grub2 due
> > to limitations and maintenance problems with grub1.
> >
> >> SteveT
> >>
> >> Steve Litt
> >> January 2016 featured book: Twenty Eight Tales of Troubleshooting
> >> http://www.troubleshooters.com/28
> >>
> >>
> >> ___
> >> Dng mailing list
> >> Dng@lists.dyne.org
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> > --
> > Joel Roth
> >
> >
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware

[Stephanie Daugherty]

On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen  wrote:

> ..why did Debian kill ssh into localhost?
> Is su or sudo safer than ssh nowadays?
>


Because the architecture of Linux gurantees that root has a fixed account
name, fixed UID, and, if in a server environment, will be essentially a
shared account, it's considered a long standing best practice to not let
people log in directly as root, at least not remotely. This makes sure
there's an audit trail of logging in with the unprivileged user and then
elevating to root, rather than just the root login that doesn't indicate
which of possibly several users was responsible. It also means a brute
force against the root account is more difficult to automate, since you
need to attack an umprivledged account first, and it offers a little bit of
protection against a weak root password.

sudo is generally the accepted way in the ubuntu world as well as in most
server environments these days, since the audit trail will record exactly
what commands were elevated and by who, and since only a single command is
run with elevated permissions, therefore dropping back to an unprivledged
command prompt after each elevated command.

su was the best practice long before sudo or even Linux ever existed, and
is still perfectly acceptable for hobbyists, desktops, and others where
there's exactly one *competent* admin for each machine. and may even be a
viable option in other, more controlled environments that don't want to use
sudo. Historically, on other *nixes, it was gated with the "wheel" group,
(and this can be done on Linux as well if the admin wants to configure it
this way).

Obviously, this has the additional advantage that, through some tinkering
with PAM, you can implement additional authentication requirements just on
root access - for example, you might let your admins log in and look around
with just their SSH key, but require them to have an additional password or
multifactor authentication token to access root privileges.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] That one unsupported app: was Predictable Network Interface Names - Stupid or good idea?

[Stephanie Daugherty]

OpenBSD's overall stance on virtualization makes it a poor choice for a
desktop OS unfortunately. I partially understand the reasoning, however,
given the limits of software support on the *BSDs in general, and OpenBSD
in particular, the lack of virtualization options effectively makes it
unusable for a substantial number of users.

The situation on FreeBSD seems a little better though, and I've seriously
considered making that switch.






On Sun, Jan 10, 2016 at 6:10 PM, Steve Litt 
wrote:

> On Sun, 10 Jan 2016 21:55:48 +
> Dave Turner  wrote:
>
> > Slackware is hard work when you have been used to the ease of debian
> > for so many years...
> > Eventually it all worked OK until one particular bit of music
> > composition software I like to use could only be found in
> > Slackbuilds, and it would not install even after I did some editing
> > of the scripts. I gave up and installed devuan again.
>
> Devuan is an excellent distro and I applaud you for installing it.
>
> If you ever find that one app that you can't install on Devuan, just
> run a VM or container that *does* do that app right, and run that one
> app there.
>
> The entire reason why I didn't migrate to OpenBSD and happily stay
> there in September 2014 is because OpenBSD has no functional and
> working Qemu, and shows little motivation to change that. So I'd have
> to permanently live without those couple programs I needed. Normal
> Linuxes enable you to run other distros in VMs or containers, so choose
> the best one, even if it won't do your favorite program.
>
> SteveT
>
> Steve Litt
> January 2016 featured book: Twenty Eight Tales of Troubleshooting
> http://www.troubleshooters.com/28
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Predictable Network Interface Names - Stupid or good idea?

[Stephanie Daugherty]

Having dealt with systems with half a dozen interfaces in the past there's
a very small number of cases where it even matters, but when it does, it
can be a huge inconvenience either way.

Their (for once, rational) argument is that Interface names of existing
interfaces should never change by adding or removing hardware from the
system, or as a result of hardware/software quirks (on some systems,
interfaces are known to swap places on reboot, which is clearly not
acceptable).

There are numerous approaches to dealing with interface names - off the top
of my head I can come up with the following

1 - detect the current name by mac address and use shell script variables
to deal with it.
2 - have udev issue automatic persistent names by bus location
3 - have udev issue automatic persistent names by mac address
4 - have udev issue manual (admin-chosen) persistent names by bus location
5 - have udev issue manual (admin-chosen) persistent names by mac address
6 - do nothing, blindly use the traditional interface names and hope it
doesn't break due to some event reordering the interfaces
7 - detect the current name based on what other devices are visible via
each interface / which devices can reach the internet
8 - name interfaces by driver family (IIRC, default behavior of some *BSDs)



Bus location is a sensible default in newly installed systems, because it
provides reasonable guarantees that names won't shift on their own. It
shouldn't automatically change from traditional names to these names on an
installed system though, because then you've just caused the very problem
you are supposedly trying to solve.

Dealing with possibly shifting interface names in firewall scripts is
certainly an option, but dealing with it in udev is far more elegant, and
in the long run, much friendlier to the admin. It's easy to fix these names
to an admin-defined name by bus location or mac address as needed






On Sat, Jan 9, 2016 at 11:03 AM, dev1fanboy 
wrote:

> It sounds like a good idea in theory, but I see no reason eth0, eth1,
> wlan0, wlan1, etc should change. It could be as simple as deciding which of
> those to use based on some information from the device in the case there is
> more than one NIC. Changing that for no good reason is clearly a bad idea.
>
> Personally, I'm not buying it. Freedom to choose and backwards
> compatibility is more important to me [not for sale].
>
> On Saturday, January 9, 2016 11:41 AM, Anto  wrote:
> > Hello Everybody,
> >
> > I have just rented a KVM VPS. I started with Debian squeeze, pin
> > everything related to systemd to -1, then upgraded to Debian wheezy.
> > After I upgraded udev to version 220 using eudev, I could not connect to
> > my VPS any more after reboot. This has never happened on my other VPS'
> > but they are all Xen-PV based VPS.
> >
> > It turned out that the eth0 interface was changed to ens3, due to the
> > implementation of Predictable Network Interface Names
> > (
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
> ).
> > I can change everything which contain eth0 into ens3, but I prefer to
> > keep the old interface naming. So my temporary solution is to add
> > net.ifnames=0 into the kernel command line.
> >
> > I have been indoctrinated myself that everything come from systemd gang
> > are stupid and bad. After reading the above link and some other pages
> > from systemd supporters, I think I might have to change my mind about
> > that Predictable Network Interface Names idea. But I am not entirely
> > sure yet. What do you guys think about that?
> >
> > Kind regards,
> >
> > Anto
> >
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> --
> Take back your privacy. Switch to www.StartMail.com
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Stephanie Daugherty]

On Sun, Jan 3, 2016 at 3:59 AM, KatolaZ  wrote:

> But what's the point of having modules "at the end of [the kernel]
> image"? You can just compile-in them.
>


Simple, It's to be able to turn a packaged, distribution supplied kernel
into one that will successfully boot on obscure hardware - to be able to
inject the modules needed for drive controllers, filesystems, and other
boot-time dependencies into the image.  Which would be not only faster, but
also less error prone, and easier to do than a full kernel compile and all
the obscure, potentially breaking choices that go with it.

There's also the issue of overly risk-averse enterprise environments. Even
if they trust their sysadmins, they may not trust the compiler and the
hardware it runs on well enough to risk deployment into production. A
distribution-supplied kernel typically means that same binary is already
running on at least hundreds of thousands, if not millions of other
systems, meaning someone else is finding problems for you. There's no way
they're going to get that level of testing from a kernel built in house.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Stephanie Daugherty]

On Sun, Jan 3, 2016 at 8:25 AM, Roger Leigh  wrote:

> Regarding the comments people made about having separate / and /usr
> filesystems.  While it was common historically, there is little or no
> practical benefit to doing so in 2016.  Storage sizes make it unnecessary
> for pretty much all practical scenarios.  The two are managed by dpkg as a
> coherent whole; they are logically inseparable. They serve the same
> purpose.  Do reconsider whether it's actually necessary for you to do this,
> or whether it's merely habit.  Some historical practices continue to have
> value; others, including this one, do not.



There's still numerous practical benefits.
1) emergency storage expansion in place on a mission critical system. One
of the quickest and safest ways to add disk space to such a system with
little to no downtime.is to add another drive, create a partition on that
drive for /usr, and then migrate everything under /usr there while using
the "critical" binaries in /bin and /sbin to finalize the move.
2) Backups - the traditional layout makes it easier to determine backup
schedules granularly by path. (most of /usr can potentially be excluded
entirely, as it can be recovered be reinstallation of  packages)
3) split layout with separate partitions minimizes the chance that an out
of control process might fill up enough of the disk to render the system
unusable
4) split layout with separate partitions minimizes the chance of a
filesystem error impacting ability to boot single user
5) split layout with separate partitions minimizes the size of the root
partition that needs to be periodically checked by fsck
6) some sysadmins choose to mount /usr and other non-root filesystems
nosuid to minimize attack surface
7) split layout with separate partitions allows a root filesystem from the
current system to be used to cleanly reinstall or even change distributions
in place on a running system with minimal downtime.

Granted, a lot of these are corner cases, but, they are still practices
that may be employed by experienced sysadmins. I've had to implement a
separate /usr filesystem as an emergency fix in the last year and a half -
client had an eCommerce website with relatively low traffic. Black Friday
happened - filesystem was filling up faster than we could do something
about it, and we couldn't have lengthy downtime. Their website was served
off of a VPS, the provider could attach additional storage as new
filesystems, but didn't support resizing of existing ones. Breathing room
was obtained by adding a separate /usr and separate /var, and all of this
had to be done live. Having the necessary tools safely tucked away in /bin
and /sbin meant being able to cut over in seconds without risk of fucking
the system up to the point of needing a reboot.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Stephanie Daugherty]

Regardless of who proposed it, merged /usr is still a reckless change that
needlessly complicates things.

The /usr and / split hasn't been perfectly followed, ever, but, still
achieves the goal of having a system that can be recovered from various
problems easily.

I should be able to substitute /bin/sh for init, and directly mount / and
go from there to a fully working system, regardless of my partitioning.
Period. If I can no longer do that, it's a broken system.




On Fri, Jan 1, 2016 at 9:25 PM, Steve Litt 
wrote:

> On Fri, 1 Jan 2016 19:33:41 +0100
> Didier Kryn  wrote:
>
> > Le 01/01/2016 18:07, Steve Litt a écrit :
> > > On Fri, 01 Jan 2016 15:45:49 +0100
> > > Micky Del Favero  wrote:
> > >
> > >> Daniel Reurich  writes:
> > >>
> > >>> So the potteringisation continues...
> > >> If I remember well Solaris has /bin linked to /usr/bin since many
> > >> years, so linking /bin to /usr/bin is not a poetteringisation, or
> > >> almost it's not an original idea of poettering.
> > >>
> > >> Ciao, Micky
> > > Well, OK, if we're really going to discuss this...
> > >
> > > This *is* poetterization, regardless of what Sun or anyone else did
> > > before. It's supported by Freedesktop.org, and I think everyone
> > > here can agree that anything Freedesktop supports is anti-init
> > > choice, anti-simplicity, anti-modularity, and pro-systemd.
> > >
> > >
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> > >
> > > Those of you who have tried to lay down an alternate init system, to
> > > replace systemd, without the aid of a package manager, will probably
> > > agree with me that the toughest obstacle isn't udev, it isn't dbus,
> > > it's initramfs. I looked up the word "black box" in the dictionary
> > > last night, and they had a picture of initramfs.
> > >
> > > Hey, I'll be the first to admit that sometimes you need an
> > > initramfs. Maybe you have LUKS plus LVM plus software raid. Merge
> > > or not, you'll need to compile yourself one heck of a kernel to
> > > avoid needing initramfs. But for the very prevalent use case of
> > > Ext4, no raid, no LVM, no LUKS, no silly merge, and a few
> > > partitions, initramfs is as useful as udders on a snake. I mean
> > > seriously, in such a use case, you forego initramfs: boot to the
> > > root partition, run /sbin/mount -a, and bang, you have all
> > > resources available to you. But nooo.
> > >
> > > Initramfs does have one big benefit for the Poetterists: It
> > > provides a dark, safe place for them to start up their
> > > megacomplexities and call it magic. Oh, there are tools with which
> > > you can periscope into initramfs, but have you ever really looked
> > > at everything in an initramfs? It's a jungle in there. Just right
> > > for the Poetterists to incubate their plague.
> > >
> > > Now, the Freedesktop.Org to which I referred earlier in this email
> > > has a link to the following Rob Landley page explaining what they
> > > call the "historical reasons" for separate directories:
> > > jitsi_2.8.5426-1_amd64.deb
> > > http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> > >
> > > Note that Landley's #1 reason for merging is the existance of
> > > initramfs. Now I'm not stupid enough to call the author of Busybox a
> > > Poetterist. He wrote this in 2010, before anyone really knew the
> > > Napoleonistic aspirations of systemd, back in the days when a
> > > complex and opaque "early boot" wasn't a big deal.
> > >
> > > But now it's 5 years later, and that early boot black box is exactly
> > > where the Poetterists fester most virulently.
> > >
> > > In summary, if you accept the merge and /usr on a separate
> > > partition, you need initramfs. And if you have initramfs, you've
> > > just made it three times as hard to lay down Runit or Epoch or s6
> > > or Suckless Init plus daemontools-encore plus Littkit.
> > >
> > > We all have to pick our own battles, and I'm not sure how much
> > > effort I'd make to roll back the merge. It may indeed be a good
> > > thing that only 3 changes are required to patch up Devuan for the
> > > merge. But make no mistake about it: regardless of its initial
> > > motivation, today the merge's primary beneficiaries are Red Hat and
> > > their proxies, Freedesktop.org and Lennart Poettering.
> > >
> > > SteveT
> > >
> >
> >  Sorry Steve but I think you are making some confusion.
> >
> >  Before initramfs, there was initrd for the same major purpose:
> > to load the necessary device driver to operate the hard disk drive.
> > initramfs is just more clever than initrd. The kernel developpers,
> > IIRC, have developped their own set of applications for use in the
> > initrsmfs/initrd.
> >
> >  Busybox OTH was not developped for initramfs at all, and Rob
> > Landley was only one of many developpers of Busybox (he's now
> > developping his own alternative). The fact is that Busybox 

Re: [DNG] Preferred automounter behavior?

[Stephanie Daugherty]

FHS 2.3 apparently. They appear to serve mostly the same purpose, but /mnt
is specified as "temporarily mounted filesystems" while /media is specified
as just "removable media".

Regardless, since the implementation of /media, automounters have tended to
mount stuff there, while things manually mounted have tended to be mounted
in /mnt, presumably avoiding conflict between what the administrator wants
to do and what the automounter wants to do - which is a good precedent to
follow IMHO.


On Fri, Dec 25, 2015 at 3:03 PM, Arnt Karlsen  wrote:

> On Fri, 25 Dec 2015 12:44:43 -0700, Gregory wrote in message
> <20151225194443.ga2...@gregn.net>:
>
> > On Fri, Dec 25, 2015 at 02:35:39PM -0500, Steve Litt wrote:
> > > > (Why /mnt ?)
> > >
> > > Tradition. It exists on all distros I've ever seen, and it's used
> > > for mountpoints. Do you think the more modern, file
> > > manager-centric /media would be a better choice? That would be no
> > > more difficult.
> >
> > Here's another good reason: /mnt is quicker and easier to repeatedly
> > type than /media. I'd say mount as /mnt/sdd1, /mnt/sdd2, ... Just my
> > $0.01 worth.
> >
> > Greg
>
> ..where did the "/media tradition" come from anyway?
>
> --
> ..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
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Stephanie Daugherty]

On Fri, Aug 14, 2015 at 8:20 PM James Powell james4...@hotmail.com wrote:

 Slackware is maintained by 3 core people with extra help as needed. The
 rest of the packages are pushed by the community at large contributing.
 Devuan doesn't have to maintain every package possible. That's ludicrous to
 think so.

 Debian got in over its head by allowing this. Thousands upon thousands of
 packages that required a committee to oversee.

 They did, but out of all this design by committee, hidden between all the
political bullshit and bikeshedding, they also created the most brilliant,
most comprehensive set of standards for quality control, package
uniformity, license auditing, and of course. the most robust dependency
management, at least among binary distributions.

More importantly than that, they backed these standards up with automated
tools that are nearly as robust as the standards themselves. You don't see
packages interfering with one another very often in the Debian world,
because this is caught right away by scripts that check that every file
installed by a package, or automatically created by that package belongs to
EXACTLY ONE package, otherwise all the packages have to use some approved
mechanism to cooperate. You also see this effort it in difficult to
configure packages that set themselves up and work out of the box, and in
the modularized configuration that's common to many packages.

Most importantly, this rigid attention to detail  is why for more than a
decade now, in place upgrades have been fully supported, officially
recommended and for the most part, Just Work(tm(. It used to be said, back
in the day that the installer was still horrible, thank god you only ever
have to see it once

With that said, Debian could have accomplished far more had it not been a
case of Design by committee, or if they had a competent BDFL with a firm
grasp on the overall vision stepping in from time to time when all that
process got out of hand, but I'm not sure if they'd have been ambitious
enough to create some of the architectural  masterpieces they have with
different leadership.


Honestly, what is needed by a distribution? Look at Slackware or BLFS
 that's a lot of packages, but it's manageable by a small team. Why can't
 Devuan follow suit? There doesn't need to be a bagillion packages
 maintained by the main devs. If the rest need to be passed back to the
 community at large, then do it. This also hits the point of why do we need
 5 different for things like, for example, SDL packages for -bin, -lib,
 -doc, -dev, -src, and such? One package is easier to maintain than five
 individual ones. It lightens the load significantly, especially for the
 poor soul having to make 5 or more different scripts for 5 packages from
 the same source tarball. Yes, it's nice to have small packages for embedded
 stuff and small disks, but do you really want to raise the workload of the
 maintainer that much?


The various -bin -lib etc packages raise the workload very little, if at
all - once it's properly set up, that part's effectively automated.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Stephanie Daugherty]

On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene t.j.duch...@gmail.com wrote:


 1.  You can't mark a package as Do not install.  APT simply does not give
 you the option.

 Heaven knows, there are a lot of people who dislike things like network-
 manager, and do not them to install for any reason.

 Someone might say - wait you can put a hold on packages.  That's true, but
 that does not stop packages from being installed. It only says which
 version
 is preferred.  There is no option for none.

 You can block packages with APT pinning, but using pinning is very
 esoteric.

 There's a less obvious, but more reliable solution that holding or
pinning., and that is the dummy package. equivs makes this pretty easy to
create - you simply need a package marked that conflicts with the undesired
software, or if you prefer, one which tells the system that package is
already installed, so that you can ignore the dependency at your own risk
and without any pestering from apt. .



 2. Whenever an update has bug, you cannot rollback to the previous version
 of
 the package.  It is always assumed that the latest version is correct.  In
 the
 real world, we know that is not always true.


Sure you can, just not with apt. dpkg is still the actual package manager,
and will happily install older versions for you, so long as you take care
of the dependencies on your own. In many cases the previous packages are
still sitting around in apt's download directory, but if not, they can
usually still be found in the archives.

Besides, unless you follow unstable, this doesn't happen often enough to be
a serious concern, because of Debian's rigid no functionality changes in
stable, only fixes policy.

The situation in both of these cases should be better, but arguably, if
it's a direction Devuan decides to go in, it would be best to do so as
extensions to apt rather than reinventing the wheel, so as to keep as much
compatibility with Debian as possible and continue to use Debian as
upstream whenever possible.

Without Debian as an upstream, the task of maintaining Devuan even at
parity with Debian would be all but impossible for the small team of
maintainers and developers currently part of Devuan. Unless a very large
portion of the Debian community jumps ship, and Devuan becomes the base of
Debian rather than the other way around, I think this will have to continue
for the foreseeable future.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Stephanie Daugherty]

If anything, shims for systemd should be something that relies on
LD_PRELOAD to provide the wrappers, rather than making them broadly
available - so that it's possible to use it as a workaround, but without
deliberately doing so, the affected packages WILL break.

I fear however that we're going to see packages with deeper and deeper
entanglement with systemd, where it won't be a simple matter to patch the
software to work correctly. Gnome already seems to be moving full speed
ahead in this direction, and unfortunately, it's a matter of time before
others follow suit. Since systemd is firmly committed to being Linux only,
other *nix operating systems, including the *BSD world are having to build
workarounds. I think collaboration with them on a common implementation
that provides a workable, portable, and non-invasive comparability layer
would be mutually beneficial, and needn't be exclusive of efforts to
disentangle packages from the systemd beast altogether.


On Fri, Aug 14, 2015 at 8:59 AM Simon Hobson li...@thehobsons.co.uk wrote:

  It seems to me that it's good to have shim programs that satisfy
  dependencies of apps on systemd, each shim performing some systemd
  function. Here's why:
 
  Suppose there are 10,000 application programs (apps) for Linux,
  and their developers foolishly insert dependencies on systemd.
 
  If Devuan developers write 50 simple shims to fulfill those
  dependencies, then Devuan users can run those 10,000 apps
  as they are, directly from the Debian repos. And when the
  apps are updated, they will still run.

 As pointed out already, unless the systemd calls are not actually doing
 anything useful to the operation of the program then replacing each call
 with a null operation will break the program.

 But, IMO there is a more important philosophical reason not to do it.

 If it were technically possible to create all these shims that would do
 nothing but magically still let programs work, by doing it that way you
 have legitimised the use of those systemd calls. As in, use as many as
 you like, it doesn't actually matter.
 If Devuan can get to the point where the devs that are blindly going down
 the systemd alley* want to get on board, without these shims there is a
 clear message - fix your code or it can't be installed.

 * I'm sure some feel they are using systemd calls for a good reason. In
 many cases there may well be merit in using them when available.


 As an example, I tried to upgrade one of my Wheezy systems to Jessie with
 *systemd* pinned as not installable. It took a bit of messing around
 figuring out what the broken dependencies were, and in the end I only had
 ONE single package that I needed and which wouldn't install - clamav-daemon
 (the other clamav* packages were fine, just not that individual one). In
 response to my messages on the clamav mailing list and bug report, it turns
 out that they only make ONE call to libsystemd during startup and then
 never use it again, and it's not even an essential call - but no, it would
 be a waste of CPU cycles to do a if exists libsystemd0 then call ... I
 assume it's not considered a waste of cycles to maintain a separate package
 for Wheezy security updates !
 If you provide a shim, then you legitimise this sort of behaviour. Which
 would you prefer : a clamav-daemon package with a dependency on a fake
 libsystemd0, or a clamav-daemon package without any systemd dependency ? If
 you legitimise using shims, then the same people that see no reason to not
 hard-depend on libsystemd0 will bring you a package with a hard-depends on
 fake-libsystemd0.

 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan LTS

[Stephanie Daugherty]

On Fri, Jul 17, 2015 at 1:50 AM James Powell james4...@hotmail.com wrote:

  There is one thing I would recommend different that the standard Debian
 model. Release only the right amount of packages to create a working
 operating system under a complete installation, and dedicate the rest of
 all packages to Debian friendly build scripts for packages of the
 non-sequitur ranks to keep anything and everything optional, as that,
 optional.

 This might help other non-Linux distributions like kfreebsd and killumos
 (Dyson) formulate strategies for packages.

 Any thoughts on this?



This is a model that I've had thoughts about for a while, originally
spurred on by the old Fedora Core/Extras division and refined by Ubuntu's
PPA model - although for different reasons entirely.

What'd I'd be interested in seeing is this:

- A core distribution consisting of the kernel, base system, openssh(d)
and enough of the development toolchain to build packages - and nothing
else - basically a stable set of core libraries, ABI, and userland
utilities that could go untouched for a long period of time.

- A modular system of self-contained repositories with their own much
faster lifecycles for everything else, with an emphasis on encouraging
upstream vendors to provide their own repositories.

The advantages:
-  a leaner core distribution would be maintainable for a longer period
of time
- modular repositories for everything else would keep it from being stale -
a different kind of balance between long term stability and rolling
releases.
- any LTS for each of the modular components could align strictly with the
upstream maintainer's LTS strategy, rather than the distribution's release
schedule, so the distribution would bear much less burden for supporting
these packages and the blame your distribution game would be lessened.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan LTS

[Stephanie Daugherty]

ILTS just doesn't make sense with a release cycle that's already set to be
one of the slowest in the Linux world. Debian, and now Devuan releases are
extremely conservative. N+1 cycles are good enough. The manpower that would
be required to maintain 4, 5, or more more supported released branches is
manpower that could be better spent elsewhere - improving the release
engineering and working through the backlog of bugs.

rant
IMHO the enterprise mindset does more harm than good, because deferring
change creates a vicious cycle, where the accumulated breakage of half a
decade between each release prompts cries for even more time, and more
breakage, meanwhile more dirty hacks and accumulated cruft build up within
that organization's infrastructure, adding to the fragility and
breakage. Meanwhile, developers demand newer libraries, runtimes, and
components for applications - as the solution to any problem from
upstream maintainers is ALWAYS to run the latest stable upstream version
come hell or high water, and the first time that developer tries to use a
feature that's the documentation says is there but's not in the decade-old
version that happens to be available, they demand updates - which then get
compiled from source or installed from packages obtained from god knows
where, along with a slew of dependencies.

A reasonable, conservative release cycle, coupled with the 4 branch
(unstable, testing, stable, oldstable) and a FIRM  n+1 support policy
minimizes the cost of support, sets firm expectations for EOL, and provides
more than enough time to test, qualify, and migrate, while forcing
organizations to address their infrastructure's growing technical debt
while they still have the institutional memory to understand how. If you
can't do this in the 2 years that typically go between releases,  then your
problem is not that the releases are too fast, it's that your organization
is institutionally incompetent.
/rant
On Fri, Jul 17, 2015 at 12:57 AM James Powell james4...@hotmail.com wrote:

  An LTS branch isn't needed if you do version controlled releases and
 sponsor support for versioned releases for at least 3-4 versions back.

 To be fair, I've used Slackware long enough to see how maintaining a
 versioned release can go right, and seen enough of Ubuntu to see how it can
 go horribly wrong.

 Devuan should have at least 3 branches.

 Versioned releases released on annual cycles as packages mature.

 Unstable but tested branch similar to Slackware-Current in which Versioned
 releases are established.

 Experimental branch for new packages that aren't tested or just slightly
 tested for buildability in a working environment that will determine what
 goes into Unstable. This branch should also NOT be part of the mainline
 availability but accessible through a git/svn/cvs client only for safety
 reasons, namely preventing someone from blowing their system to Hell.

 As releases mature, 1.0 would be maintained until the fourth or fifth
 release year following, then pastured, regardless of version number. The
 only time the main number should be changed is IF and ONLY IF glibc is
 updated, otherwise 1.0 would transmigrate to 1.1.

 How does that sound?

 Sent from my Windows Phone
  --
 From: Adam Borowski kilob...@angband.pl
 Sent: ‎7/‎16/‎2015 9:44 PM
 To: dng@lists.dyne.org
 Subject: Re: [DNG] devuan LTS

  On Thu, Jul 16, 2015 at 09:39:41PM -0700, Gregory Nowak wrote:
  the recent discussions here have made me think about what features I
  would like devuan to have which debian doesn't currently have. One
  feature that comes to mind is a long term support branch like what
  ubuntu has.

 Since squeeze, every release has amd64+i386-only long term support.

 --
 ⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
 ⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
 (https://github.com/kilobyte/braillefont for this hack)
 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
  ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng