[gentoo-user] Optional /usr merge in Gentoo

[gentoo-user] Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

Hi!

I wrote a script that allows /usr merge in Gentoo without changes to
ebuilds.

I described it in an article
http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/

Are there any volunteers to test it? I use it on my computers for two
months.

Alessio Ababilov
Senior Software Engineer
Grid Dynamics

[-- Attachment #2: Type: text/html, Size: 529 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[东方巽雷]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

more information?


2013/8/13 Alessio Ababilov <ilovegnulinux@gmail.com>

> Hi!
>
> I wrote a script that allows /usr merge in Gentoo without changes to
> ebuilds.
>
> I described it in an article
> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
>
> Are there any volunteers to test it? I use it on my computers for two
> months.
>
> Alessio Ababilov
> Senior Software Engineer
> Grid Dynamics
>

[-- Attachment #2: Type: text/html, Size: 983 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

"/usr merge" is the process of making /bin, /sbin, and /lib to be symlinks
to corresponding directories in /usr. It is done in Fedora and several
other distros now, and also in Solaris 15 years ago.
Benefits from /usr merge are described here:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
Technical details are here:
http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/

In few words, the script is run once to merge /usr on a running system.
Also, the script is installed in post_src_install hook to perform /usr
merge during package updates or installations.

2013/8/13 东方巽雷 <dongfangxunlei@gmail.com>

> more information?
>
>
> 2013/8/13 Alessio Ababilov <ilovegnulinux@gmail.com>
>
>> Hi!
>>
>> I wrote a script that allows /usr merge in Gentoo without changes to
>> ebuilds.
>>
>> I described it in an article
>> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
>>
>> Are there any volunteers to test it? I use it on my computers for two
>> months.
>>
>> Alessio Ababilov
>> Senior Software Engineer
>> Grid Dynamics
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2648 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[pk]

On 2013-08-13 16:05, Alessio Ababilov wrote:
> "/usr merge" is the process of making /bin, /sbin, and /lib to be symlinks
> to corresponding directories in /usr. It is done in Fedora and several
> other distros now, and also in Solaris 15 years ago.
> Benefits from /usr merge are described here:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> Technical details are here:
> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
> 
> In few words, the script is run once to merge /usr on a running system.
> Also, the script is installed in post_src_install hook to perform /usr
> merge during package updates or installations.

So, how would this work for me who have /usr on a separate harddrive?
And what would be the benefit? To me, mentioning Fedora, makes the alarm
bells go off...

Best regards

Peter K

Re: [gentoo-user] Optional /usr merge in Gentoo

[the]

On 08/13/13 18:05, Alessio Ababilov wrote:
> "/usr merge" is the process of making /bin, /sbin, and /lib to be
> symlinks to corresponding directories in /usr. It is done in Fedora and
> several other distros now, and also in Solaris 15 years ago.
> Benefits from /usr merge are described here:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> Technical details are here:
> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
>
> In few words, the script is run once to merge /usr on a running system.
> Also, the script is installed in post_src_install hook to perform /usr
> merge during package updates or installations.

The site doesn't describe any real problems.

Also I don't see how the current dir tree is not compatible
with gnu autoconf/automake.

-- 
Stop talking and start compiling.
Linux user #557897

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

2013/8/13 the <the.guard@mail.ru>

> The site doesn't describe any real problems.
>
Well, it is a question to discuss.
I am not going to begin a holy war, I would like just to provide a
possibility to perform a harmless /usr merge for those who share
FreeDesktop's opinion.

>
> Also I don't see how the current dir tree is not compatible
> with gnu autoconf/automake.
>
In a simple way: please look at coreutils-8.20.ebuild that has to move a
lot of binaries from /usr/bin to /bin:

                cd "${D}"/usr/bin
                dodir /bin
                # move critical binaries into /bin (required by FHS)
                local fhs="cat chgrp chmod chown cp date dd df echo false
ln ls
                           mkdir mknod mv pwd rm rmdir stty sync true uname"
                mv ${fhs} ../../bin/ || die "could not move fhs bins"

2013/8/13 pk <peterk2@coolmail.se>

> So, how would this work for me who have /usr on a separate harddrive?
>
If you have an initrd, it will work.
Anyway, I just look for people that are interested in /usr merge.

And what would be the benefit? To me, mentioning Fedora, makes the alarm
> bells go off...
>
Yes. it does. Fedora is a big distro sponsored by Red Hat and its /usr
merge will be in RHEL-7. That's not a great idea to fight against upstream
if it will do /usr merge. Remember, /bin/mail now is moved to /usr/bin/mail
- what will be the next?

Sincerely,
Alessio Ababilov
Senior Software Engineer
Grid Dynamics

[-- Attachment #2: Type: text/html, Size: 3227 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/13/2013 01:08 PM, Alessio Ababilov wrote:
> 
> 2013/8/13 the <the.guard@mail.ru <mailto:the.guard@mail.ru>>
> 
>     The site doesn't describe any real problems.
> 
> Well, it is a question to discuss.
> I am not going to begin a holy war, I would like just to provide a
> possibility to perform a harmless /usr merge for those who share
> FreeDesktop's opinion.
> 
> 
>     Also I don't see how the current dir tree is not compatible
>     with gnu autoconf/automake. 
> 
> In a simple way: please look at coreutils-8.20.ebuild that has to move a
> lot of binaries from /usr/bin to /bin:
> 
>                 cd "${D}"/usr/bin
>                 dodir /bin
>                 # move critical binaries into /bin (required by FHS)
>                 local fhs="cat chgrp chmod chown cp date dd df echo
> false ln ls
>                            mkdir mknod mv pwd rm rmdir stty sync true uname"
>                 mv ${fhs} ../../bin/ || die "could not move fhs bins"
> 
> 2013/8/13 pk <peterk2@coolmail.se <mailto:peterk2@coolmail.se>>
> 
>     So, how would this work for me who have /usr on a separate harddrive?
> 
> If you have an initrd, it will work.
> Anyway, I just look for people that are interested in /usr merge.
> 
>     And what would be the benefit? To me, mentioning Fedora, makes the alarm
>     bells go off...
> 
> Yes. it does. Fedora is a big distro sponsored by Red Hat and its /usr
> merge will be in RHEL-7. That's not a great idea to fight against
> upstream if it will do /usr merge. Remember, /bin/mail now is moved to
> /usr/bin/mail - what will be the next?
> 
> Sincerely,
> Alessio Ababilov
> Senior Software Engineer
> Grid Dynamics
Red Hat is only upstream for GNOME and systemd. What they choose to do
with their distro should not affect the choices of any other distro. I
see no reason for a /usr merge unless one is using Fedora or wants to
turn their Gentoo installation into a makeshift Fedora installation.
This merge should not be forced on Gentoo whatsoever.

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

2013/8/13 Canek Peláez Valdés <caneko@gmail.com>

> I think it's a great experiment, but perhaps too much work for little
> gain, at least currently.
>
> Thank you!

> The next council meeting will vote if separated /usr without and
> initramfs is officially supported by Gentoo; I hope this time around
> finally is officially and unequivocally stated by the council that a
> separated /usr without an initramfs is *NOT* supported.
>
As I see from
http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the
council has stated that it is not supported anymore.

The usr-merge will be a slow, gradual change; it will probably take
> years. The systemd package entered the tree in June 2011, after more
> than a year in an overlay, and then it took more than two years to
> make it an official alternative to OpenRC. The /usr merge will take a
> similar amount of time, if not longer.
>
> Yes, but systemd is a large important package and it requires changes to
startup files in other packages, so, it took a lot of time.

As the opposite, /usr merge is easier and, IMHO, it doesn't introduce any
_obvious_ problems to Gentoo.

2013/8/16 Daniel Campbell <lists@sporkbox.us>

>
> Red Hat is only upstream for GNOME and systemd. What they choose to do
> with their distro should not affect the choices of any other distro. I
> see no reason for a /usr merge unless one is using Fedora or wants to
> turn their Gentoo installation into a makeshift Fedora installation.
> This merge should not be forced on Gentoo whatsoever.
>
>
I would like to ask you to understand my intension. I believe that Gentoo
is a distro that is famous for providing choises (USE flags and so on).
/usr merge is also a choise, and I look for volunteers and supporters.
BTW, /usr merge is not just a Fedora's caprice: is is done in Arch this
year:
https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html


Sincerely,
Alessio Ababilov
Senior Software Engineer
Grid Dynamics

[-- Attachment #2: Type: text/html, Size: 3634 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-16 8:29 AM, Alessio Ababilov <ilovegnulinux@gmail.com> wrote:
> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com <mailto:caneko@gmail.com>>
>
>     I think it's a great experiment, but perhaps too much work for little
>     gain, at least currently.
>
> Thank you!
>
>     The next council meeting will vote if separated /usr without and
>     initramfs is officially supported by Gentoo; I hope this time around
>     finally is officially and unequivocally stated by the council that a
>     separated /usr without an initramfs is *NOT* supported.
>
> As I see from
> http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the
> council has stated that it is not supported anymore.

<sigh>

Great. So what does this mean for those of us with older systems with 
separate /usr and don't want initramfs?

Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Fri, Aug 16, 2013 at 7:35 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-08-16 8:29 AM, Alessio Ababilov <ilovegnulinux@gmail.com> wrote:
>>
>> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com <mailto:caneko@gmail.com>>
>>
>>
>>     I think it's a great experiment, but perhaps too much work for little
>>     gain, at least currently.
>>
>> Thank you!
>>
>>     The next council meeting will vote if separated /usr without and
>>     initramfs is officially supported by Gentoo; I hope this time around
>>     finally is officially and unequivocally stated by the council that a
>>     separated /usr without an initramfs is *NOT* supported.
>>
>> As I see from
>> http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the
>> council has stated that it is not supported anymore.
>
>
> <sigh>
>
> Great. So what does this mean for those of us with older systems with
> separate /usr and don't want initramfs?

It means exactly what the Council voted:

"Since that particular setup may already be subtly broken today
depending on the installed software, Council recommends using an early
boot mount mechanism, e.g. initramfs, to mount /usr if /usr is on a
separate partition."

If you don't want an initramfs, you are on your own. Things will start
to break subtly (probably they *are* broken *now*, you just didn't
noticed), and if you file bugs about it they will be closed as WONTFIX
or INVALID.

If you want your system to be supported, you need an initarmfs, or
anything similar that allows the system to mount /usr really early in
the boot process.

https://wiki.gentoo.org/wiki/Early_Userspace_Mounting

http://www.gentoo.org/doc/en/initramfs-guide.xml

By a quick lecture of the Council session, I believe they are even
open to a closer /usr merge than I thought. When that happens (if it
happens), your system (if you keep upgrading) will not be able to boot
for sure if you don't follow the Council suggestion.

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

How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

So, in order to fix a system I'd rather not reinstall from scratch...

Is this possible? Easy? Recommended?

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Fri, Aug 16, 2013 at 9:35 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> So, in order to fix a system I'd rather not reinstall from scratch...
>
> Is this possible? Easy? Recommended?

If you have physical access to the system, and a large enough /, it's
really easy. You boot from a livecd, mount /usr in another directory,
copy all the files from it to /usr (be sure to preserve links,
permissions, attributes, etc.), change /etc/fstab, and off you go.

If you need to resize / then it's a little more difficult, but not so
much. You need again to boot with a livecd, and somewhere (a external
or internal disk with enough free space) to put the contents of / and
/usr while repartitioning an reformatting the drive that contains
them. Afterwards you just change /etc/fstab and you are good to go.

If it's a remote system then it gets hairy; any changes to how /usr is
handled should not be done while the system is running.

And really, maybe you could try an initramfs? It will be much more
easy than any juggle of filesystems.

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

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

Thanks for the reply Canek

On 2013-08-16 10:48 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> If you have physical access to the system,

I do.

> and a large enough /,

Well...

/ is 19GB, with 18GB available.

/usr is 20GB, with 13GB used, with 7.9GB available.

I guess I'd be ok with going from 18GB available on / to just 5GB 
available...

> it's really easy. You boot from a livecd, mount /usr in another
> directory,

Not exactly sure how to do this since /user in on lvm...

> copy all the files from it to /usr (be sure to preserve
> links, permissions, attributes, etc.),

So, once I have it mounted

cp -rp ... ?

> change /etc/fstab, and off you go.

Currently:

> # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
> /dev/sda1               /boot           ext2            noauto,noatime  1 2
> /dev/sda2               none            swap            sw              0 0
> /dev/sda3               /               ext3            noatime         0 1
> /dev/sda4               /backups        ext3            noatime         0 2
> /dev/vg2/home           /home           reiserfs        noatime         0 0
> /dev/vg2/usr            /usr            reiserfs        noatime         0 0
> /dev/vg2/var            /var            reiserfs        noatime         0 0
> /dev/cdroms/cdrom0      /mnt/cdrom      iso9660         noauto,ro       0 0
> /dev/fd0                /mnt/floppy     auto            noauto          0 0
>
> # NOTE: The next line is critical for boot!
> none                    /proc           proc            defaults        0 0

So, just remove the line referencing /usr?

> And really, maybe you could try an initramfs? It will be much more
> easy than any juggle of filesystems.

I always compile my kernels manually, by choice - so, no desire to use 
genkernel or dracut.

How would I then create one? I am *not* a programmer, just a reasonably 
competent general sys admin.

Is there a 'generic' one that I can use? Or is there a separate tool 
that will create one based on my system profile (or whatever)?

Thanks again

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 16/08/2013 17:04, Tanstaafl wrote:
> Thanks for the reply Canek
> 
> On 2013-08-16 10:48 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> If you have physical access to the system,
> 
> I do.
> 
>> and a large enough /,
> 
> Well...
> 
> / is 19GB, with 18GB available.
> 
> /usr is 20GB, with 13GB used, with 7.9GB available.
> 
> I guess I'd be ok with going from 18GB available on / to just 5GB
> available...

You should be fine with that. A reasonably sane / is quite static, and
/usr tends not to change all *that* much.

There's some precautions I always take on server:

/var, /usr/local, /opt and /tmp are separate mount points
portage moves to /var, not /usr

With those dealt with, the balance of / shouldn't grow much.


> 
>> it's really easy. You boot from a livecd, mount /usr in another
>> directory,
> 
> Not exactly sure how to do this since /user in on lvm...
> 
>> copy all the files from it to /usr (be sure to preserve
>> links, permissions, attributes, etc.),
> 
> So, once I have it mounted
> 
> cp -rp ... ?
> 
>> change /etc/fstab, and off you go.
> 
> Currently:
> 
>> # NOTE: If your BOOT partition is ReiserFS, add the notail option to
>> opts.
>> /dev/sda1               /boot           ext2           
>> noauto,noatime  1 2
>> /dev/sda2               none            swap           
>> sw              0 0
>> /dev/sda3               /               ext3           
>> noatime         0 1
>> /dev/sda4               /backups        ext3           
>> noatime         0 2
>> /dev/vg2/home           /home           reiserfs       
>> noatime         0 0
>> /dev/vg2/usr            /usr            reiserfs       
>> noatime         0 0
>> /dev/vg2/var            /var            reiserfs       
>> noatime         0 0
>> /dev/cdroms/cdrom0      /mnt/cdrom      iso9660        
>> noauto,ro       0 0
>> /dev/fd0                /mnt/floppy     auto           
>> noauto          0 0
>>
>> # NOTE: The next line is critical for boot!
>> none                    /proc           proc           
>> defaults        0 0
> 
> So, just remove the line referencing /usr?
> 
>> And really, maybe you could try an initramfs? It will be much more
>> easy than any juggle of filesystems.
> 
> I always compile my kernels manually, by choice - so, no desire to use
> genkernel or dracut.
> 
> How would I then create one? I am *not* a programmer, just a reasonably
> competent general sys admin.
> 
> Is there a 'generic' one that I can use? Or is there a separate tool
> that will create one based on my system profile (or whatever)?

NAFC. I'm like you and don't built initramfses. The only ones I have are
ones that RH shipped :-)




> 
> Thanks again
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Fri, Aug 16, 2013 at 10:04 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> Thanks for the reply Canek
>
>
> On 2013-08-16 10:48 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> If you have physical access to the system,
>
>
> I do.
>
>
>> and a large enough /,
>
>
> Well...
>
> / is 19GB, with 18GB available.
>
> /usr is 20GB, with 13GB used, with 7.9GB available.
>
> I guess I'd be ok with going from 18GB available on / to just 5GB
> available...
>
>
>> it's really easy. You boot from a livecd, mount /usr in another
>> directory,
>
>
> Not exactly sure how to do this since /user in on lvm...

If the Gentoo minimal install CD doesn't allow you to mount /usr in
LVM, for sure SystemRescueCD will:

http://www.sysresccd.org/SystemRescueCd_Homepage

>
>> copy all the files from it to /usr (be sure to preserve
>> links, permissions, attributes, etc.),
>
>
> So, once I have it mounted
>
> cp -rp ... ?

I would use rsync:

rsync -PvasHAX /oldusr/ /usr/

>
>> change /etc/fstab, and off you go.
>
>
> Currently:
>
>> # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
>> /dev/sda1               /boot           ext2            noauto,noatime  1
>> 2
>> /dev/sda2               none            swap            sw              0
>> 0
>> /dev/sda3               /               ext3            noatime         0
>> 1
>> /dev/sda4               /backups        ext3            noatime         0
>> 2
>> /dev/vg2/home           /home           reiserfs        noatime         0
>> 0
>> /dev/vg2/usr            /usr            reiserfs        noatime         0
>> 0
>> /dev/vg2/var            /var            reiserfs        noatime         0
>> 0
>> /dev/cdroms/cdrom0      /mnt/cdrom      iso9660         noauto,ro       0
>> 0
>> /dev/fd0                /mnt/floppy     auto            noauto          0
>> 0
>>
>> # NOTE: The next line is critical for boot!
>> none                    /proc           proc            defaults        0
>> 0
>
>
> So, just remove the line referencing /usr?

Yeah, basically.

>> And really, maybe you could try an initramfs? It will be much more
>> easy than any juggle of filesystems.
>
>
> I always compile my kernels manually, by choice - so, no desire to use
> genkernel or dracut.

I compile my kernels manually too. Since ever. Dracut generates an
initramfs from your running system, is orthogonal to compiling your
own kernel.

> How would I then create one? I am *not* a programmer, just a reasonably
> competent general sys admin.
>
> Is there a 'generic' one that I can use? Or is there a separate tool that
> will create one based on my system profile (or whatever)?

Yeah, dracut. Emerge dracut with LVM support, adding "lvm" to
DRACUT_MODULES in /etc/portage/make.conf, then edit /etc/dracut.conf,
and add lvmconf="yes", and run dracut like this (for example):

/usr/bin/dracut -f -H  /boot/initrd-3.10.7 3.10.7

Then you add an initrd line to GRUB, or GRUB2 will automatically
detect the initrd with grub2-mkconfig.

You should at least try it before changing partitions; is so much
easier. If it fails, you can still do the integration of /usr  and /.

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

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Paul Hartman]

On Fri, Aug 16, 2013 at 10:04 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> And really, maybe you could try an initramfs? It will be much more
>> easy than any juggle of filesystems.
>
>
> I always compile my kernels manually, by choice - so, no desire to use
> genkernel or dracut.
>
> How would I then create one? I am *not* a programmer, just a reasonably
> competent general sys admin.
>
> Is there a 'generic' one that I can use? Or is there a separate tool that
> will create one based on my system profile (or whatever)?

I think dracut is actually exactly the tool you are looking for. It
does not have anything to do with building your kernel, its sole job
in life is to generate an initramfs built to your specifications. It
contains sane defaults but you can tweak it to include or exclude
things as you see fit. I build my kernel by hand and then run dracut
afterward to generate the initramfs.img.

I believe mounting /usr is enabled by default in dracut. I would
recommend checking out the documentation and seeing all the different
options and modules that are available so you can customize it to
match your needs. For example you may want to have it import your LVM
configuration, assemble a RAID, use the reiserfs or btrfs filesystem,
etc.

Once it generates the initramfs it's as simple as adding a line to
your grub config and off you go. If it doesn't work right away you can
just comment out that line and boot without it, for now, while your
existing setup is still valid. (It took me a few reboots to find the
right combination of options.) Then someday if separate /usr is no
longer allowed without an initramfs, you'll be prepared for it.

I always regenerate my initramfs using dracut after every time i build
a new kernel, but I'm not sure if that's truly necessary. Honestly
it's all still a bit of a black box to me.

Re: How hard is it to move separate /usr to / partition? - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Fri, 16 Aug 2013 11:04:35 -0400, Tanstaafl wrote:

> > And really, maybe you could try an initramfs? It will be much more
> > easy than any juggle of filesystems.  
> 
> I always compile my kernels manually, by choice - so, no desire to use 
> genkernel or dracut.
> 
> How would I then create one? I am *not* a programmer, just a reasonably 
> competent general sys admin.

Read the initramfs page on the Gentoo wiki and 
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt

The kernel will build the initramfs for you, all you need to provide is
the init script and a list of files to include.


-- 
Neil Bothwick

Secret hacker rule #11: hackers read manuals.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Fri, Aug 16, 2013 at 7:29 AM, Alessio Ababilov
<ilovegnulinux@gmail.com> wrote:
> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com>
>>
>> I think it's a great experiment, but perhaps too much work for little
>> gain, at least currently.
>>
> Thank you!
>>
>> The next council meeting will vote if separated /usr without and
>> initramfs is officially supported by Gentoo; I hope this time around
>> finally is officially and unequivocally stated by the council that a
>> separated /usr without an initramfs is *NOT* supported.
>
> As I see from
> http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the council
> has stated that it is not supported anymore.

Well, better late than never. It was about time.

>> The usr-merge will be a slow, gradual change; it will probably take
>> years. The systemd package entered the tree in June 2011, after more
>> than a year in an overlay, and then it took more than two years to
>> make it an official alternative to OpenRC. The /usr merge will take a
>> similar amount of time, if not longer.
>>
> Yes, but systemd is a large important package and it requires changes to
> startup files in other packages, so, it took a lot of time.
>
> As the opposite, /usr merge is easier and, IMHO, it doesn't introduce any
> _obvious_ problems to Gentoo.

Perhaps; please understand that I'm 100% behind the /usr merge. But
even if it's easier than the introduction of virtual/service-manager,
it's still true that in Gentoo flag days kinda don't work. The /usr
merge will happen as more and more programs move naturally from / to
/usr.

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

Re: [gentoo-user] Optional /usr merge in Gentoo

[Dan Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 1423 bytes --]

On 16.08.2013 15:57, Canek Peláez Valdés wrote:
> On Fri, Aug 16, 2013 at 7:29 AM, Alessio Ababilov
> <ilovegnulinux@gmail.com> wrote:
>> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com>
>>>
>>> I think it's a great experiment, but perhaps too much work for little
>>> gain, at least currently.
>>>
>> Thank you!
>>>
>>> The next council meeting will vote if separated /usr without and
>>> initramfs is officially supported by Gentoo; I hope this time around
>>> finally is officially and unequivocally stated by the council that a
>>> separated /usr without an initramfs is *NOT* supported.
>>
>> As I see from
>> http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the council
>> has stated that it is not supported anymore.
> 
> Well, better late than never. It was about time.
> 
>>> The usr-merge will be a slow, gradual change; it will probably take
>>> years. The systemd package entered the tree in June 2011, after more
>>> than a year in an overlay, and then it took more than two years to
>>> make it an official alternative to OpenRC. The /usr merge will take a
>>> similar amount of time, if not longer.
>>>

And when we are at it, why not rename '/' to 'C:\' ?

-- 
Dan Johansson, <http://www.dmj.nu>
***************************************************
This message is printed on 100% recycled electrons!
***************************************************

[-- Attachment #1.2: 0x2FB894AD.asc --]
[-- Type: application/pgp-keys, Size: 3477 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Sat, Aug 17, 2013 at 2:49 PM, Dan Johansson <Dan.Johansson@dmj.nu> wrote:
> On 16.08.2013 15:57, Canek Peláez Valdés wrote:
>> On Fri, Aug 16, 2013 at 7:29 AM, Alessio Ababilov
>> <ilovegnulinux@gmail.com> wrote:
>>> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com>
>>>>
>>>> I think it's a great experiment, but perhaps too much work for little
>>>> gain, at least currently.
>>>>
>>> Thank you!
>>>>
>>>> The next council meeting will vote if separated /usr without and
>>>> initramfs is officially supported by Gentoo; I hope this time around
>>>> finally is officially and unequivocally stated by the council that a
>>>> separated /usr without an initramfs is *NOT* supported.
>>>
>>> As I see from
>>> http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt, the council
>>> has stated that it is not supported anymore.
>>
>> Well, better late than never. It was about time.
>>
>>>> The usr-merge will be a slow, gradual change; it will probably take
>>>> years. The systemd package entered the tree in June 2011, after more
>>>> than a year in an overlay, and then it took more than two years to
>>>> make it an official alternative to OpenRC. The /usr merge will take a
>>>> similar amount of time, if not longer.
>>>>
>
> And when we are at it, why not rename '/' to 'C:\' ?

Good one!!!!! :)

I guess this merge happening only because systemd...

Now the council expects people to:

1. maintain initramfs, it can be complex or simple task, depend on the
configuration.

2. place all disk and filesystem recovery utilities within initramfs.

3. or... prepare to use rescue cd every time something is broken.

Unclear why exactly we do have support in separate /usr.

Regards,
Alon

Re: [gentoo-user] Optional /usr merge in Gentoo

[Stroller]

On 17 August 2013, at 12:49, Dan Johansson wrote:
> ...
>>>> The usr-merge will be a slow, gradual change; it will probably take
>>>> years. The systemd package entered the tree in June 2011, after more
>>>> than a year in an overlay, and then it took more than two years to
>>>> make it an official alternative to OpenRC. The /usr merge will take a
>>>> similar amount of time, if not longer.
>>>> 
> 
> And when we are at it, why not rename '/' to 'C:\' ?

Well, seriously, why not?

You haven't made any arguments against putting everything on a single partition, just made a cheap "lolz, micro$oft windoze" analogy.

I can understand wanting to put /home on a separate partition or /var/spool/mail or /var/www/sites but I don't understand this obsession with several different partitions for system files which are always going to be managed by portage and which I'm never going to move or mess with manually.

Having /usr on a separate partition dates back to an era in which 10MB and 40MB harddisks were prohibitively expensive - they cost $1000s.

Now we can host a complete Gentoo system on a $5 or $10 SDcard, I'm struggling to see the value.

Stroller.

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 18/08/2013 08:40, Stroller wrote:
> 
> On 17 August 2013, at 12:49, Dan Johansson wrote:
>> ...
>>>>> The usr-merge will be a slow, gradual change; it will probably take
>>>>> years. The systemd package entered the tree in June 2011, after more
>>>>> than a year in an overlay, and then it took more than two years to
>>>>> make it an official alternative to OpenRC. The /usr merge will take a
>>>>> similar amount of time, if not longer.
>>>>>
>>
>> And when we are at it, why not rename '/' to 'C:\' ?
> 
> Well, seriously, why not?
> 
> You haven't made any arguments against putting everything on a single partition, just made a cheap "lolz, micro$oft windoze" analogy.
> 
> I can understand wanting to put /home on a separate partition or /var/spool/mail or /var/www/sites but I don't understand this obsession with several different partitions for system files which are always going to be managed by portage and which I'm never going to move or mess with manually.
> 
> Having /usr on a separate partition dates back to an era in which 10MB and 40MB harddisks were prohibitively expensive - they cost $1000s.
> 
> Now we can host a complete Gentoo system on a $5 or $10 SDcard, I'm struggling to see the value.

I agree.

You've read that post to an embedded list that lays out clearly why this
/usr thing happened, right? I see computer files falling in two large
categories - the system and data. Portage manages the system, I only
need to ensure there's enough space. The data is mine and I may well
have very different needs for different parts - the fs settings for the
portage tree definitely don't work well for my media store with 4G
BluRay rips!

While we're on the topic, what's the obsession with having different
bits of the file hierarchy as different *mount points*? That harks back
to the days when the only way to have a chunk of fs space be different
was to have it as a separate physical thing and mount it. Nowadays we
have something better - ZFS. To me this makes so much more sense. I have
a large amount of storage called a pool, and set size limits and
characteristics for various directories without having to deal with
fixed size volumes.

There's LVM of course which makes things far easier than not having LVM,
but by $DEITY, it forces me to think of my storage in terms of 4
distinctly different layers = far too complex (even though the clever
design appeals to my inner nerd).

I can think of only one modern use case where a separate /usr is
desirable - as a read-only NFS mount for terminal servers. But that is
already a large complex setup, very stable and not changing much,
usually with an admin, so a boot environment with an initramfs shouldn't
be any real burden at all.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-18 5:16 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> While we're on the topic, what's the obsession with having different
> bits of the file hierarchy as different*mount points*? That harks back
> to the days when the only way to have a chunk of fs space be different
> was to have it as a separate physical thing and mount it. Nowadays we
> have something better - ZFS. To me this makes so much more sense. I have
> a large amount of storage called a pool, and set size limits and
> characteristics for various directories without having to deal with
> fixed size volumes.

Eh? *Who* has ZFS? Certainly not the linux kernel.

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 18/08/2013 21:38, Tanstaafl wrote:
> On 2013-08-18 5:16 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> While we're on the topic, what's the obsession with having different
>> bits of the file hierarchy as different*mount points*? That harks back
>> to the days when the only way to have a chunk of fs space be different
>> was to have it as a separate physical thing and mount it. Nowadays we
>> have something better - ZFS. To me this makes so much more sense. I have
>> a large amount of storage called a pool, and set size limits and
>> characteristics for various directories without having to deal with
>> fixed size volumes.
> 
> Eh? *Who* has ZFS? Certainly not the linux kernel.
> 

FreeBSD

You can get ZFS on Linux with relative ease, you just have to build it
yourself. Distros feel they can't redistribute that code.



The bit you quoted shouldn't be read to mean that we have ZFS, it works
on Linux and everyone should activate it and use it and chuck ext* out
the window.

I meant that we've been chugging along since 1982 or so with ancient
disk concepts that come mostly from MS_DOS and limited by that hardware
of that day.

And here we are in 2013 *still* fiddling with partition tables, fixed
file systems, fixed mountpoints and we still bang our heads weekly
because sda3 has proven to be too small, and it's a *huge* mission to
change it. Yes, LVM has made this sooooo much easier (kudos to Sistina
for that) but I believe the entire approach is wrong.

The ZFS approach is better - here's the storage, now do with it what I
want but don't employ arbitrary fixed limits and structures to do it.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

On Aug 26, 2013 5:06 AM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On 18/08/2013 21:38, Tanstaafl wrote:
> > On 2013-08-18 5:16 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >> While we're on the topic, what's the obsession with having different
> >> bits of the file hierarchy as different*mount points*? That harks back
> >> to the days when the only way to have a chunk of fs space be different
> >> was to have it as a separate physical thing and mount it. Nowadays we
> >> have something better - ZFS. To me this makes so much more sense. I
have
> >> a large amount of storage called a pool, and set size limits and
> >> characteristics for various directories without having to deal with
> >> fixed size volumes.
> >
> > Eh? *Who* has ZFS? Certainly not the linux kernel.
> >
>
> FreeBSD
>
> You can get ZFS on Linux with relative ease, you just have to build it
> yourself. Distros feel they can't redistribute that code.
>
>
>
> The bit you quoted shouldn't be read to mean that we have ZFS, it works
> on Linux and everyone should activate it and use it and chuck ext* out
> the window.
>
> I meant that we've been chugging along since 1982 or so with ancient
> disk concepts that come mostly from MS_DOS and limited by that hardware
> of that day.
>
> And here we are in 2013 *still* fiddling with partition tables, fixed
> file systems, fixed mountpoints and we still bang our heads weekly
> because sda3 has proven to be too small, and it's a *huge* mission to
> change it. Yes, LVM has made this sooooo much easier (kudos to Sistina
> for that) but I believe the entire approach is wrong.
>
> The ZFS approach is better - here's the storage, now do with it what I
> want but don't employ arbitrary fixed limits and structures to do it.
>

+1 on ZFS. It's honestly a truly *modern* filesystem.

Been using it as the storage back-end of my company's email server.

The zpool and zfs command may need some time to be familiar with, but the
self-mounting self-sharing ability of zfs (i.e., no need to muck with fstab
and exports files) is really sweet.

I really leveraged its ability to do what I call "delta snapshot shipping"
(i.e., send only the differences between two snapshots to another place).
It's almost like an asynchronous DRBD, but with the added peace of mind
that if the files become corrupted (due to buggy app, almost no way for ZFS
to let corrupt data exist), I can easily 'roll back' to the time where the
files are still uncorrupted.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 3164 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 26/08/2013 08:10, Pandu Poluan wrote:
>> The ZFS approach is better - here's the storage, now do with it what I
>> want but don't employ arbitrary fixed limits and structures to do it.
>>
> 
> +1 on ZFS. It's honestly a truly *modern* filesystem.
> 
> Been using it as the storage back-end of my company's email server.
> 
> The zpool and zfs command may need some time to be familiar with, but
> the self-mounting self-sharing ability of zfs (i.e., no need to muck
> with fstab and exports files) is really sweet.
> 
> I really leveraged its ability to do what I call "delta snapshot
> shipping" (i.e., send only the differences between two snapshots to
> another place). It's almost like an asynchronous DRBD, but with the
> added peace of mind that if the files become corrupted (due to buggy
> app, almost no way for ZFS to let corrupt data exist), I can easily
> 'roll back' to the time where the files are still uncorrupted.
> 


I run it on my NASes, and the thing that really sold me was what it lets
me as the admin do:

I get all the benefits of directories with none of the downsides.
I get all the benefits of mount points with none of the downsides.
I get all the benefits of discrete filesystems with none of the downsides.

Like you say, a truly modern fs built for modern needs.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-26 2:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> I run it on my NASes, and the thing that really sold me was what it lets
> me as the admin do:
>
> I get all the benefits of directories with none of the downsides.
> I get all the benefits of mount points with none of the downsides.
> I get all the benefits of discrete filesystems with none of the downsides.
>
> Like you say, a truly modern fs built for modern needs.

Are these home-built NAS's running FreeBSD (or maybe FreeNAS)? Or 
TrueNAS or Nexenta boxes?

I'm wondering what the best way would be to get something set up for ZFS 
file storage. I have some older servers that I can use, so was leaning 
toward FreeNAS...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 13:36, Tanstaafl wrote:
> On 2013-08-26 2:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> I run it on my NASes, and the thing that really sold me was what it lets
>> me as the admin do:
>>
>> I get all the benefits of directories with none of the downsides.
>> I get all the benefits of mount points with none of the downsides.
>> I get all the benefits of discrete filesystems with none of the
>> downsides.
>>
>> Like you say, a truly modern fs built for modern needs.
> 
> Are these home-built NAS's running FreeBSD (or maybe FreeNAS)? Or
> TrueNAS or Nexenta boxes?
> 
> I'm wondering what the best way would be to get something set up for ZFS
> file storage. I have some older servers that I can use, so was leaning
> toward FreeNAS...
> 

Mine are HP mini-servers (the cube shaped ones) with 4 SATA bays running
FreeNAS 8.0.something.

Dunno if you've worked with FreeNAS before, but it's literally a case of
write the image to USB or flash storage and boot off it. Then play.

You will need to be able to boot off a USB stick, CF card or similar,
FreeNAS uses an entire drive for it's system partition and it's a shame
to waste a whole high-capacity disk just for a 2G system image



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-27 7:42 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 27/08/2013 13:36, Tanstaafl wrote:
>> I'm wondering what the best way would be to get something set up for ZFS
>> file storage. I have some older servers that I can use, so was leaning
>> toward FreeNAS...

> Mine are HP mini-servers (the cube shaped ones) with 4 SATA bays running
> FreeNAS 8.0.something.
>
> Dunno if you've worked with FreeNAS before, but it's literally a case of
> write the image to USB or flash storage and boot off it. Then play.
>
> You will need to be able to boot off a USB stick, CF card or similar,
> FreeNAS uses an entire drive for it's system partition and it's a shame
> to waste a whole high-capacity disk just for a 2G system image

I haven't worked with it before, but this comment of yours means I soon 
will be - thanks... :)

So, once I have something up and running and fully configured, it is 
relatively easy to backup the new/running system image, in case the 
flash drive ever crashes and burns?

Thanks Alan, starting to get excited about playing with ZFS.

How would you rate their docs and support community (for the free version)?

Thanks again Alan

Charles

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 14:05, Tanstaafl wrote:
> On 2013-08-27 7:42 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On 27/08/2013 13:36, Tanstaafl wrote:
>>> I'm wondering what the best way would be to get something set up for ZFS
>>> file storage. I have some older servers that I can use, so was leaning
>>> toward FreeNAS...
> 
>> Mine are HP mini-servers (the cube shaped ones) with 4 SATA bays running
>> FreeNAS 8.0.something.
>>
>> Dunno if you've worked with FreeNAS before, but it's literally a case of
>> write the image to USB or flash storage and boot off it. Then play.
>>
>> You will need to be able to boot off a USB stick, CF card or similar,
>> FreeNAS uses an entire drive for it's system partition and it's a shame
>> to waste a whole high-capacity disk just for a 2G system image
> 
> I haven't worked with it before, but this comment of yours means I soon
> will be - thanks... :)
> 
> So, once I have something up and running and fully configured, it is
> relatively easy to backup the new/running system image, in case the
> flash drive ever crashes and burns?

