Re: [gentoo-dev] DESCRIPTION in eclasses

[Ulrich Mueller]

> On Wed, 18 Jul 2012, Ciaran McCreesh wrote:

>> Many eclasses (eutils being the most prominent example) contain:
>> DESCRIPTION="Based on the ${ECLASS} eclass"
>> 
>> Is this of any use?

> The reason that sort of thing is there is because in the olden days
> before we had specs or EAPIs or anything like that, eclasses were
> originally designed and implemented as "classes" in an OO type manner.
> The idea was that there would be a "base" eclass, and then you'd derive
> "kde", "gnome" etc eclasses from there, all in a nice hierarchy, and
> you'd be expected to "override" variables like DESCRIPTION as you go
> down the tree.

> As it turns out, eclasses ended up being used in a completely different
> way. But you still see bits of the original idea cropping up, such as
> in the words "class" and "inherit" and "base".

Thanks, this explains why these DESCRIPTIONs are there.

But history left aside, are they still useful today? If not, then they
should be removed.

Ulrich

[gentoo-dev] RFC: l10n.eclass

[Ben de Groot]

Today I would like to present to you my proposal for a new eclass with
helper functions for treating localizations: l10n.eclass (see the
attached file or [1]). Its functionality can be used in other eclasses
(such as qt4-r2 and cmake-utils) as well as directly in ebuilds.

In order to keep the code simple, and prevent double loops and extra
variables (such as currently used in the media-video/smplayer ebuild),
I am proposing that we should add any missing long-form locales to
profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
This also means that users may have to expand their LINGUAS setting in
make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
cover the different variants used in packages.

If you have any comments, spot any mistakes, or have proposals for
improvement, I would love to hear it! I would especially love from
maintainers of complicated packages such as libreoffice-l10n, if there
is any additional functionality that we could include in this eclass
to make their job simpler.

1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin


l10n.eclass
Description: Binary data

[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Michael Mol posted on Wed, 18 Jul 2012 15:18:35 -0400 as excerpted:

> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman  wrote:
>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> We don't even update kernels as part of the regular update process, let
>> alone initramfs systems.
>>
>> In general you update them together.
>>
>> The only issue I could see is if problems arise if you have a different
>> version of udev in your initramfs than on your system.  I don't know if
>> that actually causes problems.  For the most part after the system is
>> booted the initramfs is done its job.
> 
> The most widely touted benefit I've heard for initramfs is its
> capability to ease system recovery in case, e.g. a critical filesystem
> refuses to mount. With recovery roles come recovery tools, which quickly
> extends network-aware tools and a security attack surface.
> 
> Hence why I tend to feel that if an initramfs is going to become the
> go-to solution for bootstrapping userland, it's important to consider
> the difficulties of keeping the packed tools up-to-date; it's not just a
> bootstrap tool, it's also the first recovery option a sysadmin faces.

As others have stated, that might be /a/ widely touted benefit, but the 
reason for initr* being there in the first place, is to solve the 
otherwise chicken/egg issue of having the tools/modules necessary to 
mount a filesystem, /on/ that filesystem, since now they're on the initr* 
as well, and that is maintained with the kernel.

But meanwhile, recovery /is/ /a/ widely touted benefit, which really 
presents its own problem, in the form of a choice:

a) automatically update the initr* and get the security benefits but risk 
breaking the recovery tools when they break with an update to the main 
system,

OR:

b) don't automatically update the initr* in ordered to keep a known/
tested-working first recovery mechanism, but at the cost of potentially 
unfixed security-vulns in the initr* that were already fixed on the main 
system.

Of course (b) is the usual case on an initr* (unless it's one-size-fits-
all automatically updated by the distro), due to static linking.  So 
security is already taking second priority to a known-working recovery 
mechanism, and updating the initr* on a user-configured/managed distro 
like gentoo pretty much must remain in that user-admin domain.  There's 
simply no way around it, without going the one-size-fits-all-distro-
configured route, which by accepted definition isn't palatable to 
gentooers, or they'd be using something else.

So IMO, updating the initr* is and must remain user-admin domain, not 
something gentoo really can worry about, other than to the extent of 
making those updates as easy and stupid-mistake-proof as can reasonably 
be done while still placing the responsibility of actually configuring 
and maintaining the initr* with the user-admin.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Opinion against /usr merge

[Matthew Marlowe]

On Wed, Jul 18, 2012 at 7:04 PM, Olivier Crête  wrote:
> On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
>
>> - It would be nice if the rootfs used a snapshot based filesystem and
>> if the bootloader was intelligent enough to easily allow admins to
>> boot to older snapshots as an expectation for any standard modern unix
>> system.
>
> One of the reasons to put everything in /usr is to allow using a
> snapshot based FS, so you can run a system where /usr is read-only and
> where when you can do all upgrade atomically by writing your changes to
> a read-write snapshot and then switch all at once. So you never have any
> half-upgraded package on your system.
>

I understand that RHEL is promoting this system management model, but
I'm not sure it is any way superior than other models that do not
require RO /usr.  Many enterprises today solve the same issue via
automation with puppet, active traffic management via LVS/HA/Load
Balancers, or replace /usr snapshots with virtualization where a new
VM snapshot or clone is upgraded and then replaces the active VM.
Therefore, I'm not convinced we should promote /usr/bin and /usr/sbin
over /bin and /sbin.  It is a point in their favor to give more
flexibility but the simplicity of also just removing /usr would also
be compelling if our goal afterall is to simplify the FHS.

>
>> - OK with merging / and /usr, but in that case...why not just move
>> everything in /usr to /...but limit /sbin to system binaries and /bin
>> to user ones?  This would be horrible for migrations though and
>> possibly confuse many scripts.
>
> The idea of putting everything in /usr instead of / is that you can then
> make /usr read-only and you can share /usr between multiple systems,
> while / is read-write and contains /root and /etc.
>

Most enterprises that need the ability to make /usr RO for canonical
server configs  could just as well get by with automated configuration
management tools (e.g. puppet) and smart hypervisors/SAN storage.
This allows deployment of new servers within minutes and it reflects
at least the true reality that a true controlled system state is a
snapshot of server config files, virtual hardware, and all binaries.
Just making /usr RO is a cheat that might work well for long lived
binary distributions that require major version upgrades anytime
software packages update their config behavior dramatically.  I
haven't found it very helpful for source type systems like Gentoo.  Of
course, others may disagree.

>> - NOT OK with making systemd the default init system anytime in the
>> next few years, it is way too immature and like most major system
>> software changes...probably will take much longer before it really has
>> the standing to propose being a new standard.
>
> I fully expect systemd to be the init system of the next iteration of
> RedHat Enterprise Linux, which is probably the most "enterprise" of all
> distributions, with the most QA and support and everything. It's not a
> side project of dude of his basement, it has the full support of a large
> team of people at RedHat. There has probably already been more testing
> done on systemd today than on OpenRC...
>

Well, we know that systemd will be in the next RHEL release - it was
in their recent roadmap presentation.  However, that release would be
RHEL7 and most established servers are RHEL5 now and RHEL6 is still
relatively early in deployment.  It will be a few years before most
RedHat customers can say whether systemd was a good move for RHEL.
And, RedHat has made changes in the past that while supported might
not become the default config for other distributions (e.g. SE Linux).
 I don't see that we need to assume now that systemd will define the
default Linux ecosystem in the future, even if it becomes widely
deployed on RedHat systems..

[gentoo-dev] Re: rfc: openrc init scripts taking command line arguments

[Duncan]

Fabian Groffen posted on Wed, 18 Jul 2012 22:07:50 +0200 as excerpted:

> Perhaps, one better makes it explicit, inspired by gdb
> 
> /etc/init.d/foo stop --args aggressive-kill=yes (and when using --args,
> I'd probably disallow using multiple commands to keep it clear what's
> going on)

++

This makes sense, especially the single command when using --args bit.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Jason A. Donenfeld posted on Wed, 18 Jul 2012 19:47:49 +0200 as excerpted:

> On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête 
> wrote:
>> Also be ready for a merge of /bin and /sbin.. I'm sure most people
>> can't even explain the difference between them.
> 
> Whoa hey what why? Who's pushing this forward?

AFAIK it has been discussed for Fedora/RH, but I think they're doing 
the / /usr merge first and /usr/bin /usr/sbin (which would then take care 
of the already merged /bin /sbin) later.  I believe they've mostly 
decided already, but timing, etc, will depend on how the first phase, 
the / /usr merger, goes, and of course if that turns out to go worse than 
expected, the second phase could still be called off.  But don't bet on 
it as certainly, people will have already been running their systems that 
way in ordered to seriously advocate it, so it's likely to mostly just 
take a couple release cycles to work thru their system and get the corner-
case kinks worked out.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Canek Peláez Valdés posted on Wed, 18 Jul 2012 10:04:33 -0500 as
excerpted:

> I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin; moreover,
> I want an even more radical change:
> 
> /usr -> /System /home -> /Users /etc -> /Config

Ugh.  At least kill the shift key requirement.  Other than that, no real 
objection, but it's far afield from the current discussion and would be a 
lot of (arguably unnecessary) work to migrate.

FWIW, tho, that does look a lot like... I think it's gobo linux... If you 
like that sort of thing, I'd suggest looking at it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Opinion against /usr merge

[Olivier Crête]

On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
> > It would be nice if a sensible structure could be proposed and
> > agreed by ALL Linux distributions (coordinated with BSD).
> >
> 
> +1
> 
> If a new file system standard is required, my preferences based on a
> history of what is worked and changed over the last 20-30 years would
> be:
> 
> - OK with requiring / and /usr on the same FS.  This has become common
> practice with virtualization and small system deployments, and I
> haven't seen any compelling advantage for keeping separate on larger
> boxes.

No one proposes that, the only requirement that you have for modern
Linux to work well is that if /usr is on a separate partition, you need
to mount it before starting your main system (ie, from an initramfs).

> - NOT OK with limitation on allowing /var, /opt, /home, or any other
> common server mount points to require use of initramfs/initrd.  There
> is enough disagreement as to the reliability and ease of maintenance
> of initramfs/initrd that it should not be needed for common server
> deployments.

This is clearly not needed, /run was even invented to allow /var to be
mounted later.

> - It would be nice if the rootfs used a snapshot based filesystem and
> if the bootloader was intelligent enough to easily allow admins to
> boot to older snapshots as an expectation for any standard modern unix
> system.

