travisb

Firstly, do you want to prevent corporations from taking loans against their assets? Preventing that seems like it would be quite detrimental.

Secondly, how do you differentiate legitimate corporate expenses from personal expenses? Is a billionaire having one of their corporations rent a yacht from another of their corporations for a business meeting with another CEO who just happens to also be their friend a legitimate business expense or a personal expense? What if the yacht rental company rented it to the CEO's company instead?

However, sometimes the details matter. For example, a 'patch' (diff + description) tends to be small enough to transfer conveniently, and human friendly. Patches do not describe their relationship to other patches, so it makes sense to talk about a series of patches which must be applied in sequence to accomplish some larger goal. 'patch' doesn't imply any particular storage format, so sometimes saying 'attachment' or 'patch file' or 'email body' is an important distinction. Git documentation assumes you know what you want. It might help to think of patches as "outside time", though of course any particular version of a patch will only apply to a subset of all snapshots.

A 'commit' (snapshot + description), on the other hand, tends to be large in that it describes the entire state of the codebase and contains (implicit or explicit) metadata describing its predecessor(s) -- possibly a large graph of them. People talk about a 'commit series' all the time, but use the terms 'history' and 'branch' instead.

Stacked PRs are built on top of commits and branches to gain the advantages of a patch series while retaining the advantages of snapshots. There's no industry consensus on if they are preferable, let alone how to best implement them (eg. rebase, rebase+squash, merge-squash, merge+first-parent, etc.), so different people have different ideas about what they look like. It isn't correct to say they are just a series of commits, because sometimes they are implemented as a series of (implicit or anonymous) branches. One of the few agreed-upon features of stacked PRs (or its other names) is that it is a sequence of 'changes' which are ordered to both satisfy change dependencies and broken into smaller pieces which "tells a story" to reviewers.

