On 10/16/18 7:51 AM, Leroy Tennison wrote:

Systemd is implemented in all the major distros, if you want to find ones that don't search for non-systemd.

Hoping to not offend proponents of systemd/firewalld...

Linux kernel is already containing chunks of code related to systemd/firewalld and friends. One can disable stuff during kernel build, but the result it still is not like the result of building kernel before the existence of systemd/firewalld. Also, it is likely that at some point systemd-free Linux distribution(s) may fade away.

That said, if one is strongly willing to stay away from systemd, and not to such extent into Linux as to needing an advise on that, I would recommend to take a look at non-Linux system, specifically BSD descendants (FreeBSD, NetBSD, etc). Their kernel is not as heavy (big,resource demanding) as Linux kernel, and you can do pretty much everything one needs (except maybe computer games, although these will fall mostly into MS Windows scope). I for one have FreeBSD on my laptop (with alternative boot into Debian, the last being systemd though...).

I hope, this helps.

Valeri

Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here . If you prefer not to be contacted by Harris Operating Group please notify us . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

---

From: CentOS centos-bounces@centos.org on behalf of Robert Moskowitz rgm@htt-consult.com Sent: Tuesday, October 16, 2018 5:14 AM To: CentOS mailing list; Turritopsis Dohrnii Teo En Ming Subject: [EXTERNAL] Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

On 10/16/18 1:54 AM, Turritopsis Dohrnii Teo En Ming wrote:

...

Good afternoon from Singapore,

What are the differences between systemd and non-systemd Linux distros?

Is systemd implemented in all the latest Linux distros?

Please advise. Thank you.

My advice is to go and read up on the original design goals of systemd. The information is out there. We had this discussion here years ago when we were staring and the impending transition.

Read the archives on the angst the change engendered and the adjustment to the new methodology.

They say that the Internet never forgets, so you should be able to find the original discussions and make your own judgment call.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 10/16/2018 10:27 AM, Jonathan Billings wrote:

On Tue, Oct 16, 2018 at 09:25:15AM -0500, Valeri Galtsev wrote:

...

Also, it is likely that at some point systemd-free Linux distribution(s) may fade away.

There was already a move away from SysV init before systemd was introduced, heck RHEL6/CentOS6 used Upstart instead of SysV. There are always going to be projects with a diverse set of tools, it just depends on how many people care about it. Turns out, not that many people care about maintaining a SysV init (or other init) distro.

I'm not sure that that necessarily follows. Among RH-ecosystem distributions, and specifically RHEL derivatives, there's a barrier to the usefulness of smaller projects given that a large chunk of the users need binary-compatible commercial equivalents, or at least vaguely commercially supported ecosystems. We're long past the days where WBEL and other hobbyist projects can probably gain traction. Those RHEL alternatives that do exist either have a long history (CentOS, even before the RH deal), or are supported by large entities: the government (SL, before it became more or less congruent with CentOS), a multi billion dollar company (OEL), or a trillion dollar company (AWS). SuSE Enterprise might be the best counter example here.

Also, while EL6 did move from original init to upstart, that's somewhat beside the point. Almost none of the advanced features from upstart were used, and - crucially - the startup sequence was still handled with grokkable, imperative scripts. The jump from EL6->EL7 was night and day compared to EL5->EL6.

-jc

On 17/10/18 1:25 am, Valeri Galtsev wrote:

That said, if one is strongly willing to stay away from systemd, and not to such extent into Linux as to needing an advise on that, I would recommend to take a look at non-Linux system, specifically BSD descendants (FreeBSD, NetBSD, etc). Their kernel is not as heavy (big,resource demanding) as Linux kernel, and you can do pretty much everything one needs (except maybe computer games, although these will fall mostly into MS Windows scope). I for one have FreeBSD on my laptop (with alternative boot into Debian, the last being systemd though...).

It's starting to look as though the BSD camp may embrace systemd sooner rather than later:

https://youtu.be/6AeWu1fZ7bY?t=1537 - I like this bit the most in that video!

But do watch the entire presentation - good stuff.