It's a small image (<100M compressed), so just keep a copy handy
somewhere and reflash. The GUI has a function where you can backup the
running config, a restore is a simple matter of click restore in the GUI

The USBstick/CF card you boot off will keep a copy of the current image
and one version back (i.e. the one the current one replaced), so you can
boot the old system by pressing F2 if the new one fails for some weird
reason.

Most of the config is GUI-driven in a browser, a lot but not all options
can be set on the CLI. But honestly, it's a file server and you will
find that once you set your shares up the way you like you will seldom
change stuff. Your main interaction will probably be watching the pretty
connectd graphs in a browser

For shares you get everything you could possibly need - cifs, nfs (2,3
and 4), iSCSI, FTP, scp, some Apple thing, and tftp and a few more. And
rsync!

> Thanks Alan, starting to get excited about playing with ZFS.
> 
> How would you rate their docs and support community (for the free version)?

Support is top-notch, on par with what you find around here if that
helps ;-)

Each major.minor version has a .pdf manual published, while the next
version is in development, the docs get updated on a wiki and the final
version is an export of that. There's a forum with knowledgeable users
and the devs hang around just in case regular users can't help with a
question.

No mailing list though :-(
And the forum does have a lot of noise from n00bs, but that's common
with web forums. Like on Gentoo, you quickly learn to spot those posts
and scan over them.

> 
> Thanks again Alan
> 
> Charles
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-27 9:03 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Each major.minor version has a .pdf manual published, while the next
> version is in development, the docs get updated on a wiki and the final
> version is an export of that. There's a forum with knowledgeable users
> and the devs hang around just in case regular users can't help with a
> question.

Ok, that brings up another issue...

One thing I've always loved about gentoo is it is a rolling release, 
which means no 'major update' pains to speak of (at least not like 
binary based distros like redhat etc)...

So, have you ever gone through any major system updates, and if so, any 
issues to speak of?

Thanks again for sharing this...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 15:11, Tanstaafl wrote:
> On 2013-08-27 9:03 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> Each major.minor version has a .pdf manual published, while the next
>> version is in development, the docs get updated on a wiki and the final
>> version is an export of that. There's a forum with knowledgeable users
>> and the devs hang around just in case regular users can't help with a
>> question.
> 
> Ok, that brings up another issue...
> 
> One thing I've always loved about gentoo is it is a rolling release,
> which means no 'major update' pains to speak of (at least not like
> binary based distros like redhat etc)...
> 
> So, have you ever gone through any major system updates, and if so, any
> issues to speak of?
> 
> Thanks again for sharing this...
> 


No issues ever whatsoever. An upgrade is almost exactly the same as
upgrading firmware on your DSL router or reflashing OpenElec[1]. The
longest part is waiting for the NAS to reboot twice and get through
whatever your disk controller does at power up :-)

Once in the early days I had an incompatible database format for configs
and got a message at the start, so I had to do something manually to get
past that. But that was long ago. These days the migration script always
just dealt with it properly.


[1] another awesome project that JustWorks. I'm getting to like these
Unix-based appliances that JustWork. if I need to get under the overs
and tweak stuff, I can. Most mostly I don't need to :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-27 9:03 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> It's a small image (<100M compressed), so just keep a copy handy
> somewhere and reflash. The GUI has a function where you can backup the
> running config, a restore is a simple matter of click restore in the GUI
>
> The USBstick/CF card you boot off will keep a copy of the current image
> and one version back (i.e. the one the current one replaced), so you can
> boot the old system by pressing F2 if the new one fails for some weird
> reason.

Crazy question...

Wondering of I could run this in a VM on my ESXi server?

Purpose would be threefold...

hosting windows user homes and roaming profiles

hosting alternate email storage for dovecot (for mail archival)

hosting email backups (rsync)

hmm.... maybe I could even make it primary mail storage?

Have to give this some thought...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 17:55, Tanstaafl wrote:
> On 2013-08-27 9:03 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> It's a small image (<100M compressed), so just keep a copy handy
>> somewhere and reflash. The GUI has a function where you can backup the
>> running config, a restore is a simple matter of click restore in the GUI
>>
>> The USBstick/CF card you boot off will keep a copy of the current image
>> and one version back (i.e. the one the current one replaced), so you can
>> boot the old system by pressing F2 if the new one fails for some weird
>> reason.
> 
> Crazy question...
> 
> Wondering of I could run this in a VM on my ESXi server?
> 
> Purpose would be threefold...
> 
> hosting windows user homes and roaming profiles
> 
> hosting alternate email storage for dovecot (for mail archival)
> 
> hosting email backups (rsync)
> 
> hmm.... maybe I could even make it primary mail storage?
> 
> Have to give this some thought...
> 


Many people do just that (for testing and evaluation). ESXi lets you
present an image file as a boot device so that's sorted.

As always with VMs, IO performance is pretty sucky if you present
file-based storage to the guest. It's OK to evaluate and learn the
commands with, but for production you really want direct access to
proper storage devices. Just make sure your backend storage is NOT
itself doing RAID - ZFS doesn't play nicely with that. It really wants a
JBOD with no firmware interference.




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Pandu Poluan]

On Tue, Aug 27, 2013 at 8:03 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> On 27/08/2013 14:05, Tanstaafl wrote:

[-- snippy --]

> > Thanks Alan, starting to get excited about playing with ZFS.
> >
> > How would you rate their docs and support community (for the free version)?
>
> Support is top-notch, on par with what you find around here if that
> helps ;-)
>
> Each major.minor version has a .pdf manual published, while the next
> version is in development, the docs get updated on a wiki and the final
> version is an export of that. There's a forum with knowledgeable users
> and the devs hang around just in case regular users can't help with a
> question.
>
> No mailing list though :-(
> And the forum does have a lot of noise from n00bs, but that's common
> with web forums. Like on Gentoo, you quickly learn to spot those posts
> and scan over them.
>

Actually, there *is* a mailing list. I happened upon it accidentally
several minutes ago.

Two of them in fact.

https://groups.google.com/a/zfsonlinux.org/forum/#!forum/zfs-discuss

... and if you want to partake in development of ZFS-on-Linux:

https://groups.google.com/a/zfsonlinux.org/forum/#!forum/zfs-devel


(I've just subscribed to the first list)


Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Optional /usr merge in Gentoo

[joost]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>On 27/08/2013 13:36, Tanstaafl wrote:
>> On 2013-08-26 2:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> I run it on my NASes, and the thing that really sold me was what it
>lets
>>> me as the admin do:
>>>
>>> I get all the benefits of directories with none of the downsides.
>>> I get all the benefits of mount points with none of the downsides.
>>> I get all the benefits of discrete filesystems with none of the
>>> downsides.
>>>
>>> Like you say, a truly modern fs built for modern needs.
>> 
>> Are these home-built NAS's running FreeBSD (or maybe FreeNAS)? Or
>> TrueNAS or Nexenta boxes?
>> 
>> I'm wondering what the best way would be to get something set up for
>ZFS
>> file storage. I have some older servers that I can use, so was
>leaning
>> toward FreeNAS...
>> 
>
>Mine are HP mini-servers (the cube shaped ones) with 4 SATA bays
>running
>FreeNAS 8.0.something.
>
>Dunno if you've worked with FreeNAS before, but it's literally a case
>of
>write the image to USB or flash storage and boot off it. Then play.
>
>You will need to be able to boot off a USB stick, CF card or similar,
>FreeNAS uses an entire drive for it's system partition and it's a shame
>to waste a whole high-capacity disk just for a 2G system image
>
>
>
>-- 
>Alan McKinnon
>alan.mckinnon@gmail.com

Alan.

How is the security settings on the shares now?

I had issues when accessing through NFS and CIFS simultaneously where files written over NFS had to have the permissions altered before they were accessible over CIFS.

Other issue I had was inability to have users only being able to access files they were allowed to. With CIFS it sort of worked. But with NFS I had full access to all files.

That is the reason why I setup my NAS manually using Gentoo.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2498 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 21:24, joost@antarean.org wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>     On 27/08/2013 13:36, Tanstaafl wrote:
> 
>         On 2013-08-26 2:23 AM, Alan McKinnon <alan.mckinnon@gmail.com>
>         wrote:
> 
>             I run it on my NASes, and the thing that really sold me was
>             what it lets
>             me as the admin do:
> 
>             I get all the benefits of directories with none of the
>             downsides.
>             I get all the benefits of mount points with none of the
>             downsides.
>             I get all the benefits of discrete filesystems with none of the
>             downsides.
> 
>             Like you say, a truly modern fs built for modern needs.
> 
> 
>         Are these home-built NAS's running FreeBSD (or maybe FreeNAS)? Or
>         TrueNAS or Nexenta boxes?
> 
>         I'm wondering what the best way would be to get something set up
>         for ZFS
>         file storage. I have some older servers that I can use, so was
>         leaning
>         toward FreeNAS...
> 
> 
> 
>     Mine are HP mini-servers (the cube shaped ones) with 4 SATA bays running
>     FreeNAS 8.0.something.
> 
>     Dunno if you've worked with FreeNAS before, but it's literally a case of
>     write the image to USB or flash storage and boot off it. Then play.
> 
>     You will need to be able to boot off a USB stick, CF card or similar,
>     FreeNAS uses an entire drive for it's system partition and it's a shame
>     to waste a whole high-capacity disk just for a 2G system image
> 
> 
> 
> Alan.
> 
> How is the security settings on the shares now?
> 
> I had issues when accessing through NFS and CIFS simultaneously where
> files written over NFS had to have the permissions altered before they
> were accessible over CIFS.

I've never run into this situation myself, my shares are either accessed
via cfs or via nfs, but never both at the same time.

The permissions issue is an artifact of how NFS works. Sun designed it
to deliver entire filesystems over the network (most often /usr and-or
/home) to trusted clients. "trusted" being the operative word. To get
Unix permissions to work, the uid on the share and client have to match
- that's why we also have NIS - but I've never seen NIS actually used
anywhere, so UIDs tend to be a mix 'n match and almost always devolves
into "full access" to get it to work.

CIFS work different, it auths users by username and supports per-field
access control. That's how that protocol works.

There is no known way to fix NFS v2 & v3 in a mixed network and still
stay sane. NFS v4 does a good job but it's not NFS v3 :-)

it's common for NAS vendors to recommend you not try share the same
files over CIFS and NFS, especially if write access is involced.



> 
> Other issue I had was inability to have users only being able to access
> files they were allowed to. With CIFS it sort of worked. But with NFS I
> had full access to all files.
> 
> That is the reason why I setup my NAS manually using Gentoo.
> 
> --
> Joost
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> The permissions issue is an artifact of how NFS works. Sun designed it
> to deliver entire filesystems over the network (most often /usr and-or
> /home) to trusted clients. "trusted" being the operative word. To get
> Unix permissions to work, the uid on the share and client have to match
> - that's why we also have NIS - but I've never seen NIS actually used
> anywhere, so UIDs tend to be a mix 'n match and almost always devolves
> into "full access" to get it to work.

This is how NFS was designed before 1987, when Kerberos came up....
>
> CIFS work different, it auths users by username and supports per-field
> access control. That's how that protocol works.

This is how NFSv4 works.

BTW: as long as Linux does not support modern ACLs (originally defined by NTFS, 
now standardized by NFSv4) Linux will not be able to take advantage from CIFS 
ACLs.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Mon, 26 Aug 2013 00:02:17 +0200, Alan McKinnon wrote:

> > Eh? *Who* has ZFS? Certainly not the linux kernel.
> >   
> 
> FreeBSD
> 
> You can get ZFS on Linux with relative ease, you just have to build it
> yourself. Distros feel they can't redistribute that code.

emerge zfs works too :)

I really liek the way ZFS just lets you get on with things.


-- 
Neil Bothwick

Help put the "fun" back in "dysfunctional" !

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 618 bytes --]

On Monday 26 Aug 2013 08:06:13 Neil Bothwick wrote:
> On Mon, 26 Aug 2013 00:02:17 +0200, Alan McKinnon wrote:
> > > Eh? *Who* has ZFS? Certainly not the linux kernel.
> > 
> > FreeBSD
> > 
> > You can get ZFS on Linux with relative ease, you just have to build it
> > yourself. Distros feel they can't redistribute that code.
> 
> emerge zfs works too :)
> 
> I really liek the way ZFS just lets you get on with things.

Does anyone run it on a desktop/laptop as their day to day fs?  Any drawbacks 
or gotchas?  Other than reliability, how does it perform compared say to ext4?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Mon, 26 Aug 2013 09:45:15 +0100, Mick wrote:

> > emerge zfs works too :)
> > 
> > I really like the way ZFS just lets you get on with things.  
> 
> Does anyone run it on a desktop/laptop as their day to day fs?

Yes.

> Any
> drawbacks or gotchas?  Other than reliability, how does it perform
> compared say to ext4?

I haven't benchmarked it. It feels as if it may be a little slower on my
desktop with spinning disks, but that may be down to other factors, like
impatience. It flies on my laptop's SSD.


-- 
Neil Bothwick

Why is bra singular and pants plural?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Mon, Aug 26, 2013 at 4:56 PM, Neil Bothwick <neil@digimed.co.uk> wrote:

> On Mon, 26 Aug 2013 09:45:15 +0100, Mick wrote:
>
> > > emerge zfs works too :)
> > >
> > > I really like the way ZFS just lets you get on with things.
> >
> > Does anyone run it on a desktop/laptop as their day to day fs?
>
> Yes.
>
> > Any
> > drawbacks or gotchas?  Other than reliability, how does it perform
> > compared say to ext4?
>
> I haven't benchmarked it. It feels as if it may be a little slower on my
> desktop with spinning disks, but that may be down to other factors, like
> impatience. It flies on my laptop's SSD.
>

Additional note:

*Of course* it will be slower than ext*, because during every read it
ensures that the block being read has a proper checksum.

Likewise on writes.

But that IMO is very worth it just for the additional peace-of-mind,
knowing you will never ever have a silent corruption.


-- 
FdS Pandu E Poluan
* ~ IT Optimizer ~**
*
 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[-- Attachment #2: Type: text/html, Size: 2647 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Stefan G. Weichinger]

Am 26.08.2013 10:45, schrieb Mick:

> Does anyone run it on a desktop/laptop as their day to day fs?  Any
> drawbacks or gotchas?  Other than reliability, how does it perform
> compared say to ext4?

Sorry for being shameless:

I once described a ZFS-based gentoo setup with encryption for the
german linux magazine. They translated it and it was published in
other parts of the world as well:

http://www.oops.co.at/en/publications/english-translation-of-zfs-article

I delivered a demo-VM as well but I don't run that setup on my
productive systems currently.

Stefan (not earning anything from those pdf-downloads, btw)

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Mon, 26 Aug 2013 14:06:11 +0200, Stefan G. Weichinger wrote:

> Sorry for being shameless:
> 
> I once described a ZFS-based gentoo setup with encryption for the
> german linux magazine. They translated it and it was published in
> other parts of the world as well:

That is pretty shameless. I would never be so blatant as to mention the
ZFS tutorial in the current issue (175) of Linux Format.


-- 
Neil Bothwick

Head: (n.) the part of a disk drive which detects sectors and decides
which of the two possible values to return: 'lose a turn' or 'bankrupt.'

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 26/08/2013 16:38, Neil Bothwick wrote:
> On Mon, 26 Aug 2013 14:06:11 +0200, Stefan G. Weichinger wrote:
> 
>> Sorry for being shameless:
>>
>> I once described a ZFS-based gentoo setup with encryption for the
>> german linux magazine. They translated it and it was published in
>> other parts of the world as well:
> 
> That is pretty shameless. I would never be so blatant as to mention the
> ZFS tutorial in the current issue (175) of Linux Format.
> 
> 


If you give me a free subscription for life, I promise I won't breath a
word of you never mentioning ZFS




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Stefan G. Weichinger]

Am 26.08.2013 16:38, schrieb Neil Bothwick:
> On Mon, 26 Aug 2013 14:06:11 +0200, Stefan G. Weichinger wrote:
> 
>> Sorry for being shameless:
>> 
>> I once described a ZFS-based gentoo setup with encryption for
>> the german linux magazine. They translated it and it was
>> published in other parts of the world as well:
> 
> That is pretty shameless. I would never be so blatant as to mention
> the ZFS tutorial in the current issue (175) of Linux Format.

;-)

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-25 6:02 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> You can get ZFS on Linux with relative ease, you just have to build it
> yourself. Distros feel they can't redistribute that code.

I know you can do this as a module - but is there an overlay or patch to 
get it built directly into the kernel? I'd love to use ZFS on my gentoo 
server, but I disable modules on servers for security reasons.

Thanks...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Mon, 26 Aug 2013 09:16:44 -0400, Tanstaafl wrote:

> > You can get ZFS on Linux with relative ease, you just have to build it
> > yourself. Distros feel they can't redistribute that code.  
> 
> I know you can do this as a module - but is there an overlay or patch
> to get it built directly into the kernel? I'd love to use ZFS on my
> gentoo server, but I disable modules on servers for security reasons.

You can do it. You have to unmask the kernel_builtin USE flag to stop zfs
bringing in zfs_kmod, then unpack the sources and run the script to
install them into the kernel tree.

I run this script after emerging a new kernel

==================================================

#!/bin/sh

[[ -f /usr/src/linux/.config ]] || zcat /proc/config.gz
>/usr/src/linux/.config

SPL_EBUILD=$(ls -1 /var/portage/sys-kernel/spl/spl-0* | tail -n 1)
ZFS_EBUILD=$(ls -1 /var/portage/sys-fs/zfs/zfs-0* | tail -n 1)

