Right now my laptop is connected to 4K Dell display and it works perfectly in clamshell mode. I never saw any random lines across the middle of display, GPU acceleration seems to work fine, WebGPU in my Chromium browser works fine, video decode accelerated so 4K video eats a tiny bit of CPU. I can't say anything regarding color depth, everything seems to work fine for me. My display reports "3840x2160, 60Hz 30bit" info. I'm using 2x scaling and fonts are rendered properly (not blurry) in all applications I'm using.

My WiFi is configured using NetworkManager, I don't have iwd installed and systemd-networkd is not enabled. It somewhat helps that I'm using Arch and I decide what to install and what to enable.

I agree that Android provides much more polished system and I'd be happy to switch to desktop Android if that ever will be a thing. I don't like Linux desktop. It's just the only desktop operating system that does not suck for me.

Hardware features are contained in the kernel. GUI has nothing to do with them.

GUI frameworks provide features for applications to draw their UI.

A selection of numerous windows managers and desktop environments allows you to choose the best GUI shell to work in.

It is somewhat of a bazaar, with different components sometimes not fitting perfectly into each other and there's a constant migration to a best new thing, whether it's systemd, pulseaudio, wayland or pipewire, but generally things work OK and it's not like Windows today offers a significantly different experience.

Windows is beyond salvation at this point.

Spending humongous amount of money to get machine that'll felt obsolete in 2 years? I don't know.

I had an idea to create blatantly insecure passkey browser extension. Maybe I should do that.

Like imagine that someone managed to extract key from the specific device and distributed that key in a software implementation to fake attestation. Now Google needs to revoke that particular key to disallow its usage. This is obvious requirement.

2. It allows me to configure everything using standard manifests. I need to provision the cluster itself initially, then everything could be done with gitops of various automation levels. I don't need to upload my pages via FTP. My CI will build OCI image, publish it to some registry, then I'll change image tag of my deployment and it'll be updated.

3. It allows to start simple, and extend seamlessly in the future. I can add new services. I can add new servers. I can add new replicas of existing services. I can add centralized logging, metrics, alerts. It'll get more complicated but I can manage the complexity and stop where I feel comfotable.

4. One big thing that's solved even with the simplest Kubernetes deployment is new version deployment with zero downtime. When I'll update image tag of my deployment, by default kubernetes will start new pod, will wait for it to answer to liveness checks, then redirect traffic to new pod, let old pod to gracefully stop and then remove it. With every alternative technology, configuring the same requires quite a bit of friction. Which naturally restricts you to deploy new versions only at blessed times. With Kubernetes, I started to trust it enough, I don't care about deployment time, I can deploy new version of heavily loaded service in the middle of the day and nobody notices.

5. There are various "add-ons" to Kubernetes which solve typical issues. For example Ingress Controller allows the developer to describe Ingress of the application. It's a set of declarative HTTP routes which will be visible outside and which will be reverse-proxied to the service inside. Simplest route is https://www.example.com/ -> http://exampleservice:8080, but there's a lot more to it, basically you can think about it as nginx config done differently. Another example is certificate manager, you install it, you configure it once to work with letsencrypt and you forget about TLS, it just works. Another example is various database controllers, for example cloudnativepg allows you to declaratively describe postgres. Controller will create pod for database, will initialize it, will create second pod, will configure it as replica, will perform continuous backup to S3, will monitor its availability and switch master to replica if necessary, will handle database upgrades. A lot of moving parts (which might be scary, tbh), all driven by a simple declarative configuration. Another example is monitoring solutions, which allow to install prometheus instance and configure it to capture all metrics from everything in cluster along with some useful charts in grafana, all with very little configuration.

6. There are various "packages" for Kubernetes which essentially package some useful software, usually in a helm charts. You can think about `apt-get` but for a more complicated set of services, mostly pre-configured and typically useful for web applications. The examples above are all installable with helm, but they add new kubernetes manifest types, which is why I called them "add-ons", but there are also simpler applications.

Just for the record, I don't suggest that to everyone. I spent quite a bit of time tinkering with Kubernetes. It definitely brings a lot of gotchas for a new user and it also requires quite a bit of self-restrictions for experienced users to not implement every devops good practice in the world. Sometimes maybe you don't even want to start with ingress, I saw cluster which used manually configured nginx reverse proxy instead and it worked for them. You can be very simple with Kubernetes.

Regarding hooks: I don't know. All applications that I've used, implemented migrations internally (it's usually Java with Flyway), so I don't need to think about it. One possible approach could be to use flux CD with Job definition. I think that Flux will re-create Job when it changes. So if you change image tag, it'll re-create Job and it'll trigger Pod execution. But I didn't try this approach, so not sure if that would work for you.

For very simple deployments, you don't need anything at all. Just write manifests and use `kubectl apply`. You can write `deploy.sh` but it'll be trivial.

If you want templating, there are many options. You can use `sed` for the most simple templating needs. You can use `cpp`, `m4`, `helm` or `kustomize`. I, personally, like `kustomize`, but `helm` probably not the worst template engine out there.

Kustomize is even somewhat included into basic kubernetes tooling, so if you want something "opinionated", it is there for you. It works.

Do you have any links about Ingress being deprecated?

Official docs here: https://kubernetes.io/docs/reference/kubernetes-api/service-...

There are no mentions about this API being deprecated.

Just for the record.

The only nuance is that recent chrome versions treat it as a separate permission, so user need to allow it once.

Yes, native messaging is the "proper" way to do that, but, again, nothing wrong with localhost http server. You have origin headers so you can allow access from your whitelisted website, if necessary.

Overall it looks awesome. I just bought Thinkpad T14s upgrading from the same model of older generation, I wish Framework would expand its sales coverage, probably would buy it without second thought if it was available in my country without overseas shipping and customs tax hurdles.