One of the reasons to put everything in /usr is to allow using a
snapshot based FS, so you can run a system where /usr is read-only and
where when you can do all upgrade atomically by writing your changes to
a read-write snapshot and then switch all at once. So you never have any
half-upgraded package on your system.

> - Ideally, server motherboards would come with flash based storage
> where sysadmins could install rescue environments as part of a normal
> unix install, and that the boot loader or bios would be smart enough
> to provide the option to boot from it automatically whenever a normal
> boot failed.
> - NOT OK with removing the distinction between user and system
> binaries.  Essential binaries required to boot and troubleshoot system
> problems should be located separately from user binaries.  Security
> sensitive or paranoid admins should be able to make the system binary
> path read-only or completely remove the user binary directory from
> roots PATH if they so wish.

The rescue system should be entirely separate from the main system, so
it survives mishandled upgrades. So having that should not hinder how
your main system is built. So you should have it as a separate partition
or you can even have it an initramfs (ie, in a single file on the main
system).

> - OK with merging / and /usr, but in that case...why not just move
> everything in /usr to /...but limit /sbin to system binaries and /bin
> to user ones?  This would be horrible for migrations though and
> possibly confuse many scripts.

The idea of putting everything in /usr instead of / is that you can then
make /usr read-only and you can share /usr between multiple systems,
while / is read-write and contains /root and /etc.

> - NOT OK with making systemd the default init system anytime in the
> next few years, it is way too immature and like most major system
> software changes...probably will take much longer before it really has
> the standing to propose being a new standard.

I fully expect systemd to be the init system of the next iteration of
RedHat Enterprise Linux, which is probably the most "enterprise" of all
distributions, with the most QA and support and everything. It's not a
side project of dude of his basement, it has the full support of a large
team of people at RedHat. There has probably already been more testing
done on systemd today than on OpenRC...

> - What other elements can new filesystems like btrfs offer that should
> be considered?  ext3/ext4 has worked great with the older
> standards...but it essentially mimicked the capabilities of older
> file-systems that the original unix standards were based on.  Btrfs
> might change our expectations.  I'm assuming that btrfs will be the
> standard production fs in a few years.

The big thing that btrfs brings is snapshots and subvolumes... So it
makes it possible to do atomic upgrades and such. Also, you can have
"apps" be subvolumes and also handled atomically.

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


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

Re: [gentoo-dev] Opinion against /usr merge

[Walter Dnes]

On Wed, Jul 18, 2012 at 08:27:29PM +0200, Micha?? G??rny wrote
> On Wed, 18 Jul 2012 11:35:02 -0400
> "Walter Dnes"  wrote:
> 
> >   3. More support for mdev; e.g.  https://wiki.gentoo.org/wiki/Mdev
> > and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB
> > The next challenge is "custom mdev rules", which should be do-able.
> 
> I don't think we should give more support to building a system from
> a statically linked rescue suite tool.

  Busybox is a well-supported lightweight replacement for udev and most
of coreutils, and also happens to double up as a rescue tool.  See my
reply to Jason A. Donenfeld for more.  BTW, "static" is an optional USE
flag for busybox.

-- 
Walter Dnes 

Re: [gentoo-dev] Opinion against /usr merge

[Patrick Lauer]

On 07/19/12 03:05, Rich Freeman wrote:
> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
> We don't even update kernels as part of the regular update process,
> let alone initramfs systems.
>
> In general you update them together.
>
> The only issue I could see is if problems arise if you have a
> different version of udev in your initramfs than on your system.  I
> don't know if that actually causes problems.  For the most part after
> the system is booted the initramfs is done its job.
>
> If some package did need a kernel/initramfs/etc to be updated it
> should be the subject of news or an ewarn unless it becomes routine
> practice.  I don't think we want the system to start touching these
> things without operator intervention unless we make it really
> bulletproof like they do on big distros (the only reason they can is
> they have one-size-fits-all kernels and initramfs designs).
>
>
And here's an epic failure mode waiting to happen - what if the kernel
is not stored in /boot ?

I can think of at least two common setups where that happens. One is
virtual machines (Xen for example usually stores the kernel outside the
guest filesystem), the other is systems with full-disk encryption where
you don't have a bootloader on the local disk.

Ah, who would have guessed that there are linux installs that are not
single-disk desktops!

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18-07-2012 21:09, Michał Górny wrote:
> On Wed, 18 Jul 2012 23:03:14 +0200 Peter Stuge 
> wrote:
> 
>> William Hubbs wrote:
>>> let's move all of the discussion of this to the bug if possible
>>> so that it is all in one place.
>> 
>> That's fine and probably good.
>> 
>> Note that you were the one inviting email discussion about the 
>> change. I guess you wanted rather to focus on the question if 
>> breaking compatibility was cool or not.
>> 
>> Anything web is *way* too inconvenient for me to participate
>> without strong interest. That may be a good thing. Anyway I've
>> mentally abandoned init script including openrc long ago. :)
>> 
>> systemd is the future, and truly a leap ahead for systems world
>> wide.
> 
> No, it's not. But it's a step ahead.

It's obvious that to its supporters systemd is fantastic. It's also
obvious that to everyone else it's probably far from that.
Let's please try to leave systemd off this ml for some days - I for
one am getting tired of all the systemd related emails in this ml.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQB2O/AAoJEC8ZTXQF1qEPfPsP/R5+BIZVP7qKQn5MSsmCspnC
vDPSf3CWP1OjQ6D1yeaDKWoPCSBqYg308DIgFWscR0URruC/Jd+Vdkl8B1ZztTWv
YjuJp9tiIsrhb+gAg84tbxy5YE5I+xFwAH6pfhVb5xWX9DOwNMK2KW8C41L2GArP
jPK6xtxbTWdRlElpymaskhEftVVXeNe7V48QERG26d3YXpz7D1cmSpjIeJdp7evS
rkpleFRQHSAVVfr95KIol3gi/8LSY5M5HqnuxHqJ4NwnOna2WccFY68dK71qi4Gs
ah38h7LxWwTLsaoD83Dbmu+nOzNwA07CDA7Sf2GIhHmHbd6PoJQ4D1bGUzppry9r
NvbJKmIJdut55IHNpA9QPGTWfKO116o/1caQeiIWW0j9bmPj7YaWASBLJGNkO22e
OgJT6WedFj5jWYAH4hANZLZov8s/KvtKXvyiA1Sq6fkFZi7LBhcEf7OpcaQgSBHu
NK/MiruF1kRELrbbp5yuh/KKwZDnZQY1gNW/PZuUAfe+/DGA7ZVzmFh8UquIalNR
fuLbGqViiyd06czxlnVHvscgZZ4K1dXMT0mFF6ZpmiSEboIeoKu/H3IdiZhTCyPJ
zp5w6B2MXlNkPLQQjfkPyuRkSRpbCkFxlQIN2TDWbdfJQwIVDkZ47EGyXHCN6sc6
+/IW3MuPUHS4pEoqKnJp
=pGgy
-END PGP SIGNATURE-

Re: [gentoo-dev] Opinion against /usr merge

[Walter Dnes]

On Wed, Jul 18, 2012 at 08:06:41PM +0200, Jason A. Donenfeld wrote
> On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes  wrote:
> >
> >   3. More support for mdev; e.g.  https://wiki.gentoo.org/wiki/Mdev and
> > (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB  The
> > next challenge is "custom mdev rules", which should be do-able.
> 
> 
> Interesting. Can you talk more about the benefits of mdev in
> non-embedded systems? Why would I want to use this instead of udev
> (aside from the /usr dispute).

  The biggest benefit is that Gentoo wouldn't become a Redhat-based
distro.  You can compile Redhat (or Centos) from source with SRPM
packages if you wanted a Redhat-based build-from-source distro.  They
proclaim that udev will not require systemd for the time being.  But
given how cavalierly they broke 20 years of linux file hierarchy, I'm
skeptical of their promises of continued backwards compatability.  And
what else do they have coming down the pike?  What's next to get broken?

  Alpine Linux http://alpinelinux.org/ is busybox-based, so it can be
done.  A major problem for me is that it also uses uclibc.  It does do
X11, e.g. GNOME, XFCE, etc), but uclibc rules out my Nvidia card with
proprietary drivers.  I'm also a paying subscriber of NHL Gamecentre
Live, so I need proprietary Flash, which gets broken by uclibc.  I've
tried Nouveau and Gnash, and they are not ready for primetime.

-- 
Walter Dnes 

Re: [gentoo-dev] Opinion against /usr merge

[Matthew Marlowe]

> It would be nice if a sensible structure could be proposed and
> agreed by ALL Linux distributions (coordinated with BSD).
>

+1

If a new file system standard is required, my preferences based on a
history of what is worked and changed over the last 20-30 years would
be:

- OK with requiring / and /usr on the same FS.  This has become common
practice with virtualization and small system deployments, and I
haven't seen any compelling advantage for keeping separate on larger
boxes.
- NOT OK with limitation on allowing /var, /opt, /home, or any other
common server mount points to require use of initramfs/initrd.  There
is enough disagreement as to the reliability and ease of maintenance
of initramfs/initrd that it should not be needed for common server
deployments.
- It would be nice if the rootfs used a snapshot based filesystem and
if the bootloader was intelligent enough to easily allow admins to
boot to older snapshots as an expectation for any standard modern unix
system.
- Ideally, server motherboards would come with flash based storage
where sysadmins could install rescue environments as part of a normal
unix install, and that the boot loader or bios would be smart enough
to provide the option to boot from it automatically whenever a normal
boot failed.
- NOT OK with removing the distinction between user and system
binaries.  Essential binaries required to boot and troubleshoot system
problems should be located separately from user binaries.  Security
sensitive or paranoid admins should be able to make the system binary
path read-only or completely remove the user binary directory from
roots PATH if they so wish.
- OK with merging / and /usr, but in that case...why not just move
everything in /usr to /...but limit /sbin to system binaries and /bin
to user ones?  This would be horrible for migrations though and
possibly confuse many scripts.
- NOT OK with making systemd the default init system anytime in the
next few years, it is way too immature and like most major system
software changes...probably will take much longer before it really has
the standing to propose being a new standard.
- What other elements can new filesystems like btrfs offer that should
be considered?  ext3/ext4 has worked great with the older
standards...but it essentially mimicked the capabilities of older
file-systems that the original unix standards were based on.  Btrfs
might change our expectations.  I'm assuming that btrfs will be the
standard production fs in a few years.

