I really like these suggestions, I’ve always wanted to contribute to FOSS software, but always felt underskilled. I will add this to my list of things to do to challenge my Linux and basic programming skills.
It’s worth noting that the barrier to entry as a maintainer depends on which distro you’re using at the time. It’s not uncommon for a distro to have a community repository system, like PPAs in Ubuntu, AUR for Arch, MPR for Debian, etc. I’m not very familiar with Mint, and couldn’t easily tell if it has its own or just uses PPAs from upstream.
It isn’t especially taxing on programming skills, and if you don’t pick too complex of a package, the Linux skills required shouldn’t be wildly above your level, but may push you to learn some new things by digging a bit deeper. I haven’t formally maintained public packages, but I’ve needed to build a few over my years using Linux, and it was easier than I’d expected to just build one. It may be easier than you think, too.
Thanks for the additional info. I installed Arch, it was far less daunting then I anticipated. In fact, it was prettt straightforward. I’ll look into your suggestion.
I don’t get the hate arch gets - it’s the perfect distro if you want to choose what programs you want to use, it’s not meant to be an out of the box experience. Been using it for 3 years, and sure it might take me a couple of hours to set up initially, but after that I don’t really have to do anything.
I have not used it for a long time but it’s really easy to fuck the install and potentially your entire system, depending on the fuckup(s).
As a matter of fact, that is exactly why I used it the first time : since it’s a nice lightweight distro and it has some interesting gotchas regarding installation, our sysadmin teacher had us all install it and set it up before we could actually use our distro of choice
It’s a great distro to learn a lot about Linux. I challenged myself to install it on my Surface Go 2, and make it usable as a tablet, as well as make it boot with secure boot and more. Now it’s happily running Arch with KDE, using the linux-surface kernel signed with my own secure boot key and a pacman hook that signs that kernel after every update. I learned all of this acompanied by a lot of fuckups and reinstalls, until I was able to fix things after breaking them instead of starting from scratch.
I fully agree that it’s bad for users who aren’t that tech-savvy, but I meant it in a more general sense - during my time on Lemmy I’ve seen a ton of posts bashing arch and commenters pretty much calling it a “good for nothing distro”, with the only more hated distro being Manjaro.
It’s like arch except it doesn’t break all the time. And it has a great hardware and kernel utility, and still has access to the AUR. And I like pacman a lot better than apt.
From my experience (2 years Manjaro, 3 years Arch) it’s the other way round. Manjaro presented me with a terminal way to often after Nvidia updates. Never had that on Arch. Especially the Nvidia updates are very reliable. I don’t know what people do with their Arch installations. Mines rock-solid for the 3 years now. Possibly the most stable distro I ever used.
But I understand that you just can’t advise newbies to install Arch, even when archinstall is relatively easy to use. Maybe EndeavourOS which brings a lot of convenience features and a graphical installer to the table. A fellow linux newb is running it without problems for a year now.
I’ve been on Manjaro for about 10 years now, and these days (last few years) nvidia-dependency-conflicts-caused-by-eol-kernel is the only real issue you can run into unprompted. Even that kind of requires you to have at least a couple year old installation (for the kernel to go EOL), which means newbie shouldn’t ever be running into it. Not sure what Arch is doing these days, but when I was running it there was certain expectation of vigilance (reading Arch Linux News before updating) and readiness to fix issues caused by updates yourself. On Manjaro such major breaking updates are never sent to users on the stock stable branch, meaning you can practically run “pacman -Syu --noconfirm” willynilly.
I still wouldn’t recommend it as the first distro as it doesn’t hide the underlying complexity as well as something super mainstream like Ubuntu, but Arch/EndeavourOS is obviously much worse in that regard.
It’s been nearly 4 years since I last used Manjaro and I had that error quite often around ever ½-¼ a year in my 2 years of Manjaro. iirc to resolve it I had to uninstall the current nvidia driver > restart without driver > install supported kernel > install driver. Don’t know what I did wrong tho.
Manjaro did otherwise a good job to keep the sys together.
What bugged me a bit was the painfully long retention of the big KDE updates. At that time KDE was making big QOL leaps and quite a few distros had those updates already. But I could also live with that.
In the last month of my time with Manjaro a few Proton games dropped frames heavily and that’s the end of the story. Made the switch to Arch and never had probs with nvidia again, apart from when new Steam UI came out.
Manjaro can be a real pain depending on your hardware setup. They make a lot of choices that are difficult to work around when you need to (for better or worse) which kinda defeats the whole point of arch (to not be opinionated)
I have the same setup of packages on a few computers. 0 issues on one, plagued with boot issues on another. And unfortunately, the attitude of the devs and forum is that if you have boot issues its obviously your fault.
It was definitely a good first arch distro for me, but pacman, aur, and everything else work just as great on Endeavour and all my devices are far more stable than when they were on Manjaro.
I’ve seen a ton of posts bashing arch and commenters pretty much calling it a “good for nothing distro”, with the only more hated distro being Manjaro.
All distros have their little hate-clubs. Try being an Ubuntu user! Or Debian (“why are all the packages so old!”), or Fedora (“ew, Red Hat”), or Gentoo (“is that a laptop or a space heater?”) or…er, openSUSE (now I come to think of it, does anybody actually hate SUSE?). You get the idea, anyway. People get super weird and fanboyish about distros.
I don’t think arch has it any worse than the rest.
I think even if you’re tech-savvy you can have issues with Arch tbh. I don’t think the distro is without merit — a minimal rolling release binary distribution is clearly something people want… But I’m not sure Arch does a great job of being that (for me, at least), and I’ve personally found pacman and the official packages to be kind of lacking (keyring update issue that they’ve maybe finally fixed, installing specific versions of packages / pinning specific versions / downgrading packages are either not supported or not well supported, immediately removing kernel modules on upgrade, even if the currently running kernel may need them, etc…). It just doesn’t feel very polished in my experience and for my use cases (clearly it works for some people!), and that’s what has driven me away from Arch personally. I think a lot of this stems from Arch’s philosophy of being aggressively minimal, which is maybe fair enough… but I don’t think it’s for everybody.
I think Arch kind of deserves the hate it gets. I love barebones distros and have been a gentoo user (now on NixOS), and I’ve used arch a fair bit too… I just don’t feel like Arch is a well maintained distribution. There’s all sorts of little things that they can’t seem to get right that other distros do, like that silly issue where they won’t update the arch keyring first, so if you haven’t updated in a while it breaks. In my experience there’s a million little paper cuts like this and I’ve just been kind of unimpressed. If it works for you that’s great! I’ve just been disappointed with it. I get the niche that it fills as the binary “from scratch” rolling release distro, but I think the experience with it is a little rough. I’ve found gentoo more user friendly, which probably sounds bizarre if you haven’t used gentoo, but ignoring compiling stuff, gentoo does an excellent job of not breaking things on updates, and it’s much easier to pin and install specific versions of packages and stuff.
@Chobbes
Looks like you haven't been using Arch for quite some time now. That used to be the case, nowdays it's way better experience. I've been using Arch for about 11 yrs now and I can see that improvement is noticable. Still not THE BEST, but waaaay better.
Once you learn about Linux, you go faster than any other noob. And that is very useful for programming/hacking jobs, faster than all those noobs with 0 knowledge about what is what.
Reminds me of the test server shenanigans I had at an old job versus a colleague. All in fun. Nothing in production.
One was the faux Bash shell that kind of worked OK until you pushed it or tried to do anything fancy. It was the default shell for the user called "root", but that wasn't the UID 0 user. It had been, but I renamed it. Then created a new "root" with a different UID. Of course, the faux shell would tell "root" that it was UID 0.
The other was the simple background loop that would detect any rival admin sessions and SIGHUP their shell process. First user on the box to run that pretty much had free reign, and everyone else was logged off instantly.
I don't think anyone is going to come smash down your door because you installed Ubuntu. But I don't know what country you are in and two years ago I wouldn't have believed Iranian police would kill people over wearing a hijab. So I think you should do it, but I also think you should stay safe.
I think most chromebooks allow you to disable their boot security? some even allow you to re-enable it with different keys so that you can have a different trust anchor instead of google.
Installing Ubuntu isn’t breaking any DRM or any anti-piracy measures.
Unless your country is really strict about using devices exclusively as the manufacturer intended, but that’d be countries that also want to monitor everything you do. Hard to tell without knowing what country that is.
That said, I’m pretty sure Google is perfectly okay with people doing that. Even on the Pixel phones, they openly let you unlock the bootloader, and even allows you to add your own keys so you can relock the bootloader with a custom OS. They only care about security and people not getting a device from eBay full of malware. That’s why there’s a message during boot that’s either orange or yellow warning, to tell the users the device has been tampered with. But everything works fine otherwise.
Is anyone actually running modern Linux on Itanium? I have never in my life even heard of anyone using those chips. I find it hard to imagine anyone still using them that isn’t running something legacy.
It’s still a supported architecture in Gentoo. I expect it will limp along there for as long as there is viable kernel source (current or LTS) and at least one interested maintainer. So if you have an Itanium machine lying around, you can install a current Linux on it. As long as you’re willing to follow a long set of instructions, anyway.
The last chip was manufactured 3.5 years ago and the last serious user was probably several years before that. Obviously no one’s running Itanium with modern hardware.
But just because the hardware isn’t modern, doesn’t mean the software can’t be modern. Tonnes of people run the most recent Linux kernels on 15 year-old laptops, so why not 10 year-old servers? Itanium is only for the hobbyists these days, but so what? Hobbyists have done a good job of ensuring modern Linux can run on 40 year-old 68k. Itanium can theoretically be done, too. It’s just a question of whether the hobbyist community has enough of the right people that can actually maintain it.
Hobbyists, especially hobbyists in itanium are an incredibly small market share. Their time is much better spent on what people, and most importantly businesses (who pay their bills) use.
It wouldn’t surprise me if there were still a few production Itanium systems in server rooms somewhere, running some obscure or bespoke proprietary software that can’t be migrated to anything else. There are other more arcane systems still being limped along in businesses around the world, for some frighteningly critical applications in some case.
Itanium support being dropped probably has a handful of admins panicking, but in the eyes of the kernel developers it’s a case of “put up or shut up”.
running some obscure or bespoke proprietary software that can’t be migrated to anything else
this is the primary issue – everyone looks at corporations when talking technical debt, but so many medium and small businesses are limping along on so called “enterprise” solutions they were sold a couple decades back and are now completely locked into proprietary formats for which support ended last decade
I’m a mech E in the medical field. We’re consistently understaffed. If I validate an Excel worksheet in Excel '08 or a Python program in 3.5 with a specific version of NumPy, we’re probably sticking with those versions for a while. Every time I bring up re-validating with the latest version, keeping one old system running the old software requires fewer resources than me or a colleague re-validating.
My whole department is stuck on one version of Python because that was the most recent version when I had an emergency project and developed a data analysis algorithm. We validated it, then as new members were added to my team, they needed a copy, so we had to keep using it. I’ll probably re-validate it to the next Python release. It’s not only unit tests, or we could automate validation. Unit tests are a tiny part of validating software for making medical decisions. And software that directly runs a medical device (like firmware on an insulin pump) is an order of magnitude more rigorous than what I do.
Side note: there are people who somehow root their insulin pumps and run algorithms on them. There’s a group that can get a PID control loop on an insulin pump that has a more simple control scheme on it (because that’s how the FDA approved it). The company has been trying to get approval to use PID control in the US for years.
The AS/400 platform is still alive and actively maintained by IBM so I’m told, although I think it goes under the Power Systems and IBM i brands now. I know several business still using them, with development teams still coding with RPG etc. Apparently there is also reasonable ecosystem of middleware to interface with more modern systems, and some sort of *nix compatibility layer to run more modern software on the platform.
I’ve never touched one myself, but they are keeping a few greybeards I know in steady work.
I thought that “Wayland by default” being merged meant it will be a part of the next release but there wasn’t even a mention of it. Will it be a part of the next release maybe?
I could be wrong, but i think that was probably on the alpha release, which is now the beta release, so maybe the next stable release will have wayland by default.
Also Brodie’s podcast Tech Over Tea. I was on the podcast so I’m a bit biased, but he has a lot of open source developers from different projects on and they are always interesting.
Title bullshit, we have multicore machine for years, I can guarantee you this had about no impact else people running Xeon or Threadripper would have saw it at first try 15 years ago.
This looks like to have an impact on the scheduler but not on how many cores are used.
I agree. Some of the Linux servers I used to run at work in the early 00’s were 12 to 16 core monsters (for the time) and the kernel didn’t even blink.
How did you manage with video performance? I don’t game and have had a lot of experience with both vbox and kvm. Kvm performance for video is excruciatingly slow. It got to a point I said “that does it” and went back to vbox.
Yea KVM is great but it’s not so easy to pass device’s through. Whereas in Virtualbox you go to the menu, select devices, the type of device (eg usb) and then select the device (eg printer) to have it show up on Windows.
I think NixOS is awesome, but it certainly doesn’t offer “access to (basically) all Linux-capable software, no matter from what repo.” - at least not natively. You can do that through containers, but you can do that with containers on any distro. Where it shines is declaring the complete system configuration (including installed programs and their configuration) in its config file (on file-based configuration, I wouldn’t really consider blendos a viable competitor).
And you can create package configs, but you can also do that for nearly every distro. So, yeah, that confuses me too… I’m not sure what OP was trying to say there.
To clarify, I was referring specifically to its ability to specify the full system configuration in its config file - not overall. But I haven’t used blendos, and my impression is mostly from a quick look at their documentation. They have a snippet with sample configuration. There, they have a “Modules” section, but I couldn’t find what modules are available, what options they have, how to configure them if we want to do something more complex than the available options.
Then containers are clearer: they have a list of installed apps, and then commands to bring them to the desired state (somewhat similar to a dockerfile). But even then, i imagine that if you have a more complex configuration, that’s going to get clunkier.
Do you think the use of OCI containers/images is a mistake/bad choice from blendOS?
No. It’s probably the best way to run packages from Arch, Debian. Ubuntu, Fedora, and others, all on the same system.
How is NixOS different?
NixOS simply doesn’t tackle that problem, so it doesn’t come with containers out of the box. If you want to run packages from other distros on NixOS, you’d probably need to manually configure the containers.
I feel like you’re under the impression that the three distros, NixSO, blendos, and Vanilla OS, have similar goals. I don’t know about Vanilla OS, but the main similarity between the other two is that they’re both non-standard in some way.
But they’re actually solving completely different problems: BlendOS wants to be a blend of different OSes, NixOS wants to have a reproducible, declarative configuration (declarative here means, you don’t list a bunch of steps to reach your system state, but instead declare what that state is).
It’s the probably the best distro for dev work imo. Nix in general is really nice for development. Games work fine — you can just install steam or putrid or whatever, and you can run normal binaries with steam-run.
The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you’re working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don’t accidentally use features from after boost 1.61 for project A, because that’s the stated requirement, but you need features from boost 1.75 in project B.
In a normal distribution, in order to set up an environment that has the proper version for project A you’d need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.
In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there’s even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It’s like a better version of venv, but for everything.
Well, for playing games I use the flatpak version of steam and it works OK.
For dev work, it’s great overall. Especially its ability to create separate reproducible environments with whatever dependencies you need for every project. However, there are some tools (rare, but they exist) that don’t work well with it, and if your dev work happens to need them, it can becomes a problem.
For day to day (i.e. web browsing), it works the same as anything, with one disadvantage: there is a disadvantage here: it downloads a lot more than other distros on update, and uses more disk space. The biggest difference between NixOS, and say Arch, is not how it behaves once it’s up and running, but in how you configure it. Specifically, you have to invest a lot of time to learn how, and set up your system initially. But then reinstalls, and (some of) the maintenance, become easier.
The way nix deals with packages is very different from most distros. If you install a newer version of a package, the older version just gets hidden, not removed. This makes it very easy to rollback or recover from errors, but it does mean you tend to use more space.
In regular FHS distros, an upgrade to libxyz can be done without an update to its dependants a, b and c. The libxyz.so is updated in-place and newly run processes of a, b and c will use the new shared object code.
In Nix’ model, changing a dependency in any way changes all of its dependants too. The package a that depends on libxyz 1.0.0 is treated as entirely different from the otherwise same package a that depends on libxyz 1.0.1 or libxyz 1.0.0 with a patch applied/new dependency/patch applied to the compiler/anything.
Nix encodes everything that could in any way influence a package’s content into that package’s “version”. That’s the hash in every Nix store path (i.e. /nix/store/5jlfqjgr34crcljr8r93kwg2rk5psj9a-bash-interactive-5.2-p15/bin/bash). The version number in the end is just there to inform humans of a path’s contents; as far as Nix is concerned, it’s just an arbitrary name string.
Therefore, any update to “core” dependencies requires a rebuild of all dependants. For very central core packages such as glibc, that means almost all packages in existence. Because those packages are “different” from the packages on your system without the update, you must download them all again and, because they have different hashes, they will be in separate paths in your Nix store.
This is what allows Nix to have parallel “installation” of any version of any package and roll back your entire config to a previous state because your entire system is treated as a “package” with the same semantics as described above.
Unless you have harsh data caps, extremely slow connections or are extremely tight on disk space, this isn’t much of a concern though.
Additionally, you can always “garbage collect” old paths that are no longer referenced and Nix can deduplicate whole files that are 1:1 the same across the whole Nix store.
I would disagree. I feel like nixpkgs has pretty much everything, more so than any other distro in my experience. The differences in how NixOS work can make it a little weird to run something off the cuff, but steam-run has your back in those situations.
I think NixOS is awesome, but it certainly doesn’t offer “access to (basically) all Linux-capable software, no matter from what repo.” - at least not natively.
I don’t quite agree with this. In NixOS you can write custom expressions that fetch software from any source, and stitch them into your configuration as first-class packages. So you do get access to all Linux-capable software natively, but not necessarily easily. (There is a learning curve to packaging stuff yourself.)
I use this process to bring nightly releases of neovim and nushell into my reproducible config. Ok, I do use flakes that other people published for building those projects, which is a bit like installing from a community PPA. But when I wanted to install Niri, a very new window manager I wrote the package and NixOS module expressions all by myself!
Another NixOS user (and minor package maintainer, if it matters) here. Essentially, NixOS is actually rather simple to write a configuration file for a particular program once you get the knack for the nix language and learn how to workaround the sandboxing. I would actually consider it substantially less involved as compared to (for instance) creating your own Debian package.
However, getting to this point will take a bit of effort, and this step is more or less obligatory to use software on NixOS, whereas it generally isn’t (but still is a good idea) on other distributions.
(There is a learning curve to packaging stuff yourself.)
“Learning curve” is an understatement. Nix is one of the most poorly documented projects I’ve seen, next to openstack. Coming into it with no background in functional programming didn’t help.
But I’ve tried to package other stuff, like quarto, and that was a nightmare. Nixpkgs didn’t have an updated pandoc and I spent an eternity asking around for help, to try to package it. An updated version just got pushed to unstable a few days ago. The same matrix channels I joined to ask for help have been discussing this since then. Props on them for getting it working, but anyone who says that you can easily package anything, is capping. You need to have an understanding of the nix language, nix packaging (both of which are poorly documented), and a rudimentary packaging ecosystem of what you are trying to package.
Don’t even get me started on flakes vs nonflakes.
I still use nix-shell for all my development environments, because it’s the best way for reproducible environments I can share I’ve found.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.