Slashdot Mirror


Clear Linux Beats CentOS, openSUSE, and Ubuntu in (Enterprise) Benchmark Tests (phoronix.com)

An anonymous reader writes: Recently completed Linux distro benchmarks by Phoronix show Intel's Clear Linux is the most powerful on x86 hardware. A six-way, enterprise-focused Linux distro comparison show Clear Linux being the fastest with a Core i9 and Xeon systems, easily beating CentOS, openSUSE, and Ubuntu in a majority of the tests.

When doing an 11-way Linux distro boot test they also found Clear Linux easily booted the fastest followed by the Clear-inspired Solus distribution. Clear Linux does work on AMD hardware and works on Intel CPUs back to Sandy Bridge but leverages its speed from optimized compiler settings, specially built libraries capable of AVX instructions on supported systems, a specially tuned kernel configuration, and other optimizations/patches.

Debian 9.2 and Fedora 27 "ended up being dropped from this article due to data overload," the article concludes, "and those distributions really not offering anything really different in terms of the performance."

136 comments

  1. Double Penetration! by Anonymous Coward · · Score: 0

    Windows vs. NetBSD! Who will be penetrated more? Heeyyyzzzoooo!

    1. Re: Double Penetration! by emil · · Score: 1

      And brand new, prehacked ME binaries for easy, promiscuous access!

  2. Centos will never win performance benchmarks by Anonymous Coward · · Score: 0

    b/c it's a clone of RHEL, and RHEL sticks to older, "very long term support" kernels to minimize risks in production servers.

  3. I'm so glad I stayed up for this by Zontar+The+Mindless · · Score: 5, Insightful

    Linux distro produced by Intel, tuned by Intel for latest Intel hardware, works fastest of any distro on latest Intel hardware. Shocking!

    --
    Il n'y a pas de Planet B.
    1. Re: I'm so glad I stayed up for this by bsDaemon · · Score: 1

      I bet itâ(TM)s really Gentoo but they futzed with the compiler optimizations then built it in a cluster so they could finish before the heat death of the universe.

    2. Re:I'm so glad I stayed up for this by jmccue · · Score: 0

      and in other news, when I get out of bed tomorrow I will see this big bright yellow circle in the sky, seems it is always there, every day.

      (I had no mod points for you, so had to say something dumb)

    3. Re:I'm so glad I stayed up for this by 93+Escort+Wagon · · Score: 2

      You obviously don't live in the Pacific Northwestern US.

      --
      #DeleteChrome
    4. Re:I'm so glad I stayed up for this by The+Cynical+Critic · · Score: 1

      Lucky you, where I live it only becomes visible when I'm at work and stops being visible when I'm still at work.

      --
      "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
    5. Re:I'm so glad I stayed up for this by shaitand · · Score: 1

      It's Intel's optimized compiler but as a distro this time!

    6. Re:I'm so glad I stayed up for this by Jane+Q.+Public · · Score: 1

      Correction: COASTAL Pacific Northwest.

      The other side of the Cascades is still the PNW. And a good part of it is semi-arid desert.

    7. Re:I'm so glad I stayed up for this by 93+Escort+Wagon · · Score: 2

      The other side of the Cascades is still the PNW. And a good part of it is semi-arid desert.

      Ha! There’s nothing east of the Cascades. Spokane and Omak are imaginary places - they’re make-believe, just like Narnia or Canada.

      --
      #DeleteChrome
    8. Re:I'm so glad I stayed up for this by tburkhol · · Score: 1

      The general result isn't particularly surprising, but the scale is. In some of those tests, the 'conventional' distros are 3x slower.

    9. Re:I'm so glad I stayed up for this by Anonymous Coward · · Score: 0

      Narnia is not real?

  4. This is not surprising by Anonymous Coward · · Score: 3, Insightful

    A hardware company that optimises software to run on its chipsets. No voodoo here. Whilst I dislike Intel for a number of reasons, not the least of which is the recent Minix debacle, this is nothing to ponder over.

    I'll stick with FreeBSD and Red Hat/CentOS.

  5. Why? by Anonymous Coward · · Score: 0

    Is the kernel different? Libraries?

    Just a different compiler, or compiler options?

    This is such a stupid article.

    1. Re:Why? by hcs_$reboot · · Score: 1

      Because Clear Linux must be less demanding in terms of system resources consumption, thus having more resources (cpu, IO...) let to applications.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    2. Re:Why? by ClickOnThis · · Score: 2

      I thought perhaps it might be Intel's ICC compiler doing a better job of optimizing for Intel CPUs than GCC does. If that were true, and the distro is compiled with it, then that could explain the performance differences.

      But now I doubt that because: (a) what I can find on compiler benchmarks indicates that GCC and ICC are about on par with each other; and (b) Clear Linux has GCC selected as the default anyway.

      I wonder if some crucial parts of the system were re-coded to work better on Intel systems, at the expense of cross-compatibility (or AMD products.) That might explain why it does better across so many tools, both compiled and interpreted.

      --
      If it weren't for deadlines, nothing would be late.
    3. Re:Why? by RickRussellTX · · Score: 2

      Intel's ICC compiler doing a better job of optimizing for Intel CPUs

      Um, yeah, optimizing , that's what we'll call it. Optimizing , I like the sound of that.

    4. Re:Why? by Anne+Thwacks · · Score: 4, Insightful
      Who give a toss about the speed?

      What we need is a Linux distro that values stability and does not keep pissing around with UIs (and APIs) with no warning.

      Ok, I will go back to my BSD cave right now!

      --
      Sent from my ASR33 using ASCII
    5. Re:Why? by Anonymous Coward · · Score: 0

      Intel's ICC compiler doing a better job of optimizing for Intel CPUs

      Um, yeah, optimizing , that's what we'll call it. Optimizing , I like the sound of that.

      Yah, too many have forgotten about those little shenanigans from Chipzilla

    6. Re:Why? by Anonymous Coward · · Score: 0

      Because Clear Linux must be less demanding in terms of system resources consumption, thus having more resources (cpu, IO...) let to applications.

      And spying.

    7. Re:Why? by hummassa · · Score: 1

      Who give a toss about the speed?

      Whomever wants to serve a lot of pages, for instance, without breaking the bank in the process?

      --
      It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
    8. Re:Why? by Agripa · · Score: 1

      Yah, too many have forgotten about those little shenanigans from Chipzilla

      Too many forgot that the shenanigans never stopped. The court decision just required them to post an ambiguous unsearchable notice that they might be deliberately disabling optimizations on non-Intel processors.

  6. Cloud? by Anonymous Coward · · Score: 0

    You have to connect to their cloud to use their distro? If so, no thanks.

  7. Boots faster ... by drnb · · Score: 4, Insightful

    Boots faster ... ok, how often do we reboot linux ? :-)

    1. Re:Boots faster ... by Anonymous Coward · · Score: 5, Funny

      Every time systemd crashes.

    2. Re:Boots faster ... by IckySplat · · Score: 2

      Exactly; Boot time dick measuring is a waste of time and leads to abominations like SystemD.

      --
      Help! help!, the termites are eating my DRAM!!!
    3. Re:Boots faster ... by Anonymous Coward · · Score: 0

      That's funny, because I've never seen it crash.

    4. Re:Boots faster ... by Cyberax · · Score: 4, Interesting

      Every time I start a new VM on Amazon EC2. Since you're paying by a second now, boot time matters if you're launching hundreds of instances.

    5. Re: Boots faster ... by Anonymous Coward · · Score: 0

      The VMs I use at work boot in about 10 seconds. Because there's a 3 second boot delay there on purpose. If we were using a public cloud we could cut it down to around 5 seconds by eliminating the delay timer and dumping some unused cruft.
      The applications are what take a long time to become ready, not the OS.

      But if you're really that worried about spinning up a shitload of systems, then there are a lot of other ways to tackle the problem where boot time of the OS simply isn't relevant.

      Tl;dr boot time isn't an issue if you're not a moron.

    6. Re:Boots faster ... by drnb · · Score: 1

      Every time I start a new VM on Amazon EC2. Since you're paying by a second now, boot time matters if you're launching hundreds of instances.

      If boot time is not a trivial inconsequential amount of time, you are doing VMs wrong.

    7. Re:Boots faster ... by keltor · · Score: 2

      In a horizontally scaled application, it can be important to how responsive the horizontal scaling is. A big enough issue that we're now using resumed images instead of actually booting them.

    8. Re:Boots faster ... by Anonymous Coward · · Score: 0

      Found someone who doesn't use systemd.

    9. Re:Boots faster ... by gravewax · · Score: 1

      If after running up hundreds of instances boot time is anything but pocket change in the process you have completed fucked up your systems.

    10. Re:Boots faster ... by Anonymous Coward · · Score: 0

      Boots faster ... ok, how often do we reboot linux ? :-)

      Exactly. And yet the systemd fans continue to claim that it's vitally important.

    11. Re:Boots faster ... by Anonymous Coward · · Score: 0

      But SystemD probably saved you a good 3 minutes over the past 3 years!

    12. Re:Boots faster ... by 93+Escort+Wagon · · Score: 4, Insightful

      But SystemD probably saved you a good 3 minutes over the past 3 years!

      He's given that three minutes back - and more - if he's ever needed to check the binary logs SystemD generates.

      --
      #DeleteChrome
    13. Re: Boots faster ... by K.+S.+Kyosuke · · Score: 1

      systemd has its own fans now? How much heat does it generate?

      --
      Ezekiel 23:20
    14. Re:Boots faster ... by Anonymous Coward · · Score: 0

      If after running up hundreds of instances boot time is anything but pocket change in the process you have completed fucked up your systems.

      Might be a Redhat system. A Linux overenginered so completely that systemd helped the startup time.

    15. Re: Boots faster ... by Anonymous Coward · · Score: 0

      Boots faster ... ok, how often do we reboot linux ? :-)

      Given this is about enterprise distributions, I would say at least once per day.

    16. Re:Boots faster ... by Anonymous Coward · · Score: 0

      Boots faster ... ok, how often do we reboot linux ? :-)

      As often as there are security updates to the kernel, glibc or any other widely used system library
      It’s still the best way to clean up SCSI devices that have been removed
      When the OOM killer randomly hits a few system services
      RAC reboots Oracle server for reasons
      Random kernel panic from some one-off driver/firmware mismatch or god only knows what
      Support team does what was literally asked in the ticket and “reboots” an application.

      so with a thousand or so systems, someone’s looking at a boot screen a few times a week easy in practice, probably every day even.

    17. Re:Boots faster ... by Anne+Thwacks · · Score: 1
      RAC reboots Oracle server for reasons

      Not sure why the Royal Automobile Club is involved in this, but I think we see the problem here:

      You are using Intel.

      If you want uptime, use OpenBSD on Sparc64: you boot once every 6 months - when you upgrade. Other updates don't need a reboot, and you won't have kernel panics.

      --
      Sent from my ASR33 using ASCII
    18. Re: Boots faster ... by ls671 · · Score: 1

      Well, it depends which hardware it runs on!

      Anyway, at first, it was negligible. But lately, it has started to grow exponentially to produce more and more heat, thus the requirement for its own fans:
      https://en.wikipedia.org/wiki/...

      --
      Everything I write is lies, read between the lines.
    19. Re:Boots faster ... by shaitand · · Score: 4, Informative

      My problem with systemd is that the only itch it legitimately scratched was parallel startup and we've had that option with alternatives that more or less just replace init since the early 00's. Nothing about that problem required a massive overreaching full binary system that is completely counter both to the concept of Unix (small utilities with narrow and well defined specific functions) and Linux (every aspect of the system is text and can be treated as text). As far as I can tell a handful of people in love with Unix(TM) OS who had sour grapes about the fact that their preferred systems are far less popular used this itch as an excuse to shove their crappy one-size-fits-all binary crap down the throats of Linux users just so they can feel more at home.

    20. Re: Boots faster ... by Anonymous Coward · · Score: 0

      As often as they appear? No, as often as required after testing to ensure nothing gets broken.

    21. Re:Boots faster ... by Anonymous Coward · · Score: 1

      But if you can walk away from ms windows and introduce linux in the server room despite the phb, how much easier to walk away from SystemdD

      The windows crowd needed somewhere to go and something to do. They've stormed the citadel and the citadel is lost. But on the plus side they've self identified and now we know who they are and where they are and who they're paid by.

    22. Re:Boots faster ... by Anonymous Coward · · Score: 0

      So you are claming that openbsd on x86 is unstable.

    23. Re:Boots faster ... by Anonymous Coward · · Score: 0

      On average every about 300 days for me. I'm thinking about buying an UPS again, damn those blackouts.

      And what does the 10-30s boot time matter compared with the 5 minute raid sync, journal replay and fsck?

    24. Re: Boots faster ... by Zero__Kelvin · · Score: 2

      I'm glad you found yourself. It's the first step to self improvement!

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    25. Re: Boots faster ... by Zero__Kelvin · · Score: 0

      Great way to show that you have literally no clue about systemd, what it does, or why.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    26. Re:Boots faster ... by Anonymous Coward · · Score: 0

      Faster boot times is mainly for the purpose of vms and cloud servers. Being able to pull up a new vm from scratch faster makes spinning up more servers on demand that much less painful. When you pay by the cycle/time/bit transfer, starting them when necessary and turning them off when not saves money.

    27. Re: Boots faster ... by Zero__Kelvin · · Score: 0

      I gather math isn't your bailiwick.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    28. Re:Boots faster ... by Anne+Thwacks · · Score: 1

      No. I have not used OpenBSD in a serious way on Intel since about the P4, so I am not in a position to comment.

      --
      Sent from my ASR33 using ASCII
    29. Re:Boots faster ... by Anne+Thwacks · · Score: 1
      When you pay by the cycle/time/bit transfer

      I thought that went out the window when Ross Perot left IBM!

      --
      Sent from my ASR33 using ASCII
    30. Re: Boots faster ... by Anonymous Coward · · Score: 0

      As often as they appear? No, as often as required after testing to ensure nothing gets broken.

      Sure, so counting test systems... someone is watching something reboot repeatedly, rolling snapshots back and reinstalling a patch until they figure it out, after which it gets pushed into this or the next production patching cycle.

      So yes, frequency of Linux reboots increases when we include test systems and patch testing, duh, have a cookie.

    31. Re: Boots faster ... by PPH · · Score: 1

      Much more now that they built Bitcoin mining into it.

      --
      Have gnu, will travel.
    32. Re: Boots faster ... by Anonymous Coward · · Score: 0

      Why the hell would you "boot" 100s of instances? You're doing it wrong.

    33. Re:Boots faster ... by MangoCats · · Score: 1

      Seriously now, for a moment, systemd on Raspbian seems to slash boot time by about half - which is important when you power the Pi on...

    34. Re:Boots faster ... by thegarbz · · Score: 1

      the only itch it legitimately scratched

      The only itch of *yours*. Parallel startup is actually the feature many cared about the least and is also why the alternatives saw little adoption.

      By the way most people don't give a shit about "concept of Unix", that is something completely incompatible with the workload and interaction between various parts of a modern OS.

    35. Re: Boots faster ... by IckySplat · · Score: 1

      SystemD is either a SysV init replacement or it's not. If it's not then it shouldn't be PID 1; If it IS then it shouldn't be doing all the crap that it currently does.

      --
      Help! help!, the termites are eating my DRAM!!!
    36. Re: Boots faster ... by Anonymous Coward · · Score: 0

      Exactly. Thus proving the point that boot time is irrelevant. In your own case, your image boots only once, regardless of how often you resume it.

    37. Re: Boots faster ... by Zero__Kelvin · · Score: 0

      Most of systemd does not run as PID 1. You should forget all the ridiculous shit you "learned" about it here. It makes you sound foolish.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    38. Re:Boots faster ... by dave420 · · Score: 1

      You might want to check out journalctl, as apparently you're doing it incredibly wrong.

    39. Re:Boots faster ... by shaitand · · Score: 1

      "Parallel startup is actually the feature many cared about the least"

      Given that it is the only notable feature beyond looking similar to the solution used in some Unix(TM) distributions I'm curious what features "many" cared about.

      "By the way most people don't give a shit about "concept of Unix", that is something completely incompatible with the workload and interaction between various parts of a modern OS."

      I work on large enterprise systems moving petabytes of data, tens of thousands of connections per second per host on multiple large pools of servers, web nodes, load balancers, app nodes, storage systems, datacenter scale virtualization and "cloud" stacks on a daily basis and have in one form or another for over a decade. That "concept of unix" has worked well during all that time and offers dramatically increased flexibility for uses nobody has thought of until the moment you need them, so I'm curious how it is "completely incompatible." The concept of one big binary blob for micro-optimization and better integration is the concept of windows and it works so well that every notable advance of windows in the last ten years has been to copy *nix functionality because it falls apart every time you need something the developers didn't think of which is generally every day in a large environment.

      I also love a definition of the term "modern OS" given that the OS has been mature technology for about 20 years with only incremental tuning improvements and implementation of features that already exist in other OS's. If anything can truly be called a "modern OS" these days it would be an absolutely minimal OS skin to sit inside a vm and run an application since it the OS is redundant overhead instantiated many times in a virtual environment and it has been discovered that beyond 10k concurrent connections the OS context switching limitations become the bottleneck and so more and more OS functionality is being shifted to the application level.

    40. Re:Boots faster ... by thegarbz · · Score: 1

      Given that it is the only notable feature

      I'm not reading the rest of your comment beyond this as you have just made it clear that you know nothing about systemd much less the problems it set out to solve, how it goes about solving them, and the technical reasons for its very wide spread adoption.

    41. Re:Boots faster ... by shaitand · · Score: 1

      In other words, your argument is "nu uh."

    42. Re: Boots faster ... by Anonymous Coward · · Score: 0

      Evers day and sometimes more often. I am not running my desktop machine 24/7.

    43. Re:Boots faster ... by thegarbz · · Score: 1

      I'm not making any argument other than the fact that yours are irrelevant in the face of very big and public technical debates on the adoption of systemd.

      Whatever you think is behind it doesn't matter. You're just some voice on the internet and don't represent the adopters, technical committees, or the large user base.

    44. Re:Boots faster ... by shaitand · · Score: 1

      "I'm not making any argument other than the fact that yours are irrelevant in the face of very big and public technical debates on the adoption of systemd."

      That is an assertion, not a fact or even an argument, and you provide no logical or factual support for it.

  8. a stripped-down derivative by Anonymous Coward · · Score: 1

    is faster at cherry-picked benchmarks than its full-sized parent. how much did this ad cost?

  9. because of backdoor cpu by Anonymous Coward · · Score: 0

    thanks to intel's hidden cpu

  10. Eh? by Anonymous Coward · · Score: 0

    Who the fuck cares about a) a benchmark discussing âoeenterpriseâ and consumer CPUs and b) any enterprise discussion about performance these days? Enterprise (compute) hardware is so over overpowered these days, adding performance to an application these days involve adding virtual CPUs to a VM.

    1. Re:Eh? by Anonymous Coward · · Score: 0

      adding performance to an application these days involve adding virtual CPUs to a VM

      I usually just virtually overclock the existing one and if necessary add virtual water cooling.

    2. Re: Eh? by Anonymous Coward · · Score: 0

      Maybe your enterprise app doesn't need more power. Mine does. I appreciate that Intel has a team devoted to tuning performance for those of us who need more. And since you seem unaware, they've been doing this for many many years. This isn't a new thing from Intel.

    3. Re: Eh? by Anne+Thwacks · · Score: 1
      Maybe your enterprise app doesn't need more power. Mine does.

      Perhaps a port from Javascript to C might help.

      --
      Sent from my ASR33 using ASCII
    4. Re: Eh? by shaitand · · Score: 1

      Shill or worse, someone developing on javascript or java.

      This isn't anyone giving more power to enterprise apps. This is a vendor producing something to create the illusion their chips are faster than the other guy. For the record, in the real world, the other guy currently has the better chips both in Enterprise and on the desktop.

    5. Re:Eh? by Anne+Thwacks · · Score: 1

      Can I email my surplus virtual heat to you for you to dispose of?

      --
      Sent from my ASR33 using ASCII
  11. serious results by Anonymous Coward · · Score: 0

    Good on Intel for doing this. Theses are some serious improvements. There are two major implications to be drawn from these results 1) other distros can and will take notice, 2) AMD and ARM should take notice. Let the performance war begin, it will benefit everyone.

    1. Re:serious results by shaitand · · Score: 2

      Results are cooked benchmarks. This is about as legitimate as the ICC nonsense.

      AMD is actually shipping the superior chips ATM and for the first time in at least a decade on the desktop and possibly ever in the Enterprise space. This is Intel throwing out some FUD because THEY took notice of that.

  12. someone doesn't know the meaning of enterprise by gravewax · · Score: 1

    sounds to me someone doesn't know what the meaning of the word enterprise is if the highlighted comparison in the summary is it "booted fastest"

    1. Re:someone doesn't know the meaning of enterprise by Anonymous Coward · · Score: 0

      Cloud systems spin up VMs in response to load. Yes, boot time matters.

  13. Not really earth shattering here... by ctilsie242 · · Score: 1

    The car analogy would be a fast motorcycle versus mainstream, general purpose sedans. Yes, Clear Linux is faster. I could possibly make a Linux distro which is faster than RHEL, and other mainstream distros as well, especially if I tossed the initial RAMdisk image, and booted to some sort of init at once.

    I appreciate Intel making Clear Linux available, and for IoT devices, a fast boot time is a must... but other than Clear Containers, I'd like to see more security features. IoT is where a focus in security should be, and Intel should have enough security stuff available and trivial to use.

    1. Re:Not really earth shattering here... by Anonymous Coward · · Score: 0

      I'd say CentOS is more like a commercial diesel truck. It is meant to run forever with lots of regular maintenance and be a work horse for businesses.If you want to do all your service/maintenance at the dealer then it is RHEL.

  14. Why the fuck are you not using a snapshot then? by Anonymous Coward · · Score: 0

    Just load a memory snapshot that has finished booting from permanent memory, and do the few leftover hardware initializations, and off you go.

    Not that anyone with a sane mind would ever run any of his stuff on a system that isn’t under his physical control. Let alone under Amazon's!
    But hey, insanity is the second name of Sillycunt Valley.

    1. Re:Why the fuck are you not using a snapshot then? by Anonymous Coward · · Score: 0

      Sillycunt Valley

      So, you're 12. Bravo.

  15. Booting speed! by Anonymous Coward · · Score: 0

    Number ONE priority for an Enterprise system!

    1. Re:Booting speed! by greenwow · · Score: 0

      Hey that helps once a year or so when we reboot our Red Hat systems.

    2. Re:Booting speed! by Anonymous Coward · · Score: 0

      You reboot your Red Hat system once a year? Boy is Mr Red Hat going to be mad when he hears about your lack of faith.

    3. Re:Booting speed! by shaitand · · Score: 1

      This old high uptime is good myth just won't die. We'll file it along with using swap memory is bad and running everything out of physical ram is betterer. These are myths that even *nix guys who should know better won't let go of. Planned regular reboots are proper maintenance, they catch problems with the boot configuration on the host. Didn't set that daemon for startup? Forgot to save that static route or firewall change? Didn't make a udev rule to give that usb device a fixed name for your configs? Planned reboots less than a month from when those changes are made is when you want to find out. You know, while the people who made the changes still work there and can speak up or silently double check their work when they find out you rebooted it. What are you collecting uptime counts for, merit badges or something?

      The last thing you ever want is to break a route when rebooting to reset the rootpw to fix some other issue two or three years down the line. Especially if it is needed for something infrequently used that won't be noticed until long after that reboot is out of your brain.

    4. Re: Booting speed! by Anonymous Coward · · Score: 1

      This old high uptime is good myth just won't die.

      True.

      We'll file it along with using swap memory is bad

      True.

      and running everything out of physical ram is betterer.

      Depends on what you're doing. Often the file cache lets us use all physical memory usefully without causing the standard issues that 100% memory use might otherwise.

      Planned regular reboots are proper maintenance, they catch problems with the boot configuration on the host.

      True.

      Didn't set that daemon for startup? Forgot to save that static route or firewall change? Didn't make a udev rule to give that usb device a fixed name for your configs?

      You're doing it WRONG. Never, ever make direct changes like that. ALWAYS update the config first, and restart the appropriate service (or reboot to start a daemon, I'll half give you that).

      Planned reboots less than a month from when those changes are made is when you want to find out. You know, while the people who made the changes still work there and can speak up or silently double checktheir work when they find out you rebooted it.

      Hire better people. They'd better call it out. I don't have issues with people making mistakes. Try and hide it, and if I find out, there WILL be hell to pay.

  16. Compare it against Gentoo by knorthern+knight · · Score: 4, Interesting

    > but leverages its speed from optimized compiler settings, specially
    > built libraries capable of AVX instructions on supported systems,
    > a specially tuned kernel configuration, and other optimizations/patches.

    I see your "Clear Linux" and raise you Gentoo with

    CFLAGS="-O2 -march=native -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
    CXXFLAGS="${CFLAGS}

    and also appropriate CPU_FLAGS_X86 for the CPU, as well as the same kernel tuning used for Clear Linux. I dare Phoronix to try that. It should be a much closer horse race.

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user
    1. Re:Compare it against Gentoo by Anonymous Coward · · Score: 0

      I thought you gentoo kiddies finally grew up.

    2. Re:Compare it against Gentoo by Anonymous Coward · · Score: 0

      I did that once for a non-profit organization, but working with a large mix of hardware from different eras (some of them are 1st-gen Celeron) forced me to settle for compiling to the lowest CPU in the group and have them all participate in distcc. The CPU-optimized speed benefits are essentially lost.

    3. Re:Compare it against Gentoo by Anonymous Coward · · Score: 0

      Don't forget -fmerge-all-constants

    4. Re:Compare it against Gentoo by Anonymous Coward · · Score: 0

      No, it's more than that. Clear Linux includes AutoFDO, which collect profiling info and does feedback-directed optimizations.

  17. Never used Internet Explorer? by raymorris · · Score: 1

    You assume newer is always faster. That's not necessarily so. Internet Explorer got slower and slower with each version. Vista was slower than XP. In the Linux world, going from 32-bit to 64-bit makes it slower, all other things being equal. It's entirely *possible* than a newer systemd will slow things down as it gets bigger and bigger - compare an old, small editor such as vi/vim vs the newest MS Word. Newer and bigger sure can be slower.

    On the other hand, as someone else commented:
    > Linux distro produced by Intel, tuned by Intel for latest Intel hardware, works fastest of any distro on latest Intel hardware.

    1. Re:Never used Internet Explorer? by shaitand · · Score: 1

      In some cases that is true but RHEL is also tuned for stability rather than speed out of the box.

    2. Re:Never used Internet Explorer? by Dutch+Gun · · Score: 1

      You assume newer is always faster. That's not necessarily so. Internet Explorer got slower and slower with each version. Vista was slower than XP.

      And every version of Windows since Vista has been faster and leaner. Firefox, after years of bloating up, just got a substantial speedup.

      In these cases, it was determined that *performance* was a feature worth chasing after, and a lot of effort went into optimizing and streamlining code. I certainly agree you can't always assume that newer is faster, but it can be if it's a priority for developers.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    3. Re:Never used Internet Explorer? by jellomizer · · Score: 1

      It really depends where you look.
      Moving from 32 bit to 64 bit seemed slower because it has double the size of the opt-code stored in the executable. So more time is taking transferring data from slowest part of the computer. However once the data is there, especially with larger numbers, and the extra RAM so much more can be done. How we use computers had also changed over the past 40 years too. We use to run one application. What was called the OS was mostly a boot loader and when the Application was executed the OS sometimes had nearly been pushed out of memory. (for those without hard disks may remember the prompt when exiting an application "Please insert a disk with Command.com") Because nearly all of DOS was pushed out of the PC to run an application.
      Then they are features that we get that we don't think twice about.
      Lotus 123 for DOS worked on an 80x25 text display. If we were to use it today we would consider it nearly unusable. just because you wouldn't be able to see enough data. However this 80x25 screen meant that there is much less processing to show values on the screen.

      That said... A lot of app makers try to keep on selling new versions and adding more features that we really don't use. On a server we had a legacy app with Excel 95 on it. We had to upgrade it for security concerns, but before that. Excel 95 really flew on a modern PC, and there are not too many features that I really care to use on the new version. It would be nice if application makers, just put in add ins vs upgrading the core software. So I can keep basic Excel 95 on a new system, without adding features that I don't need.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    4. Re:Never used Internet Explorer? by bluefoxlucid · · Score: 1

      That's actually a handwave statement. Scientifically, how do they know what they've selected is more-stable?

      I've had more data loss on CentOS boxes than anything else. There's also an issue with e1000 NICs where the in-kernel driver crashes every couple days if under moderate network load, so you need to build an out-of-tree driver--and RedHat doesn't do out-of-tree drivers because it's "not stable". To get networking to work again, you have to reboot, as the driver won't unload.

      The solution was to switch to Ubuntu.

    5. Re:Never used Internet Explorer? by hummassa · · Score: 1

      8-bit spreadsheets used to present 40x22 or less... :-)

      --
      It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
    6. Re:Never used Internet Explorer? by shaitand · · Score: 1

      "Scientifically, how do they know what they've selected is more-stable?"

      Scientifically, they wouldn't because the OS is logic and many layers away from even the applied science. But there are many ways you can objectively select for stability over performance. For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun. Compiling to a lower common denominator means a lower chance of strange errors and failures running against various platforms out there both because they are more likely well supported and because the optimizations are far far more heavily field tested.

      "I've had more data loss on CentOS boxes than anything else."

      If you have enough data loss happening in an Enterprise environment to even begin to think you can assess one OS vs another you are definitely doing something wrong. Without knowing anything else I can already tell you are doing something wrong by associating data loss with the OS rather than the FS or your data handling procedures.

      "There's also an issue with e1000 NICs where the in-kernel driver crashes every couple days if under moderate network load, so you need to build an out-of-tree driver--and RedHat doesn't do out-of-tree drivers because it's "not stable". To get networking to work again, you have to reboot, as the driver won't unload."

      I have no idea what version CentOS/kernel/etc you were running against with this issue but e1000 nics are extremely common and I can't say I've run into any significant issues with them. Since the entire world isn't on fire fixing this issue I suspect it's more likely a bug that impacts your particular e1000 variant than the chipset at large but that is speculation so I could certainly be mistaken. Honestly, most things are VM's these days so I would just pick a different virtual nic.

    7. Re:Never used Internet Explorer? by bluefoxlucid · · Score: 1

      For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun.

      Actually, allocating a larger buffer doesn't necessarily incur more performance overhead. On-stack buffers are identical performance cost at any size; however, thread stacks don't grow, so a larger on-stack buffer can lead to crashes depending on usage--something that hit one of the JSON libraries which was allocating 128k buffers. Large malloc() calls at the user level may search through a tree by size, thus not incurring a specific performance overhead or savings compared to small malloc() calls; smaller calls cause more fragmentation in the end, so can be the source of a performance penalty in the long run; and particularly-large malloc() calls just call mmap() for an anonymous mapping. Large mmap() calls have to find contiguous memory, although the kernel operates in such a way as to avoid too much fragmentation.

      "Chance of overrun" isn't really a thing. Either you have an overrun error or you don't. Overrun errors are exploitable, and buffer size is generally tuned to not require enlargement. Code is supposed to validate if this is true.

      So no, none of these things affect performance or stability in a general sense. In an embedded system, you might; but then you're not working with these general-purpose server OSes.

      If you have enough data loss happening in an Enterprise environment to even begin to think you can assess one OS vs another you are definitely doing something wrong

      RedHat has pushed things as stable before they were ready--notably GlusterFS, which is not ready for prime time, at all. It's fundamentally-flawed.

      There's also been a habit of RHEL of just upgrading things mid-release, calling it a "point release", and overwriting configuration files. Really read your release notes before running updates--although I've had a cluster destroyed by a complete removal of certain configuration utilities from the repositories, replaced with others, which wasn't mentioned in the release notes.

      I have no idea what version CentOS/kernel/etc you were running against with this issue but e1000 nics are extremely common and I can't say I've run into any significant issues with them.

      It was CentOS 6. It was a known issue. I found the fix on RHEL's own bugzilla, WONTFIX. The particular variant is the e1000e chipset, although it's been noticed that e1000 in the version they were using in early 2016 was broken as all hell. It was common in hardware servers used by a service provider with whom we worked. I think it was the 2.6.32 kernel release they were stuck on for a long time that we were using; I don't remember it being fixed by the time I decommissioned that CDN. It's been a long time since I cared.

      The lesson I learned from 4 years of administrating RHEL and 5 of administrating Ubuntu was to never use RHEL (CentOS). It's a broken, bloated, unstable, unpredictable, and outdated piece of shit.

      The truth is RedHat claims that the old, old, old, old, ancient versions of software they use, with lots of distributor-maintained patches backported into them--and plenty not--are "stable". They claim stability because, in part, the environment doesn't change: it's the same software for 2 decades. That's as long as they don't decide to upgrade from Apache 2.0 to Apache 2.2 at a point release, with zero days of support between making the release and cutting off official support for anyone running Apache 2.0 on their OS. Basically, if RHEL 7.2 has Apache 2.2 and RHEL 7.3 has Apache 2.4, RHEL 7.2 is unsupported the moment 7.3 comes out; if you call and say Apache is doing funky stuff, they'll tell you to upgrade to the latest Apache 2.4 and call them back.

      Compare that to Ubuntu: they won't change software versions in a release, with

    8. Re:Never used Internet Explorer? by shaitand · · Score: 1

      "Actually, allocating a larger buffer doesn't necessarily incur more performance overhead. On-stack buffers are identical performance cost at any size; however, thread stacks don't grow, so a larger on-stack buffer can lead to crashes depending on usage--something that hit one of the JSON libraries which was allocating 128k buffers. Large malloc() calls at the user level may search through a tree by size, thus not incurring a specific performance overhead or savings compared to small malloc() calls; smaller calls cause more fragmentation in the end, so can be the source of a performance penalty in the long run; and particularly-large malloc() calls just call mmap() for an anonymous mapping. Large mmap() calls have to find contiguous memory, although the kernel operates in such a way as to avoid too much fragmentation.

      "Chance of overrun" isn't really a thing. Either you have an overrun error or you don't. Overrun errors are exploitable, and buffer size is generally tuned to not require enlargement. Code is supposed to validate if this is true."

      lol, I've woken up a coder. Maybe I shouldn't have used the term "overrun" because it does tend to imply something specific, namely a bug allowing you to coax code into writing outside the intended memory allocated for a variable. You are right this is often, though not always, exploitable.

      We are talking about an entire operating system distribution full of tunable values of all sorts implemented with a wide range of algorithms I was using the term in a very very generic sense. I'm trying to avoid getting into the weeds on a specific example. If your contention is that my assertion they tune for stability out of the box is "handwaving" because they can't tune for an exact use case then I will concede that point. If you are asserting that what I really meant, that tuning values for disk, filesystem, network stack, process limits, etc can and do in many cases impact stability and performance and that it is not possible to select values that are more cautious defaults at the expense of leaner defaults I do not concede that point.

      "The lesson I learned from 4 years of administrating RHEL and 5 of administrating Ubuntu was to never use RHEL (CentOS). It's a broken, bloated, unstable, unpredictable, and outdated piece of shit."

      I've administered both Ubuntu and RHEL for a bit longer than that and in many distinct roles in enterprise environments. Sorry, I can't agree with you on all points here. Outdated I will definitely grant you and you make solid points about rhel package management. I always generally begin with CentOS minimal for most servers and add what I need from there and the result is usually more trim than Ubuntu. For most tasks I don't have stability issues with either one but updates break things more often on the Ubuntu side and for a typical server running some off the shelf enterprise package rhel is generally closer to what I need. For instance, iptables is without question the best tool for firewall configuration on Linux. Most importantly it is universal. Ubuntu isn't set to save iptables configuration and restore it on reboot out of the box. Yes it is easy to set up. Still this is more than a little annoying since you need it on EVERY box for almost any purpose. RHEL also gives you a reasonable starting config, most of the time you can just add in a couple lines for whatever ports you need to listen on and be done with it. If I have someone new working under me I can just have them copy and paste, change the transport and the port, so easy none of these "easy firewall" alternatives using iptables under the hood are simpler.

      When doing custom development/scripting I certainly bang my head against the oldness and security considerations of rhel far more than ubuntu and when supporting other developers they do the same and it is exactly what I want since it helps prevent them from playing with the latest and greatest crap in the developer toolbox. The last thing you want is a production enterprise application running a custom

    9. Re:Never used Internet Explorer? by bluefoxlucid · · Score: 1

      If you are asserting that what I really meant, that tuning values for disk, filesystem, network stack, process limits, etc can and do in many cases impact stability and performance and that it is not possible to select values that are more cautious defaults at the expense of leaner defaults I do not concede that point.

      Well, no, the system won't crash or fail from these things. Also, RHEL has the same out-of-the-box process limits and filesystem tunables as everything else out there--and, for the longest time, raising the max file handles would actually cause a bug to show up in glibc (Drepper spent a decade telling everyone who wanted support for more than 1024 open files in a specific glibc function that they were morons; people worked around it, although it caused Apache to crash now and then). The per-thread stack is also up to the library; musl libc cuts that in half from the defalt--the value used by RHEL, Ubuntu, SuSE, Mint, and everything else using glibc--which caused some bugs to show up in a lean json library, but nobody turns it up in any distribution, and doing so wouldn't really cause a performance issue.

      For most tasks I don't have stability issues with either one but updates break things more often on the Ubuntu side and for a typical server running some off the shelf enterprise package rhel is generally closer to what I need. For instance, iptables is without question the best tool for firewall configuration on Linux. Most importantly it is universal. Ubuntu isn't set to save iptables configuration and restore it on reboot out of the box.

      Yeah, a few deficiencies there; it's not unstable though. In other news, RHEL is not Windows Server and doesn't come with an Active Directory Domain Controller running out-of-the-box.

      RHEL also gives you a reasonable starting config, most of the time you can just add in a couple lines for whatever ports you need to listen on and be done with it.

      Debian systems have always come with default working configurations, and they structure them. Apache on RHEL has a giant main httpd.conf, while any Debian derivative splits it out. Some services don't even work on RHEL when you start them up; that happens on Ubuntu, too, for a few services requiring you to hit /etc/default/foo.conf and set ENABLED=true. For the longest time, RHEL also came with tons of open ports, while Debian systems came with no running services.

      I don't do any programming on these systems; I do a lot of system administration and a lot of system engineering--taking the software out there and putting it together to accomplish some business goal. If you want to drag your head through lots of stuff paywalled behind Access.Redhat.Com and fragments of mailing list discussions hinting at what the solution might be, go RHEL; if you want things to work out of the box so you can make your way toward a working configuration, go to a Debian derivative. Also you might want to set up Gitlab and track your Ansible configuration in there (and run Ansible from an alpine Docker container so you can keep its config self-contained) if you have a lot of systems to administrate.

    10. Re:Never used Internet Explorer? by Anonymous Coward · · Score: 0

      I've had more data loss on CentOS boxes than anything else.

      Please keep your ignorant anecdotes to yourself. CentOS is based on one of the oldest, most stable and most widely used Linux distros in the world. The only way this is possible is through your own world-class ineptitude and everyone knows it. You just look stupid saying things like this.

    11. Re:Never used Internet Explorer? by shaitand · · Score: 1

      "Yeah, a few deficiencies there; it's not unstable though."
      "Well, no, the system won't crash or fail from these things."

      I think we have different definitions at play. In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break. In the real world I need exclusion lists and run through a test environment but unless there is a major revision change there is very very rarely a problem updating the system in RHEL between service packs. Even full service pack updates almost always go smoothly. I definitely can't say this with Ubuntu, especially Ubuntu systems I don't solely control as people who prefer this distribution are far more likely to be running things that were installed by a method other than the binary package manager or debs not explicitly made for Ubuntu.

      "Also you might want to set up Gitlab and track your Ansible configuration in there (and run Ansible from an alpine Docker container so you can keep its config self-contained) if you have a lot of systems to administrate."

      Actually a fan of Gitlab as well. I was really talking about more and more of the developer driven tools in general which are so rapidly changing and unstable that the binary packages are hopelessly out of date or non-existent because developer driven tools are driven by developers and they don't have the administration experience to realize proper package management integration is critical to avoiding bitrot. Ansible, Salt, Chef, Puppet, they are all very powerful but also very dangerous... they essentially turn your entire environment into a homegrown script or set of homegrown scripts so we can assume they will be as stable and well maintained over time as homegrown scripts typically tend to be. I wonder why we all started embracing the philosophy of using supported off the shelf solutions and avoiding homegrown scripts anywhere possible...

    12. Re:Never used Internet Explorer? by bluefoxlucid · · Score: 1

      In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break.

      My experience has been that security updates on RHEL may bring breakage, while on Ubuntu I just leave the automatic updater on.

      RHEL "service packs" are bullshit. A RHEL "Service pack" is allowed to be equivalent to an Ubuntu major release: they can upgrade the versions of any software they choose, and often do drop software from the repos, add new software, and upgrade the major version of software. When they do this, they immediately cease supporting the old software. Again: RHEL replaced Apache 2.2 with 2.4 in one point release--an update which slightly changed the syntax of httpd.conf, causing Apache to fail because I needed to enable a module to use IfEnv in 2.4 but didn't in 2.2.

      Debian-style releases are as follows: if it worked on the day of release, it will work after any update. No breaking changes.

      especially Ubuntu systems I don't solely control as people who prefer this distribution are far more likely to be running things that were installed by a method other than the binary package manager or debs not explicitly made for Ubuntu.

      I've always found it hard to get packages in RHEL. I had a mix of CentOS's repos, EPEL, RepoForge, ElRepo, and a few other third-party repos to get Perl modules which were available in Ubuntu Universe. We also had locally-installed Perl and PHP modules through manual building, Pear, or CPAM. This stuff broke frequently, and I tended to fight back against polluting the system with non-repo software (and the mix of repositories occasionally caused breakage itself, but less-so).

      It's been pretty rare I couldn't find something in Ubuntu's repositories.

      Central management with Ansible or Puppet does give the advantage of making an entire process repeatable and auditable by putting it all in one place. Without these, you're doing untracked changes and manual processes with more potential human error. There aren't really a lot of good options when you get into the weeds, although bringing a proper mower helps, for all the problems that itself brings.

  18. The benchmark I want to see by Anonymous Coward · · Score: 0

    "The number of applications that work out of the box"
    Without fiddling around and googling stack overflow
    This is especially a pain whenever you try to get the newest version of something.

  19. huh by buddyglass · · Score: 1

    Strange that the two benchmarks mentioned are "enterprise performance" and "boot speed". If you care about the former you probably don't care about the latter, and vice versa.

  20. Enter the world of Intel-specific Linux by bradley13 · · Score: 1

    Stupid benchmarks

    Some of the benchmarks run seem pretty stupid, for the goal of evaluating Linux for the enterprise. Whether your Perl script compiles in 0.001 or 0.002 seconds? Really? On others, it had more to do with packages, for example, PHP/5 was slower than PHP/7. That's not really relevant: If you need PHP/7, you'll install it.

    That said, Clear Linux does come in ahead on virtually all of the benchmarks listed. Clear Linux is by Intel, and these tests are all running on Intel processors. I suspect this advantage comes down to some very special drivers: better instruction set usage, cache optimizations, etc. Stuff that could be made available to the Linux kernel, but that Intel has kept for their particular Linux flavor.

    --
    Enjoy life! This is not a dress rehearsal.
    1. Re:Enter the world of Intel-specific Linux by Bert64 · · Score: 1

      I doubt anything is being kept back by Intel, it's just that Intel target a higher common denominator...
      Binaries in centos or rhel are compiled for a generic amd64 cpu, and therefore can't take advantage of features present in newer processors. A gentoo install targeting the specific hardware being used to test would probably beat both of them.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  21. But is it faster than Firefox Quantum?!? by Anonymous Coward · · Score: 0

    We have to know!

  22. Even Linux suffers from bloat by Anonymous Coward · · Score: 0

    I remember when Ubuntu was considered a lean OS alternative to Windows. Lately the bloat from bad decisions in terms of trying to add in too much eye candy has left many Linux versions with similar issues as Windows. Its actually come down to Windows 10 being more friendly to weak hardware then some Linux distro's. Nice to see Clear Linux address the fact a lot of business want the basics and not all the crap that consumers want. Wish this would rub off on Windows 10 which also loads up a ton of stuff in boot that is not needed. Be nice if a OS goes back to just being a OS.

  23. ClearLinux is basically "enterprise" Gentoo by Anonymous Coward · · Score: 1

    I love Gentoo and have used it frequently but if you're a sysadmin managing hundreds or thousands of servers on hardware that's not homogenous (different CPUs, different NICs, etc) it's a non starter. Building, testing and distributing multiple builds is a drain on company resources that has to be offset by performance gains. That's a hard sell. There are plenty of companies that use Gentoo but it's generally for very specific functions and not company wide. ClearLinux lets companies get the benefits of Gentoo on a wider range of platforms then they could support themselves and without that overhead (the price you pay is Intel lock-in).

    1. Re:ClearLinux is basically "enterprise" Gentoo by Anonymous Coward · · Score: 0

      If you are a sysadmin running thousands of servers your complexity is mostly handled by configuration management and you couldn't care less what distro is running underneath. The only thing you care about is if it runs well on all of your heterogeneous (opposite of homogeneous) hardware. Clear Linux won't won't run at all on most of it. Talk about a non-starter.

    2. Re:ClearLinux is basically "enterprise" Gentoo by Anonymous Coward · · Score: 0

      "Enterprise" OP: Please try to understand what you are responding to before you respond:

      1. Gentoo has to be compiled and the OP specifically talked about optimizing CFLAGS for the CPU. That's not "configuration management". That's custom builds for each machine type. Sure you push them with a config management tool but someone still has to build and test them.

      2. "ClearLinux won't run at all on most of it." So basically you've never used ClearLinux and have no idea what you're talking about.

      Thank you for your contribution to the conversation.

  24. What's the point of... by Anonymous Coward · · Score: 0

    ...superior performance if you have to install a commercial grade AC unit in your computer room simply to keep from roasting youself to death due to the copious heat an AMD processor emits?

    1. Re: What's the point of... by Anonymous Coward · · Score: 0

      Keep up with your memes. AMD Ryzen is the one operating at normal temps while Intel Covfefe Lake is the 95W housefire.

  25. DITCH INTEL w/ME altogether by Anonymous Coward · · Score: 0

    Recent facts MUST make INTEL liable (yes in court) for any incident related to ME

    As a matter of fact sold as a "security" it turns out to be quite the other.

    To say the least.

    Ditch INTEL - any distro based on a combination free of such thing is welcome

  26. bend over, TELEMETRY boner prolapses your anus by Anonymous Coward · · Score: 0

    https://clearlinux.org/feature...

    it's a "feature", just like the IME, creepy uncle intelirapist prowls your underwear drawer

  27. This is old news. by Mysticalfruit · · Score: 1

    We've know for a LONG time that Intel's compiler can do tricks with x86 that the GCC guys could only dream of.

    --
    Yes Francis, the world has gone crazy.
    1. Re:This is old news. by Agripa · · Score: 1

      We've know for a LONG time that Intel's compiler can do tricks with x86 that the GCC guys could only dream of.

      The major trick is disabling optimizations when the CPU does not report GENUINEINTEL.

  28. Gentoo users are like Hatchables by Dareth · · Score: 1

    Gentoo users are like Hatchanimals. You have to wait for them to emerge to see what you get.

    --

    I only look human.
    My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
  29. Re: Linux by Anonymous Coward · · Score: 0

    We prefer "God Emperor" to "Dear Leader", thanks. :^)

  30. Oracle UEK by emil · · Score: 1

    Instead of CentOS, it would have made more sense to benchmark Oracle Linux, running both the UEK (Unbreakable Enterprise Kernel), and the RHCK (Red Hat-Compatible Kernel).

    I've never tried running the UEK on CentOS/RedHat/Scientific Linux. I'm assuming it's built with GCC and runs equally well on AMD vs. Intel.

  31. So it boots real fast... by whitroth · · Score: 3, Insightful

    Who, other than someone running it on a laptop, gives a flying fart how fast it boots?

    I've got an older (580 G5) that takes SEVENTY SECONDS before the POST logo appears. I've got HBS (honkin' big servers) that take minutes before it gets to the grub boot. And the servers, we're working on a once-a-month maintenance window, to reboot to new kernels, etc.

    Show me how it outperforms other distros running, say, a very large R job, or modeling protein folding. Then I'll be interested....

    1. Re:So it boots real fast... by thegarbz · · Score: 1

      I've never seen a VM instance take more than a split second to post. Who* uses servers these days? Throw them off a cliff and into the clouds.

      I'm only being partially facetious here. Spinning up an entire OS instance for a short activity is rapidly becoming a thing that we are interested in doing these days, and shaving that boot time counts when you're paying by the second.

  32. So which distro... by Anonymous Coward · · Score: 0

    ...for maximum performance on a box that will not connect to net?

  33. Don't benchmark CentOS "out of the box" by MSG · · Score: 1

    Red Hat's "tuned" package will set the CPU frequency governor to a high-performance governor if the word "server" or the word "computenode" appear in the system's CPE identifier. CentOS's CPE contains neither, so a low-performance profile is selected by default.

    Details are available here: http://jperrin.org/centos/boos...

    The short version is that CentOS "out of the box" will always benchmark poorly, and you must run "tuned-adm profile throughput-performance" to get a high performance profile.

  34. thanks to.. by Anonymous Coward · · Score: 0

    "MINIX Inside®"

  35. Telemetry by Anonymous Coward · · Score: 0

    So that distro has Telemetry.... hmm lets just see how fast the community rejects that... I switched from Windows 10 to linux to get away from that crap and I'm sure many others are doing or about to do the same...