structural

You could very likely fund fixing the software of every astronomer on the planet for less than the cost of one outage caused by adding/removing a leap second when you look at Meta + Google + a few telcos.

For humans, it's no worse than folks today who live on a time zone boundary and cross it often. You might argue that for humans, the local solar time should be computed as a continuous function of longitude, leap seconds can be managed there, and we get rid of the concept of a time zone.

Computers are another story though, perhaps in the past "a typical computer clock" could be on the order of seconds off and be fine. When computers start to control things like wireless networks (cellular is a problem today, time accuracy is a design factor in evolving Wifi as well), those seconds turn into microseconds very, very quickly. The whole point of the article is to reduce unnecessary complexity in the existing complex time synchronization systems.

If you're running large infrastructure, the next leap second is going to cause an outage somewhere in your org, and the cost may be very large.

This is actually where NASA gets a significant amount of hardware: manufactured parts from intelligence programs that were the rejects from those production lines. Hubble was a prime example of this, but there are many others.

For many people, going to a store the same day is completely impossible (not having a store within reasonable distance that stocks any similar product).

This is not just rural areas, either: even in major cities items can be delivered faster than the time it would take to find a store that carried the item, go to the store, get it, and come home again. It's really only suburban areas with a high density of big-box retail that even have the option to "go out and get something" immediately.

Amusingly, it's also only in these suburban areas where next day delivery even exists to compete. As an anecdote, living in the downtown of a major American city (population > 1million), the average Amazon delivery time is roughly 3 days, and last mile deliveries are all delegated to the USPS which adds significant time.

It's for the end user who purchases a lot of things which include software components to understand the total set of software they're running and be able to ask questions about licensing, vulnerabilities, and establish policies.

A developer (or even administrator of a single computer system) is not the user of something like this, typically.

Here's an example:

A small manufacturing business may have a dozen different machines. Each one has a set of software to control it, running on a computer embedded in the machine. The business also has a website (developed by a contractor), a bunch of software packages purchased from different vendors for accounting, inventory, payroll and scheduling. They probably have some internal home-grown tools too.

1. A new remotely exploitable CVE is announced in a widely-used open source library. Is the company vulnerable to it? Anywhere?

If each one of the pieces of software was delivered with a SBOM along with the actual code, you can use tools like this to look at this globally. It starts to make more sense at the scale of "all the software in the business" is provided by tens to hundreds of different vendors or teams that not only don't communicate with each other but also don't even know that the others exist.

And most of them were tuned for profit too, so it's not like this is a new concept. It does feel like a lot of the mobile and F2P monetization folks are the same ones that enjoyed profiting from arcade games and see them as being similar to slot machines (except better, because they only pay out in neurochemicals, not money!).

There's been a quiet war for decades between people who want to design games as art, and people who want to design them as a predictable recurring revenue stream. I'm not sure what iteration we're up to now.

These sorts of shenanigans a decade ago certainly influenced the creation of GDPR.

It's certainly not clickbait. If I wanted to fly to London for a meeting in 6 weeks and then fly home, I can no longer do so via Heathrow. It's not like I can just get an earlier or later flight, travel a day earlier, whatever. It's just not an option. That's a rather big deal.

It's hard when your customers are requiring you to do mutually exclusive things. First, reduce fuel consumption by significant amounts, which requires changes to aerodynamics or engines (this is just physics). Second, don't make any major changes, because major changes would be too expensive for customers to implement and make the whole project not feasible.

There's no "honest engineering" that will solve the problem. This is exactly what regulators are for, because there are huge incentives for the executives on both the airline side and the Boeing side to make a deal here... everyone saves money and takes home huge bonuses.

This generally means the aircraft is the best choice to prop up customers whose business is slowly failing, and would be severely harmed by having to invest in improvements to the supporting infrastructure. This is not altogether surprising since air travel has been increasingly commoditized, so aircraft operators who don't price in long term capital improvements can outcompete (or for the worse ones, just stay afloat at all) for some period of time.

So it's no different than any other business with eye-wateringly expensive infrastructure, really.

