Re: [DNG] netman packages

[Isaac Dunham]

On Sun, Nov 15, 2015 at 11:02:07AM -0500, Hendrik Boom wrote:
> Except for [...] it all went smoothly until:
> 
> Now signing changes and any dsc files...
>  signfile netman_0.1.1~468c97d-jessie2.dsc Aitor Cuadrado Zubizarreta 
> 
> gpg: skipped "Aitor Cuadrado Zubizarreta ": 
> secret key not available
> gpg: /tmp/debsign.spl1F1J4/netman_0.1.1~468c97d-jessie2.dsc: clearsign 
> failed: secret key not available
> debsign: gpg error occurred!  Aborting
> debuild: fatal error at line 1295:
> running debsign failed
> gbp:error: 'debuild -i -I -tc' failed: it exited with 29

Add "-b" to the dpkg-buildpackage options, IIRC.

It's trying to sign the source package with the key of the author of the
last change. If you're not building it to redistribute after making your
own changes, you don't have a need to build the source package.

> P.S.  The packages I had to install first were:
> 
> pristine-tar
> git-buildpackage
> debhelper quilt libgtk2.0-dev fp-units-gfx-2.6.4 lazarus 
> lazarus-ide-gtk2 lcl-nogui-1.2.4 lcl-utils-1.2.4 lcl-units-1.2.4 
> python-all-dev
> 
> Is there any easy way to install all these without having to wait until 
> it complains they are missing, and then aptitude install them comolaint 
> by complaint?

If it's a source package in an apt repository, it's just "apt-get build-dep";
but this won't help you, so the only shortcut is writing your own script
to parse debian/control (field Build-Depends, IIRC).

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

Re: [DNG] dbus, Was Re: Systemd-free network-manager package

[Isaac Dunham]

On Sat, Nov 14, 2015 at 07:36:08PM +, Rainer Weikusat wrote:
> Mitt Green <mitt_gr...@yahoo.com> writes:
> > Not sure if that was sarcasm though.
> >
> > Anyway, why do we need dbus if we can live
> > without it?
> >
> > I've seen these [1] cool figures explaining what it is
> > but neither them,
> > nor the article didn't give me the answer why it is
> > necessary.
> 
> "Necessary" is a bit of a bad category because anything can be
> implemented in some other way, hence nothing is strictly
> necessary. D-BUS is an OO RPC system intended to enable long-running
> applications to call methods implemented by other long-running
> applications provided these other long-running applications run on the
> same computer.


Your explanation is pretty good.
But there are a very few more details that I thought should be mentioned:

- Regarding 'long-running', it seems worthwhile to mention that D-Bus
is the main *stateful* IPC protocol available.
In other words, it is designed around the concept that you're dealing with
programs that will not be restarted.
This, apparently, makes it simpler to use, since rather than dealing with
failures of the 'remote' process, you can simply ignore them because it's 
irrecoverable anyhow.
This simplicity in use, obviously, makes it a favored API for combination
with the systemd init/service manager/*.

(Anyone who does not see the humor of this probably should either
re-read that or consult the definition of 'service manager'.)

- Regarding 'on the same computer', it's apparently supposed to be
'possible' to set up some method of forwarding over ssh.
I saw references to this being already implemented in one of the threads
Miroslav posted in; but as far as documentation goes, I see only a
two and a half year old page mentioning it as a possible but untested
solution.
(http://www.freedesktop.org/wiki/Software/DBusRemote/)
There's also a third-party program to implement this
(http://gabriel.sf.net/howto.html).

-A caveat is that it's apparently also notorious for being troublesome
when using SSH with X forwarding.

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

Re: [DNG] Systemd-free network-manager package

[Isaac Dunham]

On Sat, Nov 14, 2015 at 11:41:56PM +0100, Didier Kryn wrote:
> Le 14/11/2015 21:20, Brian Nash a écrit :
> >I never did figure out (or remember) how to use wpa_supplicant, although
> >IIRC connecting to a wifi network is just two commands.
> 
> 1) Follow this howto:
> http://www.debuntu.org/how-to-wifi-roaming-with-wpa-supplicant/
> 2) change the config file to set the gid of the control interface and
> make yourself a member of this group,
> 3) then install wpa_gui
> 
> This is a modular set up which involves the traditional ifupdown
> mechanism, and in which wpa_supplicant is running in daemon mode and wpa_gui
> is a graphical config helper for it. If you also want some roaming for
> Ethernet, then you also need ifplugd. wpa_gui is provided upstream together
> with wpa_supplicant, but some people dislike it because it is based on Qt.
> 
> If you prefer to completely bypass ifupdown and /etc/network/interfaces,
> and integrate all in one app, then I understood netman is doing what you
> want; AFAIU, netman is the daemon and it invokes wpa_supplicant in
> non-daemon mode.

wpa_supplicant has no non-daemon mode. When it exits, it deconfigures the
interface.

AFAIU, netman uses ifupdown but bypasses /etc/network/interfaces, writing
its own alternate interfaces files (utilized by spawning 'ifup -i ...').
These files use the "fire-and-forget" mode of the wpa_supplicant ifconfig
plugin (wpa_essid and so forth). 
Actually, I'm not sure exactly how much forgetting ifupdown does.
But I know that this mode is *not* utilising the ability of wpa_supplicant
to handle multiple networks; netman seemed to repeatedly call a helper
in order to do what wpa_supplicant could do, if properly configured.

The developer intends to call wpa_* directly at some point; I hope that
he takes the opportunity to make it use wpa_supplicant's abilities.

> 
> I don't know where wicd is in this plot.

It's a two-part python/dbus interface that runs wpa_supplicant from a
daemon and controls it from a client.

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

Re: [DNG] Systemd-free distros Was Re: Distrowatch

[Isaac Dunham]

On Mon, Nov 02, 2015 at 02:38:13PM -0500, Steve Litt wrote:
> On Mon, 02 Nov 2015 21:57:25 +0300
> Mitt Green <mitt_gr...@yahoo.com> wrote:

> > I think we should count NetBSD here as the folks there
> > try to maintain the philosophy, keeping things simple
> > and minimal. I will write to them about it.
> 
> If you can actually install a functional NetBSD, you're much more
> skilled than I. After about 4 hours playing whack-a-mole with NetBSD
> problems precluding a barely functional machine, I gave up.

It's all about hardware, as far as I could tell.
...and what your definition of functional is...
Seemed fairly simple to install NetBSD 5.x on a PIII with i845 graphics,
using broadcom gigabit ethernet (bge); I tried it because at the time,
almost all Linux distros had support for that GPU broken.

On the other hand, it did not play nice with my Acer Aspire One
(AR5007?? wireless, realtek 810?? ethernet).
> > There is also Alpine which uses BusyBox.
> 
> I didn't know this. Thanks. I'll check it out.

Alpine is musl/busybox/openrc based; it feels like a lightweight knockoff
of Debian.

The developers have not said "we will *NEVER* use systemd", but have
indicated that they do not consider it a good direction for Alpine's
init.
(In addition, systemd uses glibc features incompatible with musl,
the musl maintainer says systemd is broken by design, and the systemd
developers certainly aren't interested in doing any ports.)

> > There is also Puppy/Quirky
> > (http://bkhome.org/news/?viewDetailed=00114).
> 
> The last time I used Puppy it was a different kind of Linux: Not much
> available software: Its claim to fame is it could run in tiny RAM
> situations. But you wouldn't run your business on it.

Puppy?
Not much available software?

It has a program or two for nearly every possible use included, though
they're usually the lightweight ones.
For example: how many distros have an audio editor (mhwaveedit) on the
livecd, along with a spreadsheet (gnumeric), wordprocessor (abiword),
and accounting program (gnucash, homebank)?

However, yes, software off CD is a rather patchy business: there's usually
some way to get "native" packages from the "host" distro if there is one,
and then PPM has a smallish selection of favorites and one-off requests.

Of course, Quirky doesn't have a real 'host' distro; it is (was?) built
from T2, which is a source-based distro not many people have heard of.

HTH,
Isaac Dunham

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

Re: [DNG] Office pack

[Isaac Dunham]

On Mon, Nov 02, 2015 at 01:47:37PM -0500, Steve Litt wrote:
> On Mon, 2 Nov 2015 15:50:27 + (UTC)
> Mitt Green  wrote:
> > I
> > can't be sure about word processor, speaking of numerous AbiWord
> > issues.
> 
> Honestly, if you can run MSWord under Wine, you'll have a better word
> processor than anything Linux has to offer. They all suck.
> 
If you're talking about a Word version that's not 12 years old, I would
respectfully disagree.

As far as what I would use, there are a couple things lighter than LO
and more reliable than Abiword:

* Ted , an RTF editor (on a level with wordpad).
Not in the repositories, but you only need X, the right gui toolkit, and
a few common libraries to build it. GTK+ 2.x or Motif are the currently
available toolkits, as far as I know.
A little minimalist compared to Abiword, also less dependencies.
Edits RTF/text, exports html, epub, ps, pdf.
Last I knew, tended to crash when confronted with large images, but
otherwise quite stable.

* Textmaker, from Softmaker Office (note: commercial product).
Fairly compatible with MS Word.
In my own experience, generally stable and almost always renders right,
though I have seen it crash.
Needs X libs and C++ support, which means it shouldn't be a problem.
Available for Linux and Windows; the Linux port is usually released a
few months to a year behind.
There are older versions available gratis online (IIRC, 2006 was the last
no-key version, while "FreeOffice" 2008 requires you to sign up to get
a key emailed to you; ~weekly email offers follow).
(And when I say "available", I mean "...with the approval of Softmaker".)

> > LibreOffice has too many dependencies, as well as AbiWord, while I'd
> > like to remain minimalistic.
> >
> > What do you use daily and would advise?

I don't do that daily anymore, but I used to write/do basic formatting
in Ted, then the fancy stuff in one of OO/LO Write, MS Word, or TextMaker.

Sometimes I used VDE or MS Word for DOS 5.5 from FreeDOS or dosemu for
preliminary writing; of the two, I'd only recommend vde.

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

Re: [DNG] busybox

[Isaac Dunham]

On Sat, Oct 31, 2015 at 05:30:15PM +0100, Adam Borowski wrote:
> How do you guys like this:?
> http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346

:), though I hadn't heard about it despite being on the Busybox list.
A lot of the people over there are *at least* as opposed to systemd as
the people here.

All that was removed, if you look at it, is socket fd passing for syslogd.

Thanks,
Isaac

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

Re: [DNG] OpenRC: was s6-rc, a s6-based service manager for Unix systems

[Isaac Dunham]

On Tue, Sep 29, 2015 at 11:00:23AM -0400, Steve Litt wrote:
> On Mon, 28 Sep 2015 16:05:22 -0400 (EDT)
> Rob Owens <row...@ptd.net> wrote:
> 
> 
> > This system is supposed to mount several NFS shares
> > on boot, but it always fails -- even when using openrc (which is
> > dependency-based) on Funtoo.  
> 
> Am I the only person who doesn't like OpenRC? It can't respawn
> (supervise, whatever you call it). Its init scripts are every bit as
> complicated as those of sysvinit, but must be written in a special
Huh?

#!/sbin/openrc-run

name="busybox cron"
command="/usr/sbin/crond"
pidfile="/var/run/crond.pid"
command_args="$CRON_OPTS"

depend() {
need localmount
need logger
}

That's cron on my Alpine system; it's configureable in /etc/conf.d/cron.

OpenRC can automatically figure out how to start a daemon based on the
command and so on.
The script author doesn't need to set a series of rather obscure
options in a magic comment block; he just writes
need ...
before ...
after ...

And the system administrator doesn't need to fight to add it to a custom
runlevel, or remove it from a default runlevel.
> language that's confusingly almost but not quite /bin/sh. To be

Not quite /bin/sh?
My research indicates that it basically sets up a custom
environment in a /bin/sh script that sources the one you use:
see /lib/rc/sh/openrc-run.sh for more.

If you're referring to the commands, those don't determine the language:
shell script was designed to be extensible by adding new commands.
And any *good* sysvinit script uses several "commands" that are
really shell functions.

> complete, therefore, it must spawn daemontools-encore or s6 to
> supervise things like dhcpd and wpa_supplicant.
True.
But it does integrate some support for that, rather than requiring
the user to figure it out from scratch. 

> I agree that OpenRC is better than world-dominator systemd and Upstart,
> but I'd choose sysvinit over it. And I'd *certainly* choose Epoch or
> any of the daemontools inspired inits (or even Suckless Init +
> daemontools-encore + LittKit) over it.

Pedantry: OpenRC competes with sysv-rc, not sysvinit.
Some of the daemontools-style stuff are rc systems, some include init.

> OpenRC? I just don't get it.

Simple:
It's POSIX sh like sysv-rc, minus the boilerplate...stuff like
### BEGIN INIT INFO
# Provides:  
# Required-Start: 
# Required-Stop:
# ...
### END INIT INFO

[ -e /etc/default/$NAME ] && . /etc/default/$NAME
...
case "$1" in
  start)
...
;;
  stop)
...
;;
  ...)
;;
  esac

is stripped down to the depends() function and optionally extra_commands="".
It's also *more* obvious, since you use a shell fuction rather than a
magic comment block.
It handles pretty-printing the status for you, but that's just the icing
on the cake:
most of the functionality that's implemented in shell functions calling
several external helpers in sysv-rc is instead handled in a fairly small
multi-call binary.
And it works close enough to sysv-rc overall that it's fairly easy to
make the move...only a lot of the things that were less obvious now have
simple tools.


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

Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems

[Isaac Dunham]

On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote:
> Laurent Bercot <ska-de...@skarnet.org> writes:
> 
> [...]
> 
> > It manages dependencies between services, no matter whether they are
> > oneshots or longruns; it can intertwine oneshot starts and longrun
> > starts, or oneshot stops and longrun stops. When changing the machine
> > state, it always ensures the consistency of the dependency graph.
> 
> I'd still very much like to see an actual example which really needs
> these depenencies which isn't either bogus or a workaround for a bug in
> the software being managed.

Well, let's see:

* cups should be started after avahi if you want zeroconf network printers
  accessible by name (note: X-Start-After or openrc "after" is suitable;
  declaring a dependency is not ideal.)
* routers:
  - you don't want networking stuff up before your firewall
  - hostapd needs to start after the interface is configured
  - the dhcp daemon needs to start after the interface is configured
(after hostapd is best, but after networking may be adequate)
  - the ssh server needs to start after the interface is configured, if
you want to bind to a specific interface
 Alpine example:
 I want SSH on wlan0 (192.168.64.1) only.
 I need to specify "-p 192.168.64.1:22" in /etc/conf.d/dropbear;
 wlan0 must already be 192.168.64.1 for this to work.
* to properly prioritize user-specified drivers, "modules" should run
  before driver autoload.
* an entropy-gathering daemon should start after the device used have
  been initialized, and before the services that need random bytes start.
* anything that uses the syslog should start after the syslog.
  While a failure to connect to /dev/log is recoverable, proper ordering
  will greatly simplify debugging.


Now, regarding "as long as it's working in five minutes, the users will
forget about it."
I can only speak for myself and my family, but five minutes is far too
long for me:
I can boot to a desktop with a usable internet connection in ~20 seconds
(the first 12 or so being BIOS+GRUB), and I'm annoyed if I can't start
mutt immediately without any problems.
For my parents, if the computer can't connect in the first two minutes,
they might never find out that it actually does connect.
And on a router, a minute is too long.

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

Re: [DNG] libpam-xdg-support / libpam-systemd

[Isaac Dunham]

On Sat, Sep 12, 2015 at 10:32:13PM +0200, tilt! wrote:
> Hi,
> 
> On 09/12/2015 12:52 PM, tilt! wrote:
> > [...]
> > I will think about this a bit more, but currently it converges
> > towards a SUID helper and a separately configured directory for
> > refcounts.
> 
> Here's my shot at it:
> 
>https://git.devuan.org/tilt/xdg-compat

$ git clone  https://git.devuan.org/tilt/xdg-compat
Cloning into 'xdg-compat'...
fatal: repository 'https://git.devuan.org/tilt/xdg-compat/' not found
newbook:~/src$ git clone  git://git.devuan.org/tilt/xdg-compat
Cloning into 'xdg-compat'...
fatal: unable to connect to git.devuan.org:
git.devuan.org[0: 78.26.97.141]: errno=Operation timed out

And a web browser redirects to a login page.
Similar with the git url.

 

> I would appreciate your opinions on it, and of course i will
> include a list of contributors soon; i just would not like
> to imply an endorsement while you actually think it sucks. ;-)

Thanks. ;-)

One detail I'm not sure if you implemented:
I suggested that default be to create .../$UID if needed, but you can pass
"-n" to create a new session.

Thanks,
Isaac Dunham

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

Re: [DNG] xf86-input-evdev

[Isaac Dunham]

On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
> On arch linux xf86-input-evdev is reported to have a dependency on systemd.
> 
> I thought the dependency is on udev and that is usually reported on arch
> like
> systemd(udev).
> 
> I downloaded xf86-input-evdev for recompilation but could not find any
> switches
> to compile without systemd though some evidence pointing at a udev
> dependency was there.
> 
> Does anyone know?

Long explanation here.

xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's
hotplug support, which depends on libudev (or an API-compatible replacement
such as libudev-compat or libeudev...); at least in theory, you can also
use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.

So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs 
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a device
path instead of anything pointing into sysfs.

This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the 
corresponding link in /sys/dev/ - this would be the string returned by:
sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.

However, most people prefer to avoid depending on the sysfs layout even
where its behavior is documented; libudev provides a thin veneer to hide
it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do
this.
There is no dependency on udev being running.

I've redone that function without udev but using my own library libsysdev,
which I mentioned earlier this summer.
Repositories that you'd need to build that:

-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)

But that does require something that has no Debian packaging yet.

There are also two other options:
- comment out that function and disable device hotplug in Xorg.conf or
xorg.conf.d
- replace the function with one that does all the work itself.

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

Re: [DNG] wpa_supplicant/ifup integration documentation

[Isaac Dunham]

On Mon, Aug 31, 2015 at 09:38:12AM +0200, Didier Kryn wrote:
> Sorry, this thread became private my my mis-clicking on Icedove.
> 
> Le 30/08/2015 22:37, Isaac Dunham a écrit :
> >On Sun, Aug 30, 2015 at 12:58:59PM +0200, Didier Kryn wrote:
> >>Le 28/08/2015 04:28, Isaac Dunham a ??crit :
> >>>I could make something similar to wpa_config but using wpa_cli more
> >>>rather than writing a config file; *however*, this would be harder to
> >>>edit and would lose comments if you make the changes permanent.
> >> wpa_gui works by interaction with wpa_supplicant, through the control
> >>socket, I guess, and the changes can be made permanent.
> >>Actually I am perfectly happy with wpa_gui; it is just perfect; I don't need
> >>anything else on my laptop. But some people consider that Qt is too big, and
> >>I agree that a lighter version with the same functionality is always a
> >>progress. Also a version working without X windows, but still GUI-like (ie
> >>ncurses), could be usefull.
>
> >wpa_gui works through the control socket, as does wpa_cli.
>
> >If you "make the changes permanent", you send a command over the control
> >socket that writes out the in-memory config.
> >Comments are not part of that in-memory config, so you will lose them.
>
> >dialog is an ncurses-based tool for the "GUI-like" interface you mentioned.
> 
> So the only thing which this UI would miss is that it couldn't put
> comments in the config file. I agree that most ESSIDs have no meaning and
> therefore motivate a description. This is a minor problem which no UI
> currently addresses. I don't think a comment is the proper method to do
> that. Comments are meant for humans who read the file, not for use by
> applications. What is missing is a formal field which could be called
> 'description' and should be managed by wpa_supplicant.
> 
> To summarize, I see three possibilities
> 
> 1) hack wpa_supplicant.conf from the UI to put a specially formatted
> comment. Very bad for the reason explained above and because it needs root
> permission and incurs race conditions with wpa_supplicant itself.
> 2) put the load on the user: let him choose or ask for sensible ESSIDs.
> 3) patch wpa_supplicant so that it accepts and stores a description
> phrase for every ESSID.
> 
> Things could be staged: 2, then 3. And 3 might be just a request to the
> author of wpa_supplicant. What do you think?

I'm *not* saying that I'd like to be able to *write* comments.
In fact, I don't want to write any comments that aren't important for the
person who edits wpa_supplicant.conf manually, and wpa_config currently
doesn't write any comments except the ones wpa_passphrase makes.

I simply would like to write to the file without *losing* all the comments
that are there, which is what will happen if you use
 wpa_cli save_config
or similar features in wpa_gui.

The only race in adding a network is when you (a) start wpa_supplicant,
(b) invoke "wpa_cli reconfigure", or (c) use a respawner and have
wpa_supplicant randomly crashing, in the midst of writing a new network
entry to the config.
Writing a new entry to a temp file, then appending it to the config,
then reloading, is the most reliable approach, because you can fail much
harder by using wpa_cli add_network/set_network/enable/save_config:
suppose that wpa_supplicant starts after you start adding a network or
crashes/restarts in the midst of it.

Finally, there's one fundamental flaw in wpa_gui, which actually was the
initial motive for wpa_config:
it's rather exasperating to have a tool to configure a program that won't
work until the program is properly configured.
The people who most need a tool for configuring wpa_supplicant are those
who cannot configure it themselves.
This means that wpa_config needs to write out a basic wpa_supplicant.conf
itself on request.

I think wpa_id_str is adequate as far as a "description phrase",
apart from the fact that you don't want it to be invalid for a logical
interface.

Hope this helps clarify things.

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

Re: [DNG] docker/virtualization (was: The show goes on...)

[Isaac Dunham]

On Sun, Aug 30, 2015 at 09:11:01PM -0500, Nate Bargmann wrote:
 And all along I thought a dock had to do with a place to put program
 icons on a desktop and that docker was a tool to handle it.  I've
 ignored everything about virtual machines except for Virtual Box and
 QEMU.
 
 Evidently, I now have to know that a container is a virtual machine.
 Or is it?  Seems like more buzz words for buzz words sake.

Not quite, though close.
There are several levels of virtualization:
-chroots (a different /, but same resources)
-containers (different resources, same kernel handling them; built on
 namespaces, so one kernel can have programs with different network,
 cpu, filesystem, and other resources)
-hypervisors (different kernel, but relying on shims to use host OS
 drivers: Xen and KVM can fall here)
-virtual machines (OS runs on virtual hardware, but most instructions
 get executed directly on the processor; Virtual Box, Virtual PC, some
 Xen/KVM deployments, and Qemu+kqemu fall here)
-emulators (every instruction is emulated; Qemu, various arcade emulators,
 and so on fall here)

The difference is that a container is a set of programs on the same
kernel, but with all their resources restricted to a subset of what the
real hardware has.

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

Re: [DNG] strange characters when using 'examine' in aptitude

[Isaac Dunham]

On Sat, Aug 29, 2015 at 03:01:26PM +0100, Dave Turner wrote:
 On 29/08/15 01:37, Isaac Dunham wrote:
 On Fri, Aug 28, 2015 at 08:45:51AM +0100, Dave Turner wrote:
 I run devuan unstable 'ceres' on my Toshiba laptop and my iMac.
 It all works with just a bit of weirdness.
 I use apt-get update  apt-get upgrade and then use aptitude to fix those
 upgrades that get held back for various reasons.
 Whenever I highlight one of the held back packages and press 'e' to examine
 the various possibilities the names of the packages to be removed or
 installed are mangled with block characters and/or assorted characters from
 other non-Latin1 character sets. Upside down question marks etc.
 
 Any ideas what is going on?

 What's your terminal?
 Are ncurses-term and ncurses-base installed?
 What does this command output:
   env |grep -e TERM -e LC -e LANG -e LOCALE
 
 I ask these because I'm *guessing* that it's one of the following:
 -you don't have TERM pointing to an installed  correct termcap/terminfo
 database
 -your localization is screwy
 -you have the wrong fonts (not likely unless it's a plain xlib terminal)

 ncurses-term and ncurses-base are installed.
 the output of
 
  env |grep -e TERM -e LC -e LANG -e LOCALE
 
 TERM=xterm
 LANG=en_GB.UTF-8
 LANGUAGE=en_GB:en
 COLORTERM=xfce4-terminal

Maybe try running aptitude with TERM=xfce and COLORTERM=xfce or go
ls /usr/share/terminfo/x/xfce4-terminal?
(Here, terminfo only has xfce.)

Check that you're using a UTF8 font?

These are my bestt guesses; if they don't work, I'd be stumped.

HTH,
Isaac

PS:
A: Because it messes up the reading order.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

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

Re: [DNG] The show goes on: ???su??? command replacement merged into systemd on Fedora Rawhide

[Isaac Dunham]

On Sun, Aug 30, 2015 at 02:20:41AM +0200, Laurent Bercot wrote:
 [snip] Alpine Linux, for instance, makes Docker
 containers a breeze to use, and makes the images a lot smaller.
  Alpine is runit-based, and people have also found success running Docker
 containers under s6; systemd is very unnecessary, and anyone pretending
 it is is either ignorant or malicious.

Correction for this:
Alpine Linux is OpenRC based.
There is some level of runit integration, but I'm pretty sure it's not
the base of the primary rc system (unless they did some *big* changes
with no discussion on either list over the last couple weeks).

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

Re: [DNG] strange characters when using 'examine' in aptitude

[Isaac Dunham]

On Fri, Aug 28, 2015 at 08:45:51AM +0100, Dave Turner wrote:
 I run devuan unstable 'ceres' on my Toshiba laptop and my iMac.
 It all works with just a bit of weirdness.
 I use apt-get update  apt-get upgrade and then use aptitude to fix those
 upgrades that get held back for various reasons.
 Whenever I highlight one of the held back packages and press 'e' to examine
 the various possibilities the names of the packages to be removed or
 installed are mangled with block characters and/or assorted characters from
 other non-Latin1 character sets. Upside down question marks etc.
 
 Any ideas what is going on?
 
 I am using the slim login manager and then depending on my mood fluxbox,
 xfce, or lumina - the new desktop from pc-bsd.

What's your terminal?
Are ncurses-term and ncurses-base installed?
What does this command output:
 env |grep -e TERM -e LC -e LANG -e LOCALE

I ask these because I'm *guessing* that it's one of the following:
-you don't have TERM pointing to an installed  correct termcap/terminfo
database
-your localization is screwy
-you have the wrong fonts (not likely unless it's a plain xlib terminal)


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

Re: [DNG] wpa_supplicant/ifup integration documentation

[Isaac Dunham]

On Thu, Aug 27, 2015 at 10:29:31AM +0200, Didier Kryn wrote:
 Le 25/08/2015 03:40, Isaac Dunham a ??crit :
 For your perusal, here's an overview of how they work together; it's a 100+
 line summary.
 If anyone wants more details, here are some sources:
 Manual pages:
 interfaces(5), wpa_supplicant.conf(5), wpa_supplicant(8), wpa_cli(8),
 wpa_action(8).
 Scripts:
 /sbin/wpa_action
 /etc/network/if-*.d/wpasupplicant
 /etc/wpa_supplicant/*.sh
 (/etc/wpa_supplicant/functions.sh is going to be needed if you want a
 low-level understanding of what's going on; the script authors have an
 exceptional capacity for indirection.)

 You will need to read the scripts for a practical understanding of how
 it works, but the interfaces, wpa_cli, and wpa_action manpages are rather
 helpful for understanding the glue.
 
 Thanks, Isaac, I had made my best to RTFM :-) but what I couldn't find
 is how the line wpa_roam ... is passed to the script.

Did you look at the summary I attached?

 Here is the idea I got from looking at the scripts. Any line following
 the iface line is interpreted by ifup in the following way before invoking
 all the scripts:
 
 The first token in the line is capitallized and prefixed with IF_,
 then, an environment variable with this name is created and its  value is
 the rest of the line. Each line following the iface line is treated like
 this and all the scripts can then check the enviroment variables. This is

Correct.
man 5 interfaces, IFACE OPTIONS (just over INET ADDRESS FAMILY):
   Additionally,  all  options given in an interface definition stanza are
   exported to the environment in upper case with IF_ prepended and with
   hyphens  converted  to underscores and non-alphanumeric characters dis-
   carded.

 not the whole story though, since I remember it is also possible to put
 command lines -- I did it a few years ago to configure bonding interfaces.

In man 5 interfaces, IFACE OPTIONS, at the top, see the descriptions of
pre-up, up, post-up, pre-down, down, and post-down options.

These, as well as scripts in /etc/network/if-*.d, are run directly by ifup.

 Therefore, asserting all this is still on my todo list, and maybe the
 only way is to look at the source of ifup, althoug I would have preferred a
 more authoritative description. For now, my feeling is still that it makes
 little sense to set up a parallel framework when what is missing is only a
 tinier version of wpa_gui, and maybe first a curses version.

wpa_config is supposed to be that curses version, though I'm sure it's
a long way off.
I could make something similar to wpa_config but using wpa_cli more
rather than writing a config file; *however*, this would be harder to
edit and would lose comments if you make the changes permanent.

Anyhow, ifup/wpa_supplicant integration features two paths:
-roaming/user-specified config file, as shown in wpa_action(8)
 Here, you have two files: interfaces and wpa_supplicant.conf
 wpa_config (but not the rest of wpanet) works with this method,
 and might eventually be enhanced for static configuration via this
 method.

-configuration in /etc/network/interfaces
 Here, you specify
...
wpa-ssid mynetwork
wpa-psk  topsecret
 in the configuration for a logical interface.
 Presumably, one *could* parse 
 iwlist IFACE scanning
 in a mapping script, though it's a brittle approach.

Edward and tilt! seem to be working on a tool that simply writes
a new interfaces file for the second approach.
wpanet is a knockoff of the first, originally intended for Busybox-based
systems.

HTH,
Isaac Dunham

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

Re: [DNG] netman GIT project

[Isaac Dunham]

On Wed, Aug 26, 2015 at 02:27:57PM +0200, tilt! wrote:
 On 08/26/2015 01:36 PM, Irrwahn wrote:
 [...]
 Or, even better, you could easily pass the IF name as an additional
 parameter to the backend (and possily even use it as additional component
 to construct the interface file names).
 
 An easy way to obtain a list of interface names on Linux is:
 
 awk 'NR2{gsub(/:/,);print $1}' /proc/net/dev

Or ls /sys/class/net.
For listing non-loopback devices only, use 
ls -d /sys/class/net/*/device | cut -d/ -f5

