subject:"\[gentoo\-user\] udev \+ \/usr"

On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
 On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld jo...@antarean.org wrote:
  On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
  Last time I checked, neither GNOME nor Emacs demanded that Gentoo
  developers or users had to write a fork/replacement for a core
  component of the system. GNOME and Emacs just need ebuilds and
  adapting their configuration to Gentoo-isms. Testing and bug
  reporting, as usual. The only code needed is some small patches for
  both and around 200 lines of emacslisp for site-gentoo.el.
 
  Funny that you mention this. There might be something similar brewing
  for
  users of Gnome where quite a few low-level parts will end up being
  mandatory for Gnome:
 
  ...but I'm increasingly seeing talk on the
  gnome side of the Gnome OS, to include pulse-audio, systemd,
  policykit,
  udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
  forces one to use it... yet, since lvm is required for udisks), etc.

 I'm pretty sure the last part is false. I certainly have udisk
 installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
 there.

 I don't use Gnome and haven't looked into all this. Udev also doesn't appear
 to have a LVM-useflag. But as I do use LVM, I can't actually check.
 Do you have sys-fs/lvm2 on your system?

 The ebuild does list it as RDEPEND.

Yes, I got it installed. I didn't noticed until now. Then again, it
takes 1 minute to install in my puny laptop, and uses 7 Mb of hard
drive. But anyhow, I was mistaken: it is forced by udisks.

  It's a reply in the gentoo-dev thread I started.
 
  Requiring pulse-audio and policykit, I can understand. But requiring a
  specific init-system for the desktop seems a bit overkill.

 I don't think that will happen, although certainly is what Lennart
 (and probably Kay) wants. What I think will happen is that, if
 available, GNOME will use systemd. FreeBSD does not have udev, and
 GNOME works there (with diminished functionality).

 That's the future, I believe: you will be able to use GNOME without
 systemd, but it will be like more awesomer with systemd.

 I still think Gnome (or any other desktop environment) should not care about
 which init-system is being used.

And they will not. They will only use some capabilities that a system
provides, and use it if available. It's the exact same thing as udev.

  I'm not a gnome user and am happy with my KDE-desktop. But the same post
  also mentions KDE seems to be headed in a similar direction. Just
  slower.
 Because it makes sense for the full-fledge desktop. Notice that
 Gustavo Barbieri (who works a lot on e17) is a heavy promoter of
 systemd. Maybe even makes sense for Xfce, but that I don't know.

 At the end of the day, systemd manages how to start and stop
 processes. Which is basically the task of gnome-session-manager (and
 whatever is the equivalent in KDE).

 systemd, like any init-system, should start services.
 KDE has some kde-services like akonadi, nepomuk,... that get controlled by
 the kde-system internally. I would NOT want to see these controlled by
 systemd.

It would be a different process from PID 1. systemd call be called
with --user: every user will get it's own instance (replacing what now
is controlled by gnome-session-manager and [I presume] kde-system),
but that instance will be able to use all the plumbing that systemd
provides.

 These are running for the user that is logged in. Having these running for all
 users at once leads to the multi-user-kludge that MS Windows tries to have and
 for which Citrix was invented ontop of MS Windows

As I explained, it will be an instance per user. Nothing like Windows.

 We already have a decent multi-user environment, why would we want to kill
 that? If I wanted a single-user system, I'd be running MS Windows.

See above, you are wrong on how systemd will handle it.

  Mind you, I do think systemd is nice and usefull on a desktop machine,
  but I don't see much need for this on a server where the sysadmins
  generally prefer to have a much more detailed control of what is
  happening.

 I think systemd gives you that in servers. With OpenRC and Apache with
 user CGI scripts, ¿do you know how to list the httpd daemon spawned
 processes, and only those? Remember that a CGI script can double fork.

 With systemd is a matter of:

 systemctl status apache-httpd.service

 Did you look at the output of pstree?
 Try pstree -pu and you see all the PIDs and whenever there is a user-
 switch, it also lists the new user.

Yeah, and I specifically said: do you know how to list the httpd
daemon spawned processes, **and only those**? (emphasis mine). pstree
(or ps) will show the processes with **user** apache, not those
spawned by httpd.

 And you can kill every process related to a daemon, no matter how many
 forks its children

Re: [gentoo-user] udev + /usr

On Sat, Sep 17, 2011 at 3:04 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Saturday, September 17, 2011 08:45:15 AM Joost Roeleveld wrote:
 On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
  I think systemd gives you that in servers. With OpenRC and Apache with
  user CGI scripts, ¿do you know how to list the httpd daemon spawned
  processes, and only those? Remember that a CGI script can double fork.
 
  With systemd is a matter of:
 
  systemctl status apache-httpd.service

 Did you look at the output of pstree?
 Try pstree -pu and you see all the PIDs and whenever there is a user-
 switch, it also lists the new user.


 Had a quick look to get a more detailed list:

 Specifically only for apache:
 # pstree -pu `cat /var/run/apache2.pid`

 /var/run/apache2.pid gets the PID for the parent process automatically.

 With this list, I can get a more detailed picture of which process calls which
 child-process / thread and which user(s) are used for which process.

Yeah, but apparently you have never had a rogue (or just poorly
written) CGI script. If inside a CGI script you do a double fork, and
kill the first child, the second child (the grandchild of apache)
will get reattached to PID 1. This is the POSIX defined behaviour.

But then your pstree -pu $(cat /var/run/apache2.pid) doesn't work.

Again, with cgroups (and without systemd) you can handle it. But then
you need to do it manually for every daemon in the system. systemd
allows you to do it for you.

And it will be the same with user sessions, because is (for all that
matters) the same problem. Your desktop session will have its own
cgroup, and every application run by the user will be a subgroup of
the session group.

With systemd, my slow laptop boots from GRUB2 to GDM in 15 seconds.
That's almost three times better than with OpenRC. But from GDM to
full started desktop (before lauching applications) it takes almost 45
seconds. If I get to shave 15 seconds of it (and I am sure it will be
more) by using systemd --user, I will be a really, really happy man.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-17 Thread Michael Mol

On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld jo...@antarean.org wrote:
[[snippage]]
 I still think Gnome (or any other desktop environment) should not care about
 which init-system is being used.

 And they will not. They will only use some capabilities that a system
 provides, and use it if available. It's the exact same thing as udev.


[[snippage]]

 a) dbus is not part of the GUI, b) like it or not, it's the
 standardized IPC mechanism in Linux. If it's available, let's use it.

This is exactly the same attitude of convenience that led to udev
being abused, and then to the very decisions by udev's maintainer that
started off the firestorm on this list over the last couple weeks. The
system is *bloating* at an incredible rate.


 There are already well-tested and working mechanisms for communication where
 needed.

 I would like for you to be more specific about them.

Sockets, be they UNIX domain sockets, IPv4 or IPv6.
* Very common, very stable, very standard interface.
* IPv4 sockets exist on every major operating system.
* The sockets API has a common, portable C-level API going back to the
1980s, thanks to BSD 4.2.
* IP sockets support multicast, both host-local and as part of networking.
* Protocols implemented on top of IP make up the largest continual IPC
environment in existence...the Internet itself.
* IP sockets may have ACLs applied by kernel firewall rules.
* UNIX domain sockets get the full benefit of filesystem ACLs.

Shared memory:
* Exists in various forms.

Pipes:
* Exist in named and anonymous forms.
* If you use the command-line much, you might use them so much you've
taken them for granted.
* Some platforms support opening named pipes on remote systems. (I
know Windows can do this. I don't know about Linux.)
* 'nc' makes for an incredibly simple adapter to work with IP sockets.

Not sure what others there are, but those have existed longer than
I've been alive, and been standard since the early 1990s. Progress is
adding new functionality, not reimplementing existing functionality as
new APIs on top of the existing functionality. That's little better
than busywork for people who could be building something actually new.

-- 
:wq

Re: [gentoo-user] udev + /usr

On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol mike...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés can...@gmail.com 
 wrote:
 On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld jo...@antarean.org wrote:
 [[snippage]]
 I still think Gnome (or any other desktop environment) should not care about
 which init-system is being used.

 And they will not. They will only use some capabilities that a system
 provides, and use it if available. It's the exact same thing as udev.


 [[snippage]]

 a) dbus is not part of the GUI, b) like it or not, it's the
 standardized IPC mechanism in Linux. If it's available, let's use it.

 This is exactly the same attitude of convenience that led to udev
 being abused, and then to the very decisions by udev's maintainer that
 started off the firestorm on this list over the last couple weeks. The
 system is *bloating* at an incredible rate.


 There are already well-tested and working mechanisms for communication where
 needed.

 I would like for you to be more specific about them.

 Sockets, be they UNIX domain sockets, IPv4 or IPv6.
[snip]
 Shared memory:
[snip]
 Pipes:
[snip]

Yeah, but then you need to design, implement and debug a protocol
communication: what part of the wire speaks first, what does it says,
what are the valid responses, etc.

And then, if other component wants to communicate, it has to learn
your little protocol. dbus standardize this. And it uses sockets,
shared memory and pipes as building blocks, I believe,

 Not sure what others there are, but those have existed longer than
 I've been alive, and been standard since the early 1990s.

They are standard in the sense that they are a low level communication
standard API. An IPC is *way* more than that;  dbus is an IPC, because
then you have high level objects and methods, no matter the
language of the two sides of the wire communicating, or even if the
objects live in the same computer or not.

BTW, there *was* an standard that did everything dbus does: ORB, the
Object Request Broker. They tried to use that as IPC years ago, but is
so damn complicated to implement right they decided to better
implement a new standard. The standard is dbus.

 Progress is
 adding new functionality, not reimplementing existing functionality as
 new APIs on top of the existing functionality.

I think you are wrong if you believe that dbus is just existing
functionality as new APIs on top of the existing functionality. dbus
is a complete IPC system. Neither sockets, shared memory nor pipes are
an IPC, because they lack a well defined protocol. You *can* do the
same you do with dbus if you only use sockets/sharedmem/pipes, but
then you need to do it over and over and over again. Is like the
difference between assembler and C: you *can* do the same with both,
but that does not mean that is actually a good idea to only use
assembler.

 That's little better
 than busywork for people who could be building something actually new.

dbus offers new functionality, like I said.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote:
 On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld jo...@antarean.org wrote:
  On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
  Last time I checked, neither GNOME nor Emacs demanded that Gentoo
  developers or users had to write a fork/replacement for a core
  component of the system. GNOME and Emacs just need ebuilds and
  adapting their configuration to Gentoo-isms. Testing and bug
  reporting, as usual. The only code needed is some small patches for
  both and around 200 lines of emacslisp for site-gentoo.el.
 
  Funny that you mention this. There might be something similar brewing
  for
  users of Gnome where quite a few low-level parts will end up being
  mandatory for Gnome:
 
  ...but I'm increasingly seeing talk on the
  gnome side of the Gnome OS, to include pulse-audio, systemd,
  policykit,
  udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
  forces one to use it... yet, since lvm is required for udisks), etc.

 I'm pretty sure the last part is false. I certainly have udisk
 installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
 there.

 I don't use Gnome and haven't looked into all this. Udev also doesn't appear
 to have a LVM-useflag. But as I do use LVM, I can't actually check.
 Do you have sys-fs/lvm2 on your system?

 The ebuild does list it as RDEPEND.

 Yes, I got it installed. I didn't noticed until now. Then again, it
 takes 1 minute to install in my puny laptop, and uses 7 Mb of hard
 drive. But anyhow, I was mistaken: it is forced by udisks.

I think udisks depending on LVM is an error, so I decided I would took
this Saturday and see if I was able to write a patch that makes it
optional. However, as per free software rules, I first visited the
Freedesktop.org bugzilla.

Gustavo Barbieri (who I mentioned before) got there first:

https://bugs.freedesktop.org/show_bug.cgi?id=37647

As I said before, Gustavo has contributed a lot to systemd, usually
making stuff optional. I'm sure his patch (or a similar version of it)
will be accepted.

As I keep saying: code talks.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-17 Thread Michael Mol

On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol mike...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés  I would like for 
 you to be more specific about them.

 Sockets, be they UNIX domain sockets, IPv4 or IPv6.
 [snip]
 Shared memory:
 [snip]
 Pipes:
 [snip]

 Yeah, but then you need to design, implement and debug a protocol
 communication: what part of the wire speaks first, what does it says,
 what are the valid responses, etc.

 And then, if other component wants to communicate, it has to learn
 your little protocol. dbus standardize this. And it uses sockets,
 shared memory and pipes as building blocks, I believe,

Reasonable points, all, up to the term 'standardize'. How stable is the API?

Apart from our discussions of dbus from a few weeks ago, that's most
of what I know about it, quoted from the gpsd man page:

USE WITH D-BUS
   On operating systems that support D-BUS, gpsd can be built to broadcast
   GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
   stage, we will not attempt to document this interface here. Read the gpsd
   source code to learn more.


 Not sure what others there are, but those have existed longer than
 I've been alive, and been standard since the early 1990s.

 They are standard in the sense that they are a low level communication
 standard API. An IPC is *way* more than that;  dbus is an IPC, because
 then you have high level objects and methods, no matter the
 language of the two sides of the wire communicating, or even if the
 objects live in the same computer or not.

 BTW, there *was* an standard that did everything dbus does: ORB, the
 Object Request Broker. They tried to use that as IPC years ago, but is
 so damn complicated to implement right they decided to better
 implement a new standard. The standard is dbus.

Interesting. I'd heard of ORB, even tried to play with it a bit, but
the documentation I've found is terrible. Like a number of fields I've
poked at, if you wan to understand how to do something, you have to do
it, making for a tricky.

That said, who is They, and who decided that The standard is D-Bus?


 Progress is
 adding new functionality, not reimplementing existing functionality as
 new APIs on top of the existing functionality.

 I think you are wrong if you believe that dbus is just existing
 functionality as new APIs on top of the existing functionality. dbus
 is a complete IPC system. Neither sockets, shared memory nor pipes are
 an IPC, because they lack a well defined protocol. You *can* do the
 same you do with dbus if you only use sockets/sharedmem/pipes, but
 then you need to do it over and over and over again. Is like the
 difference between assembler and C: you *can* do the same with both,
 but that does not mean that is actually a good idea to only use
 assembler.

I take (and even accept) your points on D-Bus having more
functionality than the three other IPC mechanisms I described.

That said, I disagree that D-Bus is an inter-process control
mechansim, but sockets, shm and pipes are not. To draw from networking
terminology, sockets, shm and pipes could be seen as being on layers 2
and/or 3 of the OSI stack (shm and unix domain sockets being a
definite layer 2, IP sockets being layer 3), and D-Bus represents a
mixture of layers 3-5.

An application may choose to use only layers 2-3 for IPC, or it may
choose to use D-Bus.

-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-17 Thread pk

On 2011-09-17 20:36, Canek Peláez Valdés wrote:

 They are standard in the sense that they are a low level communication
 standard API. An IPC is *way* more than that;  dbus is an IPC, because

https://secure.wikimedia.org/wikipedia/en/wiki/Inter-process_communication

 then you have high level objects and methods, no matter the
 language of the two sides of the wire communicating, or even if the
 objects live in the same computer or not.

Acc. to this link, dbus currently only uses unix sockets (so the
objects must live on the same computer)...
https://secure.wikimedia.org/wikipedia/en/wiki/D-Bus

 is a complete IPC system. Neither sockets, shared memory nor pipes are
 an IPC, because they lack a well defined protocol. You *can* do the

See above.

Also:
https://www.ibm.com/developerworks/aix/library/au-ipc/

dbus is installed in my system, but only because I run Xfce4 (I am
thinking of installing something else due to it's becoming bloated just
like gnome). And I have -dbus in my global make.conf.

PS. I am quite astonished at the fact that I have a computer that is
_way_ faster than the first machine I installed GNU/Linux (an Amiga 4000
with a 68040 cpu at 40Mhz) on but the experience is still the same; it
takes about the same time to boot, the same time (or even slower) to
load a program. It seems the faster the computer the more I have to wait
for it to finish some task. Contradictory, no? Wonder why that is...
(bloat?).

Best regards

Peter K

Re: [gentoo-user] udev + /usr

On Sat, Sep 17, 2011 at 3:24 PM, Michael Mol mike...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol mike...@gmail.com wrote:
 On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés  I would like for 
 you to be more specific about them.

 Sockets, be they UNIX domain sockets, IPv4 or IPv6.
 [snip]
 Shared memory:
 [snip]
 Pipes:
 [snip]

 Yeah, but then you need to design, implement and debug a protocol
 communication: what part of the wire speaks first, what does it says,
 what are the valid responses, etc.

 And then, if other component wants to communicate, it has to learn
 your little protocol. dbus standardize this. And it uses sockets,
 shared memory and pipes as building blocks, I believe,

 Reasonable points, all, up to the term 'standardize'. How stable is the API?

Between major releases, pretty stable. And new releases usually add
functionality; I haven't used that much dbus, but I don't think the
developers had deprecated much.

 Apart from our discussions of dbus from a few weeks ago, that's most
 of what I know about it, quoted from the gpsd man page:

 USE WITH D-BUS
       On operating systems that support D-BUS, gpsd can be built to broadcast
       GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
       stage, we will not attempt to document this interface here. Read the 
 gpsd
       source code to learn more.

That's old, obviously. I have dbus 1.4.12, pretty much post-1.0.
gpsd should update its documentation.


 Not sure what others there are, but those have existed longer than
 I've been alive, and been standard since the early 1990s.

 They are standard in the sense that they are a low level communication
 standard API. An IPC is *way* more than that;  dbus is an IPC, because
 then you have high level objects and methods, no matter the
 language of the two sides of the wire communicating, or even if the
 objects live in the same computer or not.

 BTW, there *was* an standard that did everything dbus does: ORB, the
 Object Request Broker. They tried to use that as IPC years ago, but is
 so damn complicated to implement right they decided to better
 implement a new standard. The standard is dbus.

 Interesting. I'd heard of ORB, even tried to play with it a bit, but
 the documentation I've found is terrible. Like a number of fields I've
 poked at, if you wan to understand how to do something, you have to do
 it, making for a tricky.