Re: [gentoo-dev] Opinion against /usr merge

[llemike...@aol.com]

In the beginning there were root (/bin) and /usr programs

See UNIX Programmer's Manual (Thompson, Ritchie, November
1971). [http://cm.bell-labs.com/cm/cs/who/dmr/manintro.pdf]

/usr programs were "not considered part of the UNIX system"
[bottom of page ii].

Root (/) contained all the system files and configuration;
/usr all the user's files.

In the UNIX V7 manuals hosted here:
http://plan9.bell-labs.com/7thEdMan/bswv7.html
Dennis Rtichie suggests moving binary files from root (/bin)
to /usr/bin because it might speed up systems:
See page 152 of UNIX Version 7, Volume 2B
UNIX Programmers Manual.

Hence, he suggests leaving only maintenance binary files in
root (see para. 3 under Disk Layout, Pg. 152).

The most important remark comes in paragraph 2 of the disk
layout page:

"There are two considerations in deciding how to adjust the
arrangement of things on your disks: the most important is
making sure there is adequate space for what is required;
secondarily, throughput should be maximised."



For me the argument is about what gets mounted in which way.
I want to be able to ensure filesystems are mounted to prevent
potential privilege escalation.
Consequently, I have split my Gentoo system with the following
settings.

At boot /usr is present in / (on same partition)
/tmp is mounted nosuid from a separate partition
/var is mounted nosuid from a separate partition
/home is mounted nosuid from a separate partition

/bin and /sbin programs that do not require root authority
are all marked nosuid.

None of the executables/configuration files in / or /usr are
user-writable.

umasks are 077.

On my backup server, /home is mounted noexec, nosuid.

Personally I like the split between /bin and /usr/bin and /sbin
and /usr/sbin - provided ports maintainers stick to an
understanding that /bin is for maintenance files and /usr/bin
is for user application files (i.e. applications used by users).

/sbin and /usr/sbin should segregate root's/system maintenance
executables and root's/system application executables.


Although I am not sure at all that executables have been so
split by recent developers/maintainers (a lot of time has passed)...

It would be nice if a sensible structure could be proposed and
agreed by ALL Linux distributions (coordinated with BSD).

For me, it is a credit to Ken and Dennis' vision that they foresaw
the benefit of file permissions, including suid and sgid and the
EXCEPTIONALLY BRILLIANT idea of the sticky bit for /tmp.

It is incredible that they came up with much of this structure in
1969 - 1978.

"Progress, far from consisting in change, depends on retentiveness.
When change is absolute there remains no being to improve and
no direction is set for possible improvement: and when experience
is not retained, as among savages, infancy is perpetual.
Those who cannot remember the past are condemned to repeat it."
SATAYANA

Those querying a separate /usr partition or otherwise might like to
peruse UNIX Version 7 UNIX Programmers manual, Volume 2A:
UNIX for Beginners (Brian W. Kernighan)
Page 46 of this PDF: http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf

I LIKE THE IDEA of a separate /usr partition - but that is from a
mounting file-systems perspective rather than relying on the history
of UNIX...

Live free or die - UNIX.

Mike




On 18/07/12 18:35, Canek Peláez Valdés wrote:

As William pointed out, this is just another silly rationalization
done after the fact. But, just for argument's sake, lets suppose that
"usr" was named like that because it was the acronym for "UNIX System
Resources".

*Who cares about that now?* It was 43 years ago. My cellphone is
thousands of times faster than the PDP-7 Unix was originally developed
for, and it has millions of times more storage. The length
restrictions imposed on system directories are completely superfluous
now.

All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
separated are really instances of the Chewbacca defense [1]. They just
don't make any sense.

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Michał Górny]

On Wed, 18 Jul 2012 23:03:14 +0200
Peter Stuge  wrote:

> William Hubbs wrote:
> > let's move all of the discussion of this to the bug if possible so
> > that it is all in one place.
> 
> That's fine and probably good.
> 
> Note that you were the one inviting email discussion about the
> change. I guess you wanted rather to focus on the question if
> breaking compatibility was cool or not.
> 
> Anything web is *way* too inconvenient for me to participate without
> strong interest. That may be a good thing. Anyway I've mentally
> abandoned init script including openrc long ago. :)
> 
> systemd is the future, and truly a leap ahead for systems world wide.

No, it's not. But it's a step ahead.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Peter Stuge]

William Hubbs wrote:
> let's move all of the discussion of this to the bug if possible so
> that it is all in one place.

That's fine and probably good.

Note that you were the one inviting email discussion about the
change. I guess you wanted rather to focus on the question if
breaking compatibility was cool or not.

Anything web is *way* too inconvenient for me to participate without
strong interest. That may be a good thing. Anyway I've mentally
abandoned init script including openrc long ago. :)

systemd is the future, and truly a leap ahead for systems world wide.


//Peter


pgpwyFiyr6tkg.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Peter Stuge]

Rich Freeman wrote:
> 5.  When something goes wrong you can get a dash/bash shell
..
> useful even if you don't have firefox+X11 in your initramfs.

This is one of the first videographed use cases for coreboot.

The initramfs in the video[1] admittedly does not have a browser.

Those days, boot flash were up to 2 Mbyte. Today they are up to 16
Mbyte, so a browser can certainly be added.

http://www.coreboot.org/Screenshots#LinuxBIOS_with_X_Server_Inside


//Peter

[1] http://www.youtube.com/watch?v=nuzRsXKm_NQ
[1] http://downloads.sourceforge.net/fornix/linuxbios.ogg

[gentoo-dev] Last rite: tetex.eclass + tetex-3.eclass

[Johannes Huber]

Is obsolete and not used anymore[1][2]. Will be removed in 30 days.

+  18 Jul 2012; Johannes Huber  tetex-3.eclass, tetex.eclass:
+  Marking as DEAD for removal.
+

[1] http://qa-reports.gentoo.org/output/eapi-per-eclass/tetex-3.eclass/
[2] http://qa-reports.gentoo.org/output/eapi-per-eclass/tetex.eclass/

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

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

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

Folks,

let's move all of the discussion of this to the bug if possible so that
it is all in one place.

Thanks,

William



pgpw1garAIRzQ.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 04:09 PM, William Hubbs wrote:
> 
> The other approach, which is on the bug, still has this issue,
> e.g.
> 
> /etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3
> arg5
> 
> gets pretty ugly pretty quick. which arguments go with which
> commands is subject to interpretation.

..i don't see how...?  anything to the right of [command] but before
{[other-command],$END} is an argument to [command] ...

ie, the above would roll out to:

/etc/init.d/foo command1 arg1 arg2 && \
/etc/init.d/foo command2 arg3 arg4 && \
/etc/init.d/foo command3 arg5

(assuming subsequent commands do not execute if the previous one fails
now, which tbh I have no idea about)

It's not the most pretty syntax ever, but given i doubt it will be
humans running such a commandline I don't see the issue with this..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHGZUACgkQ2ugaI38ACPCXNAD8DR8qHFOQnGCt2W+sOXYJDsXu
H6pnnFt09ssbuKjKHZwA/2pZxnGnXJTWGVdPySoIsJtr8Pe6Za9yeL4yQ0WHPocr
=G3H9
-END PGP SIGNATURE-

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 4:02 PM, Rich Freeman  wrote:
> On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol  wrote:
>> So your initramfs doesn't include network tools such as ping,
>> traceroute or wget. Fine. Fundamentally speaking, why shouldn't
>> someone else's?
>
> So, an initramfs is just a piece of kernel functionality.  You can do
> almost ANYTHING in an initramfs, subject to the limitation that it is
> stored in RAM without any backing store.

Yup. IIRC, it has effectively the same underlying implementation as
tmpfs, using always-dirty file cache pages.

>
> There are lots of reasons to use an initramfs, and the biggest ones
> don't pertain much to Gentoo.  Here are some of the big use cases:
>
> 1.  One-size-fits-all kernel.  You want to support root and /usr on
> any filesystem, on any kind of hard drive, or on a SAN, or who knows
> where.  That either means saying Y to every driver in the kernel, or
> saying M and using an initramfs to load what is needed to get to root.
>
> 2.  One-size-fits-all grub config.  You put the smarts in the
> initramfs, and use filesystem labels and such to identify partitions.
>
> 3.  Use of labels/UUIDs on partitions.  When mdadm decides to renumber
> half your devices on a whim or you add a drive and everything bubbles
> down by one, your system still boots.
>
> 4.  Cleaner mounting of root, ability to fsck on initial mount, etc.
>
> 5.  When something goes wrong you can get a dash/bash shell instead of
> a grub shell.  The former is clearly more useful even if you don't
> have firefox+X11 in your initramfs.
>
> 6.  Support for booting off of stuff that the kernel can't find on its
> own, like SANs/etc.  That might require network support in the
> initramfs, and that usually isn't a big deal.  If somebody can spoof
> DNS on your fiber channel interface you've got bigger problems.
>
> Sure, the more you do with the initramfs the bigger the potential
> security risks.  Most distros don't have users build either kernels or
> initramfs which means they can just push updates, but that requires #1
> above, which I think most Gentoo users would not appreciate.

I fall into use cases 3 and 5, myself. Incidentally, bash is also
network-aware. (Not sure if the default USE flag set allows it,
though.) Were I to explicitly add network-aware tools, I'd probably
add either ssh/sftp/scp or links.

>
> However, the initramfs shouldn't leave much of anything running after
> it chroots, so the window should be fairly small.

So is the window for spoofing DNS responses. That didn't stop DNS
hijacking from being fairly easy. (And why there was a large
coordinated, cross-vendor effort to add source-port randomization once
it was shown to be easy.)

Multi-threaded native code has been my day job for the last five
years. I may be a bit biased when it comes to race conditions.

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 04:05 PM, Alec Warner wrote:
> [...] However lets say I have coreutils in / and coreutils in my
> initramfs. I upgrade coreutils from v1 to v2. Are you saying that
> you are too afraid to update coreutils in / and then also update it
> in the initramfs (probably by running $TOOL to copy coreutils from
> / to initramfs-root.)
> 
> I'm not suggesting that we necessarily do this automatically, just 
> that people claim 'the tools do not exist to do this now' when in
> fact it seems fairly straightforward to do.
> 
> I mean presumably you used $TOOL to build the initramfs once, so 
> running $TOOL again to generate a new initramfs probably should
> not screw you, provided you have control over the configuration of
> $TOOL.