SPL_DIR=$(ebuild $SPL_EBUILD clean prepare | awk '/Preparing source in/
{print $5}') ZFS_DIR=$(ebuild $ZFS_EBUILD clean prepare | awk '/Preparing
source in/ {print $5}')

cd $SPL_DIR
./configure --enable-linux-builtin --with-linux=/usr/src/linux
./copy-builtin /usr/src/linux
      
cd $ZFS_DIR
./configure --enable-linux-builtin --with-linux=/usr/src/linux
--with-spl=$SPL_DIR ./copy-builtin /usr/src/linux

==================================================

Then run make oldconfig and compile as usual.


-- 
Neil Bothwick

Cross-country skiing is great in small countries.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-26 10:11 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 26 Aug 2013 09:16:44 -0400, Tanstaafl wrote:
>
>>> You can get ZFS on Linux with relative ease, you just have to build it
>>> yourself. Distros feel they can't redistribute that code.
>>
>> I know you can do this as a module - but is there an overlay or patch
>> to get it built directly into the kernel? I'd love to use ZFS on my
>> gentoo server, but I disable modules on servers for security reasons.
>
> You can do it. You have to unmask the kernel_builtin USE flag to stop zfs
> bringing in zfs_kmod, then unpack the sources and run the script to
> install them into the kernel tree.

<snip>

Very interesting, thanks... nice to know it can be done, but I wouldn't 
be uncomfortable doing that myself...

Would be nice if there was a kernel overlay for this...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Mon, 26 Aug 2013 12:36:30 -0400, Tanstaafl wrote:

> > You can do it. You have to unmask the kernel_builtin USE flag to stop
> > zfs bringing in zfs_kmod, then unpack the sources and run the script
> > to install them into the kernel tree.  
> 
> <snip>
> 
> Very interesting, thanks... nice to know it can be done, but I wouldn't 
> be uncomfortable doing that myself...
> 
> Would be nice if there was a kernel overlay for this...

The licensing conflict means that would not be possible. You have the
install the kernel source and then merge in the ZFS source yourself, it
can't be done for you and distributed.


-- 
Neil Bothwick

OPERATOR ERROR: Nyah, Nyah, Nyah, Nyah, Nyah!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Neil Bothwick <neil@digimed.co.uk> wrote:

> > Would be nice if there was a kernel overlay for this...
>
> The licensing conflict means that would not be possible. You have the
> install the kernel source and then merge in the ZFS source yourself, it
> can't be done for you and distributed.

Why do you believe this?

ZFS id doubtlessly an own "work" independent from the rest of the Linux kernel
and for this reason, adding ZFS just creates a collective work that is not 
affected by the GPL.

BTW: this was already explained in the GPL book from Till Jaeger et al. 
published in March 2005.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Mon, 26 Aug 2013 19:30:05 +0200, Joerg Schilling wrote:

> > The licensing conflict means that would not be possible. You have the
> > install the kernel source and then merge in the ZFS source yourself,
> > it can't be done for you and distributed.  
> 
> Why do you believe this?
> 
> ZFS id doubtlessly an own "work" independent from the rest of the Linux
> kernel and for this reason, adding ZFS just creates a collective work
> that is not affected by the GPL.

But the CCDL licence of ZFS precludes its being distributed with the
kernel. At least, that's how I understand it and the fact that no distro
distributes a ZFS-enabled kernel makes me believe it is true.


-- 
Neil Bothwick

Friends come and friends go, but enemies accumulate.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Neil Bothwick <neil@digimed.co.uk> wrote:

> On Mon, 26 Aug 2013 19:30:05 +0200, Joerg Schilling wrote:
>
> > > The licensing conflict means that would not be possible. You have the
> > > install the kernel source and then merge in the ZFS source yourself,
> > > it can't be done for you and distributed.  
> > 
> > Why do you believe this?
> > 
> > ZFS id doubtlessly an own "work" independent from the rest of the Linux
> > kernel and for this reason, adding ZFS just creates a collective work
> > that is not affected by the GPL.
>
> But the CCDL licence of ZFS precludes its being distributed with the
> kernel. At least, that's how I understand it and the fact that no distro
> distributes a ZFS-enabled kernel makes me believe it is true.

Did you ever read the CDDL?

People who believe that there is a problem use a wrong interpretation of the 
GPL. The CDDL definitely does not prevent combinations with other software.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Mon, 26 Aug 2013 23:37:02 +0200, Joerg Schilling wrote:

> > But the CCDL licence of ZFS precludes its being distributed with the
> > kernel. At least, that's how I understand it and the fact that no
> > distro distributes a ZFS-enabled kernel makes me believe it is true.  
> 
> Did you ever read the CDDL?

Not completely.

> People who believe that there is a problem use a wrong interpretation
> of the GPL. The CDDL definitely does not prevent combinations with
> other software.

I didn't say the CDDL prevented this. I'm not blaming one of the other
licence, but they are considered to be incompatible. I realise you
believe otherwise, and you could well be correct, but those who distribute
the software either believe otherwise or feel there is enough doubt to be
cautious. If in doubt, don't.

I wish your interpretation was correct, but the prevailing option is
otherwise.


-- 
Neil Bothwick

Will we ever get out of this airport? asked Tom interminably.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Neil Bothwick <neil@digimed.co.uk> wrote:

> > Did you ever read the CDDL?
>
> Not completely.

You should do it - it is even much shorter then GPLv3


> > People who believe that there is a problem use a wrong interpretation
> > of the GPL. The CDDL definitely does not prevent combinations with
> > other software.
>
> I didn't say the CDDL prevented this. I'm not blaming one of the other
> licence, but they are considered to be incompatible. I realise you
> believe otherwise, and you could well be correct, but those who distribute
> the software either believe otherwise or feel there is enough doubt to be
> cautious. If in doubt, don't.

There are several entities that frequently publish such unproven claims.
This sounds like marketing using the cause fear uncertaintly and doubt method.
You should not trust such entities that do not prove their claims.

> I wish your interpretation was correct, but the prevailing option is
> otherwise.

It is not my interpretation, this is the interpretation of all lawyers in the 
net that are willing to explain the background of their decisions.

This interpretation is based on two basic facts:

-	The CDDL was designed for best compatibilitiy with all licenses.

-	The parts of the GPL that are claimed to prevent this license
	combination are in conflict with the law and thus void.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 26/08/2013 23:37, Joerg Schilling wrote:
> Neil Bothwick <neil@digimed.co.uk> wrote:
> 
>> On Mon, 26 Aug 2013 19:30:05 +0200, Joerg Schilling wrote:
>>
>>>> The licensing conflict means that would not be possible. You have the
>>>> install the kernel source and then merge in the ZFS source yourself,
>>>> it can't be done for you and distributed.  
>>>
>>> Why do you believe this?
>>>
>>> ZFS id doubtlessly an own "work" independent from the rest of the Linux
>>> kernel and for this reason, adding ZFS just creates a collective work
>>> that is not affected by the GPL.
>>
>> But the CCDL licence of ZFS precludes its being distributed with the
>> kernel. At least, that's how I understand it and the fact that no distro
>> distributes a ZFS-enabled kernel makes me believe it is true.
> 
> Did you ever read the CDDL?
> 
> People who believe that there is a problem use a wrong interpretation of the 
> GPL. The CDDL definitely does not prevent combinations with other software.

The problem is not with CDDL, the problem is with the GPL.

ZFS in the kernel requires that ZFS as shipped be relicensed as GPL, it
forms a derivative work of the kernel. No external license can change
the terms of the GPL.

Admittedly this gets murky due to XFS.

But the clincher would appear to be that Oracle own ZFS and also
distribute a branded RedHat derivative distro. To the best of my
knowledge Oracle themselves do not ship a ZFS-enabled kernel. Surely, as
the owners of the code and with a large dev team, Oracle themselves
could solve this issue by doing just that? But they haven't done so.

Especially as ZFS is production-ready today whereas the competing btrfs
is not.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> > People who believe that there is a problem use a wrong interpretation of the 
> > GPL. The CDDL definitely does not prevent combinations with other software.
>
> The problem is not with CDDL, the problem is with the GPL.
>
> ZFS in the kernel requires that ZFS as shipped be relicensed as GPL, it
> forms a derivative work of the kernel. No external license can change
> the terms of the GPL.

The law can!

The GPL is in conflict with the law and therefore the parts you have in mind 
are just void.

BTW: I am still waiting for a legally acceptable explanation on why the GPL
should be compatible to the BSD license. Note that the BSD license is very 
liberal, but it definitely does not permit to relicense code that was published
under the BSD license withour written permission of the Copyright holder.

So is the problem just a social problem given the fact that Linux comes with 
BSD licensed parts?

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 09:59, Joerg Schilling wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>>> People who believe that there is a problem use a wrong interpretation of the 
>>> GPL. The CDDL definitely does not prevent combinations with other software.
>>
>> The problem is not with CDDL, the problem is with the GPL.
>>
>> ZFS in the kernel requires that ZFS as shipped be relicensed as GPL, it
>> forms a derivative work of the kernel. No external license can change
>> the terms of the GPL.
> 
> The law can!
> 
> The GPL is in conflict with the law and therefore the parts you have in mind 
> are just void.

Which law is the GPL in conflict with, and in which jurisdiction, and
what is the extent of the conflict?

To the best of my knowledge, what you claim has not been tested in a
court of law with jurisdiction, and is not a matter of law. Until that
happens, it is an untested legal opinion and as we know, opinions can vary.

The kernel devs have their position, you have yours. In this case, the
opinion of the kernel devs is the one that carries as they control what
does and does not ship.


> 
> BTW: I am still waiting for a legally acceptable explanation on why the GPL
> should be compatible to the BSD license. Note that the BSD license is very 
> liberal, but it definitely does not permit to relicense code that was published
> under the BSD license withour written permission of the Copyright holder.

There is no requirement that the GPL should be compatible with the BSD
license. The GPL only requires that derivative works comply with the
terms of the GPL.

If BSD code is shipped with GPL code and the BSD code is the derivative
work, the BSD license does not demand that the code be published.
However, the GPL does so the entire codebase is published under the
terms of the GPL. Thus the conditions of both licenses are satisfied,
and no relicensing is involved.

> 
> So is the problem just a social problem given the fact that Linux comes with 
> BSD licensed parts?

I don't follow your reasoning here. How does the BSD license affect CDDL
code in this case?


> 
> Jörg
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> > The law can!
> > 
> > The GPL is in conflict with the law and therefore the parts you have in mind 
> > are just void.
>
> Which law is the GPL in conflict with, and in which jurisdiction, and
> what is the extent of the conflict?

The GPL is in conflict with US Copyright law Section 17 Paragraph 106.
In Europe, the law on business conditions apply and allow the licensee to 
chose his best interpretation in case of 

> To the best of my knowledge, what you claim has not been tested in a
> court of law with jurisdiction, and is not a matter of law. Until that
> happens, it is an untested legal opinion and as we know, opinions can vary.

There is no need to test something so obvious in court.
A license is not allowed to redefine the definition of what a derivative work 
is and the problem with the GPL only exists in case the GPL succeeds to redefine
the lawful definition of a drivative work.

> The kernel devs have their position, you have yours. In this case, the
> opinion of the kernel devs is the one that carries as they control what
> does and does not ship.

While I am quoting the papers from lawyers (Determann, Rosen, Gordon)
you are quoting laymen.

Note that Lothar Determan is professor of law at Freie Univerität Berlin _and_
the university of San Francisco.

>
> > 
> > BTW: I am still waiting for a legally acceptable explanation on why the GPL
> > should be compatible to the BSD license. Note that the BSD license is very 
> > liberal, but it definitely does not permit to relicense code that was published
> > under the BSD license withour written permission of the Copyright holder.
>
> There is no requirement that the GPL should be compatible with the BSD
> license. The GPL only requires that derivative works comply with the
> terms of the GPL.

The GPL requires to relicense the whole work under the GPL and this is not 
permitted for code under the BSD license.


> If BSD code is shipped with GPL code and the BSD code is the derivative
> work, the BSD license does not demand that the code be published.
> However, the GPL does so the entire codebase is published under the
> terms of the GPL. Thus the conditions of both licenses are satisfied,
> and no relicensing is involved.

If the Linux kernel uses the BSD code, it is the Linux kernel that has become 
the derivative work.

Note that you cannot publishe the entire codebase under GPL as parts are under 
BSD license already.

> > So is the problem just a social problem given the fact that Linux comes with 
> > BSD licensed parts?
>
> I don't follow your reasoning here. How does the BSD license affect CDDL
> code in this case?

It demonstrates that the Linux kernel people do not really honor the GPL and I 
see no difference between adding code under BSD compared to code under CDDL.
Both licenses do not allow relicensing without written permission of the 
Copyright owner.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[gentoo-user] Re: Optional /usr merge in Gentoo

[walt]

On 08/27/2013 12:59 AM, Joerg Schilling wrote:

> The GPL is in conflict with the law

Joerg, which law are you talking about?  I've never understood the problems
surrounding the many and various available software licenses, and I don't
think I ever will understand them.  But I'm still trying :)

[gentoo-user] Re: Optional /usr merge in Gentoo

[walt]

On 08/30/2013 04:05 PM, walt wrote:
> On 08/27/2013 12:59 AM, Joerg Schilling wrote:
> 
>> The GPL is in conflict with the law
> 
> Joerg, which law are you talking about?

Oops, I see you've already answered my question.  Please ignore.

Re: [gentoo-user] Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/16/2013 07:29 AM, Alessio Ababilov wrote:
> 2013/8/13 Canek Peláez Valdés <caneko@gmail.com <mailto:caneko@gmail.com>>
> 
>     I think it's a great experiment, but perhaps too much work for little
>     gain, at least currently.
> 
> Thank you! 
> 
>     The next council meeting will vote if separated /usr without and
>     initramfs is officially supported by Gentoo; I hope this time around
>     finally is officially and unequivocally stated by the council that a
>     separated /usr without an initramfs is *NOT* supported.
> 
> As I see
> from http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt,
> the council has stated that it is not supported anymore.
> 
>     The usr-merge will be a slow, gradual change; it will probably take
>     years. The systemd package entered the tree in June 2011, after more
>     than a year in an overlay, and then it took more than two years to
>     make it an official alternative to OpenRC. The /usr merge will take a
>     similar amount of time, if not longer.
> 
> Yes, but systemd is a large important package and it requires changes to
> startup files in other packages, so, it took a lot of time.
> 
> As the opposite, /usr merge is easier and, IMHO, it doesn't introduce
> any _obvious_ problems to Gentoo.
> 
> 2013/8/16 Daniel Campbell <lists@sporkbox.us <mailto:lists@sporkbox.us>>
> 
> 
>     Red Hat is only upstream for GNOME and systemd. What they choose to do
>     with their distro should not affect the choices of any other distro. I
>     see no reason for a /usr merge unless one is using Fedora or wants to
>     turn their Gentoo installation into a makeshift Fedora installation.
>     This merge should not be forced on Gentoo whatsoever.
> 
> 
> I would like to ask you to understand my intension. I believe that
> Gentoo is a distro that is famous for providing choises (USE flags and
> so on). /usr merge is also a choise, and I look for volunteers
> and supporters.
> BTW, /usr merge is not just a Fedora's caprice: is is done in Arch this
> year:
> https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html
> 
> 
> Sincerely,
> Alessio Ababilov
> Senior Software Engineer
> Grid Dynamics

I'm completely in favor of choice, but only if it doesn't impede on any
other choice(s). If /usr merges are completely optional and only tied to
software that require it (read: systemd), then I'm fine. But requiring
people to have an initramfs to boot a system that doesn't legitimately
require it is silly. I don't even have /usr mounted separately, but
there are many, many different system configurations out there and
Gentoo is famous for supporting a wide variety. That variety is stomped
on if something like a /usr merge is forced. It also makes building your
default environment more complicated due to generating an initramfs.

Arch is following Fedora as they consider them an upstream. They were
one of, if not *the* first non-Fedora distros to ship systemd by
default. They're a poor example. Really, Arch is just Fedora with a
better package manager.

~Daniel

Re: [gentoo-user] Optional /usr merge in Gentoo

[the.guard]

> But requiring
> people to have an initramfs to boot a system that doesn't legitimately
> require it is silly. I don't even have /usr mounted separately, but
> there are many, many different system configurations out there and
> Gentoo is famous for supporting a wide variety. That variety is stomped
> on if something like a /usr merge is forced. It also makes building your
> default environment more complicated due to generating an initramfs.

Absolutely agreed.

[gentoo-user] Re: Optional /usr merge in Gentoo

[Andreas Eder]

On 17 Aug 2013, the guard wrote:

> > But requiring people to have an initramfs to boot a system
> > that doesn't legitimately require it is silly. I don't even
> > have /usr mounted separately, but there are many, many
> > different system configurations out there and Gentoo is famous
> > for supporting a wide variety. That variety is stomped on if
> > something like a /usr merge is forced. It also makes building
> > your default environment more complicated due to generating an
> > initramfs.
> 
> Absolutely agreed.

Might be a good time to switch to freebsd :-(
-- 
ceterum censeo redmondinem esse delendam.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder <andreas_eder@gmx.net> wrote:
> On 17 Aug 2013, the guard wrote:
>
>> > But requiring people to have an initramfs to boot a system
>> > that doesn't legitimately require it is silly. I don't even
>> > have /usr mounted separately, but there are many, many
>> > different system configurations out there and Gentoo is famous
>> > for supporting a wide variety. That variety is stomped on if
>> > something like a /usr merge is forced. It also makes building
>> > your default environment more complicated due to generating an
>> > initramfs.
>>
>> Absolutely agreed.
>
> Might be a good time to switch to freebsd :-(

I agree. This is the only escape plan against the new wind of
dictation into monolithic approach that comes from systemd sponsors
direction.

Let's see how it turns out... if Linux userspace will become like the
Windows user space, then freebsd suddenly looks very promising
alternative.

Regards,
Alon

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[staticsafe]

On Sat, Aug 17, 2013 at 10:26:34PM +0300, Alon Bar-Lev wrote:
> On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder <andreas_eder@gmx.net> wrote:
> > On 17 Aug 2013, the guard wrote:
> >
> >> > But requiring people to have an initramfs to boot a system
> >> > that doesn't legitimately require it is silly. I don't even
> >> > have /usr mounted separately, but there are many, many
> >> > different system configurations out there and Gentoo is famous
> >> > for supporting a wide variety. That variety is stomped on if
> >> > something like a /usr merge is forced. It also makes building
> >> > your default environment more complicated due to generating an
> >> > initramfs.
> >>
> >> Absolutely agreed.
> >
> > Might be a good time to switch to freebsd :-(
> 
> I agree. This is the only escape plan against the new wind of
> dictation into monolithic approach that comes from systemd sponsors
> direction.
> 
> Let's see how it turns out... if Linux userspace will become like the
> Windows user space, then freebsd suddenly looks very promising
> alternative.
> 
> Regards,
> Alon
> 

Y'all are welcome to switch to Slackware. :)
-- 
staticsafe
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post.
iPlease don't CC! I'm subscribed to whatever list I just posted on.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Sat, Aug 17, 2013 at 10:31 PM, staticsafe <me@staticsafe.ca> wrote:
> On Sat, Aug 17, 2013 at 10:26:34PM +0300, Alon Bar-Lev wrote:
>> On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder <andreas_eder@gmx.net> wrote:
>> > On 17 Aug 2013, the guard wrote:
>> >
>> >> > But requiring people to have an initramfs to boot a system
>> >> > that doesn't legitimately require it is silly. I don't even
>> >> > have /usr mounted separately, but there are many, many
>> >> > different system configurations out there and Gentoo is famous
>> >> > for supporting a wide variety. That variety is stomped on if
>> >> > something like a /usr merge is forced. It also makes building
>> >> > your default environment more complicated due to generating an
>> >> > initramfs.
>> >>
>> >> Absolutely agreed.
>> >
>> > Might be a good time to switch to freebsd :-(
>>
>> I agree. This is the only escape plan against the new wind of
>> dictation into monolithic approach that comes from systemd sponsors
>> direction.
>>
>> Let's see how it turns out... if Linux userspace will become like the
>> Windows user space, then freebsd suddenly looks very promising
>> alternative.
>>
>> Regards,
>> Alon
>>
>
> Y'all are welcome to switch to Slackware. :)

At 2000-2006 this what I actually used. it was the most configurable
distribution, then switched to Gentoo because it was mature and even
more customizable, easier to extend, while Slackware was on halt for
years.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/17/2013 02:26 PM, Alon Bar-Lev wrote:
> On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder <andreas_eder@gmx.net> wrote:
>> On 17 Aug 2013, the guard wrote:
>>
>>>> But requiring people to have an initramfs to boot a system
>>>> that doesn't legitimately require it is silly. I don't even
>>>> have /usr mounted separately, but there are many, many
>>>> different system configurations out there and Gentoo is famous
>>>> for supporting a wide variety. That variety is stomped on if
>>>> something like a /usr merge is forced. It also makes building
>>>> your default environment more complicated due to generating an
>>>> initramfs.
>>>
>>> Absolutely agreed.
>>
>> Might be a good time to switch to freebsd :-(
> 
> I agree. This is the only escape plan against the new wind of
> dictation into monolithic approach that comes from systemd sponsors
> direction.
> 
> Let's see how it turns out... if Linux userspace will become like the
> Windows user space, then freebsd suddenly looks very promising
> alternative.
> 
> Regards,
> Alon
> 

I've considered this as well. It's simply beyond me why so many people
are willing to drink the kool-aid from a *single upstream* and let them
shape the entire GNU/Linux landscape. It's one thing to support an
*option*, but quite another to *force* users to use this option. Systemd
itself doesn't look to be forced yet, but if the requirements for it are
forced onto users, forcing systemd afterwards would be child's play. I
saw this in action when I used Arch. It started with bash functions in
their init scripts calling some systemd tools. Then the /usr merge.
Eventually systemd itself was pushed. I'm beginning to lose confidence
that Gentoo will avoid the same fate as Arch. Even Debian is falling to
the systemd crowd. If this keeps up, it's only a matter of time before
systemd infects every Linux-based distribution and BSD will be the only
major free OS to avoid it. Red Hat may end up digging its claws into the
kernel itself. What will protect the Linux landscape, if not distros
like Gentoo that supposedly support user choice? Will all users who give
a damn be forced to run LFS or Slackware if they wish to use Linux as
their kernel? Maintain their own portage|pacman|deb repos and keep
systems free of systemd? Where does the madness end?

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]

2013/8/18 Daniel Campbell <lists@sporkbox.us>

> On 08/17/2013 02:26 PM, Alon Bar-Lev wrote:
> > On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder <andreas_eder@gmx.net>
> wrote:
> >> On 17 Aug 2013, the guard wrote:
> >>
> >>>> But requiring people to have an initramfs to boot a system
> >>>> that doesn't legitimately require it is silly. I don't even
> >>>> have /usr mounted separately, but there are many, many
> >>>> different system configurations out there and Gentoo is famous
> >>>> for supporting a wide variety. That variety is stomped on if
> >>>> something like a /usr merge is forced. It also makes building
> >>>> your default environment more complicated due to generating an
> >>>> initramfs.
> >>>
> >>> Absolutely agreed.
> >>
> >> Might be a good time to switch to freebsd :-(
> >
> > I agree. This is the only escape plan against the new wind of
> > dictation into monolithic approach that comes from systemd sponsors
> > direction.
> >
> > Let's see how it turns out... if Linux userspace will become like the
> > Windows user space, then freebsd suddenly looks very promising
> > alternative.
> >
> > Regards,
> > Alon
> >
>
> I've considered this as well. It's simply beyond me why so many people
> are willing to drink the kool-aid from a *single upstream* and let them
> shape the entire GNU/Linux landscape. It's one thing to support an
> *option*, but quite another to *force* users to use this option. Systemd
> itself doesn't look to be forced yet, but if the requirements for it are
> forced onto users, forcing systemd afterwards would be child's play. I
> saw this in action when I used Arch. It started with bash functions in
> their init scripts calling some systemd tools. Then the /usr merge.
> Eventually systemd itself was pushed. I'm beginning to lose confidence
> that Gentoo will avoid the same fate as Arch. Even Debian is falling to
> the systemd crowd. If this keeps up, it's only a matter of time before
> systemd infects every Linux-based distribution and BSD will be the only
> major free OS to avoid it. Red Hat may end up digging its claws into the
> kernel itself. What will protect the Linux landscape, if not distros
> like Gentoo that supposedly support user choice? Will all users who give
> a damn be forced to run LFS or Slackware if they wish to use Linux as
> their kernel? Maintain their own portage|pacman|deb repos and keep
> systems free of systemd? Where does the madness end?
>
> systemd is devouring other daemons. udev was the first victim, and now
consolekit is dead and replaced with systemd-logind. Who knows what will be
the next?

Gentoo guys maintain now eudev. Ubuntu (which avoids systemd and uses its
own upstart) splits systemd into several parts and happily uses them. The
second way seems to be easier for me.

BTW, what are you arguments against systemd (except for /usr merge)?

Best regards,
Alessio Ababilov

[-- Attachment #2: Type: text/html, Size: 3872 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/18/2013 03:53 AM, Alessio Ababilov wrote:
> 
> 
> 
> 2013/8/18 Daniel Campbell <lists@sporkbox.us <mailto:lists@sporkbox.us>>
> 
>     On 08/17/2013 02:26 PM, Alon Bar-Lev wrote:
>     > On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder
>     <andreas_eder@gmx.net <mailto:andreas_eder@gmx.net>> wrote:
>     >> On 17 Aug 2013, the guard wrote:
>     >>
>     >>>> But requiring people to have an initramfs to boot a system
>     >>>> that doesn't legitimately require it is silly. I don't even
>     >>>> have /usr mounted separately, but there are many, many
>     >>>> different system configurations out there and Gentoo is famous
>     >>>> for supporting a wide variety. That variety is stomped on if
>     >>>> something like a /usr merge is forced. It also makes building
>     >>>> your default environment more complicated due to generating an
>     >>>> initramfs.
>     >>>
>     >>> Absolutely agreed.
>     >>
>     >> Might be a good time to switch to freebsd :-(
>     >
>     > I agree. This is the only escape plan against the new wind of
>     > dictation into monolithic approach that comes from systemd sponsors
>     > direction.
>     >
>     > Let's see how it turns out... if Linux userspace will become like the
>     > Windows user space, then freebsd suddenly looks very promising
>     > alternative.
>     >
>     > Regards,
>     > Alon
>     >
> 
>     I've considered this as well. It's simply beyond me why so many people
>     are willing to drink the kool-aid from a *single upstream* and let them
>     shape the entire GNU/Linux landscape. It's one thing to support an
>     *option*, but quite another to *force* users to use this option. Systemd
>     itself doesn't look to be forced yet, but if the requirements for it are
>     forced onto users, forcing systemd afterwards would be child's play. I
>     saw this in action when I used Arch. It started with bash functions in
>     their init scripts calling some systemd tools. Then the /usr merge.
>     Eventually systemd itself was pushed. I'm beginning to lose confidence
>     that Gentoo will avoid the same fate as Arch. Even Debian is falling to
>     the systemd crowd. If this keeps up, it's only a matter of time before
>     systemd infects every Linux-based distribution and BSD will be the only
>     major free OS to avoid it. Red Hat may end up digging its claws into the
>     kernel itself. What will protect the Linux landscape, if not distros
>     like Gentoo that supposedly support user choice? Will all users who give
>     a damn be forced to run LFS or Slackware if they wish to use Linux as
>     their kernel? Maintain their own portage|pacman|deb repos and keep
>     systems free of systemd? Where does the madness end?
> 
> systemd is devouring other daemons. udev was the first victim, and now
> consolekit is dead and replaced with systemd-logind. Who knows what will
> be the next?
> 
> Gentoo guys maintain now eudev. Ubuntu (which avoids systemd and uses
> its own upstart) splits systemd into several parts and happily uses
> them. The second way seems to be easier for me.
> 
> BTW, what are you arguments against systemd (except for /usr merge)?
> 
> Best regards,
> Alessio Ababilov

Systemd has a monolithic design, is headed by an egotist with no respect
for other developers, and cannibalizes other projects. The projects it
can't cannibalize will be strongarmed into irrelevance. Couple this with
Red Hat employees working on both systemd and GNOME, with a very clear
agenda to vertically integrate them, and you have a recipe for a closed
and/or heavily limited operating system. This is becoming clear with the
way GTK+ 3.x is handled, too.

I don't approve of an init system (or any other software) becoming
everything-and-the-kitchen-sink. UNIX philosophy is being forgotten by
these developers, and they openly condemn it while benefiting from it at
the same time. While the job of init could be argued as complex or
multifaceted, an init system can still "do one thing, and do it well":
Bring the system to an initial state. At the core, it means populate
sysfs (or an equivalent), start the specified daemons, load the relevant
modules, and standby until an event signals it to shutdown or restart.
No splash screens needed, no need to swallow a device management system,
no need to replace logging mechanisms, and so on.

Coupling systemd with udev was a political move, not a technical one. It
was a deliberate effort to force their software on the FOSS world, with
the false pretense of "standardization", which is a buzzword among
developers that's effective at garnering support. The sad part is people
bought it. They will regret this move.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-18 11:44, Daniel Campbell wrote:

> Systemd has a monolithic design, is headed by an egotist with no respect
> for other developers, and cannibalizes other projects. The projects it
> can't cannibalize will be strongarmed into irrelevance. Couple this with
> Red Hat employees working on both systemd and GNOME, with a very clear
> agenda to vertically integrate them, and you have a recipe for a closed
> and/or heavily limited operating system. This is becoming clear with the
> way GTK+ 3.x is handled, too.

Seems to me everything Gnome related is becoming the proverbial metric
ton gorilla (on steroids, in a china shop)... Systemd follows that
pattern. And Lennarts "track record" with avahi and pulseaudio does not
inspire confidence, imho... I'm sure, given time, systemd will pull in
Gnome as a building dependency... I joke of course, but then again
nothing really surprises me anymore when it comes to the above mentioned
projects...

The supposedly advantages that systemd[1] has over other init systems
are, supposedly:
1. To allow parallel boot of system services
2. cgroup integration
3. Re-start of services

In my opinion:
1. Most of the time spent when cold booting is spent in the BIOS/UEFI
cycle (around 30 seconds), the time from grub display to login (I'm
using "slim") is 5 seconds (max). Ergo, parallel boot will do nothing
for me. The parallel boot and the starting of services is also the thing
that "breaks" the separate /usr philosophy (without static binaries).
2. cgroup can be handled by OpenRC as well. Not that I see much
improvement, if any, over pre-cgroup kernels... So no advantage there
either, for me.
3. Re-start of services (a.k.a. daemons in the UNIX world). Why would
anyone want an automatic re-start of a daemon is beyond me. If a daemon
crashes/doesn't start properly then it will not work by automatic
re-start; I would like to believe that starting a daemon is not a
stochastic process... I, however, would like to be told that it doesn't
start so I can fix it. OpenRC does the latter well.

Systemd also replaces the following services[1]:
sysvinit, initscripts, pm-utils, inetd, acpid, syslog, watchdog,
cgrulesd, cron, atd

...which obviously makes the code more complex, which goes against the
KISS rule[2]. On a personal note, I like this quote best (from [2]):
"It seems that perfection is reached not when there is nothing left to
add, but when there is nothing left to take away"

For the record... size comparisons (from [3]):
OpenRC (0.9.3): sysvinit + 300 files, ~30k lines, 3.3k posix sh, ~12k C
(sysvinit: 560kB, 75 files, ~15k lines)

systemd (v44+): dbus + glib + 900 files, 224k lines, 125k C
(D-Bus: 11MB, ~500 files. 300k lines, 120k C)
(glib: 72MB, ~2500 files, ~1.7M lines, ~430k C)

Also, integrating the services into one tool (systemd) makes a more
fragile system (again, imho)...

> I don't approve of an init system (or any other software) becoming
> everything-and-the-kitchen-sink. UNIX philosophy is being forgotten by
> these developers, and they openly condemn it while benefiting from it at
> the same time. While the job of init could be argued as complex or
> multifaceted, an init system can still "do one thing, and do it well":
> Bring the system to an initial state. At the core, it means populate
> sysfs (or an equivalent), start the specified daemons, load the relevant
> modules, and standby until an event signals it to shutdown or restart.
> No splash screens needed, no need to swallow a device management system,
> no need to replace logging mechanisms, and so on.

From [4]:
"Those who don't understand Unix are condemned to reinvent it, poorly." :-)

> Coupling systemd with udev was a political move, not a technical one. It
> was a deliberate effort to force their software on the FOSS world, with
> the false pretense of "standardization", which is a buzzword among
> developers that's effective at garnering support. The sad part is people
> bought it. They will regret this move.

Standardization per se is not a bad thing, i.e. protocols, APIs etc.
(like POSIX)... I agree that Lennart and Kay motives are political
though. Also, Lennart says this ([5]):
"So, get yourself a copy of The Linux Programming Interface, ignore
everything it says about POSIX compatibility and hack away your amazing
Linux software. It's quite relieving!"

[1] https://en.wikipedia.org/wiki/Systemd
[2] https://en.wikipedia.org/wiki/Keep_It_Simple_Stupid
[3] http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
[4] https://en.wikipedia.org/wiki/Unix_philosophy
[5] https://archive.fosdem.org/2011/interview/lennart-poettering

At the end of the day I want the compute power in my computers/devices
not to spend *one* cycle unnecessarily and it is very hard for a
"kitchen-and-sink" system to do that, imho. I would very much like to
see a "LEGO" approach (i.e. small individual tools with well defined
interfaces that can work together) which imo is the UNIX philosophy.

Best regards

Peter K

Re: [gentoo-user] Optional /usr merge in Gentoo

[Stroller]

On 18 August 2013, at 15:16, pk wrote:
> ...
> 1. Most of the time spent when cold booting is spent in the BIOS/UEFI
> cycle (around 30 seconds), the time from grub display to login (I'm
> using "slim") is 5 seconds (max). 

Blimey! You must have a slow BIOS cycle.

I mean, maybe my servers take that long (I'm not sure, I boot them annually and don't watch them rebooting) but I have a little eMachines nettop here - the first time I tried to enter BIOS, it look me several attempts, it boots past that so quick!

I've now enabled the option to wait 5 seconds before loading the bootloader, but quickboot on this system is less than 2 seconds in BIOS cycle.

(OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). 

Stroller.

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 11:21, Stroller wrote:
> 
> On 18 August 2013, at 15:16, pk wrote:
>> ...
>> 1. Most of the time spent when cold booting is spent in the BIOS/UEFI
>> cycle (around 30 seconds), the time from grub display to login (I'm
>> using "slim") is 5 seconds (max). 
> 
> Blimey! You must have a slow BIOS cycle.
> 
> I mean, maybe my servers take that long (I'm not sure, I boot them annually and don't watch them rebooting) but I have a little eMachines nettop here - the first time I tried to enter BIOS, it look me several attempts, it boots past that so quick!
> 
> I've now enabled the option to wait 5 seconds before loading the bootloader, but quickboot on this system is less than 2 seconds in BIOS cycle.
> 
> (OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). 


What pk says is quite normal in my experience.

This laptop is a Dell Precision, from pressing enter on the grub screen
to kdm showing on the screen is 3 seconds, another 4 seconds for KDE to
appear and start responding to mouse clicks.

From power-on to the grub menu showing, that's about 30 seconds. The
first 8 or so is a ... blank screen ... then I get the Dell logo,
followed by another 20 seconds or so where is does $SOMETHING.

Server hardware is even worse - the R[357]* series can easily take 4
MINUTES to get through all the various BIOS thingies. Bi-monthly
maintenance reboots get scary, 4 minutes is a loooooooong time when
you're flying blind on a critical machine that's physically on the other
side of town :-)


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[pk]

On 2013-08-19 11:21, Stroller wrote:

> Blimey! You must have a slow BIOS cycle.

Yes, I bought the motherboard specifically for a slow BIOS cycle... ;-)
Joke aside, I have a SAS raid card in the machine which probes the
harddrives (four mechanical ones) which takes maybe half that time. I've
been toying with the idea of replacing BIOS/UEFI with coreboot/seabios
but time is lacking... :-(
For the record, I've always felt BIOS have been slow...

> (OTOH, going from grub to login in 5 seconds - that suggests to me that you're using an SSD and not a hard-drive). 

I recently bought 4 SSDs (Intel 520 60GB) and have them installed as
/usr, /var and /tmp with one spare. However / is still on the SAS raid
card and boot time has not improved by much with the SSD. It's matter of
what crap you load at boot that will affect your boot time.

Best regards

Peter K

Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Tue, Aug 13, 2013 at 4:08 AM, Alessio Ababilov
<ilovegnulinux@gmail.com> wrote:
> Hi!

Hi Alessio.

> I wrote a script that allows /usr merge in Gentoo without changes to
> ebuilds.
>
> I described it in an article
> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
>
> Are there any volunteers to test it? I use it on my computers for two
> months.

I think it's a great experiment, but perhaps too much work for little
gain, at least currently.

The next council meeting will vote if separated /usr without and
initramfs is officially supported by Gentoo; I hope this time around
finally is officially and unequivocally stated by the council that a
separated /usr without an initramfs is *NOT* supported.

When that is out of the way, several packages will start to naturally
move to /usr, since most upstreams are doing that, and eventually we
will have empty /bin, /sbin, and /lib directories. Then there will be
no need for a script to move everything to /usr; which is good: I
believe in Gentoo a flag-day doesn't really work.

The usr-merge will be a slow, gradual change; it will probably take
years. The systemd package entered the tree in June 2011, after more
than a year in an overlay, and then it took more than two years to
make it an official alternative to OpenRC. The /usr merge will take a
similar amount of time, if not longer.

But it's good to know that you can do the merge now; thanks for
sharing your experiment.

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

[gentoo-user] Re: Optional /usr merge in Gentoo

[Nikos Chantziaras]

On 13/08/13 21:32, Canek Peláez Valdés wrote:
> On Tue, Aug 13, 2013 at 4:08 AM, Alessio Ababilov
> <ilovegnulinux@gmail.com> wrote:
>> Hi!
>
> Hi Alessio.
>
>> I wrote a script that allows /usr merge in Gentoo without changes to
>> ebuilds.
>>
>> I described it in an article
>> http://aababilov.wordpress.com/2013/07/17/usr-merge-in-gentoo/
>>
>> Are there any volunteers to test it? I use it on my computers for two
>> months.
>
> I think it's a great experiment, but perhaps too much work for little
> gain, at least currently.

I tend to agree.  And I still wonder why it's called "/usr merge" if it 
only affects /bin and /sbin.  If it's really a merge, shouldn't /lib 
also be affected?

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alessio Ababilov]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

2013/8/18 Nikos Chantziaras <realnc@gmail.com>

> I tend to agree.  And I still wonder why it's called "/usr merge" if it
> only affects /bin and /sbin.  If it's really a merge, shouldn't /lib also
> be affected?
>
Sure, /lib is affected. This was the idea of FreeDesktop.org's article
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/,
and so does my script.

[-- Attachment #2: Type: text/html, Size: 905 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-18 4:40 AM, Alessio Ababilov <ilovegnulinux@gmail.com> wrote:
> Sure, /lib is affected. This was the idea of FreeDesktop.org's article
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/,
> and so does my script.

And so the /usr merge is part and parcel of systemd.

I'm not afraid that the gentoo council is drinking the kool-aid, it is 
as obvious as the nose on my face that they *are*, and as has been said, 
unless someone or more people return some sanity to the project, gentoo 
will be systemd only sooner rather than later.

Guess I need to start looking at FreeBSD too... :(

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1169 bytes --]

On Sunday 18 Aug 2013 20:37:19 Tanstaafl wrote:
> On 2013-08-18 4:40 AM, Alessio Ababilov <ilovegnulinux@gmail.com> wrote:
> > Sure, /lib is affected. This was the idea of FreeDesktop.org's article
> > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/,
> > and so does my script.
> 
> And so the /usr merge is part and parcel of systemd.
> 
> I'm not afraid that the gentoo council is drinking the kool-aid, it is
> as obvious as the nose on my face that they *are*, and as has been said,
> unless someone or more people return some sanity to the project, gentoo
> will be systemd only sooner rather than later.
> 
> Guess I need to start looking at FreeBSD too... :(

Having left Slackware for Gentoo more than 10 years ago this is going to feel 
like a regressive step for me, but if it comes to it I guess I will have to 
consider it.

I honestly cannot understand why we/Gentoo are allowing the RHL monolithic 
development philosophy to break what we have.  Is Poettering the only 
developer available to the Linux world?  Are RHL dictating what path Debian 
and its cousin distros should follow?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-18 23:08, Mick wrote:

> I honestly cannot understand why we/Gentoo are allowing the RHL
> monolithic development philosophy to break what we have.  Is
> Poettering the only developer available to the Linux world?  Are
> RHL dictating what path Debian and its cousin distros should
> follow?

Problem is that Linux is dependent on udev and udev is in the hands of
Kay Sievers which also develops systemd together with Lennart
Poettering which in turn used to be a Gnome developer... With that
said, what I cannot understand is why people advocating systemd (and
the kitchen-and-sink model) are using Gentoo in the first place. Are
they just trying to make the rest of the Linux distro landscape as
miserable as Fedora? Why don't they stay with Fedora instead of trying
to turn Gentoo into Fedora?

Best regards

Peter K

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

pk wrote:
> On 2013-08-18 23:08, Mick wrote:
>
>> I honestly cannot understand why we/Gentoo are allowing the RHL
>> monolithic development philosophy to break what we have.  Is
>> Poettering the only developer available to the Linux world?  Are
>> RHL dictating what path Debian and its cousin distros should
>> follow?
> Problem is that Linux is dependent on udev and udev is in the hands of
> Kay Sievers which also develops systemd together with Lennart
> Poettering which in turn used to be a Gnome developer... With that
> said, what I cannot understand is why people advocating systemd (and
> the kitchen-and-sink model) are using Gentoo in the first place. Are
> they just trying to make the rest of the Linux distro landscape as
> miserable as Fedora? Why don't they stay with Fedora instead of trying
> to turn Gentoo into Fedora?
>
> Best regards
>
> Peter K
>
>
>

Picking random message sort of.  Isn't eudev still going to support a
separate /usr?  That is my understanding.  If eudev is not then I may
have to reconsider some things myself here. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-19 00:49, Dale wrote:

> Picking random message sort of.  Isn't eudev still going to support a
> separate /usr?  That is my understanding.  If eudev is not then I may
> have to reconsider some things myself here. 

Yes, that is my understanding as well. But the "decision" to not support
a separate /usr lies higher up in the system hierarchy (as I understand
it). Gentoo as a system will not support a separate /usr if we are to
believe the conversation (I haven't seen any official notice of this
though). That is the sad part. The problem I have, as an engineer, is
that "everybody" says that a separate /usr is broken, that sysvinit is
broken without explaining why. In order to fix a problem you need to
know what is broken... The people who claims the brokenness are, imo,
hand waving and they've managed to convince higher uppers in the Gentoo
infrastructure (as it seems). I guess if you repeat something often
enough it becomes a "truth" or said person(s) just agrees to stop the
nagging.

Best regards

Peter K

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

pk wrote:
> On 2013-08-19 00:49, Dale wrote:
>
>> Picking random message sort of.  Isn't eudev still going to support a
>> separate /usr?  That is my understanding.  If eudev is not then I may
>> have to reconsider some things myself here. 
> Yes, that is my understanding as well. But the "decision" to not support
> a separate /usr lies higher up in the system hierarchy (as I understand
> it). Gentoo as a system will not support a separate /usr if we are to
> believe the conversation (I haven't seen any official notice of this
> though). That is the sad part. The problem I have, as an engineer, is
> that "everybody" says that a separate /usr is broken, that sysvinit is
> broken without explaining why. In order to fix a problem you need to
> know what is broken... The people who claims the brokenness are, imo,
> hand waving and they've managed to convince higher uppers in the Gentoo
> infrastructure (as it seems). I guess if you repeat something often
> enough it becomes a "truth" or said person(s) just agrees to stop the
> nagging.
>
> Best regards
>
> Peter K
>
>
>


Right now, I'm using eudev.  If my machine stops booting because it
needs a init thingy, this could get interesting.  I used dracut for a
bit until eudev came along but for me, it was a tool to see if things
blow over and some folks come to their senses.  As much as I hate
Mandriva which had a init thingy, if I have to have one and find myself
unable to chroot into Gentoo and make repairs, at least Mandriva
installs faster.  Yea, you can do a lot in chroot but only if you can
figure out what is wrong and know how to fix it. 

I to hope folks can see the light before this bad dream turns into a
nightmare.  The further this goes, the harder it is going to be to back
peddle and fix it. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 11:31, pk wrote:
> On 2013-08-19 00:49, Dale wrote:
> 
>> Picking random message sort of.  Isn't eudev still going to support a
>> separate /usr?  That is my understanding.  If eudev is not then I may
>> have to reconsider some things myself here. 
> 
> Yes, that is my understanding as well. But the "decision" to not support
> a separate /usr lies higher up in the system hierarchy (as I understand
> it). Gentoo as a system will not support a separate /usr if we are to
> believe the conversation (I haven't seen any official notice of this
> though). That is the sad part. The problem I have, as an engineer, is
> that "everybody" says that a separate /usr is broken, that sysvinit is
> broken without explaining why. In order to fix a problem you need to
> know what is broken... The people who claims the brokenness are, imo,
> hand waving and they've managed to convince higher uppers in the Gentoo
> infrastructure (as it seems). I guess if you repeat something often
> enough it becomes a "truth" or said person(s) just agrees to stop the
> nagging.


It's not that separate /usr is broken - it's not.

The issue is a separate /usr without an initramfs. And the issue ONLY
occurs at early-boot time.

The problem is that with modern hardware much code that was
traditionally stored in /usr may be needed early in the boot sequence,
before /usr is mounted. The obvious case is firmware and drivers, and
the usual example cited is bluetooth keyboards. If you need keyboard
input at this time, you need to have the bluetooth daemon running, which
is on /usr, which is not mounted.

The solution is to use an initramfs, and on a technical level it's not
any different to needing a way to get the ext4 module off disk so you
can mount /.

Some may argue that bluetooth keyboards are a rarity and that's tough.
Well, there's Macbook hardware, and phones which have soft keyboards.
But many scenarios could exist, all due to the fact that hot-pluggable
hardware can in theory run any arbitrary code to get itself up and
running, and if that code is on a volume that is not mounted... The
solution is obvious - all that code should be on / somewhere, or should
be mountable using an initramfs.

Do you see that although you and I can deal with this with relative
ease, Aunt Tillie probably couldn't and the junior sysadmins I have to
deal with certainly can't?

Personally, I think that splitting / and /usr is a daft idea:

a. I have multi-TB hard disks, completely unlike the 5M monsters that
Thomson had to deal with in the 70s
b. I haven't had /usr break on me during boot requiring busybox in
maintenance mode for at least 5 years. Every startup failure in that
time required a rescue cd anyway, and I always have one of those handy
c. it IS useful for terminal servers, but those tend to have experienced
sysadmins, and they really should be OK with an initramfs (or their
vendor should ship one)

I'm often at the front of the Lennart-bashing parade, and what he says
often makes sense but only in his narrow view of the world, but in
*this* case, I can't help but admit he does have a point.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Mon, Aug 19, 2013 at 1:04 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 19/08/2013 11:31, pk wrote:
>> On 2013-08-19 00:49, Dale wrote:
>>
>>> Picking random message sort of.  Isn't eudev still going to support a
>>> separate /usr?  That is my understanding.  If eudev is not then I may
>>> have to reconsider some things myself here.
>>
>> Yes, that is my understanding as well. But the "decision" to not support
>> a separate /usr lies higher up in the system hierarchy (as I understand
>> it). Gentoo as a system will not support a separate /usr if we are to
>> believe the conversation (I haven't seen any official notice of this
>> though). That is the sad part. The problem I have, as an engineer, is
>> that "everybody" says that a separate /usr is broken, that sysvinit is
>> broken without explaining why. In order to fix a problem you need to
>> know what is broken... The people who claims the brokenness are, imo,
>> hand waving and they've managed to convince higher uppers in the Gentoo
>> infrastructure (as it seems). I guess if you repeat something often
>> enough it becomes a "truth" or said person(s) just agrees to stop the
>> nagging.
>
>
> It's not that separate /usr is broken - it's not.
>
> The issue is a separate /usr without an initramfs. And the issue ONLY
> occurs at early-boot time.
>
> The problem is that with modern hardware much code that was
> traditionally stored in /usr may be needed early in the boot sequence,
> before /usr is mounted. The obvious case is firmware and drivers, and
> the usual example cited is bluetooth keyboards. If you need keyboard
> input at this time, you need to have the bluetooth daemon running, which
> is on /usr, which is not mounted.
>
> The solution is to use an initramfs, and on a technical level it's not
> any different to needing a way to get the ext4 module off disk so you
> can mount /.
>
> Some may argue that bluetooth keyboards are a rarity and that's tough.
> Well, there's Macbook hardware, and phones which have soft keyboards.
> But many scenarios could exist, all due to the fact that hot-pluggable
> hardware can in theory run any arbitrary code to get itself up and
> running, and if that code is on a volume that is not mounted... The
> solution is obvious - all that code should be on / somewhere, or should
> be mountable using an initramfs.

You fail to understand why separate / is required.

Had the argument was: If you have special needs then have /usr mounted at boot.
I would have agreed.
This means that if you are using bluetooth keyboard, well you do have
an extra requirement.

However, because of your specific configuration drop the ability to
recover from filesystem corruptions or be able to repair is totally
different issue.

> Personally, I think that splitting / and /usr is a daft idea:
>
> a. I have multi-TB hard disks, completely unlike the 5M monsters that
> Thomson had to deal with in the 70s

You could have mounted several disk at boot even in the 70s.

> b. I haven't had /usr break on me during boot requiring busybox in
> maintenance mode for at least 5 years. Every startup failure in that
> time required a rescue cd anyway, and I always have one of those handy

This is your take... and it is totally wrong.

> c. it IS useful for terminal servers, but those tend to have experienced
> sysadmins, and they really should be OK with an initramfs (or their
> vendor should ship one)

Who is that vendor? so you along with systemd, udev, gnome, etc... do
you suggest the same vendor will also provide initramfs for gentoo...
maybe this is the next stage of systemd...

> I'm often at the front of the Lennart-bashing parade, and what he says
> often makes sense but only in his narrow view of the world, but in
> *this* case, I can't help but admit he does have a point.

Again, there is no reason why not support separate /usr configuration,
people who have special needs, like running systemd or have special
complex userland hardware that is a must for single user mode can
always mount /usr at early stage.

But because of the fact that you are using systemd or have bluetooth
keyboard force everyone to merge /usr is something that is unclear to
me.

>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-19 6:04 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> It's not that separate /usr is broken - it's not.
>
> The issue is a separate /usr without an initramfs. And the issue ONLY
> occurs at early-boot time.

And so, if this is the way it goes, this is the way it goes.

As long as I can keep using eudev - even *if* it requires an initramfs 
for a separate /usr (as long as it doesn't require one if you don't have 
a separate /usr)...

Can anyone answer *that* question please?

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 15:23, Tanstaafl wrote:
> On 2013-08-19 6:04 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> It's not that separate /usr is broken - it's not.
>>
>> The issue is a separate /usr without an initramfs. And the issue ONLY
>> occurs at early-boot time.
> 
> And so, if this is the way it goes, this is the way it goes.
> 
> As long as I can keep using eudev - even *if* it requires an initramfs
> for a separate /usr (as long as it doesn't require one if you don't have
> a separate /usr)...
> 
> Can anyone answer *that* question please?
> 


Honestly, what you want is a full-fledged udev fork from just before
systemd tainted it, and fully maintained to go in the direction we
understood "classic" udev to be going.

eudev and even mdev are a step in the right direction, but I believe
they don't have enough muscle behind them, i.e. they end up cherry
picking useful bits out of udev-subsumed-into-systemd.

udev needs the same quality of maintainership now in a fork that it used
to have. And it's probably only a matter of time before someone with
those resources gets fed up with the current scene and does exactly that.

For me, I'm not opposed to merging /usr. I'm not opposed to other people
using systemd, I am opposed to *me* using it.


For your other question, you don't need an initramfs if your /usr is not
split off and drivers for your fs on / and chipset are compiled in. That
will stay true for ages to come (until some joker starts shipping kernel
drivers in /var....)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-19 9:36 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> For me, I'm not opposed to merging /usr. I'm not opposed to other people
> using systemd, I am opposed to*me*  using it.

Agreed, and that is precisely the concern here...

> For your other question, you don't need an initramfs if your /usr is not
> split off and drivers for your fs on / and chipset are compiled in. That
> will stay true for ages to come (until some joker starts shipping kernel
> drivers in /var....)

Right, but that wasn't my question, my question was will I be able to 
continue using eudev (or mdev, or whatever)...

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 18:39, Tanstaafl wrote:
> On 2013-08-19 9:36 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> For me, I'm not opposed to merging /usr. I'm not opposed to other people
>> using systemd, I am opposed to*me*  using it.
> 
> Agreed, and that is precisely the concern here...
> 
>> For your other question, you don't need an initramfs if your /usr is not
>> split off and drivers for your fs on / and chipset are compiled in. That
>> will stay true for ages to come (until some joker starts shipping kernel
>> drivers in /var....)
> 
> Right, but that wasn't my question, my question was will I be able to
> continue using eudev (or mdev, or whatever)...
> 


Surely that depends on how well-maintained eudev remains in the future?
And is therefore best answered by the package maintainers?

Like I said a little earlier, I really think your best bet is a udev
fork (even if it's eudev) maintained with the same effort input as udev
was before all this stuff started coming down the pipes.

what I do know is that eudev is already lagging behind udev, most likely
a symptom of limited time available from the maintainer.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-19 4:54 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 19/08/2013 18:39, Tanstaafl wrote:
>> On 2013-08-19 9:36 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> For your other question, you don't need an initramfs if your /usr is not
>>> split off and drivers for your fs on / and chipset are compiled in. That
>>> will stay true for ages to come (until some joker starts shipping kernel
>>> drivers in /var....)

>> Right, but that wasn't my question, my question was will I be able to
>> continue using eudev (or mdev, or whatever)...

> Surely that depends on how well-maintained eudev remains in the future?
> And is therefore best answered by the package maintainers?

You misunderstand.

I'm concerned about feature/dependency creep, where all of a sudden the 
Gentoo Council makes a decision (or is forced into a decision) that 
makes it *impossible* for eudev (or any alternative) to work without 
systemd.

Or even worse, I actually had a dream (nightmare?) last night about an 
email to the list that went something like:

"Announcement: The Gentoo Council, in its infinite wisdom, has decided 
to make Fedora Core the official upstream for Gentoo. This is being done 
to make all of our lives easier, and so that we can all have GNOME on 
the desktop."

<shudder>

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 16:08, Tanstaafl wrote:
> On 2013-08-19 4:54 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> On 19/08/2013 18:39, Tanstaafl wrote:
>>> On 2013-08-19 9:36 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>> For your other question, you don't need an initramfs if your /usr is
>>>> not
>>>> split off and drivers for your fs on / and chipset are compiled in.
>>>> That
>>>> will stay true for ages to come (until some joker starts shipping
>>>> kernel
>>>> drivers in /var....)
> 
>>> Right, but that wasn't my question, my question was will I be able to
>>> continue using eudev (or mdev, or whatever)...
> 
>> Surely that depends on how well-maintained eudev remains in the future?
>> And is therefore best answered by the package maintainers?
> 
> You misunderstand.
> 
> I'm concerned about feature/dependency creep, where all of a sudden the
> Gentoo Council makes a decision (or is forced into a decision) that
> makes it *impossible* for eudev (or any alternative) to work without
> systemd.
> 
> Or even worse, I actually had a dream (nightmare?) last night about an
> email to the list that went something like:
> 
> "Announcement: The Gentoo Council, in its infinite wisdom, has decided
> to make Fedora Core the official upstream for Gentoo. This is being done
> to make all of our lives easier, and so that we can all have GNOME on
> the desktop."
> 
> <shudder>
> 


I just woke up from a wonderful daydream where I relived the catastrophe
that was the demise of Xfree86. Remember that, in 2004?

The project lead had been having a passive-aggressive dick-waving fight
with Keith Packard (core member) for months, then banned Keith for
committing XFixes without getting maintainer-lead blessing first.
Shortly after that, the lead introduced a license change very much like
the obnoxious advertising clause in 3-clause MIT. The community had had
enough by now and collectively said "f... this for a carry on", and
forked XFree86 to X.Org. Within a month, XFree86 was deaddeaddead,
virtually all distros started switching over, the core members voted 4
months later to disband themselves and XFfree86 source repo has had
about 2 1/2 commits in the 9 years since.

What I am saying is "don't worry". These things have a habit of fixing
themselves and nature restores the balance.

Gentoo has already been forked - Sabayon, Funtoo, Exherbo.
Gnome has already been forked - Unity, Cinnamon, Mate.
udev has already been forked - eudev and replicated - mdev

If what you fear comes to pass then many folk will have had enough and
will fork, so you are sorted.
Or what you fear does not come to pass, and there's nothing to worry about.
Or someone reigns a rogue dev in, and it all goes back to being OK.

Either way, you are still sorted. Gnome/Fedora is not Bob Mugabe - you
are not obliged to do what he wants or even to listen to a damn thing he
says.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-19 12:04, Alan McKinnon wrote:

> It's not that separate /usr is broken - it's not.

I know.

> The issue is a separate /usr without an initramfs. And the issue ONLY
> occurs at early-boot time.

It is broken for *some* systems.

> The problem is that with modern hardware much code that was
> traditionally stored in /usr may be needed early in the boot sequence,
> before /usr is mounted. The obvious case is firmware and drivers, and
> the usual example cited is bluetooth keyboards. If you need keyboard
> input at this time, you need to have the bluetooth daemon running, which
> is on /usr, which is not mounted.

Yes, bluetooth... the very thing that should not have come to pass. It
is broken by design. "Wireless" is fine but the way bluetooth works...
Back to the drawing board, please!

> The solution is to use an initramfs, and on a technical level it's not
> any different to needing a way to get the ext4 module off disk so you
> can mount /.

Yes, that is one way of solving it... But I question the sanity by
having ext4 as a module if you know you are going to use it on your
system; it's not as if you are going to use ext4 one day and reiserfs
the next day and XFS the day after that, or? The only ones that benefits
from that kind of setup is binary distros that can compile everything as
module and probe as they load.
I do however have some things compiled as modules (that I only load when
needed) but those things are not needed at boot. So for my case it's not
needed.

> Some may argue that bluetooth keyboards are a rarity and that's tough.
> Well, there's Macbook hardware, and phones which have soft keyboards.
> But many scenarios could exist, all due to the fact that hot-pluggable
> hardware can in theory run any arbitrary code to get itself up and
> running, and if that code is on a volume that is not mounted... The
> solution is obvious - all that code should be on / somewhere, or should
> be mountable using an initramfs.

Yes, *should* be. Quite optional. As it has "always" been. Just because
people are using bluetooth devices and/or want the computer to sing and
dance while booting should not impose restrictions to those who don't
want that, which is why I'm protesting.

> Do you see that although you and I can deal with this with relative
> ease, Aunt Tillie probably couldn't and the junior sysadmins I have to
> deal with certainly can't?

Yes. But have Gentoo ever been a distro for Aunt Tillie or junior
sysadmins? I don't want to discourage them to try it out of course but I
don't want to put restrictions on myself (or others) either...
Flexibility is the keyword here.

> Personally, I think that splitting / and /usr is a daft idea:

That's fine. I, respectfully, disagree. If I could break the system down
into bits and put each bit on a separate "harddrive" with a massive I/O
connection I would (yes, I exaggerate but I'm sure you get the idea).

> a. I have multi-TB hard disks, completely unlike the 5M monsters that
> Thomson had to deal with in the 70s

Haven't you heard? Size does not matter... ;-)

> b. I haven't had /usr break on me during boot requiring busybox in
> maintenance mode for at least 5 years. Every startup failure in that
> time required a rescue cd anyway, and I always have one of those handy

I haven't had /usr break either for at least that time even though I've
always had it separate. To me, I like to keep things organised in
different compartments using, perhaps somewhat arbitrary, rules.
Therefore keeping system administration tools in /sbin, user accessible
tools in /usr/bin etc. makes perfect sense (I know you think it's
arbitrary and I agree but it works, for me at least). There is no *real*
need to keep /usr separate for normal users it's just that I think it's
flexible and I want it that way. There is no right or wrong here, merely
philosophical differences. How you solve the different problems are
technical however. I do have a rescue USB stick handy as well though but
since I rarely use it I tend to forget to update it...

> c. it IS useful for terminal servers, but those tend to have experienced
> sysadmins, and they really should be OK with an initramfs (or their
> vendor should ship one)

Using an initramfs means you duplicate parts of your OS and copy them
into the kernel or using a tool (like dracut or genkernel). If you need
it from a technical point of view (bluetooth keyboard), that's fine but
if I don't have any hardware that requires it then why use an initramfs?
I guess it's a matter of taste (or "philosophy" if you will)... An
initramfs seems like bandaid to me (and it is).

> I'm often at the front of the Lennart-bashing parade, and what he says
> often makes sense but only in his narrow view of the world, but in
> *this* case, I can't help but admit he does have a point.

I don't really see it... I don't really care what Lennart does as long
as it doesn't affect me (and he may be the greatest person that ever
lived) but here we are... I choose to run Gentoo because it suits me
best of all the operating systems out there. If I didn't care about how
things works I would run Windows (or maybe MacOS).

Best regards

Peter K

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 16:33, pk wrote:
> Using an initramfs means you duplicate parts of your OS and copy them
> into the kernel or using a tool (like dracut or genkernel). If you need
> it from a technical point of view (bluetooth keyboard), that's fine but
> if I don't have any hardware that requires it then why use an initramfs?
> I guess it's a matter of taste (or "philosophy" if you will)... An
> initramfs seems like bandaid to me (and it is).


I snipped most of the thread as I don't want to revisit yet again and
old horse that is much flogged already :-)

We're not too different, you and I, if I may dare say it when we differ
it's you tend a little more towards idealism and I towards realism.

Yes, bluetooth sucks, but it was designed by what was available at the
time and it's what we have. For that matter USB, spinning disks and lack
of fibre into my house also suck, but we have to work with what we have
and what we certainly will have soon. Same with initramfs. Does it suck?
Of course it does, it just sucks less than any other realistic proposal
I've ever seen. And tricky bootstrap problems are tricky - always have
been since the 50s and always will be.

Which brings me to what I am really trying to say - giving specific
examples to highlight general problems is always a nasty road to
navigate. Like bluetooth keyboards, there's always a non-trivial number
who can claim that the example does not apply to *them*. One can go
round and round in circles with that, and skirt the actual issue:

Software exists in the context of something bigger and for us that often
means "maximally useful for the maximum number of folks inclined to use
such a package" and that sweet spot includes compromises; some things
just have to be laid in stone so that everything else works at all -
sometimes we just have to accept that.

Let's look at /usr by comparing it to /opt. I like /opt - all the crap
from Oracle, IBM, Sybase and Sun my managers shove on me goes in there
where I can at least corral it. I can agree with that setup.

I can even agree with a "system" vs "userspace" split ala / vs /usr,
although the distinction is very murky indeed, but do I really need it?
Yes, it can be useful and even if I make a case for it, does it really
need to be it's own partition? I'm carefully dodging around the niche
market for terminal servers and /usr mounted over NFS here. I
respectfully submit that we could also solve that one using full PXE
boot, automount and unionfs or brethren.

Like I said earlier, software exists in the context of something bigger,
and Gentoo exists in the context of the FOSS community. We consume much
more code than we produce and sometimes we have to back down and go with
what the world is doing or be prepared to fork.

Incidentally, I don't see that anyone has ever proposed the obvious
sword to cut this knot - have the kernel automount /usr. it already does
/ and we have root= ... it wouldn't be hard to add /usr= ...

Yes, I know I'm being stupid and Linus would reply with two words, the
first starting with an f. He'd tell us to solve it the right way even if
that's the hard way. I believe separate /usr without initramfs is
rapidly becoming white elephant material, and we are faced with a
decision to do it the hard way.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Mon, August 19, 2013 23:24, Alan McKinnon wrote:
> On 19/08/2013 16:33, pk wrote:
>> Using an initramfs means you duplicate parts of your OS and copy them
>> into the kernel or using a tool (like dracut or genkernel). If you need
>> it from a technical point of view (bluetooth keyboard), that's fine but
>> if I don't have any hardware that requires it then why use an initramfs?
>> I guess it's a matter of taste (or "philosophy" if you will)... An
>> initramfs seems like bandaid to me (and it is).
>
>
> I snipped most of the thread as I don't want to revisit yet again and
> old horse that is much flogged already :-)
>
> We're not too different, you and I, if I may dare say it when we differ
> it's you tend a little more towards idealism and I towards realism.
>
> Yes, bluetooth sucks, but it was designed by what was available at the
> time and it's what we have. For that matter USB, spinning disks and lack
> of fibre into my house also suck, but we have to work with what we have
> and what we certainly will have soon.

I could have had fibre into my house, but the rest of the neighbourhood
didn't want to sign a petition to have it installed.
The petition only stated the intent to subscribe. It didn't specify that
signatories would be required to actually subscribe.
And that is with quite a few IT-people in the area.
But that is a different rant ;)

> Which brings me to what I am really trying to say - giving specific
> examples to highlight general problems is always a nasty road to
> navigate. Like bluetooth keyboards, there's always a non-trivial number
> who can claim that the example does not apply to *them*. One can go
> round and round in circles with that, and skirt the actual issue:

What happened to wireless USB?
Bluetooth is nice for mobile phones and in-car audio/handsfree systems.
I also don't see the point of using it for keyboards.
How would I enter the pincode to link the keyboard to the computer if the
keyboard has not been linked yet? ;)

> Software exists in the context of something bigger and for us that often
> means "maximally useful for the maximum number of folks inclined to use
> such a package" and that sweet spot includes compromises; some things
> just have to be laid in stone so that everything else works at all -
> sometimes we just have to accept that.
>
> Let's look at /usr by comparing it to /opt. I like /opt - all the crap
> from Oracle, IBM, Sybase and Sun my managers shove on me goes in there
> where I can at least corral it. I can agree with that setup.

You can scratch Sun from that list, it's Oracle now...
They do have some interesting software, part of it pays for the bills.
I agree with putting that in /opt, wouldn't want to mess up the base OS
with that stuff.
Some admins install that into /home/.../, btw.

> Like I said earlier, software exists in the context of something bigger,
> and Gentoo exists in the context of the FOSS community. We consume much
> more code than we produce and sometimes we have to back down and go with
> what the world is doing or be prepared to fork.
>
> Incidentally, I don't see that anyone has ever proposed the obvious
> sword to cut this knot - have the kernel automount /usr. it already does
> / and we have root= ... it wouldn't be hard to add /usr= ...
>
> Yes, I know I'm being stupid and Linus would reply with two words, the
> first starting with an f. He'd tell us to solve it the right way even if
> that's the hard way. I believe separate /usr without initramfs is
> rapidly becoming white elephant material, and we are faced with a
> decision to do it the hard way.

If Linus would go for that, how long till there would be a /var, /home,
/... in there?
Maybe an "fstab=/path/to/fstab" would be a better option? And then make
sure that file is on the root-partition?

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Stroller]

On 19 August 2013, at 10:31, pk wrote:
> ... The problem I have, as an engineer, is
> that "everybody" says that a separate /usr is broken, that sysvinit is
> broken without explaining why. In order to fix a problem you need to
> know what is broken...
   
   Here's a short, very in-comprehensive list of software we are aware of that
   currently are not able to provide the full set of functionality when /usr
   is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all
   rules depending on this (using the PCI/USB database in /usr/share),
   PulseAudio, NetworkManager, ModemManager, udisks, libatasmart,
   usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth,
   LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs
   and a lot of other stuff. [1]

I honestly don't have a horse in this race, I don't much care one way or the other. 

I tend to like things "the old fashioned way", I like things simple, and I like to keep doing things the way I know.

I hate the whole initrd thing, but I tend to slap most everything on a single partition, anyway. 

I could be persuaded either way, were there compelling arguments, but you just undermine your own position by pretending that the reasons for the migration are somehow fictional.

Stroller.


[1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:

>    Here's a short, very in-comprehensive list of software we are aware
> of that currently are not able to provide the full set of functionality
> when /usr is split off and not pre-mounted at boot:
> udev-pci-db/udev-usb-db and all rules depending on this (using the
> PCI/USB database in /usr/share), PulseAudio, NetworkManager,
> ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager,
> usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll,
> VMWare, the locale logic of most programs and a lot of other stuff. [1]

How much of that is needed before the contents of /etc/fstab are
mounted? I certainly don't need to run a desktop, used a 3G modem, play
sounds or load a virtual machine before then. Yes, LVM may be needed, but
the needed parts are in /sbin anyway, so that is a red herring too.

I understand the need, even desire, of binary distros to cover all bases
by taking the safer option, but Gentoo is about choice and all reasonable
choices should be permitted. It comes down to what the council means by
"not supported". If it means "will not work" that will cause problems for
some, but if it means "you have to work it out for yourself", well,
what's the point of a community if we can't work it out between us?


-- 
Neil Bothwick

Death to all fanatics!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[William Kenworthy]

On 19/08/13 18:55, Neil Bothwick wrote:
> On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:
> 
>>    Here's a short, very in-comprehensive list of software we are aware
>> of that currently are not able to provide the full set of functionality
>> when /usr is split off and not pre-mounted at boot:
>> udev-pci-db/udev-usb-db and all rules depending on this (using the
>> PCI/USB database in /usr/share), PulseAudio, NetworkManager,
>> ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager,
>> usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll,
>> VMWare, the locale logic of most programs and a lot of other stuff. [1]
> 
> How much of that is needed before the contents of /etc/fstab are
> mounted? I certainly don't need to run a desktop, used a 3G modem, play
> sounds or load a virtual machine before then. Yes, LVM may be needed, but
> the needed parts are in /sbin anyway, so that is a red herring too.
> 
> I understand the need, even desire, of binary distros to cover all bases
> by taking the safer option, but Gentoo is about choice and all reasonable
> choices should be permitted. It comes down to what the council means by
> "not supported". If it means "will not work" that will cause problems for
> some, but if it means "you have to work it out for yourself", well,
> what's the point of a community if we can't work it out between us?
> 
> 

I rather suspect that they are going after the cloud/VM market ...
having VM's boot quickly and simply along with no desire/need to fault
find and repair ... just rm it and spin up another instance.

It makes sense in that market ... what doesn't is pushing it into areas
that are not appropriate and people dont want it.  I think that Fedora
has largely dropped off peoples list of useful distros but more
interesting is how Redhat will go when these ideas start to get included
in RHE - last I heard that still has not happened.  I did try Fedora as
a choice on our networking machines for students but took it off as no
one used it as it was just "not nice" - possibly the bad vibes of gnome3
contributing - the surprise was linuxmint being more popular than
ubuntu.  Gentoo is there but only as a specially configured command line
only tool so its not in the running.

I still have not seen an adequate explanation as to why systemd isn't a
profile as its far more intrusive than a gnome/kde choice and they have
profiles.  That way some bad choices like polluting systems with systemd
files because they are only small and insignificant might be avoided.  I
have used the mask method but did waste some time on chasing down odd
errors due to missing file errors in the logs so I would rather not have
them on the system at all.

So why not a profile so those guys who want to play can get a
configuration that better suits them? - and vice versa if the whole
systemd push dies and Redhat drops it as I doubt anyone else big enough
will pick it up (they have a foot in both camps at the moment).  Smaller
distros that jump entirely systemd will be in trouble until they move back.

BillK

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 15:36, William Kenworthy wrote:
> I still have not seen an adequate explanation as to why systemd isn't a
> profile as its far more intrusive than a gnome/kde choice and they have
> profiles.  That way some bad choices like polluting systems with systemd
> files because they are only small and insignificant might be avoided.  I
> have used the mask method but did waste some time on chasing down odd
> errors due to missing file errors in the logs so I would rather not have
> them on the system at all.


There was an uber-thread on -dev over the last two months that covered
most of these bases. I stopped paying attention about halfway through...
but it's all there on gmane.

The thread started with with a proposed sysvinit -> systemd migration
script, and it quickly became obvious why profiles and USE flags look OK
at first glance but rapidly becomes apparent that they aren't.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-19 9:36 AM, William Kenworthy <billk@iinet.net.au> wrote:
> I rather suspect that they are going after the cloud/VM market ...
> having VM's boot quickly and simply along with no desire/need to fault
> find and repair ... just rm it and spin up another instance.

Nothing to 'suspect'... they have made it very clear that that is 
precisely where this (systemd) is coming from.

> It makes sense in that market ... what doesn't is pushing it into areas
> that are not appropriate and people dont want it.

Exactly, and exactly.

> I still have not seen an adequate explanation as to why systemd isn't a
> profile as its far more intrusive than a gnome/kde choice and they have
> profiles.  That way some bad choices like polluting systems with systemd
> files because they are only small and insignificant might be avoided.  I
> have used the mask method but did waste some time on chasing down odd
> errors due to missing file errors in the logs so I would rather not have
> them on the system at all.
>
> So why not a profile so those guys who want to play can get a
> configuration that better suits them?

I have to say that makes the most sense to me...

Would love to hear *rational* comments from the systemd purveyors as to 
why this shouldn't be done.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Mon, Aug 19, 2013 at 11:43 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-08-19 9:36 AM, William Kenworthy <billk@iinet.net.au> wrote:
>>
>> I rather suspect that they are going after the cloud/VM market ...
>> having VM's boot quickly and simply along with no desire/need to fault
>> find and repair ... just rm it and spin up another instance.
>
>
> Nothing to 'suspect'... they have made it very clear that that is precisely
> where this (systemd) is coming from.
>
>
>> It makes sense in that market ... what doesn't is pushing it into areas
>> that are not appropriate and people dont want it.
>
>
> Exactly, and exactly.
>
>
>> I still have not seen an adequate explanation as to why systemd isn't a
>> profile as its far more intrusive than a gnome/kde choice and they have
>> profiles.  That way some bad choices like polluting systems with systemd
>> files because they are only small and insignificant might be avoided.  I
>> have used the mask method but did waste some time on chasing down odd
>> errors due to missing file errors in the logs so I would rather not have
>> them on the system at all.
>>
>> So why not a profile so those guys who want to play can get a
>> configuration that better suits them?
>
>
> I have to say that makes the most sense to me...
>
> Would love to hear *rational* comments from the systemd purveyors as to why
> this shouldn't be done.

Yohan already say it: you would need to do several combinations
(systemd+GNOME, systemd+KDE, systemd+SELinux, etc.)

Your "polluted" files are nothing (3MB, including binaries in a
*systemd* installation... if you don't use systemd they should take
less than 512KB); you don't want the profile "solution" for technical
reasons, you want it for political reasons.

That is not going to happen, and the (majority of) Gentoo maintainers
(including the council) already stated that, if you don't want systemd
unit files "polluting" your system, please use INSTALL_MASK.

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

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Yohan Pereira]

On 19/08/13 at 09:36pm, William Kenworthy wrote:
> So why not a profile so those guys who want to play can get a
> configuration that better suits them? - and vice versa if the whole
> systemd push dies and Redhat drops it as I doubt anyone else big enough
> will pick it up (they have a foot in both camps at the moment).  Smaller
> distros that jump entirely systemd will be in trouble until they move back.

  Not a systemd supporter in any way but I don't think making a profile
makes sense because we already have profiles for kde, gnome, desktop
etc. Users will probably want to use systemd in-conjunction with any one
of those, so we would need to have kde-systemd, gnome-systemd .. which
is absurd. 

  At least I don't see a sane way to achieve it from my
rudimentary understanding of profiles. 
 

-- 

- Yohan Pereira

The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
                -- Mark Twain

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 19:03, Yohan Pereira wrote:
> On 19/08/13 at 09:36pm, William Kenworthy wrote:
>> So why not a profile so those guys who want to play can get a
>> configuration that better suits them? - and vice versa if the whole
>> systemd push dies and Redhat drops it as I doubt anyone else big enough
>> will pick it up (they have a foot in both camps at the moment).  Smaller
>> distros that jump entirely systemd will be in trouble until they move back.
> 
>   Not a systemd supporter in any way but I don't think making a profile
> makes sense because we already have profiles for kde, gnome, desktop
> etc. Users will probably want to use systemd in-conjunction with any one
> of those, so we would need to have kde-systemd, gnome-systemd .. which
> is absurd. 
> 
>   At least I don't see a sane way to achieve it from my
> rudimentary understanding of profiles. 


The only way it could be done is to have additive profiles, i.e. a
collection of possible profiles such as gnome, kde, openrc, systemd -
pick all that apply.

This very rapidly cascades into a total nightmare when one profile say
to include thing X and another says to exclude thing X. There's no sane
default handling for that, one has to install local policy that applies
a precedence rule.

USE=systemd is far better (ignoring for the moment the difficulties in
actually switching the service manager over)


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Mon, August 19, 2013 12:55, Neil Bothwick wrote:
> On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:
>
>>    Here's a short, very in-comprehensive list of software we are aware
>> of that currently are not able to provide the full set of functionality
>> when /usr is split off and not pre-mounted at boot:
>> udev-pci-db/udev-usb-db and all rules depending on this (using the
>> PCI/USB database in /usr/share), PulseAudio, NetworkManager,
>> ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager,
>> usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll,
>> VMWare, the locale logic of most programs and a lot of other stuff. [1]
>
> How much of that is needed before the contents of /etc/fstab are
> mounted? I certainly don't need to run a desktop, used a 3G modem, play
> sounds or load a virtual machine before then. Yes, LVM may be needed, but
> the needed parts are in /sbin anyway, so that is a red herring too.

It is a red herring.
I currently use an initramfs, but that is because I decided to put "/" on
LVM as well.
When I had "/" as a normal partition and /usr on LVM, there were no issues
with booting. Currently, with the initramfs, I get errors about / and /usr
not being able to umount during shutdown.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

J. Roeleveld wrote:
> On Mon, August 19, 2013 12:55, Neil Bothwick wrote:
>> On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:
>>
>>>    Here's a short, very in-comprehensive list of software we are aware
>>> of that currently are not able to provide the full set of functionality
>>> when /usr is split off and not pre-mounted at boot:
>>> udev-pci-db/udev-usb-db and all rules depending on this (using the
>>> PCI/USB database in /usr/share), PulseAudio, NetworkManager,
>>> ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager,
>>> usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll,
>>> VMWare, the locale logic of most programs and a lot of other stuff. [1]
>> How much of that is needed before the contents of /etc/fstab are
>> mounted? I certainly don't need to run a desktop, used a 3G modem, play
>> sounds or load a virtual machine before then. Yes, LVM may be needed, but
>> the needed parts are in /sbin anyway, so that is a red herring too.
> It is a red herring.
> I currently use an initramfs, but that is because I decided to put "/" on
> LVM as well.
> When I had "/" as a normal partition and /usr on LVM, there were no issues
> with booting. Currently, with the initramfs, I get errors about / and /usr
> not being able to umount during shutdown.
>
> --
> Joost
>
>
>

I to have / on a traditional partition, ext4, and /boot on a small ext2
partition.  Everything else is on LVM.  I don't want a init thingy
either.  I had nightmares with that thing when I used Mandrake years
ago.  I can't recall the name of that thing that left me with no
keyboard/mouse but I still remember that init thingy.  Dang, what was
that thing that did that?  Anyway, as bad a taste as that other thing
left, the init thingy is even worse.  I still remember the init thingy
10 YEARS later.  The other thing was a few years ago. 

I bet Alan remembers.  I was plenty pissed.  That is likely the most
pissed I ever been on this list.  If that guy had been in front of me,
I'd be in jail.  I got to many trees around here.  O-o

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[joost]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

Dale <rdalek1967@gmail.com> wrote:
>J. Roeleveld wrote:
>> On Mon, August 19, 2013 12:55, Neil Bothwick wrote:
>>> On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:
>>>
>>>>    Here's a short, very in-comprehensive list of software we are
>aware
>>>> of that currently are not able to provide the full set of
>functionality
>>>> when /usr is split off and not pre-mounted at boot:
>>>> udev-pci-db/udev-usb-db and all rules depending on this (using the
>>>> PCI/USB database in /usr/share), PulseAudio, NetworkManager,
>>>> ModemManager, udisks, libatasmart, usb_modeswitch,
>gnome-color-manager,
>>>> usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath,
>Argyll,
>>>> VMWare, the locale logic of most programs and a lot of other stuff.
>[1]
>>> How much of that is needed before the contents of /etc/fstab are
>>> mounted? I certainly don't need to run a desktop, used a 3G modem,
>play
>>> sounds or load a virtual machine before then. Yes, LVM may be
>needed, but
>>> the needed parts are in /sbin anyway, so that is a red herring too.
>> It is a red herring.
>> I currently use an initramfs, but that is because I decided to put
>"/" on
>> LVM as well.
>> When I had "/" as a normal partition and /usr on LVM, there were no
>issues
>> with booting. Currently, with the initramfs, I get errors about / and
>/usr
>> not being able to umount during shutdown.
>>
>> --
>> Joost
>>
>>
>>
>
>I to have / on a traditional partition, ext4, and /boot on a small ext2
>partition.  Everything else is on LVM.  I don't want a init thingy
>either.  I had nightmares with that thing when I used Mandrake years
>ago.  I can't recall the name of that thing that left me with no
>keyboard/mouse but I still remember that init thingy.  Dang, what was
>that thing that did that?  Anyway, as bad a taste as that other thing
>left, the init thingy is even worse.  I still remember the init thingy
>10 YEARS later.  The other thing was a few years ago. 
>
>I bet Alan remembers.  I was plenty pissed.  That is likely the most
>pissed I ever been on this list.  If that guy had been in front of me,
>I'd be in jail.  I got to many trees around here.  O-o
>
>Dale
>
>:-)  :-) 
>
>-- 
>I am only responsible for what I said ... Not for what you understood
>or how you interpreted my words!

I also still remember.
Not going to mention it now. But will give a hint.
What is the name of the computer that said: "I'm sorry Dale, I can't let you do that."?

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 3209 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 06:00, joost@antarean.org wrote:
> Dale <rdalek1967@gmail.com> wrote:
> 
>     J. Roeleveld wrote:
> 
>         On Mon, August 19, 2013 12:55, Neil Bothwick wrote:
> 
>             On Mon, 19 Aug 2013 11:17:06 +0100, Stroller wrote:
> 
>                 Here's a short, very in-comprehensive list of software
>                 we are aware
>                 of that currently are not able to provide the full set
>                 of functionality
>                 when /usr is split off and not pre-mounted at boot:
>                 udev-pci-db/udev-usb-db and all rules depending on this
>                 (using the
>                 PCI/USB database in /usr/share), PulseAudio, NetworkManager,
>                 ModemManager, udisks, libatasmart, usb_modeswitch,
>                 gnome-color-manager,
>                 usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip,
>                 multipath, Argyll,
>                 VMWare, the locale logic of most programs and a lot of
>                 other stuff. [1]
> 
>             How much of that is needed before the contents of /etc/fstab are
>             mounted? I certainly don't need to run a desktop, used a 3G
>             modem, play
>             sounds or load a virtual machine before then. Yes, LVM may
>             be needed, but
>             the needed parts are in /sbin anyway, so that is a red
>             herring too.
> 
>         It is a red herring.
>         I currently use an initramfs, but that is because I decided to
>         put "/" on
>         LVM as well.
>         When I had "/" as a normal partition and /usr on LVM, there were
>         no issues
>         with booting. Currently, with the initramfs, I get errors about
>         / and /usr
>         not being able to umount during shutdown.
> 
>         --
>         Joost
> 
> 
> 
> 
> 
>     I to have / on a traditional partition, ext4, and /boot on a small ext2
>     partition.  Everything else is on LVM.  I don't want a init thingy
>     either.  I had nightmares with that
>     thing when I used Mandrake years
>     ago.  I can't recall the name of that thing that left me with no
>     keyboard/mouse but I still remember that init thingy.  Dang, what was
>     that thing that did that?  Anyway, as bad a taste as that other thing
>     left, the init thingy is even worse.  I still remember the init thingy
>     10 YEARS later.  The other thing was a few years ago. 
> 
>     I bet Alan remembers.  I was plenty pissed.  That is likely the most
>     pissed I ever been on this list.  If that guy had been in front of me,
>     I'd be in jail.  I got to many trees around here.  O-o
> 
>     Dale
> 
>     :-)  :-) 
> 
> 
> I also still remember.
> Not going to mention it now. But will give a hint.
> What is the name of the computer that said: "I'm sorry Dale, I can't let
> you do that."?


