apt_install_coffee @ apt_install_coffee @lemmy.ml

Posts

0

Comments

132

Joined

3 yr. ago

As far as ARM SBCs go, I'd say B tier. Not as good as a RaspberryPi or RockPi but armbian installed great. Had a pain debugging the rockchip video decoder in a container, and still have issues with USB hard drives.

If you're coming from x86_64, be prepared for some unique challenges.

• *arr media services
• tailscale
• mullvad
• Jellyfin
• qbittorrent
• pihole
• unbound
• Minecraft server
• Portainer-CE

On an OrangePi with a powered USB hub using a bunch of SSDs.

All except the Minecraft server running on Podman.

The GPU driver should already be in mesa, no?

If you're packaging enough changes that somebody would say it's a different experience, calling it the "X configuration" vs "X distribution" based on how it's packaged is just splitting hairs.

Nah, people always want to put their own spin on things and I welcome the diversity.

Arch can bring in all the necessary packages yourself, but Garuda exists and people enjoy using it. Horses for courses.

I use Xanmod for gaming (fsync & related tweaks), but need other flags for development on the same machine.

My issues with BTRFS were mainly in their userspace tooling; ZFS volume management is just glorious, it felt like a significant downgrade to use BTRFS.

Not really heavy lifting, I'm just running the Xanmod kernel, and need to turn on some features I need for eBPF development. I'm also keeping up to date with kernel releases, so every 6 weeks or so I need to rebuild.

The ARC runs in RAM, but is generally best when it's given:

1. A consistent amount of memory.
2. An easily predictable workload.
3. Long periods of time between restarts.

Conditions great for a server but not so much for a workstation. I don't intend for my cache misses to go to spinning rust, so I have 2 2TB NVME drives. SSDs are cheap as chips currently.

The L2ARC is a victim cache of the ARC, and while it is persistent it's still much more effective for me to just use a NVME drive for my pool.

My issue is not with the ARC, it's a few things:

• kernel integration is iffy; I don't want to attach a module to my system every time I compile the kernel and prey that the difference in pace between the release schedules of openZFS and Linux hasn't caused issues, and because of the licencing issues my options of having a distro with zfs built in are very limited.
• it's performance isn't excellent from a NVME standpoint. It's not terrible, but it could be better.
• it has a massive code base, making introducing things like performance improvements and new features quite a challenge (Though the openZFS team are doing a bang-up job despite this).

Ultimately if I was still holding on to 40+TB of important data, I'd be using ZFS and be happy about it. I want snapshots on my workstation, without all the strange issues I've had with btrfs. I'm sure bcachefs will have its own issues but it's better to have options.

It's a technology that lets you run code through the kernel's JIT compiler. It's an extremely flexible way to run code in kernel space; the typical example is using it to build XDP programs for networking, which can deeply analyse network packets without having to incur the performance penalty for changing context to userspace.

• bcachefs; I currently use zfs and am not a huge fan of btrfs. Having another filesystem mainlined will be fun.
• eBPF, particularly if somebody picks up after the presumably abandoned bpfilter.
• Improved/matured support for rust written drivers. I'm not so fussed about in-tree work, but future third party drivers being written in a safer language would be a nice benefit.
• long term: the newly introduced accelerator section of the kernel might make SoCs with NPUs and the like have better software support.
• very hyped for plasma 6, and Cosmic both. I've got a lot of confidence in KDE devs, and Cosmic previews look very nice.
• NixOS has been a really cool distro for a while, but it also looks to have a solid build system from which interesting derivatives will show up.

One of our engineering teams who normally builds our products in-house was made to bid against contractors who promised the moon.

Them and multiple other teams then had to spend a total of 18 months getting the contractor's shoddy work up to scratch. When they were done, the senior engineers from three teams left.

One of our engineering teams who normally builds our products in-house was made to bid against contractors who promised the moon.

Them and multiple other teams then had to spend a total of 18 months getting the contractor's shoddy work up to scratch. When they were done, the lead engineers from three teams left, as well as their manager.

I'm surprised, and really pleased; I was under the impression that Nix required Systemd, and was thus a Linux exclusive. Good to see

NixOS needs what is IMO the killer feature of Arch: the wiki.

Comprehensive documentation on not only the OS but the additional packages that we use is what drew me to Arch, and the thing that makes me swear in frustration whenever I have to use Ubuntu/Debian.

NixOS is an excellent OS that has the promise of being every bit as hackable as Arch, but far more stable. Problem is, configuration is very different and needs extensive documentation to reduce that friction point.

It's not, perhaps they meant memory-safe?

The DE might be more memory efficient given the hindsight and freedom a fresh slate brings, but not strictly due to rust.