For wireless, check for the files phy80211 or wireless.

The equivalent can be done trivially in C with readdir(); ask if you'd like
an example.

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

Re: [DNG] netman GIT project

[Isaac Dunham]

On Tue, Aug 25, 2015 at 10:35:21PM +0200, Irrwahn wrote:
 On Tue, 25 Aug 2015 21:16:08 +0100, Edward Bartolo wrote:
  The contents of interfaces files created by backend are as follows,
  but if necessary, we can create more than more template, although it
  doesn't look it will be necessary.
 
  Interfaces File Contents:
 
  auto lo
  iface lo inet loopback
 
  iface wlan0 inet dhcp
  wpa-ssid EB-TP-LNK67
  wpa-psk 
 
 snip
 
 And that's exactly crunchpoint: How is the wpa-ssid line 
 processed by ifup, and does it accept the Pxyz\x0Ablah 
 syntax used by wpa-supplicant?

It is exported as IF_WPA_SSID in the environment passed to
/etc/network/if-*.d/*.
/etc/network/if-*.d/wpasupplicant sources a file that sources
/etc/wpa_supplicant/functions.sh, which runs quoted strings through
echo/sed, then passes the value of IF_WPA_SSID as an argument to
wpa_cli_do, which is a shell function that calls wpa_cli.
I have no idea whether the \ escapes hold up to all that, but as long as
you have them adequately escaped, they do not need a different format for
quoting.

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

[DNG] wpa_supplicant/ifup integration documentation

[Isaac Dunham]

On Thu, Aug 20, 2015 at 10:28:45PM +0200, Didier Kryn wrote:
 I would also like to know what your understanding is of how the things
 are handled by the cooperative interaction of ifup, ifdown and
 wpa_supplicant. This is something for which I cannot find a comprehensive
 description, and I think a full understanding is necessary *prior* to
 endeavour what you are doing. This is because these 3 tools are doing a lot
 of things, and rather well and it is
 a waste of time and talent to re-invent the wheel.


As I understand, he's writing a UI to configure /etc/network/interfaces
to use the wpa_supplicant plugin.

For your perusal, here's an overview of how they work together; it's a 100+
line summary.
If anyone wants more details, here are some sources:
Manual pages:
interfaces(5), wpa_supplicant.conf(5), wpa_supplicant(8), wpa_cli(8),
wpa_action(8).
Scripts:
/sbin/wpa_action
/etc/network/if-*.d/wpasupplicant
/etc/wpa_supplicant/*.sh
(/etc/wpa_supplicant/functions.sh is going to be needed if you want a
low-level understanding of what's going on; the script authors have an
exceptional capacity for indirection.)

You will need to read the scripts for a practical understanding of how
it works, but the interfaces, wpa_cli, and wpa_action manpages are rather
helpful for understanding the glue.

Thanks for pointing me in the right direction, Didier!

HTH,
Isaac Dunham
wpa_supplicant and ifup integration

ifup is a one-shot command for bringing up interfaces, oriented towards
wired connections; it converts a stanza of options to a series of
commands that will configure an interface.
It's the standard way to configure the IP address/routing of an interface,
and is configured by /etc/network/interfaces (though another configuration
can be specified via the -i option).

wpa_supplicant is a daemon for negotiating connections with wireless
networks. It's configured via a user-specified config file, traditionally
/etc/wpa_supplicant/wpa_supplicant.conf, or commands passed via unix
sockets. It can notify other programs about changes in connection state,
but has no built-in way of configuring IP addresses, routing, or commands
to run.
wpa_cli is a tool that sends commands to wpa_supplicant via unix sockets,
as well as listening for notifications from wpa_supplicant. It can run
user-specified programs on connection state changes.

Fortunately, ifup supports plugins.
These plugins are scripts living in /etc/network/if-{up,down}.d/ (I'm not sure
if the scripts in /etc/network/if-{pre,post}-{up,down}.d/ should be called
plugins or not), which are invoked at interface configuration time with
no arguments but a rather large environment determined by the appropriate
stanza in /etc/network/interfaces.
Some of the relevant variables:
IFACE   The current physical interface
MODEstart or stop
PHASE   pre/post up/down
LOGICAL the current logical interface
IF_*(set from option names: [-a-z] becomes [_A-Z], all characters
except [_A-Z0-9] discarded, IF_ prepended).
IF_WPA_*(set from wpa-* options in the current stanza)

Some of these plugins allow configuration of wireless networks via iwtools
and wpa_supplicant.
To use wpa_supplicant from ifup, you will use the wpa_supplicant plugin.
On non-Debian-based systems, you may need to install this manually.


Example:
# ifup wlan0=home
# interfaces:
iface home inet dhcp
hostname somewhere
wpa-ssid ESSID
wpa-psk topsecret

iface public inet dhcp
wpa-ssid any


That allows multiple networks to be used, but not transparently.
For that, you need wpa_supplicant roaming:
#auto wlan0
iface wlan0 inet dhcp
hostname somewhere


wpa.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
ssid=ESSID
#psk=topsecret
psk=bfd06f8718e250cd256c8f31344229067c4f58dc86104d4145ba0ae753c19a1b
}
network={
ssid=any
key_mgmt=NONE
}

At this point you might wonder how to automatically run the DHCP
client when you connect, rather than when you set the interface up.
This actually happens, but there's a bit more behind the scenes.
When wpa_supplicant runs, ifup also runs something like:
 wpa_cli -i physical interface -a action script
This action script can run the DHCP client on demand.
A simple example:
case $2 in
CONNECTED) udhcpc -i $1 ;;
DISCONNECTED) killall udhcpc ;;
esac


Now, how do you get wpa_supplicant to configure connections to two different
networks differently?
This is where ifup integration the opposite way comes in handy.

First, what it looks like:
#wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
id_str=priv
ssid=ESSID
#psk=topsecret
psk=bfd06f8718e250cd256c8f31344229067c4f58dc86104d4145ba0ae753c19a1b
}
network={
ssid=any
key_mgmt=NONE
}

#/etc/network/interfaces:
iface default inet dhcp
hostname somewhere

iface priv inet static

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Isaac Dunham]

On Sun, Aug 16, 2015 at 12:07:45PM -0400, Haines Brown wrote:
snip
 When I startx, I'm still in vesa (?) mode. The Xorg log file says it
 is using configuration directory /etc/X11/xorg.conf.d/ directory. The
 only error is: 
 
 (EE) NOUVEAU(0): [COPY] failed to allocate class
 
 don't know what this means, and the Xorg wiki site no help.
 
 I did a # Xorg -configure to create a /root/xorg.conf.new. It has
 
   Section Device
 Identifier Card(0)
 Driver nouveau
   EndSection
 
 When I do # X -config /root/xconf.new, I'm taken to a blank screen and
 I'm hung there and so have to delete the xorg.conf.new file and do a hot
 reboot.


That blank screen is probably a sign of a successful X; try adding 
-retro to the options, and see if you see a root weave.

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

Re: [DNG] Wireless configuration tools (was: Re: Systemd Shims)

[Isaac Dunham]

On Sun, Aug 16, 2015 at 09:53:39PM +0200, shraptor wrote:
 
 Long story short: it's limited, somewhat odd in interface, and nearly
 undocumented.
 But if you've configured wpa_supplicant to start, or need to write an
 initial config file, it should be adequate if you can follow the UI.
 I tried to make the UI as obvious as possible, but I'm the only user
 I'm aware of, so no promises ;-).
 
 
 What do you mean by limited? limited by scarce documentation?
 limited in user-friendliness?

Features (and user-friendliness, to a lesser degree).
It only supports adding open/WEP/WPA networks, viewing available 
networks (4 scan in the main menu), and disconnect/reassociate.
If you want to add and use a new network, you will need to manually
reassociate.
There is no way to configure how you get an IP address/how routing and
DNS is set up in wpa_config; wpa_dhcp provides these in theory, but
there are some major caveats (see my next comment).

 Well I am thinking of trying it.
 
 It depends on udhcpc and ifup/ifdown
 Are these provided by busybox?

Yes.
Only wpa_dhcp requires these; on a Debian system, I'd suggest replacing
this script with wpa_action, since there's not any functional support for
different networks with different networking configs (you get either 
DHCP everywhere, or--if you configure it--the same static IP and routing
everywhere; I only use DHCP).
If you use wpa_action on a Busybox system, you'll need to port it
to use udhcpc.

 Are there other dependencies except wpa-supplicant, wpa-cli

For wpa_config, the part you're probably most interested in, you need
- a POSIX shell
- (POSIX) cat grep echo test true mktemp
- awk, for the scan feature (tested with busybox awk and mawk; gawk and
the one true awk should also work)
- wpa_supplicant and wpa_cli, of course
- dialog or an adequate clone (also tested with whiptail, xdialog may work).

On a minimal busybox system, you can build ncurses, dialog, and 
wpa_supplicant. Contrary to the whiptail documentation, it uses
significantly *more* disk space than dialog, unless you don't use 
ncurses at all and already use newt.

 Does it require something like OpenRC or would it work with
 busybox init?

OpenRC is a set of utilities and scripts that can be run atop sysvinit
or busybox init. I've only used it with Busybox init.

etc/init.d/wpanet requires OpenRC; however, there's a messier but
functionally roughly equivalent version in sbin/wpanet, autogenerated from
it by means of a partial OpenRC compatability library.
This version is lacking the LSB initscript headers, but should be usable
via the standard sysv-rc interface (/etc/init.d/wpanet start/stop/...).

For a pocket Linux, I'd suggest ditching the init scripts and adding
the relevant stuff to your rc script.

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

[DNG] Wireless configuration tools (was: Re: Systemd Shims)

[Isaac Dunham]

On Sat, Aug 15, 2015 at 06:19:23PM -0400, Steve Litt wrote:
 
 
 On Sun, 16 Aug 2015 00:08:11 +0200
 shraptor shrap...@bahnhof.se wrote:
  I would be interested in
  
  * No-dbus replacement for NetworkManager/Wicd
  
  Are you thinking a C program?
 
 HECK no! There's no requirement for this program to be fast, and I want
 to make it easy on myself. Python probably, with the minimum Python
 addons, and only addons that ship with Python itself.
 
 If people really hate the Python dependency (I thought almost everyone
 installs Python anyway), perhaps I could make it out of shellscripts,
 awk and the like.

  
  daemon and user interface/GUI separation?
 
 I'm not sure whether an actual daemon would be needed, but either way,
 the user interface would be a separate program from the thing that
 reveals the wifi transmitters, deals with wpa-supplicant and iwlist,
 etc. I'd probably make one curses interface, and one GUI. I *might*
 even do them with dialog and zenity.
 
 But I'd need *a lot* more people wanting it to do it. The way Devuan
 does Wicd right now means making this program isn't personally urgent.

I've written something along these lines myself about a year ago.

It's wpa_config, a shell script for wireless configuration.
Mostly, it modifies the wpa_supplicant configuration directly.

For a backend, it uses wpa_cli; for a frontend, it uses dialog or clones
that are adequately compatible (whiptail or Xdialog, though the latter
isn't really maintained at present).

It was actually written to accompany an init script that would launch
wpa_supplicant and handle DHCP properly, while not making the init scripts
hang waiting for wireless; the (limited) documentation all explains how to
use the init script, rather than how to use the configuration tool.
Contrary to what one might infer from the notes, wpa_config should work
with any way of starting wpa_supplicant with /var/run/wpa_supplicant/
as the control-interface directory.

Long story short: it's limited, somewhat odd in interface, and nearly
undocumented.
But if you've configured wpa_supplicant to start, or need to write an
initial config file, it should be adequate if you can follow the UI.
I tried to make the UI as obvious as possible, but I'm the only user
I'm aware of, so no promises ;-).

The full git tree is at:
 https://github.com/idunham/wpanet

The script in question is:
 https://github.com/idunham/wpanet/blob/master/tools/wpa_config


HTH,
Isaac Dunham

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

Re: [DNG] Alpha2 without desktop environment

[Isaac Dunham]

On Sat, Aug 15, 2015 at 11:54:06AM -0400, Steve Litt wrote:
 On Fri, 14 Aug 2015 22:25:06 -0700
 Isaac Dunham ibid...@gmail.com wrote:
 
  On Fri, Aug 14, 2015 at 07:01:11AM -0400, Haines Brown wrote:
   The aim is to boot to a console prompt, log in as root, install
   xorg and fluxbox. That gives me X and a window manager but no
   desktop environment. At present I get a log in prompt and can log
   in as user in console, but for some reason root log in not working.
   I suppose that when I provided a password I mistyped. 
  
  At the grub menu, edit the kernel commandline to change
  root=... ro ... to root=... rw ... init=/bin/bash
  
  Then run passwd, sync a couple times, and reboot.
  
  HTH,
  Isaac Dunham
 
 Why change ro to rw?

root=/dev/sda6 ro means that when initrd (or the kernel) mounts
/dev/sda6, it mounts it read-only (ro).
Then the initscripts run fsck, and remount '/' as read-write (rw).

So if you don't change it to rw, you will need to manually remount
/ so that it's writeable; I think this would be one way to do so:
 mount -o remount,rw /

HTH,
Isaac Dunham

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

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Isaac Dunham]

On Sat, Aug 15, 2015 at 07:43:04AM -0400, Haines Brown wrote:
 I reiinstalled (avoiding past missteps), to a console, and from it
 installed xorg and fluxbox. I then ran xstart from console and all went
 well.
 
 With one exception. I'm in what looks like VGA mode with large crude
 characters. It seems a problem (or symptom) is that installation did not
 create a /etc/X11/xorg.conf.d/ directory that should holding, I
 presume, a 20-nvidia.conf file. I created them by hand, but startx
 failed with error in log to effect that there is no server section.
 I suspect this is not the file that should have a Server section.
 
 I purged and reinstalled xorg without luck. Installed were libglu1-mesa,
 x11-apps, x11-session-utils, x11-server-utils, xinit, xorg,
 xorg-docs-core.
 
 The xorg log tells me that it is using as system configuration
 directory, /usr/share/X11/xorg.c. Because this file does not exist, the
 log complains about missing layout, screen and monitor definitions. It
 seems xorg is using defaults. 

Xorg looks in /etc/X11/xorg.conf.d/, then /usr/share/X11/xorg.conf.d/.
If you would rather use a single-file xorg.conf, you can create it via
Xorg -configure (IIRC).

But besides that, I'm wondering about a couple things.
1: You refer to 20-nvidia.conf. I'd assume that this would come from
the nvidia driver, which I see no reference to in your list of packages.

2: You refer to /usr/share/X11/xorg.c. Is this a typo/abbreviation,
or is Xorg misconfigured?


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

Re: [DNG] Alpha2 without desktop environment

[Isaac Dunham]

On Fri, Aug 14, 2015 at 07:01:11AM -0400, Haines Brown wrote:
 The aim is to boot to a console prompt, log in as root, install xorg and
 fluxbox. That gives me X and a window manager but no desktop
 environment. At present I get a log in prompt and can log in as user in
 console, but for some reason root log in not working. I suppose that
 when I provided a password I mistyped. 

At the grub menu, edit the kernel commandline to change
root=... ro ... to root=... rw ... init=/bin/bash

Then run passwd, sync a couple times, and reboot.

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

Re: [DNG] Devuan compared to AntiX

[Isaac Dunham]

On Sun, Aug 09, 2015 at 01:43:36AM -0400, Steve Litt wrote:
 On Sat, 8 Aug 2015 22:10:13 -0700
 Isaac Dunham ibid...@gmail.com wrote:
 
  Try Alpine Linux (alpinelinux.org).
  Install docs are here:
  http://wiki.alpinelinux.org/wiki/Installation
 
 [snip]
 
  
  -init is Busybox init, with OpenRC on top.
 
 Fascinating! The Busybox PID1 with the OpenRC process adminstration is
 enough to make me install it. I'd love to learn Busybox init.

It's pretty much the same as sysvinit, with a few small differences:
-sysvinit inittab uses the format:
id:runlevel:action:process
Busybox init uses the format:
[tty]:[ignored]:action:process

So to start getty on tty1, use
tty1::respawn:/sbin/getty 38400 tty1

If there's no tty desired, remove the first field.

-Additionally, runlevels aren't supported by Busybox init.
OpenRC provides its own runlevels, with non-numeric names; these are no
longer built on sysvinit runlevels.

-(internal details) Busybox init doesn't use utmp for runlevels, nor does
it use /dev/initctl.
The only way of communicating with it is modifying inittab or signalling;
it knows at least these signals:
HUP reload inittab
INT ctrl-alt-del pressed
QUITreexec self
USR1halt
USR2poweroff
TERMreboot

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

Re: [DNG] non-systemd Linux for newbies with good migration tool?

[Isaac Dunham]

On Sun, Aug 09, 2015 at 09:44:11PM -0400, Steve Litt wrote:
 On Sun, 9 Aug 2015 18:14:10 -0700
 Isaac Dunham ibid...@gmail.com wrote:
 
  Hello,
  I'm looking for a Linux distro that I could recommend to friends who
  are rather frustrated with Windows 10.
  The friends in question ask me about how to fix problems with their
  computers from time to time.
  
  The essentials would be:
  -has a *good* Windows migration assistant, which must be able to
  handle Windows 10; I know that Ubuntu used to have this.
 
 Could you describe this further? I don't know what you mean.

My memory is getting a little hazy, since it was about 7 years ago
that I saw this.
Back somewhere around the Ubuntu 8.04 timeframe, my brother had a
Windows (XP? Vista?) install on his laptop, and installed Ubuntu.

The installer detected the Windows install, asked Do you want to
migrate a user account from this?, gave a menu to choose which user
accounts to migrate, and set it up so that the documents, pictures,
videos, and so forth were in the standard places in the home directory.
(It also managed to set the password to match Windows, if I'm recalling
correctly. Yes, I know that requires Windows storing the password in
a pretty weak form.)

  -glibc-based, so that Flash and Avast Workstation will work
   (at least one of the friends in question uses avast on Windows)
 I think all the majors and semi-majors have glibc, although some might
 also have musl.

Alpine Linux, which I use, is musl-based (though it's semi-major at best).

  -has Chromium (and preferably Chrome)
 I think all of them have that.
 
 
  -has Open/LibreOffice (one of the friends in question has used
  OpenOffice on Windows since...7 or 8 years ago, I think)
 I think all of them have that.

I'd seen something about Slackware being an exception.

  -DE familiar to Windows users (if Trinity were more active, I'd go
  with that without hesitation; but I suspect properly configured Xfce
  or Mate may be better at this point.)
 I'd highly recommend LXDE. It looks and acts just like w95, w98, wXT,
 and somewhat similar to W7. Xfce can also look the same way, if it's
 set up to do so.

At least one of the friends in question has expressed a fondness for
eye candy; additionally, I'd been concerned about the menu (Windows
2k and older, and the old classic interface, have a plain menu with
no side menu; but Windows 7, which was the last version either of them
was happy with, has a double-column menu with a search box.)

LXDE is close to the classic interface, but so is IceWM (my own first
pick for window manager.)

  -can install to hard drive, though support for Live CD is desired.
 I think most or all of them are like that.

Puppy Linux isn't very good in that regard, hence the specification.

[snip a recommendation of Devuan]

 If you'd like an easy time maintaining your Windows refugee friends,
 I'd highly recommend installing LXDE. Most reliable window manager I've
 seen that isn't just a black screen you click on. Relatively low
 resource usage.
 
 By the way, there could be some other distros that fulfill all your
 preferences: I just don't know about them. Distros are switching to
 systemd so fast it's hard to keep track of who's still not evil, so
 I've familiarized myself with a bunch that have actively stated their
 independence from systemd.

Thank you.

Also, as far as this goes, I'd be open to using Debian Jessie with init
switched; while *I* don't want to have libsystemd present, I understand
that most packages that link to it currently will run without systemd.

Thanks again,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init scripts in packages

[Isaac Dunham]

On Sat, Aug 08, 2015 at 09:43:47AM +0200, Laurent Bercot wrote:
 On 08/08/2015 03:43, Isaac Dunham wrote:
 Which, fortunately, is pretty easy to do: I wrote an environment
 sanitizer yesterday, because I was curious how easily solved that is.
 Usage is
 cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]
 
  Would you mind linking it ? I'm interested in trying to break it. ;)

Not a problem, now that it's online.
Here's the command:
https://github.com/idunham/bits/raw/master/cautenv.c
Repository:
https://github.com/idunham/bits

CC0, so do what you wish with it.
The rest of that repository is also CC0, but almost all of it is only
useful for someone who wants an example of using some less-frequently
seen functions.

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

Re: [DNG] Init scripts in packages

[Isaac Dunham]

On Thu, Aug 06, 2015 at 05:14:28PM +0200, Laurent Bercot wrote:
 On 06/08/2015 16:31, Isaac Dunham wrote:
 If differences in environment can cause problems, it's a problem with
 design. A program that changes what it does just due to differences
 between the init environment and a login environment is going to be
 hard to debug.
 
  There are tons of those, and you can't fix them all. Stupid example:
 less. Behaves differently when its stdout is a terminal and when it's
 not.
  The only way to ensure reproducible behaviour for a program, no matter
 what it is, is to start it in a reproducible environment.

Which, fortunately, is pretty easy to do: I wrote an environment
sanitizer yesterday, because I was curious how easily solved that is.
Usage is
cautenv [-c DIR] [-u] [-x] COMMAND [COMMAND_ARGS...]

and it cleans the environment (saving some user variables if -u is
specified and DISPLAY/XAUTH if -x is specified), closes all fds above 2,
changes directory to DIR (/ if that's not specified, and calls
execvp(argv[optind], argv+optind).

It comes out at 123 lines, and could probably be made shorter.

If one wants to use this in an init script, just change the shebang to
#!/path/to/cautenv /bin/sh

and you know that there are no extra variables or fds.


 It took me ... less than a minute to find pgrep -F.
 That solves the problem of stale pidfiles.
 
  Do you think so? See for yourself:
  https://gitlab.com/procps-ng/procps/blob/master/pgrep.c
 
  It just reads the pid in the pidfile, and does its matching with
 the read pid. Unless you also give other options to narrow the match,
 it will have the exact same problem.

I meant the -F option that pgrep has solves the problem of stale
pidfiles.
I assumed that the reader would know to use that in addition to the
standard options, for which I apologize.

  Now, of course, you can give the executable name, and add even more
 guards to make sure you don't find the wrong process. At the end of
 the day, you wrote a nice and complex pgrep command line, you're
 *almost* 100% sure that it will nail your process and only yours,
 and you just scanned /proc to send a goddamn signal to a daemon.

If someone finds pgrep -F /var/run/$PIDFILE -x $NAME complex,
I don't expect that they'd be competent to write any init script,
nor even a systemd unit.

And the only way that could be wrong is if:
-you have a stale pidfile
AND
-that stale pidfile happens to contain the same PID as a running process
AND
-that running process has the same executable name as the process that
created the pidfile, while being distinct.

I will acknowledge that whoever implemented -F did so in a lame way.
What I'd assumed that it did, because it's the right thing to do, is
make -F $PIDFILE check /proc/pid/* to determine if there's a match
where pid is strictly any pid specified in $PIDFILE.
But this could be solved, if one did a little refactoring.

  I'd rather type s6-svc -d /run/service/my-daemon and kill my
 process with absolute certainty, using 10 or 20 times fewer system
 calls than pgrep and a small fraction of the CPU time.

Fair enough.

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

Re: [DNG] Init scripts in packages

[Isaac Dunham]

On Thu, Aug 06, 2015 at 02:21:55PM +0200, Laurent Bercot wrote:
 On 06/08/2015 11:45, tilt! wrote:
 Thing is, init scripts tend to have problems managing services
 that do not offer sufficient commandline interfaces as described
 above
 
  There's a simple reason for that: init scripts aren't
 managing services. They can more or less start and stop them,
 that's about it - and they're not even doing the starting and
 the stopping right.
 
  - Starting ? Sure, it's easy to start a service: run the stuff, and if
 it's a daemon, just fork it. Right ? Wrong. When you just spawn the
 stuff from your shell, it runs with your shell's environment (open fds,
 variables, terminals, so many parameters that are *difficult* to clean
 up and really harden). But when you spawn the stuff at boot time, it
 runs with the very different environment provided by init. I can't
 count how many problem reports I've read in support mailing-lists that
 were really hard to track down, but in the end it was just a config
 issue because the daemon launching script did not properly sanitize
 all its environment, so it didn't give the same results when run by
 the admin or when auto-run at boot time.

If differences in environment can cause problems, it's a problem with
design. A program that changes what it does just due to differences
between the init environment and a login environment is going to be
hard to debug.

Also, if I'm reading this right, you're implying that execline does
clearenv(), sets a new environment, and also closes all fds above 2.

  - Stopping ? Sure, just find a daemon's pid... oh wait, we need to
 have it stored somewhere. Hence, .pid files. If you don't know why
 .pid files are evil, look it up.

It took me ... less than a minute to find pgrep -F.
That solves the problem of stale pidfiles.

  And then you have the other functionality. Restarting, sometimes,
 can be lighter than stop + start: maybe there's a whole lot of
 config you don't have to do when you're just restarting a daemon -
 for instance, if restart means read your config file again,
 some daemons support the convention that receiving a SIGHUP should
 make them do just that. So restart should simply send a SIGHUP
 to those, but do stop + start on the others. That's confusing.
 There's the reload keyword sometimes, but are there any precise
 semantics ?

restart means start and stop.
reload means reread config file.

  And status. This is very service-dependent: since there is no
 global API, no service manager, scripts will query the daemon's
 status in a daemon-specific way. More vagueness again, because
 status doesn't define exactly what you should say, and the lowest
 common denominator is is it alive? but even for this basic check,
 daemon-specific interfaces are used.

The status command was originally is it running?,
but yes, that's barely useful.
If you use a pidfile and pgrep -F, that would work.

Using a tool dedicated to the purpose is more helpful than any service
manager can be (unless your service manager is a hundred-megabyte
hog).
Think it's hung?
strace/ltrace the pid.
Wondering what files it has open?
Use lsof or look in /proc/$PID/fd/.
...

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

Re: [DNG] Keeping mailing list alive - A question about error on re-compiling package

[Isaac Dunham]

On Sat, Aug 01, 2015 at 02:12:54PM +0200, Anto wrote:
 Hello everybody,
 
 I don't usually get answers on this kind of basic questions, so I post it to
 keep the mailing list alive.
 
 I am trying to re-compile a package that I took from Debian sid. And I got
 the following error.

See www.catb.org/esr/faqs/smart-questions.html#beprecise ;)
If you want an answer, tell us which package.

 dh common-install-prehook-arch --parallel --with autotools-dev --with
 autoreconf --with bash-completion
 dh: Unknown sequence common-install-prehook-arch (choose from: binary
 binary-arch binary-indep build build-arch build-indep clean install
 install-arch install-indep)
 make: *** [common-install-prehook-arch] Error 255
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
 status 2
 
 
 There is no common-install-prehook-arch either in the source package or
 the debian directory itself. So I am not sure why the debian/rules picks
 that up. Searching the internet also does not give me hints on what causing
 that. Could anybody please give me some suggestions where to look at?

Do you mean no such *file*, or no such *string*?
If the former, see if you can find that string in debian/rules.

Also, google suggests that this has something to do with cdbs; make sure
that's installed.

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

Re: [DNG] automount, mount, and USB sticks

[Isaac Dunham]

On Thu, Jul 30, 2015 at 10:39:22PM +0200, Didier Kryn wrote:
 Le 30/07/2015 01:09, Isaac Dunham a écrit :
 I'm not sure where in the discussion this fits, but I thought I'd mention
 it here:
 Permitting all mount invocations via sudo does have a potential security
 hole if your mount implementation supports FUSE, as you can run an arbitrary
 command by specifying the mount type.
 I don't think that sudo does the necessary steps to block this.
 
 If you use a wrapper script, you can make it automatically determine the
 type and run ntfs-3g if appropriate, then allow sudo to run that.
 If you use a C wrapper, you can do that and make it suid.
 
 Isaac, your comment suggests me two questions:
 One: is it really possible to mount a Fuse filesystem with 'mount' ? I
 thought it could only be done with 'fusermount'.

Yes, it is possible.
I've used sshfs in fstab, set up so I could mount ~/remote-site.

 Two: if the idea is not to allow '/sbin/mount' in sudo, but to allow a
 smart wrapper, is there still an issue?

If the wrapper is smart enough, there isn't.
Of course, that qualifier is a big one.

If I were doing it, I would
* disallow -t fuse (if it's set up in /etc/fstab so as to allow users,
  that's OK)
  Perhaps one could even disallow -t entirely, and rely on autodetection.
* disallow mounting at any directory not owned by or writeable by the user.
  Perhaps this could be moderated by ...except that any user can mount
  under /media, if they're not overmounting.

I suppose that the second point forces use of a suid helper, rather than
the use of sudo.

Alternately, you could write a wrapper that *always* mounts under
/media, and doesn't accept -t; it just takes a device name, creates an
equivalent name under /media, checks type and whether ntfs-3g is installed,
and passes a suitable type to mount (or uses mount.ntfs-3g).

Thanks,
Isaac Dunham

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

Re: [DNG] automount, mount, and USB sticks

[Isaac Dunham]

On Fri, Jul 31, 2015 at 10:47:29AM +0100, Rainer Weikusat wrote:
 
 A daemon process should only exist because it provides some important
 functionality with a real benefit for users of the system which cannot
 (reasonably) be provided in some other way, eg, by starting a program to
 perform a certain task on demand. Eg, there should be no daemon running
 permanently to monitor device creation events which never happen in
 order to create device nodes for hardware which was detected on boot and
 won't go away while the system is up. And it also shouldn't be running
 because every other millenium (as seen from the perspective of the
 computer), someone changes the configuration of the USB(-lan): This can
 perfectly well be handled with on-demand execution (and hadn't udev
 eaten hotplug, I certainly wouldn't be running it).

You could try mdev if you don't like udev.
Devuan/Debian packaging is available at
  github.com/idunham/mdev
  git.devuan.org/idunham/mdev

(builds with dpkg-buildpackage -b, no debs available yet though I'll
switch them on as soon as I find out how...)

Some warnings, though:
* I'd suggest trying it out on a test install before your main system,
for the present. If you like living dangerously and have a *plain*
disk layout (no RAID, encryption), perhapps you might get away with
dropping it in your main install.

* Right now, you'll need to manually configure xorg.conf or at least
disable input device hotplugging. Piotr Karbowski has some configuration
files to take care of that in the xorg.conf.d/ directory of
  https://github.com/slashbeast/mdev-like-a-boss

* That package has no hooks to handle LVM, encrypted partitions, or
anything else odd; if you need those, you'll have to poke around and
see what you can find (mdev-like-a-boss repo suggested as a starting
point).

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

Re: [DNG] nlmon

[Isaac Dunham]

On Wed, Jul 29, 2015 at 05:17:30PM +0100, Rainer Weikusat wrote:
 Isaac Dunham ibid...@gmail.com writes:
  On Wed, Jul 29, 2015 at 01:21:04PM +0100, Rainer Weikusat wrote:
  Isaac Dunham ibid...@gmail.com writes:
   Or you can do it with mount, sudo, sh, and nlmon 
   (http://git.r-36.net/nlmon).
  
  Using poll to wait for a message followed by recvmsg for reading it
  offers (in absence of a timeout) no advantages over just doing a
  blocking recv. Since this code neither uses control messages nor looks
  at the returned flags, it can use recvfrom instead of the (more
  complicated) recvmsg. Considering that it checks for message buffer
  overflow via len = sizeof(buf), the MSG_TRUNC flag should probably be
  used to make the kernel return the real size in case a datagram was
  truncated. Lastly, the message doesn't have to be copied to a 2nd buffer
  just to turn the 0-terminated name=value pairs into \n-terminated ones.
  
  NB: I admit that I mainly did this because it looked like a nice, simple
  programming task.
 
  A few comments:
  - I'm not the maintainer, and I don't see why this got sent here.
  - There's no reason to factor out print_event_if, and the code it replaced
is clearer and more concise.
 
 There's a very good reason to do that, namely, it's a separate task
 working with its own set of variables, even in the original code. And

I don't see it as *a* separate task; it's
 - reformat the message
 - decide whether to print the message
 - print the message
which is two or three separate tasks, combined because none of them are
working solely with their own set of variables.

 something which boasts of its light-weightness should keep rescanning

should *not* is what you intended to write, I presume?

 the same data over and over again just because that's what the standard
 C library str*-functions will do when used naively or in situations
 they're not well-suited for, eg
 
 
 for (i = 0, olen = 0; i  len; i += slen + 1) {
   slen = strlen(buf+i);
   if (!slen || !strchr(buf+i, '='))
   continue;
 
 At this point, what would really be needed is a function which returns
 a pointer to the next '=' or '\000' but C doesn't provide one.

memchr(buf+i, '\0', sizeof(buf)-i) doesn't work if you want the next char
matching ('=' || '\0'). strchrnul() does what you're asking about, but
isn't portable (GNU only).

A bigger problem is that you need to keep track of the size of the remaining
part of the buffer.
If memcspn() existed, it would be the perfect solution, but it doesn't.

slen = strlen(), then strchr() over the same memory, does involve running
over the same memory twice, but honestly:
you're complaining about going back over 8 bytes of memory?
That's about the longest that a netlink message from the kernel will go
before you hit an '=', unless you're dealing with the start of a packet.
And that's pretty short.

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

Re: [DNG] automount, mount, and USB sticks

[Isaac Dunham]

On Thu, Jul 30, 2015 at 12:40:33AM +0200, Didier Kryn wrote:
 I don't understand the preventions against sudo. It is just up to the
 administrator to take care, like for everything.
 
 Wether execution of the command is allowed by sudo, by a setuid bit or
 by policykit does not change the result. Sudo is simply the most versatile
 method to allow/disallow actions, IMHO far easier to configure than
 policykit. Don't forget that allowed commands may (should) be specified with
 their absolute path, therefore bypassing PATH. It is better than having a
 specialized daemon for this and that, because it keeps everything configured
 in one well known file.
 
 In the case of mounting usb sticks, this applies to a personal computer,
 where the owner is also the administrator. For conveniency, a limited list
 of actions may be allowed without password, like mounting a usb key.


I'm not sure where in the discussion this fits, but I thought I'd mention
it here:
Permitting all mount invocations via sudo does have a potential security
hole if your mount implementation supports FUSE, as you can run an arbitrary
command by specifying the mount type.
I don't think that sudo does the necessary steps to block this.

If you use a wrapper script, you can make it automatically determine the
type and run ntfs-3g if appropriate, then allow sudo to run that.
If you use a C wrapper, you can do that and make it suid.

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

Re: [DNG] A better default windows manager

[Isaac Dunham]

On Sun, Jul 26, 2015 at 11:18:58PM -0400, Steve Litt wrote:
 You can roll your own automount with one day's work using inotify-wait,
 dmesg, sudo, lsblk, and the mount command. Works without X or window
 manager. Heck, I'll do it myself if more than 20 people want it.

Or you can do it with mount, sudo, sh, and nlmon (http://git.r-36.net/nlmon).

Here's a demo of how to do it:

./nlmon -f block | { \
  while read LINE
do
  case x$LINE in
(xACTION=*|xDEVNAME=*) eval $LINE
;;
(x) if [ x$DEVNAME != x ]
  then
echo automount $DEVNAME $ACTION
  fi 
unset ACTION DEVNAME
;;
  esac
done
  }

Only instead of echo automount ..., you would use your mount helper
(pmount, sudo mount, ...)

nlmon reqires only libc-dev, linux-libc-dev, and a working make and
compiler.
I will note, however, that you currently need to make one small change
in nlmon.c before compiling it:
change write(0, to write(1,.

This example can be run from a user session; if one prefers, the automounter
could be replaced with a popup or anything else.

HTH,
Isaac Dunham

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

Re: [DNG] A better default windows manager

[Isaac Dunham]

On Sat, Jul 25, 2015 at 12:00:02AM +, Roger Leigh wrote:
 On 24/07/2015 23:48, James Powell wrote:
 CDE is a classic UNIX desktop, but it has long been since viable for
 modern usages.
 
 Xfce, in truth, was a modern replacement for it using Xforms since Motif
 was, at the time, under a different license. It bears the same classic
 layout minus some differences.

Xfce used to resemble CDE, yes.
But it doesn't have a strong resemblence now.
Of the two, I prefer CDE.

 However, last I had heard CDE was still unstable with some operations.
 
 My first thought on reading this was that sounds just like CDE used to be!
 (Being a CDE user back in the mid-late '90s.)

Heh. Sounds about right, given what I've read.
But there were several recent patches that fixed longstanding bugs, and
it's pretty reliable in my own experience.

 I used to really like CDE, and am very tempted to give it a try out sometime
 soon.

You'd probably want to build it from git, rather than the tarball.
Most of the commits are fixes, with a little bit of porting.
Refer to their wiki for (rather old) directions.
(http://sourceforge.net/p/cdesktopenv/wiki/LinuxBuild/)
Some deviations:
- As of Jessie, motif is in main, thus the use of non-free is outdated.
- On 32-bit platforms only, you can use tirpc instead of glibc RPC;
this allows using rpcbind without the -i option.
On 64-bit systems, using tirpc breaks tooltalk.
- In Jessie, I stumbled across an issue with openbsd-inetd shortly after
switching to Devuan, so I'm not quite sure about how to report it:
the check for RPC support in the init script uses the wrong path.


I usually start it via the sysvinit script, though that isn't quite perfect.
(It probably doesn't do quite enough error checking, and I think the pgrep
invocation may be wrong. Also, I don't think it has a -pidfile option,
though I could add that without too much work...adding -quiet was trivial.)

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

Re: [DNG] GTK (was Will there be a MirDevuan WTF?)

[Isaac Dunham]

On Fri, Jul 24, 2015 at 12:14:21AM -0500, T.J. Duchene wrote:
 
 
 On 7/23/2015 10:41 PM, Isaac Dunham wrote:
 I'm inclined to agree with you on C++, but I'd like to refer you to Roger
 Leigh's comments on the subject about seven and a half months ago;
 I'm only appending the first couple screenfuls (which is maybe a third
 of the original) but you should be able to find the original email given
 the headers and this text.
 I don't have a  high opinion of GTK either.  Honestly, I never did, but my
 opinion is subjective rather than objective.  I never bothered to learn GTK
 to a great extent.  I knew enough back in the day to hack the gnome-panel
 and add a new option or two that Gnome did not have, and I kept my changes
 to myself. That was the extent of my interest. Generally, I have a low
 opinion of UI kits because the designers tend to be horribly inconsistent.
 After GTK3 was released, I knew it was on the downhill slide.  They should
 have started over from the ground up, kept it generic, and added support for
 Qt desktop integration.  GTK has basically become part of Gnome, and no one
 of consequence except Gnome uses it.
 
[snip]
 Now then, as for Roger's comments, I find them confusing.

Probably because my comments threw you off as to what he's talking
about.
The post in question is entirely about the problems with GTK.

 [snip]
 
 The C API is overly complex and fragile.  You don't want to base your
 project on a sandcastle.  And the expertise required to use it is
 very high. Implementing dynamic typing and manual vtable construction
 rather than using C++ which does proper type checking?  Just use C++!
 
 C and C++ are both strongly typed, so I am assuming that he must be
 referring to GTK using a pointer in C presumably to dynamically handle
 function names and data for polymorphism.  He can't help it if GTK is
 sloppy, but I can't make sense of his grievance either. Type checking is
 never C's job, it's his!  That is explicit in the design of the language.
 Everyone who uses C knows that.  C++ is the same for that matter.  Neither
 language checks your variable data for type.

 In fact, you have to be an expert in C++ compiler internals just to be
 able to understand and use it effectively.
 
 [snip]
 
 That's somewhat true, but if you write C++ code PROPERLY - i.e. make sure
 you references are clean, resources released, and you aren't leaving any
 hanging exceptions, what he is claiming is pretty much a non-issue in the
 context of any OOP language.  A C++ compiler is no more mysterious that any
 of the other OOP crap we are forced to endure. C++ code is simply not as
 robust as C.   You can mitigate a lot of the annoyance;  like exceptions
 that cause premature exits - but you are never really rid of it.

it != C++; it == GTK.
The assertion is that GTK avoids using C++ by forcing the programmer to
essentially do what they would do in C++ *and* what C++ would do for them.

Hope this makes it a little clearer,
Isaac
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] sans-dbus: was Will there be a MirDevuan WTF?

[Isaac Dunham]

On Thu, Jul 23, 2015 at 12:12:36PM -0400, Steve Litt wrote:
 On Thu, 23 Jul 2015 08:39:05 +0200
 Michael Bütow mbu...@houtbay.com wrote:
 
 
  I am sure if someone wants to expend the energy to get rid of D-Bus
  related software in Devuan, they can set up their own spin of it.
 
 For those of you who don't want dbus, my experience tells me that
 getting rid of it would involve something like the following:
 
 * Use something like fvwm, Openbox or LXDE that makes minimal or no use
 of dbus.
 
 * Don't use NetworkManager. I don't remember whether Wicd uses dbus or
 not. If Wicd uses dbus, just do a combination of iwlist scanning and
 wpa_supplicant to dial in Wifi.

wpa_cli will also work; if anyone's interested, I've written a shellscript
based on dialog that simplifies configuring wpa_supplicant.

Said shell script is actually part of my local wireless configuration
setup; the other half consists of an init script to start wpa_supplicant
and a script to call busybox udhcpc when the connection is completed.

If you're wondering how wpa_cli connects to wpa_supplicant, it's by
means of a unix socket at /var/run/wpa_supplicant/$IFACE; no DBUS
involved.

 Put a command into your init system that kills the dbus started in your
 initramfs. I personally wouldn't recommend tampering with your
 initramfs itself.

Ah, that's where the fun *starts*! It's all boring till you get there.

Just purge the dbus package; it can be done, and it won't break anything
that wouldn't be broken by stopping dbus.
Then pin it (at -100, maybe?).

 In your init system, get rid of commands that start or modify a running
 dbus.

Apt does that for you if you purge dbus.

 Get rid of Pulseaudio (obviously, and not just to get away from dbus),
 get rid of ALSA to get away from dbus, and use OSS with snd_mixer_oss
 and rexima.

ALSA does not use dbus.
It uses a library that handles writing to the soundcard.
I've used a Debian system that has ALSA and not DBUS, as well as running
strace.

 You might have to tell several of your GUI programs not to do
 notifications, because they notify to dbus without the option to notify
 other ways.
 
 It's probably not going to be that difficult for the average Devuan
 user to get rid of dbus if s/he wants to.

Or just add the MirDebian repos that Miroslav referred to (you may want
both yplentyn and wtf).
There are no dependencies that are missing on Devuan, since everything
that we're trying to remove is a subset of what mirabilos set out to
remove.

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

Re: [DNG] sans-dbus: was Will there be a MirDevuan WTF?

[Isaac Dunham]

On Thu, Jul 23, 2015 at 11:49:11PM +0200, Didier Kryn wrote:
 Le 23/07/2015 22:19, Isaac Dunham a écrit :
 On Thu, Jul 23, 2015 at 12:12:36PM -0400, Steve Litt wrote:
 
 
 For those of you who don't want dbus, my experience tells me that
 getting rid of it would involve something like the following:
 
 * Use something like fvwm, Openbox or LXDE that makes minimal or no use
 of dbus.
 
 * Don't use NetworkManager. I don't remember whether Wicd uses dbus or
 not. If Wicd uses dbus, just do a combination of iwlist scanning and
 wpa_supplicant to dial in Wifi.
 wpa_cli will also work; if anyone's interested, I've written a shellscript
 based on dialog that simplifies configuring wpa_supplicant.
 
 I don't understand why you, Isaac, and also Steve want to do this
 yourself and always avoid speaking of wpa_gui. wpa_gui will really help you
 configuring wpa_supplicant. It detects all the needed parameters and only
 requires you to enter the secret keys. Why rewrite all this yourself (unless
 for training)?

My main motive was the fact that wpa_gui will not work unless you already
have a working wpa_supplicant.conf  wpa_supplicant is running.
(My script was partly inspired by how hard it is to figure out what goes
in wpa_supplicant.conf if you've never used wpa_supplicant before.)
It also has to do with Qt4 vs. dialog: one drags in one of the largest
GUI toolkits around, and the other is a couple hundred kilobytes,
runs in text mode, and only depends on a single library that's basically
guaranteed to be installed and implements a POSIX API, with an installed
size in the half megabyte range.
(In case you're wondering about the POSIX API part, curses is part of
POSIX; dialog only needs ncurses.)

For what it's worth, my script also works with whiptail, although --
contrary to the whiptail docs -- whiptail ends up using many times
the space on i386, between libslang, libnewt, and libpopt, besides
being buggy. In theory, it will also work with Xdialog if you have it.


 BTW I had a look at wicd the other day and read I could only configure
 it for one  wifi station. Is that true? wpa_supplicant can store an
 unlimited list of stations and connect to the one it detects... I have more
 than 30 in my wpa_supplicant.conf -- labs, homes, hotels, bars.

I don't recall seeing any signs of such a limitation when I used wicd
for connecting to wireless at home and at college...
That said, when I tried it was fond of spawning lots of wpa_supplicant
processes.

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

Re: [DNG] Will there be a MirDevuan WTF?

[Isaac Dunham]

On Fri, Jul 24, 2015 at 01:53:15AM +0200, Jaromil wrote:
 On Thu, 23 Jul 2015, Hendrik Boom wrote:
 
  I do not understand this entire thread.
  
  I have not a clue what a MirDevuan WTF would be.
  What does the Mir prefi contribute the the eaning?
  What does WTF mean in thei context.  I mean what the fuck?
 
 yep. this is sort of going bonkers.
 
 me and other developers on this list started receiving delirium mails
 from this WTF guy in private, not sure what to make about them if not
 evince he is flaming with himself or another guy with the same name.

Thorsten Glaser, the Debian Developer who authored the GR against systemd,
maintains two repositories named wtf and yplentyn.
Collectively, they are referred to as MirDebian, after Thorsten's
nickname mirabilos.
These repositories are designed for running without systemd, pulse, dbus,
and a whole lot of similar stuff.
The systemd_must_die package that aroused such a flamewar was in the
MirDebian wtf repository, and has been renamed
prevent_systemd_completely.


The OP is not mirabilos, nor even of the same nationality; the only
connection is that the first three letters of his name are the same
as the first three lettters of Thorsten's nickname mirabilos.
(Note that miro has o as the fourth letter; ISTR that it's short
for Miroslav.)
However, the OP objects to much of the software that Thorsten has worked
on disabling/removing, and thus has been promoting the mirdebian wtf
repository.
The OP has repeatedly stated that systemd, pulse, and dbus are all
backdoors for remote exploits, and provided notes on removing them
with the aid of Thorsten's repositories and hardening a system with
grsec; these notes have been useful to some, despite the OP not being
fluent in English.

As far as I can tell, the current thread is the OP's attempt to ask
Thorsten if he intends to duplicate the repositories for Devuan.

It is my understanding, based on my previous examination of the
repositories, that nothing in there would have to change for Devuan.


Does that clarify anything?

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

Re: [DNG] GTK (was Will there be a MirDevuan WTF?)

[Isaac Dunham]

On Thu, Jul 23, 2015 at 09:30:04PM -0500, T.J. Duchene wrote:
 On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
  On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
   ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and is
   documented on a random basis, when you compare it to the rest of
   GNU/Fedora
   it's... like GTK: it sucks, there are alternatives but it's a PITA to port
   away 'cause a lot of big codebases uses them as foundation.
  
  So there are alternatives to GTK:  Do any suck less?  What are they?
  
 What's wrong with GTK?  I don't care for it, but it is not any worse than 
 Microsoft's UI.  
 
 There are lots of alternatives.  wxWidgets and Qt are the most common 
 suggestions, but there are far more esoteric ones.  If you are aiming for 
 widest portability support, Qt is probably your best bet.  
 I don't care for it myself - because it is C++.  I do not believe in OOP as a 
 decent paradigm for software development.  I'm know I am in the minority, but 
 I am not alone.  Even Google has reined in use of some of the worst features 
 of OOP.  Programmers working for Google are not allowed to use exceptions.

I'm inclined to agree with you on C++, but I'd like to refer you to Roger
Leigh's comments on the subject about seven and a half months ago;
I'm only appending the first couple screenfuls (which is maybe a third
of the original) but you should be able to find the original email given
the headers and this text.

Appending message:
Date: Sat, 6 Dec 2014 21:51:42 +
From: Roger Leigh rle...@codelibre.net
To: dng@lists.dyne.org
Message-ID: 20141206215142.gw1...@codelibre.net

On Sat, Dec 06, 2014 at 06:44:01PM +0100, mutek wrote:
 On sabato 6 dicembre 2014 18:32:04 CEST, Mihamina Rakotomandimby wrote:
 On 12/06/2014 04:57 PM, Hendrik Boom wrote:
 On Fri, Dec 05, 2014 at 02:54:09PM +0200, Vlad wrote:
 I would propose that we do not waste any time with GDM, GNOME
 or
 anything
 else that has sprung out of that irresponsible organizations
 other than gtk.
 I wasn't aware that GTK had anything to do with that organisation.
 Isn't it the Gimp ToolKit?
 And isn't the Gimp the GNU Image Manipulation Program?
 
 Yes, but the Gimp tool kit has been adopted by the GNOME
 develoment team to be their toolkit too.
 
 whatever I saw in the industry...GTK it's not taken in account if
 compared with QT,MS-whatever,Java-whatever,HTML5-DOM-canvas-engines,

There are good reasons for that.  As a (former) professional GTK+
developer, I have found out the hard way that it's unsuitable for most
projects.  Nowadays, unsuitable for almost all projects outside GNOME.

 GTK did a very good job but seems invisible to the world out of the
 free softwares

That's because it's a terrible toolkit, and the number of people who
are experts with it is vanishingly small (and shrinking).  It's not a
safe platform on which to build anything serious.  Not because it
doesn't work, but because you can't easily hire people, and because
it's the least efficient and worst documented toolkit to work with.
If you want to achieve your own project's goals on time, this matters.

The C API is overly complex and fragile.  You don't want to base your
project on a sandcastle.  And the expertise required to use it is
very high.  Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking?  Just use C++!
In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.  It's like being a master
carpenter and then willingly eschewing your workshop for a rusty swiss
army knife!  While you could probably construct something with the
swiss army knife if you try really hard, the workshop will do a
faster, better, more professional job and let you get on with the job
rather than cursing at your inadequate tools every few minutes.

[snip]

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

Re: [DNG] Thorsten Glaser? was: Will there be a MirDevuan WTF?

[Isaac Dunham]

On Thu, Jul 23, 2015 at 12:23:26PM -0400, Steve Litt wrote:
 On Thu, 23 Jul 2015 16:18:22 +0200
 miro.ro...@croatiafidelis.hr wrote:
 
 
  What fundamentalists? The Gentoo folks? Thorsten mirabilos Glaser with
  his MirDebian WTF project, a fundamentalist? Me, a fundamentalist?
 
 What's the relationship between Thorsten Glaser, mirabilos, and
 miro.rovis ?

Thorsten Glaser == mirabilos. He's one of the founders of MirBSD, a
Debian Developer, and author of the GR to get rid of systemd.
He maintains an external repository or two for Debian, designed to help
avoid a bunch of software he considers harmful, such as dbus, pulse,
and systemd (as well as aptitude, *kit, ruby, mono, and networkmanager).


miro.rovis is not connected to Thorsten Glaser, though they share many
dislikes. That's about all I know.

Hope this clarifies things.

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

Re: [DNG] Multi-seat on Devuan, do we actually need that useless curiosity?

[Isaac Dunham]

On Thu, Jul 23, 2015 at 03:49:32AM +0300, Vlad wrote:
 I think that the pretty useless feature which helped systemd into Debian in 
 the first place was discussed some time ago.
 As you might know multi seat is supposed  to make possible for multiple users 
 to utilize a single desktop or laptop system in full blown GUI mode via 
 special USB  hubs, the main selling point of this curiosity was as a way to 
 run schools in 3rd world countries.
 However these extension hubs actually cost more than a Raspberry Pi, and the 
 Pi has the extra selling point that the student can take it home and use it 
 there.
 I do not see any real need for silly things like multi seat and with every 
 nanometer less and every new cell phone the price and power consumption per 
 Ghz falls.
 In my opinion 99+% of users really won't care about this curiosity, which is 
 a cool concept with less and less actual relevance or practical purpose 
 behind it with every passing day.

Somehow it seems to me like someone trying to reinvent the dumb terminal,
but with less distance possible.
I could imagine one situation where it makes sense:
 $site is running commercial software for x86{,_64}, licensed on a per-
 processor basis with multiple users permitted; said commercial software
 requires a decent processor but not much GPU.

Other than that, I can't picture a use.

All that said, I *can* picture a way to implement it using X(fbdev?) and
perhaps mdev (which I thought about not long ago...):
- *disable* input device hotplug in X11
- keyboards get renamed /dev/input/kbd$N, like how mice are named
- for new keyboards, mice, and framebuffer/drm nodes, run a helper
  script that will spawn an X11 login if the appropriate devices exist
  for the current $N.
You could even use hard links, bind mounts, and unshare to make
restricted containers for different users.
(I'm thinking of putting hard links to the device in /dev/seat$N/, but
with normal naming conventions under that. Then each seat gets a new
mount namespace and a private bind-mount over /dev.)

In theory, that should be a pretty small amount of work.
But I don't have any hardware suitable for testing, and don't feel that
it really justifies getting said hardware.

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

Re: [DNG] systemd in the era of hotplugable devices

[Isaac Dunham]

On Wed, Jul 22, 2015 at 12:59:56PM +0200, Laurent Bercot wrote:
 On 22/07/2015 10:00, Oz Tiram wrote:
 One argument I hear often about systemd is that it more adapted to current 
 hardware needs, [e.g. here][1]
 
Computers changed so much that they often doesn’t even look like
   computers. And their operating systems are very busy : GPS, wireless
   networks, USB peripherals that come and go, tons of softwares and
   services running at the same time, going to sleep / waking up in a
   snap… Asking the antiquated SysVinit to manage all this is like asking
   your grandmother to twerk.
 
 What I don't understand is how an init system manages hot pluggable devices.
 What does replacing a hot plugable disk drive it have to do with how the 
 system is booted?
 Maybe this all done at the none init parts of systemd?
 
  Hi Oz,
 
  Don't believe everything you read on the Web. ;)
  The author of the article has already adopted systemd's point of view, which
 is one init should do everything, without even being aware of it.
 
  The truth it, you're perfectly right: it is not init's job to manage hot-
 pluggable devices. There is NO reason why init should be made aware of
 those kernel events, and the systemd can manage modern hardware meme is
 but a pile of propaganda.
  Any init system, including sysvinit, will work just as well: managing
 hotplug is udev's job, and anything implementing udev functionality will
 do. udev predates systemd, so systemd did not invent the feature; it
 just took udev and integrated it tightly to make itself unavoidable,
 a.k.a. virus tactics.
 
  eudev and vdev, as well as other udev-like daemons, prove this is not
 necessary. So you can safely ignore the article, written by someone who
 has a wrong idea of what init is supposed to do.

In general, I'd agree with you, but there are some situations where it's
possible to argue for hotplugger/service manager integration:
 if you hotplug a scanner or printer, there's reason to think that the
 corresponding daemon (sane/cups/lprng/lpr) should start.
Note that I did not say that I think it's a good argument.

The obvious defect in this approach is that there *are* network scanners
and printers, which cannot be hotplugged. A less obvious obnoxious
detail is the sudden demand on system resources, and the delay before
the service is available.

One alternative to this approach would be socket activation, but...
using cups with inetd would really suck, given that it's pretty slow
to start.
Socket activation as done in systemd and upstart (wait till the first
connection, then start the service) could sort-of-work, though the 
first print will always be slow.

None of these are actually 100% reliable, since you have a service
starting upon some request; if there isn't enough RAM, it falls flat.
But then, printing involves spawning filters anyhow, so it would have
that problem (to a lesser degree) anyhow.

Anyone who says systemd is necessary because of wireless networks is
talking out of their hat if they mean 802.11. You have to use
wpa_supplicant if you want to handle those, and it's perfectly adequate.
A similar observation is true for GPS: just leave gpsd running, and
it will only start up the GPS when needed.
There is an alternative to gpsd from FDO, but:
-it's less reliable: gpsd carefully avoids as many conditions that may
fail as possible, and the FDO stack was written because the developer
didn't like the fact that that required avoiding malloc().
-it's much less useful: gpsd handles almost every known GPS, while the
FDO stack only supports some NMEA-conformant GPSs.

Overall reaction to the argument:
Expecting init to manage all that is stupid; init should only be concerned
with system processes.

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

Re: [DNG] Proposed defaults changes

[Isaac Dunham]

I'd like to respond to this, even though I think 'no change' is the best
policy at the moment.

On Thu, Jul 16, 2015 at 12:41:18AM +0200, Didier Kryn wrote:
 Le 15/07/2015 18:02, Klaus Ethgen a écrit :
 Even though mc is something good for beginners but debian or devuan is
 not focusing on beginners and even devuan is focusing on veteran unix
 admins so vi(m) would be the only proper choice.:-D
 I remember 30 years ago, there was an admin in my lab advocating for vi.
 I tried to find a manual and couldn't find one. Several time I watched the
 guy editing some files and was impressed by how painfull it was to him to
 change a single character in a text. I have been using emacs and emacs-like

Change a single letter:
navigate to letter
rnew letter
:xEnter

Sorry, I don't see how that's painful unless you're talking about someone
who either didn't know the software or had a hard time finding the letter.

Navigate to a location by line number:
:number
Search for a word or phrase:
/regex
...Those seem pretty simple, too.

Replace occurences of a regex with an expression on the current line:
:s/regex/exp/g
Through the whole file:
:%s/regex/expr/g
From the current line to the end of the file:
:.,$s/regex/expr/g
From the start of the file to the current line:
:1,.s/regex/expr/g

Run a command:
:!command
Replace the current line with the output of a command that reads the
current file:
:.!command %

 editors for 33 years I think. Of course I don't ask to have emacs installed
 by default (it is huge), nor even a small emacs clone, such as mg. If
 there's always vim-tiny, why are people asking to remove nano? If the gurus
 use vim and dislike nano, since they are gurus, they can change the default
 themselves and leave the ordinary people with a limited but usable editor.

For one thing, you almost certainly will get dumped into the default
editor during the install, and using nano is rather painful (especially
if you use vi).

Honestly, the first time I encountered nano, I thought How on earth do
you use this?
Sure, it has the cheat sheet right at the bottom of the screen, but even
then a *new* user will be lost by the terminology they use (Write out?
Where is? What does cur pos mean? How do you select text? How do you
paste text?).

That said, the first time I encountered vi I was even more baffled;
sure, I read a description of how to use hjkl, i, and :wq/:q!, but even
if you commit that to memory, press one wrong key and you're done.
(Speaking of which, it would be really nice if we could at least enable
multiple undo by default...)
And I really don't think that there's a way to make vi user-friendly.
But pick up any book on learning *nix, and within a few chapters you'll
find a section on vi. And the fact that it's a relative of sed is a point
that makes it easier to pick up.

But I have never managed to figure out how to use emacs, and even the way
the keybindings are written is a bit of a WTF. (Whose idea was it to
represent the modifier keys by the first letter of their *nix name?)

If I were to pick a default editor with the intent of making an easy-to-use
system, my first pick would be joe/jupp; while it doesn't have the cheat
sheet at the bottom of the screen, it tells you how to get help, and that
help is more useful than nano's.
As a bonus for those who prefer RSI, it comes with a 'jmacs' mode that
imitates emacs (which, of course, I have not tested). There's also
jpico, which is a clone of the 'pico' editor that nano is a clone of.

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

Re: [DNG] Proposed defaults changes

[Isaac Dunham]

On Thu, Jul 16, 2015 at 09:44:21AM -0400, Rob Owens wrote:
 - Original Message -
  From: Hendrik Boom hend...@topoi.pooq.com
  On Wed, Jul 15, 2015 at 09:04:03PM +0200, Micky Del Favero wrote:
  I vote to put vi as default editor in devuan because vi is the default
  editor in every unix since ever and every unix user has to know how to
  use vi!
  
  NO.  Not every Unix user.  Only the ones that use Unix variants that
  force vi on them.  Only those have to use vi.
  
 Hendrik,
 
 Just curious -- do any distros come with emacs as the default editor?  I
 don't use emacs, and have never tried running it from a default install
 of any distro I've ever used.

I'm not sure if it's the default editor, but it's included in the
Scientific Linux live cd (a ~400-500 MB live cd with icewm and a few other
things).

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

Re: [DNG] systemd in wheezy, was: Re: bummer

[Isaac Dunham]

On Wed, Jul 15, 2015 at 03:07:46PM -0400, Rob Owens wrote:
 I am of the belief that sysvinit isn't all that bad, and I'd rather use 
 it than learn something new.  But I've found OpenRC relatively easy to
 understand and work with.

OpenRC actually uses sysvinit; it replaces sysv-rc (the boot script
framework) rather than init.
In terms of how you run the scripts, it's fairly interchangeable; the
most significant difference from sysv-rc is how you write the scripts,
but even that is a matter of writing shell functions rather than
case statements.

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

Re: [DNG] Proposed defaults changes

[Isaac Dunham]

On Wed, Jul 15, 2015 at 02:59:51AM +0200, Franco Lanza wrote:
 More than the already know switch from gnome to xcfe4 as the default
 desktop and the oblovious change to sysvinit instead of systemd, i would
 to propose some other default changes in the standard install:

May I suggest that at this point, changes of this significance should be
planned for the next cycle rather than thrown in at the last moment?

 nano - vim

Which vim?

Vim can be built with features ranging from almost none beyond vi (tiny)
to a vast selection (huge), with or without integration with x11, tcl,
perl, python, lua, mzscheme, and ruby, and with your choice of curses,
Athena, GTK, Motif, or (experimental) Qt for UI.

But in my opinion, the only one of the Vim packages that belongs in the
core install is vim-tiny; anything else drags in too much.
Personally, I'd be quite happy to see that one become default,
but I realize that nano is one of a very limited number of editors that
provide adeqaute help on-screen; mcedit is the other one that I know of.

 exim - postfix

I'd probably only be using ssmtp, nullmailer, or such myself.

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

Re: [DNG] systemd in wheezy, was: Re: bummer

[Isaac Dunham]

On Thu, Jul 09, 2015 at 03:23:25AM -0500, T.J. Duchene wrote:
  
 
  
 
 From: James Powell
 Systemd is not the answer to GNU/Linux any more than BusyBox is, and by all 
 technicality, systemd is just an unmatured BusyBox.

 While there are some analogies, systemd is definitely not an “unmatured 
 BusyBox”.

Agreed, but I'd like to elaborate.

Systemd and busybox are both packages containing functionally unrelated
code that uses a common library, yes.
That's the extent of the similarity.

Busybox is a collection of mostly *drop-in* replacements for common tools,
where systemd implements its own interfaces.
As a result, there was never a need to patch openntpd (for example) to
make it log with busybox syslogd, nor to patch busybox ntpd to work with
syslog-ng.
It's possible to use busybox tar to extract bzipped tarballs even if you
completely disabled bzip2 support when building busybox.

As well as letting you use components from other projects, Busybox lets
you disable anything you want: the shells, mdev, init, cttyhack, getty,
the runit infrastructure, the dhcp client, ifconfig, route, ip, blkid,
mount

In contrast, systemd has a set of daemons that you must build, and then
other sets that can be added to that.
Many of these daemons depend on APIs provided exclusively by other
daemons in the systemd package.

Finally, Busybox combines all its seemingly unrelated functionality
in one package so as to provide a single binary that can boot or
rescue a system in as little space as possible. You will have a hard
time building a single binary from multiple packages.
In contrast, systemd creates a number of binaries that could not
possibly be combined: you will never have the same entrypoint to
the bootloader and init, though you could put init in a container
that's embedded in the kernel and stub the kernel with the bootloader.
That's no more a single binary than a self-extracting archive is.
And there's no logically consistent reason to put a bootloader, an
init system, a GUI that needs GTK, a time daemon, and a DNS server
all in the same package if they are not going to be combined and
are modular.

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

Re: [DNG] systemd in wheezy, was: Re: bummer

[Isaac Dunham]

On Thu, Jul 09, 2015 at 01:36:23PM -0400, Steve Litt wrote:
 By the way, I have no personal knowledge of how many actor sockets a
 listener socket can spawn off, but if I had to guess, I'd imagine 50
 would be way too low a number, if for no other reason than none of my
 current and former ISPs would have been able to serve httpd to the
 masses if 50 was the limit.
 
 Hmmm, as far as just plain processes, maybe I'll make a fork bomb and
 see how many there are before the system bogs down. That should be
 interesting.

Here's a trivial forkbomb-ish program that I've used for some experiments.
(So as to recover safely, when fork() finally fails it will sleep briefly
and exit.)
It's probably not representative of even a trivial server, but on my 
1GB N270 netbook running Alpine Linux, with ~100 programs running
(ls -d /proc/[0-9]*|wc -l = 103), it reports 7880 forks.

Thanks,
Isaac Dunham
/* Written by Isaac Dunham in the year of our Lord 2015
 * No rights reserved, all warranties disclaimed.
 * (You can do whatever you want, but entirely at your own risk.)
 *
 * A small forkbomb-ish test program intended to test how many trivial
 * socket-using programs can run on a processor (and their effects on
 * the scheduler).
 * It gets a pair of connected sockets and repeatedly forks, with
 * the main process reading from the socket and the children
 * writing to it.
 * On resource exhaustion, all processes will sleep for 20 seconds
 * and exit, allowing you to briefly observe practical effects
 * before the system recovers.
 *
 * Compile with -DUSLEEP if you would rather see effects of a *lot* of
 * syscalls. (For example, what does the scheduler do?)
 */

