XCabbage

I don't really understand what problem this is meant to solve at first glance. It'd be nice to see a simple example program involving concurrency written in plain Python, then a discussion of the annoying bookkeeping involved in avoiding concurrency errors and what traps would be easy to fall into, and then an example of how the same thing would be implemented using Lingua Franca and an explanation of how eliminates the bookkeeping and traps.

Why is Masley "problematic" and what's he been wrong about?

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!

How did the title end up wrong on HN (schemes vs scenes) and what's the mechanism to get a mod to fix it?

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.