I2P ftw

Artix-openrc on custom kernel*

shitstemd, glibc, bloated kernel, sudo and proprietary blobs are not secure

yeah sysctl > regedit

'tis a meme… ;)

the real question is whether you use git variants. Which is another way of not making arch (and Gentoo) certainly not free as in free beer, especially if you live in Europe and need to deal with those outrageous energy prices. btw imo one should be suspicious of projects with long tagged release cadence since it’s usually a sign of technical debt and the need to look for alternatives.

The X server has to be the biggest program I’ve ever seen that doesn’t do anything for you.
Ken Thompson

I see Wayland’s flaws but X is such a bloated piece of hardly maintainable spaghetti code that it is sadly beyond saving or prospects for anything in terms of significant improvement

well in this particular case it’s initramfs’ fault for not designing for all-or-nothing atomicity (a operation either completes fully or not at all). which you can work around with a terminal multiplexer where a session can be re-attached later in such cases btw.

well in my experience it was opensuse tumbleweed or Manjaro that were significantly less stable, but perhaps my perception is a little bit skewed since I use artix and it’s certainly not too rarely just the bloated, tightly coupled nature of shitstemd that causes some of arch’s issues.

markets access and hitherto investments play a huge role actually. Israel is the Silicon Valley of the Middle East. In Ukraine the worst scum of the earth, agricultural produce and energy speculators (and real estate/companies hiring swathes of cheap labor in countries with large refugee populations, like Poland) as well as the military industry are benefitting from dragging this conflict out as long as possible whilst not allowing Ukraine to lose completely as to not lose access to hers market on beneficial terms.

Good that you’ve enjoyed it. But a fundamentally wrong thing about systemd is that it is actively harming the best thing about Linux – freedom. Some programs won’t work on a non-systemd distro because how tightly coupled and vendor non-agnostic anything that becomes dependent on might become at times. Of course it’s not as bad as glib(loat)c, but still if something can be done without any degradation of functionality via standard POSIX facilities, WHY either incur additional maintenance overhead for non-systemd implementations or punish people for their computing choices if there’s no one to maintain it?

really cozy

I’d like to interject

Apparently there are multiple crates but no official toolchain so unsure how that works in practice. You’re still limited to either waiting for hours or cross-compiling though since currently the best available RISC-V CPU is quad-core 2.5 GHz (which still looks hella promising, 2 years ago best we had was 1.5 GHz dual-core). This blog post by Drew DeVault goes into detail of how daily driving RISC-V looked like 2 years ago. I suppose these days it looks noticeably better, especially since Samsung and Apple have been eyeing RISC-V adoption due to ARM consortium doing some monopolistic shit with their licensing. But eventually, so far, not enough critical mass was attained and afaik the whole drama mellowed out a bit.

Regarding the energy efficiency, some experimental units managed to even be manifold better at this:

https://arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/

But on the other hand, studies involving some RISC-V models show quite the contrary when it comes to energy efficiency, although the thermal performance is much better:

https://link.springer.com/article/10.1007/s11227-024-05946-9

And below is a screenshot from a comparison by Gary Explains using more microcontroller models. So it really depends on the specific model, but it seems like the design of RISC-V has some solid potential to beat ARM in terms of energy and thermal efficiency.

I agree with you that every proprietary software must be presumed to be a trojan with a backdoor but still some critical, low level free software being decades old C codebases with oftentimes millions of LoC has proven to be a double-edged sword where on one hand most of it is super optimized (just compare launch times of lightdm or GDM to e.g. regreet) but on the other hand by pure probabilistics it’s more likely to contain some vulnerabilities accumulated over the years of imperfect code reviews.

Sure I believe it’s worth hoping and supporting initiatives that might one day bring us to something like RISC-V smartphone with high level of hardware security that’d run something like Alpine (a minimalist distro) but based on Redox OS. Maybe that’ll come true in a couple of years.

But right now GrapheneOS even despite proprietary hardware is the best option security-wise, unless you’re willing to tinker with hacking together some RISC-V SBC-based device (which might even have better battery life than most smartphones by up to 60%!), but the optimization of basically any software is going to suck so badly. And forget compiling any Rust code on the currently available RISC-V CPUs. want memory safety? pick something with a VM/GC instead.

I mean I get it might be because of being afraid of it being used to train LLMs. But I doubt that it would work, either because they won’t be used regardless or because of how federation works, i.e. literally it’d be more efficient if all of the known network instances’ operators somehow agreed to include/Lemmy, kbin and all of the micro logging platforms that can federate with Lemmy included a robots.txt that blocks known AI crawlers. Probably what would be more useful would be something that e.g. Akkoma and some other AP implementers offer, i.e. message autodeletion.

Also terrible if you want to retain any anonymity even if more people did it, because of stylometry.

AOSP is not proprietary. Also security is not achieved merely by the merit of being libre, see CVEs for sudo, glibc or Apache HTTP server or even the Linux kernel itself.

And when it comes to proprietary firmware updates, in case of x86 one such notable example is the microcode which is pretty important to keep updated for security.

Pinephone doesn’t have features like IOMMU isolation or even verified boot. Also as a matter of fact, permission control, unless you’re using flatpak/bwrap/firejail is actually better on Android than Linux. Plus long before the first usable part of Linux written in Rust was released, large parts of low level AOSP code were already rewritten in it.

https://madaidans-insecurities.github.io/linux-phones.html

https://grapheneos.social/@GrapheneOS/111957964224325239

https://grapheneos.org/faq#future-devices

https://grapheneos.social/@GrapheneOS/111738765361100063

https://grapheneos.social/@GrapheneOS/111676448278523353

https://grapheneos.social/@GrapheneOS/111676423446810227

https://social.linux.pizza/@piracyy/111712189066209594

https://grapheneos.social/@GrapheneOS/111975424959573607

also kudos to GrapheneOS social media people patiently explaining why both purism and pine64 are pretty mid at best when it comes to hardware security

Play undefined, win undefined