#include sys/types.h
#include sys/socket.h
#include stdio.h
#include unistd.h


int main(int argc, char *argv)
{
pid_t pid;
int count, sv[2];
char got;

if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv))
return 32;

while ((pid = fork())  0) {
count += (read(sv[1], got, 1)  0 )? 1: 0 ;
printf(pid: %lld forks: %d\n, (long long)pid, count);
}
if (!pid) {
write(sv[0], a, 1);
}
#ifdef USLEEP
count = 0;
while (count  2) {
usleep(1000);
count ++;
}
#else
sleep(20);
#endif
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dng Digest, Vol 10, Issue 12

[Isaac Dunham]

Building on Nate's answer.

On Sat, Jul 04, 2015 at 07:23:52AM -0500, Nate Bargmann wrote:
 * On 2015 04 Jul 05:02 -0500, John Jensen wrote:
  Hi All,
  
  I've been following this list for a long time. I'm a supporter of open
  source and the philosophy around it. I studied programming years ago but as
  the work where I live, at the time, was in other areas I moved on to other
  things. If one wnated to learn C to contribute to the community what is the
  most direct approach? What books would be most relevant? Do those of you
  who program use IDEs and if so which? There's an IDE called CODE::BLOCKS
  (?) that I've looked and I've read is quite good.
  
  I have a book on C basics, C Primer Plus, that I'll have to work through to
  get my mind back into that thought process, but after that where?
 
 Knowing C is a good start as you've already surmised.  A lot of
 programmers regard The C Programming Language for ANSI C by Kernighan
 and Ritchie as definitive.  C as implemented by GNU follows the C
 standard but also adds its own extensions they you may or may not need
 to be aware of.
 
