RHEL 7 Roadmap, will be based on Fedora 18

[tux99]

According to the following article (in German) RHEL 7 will be based on Fedora 18 and a first public beta will be released during the first half of 2013.
http://www.heise.de/newsticker/meldung/Roadmap-fuer-Red-Hat-Enterprise-Linux-7-1631561.html

I really hope RH will not include 'systemd' in RHEL7 but rather keep 'init'.
Systemd will not be welcomed by most sysadmins as the faster boot time is irrelevant on servers and the hassle of having to retrain to a new half-baked boot infrastructure without any real advantage is a waste of time.

Edit: actually on this slide RH states systemd will be part of RHEL7
http://www.heise.de/imgs/09/8/8/4/4/8/6/24-9377c98f0bf4d210.png

This slide is also interesting:
http://www.heise.de/imgs/09/8/8/4/4/8/6/57-fa10e354b16c792f.png

Also some info about RHEL 6.4 (xorg rebase to 1.13, yay!):
http://www.heise.de/imgs/09/8/8/4/4/8/6/15-45ad1a49c2d064a9.png

[zxq9]

There may be quite a few folks who decide to skip RHEL 7 and jump from 6 to 8 in that case. My other feelings on the root issue have been expressed elsewhere.

It will be interesting to see how this turns out. Anyway, its not just systemd that is a major subsystem change. I wouldn't dare expose business clients to Gnome Shell (maybe their kids) and considering the film of convolution smeared liberally over the base architecture of that WM I don't think it will be a sane project for a few more years. And yet still the changes are not just systemd and Gnome Shell -- its quite deeply a very different system than RHEL 6. I get the feeling that 7 is going to be an ugly mutt bastard of ideas that won't be mature until 8.

That this is totally unnecessary is apparently not entering into anyone's thinking up the hill. Using systemd as an example, what amounts to an emotional aversion to shell scripts being used for both data (settings) and code (init execution) as they have been for years did not produce intermediate solutions that would have been usable by init or systemd in a way that could still achieve parallel boot by say, spawning multiple sub-shells and altering scripts to always return a definite exit code (as they should have already).

Parallel boot sounds like a silly position to argue on since non-mobile (as in the entire customer base) doesn't care about boot times, but parallel boot was one of the clinching arguments in favor of systemd. It sounds like someone has a daydream that RHEL 7 would be ready for mobile -- but that is preposterous (not forever, but for now, definitely). My point is that we didn't have to give up on init before systemd was ready to stand on its own, and that would have been a benefit to customers of 7. I can't help but wonder if this would have forced a cleaner development path -- but LP spoke, and He spoketh "No!"

Another major argument in favor of the changes was to bang the kinks out of the filesystem and remove the cruft where it was thickest. The most convoluted place was obviously /etc. The init system is intimate with any issues involving /etc but far from the only thing affected by changes to its layout. YAML or ini file formats could have either taken in the data elements of scripts -- and this really is a better idea anyway for the ones that involve a lot of set variables. The remaining scripts could have very easily been altered to pull information from those files in a better organized /etc, and with externally serialized data already being used by init scripts bridging to new init programs that were not shell scripts would have been init-system agnostic and not necessarily disruptive. Instead systemd wasted a lot of time as a project coping with the problem of juggling init scripts that weren't converted or just not easily convertible. This was a major distraction to packagers as a whole and that's just bad for the entire project.