When getting merge approval takes at least one or two business days (say because of time zones or your colleagues are doing deep work which they don't want to drop every fifteen minutes to do a review) the pipelining is necessary to be unblocked.

That additional layer allows finer grained history and to mostly avoid (unreviewed) rebasing. Many teams find those properties valuable.

It may very well feel that way to people who live in strong bubbles, but it just isn't true across the general population -- which of course is how the Overton Window is defined.

More tolerance is pretty much the definition of the social-left.

It's rather more likely that the increase of left-authoritarianism is due to increasing resistance to moving the Overton Window, both the left-most edge and the right-most edge, leftwards. As resistance increases more forceful techniques are necessary.

I suggest that maybe the key to success is limiting ourselves to simpler TTL logic and make up for it by adding 10% additional material. Immediately somebody responds that TTL logic is the old way and can't be as good as modern C, let alone Rust.

So now instead of a few hundred large, durable transistors and relays which shrug off radiation and heat and voltage spikes and a have few enough states that they can be formally proved correct, we need delicate 30+ MHz microprocessors which need special radiation hardening and which will go up in smoke if their signal lines transiently exceed 10 volts, and runs a couple million lines of code.

The arguments here for Rust aren't even wrong, which is the problem. In theory Rust would be better than TTL logic in every way: easier, cheaper, lighter, more capable, more logging, updatable. Professionally TTL is an argument which can't be won and is therefore career limiting to make, so finesse wins out.

Yet large projects of every type keep 'mysteriously' failing due to "unforeseen difficulties".

- We don't spend enough money

- We have a low tolerance for risk

- We choose high-tech, finessed designs over simpler, heavier designs

- The project is designed and built by international committee

It sounds like a recipe for failure to me. I'm skeptical that the USA will ever again land humans on the moon because the USA seems unable to spend enough to succeed by brute force and the supposedly cheaper finely engineered designs don't seem up to the rigours. For example, putting computer everywhere is common engineering practice these days, but modern computer chips (even the space hardened varieties) cannot be as robust as TTL logic from the 60s. Yet it sounds like a career ending event to suggest that the critical computation be done (and limited to what can be done!) purely in TTL logic.

GM did it in the early 2000's. It's not generally worth the trade-offs in a pickup truck (cost, durability, maintenance, weight capacity, wheel-well size, etc.).

I don't know why people are so happy to throw out the history. I find it's not uncommon that bugs are introduced during rebasing, and merging in from master. Sometimes this is due to incorrectly resolved conflicts, sometimes due to concurrent changes elsewhere in the codebase.

With --first-parent it isn't hard to have your cake (full history) and eat it too (linear mainline history).

Having worked extensively with patches as the semantic unit via patch(1) and quilt and stgit, I'm very skeptical that a VCS based on patches is actually superior in most circumstances.

In this particular case, perhaps it would be helpful to view code reviews as a snapshot where the differences (possibly intra-review revision differences) are highlighted instead of as patches.

It doesn't seem like a genie you'll be able to put back into the bottle without reducing the net tax take.

It also has all the other problems with estimating the true value of an asset.

PHEVs are optimal for many use cases: full-electric for most trips, but the ICE is there when it is the best fit (cold weather, long distance, towing, power outages, etc). The full electric range also helps offset of extra cost of the hybrid drive train, making the TCO more appealing for a marginal increase in total cost and yet the total cost is competitive with a BEV.

In some ways the push for BEVs has done the world a disservice and we could have had a much larger percentage of vehicle miles done on pure electric already if PHEVs had been pushed instead.

Secondly, those things you mention are true -- all else being equal. But everything else isn't equal. Eliminating thirty miles of driving a day can make up for a lot of extra heating costs. Houses can cheaply avoid major cooling costs like urban heat island effects, and lack of shade suffered by apartment buildings. Economies of scale in shipping is a thing, but past a tractor-trailer a day they diminish rapidly.

So it isn't as clear that, with the way people actually live in cities today, that the systematic carbon costs, or even financial costs, favours cities the way it might have fifty or eighty years ago.

Lower population density does not necessarily equate to higher carbon footprint, especially when commuting downtown for work has been eliminated. Above a certain point density has diseconomies of scale of its own.

For example, if you are comparing, say, a three bedroom house in a large metropolitan area versus a four bedroom house in a small town, the reduced total driving time because driving distances are less in the small town (everything is in town, but town is tiny) can make up for a lot of efficiencies of scale.

The common argument is that we should put people into apartments instead, but that isn't always a clear total system win. For example if somebody is really into fishing letting them live near a lake with space to store their own boat will be more carbon efficient than stuffing them into an apartment where every weekend they drive to the storage place on the outskirts of town to pick their boat up, then drive three hours or so to the lake.

My anecdote is that my in-office colleagues are less productive than they used to be when they were WFH. Mostly less motivated to do the asynchronous communication parts of the job, like code reviews, and scrolling their phones at their desk more. Also cutting work hours short, often through long breaks with their jacket hanging on their chair.

As for why not India or Europe, that's been tried and failed for coming on thirty years now. Timezones, language, culture all make it much less cost efficient than it sounds like.

Others have already commented on colleague resentment.

There's also the problem of being the only remote team member, or having to deal with company infrastructure which doesn't support remote work well "because we are all in the office anyways".

How much this matters differs from company to company, but often letting certain people continue to WFH while most of the company is RTO has a shelf-life before the WFH employee has enough of being a second-class citizen and leaves for a more remote-friendly company.

When money is cheap it's easy to spend a bit of money on political signalling. However when money is no longer cheap that pure cost centre is the first on the list for cuts.

It is theoretically plausible that end-users could mark their packets 'latency/jitter sensitive' or 'high throughput'. If there was an Internet-wide consensus that those two options made useful trade-offs then there would be an incentive to use it correctly. That would be as NN-safe as any other scheme.

For example, maybe 'latency/jitter sensitive' buffers less, but at a 25+% throughput penalty. 'High throughput' would then be faster, but have much higher latency/jitter.

The trick would be ensuring fairness without requiring too much hardware at scale.

As an approximate example, suppose if takes one hour for the tank/building to reduce to a thermostat set-point 10% lower than the 'high' set point. Further assume you could use that lower set point for 11 hours, so the tank/building temperature is 10% lower for a full 10 hours. Finally, assume increasing the temperature of the tank/building by 10% takes one unit of energy.

In order to maintain the low set point, the first hour is free since we are losing temperature. The middle 9 hours need (190%) = 0.9 units per hour for a total of 8.1 units. In the 10th hour the low-set point scenario needs to warm up to the high set point and overcome heat loss so that individual hour requires more energy than the high set-point scenario: (1110%) = 1.1 units for that single hour to return to the high set point.

In total the low-set point needs 0 + 8.1 + 1.1 = 9.2 units of energy over the 11 hours.

For the full 11 hours the energy required to maintain the high set point is 11 units (1 unit per hour to make up for 10% loss).

The variable per Kwh costs are historically generally pretty low relative to the fixed capex and opex (eg. maintenance, idle runtime) costs.

Mostly this has been made palatable for residential use by hiding these fixed costs in a higher per-Kwh rate. This works great as long as consumption is high and growing. If consumption trends reverse, then self-generation becomes a real possibility for the heavy consumers leaving fewer total Kwh to spread the fixed costs over.

Left unimpeded this leaves the poorest with very high energy bills when everybody else has shifted to a private, cheaper, micro-grid.

That's along ways away. It'll take a lot of costly electrical infrastructure to move that power.

Even worse, if you want to work during the night, you also want the solar panels about 45 degrees west. So like in South America. Tough luck for those places where that sweet spot is in the middle of a large ocean.

You can see that even in this very discussion where a substantial fraction of the comments are making claims that this ruling will prevent regulation entirely -- a claim entirely unsupported by the principles in question.

Modern designs depend on material science and computing abilities which could never have been made in the 70's no matter how much money was thrown at it.

My anecdotal belief is that China is doing well relatively in applied science _because_ it's companies which are doing the _research_. This provides a long-term focus, and access to resources not easily available to academic researchers. It also dramatically reduces significant overheads of the academic system like grant writing or constantly vetting and courting grad students to work with you.

Further, again anecdotally, I get the sense that most R&D in western corporations is much more _development_ than research. The research is very much done by academics with government funding. This has alignment and efficiency problems.

So it's pretty obvious that remote work doesn't need to hurt productivity and employees prefer it because commuting sucks.

Interestingly, since the trial randomized based on birthday one would expect that individual clusters (4-6 people) were often split such that two days a week the cluster should be considered fully remote. That is, about half the cluster was at home so everybody would need to communicate in a remote-friendly way on those days.

After the team lead has endlessly explained, reassigned, and simplified a person's tasks, and just generally tried their best to make the person a productive member of the team _and failed_, then they've given up and put them on a PIP so they can be let go.

AFAICT PIPs are must CYA's.

All these are places children used to go unsupervised, but now mostly don't.