[snip discussion of build systems]

 If your package uses third party libraries you'll want to get familiar
 with their documentation.  In most all cases the GNU C library
 documentation will prove indispensable.  When you need to access the
 kernel API directly, the book The Linux Programming Interface by
 Michael Kerrisk, maintainer of the Linux man pages, goes plenty well in
 depth:
 
 http://www.man7.org/tlpi/

The related package is manpages-dev (sections 2  3).
non-free/manpages-posix-dev is something you should also have if you want
to write portable code; it's section 3posix.
contrib/susv4 is the latest (HTML? PDF?) version of the POSIX standards.


 As for an IDE, I use GNU Emacs for my editor and GDB debugger
 interface.  I'm still working to get comfortable with it.  I handle
 building and source code management directly from a terminal (Xfce
 Terminal to be precise).  This is less objective and a quite more
 personal decision that you will need to sort out for yourself.  Plenty
 of options exist for you to try.

I use vim (occasionally nvi) and sometimes nedit for an editor.
Most editors in the repository will do.
Besides gdb (and the various UIs for it), other tools that come in handy
are strace (traces syscalls, showing return values) and ltrace (likewise
but for library calls). I've also heard of xtruss (X11 calls) and ptrace.


 Finally, there is source code management.  Right now the most popular
 SCM in the Linux world is Git.  Learn it on a most basic level as it in
 use by most projects you will encounter.  Second place is Subversion.
 Distant third place contenders are Mercurial, Bazaar, and CVS.
 Knowledge of these SCMs is only needed if the project uses them,
 otherwise just knowing they exist is sufficient.

