51–60 of 66 posts
Earlier quoted context omitted.
You can just use a GCC docker image to build: https://hub.docker.com/_/gcc
No I can't... without an appropriate installation of docker and/or dependencies of docker. See: https://docs.docker.com/engine/security/rootless/#prerequisi...
Earlier quoted context omitted.
You can just use a GCC docker image to build: https://hub.docker.com/_/gcc
No I can't... without an appropriate installation of docker and/or dependencies of docker. See: https://docs.docker.com/engine/security/rootless/#prerequisi...
Earlier quoted context omitted.
No I can't... without an appropriate installation of docker and/or dependencies of docker. See: https://docs.docker.com/engine/security/rootless/#prerequisi...
You don't control your device OS or otherwise have access to a machine you do, your OS does not offer modern packages, and you don't have the ability to otherwise pull in development toolchain resources.... yet it's supposed to be the projects problem you can't compile something started in 2021 from source on your older setup? I get your current situation is less than ideal for you but at some point you have to accep…
Now, I _can_, with some effort, pull/build a development toolchain. But it would be much nicer if I could have access to this utility on machines with older toolchains, that's all.
Earlier quoted context omitted.
You don't control your device OS or otherwise have access to a machine you do, your OS does not offer modern packages, and you don't have the ability to otherwise pull in development toolchain resources.... yet it's supposed to be the projects problem you can't compile something started in 2021 from source on your older setup? I get your current situation is less than ideal for you but at some point you have to accep…
You have the implicit assumption that I'm working on an individual project. Imagine a large company which settles on an OS for some product that goes into the field for 10 or 20 years. That's the OS you're stuck with. And yes, that's painful in itself. Now, I _can_, with some effort, pull/build a development toolchain. But it would be much nicer if I could have access to this utility on machines with older toolchains…
It seems unfair to both developers and other users of the project to expect it to be compatible with older toolchains given the benefits of the newer builds.
On the surface looks like an improvement over htop ( which I've been using for 10+ years ) But this is the kind of software that I would want to keep using. Will btop keep being supported? Is btop going to be available in practically all distros I use? Even currently on Arch its only in the AUR. Its also concerning there is btop[0] and bpytop[1]? I don't understand the difference. [0] https://github.com/aristocratos/…
Would you like to have btop in Arch [community]? I could move it if it has enough interest.
Earlier quoted context omitted.
I use atool ( https://www.nongnu.org/atool/ ) for unpacking random archives - it abstracts away all formats including zip/rar/7z, compression and also guarantees that nothing is ever extracted into $CWD.
I use `unp` for the same thing. `-u` extracts into a directory.
Looks like it might be in standard Ubuntu repositories: