Closed CentOS vs FreeBSD

Status
Not open for further replies.
AlexJ,

  • pkgng is a full package manager irrelevant to ZFS.
  • pkg_add(1)() a utility for installing software packages (reading the man pages can help you), irrelevant from yum.
It appears that your scripting abilities are very close to distinguishing the differences in fruits.

I have not yet decided if you are totally brain dead or just missing some brain cells.

In the mean time I will stop replying to your flames as this is getting really off topic. You have your opinion and I am sure that you know what they say about them...
 
I have used both. I am running Centos right now.

The main advantage to Centos over FreeBSD is that Centos requires less work to get it going. All the components in Centos are also in FreeBSD, while FreeBSD has many more software technologies, especially kernel wise. For example, NetworkManager is integrated throughout CentOS, versus FreeBSD where you either have to work the scripts, or install the dependencies by hand so that the desktop environments (GNOME,KDE,XFCE, etc) can work your wireless card automatically.

So one work, CentOS has more automation.
 
lockfile said:
so that the desktop environments (GNOME,KDE,XFCE, etc) can work your wireless card automatically.
Do you really think that "desktop environments" is important on VPS where each byte counted against your wallet?
 
With FreeBSD for your AMP:
  • You might have to cross your fingers after an upgrade
THIS! I installed a new CentOS 7 on my VPS, and after upgrading, it changed init.d to systemd and the whole system died after a reboot. That's why I'm afraid of going anywhere near CentOS. The packages are also extremely outdated, and you should download the source codes and compile them manually most of the times. With FreeBSD, you have both worlds, binary packages for when you have no time compiling programs, source packages for when you need machine-specific optimizations and extra configuration during compilation. I've also heard that FreeBSD's TCP stack is faster than Linux (Not quite sure, just heard).
 
THIS! I installed a new CentOS 7 on my VPS, and after upgrading, it changed init.d to systemd and the whole system died after a reboot. That's why I'm afraid of going anywhere near CentOS. The packages are also extremely outdated, and you should download the source codes and compile them manually most of the times. With FreeBSD, you have both worlds, binary packages for when you have no time compiling programs, source packages for when you need machine-specific optimizations and extra configuration during compilation. I've also heard that FreeBSD's TCP stack is faster than Linux (Not quite sure, just heard).

Why are you resurecting tree year old thread to spread pure FUD? In our Lab we use Springdale Linux (Princeton University clone of RedHat), FreeBSD and OpenBSD. We have a strong preference for Springdale over other free clones of RedHat but we are not strangers to CentOS. We have moved past systemd craze and as much as we don't like it, for now it has not being show stopper for us to migrate to 7.2. from 6.7. EPEL/Springdael packages are not outdated! That is Debian/Ubuntu party line. RHEL clones are conservative but very professionally maintained. A single RPM on RHEL might contain hundreds sometimes close to thousand of that Debian "packages". RHEL feels much more UNIX-u than Debian and Ubuntu in particular. We are using them for scientific computing. While there is no advantage in using RHEL over FreeBSD for standard things like Python, R, gsl, ATLAS, BLAS, LAPACK the lack of proprietary scientific software (MATLAB, Mathematica, MAPLE disqualifies FreeBSD as viable platform for scientific computing). Another big + for RHEL is existence of ROCKS cluster distribution and proprietary support of GPUs, Hadoop, various file systems.

We like FreeBSD for ZFS and light weight virtulization with Jails. However RHEL 7.2 is rock solid with LSI high end hardware RAID cards. We have made extensive use of KVM for various in house application. KVM was rock solid for us. In the terms of complexity both systems FreeBSD and RHEL feel about the same. We use OpenBSD for basic network services Firewall, LDAP, DNS, load-balancing, proxy etc.

FreeBSD vs RHEL will come down to use pattern and the competence of the personal. I am having hard time to see that large consumers of RHEL will be migrating to FreeBSD and vise verse.
 
