Live data from Hacker News

CentOS 7 potential release

seven.centos.org

31–40 of 57 posts

Re: CentOS 7 potential release

#31
post #13
post #8

Even this article title says "POTENTIAL" release. I am not even sure it is signed? They are still doing QA, it will be a week or two before GA Before you rush to 7.0 after 6.5 - things you are going to have to learn because they change everything: systemd replaces init.d grub2 replaces grub xfs is now default over ext4 filesystem ( many, many people dislike systemd, it is somewhat anti-linux in nature ) No more easy…

You can enable text log files by installing 'rsyslog'. You only have to install the package, no further configuration is needed.

And you should probably make sure that you do since every existing log analysis tool requires text logs.

Also, remote syslog, which journald doesn't support.

Re: CentOS 7 potential release

#32

If I were a large enterprise I'd reconsider CentOS. RedHat's lack of a commitment to the customer's experience in favor of RH's personal design preferences smacks of Oracle-ism. Anything they develop they immediately force on their users, and you have to just accept it rather than use it optionally. It's less easy to get away from those kind of changes versus something more open like ubuntu/debian (and I have no love…

Care to elaborate?

Systemd has a few nice features that I (as a systems admin of thousands of servers) really like such as:

    - simple "init script" like upstart, so magical or crappy shell scripts from vendors are a thing of the past. A standardized unit file

    - Ulimit support natively as part of the format

    - Limiting via memory/disk/cpu cgroups to contain buggy apps (hello mysql!)

    - Process restarting so tools like supervisord, monit, runit, etc are no longer necessary

    - It can _always_ stop an errant daemon as it uses control groups to do so, sysv init was sometimes buggy in this regard

    - Private /tmp (via filesystem namespaces), limiting system calls a service can run, tcp wrappers, read only parts of the filesystem (like /etc) are all trivial to add to any legacy service such as bind or sendmail and a supported part of the systemd unit file definition.
RHEL/CentOS 7 also include some super nice things like the new abrtd for centrally reporting any application coredump/kernel issue, pacemaker/crm for high availability clusters, and just a lot newer linux userspace. (yay for du -hsc | sort -h | tail)

As an _actual_ user who uses RHEL/Debian/etc on bare metal at scale, I really see nothing but awesome in RHEL7. It is just like I see awesome in Fedora 20 or in the latest Ubuntu/Debian. The Linux ecosystem has massively grown. Now we have a serious engineering company putting a lot of resources into supporting a new operating system. I'd love to see some of the technical reasons you have the opinion you do.

Re: CentOS 7 potential release

#33
post #18
post #16

Earlier quoted context omitted.

You don't like systemd but it's probably time to accept the fact that it has "won". Most major distros including Debian is switching to it so it will get harder and harder to avoid. Might as well make the effort to learn it now.

Technically I don't have to accept it until 2020 ;-) (and FreeBSD has declared they will never use it, which to be fair is easy for them to declare since they cannot use it because it requires posix) (correction: not posix, cgroups and udev)

You don't really ever have to accept it. Go grab the sysvinit source and run it. Have fun managing everything yourself. Ditto for copying a simple rc system like Slackware or OpenBSD provide. For that matter, throw out everything, declare dependencies and solve the problem with prolog. The thing is, once you deviate from the norm on linux, you just have to understand things at a deeper level. Not impossible, but IMO maintaining your own custom distro gets old after awhile.

Re: CentOS 7 potential release

#34
post #18
post #16

Earlier quoted context omitted.

You don't like systemd but it's probably time to accept the fact that it has "won". Most major distros including Debian is switching to it so it will get harder and harder to avoid. Might as well make the effort to learn it now.

Technically I don't have to accept it until 2020 ;-) (and FreeBSD has declared they will never use it, which to be fair is easy for them to declare since they cannot use it because it requires posix) (correction: not posix, cgroups and udev)

It requires Linux-specific kernel APIs like cgroups and udev, not POSIX.

Most *BSD systems are mostly or fully POSIX compliant.

Re: CentOS 7 potential release

#35
post #31
post #13

Earlier quoted context omitted.

You can enable text log files by installing 'rsyslog'. You only have to install the package, no further configuration is needed.

And you should probably make sure that you do since every existing log analysis tool requires text logs. Also, remote syslog, which journald doesn't support.

I'm afraid you're mistaken, please don't spread misinformation:

http://www.freedesktop.org/software/systemd/man/systemd-jour...

Re: CentOS 7 potential release

#36
post #14
post #8

Even this article title says "POTENTIAL" release. I am not even sure it is signed? They are still doing QA, it will be a week or two before GA Before you rush to 7.0 after 6.5 - things you are going to have to learn because they change everything: systemd replaces init.d grub2 replaces grub xfs is now default over ext4 filesystem ( many, many people dislike systemd, it is somewhat anti-linux in nature ) No more easy…

No more easy editing/understanding grub.conf True, the grub2 config is horrible. No more easy to understand /etc/init.d It's a bit more complicated, but not too bad: Instead of "/etc/init.d/thing restart" you type "systemctl restart thing" Instead of chkconfig --list, you type "systemctl list-dependencies" Writing the equivalent script with systemd is much cleaner with less hacks, particularly for launching as differ…

systemctl: I don't think anyone cares about a change of command name / syntax, it's the removal of flexible, small, readable, plain text files that is the problem. That the underlying init system of linux no longer follows the linux philosophy boggles the mind.

Re: CentOS 7 potential release

#37
post #25

Earlier quoted context omitted.

XFS is a dealbreaker for me. Nothing but bad experiences with that particular FS, especially when the filecount goes up.

Note that of course you can still choose to use EXT4 when installing 7

Ah, that's just the default. I see. I was wondering what they were smoking there that makes a lot more sense. It's a very peculiar choice, EXT4 is pretty good for most use cases, when you need XFS there are few alternatives but the performance issues make it a love/hate relationship and I really would not want that on my machines by default.

One problem with colocation is that a lot of the hosting providers I work with simply do a default re-image which will use whatever the OS comes with as standard. So chances are those will default to XFS and good luck getting rid of it then. (No phyical access to the machines.)

Re: CentOS 7 potential release

#38
post #4

looking forward to trying systemd, hope it isn't too much of a learning curve. Looking at: http://tecadmin.net/red-hat-enterprise-linux-7/# - will HAProxy come with centos 7?

It honestly isn't. The documentation is really good if you know how to use google.

Re: CentOS 7 potential release

#39

If I were a large enterprise I'd reconsider CentOS. RedHat's lack of a commitment to the customer's experience in favor of RH's personal design preferences smacks of Oracle-ism. Anything they develop they immediately force on their users, and you have to just accept it rather than use it optionally. It's less easy to get away from those kind of changes versus something more open like ubuntu/debian (and I have no love…

[deleted]

Re: CentOS 7 potential release

#40
post #38
post #4

looking forward to trying systemd, hope it isn't too much of a learning curve. Looking at: http://tecadmin.net/red-hat-enterprise-linux-7/# - will HAProxy come with centos 7?

It honestly isn't. The documentation is really good if you know how to use google.

Until its your network gatewayb appliance that is down and then you're fucked...

NEVER rely on Google for documentation or GNU info as that's probably not installed on your server.

This sort of scenario is where *BSD win every time.

Post reply on HN