The easy part of a smartphone to create for EU is the part that is done in the US.

The difficult part is the hardware. That is also why the iPhone is produced in Asia. Replacing TSMC is much more difficult than the software.

> iPhone is produced in Asia. Replacing TSMC

iPhone chips are largely produced in Arizona, and TSMC's 2nm fabs are scheduled to come online by 2028. 30% of TSMC's global production is schedule to be produced in America.

USA has been strategically re-homing TSMC to the USA mainland for a long time now.

Contrast with the EU which has done nothing to become self-reliant, and really just has no ideas. It is unfortunate.

Which iPhone chips? The A19 in the latest iPhones use TSMC N3P which AFAIK Arizona is not equipped to produce.

It appears that TSMC are not deploying the latest nodes to US for multiple years after they've entered volume production in Taiwan.

> Key Milestones:

> First Fab: High-volume production on N4 process technology started in Q4 2024.

> Second Fab: Construction was completed on the fab structure in 2025. Volume production on N3 process technology targeted for 2028.

> Third Fab: In April 2025, TSMC broke ground on the site of the third fab, slated for N2 and A16 process technologies. Targeting volume production by the end of the decade.

> TSMC Arizona will play a crucial role in increasing U.S. production of advanced semiconductor technology and elevate the state of Arizona as an American center of innovation.

https://www.tsmc.com/static/abouttsmcaz/index.htm

> In July 2025, Wei indicated that the company would speed up its production timelines on multiple manufacturing facilities following an additional $100 billion investment in Arizona. He stated that the completion of a "gigafab" cluster totaling six facilities would account for 30 percent of TSMC's 2-nanometer and more advanced capacity semiconductor production within the state.

https://www.azcentral.com/story/money/business/tech/2025/07/...

Creating good smartphone software is not easy. Only Apple has achieved it. Google is close. The rest are so far behind in the race they think they are leading.

Because there was arguably no need for a third option. The current duopoly only exists because it was seen as risk-free, and propping up an alternative was seen as uneconomical.

> Creating good smartphone software is not easy.

Yes, but it's not rocket science either (and even if it were, the EU has both rocket scientists and a space port).

Maybe it's been too long for people to even imagine it, but European companies were fully capable of developing a smartphone OS and running an app certification platform (there were no app stores yet, as the industry was very fragmented) less than two decades ago.

I would argue MS did with windows phone, and Palm and Nokia did too. BlackBerry as well, but less flexibly.

They weren’t commercially successful because of network effects, which I think matter less when your back is against the wall to migrate away from the duopoly.

Android is open source (decreasingly, but still). A reasonable starting point would be forking it and adding replacements for the proprietary Google Play services, app store etc.

Gobally Android also has a much larger market share than Apple. (Yes the US is the opposite, it is an outlier.)

It can be done, but a few things are needed: money. A lot of money. And competent project managers / architects / visionaries.

The money problem is the sticking point; even if you can find investors, if you don't have guarantees of sales you're boned. Actually, this is the other problem: Android is not profitable per se, you don't get an "android license fee" on your bill if you buy a new phone. It's the tie-in with Google's services (default search engine with ads, app store, etc) that make it work. And even without those, Google is a company that originally made money off of ads on webpages, they could do whatever they want outside of that because their primary source of income was so reliable.

> Only Apple has achieved it. Google is close.

Debatable

Android is a solid basis for a homegrown solution. We just never had the need to build one just yet. What Google and Apple built was convenient. But it's not as irreplaceable as some might think.

> Android is a solid basis for a homegrown solution.

Except all proprietary drivers tying you to an ancient Linux kernel and preventing upgrades of the OS.

That is not a problem of Android but of the hardware and funnily enough much of that is not produced in the US. I think we could cobble together a working phone in a short time and iterate upon that if it is necessary. Hardware has advanced sufficiently that we don't need the latest greatest to have an okay experience.

> I think we could cobble together a working phone in a short time and iterate upon that if it is necessary.

You drastically underestimate how complicated it will be. Here is one attempt: https://puri.sm/posts/breaking-ground/

I am 6alking about creating the hardware of the need should arise. Of course it will not be comparable.

Are these proprietary drivers owned by American or Asian companies? There are many alternatives to Qualcomm nowadays

e-boks sends a text message to the phone, so I see it much faster than a paper mail.

e-boks is like gmail (and others) in that it keeps your old mail. So you can easily find old stuff, a great improvement on paper mail.

I don't even check my physical mailbox once a week.

Denmark is one of the very most digital countries. Physical mail is very much on the way out. We no longer has mailboxes to send mail, you have to go to a shop to send letters, which now cost at last $6 per letter due to the low amount of mail sent.

It is only a matter of less than 10 years before letters will be fully gone.

Didn't Danish postal service just ended operations? https://www.nytimes.com/2025/12/30/world/europe/denmark-lett...

A Danish postal company, they wont stop receiving mail lol.

Thats all besides the point. Which was that e-boks is not making vaccine programs possible or successful.

I think it certainly helps, although of course anything is possible without anything.

6€ for a letter that's ridiculous.. wow