bwahahahaha :-)

Yes, we all remember Dale's troubles with that thing a few years ago.

2001 was a good move and a good book too (just finished both again as it
turns out). 2010 doesn't quite match up though...

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 07:55, Alan McKinnon wrote:
> On 20/08/2013 06:00, joost@antarean.org wrote:

>> I also still remember.
>> Not going to mention it now. But will give a hint.
>> What is the name of the computer that said: "I'm sorry Dale, I can't let
>> you do that."?
>
>
> bwahahahaha :-)
>
> Yes, we all remember Dale's troubles with that thing a few years ago.
>
> 2001 was a good move and a good book too (just finished both again as it
> turns out). 2010 doesn't quite match up though...

The book and movie were done at the same time, if I remember correctly.
So they both complement each other really well.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Tue, 20 Aug 2013 08:54:25 +0200, J. Roeleveld wrote:

> > 2001 was a good move and a good book too (just finished both again as
> > it turns out). 2010 doesn't quite match up though...  
> 
> The book and movie were done at the same time, if I remember correctly.

There's also a book about how the book and movie were developed in
parallel, interesting reading.


-- 
Neil Bothwick

Sacred cows make great hamburgers.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 11:59, Neil Bothwick wrote:
> On Tue, 20 Aug 2013 08:54:25 +0200, J. Roeleveld wrote:
> 
>>> 2001 was a good move and a good book too (just finished both again as
>>> it turns out). 2010 doesn't quite match up though...  
>>
>> The book and movie were done at the same time, if I remember correctly.
> 
> There's also a book about how the book and movie were developed in
> parallel, interesting reading.
> 
> 