Very old thread. In regards to Oko's response , we stick to CentOS 6.X due to systemd.
Me too. It's also part of the reason why I'm migrating our severs to FreeBSD, I don't need to learn a different way to do what already works.

I follow the traffic-control thread on Linux (LARTC) closely as we have some complicated QoS/routing requirements. Multiple times this year folk have come in with "this feature/example doesn't work as advertised". In one case, a code author wrote back and said "I had a similar problem and submitted a testcase and patch. I just ran my original test against the current kernel and it doesn't work" (I'm paraphrasing)

That just makes me cringe. When I was engineering a project about 25 years ago, the test suite was largely comprised of cases our users sent in that broke the product. It had to pass all of them, every time, before a new version went out the door.

Having said that, RH/CentOS is well engineered to a large degree. That's one of the reasons why the packages and kernel are older, because (1) they don't just throw in the newest shiny thing, (2) they do apply security patches to them, (3) they exclude things known to cause problems. Yes it's a pain half the time, but I found confidence there. However with systemd being introduced in 7 (yes I know it's optional ... right now), who knows. Too risky for me.
 
I don't believe systemd is optional in RHEL/CentOS-7.x.
You are absolutely correct, it is not.
During the past 4 months we have integrated some of the top open source software for our email collaboration platform that we sell as a service. We have sticked with CentOS 6.X because we discovered that systemd consumes more resources. I am not mentioning the platform here because I don't want to be seen as an effort to advertise a product. However, one of the competitive advantages is that it requires very few resources to run. Making it very cost efficient in cloud environments. CentOS 7 required 30% more ram in our tests.
Why not use FreeBSD? There was a discussion about that, and I am the only one in the team feeling comfortable with FreeBSD. We are probably going to make a parallel set up using FreeBSD very soon hopefully.
 
You are absolutely correct, it is not.
We have sticked with CentOS 6.X because we discovered that systemd consumes more resources.
+1
Old tools are still available as RPMs but it is obvious that they will be soon diapering. We have to run post installation script to disable Firewalld and similar crap and install several RPMs just to get to use ifconfig and few other basic commands. On another hand software on 7.2 is noticeably faster if for no other reason but due to the switch of the default GCC to 4.8.2 much older version. For scientific computing 7.2 is OK even though ROCKS 6.2 is based of CentOS 6.7 so as you can see people are not quite jumping on 7 branch even 2 years after initial release.

For basic network services/servers we just use OpenBSD. It is infinitely simpler and resource frugal. With heavy SMP optimization coming in 5.9 and WAPBL on the way into OpenBSD kernel there is just no compassion between the OpenBSD and Linux. Linux feels like tractor trailer while OpenBSD feels like the latest Toyota 4 wheel runner.

For the file server and light weight virtualization ZFS and Jails are just light years ahead of Linux XFS, containers and Docker non-sense.
 
I've been using CentOS/RHEL for quite some time (started running it on production gear since version 5), and for me it has always just worked. Let me discuss some points (which may or may not apply to linux distro's in general) about CentOS:

Lifecycle? I especially like the long support each release enjoys, each major release has a support lifecycle of 10 years. This is much longer than FreeBSD's. For me, CentOS is pretty much fire & forget.

The notorious systemd (CentOS 7)? Yes you might find it be a cludge. I don't really like it architecturally. Like everything, it has its pros and cons. But do I really care? No. It does its job and I haven't had problems with it. I had to learn some new commands and configuration file locations, but that's it. It hasn't prevented me from getting the job done.

Lack of good documentation? This has always been the main argument of BSD's over Linux. I feel this is not true. Take a look at the RHEL documentation: https://access.redhat.com/documentation/en/red-hat-enterprise-linux/. Yes it's different from the FreeBSD handbook but hey - it's a different operating system! As far as manpages go, I've never had any problems with those either. One might find FreeBSD's manpages to be written more friendly, but that's highly personal. For me, everything I needed has always been there.

