| View previous topic :: View next topic |
| Author |
Message |
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
 Posted: Mon Jun 17, 2013 11:14 pm Post subject: Systemd headsup of L.P. - reads like at first of april |
 |
|
This reads like first april of a post. As a last "fanboy" of LP at Gentoo forums I hope he gets it right now ...
| LP wrote: | [HEADSUP] systemd cgroup changes
From: Lennart Poettering
To: systemd Mailing List <systemd-devel@lists.freedesktop.org>
Heya,
in the past weeks we have been sitting down with the cgroup maintainer
in the kernel, Tejun Heo, at a number of conferences. During these
discussions it became very clear to us that the way systemd currently
exposes cgroups exposes too much of the guts of it, and is incompatible
with how the kernel cgroup subsystem will be cleaned up in the near-term
feature.
Hence I'd like to let everybody in the systemd community know that the
cgroup settings, commands and APIs in systemd will change soon. Please
be aware of this when you make use of advanced cgroup functionality.
- The functionality to define orthogonal cgroup trees for the various
controllers will be removed. In fact we'll likely remove the entire
API for setting abritrary per-controller paths for each unit. Instead
we will introduce a new concept of "Slices" which will allow you to
partition system resources in a tree and move units, users, and
machines to arbitrary places in it. There will only be a single cgroup
tree, but the various controllers may be enabled/disabled separately
for each group, so that individual controllers might only see a
subtree of the full tree, but not orthogonal trees anymore. The
ConrolGroup= unit setting will go away, and be replaced by Slice= plus
EnableControllers= or so.
- ControlGroupPersistent= will likely go away, systemd will be the only
component of the OS that sets up the cgroup tree.
- ControlGroupAttribute= will most likely go away entirely. Instead we
will introduce more high level controls like the existing CPUShares=,
MemoryLimit= and so on. (BTW, if there's a specific attribute we currently don't
cover but which you really need let us know and we will see if we can
add a high-level control for it.)
- CPUShares=, MemoryLimit= and so on will continue to exist as before.
- "systemctl set-cgroup" will go away, and be replaced by systemctl
"set-slice" or something similar.
- "systemctl set-cgroup-attr" will go away, and be replaced by
"systemctl set-attr" or so, which only can set the high level
attributes.
- The (currently undocumented) bus APIs for cgroup controls will be
replaced.
Sorry for this disruption. Thankfully we have not documented these APIs
yet and we haven't made the funcionality too widely known. We hate to
make incompatible changes like this, but in this case it's probably
better to clean this up early when it is not often used instead of late
when everybody already uses this.
This will remove a few bits of functionality but all in all give you a
lot more back. For example, the "slice" functionality will provide you
with a powerful and naturally built-in way to partition your resources
in arbitrary ways, and can be used to not only assign resource limits to
systemd units but also login users and machines.
We haven't hashed out all the details yet, but expect this to land very
soon in git.
Thanks,
Lennart |
|
|
| Back to top |
|
 |
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Mon Jun 17, 2013 11:34 pm Post subject: |
|
|
I am just using systemd without problems and without learning much new, because I didn't have to, because of problems missing.
I wanted to look into crgroups all the time, but I knew of "orthogonal cgroup trees" and felt this too complicated too understand, becaus I couldn't imagine a way how this works:
If you have orthogonal information you should provide each kind a seperate dimension!
From what I know about the filesystem and my several tries to get my music retrievable in seperate directiories: A simple filesystem is not the best tool to get orthogonal data of several dimensions cleanly arranged. It is like drawing a cuboid of 11 dimensions on a two dimensional sheet of paper.
What me wonders:
Nearly everybody of Linux-developers, Redhat, openSUSE etc had studied computer science: Informatik callled in Germany, the art to structure data. But it took years for them to recognize orthogonality ... |
|
| Back to top |
|
|
broken_chaos
Guru
Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada
|
| Posted: Tue Jun 18, 2013 12:54 am Post subject: |
|
|
I don't like Poettering very much (or, more specifically, I don't like how he thinks of himself/his ideas and then acts on those thoughts -- i.e., "one true way"), but I don't really see why it would read like a joke... It seems fairly straightforward ("something was over-engineered and needed simplification"), aside from the confusing need for systemd to constantly invent a new term for things ("systemd unit" = "service", "systemd slice" = "cgroup", etc.)
I guess maybe it's a problem if someone was using this in production, though I can't say I'd trust something really important to a project that seems to have a very laissez-faire attitude towards releases and changes (at least not without planning for eventually needing to completely tear apart and rebuild regularly). |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Jun 18, 2013 2:43 am Post subject: |
|
|
| Why would systemd users need to care about it doing something in an overcomplicated way internally? Its entire philosophy is supposed to be "No user-serviceable parts inside". |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Tue Jun 18, 2013 3:28 pm Post subject: |
|
|
| broken_chaos wrote: | | (I don't like how he thinks of himself/his ideas and then acts on those thoughts -- i.e., "one true way"), but I don't really see why it would read like a joke... |
Having read all of systemds advertising ("one true way: cgroups! cgroups! crgroups!") and imaging to read this text first of april: best joke ever 
But as a confident user of systemd I hope I don't feel anything of this internal change when the next release happens, or should I wait upgrading one release further ... |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Tue Jun 18, 2013 3:47 pm Post subject: |
|
|
you don't need sysd for cgroups... already existing init daemons configure /sys/cgroups quite nicely. What RH have works very well
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Tue Jun 18, 2013 3:54 pm Post subject: |
|
|
Naib,
You said far too much. The first four words were just fine on their own. :)
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Mon Jun 24, 2013 5:56 pm Post subject: |
|
|
| Naib wrote: | | you don't need sysd for cgroups... already existing init daemons configure /sys/cgroups quite nicely. What RH have works very well |
Nobody of Gentoo really recognizes implications?
| Quote: | Re: [HEADSUP] cgroup changes
From:
Lennart Poettering <lennart@poettering.net> (Red Hat, Inc.)
To:
Andy Lutomirski <luto@amacapital.net>
Groups:
gmane.comp.sysutils.systemd.devel
References: 1 2
On Sat, 22.06.13 15:19, Andy Lutomirski (luto@amacapital.net) wrote:
> 1. I put all the entire world into a separate, highly constrained
> cgroup. My real-time code runs outside that cgroup. This seems to
> exactly what slices are for, but I need kernel threads to go in to
> the constrained cgroup. Will systemd support this?
I am not sure whether the ability to move kernel threads into cgroups
will stay around at all, from the kernel side. Tejun, can you comment on this?
>
> 2. I manage services and tasks outside systemd (for one thing, I
> currently use Ubuntu, but even if I were on Fedora, I have a bunch
> of fine-grained things that figure out how they're supposed to
> allocate resources, and porting them to systemd just to keep working
> in the new world order would be a PITA [1]).
>
> (cgroups have the odd feature that they are per-task, not per thread
> group, and the systemd proposal seems likely to break anything that
> actually wants task granularity. I may actually want to use this,
> even though it's a bit evil -- my real-time thread groups have
> non-real-time threads.)
Here too, Tejun is pretty keen on removing the ability of splitting up
threads into cgroups from the kernel, and will only allow this
per-process. Tejun, please comment!
> I think that what I want are something like sub-unit cgroups -- I
> want to be able to ask systemd to further subdivide the group for my
> unit, login session, or whatever. Would this be reasonable?
> (Another way of thinking of this is that a unit would have a whole
> cgroup hierarchy instead of just one cgroup.)
The idea is not even to allow this. Basically, if you want to partitions
your daemon into different cgroups you need to do that through systemd's
abstractions: slices and services. To make this more palatable we'll
introduce "throw-away" units though, so that you can dynamically run
something as a workload and don't need to be concerned about naming
this, or cleaning it up.
> I think that the single-hierarchy model will require that I
> subdivide my user session so that the default sub-unit cgroup is
> constrained similarly to the default slice. I'll lose
> functionality, but I don't think this is a showstopper.
>
> A different approach would be to allow units to (with systemd's
> cooperation) escape into their own, dynamically created unit. This
> seems kind of awful.
This is basically what I meant with "throw-away" units.
> 3. My code runs unprivileged, but it still wants to configure
> itself. If needed, I can write a little privileged daemon to handle
> the systemd calls.
So, at least in the beginning I am pretty sure that manipulating the
resource parameters we'll restrict to root-only, since this is much more
security than one might assume and we simply don't oversee this all.
> I think I can get away without anything fancy if a unit (login
> session?) grant the right to manipulate sub-unit cgroups to a
> non-root user.
As mentioned, this will not be possible.
> 4. As mentioned, I'm on Ubuntu some of the time. I'd like to keep
> the same code working on systemd and non-systemd systems.
>
> How hard would it be to run systemd as just a cgroup controller?
> That is, have systemd create its slices, run exactly one unit that
> represents the whole system, and let other things use the cgroup
> API.
I have no idea, I don't develop Ubuntu. They will have to come up with
some cgroup maintenance daemon of their own. As I know them they'll
either do a "port" of the systemd counter part (but that's going to be
tough!), or they'll stick something half-baked into Upstart...
Sorry, if this all sounds a bit disappointing. But yeah, this all is not
a trivial change...
Lennart |
| Quote: | All changes to cgroup attributes must go through systemd. If the WM
wants to freeze or adjust OOM he needs to issue systemd bus calls for
that.
...
The thermal stuff is probably best done in-kernel i guess... Too
dangerous/subject-to-latency for userspace, no?
Lennart |
|
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Mon Jun 24, 2013 11:10 pm Post subject: |
|
|
Tejun Heo has answered with harsh words.
| Quote: | Re: [HEADSUP] cgroup changes
From: Tejun Heo <tj@kernel.org>
...
> cgroups are most certainly something that a binary can be aware of.
> It's not like a sysctl knob at all -- it's per process. I have lots
No, it definitely is not. Sure it is more granular than sysctl but
that's it. It exposes control knobs which are directly tied into
kernel implementation details. It is not a properly designed
programming API by any stretch of imagination. It is an extreme
failure on the kernel side that that part hasn't been made crystal
clear from the beginning. I don't know how intentional it was but the
whole thing is completely botched.
cgroup *never* was held to the standard necessary for any widely
available API and many of the controls it exposes are exactly at the
level of sysctls. As the interface was filesystem, it could evade
scrutiny and with the hierarchical organization also gave the
impression that it's something which can be used directly by
individual applications. It found a loophole in the way we implement
and police kernel APIs and then exploited it like there's no tomorrow.
We are firmly bound to maintain what already has been exposed from the
kernel side and I'm not gonna break any of them but the free-for-all
cgroup is broken and deprecated. It's gonna wither and fade away and
any attempt to reverse that will be met with extreme prejudice.
> of binaries that have worked quite well for a couple years that move
> themselves into different cgroups. I have no problem with a unified
> hierarchy, but I need control of my little piece of the hierarchy.
>
> I don't care if the interface to do so changes, but the basic
> functionality is important.
Whether you care or not is completely irrelevant. Individual binaries
widely incorporating cgroup details automatically binds the kernel.
It becomes excruciatingly painful to back out after certain point. I
don't think we're there yet given the overall immaturity and brokeness
of cgroups and it's imperative that we back the hell out as fast as
possible before this insanity spreads any wider.
Thanks. |
| Quote: | In terms of API, it is firmly at the level of sysctl. That's it.
While I agree that having a proper kernel API for hierarchical
resource management could be nice. That currently is out of scope.
We're already knee-deep in shit with the limited capabilities we're
trying to implement. Also, I really don't think cgroup is the right
interface for such thing even if we get to that. It should be part of
the usual process/thread model, not this completely separate thing on
the side.
> IOW, please, when designing this, please specify an API that programs
> are permitted to use, and let that API be reviewed.
cgroup is not that API and it's never gonna be in all likelihood. As
for systemd vs. non-systemd compatibility, I'm afraid I don't have a
good answer. This is still all in a pretty earlly phase and the
proper abstractions and APIs are being figured out. Hopefully, we'll
converge on a mostly compatible high-level abstraction which can be
presented regardless of the actual base system implementation. |
|
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Tue Jun 25, 2013 10:39 am Post subject: |
|
|
So, everyone is clueless
| Quote: | Re: [HEADSUP] cgroup changes
From: Lennart Poettering
On Tue, 25.06.13 02:21, Brian Bockelman (bbockelm@cse.unl.edu) wrote:
> A few questions came to mind which may provide interesting input
> to your design process:
> 1) I use cgroups heavily for resource accounting. Do you envision
> me querying via dbus for each accounting attribute? Or do you
> envision me querying for the cgroup name, then accessing the
> controller statistics directly?
Good question. Tejun wants systemd to cover that too. I am not entirely
sure. I don't like the extra roundtrip for measuring the accounting
bits. ...
....
Lennart |
Lennart wild guesses (....) what direction systemd should take ... |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2178
|
| Posted: Wed Jun 26, 2013 8:17 am Post subject: |
|
|
| Quote: | ...
Good question. Tejun wants systemd to cover that too.
... |
I wondered why a replacement init system was called "system" and not "init++" or something; now it's obvious, it's a new OS.
_________________
Greybeard |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Wed Jun 26, 2013 2:48 pm Post subject: |
|
|
| Goverp wrote: | | Quote: | ...
Good question. Tejun wants systemd to cover that too.
... |
I wondered why a replacement init system was called "system" and not "init++" or something; now it's obvious, it's a new OS. |
You found the point Gentoo is concerned, which is why I posted this all:
T.H. is not part of the systemd project but kernel ... |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6145
Location: Dallas area
|
| Posted: Wed Jun 26, 2013 3:23 pm Post subject: |
|
|
It was obvious, at least to many, from the get go that systemd was being designed
as a wrapper around the kernel and other important system pieces.
I think back to the early days of windows, where it started off as a process started under dos,
and even up to win98 it could be started separately or replaced completely, but it wasn't long
until they just made it all one big mish-mash. When that happens then one is in control of everything.
I think that may be the long term goal of LP and company, and maybe even redhat for that matter.
They can't control Linus and thus the direction of the kernel as is, but if systemd becomes
"the defacto standard" then they have a foot in the door of controlling things and could possibly
call the shots for kernel level changes.
Just a guess and time will tell.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2178
|
| Posted: Thu Jun 27, 2013 8:56 am Post subject: |
|
|
Would it be fair to describe the desire to extract kernel function (udev, PolicyShit, etc) into user-space "Hurd mentality"?
_________________
Greybeard |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Thu Jun 27, 2013 10:55 am Post subject: |
|
|
| Goverp wrote: | | Would it be fair to describe the desire to extract kernel function (udev, PolicyShit, etc) into user-space "Hurd mentality"? |
I would logically be forced to agree with you as...
I would say druh for the reverse desire to extract user-space functions (http servers / sound servers...) into kernel-space... 
_________________
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3515
|
| Posted: Sat Jun 29, 2013 1:39 pm Post subject: |
|
|
I've said this before, but each time I try to clarify it a bit...
My primary objection to systemd, and really with freedesktop.org stuff in general is that it all lacks casual hackability.
I go back to "the good old days" of Linux, back when you always had to come up with some sort of xf86config file, the days when you had to build your own kernel in order to get sound or the cdrom working.
I'm not advocating going back to that - I know we're better off today. But back in "the good old days" that stuff was all casually hackable. A little time with the web and man pages, and you could get a working xf86config and kernel config - you didn't have to become an expert or a developer.
With systemd and freedesktop.org stuff the goal is "just works", but somewhere on the path they also lost that casual hackability. For instance, those XML "magic strings" truly are magic - once you have it you can see how it works, but it would have been chance to have ever cooked it up on your own. When you go to the sites looking for documentation, you find become-a-developer level stuff, not casual hacking stuff.
Perhaps the real message here is that this is MY role in the current Linux community - generating more "casual hacker" documentation for things like systemd and freedesktop.org. There are already several guides to "writing udev rules", and to be fair, I haven't done enough reading at any of them. But there is always room for more. Several searches of the "casual hacking" sort for systemd (for instance "systemd" and "workaround") yields nothing - there are only developer and user hits.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
|
| Back to top |
|
|
GFCCAE6xF
Apprentice
Joined: 06 Aug 2012
Posts: 295
|
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Wed Jul 03, 2013 5:59 pm Post subject: |
|
|
@rorgoroth, have you been able to boot using this new beast?
Regarding the amount of changes necessary to achieve that cgroups handling change
I would assume this new release might hardly reach RC quality due to the rush this was all reprogramed ?
I would have hoped any of the Gentoo developers had taken a stand in the discussion about all this restructering, because this will be imposed on us by the linux kernel.
PS: And ... of cause, some new journald features appeared with system-205 that will be of benefit! |
|
| Back to top |
|
|
GFCCAE6xF
Apprentice
Joined: 06 Aug 2012
Posts: 295
|
| Posted: Wed Jul 03, 2013 6:18 pm Post subject: |
|
|
In short: Not yet.
I actually only have Gentoo on my "laptop"/notebook atm and it runs stable only, no systemd 'cause I don't fancy having to jump through so many damn hoops. I put Arch back on my main machine and got this news via arch-dev, they shall be packaging it up and putting it in their testing repo tonight so I shall get a chance to play with it tonight/tomorrow morning.
Regarding the changes causing less then RC quality, they Arch guy did say in his email "I do NOT expect that this release will ever move to [core], but maybe I'll be pleasantly surprised." It does seem like a skip-able release due to being only part way through changes, of course it will work as normal for everyone that aren't doing anything extremely exotic, at least afiak anyway. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6145
Location: Dallas area
|
| Posted: Sat Sep 28, 2013 10:25 am Post subject: |
|
|
Bwahahaha on the latest news read.
Two things.
I never thought that putting /usr on a separate file system was a good thing.
I and others tried to tell everyone that it wasn't a good idea to follow
Pottering and company so close that one could taste his breakfast
30 minutes after he ate it, but oh no, "changes won't come for a long time".
So now, because of upstream changes people have to modify their systems.
In other words, Pottering is driving the boat. So much for the assurances from
the systemd sycophants. 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Sep 29, 2013 12:47 am Post subject: |
|
|
| Anon-E-moose wrote: | | I never thought that putting /usr on a separate file system was a good thing. |
Well I did ;-) I learnt the hard way to split partitions, decades ago.
And no "N+1 True Way" johhny-come-lately "look ma, it's inturgrayted" is going to change my mind about it.
| Quote: | I and others tried to tell everyone that it wasn't a good idea to follow
Pottering and company so close that one could taste his breakfast
30 minutes after he ate it, but oh no, "changes won't come for a long time".
So now, because of upstream changes people have to modify their systems.
In other words, Pottering is driving the boat. So much for the assurances from
the systemd sycophants. :roll: |
No doubt I agree with you, and would find the latest manifestation of this stupidity amusing, but there's no context for what you're talking about: it's traditional to give a url or two for background. |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Sun Sep 29, 2013 9:23 am Post subject: |
|
|
| ulenrich wrote: | I am just using systemd without problems and without learning much new, because I didn't have to, because of problems missing.
I wanted to look into crgroups all the time, but I knew of "orthogonal cgroup trees" and felt this too complicated too understand, becaus I couldn't imagine a way how this works:
If you have orthogonal information you should provide each kind a seperate dimension!
From what I know about the filesystem and my several tries to get my music retrievable in seperate directiories: A simple filesystem is not the best tool to get orthogonal data of several dimensions cleanly arranged. It is like drawing a cuboid of 11 dimensions on a two dimensional sheet of paper.
What me wonders:
Nearly everybody of Linux-developers, Redhat, openSUSE etc had studied computer science: Informatik callled in Germany, the art to structure data. But it took years for them to recognize orthogonality ... |
Whether you can imagine that (and that varies from one person to the next one), the best way to explain 21-dimensional-spaces is, actually, paper. Just don't draw it. Write the function.  |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6145
Location: Dallas area
|
| Posted: Sun Sep 29, 2013 10:49 am Post subject: |
|
|
| steveL wrote: | | Anon-E-moose wrote: | | I never thought that putting /usr on a separate file system was a good thing. |
Well I did I learnt the hard way to split partitions, decades ago. |
I have much of my system split out, /usr/portage/distfiles, is a separate partition, so is /home and /usr/local
I also have rsync run nightly to two separate disks and / backed up once a week to two offline disks.
I'm not dismissing those that do put /usr on a separate partition, I just personally never saw the use of it.
/ is 4.5 Gig and /usr is 3.9 of that.
| Quote: |
No doubt I agree with you, and would find the latest manifestation of this stupidity amusing, but there's no context for what you're talking about: it's traditional to give a url or two for background. |
I did mention that I saw it on the latest news.
| Quote: | 2013-09-27-initramfs-required
Title Separate /usr on Linux requires initramfs
...
Due to many upstream changes, properly supporting Linux systems that
have /usr missing at boot time has become increasingly difficult.
Despite all our efforts, it already breaks in some exotic
configurations, and this trend is likely to grow worse. |
Personally I've not upgraded udev and am still happily running 171-r6 without any problems.
If it breaks somewhere in the future, I may just go to a static dev.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
grey_dot
Tux's lil' helper
Joined: 15 Jul 2012
Posts: 142
|
| Posted: Fri Oct 04, 2013 10:23 pm Post subject: |
|
|
| Anon-E-moose wrote: | | steveL wrote: | | Anon-E-moose wrote: | | I never thought that putting /usr on a separate file system was a good thing. |
Well I did ;-) I learnt the hard way to split partitions, decades ago. |
I have much of my system split out, /usr/portage/distfiles, is a separate partition, so is /home and /usr/local
I also have rsync run nightly to two separate disks and / backed up once a week to two offline disks.
I'm not dismissing those that do put /usr on a separate partition, I just personally never saw the use of it.
/ is 4.5 Gig and /usr is 3.9 of that.
| Quote: |
No doubt I agree with you, and would find the latest manifestation of this stupidity amusing, but there's no context for what you're talking about: it's traditional to give a url or two for background. |
I did mention that I saw it on the latest news.
| Quote: | 2013-09-27-initramfs-required
Title Separate /usr on Linux requires initramfs
...
Due to many upstream changes, properly supporting Linux systems that
have /usr missing at boot time has become increasingly difficult.
Despite all our efforts, it already breaks in some exotic
configurations, and this trend is likely to grow worse. |
Personally I've not upgraded udev and am still happily running 171-r6 without any problems.
If it breaks somewhere in the future, I may just go to a static dev. |
I find it kind of funny that mostly everyone sees linux from its desktop perspective, meanwhile its generally no better than windows or mac (or even freebsd) this way. One of the areas linux really rocks is embedded applications, where one can really benefit from having /usr cut off to a separate partition. I mentioned this approach here (https://bugs.gentoo.org/show_bug.cgi?id=485716), and from I can tell having initrd to mount /usr makes things really complicated. Without initrd things work just fine straight out of box, and in most simple cases (like no root on lvm on raid on nfs on etc) its just an unneccesary kludge. Just my 2 cents here. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