This is indeed good news (that BSD isn't necessarily going to adopt systemd).

Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here . If you prefer not to be contacted by Harris Operating Group please notify us . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

________________________________________ From: CentOS centos-bounces@centos.org on behalf of Mark Rousell mark.rousell@signal100.com Sent: Wednesday, October 17, 2018 11:03 AM To: centos@centos.org Subject: [EXTERNAL] Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

On 17/10/2018 10:11, Anthony K wrote:

It's starting to look as though the BSD camp may embrace systemd sooner rather than later:

https://youtu.be/6AeWu1fZ7bY?t=1537 - I like this bit the most in that video!

But do watch the entire presentation - good stuff.

I've listened to the video and no, it doesn't say any such thing. The video does not say that BSD is going to use systemd.

What the speaker in the video certainly does point out is that service and system management is a good thing overall and that there are better ways of doing this than SysVinit. However, most people have not disputed this.

A lot of people, including very many of those who greatly dislike systemd, accept that SysVinit could and should be replaced or improved upon. It's just that they do not think, for a variety of entirely legitimate reasons, that systemd is the right software to do this. Even on Devuan, for example, many people prefer to use init software other than SysVinit.

The speaker says, amongst others thing, "what I find amusing occasionally is that a lot of people who bitch about systemd, don't bitch about launchd but I find that funny because systemd is launchd in concept" but he should not be surprised. The people who complain about systemd are doing so because (a) launchd is not being forced on them as systemd is in practice (in their view), and/or (b) because they disagree with systemd's specific architectural choices and/or their view of its quality.

I should add that the speaker also massively over-simplifies opposition to systemd on the basis that he incorrectly perceives it to be opposition to change. He seems to ignore the fact that, as above, there are substantive objections to the specific architecture and quality of systemd, not merely objections to change with no deeper reason. He further seems to ignore the fact that many people objecting to systemd would nevertheless favour more modern system/service management.

The speaker goes on to give his reasons as to why bringing service and system management to BSD is a good thing. As I point out above, many people could well agree with this, even many people who dislike the specific implementation of systemd on Linux.

To be clear, objections to systemd on Linux largely seem to me to be about the specific implementation and perceived quality (and, dare I say it, personalities), rather than either fear or change or objection to modern system/service management.

The speaker explicitly points out: "What can we [BSD] get from systemd? I'm not saying that we should adopt it [...] I don't think that trying to directly adopt system is going to work for us". He then goes on to point out why implementing a BSD kernel-based systems/service management component that is inspired by some of systemd's advantages (or, to put it another way, the advantages that any modern system/service management facility could and should offer) would be a good thing. As I say, many people, including many systemd-doubters or haters, would not object to this.

He is not, however, saying that systemd will be used on BSD. He's just saying that the principles of system/service management are good ones and that software other than systemd could implement them. And that's exactly what a lot of systemd's critics say, too.

-- Mark Rousell

_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 17/10/2018 20:03, Warren Young wrote:

On Oct 17, 2018, at 10:03 AM, Mark Rousell mark.rousell@signal100.com wrote:

...

launchd is not being forced on them as systemd is in practice

Try doing without launchd on macOS.

If you think that’s irrelevant, count the number of MacBooks at the next FreeBSD conference you attend.

That's Mac. It's not Linux. And that's the point. Mac does not have Linux's very particular culture and history.

Apple and oranges, and all that. Sure, launchd is an init system but it's not on Linux. If launchd was on Linux and it had systemd's cultural issues and, in many people's views, technical issues then the opposition to it would be identical to the opposition to systemd.

When people go to Mac they accept what it is (mostly). That's a fundamentally different culture to Linux (or BSD for that matter).

For an init system to gain sufficient momentum, it must be the default, with no easy way to avoid it.

That's an argument for authoritarianism, which seems to me to be anathema to the overriding culture of Linux. Can you see why many people might dislike the personalities involved with systemd, yet, when such an argument is used in favour of systemd? :-)

...

I should add that the speaker also massively over-simplifies opposition to systemd on the basis that he incorrectly perceives it to be opposition to change. He seems to ignore the fact that, as above, there are substantive objections to the specific architecture and quality of systemd, not merely objections to change with no deeper reason.

While there certainly are objective problems with systemd’s design and implementation, it is basic human psychology that many people will not move to a newer system despite piles of advantages.

Quite true but the fact that some people do dislike change (a) does not make the substantive and objective problems, in many people's views, with systemd any less real or important and (b) does not mean that the speaker did not massively over-simplify the opposition to systemd , i.e. he effectively claimed that it was all to do with fear of change when, as you agree, there in fact are substantive, real and objective issues which are widely recognised.

The major BSDs are fundamentally conservative at the project management level, so I believe this tendency is stronger in the BSD user population than elsewhere in the IT world. It’s a form of self-selection bias: the BSDs are run conservatively, so they attract a user base that is also technologically conservative, from which come the next generation of core developers, who therefore continue to run the project conservatively. Consequently, the major BSDs are even more conservative than the Enterprise Linuxes.

An interesting observation. It seems to me that there are aspects of the Linux culture that are at least as conservative as the BSDs in this context (are perhaps shared with BSD). One of these aspects is the "do one job and do it well" expectation of componentisation. In many people's views, systemd wilfully and unnecessarily tramples all over this cultural/technical requirement. If this is the case in many people's views, then it makes a lot of sense that hey are unhappy with it.

...

many people objecting to systemd would nevertheless favour more modern system/service management.

I’d love to see that quantified.

None of these comments (neither mine nor those of the speaker of the presentation) are easy to quantify. I can only say that I base my comments mainly on the contents of technical mail lists and blogs and similar and I have very frequently observed that (a) a common question is how users can change init system to something other than either systemd or SysVinit (depending on whether they are starting with a Linux that is normally with or without systemd), and (b) there does seem to be a very common thread that the time had come that something needed to be done to update SysVinit but that systemd definitely should not be it (and that the solution, whatever it was, should not have been introduced in the way that systemd was).

Alternatives to the BSD rc init system are readily available, yet I think if you were to survey actual use, you’d find that over 99% of BSD boxes use the stock init system.

That's a different metric. People may well stick with the stock init system but that doesn't mean that they like it or really want it.

Change has to be forced from the center out on this kind of thing.

Again, an appeal to authoritarianism. Excuse me if I don't wish to join you on that. Authoritarianism, in all its forms, is dangerous and, in my view, a form of vandalism.

Also one might ask: What centre? This is the world of Linux. Many people don't recognise any centre, and quite sensibly so. Indeed, they use Linux explicitly to avoid the centrism of the likes of Linux or Apple.

As I observed above, this authoritarian centrism in in part why systemd is so despised. It was effectively forced on a great many users in in a centrist, choice-limiting manner. A great many people regard this as a bug, not a feature. I think they might be right.

The question in my mind is how long it’s going to take for the major BSDs to make such a change at the center, so that the majority of new installs will use a modern init system. The systemd project started in 2005, and wasn’t widely deployed as the default until about 4 years ago. If past is prologue, I think this won’t happen on the BSDs for another decade or so, if ever.

Example: FreeBSD is just now moving to pkg-in-base in earnest, giving it features I first saw in the default install of Debian in about 1995.

That's up to them and their users, isn't it. Just because it's a good idea doesn't mean it has to be done in a hurry. This was and is one of the problems with systemd on Linux.

On 10/17/18 7:55 PM, Warren Young wrote:

On Oct 17, 2018, at 3:28 PM, Mark Rousell mark.rousell@signal100.com wrote:

...

On 17/10/2018 20:03, Warren Young wrote:

...

On Oct 17, 2018, at 10:03 AM, Mark Rousell mark.rousell@signal100.com wrote:

...

launchd is not being forced on them as systemd is in practice

Try doing without launchd on macOS.

If launchd was on Linux and it had systemd's cultural issues and, in many people's views, technical issues then the opposition to it would be identical to the opposition to systemd.

Try this gedankenexperiment instead: what if RHEL 7 shipped based on launchd instead of systemd, with no differences relative to the version shipped in the contemporaneous version of Mac OS X?

I’m uncertain as to whether the opposition would have been as great, but I’m dead certain the opposition would have been vociferous and strident, because Linux, though less conservative than the BSDs, is much more conservative than macOS.

The systemd vs launchd vs sysvinit vs whatever-else arguments are more about human factors than about technology, even though they’re usually couched as technical battles.

...

When people go to Mac they accept what it is (mostly).

I doubt most Mac people even know launchd exists, much less have an informed technical opinion about it. And of the small minority that do have such an opinion, it almost certainly doesn’t drive buying decisions. Maybe that’s what you mean by accepting macOS as it is.

The thing I don’t get is, why is it different in the Linux world? Why did we in the Linux community spend so much time arguing about systemd over the past several years? Why is it still an active topic five years after the key events? And why is the BSD community continuing to stir the pot?

Here’s what I want to see: I want one of the BSDs to clean Linux’s clock with a thoroughly awesome modern init system that makes us Linux fans so jealous we start noisily advocating to replace systemd with it, much as ZFS is starting to replace the horrid lash-up that is ext4/xfs+md+LVM+DM.

What I *don’t* want is more of this retrenchment to SysVInit. I liked it well enough within its limitations, but we can do better in 2018.

(It’s a related tragedy that a slightly modified ksh88 remains the most powerful general purpose scripting language mandated by POSIX three decades after it was released by AT&T. We’ve got better alternatives here, too.)

...

...

For an init system to gain sufficient momentum, it must be the default, with no easy way to avoid it.

That's an argument for authoritarianism

I call it leadership. Working code argues best.

Benno Rice is right: Lennart Poettering gets stuff done.

In the BSD world, they call the opposite tendency bikeshedding. You can find a thousand people willing to argue about why something shouldn’t be done, or why it shouldn’t be done *that* way for every person capable, willing, and available to write a given piece of software.

For all the complaints about systemd over the past several years, I note that there is still no fork of CentOS 6 or CentOS 5, keeping the prior init system(s) but updating their package set to recent versions. Many would rather gripe about change than put in the work it takes to maintain the status quo.

Then you get the crowd that tries to argue that we should just stay with what works, apparently under the misapprehension that staying in place is a zero-effort choice, when in reality it is at best an accrual of technical debt; the bill will come due eventually, with interest.

I suspect these two groups overlap quite a lot, inconsistent though the combined position is.

...

the fact that some people do dislike change (a) does not make the substantive and objective problems, in many people's views, with systemd any less real or important

Of course not, but I also don’t see a lot of effort going into replacing systemd with something better. Most of the effort opposing systemd seems to be going into anti-systemd advocacy campaigns, plus a tiny slice off to the side going into retrenchment to SysVInit. That’s conservatism, plain and simple.

With all due respect, many people just stopped offering any argument about systemd, and simply fled elsewhere which in _their_ opinion (and I am one of them) lies better in what they with their education and life experience is more reasonably resembling system suitable for servers.

Servers are key word for me. You can see me using macintosh laptop in variety of places, that doens't mean MacOS will be my choice for server, so don't count laptopls into any statistics. The same is true about a bunch of other sysadmins I know, who mostly use Apple laptops, whereas run Linux, or UNIX-like, or [truly] UNIX servers.

To add to the "refugee" camp recognition, there are Linux refugees who left even earlier for different reason, so they don't even care so say aloud what they think of systemd (or don't care about it at all).