Resource footprint? On the systems I run, they are dimensioned in such a way that whatever the base operating system uses is irrelevant. The applications take the gist of it. But, a default install of CentOS does come with more software installed and running by default. But one's free to uninstall/disable as he/she pleases. Is this a bad thing? I'm sure somewhere in the past someone argued that including and running an email server by default "takes up too much resources, is bloat, other OS doesn't have it so they're more resource friendly, ...".

Speed/performance? That tractor trailer feeling Oko talks about, I've never experienced that myself. Based off of performance alone ("blind testing") I wouldn't be able to tell the difference between CentOS and FreeBSD. If you were to create a FreeBSD and a CentOS system and made the CLI/config files/etc... identical, I would be none the wiser.

Software? It has a carefully managed software set that is very timely updated with security fixes.

Filesystem? I've used whatever CentOS has defaulted to. It used to be ext3, I used ext4 (which I still do for my home stuff) and now CentOS 7 defaults to XFS. I haven't had much experience with it. But in any case, I've never lost any data.

I've mostly been talking about CentOS in a positive way, but as with everything it has its deficiencies:

Filesystem snapshots? You have to use LVM. Freeze the filesystem, create a snapshot, unfreeze the filesystem. It requires more steps than UFS and ZFS, and I actually have no idea how well this works with ext4 as there doesn't seem to be a command line tool to freeze an ext4 filesystem. In fact, as far as I know, there's no way to atomically snapshot an ext4 FS, which is why I never even tried snapshotting it. In any case, for other filesystems, there's no consistent way to do it, you have to write your own scripts to do the freezing/LVM part/unfreezing.

Containers? Horrible. I haven't even started trying to use containers. FreeBSD jails = clear win for BSD.

Installer? The new CentOS 7 installer is definitely a cludge. It's un-intuitive and especially arranging your filesystems is a real pain.

To conclude; I go by Scotty's saying "How many times do I have to tell you, the right tool for the right job!" (which is the *only* good part in Star Trek V). If you feel comfortable with CentOS and it fulfills the business needs, then by all means use CentOS. You come across a scenario where FreeBSD is a perfect fit, then go and use FreeBSD. OpenBSD fits the bill? Then use OpenBSD. Wanna keep everything consistent? Then use whatever the business was already using.
 
Resource footprint? On the systems I run, they are dimensioned in such a way that whatever the base operating system uses is irrelevant. The applications take the gist of it. But, a default install of CentOS does come with more software installed and running by default. But one's free to uninstall/disable as he/she pleases. Is this a bad thing? I'm sure somewhere in the past someone argued that including and running an email server by default "takes up too much resources, is bloat, other OS doesn't have it so they're more resource friendly, ...".

My experience comes from minimum installation on both CentOS 6 & 7. I usually never had to uninstall software. During lab tests, we saw that CentOS 7 did not behave the same as 6 with 2 Virtual Cores and 2 GB of RAM. We run mainly postfix and dovecot.

We recently decided to switch to FreeBSD because of 3 factors.
  • Support for the CentOS 6.X will eventually end in 2020.
  • In Linux we needed to reboot our systems monthly because of new kernels.
  • It turns out that memory management is even better in FreeBSD (lab testing).
Aside from all the above, the fact that in FreeBSD, the software update part is different than the OS update part, separates two very important parts of maintenance. Therefore, by using Poudriere we can easily maintain our software updates on all of our instances without having to update OS specific files.
 
I always get nervous when the selinux policy gets updated, then I have to figure out what the changes were, if they effect me and what to do. ISC-Bind got broke once because I missed that. With FreeBSD there's UPDATING, which lands on the server and is simple to read through down to the last date you updated from.

Software? It has a carefully managed software set that is very timely updated with security fixes.
While that is true, the software itself is often old (case in point squid 3.1 on CentOS 6), often requiring one to compile from source, which seems to have no structured 'ports like system', that I can easily update and recompile.
 
I always get nervous when the selinux policy gets updated, then I have to figure out what the changes were, if they effect me and what to do. ISC-Bind got broke once because I missed that. With FreeBSD there's UPDATING, which lands on the server and is simple to read through down to the last date you updated from.

