FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-11-2012, 12:44 AM
Adam Williamson
 
Default UsrMove continued

On Wed, 2012-10-10 at 13:11 +0300, Serge wrote:
> 2012/10/9 tim.lauridsen wrote:
>
> >> So you make your system incompatible with every other Linux distro out
> >> there, and with all existing documentation, but to what end? Tidyness?
>
> Tidyness, simplicity, new features... Incompatible with older, but
> compatible with newer distros. That's close to what Solaris does on
> its livecd and really close to what Android does on mobile phones.

As my favourite American folk saying goes: 'close' only counts in
horseshoes and hand grenades.

A proposal to change the filesystem that was synchronized with and
planned to continue to be identical to (or at least fully compatible
with) how it's done in Android and Solaris, with the participation of
Google and Oracle, would be a more interesting proposal than 'let's just
do something kind of like what they're doing, but not the same, on our
own, not co-ordinating with them'. It might still face a lot of
resistance, but it'd be _more_ interesting.

> Turning /lib into /usr/lib was also incompatible with every other Linux
> distro, nevertheless it's already done.

As was already said, that change also had clear concrete benefits; the
incompatibility was acknowledged as a drawback, but the benefit was
traded off against the drawback, and it won. Your proposal seems short
on clear concrete benefits, but still has all the drawback. Other
distros are now adopting /usr move, which is kind of what we expected to
happen, so that drawback will go away. They'd be less likely to adopt a
change like this, made for the sake of 'neatness'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-11-2012, 03:31 AM
Ralf Corsepius
 
Default UsrMove continued

On 10/11/2012 02:44 AM, Adam Williamson wrote:

On Wed, 2012-10-10 at 13:11 +0300, Serge wrote:

2012/10/9 tim.lauridsen wrote:


So you make your system incompatible with every other Linux distro out
there, and with all existing documentation, but to what end? Tidyness?


Tidyness, simplicity, new features... Incompatible with older, but
compatible with newer distros. That's close to what Solaris does on
its livecd and really close to what Android does on mobile phones.


As my favourite American folk saying goes: 'close' only counts in
horseshoes and hand grenades.

A proposal to change the filesystem that was synchronized with and
planned to continue to be identical to (or at least fully compatible
with) how it's done in Android and Solaris, with the participation of
Google and Oracle, would be a more interesting proposal than 'let's just
do something kind of like what they're doing, but not the same, on our
own, not co-ordinating with them'. It might still face a lot of
resistance, but it'd be _more_ interesting.


Turning /lib into /usr/lib was also incompatible with every other Linux
distro, nevertheless it's already done.


As was already said, that change also had clear concrete benefits; the
incompatibility was acknowledged as a drawback, but the benefit was
traded off against the drawback, and it won.


Really? Don't you think the answers on in this thread speak a different
language.



Your proposal seems short
on clear concrete benefits, but still has all the drawback. Other
distros are now adopting /usr move, which is kind of what we expected to
happen, so that drawback will go away. They'd be less likely to adopt a
change like this, made for the sake of 'neatness'.
Openly said, I believe this is just an "imitation cult" - These other
distros will likely go through the same learning curves as Fedora and
come to the same conclusions as Fedora.


"UsrMove" being a mistake, which should be reverted.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-11-2012, 11:54 PM
Kevin Kofler
 
Default UsrMove continued

Chris Adams wrote:

> Once upon a time, Seth Vidal <skvidal@fedoraproject.org> said:
>> Not every decision a distribution makes is a good one, lets not get
>> caught up believing that we cannot make mistakes.
>>
>> UsrMove was a mistake. End of discussion. Let's go back.
>
> I agree. The additional churn would be another one-time pain, but then
> the Band-Aid™ would be ripped off and we'd be done.

Unfortunately, it's much harder to undo UsrMove than it was to do it:
UsrMove just required merging some pairs of directories, unmerging them is
much trickier. That's yet another reason why UsrMove is broken, it is almost
impossible to revert. We've really painted us into a corner. :-(

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-11-2012, 11:58 PM
Kevin Kofler
 
Default UsrMove continued

David Howells wrote:
> Actually, the UsrMove has mucked up at least one way of doing things: we
> have/had RHEL customer(s) who kept /usr on AFS and were able to boot just
> using the stuff in /bin and /sbin. This is no longer a viable option with
> Fedora, and presumably RHEL-7.

