Live data from Hacker News

CentOS 7 potential release

seven.centos.org

41–50 of 57 posts

Re: CentOS 7 potential release

#41
post #14

Earlier quoted context omitted.

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.

Yes they reinvented some text files as the NT event log...

TBH the first thing I do is ship the logs off the box so journald seems a waste of space.

Re: CentOS 7 potential release

#42
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

Oh, that's beautiful. And if you want to get s..t done, you can't even quickly search the manpage, because for religious reasons, GNU projects use that weird (and traditionally utterly verbose) info system. But hey, GNU is for GNU's Not Unix, so we shouldn't be too surprised ...

It's not like I didn't appreciate what the GNU project has done for the free software world, but it's so annoying that they seem to be focused more on religious matters than on writing good (well-documented, easy-to-configure, non-bloated) software.

I'm doing more and more server stuff with the BSDs, simply because the docs are so well-written and if I want to understand some part of the system, it doesn't feel like there are numerous layers of abstractions hiding away the interesting parts from me.

Re: CentOS 7 potential release

#43
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…

XFS and its lack of data journaling (it only journals its own metadata) is notorious for corrupting data on power loss and kernel crashes. It performs well only under specific workloads and hardware setups.

Why choose it as the default filesystem in an enterprise-oriented distro?

Re: CentOS 7 potential release

#44
post #35
post #31

Earlier quoted context omitted.

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...

I was going on information from Red Hat that RHEL7 can't do that. Turns out, Red Hat was right, RHEL7 can't.

systemd-journald-remote was added with systemd 212, RHEL and CentOS ship with 208, so no, journald on RHEL7/CentOS7 can not do remote logging.

I also like completely ignoring how journald breaks every log analysis tool.

Re: CentOS 7 potential release

#46
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.

Would the server then do two writes, both to the binary log for systemd and then to rsyslog?

I suspect so, because systemd needs it's logs for internal analysis?

Re: CentOS 7 potential release

#47
post #14

Earlier quoted context omitted.

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.

I have to disagree. I've written some stupidly big init.d scripts in my time. Replacing them with:

    [Unit]
    Description=My dumb script
    
    [Service]
    Exec=/usr/local/bin/dumb-script
And no longer caring about PIDs, forking, etc. has been very refreshing.

I agree, however, that systemd feels too monolithic, and I question the wisdom behind journald.

Re: CentOS 7 potential release

#48
post #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 su…

I'm not going to turn this thread into a debate over the merits of individual contributions to CentOS. All i'm saying is whatever RH develops gets shoved into their distro with seemingly no regard to the customer. It's not just that they're adding new tools, they're also forcing you to use them.

The nice thing to do for your customers is to make new technology optional, and provide alternatives for people who have 10+ year old infrastructure that they don't want to spend 2 years upgrading because it's now full of legacy systems. But RH not only shoves anything they want down your throat, half the time they're not transparent about the changes taking place, and you just have to hope nothing breaks your apps (kernel as an example, but userland package changes are similar).

Re: CentOS 7 potential release

#49
post #40
post #38

Earlier quoted context omitted.

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.

The man pages are also available for every systemd app.

Re: CentOS 7 potential release

#50
post #32

Earlier quoted context omitted.

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 su…

I'm not going to turn this thread into a debate over the merits of individual contributions to CentOS. All i'm saying is whatever RH develops gets shoved into their distro with seemingly no regard to the customer. It's not just that they're adding new tools, they're also forcing you to use them. The nice thing to do for your customers is to make new technology optional , and provide alternatives for people who have 1…

RHEL6 is supported until 2020[1]

[1] https://access.redhat.com/support/policy/updates/errata/

Post reply on HN