"Seriously, the amount of money consolidated and mis-spent in military and healthcare spending would be enough to provide healthcare for the remainder of..."
Please explain the basis for your assumption that the doctors aren't people with the same made up 10% doing something that makes them a jerk at least once a week. People who think they've been wronged in some way are no more or less likely to be the jerks than the doctors.
Keep in mind we are talking about medical care here. If you go in to have surgery on your shoulder and the doctor makes a good faith best effort but say, sneezes at the wrong moment and slices a nerve leaving your arm hanging limp and dead at your side for life, you can't just shrug it off (heh) because the doctor wasn't being a jerk. It isn't about thinking the doctor was an ass, most people NEED their limbs and the loss of a limb is too great a burden to bear financially.
Our numbers are so high we can spend as much as military spenders 2 through 11 and have the most expensive low quality healthcare in the world. Let's not pretend, this is in very large part about the US.
This just doesn't mesh, we currently pay more tax dollars on healthcare in the US per capita than countries which have single payer while offering inferior healthcare to most.
How is capping malpractice payouts relaxing regulations? If you want to cut cost by removing regulations, remove the regulations that reduce competition by making the FDA approval process completely tax subsidized and provide a public option that disregards patent awarding contracts to third parties to produce a subset of the most expensive and commonly prescribed medications that would normally still be locked under patent. That will actually drive costs down as drug companies try to keep their new drug low enough to dodge the top 10 list or wherever you set the cutoff.
I mean sure, the movie would have less in common with reality than TFS by the end but the heist, the laundering through the casinos... sounds like a great start.
"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.
How do you sell conquest and murder? Call it liberation and spreading freedom. How do you buck a powerful system implementing policies contrary to your profit interests and replace it with one where you have more power to shape policies to increase your profit? Call it tyrannical and get people to commit suicide and murder to "free" themselves of that "oppression". How do you get people to support one group systematically getting the better end of the stick in trade? Call everything that results in your side of trade losing as fraud, theft, etc and make the wins for your side of the stick industry practices, interest, fees, etc. How do you get people to embrace racism? Define a racial group as racist. How do you get people to hate someone? Define a "them" and define anything "they" do that is in "their" interest and contrary to "our" interest as hate. Everything contrary or negative thing any of "them" do is proof of how bad "they" are and everything inconsistent is an anecdotal individual exception that doesn't apply meaningfully to "them" as a whole. It is okay to hate "them" because turnabout is fair play and they have no moral high ground from which to complain.
It does do real work, it validates transaction chain hashes. There is something like a salt, a randomly generated string that gets puts on each one in an attempt to guess at a hash that meets the "difficulty" of the network, if it does that transaction closes the current block of transactions resulting in a new bitcoin award.
I'm more than a little skeptical of these power figures, I can't help but wonder if they are mixing up the GPU mining power requirements of other cryptocoins with the ASIC mining powering Bitcoin.
In fact, I should add another note I think is probably a given. The nature of neural connections means capacity likely grows exponentially with neuron count. How efficiently the neurons are used can blow away difference in body mass to brain mass ratio... just look at large parrots, they have ridiculously efficient brains (I suspect their OCD behaviors are related as extremely intelligence humans often show similar OCD patterns and autism) and achieve primate level intelligence with a brain the size of a walnut.
"Thats like saying that your cell phone is more powerful than my desktop PC because the phone has 1/5th the raw processing power and 1/10th of the volume of the desktop."
No, it really doesn't compare to electronics in that way. It's more like saying that your desktop PC would be faster with 1/5th the raw processing power and an operating system with 1/10th the complexity. If you think about it, it's pretty much a given. A body isn't a solid chunk of thing, every piece of it is composed of millions or even billions of things which in many ways operate in parallel but ultimately all are generating signals read by and responded to by the brain through the central nervous system, the more of them there are, the more signals to be sent and received, and the more of your brain will be dedicated to them instead of pondering the meaning of life. Learn how to individually articulate the three middle toes on your left foot... spend a couple hours at and it and you'll make enough progress to prove you can, guess what, that doesn't come for free, you've used part of your brains capacity to form more detailed pathways and gain finer articulation of those muscles... your brain is processing more signals from there and spending less on something else, possibly higher thought. Also, you might note they framed it in terms of carnivores vs non-carnivores but they mentioned the same concept in the summary. These counts are pretty much in line with previous estimates that concluded dogs had a higher count than cats on average but a poorer body mass to brain ratio than cats.
This isn't exactly a precise thing, bigger doesn't always mean more complicated in general, having 8 legs probably makes a bigger difference than the same number of cells in a single leg and if you gain 20 lbs you likely have added little if any cells, instead your existing cells have simply grown larger. Also, while we use 100% of our brain we do not necessarily use it at 100% efficiency.
You also can't really say dogs or cats are smarter in a blanket statement on this basis, cats vary a bit but dogs vary wildly in size.
No, gaining and losing weight is generally a function of cells swelling and shrinking not multiplying and any difference it made would be miniscule. Gaining muscle is also actually generally a function of cells expanding rather than neurogenesis.
"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...
"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.
"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
"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.
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.
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.
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.
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.
"With cash, I haven't worried about any of this shit for 3 decades now. I've never had money stolen from my hands, minus a grifter for $20 in Times Square."
Then why are you worried about it with your bitcoin?
"Right now there is no insured storage of bitcoin that is backed by federal mandate."
Of course there is, you can store on an offline wallet and stick it in a safe deposit box. Where do you store your gold/silver, jewelry, 5 figures worth of electronics, car, etc? The government or bank is more likely to be the ones taking your money or handing it away to people they think are entitled to it than men in masks.
Slashdot Mirror
"Seriously, the amount of money consolidated and mis-spent in military and healthcare spending would be enough to provide healthcare for the remainder of..."
A big chunk of the world.
Please explain the basis for your assumption that the doctors aren't people with the same made up 10% doing something that makes them a jerk at least once a week. People who think they've been wronged in some way are no more or less likely to be the jerks than the doctors.
Keep in mind we are talking about medical care here. If you go in to have surgery on your shoulder and the doctor makes a good faith best effort but say, sneezes at the wrong moment and slices a nerve leaving your arm hanging limp and dead at your side for life, you can't just shrug it off (heh) because the doctor wasn't being a jerk. It isn't about thinking the doctor was an ass, most people NEED their limbs and the loss of a limb is too great a burden to bear financially.
Our numbers are so high we can spend as much as military spenders 2 through 11 and have the most expensive low quality healthcare in the world. Let's not pretend, this is in very large part about the US.
This just doesn't mesh, we currently pay more tax dollars on healthcare in the US per capita than countries which have single payer while offering inferior healthcare to most.
How is capping malpractice payouts relaxing regulations? If you want to cut cost by removing regulations, remove the regulations that reduce competition by making the FDA approval process completely tax subsidized and provide a public option that disregards patent awarding contracts to third parties to produce a subset of the most expensive and commonly prescribed medications that would normally still be locked under patent. That will actually drive costs down as drug companies try to keep their new drug low enough to dodge the top 10 list or wherever you set the cutoff.
"There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box."
Modding up overt hateful generalizations of ~300M individuals today? TFS doesn't even have anything to do with Americans.
I mean sure, the movie would have less in common with reality than TFS by the end but the heist, the laundering through the casinos... sounds like a great start.
"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.
How do you sell conquest and murder? Call it liberation and spreading freedom.
How do you buck a powerful system implementing policies contrary to your profit interests and replace it with one where you have more power to shape policies to increase your profit? Call it tyrannical and get people to commit suicide and murder to "free" themselves of that "oppression".
How do you get people to support one group systematically getting the better end of the stick in trade? Call everything that results in your side of trade losing as fraud, theft, etc and make the wins for your side of the stick industry practices, interest, fees, etc.
How do you get people to embrace racism? Define a racial group as racist.
How do you get people to hate someone? Define a "them" and define anything "they" do that is in "their" interest and contrary to "our" interest as hate. Everything contrary or negative thing any of "them" do is proof of how bad "they" are and everything inconsistent is an anecdotal individual exception that doesn't apply meaningfully to "them" as a whole. It is okay to hate "them" because turnabout is fair play and they have no moral high ground from which to complain.
In other words, your argument is "nu uh."
It does do real work, it validates transaction chain hashes. There is something like a salt, a randomly generated string that gets puts on each one in an attempt to guess at a hash that meets the "difficulty" of the network, if it does that transaction closes the current block of transactions resulting in a new bitcoin award.
I'm more than a little skeptical of these power figures, I can't help but wonder if they are mixing up the GPU mining power requirements of other cryptocoins with the ASIC mining powering Bitcoin.
In fact, I should add another note I think is probably a given. The nature of neural connections means capacity likely grows exponentially with neuron count. How efficiently the neurons are used can blow away difference in body mass to brain mass ratio... just look at large parrots, they have ridiculously efficient brains (I suspect their OCD behaviors are related as extremely intelligence humans often show similar OCD patterns and autism) and achieve primate level intelligence with a brain the size of a walnut.
"Thats like saying that your cell phone is more powerful than my desktop PC because the phone has 1/5th the raw processing power and 1/10th of the volume of the desktop."
No, it really doesn't compare to electronics in that way. It's more like saying that your desktop PC would be faster with 1/5th the raw processing power and an operating system with 1/10th the complexity. If you think about it, it's pretty much a given. A body isn't a solid chunk of thing, every piece of it is composed of millions or even billions of things which in many ways operate in parallel but ultimately all are generating signals read by and responded to by the brain through the central nervous system, the more of them there are, the more signals to be sent and received, and the more of your brain will be dedicated to them instead of pondering the meaning of life. Learn how to individually articulate the three middle toes on your left foot... spend a couple hours at and it and you'll make enough progress to prove you can, guess what, that doesn't come for free, you've used part of your brains capacity to form more detailed pathways and gain finer articulation of those muscles... your brain is processing more signals from there and spending less on something else, possibly higher thought. Also, you might note they framed it in terms of carnivores vs non-carnivores but they mentioned the same concept in the summary. These counts are pretty much in line with previous estimates that concluded dogs had a higher count than cats on average but a poorer body mass to brain ratio than cats.
This isn't exactly a precise thing, bigger doesn't always mean more complicated in general, having 8 legs probably makes a bigger difference than the same number of cells in a single leg and if you gain 20 lbs you likely have added little if any cells, instead your existing cells have simply grown larger. Also, while we use 100% of our brain we do not necessarily use it at 100% efficiency.
You also can't really say dogs or cats are smarter in a blanket statement on this basis, cats vary a bit but dogs vary wildly in size.
No, gaining and losing weight is generally a function of cells swelling and shrinking not multiplying and any difference it made would be miniscule. Gaining muscle is also actually generally a function of cells expanding rather than neurogenesis.
You are ignoring that cats have more brain cells relative to body weight and therefore are actually still more intelligent than dogs.
"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...
"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.
"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
"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.
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.
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.
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.
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.
It's Intel's optimized compiler but as a distro this time!
In some cases that is true but RHEL is also tuned for stability rather than speed out of the box.
"With cash, I haven't worried about any of this shit for 3 decades now. I've never had money stolen from my hands, minus a grifter for $20 in Times Square."
Then why are you worried about it with your bitcoin?
"Right now there is no insured storage of bitcoin that is backed by federal mandate."
Of course there is, you can store on an offline wallet and stick it in a safe deposit box. Where do you store your gold/silver, jewelry, 5 figures worth of electronics, car, etc? The government or bank is more likely to be the ones taking your money or handing it away to people they think are entitled to it than men in masks.