Feelin' safe and snug on Linux while the Windows world burns? Stop that The ransomware problems reported by The Reg over the past few weeks are enough to make you, er, wanna cry. Yet all that's happened is that known issues with Windows machines – desktop and server – have now come to everyone's attention and the bandwidth out of Microsoft's Windows Update servers has likely increased a bit relative …
Perhaps for security reasons people hide the server type tag on a Linux distro as part of PCI compliance so you have no idea what server a website is running on.
Did anyone bother to count the Linux Kernal in Android phones? Something like 432 million smartphones in 2016
Seriously?That doesn't smell right at all.
Check the source, and the data set.
That 12% figure comes from Spiceworks, who provide server monitoring software. Server monitoring software which can only be installed on Windows.
So it's far more likely that what this particular statistic is actually indicating, is that Windows-centric companies use something other than Windows on 12% of their servers.
That number is just as ridiculous as the web statistics companies that claim 90%+ of web servers run Linux. Their methodology is bunk, because SpiceWorks has no way of knowing what servers people who aren't their clients are using. Just like the web statistics companies only detect the OS on edge node servers so if you use a Linux-based web balancer (like almost everyone does regardless of app server) they think you're running Linux.
You're right to be skeptical of statistics like this, because they're in general, totally unreliable. No one has enough data to compile such wide-ranging statistics.
It is a reasonably good bet that the Five Eyes and similar signals intelligence agencies elsewhere have done the research and have a good idea of real usage, as well as the usage among their respective target populations, which might be significantly different. For a number of reasons, however, they won't be publishing anything about it.
I expect that Google and other search portal operators also would be able to report such information pretty accurately.
Thanks for the feedback - you're probably right that Spiceworks is biased in favor of Windows-centric orgs (it does offer Linux monitoring tools, though). It's something we'll keep in mind.
We've tidied up the section on Linux/Windows web server stats: there Unix-ish OSes rule the roost.
C.
"Thanks for the feedback - you're probably right that Spiceworks is biased in favor of Windows-centric orgs "
Forbes says 75% of company Servers run Windows which sounds about right to me, if not a bit low. Clearly the vast majority of most company servers run Windows anyway.
It's BS is why it smells bad http://www.zdnet.com/article/linux-foundation-finds-enterprise-linux-growing-at-windows-expense/
One of the limiting factors on Windows servers outside of Azure & AWS is licensing costs. Nobody with their head screwed on is buying windows servers, they either rent Azure or AWS or are wasting money by not engaging brain.
I think the last time I had a major problem upgrading a CentOS server was with early releases of CentOS 6.0 or 6.1. After that in version (major version) updates drop in quite nicely.
The same can't be said for stuff that is not in the main OS release.
It seems that I have just finished testing a new release of Wordpress when another one is released. The problem is that WP like many other bits of software releases a complete new version. The update process is aimed (quite rightly) at those who use WP via a hosted system and you have to do it via some control panel (or worse). That does not work very well with my hosting my own WP server on an Intel NUC that sits on a shelf in my home office. So I have to manually update it, test it all and then switch over the HTTP server to use it. I just get that done and another PITA bit of work comes along. Rinse an repeat for thousands of other bits of software on systems all over the world and the scale of updating these essential bits of software is a OMG moment.
I'm lucky in that I have a test server (and old EE-Box) that I can use to make sure that the update works AND that I have only one internet facing server to deal with.
In a past job, I had many more to deal with and it was a right PITA. The OS wasn't the issue, it was everything else that caused us a great deal of angst and late nights.
Posting AC as my server gets enough hacking attempts as it is. Added another 500+ IP addys to the firewall only last week.
Yeah, well, if you're using Wordpress it's hardly worth bothering to patch the OS :-)
That's a joke for the humour-impaired. But with more than a grain of truth, as someone who was once responsible for a Wordpress-driven site that got defaced. Turned out that a theme had bundled a plugin which had a vuln in it that had been patched 2+ years earlier, but the theme author hadn't updated the plugin. Of course, when someone found that unpatched plugin in said theme.....
Overall, I wouldn't trust Wordpress with anything important. Especially e-commerce, where you rapidly enter a maze of twisting plugins.
My previous employer used the "never touch a running system" approach to their customers' machines.
They were still distributing new servers and VMs with a 2000 vintage version of SLES on it! Why? Because they didn't want to bother having to update their applications to run on more modern Kernels or system libraries. Security? Pah, it's Linux!
They only switched to a new distro (CentOS), when the hardware would no longer boot the ancient SLES / they couldn't get any RAID controllers with drivers that worked on the ancient SLES.
Same experience here the last time I experienced any kind of issue with upgrades was on the transition from RHEL 6.0 to RHEL 6.1, in my case it was related to a blunder on LVM assuming certain defaults, you could work-around it easily and got fixed in 24h though.
This maybe shocking to Windows people, but usually upgrading a Linux server if you know what you are doing (this is if you're experienced) is completely painless and very, very quick.
The problems in Linux come with commercial software from 3rd parties, some which insist on using abnormally large amounts of shell scripts with lots and lots of assumptions (and no fail check whatsoever), seem to have odd libraries that have strange dependencies, and support personnel who think the Linux shell is a more complicated version of MS-DOS.
That is why some people keep running their RHEL 5.x boxes happily for years and years, it is for fear or screwing these applications.
One way in which people keep these stupid turds running is, they buy new hardware running RHEL 7.x, virtualise the old RHEL 5.x server, stick it in a VM and access it via proxy software running on the physical RHEL 7.x side.
If you think about it, is like a brute-force container. I have seen that done to work around applications that can't be upgraded and depend on old versions of OpenSSL. As the proxy is running on RHEL 7.x you offload the SSL to the RHEL 7.x side and voila, new cypher/protocol support on an old application.
The problems in Linux come with commercial software from 3rd parties, some which insist on using abnormally large amounts of shell scripts with lots and lots of assumptions (and no fail check whatsoever), seem to have odd libraries that have strange dependencies, and support personnel who think the Linux shell is a more complicated version of MS-DOS.
Might those products be made by Windows programmers dabbling in reproducing their mistaken ways in a brand new environment ?
Yes, it's the problem with Linux - you get into troubles whenever you install anything useful on it.
Linux relies too much on the "local compilation" model and availability of source code. Just, not all companies are willingly to give it away, and shut down business immediately after.
It's worsened by distro like Debian that usually just have last century code.
Because these issues are magnified by desktop applications, you get the one digit percentage of Linux desktop systems.
"Linux relies too much on the "local compilation" model and availability of source code."
*groan*
no. commercial packages can easily be distributed either with local copies of all shared libs, or by staticallly linking everything [avoiding the problem], or by compiling separately for different distros if shared libs MUST be used for some reason.
I think Oracle mastered this kind of thing a long time ago, as one example.
/me runs into the 'Linux Binary Compatibility' thing on occasion, being on FreeBSD. Usually one of the 'CentOS' compatibility ports gets it done.
I think that when it comes to patching servers Debian has the best strategy. They backport security fixes so that holes get closed without affecting any of the functionality of the software in question.
This provides the smallest chance for problems. Because of this, I know companies who have auto-update enabled for their production servers running Debian.
So do I, and they were impacted by the recent...I want to say dovecot/postfix problem on Debian that affected their entire platforms ability to send emails.
That said, that's only the second time they've had any problem with that process in three years that I am aware of - every other security update they've run has gone through without a glitch.
No update process is entirely without risk, which is why so many orgs have patch paranoia - god knows, I work at one and thanks to a custom software stack which the entire business runs around, on which they have almost complete technical debt - it's a fucking nightmare to keep on top of security of servers that aren't fully supported any more, and which weren't implemented well in the first place (no snapshotting capability, no staging environment, flat network so no test vlans etc)
But hiring a dev to pull the stack apart and re-implement it in modern platform/environment? Why would we need to do that? It's not broken!
*bangs head against desk*
I'm currently runnng Debian Jessie on one of these, it's headless and has gone through multiple dist-upgrades during its life, it started off as Etch and has never broken during any updates. So I totally agree that Debian is rock solid in their patching methodology, it's stable and works.
They backport security fixes so that holes get closed without affecting any of the functionality of the software in question.
All decent OS vendors do that. RedHat do the same (Red Hat Enterprise, CentOS), as do Suse and, I suspect, other Linux/Unix distros. Microsoft seem to as well ('seem' - this is what I read, I don't use any MS product).
Where they vary is how quickly they backport fixes and how far back they do it - ie how long something is supported for.
Destktop/mobile OS's v servers - it's the difference between stealing car stereos and robbing a bank. Harder, but vastly more rewarding* And Linux and Unix are pretty popular for servers.
* Ransomware has changed the balance somewhat - potentially $300 a time for fairly easy pickings!
Sorry to shout, but it is annoying that people keep quoting this useless link thinking it means something. CVE reporting is voluntary, and every company has a different process by which they determine whether to file a CVE for a security bug or not, and whether they file a CVE for each individual issue, each affected subsystem, or a single CVE that covers tons of unrelated stuff because they happened to be fixed in the same patch set. DIfferent companies ship different amounts of stuff as part of the "OS" as well.
Anyone looking at that list who has half a brain can tell easily how useless it is - notice that Windows 10 has more CVEs than Windows 8.1, which has more than Windows 7. Does anyone really believe Windows is getting LESS secure?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
