Closed CentOS vs FreeBSD

Status
Not open for further replies.
I really hate to start flame wars. I love both systems. But I am rather new to FreeBSD and it is now time to make a decision on what software I run on my first web site. I am planning on running it on my home internet for a while until I can get enough funds for a VPS.

What are the major pros/cons to running FreeBSD over CentOS on my first server?
 
My 2 cents:
1) You do not really provide enough information for someone to give you a well reasoned answer
2) If you are interested in learning unix basics you will learn more with FreeBSD and will find it easier to tweak if you have specific needs.
3) If you are trying to get experience that could translate into a job Centos/RHEL I believe to be more widely used - you can verify by looking for jobs that want FreeBSD vs RHEL experience.
4) If you are more concerned about being able to implement a particular feature both will likely work
5) If time is a consideration - security updates for Centos/RHEL are easier
6) If your hardware is older and slow in my opinion FreeBSD is faster. The default install for Centos starts a greater number of services (avahi network discovery daemons for example).

There are many more considerations that others can add. Given that both can be freely downloaded, unless you are strapped for time or not interested in learning the best advice IMHO would be to try both.
 
jwele said:
I really hate to start flame wars. I love both systems. But I am rather new to FreeBSD and it is now time to make a decision on what software I run on my first web site. I am planning on running it on my home internet for a while until I can get enough funds for a VPS.

What are the major pros/cons to running FreeBSD over CentOS on my first server?

I never ran centos so I can't tell you the differences. I have run some linux distros but for the most part they are all more desktop oriented (at least in feel) than server oriented. But maybe it's a good server.

My first webserver was with FreeBSD. Just like it's advertised it's stable, secure with a large group of developers and maintainers who also use it personally and professionally. Also as it advertises it's used by some of the world's busiest sites.

Now as the previous poster mentioned. Until you can identify the specifics of what you plan on accomplishing with your web site. You really won't get an answer which will be any different than going to a microsoft forum and asking which is better oracle or microsoft sql server.
 
I just want the highlights of each. What features stand out on FreeBSD servers that are unique. For instance ZFS Snapshots and Jails for example. I want to host a web site using all the AMP technologies and am trying to find out what features stand out in either of these operating systems.
 
If future use is VPS/KVM/XEN then IMHO FreeBSD will be better.
Security - check history of vulnerabilities for Linux and FreeBSD.
Jails.
Much better memory footprint while working.
FreeBSD will happily work with 128Mb RAM(lighttpd/nginx + sshd +ntpd + OS would take ~ 15Mb) while CentOS will refuse installation even with 256Mb from a standard "minimal CD".
If you talking about VPS in a future you should take it in account. You can find a lot of cheap deals with 128Mb (around $30-35 per year) but than more memory you needed then more expensive it became. (Im not sure if you really need ZFS on VPS since anyway you will work on virtualized HDD, plus ZFS is very memory hungry)
Disk space that would be taken by OS only:
FreeBSD takes ~ 450Mb, but if you clean up /boot/kernel you can divide this number in a half.
CentOS from other side even customly stripped will take around 900Mb.
 
FreeBSD runs many Linux applications faster than Linux can. Sorry, my reference is The FreeBSD Operating System book but there are other online references.
 
With FreeBSD for your AMP:

  • You will have better control on the software you are installing because the ports system lets you specify exactly what options you need to compile.
  • You will get better performance on lower spec systems.
With CentOS for your LAMP

  • You will get faster install and update times using yum.
  • You might have to cross your fingers after an upgrade
 
Given that I administer CentOS at work (for E-Commerce company) and FreeBSD at home (For personal website, email server), I think I can chime in with a bit...

FreeBSD:
*Lighter system (less resource hungry) allowing for lower end PC units to be used as web servers vs Linux based distributions. CentOS by default installs a lot of unneeded dependencies which require initial higher memory usage.

