Live data from Hacker News

CentOS 7 released on x86_64

lists.centos.org

31–40 of 123 posts

Re: CentOS 7 released on x86_64

#31

Earlier quoted context omitted.

http://boycottsystemd.org/

>...an abhorrent and violent slap in the face to the Unix philosophy... I can't imagine why this didn't get more traction.

>Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well.

And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true.

>In fact, udev merged with systemd a long time ago

systemd relies on udev and dbus, but udev doesn't pull in systemd as a hard dependency: another falsehood I've seen parroted by those in support of the eudev fork.

Re: CentOS 7 released on x86_64

#32
post #29

I've never used RHEL. It doesn't seem prohibitively expensive. What advantages are there over Centos, other than support?

CentOS is a repackaged RHEL, with all the Red hat IP (logo's, artwork etc.) stuff stripped out. So it's almost the same distribution. As such, the only advantage RHEL probably offers next to support are slightly faster updates.

And actually being able to call redhat can be very useful once in while when you are having a really bad day.

Re: CentOS 7 released on x86_64

#33

Earlier quoted context omitted.

that looks so much cleaner than init.d scripts. I have heard some people refer to systemd as not very linux-esque - can someone comment on what that might mean?

Linux did kind of get the short end of the stick with System V initialization. BSD rc scripts are also written in shell, but much cleaner (particularly when you make use of rcorder(8) dependencies). systemd's declarative unit file syntax is easier to reason with, but comes at the expense of having to memorize a ton of options and being fundamentally dependent on the toolbox provided to you by systemd, since you can't…

Of course your systemd startup can start a sh script at ease. I think systemd is going to make my life so much easier. Being more on the dev side of devops, but still needing to deploy correctly restarting aps depending on complex systems working. i.e. NFS mounts being available for data etc...

Re: CentOS 7 released on x86_64

#34
post #31

Earlier quoted context omitted.

>...an abhorrent and violent slap in the face to the Unix philosophy... I can't imagine why this didn't get more traction.

>Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well. And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true. >In fact, udev merged with systemd a long time ago systemd relies on udev and dbus, but udev doesn't pull in systemd as…

Optional, but enabled by default. Most distros seem to ship with defaults and only customize flags related to library paths and FHS details (besides whatever patching they may apply). The fact that it's even there is distressing enough, really.

No one is saying udev pulls in systemd as a dependency. Where is that said?

Re: CentOS 7 released on x86_64

#35

I've never used RHEL. It doesn't seem prohibitively expensive. What advantages are there over Centos, other than support?

The main benefit is support. Both in package updates and longevity.

Also you may want things like their software collections (which have had a hard time making it into centos).

Cost can be a little much especially if you don't need support other than package updates.

Also workstation in the minimum if you are going to do any development as desktop doesn't come with dev tools as far as I remember.

Re: CentOS 7 released on x86_64

#36
post #30

I've never used RHEL. It doesn't seem prohibitively expensive. What advantages are there over Centos, other than support?

The support goes both directions. It is a way to get the organization you work for to indirectly donate to a variety of free software projects, and your company also gets the contractual safety net that they want.

Yes. If you have RHEL installed on hundreds (or thousands) of HP/Dell servers at a Fortune 1000 company, you'll have someone to call if the kernel on some production machine keeps dumping.

I can see a bootstrapped company using CentOS, or a company running on angel/seed money. Once a company gets Series A funding though, you have to start wondering why they wouldn't upgrade to Red Hat. The message from the company basically is they'd prefer the sysadmin to spend their nights and weekends figuring out problems, instead of making a small payment for support service. This is the type of position you want to run, not walk from.

On a job interview, a good question for a sysadmin to ask an interviewer when they say "do you have any questions to ask me?", is, "Will I support any machines, operating systems or applications that are not under a vendor support contract?" Inevitably there will be one or two legacy machines or applications, but if you get a laundry list in response, run.

Re: CentOS 7 released on x86_64

#37
post #4

Woo. Have been using the RHEL 7 Amazon AMI images, and it's nice not to worry about shell scripts / custom supervisord stuff for your web services anymore. My node app is deployed with a single `myapp.service` file thanks to systemd: [Service] ExecStart=/usr/local/bin/node --harmony /var/www/myapp/server.js Restart=always User=nobody Group=nobody Environment=PATH=/usr/bin:/usr/local/bin Environment=NODE_ENV=productio…

that looks so much cleaner than init.d scripts. I have heard some people refer to systemd as not very linux-esque - can someone comment on what that might mean?

1) Lennart Poettering

