Re: An unpopular opinion
Matrix FTW. They also got a hosted offering at element.io if you like that.
23 publicly visible posts • joined 2 Jul 2022
From a security point of view it is interesting. GNU has become quite big in LOC terms and does questionable things (e.g. libc NSS mandating dynamic linking). Although GNU has a reputation of being well implemented. At least 20 years ago, bugginess was drastically smaller than that of Unix competitors. Now many wheel reinventors purport some (very subjective IMHO) "cleanliness". Never liked that term, sounds like the authors have a compulsion to go around the house, always looking for the last dust corn to dust off.
This is _the_ technology we need to connect the data centers in space! It'll solve the problem of the faulty hard disk. 6G will replace the motherboard, you know. The individual parts like processor, disk, RAM etc. will just be dumped out there like a fish placing its eggs and 6G will turn it into a functional computer! When the hard disk fails, it will simply go down and burn up in the atmosphere. Another hard disk from the flock will activate and replace the old one with minimal downtime. For the communication back to earth a highly powered 6G beam will be directed onto Sheffield.
The two extensions are fine for Basic Protection, though if you want to get nifty I recommend Firefox profile builder: https://ffprofile.com/ It recommends uMatrix instead of NoScript, as the former provides more fine grained control, not just over script resources.
Aye, fight and you may die. Run and you’ll live, at least a while. And dying in your beds many years from now, would you be willing to trade all the days from this day to that for one chance, just one chance to come back here and tell our enemies that they may take our lives, but they’ll never take our freedom!
Well alright, beat a dead horse a little more. XMPP is to Matrix what a floppy disk is to a SSD. The base spec did not even include E2E and when the extension was created, it had serious limitations such as a pain in the arse key management (and iirc no E2E group chat). In the end XMPP turned into a ZIP disk, but it'll never be a SSD.
I don't think Stallman and his acolytes were ever in it for the money. Just look at the current homepage video on gnu.org. The main character escapes dungeons full of human eating titans and finds herself in a warm LSD augmented world with her friends and everyones happy thanks to the freedoms granted by the licenses. It seems money making was only ever a necessity for FSF ideologists to survive in the darkest dungeons of cruel capitalist world. When FSF lost a slew of sponsors due to the attack on Stallman, they dug in, Stallman went on a vacation, and a few months later Stallman returned and FSF continued unbent. (One might say it's fine due to them being the moral compass in software world.)
The product is now a former open source product. But for all practical reasons it doesn't matter, because the only limitation is placed on huge corporations, where it's fair and just to extract some of their obscene wealth that is resting to some extent on this free tool. Therefore I say to the whiner on HN: pay up!
I have only seen the screenshots of UKUI, but my immediate reaction was, it sure looks nicely polished and user friendly. It's good to see competitors emerging and challenging the two big desktops (and their offspring). System76 is another horse in the race with their announcement not too long ago (https://www.theregister.com/2021/11/08/system76_developing_new_linux_desktop/).
The closest thing to a Windows .exe file is AppImage. AppImage builder puts your ELF binary and libraries (except those from the exclusion list) into a file system, which gets baked into a big ELF file. Yes, there's very much the same duplication issue, as you suspected. Also no sandbox to help contain the exploit.
Flatpak tries to do better. There are runtimes, archives of common libraries, including the Freedesktop stack. One might say they created the one and true Linux distribution floating above the host distribution, relegating the host distro to a diminished role. Though quite a few developers want it and users don't mind (there are shiny icons in the app store). Still, many apps bundle their libraries and Flatpak devs acknowledge there's a slew of outdated or vulnerable bundled libraries out there. IIRC they are setting up a scanning service.
AppImage has some deep flaws. It maintains a hardcoded list of libraries which are not included in the AppImage. The result is very often a crashing application, because the host does not provide the library or the host version does not match the linked version. AppImages also crash if FUSE is not available. You can tell AppImage to self-extract and avoid FUSE, but it requires an environment variable. Why not just fall back to self extraction instead of crashing? Goddammit.
Flatpak fares far better. Looking at the LingLong docs, it looks very similar to Flatpak API. Maybe it creates the needed competition for Red Hat to polish Flatpaks rough edges.
Snap meanwhile ... is just a half-arsed Flatpak competitor and ought to be scrapped. Snap out of it, Ubuntu!
The article briefly mentions Flatpaks focus on desktop. Would be interesting to see LingLong on the server. It seems to rely on Linux containers for its sandbox, so could certainly tackle Docker (if LL would export OCI container like Flatpak does LL would even be compatible with Docker). I'd also welcome an effort to replace Kubernetes with a revised, less complex component, based on LL capabilities.
> On the other hand lots of servers never have any "logged in users" so there is no chance of extra SW being installed and run unless some other bug in your apps can be exploited by which time you're largely dead anyway.
In a properly laid out zero trust architecture the effect of an exploit can be limited, by employing a rigid process isolation and RBAC least privilege scheme. For the protections to be meaningful you depend on kernel services. Therefore the kernel must be fortified.
The usual process isolation being done is to put the service in its own container, e.g. one HTTP server process processing all requests, privileged and unprivileged. An unprivileged request with the exploit could still gain access to privileged requests. To limit the exploits reach, more HTTP server processes for different privilege levels would be required.
https://mjg59.dreamwidth.org/60248.html
> "Starting in 2022 for Secured-core PCs it is a Microsoft requirement for the 3rd Party Certificate to be disabled by default."
I will NOT get over it! Microsoft can never be trusted, even if some of their moves look a bit benevolent at the beginning.