Only at the level of Java source. The JVM (and several other languages) doesn’t actually care or enforce which exceptions a method might throw, which is what makes tricks like https://projectlombok.org/features/SneakyThrows possible.
It took years to root out and torch flawed APIs from the JVM ecosystem. After that example, it’s hard to defend neglecting the problem again and launching with no solution.
Apparently the right number is 90% of 21+10%, because amortization starts at the midpoint of the first year. (If you take authoritative tax advice from me you will totally go to jail.)
If we spent $1M in year one, we are surely going to spend more than $1M in year two because the same teams keep working and hiring, and we are incrementally building a system whose fully delivered cost as of its last day will be over $5M.
This makes most salaries nondeductible, so you will need about 25% more revenue (80% of 21% federal and up to 10% state income tax) to break even than
otherwise. If you’re pre-revenue your runway doesn’t change.
I happen to work on a system that launched more than five years ago, which at my company is pretty unusual (without at least one full rewrite). The teams working on generalizing use cases and new features have expanded every year since launch. Amortization makes sense for spreading out the tax deductions on an investment whose cost is fully front-loaded, but not on an investment whose cost is incremental and continually increasing over the entire lifetime.
> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET—All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
We are made of meat. It’s rarely worthwhile to sacrifice developer effort to conserve hardware, and if you do manage to break even today, you probably won’t in the future. Async Java was pretty painful and only penciled out because the cost of a million native threads was just ludicrously higher than everything else.
init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it?
Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost.
systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.
https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%8... is interesting but I wouldn’t want Google Sheets to display it in a modal every time I hit the “/” key. A recipe needs a very high signal:noise ratio when it’s going to be followed in real time while food is cooking.