Often, low-level projects that aren't in git are in CVS.
As far as I know, the two packages I've used that are still in hg
(mercurial) are OSS4 and Firefox. Emacs just switched from Bazaar
to git.

Understanding the Debian packaging system is probably going to be
helpful; here's the New Maintainer's Guide:
https://www.debian.org/doc/manuals/maint-guide/index.en.html

debian/rules is written in Make, so you will need to understand that.

You'll probably need to understand shell scripting, but you may know
it already. Just ask if you want anything more. 

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

Re: [DNG] My experience with Devuan Alpha2

[Isaac Dunham]

On Fri, Jul 03, 2015 at 09:24:52AM +0800, Robert Storey wrote:
 Hi All,
 
 Steve Litt said...
 
  Like I said, fvwm is excellent. LXDE and Openbox are two others to look
  at, and as far as I know they have few if any systemd dependencies,
  direct or otherwise.
 
 I too am a fan of fvwm and LXDE. But another I recommend is IceWM. Only
 weakness is (like fvwm) it doesn't by default automount plugin USB devices.
 If that could be tweaked, IceWM would be my preferred default desktop.

And grep doesn't initialize your wireless, right? ;^)
(Though I have used it in some of my wireless-related scripts.)

If you want to automount devices, use an automounter. A window manager
manages windows, not disks.
If you don't want a full automounter, it shouldn't be too much work to
pipe

 udevadm monitor --kernel --subsystem-match=block

through awk or sed, and use the derived information with pmount.
But if you mean to make this widespread, make it easy to turn off.

Thanks,
Isaac Dunham

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

Re: [DNG] [Dng] vdev status update: device properties and udev compatibility

[Isaac Dunham]

On Fri, Jun 26, 2015 at 04:40:33PM +0200, Didier Kryn wrote:
 Le 25/06/2015 07:04, Jude Nelson a écrit :
   In time, it will also work the busybox tools, but I am still working on
 getting busybox's blkid to work here (specifically, we need the -p flag
 to work in order to get low-level partition table information and
 filesystem metadata).
 
 Contrary to the other options, which only deal with formatting the
 output, option -p cannot be emulated with a wrapper script. Have you any
 idea of how to proceed. I am only a consumer of Busybox and have never tried
 to dig into the source. Are you, or anybody in this list, able to submit a
 patch to busybox blkid?

What information fields from -p are needed?

Thanks,
Isaac Dunham

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

Re: [DNG] Packages aren't the only path to alternate inits

[Isaac Dunham]

On Thu, Jun 18, 2015 at 09:47:21AM -0400, Steve Litt wrote:
 On Thu, 18 Jun 2015 21:29:36 +1200
 Daniel Reurich dan...@centurion.net.nz wrote:
[snip]
  And if each of those daemon-*-init packages depended on their 
  respective init system, and each of those init systems provide the 
  virtual package init (as is the case in Debian and Devuan Jessie), 
  then apt should be able to work out that when installing daemon
  that because sysvinit-core is the package providing init that it must
  also install daemon-sysv-init in order to satisfy the dependency.
  The problem is whether changing init systems would result in pulling
  in the new daemon-*-init dependency required for the new init
  system.
  
  Thoughts??
 
 My thought is there are some packaging tasks better done by a five step
 README doc. All this package dependency described in this email is an
 example. Instead, just have one package that installs Epoch, with the
 epoch program in /sbin. Have another package that puts common
 Epoch daemon defs in a directory, ready for copying and pasting. Just
 because one installs Epoch doesn't mean he wants to blow off sysvinit.

 One more thing: There are *huge* benefits of being able to choose your
 init, at runtime, just by changing your Grub or LILO init= value.

I agree on that last point; booting with init=/bin/sh has helped me fix
a system more than once.
Also, it can be handy to switch between a known-good init and an
experimental one.

Honestly, the overhead of simply having another package is probably
going to be at least as great as the overhead of installing scripts
for all init systems, and will be paid in part by everyone:
 * the repository index gets larger
  - more disk space and bandwidth from the mirrors
  - more disk space and bandwidth required for the systems
 * the dpkg/apt package database gets larger
 * it gets harder to manually upgrade/downgrade packages
 * it gets harder to switch inits, due to the maze of initscripts
   that will need to be installed for each new package

I see some comments that seem to assume that every init script should
imply a dependency on the corresponding init system.
A dependency is for a package without which the package would be
unusable for its normal use (IIRC).
If you use runit with a daemon that supports upstart, runit, and sysvinit,
running /etc/init.d/script is not part of your normal use; there is
no reason to depend on sysvinit except perhaps this way:

Recommends: sysv-rc | upstart | runit

As far as quantity of work goes, you may need to do more than just 30
daemons to get a moderately featureful desktop going.
But maintaining the scripts separately is probably going to be easier
than adopting each of the packages.

You won't be maintaining scripts for all 1000+ packages:
epoch users probaly won't want heartbeat, or the three UPS packages.

If you do maintain scripts for separately maintained daemons,
mark your packages as enhancing them.

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

Re: [DNG] [Dng] epoch feature request

[Isaac Dunham]

On Wed, Jun 17, 2015 at 09:21:03AM +0200, Anto wrote:
 Hello Isaac,
 
 After reading http://sources.debian.net/src/dpkg/1.18.1/doc/triggers.txt/
 (over and over), it looks that dpkg-trigger is a better solution than
 monitoring /etc/init.d using inotify(). However, I still fail to understand
 some points.
 
 It looks that the only entity who has all knowledge on what is going on
 during the trigger event is dpkg. How do we forward that trigger event
 information to the triggered (or consumer) package, so that it knows which
 package (or producer) initiates that trigger and what kind of action is
 being done?
 
 For instance, we set a trigger on epoch package for any updates on
 /etc/init.d. At one point after booting with epoch, we install ntp package.
 How can we make the postint script of epoch package knows that ntp package
 is being installed and /etc/init.d/ntp file is being added? The requirement
 that needs to be fulfilled for that are, there must not be any script being
 added into ntp package and no program/script with inotify() function on
 epoch package to monitor /etc/init.d. Would that be possible?

First, I'm *not* an expert on packaging (I simply learned enough to
keep a couple PPAs going correctly) or on dpkg triggers.
I know that they exist, and that they are cumulative:
if you install four packages with init scripts, and remove three more
at the same time, a trigger does not get called for each package.

So presumably a trigger would not track the individual packages,
but rather would update the epoch configuration to match /etc/init.d
(creating entries where there are none, and removing entries that
refer to missing init scripts).

Roger Leigh may be able to answer your questions more fully--and quite
likely more accurately; I don't know who else here has a background in
this off the top of my head.

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

Re: [DNG] [Dng] epoch feature request

[Isaac Dunham]

On Tue, Jun 16, 2015 at 11:09:43AM +0200, Anto wrote:
 
 
 On 16/06/15 10:58, Arnt Gulbrandsen wrote:
 Anto writes:
 Yes. I almost have everything to start trying to build epoch package,
 *except* one important point that I have been asking for. That is the
 mechanism to trigger an action to automatically update epoch.conf and
 start the daemon when we install all packages with daemons that need to
 be started/stopped at boot/shutdown time, *without* including epoch
 specific files into those packages. So what I am basically looking for
 is totally different approach than what Debian based distros have been
 doing for other init systems, so that we don't need to patch all of
 those packages with epoch specific files and re-build them.
 
 You have code that rescans /etc/init.d and parses those LSB-Foo-Bar
 comments, is that right? If so, you have three options:
 
 1. Piggyback on someone's post-install hooks.
 2. Run inotify() in a patched epoch and watch for file creation in
 /etc/init,d
 3. Invent a new hook that lets you process ALL dpkg -i calls.
 
 Pick your poison.
 
 Arnt
 
 
 Thanks a lot Arnt,
 
 Option 1 is definitely not what I am looking for. Option 2 looks to be the
 most elegant solution, assuming that all packages will still generate their
 sysvinit files on /etc/init.d.


If you were open to option 1, you could install your own update-rc.d
if you conflicted with sysvinit.

The init scripts are *not* generated: they are config files that are
included in the package, but will not be replaced if modified unless
you specify to replace them.
But watching for file creation seems like a case of refusing to work
with the package manager.

For option 3:
https://wiki.debian.org/DpkgTriggers


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

Re: [DNG] epoch feature request

[Isaac Dunham]

On Tue, Jun 16, 2015 at 11:45:55AM -0400, Hendrik Boom wrote:
 On Tue, Jun 16, 2015 at 05:34:49PM +0100, Arnt Gulbrandsen wrote:
  Anto writes:
  So I am not really sure what you meant by reading the new
  directives at boot time. Which directive would that be, where is
  it located and which package provides that?
  
  You read things like
  
   # Provides
  
  and
  
   # Required-Start
  
  to generate an Epoch configuration in /etc/epoch.conf (or some other
  filename). Epoch then reads that file to generate an Epoch
  configuration in RAM.
  
  What I am saying is: Why bother with generating the configuration
  file? Why not just generate the in-RAM configuration? That is, why
  not teach Epoch a new configuration option, documented as following:
  When you enable this option, Epoch reads the LSB-Start-Before and
  ... options in /etc/init.d/*, and starts servers accordingly. Note
  that Epoch does not run /etc/init.d/*, it merely reads the
  LSB-Start-Before and ...
  
  This is tricky. It's quite possible that doing this directly is a
  bad idea, and that it actually is better to use the detour via the
  config file.
 
 There are sometimes zombie files in /etc/init.d  -- files that, by 
 mishap or otherwise, didn't get deleted upon package deletion.

IIRC, a config file (anything under /etc) that has been modified
will not be removed unless its package is purged or the sysadmin
deletes it manually.

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

Re: [Dng] Readiness notification

[Isaac Dunham]

On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote:
 On Sat, 13 Jun 2015 10:37:19 +0100
 KatolaZ kato...@freaknet.org wrote:
  I think there is another, more fundamental question: do we really need
  to know in *real time* when a service/daemon is ready for its job or
  has done what it is supposed to do?  AFAIK all this fuss with
  daemon-readiness began with the first attempts to have parallel boot
  sequences, which is something that is still *useless* in 95% of the
  use cases: servers don't get restarted evey other minute and normal
  users who don't use suspend can wait 30 seconds to have their desktop
  ready, what else? Embedded systems? Well, they usually have just a few
  services running, if any

Quite honestly, it really *does* matter to me that I can boot Alpine
Linux on my netbook in ~5 seconds rather than the ~10 seconds it takes
using LFS-based init scripts on my built-from-scratch system.
It really is nice to be able to grab it, press the power button, and
have it ready to use by the time I get downstairs; the old 45-second+
boots were rather awkward for conversations where some online document
was enquired about.

Alpine is OpenRC+busybox init; the built-from-scratch system is
musl/busybox/sysvinit/LFS bootscripts, but I've thought about reverting
to busybox init and doing a simpler rc script that does what I need.

  What are we really talking about? Isn't this just another
  feature-for-the-feature's-sake-thing? Why should I bother to allow
  cups signalling immediately that it is ready to put my printouts on a
  queue that will anyway need minutes to be processed?

Maybe if you have a print server?

For a moment, I thought minutes to be processed was ridiculous
hyperbole; I use a laser printer that gets ~20 pages per minute.
(I had a *lot* of papers to write and print in college.)

 KatolaZ, I just got done converting Plop Linux to init with a
 combination of Suckless Init (for the
 PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore
 for the process management. I have a daemontools service running
 dhclient in the foreground (like all daemontools managed daemons). As
 you know, dhclient takes between what, 3 and 20 seconds to get an IP
 address, so in my LittKit ordered startup script, I have a loop to
 detect when there's an IP address, and stall til one appears.

 If dhclient had seen fit to inform us of a DHCP lease aquisition in a
 way other than backgrounding itself (a feature I don't use because
 within daemontools I run the program in the foreground), I could have
 detected that. Or possibly written LittKit to afirmatively kick off a
 process when all its dependencies are met (and you would be right: that
 would be more than is necessary).

man 8 dhclient:
-sf script-file
Path to the network configuration script invoked by dhclient
when it gets a lease. If unspecified, the default
/sbin/dhclient-script is used.

Busybox udhcpc and toybox dhcp use -s for this.

You could use the script to start the network tools directly, or write
some indicator that lets the process manager start spawning network
programs.

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

Re: [Dng] Readiness notification

[Isaac Dunham]

On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote:
 On 12/06/2015 22:21, marc...@welz.org.za wrote:
 The trick is for the daemon process to only background when
 it is ready to service requests (ie its parent process exits
 when the child is ready).
 
  This is bad design, for several reasons...
  The reasons why it's bad are mostly described here:
  
 http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html
 
  Your solution enforces forking, i.e. auto-backgrounding, and
 prevents logging to stderr; in doing so, it prevents daemons from
 ever being used with a supervision framework. systemd may be able
 to supervise it, using cgroups, but that's about it, unless the
 admin is using foreground hacks.

  Moreover, the method you are using to transmit one bit of information,
 i.e. readiness of the service, is *the death of a process*. This
 is pretty heavy on the system; a simple write() does the job just
 as well, and hundreds of times faster.

I think that a program that must run in the background is broken.
Yet *prohibiting* auto-backgrounding imposes an even more heavy toll
on scripts where process 1 requires process 2 to be running and
ready: you *must* run a supervisor, or else run a lame-not-quite-a-
supervisor, just to do what would have been trivially done in a few
more lines of C.

While I haven't written the code yet, it strikes me that it should
be trivial to write something that can handle both styles of
notification, and maybe even share some of the code.
Essentially, part of the auto-background code becomes a trivial
not-quite-a-supervisor that exits as soon as it receives the same
notification that you use.
In the example, I'd want an option like -S fd, where fd
is the fd that goes to the pipe the supervisor is listening to.

Pseudocode for this without proper error checking:
  int pipefds[2];
  pid_t pid = 0;
  parse options;
  if (supervised) {
pipefds[0] = -1;
pipefds[1] = supervisor_fd;
  } else if (background_option) {
pipe(pipefds);
pid = fork();
if (pid  0) {
  error_exit();
} else if (pid  0) {
  //close write end of pipe and watch read end till the pipe closes
} else /* if (pid == 0) */ {
  //close read end of pipe
}
  }
  // setup process
  if (supervised || background_option) {
write(pipefds[1], 1, 1);
close(pipefds[1]);
  }


