Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits?
(Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a handful of trusted people can publish to the default repos for system package managers and 2. that since I have to run `apt-get install` as root anyway, package installers can completely pwn my system if they want to and I am protected purely by trust. Is some of that wrong? If it's right, isn't it nonsensical to be any more worried about installing new packages in light of these vulns?)
> If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases
In my experience (of primarily web dev), this is not true, and the reasons it is not true are not limited to software architecture conflicts like you describe (although they happen too). Instead the problems I usually encounter are that:
* once you have shipped something and users are relying on it, it limits the decisions you are allowed to make about what features the system should have. You may regret implementing feature X because it precludes more valuable features Y and Z, but now that X is there, the cost of ripping it out is very high due to the backlash it will cause.
* once you have shipped an application, most of the time when you add new features you are probably slightly changing at least some UI, and so you need to think about how that's going to confuse experienced users and how to address that in a way you wouldn't have to when implementing something de novo. For an internal LOB app, that might mean creating announcements and demos and internal trainings that wouldn't be necessary for greenfield work.
* the majority of professional web dev involves systems with databases, and adding features frequently involves database migrations, and sometimes figuring out how to implement those database migrations without losing data or causing downtime is difficult and complicated.
* as web applications grow their userbase, the scale of the business often introduces new problems with software performance, with viability of analysing business-relevant data from the system, or with moderation or customer support tasks associated with the system, and these problems often demand new features to keep the broader business surrounding the software afloat that weren't needed at launch.
* software that has actually launched and become embedded in existing business processes inherently tends to have many more stakeholders in the business that care about it than pre-launch software, and those stakeholders naturally want to get involved in decision-making about their tools, and that creates meeting and communication overhead - sometimes to such a degree that stakeholder management and negotiating buy-in ends up being an order of magnitude more work than actually implementing the damn feature being argued about.
To the extent that the amount of work involved in implementing a new feature is inflated by these kind of factors relative to what would have been involved in doing it de novo, I personally conceive of that as "maintenance" work; and in my experience my work on big teams at successful businesses has on average been inflated severalfold by those factors. (I also count work mandated by legal/compliance considerations that arise only after a successful launch as "maintenance". My rough conception of "software maintenance" is that the delta between "the work involved in building a product de novo with the same customer-pleasing features that ours has" and "the work we actually had to do to incrementally build the product in parallel to it being used" as "maintenance".)
Would most people agree with my broad notion of maintenance? I reckon they roughly would, but it's hard to say since people who talk about maintenance rarely attempt to define it with any precision. You give a precise but extremely narrow definition above. Wikipedia likewise gives a precise but extremely broad definition - that maintenance is "modification of software after delivery", under which definition surely over 99.999% of professional software development labour is expended on maintenance! I guess my definition puts me somewhere in the middle.
> Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it
This feels ludicrously backwards to me, and also contrary to what I've always seen as established wisdom - that most programming is maintenance. (Type `most programming is maintenance` into Google to find page after page of people advancing this thesis.) I suspect we have different ideas of what constitutes "maintenance".
Ah, right, sorry, I misunderstood the definition of "axle weight" I got when I hurriedly googled it even though the name should've made the meaning obvious.
More importantly, employees with options are generally not sophisticated enough to realise liquidation preferences may exist and may dramatically devalue the common stock options they have, and even if they are sophisticated enough, they will often have no means to find out what liquidation preferences exist. (They theoretically have information rights that probably entitle them to that info, but companies simply find spurious excuses to refuse books and records requests, knowing no options holder is going to drop six figures on a lawsuit to exercise those information rights.)
Liquidation preferences that merely guarantee you get back the cash you put in before anyone else gets anything are a perfectly reasonable protection for investors.
Otherwise, the risk is investors put in $1m for 10% of the company, only for the founder-CEO to decide a month later - perhaps totally genuinely and honestly after initial R&D - that the entire business plan wasn't viable after all and the best thing for stockholders is to liquidate the company... and then walk away, personally, with $900k while returning only $100k to the investors. And obviously because this scenario is possible, there would be great temptation among dishonest founders to "realise" their companies "aren't viable" in order to walk away with all the cash. Something has to protect investors from this outcome, and remove the perverse incentive on founders to promptly liquidate after getting investment. A liquidation preference where the investor gets repaid before any distributions go to other stockholders is one way of achieving that protection; what alternative would you prefer?
As for liquidation preferences with a multiplier (i.e. we get paid back X times our investment before anyone else gets anything), eh, I wouldn't outright make them illegal, but it's less clear to me they are always serving a legitimate purpose, and they may grossly mislead the public about the actual valuation of the company implied by a given funding round AND mislead naive common stockholders and options holders about how much of the company they really own and what they can really expect to make in an exit.
At the heavy end, SUVs weigh about 3 tonnes, while at the light end buses weigh about 12, a 4x difference. 4^4 = 256. So if the claim about the fourth power is true, you'd need to replace 256 SUVs to break even on wear, which is obviously impossible.
(I don't really understand how the fourth power of axel weight thing can possibly be true, though. Why would joining two vehicles together into a mega vehicle with double the weight and double the wheel count suddenly cause the combined vehicle to inflict 16x more wear than before you joined the two together? It makes no sense.)
I certainly claim that almost nobody "commits" that "fallacy" and that it is not a remotely notable viewpoint in the civic discourse of any country I know about.
No doubt in a world of 8 billion people, there exists someone, somewhere, who has for some reason voiced the belief described - i.e. that if institutions really heavily based their selection of applicants on skin color rather than merit, that would be good, but that because in reality institutions have only been convinced to somewhat compromise on merit-based selection in favour of skin-color-based selection, it's bad, and should thus be abandoned completely in favour of total meritocracy. But that belief would really be rather odd, and I have never seen it expressed even once in my entire life.
Nor am I convinced, despite its oddness, that it is properly considered to contain a fallacy! After all, sometimes it really is the case, for various reasons, that some endeavour is only worth doing if total success can be achieved, and not worth the downsides if you can only succeed partially. No doubt if someone really held the allegedly fallacious view described, they would believe affirmative action is exactly such an endeavour and be able to explain why!
I would guess that what matters most is stops for driving disqualified/uninsured/unregistered, DUI, running lights, and failing to yield (especially at crosswalks), and perhaps for speeding on non-highway roads where it has more of a safety impact. As you say, in the USA as in virtually every culture, almost everyone speeds in some contexts, and especially on big, multilane, motor-vehicle-only roads; enforcement of speed limits in that context is likely one of the lowest impact things police can do, but I think it's a massive error to treat "traffic stops" as a category as equivalent to that sort of enforcement specifically.
Well, actually, no, not everyone is free to use alternatives. Anyone using CI for "Trusted Publishing" of packages to PyPI or npm needs to use GitHub Actions or GitLab CI/CD. CircleCI and Travis CI are not supported. So many big open source projects for the two most popular languages in the world are now locked out of the alternatives you propose.
(I find it extremely sketchy from a competition law perspective that Microsoft, as the owner of npm, has implemented a policy banning npm publishers from publishing via competitors to GitHub Actions - a product that Microsoft also owns. But they have; that is the reality right now, whether it's legal or not.)
The 30% figure is "correct" if you look at the absolute number of deaths instead of deaths per VMT. But I basically agree with you; that clearly the wrong stat to cite if you are attributing the change to vehicle safety regulations.
2020 wasn't just the start of Covid, but also the start of BLM. The narrative I always see from the American right is that BLM caused many police forces across the US to radically reduce traffic enforcement, since:
1. traffic offenders are disproportionately black,
2. stops for minor traffic offences can sometimes spiral into violence in various ways, and some viral ones have involved absurdly bad use of force decisions by officers involved, and
3. no force wants to take the blame for another George Floyd
Per this narrative, a significant antisocial tranche of the public has responded to the effective suspension of traffic law in the way that you would expect them to, and that is why road deaths are up.
I assume you're an American? As a Brit, your comment confuses me. Why would anyone ever have high beams on at all in anything reasonably described as a "neighbourhood"? Do built-up areas in the US not reliably have street lighting?
Here in the UK, it is pretty much universally the case that if there are buildings, there are street lights. (Maybe there are occasional exceptions where there's a single building in the middle of nowhere on a rural road; I'm not sure. And I suppose there must be occasional outages of street lighting even in e.g. dense city centres. But such things are rare.) Having high beams on in almost any context where there are buildings around is therefore unnecessary, against the Highway Code, and quite possibly criminal under RVLR reg 27.
Hmm. That'd be pretty nasty to be on the receiving end of (and may well have been an outrageous abuse of executive power), but still, an administrative freeze is temporary and is not in itself a clawback. Even if it was a certainty this would happen to PSF, it would still be worth it for $1.5 million!
> Why was the clause included if it's completely redundant?
It's not and I didn't suggest it was. It gives the NSF itself the ability to litigate discrimination by grantees (in order to claw back its funds) instead of only the people discriminated against and the EEOC being able to do that. That's a real effect! But it doesn't impose any new obligations whatsoever on PSF - just changes the recourse mechanism if PSF violates legal obligations they already had.
> When the federal government cancels your grant and claws back money you've already spent because they claim something innocuous is illegal
As far as I know this has not happened in any of the cases you mention and _could_ not happen. Yes, grants have been cancelled for dumb reasons, but nothing has been clawed back. Right? What would the mechanism for clawing back the money without a lawsuit even be?
The burden of proof is "on the balance of probabilities" in both cases as far as I know, and there's no limit in principle on how high a breach of contract case can be appealed.
Of course it has an effect, but that effect is giving the NSF the ability to sue over a grantee's alleged breaches of discrimination law, instead of that being limited to parties discriminated against and the EEOCs.
I don't understand what you're trying to say. It's obviously possible for the extremely weak claim made by statement 2 to be true (i.e. for some non-zero number of "deserving" nonwhites to exist and for existing hiring to not be a perfect meritocracy) in the same universe where the sort of programs typically labelled "DEI" tend to have anti-meritocratic effects. You seem to be suggesting that if competent nonwhites exist, then anything labelled DEI will automatically have the effect of causing orgs to hire more competent people, but... why? There's zero reason that should logically follow.
A point made deep in a comment thread by user "rck" below deserves to be a top-level comment - the clawback clause explicitly applies ONLY to violations of existing law:
> NSF reserves the right to terminate financial assistance awards and recover all funds if recipients, during the term of this award, operate any program in violation of Federal antidiscriminatory laws or engage in a prohibited boycott.
So there's no plausible way that agreeing to these terms would have contractually bound PSF in any way that they were not already bound by statute. Completely silly ideological posturing to turn down the money.
(Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a handful of trusted people can publish to the default repos for system package managers and 2. that since I have to run `apt-get install` as root anyway, package installers can completely pwn my system if they want to and I am protected purely by trust. Is some of that wrong? If it's right, isn't it nonsensical to be any more worried about installing new packages in light of these vulns?)