IIRC, and unless this has changed recently (ie within the last year or
two), a genkernel-generated initramfs is built on specific versions of
all the tools that genkernel itself ensures is downloaded, ie, *NOT*
the same versions as are installed in your / , and often are actually
older.

You can, of course, change this via /etc/genkernel.conf for each tool.

..so in that particular case, one would want their initramfs
regenerated when genkernel gets upgraded (but after
/etc/genkernel.conf is etc-update'd)


If I remember my hearsay correctly, dracut does build the initramfs
from tools on / , though...?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHGFAACgkQ2ugaI38ACPCjlAD/Qin9JKK6SFAr/5G2vjgqJmau
BATFNwP/nbgtIb5i0rgA/jlEmZFBK9n14GOYzQxi3BJewGhRvi62WAHsX7EMQzDL
=HLZG
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

On Wed, Jul 18, 2012 at 03:58:18PM -0400, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge  wrote:
> > William Hubbs wrote:
> >> /etc/init.d/foo stop start
> >>
> >> would no longer work the way you might expect because there would be no
> >> way to tell whether start is a command or an argument to stop.
> >>
> >> What are your thoughts about this change?
> >
> > /etc/init.d/foo stop start
> >
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
> 
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.
> 
> I.e.
> 
> touch -- -an-ugly-filename
> ls -l -- -an-ugly-filename
> rm -- -an-ugly-filename

Theis still breaks backward compatibility though, e.g.

/etc/init.d/foo command1 -- arg1 arg2 command2

has issues.

The other approach, which is on the bug, still has this issue, e.g.

/etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3 arg5

gets pretty ugly pretty quick. which arguments go with which commands is
subject to interpretation.

William



pgpOp3VKyhnRD.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Michał Górny]

On Wed, 18 Jul 2012 14:41:52 -0500
William Hubbs  wrote:

> I have received a request to allow OpenRC's init scripts to take
> command line arguments [1]. As noted on the bug, there are some
> advantages to this, but implementing it would have to break backward
> compatibility, for example:
> 
> /etc/init.d/foo stop start
> 
> would no longer work the way you might expect because there would be
> no way to tell whether start is a command or an argument to stop.
> 
> What are your thoughts about this change?

As I see that the discussion is now in two places, I'd shortly repeat
what I said on the bug.

First of all, I believe that you are focusing too much on your proposed
solution and too little on the actual problem. For example, in this
mail the actual problem is just linked as a footnote. This means that
we are starting to discuss the solution not knowing what it will be for.

As I mentioned there, I see that the problem covers a wide case of
script 'multiplexing', 'templates' or 'virtual script generators',
however you want to call it. I don't really think command-line
arguments can handle that. They will just add complexity to the issue.

For example, how would you consider the state of such a script? Will
every status check require passing additional arguments? Will every
script using this technique be required to re-invent the whole
multiplexing concept?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Fabian Groffen]

On 18-07-2012 15:58:18 -0400, Michael Mol wrote:
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
> 
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.
> 
> I.e.
> 
> touch -- -an-ugly-filename
> ls -l -- -an-ugly-filename
> rm -- -an-ugly-filename

yeah, but it means something like "don't treat the '-' as anything
special any more", so if you don't have something starting with -, you
don't need --.  Hence, following your "expected" behaviour argument,

/etc/init.d/foo stop start

would do the same as

/etc/init.d/foo stop -- start

or

/etc/init.d/foo -- stop start


Perhaps, one better makes it explicit, inspired by gdb

/etc/init.d/foo stop --args aggressive-kill=yes
(and when using --args, I'd probably disallow using multiple commands to
keep it clear what's going on)


Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Michał Górny]

On Wed, 18 Jul 2012 15:58:18 -0400
Michael Mol  wrote:

> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge  wrote:
> > William Hubbs wrote:
> >> /etc/init.d/foo stop start
> >>
> >> would no longer work the way you might expect because there would
> >> be no way to tell whether start is a command or an argument to
> >> stop.
> >>
> >> What are your thoughts about this change?
> >
> > /etc/init.d/foo stop start
> >
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
> 
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.

No, it's not intuitive. It's rather counter-intuitive.

GNU command line parsers use '--' to separate options from random
arguments. It's '--' because options start with '-'. For arguments
starting with any other character, GNU option parsers treat them
equally before and after '--'.

And yes, some tools actually use '--' to separate arguments to the tool
itself from arguments which are passed to some other tool. This is not
very intuitive as well, and I really prefer having
'--subtool-one-arguments "--foo --bar"' instead, with embedded
splitting logic. Of course, this is harder to implement.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Alec Warner]

On Wed, Jul 18, 2012 at 12:05 PM, Rich Freeman  wrote:
> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
>
> We don't even update kernels as part of the regular update process,
> let alone initramfs systems.
>
> In general you update them together.
>
> The only issue I could see is if problems arise if you have a
> different version of udev in your initramfs than on your system.  I
> don't know if that actually causes problems.  For the most part after
> the system is booted the initramfs is done its job.
>
> If some package did need a kernel/initramfs/etc to be updated it
> should be the subject of news or an ewarn unless it becomes routine
> practice.  I don't think we want the system to start touching these
> things without operator intervention unless we make it really
> bulletproof like they do on big distros (the only reason they can is
> they have one-size-fits-all kernels and initramfs designs).

I'm not really following your logic here, so forgive me. I completely
understand why folks do not say, rebuild their kernel when it is
updated  (kernel configs are annoying.)

However lets say I have coreutils in / and coreutils in my initramfs.
I upgrade coreutils from v1 to v2. Are you saying that you are too
afraid to update coreutils in / and then also update it in the
initramfs (probably by running $TOOL to copy coreutils from / to
initramfs-root.)

I'm not suggesting that we necessarily do this automatically, just
that people claim 'the tools do not exist to do this now' when in fact
it seems fairly straightforward to do.

I mean presumably you used $TOOL to build the initramfs once, so
running $TOOL again to generate a new initramfs probably should not
screw you, provided you have control over the configuration of $TOOL.

-A

>
> Rich
>

Re: [gentoo-dev] Opinion against /usr merge

[Rich Freeman]

On Wed, Jul 18, 2012 at 3:40 PM, Michael Mol  wrote:
> So your initramfs doesn't include network tools such as ping,
> traceroute or wget. Fine. Fundamentally speaking, why shouldn't
> someone else's?

So, an initramfs is just a piece of kernel functionality.  You can do
almost ANYTHING in an initramfs, subject to the limitation that it is
stored in RAM without any backing store.

There are lots of reasons to use an initramfs, and the biggest ones
don't pertain much to Gentoo.  Here are some of the big use cases:

1.  One-size-fits-all kernel.  You want to support root and /usr on
any filesystem, on any kind of hard drive, or on a SAN, or who knows
where.  That either means saying Y to every driver in the kernel, or
saying M and using an initramfs to load what is needed to get to root.

2.  One-size-fits-all grub config.  You put the smarts in the
initramfs, and use filesystem labels and such to identify partitions.

3.  Use of labels/UUIDs on partitions.  When mdadm decides to renumber
half your devices on a whim or you add a drive and everything bubbles
down by one, your system still boots.

4.  Cleaner mounting of root, ability to fsck on initial mount, etc.

5.  When something goes wrong you can get a dash/bash shell instead of
a grub shell.  The former is clearly more useful even if you don't
have firefox+X11 in your initramfs.

6.  Support for booting off of stuff that the kernel can't find on its
own, like SANs/etc.  That might require network support in the
initramfs, and that usually isn't a big deal.  If somebody can spoof
DNS on your fiber channel interface you've got bigger problems.

Sure, the more you do with the initramfs the bigger the potential
security risks.  Most distros don't have users build either kernels or
initramfs which means they can just push updates, but that requires #1
above, which I think most Gentoo users would not appreciate.

However, the initramfs shouldn't leave much of anything running after
it chroots, so the window should be fairly small.

Rich

Re: [gentoo-dev] Opinion against /usr merge

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:55 PM, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius 
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 18/07/12 03:47 PM, Michael Mol wrote:
>>> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés 
>>>  wrote:
 On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol
  wrote:
 
 The real benefit is that it allows you to mount any
 partition, if the tools to mount it live in the same
 partition.
>>> 
>>> Certainly that's a benefit.
>>> 
>> 
>> ...don't you mean, "if the tools to mount it live in the
>> initramfs" ??
>> 
>> if the partition isn't mounted I don't see how the initramfs
>> will allow you to mount it using its own tools...
> 
> I think you're replying to Canek. I took it to mean that having an 
> initramfs allows you to mount the very filesystems where you would 
> _traditionally_ expect to find the tools. E.g., being able to mount
> an encrypted /.
> 

Yeah i was..  i just wanted to re-emphasize the point that the tools
to mount it need to be on the initramfs (in whatever version or form
they were when the initramfs was built), and really have nothing to do
with them (including their current and possibly more up-to-date
version) living on said partition..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHFZUACgkQ2ugaI38ACPAiMAD/eWHxvaZPu1ikYN9ZeClsEWnB
pBDgfVPC0UTDeoUOVFcA+gKCmqa+lhs0x+arJhF7AZfWEbYb+jMK+bVxUVgfElR4
=O0O4
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Michael Mol]

On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge  wrote:
> William Hubbs wrote:
>> /etc/init.d/foo stop start
>>
>> would no longer work the way you might expect because there would be no
>> way to tell whether start is a command or an argument to stop.
>>
>> What are your thoughts about this change?
>
> /etc/init.d/foo stop start
>
> along with all other commands can work like before.
>
> /etc/init.d/foo stop -- start
>
> can pass start as an argument to the stop command.

I like this approach, because its use of -- continues expected
commandline parsing behaviors from other commands, making it
intuitive.

I.e.

touch -- -an-ugly-filename
ls -l -- -an-ugly-filename
rm -- -an-ugly-filename

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 18/07/12 03:47 PM, Michael Mol wrote:
>> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés
>>  wrote:
>>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol 
>>> wrote:
>>>
>>> The real benefit is that it allows you to mount any partition, if
>>> the tools to mount it live in the same partition.
>>
>> Certainly that's a benefit.
>>
>
> ...don't you mean, "if the tools to mount it live in the initramfs" ??
>
> if the partition isn't mounted I don't see how the initramfs will
> allow you to mount it using its own tools...

I think you're replying to Canek. I took it to mean that having an
initramfs allows you to mount the very filesystems where you would
_traditionally_ expect to find the tools. E.g., being able to mount an
encrypted /.