Low delivery costs need high volume (economies of scale).

As number of deliveries per address drops, the delivery costs trend towards the same price as small package delivery.

Just say Norway to YAML.

This is a reference to YAML parsing the two letter ISO country code for Norway:

    country: no

As equivalent to a boolean falsy value:

    country: false

It is a relatively common source of problems. One solution is to escape the value:

    country: “no”

More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/

I think it would be better to require quotation marks around all string values, in order to avoid this kind of problems. (It is not the only problem with YAML, but it is my opinion of how any format with multiple types should require explicitly mentioning if it is a string type, but YAML (and some other formats) doesn't.) (If keys are required to strings, then it can be reasonable to allow keys to be unquoted if the set of characters that unquoted keys can contain is restricted (and disallowing unquoted empty strings as keys).)

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

Current PyYAML:

  >>> import yaml
  >>> yaml.safe_load("country: NO")
  {'country': False}

Other people did not stop having this problem.

It might be that there’s some setting that fixes this or some better library that everyone should be switching to, but YAML has nothing that I want and has been a repeated source of footguns, so I haven’t found it worth looking into. (I am vaguely aware that different tools do configure YAML parsing with different defaults, which is actually worse. It’s another layer of complexity on an already unnecessarily complex base language.)

The ancient rule of ”use software that is updated with bugfixes” certainly applies here.

A new spec version doesn’t mean we stop having the problem.

E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset.

[1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...

The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.

Note that you reference 1.1, I think that version still had the norway behavior.

1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. 1.2 strengthened it to remove unquoted no from list of tokens which could be interpreted as Boolean false.

> 1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false.

Do you have a source? Afaik v1.1 didn’t introduce such a change, v1.0 specified the same behavior for quoted strings, i.e. in v1.0 a quoted “no” would remain a string “no” as well.

Because there's a metric ton of software out there that was built once upon a time and then that bit was never updated. I've seen this issue out in the wild across more industries than I can count.

I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.

I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people running into issues like these are not in a position where they could solve the problem even if they wanted to.

That’s about 99% of the argument I am making. The problem is legacy software and bad certification workflows, not the software being used.

If I’m working with Java it’s indeed conceivable that I could update with some effort.

If I’m working with Node it’s conceivable that I could update with some effort.

If I working with YAML is it not conceivable that I could update with some effort?

PHP is stupid because version 3 did not support object oriented programming.

CSS is bad because version 2 did not support grid layouts or flexbox.

Why should I critique on these based on something that they have fixed a long time ago instead of working on updating to the version which contain the fix I am complaining about?

There is a gradient limit where the onus shifts squarely to one side once the spec has changed and a number of libraries have begun supporting the new spec.

Because once a technology develops a reputation for having a problem it's practically impossible to rehabilitate it.

Now add brackets and end-tags, I'll reconsider. ;)

Brackets works fine:

    Roles: [editor, product_manager]

End tags, that I’m not sure what that is. But three dashes is part of the spec to delineate sections:

    something:
        setting: true
    ---
    another:
        thing: false

Have you ever heard of the "sendmail worm", aka Morris Worm ?

https://en.wikipedia.org/wiki/Morris_worm

You can definitely have failure correlation without having centralized services.

plus report servers and others that run on obsolete versions of Windows/unix/IBM OS plus obsolete software versions.

and you just look at this and thinks: one day, all of this is going to crash and it will never, ever boot again.

I think the main question is: do your app get unknown input (i.e. controlled by other people).

Browsers get a lot of unknown input, so they have to update often.

A Weather app is likely to only get input from one specific site (controlled by the app developers), so it should be relatively safe.

Poor for high speed connections () or very unreliable connections.

) compared to when TCP was invented.

When I started at university the ftp speed from the US during daytime was 500 bytes per second! You don't have many unacknowledged packages in such a connection.

Back then even a 1 megabits/sec connection was super high speed and very expensive.

> I crawled my way out of poverty, so you can too

Sounds for me like "I could do it on my own, so nobody should have to help you".

I really hate this mentality of not helping others. Everybody gets better when everybody gets help.

I absolutely agree, and if my words didn’t convey that sentiment, I apologize.

My Miele hums with so low frequency that it sounds like a truck is passing by.

1) Get rid of all the margins. I'm not here to look at postcards, I'm here to read text. old.reddit is good.

2) Font is too small and light. Make subject font much bigger. The 2nd line is not nearly as important as the title, so title should be much bigger. (your darkmode is better at this than light mode). Personally I prefer Verdana to AppleSystemFont as the latter is very light.

1+2) The posting page has too much vert space between posts and too small font. I'm here for the text.

3) I don't care about icons. They don't help me to decide "do I want to read this posting".

My layout design: https://imgur.com/a/uBPb2pC

Both 1+2 are partially fixed by hitting my browser's "zoom in" function 3 to 4 times. But still there's too much whitespace.

I don't know why so many sites default to tiny fonts and using fixed margins to restrict content to a tiny column down my screen. Fortunately, most browsers allow you to set a minimum font size, which fixes a lot of these sites.