2) MAH FREEDOMS!

There are technical reasons people don't like systemd that are valid, but usually the die hard anti-systemd people boil down to hating Lennart Poettering and complaining about how the US Constitution must some where say they never have to use systemd.

There are some valid concerns (big scope, bloat, feature creep, etc) but they really haven't come to fruition, although are still valid concerns.

At the end of the day, without much effort or trouble of switching to systemd from OpenRC, my system boots faster, which is great.

Re: CentOS 7 released on x86_64

#38
post #31

Earlier quoted context omitted.

>Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well. And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true. >In fact, udev merged with systemd a long time ago systemd relies on udev and dbus, but udev doesn't pull in systemd as…

Optional, but enabled by default. Most distros seem to ship with defaults and only customize flags related to library paths and FHS details (besides whatever patching they may apply). The fact that it's even there is distressing enough, really. No one is saying udev pulls in systemd as a dependency. Where is that said?

>Optional, but enabled by default

Where is it enabled by default? In what distro does gatewayd get pulled in by default?

>No one is saying udev pulls in systemd as a dependency.

By the eudev hobbyists, whose justification for their fork was largely "we don't want to force people to use systemd" and "no, we didn't contact upstream with fixes before we forked" in their presentation.

Re: CentOS 7 released on x86_64

#39
post #31

Earlier quoted context omitted.

>...an abhorrent and violent slap in the face to the Unix philosophy... I can't imagine why this didn't get more traction.

>Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well. And outright falsehoods. systemd-journald-gatewayd is entirely optional. People keep harping on a packaging mistake when it was first pushed to Fedora for testing, but repeating it so many times doesn't make it true. >In fact, udev merged with systemd a long time ago systemd relies on udev and dbus, but udev doesn't pull in systemd as…

I'd be very interested to see a qualified crypto expert on the "sealing" that journald uses. This is one of two indicators of a troubling level of arrogance from the developers. The crypto method used by journald to verify messages haven't been tampered with is called Forward Secure Sealing [0]. It's based on an invention of the brother of Lennart - the lead developer, and for a long time after first release even the whitepaper describing it in detail was "coming soon" The code he finally produced is [1] - but rather light on documentation. I'm still unaware of any proper analysis of this, and using your brothers own crypto methods and ignoring all the questions this has raised does not come across well - and appears to seriously violate the "don't roll your own crypto system" rule.

The second indicator is the attitude to bugs, of which [2] is a good example - several of the developers appear to be extremely defensive towards any suggestion of defects in their software, and simply close bugs blaming the users, other software, anything else.

I'd be hopeful that RedHat manage to reign this behavior in, but that didn't seem to work for Ulrich Drepper when he was employed by RedHat to work on glibc, and I'm not sure if it's going to work here.

That said - I'm not in the "systemd is awful" camp - I do think there's a whole bunch of things it does really well, and that a lot of the hate is really quite reactionary - but the thing that frustrates me is that between the haters and the supporters, there are important questions that are getting lost in the noise.

[0]: http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Re: CentOS 7 released on x86_64

#40
post #32
post #29

Earlier quoted context omitted.

CentOS is a repackaged RHEL, with all the Red hat IP (logo's, artwork etc.) stuff stripped out. So it's almost the same distribution. As such, the only advantage RHEL probably offers next to support are slightly faster updates.

And actually being able to call redhat can be very useful once in while when you are having a really bad day.

Given that the OP said "other than support", I'll assume you mean they're actually nice and supportive when call to complain about your day :)
Post reply on HN