-- 
:wq

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:49 PM, Peter Stuge wrote:
> William Hubbs wrote:
>> /etc/init.d/foo stop start
>> 
>> would no longer work the way you might expect because there would
>> be no way to tell whether start is a command or an argument to
>> stop.
>> 
>> What are your thoughts about this change?
> 
> /etc/init.d/foo stop start
> 
> along with all other commands can work like before.
> 
> /etc/init.d/foo stop -- start
> 
> can pass start as an argument to the stop command.
> 
> 
> //Peter


I posted a response about this to the bug, but I don't see why, given
that all 'commands' are predefined anyways, the commandline couldn't
be parsed and split between commands..


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHFCkACgkQ2ugaI38ACPANyAEAnF7ngFvy/lcHPo0A4vEyN0zS
5QFTRmOiFG+GS8cRkyEBAL3ABkRD9M44sVHGs52ioctce+tsBSfLU9bawmBQuuJf
=dzvV
-END PGP SIGNATURE-

Re: [gentoo-dev] Opinion against /usr merge

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:47 PM, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés
>  wrote:
>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol 
>> wrote:
>> 
>> The real benefit is that it allows you to mount any partition, if
>> the tools to mount it live in the same partition.
> 
> Certainly that's a benefit.
> 

...don't you mean, "if the tools to mount it live in the initramfs" ??

if the partition isn't mounted I don't see how the initramfs will
allow you to mount it using its own tools...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHE3QACgkQ2ugaI38ACPDQBwD9HOn8skOvLhpPYuqCnH1Nuh7e
zefAwVaHDQQsz9vKVeYA/1utNcF2ROdeiHlMfvte4TGH42lo+NOjdM1Ml0wpU9b/
=5AMo
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Peter Stuge]

William Hubbs wrote:
> /etc/init.d/foo stop start
> 
> would no longer work the way you might expect because there would be no
> way to tell whether start is a command or an argument to stop.
> 
> What are your thoughts about this change?

/etc/init.d/foo stop start

along with all other commands can work like before.

/etc/init.d/foo stop -- start

can pass start as an argument to the stop command.


//Peter


pgpqZ9lU25F3m.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés  wrote:
> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol  wrote:
>> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman  wrote:
>>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
 AFAIK, neither genkernel nor dracut were expected to get tied to the
 Gentoo update process. Has that changed?
>>>
>>> We don't even update kernels as part of the regular update process,
>>> let alone initramfs systems.
>>>
>>> In general you update them together.
>>>
>>> The only issue I could see is if problems arise if you have a
>>> different version of udev in your initramfs than on your system.  I
>>> don't know if that actually causes problems.  For the most part after
>>> the system is booted the initramfs is done its job.
>>
>> The most widely touted benefit I've heard for initramfs is its
>> capability to ease system recovery in case, e.g. a critical filesystem
>> refuses to mount. With recovery roles come recovery tools, which
>> quickly extends network-aware tools and a security attack surface.
>
> The real benefit is that it allows you to mount any partition, if the
> tools to mount it live in the same partition.

Certainly that's a benefit.

> Recovering tools can be
> put in the initramfs, but I don't think nobody actually thinks that
> this is the "most widely touted benefit". Again, citation please.

I'm sorry, but I'm not going to grep through almost a decade of IRC
logs to find every discussion where someone says 'well, just put $tool
in your {initramfs,initrd}.' It's definitely something I've seen a
number of times. I *know* I've heard the line more than once in LUG
meetings, from people who hand-build theirs, but given that's a
local-to-me thing, you probably wouldn't know most of them by name.

>
>> Hence why I tend to feel that if an initramfs is going to become the
>> go-to solution for bootstrapping userland, it's important to consider
>> the difficulties of keeping the packed tools up-to-date; it's not just
>> a bootstrap tool, it's also the first recovery option a sysadmin
>> faces.
>
> If you keep your initramfs synchronized (which is easily done with
> dracut, for example), that problem goes away.

Again, dracut isn't stable, genkernel isn't part of any normal routine
system update, and I hold the same trepidations expressed by Rich
about limitations on circumstances where that's even appropriate.
-- 
:wq

[gentoo-dev] rfc: openrc init scripts taking command line arguments

[William Hubbs]

All,

I have received a request to allow OpenRC's init scripts to take command
line arguments [1]. As noted on the bug, there are some advantages to
this, but implementing it would have to break backward compatibility,
for example:

/etc/init.d/foo stop start

would no longer work the way you might expect because there would be no
way to tell whether start is a command or an argument to stop.

What are your thoughts about this change?

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=427144


pgp4N15VIiNj5.pgp
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 3:20 PM, Canek Peláez Valdés  wrote:
> On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol  wrote:
>> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés  
>> wrote:
>>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol  wrote:
 On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner  wrote:
>>> [snip]
> Debian uses initramfs-tools...

 AFAIK, neither genkernel nor dracut were expected to get tied to the
 Gentoo update process. Has that changed?
>>>
>>> The kernel you are running (if you update your machine) is not tied to
>>> the Gentoo update process. The *source code* gets installed, but the
>>> kernel source remains unchanged in /usr/src/whatever. It's the user
>>> responsibility to configure, compile, and install the kernel (and then
>>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
>>> genkernel, but it's not "tied to the Gentoo update process".
>>>
>>> I really don't see that much difference with needing to also update
>>> the initramfs, if needed.
>>
>> What if your DNS resolver in your rescue shell has a vulnerability?
>> What if wget, links or whatever network tools you use during recovery
>> have a vulnerability?
>>
>> These are tools which are commonly placed in initramfs.
>
> First of all, none of this has nothing to do with the discussion at
> hand.

I completely disagree. If you take a step in a direction, you have
momentum. So before you take a step in that direction, you should look
where that momentum will carry you.

> Second, I don't know what kind of initramfs you are familiar
> with, but mine has nothing network related, and I don't see *any*
> reason to include *anything* network related to an initramfs.

So your initramfs doesn't include network tools such as ping,
traceroute or wget. Fine. Fundamentally speaking, why shouldn't
someone else's?

>
>>> Because, besides, if your /usr is not in a different partition, you
>>> don't even *need* an initramfs. In that case not using an initramfs is
>>> supported by all upstreams.
>>
>> And what of /var? /opt?
>
> What about them? Again, what it has this anything to do with our
> current discussion?

See my reply to Michal.

>
>> The problem with the /usr merge upstream is
>> that someone didn't think things through when they pushed it, and the
>> same reasoning used to justify it easily justifies changing the way
>> /var and /opt are treated.
>
> That's pure speculation.

I'll repeat myself. If you take a step, you have momentum. Before you
take a step, you should see where that momentum will carry you.

> Nobody has ever suggested merging /opt nor
> /var; if I'm mistaken I would love to see even a single link (mail,
> blog post, IRC discussion) were it was at least mentioned as a good
> idea to do the same with /opt or /var. I'm pretty sure you don't have
> any.

I don't believe anyone *does* think it's a good idea, but I don't see
how the arguments on behalf of a /usr merge don't operate in the same
way on /var or /opt. If the argument is flawed for either of those
two, I don't see how it isn't equally flawed for /usr. I've never seen
where people have examined that in depth.

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol  wrote:
> On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman  wrote:
>> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> We don't even update kernels as part of the regular update process,
>> let alone initramfs systems.
>>
>> In general you update them together.
>>
>> The only issue I could see is if problems arise if you have a
>> different version of udev in your initramfs than on your system.  I
>> don't know if that actually causes problems.  For the most part after
>> the system is booted the initramfs is done its job.
>
> The most widely touted benefit I've heard for initramfs is its
> capability to ease system recovery in case, e.g. a critical filesystem
> refuses to mount. With recovery roles come recovery tools, which
> quickly extends network-aware tools and a security attack surface.

The real benefit is that it allows you to mount any partition, if the
tools to mount it live in the same partition. Recovering tools can be
put in the initramfs, but I don't think nobody actually thinks that
this is the "most widely touted benefit". Again, citation please.

> Hence why I tend to feel that if an initramfs is going to become the
> go-to solution for bootstrapping userland, it's important to consider
> the difficulties of keeping the packed tools up-to-date; it's not just
> a bootstrap tool, it's also the first recovery option a sysadmin
> faces.

If you keep your initramfs synchronized (which is easily done with
dracut, for example), that problem goes away.

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-dev] Opinion against /usr merge

[Michał Górny]

On Wed, 18 Jul 2012 15:12:14 -0400
Michael Mol  wrote:

> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés
>  wrote:
> > On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol 
> > wrote:
> >> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner 
> >> wrote:
> > [snip]
> >>> Debian uses initramfs-tools...
> >>
> >> AFAIK, neither genkernel nor dracut were expected to get tied to
> >> the Gentoo update process. Has that changed?
> >
> > The kernel you are running (if you update your machine) is not tied
> > to the Gentoo update process. The *source code* gets installed, but
> > the kernel source remains unchanged in /usr/src/whatever. It's the
> > user responsibility to configure, compile, and install the kernel
> > (and then update LILO, grub-legacy or GRUB2). It can be automated
> > with (ta-da) genkernel, but it's not "tied to the Gentoo update
> > process".
> >
> > I really don't see that much difference with needing to also update
> > the initramfs, if needed.
> 
> What if your DNS resolver in your rescue shell has a vulnerability?
> What if wget, links or whatever network tools you use during recovery
> have a vulnerability?

What if whatever tools you have in rootfs have a vulnerability and they
are statically linked so that we don't have to move half of the system
into rootfs?

> > Because, besides, if your /usr is not in a different partition, you
> > don't even *need* an initramfs. In that case not using an initramfs
> > is supported by all upstreams.
> 
> And what of /var? /opt? The problem with the /usr merge upstream is
> that someone didn't think things through when they pushed it, and the
> same reasoning used to justify it easily justifies changing the way
> /var and /opt are treated.

What with them? /var has a special place of its own, and I don't see
why it is brought here.

/opt is a defined prefix. Like /usr is. Moving anything into or out of
it is a completely separate topic.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol  wrote:
> On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés  wrote:
>> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol  wrote:
>>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner  wrote:
>> [snip]
 Debian uses initramfs-tools...