ORBit was the GNOME implementation of ORB; I don't remember what KDE
used, but I believe it was also ORB based.

 That said, who is They, and who decided that The standard is D-Bus?

The desktop developers. They needed an IPC (because, even if you don't
agree, sockets/shrmem/pipes is not an IPC), and they settled on dbus,
hosted in freedesktop. Almost everybody else then jumped on dbus,
because is light, it works, and is an standard. From
http://dbus.freedesktop.org:

D-Bus is a message bus system, a simple way for applications to talk
to one another. In addition to interprocess communication, D-Bus helps
coordinate process lifecycle; it makes it simple and reliable to code
a single instance application or daemon, and to launch applications
and daemons on demand when their services are needed.


 Progress is
 adding new functionality, not reimplementing existing functionality as
 new APIs on top of the existing functionality.

 I think you are wrong if you believe that dbus is just existing
 functionality as new APIs on top of the existing functionality. dbus
 is a complete IPC system. Neither sockets, shared memory nor pipes are
 an IPC, because they lack a well defined protocol. You *can* do the
 same you do with dbus if you only use sockets/sharedmem/pipes, but
 then you need to do it over and over and over again. Is like the
 difference between assembler and C: you *can* do the same with both,
 but that does not mean that is actually a good idea to only use
 assembler.

 I take (and even accept) your points on D-Bus having more
 functionality than the three other IPC mechanisms I described.

 That said, I disagree that D-Bus is an inter-process control
 mechansim, but sockets, shm and pipes are not. To draw from networking
 terminology, sockets, shm and pipes could be seen as being on layers 2
 and/or 3 of the OSI stack (shm and unix domain sockets being a
 definite layer 2, IP sockets being layer 3), and D-Bus represents a
 mixture of layers 3-5.

Technically you are right. But in that case, a file written in /tmp
with permissions 777 and file locking can be used as IPC.

In practice, sockets/pipes/shrmem is not an IPC, because they lack a
standard protocol.

 An application may choose to use only layers 2-3 for IPC, or it may
 choose to use D-Bus.

Yeah, and they can choose to use assembler. Doesn't mean it actually
makes sense to use it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad

Re: [gentoo-user] udev + /usr

On Sat, Sep 17, 2011 at 5:03 PM, pk pete...@coolmail.se wrote:
 On 2011-09-17 20:36, Canek Peláez Valdés wrote:

 They are standard in the sense that they are a low level communication
 standard API. An IPC is *way* more than that;  dbus is an IPC, because

 https://secure.wikimedia.org/wikipedia/en/wiki/Inter-process_communication

 then you have high level objects and methods, no matter the
 language of the two sides of the wire communicating, or even if the
 objects live in the same computer or not.

 Acc. to this link, dbus currently only uses unix sockets (so the
 objects must live on the same computer)...
 https://secure.wikimedia.org/wikipedia/en/wiki/D-Bus

You can use AF_INET and AF_INET6 sockets for dbus messages (I *think*
I even remember seeing an implementation), but in practive I believe
nobody actually has done it.

 is a complete IPC system. Neither sockets, shared memory nor pipes are
 an IPC, because they lack a well defined protocol. You *can* do the

 See above.

 Also:
 https://www.ibm.com/developerworks/aix/library/au-ipc/

 dbus is installed in my system, but only because I run Xfce4 (I am
 thinking of installing something else due to it's becoming bloated just
 like gnome). And I have -dbus in my global make.conf.

 PS. I am quite astonished at the fact that I have a computer that is
 _way_ faster than the first machine I installed GNU/Linux (an Amiga 4000
 with a 68040 cpu at 40Mhz) on but the experience is still the same; it
 takes about the same time to boot, the same time (or even slower) to
 load a program. It seems the faster the computer the more I have to wait
 for it to finish some task. Contradictory, no? Wonder why that is...
 (bloat?).

I like to call them new features, but I see your point. I myself
prefer the new features. I gladly sacrifice a few cycles from my CPU
and a few megabytes from my harddrive to run my GNOME 3 desktop.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-17 Thread Alan McKinnon

On Sat, 17 Sep 2011 15:24:39 -0400
Michael Mol mike...@gmail.com wrote:

  BTW, there *was* an standard that did everything dbus does: ORB, the
  Object Request Broker. They tried to use that as IPC years ago, but
  is so damn complicated to implement right they decided to better
  implement a new standard. The standard is dbus.  
 
 Interesting. I'd heard of ORB, even tried to play with it a bit, but
 the documentation I've found is terrible. Like a number of fields I've
 poked at, if you wan to understand how to do something, you have to do
 it, making for a tricky.

You did well to walk away from ORB and it's implementation layer CORBA.

It was one of those things not designed by real engineers but by
bloated committees. It tried to be all things to all systems and ended
up being useable by none, much like XML and Java.

There was a standards body tracking ORB, I forget which one, but none
of that matters as the folks who should use it - system builders - saw
it's flaws quite quickly. Even Gnome has dropped it and are now moving
over to dbus.

Dbus is an interesting piece of technology and rather useful, it does
it a disservice to knock it. As Canek posted a few mails higher up, it
implements a standard messaging layer on top of existing mechanisms.
You know about the existing mechanisms so you also know that they only
provide a means for communication, not the language used for the
communication. And developing a language for every IPC you want to do
becomes tiresome very quickly.

As an analogy (albeit a poor one) dbus relates to IPC as TCP relates to
IP - all the boring plumbing underneath your communication that makes it
work at all is already there. It would work best if dbus doesn't become
yet another way to do IPC, but replaces many of them. Imagine how
much unbloat you could accomplish if you could remove all the little
bits of IPC plumbing scattered throughout the average Unix system's
codebase.

There are many code projects out there that deserves to be maligned to
the point of painful death, then killed. But I honestly beleive dbus is
not one of them.


-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: [gentoo-user] udev + /usr

2011-09-17 Thread Michael Mol

On Sat, Sep 17, 2011 at 7:00 PM, Alan McKinnon alan.mckin...@gmail.com wrote:
 On Sat, 17 Sep 2011 15:24:39 -0400
 Michael Mol mike...@gmail.com wrote:
 Dbus is an interesting piece of technology and rather useful, it does
 it a disservice to knock it.

Honestly, I really only want to provide reasonable criticism. I just
tend to get hung up on the nitty gritty details and where I think I
see something illogical.

 As Canek posted a few mails higher up, it
 implements a standard messaging layer on top of existing mechanisms.
 You know about the existing mechanisms so you also know that they only
 provide a means for communication, not the language used for the
 communication. And developing a language for every IPC you want to do
 becomes tiresome very quickly.

Don't I know it. I have to maintain proprietary, network binary
protocols passing data between propriety applications I also maintain.
I don't _like_ that architecture in the slightest, but it's what I get
paid for.


 As an analogy (albeit a poor one) dbus relates to IPC as TCP relates to
 IP - all the boring plumbing underneath your communication that makes it
 work at all is already there. It would work best if dbus doesn't become
 yet another way to do IPC, but replaces many of them. Imagine how
 much unbloat you could accomplish if you could remove all the little
 bits of IPC plumbing scattered throughout the average Unix system's
 codebase.

There's the terminology confusion that I got hung up on in the last
email; D-Bus is a higher-level IPC mechanism than the ones it's
implemented on top of.

 There are many code projects out there that deserves to be maligned to
 the point of painful death, then killed. But I honestly beleive dbus is
 not one of them.

There are two principle things I dislike about D-Bus.

1) It doesn't support live upgrading of the daemon. We discussed the
reasons behind this several weeks ago, as I recall. Transparent
session control handoff is, of course, complicated, and nobody has
seen the work as worthwhile.

2) It comes with (or appears to come with) a Linux-centric (sometimes
even a Linux-only) view. I love Linux, and I would love to see Linux
grow and improve. I also use (and am comfortable with) Windows and
Android (which I would consider Not Really Linux) and other
platforms*. Attitudes and actions which push Linux as the One Ring
smack of 'Embrace, Extend, Extinguish'.

That latter point, really, bothers me greatly. Market disruption
happens, and sometimes it's even necessary for advancement, sure.

Other than those two things, D-Bus seems interesting and useful. If it
manages to obsolete system-local IPC mechanisms, that's great. If it
manages to get out into the local network and be used to pass messages
back and forth between my local systems? That's awesome. If it manages
to allow applications to talk back and forth in a secure fashion
between Linux and non-Linux systems? Now we're talking about some real
improvement on the status quo.

* I think I could get by on a Mac, but it's difficult getting past
some prejudices and annoying fanboys I know IRL. It's also difficult
getting past the price tag; I don't see myself buying the hardware or
software unless I intend to develop for them. As for what I use? All
five computers at home run Linux; one Debian, three Ubuntu, one
Gentoo. My fiancee and I both have Android phones.

-- 
:wq

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 06:44:58 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 6:26 PM, Mark Knecht markkne...@gmail.com wrote:
  On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield kut...@kutulu.org wrote:
  On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
  On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
   I would estimate that the vast, vast, vast majority of users are
   those such as myslelf, who have no opinion whatsoever, and
   either will not be affected at all by these changes (because
   they don't separate / and /usr), or will simply apply the
   proposed initramfs solution and move on.
  
  You also don't have /var (or /var/log) seperated? Or any of the
  other parts of the filesystem that might be required by udev-rules?
  
  Speaking solely for myself, no. Years ago I routinely split /, /usr,
  and /var when setting up my FreeBSD systems, and found that it only
  ever caused problems when I could not get /usr or /var mounted when I
  needed them.
  
  At least since I switched to Gentoo, I've simply set up one partition
  with everything on it, and kept regular backups in case of failure.
  
  I clearly recognize that there are valid reasons to split your
  partitions, I have just never found any of them applicable to my
  situations.
  
  --Mike
  
  My first response to this 300+ post thread, and only to say that in
  something like 15 years of playing with  using Linux I've never split
  /usr  no longer split /var. I also don't use LVM or anything fancy
  like that. I just keep backups and use them if there's a failure. Life
  is pretty simple.
  
  My suspicion is that by far most casual desktop users of Linux, Gentoo
  based or not, run pretty much this way and will be unaffected by this
  whole change and as such have no reason to post.
 
 Ubuntu recommends /, /home and swap [1]. Fedora recommends /, /boot
 and swap [2]. OpenSUSE has several sets, but the simple and dual
 booting recommends /, /boot, /home and swap [3]. Debian says [4]:
 
 For new users, personal Debian boxes, home systems, and other
 single-user setups, a single / partition (plus swap) is probably the
 easiest, simplest way to go. However, this might not be such a good
 idea when you have lots of disk capacity, e.g., 20GB or so. Ext2
 partitions tend to perform poorly on file system integrity checking
 when they are larger than 6GB or so.
 
 For multi-user systems or systems with lots of disk, it's best to put
 /usr, /var, /tmp, and /home each on their own partitions separate from
 the / partition.
 
 Interestingly, the Gentoo handbook [5] recommends /, /boot and swap.
 Damn, I haven't installed Gentoo in a long time, I hadn't looked at
 the handbook in years.
 
 Anyway, Debian is the only big distro recommending separated /usr,
 and then only for multiuser setups. It's really years since I've
 looked at the recommended partition schemes: when I started using
 Linux, a separated /home was almost a must. And we had tiny hard
 drives then. Now get out of my lawn.

Gentoo still has some guides recommending split /usr:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

There are several people using this type of layout.
The suggested partitioning scheme is usually for beginner installations. Not 
necessarily for larger installations with specific requirements.

The debian guide talks about 20GB drives. I don't have those anymore. the 
smallest drive I have is a 320GB IDE-drive for the database server in the lab.

The server has 2 mirrored 500GB drives for the OS, email and websites. The 
rest of the data is on drives larger then 1TB.
Sticking all these on a single partition is going to take forever to fsck and 
will make maintenance a nightmare. I like the flexibility LVM brings me.

On the gentoo-dev list, I am now hearing that in future, I will need to use a 
full initramfs for my usecase. I'm trying to find out if there is a way to 
avoid this.
Once I find out, I will post the info here.

--
Joost


 Regards.
 
 [1] http://www.easy-ubuntu-linux.com/ubuntu-installation-606-7.html
 [2]
 http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s2-di
 skpartrecommend-x86.html [3] http://en.opensuse.org/SDB:Partitioning
 [4] http://www.debian.org/releases/woody/i386/ch-partitioning.en.html
 [5] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 05:34:11 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 5:25 PM, Joost Roeleveld jo...@antarean.org wrote:
 [ Hugemongous snip ]
 
  If the Gentoo-devs come up with a fool-proof solution
 
 No such thing in computing, I think.

I'm afraid you're right on this as that is also my experience. And not just in 
computing.
The biggest difficult with designing fool-proof systems is the fact that 
designers will always underestimate the ingenuity of fools.

 But I also think is really
 laudable that you want to ensure no many users will get bitten by this
 change.

I work in IT. Currently in support (enterprise-software, not home users) and 
moving into consulting soon.
I don't like to see broken systems and always want to find solutions to 
problems I encounter. I might not always succeed, but I will certainly try.

 And I also tend to believe that Gentoo users are more than able to
 deal with this and almost any other thing.

I agree, the vast majority of people on this list know how to solve issues for 
themselves or are able to formulate their problems/questions in such a way 
that others with more experience in that particular field can come up with the 
answer.

However, I also think there are plenty of Gentoo-users who don't subscribe to 
this list and may easily get caught out when this situation really starts 
affecting them.

--
Joost

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 5:30 PM, Joost Roeleveld jo...@antarean.org wrote:
  On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
  On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote:
   On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
   1.  The minimal initramfs will only need to be built once (and
   rarely
   rebuilt thereafter).  This removes one of my fears and it was a
   main
   objection for me - I would hate to have to rebuild initramfs every
   time I roll a new kernel, or libs and what not of fs happen to be
   udpated, etc.
  
  In my experience, it takes more time to build the kernel than it takes
  to rebuild the initramfs. And if you choose to use dracut, the process
  is automatic (you always call dracut with the same options, unless you
  suddenly add LVM or something similar).
  
  Canek, as you've been using dracut already extensively, is it possible
  to set default options/modules/whatever to get to the situation where
  simply running dracut without any extra options will always recreate
  the correct initramfs?
 The modules get defined by the DRACUT_MODULES variable, which is
 use-expanded. The options are configured in /etc/dracut.conf, but I
 believe there are some command line options not configurable.

The developers suggested I try dracut and I do intend to do that.
My problem is, the one most likely affected by this is also the one I want to 
experiment the least with. Guess I'll have to test this inside a VM.

  I didn't use an initramfs for my first years using Gentoo. Since I
  started to use media-gfx/splashutils a couple of years ago, every time
  I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
  the same, but with plymouth and systemd using dracut. It's just part
  of the process of getting a new kernel.
  
  And, if the initramfs has other tools in it, after every emerge of these
  tools. This is where I see a possible cause for failure as then the
  situation arises where the initramfs will still start correctly, but
  because it's using older tools it's possible that older versions and
  new versions start running simultaneously and get mixed up in a way
  that is not immediately apparent.
 
 I see it the other way around: you ensure that your initramfs is in
 sync with your system. In other words: the initramfs contains a subset
 of your normal installation. That is why it makes redundant /lib,
 /sbin and /bin.

The reason I ditched lilo when grub came out was because I always would forget 
to run the lilo-command. (Another was that lilo wouldn't work on a new 
machine, but that's not important)
The same will be true for dracut. And probably not just for me.

The on-disk-format may stay the same and the tools (am thinking LVM here) 
should always be able to find my filesystems. But, what if the initramfs does 
the fsck with older tools?

Currently, the fsck runs before actually mounting the filesystems. If the 
filesystems end up being pre-mounted, when will fsck run and which version?

--
Joost

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler
 
 sebast...@darkmetatron.de wrote:
  Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
  On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
  
  sebast...@darkmetatron.de wrote:
  Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
  with an initramfs you will be able to do anything, so it will make
  no
  sense to keep supporting initramfs-less systems.
  
  With Microsoft Windows you will be able to do anything, so it will
  make no sense to keep supporting Microsoft Windows-less systems.
  
  Irrelevant: see the name on the list? It's called Gentoo Linux. I know
  you are trying to be witty, but only shows you are comparing apples
  and oranges.
  
  No, because first it was sarcasm and second it shows that your argument
  is invalid. For near to every X there is some Y that can do what X can
  do, but there are still many good and valid reasons to have X. So it
  will make sense to keep supporting Y-less systems.
 
 And you conveniently skipped my answer to your last two examples. No
 problem, here it goes again:
 
 Last time I checked, neither GNOME nor Emacs demanded that Gentoo
 developers or users had to write a fork/replacement for a core
 component of the system. GNOME and Emacs just need ebuilds and
 adapting their configuration to Gentoo-isms. Testing and bug
 reporting, as usual. The only code needed is some small patches for
 both and around 200 lines of emacslisp for site-gentoo.el.

Funny that you mention this. There might be something similar brewing for 
users of Gnome where quite a few low-level parts will end up being mandatory 
for Gnome:

...but I'm increasingly seeing talk on the 
gnome side of the Gnome OS, to include pulse-audio, systemd, policykit, 
udev/u* (thus forcing lvm as well, at least lvm installation tho nothing 
forces one to use it... yet, since lvm is required for udisks), etc.

It's a reply in the gentoo-dev thread I started.

Requiring pulse-audio and policykit, I can understand. But requiring a 
specific init-system for the desktop seems a bit overkill.

I'm not a gnome user and am happy with my KDE-desktop. But the same post also 
mentions KDE seems to be headed in a similar direction. Just slower.

Mind you, I do think systemd is nice and usefull on a desktop machine, but I 
don't see much need for this on a server where the sysadmins generally prefer 
to have a much more detailed control of what is happening.

Then again, I don't feel Gnome or KDE have any reason to be installed on a 
server, but that's just how I see it.

--
Joost

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Pandu Poluan

On Sep 16, 2011 4:03 PM, Joost Roeleveld jo...@antarean.org wrote:

 On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
 
[--major snippage--]
  I see it the other way around: you ensure that your initramfs is in
  sync with your system. In other words: the initramfs contains a subset
  of your normal installation. That is why it makes redundant /lib,
  /sbin and /bin.

 The reason I ditched lilo when grub came out was because I always would
forget
 to run the lilo-command. (Another was that lilo wouldn't work on a new
 machine, but that's not important)
 The same will be true for dracut. And probably not just for me.

 The on-disk-format may stay the same and the tools (am thinking LVM here)
 should always be able to find my filesystems. But, what if the initramfs
does
 the fsck with older tools?

 Currently, the fsck runs before actually mounting the filesystems. If the
 filesystems end up being pre-mounted, when will fsck run and which
version?


Speaking of fsck, didn't someone lamented the fact that fsck can no longer
be statically linked, thus making initr* 'blew up' in size?

When more and more utilities go the non-statically-linked way...
congratulations! You now have an initr* that's practically a cpio-ized
version of /

Rgds,

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-16 Thread Michael Schreckenbauer

On Thursday, 15. September 2011 20:22:17 Michael Mol wrote:
 On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan xa...@xaerolimit.net wrote:
  On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
  
  leonardo.guilhe...@gmail.com wrote:
  I do not know the state of Geanny since I last checked (couple of
  years
  ago), but the highlight capabilites of KDevelop got my eye. It
  highlights local variables in different colors in the same context,
  so something like int foo(float bar, float baz) {
  }
  will have bar and baz in different colors. Also, support for CMake in
  KDevelop got really great and useful. Plus, it supports debugging
  inside the editor. Its awesome.
  
  If you want something in a gui, what about Code::Blocks? It's also
  multi-platform
 
 dev-util/codeblocks is masked. How well (or poorly) does it work on
 Gentoo AMD64?
 
 I did an emerge -p kdevelop...that'd pull back in the large bulk of
 KDE. I'm going to have to pass for now.

I' using kdevelop a lot. It's a nice IDE. At least, if you already use KDE as 
I am :)

 qt-creator has some use flag
 changes, but only requires bits of KDE I already have, so I'll be
 trying it.
 
 I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj,
 dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked
 eclipse, it was a royal pain using any *DT unless one downloaded it as
 a packaged deal.

Same as my experience. But it's nice, if you do java.

 Version dependencies were a pain. (That said, I
 settled into it fairly quickly. But that was a long time ago)


 I don't see an ebuild for Emacs CC-Mode.

app-xemacs/cc-mode

Regards,
Michael

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Alan McKinnon

On Fri, 16 Sep 2011 10:46:02 +0200
Joost Roeleveld jo...@antarean.org wrote:

  Anyway, Debian is the only big distro recommending separated /usr,
  and then only for multiuser setups. It's really years since I've
  looked at the recommended partition schemes: when I started using
  Linux, a separated /home was almost a must. And we had tiny hard
  drives then. Now get out of my lawn.  
 
 Gentoo still has some guides recommending split /usr:
 http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
 
 There are several people using this type of layout.
 The suggested partitioning scheme is usually for beginner
 installations. Not necessarily for larger installations with specific
 requirements.

Using layout suggestions from install docs to justify what the udev
maintainers want to do is simply disingenuous.

The install docs are obviously a guideline only and do not form any
sort of requirement. That is obvious to anyone with some experience in
the field. Anyone suggesting otherwise is either being hyper-literal or
is following some sneaky agenda. Either way, neither type should be
allowed anywhere near policy making as their goals conflict with the
community. 

 The debian guide talks about 20GB drives. I don't have those anymore.
 the smallest drive I have is a 320GB IDE-drive for the database
 server in the lab.

I need 73G SCSI drives for some old servers still running, they cost a
fortune from Dell. The nice man from Dell sales tells me they haven't
had 20G drives in the stores for years and years, he mentioned numbers
like 5 or 8

:-)



-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: [gentoo-user] udev + /usr

On Friday, September 16, 2011 12:00:16 PM Alan McKinnon wrote:
 On Fri, 16 Sep 2011 10:46:02 +0200
 
 Joost Roeleveld jo...@antarean.org wrote:
   Anyway, Debian is the only big distro recommending separated /usr,
   and then only for multiuser setups. It's really years since I've
   looked at the recommended partition schemes: when I started using
   Linux, a separated /home was almost a must. And we had tiny hard
   drives then. Now get out of my lawn.
  
  Gentoo still has some guides recommending split /usr:
  http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
  
  There are several people using this type of layout.
  The suggested partitioning scheme is usually for beginner
  installations. Not necessarily for larger installations with specific
  requirements.
 
 Using layout suggestions from install docs to justify what the udev
 maintainers want to do is simply disingenuous.

I referenced that asa response to the list of distro-guides.
 
 The install docs are obviously a guideline only and do not form any
 sort of requirement. That is obvious to anyone with some experience in
 the field. Anyone suggesting otherwise is either being hyper-literal or
 is following some sneaky agenda. Either way, neither type should be
 allowed anywhere near policy making as their goals conflict with the
 community.

I agree and I used my example to point out that any layout that is used by a 
few people is likely to be documented somewhere on the internet.

  The debian guide talks about 20GB drives. I don't have those anymore.
  the smallest drive I have is a 320GB IDE-drive for the database
  server in the lab.
 
 I need 73G SCSI drives for some old servers still running, they cost a
 fortune from Dell. The nice man from Dell sales tells me they haven't
 had 20G drives in the stores for years and years, he mentioned numbers
 like 5 or 8

Yes, the 320GB disk is in a machine that was written off by some company about 
4 or 5 years ago. Not sure how long that company used it before they got rid 
of it.

--
Joost

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-16 Thread Mike Edenfield


On 9/15/2011 8:22 PM, Michael Mol wrote:


I don't show an ebuild for eclipse (I see dev-java/ant-eclipse-ecj,
dev-java/eclipse-ecj and dev-util/eclipse-sdk). Last time I poked
eclipse, it was a royal pain using any *DT unless one downloaded it as
a packaged deal. Version dependencies were a pain. (That said, I
settled into it fairly quickly. But that was a long time ago)


