4 ms·

> Except the upstream dev's are sick of dealing with "It doesn't work in my distro" 99/100 it does work on their distro, they just need to handle their librari

by hx8 3y ago

> Except the upstream dev's are sick of dealing with "It doesn't work in my distro" 99/100 it does work on their distro, they just need to handle their libraries better. Identify the packages they need to support the software, or if no packages exist then they need to compile the libraries themselves. The entire point of Linux distributions is to do this job for the user. Sometimes the distro will fall short, so you need to have the basic understanding to handle it yourself. Of course, Linux users aren't as tech savvy as they were 20 years ago.

akdev1l 3y ago
> so you need to have the basic understanding to handle it yourself No they don’t. This idea that people need to become System Administrators to use Linux really needs to die.
- nextos 3y ago
  You are bringing up a valid problem, but I think this needs to be fixed at UI level. There are GUIs getting developed for e.g. NixOS that lower the barrier to use the OS pretty dramatically. I agree things need to be simpler, but it would be nice to keep the capability to generate a bill of materials for each package. IMHO, Flatpak is a regression in some of these aspects.
  - timeflex 3y ago
    I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations. As much as I've despised the JavaScript ecosystem in the past, it seems like TypeScript with Deno which has built-in JSON/TOML/INI/YAML and sandboxing would be a better language to handle automatic system configuration overall... plus, you'd have the advantage of a web app to manage your system config(s), sort of like what fish does.
    - kaba0 3y ago
      > lot of packages just break out into command line scripting because of its limitations That’s not a breakout, nix just provides the glue around shell commands, because that’s the most readable/accepted way to specify process invocations. Nix should be thought of as a data store, it’s just a huge object with keys and values.
    - pxc 3y ago
      > I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations. What you're describing is the use of bash builders in Nixpkgs. This is conventional because lots of build systems expect bash anyway, and because it lets you easily incorporate the whole Nix build environment for a given package into a conventional interactive shell for debugging, where you can invoke functions that are available in the build environment and even copy/paste snippets from the build to inspect their behavior. I like it; I think it's a good approach! It's worth noting though that Nix supports using builders in arbitrary languages, and there are some rare uses of non-bash builders throughout Nixpkgs as well. Some other points: - if you prefer a using the same language for your package recipes as the builders themselves, Guix has you covered. - Nix has built-in support for reading and writing to many some of the formats you mention, like TOML and JSON. Some tools use those languages to provide an external configuration language for Nix, for the simple stuff, e.g., devenv, devbox, Flox, etc. One could certainly attempt this with NixOS as well.
    - michaelmrose 3y ago
      Why not guile with guix?
- hx8 3y ago
  This idea that we need to spoon feed simple solutions to users of free software really needs to die. If you're giving code away you don't owe your users much.
  - pxc 3y ago
    I might even say that if you're giving code away, you don't owe users anything. But you might also have goals for your project that would benefit from trying to attract, on onboard, or otherwise please users.
  - timeflex 3y ago
    The idea of spoon feeding simple but incredible solutions for free can be very rewarding for maintainers, and can also generate a monetary reward as well. There are projects that I happily donate to because they create value for me. How many terms of service have you read of apps that you pay for? It seems that many apps you pay don't just take your money, but your privacy and rights away too. Developers creating something in the open can inspire and help make communities of people working on a shared goal, that attracts quality individuals from all over the world to help. It brings people that are excited about your goals and that came to your project because it was something they could find and appreciate. I'd say, you don't get the same from closed-source software. You also can't achieve the same by being an asshole to potential contributors just because you feel like it. Sure, it is an option, but if you want to actually build something... not just for you, but a dream, then it is a bad choice to not try to build a healthy community.
- freeone3000 3y ago
  The administration should be taken care of by the distro, but, it isn’t. Fedora Stream might be the solution here.
zer00eyz 3y ago
>> The entire point of Linux distributions is to do this job for the user. You would think, but we have some fair conflicts between distros and upstream software. Bottles is throwing the gauntlets down and said "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug". A lot of other bits of software are moving this way because they just dont have the bandwidth to support the disros' nonsense (in their eyes) Some software maintainers are looking at flatpack as a way to right size the effort in supporting users.
- cuu508 3y ago
  > "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug" Two cases here: * it's a legitimate upstream bug, but is being rejected because you are using a distro-packaged version, not an official upstream release. Reproduce the problem with the upstream release, report it, done. * it's a distro-specific bug, you cannot reproduce it with an upstream release. In that case you should indeed report it to the distro, not upstream.