>>>
>>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>>> Gentoo update process. Has that changed?
>>
>> The kernel you are running (if you update your machine) is not tied to
>> the Gentoo update process. The *source code* gets installed, but the
>> kernel source remains unchanged in /usr/src/whatever. It's the user
>> responsibility to configure, compile, and install the kernel (and then
>> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
>> genkernel, but it's not "tied to the Gentoo update process".
>>
>> I really don't see that much difference with needing to also update
>> the initramfs, if needed.
>
> What if your DNS resolver in your rescue shell has a vulnerability?
> What if wget, links or whatever network tools you use during recovery
> have a vulnerability?
>
> These are tools which are commonly placed in initramfs.

First of all, none of this has nothing to do with the discussion at
hand. Second, I don't know what kind of initramfs you are familiar
with, but mine has nothing network related, and I don't see *any*
reason to include *anything* network related to an initramfs.

>> Because, besides, if your /usr is not in a different partition, you
>> don't even *need* an initramfs. In that case not using an initramfs is
>> supported by all upstreams.
>
> And what of /var? /opt?

What about them? Again, what it has this anything to do with our
current discussion?

> The problem with the /usr merge upstream is
> that someone didn't think things through when they pushed it, and the
> same reasoning used to justify it easily justifies changing the way
> /var and /opt are treated.

That's pure speculation. Nobody has ever suggested merging /opt nor
/var; if I'm mistaken I would love to see even a single link (mail,
blog post, IRC discussion) were it was at least mentioned as a good
idea to do the same with /opt or /var. I'm pretty sure you don't have
any.

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-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman  wrote:
> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
>
> We don't even update kernels as part of the regular update process,
> let alone initramfs systems.
>
> In general you update them together.
>
> The only issue I could see is if problems arise if you have a
> different version of udev in your initramfs than on your system.  I
> don't know if that actually causes problems.  For the most part after
> the system is booted the initramfs is done its job.

The most widely touted benefit I've heard for initramfs is its
capability to ease system recovery in case, e.g. a critical filesystem
refuses to mount. With recovery roles come recovery tools, which
quickly extends network-aware tools and a security attack surface.

Hence why I tend to feel that if an initramfs is going to become the
go-to solution for bootstrapping userland, it's important to consider
the difficulties of keeping the packed tools up-to-date; it's not just
a bootstrap tool, it's also the first recovery option a sysadmin
faces.

>
> If some package did need a kernel/initramfs/etc to be updated it
> should be the subject of news or an ewarn unless it becomes routine
> practice.  I don't think we want the system to start touching these
> things without operator intervention unless we make it really
> bulletproof like they do on big distros (the only reason they can is
> they have one-size-fits-all kernels and initramfs designs).

Absolutely.

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés  wrote:
> On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol  wrote:
>> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner  wrote:
> [snip]
>>> Debian uses initramfs-tools...
>>
>> AFAIK, neither genkernel nor dracut were expected to get tied to the
>> Gentoo update process. Has that changed?
>
> The kernel you are running (if you update your machine) is not tied to
> the Gentoo update process. The *source code* gets installed, but the
> kernel source remains unchanged in /usr/src/whatever. It's the user
> responsibility to configure, compile, and install the kernel (and then
> update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
> genkernel, but it's not "tied to the Gentoo update process".
>
> I really don't see that much difference with needing to also update
> the initramfs, if needed.

What if your DNS resolver in your rescue shell has a vulnerability?
What if wget, links or whatever network tools you use during recovery
have a vulnerability?

These are tools which are commonly placed in initramfs.

>
> Because, besides, if your /usr is not in a different partition, you
> don't even *need* an initramfs. In that case not using an initramfs is
> supported by all upstreams.

And what of /var? /opt? The problem with the /usr merge upstream is
that someone didn't think things through when they pushed it, and the
same reasoning used to justify it easily justifies changing the way
/var and /opt are treated.

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Rich Freeman]

On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol  wrote:
> AFAIK, neither genkernel nor dracut were expected to get tied to the
> Gentoo update process. Has that changed?

We don't even update kernels as part of the regular update process,
let alone initramfs systems.

In general you update them together.

The only issue I could see is if problems arise if you have a
different version of udev in your initramfs than on your system.  I
don't know if that actually causes problems.  For the most part after
the system is booted the initramfs is done its job.

If some package did need a kernel/initramfs/etc to be updated it
should be the subject of news or an ewarn unless it becomes routine
practice.  I don't think we want the system to start touching these
things without operator intervention unless we make it really
bulletproof like they do on big distros (the only reason they can is
they have one-size-fits-all kernels and initramfs designs).

Rich

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol  wrote:
> On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner  wrote:
[snip]
>> Debian uses initramfs-tools...
>
> AFAIK, neither genkernel nor dracut were expected to get tied to the
> Gentoo update process. Has that changed?

The kernel you are running (if you update your machine) is not tied to
the Gentoo update process. The *source code* gets installed, but the
kernel source remains unchanged in /usr/src/whatever. It's the user
responsibility to configure, compile, and install the kernel (and then
update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
genkernel, but it's not "tied to the Gentoo update process".

I really don't see that much difference with needing to also update
the initramfs, if needed.

Because, besides, if your /usr is not in a different partition, you
don't even *need* an initramfs. In that case not using an initramfs is
supported by all upstreams.

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-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner  wrote:
> On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol  wrote:

[snip]

>> To me, it looks a lot like what once was / is now expected to be an
>> initramfs, which I find extraordinarily problematic, for the following
>> reasons:
>>
>> 1) There are no truly mature tools for automatically generating and
>> installing an initramfs based on system requirements. Canek likes to
>> recommend dracut, which still isn't marked stable. I've gotten stable
>> genkernel to work reasonably, but its error reporting is terrible.
>> 2) There's no good means for applying software and security updates to
>> an initramfs. If having an initramfs is to be considered the new
>> normal, there should be some means of updating it as part of routine
>> system updates.
>
> Debian uses initramfs-tools...

AFAIK, neither genkernel nor dracut were expected to get tied to the
Gentoo update process. Has that changed?

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Alec Warner]

On Wed, Jul 18, 2012 at 8:25 PM, Michael Mol  wrote:
> On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny  wrote:
>> On Wed, 18 Jul 2012 18:40:12 +0100
>> Ciaran McCreesh  wrote:
>>
>>> On Wed, 18 Jul 2012 12:35:58 -0500
>>> Canek Peláez Valdés  wrote:
>>> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
>>> > separated are really instances of the Chewbacca defense [1]. They
>>> > just don't make any sense.
>>>
>>> All the arguments for changing things are just realising that the
>>> horse has fled the barn and then trying to rationalise not needing a
>>> horse.
>>
>> I believe I don't need a horse. I don't even have a barn either.
>
> To carry the analogy, udev forcing a /usr merge is much like "We don't
> need a horse, so we don't think anyone else should have one, either.
> If they need a horse, they can use one of those newfangled tractors."
>
> Personally, I think the original reasoning behind udev's move was
> flawed. When I read it, it sounded like "we can't control whether or
> not anyone else puts boot-required packages into /usr before /usr has
> been mounted. In order to cover for those packages, we'll force the
> issue by putting ourselves there."
>
> I think that any package which puts boot-required things into a path
> which may not be available at boot time is inherently broken, and
> needs to be fixed. There's absolutely nothing about the move which
> both accounts for boot-required packages requiring access to /var
> _and_ a sysadmin's need to have /var as a special mount point.
>
> To me, it looks a lot like what once was / is now expected to be an
> initramfs, which I find extraordinarily problematic, for the following
> reasons:
>
> 1) There are no truly mature tools for automatically generating and
> installing an initramfs based on system requirements. Canek likes to
> recommend dracut, which still isn't marked stable. I've gotten stable
> genkernel to work reasonably, but its error reporting is terrible.
> 2) There's no good means for applying software and security updates to
> an initramfs. If having an initramfs is to be considered the new
> normal, there should be some means of updating it as part of routine
> system updates.

Debian uses initramfs-tools...

> 3) With an initramfs and the tools to generate it, we have more moving
> parts were previously there were few.
>
> --
> :wq
>

Re: [gentoo-dev] Opinion against /usr merge

[Michał Górny]

On Wed, 18 Jul 2012 11:35:02 -0400
"Walter Dnes"  wrote:

> On Tue, Jul 17, 2012 at 07:12:09PM -0500, William Hubbs wrote
> > On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> > > 
> > > Looking at @system and what it typically pulls into @world, the
> > > only thing that might cause a problem is udev, although
> > > virtual/dev-manager is in @system, rather than udev. If that
> > > happens, we have a few ways of dealing with that:
> > > 
> > > 1. Patch udev.
> > 
> > I think I can come up with a patch locally that will read rules from
> > /lib/udev/rules.d if that's what we want to do for now.
> > 
> > > 2. Fork udev.
> > 
> > I don't think this is necessary, and it would create more work for
> > us than is needed.
> 
>   3. More support for mdev; e.g.  https://wiki.gentoo.org/wiki/Mdev
> and (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB
> The next challenge is "custom mdev rules", which should be do-able.

I don't think we should give more support to building a system from
a statically linked rescue suite tool.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 1:58 PM, Michał Górny  wrote:
> On Wed, 18 Jul 2012 18:40:12 +0100
> Ciaran McCreesh  wrote:
>
>> On Wed, 18 Jul 2012 12:35:58 -0500
>> Canek Peláez Valdés  wrote:
>> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
>> > separated are really instances of the Chewbacca defense [1]. They
>> > just don't make any sense.
>>
>> All the arguments for changing things are just realising that the
>> horse has fled the barn and then trying to rationalise not needing a
>> horse.
>
> I believe I don't need a horse. I don't even have a barn either.

To carry the analogy, udev forcing a /usr merge is much like "We don't
need a horse, so we don't think anyone else should have one, either.
If they need a horse, they can use one of those newfangled tractors."

Personally, I think the original reasoning behind udev's move was
flawed. When I read it, it sounded like "we can't control whether or
not anyone else puts boot-required packages into /usr before /usr has
been mounted. In order to cover for those packages, we'll force the
issue by putting ourselves there."

I think that any package which puts boot-required things into a path
which may not be available at boot time is inherently broken, and
needs to be fixed. There's absolutely nothing about the move which
both accounts for boot-required packages requiring access to /var
_and_ a sysadmin's need to have /var as a special mount point.

To me, it looks a lot like what once was / is now expected to be an
initramfs, which I find extraordinarily problematic, for the following
reasons:

1) There are no truly mature tools for automatically generating and
installing an initramfs based on system requirements. Canek likes to
recommend dracut, which still isn't marked stable. I've gotten stable
genkernel to work reasonably, but its error reporting is terrible.
2) There's no good means for applying software and security updates to
an initramfs. If having an initramfs is to be considered the new
normal, there should be some means of updating it as part of routine
system updates.
3) With an initramfs and the tools to generate it, we have more moving
parts were previously there were few.

