The Performance of Ubuntu Linux Over the Past 10 Years (phoronix.com)

← Back to Stories (view on slashdot.org)

The Performance of Ubuntu Linux Over the Past 10 Years (phoronix.com)

Posted by timothy on Friday February 5, 2016 @07:46AM from the so-it's-not-just-new-chips dept.

An anonymous reader writes: Tests were carried out at Phoronix of all Ubuntu Long-Term Support releases from the 6.06 "Dapper Drake" release to 16.04 "Xenial Xerus," looking at the long-term performance of (Ubuntu) Linux using a dual-socket AMD Opteron server. Their benchmarks of Ubuntu's LTS releases over 10 years found that the Radeon graphics performance improved substantially, the disk performance was similar while taking into account the switch from EXT3 to EXT4, and that the CPU performance had overall improved for many workloads thanks to the continued evolution of the GCC compiler.

110 comments

Min score:

Reason:

Sort:

But... how? by Anonymous Coward · 2016-02-05 07:49 · Score: 0

Were they running it in headless mode? This does not line up with my experience.
1. Re:But... how? by __aaclcg7560 · 2016-02-05 08:13 · Score: 5, Funny
  
  Ever see a chicken with its head chopped off? It runs faster.
2. Re:But... how? by penguinoid · 2016-02-05 16:29 · Score: 1
  
  Less deadweight?
  
  --
  Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
3. Re:But... how? by __aaclcg7560 · 2016-02-06 14:38 · Score: 2
  
  Less pecker.
4. Re:But... how? by Shirley+Marquez · 2016-02-08 00:29 · Score: 1
  
  No. But they were running it on a system with an eight core CPU and 16GB RAM. The memory usage of Linux has increased over time, so testing on a system with less memory might favor older releases.
And a big reduction in manageability... by Anonymous Coward · 2016-02-05 07:52 · Score: 3, Insightful

after forcing systemd on us!
1. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 08:38 · Score: 0
  
  The nice GUI dialog box asking the sudo password is nice, but yes dropping stderr and always exiting with zero as the exit status does make things harder to manage.
2. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 08:45 · Score: 1
  
  The nice GUI dialog box asking the sudo password is nice, but yes dropping stderr and always exiting with zero as the exit status does make things harder to manage.
  Great dialog unless you are logging in with ssh (have they absorbed that yet?) on a pty. I guess thats not what you do on a modern OS. Retards.
3. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 08:55 · Score: 0
  
  I'd love it if they added sshd to systemd. Then it would start faster and be more reliable. The unit files for OpenSSH aren't very good.
4. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 09:03 · Score: 3, Interesting
  
  systemd never ever drops stderr, could you trolls stop spewing that lie sometime?
5. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:03 · Score: 0
  
  You're fixing the wrong problem!
6. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:13 · Score: 1
  
  I hate how this is always the answer the systemd guys give. If Red Hat and Debian both can't get the unit files right then that points to a problem with systemd.
7. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:15 · Score: 0
  
  Was he wearing a short skirt, too?
8. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:17 · Score: 0
  
  I've seen repro steps for that problem posted here and in Reddit multiple times! If you systemd guys would spend as much time fixing bugs as you do defending something that is broken, you could probably fix it.
9. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:20 · Score: 1
  
  systemd never ever drops stderr, could you trolls stop spewing that lie sometime?
  I manage about 300 servers running Red Hat, and I've seen that problem hundreds of times when a service doesn't start, and there is nothing in the journal. Starting the service by hand usually clearly shows the error. It makes life much more difficult for us.
10. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 09:26 · Score: 1
  
  Check the unit file, I can almost guarantee that whatever application you start is either started with flags such as --quiet or a >/dev/null 2>&1 since the daemon developers are accustomed the old SysVInit where stderr wasn't supported.
11. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 09:27 · Score: 1
  
  So show one such repro step then, in every example that I have seen people have actively told the daemon to drop stderr due to it beeing copyied from a SysVInit script since SysVInit does not support stderr
12. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:38 · Score: 2
  
  And, exiting with a zero when there's a failure is even worse. We use Puppet scripts to manage about 1,500 virtual machines so it's really annoying that we can't easily detect the failure.
  # systemctl start mysqld Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details. # echo $? 0 # journalctl -u mysqld -- Logs begin at Mon 2016-01-11 18:19:52 UTC, end at Fri 2016-02-05 21:36:45 UTC. --
  The journal is empty!
13. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:43 · Score: 0
  
  Puppet uses exit statuses which are an out of date concept.
14. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 09:44 · Score: 0
  
  You misunderstand the purpose of the journal. It's not like syslog.
15. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 10:12 · Score: 4, Informative
  
  Just to show an example, look what I found in the MediaTomb unit file:
  ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE
  That "-l" there means that MediaTomb will not log to stdout/stderr/syslog but that it instead logs to it's own logfile in $MT_LOGFILE so no wonder one will never ever find MediaTomb logs in the journal, they are never sent there by the daemon in the first place.
16. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 10:25 · Score: 1
  
  The journal is empty because mysql.service does not start mysqld but the ancient mysqld_safe (which is no longer needed with systemd anyway):
  ExecStart=/usr/bin/mysqld_safe
  And mysqld_safe by default prevents mysqld from syslog, from stdout and stderr. Instead it redirects all these to /var/log/mysql.err. So it's another case where the people who created the systemd unit file didn't know what they where doing, they simply copied how they did it in the SysVInit script.
  Regarding the exit code from systemctl, I'm not really sure but I think that it only returns an error code if you tried to start a disabled service or a service that didn't exist. The proper way to check if the service is running is to issue a "systemctl is-failed mysqld.service" and then it will return 0 if the service failed to start and 1 if it's running.
17. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 10:29 · Score: 1
  
  Or simply it will take some time until developers and managers discover that things that they did and which made sense in a SysVInit script no longer does in a systemd unit file. Often in SysVInit scripts stderr and co are sent to /dev/null (or forking using the daemon() call which does exactly that) something that is no longer needed for systemd.
18. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 10:41 · Score: 1
  
  There is also a "systemctl is-active mysql.service" which returns 0 if it's running and 1 if it's not. Just so no one barks at the reversed exit code in my previous post.
19. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 10:58 · Score: 0
  
  You misunderstand the purpose of the journal. It's not like syslog.
  Then please enlighten us.
  Even after over twenty-seven years managing UNIX servers, and at one point managing over 1k servers and about 150 routers using rsyslog, the systemd journal still doesn't make sense to me.
20. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 11:03 · Score: 0
  
  Thank you! That works:
  # systemctl is-active mysqld ; echo $? failed 3
  Notice on Red Hat it's called mysqld and not mysql.
  Now I have to figure-out how to integrate that into Puppet since it only uses the exit status which is always 0 from systemd.
21. Re: And a big reduction in manageability... by Curunir_wolf · 2016-02-05 11:34 · Score: 1
  
  Puppet uses exit statuses which are an out of date concept.
  Exit statuses are useless now? WTH?
  
  --
  "Somebody has to do something. It's just incredibly pathetic it has to be us."
  --- Jerry Garcia
22. Re: And a big reduction in manageability... by F.Ultra · 2016-02-05 13:09 · Score: 1
  
  It's not always 0, it's only 0 of everything went ok for the things that the "systemctl start" command is concerned which is that it could schedule the service to be activated. This is just the way that the "modern" init launches like systemd, solaris smf, osx launchd and the upcoming new launcher for BSD (which I don't know the name for) works. With these you no longer run a shell script but instead schedule an event to occur and if that event does not occur, then it can wait some time and then try again (respawning failed services is one feature of systems like this) and thus there is a different way of finding out if a service is currently running or not.
  With SysVInit there was no guarantee that the service would be running after it returned 0 since the service could encounter an error sometime after it forked (and that happens a lot I can tell you) so even there one really cannot use the exit code of "service xx start" but you have to do a "ps ax | grep xx" dance, or if the service was smart enough so store it's pid in a file you had to do that dance instead. So once people just calm down and get used to systemd they will probably discover that they now have a generic way to see if services are running and so on. And we need better unit files, the mysqld one is completely insane with the use of mysqld_safe since what that script does, systemd already does better, so it's completely useless not to mention that it makes mysqld to not log to the "correct" places.
23. Re: And a big reduction in manageability... by dbIII · 2016-02-05 14:04 · Score: 2
  
  Anything other than a single user desktop computer without a network is an out of date concept to the new shinies of systemd and wayland.
  Let's party like it's 1994!
24. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 14:58 · Score: 1
  
  > service could encounter an error sometime after it forked
  True, but SysV init scripts didn't swallow stderr and hide the error like systemd does. That's the problem.
25. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-05 19:24 · Score: 0
  
  The exit status is the return value of main(). Why would you not want to check the return value of stuff you call? I bet you think C is also an out of date concept.
26. Re: And a big reduction in manageability... by F.Ultra · 2016-02-06 00:24 · Score: 1
  
  systemd does not swallow stderr, if you see no stderr in the journal then it's because who ever wrote the unit code decided to redirect it to /dev/null or the service did a daemon() call to do the same (in which case you wouldn't get stderr in SysV either), and it doesn't hide the error (it just works differently than SysV).
27. Re: And a big reduction in manageability... by Anonymous Coward · 2016-02-06 07:48 · Score: 0
  
  Wtf lol. So it's hidden by default depending on the program running or who wrote it. Or I guess not hidden but dumps it to /Dev/null?
  Sounds suspect. I'll stay away from systemd and continue to be happy with the family of BSDs I use.
28. Re: And a big reduction in manageability... by F.Ultra · 2016-02-06 13:10 · Score: 1
  
  No you don't understand what is happening here, it's the service/daemon it self that redirects stderr to /dev/null, and it does this regardless of if you run it on BSD, on SysV or on systemd. How do you propose to be able to log stderr when the application itself redirects it to /dev/null?
In all honesty... by Anonymous Coward · 2016-02-05 07:54 · Score: 5, Insightful

Writing sane optimized software makes far bigger impact than dicking with filesystems, schedulers and compiler optimizations to hunt the 0.05% extra performance. For example the Unity desktop is super laggy on low-end hardware, all due to bloated design.
1. Re:In all honesty... by Anonymous Coward · 2016-02-05 08:23 · Score: 0
  
  running ubuntu 14.04 LTS with UNITY on a core 2 duo with 2gb of ram, and 2.5" IDE hard drive. What is this "super laggy" you talk about? Are you running it from a live cd? Or is the "low end hardware" that you're running on older than this 8 year old laptop?