And with FreeBSD you get a package tool that just updates postgresql to an incompatible version (breaking your server) without any warning, even though you explicitly told it not to.

This is, of course, not a bug.

This is when I stopped using all FreeBSD after 10 years and switched to CentOS.
 
CentOS v. FreeBSD, I've used both. FreeBSD since 9.0, CentOS since 6.3. I no longer use CentOS since version 7.x was such a colossal disappointment.

As far as Linux goes, CentOS is okay at three things:

It ensures, to a much greater degree, that its packages that you upgrade are not going to break. However, backporting hasn't always been consistent, I had to wait for a month for a bug in PHP to be backported to the version I was using. I also despise yum. Package managers should not be able to uninstall a kernel, the base system should be separate.

It has a stable, well supported kernel version. The downside to this is, that you don't get the latest and greatest features. I like to have a choice between both, personally.

It has a long term support system, only beaten by RHEL and SUSE, which are both rather similar in many respects.

And with FreeBSD you get a package tool that just updates postgresql to an incompatible version (breaking your server) without any warning, even though you explicitly told it not to.

This is, of course, not a bug.

This is when I stopped using all FreeBSD after 10 years and switched to CentOS.

Sounds like you simply didn't watch yourself - thats not a bug, and nothing you can blame on FreeBSD. Careless system management is not the fault of the system - also, were you using pkgng or pkg_tools? The latter was notorious for having a mind of its own.

Not only that, but saying you left FreeBSD for CentOS, you're blantantly shilling for them. If you want to sing praises of CentOS, I suggest you head to their forums.

My beef with CentOS was:

On 6, upstart was constantly fucking up services, leading to flapping. And hell forbid you go in and try to figure it out, because you might as well try getting a horse with brain damage to compile a kernel. In addition, it had a tendency to be less than ideal for configuration, with less than standard file placements, and a weird obsession with having ancient, ancient packages with no higher version available. So they didn't even offer a choice. That is not okay with me. If I want to use Apache 2.4 I shouldn't have to add an outside repo or compile it manually - differentiating with apache2 and apache22 and apache24 is more than easy to do and understandable.

And 7... what a disappointment. They took one step forward and two steps back. First time I tried to install it - systemd gave me an unbootable system - I know this because I reinstalled, chroot'd in and installed upstart and added the necessary scripts from 6 with necessary modifications, and uninstalled systemd. Reboot and BAM it worked. I filed a bug report and they blamed it on my SAS setup, which worked fine on 5.x and 6.x when I tested. Bullshit. Adding XFS as the default is great though as ext4 is an unreliable abortion of a filesystem. Its like an Ferrari - when it works, its fantastically performing, but when it needs to be fixed its needlessly difficult. Screw that.

Thats not to say FreeBSD has problems, but systemd is garbage. I hate it. Its unreliable, buggy, insecure and a monolith where it doesn't need to be, and the whole expand, embrace, extinguish tactic used by the developers is deplorable. Absorbing ConsoleKit, GummiBoot, udev, NetworkManager and such into a single project to force people to use your program is something along the lines of what MS did with DR-DOS for 3.1 and how they slowly got the upper hand of other GUIs for DOS with Windows by mandating it be running and present for this to work. This doesn't have to be this way. And the constant attempts to integrate KDBUS are nothing more than a thinly veiled attempt to quash the distros refusing to run it.
 
TeamBlackFox, I see you have introduced youself to Carpetsmoker. Carpetsmoker set up and moderated Daemonforums.org for years. Prior to FreeBSD setting up their own forum, it was the only forum for BSD users.
 
TeamBlackFox, I see you have introduced youself to Carpetsmoker. Carpetsmoker set up and moderated Daemonforums.org for years. Prior to FreeBSD setting up their own forum, it was the only forum for BSD users.

Are you saying he's being sarcastic? I couldn't verify it from his post.