by hx8 3y ago

akdev1l 3y ago

> so you need to have the basic understanding to handle it yourself No they don’t. This idea that people need to become System Administrators to use Linux really needs to die.

nextos 3y ago
You are bringing up a valid problem, but I think this needs to be fixed at UI level. There are GUIs getting developed for e.g. NixOS that lower the barrier to use the OS pretty dramatically. I agree things need to be simpler, but it would be nice to keep the capability to generate a bill of materials for each package. IMHO, Flatpak is a regression in some of these aspects.
- timeflex 3y ago
  I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations. As much as I've despised the JavaScript ecosystem in the past, it seems like TypeScript with Deno which has built-in JSON/TOML/INI/YAML and sandboxing would be a better language to handle automatic system configuration overall... plus, you'd have the advantage of a web app to manage your system config(s), sort of like what fish does.
  - kaba0 3y ago
    > lot of packages just break out into command line scripting because of its limitations That’s not a breakout, nix just provides the glue around shell commands, because that’s the most readable/accepted way to specify process invocations. Nix should be thought of as a data store, it’s just a huge object with keys and values.
  - pxc 3y ago
    > I really love the theory of NixOS... an entire OS that is declaritively (or dynamically) defined. But the nix language itself does not seem like the right approach. A lot of packages just break out into command line scripting because of its limitations. What you're describing is the use of bash builders in Nixpkgs. This is conventional because lots of build systems expect bash anyway, and because it lets you easily incorporate the whole Nix build environment for a given package into a conventional interactive shell for debugging, where you can invoke functions that are available in the build environment and even copy/paste snippets from the build to inspect their behavior. I like it; I think it's a good approach! It's worth noting though that Nix supports using builders in arbitrary languages, and there are some rare uses of non-bash builders throughout Nixpkgs as well. Some other points: - if you prefer a using the same language for your package recipes as the builders themselves, Guix has you covered. - Nix has built-in support for reading and writing to many some of the formats you mention, like TOML and JSON. Some tools use those languages to provide an external configuration language for Nix, for the simple stuff, e.g., devenv, devbox, Flox, etc. One could certainly attempt this with NixOS as well.
  - michaelmrose 3y ago
    Why not guile with guix?
hx8 3y ago
This idea that we need to spoon feed simple solutions to users of free software really needs to die. If you're giving code away you don't owe your users much.
- pxc 3y ago
  I might even say that if you're giving code away, you don't owe users anything. But you might also have goals for your project that would benefit from trying to attract, on onboard, or otherwise please users.
- timeflex 3y ago
  The idea of spoon feeding simple but incredible solutions for free can be very rewarding for maintainers, and can also generate a monetary reward as well. There are projects that I happily donate to because they create value for me. How many terms of service have you read of apps that you pay for? It seems that many apps you pay don't just take your money, but your privacy and rights away too. Developers creating something in the open can inspire and help make communities of people working on a shared goal, that attracts quality individuals from all over the world to help. It brings people that are excited about your goals and that came to your project because it was something they could find and appreciate. I'd say, you don't get the same from closed-source software. You also can't achieve the same by being an asshole to potential contributors just because you feel like it. Sure, it is an option, but if you want to actually build something... not just for you, but a dream, then it is a bad choice to not try to build a healthy community.
freeone3000 3y ago
The administration should be taken care of by the distro, but, it isn’t. Fedora Stream might be the solution here.

zer00eyz 3y ago

>> The entire point of Linux distributions is to do this job for the user. You would think, but we have some fair conflicts between distros and upstream software. Bottles is throwing the gauntlets down and said "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug". A lot of other bits of software are moving this way because they just dont have the bandwidth to support the disros' nonsense (in their eyes) Some software maintainers are looking at flatpack as a way to right size the effort in supporting users.

cuu508 3y ago
> "we dont care about your bug if your NOT using the flat pack, if you got it from your distro its your distorts bug" Two cases here: * it's a legitimate upstream bug, but is being rejected because you are using a distro-packaged version, not an official upstream release. Reproduce the problem with the upstream release, report it, done. * it's a distro-specific bug, you cannot reproduce it with an upstream release. In that case you should indeed report it to the distro, not upstream.