Valeri

...

he effectively claimed that it was all to do with fear of change when, as you agree, there in fact are substantive, real and objective issues which are widely recognised.

I suspect that for many people, those are rationalizations rather than reasons.

I saw much the same sort of logic in the Unix vs Linux wars, roughly spanning the decade surrounding 1996.

The Big Iron Unix and SCO Unix fans had all kinds of myopically rational reasons why Linux wasn’t going to replace their OS of choice: journaled filesystems, better SMP, STREAMS, hot-swap hardware, real ksh93 instead of that cheesy nonstandard imitation Bash…

The analogy I used at the time is that the Unix fans saw Linux surfing behind their big yacht and laughed at the tiny, flimsy, cheap little surfboard, not realizing that it would take an awfully big wave to allow someone to be surfing out in the middle of the ocean. We’ve been skimming the splinters of that yacht off the surface of the sea for decades now.

Like the Linux wave, the systemd wave took years to build beneath the surface. If you perceive that it broke fast, it’s only because you weren’t looking in the right places, where you could see and even help direct that long build-up.

You can spend your time rationalizing against systemd while it sheds enough of its weaknesses and gains enough features to sweep the planet. You’re years late if you want to stop that from happening, but I believe it can be done, just as systemd replaced rc files, SysVInit, and Upstart.

It’ll take a lot of hard work, but it can be done.

...

One of these aspects is the "do one job and do it well" expectation of componentisation.

That’s never been an especially hard and fast rule. Witness Emacs, Perl, GNOME, Firefox, ZFS…

My DVCS of choice is Fossil, which is about as far from the “small pieces loosely joined” philosophy as you can get, from which comes much of its power and simplicity. Fossil’s primary opposition is Git, which is famously difficult to understand and use properly, even though it adheres perfectly to that philosophy.

(Incidentally, I’ve spent a fair bit of time in recent months making Fossil work better, so my calls to action in this thread are not just me proposing work for other people to do.)

I *want* my init system to build a dependency graph and maintain that graph at run time. I *want* it to start services in parallel, consistent with that dependency graph. I *want* it to restart services that die unexpectedly, with exponential back-offs. I *want* it to have sensible answers to a “status” command without having to write the shell code to dig that that status out of service-specific files. I *want* my service definition scripts to be 15 lines, rather than 150. I *want* to be able to start services as a normal user, with all of the power of a real system service, limited only by OS permissions, without needing sudo.

That puts an awful lot of code into a single place. It is not small pieces loosely joined. What it *is* is powerful.

...

In many people's views, systemd wilfully and unnecessarily tramples all over this cultural/technical requirement. If this is the case in many people's views, then it makes a lot of sense that hey are unhappy with it.

I’m not a particularly big fan of systemd. I agree with much of what its opponents dislike it for.

The only reason I enter these arguments is that I feel the need to fight against the complainers, because I’d rather see opposition deflected toward a replacement.

Give me a better option, and I’ll happily switch to it.

Tricky bit: “better option” is evaluated on a systems basis, not on a per-feature basis. If the combined system doesn’t provide most of CentOS’ key virtues, as I see them, it isn’t a better option.

If you ask why I don’t just write something better myself, it’s because I don’t care enough about the Linux init system to do that, so I’d rather spend time advocating for and taking advantage of systemd’s features than complaining about its weaknesses.

(Automatic service restarts saved me a lot of work just a few weeks ago!)

I’m also unwilling to stick with increasingly poorly supported technology. If the cheese moves, I’m following the cheese.

