Taxpayer money may have helped build the initial nuclear fleet, but for many years, electricity was cheaper than in many neighboring countries, and dividents (or benefits, before EDF was privatized) were that much money in the state's budget that did not need to come from the taxpayer.

And with the ARENH mechanism, the nuclear industry is actually forced to subsidize purely finance-based companies which produce nothing. The sums of money that were injected in the industry in the last years by the state are less than than the dividends the state took from the industry.

Nor really subsidies, unless negative subsidies count in you world.

If a person lives in France, their phone company is probably a French company, so wiretapping can be done under the French justdicction, and this is a non-issue. Granted, that person could have a phone plan in another country, but that will cost more and it will probably be difficult even to get a phone plan (hint: many US bank verification systems require a phone number in the US, to limit fraud, so there must be at least a statistical reason for this). Probably does not make it impossible constitutes a first barrier.

With Telegram, Whatsapp, Signal, ... there are no such restrictions, so any random tech illiterate person could bypass tapping if the company does not comply.

In the company I work for (in France), we have the choice between an 2nd, company-supplied phone, and a BYOD option.

Most of the managers or people who tend to get more phone calls instead of mostly chat and e-mail messages choose the 2-phone option.
It is nice to have the choice, though each option has its disadvantages and constraints.

In any case, I do not feel the right to disconnect law here has been life-changing. People are a bit more careful to avoid messages after 8 Pm, but except for the few people who are specifically on call for some infrastructures, which involves a calendar, and is not 7/7, I never felt an obligation to answer late and week-end messages, and did not get many. I just assumed it was more practical for the senders to do at at those times, not that am immediate answer was required. But then again, things might be more tense in activities involving shorted time frames than R&D.

You can always wait to see if they start following local laws and destroy data they collected illegally (GDPR in Europe), but that would really surprise me, since they know what they are doing is immoral, and illegal at least in Europe, and are pushing it anyways.

If they continue illegally using our personal data or trying to get as much of it as they can, I certainly would not lift a little finger or spend the least amount of energy to discourage anyone who would give them a taste of their own medicine, noble ideals notwithstanding.

Two wrongs may not make a right, but when some people spend all their energy trampling other people's rights, I just couldn't manage to feel sorry for them if their own rights were trampled, especially with the tools or techniques they promote.

I would absolutely leave their family and friends out of this (red line here), but the executives, board members, investors, (and probably many employees) should be fair game.

So even if following them person-of-interest style is only wishful thinking, I can only root for that idea.

Wow. Didn't know it was that bad.

In any case, even if that had not been Linus, most people who are to used to working with saner people would be too surprised in the sort of situation to react in time. So patting the guy in the shoulder and making him know he is not alone is probably the second best you can do, even if you wish you had done better.

Simply trying to be a bit more precise than the first time. Probably not that useful...

I agree 100% that Linux is only one of many components in the whole system, and that the work of many people was involved to get where we are today. That was not the point. Linus's role for the kernel the first 10 years was probably more essential than today.

I disagree with the comparison with Weinstein. Being opinionated and abrasive (even if it goes so far as to threaten the project) is not on the same level as abuse of power and rape. Even if it can put a project at risk, and if it goes all the way to failure, waste years of contributor's time and leave them disillusioned, it it still not comparable.

I may not have followed the Linux development in enough detail these last years, compared to the early 2000's, but I had the impression that some rants (for example about non-repaired breakage by L. Poettering) were warranted, and that some others were certainly opinionated, but not targeted towards specific people, and normal technical conversation tended to resume after that. I did not have the impression things were that bad.

The fact that some of the people complaining represented by corporations and seemed to be using politics to push technical options did not lead me to trust them: I've seen several bad solutions promoted by companies in various collaboratively funded projects just because someone in that company (or lab) wanted to push their pet solution, and others had to accept *something* from that participant. And instead of still wasting time due to those choices years later, I would have very much liked to have someone in the project at the time be either insensitive enough or in "protected" enough position to honestly tell them to go play somewhere else. Even if dealing with those people comes with its own difficulties, and you can't have more than one at a time on a team (and admittedly not work with them every day)..

