ulrikrasmussen

Then we don't really need software anymore, LLMs can just receive every user input and perform the action required.

/s

This is a fun idea, although it doesn't really solve a problem for me since I find IKEA instructions to be extremely intuitive and easy to follow to begin with. Probably only LEGO does a better job at making clear, wordless instructions where e.g. ambiguity is resolved by cleverly using bright colored pieces in places where they are eventually obscured.

What I really would like is a universal furniture planning program which includes all IKEA furniture (and possibly third party furniture as well) and full configurability of the room. IKEA has design apps, but they are so frustrating to use because only some products are available in each app and they are wildly inconsistent in how much each allows you to configure the room shape.

I didn't mean another clause in CLAUDE.MD, but that one has to actually specify what they want instead of expecting the LLM to read minds

This also sounds a bit like an underspecified interface. If the class spec clearly states under which conditions it is thread safe then the agent can take that into account, but if it doesn't then the agent has to assume that it should guarantee thread safety in all contexts.

I think you also expand on that later, but that paragraph just gave me pause because it essentially says that if you hold it as wrong as possible, then bad things will happen. It's a bit like presenting an alternative to relational databases by pointing out that schemas with no indexes lead to hour long queries. I'm not interested in the hypothetical worst-case of the old system, I am interested in your average traffic and storage overhead when using it with a common caching setup.

I do accept the argument that a distributed architecture has inherent costs which can be managed better using a client-server architecture because you don't have to replicate state across all nodes. I have worked with both git and Perforce and see the appeal of both.

> We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day.

Who in their right mind would fetch that naively? For starters, CI runners should of course not do a fresh clone on each run. If you can't make them keep the repo, that sounds like a problem with your CI setup rather than your VCS.

This reads like a straw man.

You should consider scrapping him also.

I think you mean MitID, but yes. I have tried going through the process of getting a new MitID at the citizen service desk, and the questions I am asked to verify that it is me are almost all family related. If the leaked data reveals things like parent/child and spouse relationships then that process is cooked.

Only If you attribute every accident to "because they were on drugs"

Agreed. It's a major pain in the butt, and I wish I could just ship an int64 back and forth and not have to deal with mapping it to a calendar.

Really fun idea. Some immediate feedback:

* Moon is moving too fast, has too much influence.

* Movement breaks the game as you can just move up to the opponent.

* The timeout is frustrating. I can line up a shot that actually looks like it is going to be a direct hit just to have the game remove it as it starts descending towards the target.

Ah, yes, you are right! Forgot about those two details

The SQL standard is unfortunately really horrible when it comes to handling of time. The type `timestamp` is not a timestamp at all because it doesn't encode a unique point in time, it just stores a date and a time which has to be interpreted relative to a timezone. It should be called "datetime".

Moving a Java Instant back and forth between a database is also a surprisingly difficult task to do right, and it doesn't help that JDBC is just handling it completely wrong if you use its setTimestamp/getTimestamp methods. Not because it is a bad design with footguns, but because the implementation is just plain wrong and will corrupt your data if you deal with instants whose calendar date is far enough in the past due to it using the legacy date/time API which switches to the Gregorian calendar for dates in the past.

The name `timestamp with time zone` is also misleading because it doesn't actually store a time zone, it stores the number of seconds since epoch like a java.time.Instant (although at a different resolution). The "with time zone" part just refers to the textual format you denote the values in which includes the time zone after the date/time part to uniquely identify a timestamp, but the time zone is thrown away and not stored after the value has been parsed. This is different from e.g. `ZonedDateTime` in Java which will actually store the offset and therefore corresponds to a pair of (Instant, TimeZone).

A combination of different ones, sometimes close to what you know from the clearnet, i.e. click pictures that match a description. For the proxy defeating one, the server can send you a picture of the real .onion address where some letters are blanked out, and with noise added to it to prevent it from being solved by the proxy. You then have to enter the blanked out letters from the browser URL.

This can of course still be defeated if the proxy URL receives very few requests and just have a human in the middle to solve the CAPTCHAs. But it does make the attack non-automated.

This is a good question. Off the top of my head:

* Less crime because people who are addicted to drugs do not have to raise instant money for their next fix,

* Getting open, visible drug use off the streets and into a controlled supervised setting (this is not strictly part of safe supply though, but an orthogonal related service),

* Making drug use safer for the users by ensuring quality and consistent strength. Fentanyl, orphines and nitazenes are killing lots of people, and they exist on the market not because of demand from the users but because they are easier and cheaper to manufacture and smuggle than heroin.

* Making it easier to help the drug user by removing the burden and stress of obtaining the drugs. This is often an endless cycle of stress which leaves no room for getting help.

* Making it possible for drug users to be functional members of society. Not all people who are addicted to drugs need to stop, for some the safer choice is to accept that they are dependent and work around it. Taking opioids to prevent withdrawal is not incompatible with holding a job and contributing to society, committing crimes to get money for the next fix is. For many people who are addicted to opioids, abstinence programs are not the best option because the rate of falling back to using is very high, and once that happens the risk of fatal overdose is also very high due to decreased tolerance. I won't quote concrete numbers because I cannot remember them right now, but last I heard the rate of failure in abstinence programs was well above 70%.

* By supplying the drugs from sources that have no financial incentive in keeping the drug users on the drugs, you can ensure that users are exposed to all public offers to get help with their addiction or any underlying socioeconomic factors that are probably contributing to why they have become addicted in the first place.

Most criminologists will tell you that punishment is a very poor method of reducing the crime rate. I believe that to be true, and I think that a much better way is to address the underlying desperation and inequality that drives people towards crime. It doesn't mean that we should stop at the safe supply, because that would indeed be the cynical approach, we of course also have to help people overcome all the problems that are probably keeping them in their drug addiction, such as mental health issues and homelessness.