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

FreeBSD – a lesson in poor defaults

vez.mrsk.me

Post reply on HN
Print view View original

41–50 of 67 posts

Re: FreeBSD – a lesson in poor defaults

#41

Post by armitron »

ceratopisan wrote: post #40
armitron wrote: post #38

Earlier quoted context omitted.

Given the focus on security, don't expect to see SMP anytime soon if ever. It's a huge source of potential security bugs and attacks on the kernel.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

Not at all, SMP opens a huge can of worms both for userland and kernel security. Suddenly you have all sorts of weird race conditions to deal with and in some kernels (cough XNU) logic bugs that stem directly from how kernel subsystems interact with threads. I don't blame OpenBSD for not going down that route.

Re: FreeBSD – a lesson in poor defaults

#42

Post by aduitsis »

floatboth wrote: post #33
aduitsis wrote: post #27

Pkgng and poudriere can very neatly be used in conjunction. You can use pkg to fetch and install all your binary packages from FreeBSD in the same way that apt-get is used in Debian. Most people will do just that. But, if you'd like to have some ports built by yourself with special options, you can setup a poudriere builder and tell it to periodically make the ports you're interested in. The ports are compiled and pa…

Last time I checked, poudriere and other similar tools didn't have the option to ONLY build ports for which you have customized options, i.e. fetch their non-customized dependencies from pkg repos >_< That was possible on Arch Linux with yaourt… back when I used Arch as my primary OS, and that was when the Eee PC 900 was still relatively new.

Yes, that is correct. But this isn't a characteristic of Poudriere, but of FreeBSD ports in general. If you try to build a port and it has dependencies, it will build them as well. Doing pkg search -f yourpackage will fetch the build options that were used when building the remote package if I remember correctly. So one could theoretically ascertain what are the local Poudriere and the remote repo build options.

And yes, I agree, it would be more efficient to just download the packages if the default options are unchanged. But in practice I hardly notice, because for most packages the dependencies are not too deep.

Besides, doing all the dependencies yourself adds a level of consistency. If your package depends on libwhatever.so.6 and there is a major/minor version change in that library, that might introduce a subtle but important API change, I guess you would rather prefer building libwhatever yourself to make sure that everything will work out ok.

Re: FreeBSD – a lesson in poor defaults

#43

Post by aduitsis »

cm3 wrote: post #31
aduitsis wrote: post #27

Pkgng and poudriere can very neatly be used in conjunction. You can use pkg to fetch and install all your binary packages from FreeBSD in the same way that apt-get is used in Debian. Most people will do just that. But, if you'd like to have some ports built by yourself with special options, you can setup a poudriere builder and tell it to periodically make the ports you're interested in. The ports are compiled and pa…

I've heard time and again that you should either build everything from ports of install pkg binaries? I believe it's because of different use flags (in Gentoo lingo), so maybe you mean that one would build everything privately in a consistent poudriere repo with personal settings and only ever install packages from there. Is that right?

As floatboth said, there's really no reason to build every minor package by hand. Only those that you want to change the config or their dependencies.

Re: FreeBSD – a lesson in poor defaults

#44

Post by Sanddancer »

cm3 wrote: post #31
aduitsis wrote: post #27

Pkgng and poudriere can very neatly be used in conjunction. You can use pkg to fetch and install all your binary packages from FreeBSD in the same way that apt-get is used in Debian. Most people will do just that. But, if you'd like to have some ports built by yourself with special options, you can setup a poudriere builder and tell it to periodically make the ports you're interested in. The ports are compiled and pa…

I've heard time and again that you should either build everything from ports of install pkg binaries? I believe it's because of different use flags (in Gentoo lingo), so maybe you mean that one would build everything privately in a consistent poudriere repo with personal settings and only ever install packages from there. Is that right?

You can mix and match. The only problem comes if you have flags in a dependency that don't match the flags in the package pkg wants to install. A bit bothersome, but it allows you the best of both worlds.

Re: FreeBSD – a lesson in poor defaults

#45

Post by _delirium »

ceratopisan wrote: post #40
armitron wrote: post #38

Earlier quoted context omitted.

Given the focus on security, don't expect to see SMP anytime soon if ever. It's a huge source of potential security bugs and attacks on the kernel.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

OpenBSD supports multiple cores fine as far as userland goes. If you have 8 cores and start 20 userland processes, they'll be scheduled on all 8 cores. But yes, the kernel itself is not as fine-grain multithreaded as some others. Whether that matters depends on whether waiting on the kernel turns out to be a bottleneck for your workload.

Re: FreeBSD – a lesson in poor defaults

#46

Post by [deleted] »

mioelnir wrote: post #37
zippergz wrote: post #18

Earlier quoted context omitted.

I use FreeBSD for a fileserver because it has rock solid ZFS support. At least at the time I set it up (I haven't looked recently), neither OpenBSD nor Linux supported ZFS nearly as well.

In terms of tool/system integration FreeBSD's ZFS is miles ahead of ZFSoL and this is unlikely to ever change. FreeBSD has its own userland that does not need to run anywhere else; updating it to integrate new kernel capabilities is comparatively easy. This can simply not happen for ZFSoL in the same way, since it would split this integration over a myriad of projects and then still require a distribution to make all…

[deleted]

Re: FreeBSD – a lesson in poor defaults

#47

Post by alwaysdownvoted »

"I don't know anythng about IPFilter, nor do I know anyone who uses it, so we'll pretend it doesn't exist."

If alternatives exist that would address the author's complaints (and they do), but he doesn't know anything about them or anyone that uses them then does he pretend they don't exist? What do you think?

Re: FreeBSD – a lesson in poor defaults

#48

Post by chriscappuccio »

_delirium wrote: post #45
ceratopisan wrote: post #40

Earlier quoted context omitted.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

OpenBSD supports multiple cores fine as far as userland goes. If you have 8 cores and start 20 userland processes, they'll be scheduled on all 8 cores. But yes, the kernel itself is not as fine-grain multithreaded as some others. Whether that matters depends on whether waiting on the kernel turns out to be a bottleneck for your workload.

The kernel is undergoing rapid work to distribute load among cores for major subsystems right now...

Re: FreeBSD – a lesson in poor defaults

#49

Post by chriscappuccio »

craftkiller wrote: post #13
daenney wrote: post #10

It seems that a lot f the issues the author has they can fix by moving over to OpenBSD. I'd be curious to hear what makes them stick with FreeBSD instead considering the complaint.

I'm not the OP but OpenBSD is missing some pretty key features. My reasons to use FreeBSD over OpenBSD are: - Virtualization (jails, bhyve) - Filesystems (ZFS) - beadm (which requires ZFS) - Linuxulator Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

Virtualization for amd64 and i386 is in progress. Rapid development is taking place on vmm/vmd. There is a port of dragonfly hammer fs which is less rapid.
Post reply on HN