...

...

Alternatives to the BSD rc init system are readily available, yet I think if you were to survey actual use, you’d find that over 99% of BSD boxes use the stock init system.

That's a different metric. People may well stick with the stock init system but that doesn't mean that they like it or really want it.

That’s a large part of my point: if you are unable or unwilling to take the time to replace a thing, why bother spending time griping about its weaknesses?

Talk about a first world problem: Oh, waaah, my automated software management service isn’t ideally designed. Woe is meeee!

It’s much like my macOS argument above: CentOS sucks in many ways, but I have no good answer to the “What’s better?” question for the applications where I use it. I’m not going to spend a bunch of time listing all the ways CentOS sucks: either I’ll fix the problems myself, or I’ll work around them, or I’ll ignore them.

Notice that putting up with systemd is only one of your several choices. The FOSS ecosystem advances every time someone scratches an itch. My objection is that we’ve got all these people claiming to have itches, but very, very few are scratching.

...

...

Change has to be forced from the center out on this kind of thing.

Again, an appeal to authoritarianism. Excuse me if I don't wish to join you on that. Authoritarianism, in all its forms, is dangerous and, in my view, a form of vandalism.

In what useful sense do you believe you own the parts of CentOS affected by the move to systemd? It can’t be vandalism otherwise.

Intellectual property is no answer in the FOSS world, since that implies that you’ve relinquished the relevant rights already, so you have little to no say in how the wall gets reshaped, if in fact you built it in the first place.

I suspect it’s more that you found this free wall just sitting around online, and no one was guarding it, and in fact there were people offering you free copies of the wall, as many as you want, so you started making buildings out of these walls. Then someone changed the wall generator to produce differently-shaped walls, and now you’re upset that the walls aren’t the same any more.

I get it: you’re annoyed. What I don’t get is why you believe your annoyance should, of itself, effect a change in the world.

FOSS is a do-ocracy: he who does the work makes the rules. If you want the wall to be shaped differently, and no one is making new walls with that shape any more, go make your own wall, or maintain an old wall that was already correctly-shaped, by your lights.

In this case, I think the lowest friction path is to fork CentOS 5 or 6, then backport as much of the feature set as is possible without dragging in systemd. No one’s done this, despite having over 7 years to react, dating from systemd’s deployment as the default init system in Fedora. Why not?

The closest thing I’m aware of in the Linux world is Devuan, which was low in popularity a year ago and has been dropping ever since:

 https://distrowatch.com/dwres.php?resource=popularity

According to the same stats, CentOS is pretty stable, which I find appropriate. :)

...

Also one might ask: What centre?

In this case, the one currently headquartered in Raleigh, NC, USA.

If you want a different centre, pick one, or be your own. That’s why we have several major Linux flavors and hundreds of Linux distros.

Centralized control is clearly not the key problem here, since so much of this anti-systemd sentiment is coming from the much more centralized BSD camps.

Centralized control didn’t do the Big Iron Unix vendors much good. A better thing came along and wiped them out. The thing is, a whole lot of programmers went to a whole lot of effort to make that happen. Are you going to do more than post to mailing lists in an effort to wipe out systemd?

...

As I observed above, this authoritarian centrism in in part why systemd is so despised. It was effectively forced on a great many users in in a centrist, choice-limiting manner.

You also didn’t get a choice over SysVInit vs BSD style init, short of switching from Red Hat to Slackware. So what?

Someone has to make a decision. We call those who do this often and well leaders.

Leadership is not central control or authoritarianism: we get to choose which leaders we wish to follow.

Don’t like where Poettering is taking his slices of the Linux world? Fine; follow someone else who is taking equivalent slices in a direction you like better. Or, be that someone!

...

That's up to them and their users, isn't it. Just because it's a good idea doesn't mean it has to be done in a hurry. This was and is one of the problems with systemd on Linux.

The first version of systemd was released in 2010, and it wasn’t deployed “for real” until RHEL 7 came out in 2014, as far as I’m concerned. I don’t call that “in a hurry.”

This in a world where Linux’s major competition all had systemd-like service management by around 2005:

• Solaris 10 came out in early 2005 with the Service Management Facility (SMF), which is very similar to systemd’s initial feature set.

• Several months later, Apple shipped Mac OS X “Tiger” with launchd replacing init(8).

• Microsoft, ever late to the party, shipped the last major piece missing relative to the above about 18 months after Tiger came out, adding delayed-start services to Windows Vista.

(This is probably where the “2005” in my prior post came from, by the way. I thought systemd got started earlier.)

So yeah, systemd finally let Linux catch up to Vista in the area of background service handling, an area where Linux is supposed to be superior, but it’s all happening too fast? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Oct 18, 2018, at 9:41 AM, mark m.roth@5-cent.us wrote:

On 10/17/18 7:55 PM, Warren Young wrote:

...

...

Benno Rice is right: Lennart Poettering gets stuff done.

Because he's funded.

There are plenty of people with jobs that don’t get stuff done.

I strongly suspect that a lot of that funding comes from M$'s interest in Upstream.

Soooo…systemd is a Microsoft conspiracy against Linux?

my home workstation is CentOS 6, and I am NOT looking forward to EOL.

That’s what I meant with my comment about the technical debt bill coming due. You can’t ignore the changes in the external world forever.

The OpenSSL issue brought up in a prior post is another example of the same basic problem.

people are tired of screaming and yelling about systemd, because we've had years now of the response being "tough, it's the Wave of the Future"

We covered that back when RHEL 7 was still in beta: the time is far too late to change the init system of RHEL 7. The fact that you’re tired of being ignored doesn’t enter into it: you could still be yelling about it, and it still wouldn’t change. Red Has simply isn’t going to swap out its Enterprise Linux init system within a major release cycle.

I believe it’s certain that RHEL 8 (and thus CentOS 8) will also be systemd-based, since we’d be hearing about the change by now via Fedora if it were otherwise.

Those of you who want a systemd-free CentOS-like OS to be available before CentOS 6 hits EOL are going to have to see to that yourselves. You cannot expect it to just drop from the sky.

Poettering is like upper management: they know, I mean, Everything, so why should they need to talk to end users (or working sysadmins)?

The suggestion that Red Hat is not listening to working system administrators beggars belief. That’s pretty much the basis of their company’s major income stream.

