291–300 of 538 posts
Is it time to switch from Ubuntu to Mint? Does Mint have enough repositories that work? I'm at Ubuntu 18.04 LTS, and Ubuntu 20 seems to have a host of unwanted Canonical-oriented features. I'd appreciate comments.
Earlier quoted context omitted.
Any distro where you have to write a little haskell-ish 30 line script to set up an environment just to be able to start compiling (or even running!) things is not going to be widely popular for desktop use.
It's definitely going to take some work. I have set up my first NixOS install, and the functionality is very impressive, but usability-wise it is a mess. I think Nix/Guix is going to be the bridge to the post-POSIX world where we can move away from the trend of a globally visible filesystem and into much stronger container-based approach. But it can't be in its current form; the Nix language and Guix's Guile/Scheme a…
Earlier quoted context omitted.
Any distro where you have to write a little haskell-ish 30 line script to set up an environment just to be able to start compiling (or even running!) things is not going to be widely popular for desktop use.
For desktop use, any shortcut icon on a desktop would just be a wrapper script for `nix-shell -p --run `
Earlier quoted context omitted.
> If desktop Linux is ever going to be mainstream there needs to be an easy to use "app store" where users can use a GUI to install apps which need to be sandboxed like on a mobile phone with defined permissions. Curious... do you think that the world has moved on from the "download from website and run installer" model? Obviously that has serious drawbacks from a security perspective, but up until less than a decade…
>For the most part, the only people who really care about "the year of the Linux desktop" are people trying to build a business around desktop Linux As another long time Linux guy, I have a feeling most of those obsessed with Linux becoming a mainstream desktop platform are Mac or Windows users.
They just want to get Chrome and VSCode running without any headaches.
This seems like a problem: > Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone. One of the nice properties of debian packages is the ability to `apt-get source` and build it locally. Would be a shame to lose that. Maybe Nix and Guix can provide the best of both worlds here: self-contained software but reproducible builds t…
Any distro where you have to write a little haskell-ish 30 line script to set up an environment just to be able to start compiling (or even running!) things is not going to be widely popular for desktop use.
I understand why there's consternation about usability (and a steady stream of requests focused on helping novices get it up and running), but I'm not sure the project(s)/ecosystem are ready for the stress of getting strapped to a growth rocket that brings in many new non-developer general-computing users who can't reasonably contribute back.
I don't mean this in an elitist RTFM way. More users of any stripe just inevitably exert support pressure in all sorts of directions. The community is perpetually iterating on tools/automation/process issues to try and stay on the right side of the wave. I sympathize with everyone who has a tough time finding their legs, but for the near term I think it is probably a net good if ergonomics issues filter out people for whom most distros are effectively fungible.
Earlier quoted context omitted.
The point isn't that the devs are the ones doing the auditing, even though pretty much everything that lives in DEB and RPM repos has maintainers which do. The point is that you can audit without having to depend on a third party. Nobody's claiming audits are free or that they're assumed. The point is that you have the option to choose to trust as much or as little of the build chain, from the compiler to the target…
let me clear some things up and tell me if I am wrong, link me to the correction and I will apologize. - Mint uses Ubuntu repositories - Canonical pushes the changes they want into this repos, this changes are probably done by scripts that build source code on Canonical servers. - the Ubuntu repos also contain binary blobs - when a Mint user does an update he gets the binary directly from Canonical servers, there is…
When I update Mint binaries, I get them from one of about 30 mirrors which Mint enables me to choose. (Or it will decide for me based on speed.) Do the mirrors at Clarkson, Harvard, Purdue, UW, etc belong to Canonical? I think not. Nor does most of the code the binaries are built from.
Canonical has made its choice, Clem's made his.
Earlier quoted context omitted.
As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former…
FlatPack was made to address two things focused on security: 1) Application won't need root privileges 2) Without compromising on the systems security
I think fixing what we have in standard kernel/userland, and leaving the containers for specialized developer/devops deployed workloads may well be where this (what will be known as the snap/flatpack saga) started from, and will end as well.
Earlier quoted context omitted.
> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken…
As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former…
I wonder if it is finally time for me to give Arch a try. It's a shame that all my lab's machines run Ubuntu; although I find it solid, this sort of controlling behavior by Canonical seems against the spirit of FOSS.
There's a reason Arch is so famous and a meme: installation is a challenging weekend project if you've never done it, but it's the most stable distribution with the sanest ecosystem (AUR, sane defaults like systemd, fastest package manager, rolling releases, packages are kept as close to upstream as possible).
Once you go Arch you probably won't go back and you will just grow the meme further.