In the case of Linux, if things really have become worse since 2018, that would mean the "awakening" has made things worse, so maybe working around people and sidelining them is more realistic than "forced reeducation", if it comes to that. At least is is more incremental and mostly reversible, if the person learns the lesson (though that usually requires being able to put themselves in other people's shoes, which might not be their strong point from the onset).

Thanks for the link.

I agree that the FSF's tech leadership might not be the best around. Although RMS's initial work on tools such as gcc was invaluable in that it laid the groundwork for a free software ecosystem, I was also aware and concerned making it less modular than it should have been on political grounds is probably what led to the rise of LLVM, whereas a less extreme position might have led to much earlier improvements in gcc, and possibly even avoided having a non-LGPL competitor (The competition has probably improved the quality of both, but the burden is probably now on GCC to maintain itself relative to a free-as-in-beer competitor, while being harder to maintain, so RMS's technical choices really seem to have backfired there).

I always had the impression the failure of HURD was in part due on insistence on following an option that was better on paper bit not so great in practice, where Linus bet on a safer horse (but then again, lack of manpower at the right time and other aspects might be the main factors). And GNU software has always seemed on the "bloated" side, with many features, which is great for many low-level tools and GNU make, maybe not so great for everything,

So I certainly would not trust him (or anyone for that matter) with too much power. But given his initial role, I am not comfortable with some people who would seem to be happy to remove people from the history books, which is a slippery slope. In any case, the impression I had reading their open letter was that it was the person who was rejected, more than a set of some specific actions/behavior patterns, which would have been much more convincing, The current situation where his past role is acknowledged yet he does not seem to weigh anymore on technical choices would seem reasonable to me, though maybe it is easier to recognize someone's contributions when I do not have to put up with him in real life, compared to people who actually do.

You say "endure". Sure, there are plenty of examples of bad leadership in *existing* organizations.

But Linux is more of a project than a single organization.Its reason to exist is not that of an organization.

And an organization / a project does not grow from scratch (or almost) instead of simply enduring for 30 years if the leadership is that terrible, especially when competing projects exist. That does not mean it can't be improved, but it certainly delivers on some essential aspects, where many others do not.

If Linus's leadership were that horrible, a better leader could fork their own Linux tree and take it beyond Linus's reference version. The fact that hasn't happened tells more than anyone's opinion.

Leadership in technical projects is not limited to people skills, though neglecting those can cause some issues.

If Linus's leadership had been so bad, Linux would not have made it to 2018. And I can understand that when somebody proposes (or in some cases, insists) on pushing patches which either add complexity/reduce consistency/add breakage, the people who decide upon these patches don't have time to waste, and need to make a point that things need to be a lot better before they are ready for integration.

In a single team of small to medium size, not putting people off is essential, but in very large projects, with varied contributors, you can't afford the time to clean up people's patches for them, so being abrasive is probably much less consequential to the project's long term success than accepting low-quality contributions simply avoid hurting people's feelings. Diplomacy is good, but not nearly as essential as justice (abrasive remarks are based on technical points, not on developer's longstanding/newbie/friend/foe favorites, and no one is pursued/picked on). In the enterprise, you can find plenty of nice and diplomatic people who tick all the required boxes but make horrible leaders either because they lack other skills or simply don't care enough.

Stallman is another story. We would not have had the GPL without him, and a lot of his predictions came true, or are on the right track (and reading them 15 years ago it was obvious we were on that track). But though his inflexible nature probably drove him to his achievements, it does not help in having a nice personal life. That may be the price to pay, and he is the one paying it. If it suits him, fine. In any case, he may have his faults, but I certainly would not trust those who try to kick a founder out of the organization he built. And especially not using "cancel" techniques. There are plenty of other organizations promoting free software, created by people who had other approaches and priorities than the FSF, for those who do not like RMS. So why attack the FSF board, unless there are ulterior motives/power plays ?

But as to why Linus seems more "popular", there is probably a mix of many factors. Timing, being in the right place in the right time, and focusing on technical aspects whereas RMS focuses more on fundamentals and tells many people what they do not want to hear. In any case, Linux would not be where it is today without the GPL, and GNU tools would not be as ubuquitious without Linux. HURD may have been nice on paper, but is one case where RMS's intransigeance was a disadvantage.

I agree encryption should be a choice, and not imposed. How is this handled when there is already full-disk encryption ? What is the overhead ?

But having had that policy quite a few years ago in the company I work for, I certainly hated it when admins put things in my $HOME. Any well designed reference .profile, .bashrc, and whatnot checks for files to source in /etc anyways.
As a user, I consider my $HOME directory is mine to organize and manage. The admins already control all the rest of the system, so they should be busy enough doing clean stuff elsewhere rather than mess with my profile (which is actually not so fancy, mostly defaults, but still mine). Maybe I could have been convinced if when I got an account, I was informed of which files were "reserved", and why it was not possible to do otherwise, but I don't remember that ever happening.

So if that's one thing admins can't do anymore, I certainly won't regret it (though I have not faced this for a long time)

That said, I don't trust LP, given his documented attitude...

Yes.

It is strange that with the 2 sounding similar, some conspiracy theorist has not already jumped on this to declare that Stable Genius knew of the upcoming pandemic long before it started, proving that he is behind the whole thing. If anyone else than stable genius, his cult followers, or his dictator allies had written "covfefe" last year, the conspiracy theorists would be going crazy about it. Guess they're worth shit at spotting conspiracy theory opportunities that don't match their bias.

Very true.

By ignoring regulations, Uber is actually stealing from all law-abiding residents: if a cab goes out of business and can't pay the loan for their licence, the bank will make up for it off the backs of their other clients, which include me. When someone takes up an unlicenced job, paying no taxes or social security, I, as a middle-class tax-payer with an real job, get to pay in their place.

Competion is good in many cases, but when there is no need for expensive licences for new entrants, while those who bought them still need to pay their loans, things are so biased that you can't decently call it competition. Licences might be too expensive, but to keep things fair, the prices would need to change gradually, not overnight

And by profiting from people's desperation, Uber is indirectly contributing to the violence, as desperate people tend to forget to be "reasonable" (to make things worse, successive governments have a common track record of often listening to and backing down from aggressive protestors, to make problems "go away" fast, while violently evacuating peaceful protesters when protests last too long, so to someone desperate, choosing violent protest might actually be logically sound even though morally wrong).

In addition to that ridesharing is rather encouraged as being "green", while Uber is parasitic.

Ride sharing probably doesn't take that much business out of taxis, as it is especially popular for long distances, where a taxi ride would be way too expensive (and people first need to go to a meeting point), while taxis make a lot of their business in evenings when it's too late for public transportation and you've chosen to drink rather than drive (and most of them here in Paris are actually quite decent, and I don't care if they have a tie, as long as they and their taxi are clean).

Occasional, non-professional drivers might have a real use in remote areas where a taxi couldn't make a living by lack of clients, but then that's not what taxis seem to be complaining about.

Actually, things are much more complex, and as some other poster mentioned, these issues are the continuing subject of research, and are expected by the supercomping community since quite a few years (simply projecting current statistics, the time required to checkpoint a full-machine job is would at some point become bigger thant the MTBF...)
The PhD student mentioned seems to be just one of many working on this subject. Different research teams have different approaches, some trying to hide as much possible in the runtimes and hardware, others experimenting with more robust algorithms in applications.

Tradeoffs on HPC clusters are not the same as on "business" type computers (high-throughput vs. high availability). For tightly coupled computations, a lot of data is flying around the network, and networks on these machines are fast, high throughput, and especially low-latency networks, with specific hardware, and in quite a few cases, partial offload of message management, using DMA writes or other techniques which might make checkpointing message queues a tad complex. The new MPI-3 standard has only minimal support for error handling, simply because this field is not mature/consensual enough, in the sense that not everyone agrees on the best solutions yet, and these may depend on the problem being solved and its expected running time. Avoiding too much additional application complexity and major performance hits is not trivial.

In addition, up to now, when medium to large computations are batch jobs that may run a few hours to a few days on several thousand cores, re-running one a computation that failed due to hardware failures once in a while (usually much less than one in 10 times is much more cost-effective than duplicating everything, in addition to being faster. These applications do not usually require real-time results, and even for many time-constrained applications (such as tomorrow's weather), running almost twice as many simulations (or running them twice as fast in the case of ideal speedup) might often be more effective. This logic only breaks with very large computations.

Also, regarding similarity to the cloud, when 1 node goes down on most clusters, the computation running on it will usually crash, but when a new computation is started by a decent resource manager/queuing system, that node will not be used, so everything does not need to be replaced immediately (that issue is at least solved). So most jobs running on 100th or 1/10th of a 100000 to 1 million node cluster will not be too much affected by random failures, but a job running on the full machine will be much more fragile.

So, as machines get bigger and these issues become statistically more of an issue, an increasing portion of the HPC hardware and software effort needs to be devoted to these, but the urgency is not quite the same as if your bank had forgotten to use high-availability features for its customer's account data, and the dradeoffs reflect that.