Thanks,
Isaac Dunham

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

Re: [Dng] printing (was Re: Readiness notification)

[Isaac Dunham]

On Sun, Jun 14, 2015 at 07:39:37AM -0400, LM wrote:
  Hendrik Boom wrote:
  I think that Brother is one of the companies that advertises actual
  Unix support, and that my printer an HL-3170CDW, at least, accepts a
  variety of networked protocols, including some that originated in Unix.
  But I don't know how to access them without CUPS.
 
  There must be a way.
 
 I've had a lot of problems with getting hardware working properly with
 Linux, so when I bought my last printer, I tried to do some research
 on what printers had support for Linux.  As mentioned, Brother
 advertises support.  So, I ended up buying my first (and probably
 last) Brother printer.  Besides the fact that the model seems to have
 an issue with the ink and stops printing often, I found out that the
 drivers are proprietary.  There are rpm and deb versions of the driver
 (in binary format) and I've seen some information on how to get them
 to work with systems like Slackware that need tarballs.  However, if
 you're running with a different processor or using a different C
 library like uclibc (which I was at one point) or musl, you're going
 to have issues.  The way I've seen FreeBSD users get Brother printers
 running is to run Linux versions of printing software using their
 Linux compatibility layer.

brlaser (github.com/pdewacht/brlaser) works for at least some Brother DCP
printers, and builds (with a very new compiler) on Alpine.
Requires the cups development libs.

For the more plain Brother printers, using the right PCL or Postscript
driver may be adequate; I know I got a couple HL-series printers
working with PCL (PCL5 drivers, IIRC).

 Postscript printers seem like the best option.  Similar to DOS
 systems, you can copy a binary file to lpt, serial, etc.
 Unfortunately, many printers these days are not Postscript compatible.
 PCL seems like the most supported format after Postscript.  That's
 where programs like GhostPCL come in.  A lot of printers support the
 wingdi format which is based on Windows GDI (graphic device interface)
 API.  I've only seen a few projects that try to support that on Linux.

 Cups may be a great solution for a corporation or a situation where
 printers are networked.  I think it can be overkill for a single user
 with a dedicated printer.  As mentioned, Cups does work on BSD and
 Apple systems so the systemd dependency should not be a real issue.
 It seems to be used as the default printing option on most Linux
 systems I've looked at.  It would be really nice to have some viable
 alternatives for users who don't need all the features Cups can
 provide.  I like the idea of trying to avoid monopolies in
 libraries/programs.  Cups seems to be a monopoly on most systems at
 this point. 

CUPS is a lot more basic in functionality than it looks: 
a meta-driver for conversions from format to format that ultimately goes
(any format)  PostScript/PDF  (printer-specific format),
plus a queue manager and a way to copy files to their destination.

LprNG does the same thing, but has a much more limited set of drivers
available; the Brother binary drivers do support lprng.

XPrint is no longer really supported by anyone, though RedHat does
include it in their latest RHEL version; it's a daemon that runs on
top of a printing daemon, and provides something along the lines of an
X server rendering to paper. It was easy to add pixel perfect
WYSIWYG printing to X applications, but the maintainers found the
code unpleasant and it was otherwise unappreciated...
 
 GhostPCL isn't in the Debian archives and I believe the reason might
 be because the GhostPCL build scripts were not designed to allow use
 of system libraries in place of their packaged third party libraries.
 It would be nice to find another alternative, but if nothing efficient
 is available at this point, I've been considering creating alternative
 build scripts that would use system libraries whenever possible.  I'm
 pretty sure if alternative build scripts are used, the GhostScript
 project would not want anything to do with support.  One would have to
 check for/submit bugs on their official versions.  It would at least
 be one alternative for printers that used PCL instead of Postscript.

GhostPCL, GhostScript, and related projects are not named for the
output, but the input: you do not need GhostPCL unless you want to
view PCL files.
GhosScript can output PCL, which is all you need for printing.

GhostPCL was dropped from Debian because it included (and required)
non-free fonts.
Artifex Software (the company that wrote and maintained both) has since
merged it with GhostScript (GhostPDL), though I'm not sure what the
license deal is.

There were a few forks of GhostScript, though AFAICT Ghost Trap
is the only active one.

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

Re: [Dng] straw poll, non-free firmware for installers

[Isaac Dunham]

On Fri, Jun 05, 2015 at 01:13:51AM +0100, KatolaZ wrote:
 Maybe I am the only one unable to see the problem in asking the owner
 of hardware which requires some essential non-free firmware during
 installation to put the required firmware on a USB stick during the
 first boot. If the user has got a way to burn a net-install cd, then
 he almost surely has no problem into plugging a USB stick on that
 other computer and copying one file therein

Because maybe the user doesn't have a free USB stick available?

No, I'm not coming up with theoretical problems:
When I was taking courses at the university, there was a smallish LUG
there, with its own club room, a few desktops, and a table.
Standard practice for installing distros was bring your laptop, and there
was a single shared flash drive that stayed in the room as installation
media: to install a distro, someone downloads a hybrid ISO, dd's it
to the flash drive, and then you boot from it.
There was no second flash drive for installing, and frequently no one
brought their own flash drive: almost everyone had a login on the
university servers, where they could store almost anything, and 
course work was available via an online portal.

In short, there was usually only the flash drive that the CD was written to.
 
 From a legal point of view, I would also carefully refrain from
 redistributing any non-free firmware in Devuan, the main reason being
 that usually you *don't* have the right to redistribute it, and even
 if you have got this right from the HW constructor, such right can be
 withdrawn any moment at their own will, which might be a quite
 unpleasent surprise for Devuan...

There is a *very* large set of non-free firmware for which at least your
first claim is false, and for much of it the second is false as well.
I've actually read several of the licenses in firmware-linux-nonfree.

b43 is/was a notable exception, getting it the b43-fwcutter package...
which leads me to mention something else:
The criteria for something getting into debian non-free require your
claims to be false for that package, if it isn't a downloader or
installer.

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

Re: [Dng] straw poll, non-free firmware for installers

[Isaac Dunham]

On Wed, Jun 03, 2015 at 08:37:22PM +1200, Daniel Reurich wrote:
 Hi,
 
 I'd like a straw poll on whether we should include non-free firmware in our
 installers by default.

I would like to see essential installation-related firmware available
on the installer media if it is properly redistributable.

To elaborate:
- Only firmware without which the installition *cannot* proceed are
covered.
Disk and RAID firmware can be downloaded from the installer, but
making network firmware unavailable renders the installer useless
to the user.
Having to use VGA, VESA, or fbdev is not covered.

- Non-free drivers are not covered.

- I am *not* endorsing any changes to the defaults that the installer 
proper has, or to the settings of the installation.

- Available on the media technically includes have a udeb in some
folder, and if that folder can be discovered I think that's enough.

- Only firmware subject to a license allowing *anyone* to redistribute
it, including on commercial media, is permitted.

- In my humble opinion, it would be nice if the user had to manually
enable said frmware (and could do so after checking that a lack of
firmware caused a lack of working networking).

Now, some comments on other comments...
* If you're sending messages from your Windows phone, we already
know where you stand. No need to repeat it three times.
* The question is whether to change what's available on the installer,
not whether to install nonfree firmware on systems by default.

...and on Daniel's later proposal:
* A useful tool would be one that recurses through 'lsmod' output,
using modinfo -F firmware and a file-package lookup to determine
what packages are relevant.
Conceptually, this *could* determine whether you're dealing with
networking hardware.
Additionally, one could scan for 'modalias' entries that are unclaimed,
and find the required module/firmware.

* Ideally, any change in installer behavior would be limited to advising
the user about missing firmware and loaded drivers that require non-free
firmware.
I'd want it to say something along the lines of this (sample based on
my currently non-operational X100e):

 The following drivers that are loaded use non-free firmware:
 DRIVER PACKAGE
 r8192sefirmware-realtek
 ...
 Some loaded drivers request uninstalled firmware:
 radeon firmware-linux-nonfree
 Some drivers have not been loaded, and require unavailable firmware:
 ...
 If you wish to obtain full functionality from these devices, it may
 be necessary to enable non-free packages.
 In some cases, drivers will work without the firmware.
 You may prefer to not use the hardware in question due to the
 proprietary licensing or for other reasons.
   [Continue]

The last sentence is an abbreviated version, but should give you
the picture.
The point is to give users the knowledge that this hardware would
need such-and-such, without glossing over the fact that there are
downsides to selecting it.

This should be information presented before the user selects repos
to enable.

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

Re: [Dng] automounting in a window manager

[Isaac Dunham]

On Sun, May 31, 2015 at 07:57:47AM +0800, Robert Storey wrote:
 With all the recent discussion about DEs (Cinnamon, Gnome, Mate, etc), I
 just thought I'd throw this in here...
 
 For the longest time, I simply used a window manager. In the beginning, it
 was FVWM, but later I took a liking to IceWM. As opposed to a full-blown
 Desktop Environment, I liked the speed and simplicity of a window manager.

I use IceWM, and also FVWM1 (on my sparta devuan-with-mdev install).
I prefer the simplicity, and I enjoy having something faster than *any*
desktop, xfce included.

 The only drawback is that window manager doesn't seem to do automounting of
 plugged-in devices. I went looking for a solution, and found this page:

In my book, that's an advantage.
Of course a significant percentage of the times that I plug in a USB
device I'm trying to repartition it.

 https://awesome.naquadah.org/wiki/Automounting
 
 It says, among other things, that udev can be configured to handle
 automounting. That's nice, but since systemd has polluted udev beyond
 repair, I'm wondering if Devuan can be set up to handle it better, perhaps
 with vdev. Or is there a better way?

Use mount ;-)
Locally, I sometimes use a script I named mat, which mounts a device
(shortname) at the usual location, creating the mountpoint if needed.
This isn't the version I use, but it gives you the idea:

#!/bin/sh
[ -b /dev/$1 ] || exit 3
mkdir -p /mnt/$1 || exit 2
mount -o users,rw /dev/$1 /mnt/$1


Something like this could be run from mdev as a helper when a partition
is detetected, or you could use mount -a -T /etc/autotab, or you could
use a hotplug helper along the lines of

#!/bin/sh
[ -n $DEVTYPE -a  $ACTION = add ] || exit
mkdir -p /mnt/$DEVNAME
mount -o users,rw /dev/$DEVNAME /mnt/$DEVNAME

Or you could parse the output of nlmon...

There are no shortage of ways to set it up.

 I believe that people who are opposed to systemd are similar to me - we
 prefer simplicity over complex solutions, and are not impressed by bells
 and whistles. Thus, I think people who are attracted to Devuan would be a
 good market for a simple desktop based on IceWM.

True.
However, we're often able to set it up ourselves.

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

Re: [Dng] I want to mount a Packages page, buildd and Wanna-build system

[Isaac Dunham]

On Tue, Jun 02, 2015 at 01:00:12PM -0500, APT Gatuno MX wrote:
 El 31/05/2015 8:23 pm, Franco Lanza escribió:
 
 Hello Felix,
 if you can also donate a VPS to the project, this would be great.
 
 So, if you can do that, please do it and just let me know the
 ip address and the hostname you want to have and i will setup the
 devuan.org subdomain on our dns.
 
 If you can't do that or you think is better we host this machine,
 in few
 days i will give you a machine with ssh access to do the work.
 
 The repository to be used is packages.devuan.org/merged [suite] main
 [contrib] [non-free]
 
 Ok. There is a working Devuan packages at packages.devuan.gatuno.mx

Thanks!
Seems to work well.

However, I'm wondering about something that's tangentially related but
perhaps not part of the same code:
Does anyone know what it takes to make Aptitude support downloading 
changelogs from non-Debian packages?


Thanks,
Isaac Dunham

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

Re: [Dng] OT: separate GUI from commands

[Isaac Dunham]

On Sun, May 31, 2015 at 12:19:51PM -0400, Hendrik Boom wrote:
 On Thu, May 28, 2015 at 07:16:55PM -0700, Isaac Dunham wrote:
  On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote:
   On 27/05/2015 12:12, Hendrik Boom wrote:
   I'm in the process of writing (yet) a(nother) editor and output 
   formatter,
   and on reading this, I started to wonder -- just how could one separate
   a command-line version from the UI?  I can see that the output
   formatter can be so separated (and very usefully), but the actual
   editing?
   
Maybe I'm misunderstanding the question, as I'm unfamiliar with the
   internal of editors. But IIUC, an editor is, by definition, a user
   interface, so the command-line / UI separation looks impossible or
   irrelevant to me here.
However, there are still some separations that you can perform when
   designing an editor. Right off the top of my head:
- Core functions vs. actual interface, which could be terminal-based
   or X-based. Think vim vs. gvim, or emacs -nw.
- programmable editor commands vs. interface to enter those commands.
   Think the sed engine in vi, or the LISP engine in emacs.
   
If you factor your work correctly, it should be trivial for a program
   to get access to your editor commands via a library function call - and
   you can make a command-line tool to wrap useful calls. Also, there could
  
  nvi (the Berkeley rewrite of vi, after abandoning their first version)
  uses a shared backend (vi-ipc) connected to the frontend via pipe().
  There are about four frontends: terminfo-based (curses was derived
  from the code for this), tk, motif, and gtk.
  I ended up finding out this as a result of making the motif frontend
  build/work again.
 
 Thanks.  I should probably look into that.  It might be illumination.
 Which version of the code or inteernal documentation should I be 
 looking for?  And where?

I think what I used was http://repo.or.cz/w/nvi.git, and the vi-ipc code
is in ipc/.
However, I'm not seeing much of anything by way of documentation.

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

Re: [Dng] OT: separate GUI from commands

[Isaac Dunham]

On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote:
 On 27/05/2015 12:12, Hendrik Boom wrote:
 I'm in the process of writing (yet) a(nother) editor and output formatter,
 and on reading this, I started to wonder -- just how could one separate
 a command-line version from the UI?  I can see that the output
 formatter can be so separated (and very usefully), but the actual
 editing?
 
  Maybe I'm misunderstanding the question, as I'm unfamiliar with the
 internal of editors. But IIUC, an editor is, by definition, a user
 interface, so the command-line / UI separation looks impossible or
 irrelevant to me here.
  However, there are still some separations that you can perform when
 designing an editor. Right off the top of my head:
  - Core functions vs. actual interface, which could be terminal-based
 or X-based. Think vim vs. gvim, or emacs -nw.
  - programmable editor commands vs. interface to enter those commands.
 Think the sed engine in vi, or the LISP engine in emacs.
 
  If you factor your work correctly, it should be trivial for a program
 to get access to your editor commands via a library function call - and
 you can make a command-line tool to wrap useful calls. Also, there could

nvi (the Berkeley rewrite of vi, after abandoning their first version)
uses a shared backend (vi-ipc) connected to the frontend via pipe().
There are about four frontends: terminfo-based (curses was derived
from the code for this), tk, motif, and gtk.
I ended up finding out this as a result of making the motif frontend
build/work again.

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

Re: [Dng] Which source version fo systemd are you stripping code from?

[Isaac Dunham]

On Fri, May 08, 2015 at 11:40:28AM +1000, Alex 'AdUser' Z wrote:
  Netplug, NetworkManager, inetd, xinetd, dhcpcd, and dhcp(client) to name a 
  few already did the same work.
  Netplug is possibly the lightest weight of them all and provides
  connectivity device management as well as net connectivity service.

netplug and ifplugd provide essentially the same functionality; ifplugd
(written by Lennart several years ago) is the more widely used one as
far as I can tell, and there's a small version of it included in Busybox.

I'd be unsurprised if Lennart started thinking in terms of all the
projects he'd done and decided to roll everything that has some
association with initscripts/sysvinit/the minimal boot profile
into one package.

 FYI, there is (was?) another alternative:
 https://bugzilla.redhat.com/show_bug.cgi?id=195365
 
 Known problems:
 
 * highly relies on initscripts package
 * almost undocumented, official wiki page is compilation of comments
 from sources.
 * used in only one distro (AltLinux)

http://git.altlinux.org/people/sbolshakov/packages/?p=etcnet.git;a=summary
That's about all I could read of www.altlinux.org/etcnet (said page
is Russian).

Last changes were the start of this year.

Reading the docs/ dir, I see that the READMEs are almost all how to do
something you already know how to do, using this package.

etcnet.8 seems to be *almost* enough to get started;
etcnet-options.5 is almost enough to do something;
but the real documentation is in examples/.
Unfortunately, there's no example of how to do wireless via WPA.

I also see that it's meant to work with the hotplug scripts, and that it
amounts to a different way to configure ifup.

Thanks,
Isaac Dunham

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

Re: [Dng] why someone might want systemd on devuan

[Isaac Dunham]

On Tue, May 05, 2015 at 09:17:28PM +0100, David Harrison wrote:
 On 05/05/2015 20:43, dng-requ...@lists.dyne.org wrote:
 Well, the problem here is that systemd is*not*  hot-pluggable, at all,
 as we have recently learned the hard way.
 
 Here's a thought. Thrown to the list with no requisite knowledge to back it
 up, so please don't bite!
 
 Is there any way of building a package or some other installable to create a
 sandboxed/containerised/quarantined/VM'd minimal systemd? That's if minimal
 isn't a contradiction in terms where systemd's concerned? Just complete
 enough for a user to install and use contaminatedware within it, when they
 really have no other choice, but designed not to leak out and infect their
 otherwise clean system?

I'd imagine this would be best done via debootstrap install of Debian
and some script that can properly configure the result as a VM/container
(if it's even possible to use systemd in a container).

HTH,
Isaac Dunham

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Isaac Dunham]

On Tue, May 05, 2015 at 08:44:22PM +0200, Anto wrote:
 
 On 05/05/15 18:52, Noel Torres wrote:
 
 As a resume: If you want a systemd-free system, Devuan is your
 distribution, and will always be. But if you want a system designed to be
 unable to run systemd, please leave us. This is not the place for such an
 anti-freedom POV.

 Do you understand the impact on what you wrote?
 
 How much efforts will that be to support systemd *without* any locked-in? I
 believe this is what you meant, because Devuan will be exactly the same as
 Debian if the support for systemd would also force the locked-in of a lot of
 packages. And unless the number of Devuan developers will be as many as
 Debian developers, I think you are just dreaming.

I think an overview of the different levels of systemd dependency
is in order to clarify what's under discussion.

Level 0:
On paper, systemd can boot a system even if everything else is
completely unaware of it. (This was an important part of how it got
anywhere to begin with.)
This gives almost exactly the same functionality as sysvinit, since
it uses init scripts.

Level 1:
If someone wants to use the dependency resolution that systemd has,
they need to have a configuration file for the software that specifies
how to start it and what needs to happen first.

Level 2:
The systemd maintainers claim that writing applications to use systemd
gives the users a better experience or some such garbage; this usually
means a run-time dependency on libsystemd. Such software usually can
still run if systemd is not PID 1.

Level 3:
A few programs require a DBUS method or similar thing tht must be
provided by systemd at runtime.

It's settled that we don't want *anything* to be at level 2 or higher
integration.

Now, what's under discussion is whether we are OK with *not* rebuilding
packages that are at level 1.

This does not mean adding systemd to the repository, it does not require
supporting systemd, it does not mean that we add service files to
anything: all that it means is we decide that we can ignore configuration
files, when there's no dependency.
Remember: a configuration file can be modified as the user wishes, or
even deleted, and the package manager will respect the user changes.

I read Noel's comments as being in favor of leaving whatever is at
integration level 1 alone, so that *if* someone decides that *they*
want to install systemd on their system, we don't make it harder
than necessary. This does not require that *we* should test it, just
let things remain (without any support from us).


I'd think that this is OK, apart from the question of whether all
packages can be rebuilt on a Devuan system.

Thanks,
Isaac Dunham

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

Re: [Dng] Which package generates /lib/systemd and /etc/systemd files?

[Isaac Dunham]

On Tue, May 05, 2015 at 11:53:30AM -0400, Steve Litt wrote:
 Before we get too deeply into this whole thing, what was the original
 question? What exact thing are we arguing whether or not to include in
 Devuan?

Whether or not we need to rebuild packages that have .service files so
they will not be installed.
A .service file is a configuration file exactly analogous to an init
script.

I would argue that a configuration file is not enough justification for
a rebuild in itself unless it trigggers harmful behavior, and the proper
solution for those who want to be shed of them is to create a trigger for
dpkg which will run rm -rf /etc/systemd...

HTH,
Isaac Dunham


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

Re: [Dng] Linux boot documentation

[Isaac Dunham]

On Tue, May 05, 2015 at 12:29:59PM +0200, Jürgen Buchmüller wrote:
 Am Dienstag, den 05.05.2015, 11:22 +0200 schrieb Didier Kryn:
  I'm not sure what happens if init crashes after other processes have
  been started, wether the kernel panics or other processes continue
  without init - not a very good situation.
 
 FWIW: I've seen this happening with a home grown jessie (RC2) for
 Cubietruck (armv7hf) where a module was seriously broken and led to a
 segfault.
 
 Since with systemd modules seem to be loaded by pid 1 itself, the crash
 takes down systemd with it and the system reboots after exiting pid 1,
 just crash again when trying to load the broken module the next time. No
 chance to break out of this loop AFAIK.
 
 To me this looks like a fundamental design flaw. A crashing module
 should never _ever_ take the whole system down. There has to be some
 privilege separation and signal handling in place to prevent that.
 
 With SysV init this is no big problem, as usually some child process of
 init (a shell script) loads the detected (udev rules) or defined
 (/etc/modules) modules and if it crashes, init will still be alive.

