Particularly Google has a heck of a lot of control through android and gets content providers to do things they universally wouldn't otherwise want to do (AMP comes to mind). Yes, it is a prudent time to highlight shenanigans that already unreasonably shape the internet that are already happening without any sort of counter.
Of course, doubling down and also opening the flood gates for the ISPs to also lock things down doesn't help matters.
The author blames regulation for the phone experience not progressing and that deregulation paved the way for things to improve. It's a very bizarre thing to blow off the whole forced breakup of AT&T as the factor. I don't think many folks blame FCC regulations for AT&T preserving a monopoly, and certainly no one in their right mind ignores the DOJ breakup of AT&T in favor of some FCC deregulation as to triggering the end of that era. Particularly since this common carrier thing persisted the whole time, it's very strange.
In short, I fint the article to be a bizarre self-contradiction. On the one wand worrying that there already are companies with worrisome control, but also vilifying regulation at the same time..
I have felt the pain of being in various teams with plenty of appropriate software tools to keep everything in sync and not have a confused mess of data with muddied authority and progeny.
However, inevitably, the UI design is so crappy that people 'export to xls' and use spreadsheet offline to add little fields or discuss en-masse.
It's also a process issue. Inevitably people think too much about the contents of the fields, and another motivation for people doing xls is for them to add a column with some small teams 'little comments' about the data, but without putting it in the tool that other people could see.
Nothing like being given a list of 50 thing in an emailed spreadsheet and being asked to update status on them. Then upon manually checking the very first one and seeing that record is closed, replying 'please use the tool to have an up to date report' and then getting the reply 'just operate against the list given, I don't have 'time' to pull a new report for you'
XSS largely caused by web developers overengineering their site and simultaneously lost at how to precisely and accurate describe the policies. Mostly the former, not every situation needs to splatter a web page across half a dozen servers.
Of course a lot of the 'medium/lows' become debates about whether they are really vulnerabilities or not. A lower severity is frequently a compromise between some security guy being surprised at a design point and a developer who intends the behavior.
But yes, the whole 'security team over here to 'fix everything', most of the software developers over there to do the work, whew they don't have to think about security because we have a team for that' is a pervasive problem in the industry.
Often companies make 'security teams' that go in and tackle the security problems so the other developers don't have to. This helps with things like, say, bundling third-party libraries with known CVEs, and answering security concerns *when the developers bother to think to ask*. However, so long as your rank and file developers don't think about security and how an attacker would go at their code pretty much all the time, there's no way a security team is going to be able to keep up with the 'organic' code, which contains many design decisions that no one even thinks to bring up for security review.
It does mitigate certain families of security flaws. However most C programmers have had it beat into their head to generally do the right thing, so these are more rare than they used to be, though still real enough to value the language removing the and implementations like rust deserve credit for taking measures that help here..
However it simply cannot magically fix most modern vulnerabilities that get announced, as they are generally oversights in logic flows. So it's a bit worrisome to see people seeming to put a bit *too* much faith in language to provide 'automagic' security, when the design is more often the vulnerability rather than bungling pointers/mallocs/bounds.
By itself as an isolated incident, sure, it's a trivial thing and whatever.
But it is part of a larger phenomenon of tucking painful things out of sight and trying to live a life of blissfully feeling like we are and have been a pretty enlightened society. Because doing any quoting of or about Hitler is automatically considered *endorsing* him, rather than ever serving as a cautionary tale.
History studied for the sake of history is a valuable pursuit, but everyday reminders are valuable particularly since most folks don't exactly go out of their way to even know history that well, let alone understand *how* it happens. Hitler's place in history devoid of context is just an obviously evil man come to power. Most have no understanding of how in the world modern society could fall so low. Of course not only Hitler, but other powerful evil folk in history provide great examples of worrying signs to notice in those who aspire to power today, but in general it makes us feel better to close our eyes and to the extent possible pretend they never happened or when they can't be ignored, to make them into inhuman monsters with no discernible connection to humanity who inexplicably magically came into power. Even little things like quotes can feed into how you perceive and recognize bad omens as they come.
In consumer market, true, and there the mandatory 'replace key using firmware config menu' is passable.
In business market, it is exceedingly common to ship computers without OS image and the business receiving is responsible for OS load choice, which is where scalable automation is critical.
SecureBoot merely validates that the OS booting is 'a' legitimate OS (for some value of legitimate). For the most part it means 'microsoft thinks this isn't malware'.
TPM gets into more specifics, and even it explicitly has the concept of physical presence as a way to 'recover' things.
However, a best practice there is for you to have an encrypted volume, with the keys sealed to TPM PCRs. Any TPM 'recovery' will make that sealed copy forever unrecoverable. So someone with physical presence can always reinstall the box, they may get forever locked out of the contents. Generally the key is additionally passphrase protected, so the sealing to TPM PCRs is a measure to allow automated boot so long as no shenanigans happen (breaking into firmware setup, breaking into grub cfg, etc).
I think it's not exactly sincere Hitler supporters that are the only ones that could think the change a bad idea. I would think pretending those things were never said because we are hurt they were ever said is harmful for the future. Lest we have public figures repeat many of those patterns without recognizing the problem because we bury our heads in the sand at the past when it offends us.
ML is generally enabling scenarios that were just too tedious to actually do by developer hands. Sure there are specific scenarios where developers had done the best they can (and generally failed) with hopelessly unstructured data, but for the most part those problems were just left untouched as infeasible to do manually.
For the vast majority of software development, ML doesn't add anything. If you have no unstructured data or a way to impose structure, ML doesn't do anything over boring old programming. Even when you find yourself in one of the very chaotic, large, and diverse data sets where ML can in theory help you sort through, you have to first chew through enough data in training to get decent confidence. So you not only need a large data set, you also need to have a continued need after human assisted training has already done the work on a big chunk of that data. Even then you may be grasping for some intelligent way to apply ML techniques, because the kicker is you have to have some sort of real idea of what to do, even if you have a 'how to do it'.
Big Data has done this same song and dance. ML is now the purported answer to 'once collected and have tools to analyze, most orgs have no idea what to do with the data'. I suggest that the orgs will still have no idea what to do with the data, and ML won't move the needle much in the wider market because the root cause is just a general lack of thoughts on what to do with the data. This is the curse of hyped adoption, the vast majority of adopters will be disappointed because it doesn't magically solve.
The question was *how* equifax was hacked. Was it through a measure that this would have prevented? Probably not, it was probably much more mundane.
The patch may be a nice improvement and ultimately a good idea, but it's a hardening improvement, not a fix for a specific vulnearabilty, so caution must be taken. You can't just invoke the 'security' card as a 'nothing else matters' when dealing with adding security features.
Security vulnerablities are urgent, security mitigation features are important, but less urgent and are worth the time to get them *right*. One thing is to not break function, but also to make sure that feature is comprehensive, lest you end up with a myriad of complex code to paste over the gaps of the last thing.
The patch submitter agreed with him, don't know why everyone is jumping to white knight for him.
Torvalds point is that it can wait, and that it can be phased in. The proposal is a hardening scheme and there's a long history of hardening schemes breaking valid usage inadvertently. Torvalds perspective is that it can be done carefully, it's a nice to have, but it's not going to save the world and it's not so terrible for it to wait a little while to make sure it is right. The patch submitter said that he did a whitelist, then realized late that there were problems, added a fallback, but now it could be removed. Torvalds rightfully felt there was no way his test effort would be adequate to become a staple of the stable kernel as-is, and even suggested a course of adding a warning mechanism first to help get data to determine the risks of the mechanism.
The problem is that security folks have gone crazy and think only security matters, risking legitimate usage scenarios for the sake of security. Also, any attack is a reason to add more locks. It's like if I read that someone in my neighborhood got their house broken into because they left their door open, then I move. Then I read that someone else from that neighborhood had the same thing happen when they left the door open, and I install another lock on the door. Then it happens again and I construct an underground bunker. All the time it's because folks are leaving their doors open, but every time scares me into taking more and more unreasonable measures to counter the victimizations of those less careful.
The same can be said of functional bugs, they are buggy, but you don't know it until discovered. The discovery of the bug does not mean the code changed, it means that bug hadn't been caught yet.
So yes, a system that is vulnerable to an as-yet unknown attack is buggy.
Note that usually BIOS boot is a BIOS emulation layer ('CSM') hosted in the firmware.
The usual approach has been that Intel reference platform included that emulation. Moving forward, they plan not to, however system vendors may opt to include it of their own volition.
Of course, in order to suspend UEFI runtime services, the UEFI would have to cooperate, so emulating BIOS without the cooperation of the firmware platform would be pointless, since you have the relatively small downsides of UEFI without the upsides.
Note that every OS in a long time has been UEFI boot capable. RHEL6 is UEFI bootable, SLES11 is UEFI bootable, and those are the two likely oldest distributions likely to be executed nowadays.
Well, one, SecureBoot is not mandated. Been UEFI booting since before SecureBoot existed.
Two, *if* it were mandated, using UEFI settings menu interactively isn't going to cut it, as large deployments need less manual attention. Some automation friendly mechanism is needed. The challenge being that it's hard to make an automation friendly capability that isn't also malware friendly.
I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.
If there's a massive framework that even bringing it in causes memory footprint to skyrocket, and you just use one little trivial function in it, better to write your own trivial function instead.
There do exist good PMs, very good at letting people do what they need to do, but also reminding about priorities. They also get a good sense of how the team may underestimate or overestimate themselves, and can know without being overly nagging when things are going wrong and to chase help. They also can be extraordinarily helpful at managing external dependencies and logistics. Good PMs seem never to have to ask anything and yet still know your answer. Having such a quality PM is a real thing and can greatly help a project. Even if a project can execute well, we are such a dysfunctional species that the executives may never know it without someone doing the work to keep them in the loop. I have been exceedingly greatful for PMs.
However, I've only had the rare pleasure of that. The vast majority of the time, they have no clue what the team is doing or how the team feels about it. They never learn how to communicate effectively with their team, taking things verbatim. If they have a 5 minute status report to give, they'll suck up an hour of the dev team's time to 'sync up' their understanding. When it comes to planning, they have no idea that a request can be a 5 minute thing or a huge thing, and after running through a dozen requests in a couple days, why is it that they are being told 'just one request' will take weeks to do. If something is a requirement without a specific deadline imposed by anyone, they will impose a deadline themselves so that everything fits. They will get pissed when development pauses on a fictional deadline to address an 'out of plan' urgent customer request. Rather than facilitating communication and planning with customers and other teams, they become horrible middlemen.
In one recent project, I spent months without the 'horror' of dedicated PM, and I had to double up the role and it took me maybe an hour of my time every two weeks, including the status reports to executives. I did feel like compared to a previous PM experience, it was a bit more of my time lost and some things were left undone for lack of a PM to take care of them. Of course, more critically the team was way understaffed for development, and I made that clear in meetings with management.
Then management decided to 'help' me, not by giving me a developer like I suggested, but a project manager so I wouldn't have to 'spend so much time in status meetings'. Now I spend 6 times more time in status meetings, spending a lot of the time repeating the same details over and over again. I don't even get out of the status meetings I used to have to attend, I still attend those too. In those meetings, my PM gets bypassed to talk directly to me because while the PM is putting up more charts and such, the execs don't feel like they know as much from them as my previous reports, and the PM can't answer a single question asked in those meetings.
So as with everything, there are good and bad experiences. We tend to simplify things so that either PM==good or PM==bad depending on our personal experience, but it's a very subjective thing.
Enlightenment is probably the best looking desktop software anywhere, it's customizability makes it hard to include with distros but it should be considered as evidence that it's not user-friendliness or beauty holding Linux back.
Note that 'beauty' is relative and certainly it is not equivalent to 'user friendly'.
I will though agree with the sentiment that there is no winning the 'user friendly', because the main desktop environments are user friendly enough, but there just isn't enough upside for the casual user to bother to even think about changing. As such diminishing the 'enthusiast' experience for the sake of the casual user is a strange thing to do.
You are right it's not about ability to take on load (though there is a matter of how self-reliant shops can be when trying to analyze failures, which is unlimited with Linux and inherently limited in Windows). However:
the lack of tools and tracking down a couple numerical inconsistencies
Those are pretty huge things. It all stems from the origin of supercomputing as a Unix thing, and as such similarity to Unix allowed seamless porting. Windows however is very different and requires more work to port all of the technical computing ecosystem that no one wants to do (except for a brief period Microsoft themselves, before they figured out just how *much* work they would need to do, how uphill a battle it was philosophically, and how utterly thankless a market win it would be even if they pulled it off).
One could say if the situation were reversed, *maybe* the technical challenges would have been worth solving to get some cost savings, but even if Windows were 100% free, it still wouldn't make inroads into Top500 class systems, because it's a lot of work with no upside to be on Windows.
It's the opposite challenge as Linux on the desktop. Linux on the desktop is perfectly capable and usable now, but there's so much stuff that is Windows only and not enough upside to address all that. We have an entrenched market in both cases and as such you either have to act*exactly* like what you are trying to replace or have to have something *really* worthwhile to convince the market to move.
Some of my favorite wtf *real sentences* that I've heard people say with a straight face in just the last week about AI: -"This is a neural network, it works just like the human brain, with neurons, dendrites, and axons!" -"The neural network evolves, we have species and genomes, just like the process that produced human intelligence!"
Problem of course being there is legitimate good work being done in the field, that will likely get flushed with the BS when the hype curve lets the industry down when folks realize the above sentences are BS, just intended for people to think they are magical than they are.
It's not really my genre, but the problem is that it's 40 hours before you can even play as even *one* of the characters they are likely to have bought the game to do at all (unless of course you pay out some cash to accelerate things).
Basically, it's trying to avoid the backlash of incremental const of DLC, but making the 'free' path so painful as to not be viable.
DLC started as a way to extend a nice game with even more stuff, but has devolved to being a paid-for demo which manages to avoid having any of the actual content people came for in the first place.
The Top500 list measures xhpl performance only. While it is hurt by poor interconnect, it can still turn out solid numbers on a typical 10gb network.
Truth is, the crappiness of a single dimension to measure the Top500 has been a well-known thing for at least 15 years. Interconnect can matter for a great deal of technical computing, but then again, sometimes plain ethernet is fine. Sometimes you don't need large memory amounts per node or decent single-threaded performance, but then again sometimes you do. Technical computing is a very diverse landscape and some of these hyper-specialized publicity stunts of Top500 systems suck at doing much of anything apart form running xhpl.
Slashdot Mirror
Particularly Google has a heck of a lot of control through android and gets content providers to do things they universally wouldn't otherwise want to do (AMP comes to mind). Yes, it is a prudent time to highlight shenanigans that already unreasonably shape the internet that are already happening without any sort of counter.
Of course, doubling down and also opening the flood gates for the ISPs to also lock things down doesn't help matters.
The author blames regulation for the phone experience not progressing and that deregulation paved the way for things to improve. It's a very bizarre thing to blow off the whole forced breakup of AT&T as the factor. I don't think many folks blame FCC regulations for AT&T preserving a monopoly, and certainly no one in their right mind ignores the DOJ breakup of AT&T in favor of some FCC deregulation as to triggering the end of that era. Particularly since this common carrier thing persisted the whole time, it's very strange.
In short, I fint the article to be a bizarre self-contradiction. On the one wand worrying that there already are companies with worrisome control, but also vilifying regulation at the same time..
I have felt the pain of being in various teams with plenty of appropriate software tools to keep everything in sync and not have a confused mess of data with muddied authority and progeny.
However, inevitably, the UI design is so crappy that people 'export to xls' and use spreadsheet offline to add little fields or discuss en-masse.
It's also a process issue. Inevitably people think too much about the contents of the fields, and another motivation for people doing xls is for them to add a column with some small teams 'little comments' about the data, but without putting it in the tool that other people could see.
Nothing like being given a list of 50 thing in an emailed spreadsheet and being asked to update status on them. Then upon manually checking the very first one and seeing that record is closed, replying 'please use the tool to have an up to date report' and then getting the reply 'just operate against the list given, I don't have 'time' to pull a new report for you'
XSS largely caused by web developers overengineering their site and simultaneously lost at how to precisely and accurate describe the policies. Mostly the former, not every situation needs to splatter a web page across half a dozen servers.
Of course a lot of the 'medium/lows' become debates about whether they are really vulnerabilities or not. A lower severity is frequently a compromise between some security guy being surprised at a design point and a developer who intends the behavior.
But yes, the whole 'security team over here to 'fix everything', most of the software developers over there to do the work, whew they don't have to think about security because we have a team for that' is a pervasive problem in the industry.
Often companies make 'security teams' that go in and tackle the security problems so the other developers don't have to. This helps with things like, say, bundling third-party libraries with known CVEs, and answering security concerns *when the developers bother to think to ask*. However, so long as your rank and file developers don't think about security and how an attacker would go at their code pretty much all the time, there's no way a security team is going to be able to keep up with the 'organic' code, which contains many design decisions that no one even thinks to bring up for security review.
It does mitigate certain families of security flaws. However most C programmers have had it beat into their head to generally do the right thing, so these are more rare than they used to be, though still real enough to value the language removing the and implementations like rust deserve credit for taking measures that help here..
However it simply cannot magically fix most modern vulnerabilities that get announced, as they are generally oversights in logic flows. So it's a bit worrisome to see people seeming to put a bit *too* much faith in language to provide 'automagic' security, when the design is more often the vulnerability rather than bungling pointers/mallocs/bounds.
Eh, I'd say it's not guaranteed that anything is invariably open to hacking.
I'd say 15% vendors are crap, 85% users/admins picking the password 'password' to secure things.
In the world of IoT of course, it goes to 100% crappy vendors.
By itself as an isolated incident, sure, it's a trivial thing and whatever.
But it is part of a larger phenomenon of tucking painful things out of sight and trying to live a life of blissfully feeling like we are and have been a pretty enlightened society. Because doing any quoting of or about Hitler is automatically considered *endorsing* him, rather than ever serving as a cautionary tale.
History studied for the sake of history is a valuable pursuit, but everyday reminders are valuable particularly since most folks don't exactly go out of their way to even know history that well, let alone understand *how* it happens. Hitler's place in history devoid of context is just an obviously evil man come to power. Most have no understanding of how in the world modern society could fall so low. Of course not only Hitler, but other powerful evil folk in history provide great examples of worrying signs to notice in those who aspire to power today, but in general it makes us feel better to close our eyes and to the extent possible pretend they never happened or when they can't be ignored, to make them into inhuman monsters with no discernible connection to humanity who inexplicably magically came into power. Even little things like quotes can feed into how you perceive and recognize bad omens as they come.
In consumer market, true, and there the mandatory 'replace key using firmware config menu' is passable.
In business market, it is exceedingly common to ship computers without OS image and the business receiving is responsible for OS load choice, which is where scalable automation is critical.
Well SecureBoot and TPM don't really relate.
SecureBoot merely validates that the OS booting is 'a' legitimate OS (for some value of legitimate). For the most part it means 'microsoft thinks this isn't malware'.
TPM gets into more specifics, and even it explicitly has the concept of physical presence as a way to 'recover' things.
However, a best practice there is for you to have an encrypted volume, with the keys sealed to TPM PCRs. Any TPM 'recovery' will make that sealed copy forever unrecoverable. So someone with physical presence can always reinstall the box, they may get forever locked out of the contents. Generally the key is additionally passphrase protected, so the sealing to TPM PCRs is a measure to allow automated boot so long as no shenanigans happen (breaking into firmware setup, breaking into grub cfg, etc).
https://svnweb.freebsd.org/bas...
I think it's not exactly sincere Hitler supporters that are the only ones that could think the change a bad idea. I would think pretending those things were never said because we are hurt they were ever said is harmful for the future. Lest we have public figures repeat many of those patterns without recognizing the problem because we bury our heads in the sand at the past when it offends us.
https://svnweb.freebsd.org/bas...
ML is generally enabling scenarios that were just too tedious to actually do by developer hands. Sure there are specific scenarios where developers had done the best they can (and generally failed) with hopelessly unstructured data, but for the most part those problems were just left untouched as infeasible to do manually.
For the vast majority of software development, ML doesn't add anything. If you have no unstructured data or a way to impose structure, ML doesn't do anything over boring old programming. Even when you find yourself in one of the very chaotic, large, and diverse data sets where ML can in theory help you sort through, you have to first chew through enough data in training to get decent confidence. So you not only need a large data set, you also need to have a continued need after human assisted training has already done the work on a big chunk of that data. Even then you may be grasping for some intelligent way to apply ML techniques, because the kicker is you have to have some sort of real idea of what to do, even if you have a 'how to do it'.
Big Data has done this same song and dance. ML is now the purported answer to 'once collected and have tools to analyze, most orgs have no idea what to do with the data'. I suggest that the orgs will still have no idea what to do with the data, and ML won't move the needle much in the wider market because the root cause is just a general lack of thoughts on what to do with the data. This is the curse of hyped adoption, the vast majority of adopters will be disappointed because it doesn't magically solve.
The question was *how* equifax was hacked. Was it through a measure that this would have prevented? Probably not, it was probably much more mundane.
The patch may be a nice improvement and ultimately a good idea, but it's a hardening improvement, not a fix for a specific vulnearabilty, so caution must be taken. You can't just invoke the 'security' card as a 'nothing else matters' when dealing with adding security features.
Security vulnerablities are urgent, security mitigation features are important, but less urgent and are worth the time to get them *right*. One thing is to not break function, but also to make sure that feature is comprehensive, lest you end up with a myriad of complex code to paste over the gaps of the last thing.
The patch submitter agreed with him, don't know why everyone is jumping to white knight for him.
Torvalds point is that it can wait, and that it can be phased in. The proposal is a hardening scheme and there's a long history of hardening schemes breaking valid usage inadvertently. Torvalds perspective is that it can be done carefully, it's a nice to have, but it's not going to save the world and it's not so terrible for it to wait a little while to make sure it is right. The patch submitter said that he did a whitelist, then realized late that there were problems, added a fallback, but now it could be removed. Torvalds rightfully felt there was no way his test effort would be adequate to become a staple of the stable kernel as-is, and even suggested a course of adding a warning mechanism first to help get data to determine the risks of the mechanism.
The problem is that security folks have gone crazy and think only security matters, risking legitimate usage scenarios for the sake of security. Also, any attack is a reason to add more locks. It's like if I read that someone in my neighborhood got their house broken into because they left their door open, then I move. Then I read that someone else from that neighborhood had the same thing happen when they left the door open, and I install another lock on the door. Then it happens again and I construct an underground bunker. All the time it's because folks are leaving their doors open, but every time scares me into taking more and more unreasonable measures to counter the victimizations of those less careful.
The same can be said of functional bugs, they are buggy, but you don't know it until discovered. The discovery of the bug does not mean the code changed, it means that bug hadn't been caught yet.
So yes, a system that is vulnerable to an as-yet unknown attack is buggy.
Note that usually BIOS boot is a BIOS emulation layer ('CSM') hosted in the firmware.
The usual approach has been that Intel reference platform included that emulation. Moving forward, they plan not to, however system vendors may opt to include it of their own volition.
Of course, in order to suspend UEFI runtime services, the UEFI would have to cooperate, so emulating BIOS without the cooperation of the firmware platform would be pointless, since you have the relatively small downsides of UEFI without the upsides.
Note that every OS in a long time has been UEFI boot capable. RHEL6 is UEFI bootable, SLES11 is UEFI bootable, and those are the two likely oldest distributions likely to be executed nowadays.
Well, one, SecureBoot is not mandated. Been UEFI booting since before SecureBoot existed.
Two, *if* it were mandated, using UEFI settings menu interactively isn't going to cut it, as large deployments need less manual attention. Some automation friendly mechanism is needed. The challenge being that it's hard to make an automation friendly capability that isn't also malware friendly.
I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.
Of course, there's the opposite of NIH.
If there's a massive framework that even bringing it in causes memory footprint to skyrocket, and you just use one little trivial function in it, better to write your own trivial function instead.
There do exist good PMs, very good at letting people do what they need to do, but also reminding about priorities. They also get a good sense of how the team may underestimate or overestimate themselves, and can know without being overly nagging when things are going wrong and to chase help. They also can be extraordinarily helpful at managing external dependencies and logistics. Good PMs seem never to have to ask anything and yet still know your answer. Having such a quality PM is a real thing and can greatly help a project. Even if a project can execute well, we are such a dysfunctional species that the executives may never know it without someone doing the work to keep them in the loop. I have been exceedingly greatful for PMs.
However, I've only had the rare pleasure of that. The vast majority of the time, they have no clue what the team is doing or how the team feels about it. They never learn how to communicate effectively with their team, taking things verbatim. If they have a 5 minute status report to give, they'll suck up an hour of the dev team's time to 'sync up' their understanding. When it comes to planning, they have no idea that a request can be a 5 minute thing or a huge thing, and after running through a dozen requests in a couple days, why is it that they are being told 'just one request' will take weeks to do. If something is a requirement without a specific deadline imposed by anyone, they will impose a deadline themselves so that everything fits. They will get pissed when development pauses on a fictional deadline to address an 'out of plan' urgent customer request. Rather than facilitating communication and planning with customers and other teams, they become horrible middlemen.
In one recent project, I spent months without the 'horror' of dedicated PM, and I had to double up the role and it took me maybe an hour of my time every two weeks, including the status reports to executives. I did feel like compared to a previous PM experience, it was a bit more of my time lost and some things were left undone for lack of a PM to take care of them. Of course, more critically the team was way understaffed for development, and I made that clear in meetings with management.
Then management decided to 'help' me, not by giving me a developer like I suggested, but a project manager so I wouldn't have to 'spend so much time in status meetings'. Now I spend 6 times more time in status meetings, spending a lot of the time repeating the same details over and over again. I don't even get out of the status meetings I used to have to attend, I still attend those too. In those meetings, my PM gets bypassed to talk directly to me because while the PM is putting up more charts and such, the execs don't feel like they know as much from them as my previous reports, and the PM can't answer a single question asked in those meetings.
So as with everything, there are good and bad experiences. We tend to simplify things so that either PM==good or PM==bad depending on our personal experience, but it's a very subjective thing.
Enlightenment is probably the best looking desktop software anywhere, it's customizability makes it hard to include with distros but it should be considered as evidence that it's not user-friendliness or beauty holding Linux back.
Note that 'beauty' is relative and certainly it is not equivalent to 'user friendly'.
I will though agree with the sentiment that there is no winning the 'user friendly', because the main desktop environments are user friendly enough, but there just isn't enough upside for the casual user to bother to even think about changing. As such diminishing the 'enthusiast' experience for the sake of the casual user is a strange thing to do.
You are right it's not about ability to take on load (though there is a matter of how self-reliant shops can be when trying to analyze failures, which is unlimited with Linux and inherently limited in Windows). However:
the lack of tools and tracking down a couple numerical inconsistencies
Those are pretty huge things. It all stems from the origin of supercomputing as a Unix thing, and as such similarity to Unix allowed seamless porting. Windows however is very different and requires more work to port all of the technical computing ecosystem that no one wants to do (except for a brief period Microsoft themselves, before they figured out just how *much* work they would need to do, how uphill a battle it was philosophically, and how utterly thankless a market win it would be even if they pulled it off).
One could say if the situation were reversed, *maybe* the technical challenges would have been worth solving to get some cost savings, but even if Windows were 100% free, it still wouldn't make inroads into Top500 class systems, because it's a lot of work with no upside to be on Windows.
It's the opposite challenge as Linux on the desktop. Linux on the desktop is perfectly capable and usable now, but there's so much stuff that is Windows only and not enough upside to address all that. We have an entrenched market in both cases and as such you either have to act*exactly* like what you are trying to replace or have to have something *really* worthwhile to convince the market to move.
Some of my favorite wtf *real sentences* that I've heard people say with a straight face in just the last week about AI:
-"This is a neural network, it works just like the human brain, with neurons, dendrites, and axons!"
-"The neural network evolves, we have species and genomes, just like the process that produced human intelligence!"
Problem of course being there is legitimate good work being done in the field, that will likely get flushed with the BS when the hype curve lets the industry down when folks realize the above sentences are BS, just intended for people to think they are magical than they are.
It's not really my genre, but the problem is that it's 40 hours before you can even play as even *one* of the characters they are likely to have bought the game to do at all (unless of course you pay out some cash to accelerate things).
Basically, it's trying to avoid the backlash of incremental const of DLC, but making the 'free' path so painful as to not be viable.
DLC started as a way to extend a nice game with even more stuff, but has devolved to being a paid-for demo which manages to avoid having any of the actual content people came for in the first place.
The Top500 list measures xhpl performance only. While it is hurt by poor interconnect, it can still turn out solid numbers on a typical 10gb network.
Truth is, the crappiness of a single dimension to measure the Top500 has been a well-known thing for at least 15 years. Interconnect can matter for a great deal of technical computing, but then again, sometimes plain ethernet is fine. Sometimes you don't need large memory amounts per node or decent single-threaded performance, but then again sometimes you do. Technical computing is a very diverse landscape and some of these hyper-specialized publicity stunts of Top500 systems suck at doing much of anything apart form running xhpl.