What Red Hat is not doing is filling every demand from all working system administrators. They’re choosing which demands to address, as any software project management must.

Red Hat has certainly heard the screams of the reactionaries. Since that hasn’t changed anything, I believe you have your demand’s answer. So, what are you going to do about it?

On Oct 18, 2018, at 6:52 PM, Japheth Cleaver cleaver@terabithia.org wrote:

Conoboy, on the other hand, takes great pains during the speech to describe a much more fluid and complex interaction between CentOS and its upstream, and puts forth CentOS as a mechanism (perhaps the best mechanism) for the winder EL community to contribute (something?) back into RHEL's future.

I don’t see a change as significant as a new (or old!) init system making its way up from CentOS or Fedora to RHEL.

But hey, if you wanted to spend your time trying, that’s a *far* better use of your time than griping about systemd on mailing lists.

I think forking CentOS 5 or 6 is less effort, but hey, your time, your project.

If anyone out there is thinking this is too much work, some of the major Linux distributions are, or were at one point, largely one-person efforts. It is certainly not a lot of work, but you don’t need a multibillion dollar company to fork CentOS.

Both projects could fail, and it would still be a much better signal to Red Hat what the people want. Again: working code argues best.

On Thu, Oct 18, 2018 at 05:52:12PM -0700, Japheth Cleaver wrote:

The wider EL community is trapped between a rock and a hard place somewhat. If you try to direct Fedora into the needs of EL users, you stand a good chance of getting told to pound stand, and that EL is getting in the way of bleeding-edge progress. Traditionally,

For what it's worth (I hope something!) I think this is an outdated fear or assumption. Before Fedora.next, the "default user" for Fedora was assumed to be an indiviual desktop user, and the overall Fedora OS offering meant to be one-size-fits-all but modeled to that user. That wasn't working, partly for the reason you identify here. Nonetheless, something like 20% of Fedora usage is on servers, and a lot of people work with Fedora in parallel with a Enterprise Linux deployment. We needed to find a place for those users to have a voice.

So, Fedora Server was explicitly chartered as not just for its own sake (although we intend to make that true as well) but also the intentional upstream for downstream enterprise Linux consumers. That doesn't mean that every change there goes into RHEL, or is RH blessed or even Red Hat aligned — but the needs of EL users are *definitely* taken into account.

wider EL-using community. Does it want direct feedback in the form of tickets? Should people form SIGs? Obviously RHEL7 is not changing init systems, but where should one talk about the future?

If this is your interest, I'd really encourage you to get more involved in Fedora Server. We could use your input.

On 10/20/18 7:42 AM, Valeri Galtsev wrote:

I would like to hear the reasons of those who chose to use Fedora on their server. Specifically what advantages one has found compared to other alternatives. And also what kind of server that is. Single user/home/family one? Serving some department or similar (say 100 people, who may need services 24/7/365)? I know, this is just my curiosity, as I did make my own choice, but curiosity grossly fueled by the fact that my choice is grossly different.

Always happy to hear different [from mine] opinions which may be based on different objectives.

We are running about 50 development servers for the Storage Systems Research Center in the University of California, Santa Cruz. All Fedora. We will be updating all machines to F29 as soon as it is released. The reason is that we want the students to have access to the latest development toolchain, libraries, and other tools from the Linux world in a reasonably stable fashion. Fedora is the best fit. Not bleeding edge, but not outdated either. Our infrastructure servers, such as file sharing, cluster management, etc., are all Fedora machines too, for homogeneity and simplicity.

We don't need 24/7/365 uptime, but in my memory, there has been no downtime caused by anything in Fedora in the past decade. And we always do in-place upgrading when a new Fedora comes out. Upgrading from one Fedora to the next never failed us in the past decade either in my memory.

Occasionally, one or more machines will be loaded with CentOS 7 for a few months for running Lustre or some other CentOS/RHEL certified software.

This is unrelated to the campus-wise Linux clusters that are managed by the university IT department, which maintains hundreds of CentOS machines for the whole campus.

I also know colleagues who maintain Fedora as servers from my other jobs. These were for all kinds of services: email, file storage, development, etc. Why Fedora over CentOS? I guess Fedora is more fun to play with and is stable enough for these applications. As I said before, in-place upgrading for Fedora is pretty reliable. And doing it once a year (or every 6 months) to get the latest software is a good bargain for a techie.

On 10/20/18 8:37 AM, Valeri Galtsev wrote:

Oh, great, I now can see the world with your eyes! And last part about servers life cycle wise doesn't sound much different from what I do using FreeBSD and jails. The only difference is maybe in how frequently I have to reboot Linux (any flavor) due to kernel or glibc security update compared to reboot of FreeBSD.

Yup. That's indeed a problem that the Fedora kernel is moving a bit too fast for a server. Our machines sit behind a firewall, and as of I know, our students are not crazy about privilege escalation/Meltdown attacking their own servers. So we usually only reboot when there's a power outage that is longer than what our UPS could handle, which is unfortunately quite common on this campus.

On 10/20/2018 6:23 AM, Matthew Miller wrote:

On Thu, Oct 18, 2018 at 05:52:12PM -0700, Japheth Cleaver wrote:

...

The wider EL community is trapped between a rock and a hard place somewhat. If you try to direct Fedora into the needs of EL users, you stand a good chance of getting told to pound stand, and that EL is getting in the way of bleeding-edge progress. Traditionally,

For what it's worth (I hope something!) I think this is an outdated fear or assumption. Before Fedora.next, the "default user" for Fedora was assumed to be an indiviual desktop user, and the overall Fedora OS offering meant to be one-size-fits-all but modeled to that user. That wasn't working, partly for the reason you identify here. Nonetheless, something like 20% of Fedora usage is on servers, and a lot of people work with Fedora in parallel with a Enterprise Linux deployment. We needed to find a place for those users to have a voice.

So, Fedora Server was explicitly chartered as not just for its own sake (although we intend to make that true as well) but also the intentional upstream for downstream enterprise Linux consumers. That doesn't mean that every change there goes into RHEL, or is RH blessed or even Red Hat aligned — but the needs of EL users are *definitely* taken into account.

...

wider EL-using community. Does it want direct feedback in the form of tickets? Should people form SIGs? Obviously RHEL7 is not changing init systems, but where should one talk about the future?

