iotku

It's not really a demerit of FreeBSD given their lesser resources (and even less vender support) than Linux.

Most of the major ethernet chipsets for networking you'd expect to find in a server are well supported and the system is quite solid for many server use cases, but you're probably not going to be running bleeding edge consumer hardware day one on it.

On the desktop side of things Linux has far superior hardware support for current GPUs/Wifi chipsets. AMDGPU support is a few card generations behind (they have to spend effort porting from the Linux drivers) and things are still mostly in X11 land and you don't have Valve supporting gaming on BSD.

I'd still be interested in running FreeBSD on severs, it just takes a bit of different knowledge (the handbook is excellent) and with OpenZFS being a thing on Linux there's not as much exclusive to the BSDs on a surface level that Linux can't at least mostly provide.

There's also BlueBuild [1] which abstracts the process of building your own images away further into yaml configurations.

It takes away a tad bit of the direct control of the process, but covers the majority of things you would want to configure.

[1] https://blue-build.org/

Always a possibility with any distro, but the tooling around it is flexible and repeatable. If another group of people wanted to continue off where they left off it would be far more possible than a lot of the Ubuntu forks.

Just need the Atomic Fedora base to still be around and everything else is already pre-setup to run on GitHub infrastructure neither of which I anticipate going away soon. (Famous last words)

Calling it a superset of Fedora rather than just being its own bespoke distro can be a fine line, but really there's nothing stopping anyone from forking it and continuing on, a good few people run their own forks already to meet their own needs a bit more specifically.

Location: Seattle, WA

Remote: OK

Willing to relocate: Maybe

Technologies: Java, Golang, RESTful APIs, Astro, React, Typescript, AWS (EC2, S3, RDS, Lambda), Linux, Bash, Git, Containers

Email: jnthnab@gmail.com

I'm CS new grad looking for entry to mid level positions to gain industry experience.

Full-stack experience with building backend APIs in Java and Golang, and frontend interfaces with Astro and React. I'm a Linux enthusiast with a fair bit of systems administration knowledge as well.

Familiar with dealing with VoIP/messaging platforms such as Discord and Mumble.

Willing and able to adapt to new technologies!

Well actually...

https://wiki.xfce.org/releng/wayland_roadmap

From a marketing perspective perhaps, but it's still a supported LTS release of Ubuntu at heart and having two different version numbers would create ambiguity.

Things that should work on that particular Ubuntu LTS should work in Pop_OS! And at least you don't have to cross reference things.

Thankfully they keep important things more up to date with newer kernels/hardware support than the version numbers would suggest, but I think that it's a common point of confusion.

Debian repo proper worked fine, but I hit a problem with an application that wasn't playing nice (Zed would just stop accepting text input...) with X11/Gnome and Wayland is a bad time on the 535/550 Nvidia drivers.

Realistically I can live on X11 outside of my dual monitor setup and that one application, but things get very choppy with mixed refresh rates. Still not the biggest fan of Gnome, but if I'm using deskflow only Gnome or KDE support the input sharing portal on Wayland.

I consider myself pretty technically literate, and not the worst at programming (though certainly far from the very best). Even so I can spend plenty of time arguing with LLMs which will give me plausible looking but extremely broken answers to some of the programming problems.