2. Re:In all honesty... by Anonymous Coward · 2016-02-05 08:44 · Score: 0
  
  There are new machines sold that have slower chips than Core 2 Duo.
3. Re:In all honesty... by Narcocide · 2016-02-05 09:03 · Score: 1
  
  He's running it a VMware guest on Windows.
4. Re:In all honesty... by Anonymous Coward · 2016-02-05 09:06 · Score: 0
  
  Dude a new ATOM is a quadcore cpu that can do 1080p video which is comparable to the core 2 duo. These are used on low end sub $200 tablets and pcs. The Core 2 Duo was fast at it's time (compared to a Pentium IV). But it is quite dated now for all but elementry word processing and email and maybe under 4 tabs in Chrome.
  Technology has progressed considering a 24 raid SSD in 2011 is the same speed as 1 NVME ssd.
5. Re:In all honesty... by Anonymous Coward · 2016-02-05 09:10 · Score: 0
  
  I do not know what is low end hardware by your standards. Unity run well on Athlon 3700, and runs well on Phnom III 440 today. 4 GB of RAM.
  What are you running it on?
6. Re:In all honesty... by Anonymous Coward · 2016-02-05 09:14 · Score: 0
  
  As I type, I am installing linuxmint with mate on a machine with an AMD athlon 64 3800+ cpu and an nvidia FX 5200 card. Unity was unbearable on this machine. Super laggy is the proper description for it. When typing an email (firefox and gmail), there was a huge delay between keystrokes and the letter appearing on the screen. Keystrokes were properly buffered so it was usable, buy annoying and typo detection was done afterwards. Scrolling a web page was also annoying. Yes, it is a very old machine, but for checking email and browsing the web should be more than enough.
  This was with ubuntu 12.04. Upgrade to 14.04 did not work well (mostly xorg and nvidia drivers), had to fix many things and still worked like a dog.
  I tested linuxmint from a dvd and works like a charm.
7. Re:In all honesty... by JoeMerchant · 2016-02-05 09:46 · Score: 2
  
  I wouldn't call Unity bloated, I'd call it inappropriately feature rich for low-end hardware.
  Would be nice if there were a "I'm on a crappy little ARM core" switch in Ubuntu that reconfigures it to a more Raspbian like system hardware requirement.
8. Re:In all honesty... by Guybrush_T · 2016-02-05 09:50 · Score: 1
  
  I'm still using my old Core2Duo laptop on 10.04 because it is way faster than any recent laptop on 14.04 or 16.04. Just added an SSD, it boots in 14 seconds and launches any application instantly. I installed 12.04 on it because I wanted to get updates, but it was clearly slower, so I sticked to 10.04.
9. Re:In all honesty... by walterbyrd · 2016-02-05 10:35 · Score: 1
  
  I loved 10.04! Best version of Ubuntu ever, IMO.
  At the time, Ubuntu was just getting better, and better. I could hardly wait for 10.10.
  When 10.10 came out, it had that awful Unity desktop. I hated it so bad, I never used Ubuntu again.
  And now they are using systemd - barf.
10. Re:In all honesty... by armanox · 2016-02-05 10:52 · Score: 1
  
  I think see your problem - GNOME 3 desktops (Unity, GNOME Shell) require 3D acceleration for rendering, and I am pretty sure the FX 5200 is no longer supported. A non-accelerated DE/WM should do fine for you (and disable GPU acceleration in Firefox)
  
  --
  I'm starting to think GNU is the problem with "GNU/Linux" these days.
11. Re: In all honesty... by crankyspice · 2016-02-05 11:00 · Score: 1
  
  I use a Core 2 Duo (1.86 GHz, 4GB RAM, 128GB SSD) MacBook Air (2010) as a daily driver, updated to the latest 10.11.2 OS X. Works fine with 2 browsers, MySQL
  (10GB indexed database), Ruby on Rails, Webrick, Adobe Acrobat Pro... I often have at least 4 apps open at once (right now: Acrobat Pro, Word, Firefox, TextWrangler, and Clean Text). I have a newer Core i5 8GB MBA I leave at home (I commute via metro and the C2D is "expendable"), so I could use a higher performance machine, just haven't felt the need to. Of course, if I'm going to do anything hefty in Photoshop, final cut pro, etc., I fire up a 3.4 gigahertz Quad core I five Hackintoshâ¦
  
  --
  geek. lawyer.
12. Re:In all honesty... by Anonymous Coward · 2016-02-05 11:08 · Score: 0
  
  I wouldn't call Unity bloated, I'd call it inappropriately feature rich for low-end hardware.
  I have use cases where I need to get 60 fps consistently (59 fps is tolerated, a drop to 50 is not) for a specific application and the Unity maintainers have repeatedly moved or outright removed options to disable wasteful and obnoxious effects. Even Unity2D moved around until it just disappeared on me - fuck I had to support some software on Ubuntu as VirtualBox Guest and its GPU drivers just blow up the moment you have more than one application ( or Unity and anything else ) running OpenGL - current solution: disable 3D acceleration for the system and let MESA do its job on the CPU.
  Unity is nice if you want your desktop to woosh, zirp and bling. For everything else its a bloated mess.