You want the one called eclipse-sdk. The actual Eclipse 
product is just a shell that you can then plug in 
development environments -- the JDT (for Java) is the 
default but you can also install the CDT (for C/C++) or 
tons of others.


If you want the latest release of Eclipse you'll have to 
download or build it yourself; the Ganymeade (3.5) in the 
ebuild works fine but it doesn't support some of the newer 
plug-ins built for Helios (3.6) or Indigo (3.7). But 3.6 
introduced a *ton* of new dependencies that the Gentoo folks 
haven't been able to work out properly in portage.[1]


Of course, that's also likely an indication that Eclipse is 
getting way to big for it's own good, especially if you 
don't want to do any Java development, so you may just want 
to pass :)


--Mike

[1] https://bugs.gentoo.org/325271?id=325271

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-16 Thread Michael Mol

On Fri, Sep 16, 2011 at 8:30 AM, Mike Edenfield kut...@kutulu.org wrote:
 On 9/15/2011 8:22 PM, Michael Mol wrote:

 But 3.6 introduced a *ton* of new dependencies that the Gentoo folks
 haven't been able to work out properly in portage.[1]

 Of course, that's also likely an indication that Eclipse is getting way to
 big for it's own good, especially if you don't want to do any Java
 development, so you may just want to pass :)

I feel like there's an Eclipse is the new Emacs joke in there somewhere. ;P

-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Alan McKinnon

On Fri, 16 Sep 2011 12:54:46 +0200
Joost Roeleveld jo...@antarean.org wrote:

  Using layout suggestions from install docs to justify what the udev
  maintainers want to do is simply disingenuous.  
 
 I referenced that asa response to the list of distro-guides.

I was backing you up, not arguing against you :-)

-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-16 Thread Alan Mackenzie

Hi, Michael.

On Thu, Sep 15, 2011 at 08:22:17PM -0400, Michael Mol wrote:

 I don't see an ebuild for Emacs CC-Mode.

CC Mode is distributed along with the rest of {,X}Emacs (although I think
XEmacs half-splits all its packages off from its cord).

Those version of CC Mode are somewhat out of date, as the newer versions
have not yet percolated their way through to {,X}Emacs themselves.  The
most recent version is available from
http://cc-mode.sourceforge.net/release.php

 -- 
 :wq

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Canek Peláez Valdés

On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler

 sebast...@darkmetatron.de wrote:
  Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
  On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
 
  sebast...@darkmetatron.de wrote:
  Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:
  with an initramfs you will be able to do anything, so it will make
  no
  sense to keep supporting initramfs-less systems.
 
  With Microsoft Windows you will be able to do anything, so it will
  make no sense to keep supporting Microsoft Windows-less systems.
 
  Irrelevant: see the name on the list? It's called Gentoo Linux. I know
  you are trying to be witty, but only shows you are comparing apples
  and oranges.
 
  No, because first it was sarcasm and second it shows that your argument
  is invalid. For near to every X there is some Y that can do what X can
  do, but there are still many good and valid reasons to have X. So it
  will make sense to keep supporting Y-less systems.

 And you conveniently skipped my answer to your last two examples. No
 problem, here it goes again:

 Last time I checked, neither GNOME nor Emacs demanded that Gentoo
 developers or users had to write a fork/replacement for a core
 component of the system. GNOME and Emacs just need ebuilds and
 adapting their configuration to Gentoo-isms. Testing and bug
 reporting, as usual. The only code needed is some small patches for
 both and around 200 lines of emacslisp for site-gentoo.el.

 Funny that you mention this. There might be something similar brewing for
 users of Gnome where quite a few low-level parts will end up being mandatory
 for Gnome:

 ...but I'm increasingly seeing talk on the
 gnome side of the Gnome OS, to include pulse-audio, systemd, policykit,
 udev/u* (thus forcing lvm as well, at least lvm installation tho nothing
 forces one to use it... yet, since lvm is required for udisks), etc.

I'm pretty sure the last part is false. I certainly have udisk
installet (it's pulled by gnome-disk-utility), but I don't use LVM. So
there.

 It's a reply in the gentoo-dev thread I started.

 Requiring pulse-audio and policykit, I can understand. But requiring a
 specific init-system for the desktop seems a bit overkill.

I don't think that will happen, although certainly is what Lennart
(and probably Kay) wants. What I think will happen is that, if
available, GNOME will use systemd. FreeBSD does not have udev, and
GNOME works there (with diminished functionality).

That's the future, I believe: you will be able to use GNOME without
systemd, but it will be like more awesomer with systemd.

 I'm not a gnome user and am happy with my KDE-desktop. But the same post also
 mentions KDE seems to be headed in a similar direction. Just slower.

Because it makes sense for the full-fledge desktop. Notice that
Gustavo Barbieri (who works a lot on e17) is a heavy promoter of
systemd. Maybe even makes sense for Xfce, but that I don't know.

At the end of the day, systemd manages how to start and stop
processes. Which is basically the task of gnome-session-manager (and
whatever is the equivalent in KDE).

 Mind you, I do think systemd is nice and usefull on a desktop machine, but I
 don't see much need for this on a server where the sysadmins generally prefer
 to have a much more detailed control of what is happening.

I think systemd gives you that in servers. With OpenRC and Apache with
user CGI scripts, ¿do you know how to list the httpd daemon spawned
processes, and only those? Remember that a CGI script can double fork.

With systemd is a matter of:

systemctl status apache-httpd.service

And you can kill every process related to a daemon, no matter how many
forks its children process make. That alone makes systemd more usefull
for servers thatn SysV+OpenRC, I think.

 Then again, I don't feel Gnome or KDE have any reason to be installed on a
 server, but that's just how I see it.

Dear evolution, of course not. Why would you install GNOME or KDE in a
server? My two servers run with systemd, and not a single GUI library
is installed in them.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Canek Peláez Valdés

On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluan pa...@poluan.info wrote:

 On Sep 16, 2011 4:03 PM, Joost Roeleveld jo...@antarean.org wrote:

 On Thursday, September 15, 2011 05:38:41 PM Canek Peláez Valdés wrote:
 
 [--major snippage--]
  I see it the other way around: you ensure that your initramfs is in
  sync with your system. In other words: the initramfs contains a subset
  of your normal installation. That is why it makes redundant /lib,
  /sbin and /bin.

 The reason I ditched lilo when grub came out was because I always would
 forget
 to run the lilo-command. (Another was that lilo wouldn't work on a new
 machine, but that's not important)
 The same will be true for dracut. And probably not just for me.

 The on-disk-format may stay the same and the tools (am thinking LVM here)
 should always be able to find my filesystems. But, what if the initramfs
 does
 the fsck with older tools?

 Currently, the fsck runs before actually mounting the filesystems. If the
 filesystems end up being pre-mounted, when will fsck run and which
 version?


 Speaking of fsck, didn't someone lamented the fact that fsck can no longer
 be statically linked, thus making initr* 'blew up' in size?

 When more and more utilities go the non-statically-linked way...
 congratulations! You now have an initr* that's practically a cpio-ized
 version of /

Now, common: that's an exaggeration. My dracut generated initramfs
(with systemd, plymouth, udev, and I don't remember what many things
more) is 5 Mb. That's a little less than my several-gigabytes /.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Dale


Canek Peláez Valdés wrote:

On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.info  wrote:

Speaking of fsck, didn't someone lamented the fact that fsck can no longer
be statically linked, thus making initr* 'blew up' in size?

When more and more utilities go the non-statically-linked way...
congratulations! You now have an initr* that's practically a cpio-ized
version of /

Now, common: that's an exaggeration. My dracut generated initramfs
(with systemd, plymouth, udev, and I don't remember what many things
more) is 5 Mb. That's a little less than my several-gigabytes /.

Regards.


Give it time.  Something will need /home on the root partition next.  
Like someone else posted, we are headed towards windows land with this.  
I won't be surprised if /boot will have to be on / next too.


Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Canek Peláez Valdés

On Fri, Sep 16, 2011 at 11:57 AM, Dale rdalek1...@gmail.com wrote:
 Canek Peláez Valdés wrote:

 On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.info  wrote:

 Speaking of fsck, didn't someone lamented the fact that fsck can no
 longer
 be statically linked, thus making initr* 'blew up' in size?

 When more and more utilities go the non-statically-linked way...
 congratulations! You now have an initr* that's practically a cpio-ized
 version of /

 Now, common: that's an exaggeration. My dracut generated initramfs
 (with systemd, plymouth, udev, and I don't remember what many things
 more) is 5 Mb. That's a little less than my several-gigabytes /.

 Regards.

 Give it time.  Something will need /home on the root partition next.  Like
 someone else posted, we are headed towards windows land with this.  I won't
 be surprised if /boot will have to be on / next too.

I think I know what I am talking about when I say this:

The sky is, in fact, not falling.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Mark Knecht

On Fri, Sep 16, 2011 at 8:57 AM, Dale rdalek1...@gmail.com wrote:
 Canek Peláez Valdés wrote:

 On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.info  wrote:

 Speaking of fsck, didn't someone lamented the fact that fsck can no
 longer
 be statically linked, thus making initr* 'blew up' in size?

 When more and more utilities go the non-statically-linked way...
 congratulations! You now have an initr* that's practically a cpio-ized
 version of /

 Now, common: that's an exaggeration. My dracut generated initramfs
 (with systemd, plymouth, udev, and I don't remember what many things
 more) is 5 Mb. That's a little less than my several-gigabytes /.

 Regards.

 Give it time.  Something will need /home on the root partition next.  Like
 someone else posted, we are headed towards windows land with this.  I won't
 be surprised if /boot will have to be on / next too.

 Dale

Not the case IMO. My read of all this stuff is that within a few
months we'll be back to allowing /usr to be anywhere without an
initramfs or initramfs generated automagically such that you hardly
know it's there.

While I'm no expert on initramfs technology, it's not large. Mine is
only a bit larger than 2MB. Likely it doesn't contain whatever is
required to deal with systemd/udev but it's not like it's much disk
space...

c2stable ~ # ls -al /boot/my-initramfs.cpio.gz
-rw-r--r-- 1 root root 2296212 Jan  1  2011 /boot/my-initramfs.cpio.gz
c2stable ~ #

- Mark

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Pandu Poluan

On Sep 16, 2011 11:00 PM, Dale rdalek1...@gmail.com wrote:

 Canek Peláez Valdés wrote:

 On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.info  wrote:

 Speaking of fsck, didn't someone lamented the fact that fsck can no
longer

 be statically linked, thus making initr* 'blew up' in size?

 When more and more utilities go the non-statically-linked way...
 congratulations! You now have an initr* that's practically a cpio-ized
 version of /

 Now, common: that's an exaggeration. My dracut generated initramfs
 (with systemd, plymouth, udev, and I don't remember what many things
 more) is 5 Mb. That's a little less than my several-gigabytes /.

 Regards.


 Give it time.  Something will need /home on the root partition next.  Like
someone else posted, we are headed towards windows land with this.  I won't
be surprised if /boot will have to be on / next too.


Heh. If it's only limited to 'everything in /' it's still acceptable. MIGHTY
annoying, and most likely an admin hell, but workable.

Now, if everything needs to go into initr* (yes, I'm exaggerating, but...)
...

Rgds,

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Dale


Mark Knecht wrote:

On Fri, Sep 16, 2011 at 8:57 AM, Dalerdalek1...@gmail.com  wrote:

Canek Peláez Valdés wrote:

On Fri, Sep 16, 2011 at 5:29 AM, Pandu Poluanpa...@poluan.infowrote:

Speaking of fsck, didn't someone lamented the fact that fsck can no
longer
be statically linked, thus making initr* 'blew up' in size?

When more and more utilities go the non-statically-linked way...
congratulations! You now have an initr* that's practically a cpio-ized
version of /

Now, common: that's an exaggeration. My dracut generated initramfs
(with systemd, plymouth, udev, and I don't remember what many things
more) is 5 Mb. That's a little less than my several-gigabytes /.

Regards.

Give it time.  Something will need /home on the root partition next.  Like
someone else posted, we are headed towards windows land with this.  I won't
be surprised if /boot will have to be on / next too.

Dale

Not the case IMO. My read of all this stuff is that within a few
months we'll be back to allowing /usr to be anywhere without an
initramfs or initramfs generated automagically such that you hardly
know it's there.

While I'm no expert on initramfs technology, it's not large. Mine is
only a bit larger than 2MB. Likely it doesn't contain whatever is
required to deal with systemd/udev but it's not like it's much disk
space...

c2stable ~ # ls -al /boot/my-initramfs.cpio.gz
-rw-r--r-- 1 root root 2296212 Jan  1  2011 /boot/my-initramfs.cpio.gz
c2stable ~ #

- Mark




I hope you are right about sanity returning.  I have been wrong before 
but I have also been right too.  I picture this going bad for a lot of 
people and the dev getting a lot of emails about it.  Someone is going 
to try rebooting and have a jaw dropping experience.  One that comes to 
mind is hal but there are others that went south too.


Dale

:-)  :-)

Re: [gentoo-user] udev + /usr

2011-09-16 Thread Carlos Hendson

On Fri, 2011-09-16 at 10:57 -0500, Dale wrote:
 Give it time.  Something will need /home on the root partition next.  
 Like someone else posted, we are headed towards windows land with
 this.  
 I won't be surprised if /boot will have to be on / next too.
 
 Dale
 
 :-)  :-) 