I presume module == kernel module.
A module is never run in the same context as the process that loads it.
It is a part of the kernel, and thus runs in the kernel context.
If it crashes, it crashes the kernel or the associated device disappears.

By default, udev automatically loads non-blacklisted modules based
on the hardware it detects.
On a systemd-based system, udev is mandatory; it is not a part of pid 1,
though it is built from the systemd source.

If you can figure out what module is causing the crash, you can blacklist
it.

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

Re: [Dng] Linux boot documentation

[Isaac Dunham]

On Mon, May 04, 2015 at 10:48:06AM -0400, Steve Litt wrote:
 Hi all,
 
 I just documented the boot process, from Grub through init.
 
 See http://troubleshooters.com/linux/diy/howboot.htm
Comments/contributions for a few sections.

The Bootloader:
I can elaborate a little on grub stuff, though I'm most familiar with
grub4dos-chenall (a fork of a fork of grub legacy) rather than grub2.

set root=(hd2,msdos1) or root (hd0,8) specify the filesystem that
all file paths are relative to.
So these stanzas are theoretically both ways of loading /boot/bzImage
and /boot/initrd.img from /dev/sda9 (grub legacy):

root (hd0,8)
kernel /boot/bzImage root=/dev/sda9
initrd /boot/initrd.img

kernel (hd0,8)/boot/bzImage root=/dev/sda9
initrd /boot/initrd.img


With grub legacy and derivatives, (hd0,0) is the first partition (,0)
of the first harddrive (hd0).
Partitions are numbered in the same order as Linux orders them
(under most circumstances).

Grub2 has switched from a 0-based index to counting partitions, but
still counts hard drives from 0:
(hd0,msdos1) is the first partition on the first hard drive;
the msdos presumably indicates the partitioning scheme.

The Kernel's Role in Booting:
If you have a kernel with enough stuff builtin (drivers for your disk
controller like ata_piix, block device drivers like sd aka sd_mod,
*and* a filesystem driver for / like ext4 or xfs), you can boot without
an initramfs, by disabling initramfs support when you compile the kernel
or by booting with noinitrd.
In this case, the kernel mounts the filesystem you specify with root=...,
mounts devtmpfs on /dev (if you configured it to do so at compile time),
and executes /sbin/init* or the executeable specified with init=...
(must be an absolute path; symlinks work, as long as it's on the
same filesystem and resolves to an executable binary of ELF/A.OUT format,
or a script with a shebang line that resolves to such a binary).

*To be pedantic, the kernel actually executes the first init program
from a hardcoded list to be found; typically this is /sbin/init.

You can specify mount options for the root filesystem right after
root=...  in the kernel commandline.

As far as programs the kernel launches directly other than init go, I'm
aware of two:
First, on hotplug events: if kernel.hotplug is set to the path of an
executable, the kernel will run that executable with an environment
describing the hotplug event.
If the USB subsystem was involved, the first argument will be usb.
Second, on attempts to mount something with a specified filesystem type
or to access an OSS device when ALSA's OSS-compat layer has been
configured to preclaim them, the kernel will run 
  modprobe MODALIAS
where MODALIAS is some keyword generated from the device/filesystem/
underlying hardware (modinfo and /lib/modules/`uname -r`/modules.alias
are useful for finding out more about these).

The kernel also sends messages via the netlink layer to any service
that wants to listen.

The Role of the initramfs:
s/cnew/newc/
This is the SVR4 new ASCII-based format, commonly referred to as
newc. Spelling that out might be helpful.

One important yet obscure detail for preparing an initramfs is that
cpio does *not* create the ancestors of a directory automatically, and
the kernel requires all ancestors to be created before extraction;
if you add
./lib
./lib/firmware
./lib/firmware/radeon/R100_cp.bin
to the input list of files, the initramfs will have /lib/firmware but
/lib/firmware/radeon will be missing so R100_cp.bin will not be
extracted.

The On-Disk Init System:

Another init system is toybox oneit, which properly sets up a tty,
runs a process, and shuts down the system when said process exits.

busybox init is similar to sysvinit with the following exceptions:
-runlevels are not supported
-the tag in the first field is used as the name of a tty to run
a program on, so to set up a getty you usually do this:
tty1::respawn:/sbin/getty 38400 tty1

I would have described openrc differently:
 OpenRC competes with the various rc packages as a way to run init
 scripts (so sysv-rc, file-rc, and openrc are alternatives); it can
 even be used with systemd or upstart if you want to do that.
 Its main benefit is that you can write a basic script that acts
 like a standard initscript in just a few lines.

Minimal Process Management:

I'd suggest a couple changes to the wording of the list:
 1. *Mount* /proc and /sys
 2. Populate /dev; initialize drivers and create devices in response
to hotplug events (typically via udev, eudev, vdev, mdev)


On the whole, it's a fairly good overview.

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

Re: [Dng] [dng] vdev status updates

[Isaac Dunham]

On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote:
 On Sun 03 May 2015 11:15:45 Laurent Bercot wrote:
  I remember 10ish years ago, mount was actually /sbin/mount.
  It migrated to /bin at some point, probably, as you say, when the
  user mount option was added. I personally think that moving
  executables between places is a bad thing, and one of the reasons
  why I'm not a fan of /sbin.
 
 Easy!
 in your dream distro you have no directory tree at all and place *all*
 files into root ;-) Never again you have to move a file to the place
 it belongs to (just kidding). Unless you follow that radical approach,
 any sort of meta info no matter which type attached to an item will
 eventually need update when the semantics of the item changes. 

Strawman! (I suppose that you jest.)

This *has* been done before, on a certain *very* minimalist
system that was vaguely and indirectly inspired by *nix.
You just had to make sure that you had the correct root filesystem
in the floppy drive.
QDOS/PC-DOS/MS-DOS 1.x is the system referred to. 


Now, regarding Laurent's argument that containers obsolete the concept
of some utilities being useless for users:
One of the major uses for containers is to isolate potentially vulnerable
programs from the rest of the system.
Now, suppose one has a possibly vulnerable webserver in a container with
its own network configuration.
Suppose that someone gets a shell (as whatever user the webserver is
running as); would denying them the ability to modify network state be
useful?

This doesn't establish that /sbin is useful, but the concept of having
a limited set of users be able to utilize a program is likely to remain
relevant even with containers, unless you can set them up so that all
administration takes place externally.

A possible use for /sbin on a non-containerized system is to bind-mount
an empty directory over /sbin/ in a private mount namespace for all
non-administrative users.


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

Re: [Dng] Debian Dev: anti-systemd people hate women; thus respectable people should not support anti-systemd stance.

[Isaac Dunham]

Well, I'll comment on a couple points, since the material you quoted
is rather misleading at best.

Full disclosure:
My only associations with the VUA are (1) subscribing to this list;
(2) using the devuan repositories, and (3) having an account on the
devuan gitlab, which I have only used to mirror a single repository
containing packaging for mdev.
I have used Debian and Ubuntu in the past, but I was only active in
the Debian User Forums, the Ubuntu Forums, and on Launchpad (I have
not been involved in Debian development beyond commenting on/filing
a very few bug reports, but would be technically capable, as I've
had a couple PPAs).
I am also involved in multiple unrelated projects where the community
is decidedly opposed to systemd (musl, busybox, toybox, puppy), and
in one where there are multiple technical barriers to using systemd
(Alpine Linux: grsec is the default kernel, musl is the libc).

* The laptop for a developer (pieced together from personal knowledge
 and comments here):
 Dima Krasner (Iguleder on the Puppy Linux forums) describes himself
 as an independent RD freelancer; he has done a lot of work related
 to Puppy Linux, including Debian-based editions of Puppy.
 He was *not* one of the original VUAs or other participants in
 the fork process.
 His latest project before Devuan was announced was a vaguely Puppy-like
 independent distro, built from source for i486/32 megabyte systems
 (it may have been 20 megabytes minimum):
 in other words, aimed at *bare minimum* hardware.
 I can't tell for sure what hardware he had, but I would be rather
 surprised if it was significantly over 1.6 GHz (based on the minimal
 specs he was aiming at).
 As soon as the Devuan fork announcement was out, he started working on
 a stub library, then came up with a shim to use software compiled for
 logind with consolekit2 (loginkitd)
 The most productive approach for testing system software is to fire
 up a vm, which can be *extrememly* slow with limited hardware.
 Possibly for this reason, the VUAs agreed to get him a new laptop for
 testing and development of loginkitd.

* MikeeeUSA:
 There have been occasional posts from some individuals which
 resembled MikeeeUSA's rants.
 Said individuals have been flamed, banned, or possibly ignored; the
 first such poster accused the list in general of being SJWs, and
 tried to flame me when I requested that he moderate his language,
 saying that the New Testament was feminist. (In case you don't see
 the irony, I'm a Pentecostal/Fundamentalist Christian, and am
 generally disgusted with most feminists...and all MRAs.)

 There have also been some posts in technical threads directing
 vulgarities at systemd and its supporters as such; the reaction to
 these has varied from ignoring or *lightly* criticizing them to
 full agreement. Personally, I wish that this would stop: obscenity
 says litle beyond who the speaker is, especially about the target,
 though perhaps it's excusable to acknowledge the stupidity that
 some code has. (Insult the *code* if needed; not the coder, and even
 more certainly not the users.) I try to delete mails and threads that
 end up like this.

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

Re: [Dng] [dng] vdev status updates

[Isaac Dunham]

 and hooks/.


 * (long-term) does the above in a way that is agnostic to the device
 manager, since there are real-world use-cases for selecting mdev or a
 static /dev/ over udev or vdev.
 
 (That last point is why I'd like to work on making it possible to select a
 device manager via the alternatives system--the user should be able to pick
 whatever device manager they need, but without having to jump through all
 these hoops).

I doubt that you could make the device manager safely selectable via
alternatives, unless you install the interchangeable files in 
/lib/hotplugger/, have that selectable via alternatives, and have
everything that can conflict symlink into /etc/alternatives/device-manager/
or a directory that symlinks to that.

This is needed because otherwise, you are inviting an inconsistent state
that can render a system unbootable.

For example, this might be udev/mdev/initramfs-tools:
/lib/udev-rd:
devmanager-hook
devmanager-top
devmanager-bottom

/lib/mdev-rd:
devmanager-hook
devmanager-top
devmanager-bottom

/etc/init.d:
udev
mdev

/usr/share/initramfs-tools/hooks/devmanager -
/etc/alternatives/rd-dev-manager/devmanger-hook
/usr/share/initramfs-tools/scripts/init-top/devmanager -
/etc/alternatives/rd-dev-manager/devmanager-top
/usr/share/initramfs-tools/scripts/init-bottom/devmanager -
/etc/alternatives/rd-dev-manager/devmanager-bottom

An alternative is just have udev/vdev/mdev all Provide:/Conflict: 
device-manager,
and initramfs-tools can depend on that; but this is clumsy.

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

Re: [Dng] Story: Debian Jessie laptop without systemd

[Isaac Dunham]

On Sun, Apr 26, 2015 at 11:03:07AM -0400, Steve Litt wrote:
 The route I've taken, so far, with experimental machines initting with
 sysvinit, OpenRC, Epoch and Runit, was to remove as much desktopism
 as possible. This isn't for everybody, but it works for me because I
 never did like the high degree of desktopism that Xfce delivers.
 
Desktops seem to aggregate a bundle of software that attempts to meet
most of the major needs of most users, of necessity implying bloat
(because it isn't tuned to what *a* user needs, it has features that
each user will find useless). But generally the desktop-specific tools
I've used seem to lack features I want.
For a while, I used bits of LXDE, and that worked. But the most useful
tools I've found are almost all independent projects:
icewm, vim, nedit, xterm/urxvt, worker, mc, mtpaint/pixmap, links2, Ted,
magicpoint...
In contrast to that I have only gnumeric.

 My experience is that, on systemd-equipped distros on which you've
 installed an alternate init, NetworkManager isn't worth the heartache
 it takes to set up. Running the Wicd daemon and using the Wicd-gtk
 client is an alternative that takes more keystrokes. Alternatively,
 some day I'm going to create an nCurses equivalent of NetworkManager,
 but not any time soon.

Some you might be interested in: wicd-curses, ceni, or my own lame
wpanet (github.com/idunham/wpanet; it's got a rudimentary dialog
interface for generating and extending wpa_supplicant.conf that should
be able to use xdialog or whiptail).
The configuration part was not the point of wpanet; it was about
starting wpa_supplicant and a dhcp client without relying on sleep,
but there is an interface that I hope is fairly clear.

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

Re: [Dng] Fwd: [dng] vdev status update

[Isaac Dunham]

On Sat, Apr 18, 2015 at 12:08:54AM -0400, Jude Nelson wrote:
[snip]
  I am still using file-rc instead of sysv-rc, but I didn't clean up
  /etc/rc?.d directories. I tried to use sysv-rc, but my mouse and keyboard
  are not being detected when using kernel 3.18.11. They are only being
  detected on kernel 3.2.0 from wheezy repository. I think there is something
  wrong with my kernel config but I will investigate that later.
 
 
 Not sure yet what could be the cause of your keyboard and mouse not
 working.  Let's see what happens after you fix steps 3 and 4--it could be a
 side-effect of the init program being broken, since the init program should
 also run the console setup scripts.

To spare you a bit of experimentation:
The only thing that needs to happen for a standard keyboard or mouse
to work on a VT is the driver loading.
The driver for USB keyboards (and USB mice) is usbhid; I think 'hid'
is the driver for non-usb keyboards. 'evdev' is needed for some X
drivers to work right.
...
However, this reminds me: Busybox 1.23.0 and 1.23.1 had a bunch of
different issues with modprobe/depmod, and should not be used.

If you want to use a non-standard keyboard layout or a different font
or resolution, then you need a script for console settings (and a
framebuffer driver and fbcon).

HTH,
Isaac Dunham


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

Re: [Dng] [dng] vdev status update

[Isaac Dunham]

On Tue, Apr 14, 2015 at 07:40:41PM +0200, Anto wrote:
 On 14/04/15 17:48, Jude Nelson wrote:
 I'm using it as the device manager in my copy of the alpha Vagrant image,
 and others have tested it locally (but not for booting, AFAIK).??  I'm
 working on getting it to boot the the qcow2 image, which boots from LVM.
 
 Thanks,
 -Jude
 
 
 Thanks Jude,
 
 I am not sure if at this stage, it is worth it to report the problems that I
 have just experienced.
 
 I followed your 3 steps instruction to have vdev on the PC that I am
 currently using for writing this email (HP EliteBook 8530w), and
 surprisingly it does not work (yet) :)
 
 Before anyone ask: no, this is not a production PC as I have been beating
 it up so bad in the last 3 years since I got it used from the company I work
 for.
 
 In the grub.cfg, I used the same set of files as the ones from the running
 kernel generated by update-initramfs, except the initrd that I took from the
 example directory under vdev source directory.
 
 It booted the initrd, but just ended up on the (initramfs) prompt. It is
 hard to get the error messages during boot. I tried to record them using my
 mobile phone and the messages at the beginning are the following:
 
 Loading, please wait...
 /init:  line 175:  resolve_device:  not found
 00071:859055872:  [  vdev.c:0425]  vdev_init:  ERROR:
 vdev_config_load('/etc/vdev/vdevd.conf')  rc = -2
 00071:859055872:  [ main.c:0042]  main:  ERROR:  vdev_init rc = -2
 
 some messages that are too fast to be captured

Not being very familiar with vdev, I can't tell you what this means beyond
that something didn't get copied or ended up in the wrong place.

 The last messages that I could see on the screen are about modprobe:
 modules some modules not found in modules.dep.
 
 If you needed more information, I am quite happy to provide them.


This sounds like what I ran into with mdev.
https://github.com/idunham/mdev/blob/master/hooks/mdev-hook, last two lines:
# Apparently, this somehow only gets copied if udev is installed.
copy_modules_dir kernel/drivers/scsi

The directory where that is would probably be helpful for integration
with initramfs-tools; it's what I worked out for making mdev replace
udev.

HTH,
Isaac Dunham

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

Re: [Dng] [dng] vdev status update

[Isaac Dunham]

On Tue, Apr 07, 2015 at 05:22:55PM -0400, Jude Nelson wrote:
report every kind of device, since it listens to the kernel's driver
  core
