Microkernels have been the future since at least the 1970s.
Xen, which powers Qubes is a microkernel for instance
This is the lemmy community of Monero (XMR), a secure, private, untraceable currency that is open-source and freely available to all.
Wallets
Android (Cake Wallet) / (Monero.com)
iOS (Cake Wallet) / (Monero.com)
Instance tags for discoverability:
Monero, XMR, crypto, cryptocurrency
Microkernels have been the future since at least the 1970s.
Xen, which powers Qubes is a microkernel for instance
What kind of threat model makes Linux not secure? (Genuinely curious, I daily drive Fedora and use Flatpaks for sandboxing)
Any threat model tbh, your linux computer can be remotely used for botnet and you may not even find out (unlikely as linux is not targeted as much as windows simply because too few desktop linux users) Linux desktop's only advantage currently is obscurity but that may not remain the case with rise of popularity in Steam Deck
I'm no expert, but I don't know if I agree with the premise that Linux desktop is secure via obscurity. Linux is probably the largest effort to create a secure OS, and the Linux desktop benefits greatly from that effort.
OpenBSD has an excellent security track record and is regularly updated, I'm not sure if I believe that its security is "outdated."
botnet
Google has been showing me 'suspicious activity from your computer' Captcha lately Is there a way I can scan my device for my peace of mind(not talking about clamAV) a manual inspection, what are the signs that something is wrong?
No good solution but easiest thing to do is System monitor resource usage (CPU, GPU, Memory) check it when programs are closed and system is idle
Captcha is probably unrelated to botnet, it can be from your browser (most privacy focused browsers like LibreWolf, Brave, Hardened Firefox get this captcha problem) or your VPN/proxy if you use one
Linux is the number one priority target for APTs and other threat actors. Linux runs most of the corporate world, therefor its the biggest target.
I liked the concept behind Kodachi, but there's a very, very small community supporting it. It's a good thumb-drive OS like Tails, but does a much better job than Tails. I haven't tried it in quite a while, but FreeBSD may be worth a shot. When testing open source versions of Unix, I found them ahead of OpenBSD on the modern GUI stuff, but it's anyone's guess where they are at now. Might be worth spinning up a Virtual Machine. BSD Unix has been around longer than Linux, so you can be confident there's well tested and vetted code base.
Don't use Kodachi, it is insecure mess and privacy invasion shit OS.
https://bitsex.net/english/2021/kodachi-linux-is-probably-not-secure/
More info on Atmosphere as I find it fascinating that an OS created for a gaming device got such tight security:
https://www.reddit.com/r/emulation/comments/hygtnx/mesosphere_opensource_nintendo_switch_kernel_now/
"It is a completely unique microkernel with a cooperative (non-preemptive) scheduler. The kernel is secure -- so far as I can tell (as a reverse engineer and hacker), it has zero security bugs. They throw out years of backwards compatibility (they're not POSIX/UNIX), and they really, really benefit from it from a security and modularity PoV. Horizon's the only meaningful RTOS with a microkernel that I'm aware of (other than Fuschia). Everything's in userland -- filesystems, gpu (and other device drivers). The OS is capability-based and conceptually all about lots of different processes/drivers ("system modules") that host microservices. The fact that Nintendo designed such a rock-solid, modular, custom operating system for their consoles fascinates me."
"IPC is the hottest hot-path in a microkernel, correspondingly Nintendo marked every function involved in IPC as attribute((always_inline)), this was kind of a huge pain to reverse engineer as a result. In addition, Nintendo implemented "SvcReplyAndReceive" as a single system call that allows a microservice server process to reply to and receive a new message in one invocation. That said, there's actually less overhead than you think. Past of why FUSE is slower than a kernel driver for FS is because FUSE has to talk to the kernel to do filesystem stuff, so when you read a file you have your process -> FUSE -> kernel -> hardware. In comparison, on Horizon the kernel is completely uninvolved in filesystem management (it doesn't even have the sdmmc hardware mapped). Thus processes will do process -> FS system module process -> hardware."
"In Horizon, everything is very distinctly not a file. There's no global filesystem paths the way that unix/linux have special /dev/whatever. Pipes don't exist in Horizon -- all IPC is done via the horizon ipc ("HIPC") protocol. UNIX/POSIX have stuff like fork() and child processes...but creating a process is an incredibly privileged operation in a capability-based operating system. Fork() is impossible to implement in Horizon, all threads are created via SvcCreateThread() instead. Child processes aren't a thing that exist."
GNU Hurd?
Their basic premise seems solid, but is it actively developed? it seems to go through long periods of inactivity
It's no longer a prioritiy in GNU. It's better if we forget GNU Hurd for the time being.