Yes, Germany's Turkish community largely traces back to Gastarbeiter recruitment in the 1960s/70s.

But since 2010, Germany alone received 850,000 Muslim migrants, with 86% of refugees coming from war zones like Syria, Iraq and Afghanistan.

Between 2013 and 2019, nearly 70% of all refugees in Germany were Muslim. Across Europe, large Muslim communities in Sweden, the Netherlands, and elsewhere originate from Iraq, Syria, Afghanistan and ex-Yugoslavia, not from guest worker programs.

The Gastarbeiter framing erases the millions who came because their countries were destroyed by wars the West participated in.

To name a few conflicts incited by the West: The Nakba in 1948 displaced 750,000 Palestinians and created a refugee population that still hasn't been resolved.

The Soviet-Afghan War displaced 6M+ people.

The US invaded Iraq in 2003, directly creating the vacuum that spawned ISIS.

NATO bombed Libya into a failed state.

The US and Israel spent years destabilizing Syria long before the civil war made it the worst refugee crisis since WWII.

Europe's closest allies armed all sides of Yemen's proxy war.

=> Every single wave of Muslim refugees into Europe traces back to a conflict the West had its hands in. Blaming Muslims for being here while ignoring why they had to leave is not a serious position.

And now Iran, a country with 90+m population. And noone stops US/israel. What do you think will cause the next flow of refugees?

"The power of the Jews even today, especially in America, should not be underestimated. And therefore I have very deliberately and very consciously — and that was always my opinion — put all my strength, the best I could, to bring about a reconciliation between the Jewish people and the German people."

It was never about guilt, still is not. Germany has learned nothing from its past.

Initially I went with Cursor, but the terminal setup feels way faster, more natural.

The Lua config isn't just "dynamic" in the abstract sense. I built a tmuxinator-style workspace manager that spawns project-specific layouts - named tabs, splits, working directories, startup commands - from a fuzzy launcher. Session state auto-saves every 10 minutes with timestamped snapshots and crash recovery. Theme toggling between dark and light mode triggers a system-wide theme switch script. These are runtime behaviors, not static settings - try doing any of that in TOML.

The built-in multiplexer is the other major differentiator. Splits, directional navigation, pane zoom, pane selection with alphabet overlays, moving panes between tabs or windows, all without a tmux prefix key. It's not just "WezTerm has splits too, it's that the interaction model is fundamentally more fluid when there's no mode switching.

WezTerm isn't trying to be the fastest terminal. It's trying to be the most programmable one, and for people who want their terminal to work as a development environment rather than a PTY renderer, that tradeoff is worth it.

The real bottleneck isn’t writing (or even reviewing) code anymore. It’s:

1. extracting knowledge from domain experts

2. building a coherent mental model of the domain

3. making product decisions under ambiguity / tradeoffs

4. turning that into clear, testable requirements and steering the loop as reality pushes back

The workflow is shifting to:

Understand domain => Draft PRD/spec (LLM helps) => Prompt agent to implement => Evaluate against intent + constraints => Refine (requirements + tests + code) => Repeat

The “typing” part used to dominate the cost structure, so we optimized around it (architecture upfront, DRY everywhere, extreme caution). Now the expensive part is clarity of intent and orchestrating the iteration: deciding what to build next, what to cut, what to validate, what to trust, and where to add guardrails (tests, invariants, observability).

If your requirements are fuzzy, the agent will happily generate 5k lines of very confident nonsense. If your domain model + constraints are crisp, results can be shockingly good.

So the scarce skill isn’t “can you write good code?” It’s “can you interrogate reality well enough to produce a precise model—and then continuously steer the agent against that model?”

This back and forth between the two agents with me steering the conversation elevates Claude Code into next level.

After two years of reading increasing amounts of LLM generated text, I find myself appreciating something different: concise, slightly rough writing that is not optimized to perfection, but clearly written by another human being

What users actually experience is this: every other major platform is shipping increasingly capable intelligent assistants. These systems can interpret intent, execute multi-step actions, and meaningfully reduce friction. Meanwhile, Siri still struggles with fairly basic workflows.

At the end of the day, I do not particularly care about internal constraints, organizational structure, privacy positioning, or strategic rationale. What matters is whether the product works.

Today, I still cannot reliably:

- Dictate complex voice input without constant correction

- Use voice to control my iPhone in a composable way such as “open this contact and send a message,” “replay the song I liked yesterday,” or “create a note in Obsidian with this content: …”

- Chain actions together in a way that reflects actual user intent

These are not futuristic requests. They are practical, everyday workflows that competitors are increasingly able to handle.

The gap is no longer about incremental feature parity. It is about whether Apple can deliver a genuinely intelligent interface layer, or whether Siri remains a deterministic command parser in an era where users expect contextual reasoning.

But you can already do that, in the terminal. Open your favourite terminal, use splits or tmux and spin up as many claude code or codex instances as you want. In parallel. I do it constantly. For all kinds of tasks, not only coding.