Oh you again, yes Linux supports every normal hardware, and even a lot of crazy ones like Risc-V
On Android the system is bundled with the firmware as it comes from the same people. And for some reason those people dont like providing updates for sane amounts of time, like… 20 years?
haha yes me, no I was wondering about running the latest versions of linux on older machines. are they capable or more limited to older versions just because the age and the older hardware?
But I just may not be able to run the newer releases that come out and continue to come out? if the machine is a tad old? is that what I’m getting? because that’s what im trying to figure out
is there like a competent antivirus i could use: the system is freshly installed and i havent used any shady software; everything from the repo and a hash checked tor browser(I didnt visit any shady site just clearnet browsing)
Totally fair, and largely what I use it for, but it’s also helpful in the term at times to just get out a weird regex for a weirder file operation you don’t want to dork
Probably yes. As long as it’s 64 bit, it will run without issue, hardware dependant. For 32 bit machines, you have to be more careful. The 32 bit core duo and pentium m CPUs don’t support pae.
Edit: First Gen Pentium M don’t show pae support as a flag but they do.support it. You have to set forcepae for some distros. I read the page incorrectly. Pentium M laptops that have 5 in their model number, like the 735 are second gen Pentium M
They don’t show pae support so some OSes have issues. This is specifically for the first generation. I have a Pentium M 735 laptop which shouldn’t have this issue but for whatever reason PAE enabled OSes such as 32 bit Ubuntu won’t boot. I probably screwed something up. It currently runs bunsenlabs helium as it doesn’t require PAE. I’ll amend my previous comment
I usually go for business level dells, like latitudes. They’re the go-to for corporations so they’re usually pretty well supported simply because they’re so common
Looks like they have no idea how to get their software working using Nix. The following blurb is absurd to most GUIX or Nix users:
NOTE: In most cases, end users should never compile fwupd from scratch; it’s a complicated project with dozens of dependencies (and as many configuration options) and there’s just too many things that can go wrong.
Users should just have fwupd installed and updated by their distro, managed and tested by the package maintainer. The distribution will have also done some testing with how fwupd interacts with other software on your system, for instance using GNOME Software.
I’m not sure I see the problem here? It does say most cases and I’d definitely consider Nix/GUIX users to be in the minority for this (on top of users who would even compile software themselves in the first place).
Also from what I experienced during my (not so long) time with NixOS, usually things in Nixpkgs were contributed there by community members who ported applications over to be compatible with Nix. Sure, it’s a nice extra thing when the application developer does so out the gate, but given how special Nix and GUIX’s environment is, the onus has never really been on the app dev.
I’m not pointing to a problem per se. I’m just saying that this dev dismissed the act of building this from scratch as impossible when it is not actually impossible. Honestly, I’m just trying to spread the word about Nix and GUIX because they make things that were previously considered impossible (like this) possible.
I see, that’s plenty fair enough, although I don’t think they meant it quite so literally (but rather as a method of lightening their support requests - I don’t have any fwupd capable hardware AFAIK however I get the feeling fwupd is pretty popular).
I find it really cool what Nix/Guix are doing and I give major props to their communities for what they’ve pulled off, for what its worth.
My experience with flatpak has been stellar from a technical perspective has been stellar.
Where it currently falls short for me personally is trust. With my distro I am putting my trust into the maintainers, but with flatpak its… random people for most apps?
It is tough when it is not a primary channel of distribution for most devs, but I am optimistic that will change in the future.
It’s sandboxed though. Running an app from a developer already implies trust on your part. So if it’s sandboxed away from your other stuff, what’s the issue?
Sandboxed just means an app can’t reach out to the rest of the OS. What about the information I am entrusting to it to process?
If my browser is a flatpak, it likely has access to most of the information I care about. If I am using a chat app that is a flatpak, it can read my most personal communications. Why do I care if it can read what is in /etc?
Running an app from a developer already implies trust on your part.
You totally missed my point. My point was that a lot of flatpaks are packaged by unknown third parties. I would love it if the devs would package things as flatpaks directly, but that is mostly not the case.
Looking at flathub right now. 1567 applications are from unverified publishers vs 789 verified. Unverified apps include chrome, edge, chromium, brave, BITWARDEN and signal. All of those applications process highly sensitive information.
Seems like every flatpaks update has to redownload Nvidia drivers for each package which is like 500mb, and my download speed is 3mb/s on a good day. So flatpaks limit me to updating once a month
Nix is definitely cool and I already have it installed on my system. Unfortunately, even Nix has trouble with keeping Brave up-to-date at all times. It’s still on 1.59.120, while Brave has had three releases since. It took about 3 days after the release of version 1.59.120 for them to release it on their repos. As you can see, it leaves a lot to desire.
It’s a community maintained repo. The possibility of updating it yourself is possible. The master branch is updated to the 1.59.124, which came out a week ago. And was updated around the same time. 1.60.110 was just released 1 day ago. You can update it yourself. After all, it’s supposed to give you a great default state to fall back to, not keep you on the bleeding edge of releases.
Minor version bumps should be mostly trivial: Change version and hash, package that into commit+PR (ckeck guidelines on that!) and that’s it most of the time.
The harder part is QA; ensuring it still works as expected. Therefore, even just testing update PRs as they come in would be a great help.
If the code change is trivial and a user of the package said it still works for them, a commiter coming along is likely convinced of the PR’s quality and just merges it.
It’s super easy to contribute to Nixpkgs in a meaningful manner :)
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.