alkonaut

What does Canada have to do with what I wrote? I described one country and it wasn't Canada. But ok, Re: US wine exports to Canada (I have no idea about what this looks like, but a quick googling found several articles).

> "In 2025 the U.S. wine exports plummeted 33.5 percent compared to 2024, driven largely by a 76.8 percent drop to its largest market, Canada, according to new data just released by the U.S. Census Bureau. In total, American wine exports fell from $1.3 billion in 2024 to $850 million this past year, a $428 million loss." [1]

So the largest export market dropped by 3/4 which led the total exports to fall by 1/3. I don't know how that is anything but a "real consequence"?

[1] https://robbreport.com/food-drink/wine/us-wine-exports-fell-...

Yes, and usually in the form "You may not reverse engineer, decompile, or disassemble the SOFTWARE or any of its constituents, except and only to the extent that applicable law expressly permits". (This is the concrete example from this software). And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want.

The law that covers this (in the EU) is EU Directive 2009/24/EC, where Article 5 is the reverse-engineering-without-decompilation.

> The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

This is pretty difficult to parse, but luckily there is a ruling from the European Court of Justice on this: SAS Institute Inc. v World Programming Ltd (Case C-406/10), delivered on May 2, 2012.

SAS Institute claimed that World Programming Ltd (WPL) infringed its copyright by studying the behavior of the SAS software system and writing a competing program (the World Programming System) that emulated its exact functionality and used the same data file formats. WPL did not have access to SAS's source code and did not copy any of its literal text or internal structural design.

CJEU:

> "It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the license did not have access to the source code of the computer program to which that license relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program".

Which is a good find. But this is where I wonder if LLM-based reverse engineering is going to creep into either law (via lobbying) and/or EULA's, because this "observe every single state of the program for every single mutation" was simply not a viable mode of reverse engineering in the past. Or, it was at least always cheaper than just buying the software! Not so any more.

Or alternatively, that programs stop having so many observable states, making more things public. But for libraries as in this case, the whole product IS the public API. Without a rich public API, the library can't be sold. And with it, I can observe it and copy it - because it's internal workings are "too simple" not to be deduced from the public API. In short: a UI control is a ton of hard-to-write but easy to copy boilerplate code. And selling this has been an industry, but I wonder if it will be for very long.

> I responded to the claim that this was due to a boycott of US goods writ large, not a specific boycott about wine.

While boycotting iPhones might be difficult, taking the Cabernet one shelf over takes almost no effort or negative impact to the consumer. It's rarely more expensive to switch from a US wine e.g. French or Australian. It's sold in the same store.

For the specific example of Sweden, every single wine bottle in every store is sorted by country in the store. And it sits above a price sticker with the flag of the origin country on it.

That's wildly different from similar choices e.g. when you pick a can of Hellman's Mayonnaise, there's no US flag under it. But for wine in particular, the country of origin is almost always known to the buyer and involved in the process, even if Sweden stands out as an extreme due to the flag being under the bottle.

That's why I believe the boycott which isn't a boycott on US wine but on US products in general, is _most notable_ for wine or in some other case not notable at all because it's a small effect and consumers don't always know what is American and what isn't (Hellman's example). But for wine, everyone knows.

The difference between the general slump in wine sales (10%) and the decline in US sales (20%) could have more factors, such as price. But it's easy to assume - and polls suggest - that consumers really do avoid the US wine.

I don't think you'll have several thousand years of people enjoying wine and then suddenly one generation decides that "wait this doesn't even taste good?".

I really like wine, and a $8.50 bottle of good quality French bubbles isn't a luxury good or a status symbol it's just life.

But it's definitely acquired - and the fewer that acquire that taste, the less you'll sell. And people I guess often establish that taste in the 20-30 year age, and if people go out less and drink less, perhaps they'll not grow up to be wine-drinking 50 year olds?

> - Tariffs so less international demand for US wine > - Canadian boycots of US products due to tariff wars

The tariff wars and "boycott US wine" goes way beyond Canada. I (in Europe) completely stopped buying US wine during this admin. Polls support this.

The fact that US wine declines more than other wine isn't a theory it's a fact. The reason could have several theories. One is that people are simply boycotting. This is supported by polls etc. But another would be if prices drift apart and a strong dollar makes US wine less attractive relative to (say) French and Italian wines.

As usual the reason overall wine sales would be down e.g. 10% and US wine sales down 20% in a country will be a combination of multiple factors. My pet theory though is that at least for some countries, the boycott factor is the big one.

It's a shrinking market, but it surely doesn't help that people are simply boycotting US goods.

For example: Swedish sales for US wine was down around 20% in 2025. The overall decline was about 10%. In a shrinking market, you don't want to also have a shrinking market share.

I'm sure the figures are similar in other countries - and this year it's going to be very different in Canada as well. I imagine Canada was always a big importer of US wine seeing as it's close by and they don't have much domestic production.

