The problems systemd sought to fix sadly we're solved years ago by Dan Bernstein with daemontools. Process supervision isn't new, but it's taken forever for anyone to even think about using it. Bsdinit and sysvinit both can start up things then pass off init to Runit, s6, perp, or djbdts and still be fast with loads. To me systemd only reinvented a wheel guys like Gerrit Pape, Dan Bernstein, and Laurent Bercot solved years prior.

We had djbdts since 1999 so why the Hell didn't anyone bother using it? Djbdts solved it without creating the so-dubbed clusterf*ck in the system and simplified init. Init loaded the system at the bare minimum then svscan from djbdts loaded daemons all in parallel using tree based dependency loading.

To me vermaden, if people had used the tools given when they had the chance we'd never have seen systemd even sprout from the black ooze from whence it spawned from. Distributions like CentOS, Debian, and such wouldn't be all clones of each other.

It's been refreshing to see nearly unknown distributions like VoidLinux crawling up through the cracks dumping systemd like a bad habit for more system and resource friendly solutions like Runit. I dare say my next distribution might just be an alternative project Linux.

On a long enough timeline, the survivability of systemd as a project will eventually drop to zero.

@ReaperX7

Agreed.

Also on VIOD Linux: https://twitter.com/vermaden/status/498755465850134528

One problem of these alternate init and init-helpers had was the fact they all aren't GPL licensed. I think honestly people are wising up and seeing not all good projects reside under the GPL umbrella. Just because it has GPL plastered all over it, doesn't make it the next best thing since Black Coffee. If GPL was so great, I wouldn't be using a CDDL licensed file system on my Linux box, and our Runit-for-LFS project wouldn't be MIT licensed.

No issues here with CentOS 7 or Anaconda.

For those who have not been paying attention to Fedora for a few years, the Anaconda rewrite and redesign abandoned the lockstep sequential you-can't-go-back-and-fix-anything approach. It's based on a so-called hub-and-spoke approach with all tasks accessible by clicking icons at the hub. The "Done" approach is taken because there is no "next" step. You just return to the hub until you are satisfied with everything. E.g., you can edit package groups to be installed umpteen different times if you want.

I never cease to be amused that so many apparently clever people are so flummoxed when the people who give them software for free change something. Can't they figure it out?

(As a user, I don't care about the systemd politics. I expect the init process to be hidden from me.)

1 members found this post helpful.

Can't figure it out? Did you read my post at all or did you just page down to the reply button and jump into defensive mode for some reason?

Basic partitioning functionality is GONE. If a user can't assign an existing partition to a mount point on the new filesystem, that is a fundamental, unforgivable failure in the installer. And on top of that, undoing existing partitioning information results in a CATASTROPHIC FAILURE that shuts down the entire installation process and reboots the computer!

No, this is not a simple change in appearance, this is an absolute abomination of an installer for a supposedly "enterprise" OS. The fact that this POS was actually released seriously disturbs my notion of what the CentOS developers stand for with regards to usability and stability. Given these bugs, CentOS 7 should at this point be an ALPHA release, not even to the level of BETA, much less so-called stable, distributable, etc.

The Fedora installer isn't even this bad, and that's saying something!

Or are you saying that users of free software aren't allowed to complain when that software is crap? Well I'm afraid I can't help you there.

Yes, but apparently for different reasons.

I had no trouble with that.

I can only guess I would not have been confused by that even if I had not been warned. The change from sequential to "hub and spoke" and change from "next" (step) to "done" (with this step) seemed obvious when I saw it, but I had also been warned to look for the tiny "Done" button.

Now that you mention it, I didn't see that option either. I wanted the default. I got the default. But I still would want to know where the option is.

When (which screen)?

At some point I will find that VERY annoying. When installing earlier Centos versions, I usually wanted to create my partitioning in a liveCD boot of a different distribution and then tell the Centos installer to use those. On some systems, the Centos installer was sufficiently confused by previous Windows fake RAID that it could not create the partitions I needed and I had no choice but to use another distribution liveCD to create the partitions for Centos.

This time, I had already shrunk Windows and I wanted to manually partition the space that created and doing so in the Centos 7 installer was easy.

I watched our local IT guy start a Centos 7 install, and he chose the option to blow away everything on sda and use default partitioning. That was easy (maybe too easy, because a beginner might not understand what it was doing).

Here's a screenshot from the installer (from that review I mentioned in the first post):
http://www.dedoimedo.com/images/comp...-selection.jpg

That "full disk summary and bootloader" text at the bottom is a button, if you click on that it brings up the bootloader menu.

What bothered me most was confusion over selecting which packages would be installed initially from the DVD (available on first reboot).

I know I can use yum to install whatever I want pretty easily later. But there are still advantages to having some packages there from the start.

If I remember correctly, earlier Centos versions let you choose packages from several different categories and the choices stuck, so what you ended up with was all the packages you choose. If I understand correctly, this one have several basic plans and you can select a plan and packages in that plan, but you can't select a few packages each from two or more different plans. Of course the important packages I wanted for the first reboot were not together in one plan.

I set up this system on my employer's LAN, so the process was made more difficult by my lack of knowledge about that LAN and lack of admin rights:

We use NIS. I'm not sure what packages are needed for a workstation in an NIS LAN, but something is and I didn't figure out how to install that up front. So when the system reboots before asking to create a local user, I don't have any option to skip that and use my real account.

Similarly, large parts of the environment to make a computer usable on this LAN are based on yp and automount and similar tools. According to our IT guy, if all those packages are installed before the reboot within the install process, all the required info comes in through DHCP and everything comes up usable and not intervention by a LAN administrator would be required. But booting without those installed gives me a system I can't use without getting him to fix things.

The dual boot with Windows was not set up automatically by the Centos 7 installer. I'm experienced enough to deal with that with only minor inconvenience. Most serious users of Centos 7 won't want dual boot with Windows anyway. But the users most likely to want dual boot are the users least able to deal with fixing that themselves after the fact.

My limited testing seems to show that the os-prober code for creating the dual boot doesn't work until after you have installed ntfs-3g. I'm not sure that is correct. But if it is true (and of course you can't install ntfs-3g from the Centos 7 DVD, so dual boot can't be correct initially) there ought to be a very clear warning and instructions to get beginners past that.

os-prober ought to be smarter. Without ntfs-3g, maybe it can't tell the partition flagged as bootable in the partition table is Windows (so it can't label the menuentry confidently). But it can trivially tell something was meant to be bootable and it can trivially create a usable menuentry for it. So that is a mis-feature in os-prober so bad, I think it is a bug not just a badly thought through feature.