If this is your interest, I'd really encourage you to get more involved in Fedora Server. We could use your input.

This does indeed remind me of the "ring" concept, with the (perhaps overloaded) "Core" being something that all subsequent variations on top of Fedora (or Fedora-as-upstream) can use with potentially more and more alterations in policy, build, selection, and UX the further downstream you get.

The problem is that it seems like very low level decisions are and have been made that align most closely with the needs of the "individual desktop user" rather than in a more neutral manner that allows for meaningful distinctions *outside* of minor configs. Fedora Server can override Fedora configs, but it still has to deal with those Fedora-wide changes. Knowing at least that, for now, Fedora Server is trying to serve in this role is definitely encouragement to get more involved there, but I do fear a larger paradigm shift is involved.

Some of the Fedora-pushing is most visible in the use of Packaging Guidelines to implement that Fedora-specific policy; the outright *banning* of initscripts in RPMs (rather than allowing them to continue as subpackages or conditionals a la tcp_wrappers) is the ur-example, but there are more. Fedora inherited a lot of the moral leadership of RHL, but if there's question whether it can safely be considered "upstream" for EL (to say nothing of providing guidance other RPM-based distros), then I wonder if a further reorganization is necessary beyond Fedora into Fedora+Workstation/Server/Atomic.

Maybe if we had something above both Fedora *and* EL (whether the EL is RHEL or a Community *Input* ENTprise OS) which worked to enforce maximal downstream flexibility for its packages (rawhide specs, if you were), it might reduce some of this tension and provide an easier entry point for people wanting to get more involved in EL, but not interfere with overall Fedora questions. (That's really two distinct proposals there, but I hope my meaning comes through.)

-jc

On 10/18/2018 7:33 PM, Young, Gregory wrote:

*** This response is my personal opinion and may not reflect that of my employer. ***

*snip*

If CentOS 8 were to switch back from systemd, I think you would be able to see the explosions from Alpha Centauri as all the developers out there lost their minds after spending all this time converting their apps to work with systemd.

I think think some of the opposition to "switching back" misses the point. IMO there's nothing particularly wrong with systemd as a service manager, so folks wanting to use it as /just/ that (which accounts for the bulk of what SysV-style init scripts from vendors do) could still use it if they wanted. Initscripts work fine for traditional C unix daemons, but lots of other ecosystems (looking at java) are better served with other management systems. Disintangling from systemd's overall paradigm doesn't necessitate forcing everyone to write initscripts again for their own daemons.

-jc

Valeri Galtsev wrote:

...

On 10/17/18 7:55 PM, Warren Young wrote:

<snip> >> Benno Rice is right: Lennart Poettering gets stuff done.

Because he's funded. And I strongly suspect that a lot of that funding comes from M$'s interest in Upstream.

<snip> > > With all due respect, many people just stopped offering any argument > about systemd, and simply fled elsewhere which in _their_ opinion > (and I am one of them) lies better in what they with their education > and life experience is more reasonably resembling system suitable > for servers. > > Servers are key word for me. You can see me using macintosh laptop in > variety of places, that doens't mean MacOS will be my choice for server, > so > don't count laptopls into any statistics. The same is true about a bunch > of other sysadmins I know, who mostly use Apple laptops, whereas run > Linux, or UNIX-like, or [truly] UNIX servers.

Actually, I've got CentOS on my 9 yr old Netbook, that I use while traveling. Otherwise, my home workstation is CentOS 6, and I am NOT looking forward to EOL.

But Valeri's correct: people are tired of screaming and yelling about systemd, because we've had years now of the response being "tough, it's the Wave of the Future", and Poettering is like upper management: they know, I mean, Everything, so why should they need to talk to end users (or working sysadmins)?

Lack of screaming and yelling filling this venue is more because "what's the point?", and we have to get work done.

Hi,

A lot was already said but let me underline a few things from my personal point of view:

- the upgrade path from EL6 to EL7 is completely broken.

That's certainly a good thing for upstream, because they can sell even more support and training. I don't blame them for trying to make money, I just say from the technical point of view it's not the best solution.

For home users it doesn't hurt too much but for the enterprise market it's bad. Migrating complex systems is a huge amount of work and takes a lot of time and manpower. In the end it means higher costs.

- the migration to systemd is not really finished carefully in EL7.

Just look into upstream's Bugzilla and see how many issues still exist and will probably not be fixed.

I show you a simple example: we happen not mount some NFS filesystems on servers like this in /etc/fstab:

ftp:/var/ftp/pub /mnt/nfs nfs bg,soft 0 0

Now, with every Linux since the last millennium one could simply bring down the system into maintenance mode with 'telinit 1', and all worked fine. Now try the same with EL7, do a 'systemctl rescue' or 'systemctl emergency' and see what happens. With lightning speed it does the wrong thing, brings down networked services, brings down the network, and doesn't unmount the NFS filesystems. Then try a 'df' or 'lsof' in rescue mode, it all hangs.

Of course I found a solution, mount it with the option 'x-systemd.requires=network-online.target' and it behaves correctly. But really, it's broken, because it's always clear that NFS mounts always only work WITH network!

That's just a single small example how things don't work as expected.

- migrating from EL6 --> FreeBSD seems easier than migrating from EL6 --> EL7, IMHO.

That's really an important point, because those who started using Linux with Linux/systemd will be bound to Linux/systemd with their knowledge, switching to a *BSD or other Unix will be difficult. For me, I don't like to be limited in such ways.

In other words, systemd is a new operating system which still lacks a kernel :-)

One thing I know for sure: if the *BSD folks were ever going to invent something like systemd, they will do it in a way which hurts less.

Regards, Simon

On 10/19/2018 5:09 AM, Jonathan Billings wrote:

On Fri, Oct 19, 2018 at 01:07:46PM +0200, Simon Matter wrote:

...

That's really an important point, because those who started using Linux with Linux/systemd will be bound to Linux/systemd with their knowledge, switching to a *BSD or other Unix will be difficult. For me, I don't like to be limited in such ways.

Having worked with the init systems in a bunch of different distros, I really *loved* having to write a different SysV init script for debian and RHEL, using different functions and different styles. Also, don't forget to actually package the Red Hat init scripts as /etc/rc.d/init.d/, because /etc/init.d is a symlink, while on debian it is the actual location, and if you weren't careful, your package would create an /etc/init.d directory and suddenly it's not even found by the init system.

