On Thu, 13 Oct 2011 16:22:16 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Oct 13, Salvo Tomaselli wrote:
>> Some systems have quite a small /boot partition, I've had some problems with
>> a
>/boot partitions nowadays are mostly useless, unless e.g. you are doing
>something stupid like a RAID 5
On Wed, Oct 12, 2011 at 11:24:09AM +0700, Ivan Shmakov wrote:
> > unruh writes:
> > On 2011-10-12, Marco d'Itri wrote:
>
> With all the sort of software continuously writing to /etc/?
> Consider, e. g., /etc/blkid.tab, which is updated almost every
> time a removable m
On Thu, Oct 13, 2011 at 06:08:32PM +0200, Marco d'Itri wrote:
> On Oct 13, Steve McIntyre wrote:
> > Or on devices where the firmware / boot loader doesn't support large
> > disks, or only limited filesystems etc. Please don't ignore other
> > people's use cases.
>
> Can you point me at some exam
On Fri, Oct 14, 2011 at 12:27:03PM +0800, Paul Wise wrote:
> On Fri, Oct 14, 2011 at 1:38 AM, Wouter Verhelst wrote:
>
> > share /usr between multiple systems today; but nobody does it, because
> > - Keeping your software on a central fileserver introduces a single
> > point of failure that you d
On 2011-10-14 02:28 +0200, Marco d'Itri wrote:
> My plan is to write a script which moves to /usr all the binaries in
> /bin and /sbin (taking care of the few cases which actually are links
> to /) and then converts the directories to symlinks to /usr/bin and
> /usr/sbin.
> After this I will try
On Fri, Oct 14, 2011 at 1:38 AM, Wouter Verhelst wrote:
> share /usr between multiple systems today; but nobody does it, because
> - Keeping your software on a central fileserver introduces a single
> point of failure that you don't have if you don't do the central
> fileserver thing
That sound
On Fri, Oct 14, 2011 at 12:08 AM, Marco d'Itri wrote:
> Can you point me at some examples?
The default setup when choosing full-disk encryption in d-i.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscr
Hello Wouter and *,
since August 2011 I run an Experimanental-Cloud with 20 IBM eServe x345
and 40 IBM eServer x335... Enough machines to play with it.
Since 3 weeks I now have my two 400V/32A/3P CEE Wallets for my two
Severracks in my office.
Am 2011-10-13 19:38:12, hacktest Du folgende
On Oct 14, Charles Plessy wrote:
> If the merge in /usr is implemented in the base-files package, it means that
> existing systems will not be automatically converted. So to support the
> systems combining where the root filesystem is not supported by bootloaders
> and
> where the disk is small
Le Thu, Oct 13, 2011 at 04:12:07PM +0100, Steve McIntyre a écrit :
> Marco wrote:
> >On Oct 13, Salvo Tomaselli wrote:
> >> Some systems have quite a small /boot partition, I've had some problems
> >> with a
> >/boot partitions nowadays are mostly useless, unless e.g. you are doing
> >something
Steve Langasek wrote:
>On Thu, Oct 13, 2011 at 06:08:32PM +0200, Marco d'Itri wrote:
>> On Oct 13, Steve McIntyre wrote:
>
>> > Or on devices where the firmware / boot loader doesn't support large
>> > disks, or only limited filesystems etc. Please don't ignore other
>> > people's use cases.
>> Ca
On Oct 13, Luk Claes wrote:
> Isn't this what the whole thread is about: ignoring other people's use
> cases?
I do not know what it is for you. For me, it is about understanding the
impact on Debian of implementing this.
I have received interesting replies which address valid issues, like the
nee
On Thu, Oct 13, 2011 at 06:08:32PM +0200, Marco d'Itri wrote:
> On Oct 13, Steve McIntyre wrote:
> > Or on devices where the firmware / boot loader doesn't support large
> > disks, or only limited filesystems etc. Please don't ignore other
> > people's use cases.
> Can you point me at some exampl
On 10/13/2011 05:12 PM, Steve McIntyre wrote:
> Marco wrote:
>> On Oct 13, Salvo Tomaselli wrote:
>>> Some systems have quite a small /boot partition, I've had some problems
>>> with a
>> /boot partitions nowadays are mostly useless, unless e.g. you are doing
>> something stupid like a RAID 5 ro
On Tue, Oct 11, 2011 at 04:32:46PM +0200, Marco d'Itri wrote:
> https://fedoraproject.org/wiki/Features/UsrMove
>
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
>
> How much complex would it be to implem
On Oct 13, Steve McIntyre wrote:
> Or on devices where the firmware / boot loader doesn't support large
> disks, or only limited filesystems etc. Please don't ignore other
> people's use cases.
Can you point me at some examples?
Excluding hardware which has been obsolete for many years...
--
ci
Marco wrote:
>On Oct 13, Salvo Tomaselli wrote:
>> Some systems have quite a small /boot partition, I've had some problems with
>> a
>/boot partitions nowadays are mostly useless, unless e.g. you are doing
>something stupid like a RAID 5 root.
Or on devices where the firmware / boot loader does
On Thu, 13 Oct 2011 16:22:16 +0200, m...@linux.it wrote:
Some systems have quite a small /boot partition, I've had some
problems with a
/boot partitions nowadays are mostly useless, unless e.g. you are
doing
something stupid like a RAID 5 root.
If you have a 30 MB /boot partition then just sto
On Oct 13, Salvo Tomaselli wrote:
> Some systems have quite a small /boot partition, I've had some problems with
> a
/boot partitions nowadays are mostly useless, unless e.g. you are doing
something stupid like a RAID 5 root.
If you have a 30 MB /boot partition then just stop mounting it and ke
In data Thursday 13 October 2011 10:14:17, Reinhard Tartler ha scritto:
> Note that an initramfs can be embedded directly into the kernel, so this
> wouldn't require necessarily any changes to your bootloader.
Some systems have quite a small /boot partition, I've had some problems with a
server
On Mi, Okt 12, 2011 at 23:33:23 (CEST), Michelle Konzack wrote:
> Hello Matt Zagrabelny,
>
> Am 2011-10-11 11:21:30, hacktest Du folgendes herunter:
>> There are good arguments in the following link (Marco provided it with
>> his initial email.)
>>
>> https://fedoraproject.org/wiki/Features/UsrMo
> Tollef Fog Heen writes:
> ]] Ivan Shmakov
> Tollef Fog Heen writes:
>>> (With the assumption that /usr is on a separate fs from /): You
>>> might very well need to load some drivers (be it network, FC, USB,
>>> SATA or something else) and probe some bits (iSCSI auth?) to
>>> a
Hello Matt Zagrabelny,
Am 2011-10-11 11:21:30, hacktest Du folgendes herunter:
> There are good arguments in the following link (Marco provided it with
> his initial email.)
>
> https://fedoraproject.org/wiki/Features/UsrMove
I have read this too but what about systems which do not have an initr
On 2011-10-12, Daniel Baumann wrote:
> On 10/12/2011 05:42 PM, Mathieu Trudel-Lapierre wrote:
>> Did you know about http://www.gobolinux.org/ ?
> gobolinux is iirc that project that aims to replicate what windows does:
> having every application (and it's depends) in one directory so that
> uninst
]] Ivan Shmakov
| > Tollef Fog Heen writes:
|
| > (With the assumption that /usr is on a separate fs from /): You might
| > very well need to load some drivers (be it network, FC, USB, SATA or
| > something else) and probe some bits (iSCSI auth?) to actually get to
| > the right block d
On 10/12/2011 05:42 PM, Mathieu Trudel-Lapierre wrote:
> Did you know about http://www.gobolinux.org/ ?
gobolinux is iirc that project that aims to replicate what windows does:
having every application (and it's depends) in one directory so that
uninstalling is a matter of removing a single direct
On Wed, Oct 12, 2011 at 8:48 AM, Jon Dowland wrote:
[...]
>> oiow, someone with time should just make that trichotomy happen in FHS 3.0.
>
> I think there's a chicken-and-egg problem here: FHS want to document existing
> practice. Someone needs to put work into a runnable concept OS at the very
Hi there!
On Wed, 12 Oct 2011 02:58:24 +0200, Marco d'Itri wrote:
> So let's look at the reasons against merging /usr in / listed in my
> final summary. All of them do not apply to merging / in /usr, and
> actually become arguments in favour of doing it:
[...]
> - dmcrypt: more parts would not nee
On Wed, Oct 12, 2011 at 01:56:47PM +0200, Daniel Baumann wrote:
> moving / to /usr will take a lot of time in the linux ecosystem. since i
> prefere doing such a thing only once in a decade, going for the right
> thing directly is better than going for something incomplete first.
Sensible.
> oiow
Hi there!
On Wed, 12 Oct 2011 06:24:09 +0200, Ivan Shmakov wrote:
>> unruh writes:
>> On 2011-10-12, Marco d'Itri wrote:
> >> - read only system: more parts would be read only
>
> > ? Surely you can make whatever you want read only now.
>
> With all the sort of software continuo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/12/2011 11:28 AM, Marco d'Itri wrote:
> This would be the practical effect, but let's try to not get away
> too much from UNIX...
moving / to /usr will take a lot of time in the linux ecosystem. since i
prefere doing such a thing only once in a
> Tollef Fog Heen writes:
>> The problem, AIUI, is that we start udev(7) before /usr is mounted.
>> As udev is prone to spawn all the sorts of software in turn, we're
>> either going to move more and more from /usr to /, /or/ to invent
>> more kluges so that udev scripts would actually wa
On Wed, Oct 12, 2011 at 12:50:32PM +0200, Cyril Brulebois wrote:
> Adam Borowski (12/10/2011):
> > On Wed, Oct 12, 2011 at 06:56:25AM +, Philipp Kern wrote:
> > > On 2011-10-11, Ognyan Kulev wrote:
> > > >
> > > > /usr/include -> /usr/share/include
> > >
> > > Obviously broken. Includes can
]] Ivan Shmakov
| The problem, AIUI, is that we start udev(7) before /usr is
| mounted. As udev is prone to spawn all the sorts of software in
| turn, we're either going to move more and more from /usr to /,
| /or/ to invent more kluges so that udev scripts would actually
Adam Borowski (12/10/2011):
> On Wed, Oct 12, 2011 at 06:56:25AM +, Philipp Kern wrote:
> > On 2011-10-11, Ognyan Kulev wrote:
> > >
> > > /usr/include -> /usr/share/include
> >
> > Obviously broken. Includes can (and will be) architecture-specific.
>
> With multiarch, they are shareable.
On Wed, Oct 12, 2011 at 06:56:25AM +, Philipp Kern wrote:
> On 2011-10-11, Ognyan Kulev wrote:
> > На 11.10.2011 17:32, Marco d'Itri написа:
> >> https://fedoraproject.org/wiki/Features/UsrMove
> >> This reminds me a bit of the /usr/doc/ => /usr/share/doc/ transition.
> > This changes semanti
On Oct 12, Daniel Baumann wrote:
> On 10/11/2011 04:32 PM, Marco d'Itri wrote:
> > I am still not 100% persuaded that this would be easy to do, but at
> > least I think that it has more merit than the old "move all to /"...
> i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we can
> Daniel Baumann writes:
> On 10/11/2011 04:32 PM, Marco d'Itri wrote:
>> I am still not 100% persuaded that this would be easy to do, but at
>> least I think that it has more merit than the old "move all to /"...
> i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we
>
On 10/11/2011 04:32 PM, Marco d'Itri wrote:
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we can
have the trichotomy /system, /local and /h
> Philipp Kern writes:
> On 2011-10-11, Ognyan Kulev wrote:
> На 11.10.2011 17:32, Marco d'Itri написа:
[…]
>> /usr/src -> /usr/share/src
> Probably depends if you want to support compile outputs there. I
> guess some people compile their kernels there.
Which isn't a g
On 2011-10-11, Ognyan Kulev wrote:
> На 11.10.2011 17:32, Marco d'Itri написа:
>> https://fedoraproject.org/wiki/Features/UsrMove
>> This reminds me a bit of the /usr/doc/ => /usr/share/doc/ transition.
> This changes semantics of /usr directory. /usr becomes all shareable
> files, /usr/share -
On 2011-10-11, Marco d'Itri wrote:
> https://fedoraproject.org/wiki/Features/UsrMove
What I don't buy is the "your /usr will be your /System" thing. We're
too much entangled with /var (the dpkg DB for instance), so that there
are parts in /var that are not at all host-specific but /System-specif
On 2011-10-11, Adam Borowski wrote:
> I especially dislike moving /sbin/ and /usr/sbin/ to /usr/bin/.
> That's namespace pollution, you don't want to have executables you can't run
> due to them being root-only in your $PATH.
You could skip executables that you cannot run in tab completion and ac
> unruh writes:
> On 2011-10-12, Marco d'Itri wrote:
[…]
>> So let's look at the reasons against merging /usr in / listed in my
>> final summary. All of them do not apply to merging / in /usr, and
>> actually become arguments in favour of doing it:
>> - NFS: sharing a read only sy
On 2011-10-12, Marco d'Itri wrote:
>
> --zx4FCpZtqtKETZ7O
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Oct 11, Sven Joachim wrote:
>
>> >> We already discussed the idea of dropping support for a separate /usr,
>> >
On Oct 11, Sven Joachim wrote:
> >> We already discussed the idea of dropping support for a separate /usr,
> >> and the outcome was a broad consensus for keeping things this way.
> > No, we discussed the idea of merging /usr in / (to which I was opposed
> > myself as well).
> > This is a differen
On Oct 11, Adam Borowski wrote:
> On Tue, Oct 11, 2011 at 04:32:46PM +0200, Marco d'Itri wrote:
> > https://fedoraproject.org/wiki/Features/UsrMove
> I especially dislike moving /sbin/ and /usr/sbin/ to /usr/bin/.
I do not like this either, but it is not required.
--
ciao,
Marco
signature.asc
Marco d'Itri dijo [Tue, Oct 11, 2011 at 04:32:46PM +0200]:
> https://fedoraproject.org/wiki/Features/UsrMove
>
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
>
> How much complex would it be to implement
On Tue, Oct 11, 2011 at 04:32:46PM +0200, Marco d'Itri wrote:
> https://fedoraproject.org/wiki/Features/UsrMove
I especially dislike moving /sbin/ and /usr/sbin/ to /usr/bin/.
That's namespace pollution, you don't want to have executables you can't run
due to them being root-only in your $PATH.
> Mike Hommey writes:
> On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote:
> Marco d'Itri writes:
[…]
>>> No, we discussed the idea of merging /usr in / (to which I was
>>> opposed myself as well). This is a different concept.
>> The only significant difference that
On 11/10/11 20:28, Mike Hommey wrote:
On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote:
Marco d'Itri writes:
On Oct 11, Josselin Mouette wrote:
Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
>>> I am still not 100% persuaded that this would be easy to do, but a
On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote:
> > Marco d'Itri writes:
> > On Oct 11, Josselin Mouette wrote:
> > Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
>
> >>> I am still not 100% persuaded that this would be easy to do, but at
> >>> least
On 2011-10-11 19:48 +0200, Marco d'Itri wrote:
> On Oct 11, Josselin Mouette wrote:
>
>> Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
>> > I am still not 100% persuaded that this would be easy to do, but at
>> > least I think that it has more merit than the old "move all to /".
> Marco d'Itri writes:
> On Oct 11, Josselin Mouette wrote:
> Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
>>> I am still not 100% persuaded that this would be easy to do, but at
>>> least I think that it has more merit than the old "move all to
>>> /"...
>> W
On Oct 11, Josselin Mouette wrote:
> Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
> > I am still not 100% persuaded that this would be easy to do, but at
> > least I think that it has more merit than the old "move all to /"...
> We already discussed the idea of dropping support
На 11.10.2011 17:32, Marco d'Itri написа:
https://fedoraproject.org/wiki/Features/UsrMove
This reminds me a bit of the /usr/doc/ => /usr/share/doc/ transition.
This changes semantics of /usr directory. /usr becomes all shareable
files, /usr/share - all shareable architecture-independant fi
Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
We already discussed the idea of dropping support for a separate /usr,
and the outcome was a
> Marco d'Itri writes:
> On Oct 11, Ivan Shmakov wrote:
>> Saving a dozen of bytes in ${PATH} doesn't seem like an
>> astonishing idea, anyway. What's the point, then?
> It is explained in the Red Hat wiki page. Try reading it again.
Indeed, I've just read it. To summarize
On Oct 11, unruh wrote:
> That would be fine if /usr is always on the root partition. However many
Feel free to come back after actually reading the linked page.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Tue, Oct 11, 2011 at 11:09 AM, Ivan Shmakov wrote:
> Saving a dozen of bytes in ${PATH} doesn't seem like an
> astonishing idea, anyway. What's the point, then?
There are good arguments in the following link (Marco provided it with
his initial email.)
https://fedoraproject.org
On 2011-10-11, Marco d'Itri wrote:
> https://fedoraproject.org/wiki/Features/UsrMove
>
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
>
> How much complex would it be to implement this in Debian?
> Would
On Oct 11, Ivan Shmakov wrote:
> Saving a dozen of bytes in ${PATH} doesn't seem like an
> astonishing idea, anyway. What's the point, then?
It is explained in the Red Hat wiki page. Try reading it again.
--
ciao,
Marco
signature.asc
Description: Digital signature
> Marco d'Itri writes:
> On Oct 11, Sven Joachim wrote:
>> Rather complex, I'm afraid. Especially as not all architectures
>> even support an initramfs, AFAIK.
> I doubt this, since the initramfs can be embedded in the kernel image
> itself (and indeed it always contains one, it ju
On Oct 11, Sven Joachim wrote:
> Rather complex, I'm afraid. Especially as not all architectures even
> support an initramfs, AFAIK.
I doubt this, since the initramfs can be embedded in the kernel image
itself (and indeed it always contains one, it just is empty).
But still, then these architect
On Tue, 11 Oct 2011 16:44:12 +0200, Sven Joachim wrote:
On 2011-10-11 16:32 +0200, Marco d'Itri wrote:
https://fedoraproject.org/wiki/Features/UsrMove
[snip]
Would "mv /bin/* /usr/bin/" and making it a symlink just work,
without
the need to create temporary symlinks in every package as red
On 2011-10-11 16:32 +0200, Marco d'Itri wrote:
> https://fedoraproject.org/wiki/Features/UsrMove
>
> I am still not 100% persuaded that this would be easy to do, but at
> least I think that it has more merit than the old "move all to /"...
>
> How much complex would it be to implement this in Debi
https://fedoraproject.org/wiki/Features/UsrMove
I am still not 100% persuaded that this would be easy to do, but at
least I think that it has more merit than the old "move all to /"...
How much complex would it be to implement this in Debian?
Would "mv /bin/* /usr/bin/" and making it a symlink ju
67 matches
Mail list logo
