"As you have guessed by now I am some kind of allergic to this... those idealistic over-simplifications... drawing everything in black and white..." I avoid oversimplifications, too. Yet, most of what the author wrote was proven by precedent. Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment o…
"Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform." That's fair. FWIW I wasn't trying to focus on Linux in my post. I'm grateful for Linux and the volunteers that contribute to it, both the apps and the security work. The work everyone is doing on FOSS lifts all boats. And you're right of course, not all Linux distros are created equal when it comes…
I don't know it from the top of my head, but FreeBSD runs Wine iirc and afaik FreeBSD 11 (I know, not OpenBSD) will introduce bhyve, a hugely hyped hypervisor/virtual machine manager supporting among other things Windows Operating Systems, also there should be some improvements to the Linux Emulation Layer. Also there is this https://github.com/tony/steam-freebsd-client but not sure how good it works. This might or m…
Here it is (not available): http://openports.se/emulators/wine I don't think FreeBSD is much more secure (if any) than some of the better GNU/Linux distributions though I do, and I've look through the source code of both. Edit: too early in the morning. I misread FreeBSD as OpenBSD in that sentence
It's really the focus. FreeBSD operates a little closer to the cathedral model where they're pickier, more deliberate, and more consistent. Linux takes in about anything to maximize features and development pace. Probably the reason FreeBSD has higher quality in code. Just different priorities.
Of course, I watch these communities from a distance. I'm not in the trenches over there. So, I could be way off. :)
Yall don't be too nice to them. The code quality is shit. My favorite quip of all came from Ted Unagnst noticing they did endian-checks in one code that ran very often during use of protocol. He said something along the lines that they hadn't applied any sense to (important issue) but they had you covered if your CPU's endianness changed in mid-operation. No words. :)
I meant my comment in the same spirit as a Southerner means "Bless your heart". I do believe Ted Unagnt's comment is included in the https://www.youtube.com/watch?v=GnBbhXBDmwU LibrSSL first 30 days along with quite a lot of other oddities.
Alright lol. I lost the video but it was definitely a LibreSSL presentation at a conference. Thanks for the link in case it has it.
Indeed. If systemd were just a parallelized init system with better unit management, far more would be okay with this shift. But that wasn't enough. They had to hijack bootloading, logging, device management, network, etc. For reasons that nobody seems to be able to actually explicate.
They want to control it all to give the best possible user experience but fail short and introduce bugs I've never had since the first day I've installed Linux in the 90s.
They want to control it all to give the best possible user experience
Or perhaps, since Poettering et al. are Red Hat employees:
it's not just that though, there's the push for systemd which was not welcomed and alienated a lot of sysadmin folk who frequent hackernews. personally I felt rather shafted by systemd, not because it's bad, but because my arguments were never even met, it was just a brushing off from some of the people who had already accepted it. So I tried the BSD's and they were significantly better than I imagined they would be,…
There's also systemd's constant regressions and awkward interfaces and limited functionality when they replace existing solutions. It should have stopped at unifying init scripts, although upstart had that, SMF had it, so it's great to see nosh being cross-platform and able to import system unit files.
Speaking of SMF, it's interesting that the seemingly little effort to recreate it led to systemd, while nobody attempts to create a read/write implementation of ZFS. I mean, if you can accept the license of ZFS (huge piece of code), we could have just as well forked SMF, but a clean slate with a different license may have been a favorable choice.
I wanted multiple times to study the OpenBSD source code and I've downloaded it but I never managed to navigate through it, to find the "head and the tail" or to find a reasonable "map" of the source code. I would like for example to follow the execution path in the source code, from the boot up to the login prompt. Does any documentation like this exist or could anyone give me some hints ? Thanks
There are three parts in this sequence: 1. Boot up - this is very machine-dependent ("MD") so you'll find it in each architecture's source code. Look for files named "locore.s" or "locore.S" in places like src/sys/i386/i386. 2. Kernel - the machine-independent ("MI") part, or where the fun begins... this is in src/sys/kern/init_main.c, look for the function main(). You'll see the different subsystems initialized, fro…
What a relief! Thanks for scratching that itch. Also turns out to be good code organization, but I needed that post to boot me up.
They want to control it all to give the best possible user experience but fail short and introduce bugs I've never had since the first day I've installed Linux in the 90s.
They want to control it all to give the best possible user experience Or perhaps, since Poettering et al. are Red Hat employees: Red Hat want to control it all ... for reasons
They want to control it all to give the best possible user experience but fail short and introduce bugs I've never had since the first day I've installed Linux in the 90s.
They want to control it all to give the best possible user experience Or perhaps, since Poettering et al. are Red Hat employees: Red Hat want to control it all ... for reasons
NX enforced kernel W^X, SMEP/SMAP, always-on stack protector and a limited attack surface (..say, from pledge(2)), only serve to make such theoretical attacks impractical against OpenBSD.
No. Those are useful countermeasures, but kernel exploits for OpenBSD are neither theoretical nor impractical.
I'm glad you're saying it, too, as I get tired of this myth. I wrote a scheme on Schneier's blog for disproving it a while back. Basically, you counter the mitigations which look awfully similar to the one's that got countered in Linux and Windows. Once you have that, wait until a bug is mentioned on mailing list that can lead to memory attack. Weaponize it. Profit.
Leads me to what I claim is dirty secret behind "only 2 holes in..." claim they have: OpenBSD just fixes bugs they find without serious attempts to determine if they'd be exploitable vulnerabilities. They just do accounting differently than the rest. So, by their numbers, they only had 2 vulnerabilities because they didn't assess whether other bugs were vulnerabilities in the first place.
They have good code quality but they're full of shit about how vulnerable it is or isn't.
I don't know how anyone can lump Linux in with Windows when it comes to security from NSA spying and then say OpenBSD is a good alternative. HN seems to love the anti-Linux FUD though. Anything that further fractures the OSS community is upvoted fast. I like the BSDs too, but there are a ton of reasons Linux is the most popular kernel in the world, it's not just because the NSA makes it so.
it's not just that though, there's the push for systemd which was not welcomed and alienated a lot of sysadmin folk who frequent hackernews. personally I felt rather shafted by systemd, not because it's bad, but because my arguments were never even met, it was just a brushing off from some of the people who had already accepted it. So I tried the BSD's and they were significantly better than I imagined they would be,…
I'm 23, I used GNU/Linux since I was 11, and about at the beginning of this year (2016) I switched to FreeBSD. It was the first time I had an easily and consistently configurable, recreatable, understandable, enjoyable PC system that went out of the way once configured. It is so pleasurable that I don't even care I can't suspend and hibernate yet, even though I'd hardly turn of my computer and my workflow used to rely on having my laptop on for ten-twenty days and reboots were seldom and because of me forgetting to plug the thing in, or I updated the system. Also, I updated from 10.2 to .3, and it was the most pleasurable, most silent and non-destructive update I ever did. I just merged from /etc and /usr/local/etc to my config repo, and good to go (I have two scripts to copy back and forth the config files into my repo). I expect a mass migration to BSDs to happen soon. They are decent desktops, and soon they'll do better on laptops.