Funnily enough, Windows 7 implements a separate boot partition from the
default system partition.  The partition is not only a boot partition
but a has rescue environment also.

How the tables are turning ... go figure.

Carlos

-- 
Sent using GNU/Linux - Perpetuate Freedom.

Re: [gentoo-user] udev + /usr

On Wednesday, September 14, 2011 10:30:03 AM Canek Peláez Valdés wrote:
 On Wed, Sep 14, 2011 at 1:52 AM, Joost Roeleveld jo...@antarean.org wrote:
  On Tuesday, September 13, 2011 06:33:01 PM Canek Peláez Valdés wrote:
  On Tue, Sep 13, 2011 at 6:10 PM, Michael Schreckenbauer
  grim...@gmx.de
  
  wrote:
   If gentoo follows fedora on this mandatory initramfs trail, I'll
   switch to FreeBSD completely. My software works on way more
   systems than just Linux.
  
  That's of course your prerogative. And, as I said before: Linux
  strives to be much more than Unix, and that means do things
  differently. If you want to do things the same way that it was done
  in the last 20 years, maybe Linux is not the best of choices.
  
  I read it before, but to be much more then Unix, Linux should be doing
  things better. Being different is what led to MS Windows'
 
 But that's the thing: we (you and me) don't see the situation the same
 way. To me, the proposed changes are for the better.

There are not many people who agree with you here.
The changes will lead to a C:-drive, similar to MS Windows, where everything 
has to be a single partition.
For various reasons, using seperate partitions are a better solution:
-  It allows for the use of filesystems better suited to the type of files and 
usage on each partition. 
- It prevents a single part of the filesystem to kill the entire system. (I 
can risk loosing 1 partition and not loose the rest of my data)

  I myself think the new technologies are worth to change the way we did
  things before. But that's just me.
  
  The new technologies have great merit. But, the implementation of it
  isn't thought through.
 
 In my humble opinion, what you just said is a little pedantic. You can
 disagree with the proposed changes, you can argue why you think
 another approach could be better. But just saying the implementation
 of it isn't  thought through, is a little insulting to the devs. I
 think they though about the implementation a lot.

They may have thought about it, but didn't think things through.
I have already stated a better way of doing it in the past few days. I will 
repeat it here.

The problem-scope that udev is TRYING to solve should NOT be solved in a 
single tool.
The main purpose of udev is to populate the /dev-tree.
The running of scripts based on /dev-tree events should be in a seperate tool 
that starts later in the boot-process.

Merging these 2, without properly handling failures, is bad design.
Forcing ALL Linux users to use a C-drive is one of the worst design flaws I 
have ever encountered.
Forcing the use of an init* which can leave systems unbootable, is also a 
design flaw.

How do you propose to fix the situation where the init* is broken and someone 
is unable to mount all the filesystems needed to rebuild the init* because 
udev, which SHOULD be populating the /dev-tree, refuses to do the single job 
it is designed to do?
Then rethink about the fact that not all computers are easily accessible 
and/or have cd-drives/usb-ports active.
My desktop has them active, my servers don't as I do not need USB on the 
server.

   And maybe I shouldn't even mention it, but I don't use OpenRC. I
   use
   systemd. And it works great on Gentoo.
   
   Well. Linux only. If I wanted a monoculture, I would use
   MS-Windows or
   OSX.
  
  Relax man. I mention what I use: I'm not forcing you (or anybody else)
  to use it. But I repeat (because I said it before) that I care about
  Linux, and Linux only.
  
  If you care about Linux, why do you allow it to be broken in such a
  fundamental way?
 
 Again, to me is not breaking it. To me is improving it.

Adding another SPOF (Single Point Of Failure) is not an improvement.

--
Joost

Re: [gentoo-user] udev + /usr

On Wednesday, September 14, 2011 10:37:14 AM Canek Peláez Valdés wrote:
 On Wed, Sep 14, 2011 at 5:06 AM, Neil Bothwick n...@digimed.co.uk wrote:
  On Tue, 13 Sep 2011 17:10:40 -0400, Canek Peláez Valdés wrote:
  No, by you know what needs to be done I mean: code. Contribute.
  Become a developer. Make shit happens the way you think it should
  happen.
  
  You're happy to run an important system service coded by someone with
  less experience than their dislike of the way things are going.
 
 Someone with less experience? As I said before, Kay has been working
 in udev for more than eight years. I think he's entitle to receive the
 acknowledge of his experience.

A certain amount of years of experience doesn't mean the person can not make 
mistakes. Kay has done a lot of good work with udev, but he should rethink his 
design and breaking a lot of systems just to satisfy his insane desire to make 
everyone do whatever he dreamed up is simply wrong.

--
Joost

Re: [gentoo-user] udev + /usr

On Wednesday, September 14, 2011 06:40:44 PM Sebastian Beßler wrote:
 This thread goes in endless circles, round and round and round.
 In the last 20 posts or so is not one new argument pro or con can be
 found, both sides only repeating their pov over and over again.
 
 Nothing will be achieved by that, it is only a big waste of time and
 energy that could be used better. Create documents with all your
 arguments, maybe a reply to that blog post that claims that split of
 /usr is broken.
 
 Flameing here on -user helps noone, because the devs must be convinced
 not the users.
 
 Just my 2 €-cent
 
 Greetings
 
 Sebastian Beßler

I agree, I also wanted to leave a comment on that page about systemd and /usr 
written by the same guy who is making this decision for udev.

Comments and changes are not possible on that page at all.

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 3:01 AM, Joost Roeleveld jo...@antarean.org wrote:
 There are not many people who agree with you here.
 The changes will lead to a C:-drive, similar to MS Windows, where everything
 has to be a single partition.

Technically, this isn't true. %PROGRAMFILES need not be on
%SYSTEMDRIVE%. %PROGRAMFILES(x86)% need not be on the same drive as
%PROGRAMFILES%. I believe most of the system key locations are allowed
to be in disparate locations.

 For various reasons, using seperate partitions are a better solution:
 -  It allows for the use of filesystems better suited to the type of files and
 usage on each partition.
 - It prevents a single part of the filesystem to kill the entire system. (I
 can risk loosing 1 partition and not loose the rest of my data)

Fully concur.

 In my humble opinion, what you just said is a little pedantic. You can
 disagree with the proposed changes, you can argue why you think
 another approach could be better. But just saying the implementation
 of it isn't  thought through, is a little insulting to the devs. I
 think they though about the implementation a lot.

 They may have thought about it, but didn't think things through.
 I have already stated a better way of doing it in the past few days. I will
 repeat it here.

 The problem-scope that udev is TRYING to solve should NOT be solved in a
 single tool.

Concur.

 The main purpose of udev is to populate the /dev-tree.
 The running of scripts based on /dev-tree events should be in a seperate tool
 that starts later in the boot-process.

I'm not *entirely* convinced this is the case, because it feels like
some situations like network devices (nbd, iSCSI) or loopback would
require userland tools to bring up once networking is up.

 Merging these 2, without properly handling failures, is bad design.

Concur.

 Again, to me is not breaking it. To me is improving it.

 Adding another SPOF (Single Point Of Failure) is not an improvement.

Concur.

-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Stroller


On 14 September 2011, at 22:34, Alan Mackenzie wrote:
 …
 That's got nothing to do with it, and it's rude of you to make this
 about Canek, IMO.
 
 Given how much Canek has been saying about free/open source recently, the
 attitudes he's been attributing to its developers (which don't accord
 with my experience of them), and the number of times he's told people,
 in a manner I find very rude, to stop moaning and code it yourself -
 given all of this, I find it reasonable to question Canek's background.
 I'm not the only one of us getting irritated by him.

Personally, I'm getting really irritated with all the people who expect someone 
else to fix their problems.

It's a fact of open-source software that you can write the dev a polite note 
saying have you considered this approach? and if you don't like the answer 
then you can code it yourself. Use BSD, write your own kernel, buy a copy of 
Windows - those are your other alternatives. 

Bitching about the author on here, 100 posts of complaining, does naff all 
good. That doesn't solve the problem. The only people who are listening are 
your mates, who already agree with you. You're not trying to persuade anyone to 
your point of view in accusing the software authors of being stupid or 
short-sighted. 

Yes, I *still* think it was rude of you to try to make this issue about Canek. 

I don't know what attitude you think Canek is attributing to OSS developers, 
because what I'm mostly seeing is those on your side of the field accusing the 
udev devs of being shallow and single-distro orientated. Of not talking to 
anyone. 

This is not about Canek. Or me. Or you. This is about udev, a piece of software.
If you don't like it, you have the source code. 

I'm not going to respond in detail to the rest of your post. 

It sounds like you have an excellent background to go fixing the problems. 

If you've got questions for the udev authors, ask them, but they're probably 
not reading this list.

Note that you're not required to talk to anyone else before coding your 
solution. If people like it, they'll use it. If you go talking to other people 
first you'll probably get a thousand different answers and options and a 
thousand different people telling you to do it some other way. So it's probably 
better if you get your code into some kind of working state and just worry 
about it solving your problem.

Stroller.

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 09:47:34 AM Michael Mol wrote:
  The main purpose of udev is to populate the /dev-tree.
  The running of scripts based on /dev-tree events should be in a seperate
  tool that starts later in the boot-process.
 
 I'm not entirely convinced this is the case, because it feels like
 some situations like network devices (nbd, iSCSI) or loopback would
 require userland tools to bring up once networking is up.

Yes, but the kernel-events referencing those devices won't appear untill after 
the networking is brought up.
The scripts that udev starts are run *after* a device-event is created. If 
the device itself has not been spotted by the kernel (for instance, the 
networking doesn't exist yet), the event won't be triggered yet.

This situation does not require udev to start all these tools when network-
devices appear.

I hope the following would make my thoughts a bit clearer:

1) kernel boots

2) kernel detects network device and places network-device-event in the 
queue

3) further things happen and kernel places relevant events in the queue (some 
other events may also already be in the queue before step 2)

4) udev starts and starts processing the queue

5) For each event, udev creates the corresponding device-entry and places 
action-entries in a queue

6) system-init-scripts mount all local filesystems

7) udev-actions starts (I made up this name)

8) udev-actions processes all the entries in the action-queue

From step 4, udev will keep processing further events it gets, which means 
that if any action taken by udev-actions causes further devices to become 
available, udev will create the device-entries and place the action in the 
action-queue.

If anyone has a setup where /usr can not be mounted easily, it won't work 
currently either and a init* would be necessary anyway.
(Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting /usr 
or other required filesystems)

But anyone with a currently working environment should be able to expect a 
currently working environment. If it fails to boot with only updating 
versions, it's a regression. And one of the worst kinds of all.

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org wrote:
 I'm not entirely convinced this is the case, because it feels like
 some situations like network devices (nbd, iSCSI) or loopback would
 require userland tools to bring up once networking is up.

 Yes, but the kernel-events referencing those devices won't appear untill after
 the networking is brought up.
 The scripts that udev starts are run *after* a device-event is created. If
 the device itself has not been spotted by the kernel (for instance, the
 networking doesn't exist yet), the event won't be triggered yet.

 This situation does not require udev to start all these tools when network-
 devices appear.

 I hope the following would make my thoughts a bit clearer:

 1) kernel boots

 2) kernel detects network device and places network-device-event in the
 queue

 3) further things happen and kernel places relevant events in the queue (some
 other events may also already be in the queue before step 2)

 4) udev starts and starts processing the queue

 5) For each event, udev creates the corresponding device-entry and places
 action-entries in a queue

 6) system-init-scripts mount all local filesystems

 7) udev-actions starts (I made up this name)

 8) udev-actions processes all the entries in the action-queue

 From step 4, udev will keep processing further events it gets, which means
 that if any action taken by udev-actions causes further devices to become
 available, udev will create the device-entries and place the action in the
 action-queue.

So, if I read this correctly, there are two classes of processing
events. kernel events and scripted actions. Here's rough pseudocode
describing what I think you're saying. (Or perhaps what I'm hoping
you're saying)

while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
  {
process_kernel_event(pkEvent);
  }
  else
  {
aevent* pAction = NULL;
if(get_waiting_action(pAction)) // Returns true if there's an
action waiting.
{
  process_action(pAction);
}
  }
}

So, udev processes one event at a time, and always processes kernel
events with a higher priority than resulting scripts. This makes a
certain amount of sense; an action could launch, e.g. nbdclient, which
would cause a new kernel event to get queued.

 If anyone has a setup where /usr can not be mounted easily, it won't work
 currently either and a init* would be necessary anyway.
 (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting /usr
 or other required filesystems)

I don't see how this is relevant to actually fixing udev. (See below)

 But anyone with a currently working environment should be able to expect a
 currently working environment. If it fails to boot with only updating
 versions, it's a regression. And one of the worst kinds of all.

I agree that the direction udev is going is a regression. There aren't
very many people active in this thread who would disagree with that
point. So let's just drop it and focus on what a good, general
solution would look like. (And anyone who says something amounting to
'status quo' for udev needs another explanation of why the udev
developer sees the current scenario as broken. And he's right; the
current scenario is architecturally unsound. I just think he's wrong
about the solution.)

-- 
:wq

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org 
wrote:
  I'm not entirely convinced this is the case, because it feels like
  some situations like network devices (nbd, iSCSI) or loopback would
  require userland tools to bring up once networking is up.
  
  Yes, but the kernel-events referencing those devices won't appear untill
  after the networking is brought up.
  The scripts that udev starts are run *after* a device-event is
  created. If the device itself has not been spotted by the kernel (for
  instance, the networking doesn't exist yet), the event won't be
  triggered yet.
  
  This situation does not require udev to start all these tools when
  network- devices appear.
  
  I hope the following would make my thoughts a bit clearer:
  
  1) kernel boots
  
  2) kernel detects network device and places network-device-event in
  the
  queue
  
  3) further things happen and kernel places relevant events in the queue
  (some other events may also already be in the queue before step 2)
  
  4) udev starts and starts processing the queue
  
  5) For each event, udev creates the corresponding device-entry and
  places
  action-entries in a queue
  
  6) system-init-scripts mount all local filesystems
  
  7) udev-actions starts (I made up this name)
  
  8) udev-actions processes all the entries in the action-queue
  
  From step 4, udev will keep processing further events it gets, which
  means that if any action taken by udev-actions causes further devices
  to become available, udev will create the device-entries and place
  the action in the action-queue.
 
 So, if I read this correctly, there are two classes of processing
 events. kernel events and scripted actions. Here's rough pseudocode
 describing what I think you're saying. (Or perhaps what I'm hoping
 you're saying)
 
 while(wait_for_event())
 {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
 process_kernel_event(pkEvent);
   }
   else
   {
 aevent* pAction = NULL;
 if(get_waiting_action(pAction)) // Returns true if there's an
 action waiting.
 {
   process_action(pAction);
 }
   }
 }

This is, sort-of, what I feel should happen. But currently, in pseudo-code, 
the following seems to happen:
while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was 
waiting {
process_kernel_event(pkEvent);
  }
}

I would prefer to see 2 seperate processes:

--- process 1 ---
while(wait_for_event())
{
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was 
waiting
  {
action_event = process_kernel_event(pkEvent);
if (action_event != NULL)
{
  put_action_event(pkEvent);
}
  }
}

--

--- process 2 ---
while(wait_for_event())
{
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was 
waiting
  {
process_action_event(paEvent);
  }
}
---

 So, udev processes one event at a time, and always processes kernel
 events with a higher priority than resulting scripts. This makes a
 certain amount of sense; an action could launch, e.g. nbdclient, which
 would cause a new kernel event to get queued.

Yes, except that udev ONLY handles kernel-events and doesn't process any 
actions itself.
These are placed on a seperate queue for a seperate process.

  If anyone has a setup where /usr can not be mounted easily, it won't
  work
  currently either and a init* would be necessary anyway.
  (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting
  /usr or other required filesystems)
 
 I don't see how this is relevant to actually fixing udev. (See below)
 
  But anyone with a currently working environment should be able to expect
  a currently working environment. If it fails to boot with only updating
  versions, it's a regression. And one of the worst kinds of all.
 
 I agree that the direction udev is going is a regression. There aren't
 very many people active in this thread who would disagree with that
 point. So let's just drop it and focus on what a good, general
 solution would look like. (And anyone who says something amounting to
 'status quo' for udev needs another explanation of why the udev
 developer sees the current scenario as broken. And he's right; the
 current scenario is architecturally unsound. I just think he's wrong
 about the solution.)