*Jails systems is great for an AMP stack that you want to keep secure and partitioned. Example, use ezjail to configure jails for your MySQL service: a jail for Apache, and a jail for PHP (all communicating with each other via IP). Closes you can get to jails in CentOS is chroot (which is a PITA to configure manually, especially for PHP or MySQL) or Debian's vserver (can't recall if its supported on CentOS).

*Easier update of installed ports (Apache, MySQL, etc) as the dependency matching, IMO, are much better in FreeBSD.

*Since FreeBSD uses the upstream code for applications with minimal patching, much easier to maintain your system up-to-date with upstream versions. CentOS has a really slow adoption for patched software unless there it is a security patch.

*Easy upgrade of OS without ever having to re-install the system. Try that with CentOS. Even going from version 5.0 to 5.5 sometimes gives me issues.

*Single place to find configurations, /etc or /usr/local/etc. Not much to it.

*You get to learn more about the inner workings of FreeBSD which I am sure you will fall in love with quickly. I know I did.

*update*
*Good documentation on setting up your system.

CentOS:
* RPM based so not much compiling by hand
* If your more familiar with it, then easier to administer vs FreeBSD

In all, if I could convert work to using FreeBSD systems vs CentOS, I would. But then I have to train the other sysadmins on FreeBSD.
 
Well, with CentOS the installation and setup will probably be faster, it's a very popular platform so there will be lots of people on forums and such who can help you if you get stuck. In my experience CentOS has slightly better hardware support than FreeBSD. Performance wise, in my experience, both platforms are fairly similar, though I think FreeBSD is typically lighter/faster.

With FreeBSD if you're going to set up an AMP server you have to compile PHP support from ports, which takes a long time and future package upgrades take more time. On CentOS it's a really quick "yum install package" procedure with a regular "yum update" command to keep things up to speed with security updates. With regards to third-party software, cPanel is designed to work with Red Hat/CentOS, but not other distributions and not FreeBSD. With regards to support I believe CentOS gets around 7-10 years of support. I think FreeBSD is a little less than that, but not by a significant amount.

FreeBSD has really nice security features, like jails, which give it a bit of an advantage, but it tends to lag a bit with software updates.

Really, I think CentOS wins in most categories though both are good platforms. Personally, I think you should go with whichever one you know best and spend some spare time learning the other so when this choice comes up again you're better prepared to make a comparison.
 
There are numerous web sites that will walk you through setting up a *AMP server and again it depends on your goals. A couple of comments:
ZFS Snapshots
Not only memory intensive but tends to be more valuable when dealing with a large amount of data. From a hardware standpoint I would want a mobo that supports and is populated with ECC memory. ECC memory costs about 2x more than non-ECC memory and IMHO would be worth it if your mysql data is valuable/difficult to replace.

I was unable to find find the article but the Distrowatch web site has been run on Debian and FreeBSD. The webmaster described that the nightly page hit Talley for a particular distro ran twice as fast in FreeBSD compared to Debian. On the downside, when he had to redo his site secondary to a hardware failure it took alot less time to do it in Debian.

If you do a search using AMP and the Operating system name (for example AMP + OpenBSD) you should get multiple hits and hopefully one will be pretty close to what your goal is. If you want something like a jail (chroot) and are not going to need the overhead/optimal hardware for ZFS this OpenBSD site describes a quick, binary package based setup
 
I haven't run CentOS, but I do have a Redhat box at work.

2c: FreeBSD will not change the way things are done. Linux sometimes changes how to do things from release to release in drastic ways. FreeBSD does not.
 
NewGuy said:
With FreeBSD if you're going to set up an AMP server you have to compile PHP support from ports, which takes a long time and future package upgrades take more time.

VPS (that was mentioned by the thread author) usually provide VERY limited hard drive space, so we don't need /usr/ports/* at all in such environment to be able to run ports and of course we don't need to compile it on VPS, risking that VPS will be throttled on such operations.

