Oh fk now thinking about it, me starting to use an Arch based distro and starting going to laser epilation pretty much happened at the same time period. Save me…
Yes, there is a little colony of gnomes sitting inside the machine. They are the ones doing all the heavy calculations. The bitcoin boom burned out so many of them it’s a total disaster. Currently you could consider them kind if endangered I guess.
In the unix world, truly great programs tend to stay around for ever. less has been around since 1983. grep was there ten years earlier. Linux users love vim. What does the “v” stand for, you ask? “Visual”, of course, because it was one of the first text editors to offer support for computer monitors. And before that, when we had teletypes, people used ed, which still comes pre-installed with Ubuntu. Not to mention that the modern linux terminal is basically emulating (that’s why we called them terminal emulators) an electronic typewriter with some extra extensions for color and cursor support. They’re backwards compatible to this day. That’s why it says tty (teletype) when you press ctrl-alt-F2.
The caveat is that these examples are all low-level programs that have few dependencies. And they are extremely useful, therefore well-maintained. When it comes to more complex programs with a lot of dependencies, unless there is someone to keep it updated with the latest versions of those dependencies, it will eventually get broken.
The reason this happens less often in Wndows is because wndows historically hasn’t had a package manager, forcing devs to bundle all their dependencies into the executables. Another part of the reason is that mcrosft would lose a lot of business customers if they broke some obscure custom app with a new update, so they did their best to keep everything backwards compatible. Down to the point of forbidding you from creating a file named in order to keep support for programs written for qdos, an OS from before filesystems were invented.
The reason this happens less often in Wndows is because wndows historically hasn’t had a package manager, forcing devs to bundle all their dependencies into the executables
Thanks that’s pretty informative
Why isn’t there a way for Linux users to automatically install every missing dependency for a program? Not sure if this will net me a ban here but the W*ndows way kind of looks superior here. Having old programs break with updates is a massive pain.
isn’t there a way for Linux users to automatically install every missing dependency for a program?
Great question! There is. What you’re describing is a package manager. Overall, they are a great idea. It means devs can create smaller “dynamically linked” executables that rely on libraries installed by the package manager. The w*ndows equivalent of this is using DLL’s. Another advantage is that urgent security updates can be propagated much faster, since you don’t have to wait for each app that uses a vulnerable library to update it on their own. Also, dynamically linked executables can help save on ram usage. With statically linked executables, everyone brings their own versions of some library, all off them off by a few minor revisions (which all have to be loaded into ram separately), whereas a bunch of dynamically linked executables can all pointed to the same version (only needs to be loaded once), which is what package maintainers often do. Finally, package managers eradicate the need for apps to include their own auto-updaters, which benefits both developers and users.
This model goes wrong when software depends on an outdated library. Even if the package maintainers still provide support for that outdated version, often it’s difficult to install two wildly different versions of a library at the same time. And apart from libraries, there are other things that a program can depend on, such as executables and daemons (aka background processes aka services), old versions of which are often even more difficult to get running along with their modern counterparts.
So when you say that the “W*ndows way kind of looks superior here”, you are right about the specific edge case of running legacy apps. It just happens that the Linux crowd has historically decided that the other benefits of package managers outweigh this disadvantage.
There are tools for developers to bundle dependencies. Statically linked binaries, “portable” apps, AppImage, and so on… It’s just that package managers are so widespread (because of the aforementioned benefits), few developers bother with these. The general attitude is “if you want a statically linked executable, go compile it yourself”. And by the time it’s time to make an “archiveable” version of an app because it’s abandoned… nobody bothers, because it’s, well, abandoned.
However, as disk capacity and ram size steadily increase, people are starting to question whether the benefits of traditional package managers really outweigh the added maintenance cost. This, combined with the recent development of a linux kernel feature called “namespaces”, has spawned various new containerization tools. The ones I am familiar with are Docker (more suited for developer tools and web services), and Flatpak (more suitable for end-user desktop apps). I personally use both (flatpak as a user, and docker as both a user and a developer), and it makes my life a whole lot easier.
As for what makes it easier for users to get old apps working (which is what you’re asking), well… that’s sort of what we are discussing in this thread. Again, these tools aren’t very widespread, because there is rarely a practical reason for running legacy programs, other than archivism or nostalgia. More often than not, modern and maintained alternatives are available. And when their is a practical reason, it is often in the context of development tools, where the user is probably skilled enough to just Dockerize the legacy program themselves (I did this a couple times at a job I used to have).
I’m just getting started with nix, if I’m understanding it correctly I think that is kind of what nix package manager does? It keeps packages and their versions separate and doesn’t delete them, so that you can update some programs and their dependencies without breaking other programs that depend on other versions of those same dependencies. linux.com/…/nix-fixes-dependency-hell-all-linux-d…
Yep, that’s the gist. Nix build is reasonably good at spitting out what’s missing ( if your packaging a random git ) and nix-init gives you a great starting point, but generally will need some tweaking to get the package running / installing.
Why isn’t there a way for Linux users to automatically install every missing dependency for a program?
There is; actually there are several. Every^* distribution has a package manager, that’s what it does. But you have to make a package for the program, similar to what the tegaki folks have done for Mac and Windows.
Another option is to statically link everything.
One issue is the fragmentation; because there are so many Linux distributions, it’s hard to support packages for all of them. This is one thing that flatpack aims to solve.
I would expect this to be an issue for old closed-source software, but not for old free software. Usually there’s someone to maintain packages for it.
Some cursory searching shows no tegaki package on flathub or in nix (either of these can be used on any distro; the nix one is surprising to me; it hosts soooo many packages).
There’s pros and cons. On one hand, packing your dependencies into your executable leads to never having to worry about broken dependencies, but also leads you into other problems. What happens when a dependency has a security update? Now you need an updated executable for every executable that has that bundled dependency. What if the developer has stopped maintaining it and the code is closed source? Well, you are out of luck. You either have the vulnerability or you stop using the program. Additionally bundling dependencies can drastically increase executable size. This is partially why C programs are so small, because they can rely on glibc when not all languages have such a core ubiquitous library.
As an aside, if you do prefer the bundled dependency approach, it is actually available on Linux. For example, you can use appimages, which are very similar to a portable exe file on windows. Of course, you may run afoul of the previously mentioned issues, but it may be an option depending on what was released.
Do you happen to know what (if any?) technical advantages appimage has over “portable” applications (i.e. when the app is distributed as a zipped directory containing the executable, libraries, and all other resources)"? As far as I understand, appimage creates an overlay filesystem that replaces/adds your system libraries with the libraries that the packaged app needs? But why would that be necessary if you can just put them in a folder along with the executable and override LD_LIBRARY_PATH?
You can Linux with your frineds, with your coworkers, with your gf/wife/mistress… just about anyone that knows what a gagball and a buttplug is, but would like to take that experience to another level.
Perfect response as always. Thank you. Hearing about my friend’s job having some difficulties where there was some update on a Linux based device at stores and it’s causing all sorts of issues at the stores. I’m sure he would agree with your statement right now.
Meeh…shit happens, I know what it’s like as well 🤷. To the best of luck to your friend, may he troubleshoot without distractions… or some, from time to time, just to clear his head 😉.
LUKS doesn’t protect you from an evil maid attack. It hides your data when your stuff gets stolen in a powered off state, but it provides neither verification of data, nor does it provide verified/secure/safe boot.
In simple terms: the very first thing which gets loaded needs to be unencrypted (barring some exceptions I will omit here), which can get replaced with an evil version by the evil maid.
Is it even possible to mitigate such an issue? Will resetting the bios by removing the cmos battery not also disable password protection in the bios thus making it possible to disable secure boot?
And at that point could they not just use a hardware keylogger or something?
Yes, with a TPM. A TPM (2.0) can seal secrets and only release it when a machine fulfills certain configuration and state requirements (saved into registers called PCRs).
For example: make the decryption key one part dependant on a passphrase you memorized (to not only rely on a TPM), and one part on something saved in a TPM. If you select the correct PCRs when saving the latter, and your TPM works as advertised (and doesn’t offer an easy way to eavesdrop/fool it), removing the battery would make the TPM not release the secret (if removing the battery even still works on modern machines).
However, this depends on having a unified kernel image, having configured dm-verity and maybe more stuff I don’t recall right now. Probably should also make sure you don’t allow Microsoft’s Secure Boot keys and instead only your own. I hope this will get easier in the future, but I know SystemD is actively developing useful tools for that (e.g. ukify).
That all doesn’t mean the critique of TPMs (intransparent, proprietary) is invalid. Maybe we’ll have OpenTitan based TPMs at some point?
See but I’m talking about burning an install CD for Puppy and having it just straight not work and the solution being “just burn another one” like CDs were cheap for a 13 year old.
I don’t recommend it, the more boots you use the heavier your computer will be. I’ve got mine down to half a boot and I’m working on getting it down to a quarter.
I just did this yesterday! I’ve worked with Linux/Unix for a long time, but I’ve never had a Linux machine at home. We had an ancient cheap chromebook and I turned it into a functional Linux laptop! I used GalliumOS though, which isn’t being actively developed any longer, so I might have to change setups eventually.
I really think chromebooks have a decent future in the linux community. Especially with them being cheap. I use mabox linux, its a manjaro +openbox distro with tons of customization options. Its way way cool. If you are more into debian you should check out bunson labs ! https://www.bunsenlabs.org/https://maboxlinux.org/
In didn’t plan to distro hop on the chrome book, but having something actively maintained that’s a nice’d up Debian would be sweet.
What have you done to me?!?!?
Are these distros good at supporting various old chrome book hardware? Hell maybe even something like Mint would work, but I should probably stick with the lightweight ones.
Mabox has an option at setup for Chromebook keyboards but i find binding from a regular keyboard less of a pain. My one real issue was the sound card, but SOF ( sound open firmware) fixed it immediately.
Mint is basically perfect, i just wish their xfce edition was based on Debian And not ubuntu. Mint + debian = the tops. Another one to consider is Sparky Linux. I heard good stuff about it. https://sparkylinux.org/
linuxmemes
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.