If not for political reasons then why limit first version to Google/GitHub rather than starting with generic OIDC (which should include those two anyway)?
We also took your feedback seriously and we are now implementing proper sign-in options like: Google GitHub (and more coming later)
My guess is some firmware or modules that just makes it that big and if you want room for snapshots you need to resize (or uninstall some variant if not needed). OS installer might have too small default size for a setup like this.
300MBish for a kernel is totally normal and you have 3 variants installed.
One way to go about the network security aspect:
Make a separate LAN(optionally: VLAN) for your internals of hosted services. Separate from the one you use to access internet and use with your main computer. At start this LAN will probably only have two machines (three if you bring the NAS into the picture separately from JF)
The server running Jellyfin. Not connected to your main network or internet.
A “bastion host” which has at least two network interfaces: One connected outwards and one inwards. This is not a router (no IP forwarding) and should be separate from your main router. This is the bridge. Here you can run (optional) VPN gateway, SSH server. And also an HTTP reverse proxy to expose Jellyfin to outside world. If you have things on the inside that need to reach out (like package updates) you can have an HTTP forward proxy for that.
When it’s just two machines you can connect them directly with LAN cable, when you have more you add a cheap network switch.
If you don’t have enough hardware to split machines up like this you can do similar things with VMs on one box but that’s a lot of extra complexity for beginners and you probably have enough of new things to familiarize yourself with as it is. Separating physically instead of virtually is a lot simpler to understand and also more secure.
I recommend firewalld for system firewall.
Here, you dropped this: /*
BTW ncdu -x /boot
Regarding the questions on Bluetooth security, his great presentation from last month covers a lot of your questions and more.
https://media.ccc.de/v/39c3-bluetooth-headphone-jacking-a-key-to-your-phone
Partitioning in the Debian installer being half-broken is something nobody talks about but IME still a thing.
What do is step through the installer to the point where you’re at, ctrl+F* to get a shell, set it up manually using fdisk/mdadm/lvm/cryptsetup/mkfs, and then back again to rescan and just assign the mounts and filesystems
I think I still have a half-written guide for just this in drafts somewhere actually. If you get stuck you can DM and maybe I dig something up
I think it depends a lot on what you are building.
For bigger projects and apps leveraging the mobile platform I’m 100% with you.
These kinds of frameworks can still be a good fit for a quick MVP demo, as a stepping stone for porting an existing web app, or if all you really want is a glorified web view (or are PWAs enough for the last one these days?)
Specifically RN is in terrible shape and IMO something to avoid though.
I do not ask you to read?
So that’s the mistake I made and the important part. Thanks for clarifying.
I still feel misled that it’s labelled as somehing it isn’t (“my reasoning”).
It is indeed with the help of llm. But reasoning is still solid and very curated.
It isn’t your reasoning and promoting it as such when asking us to read doesn’t feel honest at all.
Try answering the questions I asked for yourself and see if anything comes up!
Linux MATE desktop is pretty established and I think has a similar audience. Pretty confusing name choice… “want to install mate on linux? Try linuxmate (no relation)”
BTW are those actually your reasonings on the blog as you say? It reads very LLMy.
What makes you suspect the Nginx config instead of Lemmy? Do you have any failing requests (timeout or statuscode >= 400) in nginx log? What are the failing endpoints?
Both can be true.
I think such character assessment and calling names is unnecessary and off-topic here though. Better engage with substance than judging by vibes and doing ad-hominem.
Called it.
https://feddit.online/post/1372107/comment/6758185
No one listen grug til chicken come to roost
I guess they now have large enough number of users that it would be wise to shift some focus to supply-chain security from growth-hacking.
This is growing pains.
Ventoy is risky and a bit sus for such a security-critical software.
Glim is another solution for ISO-multiboot-USB that doesn’t require as much trust.
QuickEmu makes distrohopping in VMs easy.
The concept is attractive.
Since back before “atomic” and “immutable” were fashionable buzzwords, I’ve had a few Alpine installations running something like this. Their installer supports it. https://wiki.alpinelinux.org/wiki/Immutable_root_with_atomic_upgrades
I guess I’m also not alone in having been running OpenWrt with atomic upgrades for many years.
Since then been running a ublue fork (Aurora) for a while now. Forking it and running the builds on my own infra instead of relying on their GitHub works after hacking up the workflow files but it’s quite redudandant and inefficient with IMO one too many intermediate layers (kinoite -> akmods -> main -> aurora/silverblue/bazzite -> iso) downloading the same things multiple times repeatedly despite spending considerable overhead on caching. It’s clear that building outside of their GitHub org is not really actively supported.
Also tried openSUSE microOS (Aeon) a year or two back for a while. I want to like it but find zypper and transactional-update pretty uncomfortable and TBH sometimes still confusing to work with. Installing it on encrypted RAID was daunting IIRC. Rough edges. Enough out-of-date docs on the official site to make Debian wiki look like ArchWiki in comparison.
KDE Linux looks promising but it was still in a very early and undocumented stage last I looked. Great to see the progress.
More recently been looking more at Arkane Linux and been using it for some months now. It’s an immutable with Arch base. Much easier to customize and maintain than the ublue options and a lot less time spent triggering and waiting for builds - while having less stuff pulled from third-party servers in the process and an easy way to fork packages by cloning and submoduling an AUR repo. Lot more straightforward to make work without relying on GitHub. If you’re looking at rolling your own builds and are comfortable with Arch, I highly recommend checking it out. My fav so far.
https://codeberg.org/arkanelinux/arkdep
Given the self-contained nature of Debian - cloning the Debian sources is enough to do a complete offline build of everything - I think it’d be the most interesting base for a sustainable immutable distro unless you go to the opposite end with “distroless” (no comment). Looking forward to one.
Just a small number of base images (ubuntu:, alpine:, debian:) are routinely synced, and anything else is built in CI from Containerfiles. Those are backed up. So as long as backups are intact can recover from loss of the image store even without internet.
I also have a two-tier container image storage anyway which gives redundancfor the built images but thats more of a side-effect of workarounds… Anyway, the “source of truth” docker-registry which is pushed to is only exposed internally to the one who needs to do authenticated push, and to the second layer of pull-through caches which the internal servers actually pull from. So backups aside, images that are in active use already at least three copies (push-registry, pull-registry, and whoevers running it). The mirrored public images are a separate chain alltogether.
This has been running for a while so all handwired from component services. A dedicated Forgejo deployment looks like it could serve for a large part of above in one package today. Plus it conveniently syncs external git dependencies.