I unpack them because the app runs faster, no container/fs problems, and I use apps where I want to access the files in the app. Kicad in particular has a load of component files that I always want to copy from /usr/lib into each project so that the project is fully self contained and in a nicer way than the way kicad does it itself.
freecad has a problem where it uses python, and python3 defaults to shitting turds (pycache directories) everywhere it's executed. There is a way to tell python not to do that, but that mechanism is not possible when the app is an appimage. But is possible if the appimage is unpacked.
It's a simple, but totally manual process to unpack and integrate into the desktop fully so that file types autolaunch the app and displays the icon in the file manager. I started to write a script to automate it but there is just enough variation in the way appimages are constructed that it's annoying to try to script even though it's pretty easy to do manually.
People joke about "safety third" but I've always thought that was literally about right. It's a higher priority than many other considerations, but it's no way the highest priority. Doing or having something at all absolutely comes before having it in safety and comfort.
All fun and games til you realize you lose more servicemen & women to mishaps than you do to enemy combatants. Which is a factual reality the military has to deal with. Safety isn't a joke, and no, your safety officer isn't going to be getting on your ass with the Hun at the gates, but after a certain point, you have to temper get-there-itis unless you want to hemorrhage manpower to mishap related casualties.
Why not just use gcc which already exists everywhere?
When you answer that, same answer. If you can't imagine any answer for that, then the answer won't be convincing or make sense even if anyone tried to articulate it. Which is fine. Everyone doesn't have to find meaning in the same things.
Shell without a userland is like FORTH without the ability to define new words. It's really contrary to the whole idea of what a shell is. Bootstrapping in very constrained conditions makes some sense, but where would you have a POSIX shell and not a POSIX userland (or close equivalent) to work with? When I wrote a similar compiler in shell, I purposely offloaded everything I could to external tools and used the shell for composition, so I found the approach intriguing and wanted to ask. I wasn't trying to criticize or dismiss the project, I think it's really cool or else I wouldn't have bothered to read the code in the first place.
gcc exists essentially everywhere a shell exists too. If you're ok with using grep and bc or whatever, then why not gcc?
Or better yet, awk? awk is as old and ubiquitous as sh itself, on every machine even ancient ones that don't even have a compiler because that was a paid extra. Only unlike sh it's actually a full normal programming language that can do basically everything the shell can do only in a far more readable and sane way instead of using wierd expansions and abusing the command line parser to achieve functions it doesn't have overt functions for. Just write directly in awk the same way you would in say python or js. If you have sh, especially if you also have the userland you are talking about, then you have awk. It's part of that userland in a way that gcc is admittedly not.
More in your vein actually, when I do things like this I pick yet a different ideal goal than either you or the author. I avoid all externals (and even child shells) to whatever extent possible, but I do use bash for all its' worth. Every possible intentional or hack bashism. Require bash, but leverage bash to within an inch of it's life and require nothing else.
But this project tageting more portable code that doesn't require bash is really cool and valuable. Even though it's not a standard I personally shoot for even when I am specifically shell-golfing.
There are probably as many different points along the spectrum to draw the line as there are individual developers, each with some actually reasonbable argument to justify that particular place to draw the line.
To me using grep and sed and tr and ls and cat etc etc when I don't need them is just unsatisfying, inelegant, uninteresting.
If you are in bash or ksh93 or zsh, you don't need all kinds of things like basename, dirname, cut, tr, wc, nor some of the more powerful stuff either most of the time. I have a shell function that uses the built-in read combined with a named pipe file created in tmp to make a sleep that doesn't need /bin/sleep. Why bother? because it's awesome. And usually the only times I need to use sleep it's in some rapid short duration polling loop that really is better if you don't have to fork & exec & teardown on every iteration. It's bad enough to be polling like that in the first place. And it just doesn't matter how "probably all the externals will be there", not using them is even better. And these days a lot of once-common "userland" is no longer common or installed by default. A script that never tries to run dos2unix never cares that it's not installed, or that the bsd version behaves differently, or the mac version is stupid old, etc.
"This problem has already been solved in Canada. Just move to Canada."
Make is generic. Nix is not.
Before I even look at the actual code I already know that it is something I can use immediately on my existing system, no matter what that happens to be, right now, without changing anything else.
It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Even if you're only talking about nix the package manager, or nix the language, and not nix the os, it actually still applies because Make is everywhere and nix is not.
Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
>Make is generic. Nix is not. Before I even look at the actual code I already know that it is something I can use immediately on my existing system.
Hard disagree on this one. It's a series of makefiles that depend on apt (or whatever pacman you choose), so for any heterogeneous environment it's going to constantly be uphill battle to keep working in terms of package naming, existence of dependencies, etc. You'd find yourself reinventing Ansible, but worse.
> It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Nix runs fine on most (all?) modern Linux distros, macOS, even WSL, and there are workarounds to make it run on BSD, though I admittedly haven't tested those.
> Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
Use it on Xenix (which last shipped in 1991) to do what? The package management was tarballs and compiling. Instead of reinventing Ansible, you'd be reinventing pkgsrc. Not sure what your point here is.
And in normal use, how often do you handle or cycle an rj45 vs a usb?
Even when it's your job the usb are still handled and cycled way more often. You might handle 100 ethernet jacks today, but it won't be the same one 100 times. You plug it in and don't touch that one again for 5 years.
You mean the ethernet cable in my laptop? Couple of times a day. The box under my desk? Often? How about the hundreds of devices I work with that have RJ45 connectors for serial access? All the time? Are you seriously telling me you hold up a (decently made) ethernet cable next to a USB-C connector and think "yeah...the one a fraction of the size of the other is obviously mechanically stronger". Is this some Apple shill campaign to try and get people to think "no, no...the smaller, thinner, narrower and shallower the connector is the better it will be someplace where people bump it all the time"?
No, but looking at the two side by side, I do think that the one with a fragile clip that shears off every time somebody trips on it is going to be more of a problem than the friction fit one that will just come off.
As opposed to the one that has no clip to hold it in, and shears off the whole connector when you trip over it. And I can use the ethernet cable without the tab.
Some people will embrace any absurdity to pretend to be right.
In your world, then, is it normal to complain about other people's names, and expect them to change what they call themselves to better suit your preference?
But the whole hemisphere is not "Mexico". USA and Canada are not also "North Mexico". Their harmless little reminder is more correct than any of the attempted arguments against it.
It was the first group of united states on the continent. North America was, relative to the land that became Mexico, thinly peopled. Unlike in Mexico there was no pre-colonial, indigenous empire that had ruled and named the land which eventually became the 13 colonies. So there wasn't necessarily a better alternative to put after "United States of" at the time. Do you know of one?
>Unlike in Mexico there was no pre-colonial, indigenous empire that had ruled and named the land which eventually became the 13 colonies.
Actually, there were multiple indigenous political entities both along the Eastern Seaboard (where we find those 13 colonies) as well as across what is now the US and Canada[0].
We just took their land and killed most of them, but they were still pretty organized -- with political groupings of various types.
Of course colonists committed genocide against indigenous people everywhere they went. No one's denying that. I'm addressing precisely what you yourself said
> there were multiple indigenous political entities both along the Eastern Seaboard
They were fragmented and smaller than the Aztec empire. That doesn't make it right to take their land. It does explain why their names didn't apply to the entire land. Because none of them was so big and centralized. If you look at the geographical features of the Eastern seaboard - mountains, lakes, streams, rivers, cities and towns, even 2 states (Massachusetts, Connecticut) - native names abound.
The lands that became the US and Canada really did have fewer people living on them than the lands that became Mexico. [1] Again because Mexico had centralized states and large-scale agriculture capable of supporting large populations.
What about Iran? Iran was conquered by muslims. So should we conquer it and kick muslims out because it wasn't ok to take that land? What about every muslim country? Muslims stole mecca from the Jews, as is extensively detailed in muslim history books. Should it be conquered and returned?
What about China? The kingdoms did most of the conquering of course, then "unification" took their land and then communists did ethnic cleansing until Han Chinese were in most places all that's left. Hell, a number of the people they cleansed aren't even gone yet. There are still Tibetans. There are plenty of original Hong Kong'ers still alive.
What about Russia? What about North Africa? What about ...
Given that they were quoting themselves, I think it's probably intended as humor. (I had to scroll up to check but I immediately suspected, and it made me chuckle)
Not just bouyancy but friction. An off-center mass moving through anything but vacuum is a dart with fins.
Or is bouyancy just used as a shorthand term for the effect of fins? Because literal bouyancy would also be a thing here. But the literal bouyancy points away from the center of the Earth while the friction points away from the direction of travel.
freecad has a problem where it uses python, and python3 defaults to shitting turds (pycache directories) everywhere it's executed. There is a way to tell python not to do that, but that mechanism is not possible when the app is an appimage. But is possible if the appimage is unpacked.
It's a simple, but totally manual process to unpack and integrate into the desktop fully so that file types autolaunch the app and displays the icon in the file manager. I started to write a script to automate it but there is just enough variation in the way appimages are constructed that it's annoying to try to script even though it's pretty easy to do manually.
reply