That's exactly what we do, which is why adding Tailscale SSH to our current workflow isn't helpful, since we would still have to manage SSH keys for access via the local subnet.

This is spot on. One interesting approach I've seen before is that all commands executed as the superuser must be written in file, and the only command accessible via sudo is "please_save_to_audit_log_then_run_it_in_sandboxed_env <file>". For particularly high-risk situations, there might be a second person reading your script before running an approval command that actually lets the script run. Things don't move quickly, but the number of mistakes via typo is certainly reduced.

I've been using Tailscale for years but will likely not use this feature, even though I would like to.

The fundamental problem with the approach really is that connections are different over the tailnet and over the local network. Here is a specific use case that is painful:

1. There exists a cluster of machines, each with large amounts of locally attached storage. They are all on the same local network and connected with 10Gb (and likely soon 40Gb ethernet interfaces).

2. Each machine is individually on the same tailnet so they can be accessed remotely.

3. Remote users frequently need to move large amounts of data between machines. A user copying a few hundred gigabytes of data with "scp" is normal.

4. For performance reasons, it's preferred to avoid the Tailscale/wireguard overhead when copying data between adjacent machines in a rack.

At this point, if I enable tailscale ssh for remote login, it appears that the problem of key management for connections between local machines (using ssh over the normal interface, not the tailnet) still remains, and in fact, the overall authentication configuration is more complex than it was before.

What I would love to exist, and would make me instantly use this feature, is if the tailnet issued SSH certificates (probably injected into its own ssh-agent?), the existing tailscale SSH implemention worked just like it currently does (it's great!), AND I could manually configure servers to accept certificates issued by the tailnet. Then SSH paths like "laptop --> (over tailnet) --> server 1 --> (over local network) --> server 2" could be made to work transparently, for those machines that need it, and for regular users, it still "just works".

Double (or more) encryption ends up happening a lot in larger networks not for technical reasons but for policy ones.

This is unsurprising, because it is used for different purposes in different layers of the stack. It is not at all a black and white state of "encrypted" vs. "not encrypted".

For example, in one organiztion I've worked with, Wireguard (generally, including Tailscale) is approved for restricting connections only to authorized network devices/users and that data maintains integrity in transit, but is not approved for protecting the confidentiality of sensitive information. Connections which access specific resources are required to be encrypted at the application level using a mechanism which has been approved for that information type (given a specific threat model).

So you could transmit very small amounts of data over TCP/IP, over a Tailscale network, using a set of pre-shared, one-time pads. And you might actually want to do this! It's really not ridiculous, but you do need to assess whether you really do have a threat model that needs it.

It's more than just a work/personal split. Even at work, having "development" and "production" tailnets so that things like testing complex ACLs, inhouse apps that use tailscale via its API, etc. are possible without having everyone on the devops team create an unmanaged/non-company email so they can create their own development tailnet, and then deploy a bunch of company IP using this rogue account.

It's a pain point.

This is the excessively fun part of dealing with crash dumps in general. Many of them are going to be 1% corrupt, 99% fine, and somewhere in them likely has vital information about what caused the corruption.

So the entire reason for being for things like rust-minidump are to make enough sense out of files that are known to be corrupt garbage to be able to find bugs.

That's not a positive for everyone, Matlab's API choices are a bit polarizing/confusing for people who don't use it.

Eigen is similar to xtensor, but with 1) Eigen being significantly more mature, and used in production in simulation/research environments and 2) Eigen having not just basic operations on arrays, but also a full suite of linear algebra operations comparable to a full BLAS library, including a full test suite. xtensor wins on having better integration with Python and other languages out of the box. There's also some performance limitations due to being inspired by numpy, particularly with respect to memory management.

This is great to hear. We've been happy users for a couple of years, and the device tagging support has come a long way (and is a big enabler for sensible ACLs), but trying to use Tailscale's ACLs in general has been our biggest pain point with the product.

DIMMs likely won't be a thing anywhere before too long. They're too large and problematic to deal with for the latest memory interfaces (which previously had only been found on GPUs). There's only so much you can miniaturize before the connectors become a real problem - and we can now put an entire "computer" in a single package.