pkg_add -r php53 will do the same that yum do and it is pretty fast. All upgrading process even with huge ports could take less than 15-20 minutes, - just delete package and reinstall it again or use ports-mgmt/pkg that can upgrade installed packages.

Of course it works if you don't need some special tweaking(well, same could be applied to yum), but it also isn't a case, one can prepare(compile) custom package as he/she wants on development machine/virtualBox and install in on VPS as a package.
 
AlexJ said:
pkg_add -r php53 will do the same that yum do and it is pretty fast. All upgrading process even with huge ports could take less than 15-20 minutes, - just delete package and reinstall it again or use ports-mgmt/pkg that can upgrade installed packages.

It will not install the Apache module.

For servers you want to use ports instead of packages. Even the smallest VPS will give you the little extra space required for that purpose.
 
gkontos said:
It will not install the Apache module.
IMHO it's suicide action to run PHP as an Apache's module on a limited VPS with 128/256Mb of RAM anyway.

gkontos said:
For servers you want to use ports instead of packages.
No, IMHO for servers it would be more effective to prepare prepare custom package on a powerful machine with exact options you'd like and then feed with it servers on VPS.

gkontos said:
Even the smallest VPS will give you the little extra space required for that purpose.

Real live example:
TinyKVM.com, London's datacenter, - smallest KVM is 128RAM,3Gb-HDD.
Space that is taken by OS itself plus needed packages ~ 1Gb
[CMD=""]# cd /usr/ports; du -sm[/CMD]
show 808Mb.

I guess, nobody would sacrifice 1/3 of space to keep ports tree while it possible to save it for primary purpose of VPS.
 
AlexJ said:
IMHO it's suicide action to run PHP as an Apache's module on a limited VPS with 128/256Mb of RAM anyway.

Most of the memory problems will come from the database. In any case 128MB of RAM is a very limiting choice and you will probably want to perform some tuning. A stripped kernel might also be a good idea.

AlexJ said:
No, IMHO for servers it would be more effective to prepare prepare custom package on a powerful machine with exact options you'd like and then feed with it servers on VPS.

From a security prospective yes. But this is not what you originally suggested.

Using pkg_add -r on a RELEASE will try to fetch packages that are most probably out of date.

It is not the same thing with yum like you mentioned before.
 
gkontos said:
Most of the memory problems will come from the database. In any case 128MB of RAM is a very limiting choice and you will probably want to perform some tuning.
Sure !!! mysql-tuning-primer is always our friend :) even on decent computers.
Usually MySQL (actually MariaDB in place of this) can happily work consuming 25Mb of RAM.

As about "very limiting choice" - it is much better choice to compare with sharing hosting, where delay can be up to 30 seconds, until a site return anything.
For multiple distributed DNS's around the globe to resist against DDoS - it is also enough. Well, this VPS hostings help me feel myself as it was a few decades ago too :), when programer counts every byte and wrote efficient algorithms because of limited resources to compare nowadays bloatware monsters :)

gkontos said:
A stripped kernel might also be a good idea.
Ghm... well, it helps to safe 5-7 Mb of RAM, but it isn't economically profitable because of time for kernel tuning and most important it will require rebuild everything on next update instead of just running binary freebsd-update, - much less downtime will be with GENERIC kernel.


gkontos said:
From a security prospective yes. But this is not what you originally suggested.
Not only security, but mostly customization. I didn't advise it before because mostly it isn't necessary, but in cases when it needed - it isn't a problem.

gkontos said:
Using pkg_add -r on a RELEASE will try to fetch packages that are most probably out of date.

It is not the same thing with yum like you mentioned before.

I hate to say that (really), but you are wrong, this:

Code:
#!/bin/sh

export PACKAGESITE=ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9-stable/Latest/
pkg_add -vr "${1}"

will grab fresh packages.

RELEASE's packages are always freezes on a moment when particular FreeBSD RELEASE is issued for some reason, but it's curable as you can see.
 
