choeger

"most settlers". Settlements can be legal according to Israeli law.

> Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.

That's probably about the time when your development pace goes downhill.

I think it's an interesting idea to consider: If some team interfaces with something outside of its control, they need to have a mock of it. That policy increases the development effort by at least a factor of two (you always have to create the mock alongside the thing), but it's just a linear increase.

I don't think that moving the whole thing into our orbit would make much sense.

The biggest amount of delta-v is necessary to leave Earth's gravity well. Once you're there, going from and to asteroid is time-consuming but doesn't need that much delta-v, moving ore from the asteroid to Earth would cost some fuel, proportional to the mass.

So moving it into orbit would save time but require us to pay for the fuel all at once.

So why should someone do this, unless you need a permanent human presence on the asteroid?

Let's see if some data protection officials have the balls to sue companies that use that on their work machines.

It should be obvious that this technology and some "AI"-based analysis makes for a nifty "productivity assessment" of your white-collar employees.

While this might sound great at first, it comes with a tangible risk: In a worker-owned enterprise, workers cannot freely sell their stock (or it would not be worker-owned for long). So their wealth is tied to the company and the value of every stock hinges on the company's long-term success. Imagine going into retirement with this six-year plan to learn that the company goes bankrupt one year later.

Of course, there are probably ways to try to minimize the risk (e.g., saving the profits for the payout and keeping them separate from business cash) but it won't be very diverse. Or maybe several such companies could put their stocks in a basket and allow employees to diversify their portfolio.

So I think it's a great idea as an add-on, but no one should bet their retirement on it.

> You or I can not buy stock in them.

But that means employees cannot sell their stock, either. So if one of those millionaire employees retires and the company goes bankrupt one year later, the million is worthless all of a sudden.

Well, that explains why Cuban cigars are impossible to get since a couple of years...

30 degrees north. That's about Kairo, for reference. I would not be surprised to see Mangroves at that latitude.

It's probably more surprising that these areas aren't already subtropical. Climate change seems to reduce whatever factor caused the cooling there.

Or, and that maybe a radical idea, YOU DON'T INSTALL THIS FUCKING SNAKE OIL IN THE FIRST PLACE.

The idea of antivirus software is laughable when Adobe cannot implement a safe and secure PDF parser then how can Crowdstrike while simultaneously supporting the parsing of a million other protocols?

Everyone involved: Vendor, operator, and auditors who mandate this shit are responsible and should be punished.

YOU HAVE TO MINIMIZE THE ATTACK SURFACE, NOT INCREASE IT.

It massively increases your attack surface but lets you tick the "cybersecurity" box on your audit. It's a good trade for many people, it seems.

It's eye-opening how bad our crucial IT infra is nowadays. Running in-kernel third-party tools (AV) on critical infrastructure on Windows? Central banks? Control towers? Seriously? We should fire everyone involved and start IT from scratch. This level of negligence cannot be fixed.

Where I live, most people will hesitate to buy into a yearly plan.

I'd suggest to make it possible to gift someone x years of your service, because that's something many people will happily do. The only thing to avoid here is any kind of automatic retention. One year is one year, period.

The obvious downside is the number of examples computed. A simple unit test can easily take 100 times as long when property-tested.

Besides, it would be really cool to have property-based integration or hybrid unit/integration tests. Or even property-based E2E tests. Unfortunately, the setup of the example will almost always take too long for a relevant set of runs.

For instance: If you have a basic data model (say in sqlalchemy) and want to write property-based tests (say in hypothesis), you can relatively quickly derive strategies for the models (but beware of recursion and primary keys). But writing that model instance into the DB for running an example just takes too long for swift testing.

> It works because when you have a bug/error message, instead of spending a bunch of time on Google/searching on stack overflow for the exact right answer, you can now do this:

That's not how I work since I stopped being a junior dev. I might google an error message/library combination if I don't understand it but in most cases, I just read the stacktrace and the docs, or maybe the code.

I don't doubt that LLMS can be quite useful when working with large, especially foreign, codebases. But I have yet to see the level of "if you don't use it you're not an engineer" some people like to throw around. To the contrary, I'd argue if you rely on an LLM to tell you what you should be doing, you aren't an engineer, you are a drone.

> Furthermore, if you are a software engineer and you haven't included tools like github copilot, or cursor AI into your workflow yet, I simply don't consider you to be a serious engineer anymore. You've fallen behind.

That sounds like you're fresh out of college. Copilot is great at scaffolding but doesn't do shit for bug fixing, design, or maintenance. How much scaffolding do you think a senior engineer does per week?

Ozempic reduces appetite, right? So food producers cannot be happy about it.

