A Rust-Based TLS Library Outperformed OpenSSL in Almost Every Category (zdnet.com) 213
A tiny and relatively unknown TLS library written in Rust, an up-and-coming programming language, outperformed the industry-standard OpenSSL in almost every major category. From a report: The findings are the result of a recent four-part series of benchmarks carried out by Joseph Birr-Pixton, the developer behind the Rustls library. The findings showed that Rustls was 10% faster when setting up and negotiating a new server connection, and between 20 and 40% faster when setting up a client connection. But while handshake speeds for new TLS connections are important, most TLS traffic relies on resuming previously negotiated handshakes. Here, too, Rustls outperformed the aging OpenSSL, being between 10 and 20% in resuming a connection on the server-side, and being between 30 and 70% quicker to resume a client connection. Furthermore, Rustls also fared better in sheer bulk performance -- or the speed at which data is transferred over the TLS connection. Birr-Pixton said Rustls could send data 15% faster than OpenSSL, and receive it 5% faster as well.
Stop Already (Score:1, Insightful)
Stop pushing your Rust crap.
Re: (Score:2)
Stop pushing your Rust crap.
But, but... they can push it 37% faster ...
Re: (Score:2)
Probably because it was better coded. Associating languages with good programming skills is silly. Also, everybody knows that opensll has become a mess to maintain just like anything else that's got age.
Re: Stop Already (Score:1)
No! Solutions should always be pushed. If you don't like the solution attack the merits, not the exuberance.
Re: (Score:2)
Re: (Score:2)
And break 100% quicker.... (Score:2, Insightful)
Because, lets face it, not as tested as OpenSSL.
Re: And break 100% quicker.... (Score:1)
True, but it's written in a memory safe language, so exploits like heartbleed are far less likely to be possible.
Re: (Score:1)
>and definitely not too smart.
That was unnecessary.
Re: And break 100% quicker.... (Score:5, Informative)
Care to retract your statement? Go research why heartbleed shared private memory and learn why your comment is ignorant of the facts.
Heartbleed shared private memory because they erroneously malloc()ed a larger buffer based the 'length' field of the malformed request, and copied in a smaller amount of data from the 'payload' of the request. Then they sent the whole buffer, including whatever garbage memory values were present in the extra buffer space.
It's hard to figure out how you could do that in Rust without explicitly using the "unsafe" keyword. They simply don't provide a mechanism that allows you to access uninitialized memory.
In a Rust implementation, I see two possibilities as most likely: 1. You copy the payload into an empty Vec<u8>, then when you try to send "length" bytes, the program panics due to the resulting index violation, and you fix the bug before shipping the code. Or, 2. You preallocate "length" bytes into a Vec<u8> like OpenSSL did. But to do this, you need to call "resize()", which requires you to provide the filler value. This would initialize the memory and erase any old info.
Re: (Score:3)
And thus is inherently slower, in contradiction to TFA...
You don't know until you profile it. At least in case 1, the runtime safety could be implemented by the compiler in as little as one extra write and one compare instruction for the entire packet transmission, relative to the manual C approach. In many cases, on modern superscalar CPUs those extra instructions would execute in parallel with the data copy operation and would incur no runtime overhead at all, as opposed to the half nanosecond extra to get your reply that you might naively assume.
Leave out security, get speed. Duh. (Score:2, Insightful)
And features too.
Of course you're gonna be faster,.if you leave out all the corner cases that grew over the years and are precisely the reason why the library is reliable and trusted!
What an idiotic headline.
Look! My ROT256 byte encryption is even faster than AES! --.--
Re: (Score:2)
What evidence do you have that it "leaves out all the corner cases"? Yes, Rustls doesn't support deprecated SSL versions, but OpenSSL *shouldn't* either.
Bring it on (Score:1)
More TLS libraries, please. Diversity matters.
But is it as secure? (Score:4, Insightful)
I don't give a fuck about 5% faster if it doesnt benefit from the decades of bugfixes that OpenSSL has.
Re: (Score:1)
Yeah. If it wasn't for all those decades of bugfixes stuff like Heartbleed might happen. It's not like the fact that Rust can't compile such fuckups has any value, right?
Re: (Score:1)
I don't give a fuck about 5% faster if it doesnt benefit from the decades of bugfixes that OpenSSL has.
That seems like a silly attitude to have, on the face of it.
OpenSSL initial release: Hooray!
Bug found.
"Okay, we fixed it. New release!"
Bug found.
"Fixed again! New release!"
Fast forward decades...
New project initial release: We learned from all OpenSSL's mistakes and avoided them
Slashdot AC: "Well it must be crap, it's new and doesn't have decades of bugfixes"
That's.. that's just not a logical response.
Re: (Score:2)
How about (Score:3)
LibreSSL?
Re:How about (Score:5, Insightful)
I imagine they didn't post any comparisons to LibreSSL because they wouldn't have looked good.
I know I'm certainly gonna trust a product from the OpenBSD guys a lot more than some random Rust developer. Theo and company have a long, proven track record which demonstrates they understand security better than almost anyone else.
Buggier too? (Score:5, Insightful)
Various versions of OpenSSL have been audited by a third-party, has Rustls?
Many, many people have been running OpenSSL for quite a long time and bugs have been found and corrected. Why should I have any confidence in this new project?
Re:Buggier too? (Score:4, Insightful)
Seriously, this is my concern. It's easy to be faster when you're doing things wrong, and there are SO MANY ways to screw up crypto. Sure, Rust is "memory safe," but that doesn't mean that it doesn't pick predictable keys, or that it doesn't leave itself vulnerable to side-channel attacks in some way, or any of the other numerous ways crypto can go wrong.
People don't use OpenSSL because it's fast, they use it because it's well-tested.
Re:Buggier too? (Score:4, Informative)
Seriously, this is my concern. It's easy to be faster when you're doing things wrong, and there are SO MANY ways to screw up crypto. Sure, Rust is "memory safe," but that doesn't mean that it doesn't pick predictable keys, or that it doesn't leave itself vulnerable to side-channel attacks in some way, or any of the other numerous ways crypto can go wrong.
That's precisely what I was thinking, but the side channels in particular. I know crypto implementations do things intentionally in a suboptimal way so all paths take the same time and power in order to prevent leaking of the keys.
Re: (Score:2)
We thought it was "well-tested" before we found Heartbleed, too. Hours run in production do not necessarily correlate to correctness. That said, the performance numbers are just that: performance numbers. No one who knows anything about software is suggesting that everyone delete OpenSSL today and run out and install Rustls as their production TLS library. Of course, there's a Catch-22 somewhere there: OpenSSL wouldn't be as good as it is today if people didn't use it and contribute to its development, find
Re: (Score:2)
Rustls and Rust are developed in the open. Are you saying they should be kept private until they've been in production for years and had extensive testing? Then they wouldn't benefit from the contributions of the community that could make the library more useful, sooner. Of course, if you adopt a library that isn't even 1.0 yet as the SSL library for your banking application, whoever approved that to go into production should be fired. The performance numbers are not accompanied by a suggestion that everyon
Re: (Score:2, Funny)
Various versions of OpenSSL have been audited by a third-party, has Rustls?
Many, many people have been running OpenSSL for quite a long time and bugs have been found and corrected. Why should I have any confidence in this new project?
Because Rust is a socially-aware, woke language.
And not trusting it implicitly makes you a RAAAACIS'!!!!
Re:Buggier too? Needs better testing (Score:2, Interesting)
I'm glad someone said the obvious. OpenSSL has dark magic shit. It waits for randomized times, in weird places, all because the various side channel issues that have been found over the years.
This highlights a larger issue: for important libraries like these, we have no safe means to move away because we have not consolidated the body of attacks into a testing suite.
Re: Buggier too? Needs better testing (Score:1)
Re: Buggier too? Needs better testing (Score:2)
Re: (Score:2)
Despite many eyes over many years we are still finding bugs in OpenSSL. The appeal of using Rust is that the compiler itself prevents several classes of serious security bugs. That's why it's news (at least among security pros) to see widespread security critical libraries implemented in Rust.
Re: (Score:2)
Despite many eyes over many years we are still finding bugs in OpenSSL. The appeal of using Rust is that the compiler itself prevents several classes of serious security bugs.
Because OpenSSL continues to support new features.
The appeal of preventing some kinds of security issues isn't necessarily outweighed by heavily audited code with many eyeballs on it. Rust does not guarantee against design problems, and what OpenSSL does is extremely complex.
I can't tell you how crazy it is that some people don't recognize that a lot of security comes from design and auditing, and no magic compiler bypasses those requirements.
Re: (Score:2)
Because of new features? On the contrary, we are still finding holes in OpenSSL that are many years old.
If you think the mechanisms Rust uses to prevent security issues are "magic," you aren't familiar enough with the technology to comment on it.
Re: (Score:2)
I can't tell you how crazy it is that some people don't recognize that a lot of security comes from design and auditing, and no magic compiler bypasses those requirements.
It is rather amusing that design and auditing is used as an argument FOR using openssl.
openssl is a hobby project that the author created in order to learn about large number arithmetic.
Re: (Score:2)
Various versions of OpenSSL have been audited by a third-party, has Rustls?
Yes and look where that got them, a security vulnerability so bad that a fork started in an effort to clean up the software. OpenSSL is a horrendous patchwork of legacy garbage. There's no reason to consider it secure just because it has gone through an audit. There is however reason to think that RusTLS may actually be *less* buggy thanks to less complexity and less garbage patchwork.
Re: (Score:3)
Track record is a fair concern. That's something that rustls can only acquire via real-world usage over time. Fortunately that track record is growing (e.g. we use rustls in our Web service).
However, Rust gives rustls a big security advantage compared to OpenSSL or any other library written in C/C++. It's well-known that Rust ensures memory safety for the vast majority of the rustls code (that does not use 'unsafe'), but there's more to the story. Rust also prevents data races. Rust code built in debug mode
Re: (Score:1)
However, Rust gives rustls a big security advantage compared to OpenSSL or any other library written in C/C++. It's well-known that Rust ensures memory safety for the vast majority of the rustls code (that does not use 'unsafe'),
This is something I really hate. The blanket assumption RUST is memory safe when any particular codebase may well not be. As a minimum ring makes calls to assembler code that is not at all memory safe. Who knows what other tradeoffs are made at a low level within libraries. There should be a qualification regime to communicate the safety level otherwise the only prudent course of action is to operate under the assumption no rust code is memory safe.
but there's more to the story. Rust also prevents data races.
Compile time checking is only available for uninterestin
What about security? (Score:2)
Speed isn't a bad thing per se, but it's not the most important thing in a cryptography library. What about side channel resistance?
Also, OpenSSL isn't the be all and end all of SSL libraries. How does it compare to e.g. LibreSSL, which should also be faster than OpenSSL with all of the crap it's stripped out?
Re: (Score:2)
Feature set matters, too.
AFAIK only OpenSSL is truly usable... though that's stretching the word "usable" a bit... outside
run of the mill use cases. In particular, it would be interesting to know if this library could
be used in a mature EAP authentication server implementation, some of the qualifications
for which are mentioned here:
http://lists.cistron.nl/piperm... [cistron.nl]
Third Party Testing (Score:1)
Re: (Score:2)
> Its like trusting the government, you just don't.
I would trust government studies way more than industry studies, at least in US, generally speaking.
Re: (Score:1)
> Its like trusting the government, you just don't.
I would trust government studies way more than industry studies, at least in US, generally speaking.
So you trust the Democrats and Republicans? Show me where this is a good idea.
Re: (Score:2)
So you trust the Democrats and Republicans? Show me where this is a good idea.
Captain Obvious says: Politicians are not the government, and government workers are not politicians.
Re: (Score:1)
Re: (Score:2)
Also, it is an open source benchmark. What is there to not trust? Improve it if you see a defect. Rust is not even a commercial tool, nor are the TLS implementations. I think you are sticking in ideology where it does not belong.
Didn't RTA, but the only question I have is whether it is a comprehensive library that can replace OpenSSL. Lightweight implementations do perform better because they don't cover everything.
Re: (Score:3)
You must be very young. You have only one scoffing retort when you find yourself flat footed. But sadly, you are not.
https://slashdot.org/comments.... [slashdot.org]
"You must be younger than 10 because of the way you are acting."
https://slashdot.org/comments.... [slashdot.org]
"You must be young. As most that trust too much are."
https://slashdot.org/comments.... [slashdot.org]
"Arent you the moron, you must be younger than I."
All from the first page of your comment history. Your UID is much too small for such overuse of a juvenile retort.
Re: (Score:1)
You realize that the author is always the first one to publish his idea right? You can't have third party testing if the first party never publishes because everyone will just complain that it isn't third party tested. It's a fucking open source project. No one is asking you to switch today, yet all everyone can seem to do is shit on him because he hasn't paid foxit to certify it.
Did I swear at all in this? You must really have a sore spot as a keyboard warrior, I was just making a point about any creator. If I created something I would be touting it as the best thing since sliced bread. You are easily swayed.
What about the one thing that matters most? (Score:2)
Namely security? OpenSSL has seen extensive independent review. What has Rustls seen? Performance is irrelevant if security is not there.
Re: (Score:2)
OpenSSL has seen extensive independent review.
And it's still riddled [cvedetails.com] with security flaws [openssl.org]. That's the trademark C Disadvantage.
Re: (Score:1)
Bullshit. You seem to be unable to read that CVE table. Also bullshit on any "C Disadvantage". The only disadvantage that C has is that is exposes bad coders more obviously.
Re: (Score:2)
Bullshit.
LibreSSL [libressl.org] was forked from OpenSSL because OpenSSL's security was so bad they gave up on trying to fix it. You're very plainly not across these issues. Don't let your C zealotry blind you to obvious realities.
Re: (Score:2)
Re:What about the one thing that matters most? (Score:5, Insightful)
The only disadvantage that C has is that is exposes bad coders more obviously.
... and that's a pretty big disadvantage, considering that 90% of coders are bad all the time, and the remaining 10% of coders are bad some of the time.
Anyone who thinks they are a good coder all the time is fooling themselves.
Re: (Score:2)
I do agree on that. But it is not a disadvantage of the language. And, unfortunately, these bad coders make about as severe and often worse mistakes in _other_ languages as well and Rust is no exception.
Re: (Score:2)
But it is not a disadvantage of the language.
Of course it is. The tool has failed to anticipate and account for the practical realities of software engineering. It is not fit for purpose.
Re: (Score:2)
Of course you are wrong. And you also seem to be lacking any real understanding of software engineering. C is fit for purpose. But people like you are probably not.
Re: (Score:2)
Difference? (Score:5, Interesting)
Re: (Score:2, Informative)
If you read the linked pages, you’d see that the openSSL is doing unneeded buffer copies & discarding then re-doing some crypto operations, which account for various parts of the worse performance.
Re: (Score:2)
Sweet! That should definitely speed things right the hell up. Those Rust programmers really know their shit.
Re: (Score:1)
Unfortunately for you, conclusion jumping isn't an Olympic sport yet. You could easily qualify.
Re: (Score:2)
Does it support fewer features so is smaller?
This. OpenSSL is a patchwork of support for everything. If the kitchen sink ran code, OpenSSL would have some support for it hacked in an ugly way. Remember Heartbleed? LibreSSL come out of that to clean up the OpenSSL code base in an attempt to improve performance and security. After deleting 100,000 lines of code they established that nothing at all had changed in the software. Sure it didn't work on VMS or Windows 95 anymore, but really.
Conflict of interests (Score:3)
So the developer of this library also created some benchmarks in which this library performs better than a legacy library?
I would be a lot more impressed if the benchmarks were created and performed by an independent developer.
Also, how much did this strip from the original implementation, and does it still perform all needed functionalities?
Also, how do we know this new code doesn't contain vulnerabilities? Rust may protect against buffer overflows, but it will do nothing against using cryptographically weak algorithms, or things like timing attacks.
The 10% or so speed improvements are not worth it if it's not 100% secure and feature complete.
Re: (Score:2)
and does it still perform all needed functionalities?
What do you consider a needed function? VMS support? Socket support for Windows 9x? OpenSSL would add support for encryption on an abacus if you could automate it. Remember the LibreSSL project started with OpenSSL and removed 100,000 lines without breaking anything.
I'm not surprised a newly coded alternative performs better.
Re: (Score:2)
What do you consider a needed function? VMS support? Socket support for Windows 9x? OpenSSL would add support for encryption on an abacus if you could automate it. Remember the LibreSSL project started with OpenSSL and removed 100,000 lines without breaking anything.
Personally couldn't select LibreSSL if I wanted to given it doesn't support features I need: DTLS, TLS-SRP, TLS 1.3.
Remember at the time LibreSSL was initially started thumbing thru changes having a good laugh at all the shit they were putting back after having just torn out. A reflection of general cluelessness and poor planning.
It's one thing to redesign and architect a better library from existing code but really all LibreSSL ever amounted to was a poorly maintained fork of OpenSSL with a bunch of shit
Re: (Score:2)
Sorry, I know I'm not suppose to read the article, (Score:5, Informative)
The difference between OpenSSL and rustls appears to be thanks to an extra copy in the main data-path in OpenSSL
OpenSSL has one more memory copy operation, so the question is why? Is it a security risk, or just an optimization that hasn't been implemented? Given the age of the OpenSSL code, my money would be it is some kind of security risk.
As for receiving the results are very close and the author notes that rustls implemented a few hardware accelerated optimizations which would account for the difference. So not really a "our language is better" kind of thing, just a we found an optimization. It might be worth taking a look at the rust code and seeing if those changes could be made to the existing OpenSSL packages.
Re: (Score:1)
But looking at the results you see this note when comparing sending speeds:
The difference between OpenSSL and rustls appears to be thanks to an extra copy in the main data-path in OpenSSL
OpenSSL has one more memory copy operation, so the question is why? Is it a security risk, or just an optimization that hasn't been implemented? Given the age of the OpenSSL code, my money would be it is some kind of security risk.
My money is on side channel attack mitigation. A lot of effort has been made that the functions execute in fixed time so you can't deduce code path information from execution time. This is something rust wont help you with. It also prevents speedups.
Re: (Score:2)
OpenSSL has one more memory copy operation, so the question is why? Is it a security risk, or just an optimization that hasn't been implemented? Given the age of the OpenSSL code, my money would be it is some kind of security risk.
Given that it's written in C, my money would be that it's an artifact of a memory management strategy.
In a language without GC, you are confronted with memory allocation lifetime issues all the time. And sometimes it's just easier to make an extra copy.
Why is it faster? (Score:2)
I would be shocked if it didn't (Score:2)
OpenSSL is a poster child for bloat, cruft, and the weight of accumulated decades. I'm not really blaming it, because that's just what happens over time, but nobody expects it to be performant.
It's good to know the a Rust version that does the same useful bits actually is faster, but it would be interesting to see it compared to something like mbed or the other rewrites that have appeared since the giant OpenSSL crisis.
And? (Score:2)
Anyone who's ever read the OpenSSL code won't be surprised.
When I looked at it a few years ago (before their last major feck-up) I'd never seen such a mess of undocumented, incompletely described, un-maintainble junk in my life.
I realise that speed is second to security, but you could rewrite OpenSSL in Microsoft BASIC and probably churn out something quicker, more reliable and more readable.
Re: (Score:2)
When I looked at it a few years ago (before their last major feck-up) I'd never seen such a mess of undocumented, incompletely described, un-maintainble junk in my life.
Which is the stated reason why the OpenBSD guys forked the codebase and started LibreSSL.
OS X / MacOS switched to LibreSSL several years back. I know there's a lot of antipathy in the Linux community against the OpenBSD group, but I wouldn't be surprised if the big Linux distros let their pragmatism override their biases and eventually adopt it as well. It's not GPL licensed, but neither is OpenSSL.
You mean to tell me (Score:2)
And 70% more side channel attacks (Score:1)
There is a reason a proper SSL implementation is slow: all code paths need to be equally slow in order to prevent side channel attacks. Make half of them faster, and the program is more efficient. Also you can read its operations like a book.
"Faster" can actually be a security hole (Score:3)
One of the attacks against encryption systems is to see how long it takes to fail to decrypt in various circumstances.
If every single decryption failure takes the same amount of time, no information is leaked when someone starts battering the library. However, if it fails faster when the first character of the key is bad, then all an attacker has to do is try combinations until they get a fast response ... and now they have the first part of the key. Repeat on the second, then the third, and so on.
In that scenario, cracking the key drops from X**N (some time raised to the power of how long the key is) down to X*N (the same time multiplied by the length of the key).
I have no idea if this particular Rust library has that problem. But I am skeptical of anything so utterly focused on speed. Just ask Intel about Specter.
Oops (Score:2)
... until they get a slower response ...
Sigh (Score:2)
Outperformed in one category (Score:2)
What will it look like in ten years? (Score:2)
After ten years of security patches, how will it perform?
It's not pure Rust (Score:4, Insightful)
If you look at the developer's GitHub page, it says it has a dependency on a thing called "ring" for cryptography. The ring page [github.com] says
This is not quite the triumph for Rust the story claims.
Re: (Score:2)
Re:Breaking News (Score:5, Insightful)
I'm Shocked! Shocked I tell you!
Rightfully so. C is often admired for its performance, the only downside being that you need to take care of memory management yourself. Also, OpenSSL is probably the most commonly used TLS library out there written by a couple of mathematicians who used every trick in the book to get it to perform in the fastest way possible (security turned out to be less of a concern...). If there's now a new library written in a language touted for its memory safety, which is also faster than the most commonly used library written in C, then I think this achievement is quite admirable.
I'm not a Rust user myself but I'm happy to give credits where they're due.
Re:Breaking News (Score:5, Informative)
WolfSSL (Written in C) as an example, blows it out of the water with speed increases of up to 35-40% depending on cipher.
It really isn't a surprise at all that a new implementation written in anything native outperforms it. That's not to say it isn't cool that an SSL library was written in a "safe" language, but benchmarking the performance against OpenSSL isn't saying anything important in this conversation.
Re: (Score:2, Interesting)
OpenSSL is also as you said: "written by a couple of mathematicians" I.e. Not programmers. And it shows [github.com].
OpenSSL is a horrible mess to even look at let alone maintain, sins with heavy usage of GOTO, and has areas literally copy pasted where a function call or a proper if than else would have been sufficient and a better design. (Remember heartbleed?)
I'm not surprised at all that some other library is faster, regardless as to the language it's written in. Any modern compiler is going to have a hard time try
Re: (Score:2)
OpenSSL is also as you said: "written by a couple of mathematicians" I.e. Not programmers. And it shows [github.com].
Doesn't that code look mostly machine-generated? No self-respecting mathematician, lazy as hell as we all are, would write all that.
Re: (Score:3)
C is my primary language, and when I need TLS, my first stop is usually mbedTLS.
OpenSSL is not some awesome piece of wonder-software that has high performance, it is just a mature library that is easy to use and has a lot of features. That implies it is bigger and slower, which it is.
Re: (Score:3)
So I'm willing to applaud them now (when they get the exposure), and simply rant more when it turns out it's buggy as hell and/or totally unfit for production.
Also, I also didn't read tfa, so my response was merely based on the headline. I'm sure you'll understand
Re: (Score:1)
Sorry, but I won't EVER applaud anybody "just because they say so".
They have written something and they themselves have said "it's fantastic".
NOTHING to applaud anybody for.
Re:Great (Score:5, Informative)
Why?
https://benchmarksgame-team.pa... [debian.net]
https://benchmarksgame-team.pa... [debian.net]
Rust and C/C++ are in the same league - zero overhead abstractions. Swift isn't - has performance trade-offs for safety.
Swift vs. Go is a reasonable comparison.
Re: (Score:2)
The point he is trying to make is that 64 bit pointers being bigger are less performant because (amongst other things) you can only get half as many in the cache as 32 bit pointers.
What he is neglecting to mention is that Java achieves 32 gigs with 32 bit pointers by assuming that everything is 8 byte aligned. To actually reference the data, Java has to convert the 32 bit pointer to a 64 bit pointer and then shift it right by 3 bits. Admittedly, that operation can be done pretty quickly on the assumption th
Comment removed (Score:5, Insightful)
Re: In C, it'll be 2x as fast, and free of SJW cod (Score:1, Insightful)
Re: (Score:3)
I spoke with ESR at length, about sixteen years ago. While that's still not enough time to know a person in depth, I did not get from him the negative vibe you seem to attribute.
Re: (Score:2)
some people who loudly proclaim their desire to see fewer barriers to advancement for women and minorities
How about just not throwing up barriers to anyone?
Why focus on only part of the problem?
(i am not implying that you personally want to throw up barriers, i am just responding to a sequence of words without regard to the beliefs of the person who said them)
Re: (Score:2)
I have friends who are both clearly SJW and self-identify as such. They are also within the free software world. No, they really exist and are psychopaths. About half of the free software people are SJW. The other half are libertarian.
I found the above statement on the Internet, so it must be true!
Without all the corner cases? Hell no. (Score:3, Insightful)
The iMillenials call it "cruft".
I call it reliable handling of ALL the corner cases of actual real-world usage!
This here is what one gets, when one puts minimalism above all else, as today's generation of permanently-overwhelmed pussies does.
Re: Without all the corner cases? Hell no. (Score:2)
NodeJS == JavaScript
Re: (Score:2)
That's because libraries do things, and doing things slows things down.
Very easy to believe (Score:2)
Re: You don't know what a Linux distribution is. (Score:2)