In the programming domain I can at least run something and see it doesn't compile or work as I expect, but you can't verify that a written statement about someone/something is the correct interpretation without knowing the correct answer ahead of time. To muddy the waters further, things work just well enough on common knowledge that it's easy to believe it could be right about uncommon knowledge which you don't know how to verify. (Or else you wouldn't be asking it in the first place)

Just never managed to load the Nvidia module properly and fell back to the open drivers which don't work on my system. Didn't really feel like investigating further because the whole point of using Debian was going to be to setup and forget about it.

The Nvidia CUDA repos are still on Debian 12 as well which was a blocker for me. (Some claim it works fine anyways, but not in my experience.)

It's not like the Debian release schedule is a secret, I suspect there's just less corporate pressure to prioritize Debian.

The server browser is deliberately hidden, neglected, and full of spam on the modern versions of CS.

It's no longer the "default" way to play, and only a select amount of people get around to using it. Despite a much larger playerbase, there is far less activity than there was in the past.

There's still community servers out there (and niche communities like surf and bhop when still possible), but they're only still around for legacy reasons. If there wasn't any lineage there it would have been removed entirely in GO.

They're prioritizing correctness to the spec over speed and are still 'officially' in pre-alpha. It's still to be determined how well they can bridge the gap there.

For casual web browsing it's plenty fast enough already to do a lot of things, but they're a relatively small team fighting against decades of optimization.

I'm sure in larger codebases it can get unwieldy with tons of TODOs from a lot of different people, but for personal projects I've always found them a good compromise.

For me it's saying "yeah I know it could be better but I'm not going to break my train of thought over this and context switch. It's not so critical as to break functionality, this would just be nicer."

I really do appreciate TODO hilighting in editors for the odd occasion where I get back to something on a whim and feel like doing a quick fix then. (It's probably not realistically that common though and most will sit there indefinitely)

I do love the joke, but it is worth remembering as well that all of those S were to a certain extent afterthoughts to fix otherwise insecure protocols.

Given how old FTP and HTTP are it's fairly understandable that they weren't initially designed with security in mind, but I think it's valid to question why we're still designing insecure systems in 2025.

There's a pretty big gap between "make it work" and "make it good".

I've found with LLMs I can usually convince them to get me at least something that mostly works, but each step compounds with excessive amounts of extra code, extraneous comments ("This loop goes through each..."), and redundant functions.

In the short term it feels good to achieve something 'quickly', but there's a lot of debt associated with running a random number generator on your codebase.

It's greatly improved with Flathub's "Verified apps" [1] implementation, but you can make similar arguments about downstream packaging (e.g. from distros) not being clear about being independent of "offical" builds.

It's also very worth noting that `Fedora's Flatpaks` are sourced separate from the "Main" `Flathub` service which most people expect flatpaks are generally being sourced from which has many "official" flatpak releases of software directly from projects leading to extra confusion.

Flathub itself is fairly auditable (but not trivially so) and built through their CI, but I still agree that the unofficial packages are often of questionable security/quality.

That said, Many of the "native" (e.g. not Flatpak) distro packages are using far from supported/official builds with often missing/broken features and it's an unreasonable support burden when nearly all of issues related to distro packaging end up on the upstream issue trackers/support channels.

It's especially troublesome when the upstream has official builds available and it's unclear to the user reporting issues that they are not actually using official builds.

[1] https://docs.flathub.org/docs/for-users/verification/

Seems the only impossible problems that can't be solved by AI are things that make metrics falsely look good to investors

I'd probably flip the order, but to a certain extent I don't disagree.

In theory, if there's a truely competitive market (has such a thijg evwr actually existed for anything?) it shouldn't matter what a particular store charges as any other store could come in and charge a lower percentage and provide a 'better' service.

That can't happen without very open access to alternative app stores though.

In an idealized enviornment whoever could provide the best app store for the least amount of overhead and fees would be successful.

That said there's something about defaults and the many year headstart Apple has had with their own app store which makes me skeptical that even in a completely open environment that there could ever realistically be a mass alternative for everyone and expecting the average user to care about developer fees they don't understand is a hard sell.

I feel like (with no research) these interfaces were designed by programmers first and foremost and have a tight coupling to the actual underlying code.

A "well designed" interface with "good" UI/UX from a proper designer may have best practices, but additional layers of abstraction from the functionality which makes everything feel less direct.

Properly levereged GUI editors have the potential to use the extra refresh rate for smother animations/smooth scrolling, though that's pretty far away from Emacs territory.

Perhaps when increasing efforts in implementing spyware directly into your OS it would be good to dilute the namespace as to not find relevant information.

Either that or someone's giving a not so subtle hint.

I do think the program is probably far out of the consciousness of most people at this point (outside of older technical people), and the younger generation probably wouldn't know or care.

Fwiw (antidotal) I have 8 shucked WD drives in my my nas approaching 5/6 years worth of power-on hours. Moderate to medium read-mostly use case. No data integrity issues (according to zfs).

Certainly getting near the age where I wouldn't be shocked if I started seeing failures crop up, but I've gotten my savings plenty worth there.

Matrix is the modern IRC alternative, not discord.

But simultaneously Matrix is not a good enough Discord alternative.

Too much friction, too many issues, and still difficult for non-technical users.

The reason Discord won out is you can just send a link to somebody and they're already on-boarded.

Even more relevant is that you can "fork" Bazzite relatively simply and add any missing packages or configuration you need to your own custom image and let GitHub actions do most of the infra work for you

https://universal-blue.org/guide/fork-your-own/

And yes, you can roll back to previous images as its an "immutable" OS as well should issues arise

Counterpoint:

https://forums.developer.nvidia.com/t/545-drivers-have-bad-f...

https://forums.developer.nvidia.com/t/wayland-native-wayland...

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317

and literally me being a Linux Nvidia 1080ti user for years and having plenty of issues

https://i.imgur.com/lwHDZoq.png

The Nvidia container toolkit works pretty much out of the box on WSL these days as well.

Funny that some cuda stuff works better through Windows virtualizing Linux than Windows natively, but if we're being honest even as a native Linux user, WSL probably provides a better user experience (vs having to use Nvidia drivers on Linux anyways)

I don't particularly disagree, but rather I've viewed the AUR as having value in that you can change build options (for instance enabling/disabling features) that may not exist in pre-existing binary builds.

The distribution aspect of the AUR is useful given the various tooling/helper utilities around it, but I don't see it as more effective than flatpak if you're just using binaries that already exist. While the AUR is a bit more of a direct path, you don't have to worry about system level dependencies changing and breaking the binaries with flatpak (even if that does result in more disk usage as a side-effect).

I found it a more practical alternative to the Arch AUR in many cases (especially the -bin packages which don't have any benefit of being a part of a "build" system anyways)

Similar (perhaps slightly lower given verification efforts) concerns about integrity/supply chain (who is maintaining this package really? Is it a clean build from the correct source?), but distro independent and often works good enough with some exceptions. Sandboxing is limited but better than nothing.

Once I somewhat understood the process and where everything is on GitHub (fairly transparent with CI stuff) I felt a bit more comfortable with things, but a lot of the store interfaces leave a lot of questions unanswered about the source (location) of the software.

If something is out of date I can usually make a GitHub issue and it'll get sorted soon enough.

Not the worst experience I've had.

Basically:

- Scan your system processes (and associated window titles)

- "native" screen capture

- Game overlay

- Global hotkeys

It's plenty possible to just use discord in the browser if you don't care of any of the above

I can kinda see the point there, but in the lottery example there's at least a possibility of making contact at a later date.

The bus is irreversible and sudden.

I'd say the lottery example works for example with skills/knowledge. ("Do we have someone else who can do what that person was doing?")

While the Bus factor is very relevant for issues like infrastructure and access ("The only person who knew the important passphrase or credentials is now lying dead on the pavement.)