Regulatory fears, not fears of getting it wrong. That's just trying to pass the buck to agencies or lawmakers. As soon as someone in this chain gives in, e.g., an official short before retirement or in need of a consulting gig in the "AI" industry, the "best practices" will be applied everywhere just out of FOMO. The results will be ... interesting.

That being said, I still think LLMs will make for novel user interfaces.

You are not free to perceive any information. In our society, some people have the right to decide whether or not you can watch a particular football game, look at a particular image, or know a particular prime number, as ridiculous as that sounds. Freedom of information consumption is an illusion from the days when law enforcement in the internet wasn't a thing.

Industry and state have a large interest in this and in just a few years they will have total information dominance. This won't require awkward measures like attacks on DNS or VPN providers. You simply won't be able to execute unvetted software soon. Chat control is just an example and the first step. The principle will be: You can only run software that fulfills all legal requirements, especially if said requirements monitor your well-behavedness.

> ??! You've got a system of unpredictable reliability and you're going to let it handle money?

Yes. Recall phone banking? I imagine it like that. Potentially via a chat service like Whatsapp or signal.

You'd start with simple standard tasks and low limits, if course. But the risk and value can be directly quantified in online banking.

"AI" (or rather language models) will change the world. But in a very different way. They aren't (and won't become) AGI. They aren't (and won't) replace software engineers (but maybe help them to write better software, or more realistically churn out even more bad software). And they aren't and won't become ultra-wise oracles that can solve any task you throw at them.

But they are an interface between the real world and computing, because everything in the real world revolves around human language. Here are a few things that are actually solved by now, even if we did not yet fully recognize it:

1. automatic human-human translations

2. collection and annotation of all kinds of real-world data (with the help of image recognition, of course)

3. human-machine communication (not decision-making, mind you.)

The most crucial aspect is that other human-machine interfaces will become less relevant. In particular web pages and mobile apps. They might stay as an attempt to capture attention, but they will become less and less relevant for actual usage. Here are a few services that might get by without a web browser or app soon:

1. online banking

2. delivery services (and others like Uber)

3. small business that basically only need to manage appointments online (doctors, lawyers, car shops)

Capers are very common in my family's refrigerators, but still mostly used for a single dish (Königsberger Klopse). And the jars have been tiny for as long as I can remember. So it seems to be a universal design decision.

A radical point of view. And as such it is of course wrong ;).

First of all, there are languages where dry-running your code with all parameters mocked is still a valid test run. Python, js, and Perl for instance make it very simple to have a stupid error in the routine that crashes every run.

But more importantly, a unit test usually executes inside the same process as the code. That gives you tremendous introspection capabilities and control over the execution flow. Testing for a specific path or scenario is exactly what you should do there.

Finally, what if not mocks, are in-memory filesystems or databases? They, too, won't show all the behaviors that the real thing will do. And so so test containers or even full dedicated environments. It's all going to be an approximation.

Will this drug ever stop giving? What does it do next? Stop dementia? Fix short-sightedness?

What everyone seems to be ignoring when it comes to autonomous cars is that the last 1% or 0.1% or whatever remains unsolvable for "AI" might not really matter.

We can change roads, ffs! At the bare minimum, we could fence off difficult areas and force manual driving. Once many people own an autonomous car, there will be pressure to make roads safe and convenient for them.

Phantom braking for instance, is only a safety issue when the following car gets too close. Lanes can be annotated, etc.

The "AI" part is just marketing to get these cars on the road and set the customer's expectations. Once that is done, the hard parts will just be moved from the car manufacturer to the road builders.

Rationally it's more like a "oh shit we're too late to exit now" situation. The stock would have crashed if they'd denied the package. So they voted for it and hope to sell afterwards for a better price.

We know for a fact that cats, dogs, and humans do.

It's a shame that TeX the great typesetting system comes with TeX the ungodly complex language. There's literally no chance to create good tooling for TeX because of this. There's very little chance to optimize rendering of large documents because of it (e.g., by automatic parallelization). Finally, there's never going to be a readable error message from TeX.

TeX the language is the prime example of gatekeeping.

OTOH, no one has ever succeeded in creating and popularizing a context-free language that compiles to TeX.

This. The next time, there's a real disagreement in trade policies, Europe is going to be fucked. Microsoft does have access to literally everything and no one even seems to understand that, because no one understands what "cloud" or even just "online vs. offline" means nowadays. It's a bit scary.

Let's hope they continue making progress. Expected failures are fine. Unexpected failures have the potential to derail such a program for years.

Interestingly, when I switched to HO during Corona, I put my glasses away as I was working on a notebook (sometimes even outside). My eyesight has improved markedly over these last years. I still need glasses gut the effect is definitely unexpected for my optometrist. I even joked that he might not see me ever again if this trend continues.