I tried Centos 7 on a 4 year old high end (for four years ago) work station with an expensive nVidia display card with four LCD displays connected.

Centos 7 came up using all four displays and so horrible slow it was nowhere close to usable. I guessed it was a display driver problem related to four displays and painfully slowly (every mouse movement was a challenging task) found the place to disable displays and disabled three of them, resulting in normal performance.

Any failing of open source nVidia drivers is not the fault of the Centos distribution, nor its installer. But if this is at all common for multiple display workstations, the installer ought to be more conservative about what is initially enabled.

This is a temporary install for investigation of various issues and will mostly be accessed from other systems via ssh -X so getting it to work well with its attached displays isn't important. I might work though that mess anyway for the learning value. But I don't know if/when I'll have time. In similar situations in the past, I always waste lots of time trying/failing to get the open source drivers configured correctly then switch to the closed source driver spending nearly as much time again on the configuration details but getting it to work.

Maybe I am the outliner here but I got CentOS7 installed on my home server and it runs great. There are some configuration issues that were my fault, but other then that smooth sailing. The installation GUI was abysmal though, I will admit that. Once you got used to the weird "Done" = "Next" quark, it was at least manageable. Once up and running I could install all the programs I use regularly from yum without having to force-compile something cause of how out of date the os is (looking at you CentOS6.5). And if my laptop was 64bit I would be upgrading that to 7 as well.

I am not disappointed. But then again, I don't have high expectations of any OS. I take it for what it is: an upgrade to 6.5. Is it an upgrade to 6.5? Yes. Yes it is.

All you disappointed peoples, be happy! There are other distro's out there if CentOS7 doesn't do it for you. Just be glad you are not a windows user stuck with Windows8 (w/o touchscreen)

i agree with johns that centos 7 was too buggy to be called an 'Enterprise' OS. i was able to dualboot windows 7 only after installing ntfs-3g, just after installation centos 7 marked windows partitions as unknown. if it is intentional it emulates windows which boorishly overwrites MBRs and refuses to recognise other file/operatingsystems.

during the update process i got the impression that users should not expect quality for free. i have not
felt anything like this with FreeBSD or Slackware.

Come on now. You have never, ever, ever experienced a bug in FreeBSD or Slackware, and FreeBSD and Slackware has never, ever, ever made a mistake in a release?

I think it's fine to point out flaws and state your opinion, but wrapping it up with "because on the contrary, these two operating systems have always been infallible" takes away from your credibility and shows your bias.

The mistake here lies in adoption. As a sysadmin, I learned way back in the day to not adopt ANY operating system and use it in production until it has been out for a couple of years. IMO, that inclination is why many, many, many, many, many, many companies still have Windows 2008 servers and Solaris 11.0 servers and RHEL 4 servers - because they aren't going to grab the newest 'enterprise' OS and plug it into their infrastructure without some major vetting first.

"Enterprise" users aren't going to be dualbooting with Windows.