The Road to 2001 (or some such) - excellent book, with sample chapters
of early revisions so you can see how the plot developed over time and
how Clarke gradually removed the Deus Ex Machine hackery :-)

Yup, I admit it, huge Clarke nerd <-- me


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Mon, 19 Aug 2013 20:12:30 -0500, Dale wrote:

> I to have / on a traditional partition, ext4, and /boot on a small ext2
> partition.  Everything else is on LVM.  I don't want a init thingy
> either.  I had nightmares with that thing when I used Mandrake years
> ago.  I can't recall the name of that thing that left me with no
> keyboard/mouse but I still remember that init thingy.  Dang, what was
> that thing that did that?  Anyway, as bad a taste as that other thing
> left, the init thingy is even worse.  I still remember the init thingy
> 10 YEARS later.  The other thing was a few years ago. 

Comparing a Mandrake generated initrd of 10 years ago with a current
initramfs generated by Dracut is hardly relevant.

And since no one else seems willing to mention the word;

HAL HAL HAL HAL HAL HAL HAL :)

It should be easy for you to remember, it sounds like HELL, in so many
ways :)


-- 
Neil Bothwick

Too many clicks spoil the browse.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

Neil Bothwick wrote:
> On Mon, 19 Aug 2013 20:12:30 -0500, Dale wrote:
>
>> I to have / on a traditional partition, ext4, and /boot on a small ext2
>> partition.  Everything else is on LVM.  I don't want a init thingy
>> either.  I had nightmares with that thing when I used Mandrake years
>> ago.  I can't recall the name of that thing that left me with no
>> keyboard/mouse but I still remember that init thingy.  Dang, what was
>> that thing that did that?  Anyway, as bad a taste as that other thing
>> left, the init thingy is even worse.  I still remember the init thingy
>> 10 YEARS later.  The other thing was a few years ago.
>
> Comparing a Mandrake generated initrd of 10 years ago with a current
> initramfs generated by Dracut is hardly relevant.
>
> And since no one else seems willing to mention the word;
>
> HAL HAL HAL HAL HAL HAL HAL :)
>
> It should be easy for you to remember, it sounds like HELL, in so many
> ways :)
>
>

Well, it gave me issues then and I couldn't boot.  Even WITH dracut, if
the init thingy failed, I wouldn't have a clue how to fix the stupid
thing even today.  Also, why use one when I don't need one?  My plan,
stay away from it for as long as possible.  When the day comes that I
have to have one, find something that installs faster.  Crap, that
sounds like winders don't it?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 2209 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[microcai]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

在 2013-8-19 上午5:55，"pk" <peterk2@coolmail.se>写道：
>
> On 2013-08-18 23:08, Mick wrote:
>
> > I honestly cannot understand why we/Gentoo are allowing the RHL
> > monolithic development philosophy to break what we have.  Is
> > Poettering the only developer available to the Linux world?  Are
> > RHL dictating what path Debian and its cousin distros should
> > follow?
>
> Problem is that Linux is dependent on udev and udev is in the hands of
> Kay Sievers which also develops systemd together with Lennart
> Poettering which in turn used to be a Gnome developer... With that
> said, what I cannot understand is why people advocating systemd (and
> the kitchen-and-sink model) are using Gentoo in the first place. Are
> they just trying to make the rest of the Linux distro landscape as
> miserable as Fedora? Why don't they stay with Fedora instead of trying
> to turn Gentoo into Fedora?
>
> Best regards
>
> Peter K
>

any one complant to systemd is not a programer. he does not understand how
bad sysvinit it is from the code point of view..

some one even say the old version is more stable than latest version even
the author say no and drop the support.

this is all the stupicy of non programer. they think they understand progam
while in fact no.

[-- Attachment #2: Type: text/html, Size: 1576 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/18/2013 09:39 PM, microcai wrote:
> 
> 在 2013-8-19 上午5:55，"pk" <peterk2@coolmail.se
> <mailto:peterk2@coolmail.se>>写道：
>>
>> On 2013-08-18 23:08, Mick wrote:
>>
>> > I honestly cannot understand why we/Gentoo are allowing the RHL
>> > monolithic development philosophy to break what we have.  Is
>> > Poettering the only developer available to the Linux world?  Are
>> > RHL dictating what path Debian and its cousin distros should
>> > follow?
>>
>> Problem is that Linux is dependent on udev and udev is in the hands of
>> Kay Sievers which also develops systemd together with Lennart
>> Poettering which in turn used to be a Gnome developer... With that
>> said, what I cannot understand is why people advocating systemd (and
>> the kitchen-and-sink model) are using Gentoo in the first place. Are
>> they just trying to make the rest of the Linux distro landscape as
>> miserable as Fedora? Why don't they stay with Fedora instead of trying
>> to turn Gentoo into Fedora?
>>
>> Best regards
>>
>> Peter K
>>
> 
> any one complant to systemd is not a programer. he does not understand how
> bad sysvinit it is from the code point of view..
> 
> some one even say the old version is more stable than latest version
> even the author say no and drop the support.
> 
> this is all the stupicy of non programer. they think they understand
> progam while in fact no.
> 

As a budding programmer I understand that a lot of the functionality
that users take for granted in sysvinit scripts is hacked together and
prone to bash upgrades breaking them, syntax for outside programs to
change, and other auxiliary breakages. This is true of *any* program
that relies on code not written by the author, however, and it is
managed through something called "maintenance". All code needs
maintenance or it will eventually cease to work, unless the code that
the programs rely on does not change. It's a fact of life for
programming projects. Some would rather maintain C code than bash
scripts. Nothing wrong with that. I prefer C over bash as well, but it's
not like bash is *terrible*. It's a language that practically any
serious *nix user will know some variant of. Due to this, sysadmins and
users can gain familiarity with sysvinit or other bash-script-using init
systems much faster than with a broad, C-only init system like systemd.
This familiarity means end-users can fix their own problems without
needing to recompile or do backtraces or other higher-level debugging
tasks. This also ensures that the primary init binary stays untouched
and can still bring up a system.

sysvinit may not be perfect, but systemd's approach ("Include as much as
possible in one package") is just as bad, if not worse. At least
sysvinit is hackable, which adds to its versatility. Systemd is not free
of good ideas. cgroups can be a useful, optional build-time thing that
Linux users can opt into. Parallel boot sequences can speed up the
booting of a machine that launches many services. The fatal mistake made
from a technical point is that systemd became too ambitious. Taking on a
new feature or a new task in a project has a multiplicative or
exponential effect, *not* an additive one. Given the broad array of
features that systemd has, its purpose is spread too thin and tries to
do too much. It's not simple code and it does too many things.

People often forget that there are other init systems out there, as
well. runit is a great little package, and also uses bash scripts like
sysvinit. It's designed to be lightweight, supports a custom amount of
run levels, and a few extras I'm forgetting. The important thing about
runit is that *it knows what it is*. It's an init system with
service-management added in. It doesn't log things for you, it doesn't
manage your splash screen, it doesn't manage devfs/sysfs, it doesn't
make you coffee and comb your hair, it doesn't take over
security-related tasks. It knows itself and is *happy* to stay focused
on its one job. Because of this, runit and other specialized projects
can focus on being the best it can be on that single task. Compare this
approach to a project that wants to add tons of features or do a little
bit of everything to appeal to the broadest audience possible. This is
literally what systemd does, as a project and as code. It's a "yes"
project instead of a "no" project.

Lastly, programmers are not immune to the effects of cognitive biases.
They are just as prone as anyone else to social engineering and
groupthink influencing their decisions. To believe any group is immune
to social misdeeds is foolhardy. This doesn't completely discredit
programmers (or other groups that fall to kool-aid), but it certainly
casts an unfavorable light and earns them suspicion. By asserting that
only the programmers' viewpoints matter, you are forgetting the social
aspects of software development, which are equally important. Without an
audience and users who have good relations with the devs, there's not a
healthy dialogue to enrich the project and make bug fixes, feature
discussions, and so on easier to work with. Without users, software
doesn't mature and bugs are slower to be found. You need both the
technical and the social in order to have a healthy project. Excluding
the social aspect right out of the gate will alienate your potential
audience in the FOSS world.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 05:42, Daniel Campbell wrote:
> As a budding programmer I understand that a lot of the functionality
> that users take for granted in sysvinit scripts is hacked together and
prone to bash upgrades breaking them


sysvinit scripts have ended up where almost every large project that
spans many years ends up:

#!/bin/sh

# do a standard action here
idea.get()

# do some weird magic hacked user-defined shit here
???

# do a few more standard things here
profit(!)





sysvinit, like X11, needs a massive overhaul and a sprint clean.
systemd may or may not be a good replacement


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-19 08:35, Alan McKinnon wrote:

> sysvinit, like X11, needs a massive overhaul and a sprint clean.

Yes, an overhaul is always welcome. But most people criticising these
systems (and other systems) just say that they are bad without pointing
out what is bad. How can you fix something without knowing what's bad?
To me the problem with sysvinit (and X11) seems mostly to be a
philosophical one. Some people say: "this doesn't work the way I want it
to - therefore it's crap!". While others (like me) say: "I have no
problem with this - it works fine!".

From a technical standpoint, does sysvinit fulfill the technical
requirements (i.e. the "specification")? I honestly don't know, I just
think/assume it does since we've been using it for, what, 30 years or so
(SVR1 was released in January 1983 acc. to [1]) and I've never had any
problems with it. Does the "specification" need to be updated? I'm sure
it does but to throw out everything and start from scratch is not the
way I would go (unless it's technically required because of some
fundamental issue - and I disagree with people thinking there's a
fundamental issue here).
 Now, some people who thinks the computer should sing and dance to them
(seems to me mostly the Gnome crowd) while booting, I can understand
that sysvinit may not fit their "philosophy". I am not one of them.
Basically I want the computer to do as little as possible, i.e. not
waste one cycle unless _absolutely_ necessary; _all_ compute power
should be available to me and me only for whatever purpose I see fit.
The computer is a tool, a hammer if you will and I don't want a hammer
with built-in radio, a fan to cool you down, a radiator to warm you up
or a tv screen (or whatever). Of course, computers being so complex
these days (I started out with a Commodore PET in the late 70ies), there
has to be compromises. And I think that sysvinit with it's init scripts
(i.e. OpenRC) is a good compromise because I don't care about boot time
(as mentioned in another mail most of the time is spent in BIOS/UEFI
anyway). Having said that I wouldn't mind if we refined sysvinit/OpenRC
carefully, getting rid of bugs (even though I've never encountered any),
refining the "blueprints/specification" so that it fits the customers
wishes (within reason).

Basically what I'm trying to say is: The "technical" arguments that have
been brought forward pro/con sysvinit(+OpenRC)/systemd I think is bogus.
It is just a philosophical disagreement between parties having different
goals, which I'm not sure can be fully satisfied by either side.

[1] https://en.wikipedia.org/wiki/UNIX_System_V

Best regards

Peter K

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 14:13, pk wrote:
>> sysvinit, like X11, needs a massive overhaul and a sprint clean.
> Yes, an overhaul is always welcome. But most people criticising these
> systems (and other systems) just say that they are bad without pointing
> out what is bad. How can you fix something without knowing what's bad?
> To me the problem with sysvinit (and X11) seems mostly to be a
> philosophical one. Some people say: "this doesn't work the way I want it
> to - therefore it's crap!". While others (like me) say: "I have no
> problem with this - it works fine!".


I find sysvinit to be unwieldy and clunky. Perhaps not so much the code
itself, but surely the interface it presents to me the sysadmin. All
that rc.[0-6] nonsense - what's that all about? In all my days I have
never seen a computer running *nix that wasn't fully satisfied with two
exclusive running states:

- normal operation (whether console, headless, X)
- maintenance mode (busybox on console).

So why do I have 6 of them? The runlevels themselves are fixed and
rigid. I want them somewhat more flexible, I actually don't want a
bluetooth daemon *running*all*the*time* - really, it should only start
when I enable bluetooth. This may not be the best analogy but you get
the point, the OS needs to react to changes in the environment and
sometimes those reactions are best dealt with by the service manager.

OpenRC to my mind made huge strides in dragging this into modern times
by making runlevels declarative. It all make so much sense in Gentoo. As
for the bulk of the code, I don't have issue with that. PID=1 does what
it needs to do.

I suppose I can sum up the changed environment in one word: hotplug

X11, well that's another story and probably way off topic. It was
designed for hardware and architectures that haven't existed for 20+
years. Almost all factors that made X11 awesome in the 80s and 90s
simply are not there anymore.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[joost]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>On 19/08/2013 14:13, pk wrote:
>>> sysvinit, like X11, needs a massive overhaul and a sprint clean.
>> Yes, an overhaul is always welcome. But most people criticising these
>> systems (and other systems) just say that they are bad without
>pointing
>> out what is bad. How can you fix something without knowing what's
>bad?
>> To me the problem with sysvinit (and X11) seems mostly to be a
>> philosophical one. Some people say: "this doesn't work the way I want
>it
>> to - therefore it's crap!". While others (like me) say: "I have no
>> problem with this - it works fine!".
>
>
>I find sysvinit to be unwieldy and clunky. Perhaps not so much the code
>itself, but surely the interface it presents to me the sysadmin. All
>that rc.[0-6] nonsense - what's that all about? In all my days I have
>never seen a computer running *nix that wasn't fully satisfied with two
>exclusive running states:
>
>- normal operation (whether console, headless, X)
>- maintenance mode (busybox on console).
>
>So why do I have 6 of them? The runlevels themselves are fixed and
>rigid. I want them somewhat more flexible, I actually don't want a
>bluetooth daemon *running*all*the*time* - really, it should only start
>when I enable bluetooth. This may not be the best analogy but you get
>the point, the OS needs to react to changes in the environment and
>sometimes those reactions are best dealt with by the service manager.
>
>OpenRC to my mind made huge strides in dragging this into modern times
>by making runlevels declarative. It all make so much sense in Gentoo.
>As
>for the bulk of the code, I don't have issue with that. PID=1 does what
>it needs to do.
>
>I suppose I can sum up the changed environment in one word: hotplug
>
>X11, well that's another story and probably way off topic. It was
>designed for hardware and architectures that haven't existed for 20+
>years. Almost all factors that made X11 awesome in the 80s and 90s
>simply are not there anymore.

X11 was still really awesome in 2002. When we used remote graphical logons to different machines. 
It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;)

But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that?

--
Joost

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 22:32, joost@antarean.org wrote:
>> X11, well that's another story and probably way off topic. It was
>> >designed for hardware and architectures that haven't existed for 20+
>> >years. Almost all factors that made X11 awesome in the 80s and 90s
>> >simply are not there anymore.
> X11 was still really awesome in 2002. When we used remote graphical logons to different machines. 
> It also helped with performance of certain desktop applications. Running the application on a different machine (with better CPU) then the machine I was working at always made people wonder why the same application was performing so badly on theirs ;)
> 
> But these days. Having fast reliable performance locally is better. With a decent RDP that can connect to an existing desktop without having to set it up as shared from the beginning is more useful. Any ideas on that?


Agreed. I've gotten so used to all that local *GL* goodness that running
almost any app (except maybe xterm) remotely is just so painful it makes
me cry...

I'm also lucky in that when I managed to foist all the oracle with java
installers off onto some other team of luckless suckers, I was left with
just the best remote interface ever - ssh and bash. So I can afford to
be smug :-)

I don't know how to make your RDP problem easier - I treat that the same
as allow/deny rules for ssh (or any other kind of access really) and
just accept that sometimes I need to ask first for something to be
allowed. again, I can afford to be smug here too as the only things I
need to RDP to are terminals set up for that very purpose and VirtualBox
VMs (that is one more check box at the create stage).



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote:

> I'm also lucky in that when I managed to foist all the oracle with java
> installers off onto some other team of luckless suckers, I was left with
> just the best remote interface ever - ssh and bash. So I can afford to
> be smug :-)

Those of us running ssh and zsh can easily out-smug you :)

And those adding screen/tmux into the mix can become truly unbearable...


-- 
Neil Bothwick

I am Flatulus of Borg.  You will be asphixiated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 00:33, Neil Bothwick wrote:
> On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote:
>
>> I'm also lucky in that when I managed to foist all the oracle with java
>> installers off onto some other team of luckless suckers, I was left with
>> just the best remote interface ever - ssh and bash. So I can afford to
>> be smug :-)
>
> Those of us running ssh and zsh can easily out-smug you :)
>
> And those adding screen/tmux into the mix can become truly unbearable...

When working remotely on a console, I always use screen. Been bitten too
often by dodgy links that it is a sane safety feature.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 07:41, J. Roeleveld wrote:
> On Tue, August 20, 2013 00:33, Neil Bothwick wrote:
>> On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote:
>>
>>> I'm also lucky in that when I managed to foist all the oracle with java
>>> installers off onto some other team of luckless suckers, I was left with
>>> just the best remote interface ever - ssh and bash. So I can afford to
>>> be smug :-)
>>
>> Those of us running ssh and zsh can easily out-smug you :)
>>
>> And those adding screen/tmux into the mix can become truly unbearable...
> 
> When working remotely on a console, I always use screen. Been bitten too
> often by dodgy links that it is a sane safety feature.


Oh, are you also working in Africa since recently then?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 07:58, Alan McKinnon wrote:
> On 20/08/2013 07:41, J. Roeleveld wrote:
>> On Tue, August 20, 2013 00:33, Neil Bothwick wrote:
>>> On Mon, 19 Aug 2013 22:51:38 +0200, Alan McKinnon wrote:
>>>
>>>> I'm also lucky in that when I managed to foist all the oracle with
>>>> java
>>>> installers off onto some other team of luckless suckers, I was left
>>>> with
>>>> just the best remote interface ever - ssh and bash. So I can afford to
>>>> be smug :-)
>>>
>>> Those of us running ssh and zsh can easily out-smug you :)
>>>
>>> And those adding screen/tmux into the mix can become truly
>>> unbearable...
>>
>> When working remotely on a console, I always use screen. Been bitten too
>> often by dodgy links that it is a sane safety feature.
>
> Oh, are you also working in Africa since recently then?

Nope, but dodgy links exist in NL as well.
And considering I still remember using dial-up modems (14k4 was my first
one), screen was really usefull to keep my phonebills under control.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Tue, 20 Aug 2013 07:41:12 +0200, J. Roeleveld wrote:

> > And those adding screen/tmux into the mix can become truly
> > unbearable...  
> 
> When working remotely on a console, I always use screen. Been bitten too
> often by dodgy links that it is a sane safety feature.

Same here. My .zshrc starts scree if it detects I am logging in via SSH.


-- 
Neil Bothwick

Growing old is mandatory; growing up is optional!!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Mon, August 19, 2013 22:51, Alan McKinnon wrote:
> On 19/08/2013 22:32, joost@antarean.org wrote:
>>> X11, well that's another story and probably way off topic. It was
>>> >designed for hardware and architectures that haven't existed for 20+
>>> >years. Almost all factors that made X11 awesome in the 80s and 90s
>>> >simply are not there anymore.
>> X11 was still really awesome in 2002. When we used remote graphical
>> logons to different machines.
>> It also helped with performance of certain desktop applications. Running
>> the application on a different machine (with better CPU) then the
>> machine I was working at always made people wonder why the same
>> application was performing so badly on theirs ;)
>>
>> But these days. Having fast reliable performance locally is better. With
>> a decent RDP that can connect to an existing desktop without having to
>> set it up as shared from the beginning is more useful. Any ideas on
>> that?
>
> Agreed. I've gotten so used to all that local *GL* goodness that running
> almost any app (except maybe xterm) remotely is just so painful it makes
> me cry...

For remote access, I can live without all the special effects.

> I'm also lucky in that when I managed to foist all the oracle with java
> installers off onto some other team of luckless suckers, I was left with
> just the best remote interface ever - ssh and bash. So I can afford to
> be smug :-)