13. Re:In all honesty... by Guybrush_T · 2016-02-05 11:11 · Score: 1
  
  I don't really care about systemd as long as it works and is fast, but Unity is definitely a failure. It's been 5 years now and I'm still not used to it, and find it a terrible UI compared to Gnome 2.
  Not better for Tablets, not better for TVs, and for sure not better for desktop.
  The only good thing I like is the windows shortcut to launch an application with the keyboard, but that would be easy to do on Gnome 2 also.
  Unfortunately, Gnome 3 was not better, and the Gnome project abandoned Gnome 2, so the remaining support on Gnome2 is too small now to make it work with latest software.
  That really sucks.
14. Re:In all honesty... by tetraverse · 2016-02-05 11:12 · Score: 1
  
  You should try Lubuntu the lightweight version based on the LXDE desktop ...
15. Re:In all honesty... by MMC+Monster · 2016-02-05 11:46 · Score: 1
  
  Let's put this another way:
  Would you expect the Mac OS X software stack to be more efficient now than a similar software stack from 10 years ago?
  How about MS Windows?
  It's nice to know that a Linux OS hasn't become a bloated mess over a decade of software upgrades.
  
  --
  Help! I'm a slashdot refugee.
16. Re: In all honesty... by corychristison · 2016-02-05 13:20 · Score: 1
  
  If you have a use case that requires a specific FPS, any of the so called "Desktop Environments" are probably way overkill.
  A lightweight WM like Openbox, Fluxbox, enlightenment, or even IceWM is probably better suited.
  I use IceWM on my custom HTPC. If works for my needs with very minimal configuration.
17. Re:In all honesty... by Anonymous Coward · 2016-02-05 13:27 · Score: 0
  
  Sempron 3000+ here, it works pretty nice with Debian + XFCE, why would anybody use unity?
18. Re:In all honesty... by Christopher+Cashell · 2016-02-05 14:30 · Score: 1
  
  There kind of is. Install Xubunt or Lubuntu, or install the respective desktop environments used by those projects. I'm running Xubuntu on an almost 8 year old NetBook with a 1.6GHz Atom CPU and, while I wouldn't call it fast, it's usable.
  
  --
  Topher
19. Re:In all honesty... by rrohbeck · 2016-02-05 16:13 · Score: 1
  
  I run KDE on Banana Pi and Raspberry Pi and it works fine. Just sayin'.
  
  --
  thegodmovie.com - watch it
20. Re: In all honesty... by Anonymous Coward · 2016-02-05 18:56 · Score: 0
  
  It runs well. But games on top of it are significantly slower to the point of not playable. I had to install xubuntu to be able to play some games.
21. Re:In all honesty... by jones_supa · 2016-02-05 20:14 · Score: 1
  
  Please, stop the denialism.
  Windows 10 works smoothly on an Atom N270 or Core 1 Duo. Unity, on the other hand...not so much.
  A basic composited desktop with basic animations does not require that much horsepower. Even a measly GMA950 is more than enough. Even VIA C7-M with Chrome9 graphics ran Windows 7 with no hiccups and all 3D eyecandy enabled.
  Linux is terribly bloated and unoptimized.
What about measuring reliability? by Anonymous Coward · 2016-02-05 07:59 · Score: 5, Interesting

What about measuring reliability? That's one of the most important performance factors of any system of any sort, including Linux installations.
After all, a Linux system that crashes or that does not even boot will offer no reasonable performance of any type!
When I last used Ubuntu, it used its own init system called Upstart. It generally worked well for my needs.
Correct me if I'm wrong, but as I understand it Ubuntu 15.04 was the first to switch to systemd.
Based on my experiences with Debian, systemd was a complete disaster. After doing routine updates I experienced booting problems on several of my computers. After some investigation it turned out that all were due to various problems with systemd.
While desperately looking for solutions to my problems, I found many other people reporting all sorts of problems with systemd. These are the kinds of problems we never experienced with sysvinit or Upstart or other init systems.
It doesn't matter how fast my computer's CPU is, or how fast the disk is, or how fast the graphics are if the computer doesn't even boot far enough to be usable because the init system crapped out.
1. Re:What about measuring reliability? by Anonymous Coward · 2016-02-05 08:58 · Score: 1
  
  I am getting nauseous from reading pro-systemD comments every day. And?
2. Re:What about measuring reliability? by Anonymous Coward · 2016-02-05 09:03 · Score: 1
  
  Just shut up and install Gentoo.
3. Re:What about measuring reliability? by Anonymous Coward · 2016-02-05 09:11 · Score: 0
  
  Let's review what happened in late 2014. Slashdot can help us with this, in fact: Debian Votes Against Mandating Non-systemd Compatibility
  So in November of 2014, after a very questionable vote, Debian decided to force systemd on all of its users, without leaving any option to use other non-systemd init systems.
  Systemd is notorious for suffering from inherent architectural problems and implementation flaws. Many Debian users experienced these problems first hand.
  Now, Debian users have traditionally been accustomed to very reliable systems. The level of reliability that systemd tends to provide falls far below the threshold of what Debian users, and Linux users in general, have come to see as acceptable.
  Of course there will be outrage and anger regarding systemd. It was forced on many victims against their will, and it has caused them nothing but problems, while offering them absolutely no benefits at all.
  The only nightmare here is that suffered daily by those long-time Linux users who are now subjected to systemd and the problems it has caused them. Many have moved to FreeBSD, but others don't have that luxury (sorry, fringe Linux distros, including Slackware and Gentoo, are not proper replacements for Debian). So every day they endure yet more problems caused by systemd.
  Instead of bitching about them describing the many problems they've encountered, you should push for systemd to be removed form Debian. Once systemd is removed from Debian these people will have no reason to complain, and they'll get Linux systems that actually work well again.