I agree he is wrong about the solution as well.

I have actually just posted my idea to the gentoo-dev list to see how the 
developers actually feel about possible splitting udev into 2 parts.

I'm not a good enough programmer to do this myself. But if anyone who can code 
and who also agrees with me that my idea for a solution is actually a good 
idea, please let me know and lets see how far we can get with implementing 
this solution.

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:32 AM, Michael Mol mike...@gmail.com wrote:
 On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org wrote:
 I'm not entirely convinced this is the case, because it feels like
 some situations like network devices (nbd, iSCSI) or loopback would
 require userland tools to bring up once networking is up.

 Yes, but the kernel-events referencing those devices won't appear untill 
 after
 the networking is brought up.
 The scripts that udev starts are run *after* a device-event is created. If
 the device itself has not been spotted by the kernel (for instance, the
 networking doesn't exist yet), the event won't be triggered yet.

 This situation does not require udev to start all these tools when network-
 devices appear.

 I hope the following would make my thoughts a bit clearer:

 1) kernel boots

 2) kernel detects network device and places network-device-event in the
 queue

 3) further things happen and kernel places relevant events in the queue (some
 other events may also already be in the queue before step 2)

 4) udev starts and starts processing the queue

 5) For each event, udev creates the corresponding device-entry and places
 action-entries in a queue

 6) system-init-scripts mount all local filesystems

 7) udev-actions starts (I made up this name)

 8) udev-actions processes all the entries in the action-queue

 From step 4, udev will keep processing further events it gets, which means
 that if any action taken by udev-actions causes further devices to become
 available, udev will create the device-entries and place the action in the
 action-queue.

 So, if I read this correctly, there are two classes of processing
 events. kernel events and scripted actions. Here's rough pseudocode
 describing what I think you're saying. (Or perhaps what I'm hoping
 you're saying)

 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was waiting
  {
    process_kernel_event(pkEvent);
  }
  else
  {
    aevent* pAction = NULL;
    if(get_waiting_action(pAction)) // Returns true if there's an
 action waiting.
    {
      process_action(pAction);
    }
  }
 }

 So, udev processes one event at a time, and always processes kernel
 events with a higher priority than resulting scripts. This makes a
 certain amount of sense; an action could launch, e.g. nbdclient, which
 would cause a new kernel event to get queued.

 If anyone has a setup where /usr can not be mounted easily, it won't work
 currently either and a init* would be necessary anyway.
 (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting /usr
 or other required filesystems)

 I don't see how this is relevant to actually fixing udev. (See below)

 But anyone with a currently working environment should be able to expect a
 currently working environment. If it fails to boot with only updating
 versions, it's a regression. And one of the worst kinds of all.

 I agree that the direction udev is going is a regression. There aren't
 very many people active in this thread who would disagree with that
 point. So let's just drop it and focus on what a good, general
 solution would look like. (And anyone who says something amounting to
 'status quo' for udev needs another explanation of why the udev
 developer sees the current scenario as broken. And he's right; the
 current scenario is architecturally unsound. I just think he's wrong
 about the solution.)

Let me throw my own guess of how they came out with the corrent
proposed solution. I repeat: is my own guess: I am not the one calling
the shots, so maybe I'm completely wrong.

As many of you guys said, there are ways of solving the problem
without requiring an initramfs. Note that if you decide to use an
initramfs, every use case works: You can have a practically empty /,
throw everything in /usr, and have /usr in another partition, maybe
even an encrypted remote NFS share. With an initramfs you can have a
separate /var, you can even have a separated /etc, mounted even by NFS
too. You can do pretty much whatever you want, because you have a full
userspace *the moment you boot*. Bluetooth, network, LVM,
crypto-filesystems: Everything is available from the instant zero.

From that perspective, the problem then is trying to support the
initramfs-less setups. Putting myself in the shoes of the developers,
the smart solution is to simply force an initramfs. KISS is to force
an initramfs, because it solves everything. The Gentoo devs are
working in a minimal initramfs that works for most normal usecases.
Everything else will be handled by dracut or genkernel.

An initramfs is not an initrd. And is not a binary blob coming who
knows from where; with dracut, your initramfs is simply a subset of
your normal installation, and can be as simple (just mount /usr) or as
complicated (LVM+crypto+network+NFS+whatever) as you want.

Of course you can solve it differently, for example splitting udev

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
 wrote:
  I'm not entirely convinced this is the case, because it feels like
  some situations like network devices (nbd, iSCSI) or loopback would
  require userland tools to bring up once networking is up.
 
  Yes, but the kernel-events referencing those devices won't appear untill
  after the networking is brought up.
  The scripts that udev starts are run *after* a device-event is
  created. If the device itself has not been spotted by the kernel (for
  instance, the networking doesn't exist yet), the event won't be
  triggered yet.
 
  This situation does not require udev to start all these tools when
  network- devices appear.
 
  I hope the following would make my thoughts a bit clearer:
 
  1) kernel boots
 
  2) kernel detects network device and places network-device-event in
  the
  queue
 
  3) further things happen and kernel places relevant events in the queue
  (some other events may also already be in the queue before step 2)
 
  4) udev starts and starts processing the queue
 
  5) For each event, udev creates the corresponding device-entry and
  places
  action-entries in a queue
 
  6) system-init-scripts mount all local filesystems
 
  7) udev-actions starts (I made up this name)
 
  8) udev-actions processes all the entries in the action-queue
 
  From step 4, udev will keep processing further events it gets, which
  means that if any action taken by udev-actions causes further devices
  to become available, udev will create the device-entries and place
  the action in the action-queue.

 So, if I read this correctly, there are two classes of processing
 events. kernel events and scripted actions. Here's rough pseudocode
 describing what I think you're saying. (Or perhaps what I'm hoping
 you're saying)

 while(wait_for_event())
 {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
     process_kernel_event(pkEvent);
   }
   else
   {
     aevent* pAction = NULL;
     if(get_waiting_action(pAction)) // Returns true if there's an
 action waiting.
     {
       process_action(pAction);
     }
   }
 }

 This is, sort-of, what I feel should happen. But currently, in pseudo-code,
 the following seems to happen:
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
    process_kernel_event(pkEvent);
  }
 }

 I would prefer to see 2 seperate processes:

 --- process 1 ---
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting
  {
    action_event = process_kernel_event(pkEvent);
    if (action_event != NULL)
    {
      put_action_event(pkEvent);
    }
  }
 }

 --

 --- process 2 ---
 while(wait_for_event())
 {
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was
 waiting
  {
    process_action_event(paEvent);
  }
 }
 ---

 So, udev processes one event at a time, and always processes kernel
 events with a higher priority than resulting scripts. This makes a
 certain amount of sense; an action could launch, e.g. nbdclient, which
 would cause a new kernel event to get queued.

 Yes, except that udev ONLY handles kernel-events and doesn't process any
 actions itself.
 These are placed on a seperate queue for a seperate process.

  If anyone has a setup where /usr can not be mounted easily, it won't
  work
  currently either and a init* would be necessary anyway.
  (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting
  /usr or other required filesystems)

 I don't see how this is relevant to actually fixing udev. (See below)

  But anyone with a currently working environment should be able to expect
  a currently working environment. If it fails to boot with only updating
  versions, it's a regression. And one of the worst kinds of all.

 I agree that the direction udev is going is a regression. There aren't
 very many people active in this thread who would disagree with that
 point. So let's just drop it and focus on what a good, general
 solution would look like. (And anyone who says something amounting to
 'status quo' for udev needs another explanation of why the udev
 developer sees the current scenario as broken. And he's right; the
 current scenario is architecturally unsound. I just think he's wrong
 about the solution.)

 I agree he is wrong about the solution as well.

 I have actually just posted my idea to the gentoo-dev list to see how the
 developers actually feel about possible splitting udev into 2 parts.

 I'm not a good enough programmer to do this myself. But if anyone who can code
 and who also agrees with me that my idea for a solution is actually a good
 idea, please let me know

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
 wrote:
  I'm not entirely convinced this is the case, because it feels like
  some situations like network devices (nbd, iSCSI) or loopback would
  require userland tools to bring up once networking is up.
 
  Yes, but the kernel-events referencing those devices won't appear untill
  after the networking is brought up.
  The scripts that udev starts are run *after* a device-event is
  created. If the device itself has not been spotted by the kernel (for
  instance, the networking doesn't exist yet), the event won't be
  triggered yet.
 
  This situation does not require udev to start all these tools when
  network- devices appear.
 
  I hope the following would make my thoughts a bit clearer:
 
  1) kernel boots
 
  2) kernel detects network device and places network-device-event in
  the
  queue
 
  3) further things happen and kernel places relevant events in the queue
  (some other events may also already be in the queue before step 2)
 
  4) udev starts and starts processing the queue
 
  5) For each event, udev creates the corresponding device-entry and
  places
  action-entries in a queue
 
  6) system-init-scripts mount all local filesystems
 
  7) udev-actions starts (I made up this name)
 
  8) udev-actions processes all the entries in the action-queue
 
  From step 4, udev will keep processing further events it gets, which
  means that if any action taken by udev-actions causes further devices
  to become available, udev will create the device-entries and place
  the action in the action-queue.

 So, if I read this correctly, there are two classes of processing
 events. kernel events and scripted actions. Here's rough pseudocode
 describing what I think you're saying. (Or perhaps what I'm hoping
 you're saying)

 while(wait_for_event())
 {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
     process_kernel_event(pkEvent);
   }
   else
   {
     aevent* pAction = NULL;
     if(get_waiting_action(pAction)) // Returns true if there's an
 action waiting.
     {
       process_action(pAction);
     }
   }
 }

 This is, sort-of, what I feel should happen. But currently, in pseudo-code,
 the following seems to happen:
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
    process_kernel_event(pkEvent);
  }
 }

 I would prefer to see 2 seperate processes:

 --- process 1 ---
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting
  {
    action_event = process_kernel_event(pkEvent);
    if (action_event != NULL)
    {
      put_action_event(pkEvent);
    }
  }
 }

 --

 --- process 2 ---
 while(wait_for_event())
 {
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was
 waiting
  {
    process_action_event(paEvent);
  }
 }
 ---

 So, udev processes one event at a time, and always processes kernel
 events with a higher priority than resulting scripts. This makes a
 certain amount of sense; an action could launch, e.g. nbdclient, which
 would cause a new kernel event to get queued.

 Yes, except that udev ONLY handles kernel-events and doesn't process any
 actions itself.
 These are placed on a seperate queue for a seperate process.

The problem with this is that you now need to manage synchronization
between the kernel event processor and the action processor, which is
actually more complicated than keeping them together in a
single-threaded, single-process scenario.


-- 
:wq

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:57 AM, Canek Peláez Valdés can...@gmail.com wrote:
 Of course you can solve it differently, for example splitting udev as
 Joost proposes. But then is more code to maintain, and the number of
 possible setups is suddenly the double it was before. It. Is. Not.
 KISS.

If you want KISS by imposing rules on the many to make
responsibilities fewer for the few, build a walled garden. Building a
safe playground has never been what Linux has been about, or what it
has been advocated or marketed as, in the ten or so years I've been
using it.


 It's a lot like the CUPS/lprng situation we discussed before. CUPS can
 do anything that lprng does, so it makes no sense to keep support for
 lprng. It's the same: with an initramfs you will be able to do
 anything, so it will make no sense to keep supporting initramfs-less
 systems.

While I came down on the CUPS side of that argument, udev is a very
different beast.

-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Michael Schreckenbauer

On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
 I agree he is wrong about the solution as well.
 
 I have actually just posted my idea to the gentoo-dev list to see how the
 developers actually feel about possible splitting udev into 2 parts.

I've read it there. Thanks for doing this.

 I'm not a good enough programmer to do this myself. But if anyone who can
 code and who also agrees with me that my idea for a solution is actually a
 good idea, please let me know and lets see how far we can get with
 implementing this solution.

I'm definitely interested in this. I don't know, how many or little I can 
contribute. Working as a freelancer, I have some time now, but this could 
change quite fast. I have developed quite a few daemons at the company I 
worked for the past ~10 years. So I can say, I have some experience in doing 
things your proposal needs.
Feel free to send me PM, if you have questions about me, my knowledge or 
simply to exchange ideas.

 --
 Joost

Best,
Michael

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Michael Schreckenbauer

On Thursday, 15. September 2011 11:03:09 Michael Mol wrote:
  Yes, except that udev ONLY handles kernel-events and doesn't process any
  actions itself.
  These are placed on a seperate queue for a seperate process.
 
 The problem with this is that you now need to manage synchronization
 between the kernel event processor and the action processor, which is
 actually more complicated than keeping them together in a
 single-threaded, single-process scenario.

Yes, it's more complicated to do. But not impossible.
IPC, shared memory and what not, exists for a reason

Best,
Michael

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 11:16 AM, Michael Schreckenbauer grim...@gmx.de wrote:
 On Thursday, 15. September 2011 11:03:09 Michael Mol wrote:
  Yes, except that udev ONLY handles kernel-events and doesn't process any
  actions itself.
  These are placed on a seperate queue for a seperate process.

 The problem with this is that you now need to manage synchronization
 between the kernel event processor and the action processor, which is
 actually more complicated than keeping them together in a
 single-threaded, single-process scenario.

 Yes, it's more complicated to do. But not impossible.
 IPC, shared memory and what not, exists for a reason

Sure. But it's not KISS, it's not necessary and it's a royal PITA. One
of queued tasks here at work is debugging _exactly_ that kind of code.
You need a _very_ good reason to use it, because it doesn't make any
solution more elegant.

I don't see a pragmatic value to splitting the process. At work, I
have to do it because it links to badly-written crash-prone code I
can't fix. If I can reasonably guarantee that the code I need to run
will behave, then the overhead and complexity definitely doesn't seem
worthwhile.

And because I've sat on two sides of the KISS argument in as many
messages, I'd like to make some points clear:

* The udev tool needs to be reliable, and this means no complexity
unnecessary to fulfilling its role. However...
* Part of udev's role needs to be *not* impose constraints on a system
without a clear path to get from point A to point B; as long an API is
understood, someone plugging into udev should be able to find a way to
reliably do what they want to do.


-- 
:wq

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 10:57:27 AM Canek Peláez Valdés wrote:

snipped to keep only the email from Canek

 Let me throw my own guess of how they came out with the corrent
 proposed solution. I repeat: is my own guess: I am not the one calling
 the shots, so maybe I'm completely wrong.

Ok and I do actually think you are correct with your guess as to why the 
developer came up with his solution.

 As many of you guys said, there are ways of solving the problem
 without requiring an initramfs. Note that if you decide to use an
 initramfs, every use case works: You can have a practically empty /,
 throw everything in /usr, and have /usr in another partition, maybe
 even an encrypted remote NFS share. With an initramfs you can have a
 separate /var, you can even have a separated /etc, mounted even by NFS
 too. You can do pretty much whatever you want, because you have a full
 userspace *the moment you boot*. Bluetooth, network, LVM,
 crypto-filesystems: Everything is available from the instant zero.

For these specific custom environments, yes, I agree. An initramfs is 
mandatory.

 From that perspective, the problem then is trying to support the
 initramfs-less setups. Putting myself in the shoes of the developers,
 the smart solution is to simply force an initramfs. KISS is to force
 an initramfs, because it solves everything. The Gentoo devs are
 working in a minimal initramfs that works for most normal usecases.
 Everything else will be handled by dracut or genkernel.

Initramfs is already supported. so is initramfs-less.

 An initramfs is not an initrd. And is not a binary blob coming who
 knows from where; with dracut, your initramfs is simply a subset of
 your normal installation, and can be as simple (just mount /usr) or as
 complicated (LVM+crypto+network+NFS+whatever) as you want.

I haven't looked at dracut yet, but as far as I understand, it does create an 
initramfs with the script(s), libraries and binaries needed to start whatever 
is needed to get to the stage where udev is happy. 

 Of course you can solve it differently, for example splitting udev as
 Joost proposes. But then is more code to maintain, and the number of
 possible setups is suddenly the double it was before. It. Is. Not.
 KISS.

Depends on your definition of Simple.

 It's a lot like the CUPS/lprng situation we discussed before. CUPS can
 do anything that lprng does, so it makes no sense to keep support for
 lprng. It's the same: with an initramfs you will be able to do
 anything, so it will make no sense to keep supporting initramfs-less
 systems.

The situation with Cups and lprng is different.
If either of these fail, the system will still boot and then you can spend the 
time to fix the problem.

If this change continues, an initramfs failure, will mean the system will not 
boot correctly. And when all the tools needed to fix the system are moved to 
/usr, what options are there to actually analyse and solve the problem?

In my opinion, the simplest solution will be to make the tool(s) do what 
they're supposed to do.
udev should, in my opinion, create the devices in userspace.
That it also allows for programs/scripts to be executed when a device is 
created is a nice thing to have.
Unfortunately, this leads to chicken-and-egg style problems when the scripts 
are on a filesystem that hasn't been mounted yet.

There are 3 solutions for this:
1) The easy way out: the whole user-space must be available before udev
2) udev actually includes correct error-handling for this and retries
3) udev splits this into 2 seperate tools

Option 1 is what is currenty proposed and what you appear to be in favour off.
Except, what is the point of having udev when the entire user-space already 
exists before it starts?
You yourself said it's nice to have everything already available from the 
beginning. But isn't the problem that udev can't start bluetoothd because 
/usr/bin/bluetoothd can't be found when /usr doesn't exist yet?

