Reading the announcement, this won’t be changed. Steam on Arch is still not supported.
Reading the announcement, this won’t be changed. Steam on Arch is still not supported.
How about something e2ee? (Even Whatsapp is more privat than telegram)
The channel owner directly states that it is their intention to mislead. I did see the disclaimer on the channel after looking up the “artist” and before making this post, but that disclaimer is not visible on the thumbnail preview and the video description omits any reference to it. The inclusion of the year in the video title as well as the hashtags all attempt to work their way into the feeds of those not in the know to convince them that it is legitimate.
I agree in that regard.
I mean, yes it is garage, but:
Yes, it is still bad.
I’ll believe it, when I ordered one for $1.
Do you have a minute for our lord and savoir TypeScript?
A baby step in the right direction.
Relevant commitstrip: https://www.commitstrip.com/en/2019/02/25/pythonscript/
While you are basically right, the problem is that there is an operator that should not exist. Though that is not the biggest problem of JavaScript.
Todays ThinPads are not superior. Some things are:
flatpak install "$1"
snap install "$1"
appimage-cli-tool install "$1"
))))))))))))))))))))))))))))))))))))))))))))))
that saves each audio project as an SQLite database 😳
Is this a problem? I thought this would be a normal use case for SQLite.
I think flatpak could perfectly fine for installing cli applications even though it is designed for desktop applications.
Shoving CLIs into flatpaks could be a thing but that wouldn’t really solve a problem, it would just mean adding one more ocean to boil and someone would have to volunteer to package htop for the 30th time.
Flatpak is distribution independent, which means, it could be actually reduce repackaging.
flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it’s just a specific implementation designed for desktop apps, and it has things like portals and stuff that’s specific for gui apps.
While that is true, I don’t see, why this is a problem for CLI applications to be installed and run via flatpaks.
Direct package management in your home dir - also an option, you can just install homebrew, nix, or tea or whatever install packages in your home directory and then it’s totally decoupled from the system.
Can you explain, why this works better, than flatpaks? I mean it does not matter what flatpaks were intended for originally, if they do the job just fine.
So for example, if you use silverblue, you use htop, but it wouldn’t make sense as a flatpak when there’s a full fedora installation delivered via a container already on your desktop, you’d just dnf install htop and move on.
I found this approach lacking, because:
dnf install foo
in a bashscript. Controlling a container via bash is not that easy (or, I don’t know how it works)I use silverblue myself, but I think “cloud nativ” is a terrible name. “Immutable” is IMO better.
Also installing cli tools via toolbox/distrobox is not ideal. I hope for a better solution. Maybe someday i can install htop via flathub.
This is cool, but if Microsoft would <3 Linux, they would do this themself.
If its true it is a big “achivement”, but it still did not broke RSA.