If you're trying to upgrade or rebuild ten year old software, it's very important to know exactly what its dependencies were and where to find them, because there are too many other versions to choose from and most of them won't work. New software only needs a lockfile because it will eventually get old (if useful).
Just one cheeseburger is three miles of running. Not only is it very easy to shop and overeat, your body continually encourages it. The only way out is determination not to eat whatever you want.
Caching is the most important reason to consider GET for a non-hypertext API. Vary headers tell the server which header diffs should cause cache misses, but there's no way to do that for an encoded body.
https://en.wikipedia.org/wiki/SPECint talks about a dozen programs they selected for single-core logic and discrete math, including gcc and bzip2 (there are more than a dozen others using floats).
I would think they have to keep the commitments in the charter, and only the board can propose changes for shareholders to vote on (because they own it all).
In that case the mistake was the overhiring rather than the layoff. And it's hard for a board to admit that the entire plan (which they probably approved) was a mistake from the beginning. If the CEO fails at making the plan work in an obvious way, he's probably out.
Edit: As I understand it, he's out if the board thinks they will recruit someone who would have done better.
Lots of boards have pushed out CEOs who performed poorly enough: Apple, Disney, HP, IBM, Twitter, and Yahoo are well known. But the performance is expectations around market share, profits, stock price, or dividends, not burning as much money as possible on payroll.
Tech companies wire rows of desks for laptops and big monitors, but I think it'd be hard to find a meeting room where you could safely plug in more than a dozen 140 W chargers.
Over years, I've worn laptops (with sealed-in batteries) down to three-ish reliable hours. There are never enough power outlets (or AC vents or even seats at the table) for a big meeting. That's a problem for a very long meeting format like a war room or a promo committee.
Rust's borrow checker proves some invariants that the code always upholds. Valgrind only checks that this run hasn't triggered some undefined behavior so far, it's always possible that (ab)using it further or another run with different input might.
I'm a little concerned about ESBMC's "simulating a finite prefix of the program execution with all possible inputs" when important software like operating systems are intended to run indefinitely. Would they start with a valid state (filesystem, process list) and prove no invalid state is reachable within n syscalls or interrupts? Maybe I was hoping for proving invariants.
I'm a little familiar with TLA+ but it can't verify the actual code you want to run, only a restatement of your intended algorithm. Are there published model checkers that can check real C++? How would they catch double-free or use-after-free or double-throw?
I switched to using the trackpad full time, because the mouse randomly bricked itself unless I let it distract me about its state of charge and whether my only cable was at home or my office desk.
That system doesn't seem to take you to every Bucharest address in ten minutes, only popular ones. I picked a few buildings at random in Google Maps and got hour-long L-shaped trips (detours into downtown) that would have been fifteen-minute drives. I don't think any pre-scheduled routes can cover n^2 trips well.
From Fremont, CA, the Sunnyvale office is a 40-minute wait for a 16-minute bus to a 12-minute wait for a 14-minute train to a 14-minute wait for a 48-minute bus (making 34 stops). Google estimates I could get there in two and a half hours. Getting home after 11 PM is more like four hours.
It's only 22 miles. A replacement for a car should be able to do this in about 32 minutes. But it would have to go point-to-point on demand, they can't cover the spanning tree of n^2 possible trips with any reasonable frequency (mostly because n^2 taxpayers don't exist, nor housing for them).
"Transport to where-ever you need to go, an what-ever time you need to go there" has to functionally be pretty car-like. My question is how he wants to dispatch it on demand so it doesn't need to stay parked near us.
Memory and concurrency safety need to be the first steps, because how can you analyze results when the computer might not have executed your code correctly as written?
Early MySQL versions made egregious design choices like quietly ignoring missing foreign keys and enum typos, truncating long strings, and randomly choosing rows from groups.
Decisions should be made in writing, so everyone gets some peace and quiet to deliberate, and we don't change our minds because nobody remembers what the outcome was (sounds crazy but I have seen this happen).
If PostgreSQL has replication, why are they talking about "minimal" downtime? Is there no quorum strategy that delivers high availability? I don't know as much as I should.
One of the things I like about cloud is that it's relatively easy to spin up an isolated full-scale environment and find out where prod's redline probably is. On-prem hardware might have different bottlenecks.
I think having deep work to do is the biggest sign that a team has found a good use for me. It's how tech companies build competitive products. Commodity work should be automated; Moore's Law already paid for doing that.