mailing list of musl libc
 help / color / mirror / code / Atom feed
From: orc <orc@sibserver.ru>
To: musl@lists.openwall.com
Cc: Rich Felker <dalias@aerifal.cx>
Subject: Re: Vision for new platform
Date: Sat, 9 Jun 2012 19:27:56 +0800	[thread overview]
Message-ID: <20120609192756.6e72f25e@sibserver.ru> (raw)
In-Reply-To: <20120518010620.GW163@brightrain.aerifal.cx>

Want to refresh this.

> 1. Attempting to account for multiple "local users", possibly even
>   simultaneously, with complex policies controlling their access to
>   hardware and configuration.

I have such system. But multiple local users share their rights
via sudo.
If world is going singleuser again, then we need no such machinery
there. Or we need another approach.
One can leave a NOPASSWD switch in sudoers and don't think about it
anymore. Program with gui can simply execve() sudo or it's replacement,
and possibly ask user a password if he removed NOPASSWD, and pass it to
sudo. This is just an example how it can be done with sudo. I don't know
how fdo deals with it, I haven't tried it for years.

> (e.g. spying with the microphone or changing the network connection to
> intercept traffic)

This is really controlled with setuid bits or permissions to certain
device nodes. Am I wrong?

>  - pluggable devices such as: video capture/webcam, audio, printers,
>  scanners, obex/bluetooth file transfer, etc.

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.

> 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. 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.

> 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.

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.

Quoting again,

> What I'd really like to end up with is something that's not just a new
> distro

And of course it will be a new platform.

I can be wrong in the ideas that I explained here. Please correct me.
Thanks.
* 'fdo' stands for freedesktop.org


  parent reply	other threads:[~2012-06-09 11:27 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18  1:06 Rich Felker
2012-05-18  3:11 ` Isaac Dunham
2012-05-18  3:26   ` Rich Felker
2012-05-19  1:28     ` Isaac Dunham
2012-05-18  6:07 ` Szabolcs Nagy
2012-05-21 20:05 ` aep
2012-05-21 20:17   ` Rich Felker
2012-05-21 20:51   ` nwmcsween
2012-05-21 20:59     ` Rich Felker
2012-05-21 21:18   ` Rich Felker
2012-05-21 21:51     ` aep
2012-05-21 22:25       ` Rich Felker
2012-05-22  0:53         ` aep
2012-05-22  1:54           ` Rich Felker
2012-05-22 12:55         ` Christoph Lohmann
2012-06-09 11:27 ` orc [this message]
2012-06-09 14:44   ` Isaac Dunham
2012-06-09 15:25     ` orc
2012-06-09 21:24     ` Rich Felker
2012-06-09 22:38       ` Christian Neukirchen
2012-06-10 12:53         ` Daniel Cegiełka
2012-06-10 13:22           ` Rich Felker
2012-06-10 14:52             ` orc
2012-06-10 14:55               ` orc
2012-06-10 15:13               ` Rich Felker
2012-06-10 15:51                 ` orc
2012-06-10 16:33                   ` Rich Felker
2012-06-10 17:53                     ` orc
2012-06-10 18:03                       ` Daniel Cegiełka
2012-06-10 18:26                         ` orc
2012-06-10 18:38                           ` Daniel Cegiełka
2012-06-10 18:58                             ` orc
2012-06-10 19:19                               ` Daniel Cegiełka
2012-06-10 19:33                             ` Rich Felker
2012-06-10 20:13                               ` Daniel Cegiełka
2012-06-11  7:24                                 ` orc
2012-06-11 12:54                               ` Init system (Re: [musl] Re: Vision for new platform) aep
2012-06-12  0:59                               ` Re: Vision for new platform Isaac Dunham
2012-06-12  1:48                                 ` Rich Felker
2012-06-12  5:37                                   ` idunham
2012-06-12  5:48                                     ` Kurt H Maier
2012-06-12  8:20                                       ` aep
2012-06-12 14:32                                         ` Rich Felker
2012-06-14  4:28                                       ` Isaac Dunham
2012-06-12 14:30                                     ` Rich Felker
2012-06-12  7:46                                   ` orc
2012-06-12  8:27                                     ` nwmcsween
2012-06-12  8:41                                       ` orc
2012-06-12  8:44                                     ` aep
2012-06-12  9:02                                       ` orc
2012-06-12 10:28                                         ` aep
2012-06-12 10:33                                           ` orc
2012-06-10 15:17               ` Daniel Cegiełka
2012-06-10 15:27                 ` Rich Felker
2012-06-10 15:12 ` Jeremy Huntwork
2012-06-10 18:03   ` Kurt H Maier
2012-06-10 18:15     ` Jeremy Huntwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120609192756.6e72f25e@sibserver.ru \
    --to=orc@sibserver.ru \
    --cc=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).