4. Re:What about measuring reliability? by Anonymous Coward · 2016-02-05 13:24 · Score: 0
  
  Please do provide evidence for every usage of "many users". Where you get that metric? Rolled some dice to get "statistics"?
  And as for FreeBSD, lol good luck with that. Wake me up when that thing can suspend, except on a very limited line of ancient Lenovo laptops. Oh, hey, it's 2016, but FreeBSD can barely suspend, can't hibernate AT ALL, has bad wifi support, no UTF-8 support out of the box, and will soon be unable to run major desktop distros as they all begin integrating deeper with systemd. Good luck with that systembsd vaporware that never took off after the initial GSoC "project".
  Other than a few leeching companies using FreeBSD in the base of their proprietary product, nobody is really using FreeBSD. And before you say Netflix, they're slowly migrating to Linux systems as FreeBSD has shown inadequate for their use. That's right, "the power to serve" is no longer powerful enough in 2016.
5. Re:What about measuring reliability? by PRMan · 2016-02-05 13:32 · Score: 1
  
  I quit using Ubuntu far before systemd (during the Vista days because Vista). Back then, updates would crash it and then make me spend hours getting it back to a functional state.
  I went back to Windows with Windows 7. So that's not a systemd thing as much as a Ubuntu thing.
  
  --
  Peter predicted that you would "deliberately forget" creation 2000 years ago...
6. Re:What about measuring reliability? by dbIII · 2016-02-05 14:09 · Score: 1
  
  What about measuring reliability? That's one of the most important performance factors of any system of any sort, including Linux installations.
  It's not supposed to be beta software so reliability is assumed. If you don't get it then the software is not ready for release. It's not high turnover commercial software where something has to be out by the end of the month whether it works or not.
7. Re:What about measuring reliability? by jones_supa · 2016-02-05 20:18 · Score: 1
  
  Well, that's refreshing. :) You actually switched the operating system, instead of continuing to whine year after year about the problems, like many masochistic Linux users of Slashdot do.
8. Re:What about measuring reliability? by Anonymous Coward · 2016-02-05 20:21 · Score: 0
  
  I am getting nauseous from reading pro-systemD comments every day.
  I doubt very much that you do.
  But hey, if that's what you decide to get riled up about, every day, then have at it.