Lately I've been dealing a lot with data serialization and I've become suddenly a huge fan of both YAML and actually just using Scheme as an executable list (and in theory there really isn't any difference between a semantic list and an executable one, but that goes somewhere else...).

This many subsystem changes should have been developed a bit more deliberately and spread across two major versions instead of trying to do it all at once. Resistance within the community, for obvious reasons, set this effort back probably a lot more than Red Hat expected -- but that they expected anything different demonstrates a certain naivete.

[redman]

From the slide (in the German article) I noticed that the memory footprint for installation will be reduced to 512MB. That is a good one.

As for the rest, I hope things will work out fine.
What I fear is something different ...

[Apostate]

Hard to believe that anyone would subject their enterprise customers to gnome-shell but guess it's going to happen.

[scottro]

My feeling, whether correct or not, is that many of the Fedora developers, such as Mr. Hughes and Mr. Poettering seem to have little or no experience with system adminstration. (They get singled out because of Mr Hughes' decision to not require authentication for updating via PackgeKit, which only got changed after making the front page of slashdot, and Mr. Poettering because of the various lengthening of the simple service and chkconfig commands, as well as the lack of an easy equivalent to chkconfig --list|grep on--I think it was our own moderator, Andrew, who showed me a good workaround, ls /etc/systemd/system/*.wants).

At any rate, the big problem is that the Fedora developers with a few exceptions, seem to be younger, probably grew up with smartphones and facebook and think that way. Windows has finally gotten a text install, and if you belong to a domain, only the currently logged in, or last logged in user shows up--Fedora crippled the text install and by default, all users on a system show at a log in. Now, that's not a huge deal, LInux isn't usually used on the desktop in the enterprise yet, and those who do, if that's a concern, can fix it, but it's more the way of thinking that concerns me.

I remember when RHEL 6 came out with the crippled text install, and how many people were rather surprised. Fedora is good for what it is, but it makes RH worse at what it does as there seems to be little or no review.

On the other hand, I doubt RH is going anywhere, and like WIndows, which survives despite poor decisions, simply because it's too much trouble to change, RH will probably survive for many years too. Ubuntu, for example, has its OOM killer be far too sensitive for a server--actually, the whole OOM killer (for those who don't know, the kernel has a thing where if memory--Out Of Memory is what it stands for) is being used, the kernel starts randomly killing things to keep the system usable.

Anyway, in many ways, I'd like to see Linux get slapped down for all its catering to the people who aren't going to change from Windows or OS X anyway, but perhaps, despite we sysadmin types hating it, they're on the right track. Which has more users, Arch or Ubuntu? Or, Linux, with its bloat, and catering to the smartphone user, or FreeBSD which is more a sysadmin system?

Yes, I'm DRASTICALLY oversimplifying, there are several factors to that, but, to make it even more oversimplified, which has more users, Linux or OSX?

Ok, rant over, sorry. But, shucks, after venting, I feel so much better. (Looks for dance icon, but doesn't see one, oh well---ahah....THERE it is.)

[Nathan]

Man, this is some bad news.

[toracat]

Here's a blog post by Jon Masters (Red Hat guy) about his view on systemd:

http://www.jonmasters.org/blog/2011/04/29/response-to-why-systemd/

I was hoping there were more of these guys upstream but ...

[tux99]

QUOTE (scottro @ Jul 4 2012, 01:22 PM)

My feeling, whether correct or not, is that many of the Fedora developers, such as Mr. Hughes and Mr. Poettering seem to have little or no experience with system adminstration.

Very true, although I wouldn't even blame them, but rather their managers who don't realise the damage those skilled but naive programmers are doing to RH.

[scottro]

@tux99, agreed, and I should have put that. (I have in other threads somewhere, maybe not on this forum)

[AndrewSerk]

Andrew holds his fist in the air, angrily shaking it while yelling "Hey you dam kids, get off my operating system and stop trying to turn it into a kindergarten mush the big button pocket gadget system"

Oh well, I guess there is always runlevel 3 and elinks.

[fqberful]

Fedora has been implementing systemd slowly but surely for the last few versions. I must admit it looks and acts like a hose job. But they [Fedora developers] insist it really is better. Only time will tell. They've also fixed chkconfig so that on / off are translated to the proper messages in systemd speak for those things that are implemented in systemd.

As far as Gnome3 ... With a few of the right plug-ins and some tweaking it's actually not too bad. It does take a little time to grow on you. Anything that requires a change from a routine takes some time. Is it better than Gnome2 ? In my opinion Nope. Can it be, sure. And with every release it gets more polished. A couple win users I know think it reminds them of win7 or osx.

Remember also that RHEL like fedora can come with multiple desktop mamangers. If you're not a Gnome fan, I'm sure KDE will be in there as well as a couple others.

Speaking of which, it appears to me that KDE is the one that's truly changed for the worse. Geeze.

The thing that makes me very sad is this: As system people we complain about users that can't handle changes, not even the slightest ones. As system people we are supposed to be unfazed by them [ the system changes] ... But every one of these threads I read I see posts from system people that sound as if any change is going to be the death of them. All I can say is "man up d00ds and dudettes" ... Things evolve. Our time is best spent insuring that evolution doesn't destroy but rather improves. and it can take a few iterations to get it right. Rome wasn't built in a day and neither was RHEL.

</soapbox>

[redman]

QUOTE (fqberful @ Jul 5 2012, 01:07 AM)

The thing that makes me very sad is this:  As system people we complain about users that can't handle changes, not even the slightest ones.  As system people we are supposed to be unfazed by them [ the system changes] ...  But every one of these threads I read I see posts from system people that sound as if any change is going to be the death of them.  All I can say is "man up d00ds and dudettes" ...  Things evolve.  Our time is best spent insuring that evolution doesn't destroy but rather improves.  and it can take a few iterations to get it right.  Rome wasn't built in a day and neither was RHEL.

Changes are natural and yes, they don't come easy.
But we all (devs included) need to focus on what the intended users are...

Fedora is for homeusers, RHEL is for sysadmins.
Homeusers want eye-candy, especially to show off to their Windows-using friends.
Sysadmins do NOT need eye-candy. They want a rock-solid system where ease of configuration is desired/wanted.

[zxq9]

QUOTE (fqberful @ Jul 4 2012, 11:07 PM)

The thing that makes me very sad is this:  As system people we complain about users that can't handle changes, not even the slightest ones.  As system people we are supposed to be unfazed by them [ the system changes] ...  But every one of these threads I read I see posts from system people that sound as if any change is going to be the death of them.  All I can say is "man up d00ds and dudettes" ...  Things evolve.  Our time is best spent insuring that evolution doesn't destroy but rather improves.  and it can take a few iterations to get it right.  Rome wasn't built in a day and neither was RHEL.

You are massively, unforgivably oversimplifying.

First off, "systems people" are not here to roll with changes, they are here to enable their users to continue performing productive tasks using computing systems as an amplifier of human effort, regardless what the system is and absolutely in spite of changes. Change for the sake of change is like art for the sake of art -- and that's the same as saying for the sake of unsufferables out of touch with concrete reality who want to waste the resources of society in subsidy of their mental masturbations. Is that the level of narcissistic depravity to which open source development should aspire?

There is an important point not being made about action at opposite ends of development. On the one hand change must occur or else we'd still rely purely on violence and smell to communicate (instead of only partially as we do today). On the other hand, however, simplicity follows complexity in design -- nearly always. It is important to note that neither change nor design is a fundamental indicator of actual progress toward a goal, though, particularly when that goal remains undefined.

Skipping over every intermediate postulate we could argue about to no end, this ultimately indicates that there is a time and place to present an idea as "consumable" by users. As in, there is a point where a project or design can move from being "research" (defined as having no users -- most software is of this type) to being "deployable". Defining that point is the trick, of course, but pretending that we can rush things because of an upcoming, arbitrarily scheduled "next system release" is, to be polite, shallow.

We try to talk around this with early-entry and Alpha/Bravo/Production phases and whatever -- but that has just convoluted our thought process so we invented terms like "pre-Alpha" and other such nonsense. We've done this until now we can actually convince IT managers to incorporate half-baked ideas into serious systems. The IT managers, who have not spent countless days traversing structures in their minds trying to figure out how to make problems not merely computable but actually manageable by humans via computing tools, are acting on faith that the developers know what they are talking about because they are otherwise unequipped to judge.

Open source developers are used to having things all hairy and tinkertastic and tend to both underestimate the time required to polish a product and overestimate how impressed the user base will be with their latest brilliant idea. The problem exists in closed source development as well, but in open source it is particularly acute because there are no managers or marketers around to say "no". This, then, is where I can honestly say that marketers and management really does serve a critical task: they are the immune system response to the presence of the Good Idea Fairy when she seduces developers, and conversely developers should be enabled to perform a similar role when the situation is reversed (that this is rarely the case is why "suits" make such a bad name for themselves).

The point is that as far as the user base is concerned, whether that's "systems people" or Joe Diddlewad, there is simply software that is "useful/good" or "time-wasting/crap" regardless however the developers feel the current stage of code development should be rated.

Polish rarely ever happens because its boring and requires enormously more effort than anyone ever anticipates. I can attest to this personally and wrestle with these problems constantly managing my/our own projects. (For some reason our hardware development "polish" goals are far easier to achieve than the software ones -- after realizing this I became a firm fan of Brooks.)

Impressing the user base, even administrators and sysops, with new concepts (as opposed to impressing them with polish on an old idea or package) is hard because the brilliance of NewThing v0.09 is only apparent to those willing to not only get the source to but actually comprehend the idea and implementation -- and this is not something many folks other than the original developer will ever do on a large project. Projects suffering from second system effect are almost guaranteed to never get any appreciation because the implementation is guaranteed to suck horribly.

This gets into expectation management, and that begins with managing the expectations of the architect. An example is the Linux kernel vs HURD. Linux had a limited, and therefore achievable, goal at the outset. From that base it was easy to embellish, but only at a certain rate. Sure HURD is looking interesting now, but it suffered from second system effect to the point that it has taken decades to bring to a stable beta. Its brilliant, truly, but who cares unless they want to work on it? And who wants to work on it when we've got Linux and BSD and AIX and whatever else right now? Another good example is git. It came across so well because it set an extremely low bar for featurism which not merely permitted but implicitly insisted on a high bar for performance... and then grew later.

"Release early" shouldn't mean "toss giant, filthy reams of code out as quickly as you can ^ZZ the files", it should mean "limit your immediate feature goals so you can release a stable core early". This implies a million things about design including modularity, reduction to all but the most obvious magic (as in, a conscious attempt to limit 3-star code or similar), using the right tools for the job, designing the right tool for its job, designing for extensibility, proper observance of library VS integrated function definitions, platform respect (whether that means deliberating being platform neutral or picking a winner and pulling out all the stops in an effort to really deliver something special) and above all not submitting to creeping featurism after initial release.

I could go on, and probably will in a blog post some day -- but I roundly reject the concept that systems people bitch about others not changing until its forced on them because its making the wrong argument in every respect and neglects that computers are supposed to be tools, not art.

You're right, Rome wasn't built in a day, but it didn't have to suck completely all over again and rebuilt from scratch every time a new road got resurfaced -- and changing one road never meant changing every road, which is a problem somewhat unique to software.

EDIT: Sorry, Redman, I did it again, didn't I?