Thinking about trying this on a VM, what am I in for?

Thinking about trying this on a VM, what am I in for?

Attached: 1200px-OpenBSD_Logo_-_Cartoon_Puffy_with_textual_logo_below.svg.png (1200x781, 180K)

Great OS, might suit you well depending on your needs.

Attached: 1500580855251.jpg (600x600, 138K)

be aware that it behaves strangely under virtualbox

will it download gay porn and post to Jow Forums using appropriate language?

sup

Attached: 1533512798315.png (400x400, 87K)

Why don't you just fucking do it instead of wasting time posting here about it?

Waiting for that pasta

Don't summon him

Attached: 1531074540926.png (588x426, 129K)

How is the nvidia driver support going on?

I tried OpenBSD once. On my X220 the battery life and performance was rather bad. No luks support (don't expect the same broad range of supported filesystems like Linux) , uses something own for encryption, which fucks with my old installation backups. It has a rather complicated updating system. It's not as easy as your good old "emerge -auD @world"/"pacman -Syu"/"apt-get update && apt-get upgrade". It has seperate updating procedures for software in the base install and optionally installed software. No GNU, but you will learn some new ways to accomplish what you want.

All in all? Probably nice if you want to build a server, or have a lot of time to learn it if you want to use it as a daily driver. Otherwise stick with Gentoo/Arch/Devuan/whatever…

Attached: 1445832522381.gif (627x617, 2.6M)

Pic related: Trying OpenBSD.

None. Radeon or Intel.

>It has a rather complicated updating system.

We got syspatch(8) now, it's pretty simple and easy to use. You just run 'doas syspatch' and done. Last time I checked it was only available for the amd64, i386, arm64 releases though.

>syspatch and pkg_add -u is more complicated than a program with 6000 flags

Doesn't syspatch only patch the distribution and not optionally installed packages?

pkg_add

yeah, it's only for base.

it doesn't even work properly on virtualbox

If you have a Ryzen like me and you try to compile something from ports there are chances it will crash. This also happened whenever running a VM on my i5.

It's pretty decent. Make sure you install readline and copy over /etc/inputrc from Linux so you can use control+left/right in a terminal.

Installing it only to find out that he hates it would be much more of a waste of time than asking about it here.

I never had any issues with it in VirtualBox. How long ago did you try it?

Broken
Software
Disappointment

Gigantic
Nasty and
Unavoidable

i'm running 6.3 in VB. sound slows down the whole VM and there's some bugs in the console driver.

>Probably nice if you want to build a server

lol. Isn't that what everyone said about linux back in the day?

Say that to my face, motherfucker.

Attached: DjM3v8mUYAEFCIq.jpg large.jpg (1024x769, 159K)

you need to go back, twitter faggot.

lol

You're in for a meticulously maintained old school Unix. It's fantastic, but know that its attention to detail ends where the ports tree beings. And you'll need a lot of things from the ports tree. If you know your way around compiling software on Linux though, that's easy.

Attached: ppuf800X725.gif (800x725, 293K)

To be fair anything but those archs is only kept around for hobbyists

arm? mips?
what if you want to run OpenBSD on a router?

Doesn't even support 32bit mips and 32bit arm has no support for SMP or anything older than armv7.

I just checked, I never tried anything involving sound last time I used it, but yeah it runs horribly. I don't know what's up there.

I had no problems with sound on real hardware

In a VM? You're in for going back to your usual operating system, since you aren't dedicated to try it out as your desktop. That's the same with any OS you use in a VM. Just get another hard drive, a spare one, to dualboot with.

oh no, i didn't either. i'm just saying that he has to expect that if he's trying it out in VB.

That's actually pretty cool

A clean, minimastic, and secure operating system.

Man pages are very good so you’re expected to read them. The operating system comes with most of what you’d need for regular server operations already built in, but mostly disabled. You enable services as needed, not the other way around. pkg_add will get you most the 3rd party software you might need, and syspatch will keep your machine up to date. I suggest sticking to the current branch since that’s where most of activity is. (Current does not mean broken in the OpenBSD world). You also have an up to date version of the worlds best firewall pf. With a bit of patience to learn the ins and outs of OpenBSD, and you’ll come to appreciate what a well thought out, cohesive operating system OpenBSD is in comparison to something like Linux.

OpenBSD is a meme

>Filesystem
blablabla
>Security
blablabla
>Sustainability
blablabla
>Standards-compliance
blablabla something

Attached: opebsd.png (1000x1000, 168K)

mediocre

>recommending current when syspatch exists
No. Don't do that. Especially not to newbs.

Its deprecated and uses an outdated init system instead of a modern one like systemd.

Its really nice to use, but its slower and more power hungry than linux if you are gonna use it for general things on a laptop

These 3 issues all relate to a bug in Intel cpus

The cpu will speculatively honour invalid PTE against data in the
on-core L1 cache. Memory disclosure occurs into the wrong context.

These 3 issues (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) together
are the currently public artifacts of this one bug.

There may be more artifacts of this on the way, perhaps combined with
other past and not yet known mistakes.

CVE-2018-3620 matters for the host OS. We have reviewed our pmap module
and it appears like we never invalidate a PTE by clearing the 'valid'
bit alone, we always clear the PTE to 0 entirely. Page 0 of physical
memory is unused. As well, we don't support Wine (which has VA 0 / PA 0
issues); we don't support 32-bit emulation in 64-bit mode which makes
things trickier, and we have SMT disabled by default which reduces the
risk patterns further.

(continued)

CVE-2018-3646 relates to the same bug, but considers the cross-domain
impact upon entering VMs, which obviously run in different security
domains. A patch should arrive soon to flush the L1 cache before
vmenter, so that an incorrectly accessed PTE can't read data from
another domain. Another aspect of the risk in this area goes away if
SMT is disabled, so keep it disabled!

CVE-2018-3615 (Foreshadow) is by receiving the most press which is
amazing considering it is by far the most boring of the 3, since very
few few people give a rats ass about SGX -- who cares if SGX is broken
when the cpu can't run your OS safely? Some convincing press agencies
were hired I guess, and have performed a masterful job of distracting.

We had some idea this class of problem was coming, through hints we
received from others and an extremely cynical perspective that has
developed. We believe Intel cpus do almost no security checks up-front,
but defer checks until instruction retire. As a result we believe
similar issues will be coming in the future.

We asked repeatedly, but Intel provided no advance notice. We did not
even receive replies to our requests for dialogue.

On a side note, AMD cpus are not vulnerable to this problem. Currently
it is believed their address translation layer works according to spec.

t. Theo de Raadt

had to configure my machine to read an openbsd formatted hdd. They have totally different data storage layout than the usual partition.

Go to bed Lennart.