[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120609074426.496a5e13@newbook>
Date: Sat, 9 Jun 2012 07:44:26 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
On Sat, 9 Jun 2012 19:27:56 +0800
orc <orc@...server.ru> wrote:
> I really liked udev approach there: it monitors for new devices,
> creates nodes and gives permissions. It can execute scripts or
> programs. But udev is bloated today, it is going (or already) to be
> merged with systemd, so mdev is future simple replacement.
Not to mention it expects files in /usr, which is completely wrong.
gentoo is working to support mdev because of that.
> > What I'd really like to end up with is something that's not just a
> > new distro
>
> About distros: many of them force their own vision on solving one
> common problems, such as mounting devices or controlling wireless
> connectivity.
Or not solving, in the case of Ubuntu and wireless...
(that's a frequent issue on 11.10/12.04, from what I've
seen helping folks at the LUG)
> That's why I am, for example, using self-built one. That
> is: dealing with stuff using only my hands and head was *for me*
> better than dealing with stuff from certain distro. And the same for
> fdo junk: instead of dealing with all it's complexity I
> use /bin/mount for mounting today. I'm not saying that anyone should
> follow this, but it actually *works* as manpage says. Of course it is
> not sufficient for end-user nettops/mobile systems.
> I don't say that distros are bad. If all is going as needed, fine! But
> when undefined behavior occurs, then we try to solve it and see how
> complex and buggy (in case of fdo software) that thing is.
indeed....
mount -a does exactly the same thing as mountall, except maybe some
waiting/retrying.
> > This is an area where traditional simple scripts (boot scripts,
> > network scripts, etc.) horribly failed, using ugly things like pid
> > files, killall commands, broken behavior when a device was quickly
> > inserted then removed, etc.
>
> I've dropped this ugly and slow stuff that anyone today calls 'SysV
> init scripts' and written a more simpler and fast version based on
> idea of BSD or Slackware ones. They can be used both in embedded and
> on a regular system.
>
> > pid files
> Yup, when daemon dead (or someone cut off power), there is nothing to
> kill
> > killall
> Horrible and harmful
> Maybe pgrep/pkill sucks less and will replace that horrible approach
> to store pidfiles and believe that daemon is still running.
> Actually systemd is more, MORE harmful than this old stuff.
IIRC, pkill is racey--it checks the PID for a name, then kills the PID
(meaning that if you have almost all the processes supported running,
you use pkill, and something starts a few more programs, but the
daemon crashes before it gets killed, the new programs may end up
getting killed instead). This scenario is rather unlikely because of
time limits, but it could make for trouble occasionally.
Of course pidfiles can have the same problem unless they are
guaranteed to be removed on exit.
I don't know if killall has the same issue, but there are certain
daemons where it is the ideal solution because only one should be
running...
(wicd sometimes starts multiple instances of wpa_supplicant, which does
not work right in a big way)
Of course, the issue is now "How on earth do you kill a
daemon?"--sometimes they stop working right, but don't realize it...
I know what wpa_supplicant does is allow IPC to send it a request to
exit, but that takes IPC.
I presume plain sockets will work for IPC, though? Or am I
underestimating the requirements?
> Well...
> Reading your post I got an idea that we should begin to rework all
> stuff from scratch. Crazy enough. But look: if you already know about
> Rob Landley ideas about toybox and, in future, the QCC (a complete
> busybox-like toolchain that will replace the whole GNU: gcc, binutils,
> etc..), then we have a nice chance to start a new system, more just 'a
> new distro that have compiled stuff and put some it's own view on how
> things must be done'. You and contributors starting at point of glibc2
> replacement that is better and lightweight, Rob writes a userspace
> coreutils/util-linux/udev/archivers replacement that is better and
> lightweight, then the gcc replacement appears that can compile Linux
> kernel unmodified (or minimally modified). This can be a complete
> review of stuff we are using today.
QCC is tcc + qcg; Rob says he's gotten all the license crap taken care
of but needs time to get it started.
I know some Puppy developers would try all of this as soon as it's
usable...if not a little sooner.
So implementations following these principles do have a chance of going
somewhere, though maybe not taking over mainline desktops.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