ssh -Y <host> works really well for those.
I always feel smug when others first need to figure out how to get a
remote-X connection to the server because they use MS Windows.
They often claim that a VNC-server is a valid pre-req...
Take it from me, that is NOT a requirement to install the software.

> I don't know how to make your RDP problem easier - I treat that the same
> as allow/deny rules for ssh (or any other kind of access really) and
> just accept that sometimes I need to ask first for something to be
> allowed. again, I can afford to be smug here too as the only things I
> need to RDP to are terminals set up for that very purpose and VirtualBox
> VMs (that is one more check box at the create stage).

For me the usage case is as follows:
1) I start to do something on my desktop at home
2) I go to the office or customer site
3) I need to continue/finish what I was doing (it's usually for a customer
in that case)
...

At this point, I can't continue. Unless I remembered to run a VNC server
and used vnc to localhost for step 1.

With a MS Windows desktop, it is usually (sometimes I get a "clean"
desktop and still can't continue) possible.

One option would be to be able to redirect an application to a different
X-server and when that one dies/disconnects/... it will reconnect to the
initial (my desktop) one.
This is also not something I found yet either.
For these activities, all the latest *GL* goodies are not necessary and I
can easily live without them. Remote 3D gaming isn't something I want to
do.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 07:38, J. Roeleveld wrote:
> On Mon, August 19, 2013 22:51, Alan McKinnon wrote:
>> On 19/08/2013 22:32, joost@antarean.org wrote:
>>>> X11, well that's another story and probably way off topic. It was
>>>>> designed for hardware and architectures that haven't existed for 20+
>>>>> years. Almost all factors that made X11 awesome in the 80s and 90s
>>>>> simply are not there anymore.
>>> X11 was still really awesome in 2002. When we used remote graphical
>>> logons to different machines.
>>> It also helped with performance of certain desktop applications. Running
>>> the application on a different machine (with better CPU) then the
>>> machine I was working at always made people wonder why the same
>>> application was performing so badly on theirs ;)
>>>
>>> But these days. Having fast reliable performance locally is better. With
>>> a decent RDP that can connect to an existing desktop without having to
>>> set it up as shared from the beginning is more useful. Any ideas on
>>> that?
>>
>> Agreed. I've gotten so used to all that local *GL* goodness that running
>> almost any app (except maybe xterm) remotely is just so painful it makes
>> me cry...
> 
> For remote access, I can live without all the special effects.
> 
>> I'm also lucky in that when I managed to foist all the oracle with java
>> installers off onto some other team of luckless suckers, I was left with
>> just the best remote interface ever - ssh and bash. So I can afford to
>> be smug :-)
> 
> ssh -Y <host> works really well for those.
> I always feel smug when others first need to figure out how to get a
> remote-X connection to the server because they use MS Windows.
> They often claim that a VNC-server is a valid pre-req...
> Take it from me, that is NOT a requirement to install the software.
> 
>> I don't know how to make your RDP problem easier - I treat that the same
>> as allow/deny rules for ssh (or any other kind of access really) and
>> just accept that sometimes I need to ask first for something to be
>> allowed. again, I can afford to be smug here too as the only things I
>> need to RDP to are terminals set up for that very purpose and VirtualBox
>> VMs (that is one more check box at the create stage).
> 
> For me the usage case is as follows:
> 1) I start to do something on my desktop at home
> 2) I go to the office or customer site
> 3) I need to continue/finish what I was doing (it's usually for a customer
> in that case)
> ...
> 
> At this point, I can't continue. Unless I remembered to run a VNC server
> and used vnc to localhost for step 1.
> 
> With a MS Windows desktop, it is usually (sometimes I get a "clean"
> desktop and still can't continue) possible.
> 
> One option would be to be able to redirect an application to a different
> X-server and when that one dies/disconnects/... it will reconnect to the
> initial (my desktop) one.
> This is also not something I found yet either.

I don't think you can do that, I've never seen a way to change DISPLAY
for an X-client on the fly.

What you are describing sounds a lot like screen for X11, no?
A thread last week was about remote desktop apps and what folks use. I
didn't pay much attention, but ISTR a mention in that thread of
something like that


> For these activities, all the latest *GL* goodies are not necessary and I
> can easily live without them. Remote 3D gaming isn't something I want to
> do.
> 
> --
> Joost
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 08:06, Alan McKinnon wrote:
> On 20/08/2013 07:38, J. Roeleveld wrote:
>> On Mon, August 19, 2013 22:51, Alan McKinnon wrote:
>>> On 19/08/2013 22:32, joost@antarean.org wrote:
>>>>> X11, well that's another story and probably way off topic. It was
>>>>>> designed for hardware and architectures that haven't existed for 20+
>>>>>> years. Almost all factors that made X11 awesome in the 80s and 90s
>>>>>> simply are not there anymore.
>>>> X11 was still really awesome in 2002. When we used remote graphical
>>>> logons to different machines.
>>>> It also helped with performance of certain desktop applications.
>>>> Running
>>>> the application on a different machine (with better CPU) then the
>>>> machine I was working at always made people wonder why the same
>>>> application was performing so badly on theirs ;)
>>>>
>>>> But these days. Having fast reliable performance locally is better.
>>>> With
>>>> a decent RDP that can connect to an existing desktop without having to
>>>> set it up as shared from the beginning is more useful. Any ideas on
>>>> that?
>>>
>>> Agreed. I've gotten so used to all that local *GL* goodness that
>>> running
>>> almost any app (except maybe xterm) remotely is just so painful it
>>> makes
>>> me cry...
>>
>> For remote access, I can live without all the special effects.
>>
>>> I'm also lucky in that when I managed to foist all the oracle with java
>>> installers off onto some other team of luckless suckers, I was left
>>> with
>>> just the best remote interface ever - ssh and bash. So I can afford to
>>> be smug :-)
>>
>> ssh -Y <host> works really well for those.
>> I always feel smug when others first need to figure out how to get a
>> remote-X connection to the server because they use MS Windows.
>> They often claim that a VNC-server is a valid pre-req...
>> Take it from me, that is NOT a requirement to install the software.
>>
>>> I don't know how to make your RDP problem easier - I treat that the
>>> same
>>> as allow/deny rules for ssh (or any other kind of access really) and
>>> just accept that sometimes I need to ask first for something to be
>>> allowed. again, I can afford to be smug here too as the only things I
>>> need to RDP to are terminals set up for that very purpose and
>>> VirtualBox
>>> VMs (that is one more check box at the create stage).
>>
>> For me the usage case is as follows:
>> 1) I start to do something on my desktop at home
>> 2) I go to the office or customer site
>> 3) I need to continue/finish what I was doing (it's usually for a
>> customer
>> in that case)
>> ...
>>
>> At this point, I can't continue. Unless I remembered to run a VNC server
>> and used vnc to localhost for step 1.
>>
>> With a MS Windows desktop, it is usually (sometimes I get a "clean"
>> desktop and still can't continue) possible.
>>
>> One option would be to be able to redirect an application to a different
>> X-server and when that one dies/disconnects/... it will reconnect to the
>> initial (my desktop) one.
>> This is also not something I found yet either.
>
> I don't think you can do that, I've never seen a way to change DISPLAY
> for an X-client on the fly.
>
> What you are describing sounds a lot like screen for X11, no?
> A thread last week was about remote desktop apps and what folks use. I
> didn't pay much attention, but ISTR a mention in that thread of
> something like that

Yes, saw it too.
Window Switch seems to be what I need, except it doesn't work well with
KDE-apps. (Guess which desktop I use...)

I will simply keep looking and remember to start VNC whenever it seems
likely I might need to continue at a later date.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Sun, Aug 18, 2013 at 4:54 PM, pk <peterk2@coolmail.se> wrote:
> On 2013-08-18 23:08, Mick wrote:
>
>> I honestly cannot understand why we/Gentoo are allowing the RHL
>> monolithic development philosophy to break what we have.  Is
>> Poettering the only developer available to the Linux world?  Are
>> RHL dictating what path Debian and its cousin distros should
>> follow?
>
> Problem is that Linux is dependent on udev and udev is in the hands of
> Kay Sievers which also develops systemd together with Lennart
> Poettering which in turn used to be a Gnome developer... With that
> said, what I cannot understand is why people advocating systemd (and
> the kitchen-and-sink model) are using Gentoo in the first place.

Probably for exactly the same reason you or anyone else uses Gentoo;
USE flags, portage, you can customize at your hearts content...

> Are
> they just trying to make the rest of the Linux distro landscape as
> miserable as Fedora? Why don't they stay with Fedora instead of trying
> to turn Gentoo into Fedora?

I've never used Fedora. I used RedHay back in the day of RedHat 4.2
(it was my very first use of Linux in 1996), then moved to Mandrake
(remember Mandrake?), then Gentoo in 2003. I haven't used any other
distro since then.

I want Gentoo to keep being the best possible Linux (I *really* don't
care if it works in *BSD, Solaris, or Windows). Believe it or not, I'm
pretty sure that for Gentoo to keep being the best possible Linux, it
has to use systemd.

You don't have to agree with that, of course. But please understand
that I only support systemd in Gentoo, because I love Gentoo.

And, putting aside systemd and getting back on topic to the council's
decision of (eventually) not supporting separated /usr without an
initramfs; have you ever stopped to consider that, perhaps, that's the
best *technical* decision? (*gasp*)

When you have almost all distributions converging on that, and even
*the OpenRC maintainer* (which is the one pushing this, BTW, not the
systemd guys) supporting that decision, don't you think that perhaps,
just *perhaps*, everybody screaming about the sky falling (which, BTW,
they are certainly noisy, but I really don't think are that many) are
overreacting and even (*gasp* again) wrong?

Just something to think about it.

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

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-19 04:55, Canek Peláez Valdés wrote:

> Probably for exactly the same reason you or anyone else uses Gentoo;
> USE flags, portage, you can customize at your hearts content...

USE flags, in my mind, are there for minimising dependencies so that I
don't need to install all the crap that binary distros install. That is
why I use Gentoo, in order to avoid all the crap that things like Gnome
wants to install (for instance, I have -gnome, -dbus, -gconf in my
make.conf in order to avoid a heart attack[1]). Customisation are only
possible if you allow to minimise dependencies; and it's also dependent
on a flexible base system (if you put restrictions on it, say, if /usr
can be separate or not[without an initrd], then flexibility decreases).

> I've never used Fedora. I used RedHay back in the day of RedHat 4.2
> (it was my very first use of Linux in 1996), then moved to Mandrake
> (remember Mandrake?), then Gentoo in 2003. I haven't used any other
> distro since then.

This is rather pointless, but I started using a Linux based OS (don't
remember the name, but it came on 9 floppy disks with kernel 0.93) on my
Amiga 4000 in the early nineties. I've used Redhat, Mandrake, Debian,
Slackware and others, landing with LFS in 2000 which I was happy with
but it was too much work so I settled with Gentoo in the early 2000
which is the best compromise I have found. Haven't used any other
"distro" since then either...

> I want Gentoo to keep being the best possible Linux (I *really* don't
> care if it works in *BSD, Solaris, or Windows). Believe it or not, I'm

I want Gentoo to be the best *OS* for me. To me that is achieved by
having the widest possible selection of applications and following
standards as closely as possible (POSIX, FHS). I don't really care if
it's Linux or not but I'm most comfortable in a UNIX like environment.
That said, I think what you are advocating is going in a opposite
direction to what I want... to me the changes you seek are making Gentoo
going from best to bad; reducing choice/flexibility.

> pretty sure that for Gentoo to keep being the best possible Linux, it
> has to use systemd.

I fully believe you think that systemd is the best choice for init
systems out there, but then again you are a Gnome user (as I understand
it) and to me that is quite the opposite from what I want (I abhor the
whole Gnome eco system and Lennart is an old Gnome dev so I can see
where the influences comes from). I happen to think that many small
tools with clearly defined interfaces (i.e. a standard) works so much
better and are so much more flexible than "... the one system to rule
them all...".

> You don't have to agree with that, of course. But please understand
> that I only support systemd in Gentoo, because I love Gentoo.

I understand that. The thing is, as I see it, you "support" (advocate
would perhaps be a better choice of words) systemd and _only_ systemd,
thereby "forcing it down our throats".

> And, putting aside systemd and getting back on topic to the council's
> decision of (eventually) not supporting separated /usr without an
> initramfs; have you ever stopped to consider that, perhaps, that's the
> best *technical* decision? (*gasp*)

I fail to see why I should waste time and resources by having a
duplicate set of tools (one in the initramfs and one in /). How is that
a *technical* solution? I would call it bandaid. There is no difference
from having static binaries in / (it's just a matter of locality). So,
yes, I have thought about it and I don't consider it the best *decision*
(*gasp*).

> When you have almost all distributions converging on that, and even

You said "... customize at your hearts content...". To me that assumes
flexibility. If you take away choice, you take away flexibility. To me
that's a contradiction. That "almost all distributions" are converging
is a non-argument; it says nothing about "technical" excellence
(whatever that means). It may merely mean that the devs in said distros
have given up and just "eat" whatever crap they're served because of
lack of manpower or whatever.

[1] Yes, I hate Gnome with a passion ever since using it on those
distros mentioned above.

Best regards

Peter K

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Mon, Aug 19, 2013 at 8:17 AM, pk <peterk2@coolmail.se> wrote:
> On 2013-08-19 04:55, Canek Peláez Valdés wrote:
>
>> Probably for exactly the same reason you or anyone else uses Gentoo;
>> USE flags, portage, you can customize at your hearts content...
>
> USE flags, in my mind, are there for minimising dependencies so that I
> don't need to install all the crap that binary distros install. That is
> why I use Gentoo, in order to avoid all the crap that things like Gnome
> wants to install (for instance, I have -gnome, -dbus, -gconf in my
> make.conf in order to avoid a heart attack[1]). Customisation are only
> possible if you allow to minimise dependencies; and it's also dependent
> on a flexible base system (if you put restrictions on it, say, if /usr
> can be separate or not[without an initrd], then flexibility decreases).

USE flags are for customizations, and they are available *as long as
someone supports them*.

I don't use KDE (I really don't like it); I don't have nothing KDE
related (not even Qt) in any of my systems. AFAIK, that is not
possible to do in any distro other than Gentoo.

>> I've never used Fedora. I used RedHay back in the day of RedHat 4.2
>> (it was my very first use of Linux in 1996), then moved to Mandrake
>> (remember Mandrake?), then Gentoo in 2003. I haven't used any other
>> distro since then.
>
> This is rather pointless, but I started using a Linux based OS (don't
> remember the name, but it came on 9 floppy disks with kernel 0.93) on my
> Amiga 4000 in the early nineties. I've used Redhat, Mandrake, Debian,
> Slackware and others, landing with LFS in 2000 which I was happy with
> but it was too much work so I settled with Gentoo in the early 2000
> which is the best compromise I have found. Haven't used any other
> "distro" since then either...
>
>> I want Gentoo to keep being the best possible Linux (I *really* don't
>> care if it works in *BSD, Solaris, or Windows). Believe it or not, I'm
>
> I want Gentoo to be the best *OS* for me.

This is where you are confused, Peter. Nobody (except you) cares about
your particular needs, in the same way that nobody (except me) cares
about mine. The developers (Gentoo devs, GNOME devs, systemd devs,
OpenRC devs, kernel devs) don't care (and don't have to) about
particular cases: they have to care about *the general cases*. Some of
them care about some cases, others care about others. As long as a
case has someone(s) to support it, that case will be supported.

So, if you want Gentoo to be the best *OS* for *you*, don't
necessarily expect that anybody will do the work for you.

> To me that is achieved by
> having the widest possible selection of applications and following
> standards as closely as possible (POSIX, FHS). I don't really care if
> it's Linux or not but I'm most comfortable in a UNIX like environment.
> That said, I think what you are advocating is going in a opposite
> direction to what I want... to me the changes you seek are making Gentoo
> going from best to bad; reducing choice/flexibility.

Why? eudev is there, you can use it. OpenRC is there, and if you agree
with its maintainer (who wants to stop supporting separated /usr
without an initramfs), you can keep using it.

And of course, you can freeze all your machines and never upgrade
again; what choices are you being denied? What is being discussed is
that nobody is going to do work for you, so a bad technical
combination (separated /usr without an initramfs) works.

>> pretty sure that for Gentoo to keep being the best possible Linux, it
>> has to use systemd.
>
> I fully believe you think that systemd is the best choice for init
> systems out there, but then again you are a Gnome user (as I understand
> it) and to me that is quite the opposite from what I want (I abhor the
> whole Gnome eco system and Lennart is an old Gnome dev so I can see
> where the influences comes from). I happen to think that many small
> tools with clearly defined interfaces (i.e. a standard) works so much
> better and are so much more flexible than "... the one system to rule
> them all...".

And who is stopping you from using your "many small tools with clearly
defined interfaces"? The code is there; if you are willing and able,
you can tune everything as you want.

Just don't expect someone will cater to your specific needs.

>> You don't have to agree with that, of course. But please understand
>> that I only support systemd in Gentoo, because I love Gentoo.
>
> I understand that. The thing is, as I see it, you "support" (advocate
> would perhaps be a better choice of words) systemd and _only_ systemd,
> thereby "forcing it down our throats".

First, I maintained an overlay for having only systemd (no OpenRC) for
several months, so I would say support.

Second, when I have said that I want to force *anyone* to use systemd?
Citation please.

I want Gentoo to fully support systemd (and we are almost there). I
don't want to force no one to use it; where did you get that from?

>> And, putting aside systemd and getting back on topic to the council's
>> decision of (eventually) not supporting separated /usr without an
>> initramfs; have you ever stopped to consider that, perhaps, that's the
>> best *technical* decision? (*gasp*)
>
> I fail to see why I should waste time and resources by having a
> duplicate set of tools (one in the initramfs and one in /). How is that
> a *technical* solution? I would call it bandaid. There is no difference
> from having static binaries in / (it's just a matter of locality). So,
> yes, I have thought about it and I don't consider it the best *decision*
> (*gasp*).

Well, discuss it with the OpenRC maintainer, which is the one pushing
the option. *Nobody* that actually has worked in the problem (the
*GENERAL* problem, not "my pc works like that") wants to support
separated /usr without initramfs. Nobody.

>> When you have almost all distributions converging on that, and even
>
> You said "... customize at your hearts content...". To me that assumes
> flexibility. If you take away choice, you take away flexibility. To me
> that's a contradiction. That "almost all distributions" are converging
> is a non-argument; it says nothing about "technical" excellence
> (whatever that means). It may merely mean that the devs in said distros
> have given up and just "eat" whatever crap they're served because of
> lack of manpower or whatever.

I think there is a lot of confusion about what it means that "Gentoo
is about choice". I was against that notion for a long time, but I
turned around and now fully embrace it, with a caveat. Allow me to
state the Gentoo Is About Choice Axiom:

"Gentoo is about choice, AS LONG AS SOMEONE IS WILLING AND ABLE TO
SUPPORT THAT CHOICE".

People are willing and able to support systemd in Gentoo, so that
choice is available. People are willing and able to support GNOME in
Gentoo, so that choice is available. People are willing and able to
support OpenRC in Gentoo, so that choice is available.

*Nobody* is willing *AND ABLE* to support separated /usr without an
initramfs. The general problem, please, not some anecdotal story about
how you have never had problems with it. Therefore, that choice is not
available, unless you find someone WILLING AND ABLE to support it.

Good luck with that.

> [1] Yes, I hate Gnome with a passion ever since using it on those
> distros mentioned above.

It is clear to me that much of your reasoning is clouded by that kind
of hate. I don't hate OpenRC; it is a very good incremental step from
SysV, and I have no problem with it being the default init for Gentoo.

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

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[pk]

On 2013-08-19 19:05, Canek Peláez Valdés wrote:

<snipped a whole lot of bollocks>

I'm beginning to think you are a troll since you consistently
misinterpret what I'm trying to say. This is the last thing I will say
in this matter: Your "technical arguments" are bogus. Yes, I agree that
my point is moot since I don't have the time or resources to steer
Gentoo/Linux in a direction that I would like to see so I guess "put up
or shut up" is appropriate... But if I remember correctly someone else
(i.e. you) on this list a while ago was whining about "systemd is not
supported"... So I reserve the right to whine about it as well. A hint
for the future: Try to get off your high horse!

/PK

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Mon, Aug 19, 2013 at 1:55 PM, pk <peterk2@coolmail.se> wrote:
> On 2013-08-19 19:05, Canek Peláez Valdés wrote:
>
> <snipped a whole lot of bollocks>
>
> I'm beginning to think you are a troll since you consistently
> misinterpret what I'm trying to say. This is the last thing I will say
> in this matter: Your "technical arguments" are bogus. Yes, I agree that
> my point is moot since I don't have the time or resources to steer
> Gentoo/Linux in a direction that I would like to see so I guess "put up
> or shut up" is appropriate... But if I remember correctly someone else
> (i.e. you) on this list a while ago was whining about "systemd is not
> supported"...

I didn't whine; I collaborated with bug 318365 [1] so systemd was
supported in Gentoo, and then I modified and wrote several ebuilds so
we could have an overlay to get rid of OpenRC [3], and then I tried to
do as much as possible  (bugs 373219, 409385, several others) to get
us to where we are today: with systemd almost a first class citizen in
Gentoo. When bug 373219 is closed, I would consider that a "mission
accomplished".

So I didn't whine; I worked to bring the changes I wanted into Gentoo.
You should try it; it works.

> So I reserve the right to whine about it as well.

Oh, please, whine as much as you want. It doesn't change absolutely
nothing, though.

> A hint for the future: Try to get off your high horse!

Seriously? You call telling the facts (with citations, by the way)
being on a "high horse"?

Jeez.

Regards.

[1] https://bugs.gentoo.org/show_bug.cgi?id=318365
[2] https://github.com/canek-pelaez/gentoo-systemd-only
[3] https://bugs.gentoo.org/show_bug.cgi?id=373219
[4] https://bugs.gentoo.org/show_bug.cgi?id=409385
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> And, putting aside systemd and getting back on topic to the council's
> decision of (eventually) not supporting separated /usr without an
> initramfs; have you ever stopped to consider that, perhaps, that's the
> best *technical*  decision? (*gasp*)

That is *not* the concern here, Canek, and that should be obvious from 
the comments here.

Repeat: the primary concern is *not* about separate /usr without initramfs.

The primary concern is that systemd will eventually be shoved down our 
throats whether we want it or not, and using eudev or mdev  or 
*anything* other than systemd (ie OpenRC/eudev) will.

And the track record speaks for itself, regardless of *any* promises 
that it won't, it is obvious to anyone with eyes to see and ears to hear 
that this is a blatant LIE.

Everything that is happening is simply setting the stage for precisely that.

> When you have almost all distributions converging on that, and even
> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
> systemd guys) supporting that decision, don't you think that perhaps,
> just*perhaps*, everybody screaming about the sky falling (which, BTW,
> they are certainly noisy, but I really don't think are that many) are
> overreacting and even (*gasp* again) wrong?

Again, the main issue is not about separate /usr, so please stop trying 
to deflect the subject...

In my opinion, the single largest reason to *not* switch to systemd in 
gentoo is the source of the push - in other words, it is coming from 
Fedora - and GNOME lovers are the maintainers.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alecks Gates]

On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>
> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> And, putting aside systemd and getting back on topic to the council's
>> decision of (eventually) not supporting separated /usr without an
>> initramfs; have you ever stopped to consider that, perhaps, that's the
>> best *technical*  decision? (*gasp*)
>
>
> That is *not* the concern here, Canek, and that should be obvious from the comments here.
>
> Repeat: the primary concern is *not* about separate /usr without initramfs.
>
> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev  or *anything* other than systemd (ie OpenRC/eudev) will.
>
*snip*
>
>> When you have almost all distributions converging on that, and even
>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>> systemd guys) supporting that decision, don't you think that perhaps,
>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>
>> they are certainly noisy, but I really don't think are that many) are
>> overreacting and even (*gasp* again) wrong?
>
>
> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
>

Isn't that what this thread is about?  "Optional /usr merge in Gentoo"

Can someone please explain to me what's so hard and/or complicated
about making an initramfs?  At this point in time it's extremely
simple for me, but I only manage relatively simple systems (although
I'd like that to change soon).  All I do is add one extra line (for
example - "dracut -H --kver=3.11.0-rc6") to my kernel install
procedure.