(i.e. libudev learns about network interfaces, buses, power supplies,
etc.--stuff for which there are no device files
 
  Currently, it doesn't *report* devices; that takes something longer term,
  like inotify, polling a netlink socket, or listening to a daemon.
 
  It also has no clue about events or hardware that could not have a
  corresponding device, since it uses block/char and major:minor to find
  the hardware.
 
  I have a general idea of how to get information like this, by recursing
  through /sys or /dev, and I know of some code I could use as a starting
  point, but I don't know what the ideal format is.
  If someone points me at a program they'd like to use without libudev
  (preferably C with minimal dependencies) that doesn't cover a lot of
  ground (ie, it's clear what functionality udev provides, and I wouldn't
  need to duplicate much of libudev to get it working), that would be a
  good starting point for expanding libsysdev.
 
 
 You might find something useful in vdev_linux_sysfs_register_devices() and
 vdev_linux_sysfs_find_devices() functions in vdevd/os/linux.c.  They're
 both involved in generating the initial coldplug device listing.  They only
 need libc to work, and libvdev/sglib.h for basic data structures.

I know how to get the devices that show up in /dev;
I'm not sure about getting the sysfs entries that *don't* show up there.
I'm also not sure how anything beyond this is used.

To avoid the troublesome corner case where a libudev client crashes and
potentially leaves behind a directory in /dev/uevents/, I would
  recommend
mounting runfs [1] on /dev/uevents.  Runfs is a special FUSE
  filesystem I
wrote a while back that ensures that the files created in it by a
particular process get automatically unlinked when that process dies
  (it
was originally meant for holding PID files).
  Hmm...
  Do we need to have a subdirectory of the mountpoint?
  Could you just use ACLs if you need to make a limited subset available?
  I get the impression that we can do this for mdev via a script along
  these lines:
 
 
  FILENAME=`env | sha512sum | cut -d' ' -f1`
  for f in /dev/uevents/*
  do env $f/$FILENAME
  done
 
  but it would be *nicer* if we only needed to write one file.
 
 
 I agree that one file per event is ideal (or even a circular logfile of
 events, if we could guarantee only one writer).  However, I'm not sure yet
 what a fine-grained ACL for device events would look like.  My motivation
 for per-client directories is that unprivileged clients can be made to see
 only its own events and no one else's by default (i.e. by chmod'ing the
 directory to 0700), and that they make it easy reason about sending
 post-processed events only to the clients you want--just change the list of
 directories to iterate over in that for-loop :)

Which is not trivial in shell, unless you have a special command to do
the work of figuring out which which directories get what.
...which seems to make doing this in shell pointless, since the
corresponding C is nearly as trivial.


  Also, wouldn't mounting that with runfs result in records of uevents
  getting erased if they're written by a helper rather than a daemon?
 
 
 Yes; good catch.  There are a couple straightforward ways to address this:
  (1) have a separate, unprivileged device-event-log daemon curate
 /dev/uevents/ and have the helper scripts forward device events to it, or
 (2) fork and/or patch runfs to allow files to persist if they're generated
 by a certain whitelist of programs (i.e. all programs in a particular set
 of directories, like /lib/vdev/), but disappear otherwise once the creating
 process dies.

What about (3) having an option for runfs that lets it erase directories
(with their subentries) on process termination, but lets regular files
persist until then?

 
 Thanks for your feedback!
 -Jude

You're welcome.

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

Re: [Dng] What about pulseaudio, avahi, ... ?

[Isaac Dunham]

On Thu, Apr 02, 2015 at 09:27:36AM -1000, Joel Roth wrote:
 On Thu, Apr 02, 2015 at 07:28:27PM +0200, Stephan Seitz wrote:
  On Thu, Apr 02, 2015 at 07:15:38AM -1000, Joel Roth wrote:
  On my system, reverse depends for pulseaudio shows such
  packages as mpg123, which shouldn't have an opinion about
  
  But mpg123 neither depends on nor recommends pulseaudio. It only suggests
  pulseaudio together with jackd, alsa-utils and other packages.
 
 Yes that is only a suggests relationship, so not a
 good example. Funny tho, it shows up as a reverse depends
 listed by apt-cache showpkg.
 
 initramfs-tools-tcos, OTOH, recommends pulseaudio.

For what it's worth, this makes sense to me. (Not that I like Pulse!)

initramfs-tools-tcos is about setting up an initramfs for a thin client...
which means that any audio programs will be running on the server,
while the user is at the thinclient.
In order for the user to get sound, they will need to have pulseaudio
or another network sound daemon running, and NAS isn't really active
anymore.

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

Re: [Dng] What about pulseaudio, avahi, ... ?

[Isaac Dunham]

On Wed, Apr 01, 2015 at 10:06:13PM +0200, Patrick Erdmann wrote:
 In my experience pulse should be optional. It works. Not good but it
 does what its made for (after years of development). But avahi is
 unstable... Does not work for me. I often had this problem: Network was
 not reachable, because of avahi.

I've never had that experience myself.
I've had a (DHCP-connected) network printer that I had to specify the IP
for manually when I removed avahi (yes, that's a dangerous thing to do;
but we had all of 192.168.*.* and maybe six network devices connected to
a WRT54G router, so there wasn't a collision).

On the other hand, I've also had avahi cause a kernel panic, apparently
triggered by a printer. That was with Ubuntu Lucid, right around
release (it could have been before release, since I tested that one).

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

Re: [Dng] Freedom Logo

[Isaac Dunham]

On Tue, Mar 31, 2015 at 10:38:59PM +0200, Svarog wrote:
 Hi all,
 I uploaded a different version: 
 http://without-systemd.org/wiki/index.php/File:Devuan_Freedom_blue1.png
 
 Kind Regards,
 kvasny

That looks nice!
(yes, that's including the color)

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

Re: [Dng] Why daemontools is so cool

[Isaac Dunham]

On Sat, Mar 28, 2015 at 02:52:47PM +0100, poitr pogo wrote:
(in response to the question of why s6 prevents daemonizing)
 Cannot. This is from the s6 docs. I'm not using s6. Just heard about it today.

If you want to *manage* a daemon (ie, do something when it stops, like
restarting it), it's very tricky to do it reliably without having a fixed
PID; daemonizing means close stdin/stdout/stderr, then 
  if (fork()) exit(0);
or some such thing (in other words, create a new process and exit the
old one), so you do not have a fixed PID.

On Linux, BSD, and older UNIX versions, this can be done thus:
  daemon(0,0);

 Another s6 limitation - finish script must end in 3 seconds. or will be 
 killed.
 Nice for desktop, not a server.

sysvinit /etc/init.d/sendsigs actually only allows 1 second.

 It used to be that an application is responsible for proper start
 up/shutdown procedure, as application  knows the proper way how to do
 it. Init script is just a place where to hook a startup/shutdown
 script to be executed when system needs to start/stop application in
 some automatic way.

 Now there are tools which help deamonize things.
 Depending how portable they are it make the price one has to pay when
 decides to use them instead of handling this yourself in the
 application.

My understanding is that s6 and some of the equivalent packages, such
as daemontools, are fairly portable.

They are generally not used as a way to offload daemonizing, but as a
way to ensure that a service stays started. If you don't need that,
you don't need them.

 Regards
 piotr

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

Re: [Dng] Devuan commitments - will trade-off be applied?

[Isaac Dunham]

On Fri, Mar 27, 2015 at 11:29:53PM +0100, marc wrote:
snip
 And maybe even:
 
 - minimising the size and dependency graph of the essential
   system. I have had friends worry that the base Debian seems
   to have been growing each year so that it doesn't fit onto
   small/embedded systems anymore. For anybody who has tried
   to build a distribution from scratch particularly for a
   new architecture or just platform (a really instructive
   exercise), a small core lets one get to a running system
   quickly (the first big win), and then a self-hosting system
   (the real win). Beyond these points the nonessential stuff
   can depend on arbitrary things, but getting the core up
   and running is critical for a free distribution to support
   new/unconventional platforms, or to serve as base for other
   distributions or appliances. The downside is that somebody's
   favourite scripting language isn't essential - but it is
   still there ... it just not used in the core.
 
   Maybe visualise this as a well-formed tree, with the kernel, libc,
   compiler, shell and shell utilities forming the trunk and then only
   at some meters above ground things branching into complex
   dependencies ...

The core of the command-line tools can be found thus:
dpkg-query -W --showformat='${Package}\t${Essential}\n'|grep yes

And here that's 25 lines long.
But it includes 2 shells, Perl, util-linux and a host of GNU utilities,
and requires at least 25 libraries.
util-linux builds some dozen packages) and pam seem to be the biggest
sources of proliferation in the base system.

But this comment reminds me of Aboriginal Linux:
http://landley.net/aboriginal/
and Bootstrap Linux:
https://github.com/pikhq/bootstrap-linux
(You can build a self-hosting system in six packages, if you choose the
right ones.)

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

Re: [Dng] Devuan commitments - will trade-off be applied?

[Isaac Dunham]

On Fri, Mar 20, 2015 at 04:01:28PM -0400, Steve Litt wrote:
 On Fri, 20 Mar 2015 09:40:43 -1000
 Joel Roth jo...@pobox.com wrote:
 
  Steve Litt wrote:
   What would especially float my boat, once there's a truly
   depoetterized Devuan, is to have the package manager warn me at 160
   decibles if I decide to install something that pulls in any systemd
   code, because if there's a way to run without systemd code, that's
   how I want to run, even if it means someday I can no longer use
   Gnumeric or Gimp.
   
   Let me give an analogy that's absolutely offtopic here, I use it
   only as an analogy. Three years ago, I made a policy that no KDE
   library or software would ever exist on any of Troubleshooters.Com
   computers, any computers owned by Steve Litt, or any computers
   owned by family members who expected me to be their IT department.
   For the most part, I simply never install a package beginning with
   k. But once in a while I install an excellent sounding package,
   only to see it starting to pull in KDE Krap, have to Ctrl+C out of
   it, and then go back and painstakingly remove everything my install
   put there. My life would have been easier if the package manager
   told me THIS PACKAGE HAS KDE REQUIREMENTS, PROCEED N/y.
 In the case of Devuan, systemd is a special case, indeed, the reason
 for Devuan's existance, so I think a no brainer, idiot lite solution
 would be appropriate for systemd, so that even those, like me, who know
 nothing but apt-get install great_sounding_app get warned.

printf '\n\nPackage: libsystemd*\nPin: origin *\nPin-Priority: -1\n' \
 /etc/apt/preferences

printf '\n\nPackage: systemd\nPin: origin *\nPin-Priority: -1\n' \
 /etc/apt/preferences

You're welcome.

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

Re: [Dng] The quote of the year

[Isaac Dunham]

On Thu, Mar 12, 2015 at 06:01:41PM -0400, Steve Litt wrote:
 Hi all,
 
 I just ran across the following quote, which I think the dng people
 will appreciate:
 
 
 I'm done with my desktop being someone else's research project.
 
 
 http://www.jwz.org/blog/2011/10/has-gnome-3-decided-that-people-shouldnt-want-screen-savers/

Over three years old, and so much of it is still true.

The window managers I use I don't expect to change that much (I'm using
icewm, fvwm1, and mwm), and the one desktop environment I use is
certainly not going to go for the rewrite it for fun, and what can
we break today? approach.

After all, I use CDE.

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

Re: [Dng] Plan for Devuan to use Mozilla products as is

[Isaac Dunham]

On Sat, Mar 07, 2015 at 02:19:43PM -0600, T.J. Duchene wrote:
 
  
  https://lists.debian.org/debian-security-announce/2015/msg00031.html
 
 I think ^THIS is probably the biggest reason not to use Chromium.
 
 Never mind whether it's affiliated with Google or whether that makes it
 untrustworthy.
 If you can't keep it updated for the full lifetime of the release, it could
 be written by the most trustworthy vendor on Earth and it still wouldn't
 qualify for a good default.
 
 Hi, Isaac! 
 
 That seems very strange to me.   I see no reason why they cannot backport
 patches to the Wheezy version of Chromium.  Debian has been doing that since
 day one on other packages.  Any upstream project could change the build
 environment could happen to any project, at any time. 
 
 Debian has never demanded that an upstream project stay the same for their
 convenience before now.  The fact that Debian chose to stop building updates
 for that reason shows a lack of commitment to Wheezy.  Unless there is
 something I don't know about - It's not that they can't use or generate a
 patch.  They simply won't.   
 
 t.j.

Iceweasel and Chromium are both updated to the upstream-supported version
periodically (when the current version is no longer supported).
The amount of churn between versions and the number of versions means that
it would be very difficult to backport patches.

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

Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds

[Isaac Dunham]

On Tue, Mar 03, 2015 at 07:25:23AM +, KatolaZ wrote:
 On Mon, Mar 02, 2015 at 04:35:24PM -0600, T.J. Duchene wrote:
  When you code in Perl, you are using subroutines and libraries that
  were incorporated into Perl core.The fact you are calling an
  entire subroutine when you split strings in Perl is no different
  than having a C string library.  You call the library to do the
  work.  You don't care how it does it, only that you get the results.
  C gets a bad reputation because a percentage of programmers never
  learned how to prevent buffer overflows or leaks is all.  That is
  certainly not C's fault.
  
 
 And I can mantion dozens of counterexamples in which Perl or Python
 would solve the task more easily than C. Just to give you an idea, I
 have been doing quite a bit of XML parsing, mainly to convert data
 sets of all sorts in a reasonable (ASCII) format. Well, I have done it
 both in C and Python, so I think I can make a fair comparison between
 the two *for this particular task* and for *my specific needs*.
 
 Usually the C implementation of a non-trivial XML parser might require
 a couple of days to be finished and be able to digest the whole schema
 (you have to construct the data structure piece by piece, and to pass
 around a lot of garbage, and to be sure that you don't have leaks
 anywhere, and to catch and handle errors by hand...). Conversely, the
 Python implementation is usually ready in less than two hours,

Are you using expat for the C implementation, like you are for Python
behind the scenes?

python-stdlib requires expat, BDB 5.3, bz2, ncurses, readline, sqlite,
and openssl, along with FFI, terminfo, and mime-support.

However, I recognize you probably won't get C done in less than 2 hours
like you do with Python.

I will say that it sometimes seems like the reason leaks are a problem
in C specifically is that leaks aren't considered a problem in other
languages.
Sure, gc-based languages eventually collect the garbage.
But they seem to take a long time to do it.
And they encourage a sloppy approach where acquiring a resource is not
habitually matched with releasing it.

And exceptions can at times be more obscure and verbose than checking
return values: something three imports deep could throw an exception
you never thought about, and it may propagate.

Now, I've used Python a little bit, and I've used C a little bit.
I won't say that Python/$scripting_language should not be used, period.
But there are a lot of the features that come at costs that sometimes
seem to be ignored.

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

Re: [Dng] Devuan Weekly News XI

[Isaac Dunham]

On Fri, Feb 27, 2015 at 03:12:54PM -0500, Hendrik Boom wrote:
 On Mon, Feb 23, 2015 at 07:22:26PM +0300, Jack L. Frost wrote:
   Could you please cease ??kickass?? here -- for people read your news
   also, but such rudness leaves them nothing but to shrink from your
   writing. Thanks again for the news though.
  
  ???kickass??? is not even a swear word.
 
 I think we're seeing cultural differences here.  What may not be a 
 swearword in one community may be in another.

Over here, those who are more particular about such things consider ass
to be a somewhat vulgar term when referring to the posterior rather than
a male donkey (and kick ass refers to the aforesaid pportion of the
anatomy).  Not quite a swear word, but something to be avoided.

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

Re: [Dng] simple backgrounds

[Isaac Dunham]

On Fri, Feb 27, 2015 at 06:13:24PM +, KatolaZ wrote:
 On Fri, Feb 27, 2015 at 01:56:56PM +, Matthew Melton wrote:
 
 [cut]
 
   
   Just to support my point, Debian has a great logo, but this is what is
   currently happening to the users of Jessie, thanks to the
   systemd-nonsense:
   
   https://lists.debian.org/debian-user/2015/02/msg00013.html
  
  Think they have found a solution after reading the followups. Reminds me 
  that someone complained they couldn't terminate fdisk if started by systemd 
  during boot. 
  Might offer to help them...once I have stopped laughing of course. Ha ha.
  
  
 
 Well, I still find it hard to believe that a modern Unix OS might be
 stuck at boot because I forgot to connect an ethernet cable... This is
 the essence of the systemd-nonsense. In that case it was just a

What baffles me is that Lennart *has* written a daemon specifically to
*avoid* hung boots due to networks being down.
It's called ifplugd.

(And yes, if I used my ethernet port more often than the twice a year
I now use it, I might want to use ifplugd.  Unlike systemd, it's a
single small daemon that just checks interface state and runs a script
if it's connected.)

Or, that might be the way Debian sets up networking as a dependency of
remote-fs which is a dependency of the late-boot programs in /usr.
I used to encounter similar problems when I had no wireless; fortunately,
sysvinit proceeds after a timeout.

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

Re: [Dng] Devuan Logo survey

[Isaac Dunham]

On Thu, Feb 26, 2015 at 10:22:28PM +, Nuno Magalh??es wrote:
 Prior to recent (at least in Debian) releases, Xorg came with the
 classic checkered monochrome pattern, i'm cool with that :)
 (Now it comes with a black background which is really moronic 'cos it
 leaves me wondering Did --configure barf or is this the root
 window?).

I like the root weave too.
If you want it back, use Xorg -retro or xsetroot -def.

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

Re: [Dng] wicd wpasupplicant (WAS: Re: three important UI features

[Isaac Dunham]

On Tue, Feb 24, 2015 at 12:31:54PM -0500, Hendrik Boom wrote:
 On Tue, Feb 24, 2015 at 05:06:47PM +0100, Didier Kryn wrote:
  
  
  I discovered the name of wicd on this list recently. I didn't
  try it, therefore I can't compare, but it looks that it has more
  diverse interfaces than wpasupplicant, CLI, GUI and even Curses. I
  will probably try it the first time I install Devuan on a laptop.
  
  I imagine neither wpasupplicant nor wicd will be infected by
  Systemd, and you'll have the choice between them.
 
 It's not entirely a choice.  wicd depends on wicd-daemon, which depends 
 on wpa-supplicant. 
 
 It looks as if, to some extent, wicd may constiture still more 
 interfaces to wpasupplicant, possibly with some state or smarts of its 
 own.

AFAICT, anything that can connect to a WPA network on Linux depends on
wpa_supplicant to do so.
iwconfig can only handle open or WEP networks; I haven't been able to find
out if iw can do WPA.

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

Re: [Dng] Important changes in Linux 3.20 (4.0?)

[Isaac Dunham]

On Sun, Feb 15, 2015 at 11:40:06AM -0500, Hendrik Boom wrote:
 On Sun, Feb 15, 2015 at 10:26:01AM -0500, Gravis wrote:
   Kernel live patching makes KDBUS and systemD support mandatory!
  
  i'm weary of KDBUS but live patching is something i consider too dangerous.
  --Gravis
 
 But why would it have to depend on systemd?

Erm...I'm reading that kdbus was *not* merged.

FWIW, kdbus was specifically mentioned when Linus blacklisted Kay Sievers.
V3 seems to have gotten a lot of This needs a *lot* more documentation.

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

Re: [Dng] vdev status update

[Isaac Dunham]

On Sun, Feb 22, 2015 at 08:00:58PM -0500, Jude Nelson wrote:
 I consider vdev closer to being done than closer to having been just
 started, and it's mature enough that early testers can start experimenting
 with using it to boot Devuan in a VM (maybe even on real hardware, if
 you're the adventurous type).  Not only does it create all device files in
 /dev that you'd expect, but also it set up and maintains the directories
 and symlinks for:
 * /dev/block
 * /dev/char
 * /dev/bus
 * /dev/bsg
 * /dev/cpu
 * /dev/disk/by-id
 * /dev/disk/by-uuid
 * /dev/dri
 * /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw
 * /dev/input/by-path
 * /dev/mapper
 * /dev/net
 * /dev/rtc
 * /dev/snd/by-path
 * /dev/v4l

I had just been wondering how to set up /dev/disk/by-id;
I have a helper for mdev that will set up /dev/disk/by-uuid/ and
/dev/disk/by-label/ symlinks (by parsing the output of 'blkid'):
 https://github.com/idunham/mdev/blob/master/helpers/disk_link.sh
It's released into the public domain via the unlicense.

snip
 === TODO ===
 There's still a few major shortcomings before I'm comfortable tagging an
 alpha release, which I list below:
 * vdevd needs an accompanying init script to mount devtmpfs and set up:
 -- /dev/stdout
 -- /dev/stderr
 -- /dev/stdin
 -- /dev/core
 -- /dev/shm
 -- /dev/MAKEDEV
 -- /dev/fd
 -- /dev/log
 -- /dev/xconsole
 -- and probably others

ln -s /proc/kcore /dev/core
ln -s /proc/self/fd   /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
# MAKEDEV is part of package makedevs;
# it should be copied to /dev if it exists 
[ -x /sbin/MAKEDEV ]  cp /sbin/MAKEDEV /dev/MAKEDEV || \
 ln -s /bin/true /dev/MAKEDEV

/dev/log is the responsibity of the syslog implementation, which is not
started by the device manager.

/dev/xconsole is not something I have on my main (udev-based) partition -
I think it's the result of running xconsole?
/dev/shm is either a mountpoint for a tmpfs filesystem or a link to one.
An old FHS-style system will do:

mkdir /dev/shm  mount -t tmpfs shm /dev/shm

On systemd-influenced systems, it's instead roughly:
# in mountdevsubfs.sh, from initscripts
mount -t tmpfs tmpfs /run
mkdir -p /run/lock /run/shm
mount -t tmpfs tmpfs /run/lock
mount -t tmpfs tmpfs /run/shm

#in udev, which runs before mountdevsubfs.sh
mountpoint -q /dev/shm/  umount /dev/shm/
mountpoint -q /dev/pts/  umount /dev/pts/
#(re)mount /dev and populate it
mkdir -p /dev/pts  mount -t devpts devpts /dev/pts

#I'm not sure where this is.
ln -s /run/shm /dev/shm

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

Re: [Dng] WIP: mdev packaging

[Isaac Dunham]

On Fri, Feb 20, 2015 at 06:12:11PM +0100, Jaromil wrote:
 
 dear Isaac,
 
 On Fri, 20 Feb 2015, Isaac Dunham wrote:
 
  On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton 
  wrote:
   http://lkcl.net/reports/removing_systemd_from_debian/
  
  Somehow, this inspired me to poke at packaging mdev.
  I don't have a website or apt repository atm, so I can't provide a deb.
  But here's the source in git:
  
https://github.com/idunham/mdev
  
  To build it, use dpkg-buildpackage -b.
 
 if you like to use our CI system and apt repository, you are welcome.
 
 we can open an mdev project on our gitlab inside a new group for the
 sort of projects like vdev and mdev, something called packages-nextgen,
 there you'd be able to push mdev as a mirror in addition to your github
 
 the advantages for this would be multiple: you'd have continuous
 integration on mdev and the correctly built packages would be ready to
 use from the Devuan repository, making it much easier for people to test
 and give you feedback.

Thank you very much. That sounds nice.
I'm curious whether this works nicely with debian-source-native
packaging, like I'm using for mdev (everything including the packaging
and source is in git master).

I suppose I should also package libsysdev, since Jude was talking
about using it for parts of libudev-compat.

If you're wondering why I didn't respond sooner: lkcl and I were chasing
down a bug, which turned out to be breakage with initramfs-tools from
wheezy.
I also didn't want the mdev package to be something that someone *could*
install easily at that stage, since the only other person to try it got
a boot failure; at a certain point, someone who isn't ready to build
the package probably isn't ready to help test it.

But now that lkcl has figured out how to fix the bug, I suppose it's ready
for putting into an experimental repository.

Thanks,
Isaac Dunham

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

Re: [Dng] about mdev and udev

[Isaac Dunham]

On Fri, Feb 20, 2015 at 09:08:56PM +0100, Godefridus Daalmans wrote:
 About that error with the mdev packaging:
 
 if you purge udev, does that mean you need the old-fashioned /dev/MAKEDEV
 script back to create the device nodes?
 
 it's in Debian package makedev. and it says Conflicts: udev, but that
 doesn't mean it gets re-installed automagically after udev is purged,
 unfortunately :-(

mdev does not depend on makedev; it creates devices itself.

HTH
Isaac Dunham

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

Re: [Dng] WIP: mdev packaging

[Isaac Dunham]

On Fri, Feb 20, 2015 at 07:09:28PM +, Luke Kenneth Casson Leighton wrote:
 On Fri, Feb 20, 2015 at 7:02 PM, Isaac Dunham ibid...@gmail.com wrote:
  On Fri, Feb 20, 2015 at 06:21:27PM +, Luke Kenneth Casson Leighton 
  wrote:
  On Fri, Feb 20, 2015 at 6:04 PM, Isaac Dunham ibid...@gmail.com wrote:
   On Fri, Feb 20, 2015 at 04:30:17PM +, Luke Kenneth Casson Leighton 
   wrote:
 
   I should have a fix soon.
 
   awesome.
 
  And pushed.
 
  interesting... /etc/modules.d/* error goes away but still no
 /etc/passwd or /etc/group file so still the same errors.  both times i
 had done an apt-purge udev followed by update-initramfs -u

Now I'm lost.
update-initramfs calls mkinitramfs which refreshes the initramfs,
calling /usr/share/initramfs-tools/hooks/* .
And /usr/share/initramfs-tools/hooks/mdev makes a stub /etc/passwd
and copies /etc/group almost first thing.
So in theory, that should not happen.

I'm wondering what 'lsinitramfs /initrd.img' says is there--especially
the contents of /etc, /sbin, and /scripts/, and what you get if you
add a mkinitramfs was here type message to both ends of the mdev hook.

I seem to recall there's some shell option you can set that shows the
commands being run a la DOS ECHO on, but don't remember what it is.
Setting that in the mdev hook then running update-initramfs -u
may be the most useful approach.

Also, is this Jessie or Sid (I used Jessie)? And does it work if you
uninstall udev but don't purge it (which I believe is what I did)?

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

[Dng] WIP: mdev packaging

[Isaac Dunham]

On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton wrote:
 http://lkcl.net/reports/removing_systemd_from_debian/

Somehow, this inspired me to poke at packaging mdev.
I don't have a website or apt repository atm, so I can't provide a deb.
But here's the source in git:

  https://github.com/idunham/mdev

To build it, use dpkg-buildpackage -b.

STATUS:
This provides hooks for mkinitramfs, and *can* create a working initrd.
There's an init script that's shipped along with it, and a fairly close
to standard Debian layout for /dev.
...At least, the result allows *me* to boot (/ on a SATA partition, no
separate mountpoints). Your mileage may vary; I would suggest *not* trying
this on your main install.
I have not tested this with dracut; it may well not work

There are helpers to create /dev/disk/by-{label,uuid}/ and other symlinks,
already set up.

It provides udev, because that was the only way to defeat the dependency
chain and make it work.

How to use:
If you don't have / on an unencrypted local partition, this may not work.
Also, *don't* do this on a production system!
Conventions: Lines that begin with a non-'#' should be done as non-root;
'^# ' should be done as root, '^##' are comments.

If you have X, you need to follow lkcl's guide to setting X up to work 
without udev; then disable any scripts/configuration that autostarts
X11 for the first boot.
Re-enable it once you know it works.

git clone git://github.com/idunham/mdev
cd mdev
dpkg-buildpackage -b
cd ..
## busybox or busybox-static should work.
# apt-get install busybox
# dpkg -i mdev_0.6-1_all.deb
# apt-get purge udev
## this may not be needed (do it if you didn't get a new initramfs
## after purging udev)
# update-initramfs -u 


And reboot.

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

Re: [Dng] OT: Linux kernel and the force behind it

[Isaac Dunham]

On Fri, Feb 20, 2015 at 12:42:43PM -0500, Gravis wrote:
   CDE (common desktop environment)
  Not familiar with that.  Is it related to Inferno?
 
 https://en.wikipedia.org/wiki/Common_Desktop_Environment

That's it. By the way, it does work on Debian (though I'm not sure if the
sysvinit script for dtlogin ever got fixed - I sent a replacement once,
and someone else mentioned the bug at one point).
The build/install process is rather convoluted, since make install
doesn't work right.

CDE was an Open Group project from about the time Novell gave them the
UNIX trademark. Inferno has the most tenuous of connections to it, being
a later Bell Labs project.

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