Ok /g/ fags and /pol/aks
OpenBSD or HardenedBSD
(hint: already installed gentoo hardened, so no memeing fags.)
<btw, fuck you
Openbsd | HardenedBSD
Ok /g/ fags and /pol/aks
OpenBSD, if doesn't work for you in the end then stick with Gentoo.
portage has no package signing at all
nice larping out there, keep us informed
he doesn't realise he is compileing everything from source
he doesn't realise you either trust no one to MITM your connection as you downlaod source code or for the software itself not to be subverted at that point
Just compile everything with exotic useflags to rule out obvious and lazy MITM code injection. This is assuming everything is downloaded over http and not https. This is also assuming https is not broken. This is also assuming the checksum for the source code packaged tarballs can be changed on the fly for MITM. Or changed at gentoo's servers.
Atleast by compiling it yourself you aren't trusting someone else to not have tampered with the already possibly tampered connection they had to the source code download. And that the source code isn't subverted.
Unless you import developers' PGP keys by meeting them in person, there is no way of proving software authenticity correctly. Stay pozzed, dumb nigger.
he thinks the devs won't be either be not secret agents with bruteforced or stolen PGP keys or compromised devs if he met in person
he thinks most FOSS software isn't made by cianiggers in some capacity now
I am talking about if you want slightly more security over trusting a linux distro that is pre-compiled by cianiggers. If you are going for true security like that, then what are you doing here? Go fucking start writing your own compiler from scratch on non pozzed hardware you fucking nigger.
HardenedBSD is doing security by features, think of FreeBSD with sane defaults along with being okay with breaking backwards compatibility.
OpenBSD is doing security by correctness, if they aren't happy with something, they gut it.
This is why they don't have things like MAC yet, because they think implementations of it are insane and are therefore working on pledge.
It really depends on what you do with your machine.
You're on the wrong website, friend.
Le I decide to dual boot would the openbsd boot process be more of a problem then HardenedBSD?
Caring more about license than code quality is retarded. I GPL all my shit but that doesn't mean I'm going to run shit software just because of the license they're using.
Nevermind, retarded kernel panics on both that I don't feel like fixing.
I'll just install gentoo on this box. Developers need to step their game up and port their shit to legacy hardware if they ever want actual users.
Developers need to step their game up and port their shit to legacy hardware
What are you mean by "legacy"? You are running something older then VAX? DEC Alpha?
It is your own responsibility to port their shit to legacy hardware. It is not the developer's responsibility to work for you.
Not sure what he is talking about legacy hardware. OBSD will run on a fucking 486DX. Most likely he fucked up his "dual" boot and the panic is from not finding root.
OBSD is not kind to retards or casuals.
Do not dual boot unless you understand what you're doing.
Dual booting is hard, you're much better off testing in a VM or just installing to a separate HDD and booting via the BIOS Boot menu prompt.
OpenBSD just retired the VAX last year, still supports 486
Are you suuuuuure it's the legacy hardware?
Dual booting isn't hard if you read to website faq and man pages. OpenBSD doesn't provide a boot manager, so you have to use another one, like grub or whatever. But it's better the first time if you just install the OS on its own disk. Once you're familiar with the booting process and how the pieces fit together, dual-booting is easy.
dual-booting is easy.
Not so easy when you can't be bothered to RTFM like OP.
Booting into the live medium causes a kernel panic on my machine, I don't feel like sealing with it more than that. Dell Demension 9150.
Here's the panic if you want to figure it out.
panic: lock "msgbuf" 0xfffff8013fffffe0 already initialized
Kbd: stack backtrace:
#0 0xffffffff80a5b877 at ??+0
#1 0xffffffff80a1d556 at ??+0
#2 0xffffffff80a1d3c6 at ??+0
#3 0xffffffff80a5cab8 at ??+0
#4 0xffffffff80a01280 at ??+0
#5 0xffffffff80a62261 at ??+0
#6 0xffffffff80e57553 at ??+0
#7 0xffffffff802ff024 at ??+0
I guess I didn't read the fucking manual.
Suck it theo.
Posting that here won't help. Send all relevant details like computer make/model, dmesg, and stack trace to [email protected], as explained here: openbsd.org
If you can't capture the boot log via serial port, maybe you can at least take pictures of the screen. That's better than nothing.
Various hardware vendors are doing things in non-standard ways these days, so that causes problems, and kernel developers have to make work-around for them. I'd think about making a list of all the guilty parties, but frankly I'm done with x86 anyway (moving to OpenBSD/armv7 now).
How does OBSD performance compare to FBSD from a server standpoint? The more I learn about FBSD's weak af sec model and fetish for backwards compatibility the more I'm interested in moving on.
Nvm can't run ZFS on OBSD, deal-breaker. Someone needs to rewrite FBSD in Rust and use OBSD's security improvements.
You should try Dragonfly. It looks like correctness matters more than FBSD, but you still get Hammer (and soon Hammer2).
Or you wait for NetBSD to finish their ZFS port.
Would the best way to do this be to begin with the FBSD design, tweak it to include OBSD's improvements, then code to that? Would following their combined designs help me avoid mistakes that I'd otherwise make as a systems dev noob? Otherwise it would be a lot of work just to end up with shittier shit than the start.
Gentoo has package signing. This fud needs to end some day.
OBSD's security improvements
Don't you mean PaX project's security improvements?
I don't know I don't follow OBSD. Rundown for a fellow niggerhater?
Some years ago, PaX team kvetched at OpenBSD devs for not giving them credit in some security mitigations, because apparently Pax team invented and produced all those mitigations, even though there was no implementation prior to the hackathon that both parties attended. Then PaX trolled openbsd-misc for months, because they wanted credit of all the hard work (implementation) of OpenBSD's mitigations, even though nothing concrete existed prior to that hackathon by them or anyone else. So they're like the "idea guy" who shows up on Holla Forums and wants people to give him credit, even though he does nothing, and quite likely people didn't even use his idea anyway, since it's often the case people come up with similar solutions for a problem.
The problem is PaX team have very high egos and instead of trying to get along with people, they act like crybabies. It happened with OpenBSD, then it happened with Linux kernel, and then they took their ball and went home, because they can't get along with anyone. They couldn't even do the hard work and fork their own version of Linux like Theo forked NetBSD or like Matt Dillon forked DragonflyBSD. Instead they just sulk in their corner and try to get some suckers to pay for their closed-up kernel patch.
Same old same old, really. PaX group implemented tons of mitigations for the linux kernel half a decade before openbsd started work on anything similar. Then openbsdtards claimed they invented everything even though for years they'd been claiming it's all bloat and an added attack surface and stubbornly refused to implement the pax stuff.
I'll do that later, just got done installing the base system for gentoo on that box.
PaX team can go fuck themselves because OpenBSD never/rarely claims to have invented a mitigation, their claim to fame is that they're often the first to have a working mitigation implemented in base and turned on by default.
Did PaX get their stuff implemented into the mainline kernel before OpenBSDs base? No? Then they can go away.
OpenBSD is slower, the only thing that it will go toe to toe with FreeBSD will be pf and maybe some other routing protocols.
OpenBSD is working with DragonflyBSD on Hammer2, eventually you will see a more ZFS like FS in OpenBSD.
Interesting. Do you know if it will be available on Linux too? I don't really dig ZFS that much, same with btrfs. Seems like overkill for personal use and XFS and ext4 are just meh in general.
I have no idea about linux, safe to say no.
Maybe you'd like bcachefs.org
ZFS has gone through a decade of pain to make their filesystem super stable, if you like your data ZFS should always be the answer even if you deem it overkill.
OpenBSD is just as insecure as any other OS written in C.
Atleast PaX has solid kernel protections and userland.
I have heard of bcachefs, but that is one guy working on it in his free time, with minimal financial support. The description sounds promising, but I am skeptical until I see actual results, because everybody can talk big.
The thing about ZFS is that I don't actually need it and its plethora of features. I understand why would it be useful on server with lots of files and lots of RAM available. But I am tempted for checksums and snapshots for my desktop root partition and ZFS/btrfs seems like overkill for stuff like that.
ZFS recommendations were made in the Solaris days, 1GB RAM for every 1TB of HDD was intended for large corporations.
There are people happily running 10TB with 2GB of ram with ZFS.
ZFS ramhogging comes from caching, which is really important for a multitennant system.
If you are the only one running on your machine and using an SSD you're not going to need a huge cache and can quite happily use ZFS.
Oh then I was misinformed. Thanks, I will try it out.
Try a snapshot instead of 6.2.
backpedaling this hard
They're both shit but hardened is slightly less shit because no binary blobs.
inb4 hurr durr openbsd is perfect and the default programs have no bugs
OpenBSD has had bugs in core network stuff for over 1.5 decades. NetBSD is ahead of openbsd for security bug fixing. The other BSDs are not really much better, but the point is that the BSDs LIE!! about security by REFUSING to release CVEs for serious issues (for openbsd, they have a policy to only release CVEs for remote execution, i.e. a bug that can be used to perform remote execution, with or without the help of another exploit, is not reported if it is indirect).