The first time I had to look at SysV init scripts on a Debian/Ubuntu box my eyes bled; if systemd had begun from that ecosystem I definitely would have understood its formation a bit more. But on Red Hat-derived distros, an initscript for a basic daemon is pretty simple and mostly boilerplate: copy/paste the sample file, maybe decide what you want to make tweakable in /etc/sysconfig/, then (if desired) build an RPM according to best practices.

Virtually everything you might need that isn't provided by the 'functions' file is going to be your own custom logic for your own daemon, and it turns out that that usually doesn't change in a systemd landscape, resulting in a lot of workarounds, wrappers, and shell bits in unit files which would probably be more predictably understood in a single shell script to begin with.

Building a single init script that works across ALL Linux distributions (and other unices) is indeed painful and ugly, so if a vendor wanted to make a declarative config file and wash their hands of, that's understandable. But the same goes for an xinetd.conf snippet, or any other service manager of the same ilk. And making a boilerplate /Red Hat-specific /init script is trivial.

Heck, there was even an argument about which shell they're run with. And it was always fun when shell bugs cropped up in init scripts. A vendor writes an init script using bash features that aren't in another distro, but it still uses the #!/bin/sh shebang so you get really weird and difficult-to-diagnose startup errors.

That's a larger *nix issue. As a proponent of dash on EL systems, I definitely think ensuring bashisms are called out and that /bin/sh means /bin/sh is probably a Good Thing.

And heaven forbid you actually want to *SEE* any shell errors. Nothing is ever captured in any logs, you have to be physically looking at a console (be it a glass terminal or serial line) to capture the error.

The /sbin/service command is just a shell script. I'd suggest a patch to send stderr/out to logger as well if I thought it would be accepted. (And *manually executing* an init script with direct call was something we were already supposed to be deprecating; the service command was the standard environmental interface.)

Frankly, I've had a lot more problems debugging mysterious systemd-based startup failures than I ever had in a properly-written Red Hat init script. (Again, vendor-agnostic init scripts can be hot messes, but that's them...)

-jc

On Fri, 19 Oct 2018, mark wrote:

Yeah. I have trouble finding the actual startup configs - /etc/systemd/system? /var/lib? whereeverthehell they are, do a locate.... as opposed to /etc/init.d to find the damn name (nfs? nfsd? idmapd? nfs-idmapd? rpc-idmapd?)

systemctl status <<service>>

E.g.,

[~]$ systemctl status ntpd ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)

It shows the definition file.

On Oct 19, 2018, at 5:07 AM, Simon Matter simon.matter@invoca.ch wrote:

• the upgrade path from EL6 to EL7 is completely broken.

Under what conditions would you actually use it?

As we can see from the repeated attempts to get a reliable in-place upgrade process working, the community doesn’t seem to have much interest in the idea:

https://lists.centos.org/pipermail/centos/2018-October/170379.html

I believe this is because in-place upgrade is antithetical to the idea of a “stable” Linux distro in the first place. Once something’s configured and running, you just want it to keep doing so.

In my world, OS upgrades are generally paired with new hardware or VMs.

I did just this on an Ubuntu VM recently, which does have an in-place upgrade system. I’d been ignoring its motd offers of upgrade for years, on purpose, and only upgraded it from 14.04 LTS to 18.04 LTS when I needed to rebuild the VM anyway.

That’s why I was on an LTS release in the first place: to give me the years of stability that let me batch the changes up into a single big-bang upgrade. CentOS is even better in this regard, with version lifetimes up around 10 years, rather than 5 for Ubuntu LTS. One of the reasons I chose to upgrade it recently was because Ubuntu 14.04 is about to fall out of support, so it was time to move.

I believe a lot of the antipathy toward systemd is that people want “LTS” to be forever. That’s not going to happen until the rest of the world stops changing. That would be a very sad thing: it’s basically a wish for stagnation.

If upgrading via separate hardware or a new VM is difficult, it calls into question the usefulness of your backup and restore strategy.

Another advantage of this style of upgrade is that you have the prior box online and ready to fall back to if the manual upgrade fails. If an in-place upgrade fails, you’ve just lost the primary.

On 18/10/18 22:09, John R. Dennison wrote:

On Thu, Oct 18, 2018 at 10:27:32AM -0500, Valeri Galtsev wrote:

[topical reply trimmed for brevity]

Please learn how to trim your replies. Rough count and 145 lines of crap could have been removed from your recent post. This is getting a bit ridiculous, Valeri:

https://wiki.centos.org/GettingHelp/ListInfo

Fourth item, top section "CentOS Mailing Lists and Posting Guidelines"

Just wondering if you read down as far as the sixth item?

Note: do not reply privately to me with yet another flippant reply; please read and adhere to the published guidelines for this and other centos.org mailing lists.

					John

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 10/18/18 1:36 PM, Walter H. wrote:

On 18.10.2018 00:08, Johnny Hughes wrote:

...

The bottom line .. we don't make the decision whether or not to use systemd or not.  We rebuild RHEL source code.

will there come a CentOS 6.11 which will be capable of TLS1.3 or HTTP/2? I'm sure there will come a CentOS 8, but when is it probable to be released?

You will also need openSSL 1.1.1 for some TLS 1.3 functions.

one of the most important things (for me), as I already noticed there will be quite differences between CentOS 6 and CentOS 7, not only systemd or not, also Apache 2.2 and 2.4 and many other; the config files won't be the same, will there be a migrate helper or something like this which does the config conversion to get a CentOS 7 or maybe then CentOS 8 that does exact the same things the old CentOS 6 did?

On 10/18/18 4:14 PM, Johnny Hughes wrote:

On 10/18/2018 12:36 PM, Walter H. wrote:

...

On 18.10.2018 00:08, Johnny Hughes wrote:

...

The bottom line .. we don't make the decision whether or not to use systemd or not.  We rebuild RHEL source code.

will there come a CentOS 6.11 which will be capable of TLS1.3 or HTTP/2? I'm sure there will come a CentOS 8, but when is it probable to be released?

We have no idea .. we don't design what is in CentOS. If Red Hat adds those things to RHEL-6 then we will put them in CentOS .. If they don't we won't.

