What a massive, multi-year effort by one or two individual developers. My utmost respect to this kind of contribution that underpins so much of the software that I use every day
I remember in the early days of Mac OS X when i installed KDE. Was pretty surreal.
Then i spent to much time to try create a DarwinBSD distro with KDE.
I'm very surprised there aren't more KDE appreciation posts on here. It's such a beautifully round piece of software -- customizable, yet reliable and unassuming.
It's exactly what the desktop experience, and software in general, should be: there for you when you need it, without making the entire experience about itself.
I don't have to actively think about my desktop environment when I'm browsing Hacker News on Firefox, or writing code, or listening to music -- it looks back empathetically when a program goes wrong, or when my workflow changes and it needs tweaking, and everything else.
You've made something brilliant, and it's definitely positively contributed to Linux's increase in market share.
I'd love to get an in-depth post-mortem-style experience report from the author on what gave them the most trouble. We regularly invite distribution packagers to give talks at our annual Akademy conference to provide this sort of feedback, I can't imagine an OpenBSD talk submission getting turned down!
Fantastic effort! I have such a love for OpenBSD but unfortunately have a system with an Nvidia 4090 which is of course unsupported. Maybe one day I will see if I can dual boot this on my Intel based Mac which has an AMD GPU.
Love the man pages, love doas (I use it on my main linux machine), love that it has an HTTP server in the main install. But the filesystem is so basic that people recommend a UPS just so your data doesn't get corrupted during a power outage.
I hope OpenBSD gets some corporate love one day, because that's probably the only way you're going to get a modern file system written for it.
I tried using doas but I don't get it. On the one hand there's some inertia with everything on Linux expecting sudo, on the other, the claims about speed, simplicity and simpler configuration rang pretty hollow to me. Especially since I believe doas can't do things like custom logging.
TBH I mainly just like it because the configuration file is a single line. It also never even occured to me for sudo or doas to log anything, so there's that.
Also, I don't have sudo installed at all on my system, and everything seems to work fine with doas. YMMV.
If I recall correctly, the main reason for its existence was due to the recurring security issues with sudo. doas was designed to be a more simple tool with a smaller attack surface.
> What are some pros and cons of using OpenBSD instead of Linux?
Pros: htop only fills half of your terminal, and you know exactly what each process does because you put them there. A few well-written man pages are the complete documentation of the system. The whole thing is run by a handful of shell scripts.
Cons: exactly the same text, but read with a different tone.
Relaxing. Like back when you could attach WireShark to your local network and not see a single damn thing happen for tens of seconds at a time unless you pressed a button somewhere.
... But also when computers wouldn't do anything useful unless you pressed a button. Or a bunch of buttons, more likely.
It really was. Just my own machine's traffic makes it scroll faster than I can read, these days. Every web page and program constantly phoning home up and and including sending real-time mouse cursor locations, mdns, UDP local-network-device-discovery traffic, all kinds of stuff.
Yep I love it. ps -ax gives you like 12 processes and the role of each is obvious and essential. The OS isn't doing anything you didn't ask it to, you can actually understand the OS. Try that on a default Ubuntu install, it's like macOS, just totally and literally out of control.
The way you describe FreeBSD is how I imagine an OS should be. I'm going to make it a goal this year to get a server up and running. Thanks.
-- Rant
Linux gives me more inferiority complex than any other technology I've ever touched.
Sure, something like a database system, or a moderately large code base or framework is complicated, and intimidating, and it might take many years to get a grip on, and understand, let alone master. But Linux? I just don't get it. I've tried for years, read books about it, etc. etc.
But in the end it's voodoo to me, and I'm always left searching for answers to problems, unable to solve them myself. The answers are always just rote step-by-step; do this and copy this command, problem solved. Why? how? nothing makes sense!!!
I always have the sense that somewhere out there is the holy bible of Linux, the missing piece of the puzzle; read this and it will all make sense.
Admittedly I've never compiled a distro. So in some respect I'm guilty of not going into the deep end. I suspect that if I learnt systems programming, and really go into the thick of it... then somewhere I might start to find my feet.
But it's easier to just believe that I'm stupid, and Linux is beyond my ability to comprehend.
Have you tried LFS? You can copy and paste, but you have to read the commands and figure out what they're doing.
This will give you an overall theoretical idea of how things are laid out - but you have to realise that every new version of something, there's some developer somewhere who wants to exercise their creativity and make something really clever and cool (to them), so it probably won't make any sense to you after the upgrade. That's the point you realise you're on the eternal treadmill of trying to keep your system doing what you need it to do, without freezing in the vulnerabilities.
I'd say the Gentoo handbook comes pretty close. You set up everything in the system and all is well explained. Not quite as extreme as LFS but enough to learn and not punish yourself.
Linux is a sprawling metropolis, you have everything and its opposite - a lot of it won't make any sense unless you learn who built what, when, and why; and you can have dirty slums right next to well-designed skyscrapers.
Trying to find meaning in such a thing is fundamentally a fool's errand.
The first point equally applies to Alpine and any system built from Debian minimal install ("built" is too strong a word, all you need to do is `apt install` several packages).
The trick is, figuring out the names of the packages you want. :-\ Experiment, and take notes, I guess.
I had a fun experience playing with `grml-debootstrap', GRML¹ being a command-line-oriented LiveCD built upon Debian. Once you’ve booted up, that app installs a minimal Debian instance on your computer. I haven't tried using the stock Debian `debootstrap' utility.
I meant installing just what you need, like web servers and such. Probably should have written that in the original comment. You need to do that on any other operating system anyway, including any of the BSDs.
If you just need a plain system to drop a statically linked binary onto, Debian minimal install is perfectly usable right out of the box, and (IIRC) ships fewer components than OpenBSD.
It's a legit question, but if you have to ask, then most likely OpenBSD is not for you. I don't say that out of some elitist or gatekeeping motive, rather I think most people who use it have a specific need for it, or feel strongly about the principles behind the OS, which are security first and secure-by-default.
Here's a breakdown of some technical differences between the two, but really if you want to explore alternatives to Linux or even Linux alternatives I highly recommend you do so, even OpenBSD, but I respectfully suggest you have a use case in mind first.
The security first/secure-by-default mindset in OpenBSD means the core distribution is very locked down. By that I mean there's very little in the base OS in terms of services. OpenBSD had a robust "ports" selection for things you may need to add.
My use case for OpenBSD was as a firewall, but it was eventually retired because it just couldn't keep up with my network speeds. It still is a secure unix server for things like radius authentication of wireless clients.
Thank you, I stand corrected: it's been a while and my faulty memory had httpd outside of core. I edited my upline comment to remove the erroneous example because I don't want to add noise.
I respectfully disagree. I have very little Linux/Unix/xBSD maintenance knowledge, but I started running my own server for my personal email and website. Although I used a script as a crutch to set things up at the beginning (thanks to sive.rs/ti), when I started digging in how things work - and when I eventually run into some issues like expired certs - I managed to understand things much faster than when I was trying to run a server before with Ubuntu.
For example, Googling things are easier since the tools don't change much over the years, so an answer from 10-15 years ago still works. Besides that, I could find most of my answers in the very well written man pages. There's also just fewer things happening so there's not much clutter to distract me finding the answers I need.
I'm still a beginner of course, but I feel like OpenBSD is good for any application where you need to run something and then "forget about it" - be it a server or maybe even a "kiosk"/informational screen.
Based on someone else's comment I plan to revisit OpenBSD, because previously I wasn't able to get gigabit speeds out of a low-end appliance, even though FreeBSD and Fedora both could.
Things have definitely improved over time, but some of the best improvements are also related to utilizing advanced functionality from hardware that supports it.
I would suggest openbsd. it is not user friendly in the "hide all complexity from the user" sense but more like "this system is simple enough to understand yet full featured enough to work in".
The way I like to explain it is. if you like the unix operating environment, It is hard to do better than openbsd for a desktop system. If you are expecting something more like a mac or windows environment, there are options, but I suspect you would be better off with linux(or mac or windows for that matter).
Openbsd is comfortable in a way that is hard to explain. While largely this is just what what a person is used to. with obsd I have a good feel on how it works and goes together. something I never really felt with linux. however you do lose a lot of the network effect advantages that linux has.
They're derivatives with their own kernel each, so in that regard the question does not make much sense. Due to its large amount of binary packages though, I'd say FreeBSD it is out of the big three.
The point is that they're not really comparable. Mint/Ubuntu/etc all ship the same Linux kernel, that's why they're called distros. They're different distributions (distros) of the same software (Linux kernel, etc).
The different BSDs aren't distros, they are different kernels that are developed in parallel. Obviously there's shared history there, and some shared userspace, but FreeBSD and OpenBSD aren't just two different BSD distros of largely the same software.
I'd say that if you're trying to find the Mint/Ubuntu/Zorin/elementary of BSD, then it's not really for you. The BSD ecosystem isn't really driven by ease of use, today they're more interested in various niches - hardware appliances, OS research, etc.
If you're curious about what unix is and what a bsd is, I would recommend netbsd or openbsd in a vm.
Well of course they're not trying to replace macOS, for instance, but when an OS gets big enough to have offshoots and different front-ends and desktop environments and so forth, one would assume there are at least experimental attempts emphasizing ease of use, just like there are experiments to develop offshoots for any other purpose, from power users to pen testers. At least like, someone's toy project on GitHub or SourceForge. I just assumed BSD was big and well-established enough to have such efforts.
Besides GhostBSD, looks like there's also Lumina, MidnightBSD, FuryBSD, and TrueOS/Project Trident?
Probably still FreeBSD, even though I'd claim NetBSD's documentation is a tad better.
(And Ubuntu really does not stand out as beginner-friendly compared to e.g. openSUSE)
OpenBSD is in fact already pretty much user-friendly.
Installer is simple, althought an a textual interface.
It comes with preinstalled X server and window managers fvwm and cwm.
In the installer you can choose Xenodm to start automatically after boot, it would be your display manager and you can just simply login through it to fvwm. From here you can edit .xsession and choose any window manager you installed or pre-installed cwm.
I keep switching things around. Virtualization comes with its own limits but is a fast way to prototype things like 'how hard is it to get IPV6 PDUs working in this new os?'
Pfsense is ok, but CE went a year without an update while they worked on other branches. Most recently their switch to kea dhcp broke some minor things like mapping static DHCP addresses to DNS entries. I believe that's fixed now, but need to confirm you can also still specify a DHCP option which some network devices need.
Opnsense is also decent and has the advantage of a regular update cadence, but I believe the UI is less newbie friendly. Fedora has the advantage of a UI to let you quickly review firewall rules, although the cli is perfectly workable once you get the syntax down.
Honestly I like OpenBSD's pf too but it couldn't keep up with a one gigabit network connection on your typical AliExpress firewall appliance, and I couldn't get it there virtually on an HP 360 Gen 8 or Gen 9 with decent Xeon CPUs and network cards. Probably a limitation of the network drivers for the network cards emulated by ESXi. I resisted being nerd sniped by that because my wife needs reliable Internet so there was no time to putter.
What are you using that lets OpenBSD achieve better than gigabit speeds?
tl;dr: For now I'm using PFSense because I have a friend I supply with tech support and he uses whatever I use and it's safe for him to play around in PFSense on his own.
OpenBSD out of the box is an extremely minimal setup compared to the default install of most Linux distros.
A lot of the security of the default install comes from minimizing the attack surface by having very few services running. So you do not need to be tech-savvy to make it secure, but you might need to be tech-savvy to turn it into a usable system for your use case.
OpenBSD out of the box is not minimal. As a base install it is more feature full than most linux base installs. It is small yes, but with a lot of high quality network focused services. I could easily run a company backend and network on only what is found in the base install. If I had a good solid group of people I could probably run the frontend on it. (the main thing it lacks is a web browser).
mail, web, routing, tunnels, bgp, dns, hell there is even an ldap server in there for some reason. but no ldap client, which kind of sucks.
To add: it's not just the fact that it's barely running anything that makes it secure, but the things that you do run have effort put into making their codebase secure as well. Such as the various daemons, like httpd.
Pros: lightweight, really good docs, security as a design goal, designed from the top down as a complete OS so the userland generally all plays nice together and feels more coherent and less bloated than a typical Linux distro
Cons: hardware compatibility/drivers (especially for WiFi and GPU) is worse than Linux, finding help online is worse than Linux, software availability and compatibility tends to be worse than Linux, but generally you can get everything you need especially if you're willing to build from source.
Subjective: Lots of Linuxisms that people are used to having aren't present on BSD. For example, no docker, no systemd, no Snap/AppImage/Flatpak, and no eBPF. This is true even on FreeBSD, which is the most Linux-like of the family. BSDs have their own answers to most of the problems that these tools solve, but you'll have to learn those tools and your Linux knowledge and muscle memory will be mostly useless.
An init system isn't a Linuxism obviously. Systemd is though.
Docker is unambiguously a Linuxism. Docker on MacOS and Windows only works by running a lightweight Linux VM under the hood. Docker does not currently run on any of the BSDs, though you can achieve similar process isolation with jails.
It has its uses I guess, but it requires opt-in which is a pretty big disadvantage, and then still can't do even a fraction of what SELinux can already do. SELinux isn't that hard to learn, and the security benefits are immense.
2024-01-08 22:34 ubuntu@knope:~$ sudo apparmor_status
apparmor module is loaded.
185 profiles are loaded.
104 profiles are in enforce mode.
(...)
124 processes have profiles defined.
122 processes are in enforce mode.
Transparent limitation is a double-edged sword. From an adversarial perspective, it's good since I'm not advertising what my system can and can't do, and poorly written software may get hung up on timeouts waiting for things to happen. On the other hand, those same benefits against an adversary are negative constraints to usability, as now silent failures can happen on a system, requiring you to watch your AppArmor logs like a hawk when using new software.
Ultimately, less of a concern for servers that likely have limited scope and use cases, but a significant decrease in usability for workstations.
You need to write an AppArmor profile to limit your software. It’s an opt-in system.
The workflow is you put a test system to “complain” mode and use your software as intended, and add the required permissions to the profile by looking at the logs to see what your app is doing. Then you put AppArmor to enforcing mode, add the profile to production system and your application is sandboxed. Iteratively refine as necessary.
Debian desktop comes with AppArmor enabled. Nothing has been broken so far.
And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed. You get it to work and things seem to be fine. Over time, you start noticing things that are subtly broken, until something just fails completely and doesn't work. The fix turns out to be trivial when you give it another go two days later, but at the time it happened you really didn't have the nerve to deal with it right then.
After two dist upgrades, you realize that this approach isn't workable.
> And every time you upgrade to the next major release, you start again from square one because the requirements of your software have changed.
Nah. That's a huge exaggeration. Most software doesn't change its base behavior like that and certainly not with every new release, and certainly browsers don't.
Because there's already UNIX file permissions which prevent applications to reach places they shouldn't. Confine a daemon to its own user, chroot it, and it's a sitting duck in its own universe.
You add more layers with cgroup/AppArmor/SELinux in Linux, Jails in FreeBSD, unveil on OpenBSD, etc.
You harden as much as necessary. Not "drowned by default".
> Because there's already UNIX file permissions which prevent applications to reach places they shouldn't
Right. Just set up a separate user for Firefox using a single unprivileged command from your user account or a few clicks in your DE, then launch Firefox as that user using another single command or click. Being subordinate to your main user account, the Firefox user's files and directories can easily be managed from your main user and you can move files between subordinate users using just an (unprivileged) chown or chgrp. Accidentally launching applications as your main user is not possible and the system strongly encourages you to create separate, subordinate users for all your applications and is designed from the ground up to make this simple and it works out of the box.
Oh wait, that's not even remotely how any of this works. On a workstation, the "user account" is an almost completely useless concept (as set up and implemented in reality). That's why we have jails/namespaces/etc. Hacks that are piled on top of the useless mess of "user accounts" (all running as the same user, on workstations) trying to solve the same problems, but ultimately failing at providing any kind of comprehensive solution with a coherent vision. Software cannot take anything for granted anymore. Anything that looks like a writable file could be a read-only bind mount. Any mundane syscall could get it SIGKILLed for no reason other than that somebody forgot to add it to the whitelist. But from the user's perspective, there's no reasonable level of security by default.
Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different user and chroot doesn't exclude the use of jails, or other kernel level security systems like AppArmor/SELinux. They are layered on top of each other as necessary.
Also, namespaces is not solely a security mechanism. Yes it allows isolation, but it allows resource limitation, too. So you can partition your system to slices and show a particular set of resources to an application (I'm sure you're way more knowledgeable than me in that regard).
On the other hand, security starts with application itself. Then you start to add extra containment barriers if you don't trust the software in question.
What I understand is our realities are completely disparate, and this is not how we hold the mechanisms I talk about. This might be due to the environment each of us live in, or due to our requirements, I don't know.
But, what I know is, the state of security is not as bleak as you portray, and necessity is mother of invention. Except SELinux, AppArmor, and FireJail all of the technologies we talk here are essentially built as virtualization, or virtualization-like technologies. They bring additional security as a secondary effect, and they're good at that.
> Software cannot take anything for granted anymore.
This is why we have stat calls, defensive programming, APIs and exception handling. The first rule of system programming is to never take anything for granted.
I have reached to the end of the time I have for today,
With what purpose? Why do you want two different directories? On second thought, maybe you mean ~/Uploads could be unveiled read-only, though I still don't believe this brings much.
Pros: More of the software has been audited. That's it really. There's nice documentation but that's true for many linux distros as well, and much of the security claims are overblown.
Cons: Lack of available software and software compatibility. Lack of good security options to restrict software and the system.
It somehow happens that OpenBSD feels like an whole operating system rather than Linux distro built from various components. For example, when pledge(2) and unveil(2) appeared, many user-space programms got patched as soon as possible. You can see simillar process now, after pinsyscall(2) appeared and syscall(2) was removed.
I heard, that there is something simillar in FreeBSD with zstd compression.
Pros: Secure-by-default, easy to understand your whole system, pledge and unveil are developer-friendly hardening mechanisms, all the answers to your questions are in the (very good) documentation
Cons: all the answers to your questions are in the documentation, and not in stack overflow.
Either you are prompting it wrong, or you got unlucky, or you are stuck on GPT3.5 still and it’s less capable compared to GPT4 than I remember.
Me:
> Give me a short list of five top things that OpenBSD is superior over Linux for
ChatGPT:
> OpenBSD is known for its strong emphasis on security, simplicity, and code correctness. Here's a brief list of five aspects where OpenBSD is often considered superior to Linux:
> 1. Security by Default: OpenBSD is renowned for its security-oriented design. The system is configured with secure defaults, and security features are integrated directly into the core system, not as add-ons.
> 2. Code Quality and Audit: The OpenBSD project places a high priority on clean, readable, and well-documented code. Regular code audits are conducted to identify and fix security vulnerabilities and bugs.
> 3. Integrated Cryptography: OpenBSD includes various cryptographic tools and libraries as part of its base system, making it easier to implement secure applications.
> 4. Pf (Packet Filter): OpenBSD's native firewall, pf, is highly regarded for its flexibility and efficiency. It's often considered more straightforward and powerful than iptables, commonly used in Linux.
> 5. Documentation and Man Pages: OpenBSD’s documentation, especially its man pages, is extensive and well-maintained. It provides detailed and up-to-date information on system commands, configurations, and daemons.
> It's important to note that while OpenBSD excels in these areas, the choice between OpenBSD and Linux depends on specific use cases and personal preferences.
And then for the cons, flip the question around and ask ChatGPT for a list of five ways in which Linux is superior over OpenBSD. (Left as an exercise for the reader.)
The last time I spun up KDE was about two weeks ago on my Fedora 39 system. The tiling was awesome. Coming from i3 and sway it’s pretty good. Not quite keyboard powered everything — maybe it is I’m just a noob — but it was soooo resource heavy. Akonadi was doing too much. And too many things were using compute on my GPU. I went back to sway.
after googling for 8 hours because the last time you had to do that change was 6 months ago and you forgot all about it. At least, that was my experience.
Interesting that you bring this up; pkgs/desktops/plasma-5 in nixpkgs is 3300 LOC (not including helper/library code); x11/kde-plasma in the ports tree is 1260 LOC. I don't think either effort was trivial.
It's accelerating now becasue finally most decided not to spend time on maintaining X. Everyone who was sleeping on it finally woke up and realized they need to do something or they'll be left with no support. They can either maintain X themselves now or they'll use Wayland.
Nobody maintains X. Volunteers fix it, companies add drivers. Freedesktop is defrauding their donors, by claiming to "maintain and extend X" and failing to do so.
Other people will pick up the slack once the weirdos at Freedesktop formally announce they're finished.
When no one fixes it, "volunteers fix it" doesn't sound like a promising proposition. But sure. I suppose if someone wants to stick with it for reasons, they'll care to fix it.
X isn't going bye-bye. Heck the current "maintainers," who are trying to kill it, don't even do anything but merge code given to them by other people.
You'll never win. At best you can kill it from Red Shat. I find the snarky, hubristic nature of Wayland boosters to be insufferable. Whole thing's a huge dumpster fire too.
We'll see what happens when the toolkit maintainers decide to remove their X code paths because they're so rarely used and a pain in the ass to maintain.