-- 
:wq

Re: [gentoo-dev] Opinion against /usr merge

[Fabian Groffen]

On 18-07-2012 14:11:07 -0400, Michael Mol wrote:
> Worse, I think /home to /Users is an *egregiously* poor choice; any
> native English speaker who has rudimenatry (or even intimate)
> knowledge of how things previously worked would be very likely to
> confuse /Users with the historical /usr.

You *are* aware OSX uses this, right?

> ... Heck, I know a local guy who
> has to struggle to get newish versions of Python, CUPS and other
> things onto an AIX box, because those are the tools he has to use to
> satisfy company needs. Based on IRC conversations, it sounds like he
> spends at least 5% of his time (that *I* know about, anyway) trying to
> wedge new software into old systems.

How is this related to something like a /usr merge?

> Ugh. I've gone offtopic. This email went from having anything to do
> with udev to being about filesystems layouts.

Seems to me we're in a different thread here :)


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Opinion against /usr merge

[Jason A. Donenfeld]

On Wed, Jul 18, 2012 at 5:35 PM, Walter Dnes  wrote:
>
>   3. More support for mdev; e.g.  https://wiki.gentoo.org/wiki/Mdev and
> (still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB  The
> next challenge is "custom mdev rules", which should be do-able.


Interesting. Can you talk more about the benefits of mdev in
non-embedded systems? Why would I want to use this instead of udev
(aside from the /usr dispute).

Re: [gentoo-dev] DESCRIPTION in eclasses

[Ciaran McCreesh]

On Wed, 18 Jul 2012 19:56:56 +0200
Ulrich Mueller  wrote:
> Many eclasses (eutils being the most prominent example) contain:
> DESCRIPTION="Based on the ${ECLASS} eclass"
> 
> Is this of any use?

The reason that sort of thing is there is because in the olden days
before we had specs or EAPIs or anything like that, eclasses were
originally designed and implemented as "classes" in an OO type manner.
The idea was that there would be a "base" eclass, and then you'd derive
"kde", "gnome" etc eclasses from there, all in a nice hierarchy, and
you'd be expected to "override" variables like DESCRIPTION as you go
down the tree.

As it turns out, eclasses ended up being used in a completely different
way. But you still see bits of the original idea cropping up, such as
in the words "class" and "inherit" and "base".

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michael Mol]

On Wed, Jul 18, 2012 at 11:04 AM, Canek Peláez Valdés  wrote:
> I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin;
> moreover, I want an even more radical change:
>
> /usr -> /System
> /home -> /Users
> /etc -> /Config

This would be a terrible idea, IMO. If you can rationalize this, why
not any of these?

/etc -> /設定
/etc -> /组态
/etc -> /組態
/etc -> /configuración

Codes (and things like 'usr', 'etc' and 'home' are codes) may not be
the most intuitive, but they have roughly the same difficulty
regardless of your source language.

Worse, I think /home to /Users is an *egregiously* poor choice; any
native English speaker who has rudimenatry (or even intimate)
knowledge of how things previously worked would be very likely to
confuse /Users with the historical /usr.

> Why should we care about ancient filesystems that didn't supported
> long paths, and therefore we got stuck with /usr since we didn't
> wanted to waste another *single* character to make it /user?
>
> Let that silly legacy stuff die. Keep symbolic links to the old
> directories for compatibility reasons, if you want to (modern software
> should not need it anyhow), and move on. Remember /usr/X11R6? We kept
> a /usr/X11R6 -> /usr link for years. Do you miss it?

The longer something exists, the more things like procedures and best
practices grow to depend on it both explicitly and implicitly. There's
a lot of stuff out there which assumes the existing structure. Stuff
that people don't necessarily even think about any more, because it
just works.

Grossly changing the filesystem layout does worse than make
maintenance of known software more difficult, it changes a lot of
longstanding assumptions for ancient, still-functional code written
ages upon ages ago, and it makes it that much more difficult to
install new software onto production systems which have been running
for decades.

That's the legacy of being a UNIX-alike. Heck, I know a local guy who
has to struggle to get newish versions of Python, CUPS and other
things onto an AIX box, because those are the tools he has to use to
satisfy company needs. Based on IRC conversations, it sounds like he
spends at least 5% of his time (that *I* know about, anyway) trying to
wedge new software into old systems.

Change almost always breaks more things than you expect, because you
only expect the things you remembered to consider, not the things you
forgot existed.

Ugh. I've gone offtopic. This email went from having anything to do
with udev to being about filesystems layouts.

-- 
:wq

Re: [gentoo-dev] Don't require assignment of empty variables in ebuilds?

[Davide Pesavento]

On Wed, Jul 18, 2012 at 11:02 AM, Robin H. Johnson  wrote:
> On Wed, Jul 18, 2012 at 07:53:37PM +0200, Ulrich Mueller wrote:
>> Our current policy [1] requires that ebuilds must assign the seven
>> variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, and
>> IUSE, even if their value is empty.
>>
>> Could we drop this requirement? Repoman already enforces that
>> DESCRIPTION, HOMEPAGE, LICENSE, SLOT, and KEYWORDS are non-empty
>> (with some exceptions for virtuals). I don't see why we need to
>> distinguish the "empty value" and "not assigned" cases.
>>
>> For example, many live ebuilds already don't define SRC_URI. I'm not
>> aware of any problems caused by this.
> +1 from me.
>

++

Thanks,
Pesa

Re: [gentoo-dev] Opinion against /usr merge

[Maxim Kammerer]

On Wed, Jul 18, 2012 at 8:35 PM, Canek Peláez Valdés  wrote:
> But it must be clear that all the rationale behind
> said division was invented after the fact,

I would say that the rationale was not “invented”, but rather adapted
to an evolving system.

> and (as Rob Landley said in
> his email [2]) maintained "for decades by bureaucrats who never
> question _why_ they're doing things".

I am surprised that anyone took that rant seriously. It is just a
rant, ignoring evolution of systems (where initially arbitrary
configuration changes and gets meaning with time), and treating
developers who have to deal with backwards compatibility issues and
established usage conventions as thick bureaucrats.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Don't require assignment of empty variables in ebuilds?

[Robin H. Johnson]

On Wed, Jul 18, 2012 at 07:53:37PM +0200, Ulrich Mueller wrote:
> Our current policy [1] requires that ebuilds must assign the seven
> variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, and
> IUSE, even if their value is empty.
> 
> Could we drop this requirement? Repoman already enforces that
> DESCRIPTION, HOMEPAGE, LICENSE, SLOT, and KEYWORDS are non-empty
> (with some exceptions for virtuals). I don't see why we need to
> distinguish the "empty value" and "not assigned" cases.
> 
> For example, many live ebuilds already don't define SRC_URI. I'm not
> aware of any problems caused by this.
+1 from me.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Opinion against /usr merge

[Michał Górny]

On Wed, 18 Jul 2012 18:40:12 +0100
Ciaran McCreesh  wrote:

> On Wed, 18 Jul 2012 12:35:58 -0500
> Canek Peláez Valdés  wrote:
> > All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
> > separated are really instances of the Chewbacca defense [1]. They
> > just don't make any sense.
> 
> All the arguments for changing things are just realising that the
> horse has fled the barn and then trying to rationalise not needing a
> horse.

I believe I don't need a horse. I don't even have a barn either.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] DESCRIPTION in eclasses

[Ulrich Mueller]

Many eclasses (eutils being the most prominent example) contain:
DESCRIPTION="Based on the ${ECLASS} eclass"

Is this of any use?

Ulrich

[gentoo-dev] Don't require assignment of empty variables in ebuilds?

[Ulrich Mueller]

Our current policy [1] requires that ebuilds must assign the seven
variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE, SLOT, KEYWORDS, and
IUSE, even if their value is empty.

Could we drop this requirement? Repoman already enforces that
DESCRIPTION, HOMEPAGE, LICENSE, SLOT, and KEYWORDS are non-empty
(with some exceptions for virtuals). I don't see why we need to
distinguish the "empty value" and "not assigned" cases.

For example, many live ebuilds already don't define SRC_URI. I'm not
aware of any problems caused by this.

Ulrich

[1] 

Re: [gentoo-dev] Opinion against /usr merge

[Jason A. Donenfeld]

On Wed, Jul 18, 2012 at 1:07 AM, Olivier Crête  wrote:
> Also be ready for a merge of /bin and /sbin.. I'm sure most people can't
> even explain the difference between them.

Whoa hey what why? Who's pushing this forward?

Re: [gentoo-dev] Opinion against /usr merge

[Ciaran McCreesh]

On Wed, 18 Jul 2012 12:35:58 -0500
Canek Peláez Valdés  wrote:
> All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
> separated are really instances of the Chewbacca defense [1]. They just
> don't make any sense.

All the arguments for changing things are just realising that the horse
has fled the barn and then trying to rationalise not needing a horse.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 11:13 AM, Hobbit  wrote:
>> Why should we care about ancient filesystems that didn't supported
>> long paths, and therefore we got stuck with /usr since we didn't
>> wanted to waste another *single* character to make it /user?
>
> Because of it's original name: "UNIX System Resources" (usr).

As William pointed out, this is just another silly rationalization
done after the fact. But, just for argument's sake, lets suppose that
"usr" was named like that because it was the acronym for "UNIX System
Resources".

*Who cares about that now?* It was 43 years ago. My cellphone is
thousands of times faster than the PDP-7 Unix was originally developed
for, and it has millions of times more storage. The length
restrictions imposed on system directories are completely superfluous
now.

All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
separated are really instances of the Chewbacca defense [1]. They just
don't make any sense.

If upstream projects want to move everything to one location, Gentoo
should follow suit. If enough Gentoo devs (as others had argued) want
to waste their efforts in maintaining this artificial and silly
division between /bin, /sbin, /usr/bin, and /usr/sbin, it is of course
their prerogative. But it must be clear that all the rationale behind
said division was invented after the fact, and (as Rob Landley said in
his email [2]) maintained "for decades by bureaucrats who never
question _why_ they're doing things".

Regards.

[1] http://en.wikipedia.org/wiki/Chewbacca_defense
[2] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass]

[Ciaran McCreesh]