9. Re:What about measuring reliability? by Blaskowicz · 2016-02-05 22:23 · Score: 1
  
  Well, as a desktop user I'm used to the higher reliability of Ubuntu / Mint and debian made some bad moves before already :
  - Debian 6 : to protect your freedom, no wifi drivers are included. (Gave away a desktop that it turns out couldn't access the Internet)
  - Debian 7 : no official desktop anymore. Well, there's Gnome 3 but why would you put that on an i486 distro?
  - Debian 8 : why should I care? Buying a graphics card for getting drivers that play better with a 3D desktop is asking a bit much. But if I come across a 256MB computer I'll sure install text-mode debian and raw lxde on that. It is a bit late, though, those perfectly working Pentium III / BX chipset PC went into the trash.
10. Re:What about measuring reliability? by umafuckit · 2016-02-05 22:42 · Score: 1
  
  What about measuring reliability?
  In all seriousness: probably because his benchmark programs don't measure reliability. This guy benchmarks stuff. A lot of stuff. He knows how to do it. This time he's benchmarked a bunch of Linux installs. We learn a little, but not so much. Yes, there are some big differences (like the disk performance going down). But often it's not clear why any of that stuff happened. So not very informative, to be honest.
  
  --
  soylentnews.org
11. Re:What about measuring reliability? by Anonymous Coward · 2016-02-07 02:44 · Score: 0
  
  Netflix still uses FreeBSD because Linux has undefined performance characteristics under heavy load. Linux may work fine at 100% when doing non-interactive CPU bound science number crunching, but load Linux down by saturating IO and CPU, and the system crumbles. It has always been this way. Netflix also has a non-GPL kind of rule. If you need to get lawyers involved to write code, then don't write the code.
12. Re:What about measuring reliability? by strikethree · 2016-02-10 22:33 · Score: 1
  
  The most reliable Linux based system I has was based on Linux 2.2.30(?) anyways, 2.2, and Blackbox as a Window Manager. I played Counter Strike on my laptop and had great framerates, I ran prime number generators, cracked passwords, watched fun opengl screensavers, and everything was always smooth as silk and nothing ever crashed no matter how high the load became.
  I would go back to it if I could and could have sub-pixel font hinting. My god the fonts were ugly... but perhaps they would look nicer on a 4k screen now... hm.
  
  --
  "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Not my experience at all. by Anonymous Coward · 2016-02-05 08:13 · Score: 0

I first started using Ubuntu back in the 4.something days, and it was very apparent that each new major release (and a few point releases) were noticeably slower and less robust than the previous one(s) on the same* hardware.
The latest incarnation of both Ubuntu and Mint are just dogshit slow on my current system (Quad-core i5, 16gb Ram, Nvidia GTX 560, SATA 3 drives). I was dual booting Linux (first ubuntu 14, then Mint up to 17.1) and Windows 7, and they made Windows seem light and solid by comparison. About 4 or 5 months ago I took Salix for a spin and haven't looked back. It is light, fast, and the (few) error messages I get are actually useful, instead of "Sorry, something went wrong. You may have to restart" or such.
Unscientific and anectdotal, I know. But I wholly disagree with the main idea of this article.
* same hardware- Obviously I didn't run the same hardware from 4 to 14, but I want to say that Ubuntu 4-10 was on the same AMD Athlon, Ubuntu 10-12 was on a Core2Duo and Ubuntu 12-14 (and then Mint starting with 15 or so) were on my i5.
1. Re:Not my experience at all. by saigon_from_europe · 2016-02-05 09:11 · Score: 1
  
  My work machine is i7 laptop (4 cores, not "U" variant) with 16GB RAM, no SSD, just HDD. Both Ubuntu 14.04 and Windows 8.1 are surprisingly slow in some standard operations, most annoyingly in logging in, starting Chrome... Also annoying thing with Ubuntu is that if it uses HDD, then everything else is way too slow. If I tar/untar some really big file, and I browse web in parallel, I see that browser is noticeably slower than usual.
  I still wonder how we used to do more-or-less the same stuff on machines that had 512MB of RAM and 5x slower CPU. Where has all the CPU power gone? Why SW got so bloated?
  
  --
  No sig today.
2. Re:Not my experience at all. by Anonymous Coward · 2016-02-05 09:37 · Score: 0
  
  My work machine is also an i7 with 16GM of RAM, and it is no faster than a few years old AMD with only 4GB RAM. I have the same issues. A $250 PC runs Linux Mint faster than a $700 PC. Even if the software can't use the 8 cores, the newer CPU should be faster just using 1 or 2 cores.
3. Re: Not my experience at all. by guruevi · 2016-02-06 01:39 · Score: 1
  
  Back then all the hardware was roughly the same speed. You couldn't saturate your disk bus with a simple tar because your CPU and memory had latencies measured in 100ns-ms, your disk could catch up. Disks are still roughly the same speed as they were 10 years ago. Also, js and html have become bigger and more of it can be found on random websites. I remember a time when you would optimize websites to fit all text, graphics and code under 50-100kb (~1-2s load time). jQuery alone is that size now and we sometimes load several libraries in a page. Our network is faster but our disk isn't. There is also a lot more graphics and bells and whistles, we are back to the 90s with the flashing under construction and dancing skeletons but now it's in code.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
Surprise! by SeaFox · 2016-02-05 08:13 · Score: 2

Software performs better after it's had time to mature and be optimized and bugs removed.
Don't tell anyone by NotDrWho · 2016-02-05 08:13 · Score: 5, Insightful

If Linux fans find out that a distro is in any way successful, they're obligated to split it into a million competing forks and bitch about it endlessly.

--
SJW's don't eliminate discrimination. They just expropriate it for themselves.
1. Re:Don't tell anyone by Anonymous Coward · 2016-02-05 09:10 · Score: 0
  
  No worries mate, there are already about one gorillion forks of ubuntu.
2. Re: Don't tell anyone by Anonymous Coward · 2016-02-05 09:40 · Score: 5, Interesting
  
  There may be lots of Linux distros, but they fall into 3 categories:
  1) Fedora-derived distros
  2) Debian-derived distros
  3) Niche distros
  We don't really see fragmentation, but rather specialization.
  The Fedora- and Debian-based distros see the most use. Even they aren't very different these days, especially the Debian versions that use systemd.
  So the fragmentation you're talking about just doesn't exist any more. It's not 1996.
3. Re:Don't tell anyone by Anonymous Coward · 2016-02-05 09:58 · Score: 0
  
  It's almost as if they are always seeking something different. That sucks. We don't need change. We need cows.
4. Re:Don't tell anyone by Anonymous Coward · 2016-02-05 10:44 · Score: 0
  
  apt-get moo
  (brought to you by Super Cow Powers)
5. Re:Don't tell anyone by tetraverse · 2016-02-05 11:03 · Score: 1
  
  I've been running Lubuntu exclusively at home for a number of years, and I have no complaints. I like the way it works out-of-the-box, browsing, wordprocessing and media player and installing software can't be easier with Synaptic the graphic package manager.
6. Re: Don't tell anyone by phantomfive · 2016-02-05 13:28 · Score: 1
  
  We don't really see fragmentation, but rather specialization.
  And the alternative to specialization is bloatware, so be glad for specialization.
  
  --
  "First they came for the slanderers and i said nothing."
7. Re:Don't tell anyone by Anonymous Coward · 2016-02-05 17:00 · Score: 0
  
  I agree, this is definitely problematic. Also platforms like the Raspberry Pi are not PC. We need safe spaces for popular Linux distributions so they aren't under constant attack from reactionaries like people who hate systemd.
