Well, I explicitly tell a tool to do something, and it does something else. How is that "my fault"? I (or actually, my coworker) caught the error and nothing really broke, but in a list of dozens (or even hundreds) or packages to be upgraded, it's a very small thing to miss.
Looking at the bug report I agree with the developers - its not a bug, its a design choice. Don't like it? You can fork the code and fix it yourself.
If an unexpected situation occurs, a program should *ALWAYS* ask for user input or do the safest thing, not just try and guess and continue. This was the umpteenth problem I encountered with the pkg-ng tools, and this (together with some other things) seemed to indicate that the pride on "BSD stability" was a thing of the past, at least as far as FreeBSD is concerned. Even FreeBSD 5 was better (come to think of it, 10 is a multiple of 5; is there a rule here?)
It shows you which packages are going to be upgraded, which conflict and are to be removed. That is confirmation.
I don't see why package management would make you act like a spoiled brat and proceed to migrate off a platform entirely - there's a number of ways you could have solved the issues with pkgng that are far less extreme.
Haha. I never would have expected the
shill gambit here, of all places.
I am not using the shill gambit. I did not say "You're a shill" I said you're shilling, committing the act of. If you had outlined how CentOS better handled the same problem - I would not be saying that. Pay closer attention to my rhetoric. I'm not using ad hominem.
Well, you seem to have misunderstood the reason CentOS ships with "old" packages. After a release, the team does their best to make sure that nothing breaks (but that everything is secure). Apache 2.4 has a number of
breaking changes, so you can't upgrade safely.
Should it offer both? Perhaps ... but this is not always easy (dependencies may also have to be upgraded, and this have two versions), it needs to be kept secure (costing valuable manpower), and the benefits are usually minimal (Apache 2.2 works fine for most).
I am *not* misunderstanding. If people want to use old packages, that's fine. Let them. Instead of keeping apache as one RPM in the repo, split it up like I said, so that when you do upgrades, yum won't update the apache version to the next major version. I'm well aware of the dependency problem this can cause, but, that's their job. They're repository maintainers. They should do their job.
As for minimal benefits, Apache 2.2 is vulnerable in both MPM worker and MPM prefork to Slowloris attacks. It also suffers from lesser performance. This is a design choice. Apache 2.4 has an NGINX inspired MPM event module that runs it under a much more modern architecture. Sure, there's other modules and ways of safeguarding Apache against Slowloris attacks, but its like putting a thick wall in front of a weaker one with stress fractures - it doesn't correct the underlying problem.
Now what's wrong with ext4?
Out of all the filesystems Linux can use, its the worst choice for anything that could crash, because I find it extremely likely to corrupt its logging if it crashes in the middle of a write and therefore have to go through an extended fsck, which under systemd, has less of a chance of being successful because systemd's fsck binary is utter rubbish. I've used XFS on IRIX and Linux for years, and its much more forgiving. I'll take a performance hit to safeguard my data. I also am a huge fan of JFS on Linux and VxFS as well. Both perform very well and don't have the BS problems that ext4 does.
It's been around for years; it's hardly "new". And I've had problems on literally all machines I've used it on, from segfaults to weird stuff like this. The developer's response has either been non-existent or a disinterested shrug like the above link.
So you should not be a fan of systemd then, because the developers have an attitude problem that extends all the way into any distros that use systemd and have a problem with it.
I'm gonna quote an old post of mine to drive home a point about CentOS, which is basically a free RHEL:
TeamBlackFox said:
I'm not anti-Linux, but I'm all for giving them the middle finger for not supporting BSD efforts and making our projects they depend upon harder to port and such to make them feel what we feel like everyday. See, I dislike Linux, regardless of GNU ideology, because the kernel releases tend to be, "Ooh new feature thats cool? Lets put it in, what could POSSIBLY go wrong???"
They're impulsive and reckless and thats how the current Linux ecosystem is mostly RedHat dominated with them calling the shots because RedHat doesn't care about stability in the latest kernels, because its RHEL is always several kernel version behind, it uses the Linux kernel as a testbed along with Fedora for future features it developed, and that's how we got this mess what with systemd, udev etc. I think providing any tolerance to that type of project is tantamount to being content with grabbing their table scraps and continuing to be behind the curve - we're not setting trends, we're following them.
Examples of this folly include the recent attitude problem Kay Sievers got with Torvalds and a bug reporter on the systemd bugtracker, which resulted in a Torvalds chewing him out and revoking his commit privileges. RedHat doesn't care about stability as long as RHEL itself is left out of the mix.
And CentOS 7 has so many approaches I can best describe as Rube Goldberg or Salvador Dali esque where you have to be a brain surgeon to figure out how the hell to fix a problem with a core part of the OS, like systemd.