That's not what I'm saying.
I'm saying you need to trust the people making your OS cause no way in hell is anyone else able to audit every update they push.
Whether your OS is trustworthy depends on their history. In that regard, I'd give Ubuntu a solid B-
superkret
joined 4 months ago
Yes, they're taking the source code from upstream, modifying ("patching") it, compiling it, then uploading their compiled binaries to the Ubuntu repo where your system downloads them during an update.
You can technically download the source code as well, if you activate the source repo. But hardly any end user does. And the source code you get doesn't compile to the same binary you get from the repo anyway. (This would be called a "reproducible build". Some distros try to be reproducible. Ubuntu doesn't, they have other priorities.)
You trust their repos.
With every apt update, they could push whatever code they want onto your PC.
Same as with literally any binary-based OS.
So can Canonical. The difference is, they don't.
I think I was pretty clear with what I was asking in this thread:
"Is anyone here using an enterprise Linux distro?"
Can I assume you're not actually running an enterprise distro?
I mean, me neither, yet, but:
- Both SUSE and Red Hat have had a minor release this year, with their software being less out of date than Debian
- I feel like enterprise distros seem to be very different in the areas where differences between distros actually matter: Package management (which can be fine-tuned a lot more with application streams, security updates, package modules, etc.) and complete, up-to-date documentation (which is the thing most people miss in Linux).
I was really looking for real world experience, not a re-hashing of unvalidated opinions that have been around for >10 years (when they might have actually been true).
Scaling capacity up and down in real time should be Microsoft's core business now.
Why hand out bug fixes for free when you can charge full price once more instead?
From the point of view of a customer, the exact failure method is irrelevant.
Microsoft took a lot of money and wasn't able to deliver what was promised in exchange.
When your game is a streaming service, you better put some cloud experts on the dev team.
41
[Solved] [Slackware] What's the best way to hide the preinstalled software you don't need from the KDE menu?
(feddit.org)
shared from: https://feddit.org/post/1848262
I like the Slackware approach of installing the kitchen sink by default. Disk space is cheap.
But I find that the cluttering of the menus in KDE is a bit annoying. I use search to start my applications, and a lot of the time I have to type almost the full program name to get to the app I actually use.
What's the easiest way to hide a large number of programs from the menus, which is also easily reversible?My first idea was renaming the .desktop files in /usr/share/applications to .hidden
But they seem to be recreated automatically.Another idea was to copy .desktop files from /usr/share/applications to ~/.local/share/applications and then do:
printf "\nHidden=True" | tee -a ~/.local/share/applications/*.desktopBut I tried to add this manually with one test file and it didn't seem to have any effect.
Is there a config file somewhere that specifies in which paths .desktop files are parsed?Or is there a better way?
Thanks a lot, and happy slacking!
[Solved] Slackware comes with kmenuedit which can be accessed by right-clicking the app menu.
Blog post alert
Let me start off by saying: If you just want to have a working system to do your thing with minimal effort, Slackware isn't for you (anymore).
Running Slackware today is like being gifted a Ford Model T by a weird, bearded museum curator, and then finding out that after some minor modifications and learning how to drive it, you can keep up with any modern car on the road. Only it has no ABS, AC, power steering, starter motor, crumple zones, airbags or seatbelts.
Most people who still run it (by any realistic estimate, fewer than 10000 people in the world now) have been running it since the 90's and follow the advice not to change a running system to the letter. So why should anyone who hasn't studied CompSci in Berkeley in the 90's try it today?
First of all, the most widely known criticism (it has no dependency resolution) is a bit of a misunderstanding. Slackware is different. The recommended installation method is a full installation, which means you install everything in the repository up front. That way, all dependencies are already resolved. And you have a system you can use equally well on a desktop or server. It uses 20GB but disk space is essentially free now.
What if you need something that isn't in the repo? Well, do whatever the fuck you want. Use Slackbuilds, which aren't officially supported but endorsed by Slackware's dev. Use Sbopkg, a helper script with dependency resolution very much like Arch's AUR helpers. Use the repos of sister distros like SalixOS that include dependency resolution. Install RPM packages. Install Flatpaks. Unpack tarballs wherever you want them. Go the old school way of compiling from source and administering your own system yourself. Slackware doesn't get in the way of whatever you want to do, cause there's nothing there to get in the way.
It's the most KISS distro that exists. It's the most stable one, too. Any distro-specific knowledge you acquire will stay valid for decades cause the distro hardly ever changes. It's also the closest to "Vanilla Linux" you can get. Cause there really isn't anything there except for patched, stable upstream software and a couple of bash scripts.
Just be mindful of the fact that Slackware is different (because the Linux ecosystem as a whole has moved on from its roots).
One example:
Up-to-date Slackware documentation isn't on Google, it's in text files written by the guy who maintained the distro for 31 years, which come preinstalled with your system. Or on linuxquestions.org, where the same guy posts, asks for input from users, and answers questions regularly.
It's still a competent system, if you have the time and inclination to make it work. And it's a blast from the past, where computing was about collaborating with like-minded freaks on a personal level. And I love that.
view more: next ›
Obviously, yes. My point is: Do you read and understand all changes in the code for each update? You need to trust the maintainers, cause they could theoretically push out any code with the update.