8. Re: Don't tell anyone by Anonymous Coward · 2016-02-06 01:03 · Score: 0
  
  Doesn't Android count, it's definitely Linux based and it can't be considered niche because it covers the most popular platform type available.
9. Re: Don't tell anyone by ebvwfbw · 2016-02-06 11:45 · Score: 1
  
  ...So the fragmentation you're talking about just doesn't exist any more. It's not 1996.
  Great, glad we have just one Desktop... well we don't have that. There's kde, gnome, others.
  Great, glad we have just one Filesystem... well we don't have that either. btrfs, gpfs, ext(n), etc.
  Great, glad we have just one organized set of files... well we don't have that. We have the right way which RedHat mostly does and some really screwed up distros. Sometimes I think they're like - nobody will ever guess the config file is here! Ha!
  Great, glad we have just one way to install Linux.... well we don't have that either.
  and so on.
  Great thing about FOSS is you can make your own. The bad thing is we have so much effort going into often slightly different designs. Just imagine if we all standardized on gnome or kde. Don't care which one, either of them. Just standardize on one and call it a frickin' day! Nobody knows how long anyone really is anyhow.
  We still have the SYS V vs BSD bullshit still going on. I was ready to stick a fork in it, BSD was dead then one guy fetched it out of the fire and replaced a really bad operating system - Apple OS with BSD after a great deal of effort to bring it up near contemporary standards. Even today, BSD is still a good decade or so behind. Actually this is 2016, they're really more like two decades behind now. Before anyone gets their panties in a bunch, look into it. There's a great deal missing from bsd. Mandatory access control for example. Consolidated filesystem access... In fact Apple doesn't use their own OS at the company because everyone knows it simply isn't up to the task. I mean, it's a captain obvious moment.
  My whole career in fact. It's just moved on from arguments around VMS, Mainframe OSs, etc to Windows (which is funny in itself) and the various flavors of Unix. Need one OS, one desktop, one filesystem... one way to maintain these beasts and so on. As always - don't care which one, pick one and let's be done with it. Then Microsoft can blow their operating system off as it's a really big turd and super upgrade to Linux. Then we'll have micosoft office on Linux. Get SELinux set... the entire civilization will benefit.
On the other hand by Anonymous Coward · 2016-02-05 08:22 · Score: 0, Insightful

The intoduction of systemd has turned a once proud distribution into a nazified hot mess.
Then Start Re-Producing i7-980X's Then. by zenlessyank · 2016-02-05 08:22 · Score: 0, Offtopic

Or maybe Sandy Bridges. This is like the assholes in govt that made us start driving 55 when we were already going 75+. Always some fuckheads who think some other stupid shit is BETTER. I want SPEED. If I wanted efficient I would buy your $80 buddy boy chips. You just undid 20 years of trust. GO AMD.
1. Re:Then Start Re-Producing i7-980X's Then. by Anonymous Coward · 2016-02-05 08:31 · Score: 0
  
  Aww, that's cute, the angry troll is lost.
2. Re:Then Start Re-Producing i7-980X's Then. by Anonymous Coward · 2016-02-05 08:52 · Score: 0
  
  Wrong story dude.
  http://tech.slashdot.org/story/16/02/05/1745227/intel-says-chips-to-become-slower-but-more-energy-efficient
3. Re:Then Start Re-Producing i7-980X's Then. by Anonymous Coward · 2016-02-05 08:55 · Score: 0
  
  Nerd rage, the funniest form of rage.
4. Re:Then Start Re-Producing i7-980X's Then. by StormReaver · 2016-02-05 09:43 · Score: 1
  
  ...Or maybe Sandy Bridges.
  I think you responded to the wrong story.
5. Re:Then Start Re-Producing i7-980X's Then. by Anonymous Coward · 2016-02-05 12:11 · Score: 0
  
  If you think this is the right place to get a Sandy Bridge, then I have a Sandy Bridge to sell you.
6. Re:Then Start Re-Producing i7-980X's Then. by zenlessyank · 2016-02-05 13:58 · Score: 1
  
  DOH!!! Angry posts get me every time!!!
Meaningless stats by Anonymous Coward · 2016-02-05 08:50 · Score: 0

The only thing that matters is how snappy the GUI is, try measuring framerates of the change from 2D Gnome to 3D Unity. Also compare open source drivers vs proprietary at rendering the GUI. Users don't care about how many bits a hard drive is transferring per second as they will never notice.
1. Re:Meaningless stats by ausekilis · 2016-02-05 09:03 · Score: 4, Insightful
  
  The only thing that matters is how snappy the GUI is, try measuring framerates of the change from 2D Gnome to 3D Unity. Also compare open source drivers vs proprietary at rendering the GUI. Users don't care about how many bits a hard drive is transferring per second as they will never notice.
  Users do care about data rates to/from a hard drive. Ever install a huge game? Ever try to play a movie from disk while uploading photos to picasa? What about backing up data by copying between hard drives?
  
  I can all but guarantee there will be complaints about how long it takes to copy 20GB of crap between drives. Or the fact that the video is stuttering as thousands of photos are being accessed for upload. You'll probably hear "This computer is really slow" when it's actually the hard drive as a bottleneck. Better throughput and smarter accessing/layout aren't things a typical consumer will talk about, but they certainly will appreciate.