I'm interested to see when the PC form factor goes away completely, likely 1-2 generations of product from now.

Direct retail / individual sales are always the least important and the first to get restricted amounts of supply so that large orders can be filled. There is a queue and lots of orders are moving through it, you personally just don't see this.

Depending on the product, volume orders for high-end ICs are typically running between 52 and 72 weeks of lead time at the present, and it's been this way for many months now. So the orders that are getting filled today for parts were placed in early 2021 in most cases.

This is generally very difficult for retailers, because they have had to come up with capital to have a year's worth of orders in the pipeline. So they've been having to stock fewer things -- only what they are absolutely sure will sell -- and can't use real-time sales data to estimate the next month's order.

Welcome to the new normal, it'll be this way for at least another year or two, minimum (until new factories get built plus pre-pandemic levels of productivity, for the most part).

You can look at CoD and similar games as being very basic introductory material to military ground operations - building a surprising amount of intuition from a young age. It's also useful as a propaganda & recruitment tool.

If you need to coordinate with someone who isn't sitting by a radio, you need to call them (including the local govt, your own civilian personnel, etc.). You might not be issued a radio at all, so a phone is what you have.

Commercial telecommunications are an important part of any military worldwide, when they are available - so you use them until someone actually starts DFing you accurately, and then even after that, it's a risk to be managed and certainly not black & white.

I'm in the exact same boat.

What's funny is that I would probably pay a reasonable annual cost for the service (I'm already paying an annual fee for the domain), but the way this is announced is enough to lose me as a customer, permanently.

- No links to the information in my admin.google.com panel - No personal notification at all to the billing contact - An automated "upgrade" to paying a monthly cost for a formerly free product

Yeah, no. This is borderline scammy, not the way to treat people who have been your customers for 15-20 years, and who disproportionately are responsible for spending decisions at their companies.

Any competitors to Gmail want my business and support custom domains / have a reasonable strategy for migrating data away from G Suite accounts?

The knowledge of a satellite's orbit is taken by using the prior parameters of the orbit, predicting where the satellite will be, and pointing a combination of telescopes (for precise angular measurements) and radars (for precise distance measurements) at this location, and measuring the error between where the satellite is and where it is expected to be. A set of these observations are then used to update the "known" orbit.

This known orbit is then provided back to the satellite so that it can be broadcast. If this system of updates stopped working, the quality of GPS position estimates would degrade pretty quickly (think weeks, not years).

This also means that if a GPS satellite were to need to maneuver for some reason -- either periodically boosting back into its assigned orbit or for debris avoidance -- the normal system of updates will catch this and users will never have to know or care that the satellite moved.

After the CI system (with network access) pulls down the code, including submodules, this code is then placed into a container with no network access to perform the actual build.

In any environment where compilation and linking is separate (this covers both static and dynamic linking, it's not just a shared library problem), you have many situations where a final application is assembled from a set of binaries that were compiled on different machines.

This means that realistically, even if every machine only has one C++ compiler installed, binaries compiled with different compilers will need to be able to interface with one another. Changing a language's ABI is a really, really big deal and not having a defined ABI at all is even worse.

These days it's a lucky accident when the engineers and the end users are on the same continent and maybe speak the same language. The business will certainly optimize for lowest cost until it becomes so bad that it's impossible to overlook.

Managing by walking around is still amazingly more successful than managing by arbitrary metrics, but it's still rare.

And by comparison, a nice gas range is significantly superior to all of the electric cooktops I've ever used. By nice gas range, I mean one of the 6-burner types on one side, griddle on the other, and double side by side ovens. I'd happily electrify the rest of the building if it was economical to do so (it's still not in many places), but having gas for cooking is the one hard, non-negotiable feature I have in a property.

I suspect the average lawmaker does not take cooking seriously, which I think is fairly sad.

I laughed out loud reading at his devicetree frustration, because while it's pretty gross to work with at times, at least it's not ACPI!