Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CentOS 7 released on x86_64

lists.centos.org

Post reply on HN
Print view View original

41–50 of 123 posts

Re: CentOS 7 released on x86_64

#41

Post by mgkimsal »

Ologn wrote: post #36
derekp7 wrote: post #30

Earlier quoted context omitted.

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

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

So... if there's a friday night problem, you'd prefer staff to just be hanging, chillin' at home, and then when pressed, say "we created a ticket with redhat, nothing more to do!" ?

Critical breakages should keep people working until stuff is fixed. If you want to also pay a bit extra and involve external support people, that's fine, but it's not a magic bullet that just 'fixes' everything. You've now got to account for time to manage working with external support staff, making sure you can get them in to the affected systems, etc.

Re: CentOS 7 released on x86_64

#42

Post by qstyk »

Am I missing something? This was submitted two hours ago, yet the images (CentOS-6.5-x86_64-bin-DVD1.iso) are the same that I had downloaded on 6/20/2014. The release notes list the new image names, but they don't appear to be pushed out to the mirrors.

Re: CentOS 7 released on x86_64

#43

Post by kureikain »

I always scare of CentOS/Fedora. Whenever I updated something, it will be very old packages. Leading to use 3rd repo, and without any kind of document, the next sysadmin will be in trouble. I used to install Gearman on Centos 5.9 and it was a nightmare: the original 3rd repo didn't have gearman and I have to use other repo which is complain about PHP-Common conflicting. Remi and webtactic did help at the end.

It's hard to keep Centos Update to date with latest software IMHO.

I'm not an SysAdmin but I think the idea of APT and YUM is same but why it's so hard/trouble to use YUM?

Re: CentOS 7 released on x86_64

#44

Post by TallGuyShort »

kureikain wrote: post #43

I always scare of CentOS/Fedora. Whenever I updated something, it will be very old packages. Leading to use 3rd repo, and without any kind of document, the next sysadmin will be in trouble. I used to install Gearman on Centos 5.9 and it was a nightmare: the original 3rd repo didn't have gearman and I have to use other repo which is complain about PHP-Common conflicting. Remi and webtactic did help at the end. It's ha…

Perhaps it's what you're familiar with and the intended use case. I personally can't stand the way APT won't let you override certain behavior. RHEL / CentOS have always favored stability over being bleeding-edge, and in my experience EPEL provides enough newer software to make the system usable for most cases, although if you're wanting the latest frameworks, etc.. I can see that being incompatible with your needs. I have very rarely had any problems with broken dependencies in Red Hat repositories except for the occasional 15-minute hiccup. SUSE seems to have more problems, but still has never been enough of a problem to make me question using it in production.

Re: CentOS 7 released on x86_64

#45

Post by nailer »

jftuga wrote: post #27
nailer wrote: 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…

It looks like your node deployment is very clean. For your application, are you simply using npm and a package.json file?

Yes. I commit node_modules though.

Re: CentOS 7 released on x86_64

#46

Post by jamescun »

kureikain wrote: post #43

I always scare of CentOS/Fedora. Whenever I updated something, it will be very old packages. Leading to use 3rd repo, and without any kind of document, the next sysadmin will be in trouble. I used to install Gearman on Centos 5.9 and it was a nightmare: the original 3rd repo didn't have gearman and I have to use other repo which is complain about PHP-Common conflicting. Remi and webtactic did help at the end. It's ha…

Fedora is the RedHat "testbed" and has regular updates similar to the debian/ubuntu universes.

One of the core features of CentOS/RedHat/Scientific Linux/etc is their longterm support and package freeze (excluding critical security updates). If you are reliant on a different version of software from the default repositories (both newer or older) then you are encouraged to build and package them yourself. Additionally in the RedHat-derivative universe there is the EPEL package repository which contains a wider range of software and is kept more readily updated in addition to being maintained by the Fedora Project (essentially RedHat).

Re: CentOS 7 released on x86_64

#47

Post by scott_karana »

mgkimsal wrote: post #41
Ologn wrote: post #36

Earlier quoted context omitted.

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

"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." So... if there's a friday night problem, you'd prefer staff to just be hanging, chillin' at home, and then when pressed, say "we created a ticket with redhat, nothing more to do!" ? Critical breakages should keep people working until st…

That's a false comparison.

If a machine is kernel dumping, and Red Hat is trying to diagnose and fix the machines, nobody said your sysadmins will automatically just go home.

Instead, they can use their time more productively: making a secondary/workaround, or figuring out ways to re-architect your solution around the failure points.

Re: CentOS 7 released on x86_64

#48

Post by Torgo »

mackal wrote: post #37
netcraft wrote: post #17

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?

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…

Does "years of fucking with PulseAudio problems" count as its own item, or is that a subset of item 1?

Re: CentOS 7 released on x86_64

#49

Post by derekp7 »

Ologn wrote: post #36
derekp7 wrote: post #30

Earlier quoted context omitted.

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

I've been on both sides of the fence with regards to vendor support. In an extreme case at one company I worked with, when I'd report a slight irregularity or outage to my boss, the first question he'd ask is what is the vendor support ticket number. After all, the company was paying for the support, so it was a very high failing if an employee spent any energy in trying to solve an issue.

The problem with this, of course, was that I don't want to open a vendor ticket until I have something to give them to work on. A random program crashed? First I'd blame the programmer or some other issue, not a kernel bug. But that particular manager just wanted to pin everything on the vendors no matter what.

As an aside, since I've been supporting Linux systems for the last 1.5 decades, I've only had to call in OS vendor support twice -- once was to verify what I already new (clock skew due to a bad hardware timer chip), and another time to satisfy an app developer manager who wouldn't take responsibility for his team's code.

Actually, I should add something -- with Red Hat support, you also get access to a whole history of past case logs at access.redhat.com -- these are discoverable through a Google search, but to see the full solution you have to be logged in. And this has actually kept me from needing to call Red Hat on a number of occasions, so I guess this can count as using Red Hat's support indirectly. And their knowledge base is very well written, esp. when explaining the root cause of specific known past issues.

Re: CentOS 7 released on x86_64

#50

Post by mackal »

Torgo wrote: post #48
mackal wrote: post #37

Earlier quoted context omitted.

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…

Does "years of fucking with PulseAudio problems" count as its own item, or is that a subset of item 1?

I've never had issues with PulseAudio personally.
Post reply on HN