Seeing many people comment that they drink less; I'm happy to report I still try to drink as often as I can (Which is still not as often as I want).

I (a programmer) just did a pretty large task with Opus 5.5 that was a perfect fit for a big token eating task. It ate into my weekly budget in a way that made me have to use anthropics one-off "reset" they offer now.

Long story: we have a big legacy desktop app. It uses a big legacy UI component (a grid control), which we had a license for in an old version. Fast forward 20 years, and to be able to move to a new runtime for our app, we need to update the component. Someone had bought the company making the component and now charges north of $1k per developer per year. So instead of doing this, we had just lived with the very old version.

We had long thought of writing our own control to replace the proprietary, but it was always going to be a man-year of work we thought. But I thought I'd give it a try with AI now. I told Opus: look at our uses of that control (tens of thousands of lines of code, it has over 100 instances across our User Interface). Write a new control that would compile with the exact same app syntax. First just make a dummy implementation that throws on every call. Then start implementing. Make a test suite that can run both with our new control and the proprietary control, and test everything, every function that can be called in its public interface and every state that can be inspected from the public API. Verify that everything behaves exactly the same, and lock it in with thousands of tests. Finally, check that the control _looks_ exactly the same as the proprietary one. Render to bitmaps, figure out the rendering logic from observation, such as arithmetic for padding, font sizes, and so on. Compare pixels until it's exactly the same.

Basically: it was a mammoth coding task, but it was so extremely well specified that an LLM could easily just do it. It's a clean-room implementation of something with no tests, but we had a test double that could provide 100% of the expected behavior. The description was extremely short. "Make a new thing that works like the old thing, and prove that it does". Opus 5.5 finished this in a number of hours. 500 source files, several thousand unit tests, and html reports with image diffs from the reimplementation and the original control. It did not use any disassembly or such "cheating". Only observation of the public API and the behavior. Do we need to deeply understand the implementation? Does the architecture matter? Not much in this case I'd argue. It was a black box to begin with and it remains a black box. If we notice a bug, we can always point it to the original proprietary control and say "there's a behavioral difference when doing X" and it will fix it, and lock it down with tests.

As a programmer it's kind of chilling. I had recreated for a few tens of dollars something that would cost $1000 per year to buy. Obviously it's not a complete implementation only the parts of the API we use. It likely still has some bugs. We don't get support, we get to maintain it ourselves. But the rate of reverse engineering this thing "black box" was frightening. It hasn't created anything novel. But we must realize that as programmers some times we have man-years of work that just isn't novel. And in the past, we didn't do this work at all.

I wonder if those who write and sell libraries like this will start having explicit no-reverse-engineering EULAs soon? Perhaps even explicitly mentioning AI/LLM use in analysis and reimplementation?_ Obviously the library we reimplemented was from 2005 so didn't mention AI... (It doesn't mention reverse-engineering either, luckily).

I wonder why they chose to use the tiny watch-size amoled board for this. Wouldn't a multi effect UX be better with one of the 4-7" touchscreen boards?

Also: Am i reading it right that you can get an ESP32 with a 7" touch screen for like $30?

of people with a laptop? Maybe half (Just a guess). But most of those are not using it for anything complex. But it doesn't matter, it's that 1% of excel users and their sheet that is the problem. You'll find where it is WHEN you try to phase out excel. Not before. The report will be "I can no longer run our weekly report thing because google sheets/liberoffice doesn't run the macro and now we can't update the schedule for the drivers and they're angry, please advise". The solution, invariably, is not to throw a contractor at the problem and write a web service for it. It's to just let that sheet keep working another decade and pay the excel license. It's much much cheaper. But it also means that the long tail of Excel stays.

Whatever is in those Excel sheets. In any nontrivial org, you'll find it if you try. We found users designing roof trusses in Excel with heavy vbscript macros...

But then we'd still be left with a C or C++ codebase.

Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI. That and full self driving - including the nuances of gesturing to a human about who's going to reverse in a single lane in a snowstorm.

But if 50% of code can be converted automatically to safe idiomatic Rust? Great. Doesn't sound too far fetched. But yes, there's certainly a long tail here.

The 10% excel sheets are exactly the problem. You can replace 90% or even 99% with either some online simpler office suite or none at all. But it will turn out there are business critical things running in 2003 format excel sheets with macros and if anything stops working then the organization stops working. The person who made these sheets and macros has retired 20 years ago and "updating it" would require making a dozen little applications to replace them which would be a huge task.

The simple/cheap answer I think is to just keep the power users and legacy systems on the tools they need/want. Because that's where the pain point is that cause these projects to fail. If you aim for 100% you'll end up with 0% eventually. If you aim for 90%, you can do it.

But Microsoft know this, and would make sure that a 90% migration saves you much less than a 100% migration. Which is why this is so rare still.

