Ángel Ramírez Isea wrote:
>IMHO, at some point we will have to start ignoring whatever they do.
What does RH produce so it can't be replaced in favour of an alternative?
Maybe GTK+ only, which is made by the GNOME Project, where RH
employees work... But it's indirect. And we still use GTK+2 anywa
Yes, I agree completely.
Getting all the anti-systemd distros working together would be a very
good thing.
DaveT
On 11/01/16 01:05, da...@olansa.co.uk wrote:
This looks extremely desirable. Unfortunately we are not yet at the
point where there are two parallel threads of Gnu/Linux (since they
This looks extremely desirable. Unfortunately we are not yet at the
point where there are two parallel threads of Gnu/Linux (since they
persist to use that name) development. RedHat and Debian are still the
major driving force, due to their large number of developpers. And
Devuan is still derived
Le 10/01/2016 20:30, Ángel Ramírez Isea a écrit :
IMHO, at some point we will have to start ignoring whatever they do.
This looks extremely desirable. Unfortunately we are not yet at the
point where there are two parallel threads of Gnu/Linux (since they
persist to use that name) development.
El 2016-01-05 14:50, Joel Roth escribió:
Rainer Weikusat wrote:
Clarke Sideroad writes:
> So I've been thinking more about this as to why?
>
> It is quite obvious that it is driven by Redhat to be the same as Oracle
> Solaris, they say as much.
That's "quite obviously" an after-the-fact justif
Le 05/01/2016 20:25, Rob Owens a écrit :
- Original Message -
From: "Didier Kryn"
Le 05/01/2016 15:59, Rob Owens a écrit :
I have customers who use a shared /usr among several zLinux
systems, and the reason is cost savings.
For my information: They don't share rootfs? How do they
Le 05/01/2016 19:06, Rainer Weikusat a écrit :
During the last half of 1971, we supported three typists
from the Patent department, who spent the day busily typing,
editing, and formatting patent applications[*], and meanwhile
tried to carry on our own work.
On Tue, Jan 05, 2016 at 09:20:31AM -1000, Joel Roth wrote:
> Rainer Weikusat wrote:
> > Clarke Sideroad writes:
> > > So I've been thinking more about this as to why?
> > >
> > > It is quite obvious that it is driven by Redhat to be the same as Oracle
> > > Solaris, they say as much.
> >
> > That
- Original Message -
> From: "richard lucassen"
> On Tue, 5 Jan 2016 09:51:22 -0500 (EST)
> Rob Owens wrote:
>
> [too much typing]
>
>> An experienced sysadmin who has to do this type of thing several
>> times a day would have designed this syntax for ease of use. The
>> systemd develo
- Original Message -
> From: "Didier Kryn"
> Le 05/01/2016 15:59, Rob Owens a écrit :
>> I have customers who use a shared /usr among several zLinux
>> systems, and the reason is cost savings.
> For my information: They don't share rootfs? How do they manage
> package upgrade?
I just
Rainer Weikusat wrote:
> Clarke Sideroad writes:
> > So I've been thinking more about this as to why?
> >
> > It is quite obvious that it is driven by Redhat to be the same as Oracle
> > Solaris, they say as much.
>
> That's "quite obviously" an after-the-fact justification and the
> correspondin
On Tue, 05 Jan 2016 18:06:08 +, Rainer Weikusat wrote:
> Didier Kryn writes:
>
> [...]
>
I've read, from a guy who followed the story,that it was originally
split because the first disk was too
small.
>
> [...]
>
>> Good find Rainer. But I don't fully understand what
Didier Kryn writes:
[...]
>>> I've read, from a guy who followed the story,that it was originally
>>> split because the first disk was too
>>> small.
[...]
>> There's a paper by Dennis Richtie, "The UNIX Time-Sharing System"
[...]
>> The PDP-11 has a 1M byte fixed-head disk, used for
On Tue, 5 Jan 2016 09:51:22 -0500 (EST)
Rob Owens wrote:
[too much typing]
> An experienced sysadmin who has to do this type of thing several
> times a day would have designed this syntax for ease of use. The
> systemd developers did not do this, presumably because they do not
> have to type th
On Tue, Jan 05, 2016 at 04:52:07PM +0100, Didier Kryn wrote:
> Le 05/01/2016 15:59, Rob Owens a écrit :
> >I have customers who use a shared /usr among several zLinux
> >systems, and the reason is cost savings.
> For my information: They don't share rootfs? How do they manage
> package upgrade?
Le 05/01/2016 16:29, Rainer Weikusat a écrit :
Didier Kryn writes:
>Le 02/01/2016 03:44, Stephanie Daugherty a écrit :
>>Regardless of who proposed it, merged /usr is still a reckless change
>that needlessly complicates things.
>
>
> Hey Stephanie.
>
> The simple fact of splitting exe
On Tue, Jan 05, 2016 at 03:29:30PM +, Rainer Weikusat wrote:
[cut]
> In our installation, for example, the root directory resides
> on the fixed-head disk, and the large disk drive, which con-
> tains user's files, is mounted by the system initialization
> program
>
>
Le 05/01/2016 15:59, Rob Owens a écrit :
I have customers who use a shared /usr among several zLinux
systems, and the reason is cost savings.
For my information: They don't share rootfs? How do they manage
package upgrade?
Didier
___
Dng mai
On Tue, 5 Jan 2016 09:06:24 -0600
Nate Bargmann wrote:
> Snicker. What next, naming partitions 'C', 'D', etc.? Rolls eyes.
Some time ago after having read this [*] Wired article, I joked that
Redmond and Redhat have merged and Poettering is in possession of the
Windows source code. I'm still n
Didier Kryn writes:
> Le 02/01/2016 03:44, Stephanie Daugherty a écrit :
>> Regardless of who proposed it, merged /usr is still a reckless change
> that needlessly complicates things.
>
>
> Hey Stephanie.
>
> The simple fact of splitting executables between two different
> directories *is*
* On 2016 05 Jan 08:47 -0600, Rainer Weikusat wrote:
> (still) quite plainly states that udev (it names no other examples) is
> developed based on the assumption that / and /usr reside on the same
> device and that any bug reports regarding this are WONTFIXes. IOW,
> that's a policy decision certai
- Original Message -
> From: "Roger Leigh"
> Regarding the comments people made about having separate / and /usr
> filesystems. While it was common historically, there is little or no
> practical benefit to doing so in 2016. Storage sizes make it
> unnecessary for pretty much all practi
- Original Message -
> From: "Didier Kryn"
> Le 02/01/2016 03:44, Stephanie Daugherty a écrit :
>> Regardless of who proposed it, merged /usr is still a reckless change > that
>> needlessly complicates things.
>
> The simple fact of splitting executables between two different
> direc
Clarke Sideroad writes:
> So I've been thinking more about this as to why?
>
> It is quite obvious that it is driven by Redhat to be the same as Oracle
> Solaris, they say as much.
That's "quite obviously" an after-the-fact justification and the
corresponding freedesktop.org text,
http://www.fre
So I've been thinking more about this as to why?
It is quite obvious that it is driven by Redhat to be the same as Oracle
Solaris, they say as much.
The base reason I can see is part of a marketing job showing the
apparent ease of change when trying to sell Redhat servers to replace
Oracle Server
Micky Del Favero writes:
> Daniel Reurich writes:
>
>> So the potteringisation continues...
>
> If I remember well Solaris has /bin linked to /usr/bin since many years,
> so linking /bin to /usr/bin is not a poetteringisation, or almost it's
> not an original idea of poettering.
Sun/ Oracle don'
Le 04/01/2016 07:22, Steve Litt a écrit :
If you didn't merge /lib and /usr/lib, you could load them from /lib
once the root partition was mounted. This was my entire point.
OK. I think I got it. Sorry, I was slow. So this is the case:
- No initramfs, direct boot to the final rootfs (m
On Sun, 3 Jan 2016 19:02:54 +0100
Didier Kryn wrote:
> Le 02/01/2016 18:39, Steve Litt a écrit :
> > In other words, I don't think this stuff has to be compiled into
> > the kernel monolithically: It just has to be in the right
> > directories on the root partition.
>
> Either a driver is
Please keep to the traditional Linux way and keep /usr/ etc as is.
This shouldn't even be a debate.
Devuan's reason to _BE_ is to not go along with the way Systemd/Linux
is being pulled but to stay what Debian was before the coup:
Gnu/Linux.
Gnu/Linux always had /usr/
Retraining our minds from
Roger Leigh writes:
> On 03/01/2016 14:23, Edward Bartolo wrote:
>> Hi,
>>
>> People don't understand: it is bad to manage their own OS. That is the
>> work for EXPERTS who know BETTER. Users should only be allowed to move
>> the mouse, click its cool buttons, and sometimes use DVDs (CDs) to run
>
Le 02/01/2016 19:06, Steve Litt a écrit :
But there's a solution: Initramfs! Cool! Except that initramfs is one
or two more orders of magnitude more complicated than executable
splitting. So the slight simplification of merging directories buys you
a huge complication of initramfs black-boxism.
On Sun, 3 Jan 2016 18:36:48 +0100
Didier Kryn wrote:
> > I was told that the "s" in /sbin and /usr/sbin stands for*staticly*
> > built binaries.
>
> I guess it means "Sysadmin only" :-) much like the "System"
> submenu in Debian's menu.
Could be a logical explanation :)
--
richard luca
Le 02/01/2016 18:39, Steve Litt a écrit :
In other words, I don't think this stuff has to be compiled into
the kernel monolithically: It just has to be in the right directories
on the root partition.
Either a driver is built in the kernel or it is in a loadable
module. In the last case, th
Le 02/01/2016 11:47, richard lucassen a écrit :
I was told that the "s" in /sbin and /usr/sbin stands for*staticly*
built binaries.
I guess it means "Sysadmin only" :-) much like the "System"
submenu in Debian's menu.
___
Dng mailing list
Dng@
Le 02/01/2016 11:27, k...@aspodata.se a écrit :
Initrd would be an alt. solution in the nfs case, but there you
basically have the same split, initrd beeing the small fs, nfs-/
beeing the big.
That's a case where initramfs is really usefull because you can do
a lot of tricks in the initramfs
Thank you, Roger, for a well reasoned and coherent explanation on /usr
merge.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
On Sun, Jan 3, 2016 at 8:25 AM, Roger Leigh wrote:
> Regarding the comments people made about having separate / and /usr
> filesystems. While it was common historically, there is little or no
> practical benefit to doing so in 2016. Storage sizes make it unnecessary
> for pretty much all practi
On 03/01/2016 14:23, Edward Bartolo wrote:
Hi,
People don't understand: it is bad to manage their own OS. That is the
work for EXPERTS who know BETTER. Users should only be allowed to move
the mouse, click its cool buttons, and sometimes use DVDs (CDs) to run
recovery software. Other than that,
On 03/01/2016 14:33, Svante Signell wrote:
Hi Roger,
Could you please send your text below to debian-devel too? Here at
Devuan most people are aware of the issues. Unfortunately many of the
Debian developers/maintainers aren't :(
None of this is new. It's merely repeating the details of discu
Hi Roger,
Could you please send your text below to debian-devel too? Here at
Devuan most people are aware of the issues. Unfortunately many of the
Debian developers/maintainers aren't :(
On Sun, 2016-01-03 at 13:25 +, Roger Leigh wrote:
>
> It's not something that nefarious. It's about inex
Hi,
People don't understand: it is bad to manage their own OS. That is the
work for EXPERTS who know BETTER. Users should only be allowed to move
the mouse, click its cool buttons, and sometimes use DVDs (CDs) to run
recovery software. Other than that, it is bad management.
[/sarcasm]
Edward
>
On 02/01/2016 23:39, Arnt Karlsen wrote:
On Sat, 02 Jan 2016 05:50:15 -0500, Mitt wrote in message
:
Not sure about poetteringisation (of how should this be spelled?)
but take a look at this link:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
and this
https://fedorapr
On Sat, 02 Jan 2016 05:50:15 -0500, Mitt wrote in message
:
> Not sure about poetteringisation (of how should this be spelled?)
> but take a look at this link:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>
> and this
> https://fedoraproject.org/wiki/Features/UsrMove
On Sat, 2 Jan 2016 09:40:16 +0100
Didier Kryn wrote:
> Debian has a tradition to do more in the initramfs than loading
> modules. They use to prepare some tmpfs filesystems before mounting
> the rootfs. If they now cast their initramfs for systemd, it renders
> it unavoidable. I think it ju
On Sat, 02 Jan 2016 05:50:15 -0500
Mitt Green wrote:
> and this
> https://fedoraproject.org/wiki/Features/UsrMove (see owners)
Very nice! The preceding article gives a list of everything you'd want
to statically compile and put in /bin or /sbin to de-necessitate
initramfs for the purpose of fin
On Sat, 2 Jan 2016 10:06:54 +0100
Didier Kryn wrote:
> Le 02/01/2016 03:44, Stephanie Daugherty a écrit :
> > Regardless of who proposed it, merged /usr is still a reckless
> > change > that needlessly complicates things.
>
>
> Hey Stephanie.
>
> The simple fact of splitting execu
On Sat, 2 Jan 2016 09:40:16 +0100
Didier Kryn wrote:
> Le 02/01/2016 03:25, Steve Litt a écrit :
> > Everything you say above
>
> Sorry Steve if I overlooked your post.
>
> Debian has a tradition to do more in the initramfs than loading
> modules. They use to prepare some tmpfs fil
On Sat, 2 Jan 2016 13:34:00 +0100 (CET)
k...@aspodata.se wrote:
> > I was told that the "s" in /sbin and /usr/sbin stands for *staticly*
> > built binaries.
>
> Interesting, but it seems not be the case now:
>
> # ldd /sbin/ifconfig
> linux-gate.so.1 => (0xb7741000)
> libc.so.
Richard Lucassen:
...
> I was told that the "s" in /sbin and /usr/sbin stands for *staticly*
> built binaries.
Interesting, but it seems not be the case now:
# ldd /sbin/ifconfig
linux-gate.so.1 => (0xb7741000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb75c)
Not sure about poetteringisation (of how should this be spelled?)
but take a look at this link:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
and this
https://fedoraproject.org/wiki/Features/UsrMove (see owners)
and even this
http://lists.busybox.net/pipermail/busybox/20
On Sat, 2 Jan 2016 11:27:32 +0100 (CET)
k...@aspodata.se wrote:
> The "splitting" to four dirs., you have /sbin and /usr/sbin. And then
> there is /usr/local/{bin,sbin} and ~/bin. So while it's true it would
> be simplification to move all bin things to a single directory, there
> might be some
Didier:
...
> The simple fact of splitting executables between two different
> directories *is* a complication; merging them back would be a
> *simplification* :-).
The "splitting" to four dirs., you have /sbin and /usr/sbin. And then
there is /usr/local/{bin,sbin} and ~/bin. So while it's
Clarke Sideroad:
...
> Devuan _is_, at least at this point, "Debian without systemd", and I
> think that is what people like myself are looking for.
...
I'd like a system that respects the local administrator, i.e. don't
make it hard for he or she to bend the system to their liking.
So:
. Debian
Steve Litt:
> On Fri, 01 Jan 2016 23:32:40 +0100
> Micky Del Favero wrote:
>
> > Daniel Reurich writes:
...
> > > Devuan will continue to use an initramfs as a default is that is the
> > > only sane approach that provides broad support for most use cases.
> > > But of course we will support user
Le 02/01/2016 03:44, Stephanie Daugherty a écrit :
Regardless of who proposed it, merged /usr is still a reckless change > that
needlessly complicates things.
Hey Stephanie.
The simple fact of splitting executables between two different
directories *is* a complication; merging them
Le 02/01/2016 03:25, Steve Litt a écrit :
Everything you say above
Sorry Steve if I overlooked your post.
Debian has a tradition to do more in the initramfs than loading
modules. They use to prepare some tmpfs filesystems before mounting the
rootfs. If they now cast their initramfs f
Le 01/01/2016 21:47, Micky Del Favero a écrit :
years ago i've built a cluster of diskless servers that network booted
using a initramfs filesystem, it's not so obscure, I admit it wasn't
trivial to made the initramfs, but was simpler than you can think.
My experience is the same as yours :
On 01/01/2016 03:06 AM, Daniel Reurich wrote:
> So the potteringisation continues...
>
> Are we going to allow this sort of behaviour into Devuan??
>
I have no say in the matter, but I do feel free to express my opinion
here. (-:
Devuan _is_, at least at this point, "Debian without systemd", and
Regardless of who proposed it, merged /usr is still a reckless change that
needlessly complicates things.
The /usr and / split hasn't been perfectly followed, ever, but, still
achieves the goal of having a system that can be recovered from various
problems easily.
I should be able to substitute /
On Fri, 01 Jan 2016 23:32:40 +0100
Micky Del Favero wrote:
> Daniel Reurich writes:
>
> > No, rather freedesktop.org and Poettering are largely synonomous.
> > Most of what is proposed there lately is mostly either from
> > Poettering or his minions and a lot of what they propose is crap at
> >
On Fri, 01 Jan 2016 21:47:57 +0100
Micky Del Favero wrote:
> Steve Litt writes:
>
> > This *is* poetterization, regardless of what Sun or anyone else did
> > before. It's supported by Freedesktop.org, and I think everyone here
> > can agree that anything Freedesktop supports is anti-init choice
On Fri, 1 Jan 2016 19:33:41 +0100
Didier Kryn wrote:
> Le 01/01/2016 18:07, Steve Litt a écrit :
> > On Fri, 01 Jan 2016 15:45:49 +0100
> > Micky Del Favero wrote:
> >
> >> Daniel Reurich writes:
> >>
> >>> So the potteringisation continues...
> >> If I remember well Solaris has /bin link
Daniel Reurich writes:
> No, rather freedesktop.org and Poettering are largely synonomous.
> Most of what is proposed there lately is mostly either from Poettering
> or his minions and a lot of what they propose is crap at best and
> destructive to the non-systemd ecosystem at worst.
ok, but "a
On 02/01/16 09:47, Micky Del Favero wrote:
> Steve Litt writes:
>
>> This *is* poetterization, regardless of what Sun or anyone else
>> did before. It's supported by Freedesktop.org, and I think everyone
>> here can agree that anything Freedesktop supports is anti-init
>> choice, anti-simplicity,
Steve Litt writes:
> This *is* poetterization, regardless of what Sun or anyone else did
> before. It's supported by Freedesktop.org, and I think everyone here
> can agree that anything Freedesktop supports is anti-init choice,
> anti-simplicity, anti-modularity, and pro-systemd.
So anything fre
Le 01/01/2016 18:07, Steve Litt a écrit :
On Fri, 01 Jan 2016 15:45:49 +0100
Micky Del Favero wrote:
Daniel Reurich writes:
So the potteringisation continues...
If I remember well Solaris has /bin linked to /usr/bin since many
years, so linking /bin to /usr/bin is not a poetteringisation,
On Fri, 01 Jan 2016 15:45:49 +0100, Micky wrote in message
<868u498ijm@minnie.mesina.net>:
> Daniel Reurich writes:
>
> > So the potteringisation continues...
>
> If I remember well Solaris has /bin linked to /usr/bin since many
> years, so linking /bin to /usr/bin is not a poetteringisati
On Fri, 01 Jan 2016 15:45:49 +0100
Micky Del Favero wrote:
> Daniel Reurich writes:
>
> > So the potteringisation continues...
>
> If I remember well Solaris has /bin linked to /usr/bin since many
> years, so linking /bin to /usr/bin is not a poetteringisation, or
> almost it's not an origin
Daniel Reurich writes:
> So the potteringisation continues...
If I remember well Solaris has /bin linked to /usr/bin since many years,
so linking /bin to /usr/bin is not a poetteringisation, or almost it's
not an original idea of poettering.
Ciao, Micky
--
The sysadmin has all the answers, exp
Children! Down that path lies madness.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.o
So the potteringisation continues...
Are we going to allow this sort of behaviour into Devuan??
Daniel
Forwarded Message
Subject: support for merged /usr in Debian
Resent-Date: Thu, 31 Dec 2015 00:52:09 + (UTC)
Resent-From: debian-de...@lists.debian.org
Date: Thu, 31 Dec 2
71 matches
Mail list logo