And for example, if RH does not backport openSSL 1.1.1, you will not get EDDSA certificate support for TLS  1.3.  Now you might not care about this for your servers and just continue to use ECDSA certs. Clients will increasingly encounter EDDSA certs and it will be interesting to see how this is handled in older clients.  We have had years to spread support for ECDSA before it started appearing from servers.  May not for EDDSA.

Self-touting, I have an Internet Draft out on using openSSL command line to build an EDDSA pki.  I did the work on Fedora29-beta.

I think all the other TLS 1.3 features are in the latest 1.0.n version of openSSL.  Of course that is ALSO a backport issue.

I have been told that if you set up your client to only accept TLS 1.3 connections, the Secure Internet gets really small really fast...

...

one of the most important things (for me), as I already noticed there will be quite differences between CentOS 6 and CentOS 7, not only systemd or not, also Apache 2.2 and 2.4 and many other; the config files won't be the same, will there be a migrate helper or something like this which does the config conversion to get a CentOS 7 or maybe then CentOS 8 that does exact the same things the old CentOS 6 did?

No, there is no automated way to move from CentOS-6 to CentOS-7 .. and we have no idea what will be in CentOS-8 until Red Hat releases RHEL-8. We have no idea what will be in CentOS-6.11 until Red Hat releases RHEL-6.11 .. and we have no idea what will be in the release of CentOS-7 until Red Hat releases RHEL-7.6 .. literally, we take the source code they release .. modify it for Trademarks and Logos .. and release it. Until it is released, we don't have a clue.

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On 10/18/18 11:06 PM, Barry Brimer wrote:

On Thu, 18 Oct 2018, Robert Moskowitz wrote:

...

On 10/18/18 4:14 PM, Johnny Hughes wrote:

...

On 10/18/2018 12:36 PM, Walter H. wrote:

...

On 18.10.2018 00:08, Johnny Hughes wrote:

...

The bottom line .. we don't make the decision whether or not to use systemd or not.  We rebuild RHEL source code.

will there come a CentOS 6.11 which will be capable of TLS1.3 or HTTP/2? I'm sure there will come a CentOS 8, but when is it probable to be released?

We have no idea .. we don't design what is in CentOS.  If Red Hat adds those things to RHEL-6 then we will put them in CentOS .. If they don't we won't.

And for example, if RH does not backport openSSL 1.1.1, you will not get EDDSA certificate support for TLS  1.3.  Now you might not care about this for your servers and just continue to use ECDSA certs. Clients will increasingly encounter EDDSA certs and it will be interesting to see how this is handled in older clients.  We have had years to spread support for ECDSA before it started appearing from servers.  May not for EDDSA.

I am under the impression that TLSv1.3 support appeared in 1.1.1 so I don't believe that you could do any TLS 1.3 with prior versions.

https://wiki.openssl.org/index.php/TLS1.3

Yeah, I was kind of hedging my comment that maybe something for 1.3 would be in the earlier version, but yes, all the TLS 1.3 work was focused on openSSL 1.1.1.  I was personally focused on EDDSA support.

So a number of items have to appear in C6 for it to support TLS 1.3.  More slowness in TLS 1.3 availability.  Kind of flies in the face of a claim made against my HIP protocol which 'requires kernel level changes' and thus too hard to deploy.  TLS is an upper layer protocol and changes easily roll out.

Yeah, right.

No, there is no automated way to move from CentOS-6 to CentOS-7 .. and we have no idea what will be in CentOS-8 until Red Hat releases RHEL-8. We have no idea what will be in CentOS-6.11 until Red Hat releases RHEL-6.11 .. and we have no idea what will be in the release of CentOS-7 until Red Hat releases RHEL-7.6 .. literally, we take the source code they release .. modify it for Trademarks and Logos .. and release it. Until it is released, we don't have a clue.

This is in the RHEL 7.6 Beta Release Notes:

Part I. New Features This part documents new features and major enhancements introduced in Red Hat Enterprise Linux 7.6 Beta.

Chapter 4. General Updates In-place upgrade from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7

An in-place upgrade offers a way of upgrading a system to a new major release of Red Hat Enterprise Linux by replacing the existing operating system. To perform an in-place upgrade, use the Preupgrade Assistant, a utility that checks the system for upgrade issues before running the actual upgrade, and that also provides additional scripts for the Red Hat Upgrade Tool. When you have solved all the problems reported by the Preupgrade Assistant, use the Red Hat Upgrade Tool to upgrade the system.

On 10/18/2018 10:09 PM, Barry Brimer wrote:

...

...

No, there is no automated way to move from CentOS-6 to CentOS-7 .. and we have no idea what will be in CentOS-8 until Red Hat releases RHEL-8. We have no idea what will be in CentOS-6.11 until Red Hat releases RHEL-6.11 .. and we have no idea what will be in the release of CentOS-7 until Red Hat releases RHEL-7.6 .. literally, we take the source code they release .. modify it for Trademarks and Logos .. and release it. Until it is released, we don't have a clue.

This is in the RHEL 7.6 Beta Release Notes:

Part I. New Features This part documents new features and major enhancements introduced in Red Hat Enterprise Linux 7.6 Beta.

Chapter 4. General Updates In-place upgrade from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7

An in-place upgrade offers a way of upgrading a system to a new major release of Red Hat Enterprise Linux by replacing the existing operating system. To perform an in-place upgrade, use the Preupgrade Assistant, a utility that checks the system for upgrade issues before running the actual upgrade, and that also provides additional scripts for the Red Hat Upgrade Tool. When you have solved all the problems reported by the Preupgrade Assistant, use the Red Hat Upgrade Tool to upgrade the system.

I don't believe this is new to 7.6 Beta .. I believe this has been available since the beginning of RHEL 7

https://access.redhat.com/solutions/1242133

As I have posted about this many times before.

That is a community controlled package set .. we need some people from the community to step up and modify / maintain those packages.

I have asked again and again, on several fronts (blog, mailing lists, etc), to get volunteers to maintain those packages.

I'll ask again now.

Does someone from the community want to do the work to maintain those packages?

Here are a couple previous attempts:

https://blog.centos.org/2014/07/testing-centos-6-to-centos-7-upgrades-via-ce...

https://lists.centos.org/pipermail/centos/2016-May/159326.html

We would be very happy to publish those RPMs if we can get them to be maintained by the community, and maintained in a consistent manner.

Thanks, Johnny Hughes