(I think the number is probably 99% not 90%, but the point is the same)

The long tail of ms Excel does not get replaced easily. For 90% of customers and 90% of workflows you see either no use of a program, or use cases that can be replaced with anything.

But eventually you'll find the power users who do business critical stuff in excel sheets that you notice can't be done in any other way, and if you stop doing it then people aren't paid in time or whatever.

This doesn't mean it's a good idea to not try this. But Microsoft also aren't dumb. They know exactly how common this is, and what fraction this is. And they will make sure that it costs little more to keep the Microsoft products across the org, than it costs to keep them for specific users and deal with the mess that happens.

This could be said for other things than Excel, but Excel has been one of those moats for decades now.

Is the aircraft built in LA but then test flown in Plattsburgh, NY? It seems like a long way to transport a prototype on the ground for a test?

It's a prototype. But yes, the seats are going to take the trend of "lighter seats" even further. For example, for such short flights it's probably worth not having tables in the seats.

BUT, where current aircraft are usually constrained on size, cramming as many passengers as possible into the cabin is the goal.

Here, space will be less of an issue than weight. So cabins can offer more room between seats minimalist seats.

I don't think it's the daily work commute being solved. More weekly meeting in Cleveland for someone who works in Chicago. Which today is a 5h one way drive and a hotel stay.

Issuing this digital ID for all the _other things_ I do with it already has to deal with all this!

Of course the debate would revolve around ”is it fine to have a national government issued ID be the ultimate proof of your identity/humanity?”

It’s problematic - yet I think it’s better than the alternative.

But unless you want to also do all your "human" development inside a VM, how do you cooperate effectively with the agent(s)? I want to run my IDE directly on the hardware, not inside a VM.

So while the agents develop in a sandbox/VM, I still need to touch the same files, and see them in my IDE which is not in a VM. I suppose I could just _mount_ the same files (Documentation, git working copies etc) I work on as directories inside the VM, and then let it roam free in there, while I observe the same files on the host machine? Is this a common pattern?

That is a massive headache. But also for desktop dev (the boat I'm in) there are things like usb device tunneling/drivers, 3D performance and so on.

Windows Sandbox would work pretty well otherwise (And also solves the licensing issue).

The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily. I can't set up a "second machine" or an "isolated environment" to run claude cli in. At least not in the sense of a VM, physical hardware, container etc. Not sure what the best practices are for whitelisting tools/directories and so on, but so far the only useful mode I have found is just "allow everything and go to lunch". And it doesn't feel like I'm holding it right, but here we are.

Every place on earth has some legal definition of who is human. The system I’m thinking of isn’t a technical/captcha one, it’s a human curated list of humans. Just an electronic ID. Those already exist but the challenge is making them (acceptably) privacy-preserving.

I want to take my existing national digital ID and use it online basically. BUT I don’t want the websites to know it’s me. Just that I’m human (or perhaps over a certain age). And I don’t want the ID issuer to know what site/service asked whether I’m a human or I’m 18 etc.

Proof-of-humanity can’t come soon enough.

We’re talking about privacy-preserving proof of age, but as we see here the real utility of such a system will be proof of humanity.

As the CEO of HTMX I find it disturbing that we have more CEO’s than users.

I don't mind apps, even apps that are basically just browsers showing a web site. The biggest reason is that apps, at least on iOS, just behaves better. It might be that the auth persists longer or that there are notifications or whatever.

It's not without issues obviously. Most of the time the first thing I have to do is update the damn app just to order a burger or park my car or whatever it is I'm using it for. And it's dumb that we need to have a 150 meg download (per update...) for what's basically a bookmark.

But still, the better integration with my phone's native stuff like keychain etc usually means I'm more satisfied after using an app to do something, than using the _exact same web page_ in my mobile browser.

Was snorkeling this winter in some tropical waters in asia and noticed how dead everything looked, compared to the same place 20 years ago. When I asked about it, the locals said "It's all from the same El Niño in 2015. It all died the same year".

So there are vast areas of Coral that used to be fantastic in 2014 and which is dead since the 2015-16 season. It takes many decades to grow back if it ever does. And now we're about to have another.

I'm assuming that the config scenario can be re-routed so the app thinks its opening that file but instead gets routed to different ones transparently.

If the file picker enumerates N different directories immediately (which aren't the active one) that causes a problem yes. I guess allowing enumeration access _anywhere_ (but not file read access) isn't a necessarily a problem.

Can't it request and be granted that permission, transparently to the app?

E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?

At least that's how I'd thought it would work. Perhaps this isn't viable?

> a human should decide if my contribution is worth it. Otherwise, that project is not worthy of my modest contribution.

But that's the problem at hand: if there are 999 low-effort automated AI contributions for every human contribution, either all 1000 contributions must be pre-screened to gauge "human effort" and the human efforts get human review, or all PR's get 1/1000 the human attention.