Granted, the only reason I have an initramfs is for the plymouth
splash screen (other systems aren't desktops) -- but from everything I
can see it's not too complicated otherwise.

-- 
Alecks Gates

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <alecks.g@gmail.com> wrote:
> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>
>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>
>>> And, putting aside systemd and getting back on topic to the council's
>>> decision of (eventually) not supporting separated /usr without an
>>> initramfs; have you ever stopped to consider that, perhaps, that's the
>>> best *technical*  decision? (*gasp*)
>>
>>
>> That is *not* the concern here, Canek, and that should be obvious from the comments here.
>>
>> Repeat: the primary concern is *not* about separate /usr without initramfs.
>>
>> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev  or *anything* other than systemd (ie OpenRC/eudev) will.
>>
> *snip*
>>
>>> When you have almost all distributions converging on that, and even
>>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>>> systemd guys) supporting that decision, don't you think that perhaps,
>>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>>
>>> they are certainly noisy, but I really don't think are that many) are
>>> overreacting and even (*gasp* again) wrong?
>>
>>
>> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
>>
>
> Isn't that what this thread is about?  "Optional /usr merge in Gentoo"
>
> Can someone please explain to me what's so hard and/or complicated
> about making an initramfs?  At this point in time it's extremely
> simple for me, but I only manage relatively simple systems (although
> I'd like that to change soon).  All I do is add one extra line (for
> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
> procedure.
>
> Granted, the only reason I have an initramfs is for the plymouth
> splash screen (other systems aren't desktops) -- but from everything I
> can see it's not too complicated otherwise.

Yeah... it is not complicated to but Windows as well, or IBM os-390!!!

You use a tool that hides the initramfs building, and you are amazed
it is simple?

The files within the initramfs generation tool are compiled using
different tool than portage, they are not updated when distribution is
updated, and they are not even at same version within portage tree.

It may be acceptable for you... but do not expect everyone will accept
your setup.

Regards,
Alon

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alecks Gates]

On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <alecks.g@gmail.com> wrote:
>> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>>
>>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>
>>>> And, putting aside systemd and getting back on topic to the council's
>>>> decision of (eventually) not supporting separated /usr without an
>>>> initramfs; have you ever stopped to consider that, perhaps, that's the
>>>> best *technical*  decision? (*gasp*)
>>>
>>>
>>> That is *not* the concern here, Canek, and that should be obvious from the comments here.
>>>
>>> Repeat: the primary concern is *not* about separate /usr without initramfs.
>>>
>>> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev  or *anything* other than systemd (ie OpenRC/eudev) will.
>>>
>> *snip*
>>>
>>>> When you have almost all distributions converging on that, and even
>>>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>>>> systemd guys) supporting that decision, don't you think that perhaps,
>>>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>>>
>>>> they are certainly noisy, but I really don't think are that many) are
>>>> overreacting and even (*gasp* again) wrong?
>>>
>>>
>>> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
>>>
>>
>> Isn't that what this thread is about?  "Optional /usr merge in Gentoo"
>>
>> Can someone please explain to me what's so hard and/or complicated
>> about making an initramfs?  At this point in time it's extremely
>> simple for me, but I only manage relatively simple systems (although
>> I'd like that to change soon).  All I do is add one extra line (for
>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
>> procedure.
>>
>> Granted, the only reason I have an initramfs is for the plymouth
>> splash screen (other systems aren't desktops) -- but from everything I
>> can see it's not too complicated otherwise.
>
> Yeah... it is not complicated to but Windows as well, or IBM os-390!!!
>
> You use a tool that hides the initramfs building, and you are amazed
> it is simple?

Dracut isn't *hiding* anything from me, I just don't need anything
more complicated -- who said I'm amazed?

>
> The files within the initramfs generation tool are compiled using
> different tool than portage, they are not updated when distribution is
> updated, and they are not even at same version within portage tree.

Why does this matter?  Are there some huge security vulnerabilities
I'm unaware of?

>
> It may be acceptable for you... but do not expect everyone will accept
> your setup.

Don't mind me, I'm just looking for the logic.  Feel free to explain it to me.

>
> Regards,
> Alon
>

-- 
Alecks Gates

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alon Bar-Lev]

On Mon, Aug 19, 2013 at 5:37 PM, Alecks Gates <alecks.g@gmail.com> wrote:
> On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
>> On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <alecks.g@gmail.com> wrote:
>>> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>>>
>>>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>>
>>>>> And, putting aside systemd and getting back on topic to the council's
>>>>> decision of (eventually) not supporting separated /usr without an
>>>>> initramfs; have you ever stopped to consider that, perhaps, that's the
>>>>> best *technical*  decision? (*gasp*)
>>>>
>>>>
>>>> That is *not* the concern here, Canek, and that should be obvious from the comments here.
>>>>
>>>> Repeat: the primary concern is *not* about separate /usr without initramfs.
>>>>
>>>> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev  or *anything* other than systemd (ie OpenRC/eudev) will.
>>>>
>>> *snip*
>>>>
>>>>> When you have almost all distributions converging on that, and even
>>>>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>>>>> systemd guys) supporting that decision, don't you think that perhaps,
>>>>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>>>>
>>>>> they are certainly noisy, but I really don't think are that many) are
>>>>> overreacting and even (*gasp* again) wrong?
>>>>
>>>>
>>>> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
>>>>
>>>
>>> Isn't that what this thread is about?  "Optional /usr merge in Gentoo"
>>>
>>> Can someone please explain to me what's so hard and/or complicated
>>> about making an initramfs?  At this point in time it's extremely
>>> simple for me, but I only manage relatively simple systems (although
>>> I'd like that to change soon).  All I do is add one extra line (for
>>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
>>> procedure.
>>>
>>> Granted, the only reason I have an initramfs is for the plymouth
>>> splash screen (other systems aren't desktops) -- but from everything I
>>> can see it's not too complicated otherwise.
>>
>> Yeah... it is not complicated to but Windows as well, or IBM os-390!!!
>>
>> You use a tool that hides the initramfs building, and you are amazed
>> it is simple?
>
> Dracut isn't *hiding* anything from me, I just don't need anything
> more complicated -- who said I'm amazed?
>
>>
>> The files within the initramfs generation tool are compiled using
>> different tool than portage, they are not updated when distribution is
>> updated, and they are not even at same version within portage tree.
>
> Why does this matter?  Are there some huge security vulnerabilities
> I'm unaware of?
>>
>> It may be acceptable for you... but do not expect everyone will accept
>> your setup.
>
> Don't mind me, I'm just looking for the logic.  Feel free to explain it to me.

What do you mean "Don't mind me"?

I don't mind you... as long as you don't force me to do anything...

>>
>> Regards,
>> Alon
>>
>
> --
> Alecks Gates
>

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[thegeezer]

On 08/19/2013 03:37 PM, Alecks Gates wrote:
> On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev <alonbl@gentoo.org> wrote:
>> On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <alecks.g@gmail.com> wrote:
>>> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>> And, putting aside systemd and getting back on topic to the council's
>>>>> decision of (eventually) not supporting separated /usr without an
>>>>> initramfs; have you ever stopped to consider that, perhaps, that's the
>>>>> best *technical*  decision? (*gasp*)
>>>>
>>>> That is *not* the concern here, Canek, and that should be obvious from the comments here.
>>>>
>>>> Repeat: the primary concern is *not* about separate /usr without initramfs.
>>>>
>>>> The primary concern is that systemd will eventually be shoved down our throats whether we want it or not, and using eudev or mdev  or *anything* other than systemd (ie OpenRC/eudev) will.
>>>>
>>> *snip*
>>>>> When you have almost all distributions converging on that, and even
>>>>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>>>>> systemd guys) supporting that decision, don't you think that perhaps,
>>>>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>>>>
>>>>> they are certainly noisy, but I really don't think are that many) are
>>>>> overreacting and even (*gasp* again) wrong?
>>>>
>>>> Again, the main issue is not about separate /usr, so please stop trying to deflect the subject...
>>>>
>>> Isn't that what this thread is about?  "Optional /usr merge in Gentoo"
>>>
>>> Can someone please explain to me what's so hard and/or complicated
>>> about making an initramfs?  At this point in time it's extremely
>>> simple for me, but I only manage relatively simple systems (although
>>> I'd like that to change soon).  All I do is add one extra line (for
>>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
>>> procedure.
>>>
>>> Granted, the only reason I have an initramfs is for the plymouth
>>> splash screen (other systems aren't desktops) -- but from everything I
>>> can see it's not too complicated otherwise.
>> Yeah... it is not complicated to but Windows as well, or IBM os-390!!!
>>
>> You use a tool that hides the initramfs building, and you are amazed
>> it is simple?
> Dracut isn't *hiding* anything from me, I just don't need anything
> more complicated -- who said I'm amazed?
>
>> The files within the initramfs generation tool are compiled using
>> different tool than portage, they are not updated when distribution is
>> updated, and they are not even at same version within portage tree.
> Why does this matter?  Are there some huge security vulnerabilities
> I'm unaware of?

If you have one system to keep on top of, it's simple to make sure to
update initramfs after a kernel update
If you have many systems, and they are remote, it becomes trickier.
A borked kernel update remotely can be easily resolved by panic=1 and
having a grub failsafe boot option.
It doesn't even need a kernel update.  I'm a big fan of LVM, but i found
that in the upgrade to sys-fs/lvm2-2.02.99-r2 my usb devices were coming
up as invalid pvs on LVM start in the default runlevel, after the
initramfs. No biggie locally, and only backups were on those devices.  
but remotely and at system updating times (silly oclock) it's easy to
miss a simple thing like initrd update. 
worse if what is borked is relied upon -- consider a system that only
boots 75% -- it doesn't fail but it doesn't start all services in the
default runlevel because the initrd is not updated, or is updated
incorrectly.
being locked out of boxes remotely at silly oclock sucks, and we don't
always have the benefit of OOB management,  IPVS or DRBD to not worry
about it until after sleep has relaxed the mind.

this has always been one of the biggest pros of gentoo for me - where
everything is a stream of data even the OS is like a slipstream.
updating many gentoos however can be a big issue and I do try to keep
similar boxes similar hardware because of it -- allowing me to test
updates before they get rolled out, and also allows me to add in crucial
use flags (dlz, openssl) when they suddenly become required; great to
figure out on a test machine first and then roll out x30 rather than
figure out 30times over!

Because of LVM/LUKS i have used initrd for a long time but i can
understand why the migration sucks - first install and testing and then
maintenance thereafter.  Going up to udev200 was scary enough. . . scary
because of that remote system status on NIC naming!
Equally we don't always have the benefit of a secondary identical
monster server to test new configurations on.

i almost would like to request tighter integration between
portage/kernel building/initrd but i'm not convinced the ubuntu way is
the correct way as that leads to customisations breaking systems, and
gentoo is all about customisation, making the OS fit the hardware.

>
>> It may be acceptable for you... but do not expect everyone will accept
>> your setup.
> Don't mind me, I'm just looking for the logic.  Feel free to explain it to me.
>
>> Regards,
>> Alon
>>

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Mon, 19 Aug 2013 17:11:46 +0100, thegeezer wrote:

> i almost would like to request tighter integration between
> portage/kernel building/initrd

The kernel build system can also build the initramfs if you give it the
location of the config file. That way the initramfs is built for each
kernel, using the currently installed versions of the various tools.


-- 
Neil Bothwick

This virus requires Microsoft Windows XP

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 00:20, Neil Bothwick wrote:
> On Mon, 19 Aug 2013 17:11:46 +0100, thegeezer wrote:
>
>> i almost would like to request tighter integration between
>> portage/kernel building/initrd
>
> The kernel build system can also build the initramfs if you give it the
> location of the config file. That way the initramfs is built for each
> kernel, using the currently installed versions of the various tools.

Yes, it's a little bit easier then manually adding a new initramfs.
But as I update userspace more frequently then the kernel, that would
still lead to a version discrepency.
I need to always remember to rebuild the initramfs when a part of
userspace that sits in the initramfs is updated. An automatic option there
would be usefull.
If it were included into the kernel, I would need to rebuild the kernel
after every update. Just redoing the initramfs is less of a waste of CPU.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Tue, 20 Aug 2013 07:44:41 +0200, J. Roeleveld wrote:

> > The kernel build system can also build the initramfs if you give it
> > the location of the config file. That way the initramfs is built for
> > each kernel, using the currently installed versions of the various
> > tools.  
> 
> Yes, it's a little bit easier then manually adding a new initramfs.
> But as I update userspace more frequently then the kernel, that would
> still lead to a version discrepency.
> I need to always remember to rebuild the initramfs when a part of
> userspace that sits in the initramfs is updated. An automatic option
> there would be usefull.
> If it were included into the kernel, I would need to rebuild the kernel
> after every update. Just redoing the initramfs is less of a waste of
> CPU.

Not really, because make is intelligent enough to no bother recompiling
anything for which the source has not changed.


-- 
Neil Bothwick

Of all the people I've met you're certainly one of them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 12:03, Neil Bothwick wrote:
> On Tue, 20 Aug 2013 07:44:41 +0200, J. Roeleveld wrote:
>
>> > The kernel build system can also build the initramfs if you give it
>> > the location of the config file. That way the initramfs is built for
>> > each kernel, using the currently installed versions of the various
>> > tools.
>>
>> Yes, it's a little bit easier then manually adding a new initramfs.
>> But as I update userspace more frequently then the kernel, that would
>> still lead to a version discrepency.
>> I need to always remember to rebuild the initramfs when a part of
>> userspace that sits in the initramfs is updated. An automatic option
>> there would be usefull.
>> If it were included into the kernel, I would need to rebuild the kernel
>> after every update. Just redoing the initramfs is less of a waste of
>> CPU.
>
> Not really, because make is intelligent enough to no bother recompiling
> anything for which the source has not changed.

True, but why recompile the kernel just to redo the initramfs?
As mentioned, I don't update/recompile the kernel as often.
"genkernel" puts the initramfs where it needs to be, kernel-make doesn't.

--
Joost

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Tue, 20 Aug 2013 14:10:21 +0200, J. Roeleveld wrote:

> > Not really, because make is intelligent enough to no bother
> > recompiling anything for which the source has not changed.  
> 
> True, but why recompile the kernel just to redo the initramfs?
> As mentioned, I don't update/recompile the kernel as often.
> "genkernel" puts the initramfs where it needs to be, kernel-make
> doesn't.

That depends on your needs. The reason I do it this way is so that the
initramfs is locked to the kernel. Once that kernel boots, it will always
boot because the initramfs cannot be changed. If I make a change to the
initramfs, that's a new kernel and however broken it may be, the old one
will still work.

The kernel and initramfs are so closely coupled, it just seems sensible
to keep them in the same file, since neitherof them is any use without
the other.


-- 
Neil Bothwick

All mail what i send is thoughly proof-red, definately!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-20 8:22 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 20 Aug 2013 14:10:21 +0200, J. Roeleveld wrote:
>
>>> Not really, because make is intelligent enough to no bother
>>> recompiling anything for which the source has not changed.
>>
>> True, but why recompile the kernel just to redo the initramfs?
>> As mentioned, I don't update/recompile the kernel as often.
>> "genkernel" puts the initramfs where it needs to be, kernel-make
>> doesn't.
>
> That depends on your needs. The reason I do it this way is so that the
> initramfs is locked to the kernel. Once that kernel boots, it will always
> boot because the initramfs cannot be changed. If I make a change to the
> initramfs, that's a new kernel and however broken it may be, the old one
> will still work.

So, you're saying that whoever it was that said that some userland files 
(that the initramfs 'refers to') could get updated, causing it to get 
out of sync - and presumably causing it to fail to boot if/when you 
rebooted - was wrong?

The main thing about this whole initramfs thing is, like Dale, I just 
don't understand it. I understand grub and grub.conf. I understand 
enough about compiling a kernel to be able to get it done and be 
reasonably sure it is done right.

But if my system ever failed to boot because of a problem with the 
initramfs, I basically would be hosed.

> The kernel and initramfs are so closely coupled, it just seems sensible
> to keep them in the same file, since neitherof them is any use without
> the other.

See above...

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]

On Tue, 20 Aug 2013 10:08:02 -0400, Tanstaafl wrote:

> > That depends on your needs. The reason I do it this way is so that the
> > initramfs is locked to the kernel. Once that kernel boots, it will
> > always boot because the initramfs cannot be changed. If I make a
> > change to the initramfs, that's a new kernel and however broken it
> > may be, the old one will still work.  
> 
> So, you're saying that whoever it was that said that some userland
> files (that the initramfs 'refers to') could get updated, causing it to
> get out of sync - and presumably causing it to fail to boot if/when you 
> rebooted - was wrong?

I though the post about a failure to boot was due to the kernel and
initrd getting out of sync, a definite problem. Having slightly different
versions of busybox in the initramfs and / isn't going to cause a
problem. If it worked yesterday, why would it not work today?

> The main thing about this whole initramfs thing is, like Dale, I just 
> don't understand it. I understand grub and grub.conf. I understand 
> enough about compiling a kernel to be able to get it done and be 
> reasonably sure it is done right.
> 
> But if my system ever failed to boot because of a problem with the 
> initramfs, I basically would be hosed.

I was the same. I learned about GRUB and then I understood it. Then I
switched to Gentoo and learned about kernel compilation and then I
understood it. A while ago, i had a need for an initramfs, so I learned
about it and now I understand it. Somewhere in this sequence I also
switched to GRUB2, which i previously had no knowledge of.

Do you see the pattern, your lack of understanding is not a failing of
the software? This is not a technological point, or even a political one,
it is about being outside of your comfort zone. Using Gentoo is an
exercise in expanding your comfort zone.


-- 
Neil Bothwick

If Bill Gates had a dime for every time a Windows box crashed...
 ...Oh, wait a minute, he already does.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Neil Bothwick wrote:
> On Tue, 20 Aug 2013 10:08:02 -0400, Tanstaafl wrote:
>
>> The main thing about this whole initramfs thing is, like Dale, I just
>> don't understand it. I understand grub and grub.conf. I understand
>> enough about compiling a kernel to be able to get it done and be
>> reasonably sure it is done right.
>>
>> But if my system ever failed to boot because of a problem with the
>> initramfs, I basically would be hosed.
>
> I was the same. I learned about GRUB and then I understood it. Then I
> switched to Gentoo and learned about kernel compilation and then I
> understood it. A while ago, i had a need for an initramfs, so I learned
> about it and now I understand it. Somewhere in this sequence I also
> switched to GRUB2, which i previously had no knowledge of.
>
> Do you see the pattern, your lack of understanding is not a failing of
> the software? This is not a technological point, or even a political one,
> it is about being outside of your comfort zone. Using Gentoo is an
> exercise in expanding your comfort zone.
>
>


It's not about comfort zone for me.  It's that I do NOT want to use a
init thingy. Period.  Real simple.  I had fits with that thing in the
past and I do not want to revisit the issue again, certainly not on
Gentoo.  I'm not going to revisit hal either.  I forgot the name but not
the lesson I learned from it.

I might also add, I switched to grub2 a while back. The old grub worked
fine but I wanted to go ahead and switch to the new grub since it seems
to be ready and stable.  Was that outside my comfort zone?  I switched
anyway because I was ready to do it.  No real need but I had the
experience of the old grub to rely on.  At least the old grub never
failed me.  Init thingys has, many times.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 2684 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Tue, 20 Aug 2013 09:37:47 -0500, Dale wrote:

> > Do you see the pattern, your lack of understanding is not a failing of
> > the software? This is not a technological point, or even a political
> > one, it is about being outside of your comfort zone. Using Gentoo is
> > an exercise in expanding your comfort zone.

> It's not about comfort zone for me.  It's that I do NOT want to use a
> init thingy. Period.  Real simple.  I had fits with that thing in the
> past and I do not want to revisit the issue again, certainly not on
> Gentoo.  I'm not going to revisit hal either.  I forgot the name but not
> the lesson I learned from it.

I realise that, you do have a real knack for breaking things, and thus a
strong motivation for avoiding anything new, or that bit you in the past.

> I might also add, I switched to grub2 a while back. The old grub worked
> fine but I wanted to go ahead and switch to the new grub since it seems
> to be ready and stable.  Was that outside my comfort zone?

almost certainly. It is for anyone used to legacy GRUB. Is it outside of
your comfort now? No, because you took the trouble to learn how to use
it. I was exactly the same with GRUB2, and with init doodahs. now I am
not only capable of using and breaking both, but also of having a good go
at cleaning up the mess afterwards :)


-- 
Neil Bothwick

What did the first man to discover you can get milk from cows think he
was doing? - anon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Neil Bothwick wrote:
> On Tue, 20 Aug 2013 09:37:47 -0500, Dale wrote:
>
>>> Do you see the pattern, your lack of understanding is not a failing of
>>> the software? This is not a technological point, or even a political
>>> one, it is about being outside of your comfort zone. Using Gentoo is
>>> an exercise in expanding your comfort zone.
>
>> It's not about comfort zone for me.  It's that I do NOT want to use a
>> init thingy. Period.  Real simple.  I had fits with that thing in the
>> past and I do not want to revisit the issue again, certainly not on
>> Gentoo.  I'm not going to revisit hal either.  I forgot the name but not
>> the lesson I learned from it.
>
> I realise that, you do have a real knack for breaking things, and thus a
> strong motivation for avoiding anything new, or that bit you in the past.
>
>> I might also add, I switched to grub2 a while back. The old grub worked
>> fine but I wanted to go ahead and switch to the new grub since it seems
>> to be ready and stable.  Was that outside my comfort zone?
>
> almost certainly. It is for anyone used to legacy GRUB. Is it outside of
> your comfort now? No, because you took the trouble to learn how to use
> it. I was exactly the same with GRUB2, and with init doodahs. now I am
> not only capable of using and breaking both, but also of having a good go
> at cleaning up the mess afterwards :)
>
>


You missed my whole point.  You can't claim it is because it is new and
outside my comfort zone because even tho grub2 was new to me, it was not
outside my comfort zone.  Grub2 is very little like the old grub.  It is
just plain outright new actually.  The thing is, grub has a track record
of WORKING for ME.  The init thingy has a record of FAILING for me.  The
init thing has not changed just the tools that make them have changed. 
The point is, I don't care what tool is used to make the init thingy, I
don't want to use one.  If it fails, I don't know how to fix it any
better today than I did back then.

To put it simply, if a init thingy is forced on me, the first time this
rig fails to boot and I can't figure out how to fix it, I'll be
installing some distro that is at least faster to reinstall.  This isn't
the first time I have posted that either.  I love my Gentoo but if it
breaks and I can't fix it, it is of no use to me on my puter.  I love my
little car that I have had for almost 20 years but if it stops getting
me from point A to point B then I need a different car.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3578 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

On Tue, 20 Aug 2013 16:16:31 -0500, Dale wrote:

> You missed my whole point.  You can't claim it is because it is new and
> outside my comfort zone because even tho grub2 was new to me, it was not
> outside my comfort zone.  Grub2 is very little like the old grub.  It is
> just plain outright new actually.  The thing is, grub has a track record
> of WORKING for ME.

Well, the post of mine you quoted wasn't in response to your comments.
But the point remains, not for you but for the quoted post I was actually
replying to. An initramfs is n more magic than GRUB, or LVM,, or many
other software components. You don't understand it until you take the
time to learn about it. That was true of you with GRUB2 and is true of
the post I replied to about an initramfs.

> The init thingy has a record of FAILING for me.  The
> init thing has not changed just the tools that make them have changed. 

That's not actually true. Ten years ago you'd have been using a 2.4
kernel with an initrd. That is quite different to how the 2.6/3 kernels
use an initramfs.

> The point is, I don't care what tool is used to make the init thingy, I
> don't want to use one.  If it fails, I don't know how to fix it any
> better today than I did back then.

I am not suggesting that you should use an initramfs. I was merely
pointing out that having no current understanding or experience of
something is no reason not to gain both. Please note that this was posted
in response to a post discussing lack of experience of such things, which
does not apply to you, even though your experience is somewhat tangential.

> To put it simply, if a init thingy is forced on me, the first time
> this rig fails to boot and I can't figure out how to fix
> it, I'll be installing some distro that is at least faster to reinstall.
> This isn't the first time I have posted that either.  I love my Gentoo
> but if it breaks and I can't fix it, it is of no use to me on my puter.

That's a fair comment. Objecting to something that is broken for you is
completely different to avoiding things just because they are new or
different.

But them I'm the sort of person that's about to install systemd on a test
VM just to see what all the fuss is about (I probably won't like it
because I'll miss those little green OKs when booting :).


-- 
Neil Bothwick

Top Oxymorons Number 5: Twelve-ounce pound cake

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 20/08/2013 16:08, Tanstaafl wrote:
> On 2013-08-20 8:22 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
>> On Tue, 20 Aug 2013 14:10:21 +0200, J. Roeleveld wrote:
>>
>>>> Not really, because make is intelligent enough to no bother
>>>> recompiling anything for which the source has not changed.
>>>
>>> True, but why recompile the kernel just to redo the initramfs?
>>> As mentioned, I don't update/recompile the kernel as often.
>>> "genkernel" puts the initramfs where it needs to be, kernel-make
>>> doesn't.
>>
>> That depends on your needs. The reason I do it this way is so that the
>> initramfs is locked to the kernel. Once that kernel boots, it will always
>> boot because the initramfs cannot be changed. If I make a change to the
>> initramfs, that's a new kernel and however broken it may be, the old one
>> will still work.
> 
> So, you're saying that whoever it was that said that some userland files
> (that the initramfs 'refers to') could get updated, causing it to get
> out of sync - and presumably causing it to fail to boot if/when you
> rebooted - was wrong?
> 
> The main thing about this whole initramfs thing is, like Dale, I just
> don't understand it. I understand grub and grub.conf. I understand
> enough about compiling a kernel to be able to get it done and be
> reasonably sure it is done right.


What part don't you understand? How to use it, how it works, how to
build it?

The full correct way to test such a thing is to configure and build the
new kernel, build the initramfs, install the whole lot, add new stanza
to grub.conf and reboot. If it fails, reboot with the old kernel, then
investigate.

You have servers and the only time you would really be building a new
kernel is to do an update you plan to use, correct? Presumably you have
a defined maintenance window for that, so make full use of the time. You
can copy debian's scheme in grub.conf to configure a known good fallback
that will be used if the boot fails.



> 
> But if my system ever failed to boot because of a problem with the
> initramfs, I basically would be hosed.

You can't fix them (well, not easily), you just rebuild them.
If it helps, think of an initramfs as a minimal system image that is
compressed and stored in a file. The kernels mounts it at /, uses it
briefly to looad some drivers and do kernel-space setups then invokes
some internal magic to toss it and mount the real (and now accessible) /
correctly. It's magic because you cannot do this anymore once init has
started


> 
>> The kernel and initramfs are so closely coupled, it just seems sensible
>> to keep them in the same file, since neitherof them is any use without
>> the other.
> 
> See above...
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Mon, 19 Aug 2013 17:30:16 +0300, Alon Bar-Lev wrote:

> The files within the initramfs generation tool are compiled using
> different tool than portage, they are not updated when distribution is
> updated, and they are not even at same version within portage tree.
> 
> It may be acceptable for you... but do not expect everyone will accept
> your setup.

That's a limitation of dracut, not of the initramfs per se.


-- 
Neil Bothwick

"What I need is a list of specific unknown problems we will encounter."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Alan McKinnon]

On 19/08/2013 16:20, Alecks Gates wrote:
> Can someone please explain to me what's so hard and/or complicated
> about making an initramfs?  At this point in time it's extremely
> simple for me, but I only manage relatively simple systems (although
> I'd like that to change soon).  All I do is add one extra line (for
> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
> procedure.

Precisely. It's not hard, it's actually almost automatable.

It's vastly simpler than configuring a kernel, something we all seem to
take in our stride and wear as badges of honour. It's arguably even
easier than figuring grub out the first time through.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Stefan G. Weichinger]