Actually, systemd had already refused to support this setup before UsrMove,
and this was cited as one of the reasons for doing UsrMove (ensuring the
draconian way that users won't even try using that setup).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-12-2012, 12:44 AM
Sérgio Basto
 
Default UsrMove continued

On Qua, 2012-10-10 at 13:11 +0300, Serge wrote:
> Turning /lib into /usr/lib was also incompatible with every other
> Linux
> distro, nevertheless it's already done.

Don't see why ?
ll /
lib -> usr/lib
lib64 -> usr/lib64
sbin -> usr/sbin
bin -> usr/bin

What is the difference of /lib and /usr/lib ?

What I see in Debian is a big confusion for example, with perl:
they have
/usr/lib/perl/
/usr/lib/perl5/
/usr/lib/perl5/auto
/usr/share/perl/
/usr/share/perl5/

And I have some modules in double and in different versions, which is a
mess. If you have just one directory you avoid double version of same
software.

Regards,
--
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-12-2012, 12:57 AM
Serge
 
Default UsrMove continued

2012/10/10 David Howells wrote:

> The contents of /dev vary depending on what hardware the computer has
> available - which may change in real time - so it cannot be shared, so
> why move it?

Ah, no, /dev was moved not because of sharing. It's just original UsrMove
among other benefits has the line:
> Simpler and cleaner overall file system layout, with full compatibility.
I was just trying to actually do that.
The best implementation I could come up with is:
> /os -- OS, kernel-space
> /usr -- user-space, shareable, possibly read-only,
> /var -- variable system data, read-write, non-shareable
> /home -- variable user data, read-write, shareable
> And nothing else.
Looks very simple, clean, easy to understand. That was the point
for UsrMove. Or at least the UsrMove page says so...

> You would _have_ to have symlinks at /dev and /proc - so moving these
> gains you nothing.

Except "simple and clean file system layout". Does it have any drawbacks?
I could not notice any changes in speed, I see no difference in
functionality. It works same, but looks better.

And some years later we may drop those symlinks, as well as /lib, /bin...

>> ... But an "eyecandy" kernel module can hide those symlinks, so user
>> would see a nice simple layout right now, and not in 10 years.
>
> Ugh. Don't go there. Really don't. That's for userspace to deal with -
> just like hiding files whose name begins with a ".".

Well, that was just an idea: show everything for `root` (UID=0),
but hide for the rest, so users could see the beauty.

> Which does not prevent you from leaving /dev and /proc where they are.

Well, maybe you're right. I have just listed all the ideas together,
trying to look as forward as possible. We can filter the best of them
and postpone/throw out the others. That's what the initial email was
written for.

> Actually, the UsrMove has mucked up at least one way of doing things

I agree that UsrMove is not in a good shape now. So it should be either
backed out, or moved forward and fixed. That's what I'm trying to do.

> we have/had RHEL customer(s) who kept /usr on AFS and were able to boot
> just using the stuff in /bin and /sbin. This is no longer a viable option with
> Fedora, and presumably RHEL-7.

In my case the goal is to mount /usr using stuff in initramfs.

--
Serge
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-12-2012, 01:37 AM
Serge
 
Default UsrMove continued

2012/10/11 Adam Williamson wrote:

> A proposal to change the filesystem that was synchronized with and
> planned to continue to be identical to (or at least fully compatible
> with) how it's done in Android and Solaris, with the participation of
> Google and Oracle, would be a more interesting proposal

Why doing identical if we can do it better?

Solaris implemented UsrMove (or rather /sbin-move in their case) in
a very weird way. Their initramfs has non-empty /usr directory which
contains the files from former /sbin and /lib, necessary to mount /usr.
Real /usr is just mounted on top of them hiding the old /usr content.
But, I guess you already knew that, since even original UsrMove page
mentions "Minimize difference to other Unixes, such as Solaris".
I remember someone had even blogged about that [1].

Androids implemented it differently, they also use initramfs for the root
filesystem layout. But they do not reuse existing directories, instead
they created a set of new directories (/system, /data, /cache...) and
then put symlinks there (i.e. /etc -> /system/etc).

I tried to make it better. To minimize changes I reused existing/known
directories so that their names still matched their content.

>> Turning /lib into /usr/lib was also incompatible with every other
>> Linux distro, nevertheless it's already done.
>
> As was already said, that change also had clear concrete benefits; the
> incompatibility was acknowledged as a drawback, but the benefit was
> traded off against the drawback, and it won. Your proposal seems short
> on clear concrete benefits

Actually my proposal is based on same benefits, it just adds more
(simpler diskless NFS stations, multiple OSes on same partition, etc).
It was aiming for a simple layout, and I made it as simple as I could.
It was trying to separate different resources, and I separated them,
grouping same resources into same directories. And so on.
You can compare initial email with UsrMove wiki page. Or are there
other UsrMove benefits that were not listed on a wiki page?

[1] https://plus.google.com/u/0/115547683951727699051/posts/DiGcrjDaKEb
--
Serge
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-12-2012, 10:11 AM
Marian Ganisin
 
Default UsrMove continued

On Wed, Oct 10, 2012 at 03:04:51PM +0200, Michal Schmidt wrote:
> Dne 10.10.2012 14:25, David Howells napsal(a):
> >Actually, the UsrMove has mucked up at least one way of doing things: we
> >have/had RHEL customer(s) who kept /usr on AFS and were able to boot just
> >using the stuff in /bin and /sbin. This is no longer a viable option with
> >Fedora, and presumably RHEL-7.
>
> The initramfs should contain everything necessary to mount / and /usr.
> Isn't there a dracut module for AFS support? If not, it should be added.
> Has a bug been reported?

As far as I know initrd doesn't provide sane environment for
troubleshooting possible issues.

Additionally / can be modified by standard fs tools "quite surprsingly".
It isn't case of initrd. Dracut seems to be good solution for this
case unless something breaks.

--
Regards,
Marian

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 07:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org