I’m hoping they can be creative and find a way to distribute revenues to member states in a way that works for everyone.

For employment taxes, one way could be to tax EU-inc employees as if self-employed in their personal tax domicile.

The amount of founders who choose to domicile their company in Estonia because the ticket rates and ease look attractive and who don't understand that this will still need to be administered in their local market as a CFC (controlled foreign corporation) would probably say differently.

> Just choose a jurisdiction where investors understand how the legals work (Delaware C-corp, UK Ltd is OK too) and there's a finite administrative burden and/or commoditized tooling in place to help you handle it.

That's exactly what EU-INC is trying to provide/solve afaict.

This helps both me and the next agent.

Using these tools has made me realise how much of the work we (or I) do is editing: simplifying the codebase to the clearest boundaries, focusing down the APIs of internal modules, actual testing (not just unit tests), managing emerging complexity with constant refactoring.

Currently, I think an LLM struggles with the subtlety and taste aspects of many of these tasks, but I’m not confident enough to say that this won’t change.

That said, I'm less and less bothered by an app that's Electron under the hood, but I think that's more to do with the quality bar for native apps slipping over the past few cycles (macOS) and forfeiting their advantage.

In Robert Bringhurst's The Elements of Typographic style – pretty much a bible amongst typographers – he states:

We should “[u]se spaced en dashes – rather than close-set em dashes or spaced hyphens – to set off phrases.” Bringhurst then adds this devastating indictment:

The em dash is the nineteenth-century standard, still prescribed in many editorial style books, but the em dash is too long for use with the best text faces. Like the oversized space between sentences, it belongs to the padded and corseted aesthetic of Victorian typography.

For example:

* Object storage: lots of horror stories out there regarding flakey performance so hard to justify sticking mission critical stuff there.

* Private networking: Again, too many anecdotes about loss of service. Lots of people just using the public IP6 interfaces to avoid their private networking entirely. And private networks are IP4 only.

* Kubernetes CSI: I've had issues with this where a PV gets in some locked state and I can't remove from console.

I'd love to see more competition here.

The current winner-takes-all approach to the outcome is wholly inappropriate. AI companies right now are riding atop the shoulders of giants. Data, mathematics and science that humanity has painstakingly assembled discovered, developed and shared over millennia. Now, we're saying the companies that tip the point of discovery over into a new era should be our new intellectual overlords?

Not cool.

It's clear that model creators and owners should receive some level of reward for their work, but to discount the intellectual labour of generations as worthless is clearly problematic. Especially given the implications for the workforce and society.

Ultimately we'll need to find a more equitable deal.

Until then, forgive me if I don't have much sympathy for a company that's had its latest model distilled.

"It just works"

1) Networking is mostly limited to 1Gbps. Even private networking. You can request a 10Gbps NIC, but it has to be housed in the correct data center and adds a $48 monthly fee.

2) Private networking is IPv4 only so dual-stack private networking isn't possible. Also each public IPv6 address is /64. Would be nice to get a /56 to setup dual-stack IPv6.

3) Can't specify a subnet to assign a server to when using hcloud API/Terraform. You have to specify the required IP on the subnet explicitly.

4) As I understand it, the private network traffic isn't truly secure between tenants, so needs to be encrypted between nodes anyway.

Still, I'm betting they'll fix these issues as their offering grows.

Previously, the friction of using a service with slightly rougher edges would have tipped the scales against it. Now, it seems we have a kind of patriotism emerging in our purchase decisions.

Ultimately, it should give us all more choice through strengthened competition.

I'm not so interested in the server based syncing/CRDTs side of things (great as that is) but more the layers that make up the web/desktop app.

What I'm particularly interested in is the roles and responsibilities across the various layers.

My understanding is that the app container is written in react and hosted via a browser or within an electron app. Then, most of the business logic is delegated to a WASM core.

However, my understanding of where the boundaries lie and how the various layers communicate are a bit fuzzy.

For example, which components are part of the Web DOM and which components are driven by Web GL? I'm guessing everything but the canvas (so menus, palettes, cursors) is part of the HTML DOM?

Then, business logic wise, how much work is done within the react app wrapper vs. the WASM core? Is the react layer used strictly for hosting the WASM core and rendering the UI, or does it take part in some of the business logic responsibilities also.

Would love to read or watch a deep dive into this if it exists somewhere.

Comments URL: https://news.ycombinator.com/item?id=41108435

Points: 12

# Comments: 3