Am 19.08.2013 22:40, schrieb Alan McKinnon:
> On 19/08/2013 16:20, Alecks Gates wrote:
>> All I do is add one extra line (for
>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
>> procedure.
> 
> Precisely. It's not hard, it's actually almost automatable.
> 
> It's vastly simpler than configuring a kernel, something we all seem to
> take in our stride and wear as badges of honour. It's arguably even
> easier than figuring grub out the first time through.

As I mentioned some weeks ago I also have my quick-and-dirty script that
runs the stuff necessary ... instead of using genkernel I "forked" (a
big word for my messed up script) some parts of it and it works fine so
far (throws quite some errors that just don't matter).

Maybe some good examples would help? At least for the people unsure
about generating the initramfs and/or dracut?

Stefan

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[William Kenworthy]

On 19/08/13 22:20, Alecks Gates wrote:
> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>
...
> 
> Can someone please explain to me what's so hard and/or complicated
> about making an initramfs?  At this point in time it's extremely
> simple for me, but I only manage relatively simple systems (although
> I'd like that to change soon).  All I do is add one extra line (for
> example - "dracut -H --kver=3.11.0-rc6") to my kernel install
> procedure.
> 
> Granted, the only reason I have an initramfs is for the plymouth
> splash screen (other systems aren't desktops) -- but from everything I
> can see it's not too complicated otherwise.
> 

Ive had one employment threatening episode when a redhat system using
initramfs wouldnt boot (my fault in fact, I got out of sync with
initramfs/kernel version on the install) and it was an important server.
 Since then I eliminated them and surprise never had a failure until
recently when I started using genkernel.  So now I have mostly systems
using initramfs, 3 customised, one of which will no longer hibernate to
disk and I am suspecting the initrd.

Its fine when it all works, but the question in this case is how many
times do I want to crash the system trying to fault-find it?  Its not
that it doesn't work, or that its generally reliable but that its an
unwanted/unneeded extra point of failure built around an extra workload.
 Distros like Redhat have specialists that do that, we dont and we are
NOT competing in Redhats market space so "why"?

I actually think working towards a read-only /usr is a good idea and am
ambivalent about it being in the root, its the baggage thats being
worked in alongside this thats the problem for me.

BillK

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-08-18 10:55 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> And, putting aside systemd and getting back on topic to the council's
>> decision of (eventually) not supporting separated /usr without an
>> initramfs; have you ever stopped to consider that, perhaps, that's the
>> best *technical*  decision? (*gasp*)
>
>
> That is *not* the concern here, Canek, and that should be obvious from the
> comments here.

It's not obvious at all.

> Repeat: the primary concern is *not* about separate /usr without initramfs.

See the last batch of emails; but even before a lot of people stated
that their concern was the separate /usr withouth an initramfs
dropping support.

> The primary concern is that systemd will eventually be shoved down our
> throats whether we want it or not, and using eudev or mdev  or *anything*
> other than systemd (ie OpenRC/eudev) will.

That makes no sense: the OpenRC maintainer is the one pushing the change.

> And the track record speaks for itself, regardless of *any* promises that it
> won't, it is obvious to anyone with eyes to see and ears to hear that this
> is a blatant LIE.

Seriosly? If you don't trust the OpenRC maintainer then you are
running out of options.

> Everything that is happening is simply setting the stage for precisely that.

Nah. That's FUD, simply. Again, dropping support for separate /usr
without initramfs is being pushed by the OpenRC maintainer, because it
needs that to effectively competing with systemd.

Really, read the Gentoo Project ML.

>> When you have almost all distributions converging on that, and even
>> *the OpenRC maintainer*  (which is the one pushing this, BTW, not the
>> systemd guys) supporting that decision, don't you think that perhaps,
>> just*perhaps*, everybody screaming about the sky falling (which, BTW,
>>
>> they are certainly noisy, but I really don't think are that many) are
>> overreacting and even (*gasp* again) wrong?
>
>
> Again, the main issue is not about separate /usr, so please stop trying to
> deflect the subject...

Stop spreding FUD.

> In my opinion, the single largest reason to *not* switch to systemd in
> gentoo is the source of the push - in other words, it is coming from Fedora
> - and GNOME lovers are the maintainers.

Who's advocating for switching Gentoo to systemd? Citation please.

Really guys, get your facts straight.

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

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Mark David Dumlao]

On Mon, Aug 19, 2013 at 5:54 AM, pk <peterk2@coolmail.se> wrote:
> On 2013-08-18 23:08, Mick wrote:
>
>> I honestly cannot understand why we/Gentoo are allowing the RHL
>> monolithic development philosophy to break what we have.  Is
>> Poettering the only developer available to the Linux world?  Are
>> RHL dictating what path Debian and its cousin distros should
>> follow?
>
> Problem is that Linux is dependent on udev and udev is in the hands of
> Kay Sievers which also develops systemd together with Lennart
> Poettering which in turn used to be a Gnome developer... With that
> said, what I cannot understand is why people advocating systemd (and
> the kitchen-and-sink model) are using Gentoo in the first place. Are
> they just trying to make the rest of the Linux distro landscape as
> miserable as Fedora? Why don't they stay with Fedora instead of trying
> to turn Gentoo into Fedora?
>

This kind of response has been repeatedly grating on my nerves
on this mailing list. It's just so TECHNICALLY WRONG, but more than
that I feel that it hints at a deeper problem about user attitudes and the
need to act like a know-it-all that is so prevalent on this mailing list.

Systemd is _not_ a monolithic design. I don't know how anyone who
has taken even a casual glance at it, or its documentation, can say
otherwise. It's so reminiscent of qmail or postfix, where you have a
bunch of small programs each doing one thing well, but for init
systems rather than for mail, that it's just one step away from being
the kind of program you show to kids to teach them how to Unix.

Scroll up further on the random systemd rants on this mailing list and
you'll "learn" that systemd has a binary / xml configuration format
(it doesn't, it's plaintext INI, like samba) that requires binary code to
run daemons (um, no it doesn't), or that thanks to systemd, old,
perfectly working servers will just stop running...

You know what I think? You can't understand why some people
like or want to support systemd because you don't _want_ to
understand. It requires you to learn something new. There's an
old problem, _mostly_, but not entirely, solved, where we've swept
the ugly parts out of sight so that they don't bug you. The parts of
systemd that you don't understand why they should be there
are the parts that deal with those ugly things you don't want to learn.
I know that feeling, of being forced to learn something new and thinking
"do I really have to?" and I know I hate it. It's the same reason why
RTFM is considered rude. But it's basically the appropriate response
here. You wanna figure out why systemd does what it does? RTFM.

Yes, system initialization SHOULD be simple. Just like
mail or web SHOULD be. And heck, If you want to run some bash
script to do your web or mail or init, nobody's stopping you.

But somebody, somewhere, is going to want features, which is why
we have apache or postfix, and what-have-you. And if other projects want
to use those features, they're free to want to require those software
as they please. You don't like it? Don't use those projects. Or fork
them. But stop acting like a pompous know-it-all, quoting software
design witticisms as if you've actually looked at the problem domain
even half as seriously as the developers involved.

Oh but systemd is going to eat up all our software so that nothing
will run without it! Don't be ridiculous. They said that about Emacs,
Java, Lisp, GNOME, kdepim, The Browser(tm), etc etc etc. If you've
paid any attention at all to the history of software, it's obvious that it's
not happening. Why the hell would apache, which runs on windows,
require systemd? Or firefox? Or google chrome? Or qmail? Or postfix?
Or MySQL? Or samba? etc etc etc

If there's anything surprising, it's that you seriously thought a software
development house (cough cough Redhat) wouldn't try to dogfood their
own stuff into their other products (cough cough GNOME) _which
already have forks by the way_, so what are you worried about?
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/19/2013 12:52 AM, Mark David Dumlao wrote:
> On Mon, Aug 19, 2013 at 5:54 AM, pk <peterk2@coolmail.se> wrote:
>> On 2013-08-18 23:08, Mick wrote:
>>
>>> I honestly cannot understand why we/Gentoo are allowing the RHL
>>> monolithic development philosophy to break what we have.  Is
>>> Poettering the only developer available to the Linux world?  Are
>>> RHL dictating what path Debian and its cousin distros should
>>> follow?
>>
>> Problem is that Linux is dependent on udev and udev is in the hands of
>> Kay Sievers which also develops systemd together with Lennart
>> Poettering which in turn used to be a Gnome developer... With that
>> said, what I cannot understand is why people advocating systemd (and
>> the kitchen-and-sink model) are using Gentoo in the first place. Are
>> they just trying to make the rest of the Linux distro landscape as
>> miserable as Fedora? Why don't they stay with Fedora instead of trying
>> to turn Gentoo into Fedora?
>>
> 
> This kind of response has been repeatedly grating on my nerves
> on this mailing list. It's just so TECHNICALLY WRONG, but more than
> that I feel that it hints at a deeper problem about user attitudes and the
> need to act like a know-it-all that is so prevalent on this mailing list.
> 
> Systemd is _not_ a monolithic design. I don't know how anyone who
> has taken even a casual glance at it, or its documentation, can say
> otherwise. It's so reminiscent of qmail or postfix, where you have a
> bunch of small programs each doing one thing well, but for init
> systems rather than for mail, that it's just one step away from being
> the kind of program you show to kids to teach them how to Unix.

It's not monolithic? Okay, then why won't logind work separately after
systemd-206? QED. If you cannot separate its parts and use them
piecemeal, it's monolithic. Period. Separation of concerns within a
project as vast as systemd is to be expected if you want to be able to
read the source. That doesn't mean that systemd isn't monolithic when
used in an actual system. Systemd swallowed udev and is doing whatever
they can to tie logind behavior into the init system to get people to
use it. That's the very definition of monolithic.

> 
> Scroll up further on the random systemd rants on this mailing list and
> you'll "learn" that systemd has a binary / xml configuration format
> (it doesn't, it's plaintext INI, like samba) that requires binary code to
> run daemons (um, no it doesn't), or that thanks to systemd, old,
> perfectly working servers will just stop running...
> 
> You know what I think? You can't understand why some people
> like or want to support systemd because you don't _want_ to
> understand. It requires you to learn something new. There's an
> old problem, _mostly_, but not entirely, solved, where we've swept
> the ugly parts out of sight so that they don't bug you. The parts of
> systemd that you don't understand why they should be there
> are the parts that deal with those ugly things you don't want to learn.
> I know that feeling, of being forced to learn something new and thinking
> "do I really have to?" and I know I hate it. It's the same reason why
> RTFM is considered rude. But it's basically the appropriate response
> here. You wanna figure out why systemd does what it does? RTFM.
> 
> Yes, system initialization SHOULD be simple. Just like
> mail or web SHOULD be. And heck, If you want to run some bash
> script to do your web or mail or init, nobody's stopping you.
> 
> But somebody, somewhere, is going to want features, which is why
> we have apache or postfix, and what-have-you. And if other projects want
> to use those features, they're free to want to require those software
> as they please. You don't like it? Don't use those projects. Or fork
> them. But stop acting like a pompous know-it-all, quoting software
> design witticisms as if you've actually looked at the problem domain
> even half as seriously as the developers involved.
> 
> Oh but systemd is going to eat up all our software so that nothing
> will run without it! Don't be ridiculous. They said that about Emacs,
> Java, Lisp, GNOME, kdepim, The Browser(tm), etc etc etc. If you've
> paid any attention at all to the history of software, it's obvious that it's
> not happening. Why the hell would apache, which runs on windows,
> require systemd? Or firefox? Or google chrome? Or qmail? Or postfix?
> Or MySQL? Or samba? etc etc etc
> 
> If there's anything surprising, it's that you seriously thought a software
> development house (cough cough Redhat) wouldn't try to dogfood their
> own stuff into their other products (cough cough GNOME) _which
> already have forks by the way_, so what are you worried about?
> 

What he and others are worried about is a single company homogenizing
the distribution landscape, starting at the bottom with the init system.
By making every distro dependent on them for init, they can
systematically homogenize the software ecosystem and kill (mainstream)
FOSS. This would benefit their business immensely. It's hard to deny
that this isn't being attempted with the spread of systemd and GNOME
(which has Red Hat devs working on it) requiring systemd. It's a perfect
storm and the community has drank the kool-aid. Gentoo is considered the
last bastion of choice for most users, lest we go as far down as
Slackware and LFS to maintain things. While Gentoo (for now) states that
systemd will not become the default, other distros (Arch) claimed the
very same thing before they pushed systemd on their users. There is
little reason to trust things won't go downhill from here. I'd love to
be wrong (seriously, Gentoo's been a great experience for me), but all
signs point to Gentoo falling to systemd as well. All it takes is a
majority vote among the Council and it happens.

Homogenizing the software stack will kill FOSS and turn Linux into
another corporate OS.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Mark David Dumlao]

On Mon, Aug 19, 2013 at 3:53 PM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 08/19/2013 12:52 AM, Mark David Dumlao wrote:
>> On Mon, Aug 19, 2013 at 5:54 AM, pk <peterk2@coolmail.se> wrote:
>>> On 2013-08-18 23:08, Mick wrote:
>>>
>>>> I honestly cannot understand why we/Gentoo are allowing the RHL
>>>> monolithic development philosophy to break what we have.  Is
>>>> Poettering the only developer available to the Linux world?  Are
>>>> RHL dictating what path Debian and its cousin distros should
>>>> follow?
>>>
>>> Problem is that Linux is dependent on udev and udev is in the hands of
>>> Kay Sievers which also develops systemd together with Lennart
>>> Poettering which in turn used to be a Gnome developer... With that
>>> said, what I cannot understand is why people advocating systemd (and
>>> the kitchen-and-sink model) are using Gentoo in the first place. Are
>>> they just trying to make the rest of the Linux distro landscape as
>>> miserable as Fedora? Why don't they stay with Fedora instead of trying
>>> to turn Gentoo into Fedora?
>>>
>>
>> This kind of response has been repeatedly grating on my nerves
>> on this mailing list. It's just so TECHNICALLY WRONG, but more than
>> that I feel that it hints at a deeper problem about user attitudes and the
>> need to act like a know-it-all that is so prevalent on this mailing list.
>>
>> Systemd is _not_ a monolithic design. I don't know how anyone who
>> has taken even a casual glance at it, or its documentation, can say
>> otherwise. It's so reminiscent of qmail or postfix, where you have a
>> bunch of small programs each doing one thing well, but for init
>> systems rather than for mail, that it's just one step away from being
>> the kind of program you show to kids to teach them how to Unix.
>
> It's not monolithic? Okay, then why won't logind work separately after
> systemd-206?

Here's the release notes for 205:

        * logind has been updated to make use of scope and slice units
          for managing user sessions. As a user logs in he will get
          his own private slice unit, to which all sessions are added
          as scope units. We also added support for automatically
          adding an instance of user@.service for the user into the
          slice. Effectively logind will no longer create cgroup
          hierarchies on its own now, it will defer entirely to PID 1
          for this by means of scope, service and slice units. Since
          user sessions this way become entities managed by PID 1
          the output of "systemctl" is now a lot more comprehensive.

That's why. Logind used to have more scope than it used to, now it
defers some of its functionality to other programs so that it could do
it's "one thing well". That's the very definition of "not monolithic".

Why can't you make it work separately after 205? Because 205 is
a MAJOR VERSION BUMP on an actively developed program.
Nobody's yet written a program that fills the functionality that logind
depends on. Better evidence is that it could work outside of systemd
in the first place. You don't expect public APIs to remain stable
past major version bumps.

So there, once again a long, long pompous rant of acting like a
know-it-all about stuff you've never bothered reading.
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-19 10:22 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> Why can't you make it work separately after 205? Because 205 is
> a MAJOR VERSION BUMP on an actively developed program.

205 is a major version bump over ... 204?

Surely you jest?

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[J. Roeleveld]

On Tue, August 20, 2013 12:51, Tanstaafl wrote:
> On 2013-08-19 10:22 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
>> Why can't you make it work separately after 205? Because 205 is
>> a MAJOR VERSION BUMP on an actively developed program.
>
> 205 is a major version bump over ... 204?
>
> Surely you jest?

I was wondering the same...
From the versioning, it is definitely not immediately obvious.

--
Joost

Re: [gentoo-user] Optional /usr merge in Gentoo

[Thomas Mueller]

On the issue of whether ZFS can be shipped with the Linux kernel, FreeBSD includes ZFS with the kernel, binary and source.

So does that mean it would be OK for Linux too?

FreeBSD has a different license (BSD) than Linux (GPL 2 or 3).

I am not a lawyer!

Tom

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 04:04, Thomas Mueller wrote:
> On the issue of whether ZFS can be shipped with the Linux kernel, FreeBSD includes ZFS 
> with the kernel, binary and source.
> 
> So does that mean it would be OK for Linux too?

No.

> FreeBSD has a different license (BSD) than Linux (GPL 2 or 3).

Please read file COPYING in the kernel sources, the Linux kernel ships
with license GPL-2

Not a later version at your choice (2.x) and certainly never GPL-3

The issue is that the Linux kernel devs consider the license terms for
ZFS to be incompatible with GPL-2.0 and therefore ZFS cannot be
redistributed as a Linux kernel module.

There's nothing in the GPL-2 to stop you as a user from building and
running ZFS on Linux, as GPL does not interfere with your right to run
whatever you wish. The GPL only kicks in when code is redistributed.

The BSD license has none of these conditions, in layman terms that
license essentially says "you can take this code and pretty much do with
it whatever you want, we don't care"

> I am not a lawyer!
> 
> Tom
> 
> 





-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> The issue is that the Linux kernel devs consider the license terms for
> ZFS to be incompatible with GPL-2.0 and therefore ZFS cannot be
> redistributed as a Linux kernel module.

Isn't it strange that those people seem to have less problems with closed 
source than with a license that gives more freedom than the GPL? But 
you are correct that the problem seem to be humans and not a license text.

> There's nothing in the GPL-2 to stop you as a user from building and
> running ZFS on Linux, as GPL does not interfere with your right to run
> whatever you wish. The GPL only kicks in when code is redistributed.

There is nothing non-void in the GPL that stops you from distributing binaries.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 09:53, Joerg Schilling wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> The issue is that the Linux kernel devs consider the license terms for
>> ZFS to be incompatible with GPL-2.0 and therefore ZFS cannot be
>> redistributed as a Linux kernel module.
> 
> Isn't it strange that those people seem to have less problems with closed 
> source than with a license that gives more freedom than the GPL? But 
> you are correct that the problem seem to be humans and not a license text.

You are aware that the GPL was not really intended to be used together
with other licenses? It was really intended to create an entire
operating system, all of which was 100% licensed as GPL, all of which
comprise an original work written from scratch

Stallman never makes this claim as bluntly as I've said it here, but
it's the only intelligent reading of his intent as far as I can make
out. This is why so many arguments arise over the GPL, the wording of
that license was not really intended to have it co-exist with other
licenses.

That's how I see it anyway.

> 
>> There's nothing in the GPL-2 to stop you as a user from building and
>> running ZFS on Linux, as GPL does not interfere with your right to run
>> whatever you wish. The GPL only kicks in when code is redistributed.
> 
> There is nothing non-void in the GPL that stops you from distributing binaries.

That's a question of packaging and bundling, which is not covered by the
GPL. But kernel code and kernel modules are not mere bundles, they are
derivative works by virtue of how tightly they integrate with the
kernel, and how the code can only ever run unchanged on Linux.

That is how ZFS as a fuse module works, no license issues with the
kernel there at all.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> > Isn't it strange that those people seem to have less problems with closed 
> > source than with a license that gives more freedom than the GPL? But 
> > you are correct that the problem seem to be humans and not a license text.
>
> You are aware that the GPL was not really intended to be used together
> with other licenses? It was really intended to create an entire
> operating system, all of which was 100% licensed as GPL, all of which
> comprise an original work written from scratch

But it has been proven that you cannot create a 100% GPL OS.
More than 50% of all Linux distros are under different licenses...

> Stallman never makes this claim as bluntly as I've said it here, but
> it's the only intelligent reading of his intent as far as I can make
> out. This is why so many arguments arise over the GPL, the wording of
> that license was not really intended to have it co-exist with other
> licenses.

Stallman does not look at reality. The first GCC version in 1986 has been 
published under something I call GPLv0 and this license did not permit a legal 
use of the GCC in public.

The license was later converted to GPLv1 by using proposals I made but 
Stallman still only talks about what has been in GPLv0.

> > There is nothing non-void in the GPL that stops you from distributing binaries.
>
> That's a question of packaging and bundling, which is not covered by the
> GPL. But kernel code and kernel modules are not mere bundles, they are
> derivative works by virtue of how tightly they integrate with the
> kernel, and how the code can only ever run unchanged on Linux.

If a kernel uses ZFS, you have to decide on whether the kernel is a derivative 
work of ZFS or whether just a collective work exists.

_Using_ ZFS definitely does not make ZFS a derivative work.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:

> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> > > Isn't it strange that those people seem to have less problems with closed 
> > > source than with a license that gives more freedom than the GPL? But 
> > > you are correct that the problem seem to be humans and not a license text.
> >
> > You are aware that the GPL was not really intended to be used together
> > with other licenses? It was really intended to create an entire
> > operating system, all of which was 100% licensed as GPL, all of which
> > comprise an original work written from scratch
>
> But it has been proven that you cannot create a 100% GPL OS.
> More than 50% of all Linux distros are under different licenses...
>

Sorry, this should be: More than 50% of a typical Linux distro is 
under different licenses...

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 11:26, Joerg Schilling wrote:
> Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
> 
>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>
>>>> Isn't it strange that those people seem to have less problems with closed 
>>>> source than with a license that gives more freedom than the GPL? But 
>>>> you are correct that the problem seem to be humans and not a license text.
>>>
>>> You are aware that the GPL was not really intended to be used together
>>> with other licenses? It was really intended to create an entire
>>> operating system, all of which was 100% licensed as GPL, all of which
>>> comprise an original work written from scratch
>>
>> But it has been proven that you cannot create a 100% GPL OS.
>> More than 50% of all Linux distros are under different licenses...
>>
> 
> Sorry, this should be: More than 50% of a typical Linux distro is 
> under different licenses...


All we can state for sure is that no-one has yet created a fully 100%
GPL operating system. If you persuade FSF to relicense glibc to you as
GPL it *is* possible to do it for kernel and (a somewhat crippled)
userland. But not for firmware.

But this is beside the point, I was illustrating Stallman's intent, not
whether that intent could be realized or not.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 27/08/2013 11:08, Joerg Schilling wrote:
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>>> Isn't it strange that those people seem to have less problems with closed 
>>> source than with a license that gives more freedom than the GPL? But 
>>> you are correct that the problem seem to be humans and not a license text.
>>
>> You are aware that the GPL was not really intended to be used together
>> with other licenses? It was really intended to create an entire
>> operating system, all of which was 100% licensed as GPL, all of which
>> comprise an original work written from scratch
> 
> But it has been proven that you cannot create a 100% GPL OS.
> More than 50% of all Linux distros are under different licenses...
> 
>> Stallman never makes this claim as bluntly as I've said it here, but
>> it's the only intelligent reading of his intent as far as I can make
>> out. This is why so many arguments arise over the GPL, the wording of
>> that license was not really intended to have it co-exist with other
>> licenses.
> 
> Stallman does not look at reality. The first GCC version in 1986 has been 
> published under something I call GPLv0 and this license did not permit a legal 
> use of the GCC in public.
> 
> The license was later converted to GPLv1 by using proposals I made but 
> Stallman still only talks about what has been in GPLv0.


I didn't bring this up to discuss fine points of licenses. I brought it
up for those who might want to understand what the GPL is intended to
do; that can only be truly understood by determining what Stallman
intended. The GPL is a reflection of Stallman's intent, and can only be
truly understood in that light.

Whether the legal wording accurately matches his intent is another
matter altogether. I personally feel it doesn't, won't and cannot, for
reasons of psychology and philosophy, not for reasons of technology or
law. What the GPL tries to do and how it does it is quite foreign to
most who practice law. Humans don't like foreign concepts. Heck, GPL-2
doesn't even remotely read like something that came off a lawyer's desk.


> 
>>> There is nothing non-void in the GPL that stops you from distributing binaries.
>>
>> That's a question of packaging and bundling, which is not covered by the
>> GPL. But kernel code and kernel modules are not mere bundles, they are
>> derivative works by virtue of how tightly they integrate with the
>> kernel, and how the code can only ever run unchanged on Linux.
> 
> If a kernel uses ZFS, you have to decide on whether the kernel is a derivative 
> work of ZFS or whether just a collective work exists.
> 
> _Using_ ZFS definitely does not make ZFS a derivative work.

I never said it did. I was concentrating on those parts of ZFS that
interact with kernel internals - that might not be been entirely clear

You are making a spurious claim by saying "you have to decide on whether
the kernel is a derivative work of ZFS or ..."

In what possible way could the entire Linux kernel be considered a
derivative work of ZFS? That doesn't make any sense.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> >> That's a question of packaging and bundling, which is not covered by the
> >> GPL. But kernel code and kernel modules are not mere bundles, they are
> >> derivative works by virtue of how tightly they integrate with the
> >> kernel, and how the code can only ever run unchanged on Linux.
> > 
> > If a kernel uses ZFS, you have to decide on whether the kernel is a derivative 
> > work of ZFS or whether just a collective work exists.
> > 
> > _Using_ ZFS definitely does not make ZFS a derivative work.
>
> I never said it did. I was concentrating on those parts of ZFS that
> interact with kernel internals - that might not be been entirely clear

You wrote that modules become derivatives of the Linux kernel and this is the 
same as writing ZFS would become a kernel derivative.

The linux kernel does not come with a modern VFS implementation, so if you like 
to use ZFS on Linux you first need to provide a suitable VFS interface.
ZFS will not interact with the Linux kernel directly but with the expected VFS 
layer. Shouldn't it be possible to put this intermediate layer under a license 
that makes even the zealots happy?

> You are making a spurious claim by saying "you have to decide on whether
> the kernel is a derivative work of ZFS or ..."

If you go the non-lawful Stallman way and insist in a derivative work to be 
build, then the linux kernel is the derivative work. I prefer to assume that 
this just builds a collective work ;-)

> In what possible way could the entire Linux kernel be considered a
> derivative work of ZFS? That doesn't make any sense.

I am just quoting claims from Stallman ;-)

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-27 5:06 PM, Joerg Schilling 
<Joerg.Schilling@fokus.fraunhofer.de> wrote:
> You wrote that modules become derivatives of the Linux kernel and this is the
> same as writing ZFS would become a kernel derivative.

Just for clarification, I was talking about compiling ZFS support INTO 
the kernel, not running it as a module.

Do you claim that support for compiling ZFS directly into the kernel 
also does not violate the license?

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 28/08/2013 12:58, Tanstaafl wrote:
> On 2013-08-27 5:06 PM, Joerg Schilling
> <Joerg.Schilling@fokus.fraunhofer.de> wrote:
>> You wrote that modules become derivatives of the Linux kernel and this
>> is the
>> same as writing ZFS would become a kernel derivative.
> 
> Just for clarification, I was talking about compiling ZFS support INTO
> the kernel, not running it as a module.
> 
> Do you claim that support for compiling ZFS directly into the kernel
> also does not violate the license?
> 


Whether the code is compile in or a module makes no difference wrt
licenses as far as I know.

There's no limitation on *running* the code, you can fetch and patch and
edit and compile and run all you want and have it on as many of your (or
the company's) machines as you want - neither license interferes with
your right to do that.

You may not redistribute the code though.

A common misconception with these license is that they have something to
do with whether you may run the code or not. That is incorrect. Free
licenses are all about redistribution and your obligations about sharing
when you hand the code over to others.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-28 7:12 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Whether the code is compile in or a module makes no difference wrt
> licenses as far as I know.
>
> There's no limitation on*running*  the code, you can fetch and patch and
> edit and compile and run all you want and have it on as many of your (or
> the company's) machines as you want - neither license interferes with
> your right to do that.
>
> You may not redistribute the code though.

So, can you answer me this...

Why would there be a problem if someone decided to create a 3rd party 
overlay *not* part of the official gentoo portage tree that contained 
*only* the zfs stuff, and when this overlay was installed combined with 
a zfs keyword for the kernel, portage would then pull in the required 
files, and automagically build a kernel with an up to date version of 
zfs properly and fully integrated?

Would this not work, *and* have no problems with licensing?

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 30/08/2013 16:29, Tanstaafl wrote:
> On 2013-08-28 7:12 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> Whether the code is compile in or a module makes no difference wrt
>> licenses as far as I know.
>>
>> There's no limitation on*running*  the code, you can fetch and patch and
>> edit and compile and run all you want and have it on as many of your (or
>> the company's) machines as you want - neither license interferes with
>> your right to do that.
>>
>> You may not redistribute the code though.
> 
> So, can you answer me this...
> 
> Why would there be a problem if someone decided to create a 3rd party
> overlay *not* part of the official gentoo portage tree that contained
> *only* the zfs stuff, and when this overlay was installed combined with
> a zfs keyword for the kernel, portage would then pull in the required
> files, and automagically build a kernel with an up to date version of
> zfs properly and fully integrated?
> 
> Would this not work, *and* have no problems with licensing?
> 

there is no problem with licensing in that case.
The ebuild could even go in the portage tree, as Gentoo is not
redistributing sources when it publishes an ebuild.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 2013-08-27 5:06 PM, Joerg Schilling 
> <Joerg.Schilling@fokus.fraunhofer.de> wrote:
> > You wrote that modules become derivatives of the Linux kernel and this is the
> > same as writing ZFS would become a kernel derivative.
>
> Just for clarification, I was talking about compiling ZFS support INTO 
> the kernel, not running it as a module.
>
> Do you claim that support for compiling ZFS directly into the kernel 
> also does not violate the license?

There is no difference, both is permitted.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Thomas Mueller <mueller6726@bellsouth.net> wrote:

> On the issue of whether ZFS can be shipped with the Linux kernel, FreeBSD includes ZFS with the kernel, binary and source.
>
> So does that mean it would be OK for Linux too?
>
> FreeBSD has a different license (BSD) than Linux (GPL 2 or 3).

For FreeBSD, things are less easy than for Linux.

FreeBSD comes with a license that gives real freedom and the CDDL
being copyleft, is a license that intentionally limits the freedom a bit
in order to achieve other benefits.

The GPL limits freedom in a way far beyond what the CDDl does.
Adding code (ZFS) that gives more freedom than the base project (Linux) 
is easy...

It however was a real challenge for me to convince the FreeBSD people in early 
2006 to add something to their code that reduces the freedom of the FreeBSD
project. I succeeded because I could explain them that ZFS is not code that is 
_needed_ in order to run FreeBSD - you just could use their UFS variant instead.
The same arguments worked for integrating DTrace into FreeBSD.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

Ummm... I didn't suggest that ZFS be shipped with or distributed with 
the kernel...

I was talking about some kind of overlay or patch system, where I could 
add zfs to my kernel use flag, and it would pull the gentoo-sources from 
wherver it pulls them, and pul;l the patch from a *separate*/*different* 
source/location, and then put the patch where it needs to go to be 
properly compiled into the kernel.

Again, the overlay would *not* contain or provide the kernel sources, 
only the zfs 'patch'.

I don't see a problem with that.

On 2013-08-26 10:04 PM, Thomas Mueller <mueller6726@bellsouth.net> wrote:
> On the issue of whether ZFS can be shipped with the Linux kernel, FreeBSD includes ZFS with the kernel, binary and source.
>
> So does that mean it would be OK for Linux too?
>
> FreeBSD has a different license (BSD) than Linux (GPL 2 or 3).
>
> I am not a lawyer!
>
> Tom
>
>

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Tue, 27 Aug 2013 06:33:52 -0400, Tanstaafl wrote:

> Ummm... I didn't suggest that ZFS be shipped with or distributed with 
> the kernel...
> 
> I was talking about some kind of overlay or patch system, where I could 
> add zfs to my kernel use flag, and it would pull the gentoo-sources
> from wherver it pulls them, and pul;l the patch from a
> *separate*/*different* source/location, and then put the patch where it
> needs to go to be properly compiled into the kernel.

I already posted the script I use to do exactly that.

emerge gentoo-sources
run the script

I wonder it it would be possible to have the spl and zfs-kmod ebuilds do
this with an appropriate USE flag.


-- 
Neil Bothwick

Bury a lawyer 12 feet under, because deep down they're nice.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-08-27 8:25 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 27 Aug 2013 06:33:52 -0400, Tanstaafl wrote:
>
>> Ummm... I didn't suggest that ZFS be shipped with or distributed with
>> the kernel...
>>
>> I was talking about some kind of overlay or patch system, where I could
>> add zfs to my kernel use flag, and it would pull the gentoo-sources
>> from wherver it pulls them, and pul;l the patch from a
>> *separate*/*different* source/location, and then put the patch where it
>> needs to go to be properly compiled into the kernel.
>
> I already posted the script I use to do exactly that.
>
> emerge gentoo-sources
> run the script
>
> I wonder it it would be possible to have the spl and zfs-kmod ebuilds do
> this with an appropriate USE flag.

Thats what I'm looking for... something that is automatic and basically 
'just works'.

Manually running a script as part of each kernel update just... well, 
computers do automation best.

But thanks very much for your script. I'm just not comfortable (at this 
point at least) doing it that way on a production system...

Re: [gentoo-user] Optional /usr merge in Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Tue, 27 Aug 2013 08:37:54 -0400, Tanstaafl wrote:

> > I already posted the script I use to do exactly that.
> >
> > emerge gentoo-sources
> > run the script
> >
> > I wonder it it would be possible to have the spl and zfs-kmod ebuilds
> > do this with an appropriate USE flag.  
> 
> Thats what I'm looking for... something that is automatic and basically 
> 'just works'.
> 
> Manually running a script as part of each kernel update just... well, 
> computers do automation best.

I use a script to configure, build and install new kernels. It's called
from there, so it is automatic for me :)

> But thanks very much for your script. I'm just not comfortable (at this 
> point at least) doing it that way on a production system...

That's the recommended way, since the script follows the instructions for
merging the modules in the kernel tree and uses the make scripts that
come with the sources. It will not mess up your kernel since it only adds
code, code that isn't even used until you enable it in the .config.


-- 
Neil Bothwick

MACINTOSH: Most Applications Crash; If Not, The Operating System Hangs

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Gregory Shearman]

In linux.gentoo.user, Mr Schilling wrote:
>
> On Solaris, you can disable loading unsigned modules,  is this not supported by 
> Linux?

CONFIG_MODULE_SIG

-- 
Regards,
Gregory.

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Joerg Schilling]

Gregory Shearman <zekeyg@gmail.com> wrote:

> In linux.gentoo.user, Mr Schilling wrote:
> >
> > On Solaris, you can disable loading unsigned modules,  is this not supported by 
> > Linux?
>
> CONFIG_MODULE_SIG

So there seems to be no real need to create a static linux kernel with ZFS 
inside.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Walter Dnes]

On Sat, Aug 31, 2013 at 02:19:56PM +0200, Joerg Schilling wrote

> So there seems to be no real need to create a static linux kernel
> with ZFS inside.

See http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap7

> Now go to File Systems and select support for the filesystems you use.
> Don't compile the file system you use for the root filesystem as
> module, otherwise your Gentoo system will not be able to mount
> your partition.

  You can get away with most stuff as modules; ***BUT NOT THE ROOT
FILESYSTEM***.  Think about it for a minute.  Gentoo reads modules off
the disk.  If the code for the root filesystem is a module, Gentoo would
have to read the module off the disk to enable it to read the module off
the disk... OOPS.  This is a classic "chicken and egg" situation.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Sat, Aug 31, 2013 at 7:13 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Aug 31, 2013 at 02:19:56PM +0200, Joerg Schilling wrote
>
>> So there seems to be no real need to create a static linux kernel
>> with ZFS inside.
>
> See http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap7
>
>> Now go to File Systems and select support for the filesystems you use.
>> Don't compile the file system you use for the root filesystem as
>> module, otherwise your Gentoo system will not be able to mount
>> your partition.
>
>   You can get away with most stuff as modules; ***BUT NOT THE ROOT
> FILESYSTEM***.  Think about it for a minute.  Gentoo reads modules off
> the disk.  If the code for the root filesystem is a module, Gentoo would
> have to read the module off the disk to enable it to read the module off
> the disk... OOPS.  This is a classic "chicken and egg" situation.

I usally use ext4 as filesystem.

# lsmod|grep ext
ext3                  100768  0
jbd                    39586  1 ext3
ext2                   49572  0
ext4                  263621  1
crc16                   1255  2 ext4,bluetooth
mbcache                 4450  3 ext2,ext3,ext4
jbd2                   48679  1 ext4

Isn't great what an initramfs can do?

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

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Walter Dnes]

> I usally use ext4 as filesystem.
> 
> # lsmod|grep ext
> ext3                  100768  0
> jbd                    39586  1 ext3
> ext2                   49572  0
> ext4                  263621  1
> crc16                   1255  2 ext4,bluetooth
> mbcache                 4450  3 ext2,ext3,ext4
> jbd2                   48679  1 ext4
> 
> Isn't great what an initramfs can do?

  In this case, initramfs is your root filesystem, from which you load
another fs and then transfer (pivot root?) to it.  You have to build
initramfs support into the kernel, to boot an initramfs.  So my argument
still stands, regardless of whether your *INITIAL* filesystem is ext4fs,
or ZFS, or initramfs, that *INITIAL* filesystem has to be built into the
kernel.  Also, I really wonder what the point is in having to use
initramfs on a system where /usr is part of /.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: Integrated ZFS for Gentoo - WAS Re: [gentoo-user] Optional /usr merge in Gentoo

[Canek Peláez Valdés]

On Sat, Aug 31, 2013 at 10:55 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> I usally use ext4 as filesystem.
>>
>> # lsmod|grep ext
>> ext3                  100768  0
>> jbd                    39586  1 ext3
>> ext2                   49572  0
>> ext4                  263621  1
>> crc16                   1255  2 ext4,bluetooth
>> mbcache                 4450  3 ext2,ext3,ext4
>> jbd2                   48679  1 ext4
>>
>> Isn't great what an initramfs can do?
>
>   In this case, initramfs is your root filesystem, from which you load
> another fs and then transfer (pivot root?) to it.  You have to build
> initramfs support into the kernel, to boot an initramfs.  So my argument
> still stands, regardless of whether your *INITIAL* filesystem is ext4fs,
> or ZFS, or initramfs, that *INITIAL* filesystem has to be built into the
> kernel.

Interesting perspective. Of course, support for an initramfs is not
actually a file system (it's not even in the File systems section of
the kernel configuration, is in General setup); it's not possible to
have initramfs as a module (that would make no sense at all); and it's
code that is several orders of magnitude more simpler than the one
used by ext4 (or any other journal file system).

But you are right that for booting with an initramfs, you need
initramfs support.

> Also, I really wonder what the point is in having to use
> initramfs on a system where /usr is part of /.

Well, since some months ago I've been running as a module almost
everything that can be compiled as a module. This allows me to run a
*truly* minimal kernel, and only the necessary modules autoload
automatically (one big exception: binfmt_script, I compiled that into
the kernel because it was not loading automatically). I can also
unload some modules when not in use anymore (and this is great to
debug sometimes).

This also lets me to add a lot of stuff in the kernel, as long as I
add them as modules, without me worrying about bloating my kernel.
Only when they are needed they are loaded. I have USB speakers, but I
almost never use them; no problem, they (like almost everything else)
live as modules, and only are loaded (automagically, thanks to udev)
when needed. And again, I can unload them when not in use.

And also, it turns out that by using dracut+systemd you could boot
faster than without initramfs (although I can't find the link
anymore).

Finally, using only modules and dracut liberates me from thinking what
should it be compiled in and what not; I just put *everything* as a
module, and the kernel, udev and dracut take care of loading what's
necessary. Thus, my kernel (the one running in memory) is as minimal
as it can be, all the time.

Oh, and one more thing; by having everything as a module, if suddenly
I need support for new hardware, usually I can do a quick "make
menuconfig; make modules_install", and the new module can be
modprobe'd into the kernel without needing a reboot. That's
convenient.

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

Re: [gentoo-user] Optional /usr merge in Gentoo

[Tanstaafl]

On 2013-09-01 12:31 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> Of course, support for an initramfs is not actually a file system
> (it's not even in the File systems section of the kernel
> configuration, is in General setup); it's not possible to have
> initramfs as a module (that would make no sense at all); and it's
> code that is several orders of magnitude more simpler than the one
> used by ext4 (or any other journal file system).

Is there any reason that the creation, use and maintenance of the 
initramfs couldn't be as simple as a checkbox in the kernel config, so 
that running 'make' after the kernel was configured would automatically 
build it? Then, all I'd have to do is move it into /boot along with the 
new kernel (just like I do now), with *nothing* else required, and the 
kernel would call it, and things would just work (as long as it was 
there and I didn't forget to copy it to /boot).

Re: [gentoo-user] Optional /usr merge in Gentoo

[Alan McKinnon]

On 01/09/2013 16:30, Tanstaafl wrote:
> On 2013-09-01 12:31 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> Of course, support for an initramfs is not actually a file system
>> (it's not even in the File systems section of the kernel
>> configuration, is in General setup); it's not possible to have
>> initramfs as a module (that would make no sense at all); and it's
>> code that is several orders of magnitude more simpler than the one
>> used by ext4 (or any other journal file system).
> 
> Is there any reason that the creation, use and maintenance of the
> initramfs couldn't be as simple as a checkbox in the kernel config, so
> that running 'make' after the kernel was configured would automatically
> build it? Then, all I'd have to do is move it into /boot along with the
> new kernel (just like I do now), with *nothing* else required, and the
> kernel would call it, and things would just work (as long as it was
> there and I didn't forget to copy it to /boot).


That would require a config file of some sort to define what files you
want in the initramfs, and it must be available to the kernel build
process. It also has to read your self-defined arbitrary stuff from your
userland.

The kernel build machinery is a self-contained environment, the kernel
devs work very hard to keep userland out of it. So expect Linux to shoot
you down in flames for the very suggestion.

You keep asking for tools to automate the production of an initramfs;
you should realize that the thing has got absolutely nothing to do with
building and running a kernel, it's a helper function, and not really
tied to the kernel per se.

Just rig your kernel update process to add a section where you run the
command that builds an initramfs. You already have so many steps where
you do exactly that in other areas so it's not a realistic issue, and
you take that in your stride. Or at it to the end of your kernel build
wrapper script if you wrote such a thing for yourself.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Optional /usr merge in Gentoo

[Douglas J Hunley]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Sun, Sep 1, 2013 at 10:30 AM, Tanstaafl <tanstaafl@libertytrek.org>wrote:

> Is there any reason that the creation, use and maintenance of the
> initramfs couldn't be as simple as a checkbox in the kernel config, so that
> running 'make' after the kernel was configured would automatically build
> it? Then, all I'd have to do is move it into /boot along with the new
> kernel (just like I do now), with *nothing* else required, and the kernel
> would call it, and things would just work (as long as it was there and I
> didn't forget to copy it to /boot).


This exists. You can built initramfs right into the kernel. I've been doing
it here for quite some time. You just tell the kernel either:
* where to find a filespec so it knows what to include in the initramfs
* what directory contains everything you want in the initramfs

and then the kernel builds is and attaches it to itself during 'make'

It's actually pretty trivial


-- 
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

[-- Attachment #2: Type: text/html, Size: 1845 bytes --]

Re: [gentoo-user] Optional /usr merge in Gentoo

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

Douglas J Hunley wrote:
>
> On Sun, Sep 1, 2013 at 10:30 AM, Tanstaafl <tanstaafl@libertytrek.org
> <mailto:tanstaafl@libertytrek.org>> wrote:
>
>     Is there any reason that the creation, use and maintenance of the
>     initramfs couldn't be as simple as a checkbox in the kernel
>     config, so that running 'make' after the kernel was configured
>     would automatically build it? Then, all I'd have to do is move it
>     into /boot along with the new kernel (just like I do now), with
>     *nothing* else required, and the kernel would call it, and things
>     would just work (as long as it was there and I didn't forget to
>     copy it to /boot).
>
>
> This exists. You can built initramfs right into the kernel. I've been
> doing it here for quite some time. You just tell the kernel either:
> * where to find a filespec so it knows what to include in the initramfs
> * what directory contains everything you want in the initramfs
>
> and then the kernel builds is and attaches it to itself during 'make'
>
> It's actually pretty trivial
>
>
> -- 
> Douglas J Hunley (doug.hunley@gmail.com <mailto:doug.hunley@gmail.com>)
> Twitter: @hunleyd                                               Web:
> douglasjhunley.com <http://douglasjhunley.com>
> G+: http://goo.gl/sajR3

I tried that a while back.  Followed a howto step by step, Gentoo one I
think, and it never worked, not even once.  Trivial, not hardly. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3146 bytes --]