@AlexJ,

  • pkg_add(1)() needs to be adjusted in order to fetch recent packages.
  • Comparing pkg_add(1)() with yum is like comparing Apples vs Oranges.
  • If you want to suggest a packet management solution and compare it with yum then please have a look at pkgng.
  • If you have a system with 128MB of RAM then you will see that struggling for an additional 5-7 does not sound bad.
Please don't take this personal.
 
gkontos said:
@AlexJ,

pkg_add(1)() needs to be adjusted in order to fetch recent packages.

What's that? Did you tried script provided?
What else need to be adjusted in the script that I provided to be able to get fresh packages?
The only adjustment that one need, - it is set just one environment variable that point to the STABLE tree instead of default RELEASE repository! Try it... _before_ advising RTFM ;)

gkontos said:
Comparing pkg_add(1)() with yum is like comparing Apples vs Oranges.
yum, urpmi, rpm, apt-get, pkgadd, pkg_add, pkgng - are all packet managers.
They may be are Apples and Oranges but all of them are fruits and do the same thing - install in a system precompiled/binary programs.

gkontos said:
If you want to suggest a packet management solution and compare it with yum then please have a look at pkgng.
It is far away from production use yet ...IMHO. When it wouldn't require ZFS only to build packages, will be compatible with [CMD=""]# make package[/CMD], will be able to manage dependencies, will be part of the base system and will have up to dated package repositories then one can suggest to use it as replacement for pkg_add(1)().

gkontos said:
If you have a system with 128MB of RAM then you will see that struggling for an additional 5-7 does not sound bad.

If downtime for a few hours while everything recompiling after each upgrade isn't an issue then one can do that, but until a system doesn't use 'swap' there no reason to mess up with kernel tuning on VPS, especially if there's a bunch of such small guys that happily dancing under parallel/clusterit and/or sysutils/tentakel control.

gkontos said:
Please don't take this personal.
??? I work in an industry that require everyday learning, so - no offense, but thanks for conversation. Sometimes gab fresh up an old knowledge and bring up new ideas that couldn't be born in a tough working environment.
 
AlexJ said:
If downtime for a few hours while everything recompiling after each upgrade isn't an issue then one can do that
Do all the building on a different machine, your downtime will be reduced to minutes.

NB I've seen several folks talk about packet managers. They're package managers. Packet and package have similar meanings but a bundle of software is usually called a package. Packets usually refer to networking, as in network packets.
 
SirDice said:
Do all the building on a different machine, your downtime will be reduced to minutes.

It could be done, but spending time just to satisfy own ego will not be granted. Until a system doesn't not use "swap", I think that binary update will be much better solution.

SirDice said:
NB I've seen several folks talk about packet managers. They're package managers. Packet and package have similar meanings but a bundle of software is usually called a package. Packets usually refer to networking, as in network packets.
You're right, thanks for the correction !
 
AlexJ said:
What's that? Did you tried script provided?
What else need to be adjusted in the script that I provided to be able to get fresh packages?
The only adjustment that one need, - it is set just one environment variable that point to the STABLE tree instead of default RELEASE repository! Try it... _before_ advising RTFM ;)

You suggested this.

This is wrong!

That is what I am trying to tell you. Your script is also wrong because it will work only for an I386 environment.

So, yes please RTMF!!!

AlexJ said:
yum, urpmi, rpm, apt-get, pkgadd, pkg_add, pkgng - are all packet managers.
They may be are Apples and Oranges but all of them are fruits and do the same thing - install in a system precompiled/binary programs.

Right, with your logic, pkg_add, yum, aptitude, etc. are all the same therefore no need for a comparison.

Linux, FreeBSD, and Solaris are all based on Unix. With your logic they are the same.

Unix and Windows are Operating Systems, fruits again.

