Closed CentOS vs FreeBSD

Status
Not open for further replies.
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.

Two years is relatively new for something critical like pkgng. Although it is a bug, there are ways to get around it until a solution is provided. Hardly a reason to do a knee jerk switch to something else, given all other benefits of FreeBSD. But hey, it's your choice.
 
Carpetsmoker, it is really relatively new compared to Linux package managers. Of course that does not justify big errors like the one you described. But don't you hate it that yum also updates the kernel too?
Perhaps, I did something wrong, but for me yum did another really annoying thing that never ever happened to me with pkgng and/or portmaster. I installed a web application on a RHEL6 server of a customer, and that required some adaptions of the httpd.conf and of two files in the extra directory of Apache 2.2. Three months later the customer updated Apache using yum and that update reset all the custom settings to default, and nothing worked anymore. When updating something from the ports by either way, the respective FreeBSD tool never did completely vanish out my settings.
 
Perhaps, I did something wrong, but for me yum did another really annoying thing that never ever happened to me with pkgng and/or portmaster. I installed a web application on a RHEL6 server of a customer, and that required some adaptions of the httpd.conf and of two files in the extra directory of Apache 2.2. Three months later the customer updated Apache using yum and that update reset all the custom settings to default, and nothing worked anymore. When updating something from the ports by either way, the respective FreeBSD tool never did completely vanish out my settings.

I know the feeling. On the plus side, it does save the previous file using file.rpmsave. To be honest, I almost had the same thing happen to me during a ports upgrade in FreeBSD. But checking the /ports/UPDATING indicated that this would happen.
In order to avoid these problems I have set up poudriere and all updates are delivered from my repo. Of course, I always check /ports/UPDATING even though I am delivering packages, just to make sure that nothing will break in an upgrade.
 
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???"

7aypHeo.png


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.
 
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.
Personally speaking I would call that a bug. The pkg-lock(8) man page is pretty explicit:
DESCRIPTION
pkg lock is used to lock packages against reinstallation, modification or
deletion. pkg unlock unlocks the named packages. Either variant only
has an effect on currently installed packages. Consequently it is
impossible to block installation of a new package by using this
mechanism, unless such an installation implies updating a locked package.

The impact of locking a package is wider than simply preventing
modifications to the package itself. Any operation implying modification
of the locked package will be blocked. This includes:

• Attempts to reinstall, up- or downgrade or delete the locked package
itself.
• Installation, up- or downgrade of a package where the resultant
package would have a dependency on a different version of the locked
package.
• Deletion, up- or downgrade of any package the locked package depends
upon, either directly or as a consequence of installing or upgrading
some third package.
 
Personally speaking I would call that a bug. The pkg-lock(8) man page is pretty explicit:

I quote from the discussion on his link: "There's no good solution here: pkg(8) cannot find a solution that satisfies all your requirements."

Its not a bug. Its a design choice. Do I think its the best? Hell no, but if you're to change how pkg lock functions so this doesn't happen... how do you expect it to handle deadlock conditions that result from the change. Its certainly not ideal. But its not a bug. Its a design choice the developers made.

At the end of the day I don't really care if someone leaves FreeBSD over such a problem - but I do care if they add quips that don't add to the discussion. Thats non-constructive. I don't like CentOS, but I gave rationale for it that makes sense. Replacing upstart in CentOS 6 or systemd in CentOS 7 will effectively break any packages that depend upon them. I did an experiment with this in Arch, and it worked horribly. No matter what I did - pacman wanted systemd. The ABS provided no clear solution either. And that's not even scratching the surface.
 
This thread is now over 3 years old and has about reached it's sunset. If anyone has anything further they feel is important to add here it can be reopened but as of now I'm closing it to further discussion.
 
Status
Not open for further replies.
Back
Top