Intel's Clear Linux Distribution Offers Fast Out-Of-The-Box Performance (phoronix.com)
An anonymous reader writes: In a 10-way Linux distribution battle including OpenSUSE, Debian, Ubuntu, Fedora, and others, one of the fastest out-of-the-box performers was a surprising contender: Intel's Clear Linux Project that's still in its infancy. Clear Linux ships in an optimized form for delivering best performance on x86 hardware with enabling many compiler optimizations by default, highly-tuned software bundles, function multi-versioning for the most performant code functions based upon CPU, AutoFDO for automated feedback-direct optimizations and other performance-driven features. Clear Linux is a rolling-release-inspired distribution that issues new versions a few times a day and is up to version 5700.
Intel's own compiler in many cases generated code that runs 15%-20% faster than code compiled under GCC.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
"In support of the goal to provide an agile Linux* distribution that rapidly detects and responds to quality issues in the field, Clear Linux for Intel® Architecture includes a telemetry solution, which notes events of interest and reports them back to the development team."
https://clearlinux.org/feature...
Clear Linux is a rolling-release-inspired distribution that issues new versions a few times a day and is up to version 5700.
Big deal. Firefox will catch up with that shortly.
It must have been something you assimilated. . . .
Upon seeing the description of function multi-versioning I thought of three distinct ways to use that for malware in as many minutes, and the ideas are still coming. (And I don't write malware, so someone in the field would probably think of more, faster,)
It's also a great way to make competitors' processors look bad: Detect their processors and fall back on the minimalist defaults or even hand them "grinched" code that does worse, or contains odd kickers. Or just don't support THEIR accelerations. Also: Don't support their implementations of YOUR accelerations.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Its nice to see this however we really should, in general, have a better way for Linux programs to be able to easily take advantage of the CPU extensions available without recompile. There are dozens of permutations of CPU extensions, so distributing a binary for each permutation is not feasible. Full from source compilation takes too long for many users. Having Linux binaries being able to use the CPUs most advanced features has been a problem. One solution that I favor is to take a page from AS/400, in a variation of that, in each library file, put a copy of the machine code, but also a copy of the abstract syntax tree, the last compilation phase. If the binary is moved to a new CPU, the AST is run through the code generator to regenerate the machine code in the file according to the options the CPU supports. All done in situ. This is much better than storing a copy a binary for each CPU permutation in a library file. It makes things easy to use and is faster than compiling from source as the lexer and parser phase does not need to be repeated.
The rankings in individual benchmarks were all over the place; a composite of those benchmarks is only valid for some theoretical "average" workload that's the average of all the workloads each individual benchmark is supposed to represent; almost nobody is bound to have a workload that resembles that "average".
In fact the whole "shooutout" scenario is silly because Clear Linux is a container-centric distro. It makes no sense at all to compare it to general purpose distros like Ubuntu and plain vanilla Centos then leave out Red Hat/Centos's Atomic Host flavors.
In any case if performance is your paramount concern, then "out-of-the-box" performance is bound to be irrelevant to you because you'll be compiling from source with your own choice of compiler and flags, as well as fiddling with all those bells and whistles exposed in the /sys interface. What's interesting would be an exploration of why various distros did better or worse on individual benchmarks.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Just because something is (fairly) new, we cannot safely conclude that it is better than traditional methods. Unfortunately, fashion is far more powerful than judicious evaluation.
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?"
- Larry Ellison at Oracle OpenWorld, September 2008.
I am sure that there are many other solipsists out there.
As soon as I see the words "rolling release", I swicth to another piece of software.
Let me guess: you didn't understand Katamari Damacy.
To me, an extra 0.1% performance increase, even if I am only imagining it to be faster, is certainly worth one day a week recompiling all of the latest packages from source code.
If 1 part in 1000 runtime improvement is worth 1/7 of one machine's time, then you must be running a cluster of at least 142 identical servers.
One solution that I favor is to take a page from AS/400, in a variation of that, in each library file, put a copy of the machine code, but also a copy of the abstract syntax tree, the last compilation phase.
You're thinking of distributing LLVM bitcode. Google was thinking of the same thing when designing PNaCl.
No matter what distro I use for my desktop, I always use the latest pf-kernel, with bfq scheduler, low latency, cpu optimizations, etc. I can overload the desktop, and music/video is smooth as silk, and compiling is faster. Its a real world performance boost.
I'd love to see how a pf-kernel does vs stock on each distro.
There's one thing about systemd that I don't understand: If it is terrible (and I have no doubt that it is, from its philosophy to its implementation), why have almost all of the major Linux distributions moved to it?
Love sees no species.
Clear Linux also comes packaged with spyware
From the 1st paragraph at that link:
That's what Canonical (Ubuntu) and a few others think, and it's wrong. Clever wording like "We send only minimal stuff without your knowledge" and "it's for your own good and so that we can make it better" don't change the default state of the software in question. I refuse to load Ubuntu on anything because Canonical installed their software in an always on state and hid it from consumers. I will never ever trust them again, just like I have not trusted Microsoft after their shenanigans (yeah, you have to go back pretty far for me trusting MS).
Very simply put, if it's always on and users don't have big flashing lights warning them at first boot that it's going to be on, then it's intentionally hiding the software. You can claim good intent all you want, but if you tried to hide from the start do you think I'll believe your intent is altruistic? "Fool me once", and all those quotes.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
The only person using false drama is you. I never stated that it was an evil plot, you did that. You also attempted to claim I said it, which is bullshit.
Telemetry requires a consumer dig through details to find it, and to turn it off. How hard is it to do like Redhat does, and give a prompt to users during the install which asks them if they want the service on or off? Don't bother stopping to think about why Redhat does this as opposed to just turning it on, because that may be more "false drama".
You claim to agree with my position, but then type what a shill would type. It is obvious why _you_ remain hidden in anonymity and the person who is fighting for anonymity does not hide.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Because maybe it isn't as terrible as it seems?
Sure, there's a lot of NEW things in it, but isn't Linux all about new? And things are different, which gets people tied up in knots.
And the other thing is, people don't realize the shortcomings of the ever-popular SysVInit - I mean, why do we emulate in SysVInit, init? Init is a daemon manager - in practically all Linux distros, it's managing getty (which spawns login). And when you end your session getty dies, and init duly restarts it, like a good daemon manager does. And you can have daemons kill and restart based on runlevel. This is built in, standard default behavior of init. Yet everyone creates elaborate scripts that do the same thing, or even programs that spawn a child that does the service, and when it crashes or dies, it respawns it. Something init already does. Init even does rate limiting - if a daemon quits too quickly, init stops starting it for a few minutes.
SystemD formalizes this as a fundamental part of the system - init really should manage daemons, not a rough collection of shell scripts that try to mimic its behavior.
Granted, things are more complex, like how PulseAudio made audio more complicated. But then you realize that audio IS complicated these days, especially on a desktop OS. There was a time you could open /dev/dsp and that's it, but those days are long gone, because users have multiple audio devices and not only that, but those audio devices can change suddenly. And no, the hardware can change - perhaps they're listening on wireless headphones through Bluetooth, but then they want to switch to speakers which require switching the underlying hardware, and so forth.
And initialization and startup is similar.
In the end, what's happening to Linux is what Android did to Linux. Android has its own init system (init manages daemons, like it should), its own graphical system, its own audio layer and much more.
And it was done because the demands of mobile make it purposely complex and consumer expectations ensure it isn't easy.