On Wed, 18 Jul 2012 18:18:35 +0200
"Andreas K. Huettel"  wrote:
> > On Wed, Jul 18, 2012 at 5:33 PM, hasufell 
> > wrote:
> > > "epatch" is so widely used and basic that I wonder why it's still
> > > not implemented as a real helper function.
> > 
> > Because then its harder to change, it must be in PMS, otherwise you
> > have to do things like test which version of epatch the package
> > manager providessounds a lot like EAPI :)
> > 
> 
> You know, that's actually a pretty good case *for* base.eclass,
> eutils.eclass and similar... we should probably move more functions
> there...  :D 

I'm not sure that having to make sure you don't break ten thousand
packages whenever you make a change is a good case... When it's EAPI
controlled, if a change causes problems, it doesn't break anything.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Hobbit]

On 11:26 Wed 18 Jul , William Hubbs wrote:
> Actually this is not correct (see my earlier post with the link to
> osnews.com).

Indeed. My bad.

[gentoo-dev] net-misc/rabbitmq-server up for grabs

[Benedikt Böhm]

All,

i'm not using rabbitmq-server except as a dependency for
app-admin/chef and i've no interest or time to fix it. Feel free to
take it.

Regards,
Bene

Re: [gentoo-dev] Opinion against /usr merge

[William Hubbs]

On Wed, Jul 18, 2012 at 08:13:51PM +0400, Hobbit wrote:
> > Why should we care about ancient filesystems that didn't supported
> > long paths, and therefore we got stuck with /usr since we didn't
> > wanted to waste another *single* character to make it /user?
> 
> Because of it's original name: "UNIX System Resources" (usr).

Actually this is not correct (see my earlier post with the link to
osnews.com).
Originally it contained user directories like /home does now.

William



pgpc1JoopQ1kk.pgp
Description: PGP signature

Re: Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass]

[Andreas K. Huettel]

> On Wed, Jul 18, 2012 at 5:33 PM, hasufell  wrote:
> > "epatch" is so widely used and basic that I wonder why it's still not
> > implemented as a real helper function.
> 
> Because then its harder to change, it must be in PMS, otherwise you
> have to do things like test which version of epatch the package
> manager providessounds a lot like EAPI :)
> 

You know, that's actually a pretty good case *for* base.eclass, eutils.eclass 
and similar... we should probably move more functions there...  :D 

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

Re: [gentoo-dev] Opinion against /usr merge

[Hobbit]

> Why should we care about ancient filesystems that didn't supported
> long paths, and therefore we got stuck with /usr since we didn't
> wanted to waste another *single* character to make it /user?

Because of it's original name: "UNIX System Resources" (usr).

Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass]

[Alec Warner]

On Wed, Jul 18, 2012 at 5:33 PM, hasufell  wrote:
> "epatch" is so widely used and basic that I wonder why it's still not
> implemented as a real helper function.
>

Because then its harder to change, it must be in PMS, otherwise you
have to do things like test which version of epatch the package
manager providessounds a lot like EAPI :)

-A

[gentoo-dev] epatch still no helper function? [from eutils.eclass]

[hasufell]

"epatch" is so widely used and basic that I wonder why it's still not
implemented as a real helper function.

Re: [gentoo-dev] Opinion against /usr merge

[Walter Dnes]

On Tue, Jul 17, 2012 at 07:12:09PM -0500, William Hubbs wrote
> On Tue, Jul 17, 2012 at 07:19:48PM -0400, Richard Yao wrote:
> > 
> > Looking at @system and what it typically pulls into @world, the only
> > thing that might cause a problem is udev, although virtual/dev-manager
> > is in @system, rather than udev. If that happens, we have a few ways of
> > dealing with that:
> > 
> > 1. Patch udev.
> 
> I think I can come up with a patch locally that will read rules from
> /lib/udev/rules.d if that's what we want to do for now.
> 
> > 2. Fork udev.
> 
> I don't think this is necessary, and it would create more work for us
> than is needed.

  3. More support for mdev; e.g.  https://wiki.gentoo.org/wiki/Mdev and
(still in beta) https://wiki.gentoo.org/wiki/Mdev/Automount_USB  The
next challenge is "custom mdev rules", which should be do-able.

-- 
Walter Dnes 

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 8:18 AM, Richard Yao  wrote:
> On 07/18/2012 04:10 AM, Michał Górny wrote:
>> On Tue, 17 Jul 2012 23:54:16 -0400
>> Richard Yao  wrote:

[snip]

>>> The difference is simple. You put stuff into /sbin when you do not
>>> want regular users to be able to select it via tab completion by
>>> default.
>>
>> Now put that definition into my cold logic brain.
>
> That was meant as a joke, although the irony is that it is true.

So, you are rationalizing a posteriori an original irrational decision.

Understanding the bin, sbin, usr/bin , usr/sbin split:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

"The /bin vs /usr/bin split (and all the others) is an artifact of
this, a 1970's implementation detail that got carried forward for
decades by bureaucrats who never question _why_ they're doing things.
It stopped making any sense before Linux was ever invented, for
multiple reasons"

I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin;
moreover, I want an even more radical change:

/usr -> /System
/home -> /Users
/etc -> /Config

Why should we care about ancient filesystems that didn't supported
long paths, and therefore we got stuck with /usr since we didn't
wanted to waste another *single* character to make it /user?

Let that silly legacy stuff die. Keep symbolic links to the old
directories for compatibility reasons, if you want to (modern software
should not need it anyhow), and move on. Remember /usr/X11R6? We kept
a /usr/X11R6 -> /usr link for years. Do you miss it?

I surely not. 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-dev] Opinion against /usr merge

[Richard Yao]

On 07/18/2012 04:10 AM, Michał Górny wrote:
> On Tue, 17 Jul 2012 23:54:16 -0400
> Richard Yao  wrote:
> 
>> On 07/17/2012 07:07 PM, Olivier Crête wrote:
>>> On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
 If somebody really is pushing for an all-out /usr move by all means
 speak up, but I think that basically what everybody is advocating
 is trying to follow upstream for individual packages. 
>>>
>>> As I've been saying for a while, doing a full merge
>>> of /bin, /sbin, /lib into /usr is probably unavoidable in the long
>>> term. We should be ready for it, and even try to do it
>>> progressively. As currently, the split is entirely arbitrary.
>>>
>>> Also be ready for a merge of /bin and /sbin.. I'm sure most people
>>> can't even explain the difference between them.
>>>
>>
>> The difference is simple. You put stuff into /sbin when you do not
>> want regular users to be able to select it via tab completion by
>> default.
> 
> Now put that definition into my cold logic brain.
> 

That was meant as a joke, although the irony is that it is true.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Michał Górny posted on Wed, 18 Jul 2012 11:55:32 +0200 as excerpted:

> On Wed, 18 Jul 2012 09:49:24 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> Michał Górny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:
>> 
>> > Didn't you see Lennart's opinions on Gentoo Linux? I don't think
>> > their refusal needed to be expressed at all.
>> 
>> I don't believe I did.  Link?
> 
> http://lalists.stanford.edu/lad/2009/06/0191.html
> 
> Around the non-wrapped line.

Thanks.  Not too surprising for a major binary-distro dev, I guess.

Meanwhile, I'm more appreciative than ever of gentoo's abilities.  Where 
else would I be able to run a fully distro-supported kde, without all the 
kde semantic-desktop stuff dragging stuff down?  Turning it off at 
runtime didn't cut it, but killing it at build-time surely did! =:^)

That's an option people running most distros won't ever have; a contrast 
they'll never be able to make, at least not without a whole lot more 
manual fiddling than necessary on gentoo, anyway.

Makes me really appreciate what we have, here on gentoo.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Opinion against /usr merge

[Michał Górny]

On Wed, 18 Jul 2012 09:49:24 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> Michał Górny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:
> 
> > Didn't you see Lennart's opinions on Gentoo Linux? I don't think
> > their refusal needed to be expressed at all.
> 
> I don't believe I did.  Link?

http://lalists.stanford.edu/lad/2009/06/0191.html

Around the non-wrapped line.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: Opinion against /usr merge

[Duncan]

Michał Górny posted on Wed, 18 Jul 2012 10:18:49 +0200 as excerpted:

> Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
> refusal needed to be expressed at all.

I don't believe I did.  Link?

(FWIW I expect I'll eventually switch to systemd, but there's no hurry, 
and IMO it has some maturing to do still.  Meanwhile, openrc's working 
great for me ATM and I have no immediate plans to switch.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Opinion against /usr merge

[Michał Górny]

On Tue, 17 Jul 2012 17:20:13 -0400
Richard Yao  wrote:

> Dear Everyone,
> 
> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

You forgot about /var. And possibly /srv. But yes, you are probably
having separate filesystems so you don't care about people having
different layout.

> With that said, there is a great deal of FUD being spread by the
> systemd developers and I see no reason for us to accept it. We would
> be breaking users' systems for no gain other than to make the systemd
> developers happy. Their refusal to permit udev to be built separately
> from systemd demonstrated complete disdain for Gentoo Linux. Why
> should we let them dictate how we design our distribution at our
> users' expense?

Didn't you see Lennart's opinions on Gentoo Linux? I don't think their
refusal needed to be expressed at all.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michał Górny]

On Tue, 17 Jul 2012 23:54:16 -0400
Richard Yao  wrote:

> On 07/17/2012 07:07 PM, Olivier Crête wrote:
> > On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote:
> >> If somebody really is pushing for an all-out /usr move by all means
> >> speak up, but I think that basically what everybody is advocating
> >> is trying to follow upstream for individual packages. 
> > 
> > As I've been saying for a while, doing a full merge
> > of /bin, /sbin, /lib into /usr is probably unavoidable in the long
> > term. We should be ready for it, and even try to do it
> > progressively. As currently, the split is entirely arbitrary.
> > 
> > Also be ready for a merge of /bin and /sbin.. I'm sure most people
> > can't even explain the difference between them.
> > 
> 
> The difference is simple. You put stuff into /sbin when you do not
> want regular users to be able to select it via tab completion by
> default.

Now put that definition into my cold logic brain.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Opinion against /usr merge

[Michał Górny]

On Tue, 17 Jul 2012 17:20:13 -0400
Richard Yao  wrote:

> An often cited benefit of the /usr merge is the ability to put
> everything but /etc on NFS and for that reason, we need to force an
> initramfs on people happily using /usr without it.

Are you going to send a single mail for every single benefit I will add
to the wiki? :>

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature