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

OpenBSD 6.5

openbsd.org

Post reply on HN
Print view View original

71–80 of 208 posts

Re: OpenBSD 6.5

#71

Post by ernst_klim »

brynet wrote: post #70
ernst_klim wrote: post #68

>HOWTO upgrade >Remove files no longer included in the current release of perl(1): Do they consider this a production-grade operating system or a toy one? Why couldn't it be done with a package manager?

Because perl is part of the base system, and not a package, harmless files are typically not removed by the OpenBSD Installer. You don't have to remove those files, the upgrade guide simply indicates they're no longer required.

Sure, but manual upgrades with `tar'ring userspace, copying kernel and removing files seems abysmally error-prone to me.

Re: OpenBSD 6.5

#72

Post by whalesalad »

ernst_klim wrote: post #68

>HOWTO upgrade >Remove files no longer included in the current release of perl(1): Do they consider this a production-grade operating system or a toy one? Why couldn't it be done with a package manager?

Funny you say that. I can see your perspective but at the same time the beauty of Unix is that the OS is really just a bunch of files you can see and manipulate yourself. The system doesn’t have convoluted registry systems for instance to hold state.

So for me, deleting a few files is as good as or better than asking a package manager to do it. It proves to me that the OS is simple.

I think we have become so accustomed to complexity that now we often seek it because the simple way “couldn’t possibly be right?”

Re: OpenBSD 6.5

#73

Post by dcbadacd »

tedunangst wrote: post #63
dcbadacd wrote: post #58

Why doesn't OpenBSD do KASLR?

The typical approach of sliding the kernel around only offers limited benefit. One leaked address and you're done. The current approach, called KARL, relinks the kernel so that while it may load at the same address, symbols internally do not have the same offset. Learning the address of printf will not reveal the address of malloc and so forth. In the context of kernel defense, I would argue this is more effective. A…

Why not both KARL and KASLR though?

Re: OpenBSD 6.5

#74

Post by busterarm »

MuffinFlavored wrote: post #60
pimeys wrote: post #2

Been running 6.5 snapshots in my travel laptop for some weeks and everything just works. The laptop is a ThinkPad X200 which is a bit slow for my needs, but upgrading it to ThinkPad X230 later this week should help. I really enjoy how simple the system is after all these years with Linux. I will always continue using Linux in my main computers, but for surfing, some hobby programming and as a travel OS OpenBSD defini…

> but for surfing, some hobby programming and as a travel OS OpenBSD definitely won me over. Mac OS X has won me (and many others) over when it comes to these topics. I'm curious why BSD would be your choice. It sounds painful?

Mac OS X only works for this due to herculean community efforts. The base system is fundamentally unusable for this purpose without Homebrew, Macports (oh hey, BSD ports!), or pkgsrc (oh hey, BSD ports again!).

The base packages get upgraded on a timescale approaching lolnever. They should be ashamed of themselves for shipping machines with Bash 3 still and that's just the tip of the iceberg.

OpenBSD is so simple for me and it takes me a fraction of the time to configure a new OpenBSD system than a new Mac.

Re: OpenBSD 6.5

#75

Post by chousuke »

rooam-dev wrote: post #19

Sorry for noob question, but why would one use OpenBSD instead of FreeBSD? I like latter, but also hear good things about former, although there are some limitations (e.g. no ZFS). Thank you in advance.

I run OpenBSD on my router.

t's very compact and simple and you don't need Google to solve problems because the base system is thoroughly documented.

It has everything I need, and nothing more.

OpenBSD isn't suitable for every use case because rarely used features tend to get removed instead of falling into disrepair from lack of maintenance, but when it does work, it works predictably and reliably. I was able to run OpenBSD on my desktop and have everything work flawlessly out-of-the-box, whereas with FreeBSD I encountered frequent crashes when using dual monitors. I suppose my configuration isn't something that the FreeBSD developers use, so while it "works", it doesn't work.

In the end I returned to Linux because I sometimes play games using Steam and Wine, neither of which is likely to ever be supported on OpenBSD, but if OpenBSD provides everything you need, it's certainly worth trying it out.

Re: OpenBSD 6.5

#76

Post by bigato »

brynet wrote: post #70
ernst_klim wrote: post #68

>HOWTO upgrade >Remove files no longer included in the current release of perl(1): Do they consider this a production-grade operating system or a toy one? Why couldn't it be done with a package manager?

Because perl is part of the base system, and not a package, harmless files are typically not removed by the OpenBSD Installer. You don't have to remove those files, the upgrade guide simply indicates they're no longer required.

> harmless files are typically not removed by the OpenBSD Installer

I also don't understand the reasoning behind this.

Re: OpenBSD 6.5

#77

Post by eb0la »

ernst_klim wrote: post #71
brynet wrote: post #70

Earlier quoted context omitted.

Because perl is part of the base system, and not a package, harmless files are typically not removed by the OpenBSD Installer. You don't have to remove those files, the upgrade guide simply indicates they're no longer required.

Sure, but manual upgrades with `tar'ring userspace, copying kernel and removing files seems abysmally error-prone to me.

In the past problems could happen if your kernel ended beyond cylinder 1024 on the disk (i386 problem)

You should have a disklabel with partitioning for at least /, /usr, /usr/lib, /var, and /home (with / fully behind cylinder 1024 for i386 Bios to be able to load the kernel via int13h )

Re: OpenBSD 6.5

#78

Post by ernst_klim »

whalesalad wrote: post #72
ernst_klim wrote: post #68

>HOWTO upgrade >Remove files no longer included in the current release of perl(1): Do they consider this a production-grade operating system or a toy one? Why couldn't it be done with a package manager?

Funny you say that. I can see your perspective but at the same time the beauty of Unix is that the OS is really just a bunch of files you can see and manipulate yourself. The system doesn’t have convoluted registry systems for instance to hold state. So for me, deleting a few files is as good as or better than asking a package manager to do it. It proves to me that the OS is simple. I think we have become so accustom…

>I can see your perspective but at the same time the beauty of Unix

Ah, beauty of unix =)

Using commands with terrible interfaces, lack of error messages and confirmation dialogs, which silently wipe your whole FS if you mistype them.

Yeah, I would like to upgrade using a bunch of these (no, not really).

Re: OpenBSD 6.5

#79

Post by busterarm »

moviuro wrote: post #16
justinsaccount wrote: post #11

> First release of unwind(8), a validating, recursive nameserver for 127.0.0.1. It is particularly suitable for laptops moving between networks. When systemd-resolvd was first released it was the biggest mistake ever to write a new recursive resolver instead of using unbound or dnsmasq. Also since DNS ".. wasn't broken, so it did not need fixing". I wonder if unwind will be received with the same hostility.

See https://man.openbsd.org/unwind.8 And also in general, I'm far less concerned about software released by a well-established security-minded team than I am about whatever Lennart wants to ship...

literally, "whatever Lennart wants to ship"

Re: OpenBSD 6.5

#80

Post by tedunangst »

dcbadacd wrote: post #73
tedunangst wrote: post #63

Earlier quoted context omitted.

The typical approach of sliding the kernel around only offers limited benefit. One leaked address and you're done. The current approach, called KARL, relinks the kernel so that while it may load at the same address, symbols internally do not have the same offset. Learning the address of printf will not reveal the address of malloc and so forth. In the context of kernel defense, I would argue this is more effective. A…

Why not both KARL and KASLR though?

Nontrivial endeavor.
Post reply on HN