2. Re:Meaningless stats by Kjella · 2016-02-05 11:33 · Score: 1
  
  Yes, but... what users are complaining about isn't really how "fair" it is from a CS perspective. What they really want to know is how they can say my video streaming is a lot more important than my bittorrent client and if there's CPU contention or IO contention or network contention just let the video take priority. Because usually somebody with a server has optimized the IO quite well for the use case with 100 streams and they're all equally important. That's usually not the case on the client, some things matter much, much more than others.
  
  --
  Live today, because you never know what tomorrow brings
Linux Mint by Sir_Eptishous · 2016-02-05 09:31 · Score: 1, Informative

FTW

--
We play the game with the bravery of being out of range
1. Re:Linux Mint by Anonymous Coward · 2016-02-05 10:18 · Score: 0
  
  I really like Mint 17 with Cinnamon. My only fear is that someday it'll get a new leader with a buzzword fetish that wants to take it in a "new direction".
Why just Ubuntu? by walterbyrd · 2016-02-05 10:29 · Score: 1

All Linux is open source, all use the same kernel, all use the gcc compiler.
Why would Ubuntu substantially outperform other Linux distros using the same kernel, compiler, file system, ect? Why would CPU, Radeon graphic, and HDD performance be substantially different?
1. Re:Why just Ubuntu? by tetraverse · 2016-02-05 11:17 · Score: 1
  
  It's to do with the particular Desktop Environment: Five Best Linux Desktop Environments
2. Re:Why just Ubuntu? by PRMan · 2016-02-05 13:34 · Score: 1
  
  Honestly? Because he didn't feel like configuring everything from scratch after installing...
  
  --
  Peter predicted that you would "deliberately forget" creation 2000 years ago...
3. Re:Why just Ubuntu? by Anonymous Coward · 2016-02-07 03:16 · Score: 0
  
  Default configurations? A plethora of different software that does the same job. A server can easy have a 10x difference in performance by just changing config files. No recompilation needed.
What the fuck is $MT_LOGFILE set to? by Anonymous Coward · 2016-02-05 17:27 · Score: 0

Holy fuck!
Can you find where $MT_LOGFILE is defined and tell us what the actual value it is set to is?
Have you checked that $MT_LOGFILE isn't set to /dev/stdout, or to /dev/stderr, or to /dev/syslog before you make the claim that it "will not log to stdout/stderr/syslog but that it instead logs to it's own logfile in $MT_LOGFILE"?
All you've provided us with is a usage of the variable. You haven't actually shown us what its value was set to! For all we know it is logging to stdout, stderr or syslog, but you've perhaps ignorantly not realized this in your zealous defense of systemd.
1. Re:What the fuck is $MT_LOGFILE set to? by Anonymous Coward · 2016-02-05 20:54 · Score: 0
  
  Looks like it's set to /var/log/mediatomb by default. I guess the admin would know if she/he had changed that.
  https://github.com/marcin1j/me...
2. Re:What the fuck is $MT_LOGFILE set to? by Anonymous Coward · 2016-02-05 22:38 · Score: 0
  
  Careful. It's rather evident that you are grasping at straws here, most likely due to your zealous hatred of systemd.
  I'd ask you to try to be a little more rational, but I've found that it's something most zealous systemd haters are largely incapable of, unfortunately.
  Am I trolling you? You'd think so, but no, I'm not.
3. Re:What the fuck is $MT_LOGFILE set to? by F.Ultra · 2016-02-06 00:21 · Score: 1
  
  It doesn't matter what $MT_LOGFILE is set to, that is besides the point that I'm making. With SysVInit you have to tricks like this but with systemd it's no longer necessary since the journal will group together stdout, stderr and syslog into a single log.
  But just to prove you wrong, let's look at "man mediatomb":
  -l, --logfile
  Do not output log messages to stdout, but redirect everything to a
  specified file.
  So as you can see the whole point of -l is to not use stdout or stderr, in fact it cannot be any of those since it must be a physical file!
4. Re:What the fuck is $MT_LOGFILE set to? by Anonymous Coward · 2016-02-07 03:22 · Score: 0
  
  Any good system is easy to use correctly, difficult to use incorrectly, has clear indications why things are not working as expected, and should not allow you to do anything dangerous without throwing warnings or errors that need to be overridden.
  
  If many people are having issues, even if technically their fault, it still means the program is poorly designed.
More than Debian and Fedora/Red Hat by Sits · 2016-02-05 17:27 · Score: 1
Debian is definitely a popular root but I'd dispute I'd argue that it isn't Fedora that's a major root, rather it's Red Hat/RHEL. Even then, there are large numbers of popular distros not derived from those sources. From the GNU/Linux Distribution Timeline:
1. Slackware has spawned lots of distros (including SUSE)
2. Enoch spawned the Gentoo line of distros (and Gentoo is the current base of ChromeOS).
3. The Arch family started independently
4. The on-the-rise Alpine Linux was independently started
So by lineage alone I'd argue there are more than two major categories.
1. Re:More than Debian and Fedora/Red Hat by toddestan · 2016-02-06 17:25 · Score: 1
  
  It might be a bit harsh to call Slackware, Gentoo, SUSE, Arch, etc. "niche", but I do agree that the majority of Linux installations are either from the Debian lineage, or the Redhat (Fedora) lineage.