If your bash script gets longer than 200 lines (including argument handling), use Python. I have to support bash APPLICATIONS at work and it’s a fucking nightmare to maintain.
I would then assume those scripts weren’t written properly to begin with.
But yes, shell scripts should be used (normally) to automate some simple tasks (file copying, backups…) or as an wrapper to exec some other program. I’ve written several shell scripts to automate things on my personal machines.
However shell script can be complex program while at the same time being (somewhat) easy to maintain:
functions, use functions, alot
comment every function and describe what it expects in stdin or as an arguments
also comment what it outputs or sets
This way at least I don’t break my scripts, when I need to modify a function or some way extend my scripts. Keeping the UNIX philosophy inside shell scripts: let one function do one thing well.
And of course: YMMV. People have wastly different coding standards when it comes to personal little(?) projects.
There are many reasons Microsoft software is only “good” (and I’m using that word loosely) in business and home settings. Can you imagine a rocket taking off and windows suddenly “rebooting to complete updates” (or whatever it is that it says along those lines)?
I had an issue where one keyboard (worked with another one) worked in bootloader, but not when entering the encryption password after that. I believe I solved that by moving keyboard earlier in the module list in mkinitcpio.conf. Maybe something similar would solve your issue?
These specs actually seem really solid for the price point, I’m glad to see decent alternative smartphones popping up that actually have some power.
What’s bugging me is the lack of information about the software. Apparently this is Android with a layer like Hallium to run a Debian userspace on top? And yet they don’t advertise that fact. It’s just a little off putting that this product seems to be aimed at Linux/general tech enthusiasts, yet the company seemed to miss the fact that those customers tend to really like knowing what they’re running under the hood.
How is it relying on XWayland? I don’t know of any KDE Plasma components that require X11. The apps you install might need XWayland but that is separate from the Plasma desktop.
Uninstalling Xwayland breaks it, you’re greeted to a black background and your mouse pointer.
Additionally, as per their own website, it says “The workspaces have been developed for X11 and much functionality relies on X11. To be able to make proper use of Wayland these bits have to be rewritten.”
Oficial repositories, unoficial repositories, flatpak, snap… What happened to just donwload the app from it’s own creator and install on your machine? Why do we need every app being touched by some rando before I can install it on my box?
Your wanted option is not gone, you can still download the binaries if the author presents them; or you can compile it from source. This is just another, more convenient way to distribute the program.
If you are looking to get your programs Windows-style, to download a binary or “install wizard”, then you can look into appimages.
Like any form of distribution however: someone has to offer this, be it the author or “some rando”.
If you mean downloading random stuff from random websites, yes.
But they dont have installers, so no verification, no moving to locations where executing is allowed (on Linux the entire home is executable which is a huge security issue) no desktop integration, no context menu, no file associations.
A matter of perspective I think. It’s a flaw in my opinion. Just downloading anything from anywhere sets one up for failure/malware.
Code Signing on its own is useless, I think. If there is no distribution structure or user-validated trustchain, of course. But then you don’t really need Code Signing, a simple hash is enough.
My personal preference are the distro repos, to a point where I even dislike additional package managers like pip, npm or cargo.
Just downloading anything from anywhere sets one up for failure/malware.
Reducing the size of the OS helps a ton here.
And mounting home read-only. I think Android and ChromeOS do that. I will experiment with that too, it is really interesting. You mainly need a different place to store user scripts, and appimages are broken (how sad), the rest should be fine.
Then a few more core concepts help too:
KISS (keep it stupid simple)
Unix philosophy (everything does one thing and stays transparent)
and the concept of least privilege (seccomp, MAC (mandatory access control, SELinux/Apparmor, sandboxes, jails, etc).
Flatpak helps a ton centralizing the packaging efforts. And it works. There are tons of officially supported packages. And I guess many of them will be maintained upstream.
But you still have a secure system, sandboxing, verification and packagers that keep an eye on it, kind of.
On a secure system you would need to pay a lot of people, like the typical 3-5 people that package most apps. For doing security analyses, opting-in to every new update etc.
I’m sorry, I don’t think I can see the point you are making. Are you saying that one can get around the 3-5 people by using flatpaks, ro home directories and other mitigations?
You still have to give the exec permission to the appimage.
True, but this only prevents against stuff executing itself.
Mandatory access controls and sandboxes only protect the core system. Like installing packages with root.
You put things there privileged, so you know what you run comes from a protected area.
Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.
Suddenly you rely on an executable home dir, which means any regular software (including appimages which are nearly impossible to sandbox) can write to the area where your programs are.
That concept is so broken that it needs to go.
I am against flatpak install --user for that reason, because no program should come from an unprivileged directory.
The issue especially is if it doesnt follow standards. ~/.local/bin is a standard, and with SELinux confined users you may be able to protect that directory. But random ones like ~/Applications that dont follow any standards, will not work.
Maybe no context menu depending on what you mean exactly
The “open with” and “create new” things. Actually,
Flatpaks cannot create “create new” entries too. I am currently experimenting with these, as it sucks to not be able to “create new Libreoffice writer document”. And the xdg-templates directory doesnt do anything lol, you still need desktop entries.
but the rest are fully possible and I do it on a regular basics
The concept of an installer is that the app does that on its own. That is pretty bad and the kind of Windows crap we absolutely dont want.
But on good operating systems, a privileged package manager does all that. Puts the stuff where it belongs. Flatpak for example links the desktop entry that the app itself contains in a sandboxed directory, to the export directory where the OS sees it.
And some portal or whatever deals with the “standard apps” stuff, like that Okular Flatpak will be shown to support opening PDFs.
If apps do this on their own that means a single app can mess up your entire system, also malicious.
Appimage may have tools, I only tried AppimagePool for curiosity and the experience was pretty bad and incomplete.
But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.
And only afterwards came the managers, the daemons, which cover a part of it.
They (could) solve:
being privileged, placing apps in not user-writable directories
having access to integration locations, that apps should never touch
downloading from defined, maintained locations (instead of letting people click on random internet malware ads)
running in the background, notifying about updates
centrally managing these updates
verifying signatures before allowing updates
doing the actual update process (instead of deleting a file and placing a new one)
And they often dont even do that. There are no signatures, as devs were never told “either you add a signature, or people will not install your app”. So there is zero verification
But they dont solve the core issues that are:
devs were told they dont need to care about…
creating metadata
creating a real repository
signing their apps
using a standardized build system
transparently declaring used dependencies (i.e. using a given set of them), thus deduplicating them
declaring opt-in permissions, so users know if the app is insecure (appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)
Flatpak is similar to Android. On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.
And using Obtainium, which is kind of like an AppimagePool, you can get all the apps from independend developers.
But they were told they need to follow all these rules, Appimage developers can do whatever they want.
It isn’t perfect though, right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage. But dbus, pipewire, vulkan, themes, etc works.
The “open with” and “create new” things. Actually,
You can totally do that with appimages once they are integrated into the system by the previously mentioned tools, those menus rely on desktop entries in $XDG_DATA_HOME/Applications.
That concept is so broken that it needs to go.
Good thing we have choices on linux, you can make your entire home not executable if you want to.
I like to keep all the software that I need in my home, because that way I don’t depend on what my distro provides. I can just drop my home anywhere (besides a musl distro) and I’m ready to go, I even have my window manager as an appimagebecause I couldn’t compile it statically.
But the issue is that they were just thrown out there, “here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, …”.
AppImage is just a format, same as a deb or rpm, you decide how you handle it afterwards.
doing the actual update process (instead of deleting a file and placing a new one)
On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.
You mean the APK itself does the signature verification or what? With appimage it is AppImageUpdateTool that does the verification.
(appimages are impossible to sandbox with bubblewrap, and hard with firejail (which is a setuid binary and had security issues), dont know about nsjail, crabjail, minijail or others)
You still have that github repo saying that appimages bloat the system when that is a total lie. they can even use less storage than native packages let alone comparing it to flatpak…
~/Applications is no a random place, it comes from macos.
Hahaha I would call that VERY random. It is problematic that the default xdg directories are hidden.
And I just learned that you can just source scripts into bash and thus being executable or not doesnt matter. What an incredible design flaw… at least this just works with some binaries, I guess?
You mean appimagetool
No the Flatpak Appimage Pool. But a solution to easily package a bunch of files sounds really awesome. I miss that for RPMs, sddm2rpm did this kind of.
appman
Very interesting tool. So this is for appimages but also binaries?
I am a bit confused, especially as they state to prefer official releases, which for me means tarballs.
But a very good concept.
Interesting set of apps you have there. And ironically I have to agree they are small. Flatpak libraries are too huge and the deduplication doesnt work if it us not used for downloads and if there are dozens of runtimes.
A modular approach would be very much needed, instead of a damn KDE runtime that is nearly the entire desktop.
But I have some questions.
Yes that’s aisap sandbox
Thats not a sandbox, its a nice wrapper for firejail, at least what they write. I only knew some Github issue where they discussed this, and because Appimages require fuse they couldnt be sandboxed with bubblewrap.
Then they say “bubblewrap is used in Flatpak” but no comment if THEY also use it.
Firejail is the setuid binary I talked about, they likely have fixed their security issues but bubblewrap/bubblejail are probably better as they dont need setuid binaries.
If Appimages are possible to sandbox with bubblewrap, that would for sure be cool.
I also found rustysnakes crabjail, dont know the state it is in, but that is a possible candidate for replacing bubblejail.
right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage.
No idea if Flatpaks can do that. But I would say the biggest issue is that the big vendors just put their appimage on some file server without any data on the sandbox.
Flatpak is way better here, where the sandbox is checked BEFORE apps are successfully submitted. And there are warnings etc.
And, of course, every app is sandboxed, not just a few.
those menus rely on desktop entries in $XDG_DATA_HOME/Applications.
Not the “create new” to my knowledge. That is in $XDG_TEMPLATES_DIR but I am currently struggling to make Flatpaks use that.
AppImage is just a format, same as a deb or rpm
Yes, so is Flatpak. But Appimages were introduced to be Windows-like. Sure there are companies that dont care and publish random rpms on their website too.
But with Appimages that is the only way as there is no real repo. AppMan is a cludge here, bundling together tons of different sources, kind of like Obtainium.
That tool is either completely finished or kind of abandoned.
Interesting, didnt know they have a signature builtin. That would also be useful.
That zsync2 thing explained in AppMan was just like delta updates. If a malicious actor has access to the old appimage and the fileserver, they can produce the correct zsync2 thing and the updates work, until signature verification is enforced.
I like to keep all the software that I need in my home, because that way I don’t depend on what my distro provides.
As I said, as long as bash script.sh works with nonexecutable stuff, noexec home is pretty worthless. Just another layer of defence.
You mean the APK itself does the signature verification or what?
No, android APKs are like Distro packages, they can be sideloaded however you want and then are forwarded to the “session installer” (on modern android), which is the “package manager” of android.
That installer saves the signature somewhere, and from then on you can only update the APK if the signature was made with the same private key.
Found out you can also not sign APKs, which happened here. I honestly dont know if more developers dont sign their APKs.
I will update my repo text to get to the current state of facts.
Appimagelauncher, gearlever, AM, etc. Which is the same as a install wizard since it integrates the appimage into the system. AppImages do not need to be extracted into the system which is what windows install wizards do.
Appimages came before these tools, and the tools (forgot the name GearLever, AppimagePool is another one) came afterwards.
They are structurally better as they are external.
That verification is interesting. So it is another appimage, used to verify appimages? Are all Appimages using that, if not what percentage of the ones you know? And are tools like Gearlever enforcing or using that signature check?
Are all Appimages using that, if not what percentage of the ones you know?
Usually if the appimage has a github release with a zsync you have that verification.
And are tools like Gearlever enforcing or using that signature check?
I don’t use gearlever, as far as I know gearlever doesn’t even let you sandbox the appimage like AM does. I don’t think any of those forces signature verification besides AppImageUpdateTool and that’s because that’s part of the zsync update process.
Interesting, will look into this. The issue is of course that these tools are optional.
But if they work, they may fix nearly many issues. Some will remain, for example many proprietary apps dont use Github releases, while these may be especially targets of fakes.
Probably because Windows is best suited for games and cookie-cutter corporate applications while basically every supercomputer, cluster, etc. runs Linux. Professors aren’t usually running games or cookie-cutter business software so why not? If your one-off, experimental research code is going to ultimately be run on a more powerful system running Linux, why write it on Windows and waste time debugging once you try to run it for real?
Im very interested in an officially supported linux phone, however the fitmware seems not to be upstream(yet?). I hope it will be upstreamed, or else were back to square one with linux mobile hardware support if they stop working on it!
Hong Kong only recently became part of China. I’m sure the protests are fresh in people’s minds still. If anywhere would want private phones it would be HK.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.