I didn't mean to offend, but I'm pretty sick of people singing praises of OSes irrelevant to the forum, unless its within an acceptable context to do so. There's a huge difference to saying "I used to use FreeBSD but now I use CentOS" and saying "Well, there's certain things that are handled better by CentOS, such as X, Y and Z" It isn't relevant or constructive to the topic.
 
I'm confused. Obviously it is a bug, and I agree it should have bailed on the whole thing, given that you'd locked something it wanted to remove. You look to be the first to encounter it though, unfortunately.

Also:
20141208:
AFFECTS: users of databases/postgresql??-(server|client)
AUTHOR: marino@FreeBSD.org

PostgreSQL version 9.3 is now the default. To upgrade from a version
lower than 9.3, follow the instructions on the PostgreSQL.org website.
http://www.postgresql.org/docs/9.3/interactive/upgrading.html
Please note that the pg_upgrade program is installed by the
databases/postgresql93-contrib port

When using binary packages, if you only use the client port, you can
issue the following command to follow the default version:

# pkg set -o databases/postgresql92-client:databases/postgresql93-client
Was well documented in said UPDATING.

With CentOS you would probably just be stuck with postgresql92 until you upgraded a major version. However we are talking about two very different philosophy's of package management here: Stick to old versions and stuff new security code into them vs. upgrade to new versions. If you used ArchLinux I suspect you'd experience the same thing as you did with FreeBSD, a sudden shift from 92 to 93 because they are a rolling release.

There's a very good reason I build my own packages -- to avoid exactly this kind of thing because I am in control. Having read that UPDATING, I would have either updated my db's, or I would have overridden the default and put it back to 92 (with the understanding that I may be shooting myself in the foot by doing so), or simply not updated the ports at all, depending on what was important. With CentOS I cannot use an official repo to upgrade Squid from 3.1 at all. My choice is compile my own, without the RH patches for the old squid, or use an unofficial repo (which is just the same thing, except trusting somebody who is not me). IMO that defeats the point in using CentOS in the first place, which is stability in security. I suppose for me the bottom line is CentOS is outdated and secure vs. FreeBSD gives me more freedom and with that more risk. That's not to say either is a better choice, other than what we are comfortable with. Me, I've used CentOS for 10 years and am moving to FreeBSD, for you it's the opposite. It is what it is.
 
Carpetsmoker said:
And with FreeBSD you get a package tool that just updates postgresql to an incompatible version (breaking your server) without any warning, even though you explicitly told it not to.

This is, of course, not a bug.

This is when I stopped using all FreeBSD after 10 years and switched to CentOS.

Sounds like you simply didn't watch yourself - thats not a bug, and nothing you can blame on FreeBSD. Careless system management is not the fault of the system - also, were you using pkgng or pkg_tools? The latter was notorious for having a mind of its own.

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.

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?)

And it was just pkg upgrade. No third-party tools involved.

Not only that, but saying you left FreeBSD for CentOS, you're blantantly shilling for them. If you want to sing praises of CentOS, I suggest you head to their forums.

Haha. I never would have expected the shill gambit here, of all places.

a weird obsession with having ancient, ancient packages with no higher version available. So they didn't even offer a choice. That is not okay with me. If I want to use Apache 2.4 I shouldn't have to add an outside repo or compile it manually - differentiating with apache2 and apache22 and apache24 is more than easy to do and understandable.

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

Adding XFS as the default is great though as ext4 is an unreliable abortion of a filesystem.

Now what's wrong with ext4?
 
Last edited by a moderator:
I find it really hard that one would switch to Linux after 10 years of usage, over package management. Pkgng is still relatively new thing so it isn't going to be perfect from the get-go. After all the shit and brokenness that's happened to Linux over the past decade... ugh. Never. lol
 
I find it really hard that one would switch to Linux after 10 years of usage, over package management. Pkgng is still relatively new thing so it isn't going to be perfect from the get-go. After all the shit and brokenness that's happened to Linux over the past decade... ugh. Never. lol

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.
 
  • Thanks
Reactions: Oko
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?
 
Status
Not open for further replies.
Back
Top