71–80 of 241 posts
Just need something in the file manager to recognize container images and run them like an app.
I find it interesting in a "Post-Snowden" 2016, that the web page with details about a mechanism to produce fat executables (and links to a demo app) is not protected with SSL. Certificates were cheap before... Now they are free thanks to Let's Encrypt. There's really no excuse for this.
The cost of the certificate is a very small part of the overall cost of a proper SSL/TLS implementation. If you don't want to exclude older browsers, you need a dedicated IP address, or you need a system to manage putting multiple names on one certificate. Let's Encrypt is a great option for multi-SAN certificates, as long as you don't care about Windows XP users. If you have any kind of redundancy, doing perfect for…
What this could and should lead to is this: a separation between system packages and user applications, prefferably with two different managers. What we have now are mostly system package managers, you want them to be stable, secure, having the latest features might not be necessary. But we see more and more often that that distribution channel doesn't work well with applications: you end up with old, buggy, insecure…
That's hardly related to a package manager. You can for example run Debian unstable to get more up-to-date stuff or mix Debian Jessie with backports. Same package manager, different sources.
It would be nice to have a safe consistent experience, a generic user-mode package manager.
Earlier quoted context omitted.
I haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter. Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.
You can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few.
[EDIT - Typos]
This is missing the point. Linux distributions do not lack package management options, they lack stable and sane APIs for developers to work against. No amount of static linking and binary bundles can fix that.
I don't see the lack of stable APIs elsewhere as an actual problem. The biggest problem is that it makes life harder for proprietary software developers - it's pretty much mandatory for them to setup automated CI & release processes if they want their software to actually be usable.
There's a huge upside to not caring about a huge stable userspace API: it's much easier to continue to evolve if you just stop caring about backwards compatibility. And often, backwards compatibility means giving up your future to hold on to your past. The difficulty of getting anything done grows exponentially more complicated, often with few significant tangible benefits.
I used to be interested in this kind of thing but it turns out lxc containers are lightweight and do the isolation thing well so let's use them! Just need something in the file manager to recognize container images and run them like an app.
This "drop this in and run it" seems a lot more promising for that use case. Similar to freezing a python app, I suppose.
Earlier quoted context omitted.
Because users and developers both want to be able to download and use new versions of software at a release cadence that makes sense for that application. The "every application gets the same release cadence no matter what" approach only appeals to people making distros.
This. Distro packaged applications are almost always woefully out of date, because they're frozen before the distro is released, and then you use the stable release of the distro for months or years. But even if distros adopted some kind of half-rolling-release model so applications could be updated quicker, developers either have to manage N different packaging systems (apt, rpm, etc.) or rely on other people to dea…
There's even a way to make an ebuild for nightlies, although you can get build breaks with those.
Earlier quoted context omitted.
> I trust I can count on Debian/Ubuntu/RHEL will ship a new package for every critical CVE promptly, without forcing me to upgrade to the latest upstream version. There was an article just a couple of weeks ago pointing out that distributions frequently don't fix security issues: https://statuscode.ch/2016/02/distribution-packages-consider... No doubt it's better for high-profile applications, but there are far more…
Sure, you're boned if the security flaw is in the custom protocol handler of some random package of which you are one of 37 total users. Typically, however, security code does not reside in such packages. They typically link to popular libraries for e.g. TLS support. Those popular libraries are kept current by reputable distros. You shouldn't be using low-volume packages that implement their own security, anyway.
If distros can't do security maintenance for the software people use, claiming that they shouldn't use that software at all is no kind of an answer.
Earlier quoted context omitted.
Oh? The basics are not that hard. dh_make will do most of the work for you.
The basics may not be that hard, but the multitude of overlapping tools and frameworks that sit on top of them and try to make things easier is seriously confusing and offputting. For instance, there are build tools called dpkg-buildpackage, debuild, git-buildpackage, pbuilder, cowbuilder, and doubtless some others I've forgotten about. Different guides will recommend different ones. Once you've made a package, you e…
If any aspiring hackers are around, I suggest taking a look at Arch and its makepkg/PKGBUILD tools. Pretty much a simple shell script to define a package, and a uniform tool to build it.
1. Downloaded the app, opened Nemo and double clicked on the app. Another Nemo window popped-up and the app didn't start. Opened terminal and checked permission to find that it wasn't executable. The point of the ease-of-use is kind of lost as user would be puzzled and give up.
2. How do I uninstall the app? Is it as simple as deleting the file? What if doing that leaves orphan files (that I don't know about) that double-clicking on the appimage file could have created? The website doesn't mention how to uninstall files?
PS: regarding #2 above, I found that right clicking on the Mint Menu entry for the app shows Uninstall option. Clicking on Uninstall removes the entry from Mint Menu. The .appimage file needs to be deleted manually separately (which kinda makes sense). I just hope it hasn't left orphan files.