As an expert you should be aware that security and reliability is not the same thing. Also, if you look at the full table, the bottom two providers with a lot higher outage than everybody else run FreeBSD. If you calculate an average, FreeBSD will be much worse than the other solutions. Basically you can pretty much get any result you want from this list.

Reliability in strongly connected to Security. If you need to patch, reboot, or manage an intrusion then your reliability goes down. It also means that there is less security maintenance (even though freebsd update process is more obscure).

The table show us that if you want to be the most reliable, you need to choose unix.

Or you can count privilege escalation: 61 bugs in the last 7 years for linux, 3 for freebsd.

Or you can count vulnerabilities, even thought being freebsd smaller, this is a biased comparison.

Or you can do very rough estimation:

Google "Hacked by"+ linux: 2.3 millions results

Google "Hacked by"+ Freebsd: 230.000 results (one fold less!!!)

Anyhow let's put this way: My opinion is that FreeBSD is the most secure, reliable and scalable OS. You think that Linux is more secure than FreeBSD.

The Linux kernel uptime rolls over at 497 days. The system doesn't go down, the uptime is just reset.

Linux, incidentally, has more eyes, so more seen bugs.

I like freebsd, but linux is much better for sysadmins.

+1

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell

i have also build my own little kernel, some time ago. it sucks, true. but it can start and print out a lot of information about the computer. (NO! it not just a custom build linux kernel, its a real os from the bottom).

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell

This thread is pointless, since the 'auditor' handed over database access to somebody through total carelessness so breach would've happened regardless of OS. I bet the auditor had it lying around his gmail account or unencrypted on the desktop in a file called 'STEALTHIS.TXT'

This thread is pointless, since the 'auditor' handed over database access to somebody through total carelessness so breach would've happened regardless of OS. I bet the auditor had it lying around his gmail account or unencrypted on the desktop in a file called 'STEALTHIS.TXT'

1) Use the right software. IIS is a big no-no Also Linux should frowned upon. Unix is the way to go.

I stopped reading right here.

I don't know who you are, but you know nothing about security.

I loled a lot on this one and I completely agree. Even if I prefer nginx or apache to run software and get an extra level of security you can also secure an IIS very easily, and this without knowing a lot about computer security. Look how much flaw from new nginx and apache have been reported and look how much flaw on IIS have been reported (securityfocus) you'll see that what you say is completely out of bound...

Also php / perl / etc can be attacked if badly codded, daemon running on linux can easyly be attacked too, so this is complete no-sense.

Not only freebsd has less vulnerabilities, but they are also less serious (check exploit or data execution)

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

But if you know what to do and need maximum reliability and security, without going Itanium, then BSD is a very good choice.

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

Not only freebsd has less vulnerabilities, but they are also less serious (check exploit or data execution)

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

I'd agree that OpenBSD has security as an imperative for it's dev team and while ASLR isn't the be-all of security. I would contend that it does show a team taking a proactive approach to security rather than simply reactive patching. As far as I can tell even FreeBSD 9 doesn't have it committed to the roadmap (it was suggested years ago though).

I'm rather good with Linux. If you're having problems with your mining rig I'll help you out remotely for 0.05. You can also propose a flat-rate for some particular task. PM me for details.

Okay much improved (B+), but here are some things to remember before you take your exam.

Really? Perhaps you can explain to me what you think he's trying to do here.

To me, even if "reliability" (as defined by Netcraft) was correlated with "security" (whatever we mean by that). The kind of analysis you'd want to do here is a simple comparison of categoricals. So ANOVA is the tool of choice. Looking at the Netcraft data linked to early on it's pretty clear that things like failed requests, DNS latency, connect latency and first byte latency have little to do with uptime. Sure you could make up a way they could be related to a security event (like say connect time or failed requests are related to DoS attacks but you wouldn't be able to differentiate between that and every other event). What's left after that? Outage - which might be related to a security event requiring a reboot but there almost everyone is at zero. Except for two BSD sysetms and one linux system.

So I don't even have to boot up R to tell you that the correlation coefficient here is going to be next to nothing (and probably bad for BSD).

From where I stand this is an "shows promise" mark and where I grew up that's a C. ;-)

Jono

Edit: So drudging back through his morass of poor English. It sounds like all this nonsense is actually about counting "serious" flaws per system over some time period? Exactly how does *that* become a security metric? Not to mention that using the "flaws" metric is very likely not going to follow the kind of probability density function one is expecting.

I'd like to take a moment to say that math isn't magic. The numbers you put in need to be meaningful and the operations you perform on them need to say something...*shakes head*He might as well have taken the square root of spiders and integrated it by batman...

I'm rather good with Linux. If you're having problems with your mining rig I'll help you out remotely for 0.05. You can also propose a flat-rate for some particular task. PM me for details.

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

But if you know what to do and need maximum reliability and security, without going Itanium, then BSD is a very good choice.

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

OMFG! you are now comparing a chip to a operation system.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

Because the latency for DNS, first byte and connect were lower. Exactly where is the data that those strongly correlate to security events? Nowhere.For all you know this has nothing at all to do with the OS. Cluster size, hardware config, network organization (such as the composition and placement of edge devices). Heck we don't even know that all of these systems are under the same load. All effect these kinds of statistics and considering that we are talking about averages without any idea as to their VARIANCE the placement might well be random.

Guess the mouse dropped out of stats?

I'm rather good with Linux. If you're having problems with your mining rig I'll help you out remotely for 0.05. You can also propose a flat-rate for some particular task. PM me for details.

I'm sure you know that source code doesn't depends on archs, as archs are handled by compilers.

LOL *rolls on floor laughing*. That's a good one! You do realise that we're talking about kernels here, right? Compilers don't know about page tables, or context switching, or power management, or interrupts (on most platforms), or any of a number of important architecture-specific things that kernels need to manage. The code to handle this is in the architecture-dependant arch/ directories of the Linux kernel. (I believe the BSDs handle the seperation between architecture-independant and architecture-specific code differently. Never used them though.)

I ported android to the vending machines. And if you have a barely knowledge of how android is structured, you would know how complex is this task. Obviusly I was not alone.

Android is not Linux. Developing Android drivers and porting it to a new hardware platform is not that similar to developing Linux drivers and porting that to a new platform. Android's based on the Linux kernel, but it has enough fundamental changes to the driver APIs that they're not really compatible.