I use kubernetes extensively at work. I don't manage the kubernetes cluster anymore since now we have a team that runs centralized services and you can request a namespace with a quota. But back when my team had a dedicated Azure Kubernetes cluster it was not that bad as people says it is and the biggest hassle was the extremely short lived support for each version.

Then I started to realize most people who complain are rolling their own which is also not bad since there are products like k3s that are very simple to use.

It seems things start to fall apart when they try to stuff it with all kinds of crazy idiotic controllers and the favorite of the month CNI and CSI. I always shake my head when I see people creating sand castles by setting up stuff like Ceph from within the cluster.

If you want to play with it keep things simple and have all the persistent data outside of the cluster. Use good old NFS instead of the latest longceph horngluster version. Keep databases and the container registry out. Treat it like a compute pool not a virtual datacenter. Stop recursing chickens inside eggs.

I think 1450 EUR for a 16GB RK3588 is hard to justify. Is the Rockchip open to begin with?

I'd go for a framework using the Roma or CIX boards if I wanted to go for an "open hardware but not really" goal.

RK3288 was true open source. It boots with just u-boot and no blobs. DDR init was done by u-boot code and armv7 didn't require a TEE.

RK3588 is "almost" open. It boots with mainline u-boot and device tree from the Linux kernel, but needs two blobs: the DDR training blob and the trustzone blob (BL31). It can run without a TEE OS. I recently heard that the BL31 is now open source, but I didn't look into it. Mainline kernel has support for everything, including 3d (panthor driver) and video codecs acceleration (you find it in the v4l submenu). Mainline Mesa driver (panfrost) also works, but... not great - it stutters/freezes when I move the mouse.

I believe the Mali graphics also require a blob if you want 3D acceleration.

You're right, 3D needs /lib/firmware/arm/mali/arch10.8/mali_csffw.bin, distributed by linux-firmware package.

What about in kernel binary blobs? Would something like GNUs linux-libre work on it?

mali_csffw.bin - see my other answer.

Xorg works, it uses the generic modesetting driver which is accelerated by Mesa panfrost driver, but like I said, with stuttering and temporary freezes when I move the mouse. It happens in all apps: moving windows, vkgears, glxgears, mpv video playback, but "mpv -vo gpu -hwdec=vaapi" started from console plays fine, very smooth. I didn't try Xlibre or wayland.

You're paying for significant ground-up R&D and manufacturing costs that only marginally benefit from any economies of scale. (It's also an incredibly fucking robust machine!) This is not a MacBook Neo competitor. I think if it more as a product for the person who is bored of their quad core-swapped, nitrocaster-modded, corebooted ThinkPad X230, and wants a new, weirder toy laptop to hack around on.

other than maybe some RAM related blobs I believe the mnt stuff is completely open in both ways

framework stuff is generally neither open hardware nor open software, intel and AMD don't permit it

I have a couple of these RK3588 boards and frankly the story there is mostly pretty good, a bit better than other SBCs.

Recent Linux kernels are feasible. I'm using mostly stock Debian.

I use one as a Jellyfin/Plex/Immich/NAS server thing. Jellyfin is able to use the GPU for video decode. It works really well.

The other one is in mini-ITX form factor and I use it as a local Forgejo runner for CI jobs, and some other things.

I've managed to get a fork of Llama.cpp running that uses the NPU in these devices to (modestly) run LLMs, even. No real advantage, but neat.

I am satisfied enough that I've put an order in for the Next from these guys. Which would bring the number of RK3588 devices in the house to 3.

I thought it was an NXP i.MX? or did they make another revision

There are (were?) several SoC boards to choose from.

I use disposable digital debit cards for my subscriptions. These can be issued by fintech companies like Wise. If something like this happens to me I'll just delete the card.

In my opinion pre alder lake intel is the sweet spot for FreeBSD. Not sure about AMD but anything before 2020 should work just fine. Just avoid CPUs with heterogenous core configurations for now.

In most cases you can put your computer secure boot in setup mode and roll your own keys.

Until they making CA a requirement, then disable changing the CA settings and it defaults to Microsoft. Then you are fucked.

That would make extremely inconvenient if MS ever need to revoke a certificate.

Companies coming from Active Directory and Office.

I'm sorry I had to use a feature on my browser I rarely use which is summarize. I'm pretty sure your point is valid and concerning but the way that page was designed is just too painful to read.

I'm so tired of this particular kind of LLM (-assisted) slop. The engagement bait, the stupid little hacker-style animations, the drawn out text...

Please, people, use your own words, and don't overdo every little thing. It's tiring. When everybody does this, nobody stands out.

The article contains live network captures run with `ss -tnup` during an actual Proton Meet call, DNS resolution and ASN lookups performed in real time, a line-by-line read of LiveKit's DPA identifying them as an independent Controller for call detail records, and CSP headers pulled directly from meet.proton.me.

If you found a factual error, name it. "I don't like the animations" is not a methodology critique.

Fair point on the methodology. The ss output and CSP headers are concrete. The LiveKit Controller distinction is the part worth debating-independent Controller vs Processor changes the privacy story significantly. Has Proton responded to that specific claim?

Yeah this same site did an article on some minor ubuntu bootloader drama some weeks ago and when I recognized the design I just stopped reading. If you have something to say don’t go out of your way to make it hard to parse.

>Oh does llama.cpp use MLX or whatever?

No. It runs on MacOS but uses Metal instead of MLX.

ANE-powered inference (at least for prefill, which is a key bottleneck on pre-M5 platforms) is also in the works, per https://github.com/ggml-org/llama.cpp/issues/10453#issuecomm...

Is that better or worse?

Depends.

MLX is faster because it has better integration with Apple hardware. On the other hand GGUF is a far more popular format so there will be more programs and model variety.

So its kinda like having a very specific diet that you swear is better for you but you can only order food from a few restaurants.

But you can always fall back to GGUF while waiting for the world to build a few more MLX restaurants. Or something like that; the analogy is a bit stretched.

Yeah I'm terrible with analogies.

I guess the point is that without the hype subsiding it enshitification will ensue.

Fun fact: Bonnel Atoms (D510 etc) were not affected by the meltdown vulnerability that plagued every Pentium processor since the 1995 Pentiums. These Atoms use purely in-order execution engines which kinda makes them supercharged 486s.

Pentium were the first superscalar x86 from intel, but were still in-order. Pentium-Pro (a completely different microarchitecture) was the first OoO intel x86 microarchitecture.

I stand corrected thanks.