How would udev handle a situation where I have /usr on my mobile phone which 
shares the filesystem over bluetooth?

Option 2 has been suggested and rejected. And I happen to agree with this as 
it would make udev, a vital part of the system, bigger and will increase the 
chances of problems/bugs.

Option 3, which I have proposed, would actually make the first part smaller 
and simpler.
The action-handling can then be run at a later stage, when /usr is available 
and could then easier implement a retry-queue. With this being a seperate 
tool, not needed for the /dev-tree creation, failure on this should not lead 
to an unusable system.

--
Joost

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org 
wrote:
  On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
  On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
  
  wrote:
   I'm not entirely convinced this is the case, because it feels
   like
   some situations like network devices (nbd, iSCSI) or loopback
   would
   require userland tools to bring up once networking is up.
   
   Yes, but the kernel-events referencing those devices won't appear
   untill after the networking is brought up.
   The scripts that udev starts are run *after* a device-event is
   created. If the device itself has not been spotted by the kernel
   (for
   instance, the networking doesn't exist yet), the event won't be
   triggered yet.
   
   This situation does not require udev to start all these tools when
   network- devices appear.
   
   I hope the following would make my thoughts a bit clearer:
   
   1) kernel boots
   
   2) kernel detects network device and places network-device-event
   in
   the
   queue
   
   3) further things happen and kernel places relevant events in the
   queue (some other events may also already be in the queue before
   step 2)
   
   4) udev starts and starts processing the queue
   
   5) For each event, udev creates the corresponding device-entry and
   places
   action-entries in a queue
   
   6) system-init-scripts mount all local filesystems
   
   7) udev-actions starts (I made up this name)
   
   8) udev-actions processes all the entries in the action-queue
   
   From step 4, udev will keep processing further events it gets,
   which
   means that if any action taken by udev-actions causes further
   devices to become available, udev will create the
   device-entries and place the action in the action-queue.
  
  So, if I read this correctly, there are two classes of processing
  events. kernel events and scripted actions. Here's rough pseudocode
  describing what I think you're saying. (Or perhaps what I'm hoping
  you're saying)
  
  while(wait_for_event())
  {
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event
  was
  waiting {
  process_kernel_event(pkEvent);
}
else
{
  aevent* pAction = NULL;
  if(get_waiting_action(pAction)) // Returns true if there's an
  action waiting.
  {
process_action(pAction);
  }
}
  }
  
  This is, sort-of, what I feel should happen. But currently, in
  pseudo-code, the following seems to happen:
  while(wait_for_event())
  {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
  waiting {
 process_kernel_event(pkEvent);
   }
  }
  
  I would prefer to see 2 seperate processes:
  
  --- process 1 ---
  while(wait_for_event())
  {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
  waiting
   {
 action_event = process_kernel_event(pkEvent);
 if (action_event != NULL)
 {
   put_action_event(pkEvent);
 }
   }
  }
  
  --
  
  --- process 2 ---
  while(wait_for_event())
  {
   aevent* paEvent = NULL;
   if(get_waiting_action_event(paEvent)) // returns true if an event was
  waiting
   {
 process_action_event(paEvent);
   }
  }
  ---
  
  So, udev processes one event at a time, and always processes kernel
  events with a higher priority than resulting scripts. This makes a
  certain amount of sense; an action could launch, e.g. nbdclient, which
  would cause a new kernel event to get queued.
  
  Yes, except that udev ONLY handles kernel-events and doesn't process any
  actions itself.
  These are placed on a seperate queue for a seperate process.
 
 The problem with this is that you now need to manage synchronization
 between the kernel event processor and the action processor, which is
 actually more complicated than keeping them together in a
 single-threaded, single-process scenario.

I don't agree. Why does this need to be synchronized?

The kernel puts events in the new-dev-event-queue that process 1 picks up.
process 1 creates the /dev-entrie(s) and, if there is an action to be taken, 
puts the action in the new-action-event-queue.

Process 2 will then pick up this action from the new-action-event-queue and 
will process this.

If, as a side-effect, of the action processed by process 2, a new device 
appears for the kernel, the kernel will simply put a corresponding event in 
the new-dev-event-queue.

At which state does this need to be synchronized?
We can simply use a pipe-device as, for instance, used for syslog?

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 11:43 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org
 wrote:
 The problem with this is that you now need to manage synchronization
 between the kernel event processor and the action processor, which is
 actually more complicated than keeping them together in a
 single-threaded, single-process scenario.

 I don't agree. Why does this need to be synchronized?

 The kernel puts events in the new-dev-event-queue that process 1 picks up.
 process 1 creates the /dev-entrie(s) and, if there is an action to be taken,
 puts the action in the new-action-event-queue.

 Process 2 will then pick up this action from the new-action-event-queue and
 will process this.

 If, as a side-effect, of the action processed by process 2, a new device
 appears for the kernel, the kernel will simply put a corresponding event in
 the new-dev-event-queue.

 At which state does this need to be synchronized?
 We can simply use a pipe-device as, for instance, used for syslog?

Let's assume that you have a single-reader, single-writer scenario,
and that either the protocol includes a 'record end' marker, or that
protocol messages are all of a fixed length and are written
atomically. With that out of the way, I don't know. Perhaps no
additional synchronization is necessary.

You still have a problem with race conditions. Virtually all scripts
I've read and written assume a single-threaded environment, but you've
defined a two-threaded environment.

Here's a potential scenario:

1) A kernel hotplug event comes in when a device is inserted.
2) keventler catches the hotplug event, creates the device node,
queues an action event.
3) actionhandler catches the action event, launches the script.
4) The action handler script is still running for the plug-in event,
when A kernel hotplug event comes in indicating the device was
removed. keventler catches the new hotplug event, removes the device
node--
5) --the scheduler comes around and resumes working on the action
handler script. Or perhaps the action handler script was on a
different CPU core, and never needed to be unscheduled. The device
node it was expecting to be there just disappeared out from under it,
violating one of its assumptions, and putting it in an inconsistent
state. The inconsistency might occur in a place the script author
expected it, or the inconsistency might have occurred in an unexpected
place. One presumes the script author didn't sign up to deal with
concurrency issues in a bash or python script.
6) keventler  registers a new action event, for actioning on the disconnect.
7) actionhandler picks up this new action event, runs the script.
Kudos to the script author for thinking ahead to have a shutdown
script properly clean up an inconsistent system state left by the
partially failed setup script.

Steps 3-5 are a classic example of a race condition, and stem from two
active threads operating concurrently. Entire programming languages
are developed with the core intent of reducing the programmer's need
to worry about such things.

You _must not_ change the operating environment of a script out from under it.

In bash scripts, this is an extraordinarily common pattern:

if [ -d $SOME_PATH ]; then
  // do something
fi

That's common and accepted; nobody expects a shell script to fail in a
scenario like that, because it's is a single-threaded language, and
that's been true since its inception. When something keventler does
causes the result of [ -d $SOME_PATH ] to change after the test had
already been done, then the script is only broken because
keventler/actionhandler broke it, not because the script was badly
written.

I've really got to get back to working on stuff I'm being paid for.
I'll chat with you guys this weekend. I'm very interested in helping
with a reasoned critical perspective, so if this wanders over to a new
mailing list or discussion environment, drop me an invite.

-- 
:wq

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 12:16:24 PM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 11:43 AM, Joost Roeleveld jo...@antarean.org 
wrote:
  On Thursday, September 15, 2011 11:03:09 AM Michael Mol wrote:
  On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org
  
  wrote:
  The problem with this is that you now need to manage synchronization
  between the kernel event processor and the action processor, which is
  actually more complicated than keeping them together in a
  single-threaded, single-process scenario.
  
  I don't agree. Why does this need to be synchronized?
  
  The kernel puts events in the new-dev-event-queue that process 1 picks
  up. process 1 creates the /dev-entrie(s) and, if there is an action to
  be taken, puts the action in the new-action-event-queue.
  
  Process 2 will then pick up this action from the new-action-event-queue
  and will process this.
  
  If, as a side-effect, of the action processed by process 2, a new device
  appears for the kernel, the kernel will simply put a corresponding event
  in the new-dev-event-queue.
  
  At which state does this need to be synchronized?
  We can simply use a pipe-device as, for instance, used for syslog?
 
 Let's assume that you have a single-reader, single-writer scenario,
 and that either the protocol includes a 'record end' marker, or that
 protocol messages are all of a fixed length and are written
 atomically. With that out of the way, I don't know. Perhaps no
 additional synchronization is necessary.
 
 You still have a problem with race conditions. Virtually all scripts
 I've read and written assume a single-threaded environment, but you've
 defined a two-threaded environment.
 
 Here's a potential scenario:
 
 1) A kernel hotplug event comes in when a device is inserted.
 2) keventler catches the hotplug event, creates the device node,
 queues an action event.
 3) actionhandler catches the action event, launches the script.
 4) The action handler script is still running for the plug-in event,
 when A kernel hotplug event comes in indicating the device was
 removed. keventler catches the new hotplug event, removes the device
 node--
 5) --the scheduler comes around and resumes working on the action
 handler script. Or perhaps the action handler script was on a
 different CPU core, and never needed to be unscheduled. The device
 node it was expecting to be there just disappeared out from under it,
 violating one of its assumptions, and putting it in an inconsistent
 state. The inconsistency might occur in a place the script author
 expected it, or the inconsistency might have occurred in an unexpected
 place. One presumes the script author didn't sign up to deal with
 concurrency issues in a bash or python script.
 6) keventler  registers a new action event, for actioning on the disconnect.
 7) actionhandler picks up this new action event, runs the script.
 Kudos to the script author for thinking ahead to have a shutdown
 script properly clean up an inconsistent system state left by the
 partially failed setup script.
 
 Steps 3-5 are a classic example of a race condition, and stem from two
 active threads operating concurrently. Entire programming languages
 are developed with the core intent of reducing the programmer's need
 to worry about such things.

 You _must not_ change the operating environment of a script out from under
 it.
 
 In bash scripts, this is an extraordinarily common pattern:
 
 if [ -d $SOME_PATH ]; then
   // do something
 fi
 
 That's common and accepted; nobody expects a shell script to fail in a
 scenario like that, because it's is a single-threaded language, and
 that's been true since its inception. When something keventler does
 causes the result of [ -d $SOME_PATH ] to change after the test had
 already been done, then the script is only broken because
 keventler/actionhandler broke it, not because the script was badly
 written.

Ok, didn't think of this scenario. Thank you for pointing this out to me.
Your pseudo-code would be better then, except there should be some way of 
delaying action-tasks based on wether or not required files (including 
dependencies) are available. Or a retry-queue that retries an action a few 
times with certain intervals. This, however, will be more difficult to 
implement especially with the race-condition you mentioned.

 I've really got to get back to working on stuff I'm being paid for.
 I'll chat with you guys this weekend. I'm very interested in helping
 with a reasoned critical perspective, so if this wanders over to a new
 mailing list or discussion environment, drop me an invite.

We will, but for now, why not keep it on here? :)

Was wondering, does udev actually support actions for when a device is 
removed?
Ok, just checked on my server and it does. All nicely pointing to scripts in 
/etc/

Also, anyone knows how udev handles the scenario where a device is removed 
while the script is still running? Wouldn't it fail mid-execution

Re: [gentoo-user] udev + /usr

2011-09-15 Thread pk

On 2011-09-15 16:57, Canek Peláez Valdés wrote:

 Of course you can solve it differently, for example splitting udev as
 Joost proposes. But then is more code to maintain, and the number of
 possible setups is suddenly the double it was before. It. Is. Not.
 KISS.

https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy

I can especially point out:
Rule of Modularity
Rule of Parsimony
Rule of Diversity

 It's a lot like the CUPS/lprng situation we discussed before. CUPS can
 do anything that lprng does, so it makes no sense to keep support for
 lprng. It's the same: with an initramfs you will be able to do
 anything, so it will make no sense to keep supporting initramfs-less
 systems.

... one ring to rule them all...

Best regards

Peter K

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés can...@gmail.com wrote:
 On Thu, Sep 15, 2011 at 10:48 AM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 10:32:50 AM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 10:11 AM, Joost Roeleveld jo...@antarean.org
 wrote:
  I'm not entirely convinced this is the case, because it feels like
  some situations like network devices (nbd, iSCSI) or loopback would
  require userland tools to bring up once networking is up.
 
  Yes, but the kernel-events referencing those devices won't appear untill
  after the networking is brought up.
  The scripts that udev starts are run *after* a device-event is
  created. If the device itself has not been spotted by the kernel (for
  instance, the networking doesn't exist yet), the event won't be
  triggered yet.
 
  This situation does not require udev to start all these tools when
  network- devices appear.
 
  I hope the following would make my thoughts a bit clearer:
 
  1) kernel boots
 
  2) kernel detects network device and places network-device-event in
  the
  queue
 
  3) further things happen and kernel places relevant events in the queue
  (some other events may also already be in the queue before step 2)
 
  4) udev starts and starts processing the queue
 
  5) For each event, udev creates the corresponding device-entry and
  places
  action-entries in a queue
 
  6) system-init-scripts mount all local filesystems
 
  7) udev-actions starts (I made up this name)
 
  8) udev-actions processes all the entries in the action-queue
 
  From step 4, udev will keep processing further events it gets, which
  means that if any action taken by udev-actions causes further devices
  to become available, udev will create the device-entries and place
  the action in the action-queue.

 So, if I read this correctly, there are two classes of processing
 events. kernel events and scripted actions. Here's rough pseudocode
 describing what I think you're saying. (Or perhaps what I'm hoping
 you're saying)

 while(wait_for_event())
 {
   kevent* pkEvent = NULL;
   if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
     process_kernel_event(pkEvent);
   }
   else
   {
     aevent* pAction = NULL;
     if(get_waiting_action(pAction)) // Returns true if there's an
 action waiting.
     {
       process_action(pAction);
     }
   }
 }

 This is, sort-of, what I feel should happen. But currently, in pseudo-code,
 the following seems to happen:
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting {
    process_kernel_event(pkEvent);
  }
 }

 I would prefer to see 2 seperate processes:

 --- process 1 ---
 while(wait_for_event())
 {
  kevent* pkEvent = NULL;
  if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
 waiting
  {
    action_event = process_kernel_event(pkEvent);
    if (action_event != NULL)
    {
      put_action_event(pkEvent);
    }
  }
 }

 --

 --- process 2 ---
 while(wait_for_event())
 {
  aevent* paEvent = NULL;
  if(get_waiting_action_event(paEvent)) // returns true if an event was
 waiting
  {
    process_action_event(paEvent);
  }
 }
 ---

 So, udev processes one event at a time, and always processes kernel
 events with a higher priority than resulting scripts. This makes a
 certain amount of sense; an action could launch, e.g. nbdclient, which
 would cause a new kernel event to get queued.

 Yes, except that udev ONLY handles kernel-events and doesn't process any
 actions itself.
 These are placed on a seperate queue for a seperate process.

  If anyone has a setup where /usr can not be mounted easily, it won't
  work
  currently either and a init* would be necessary anyway.
  (Am thinking of NFS, CIFS, iSCSI, NBD, special raid-drivers, hosting
  /usr or other required filesystems)

 I don't see how this is relevant to actually fixing udev. (See below)

  But anyone with a currently working environment should be able to expect
  a currently working environment. If it fails to boot with only updating
  versions, it's a regression. And one of the worst kinds of all.

 I agree that the direction udev is going is a regression. There aren't
 very many people active in this thread who would disagree with that
 point. So let's just drop it and focus on what a good, general
 solution would look like. (And anyone who says something amounting to
 'status quo' for udev needs another explanation of why the udev
 developer sees the current scenario as broken. And he's right; the
 current scenario is architecturally unsound. I just think he's wrong
 about the solution.)

 I agree he is wrong about the solution as well.

 I have actually just posted my idea to the gentoo-dev list to see how the
 developers actually feel about possible splitting udev into 2 parts.

 I'm not a good enough programmer to do this myself. But if anyone who can 
 code
 and who also agrees

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Mick

On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
 On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
  I agree he is wrong about the solution as well.
  
  I have actually just posted my idea to the gentoo-dev list to see how the
  developers actually feel about possible splitting udev into 2 parts.
 
 I've read it there. Thanks for doing this.

Thanks Joost for posting in the dev list and for explaining your proposed 
approach there.  I've just read your thread in the dev list:

http://thread.gmane.org/gmane.linux.gentoo.devel/72969


Zac's response helped me understand better what the Gentoo devs have been 
suggesting here:

http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml

and it does make sense - their version of initramfs-'lite'.

From what I understand:

1.  The minimal initramfs will only need to be built once (and rarely rebuilt 
thereafter).  This removes one of my fears and it was a main objection for me 
- I would hate to have to rebuild initramfs every time I roll a new kernel, or 
libs and what not of fs happen to be udpated, etc.

2. If initramfs fails, then Zac says it will drop you into a minimal shell, so 
we should still be able to recover/troubleshoot/reboot from there.

The only drawback is the 2 minutes it will take a user the first time this 
change is introduced to build the initramfs and change the kernel line in 
grub.conf.  I am warming up to this proposal because it seems to me that it 
will end up being less painful that I originally thought.

However, I still see it as a workaround to a more elegant solution, which as 
Joost and others suggest would involve separating udev's probing for devices 
with the rules running of scripts for them.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Neil Bothwick

On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote:

 There are 3 solutions for this:
 1) The easy way out: the whole user-space must be available before udev
 2) udev actually includes correct error-handling for this and retries
 3) udev splits this into 2 seperate tools

4) udev remains one tool but with two modes of operation. when in
early-boot mode, it can only run a restricted set of rules - such as
those using LVM, RAID, cryptsetup, network device naming. When switched
to full mode later in the boot process, it loads the rest of the rules.

Which rules it runs it early-boot mode could be decided by adding a flag
to the rule to mark it acceptable for early boot usage. That way,
existing rules would automatically be deferred  unless package
maintainers update the rules for those they know will work early in the
boot process.