AlexJ said:
It is far away from production use yet ...IMHO. When it wouldn't require ZFS only to build packages, will be compatible with [CMD=""]# make package[/CMD], will be able to manage dependencies, will be part of the base system and will have up to dated package repositories then one can suggest to use it as replacement for pkg_add(1)().

I hate to break it to you but pkgng and ZFS are irrelevant with each other. I would suggest the relevance between Apples and Oranges but I am afraid that you will misunderstand it again.
 
gkontos said:
You suggested this.

I suggest this because of this
With FreeBSD if you're going to set up an AMP server you have to compile PHP support from ports, which takes a long time and future package upgrades take more time.
The whole point that I was mentioned, if you still didn't get it, - that FreeBSD has a package manager(s) that run by the same principle as CentOS's yum, - THAT IS IT.
Not necessarily to compare difference between two package managers, they do the same job - install compiled software and it is faster than compilation from port, so no need -
to compile PHP support from ports, which takes a long time and future package upgrades take more time.
because both of them FreeBSD's pkg_add(1)() and yum are package managers.
Period.
CentOS isn't faster because it has its yum - package manager, since FreeBSD also has pkg_add(1)() that do the same job.
That is the point of my answer to PARTICULAR sentence.


gkontos said:
This is wrong!

You can make this statement even bolder, but my script continue working as expected, regardless your personal opinion.


gkontos said:
Your script is also wrong because it will work only for an I386 environment.

I can't see any questions about amd64/i386/ia64 in this thread, where it come from?

Ok, if you still can't figure out how it's works, visit please ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest and you will find that you can grab FRESH packages for amd64 too, in the same way as it works for i386 ;)
Clue: change the URL's path in the script above.

gkontos said:
So, yes please RTMF!!!

[CMD=""]# echo 'So, yes please RTMF!!!' | AlexJ > gkontos[/CMD]


gkontos said:
Unix and Windows are Operating Systems, fruits again.

Aren't they both - Operating systems ? :)
I'll try one more last time: compilation process from ports and installation by package manager - incomparable speed, package manager vs package manager - comparable.



gkontos said:
I hate to break it to you but pkgng and ZFS are irrelevant with each other.

I have a question for you then, - show me please a way, how to prepare package for ports-mgmt/pkg on a computer that doesn't use ZFS for some reason.
Strange, but author of ports-mgmt/pkg says here http://blog.etoilebsd.net/post/Home_made_pkgng_repo :

Roman wrote on 17/03/2012 :
So there's no way to use it without zfs?

bapt wrote on 08/04/2012 :
No there is no way without zfs

As you can see pkgng and ZFS are kind of relevant.
If there something changed for the last two monthes, let us know please, I'll be greatly appreciate.
 
Bapt's statement is only about ports-mgmt/poudriere, it can't be used without ZFS. You can however build PKGNG packages manually without ZFS or use ports-mgmt/tinderbox that doesn't need ZFS either.

Besides the ZFS requirement isn't so much unless you're on i386. On amd64 you can take any scrap disk and turn it into a ZFS pool.
 
kpa said:
Bapt's statement is only about ports-mgmt/poudriere, it can't be used without ZFS.
Yes, that's the only tool to prepare own packages for pkgng.

kpa said:
You can however build PKGNG packages manually without ZFS or use ports-mgmt/tinderbox that doesn't need ZFS either.

ports-mgmt/tinderbox preparing packages in old/classic format, which is different from ports-mgmt/pkg : http://wiki.freebsd.org/pkgng#Repository_format

There is workaround - prepare packages in a legacy way and then run

[CMD=""]# pkg repo[/CMD]

to convert to the new format, but it's kinda PITA...

AFAIK, the only way to prepare packages for the new format it is - ports-mgmt/poudriere. Not a big deal for a company or someone who can use separate machines, but if it's single home/customer/whatever computer - they are forced to use ZFS or prepare some script-spike that will convert packages.
 
Status
Not open for further replies.
Back
Top