Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OpenBSD Rocks

why-openbsd.rocks

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Why OpenBSD Rocks

#101

Post by knorker »

aquabeagle wrote: post #70
knorker wrote: post #31

Last time I tried the full disk encyrption [sic] it was an awful setup compared to Linux. > https://why-openbsd.rocks/fact/meltdown-spectre/ Uh, yeah. They did that, just like Linux did before them. I especially like the reply to the announcement that was "uh… I hope you didn't spend these two months coming up with that solution. We already did that for Linux, so you could have just asked".

Just because the idea is known doesn't make it trivial to implement in a completely different kernel.

I think you misunderstood my whole point.

It appears that OpenBSD chose to spend months starting from scratch researching exactly what needed to be mapped in virtual memory, instead of just confirming the x86/x64 platform needs that were already researched and published by that time.

Re: Why OpenBSD Rocks

#102

Post by knorker »

zolotarev wrote: post #34
knorker wrote: post #31

Last time I tried the full disk encyrption [sic] it was an awful setup compared to Linux. > https://why-openbsd.rocks/fact/meltdown-spectre/ Uh, yeah. They did that, just like Linux did before them. I especially like the reply to the announcement that was "uh… I hope you didn't spend these two months coming up with that solution. We already did that for Linux, so you could have just asked".

Now full disk encryption is pretty simple: https://rgz.ee/openbsd/install.html

That's very relative.

Sure, it does look better now, and I'm fine with this setup being a bit annoying since it's a one-time thing.

Re: Why OpenBSD Rocks

#103

Post by knorker »

madars wrote: post #41
knorker wrote: post #33

Earlier quoted context omitted.

I like how they list W^X as an innovation. 1) It's not W^X. W^X implies read-only pages are not possible, and they are. 2) They "invented" that, what 5-10 years after Linux?

The innovation is using W^X systemwide, which is harder than having W^X support in kernel, and system that does not fully take advantage of it. And W^X is definitely a catchier name than ~(W&X) :-)

It's catchy, yes. But it's still technically wrong.

I don't dispute that OpenBSD pushed execution prevention (and many other things) in the default OS system wide. But it's pretty dishonest to say that they "invented" it. Which they explicitly did at the time, and that the article does now.

Re: Why OpenBSD Rocks

#104

Post by poolsuite »

legosteen11 wrote: post #74

I wanted to install and try OpenBSD on my Librebooted Thinkpad T60, but unfortunately it is not possible to use full disk encryption with a non-custom Libreboot rom (you apparently need SeaBios instead of Grub2 for this to work). I find it quite sad, because I think Libreboot + OpenBSD would be the ultimate security and privacy-focused combo.

Let's hope they support RISC-V

Re: Why OpenBSD Rocks

#105

Post by enriquto »

redsavagefiero wrote: post #95
enriquto wrote: post #92

Earlier quoted context omitted.

I am a newcomer to hating systemd. At first I was indifferent, an init system cannot be so bad after all. Fuck that. In the last two years, they have changed at least three times the way that the option to delete the /tmp dir is specified. I understood the configuration, edited it so that it did not delete the /tmp dir automatically; and then, upon an innocent update the old config is overridden and the /tmp dir is m…

A systemd conceptually is quite a good idea. However systemd is not that systemd. Much rather go with rc.conf + script approach, disable all systemd services, lock selinux against systemd socket activations and run a purpose controlled environment. Avoiding systemd does force one to not use Linux as a desktop..oh well.

> Avoiding systemd does force one to not use Linux as a desktop

Why do you say that? You can even use gnome without systemd, but there are still other desktops.

Re: Why OpenBSD Rocks

#106

Post by redsavagefiero »

enriquto wrote: post #105
redsavagefiero wrote: post #95

Earlier quoted context omitted.

A systemd conceptually is quite a good idea. However systemd is not that systemd. Much rather go with rc.conf + script approach, disable all systemd services, lock selinux against systemd socket activations and run a purpose controlled environment. Avoiding systemd does force one to not use Linux as a desktop..oh well.

> Avoiding systemd does force one to not use Linux as a desktop Why do you say that? You can even use gnome without systemd, but there are still other desktops.

I have't looked at it rcently but the last time I checked systemd was the 'nice to have' that was mandatory for some of the software I associate with a fully fuctional desktop which is not just a WM, DE (or not) and basic applications like xterm , vim, etc...But you are right. You can run the linux desktop like its 2007 without systemd on select distributions without screwing around too much...of course don't add new software without researching dependencies and default build options or you may end up with the worst of systemd dependencies anyway. At that point I just run KDE on FreeBSD.

Re: Why OpenBSD Rocks

#107

Post by cat199 »

defanor wrote: post #63
cat199 wrote: post #25

Earlier quoted context omitted.

well, it's what happens if you actually install a package from source, and so is congruent with what it really means to 'install ' seems preferable to accepting arbitrary segmentation of packages into subsets based on some random package maintainers preference.. also, it's not 1993 and having 100kb of headers on my system is not really a big deal.

But at the same time there are modern general purpose systems (Alpine in particular, and Debian when it comes to GNU documentation) that wouldn't even install documentation together with software. Priorities seem to vary quite a bit.

sure.

my point is this is the package maintainer interjecting their own notions of what a package is into what is actually provided by the upstream source. the only 'package X' that is 'correct' w/r/t original author is the one that provides exactly what the source based install provides, anything else is maintainer bias. (which isn't inherently bad; just providing a counterpoint as above claim was questioning)

Post reply on HN