It saves writing/learning/debugging a new tool and gives maximum
compatibility with existing configurations.

This is pretty similar in concept to your suggestion 3, but a different
approach to its implementation.


-- 
Neil Bothwick

No, you *can't* call 999 now. I'm downloading my mail.


signature.asc
Description: PGP signature

IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-15 Thread David W Noon

On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
OT now (Re: [gentoo-user] udev + /usr):

 It occurred to me that having a decent C and C++ editing environment
 might ease some of my of the spoilage I've experienced in Visual
 Studio for C++. I'll be checking it out. It'll mean learning emacs,
 though...

If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
program, so runs natively under GNOME, Xfce and LXDE, while the latter
is a Qt suite that runs natively under KDE.  Both are *way* slicker
than Emacs or vim, but do require a graphical desktop. [Both vim and
Emacs can run in a text console.]

You might also start reading comp.os.linux.development.apps on Usenet,
if you don't already do so.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


signature.asc
Description: PGP signature

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote:
 On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
 On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote:
  I agree he is wrong about the solution as well.
 
  I have actually just posted my idea to the gentoo-dev list to see how the
  developers actually feel about possible splitting udev into 2 parts.

 I've read it there. Thanks for doing this.

 Thanks Joost for posting in the dev list and for explaining your proposed
 approach there.  I've just read your thread in the dev list:

 http://thread.gmane.org/gmane.linux.gentoo.devel/72969


 Zac's response helped me understand better what the Gentoo devs have been
 suggesting here:

 http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml

 and it does make sense - their version of initramfs-'lite'.

 From what I understand:

 1.  The minimal initramfs will only need to be built once (and rarely rebuilt
 thereafter).  This removes one of my fears and it was a main objection for me
 - I would hate to have to rebuild initramfs every time I roll a new kernel, or
 libs and what not of fs happen to be udpated, etc.

In my experience, it takes more time to build the kernel than it takes
to rebuild the initramfs. And if you choose to use dracut, the process
is automatic (you always call dracut with the same options, unless you
suddenly add LVM or something similar).

I didn't use an initramfs for my first years using Gentoo. Since I
started to use media-gfx/splashutils a couple of years ago, every time
I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
the same, but with plymouth and systemd using dracut. It's just part
of the process of getting a new kernel.

 2. If initramfs fails, then Zac says it will drop you into a minimal shell, so
 we should still be able to recover/troubleshoot/reboot from there.

From the last response in the -dev list (from Rich Freeman):

“It should be noted that the alternative is to use a more
full-featured initramfs like dracut, which will also be updated to
support mounting /usr (it already parses /etc/fstab to remount root
anyway).

...

Note that dracut does drop you to a shell if it fails (this is
configurable), but by default this shell is dash, not bash.  No doubt
it would work fine either way, but bash is likely to be a little
slower.  I don't think RAM use is likely to be a problem - it should
be completely de-allocated before init runs.”

 The only drawback is the 2 minutes it will take a user the first time this
 change is introduced to build the initramfs and change the kernel line in
 grub.conf.  I am warming up to this proposal because it seems to me that it
 will end up being less painful that I originally thought.

Reading the homepages of the projects involved always helps to better
understand the possible outcome of using the new technologies. Perhaps
you should take a look at dracut: Maybe a complete initramfs solution
will convince you, especially if an initramfs will be needed anyway.

 However, I still see it as a workaround to a more elegant solution, which as
 Joost and others suggest would involve separating udev's probing for devices
 with the rules running of scripts for them.

Maybe that's the more elegant solution. Certainly it will take a lot
more effort, in the sense that somebody has to implement, test and
debug said solution. I sincerely wish them good luck.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

On Thu, Sep 15, 2011 at 2:58 PM, David W Noon dwn...@ntlworld.com wrote:
 On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
 OT now (Re: [gentoo-user] udev + /usr):

 It occurred to me that having a decent C and C++ editing environment
 might ease some of my of the spoilage I've experienced in Visual
 Studio for C++. I'll be checking it out. It'll mean learning emacs,
 though...

 If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
 program, so runs natively under GNOME, Xfce and LXDE, while the latter
 is a Qt suite that runs natively under KDE.  Both are *way* slicker
 than Emacs or vim, but do require a graphical desktop. [Both vim and
 Emacs can run in a text console.]

I'm not touching KDE again for a while. I got nailed pretty bad with a
NVidia/Konsole/KWin, and I really wasn't using much of KDE.

That said, I might poke KDevelop again; I haven't poked it in years.
Geany is new since I last dug around.

I do like text environments, though.


 You might also start reading comp.os.linux.development.apps on Usenet,
 if you don't already do so.

Keeping up with this list is hard enough! But, thanks. :)



-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Neil Bothwick

On Thu, 15 Sep 2011 15:04:37 -0400, Canek Peláez Valdés wrote:

  1.  The minimal initramfs will only need to be built once (and rarely
  rebuilt thereafter).  This removes one of my fears and it was a main
  objection for me
  - I would hate to have to rebuild initramfs every time I roll a new
  kernel, or libs and what not of fs happen to be udpated, etc.  
 
 In my experience, it takes more time to build the kernel than it takes
 to rebuild the initramfs. And if you choose to use dracut, the process
 is automatic (you always call dracut with the same options, unless you
 suddenly add LVM or something similar).

The concern is not the time (Gentoo users are used to waiting for things
to install) it's the opportunity for failure.


-- 
Neil Bothwick

IBM: Itty Bitty Mentality


signature.asc
Description: PGP signature

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-15 Thread Leonardo Guilherme

2011/9/15 Michael Mol mike...@gmail.com

 On Thu, Sep 15, 2011 at 2:58 PM, David W Noon dwn...@ntlworld.com wrote:
  On Wed, 14 Sep 2011 18:35:37 -0400, Michael Mol wrote about Re: Really
  OT now (Re: [gentoo-user] udev + /usr):
 
  It occurred to me that having a decent C and C++ editing environment
  might ease some of my of the spoilage I've experienced in Visual
  Studio for C++. I'll be checking it out. It'll mean learning emacs,
  though...
 
  If you like Visual Studio, try Geany or KDevelop.  The former is a Gtk+
  program, so runs natively under GNOME, Xfce and LXDE, while the latter
  is a Qt suite that runs natively under KDE.  Both are *way* slicker
  than Emacs or vim, but do require a graphical desktop. [Both vim and
  Emacs can run in a text console.]

 I'm not touching KDE again for a while. I got nailed pretty bad with a
 NVidia/Konsole/KWin, and I really wasn't using much of KDE.

 That said, I might poke KDevelop again; I haven't poked it in years.
 Geany is new since I last dug around.

 I do like text environments, though.

 
  You might also start reading comp.os.linux.development.apps on Usenet,
  if you don't already do so.

 Keeping up with this list is hard enough! But, thanks. :)



 --
 :wq


I do not know the state of Geanny since I last checked (couple of years
ago), but the highlight capabilites of KDevelop got my eye. It highlights
local variables in different colors in the same context, so something like

int foo(float bar, float baz) {
}

will have bar and baz in different colors. Also, support for CMake in
KDevelop got really great and useful. Plus, it supports debugging inside the
editor. Its awesome.

-- 

Leonardo

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-15 Thread Chris Brennan

On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
leonardo.guilhe...@gmail.com wrote:

I do not know the state of Geanny since I last checked (couple of years
 ago), but the highlight capabilites of KDevelop got my eye. It highlights
 local variables in different colors in the same context, so something like

 int foo(float bar, float baz) {
 }

 will have bar and baz in different colors. Also, support for CMake in
 KDevelop got really great and useful. Plus, it supports debugging inside the
 editor. Its awesome.


If you want something in a gui, what about Code::Blocks? It's also
multi-platform

 --
 Chris Brennan
 A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting frowned upon?
 http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/
 GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8  9E4A EECD 9A84 D5B2 0C0C)

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan xa...@xaerolimit.net wrote:
 On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
 leonardo.guilhe...@gmail.com wrote:

 I do not know the state of Geanny since I last checked (couple of years
 ago), but the highlight capabilites of KDevelop got my eye. It highlights
 local variables in different colors in the same context, so something like
 int foo(float bar, float baz) {
 }
 will have bar and baz in different colors. Also, support for CMake in
 KDevelop got really great and useful. Plus, it supports debugging inside the
 editor. Its awesome.

 If you want something in a gui, what about Code::Blocks? It's also
 multi-platform

Ok, what are the atom names for all these? I'll start them building,
and they should be done before I get home. (Not so likely if I have to
build all of KDE, but I've got some Qt apps installed, so...)

-- 
:wq

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Sebastian Beßler

Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:

 with an initramfs you will be able to do anything, so it will make no
 sense to keep supporting initramfs-less systems.

With Microsoft Windows you will be able to do anything, so it will
make no sense to keep supporting Microsoft Windows-less systems.

With Gnome you will be able to do anything, so it will make no sense to
keep supporting Gnome-less systems.

With Emacs you will be able to do anything, so it will make no sense to
keep supporting Emacs-less systems.

Greetings

Sebastian Beßler



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Alan McKinnon

On Thu, 15 Sep 2011 09:47:34 -0400
Michael Mol mike...@gmail.com wrote:

  The main purpose of udev is to populate the /dev-tree.
  The running of scripts based on /dev-tree events should be in a
  seperate tool that starts later in the boot-process.  
 
 I'm not *entirely* convinced this is the case, because it feels like
 some situations like network devices (nbd, iSCSI) or loopback would
 require userland tools to bring up once networking is up.

I'd say you are both right.

Joost gave the correct (in my view) overriding principle.
You gave what to do when that just doesn't cut it.

Real-world systems involve exceptions for unusual (but valid)
conditions. The best solution is to deal with the exception within a
narrow focus, instead of just allowing everything like udev seems
determined to go to.

-- 
Alan McKinnnon
alan.mckin...@gmail.com

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
sebast...@darkmetatron.de wrote:
 Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:

 with an initramfs you will be able to do anything, so it will make no
 sense to keep supporting initramfs-less systems.

 With Microsoft Windows you will be able to do anything, so it will
 make no sense to keep supporting Microsoft Windows-less systems.

Irrelevant: see the name on the list? It's called Gentoo Linux. I know
you are trying to be witty, but only shows you are comparing apples
and oranges.

 With Gnome you will be able to do anything, so it will make no sense to
 keep supporting Gnome-less systems.

 With Emacs you will be able to do anything, so it will make no sense to
 keep supporting Emacs-less systems.

Last time I checked, neither GNOME nor Emacs demanded that Gentoo
developers or users had to write a fork/replacement for a core
component of the system. GNOME and Emacs just need ebuilds and
adapting their configuration to Gentoo-isms. Testing and bug
reporting, as usual. The only code needed is some small patches for
both and around 200 lines of emacslisp for site-gentoo.el.

Again, not witty, just not very informed.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Mike Edenfield

On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
 Canek Peláez Valdés wrote:

  But that's the thing: we (you and me) don't see the situation the same
  way. To me, the proposed changes are for the better.
 
 You are one of very few that feel this way.

You are probably correct that he's one of the relatively few people (along 
with the udev developer, and those few people for whom it will fix their 
problems) who think these changes are a real improvement.

I would estimate that the vast, vast, vast majority of users are those such as 
myslelf, who have no opinion whatsoever, and either will not be affected at all 
by these changes (because they don't separate / and /usr), or will simply 
apply the proposed initramfs solution and move on.

Then there are those relatively few people, such as the handful making up the 
rest of this thread, who think that these changes are a horrible idea and will 
have a severe deterimental affect on their systems.

Not that the relative size of the various sides in this debate is really the 
issue, but despite the tone of this and the other thread, I don't think 
there's really a huge, overwhelming outcry against these changes.

--Mike

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Sebastian Beßler

Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
 On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
 sebast...@darkmetatron.de wrote:
 Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:

 with an initramfs you will be able to do anything, so it will make no
 sense to keep supporting initramfs-less systems.

 With Microsoft Windows you will be able to do anything, so it will
 make no sense to keep supporting Microsoft Windows-less systems.
 
 Irrelevant: see the name on the list? It's called Gentoo Linux. I know
 you are trying to be witty, but only shows you are comparing apples
 and oranges.

No, because first it was sarcasm and second it shows that your argument
is invalid. For near to every X there is some Y that can do what X can
do, but there are still many good and valid reasons to have X. So it
will make sense to keep supporting Y-less systems.

Greetings

Sebastian Beßler



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 4:42 PM, Mike Edenfield kut...@kutulu.org wrote:
 On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
 Canek Peláez Valdés wrote:

  But that's the thing: we (you and me) don't see the situation the same
  way. To me, the proposed changes are for the better.

 You are one of very few that feel this way.

 You are probably correct that he's one of the relatively few people (along
 with the udev developer, and those few people for whom it will fix their
 problems) who think these changes are a real improvement.

 I would estimate that the vast, vast, vast majority of users are those such as
 myslelf, who have no opinion whatsoever, and either will not be affected at 
 all
 by these changes (because they don't separate / and /usr), or will simply
 apply the proposed initramfs solution and move on.

 Then there are those relatively few people, such as the handful making up the
 rest of this thread, who think that these changes are a horrible idea and will
 have a severe deterimental affect on their systems.

 Not that the relative size of the various sides in this debate is really the
 issue, but despite the tone of this and the other thread, I don't think
 there's really a huge, overwhelming outcry against these changes.

My complaints are chiefly philosophical; it's not a correct solution,
because the problems it purports to fix will just re-emerge down the
road. I'm all in favor of well-architected systems and good, sound,
informed discussion. I've only been involved in this thread as much as
I have been because there's been a dearth of such in it.

-- 
:wq

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 4:53 PM, Sebastian Beßler
sebast...@darkmetatron.de wrote:
 Am 15.09.2011 22:27, schrieb Canek Peláez Valdés:
 On Thu, Sep 15, 2011 at 4:05 PM, Sebastian Beßler
 sebast...@darkmetatron.de wrote:
 Am 15.09.2011 16:57, schrieb Canek Peláez Valdés:

 with an initramfs you will be able to do anything, so it will make no
 sense to keep supporting initramfs-less systems.

 With Microsoft Windows you will be able to do anything, so it will
 make no sense to keep supporting Microsoft Windows-less systems.

 Irrelevant: see the name on the list? It's called Gentoo Linux. I know
 you are trying to be witty, but only shows you are comparing apples
 and oranges.

 No, because first it was sarcasm and second it shows that your argument
 is invalid. For near to every X there is some Y that can do what X can
 do, but there are still many good and valid reasons to have X. So it
 will make sense to keep supporting Y-less systems.

And you conveniently skipped my answer to your last two examples. No
problem, here it goes again:

Last time I checked, neither GNOME nor Emacs demanded that Gentoo
developers or users had to write a fork/replacement for a core
component of the system. GNOME and Emacs just need ebuilds and
adapting their configuration to Gentoo-isms. Testing and bug
reporting, as usual. The only code needed is some small patches for
both and around 200 lines of emacslisp for site-gentoo.el.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
 On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
  Canek Peláez Valdés wrote:
   But that's the thing: we (you and me) don't see the situation the
   same
   way. To me, the proposed changes are for the better.
  
  You are one of very few that feel this way.
 
 You are probably correct that he's one of the relatively few people (along
 with the udev developer, and those few people for whom it will fix their
 problems) who think these changes are a real improvement.

If for those people using an initramfs solves their problems, then I'm not 
against it. And I don't think many others are either.
But why are people forced to use an initramfs where it is not needed?

 I would estimate that the vast, vast, vast majority of users are those such
 as myslelf, who have no opinion whatsoever, and either will not be affected
 at all by these changes (because they don't separate / and /usr), or will
 simply apply the proposed initramfs solution and move on.

You also don't have /var (or /var/log) seperated? Or any of the other parts of 
the filesystem that might be required by udev-rules?

 Then there are those relatively few people, such as the handful making up
 the rest of this thread, who think that these changes are a horrible idea
 and will have a severe deterimental affect on their systems.

Any added complexity is another thing that can go wrong.
In the thread on gentoo-dev, I am trying to figure out 3 things:
1) How are the Gentoo Developers planning on adding this new change?
2) What are the options for not having to have an initramfs if the udev-rules 
used don't actually require /usr and co to be mounted.
3) Get their input in a possible alternative (like fixing the, what I see, 
design-flaws of udev)

On 1, I am actually quite pleased. The actual information I could find 
previously sounded a lot worse. I've just got a few more questions open based 
on their answers. Once I have the full picture, I'll post it back here.

For 2, I've only just started. I'll also post back here on what my findings 
are.

For 3, I've got some feedback on how udev currently handles things. These 
actually have given me a few other ways in which to try to solve the issue. 
I'll need to try to find out how udev actually handles the retry queue 
currently.

 Not that the relative size of the various sides in this debate is really
 the issue, but despite the tone of this and the other thread, I don't think
 there's really a huge, overwhelming outcry against these changes.

I wonder how many are actually aware of these changes. But yes, I think plenty 
of people will not care and if the Gentoo-devs handle this correctly (which, 
so far, I think they are) those people won't even notice.

But, there will always be some people who get bitten by this and my reasons 
for going with parts 1 and 2 is to see how to keep this group as small as 
possible.

--
Joost

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 01:43:17 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 10:58 AM, Canek Peláez Valdés can...@gmail.com 
wrote:
 (This mail is to keep the guys un -user in the loop about -devel).
 
 OK, so Joost posted his proposal to -dev:

snipped brief discussion on gentoo-dev

The thread on gentoo-dev is not yet finished and I intend to try to get some 
more information. As I mentioned in my other email.

 I would also like to point you guys to this article in LWN.net:
 
 http://lwn.net/SubscriberLink/458789/3ae00c9827889929/
 
 The article (the second part about systemd) closes with:
 
 “The overall picture was of a project that is on a roll, gaining
 features and users at a fast rate. The Systemd view of the world has
 not yet won over everybody, but the opposition seems to be fading.
 Systemd looks like the init system of the future (and more) for a lot
 of high-profile distributions.”
 
 The article was written by Jonathan Corbet, editor of LWN and (I think
 most people would agree with me) someone who has always tried to be
 objective and impartial.

I'll read this later (probably tomorrow) and get back to you on this if 
necessary.

 So, if Joost and others are willing and able to implement the
 necessary bits to avoid the need for an initramfs, I salute them and
 wish them luck. But the most probable outcome is this:
 
 * The fork/replacement will take years of man-effort: design,
 implementation, debug, documentation, mainteinance.
 * At the same time, the dev-approved solution of a minimal initramfs
 or a dracut/genkernel generated one will be available and working.
 * If the forking/replacement team manages to create a workable
 fork/replacement, it will have to sell it to the Gentoo devs, and if
 the initramfs solution is working properly the most rational answer
 will be no, thank you.

The time needed for this is not certain as we are planning on basing it on the 
current udev and see what is possible.
If the Gentoo-devs come up with a fool-proof solution, which is one of the 
possible outcomes I am trying to get to in the gentoo-dev thread, I will be 
happy there as well.

As for the udev-fork to ever becoming mainstream, I can't say. It might not 
even work the way we are hoping. Only time will tell.

 I'm sorry if my analysis bother some people, but it's basically what
 I've been saying from the beginning. I'm glad Joost asked the
 developers for their input. I think it clears the air about a lot of
 things.

I have no problem with your analysis and yes, the initial response from Zac 
was what you've been saying.
I am hoping to get more information on this and I will have no problem if you 
keep reporting it back here.

One of the reasons I asked it on Gentoo-dev is simply because I agree with 
some people here that this thread was starting to go in circles and no new 
information was being added.

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 5:16 PM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:
 On Wednesday, September 14, 2011 01:36:56 PM Dale wrote:
  Canek Peláez Valdés wrote:
   But that's the thing: we (you and me) don't see the situation the
   same
   way. To me, the proposed changes are for the better.
 
  You are one of very few that feel this way.

 You are probably correct that he's one of the relatively few people (along
 with the udev developer, and those few people for whom it will fix their
 problems) who think these changes are a real improvement.

 If for those people using an initramfs solves their problems, then I'm not
 against it. And I don't think many others are either.
 But why are people forced to use an initramfs where it is not needed?

bad_jokeWell, technically it's not forced... if you put /usr in /
then you don't need it.../bad_joke

The thing is that the initramfs solution solves the general problem
(as the devs keep trying to explain in -dev). You may not *want* to
use an initramfs, but it *will* solve the problem.

The devs *could* make up an alternative for an initramfs for those
people who fell they don't need one, but then they (not us) need to
maintain it, test it, document it, etc. It is not worth it if the
initramfs works for everyone... even for those who don't want it.

 I would estimate that the vast, vast, vast majority of users are those such
 as myslelf, who have no opinion whatsoever, and either will not be affected
 at all by these changes (because they don't separate / and /usr), or will
 simply apply the proposed initramfs solution and move on.

 You also don't have /var (or /var/log) seperated? Or any of the other parts of
 the filesystem that might be required by udev-rules?

Many laptop users don't split /, among other things because the free
space gets fragmented. Also, some people keep Windows (and their
recovery partitions), and with a swap they got already used the four
extended partition, and some people don't like logical partitions. And
it's really the same as not wanting an initramfs.

 Then there are those relatively few people, such as the handful making up
 the rest of this thread, who think that these changes are a horrible idea
 and will have a severe deterimental affect on their systems.

 Any added complexity is another thing that can go wrong.

Take that to the limit and then we will still be using only the terminal (no X).

 In the thread on gentoo-dev, I am trying to figure out 3 things:
 1) How are the Gentoo Developers planning on adding this new change?
 2) What are the options for not having to have an initramfs if the udev-rules
 used don't actually require /usr and co to be mounted.
 3) Get their input in a possible alternative (like fixing the, what I see,
 design-flaws of udev)

 On 1, I am actually quite pleased. The actual information I could find
 previously sounded a lot worse. I've just got a few more questions open based
 on their answers. Once I have the full picture, I'll post it back here.

 For 2, I've only just started. I'll also post back here on what my findings
 are.

 For 3, I've got some feedback on how udev currently handles things. These
 actually have given me a few other ways in which to try to solve the issue.
 I'll need to try to find out how udev actually handles the retry queue
 currently.

I also think the discussion in -dev is really good, and I think is
cleaning the air abot many issues.

 Not that the relative size of the various sides in this debate is really
 the issue, but despite the tone of this and the other thread, I don't think
 there's really a huge, overwhelming outcry against these changes.

 I wonder how many are actually aware of these changes. But yes, I think plenty
 of people will not care and if the Gentoo-devs handle this correctly (which,
 so far, I think they are) those people won't even notice.

Concur.

 But, there will always be some people who get bitten by this and my reasons
 for going with parts 1 and 2 is to see how to keep this group as small as
 possible.

I think most of the Gentoo users, if able to survive the installation,
are able to deal with almost anything.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote:
  On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
  1.  The minimal initramfs will only need to be built once (and rarely
  rebuilt thereafter).  This removes one of my fears and it was a main
  objection for me - I would hate to have to rebuild initramfs every time
  I roll a new kernel, or libs and what not of fs happen to be udpated,
  etc.
 
 In my experience, it takes more time to build the kernel than it takes
 to rebuild the initramfs. And if you choose to use dracut, the process
 is automatic (you always call dracut with the same options, unless you
 suddenly add LVM or something similar).

Canek, as you've been using dracut already extensively, is it possible to set 
default options/modules/whatever to get to the situation where simply running 
dracut without any extra options will always recreate the correct initramfs?

 I didn't use an initramfs for my first years using Gentoo. Since I
 started to use media-gfx/splashutils a couple of years ago, every time
 I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
 the same, but with plymouth and systemd using dracut. It's just part
 of the process of getting a new kernel.

And, if the initramfs has other tools in it, after every emerge of these 
tools. This is where I see a possible cause for failure as then the situation 
arises where the initramfs will still start correctly, but because it's 
using older tools it's possible that older versions and new versions start 
running simultaneously and get mixed up in a way that is not immediately 
apparent.

--
Joost

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 07:15:27 PM Neil Bothwick wrote:
 On Thu, 15 Sep 2011 17:37:53 +0200, Joost Roeleveld wrote:
  There are 3 solutions for this:
  1) The easy way out: the whole user-space must be available before udev
  2) udev actually includes correct error-handling for this and retries
  3) udev splits this into 2 seperate tools
 
 4) udev remains one tool but with two modes of operation. when in
 early-boot mode, it can only run a restricted set of rules - such as
 those using LVM, RAID, cryptsetup, network device naming. When switched
 to full mode later in the boot process, it loads the rest of the rules.

Yes, I've been thinking about this option as well, after some comments on the 
gentoo-dev list.

 Which rules it runs it early-boot mode could be decided by adding a flag
 to the rule to mark it acceptable for early boot usage. That way,
 existing rules would automatically be deferred  unless package
 maintainers update the rules for those they know will work early in the
 boot process.
 
 It saves writing/learning/debugging a new tool and gives maximum
 compatibility with existing configurations.
 
 This is pretty similar in concept to your suggestion 3, but a different
 approach to its implementation.

And might be the simpler option.
Currently, I'm planning on checking if the retry-queue can be abused for 
this purpose.

--
Joost

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 5:25 PM, Joost Roeleveld jo...@antarean.org wrote:
[ Hugemongous snip ]
 If the Gentoo-devs come up with a fool-proof solution

No such thing in computing, I think. But I also think is really
laudable that you want to ensure no many users will get bitten by this
change.

And I also tend to believe that Gentoo users are more than able to
deal with this and almost any other thing.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev + /usr

On Thursday, September 15, 2011 07:37:17 PM pk wrote:
 On 2011-09-15 16:57, Canek Peláez Valdés wrote:
  Of course you can solve it differently, for example splitting udev as
  Joost proposes. But then is more code to maintain, and the number of
  possible setups is suddenly the double it was before. It. Is. Not.
  KISS.
 
 https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy
 
 I can especially point out:
 Rule of Modularity
 Rule of Parsimony
 Rule of Diversity

I like those :)

  It's a lot like the CUPS/lprng situation we discussed before. CUPS can
  do anything that lprng does, so it makes no sense to keep support for
  lprng. It's the same: with an initramfs you will be able to do
  anything, so it will make no sense to keep supporting initramfs-less
  systems.
 
 ... one ring to rule them all...

...My Precious... :)

--
Joost

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-15 Thread Alexander Tanyukevich

On Thu, Sep 15, 2011 at 9:16 PM, Michael Mol mike...@gmail.com wrote:

 I'm not touching KDE again for a while. I got nailed pretty bad with a
 NVidia/Konsole/KWin, and I really wasn't using much of KDE.

 That said, I might poke KDevelop again; I haven't poked it in years.
 Geany is new since I last dug around.

 I do like text environments, though.

Try eclipse with cdk (C/C++ developr kit). Last time I've used it 3
years ago, but it was really good...

-- 
Alexander Tanyukevich
atanyukev...@gmail.com

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

2011-09-15 Thread Alexander Tanyukevich

On Thu, Sep 15, 2011 at 11:37 PM, Alexander Tanyukevich
atanyukev...@gmail.com wrote:
 Try eclipse with cdk (C/C++ developr kit). Last time I've used it 3
 years ago, but it was really good...

Sorry it's called CDT.

-- 
Alexander Tanyukevich
atanyukev...@gmail.com

Re: [gentoo-user] udev + /usr

On Thu, Sep 15, 2011 at 5:30 PM, Joost Roeleveld jo...@antarean.org wrote:
 On Thursday, September 15, 2011 03:04:37 PM Canek Peláez Valdés wrote:
 On Thu, Sep 15, 2011 at 1:59 PM, Mick michaelkintz...@gmail.com wrote:
  On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote:
  1.  The minimal initramfs will only need to be built once (and rarely
  rebuilt thereafter).  This removes one of my fears and it was a main
  objection for me - I would hate to have to rebuild initramfs every time
  I roll a new kernel, or libs and what not of fs happen to be udpated,
  etc.

 In my experience, it takes more time to build the kernel than it takes
 to rebuild the initramfs. And if you choose to use dracut, the process
 is automatic (you always call dracut with the same options, unless you
 suddenly add LVM or something similar).

 Canek, as you've been using dracut already extensively, is it possible to set
 default options/modules/whatever to get to the situation where simply running
 dracut without any extra options will always recreate the correct initramfs?

The modules get defined by the DRACUT_MODULES variable, which is
use-expanded. The options are configured in /etc/dracut.conf, but I
believe there are some command line options not configurable.

 I didn't use an initramfs for my first years using Gentoo. Since I
 started to use media-gfx/splashutils a couple of years ago, every time
 I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do
 the same, but with plymouth and systemd using dracut. It's just part
 of the process of getting a new kernel.

 And, if the initramfs has other tools in it, after every emerge of these
 tools. This is where I see a possible cause for failure as then the situation
 arises where the initramfs will still start correctly, but because it's
 using older tools it's possible that older versions and new versions start
 running simultaneously and get mixed up in a way that is not immediately
 apparent.

I see it the other way around: you ensure that your initramfs is in
sync with your system. In other words: the initramfs contains a subset
of your normal installation. That is why it makes redundant /lib,
/sbin and /bin.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)

On Thursday, September 15, 2011 04:05:29 PM Michael Mol wrote:
 On Thu, Sep 15, 2011 at 3:59 PM, Chris Brennan xa...@xaerolimit.net wrote:
  On Thu, Sep 15, 2011 at 3:47 PM, Leonardo Guilherme
  
  leonardo.guilhe...@gmail.com wrote:
  I do not know the state of Geanny since I last checked (couple of
  years
  ago), but the highlight capabilites of KDevelop got my eye. It
  highlights local variables in different colors in the same context,
  so something like int foo(float bar, float baz) {
  }
  will have bar and baz in different colors. Also, support for CMake in
  KDevelop got really great and useful. Plus, it supports debugging
  inside the editor. Its awesome.
  
  If you want something in a gui, what about Code::Blocks? It's also
  multi-platform
 
 Ok, what are the atom names for all these? I'll start them building,
 and they should be done before I get home. (Not so likely if I have to
 build all of KDE, but I've got some Qt apps installed, so...)

As Nikos mentioned, I would try qtcreator (dev-util/qt-creator) before 
kdevelop (dev-util/kdevelop).

--
Joost

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Mike Edenfield

On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
 On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:

  I would estimate that the vast, vast, vast majority of users are those
  such as myslelf, who have no opinion whatsoever, and either will not be
  affected at all by these changes (because they don't separate / and
  /usr), or will simply apply the proposed initramfs solution and move
  on.
 
 You also don't have /var (or /var/log) seperated? Or any of the other parts
 of the filesystem that might be required by udev-rules?

Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var 
when setting up my FreeBSD systems, and found that it only ever caused 
problems when I could not get /usr or /var mounted when I needed them.

At least since I switched to Gentoo, I've simply set up one partition with 
everything on it, and kept regular backups in case of failure. 

I clearly recognize that there are valid reasons to split your partitions, I 
have just never found any of them applicable to my situations.

--Mike

Re: [gentoo-user] udev + /usr

2011-09-15 Thread Mark Knecht

On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield kut...@kutulu.org wrote:
 On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
 On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:

  I would estimate that the vast, vast, vast majority of users are those
  such as myslelf, who have no opinion whatsoever, and either will not be
  affected at all by these changes (because they don't separate / and
  /usr), or will simply apply the proposed initramfs solution and move
  on.

 You also don't have /var (or /var/log) seperated? Or any of the other parts
 of the filesystem that might be required by udev-rules?

 Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var
 when setting up my FreeBSD systems, and found that it only ever caused
 problems when I could not get /usr or /var mounted when I needed them.

 At least since I switched to Gentoo, I've simply set up one partition with
 everything on it, and kept regular backups in case of failure.

 I clearly recognize that there are valid reasons to split your partitions, I
 have just never found any of them applicable to my situations.

 --Mike

My first response to this 300+ post thread, and only to say that in
something like 15 years of playing with  using Linux I've never split
/usr  no longer split /var. I also don't use LVM or anything fancy
like that. I just keep backups and use them if there's a failure. Life
is pretty simple.

My suspicion is that by far most casual desktop users of Linux, Gentoo
based or not, run pretty much this way and will be unaffected by this
whole change and as such have no reason to post.

As for the initrd stuff, I'd welcome a way to have one built
automatically as part of the kernel build/install. My experience with
software RAID has been such that I often cannot get a new RAID to boot
without it so having one that's up to date and 'just there' (@tm)
would be fairly cool from my POV.

My only  last post on this thread.

Cheers,
Mark

On Thu, Sep 15, 2011 at 6:26 PM, Mark Knecht markkne...@gmail.com wrote:
On Thu, Sep 15, 2011 at 3:05 PM, Mike Edenfield kut...@kutulu.org wrote:
On Thursday, September 15, 2011 11:16:03 PM Joost Roeleveld wrote:
On Thursday, September 15, 2011 04:42:23 PM Mike Edenfield wrote:

I would estimate that the vast, vast, vast majority of users are those
such as myslelf, who have no opinion whatsoever, and either will not be
affected at all by these changes (because they don't separate / and
/usr), or will simply apply the proposed initramfs solution and move
on.

You also don't have /var (or /var/log) seperated? Or any of the other parts
of the filesystem that might be required by udev-rules?

Speaking solely for myself, no. Years ago I routinely split /, /usr, and /var
when setting up my FreeBSD systems, and found that it only ever caused
problems when I could not get /usr or /var mounted when I needed them.

At least since I switched to Gentoo, I've simply set up one partition with
everything on it, and kept regular backups in case of failure.

I clearly recognize that there are valid reasons to split your partitions, I
have just never found any of them applicable to my situations.

--Mike

My first response to this 300+ post thread, and only to say that in
something like 15 years of playing with using Linux I've never split
/usr no longer split /var. I also don't use LVM or anything fancy
like that. I just keep backups and use them if there's a failure. Life
is pretty simple.

My suspicion is that by far most casual desktop users of Linux, Gentoo
based or not, run pretty much this way and will be unaffected by this
whole change and as such have no reason to post.

Ubuntu recommends /, /home and swap [1]. Fedora recommends /, /boot
and swap [2]. OpenSUSE has several sets, but the simple and dual
booting recommends /, /boot, /home and swap [3]. Debian says [4]:

For new users, personal Debian boxes, home systems, and other
single-user setups, a single / partition (plus swap) is probably the
easiest, simplest way to go. However, this might not be such a good
idea when you have lots of disk capacity, e.g., 20GB or so. Ext2
partitions tend to perform poorly on file system integrity checking
when they are larger than 6GB or so.

For multi-user systems or systems with lots of disk, it's best to put
/usr, /var, /tmp, and /home each on their own partitions separate from
the / partition.

Interestingly, the Gentoo handbook [5] recommends /, /boot and swap.
Damn, I haven't installed Gentoo in a long time, I hadn't looked at
the handbook in years.

Anyway, Debian is the only big distro recommending separated /usr,
and then only for multiuser setups. It's really years since I've
looked at the recommended partition schemes: when I started using
Linux, a separated /home was almost a must. And we had tiny hard
drives then. Now get out of my lawn.

Regards.

[1] http://www.easy-ubuntu-linux.com/ubuntu-installation-606-7.html
[2]
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/s2-diskpartrecommend-x86.html
[3] http://en.opensuse.org/SDB:Partitioning
[4] http://www.debian.org/releases/woody/i386/ch-partitioning.en.html
[5] http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: IDE for C/C++ (Was: Really OT now (Re: [gentoo-user] udev + /usr)