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

31–40 of 67 posts

Re: FreeBSD – a lesson in poor defaults

#31

Post by cm3 »

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?

Re: FreeBSD – a lesson in poor defaults

#32

Post by cm3 »

kev009 wrote: post #26

A lot of these really aren't "defaults" but things necessary for ABI compatibility in the -STABLE branches. I was expecting more on poor sysctl tuning out of the box (and that is a real problem). I will say that for FreeBSD 11, where we can break ABI again, it would be nice to ditch sendmail and I don't know why it is taking so long to do it.

I believe there's work underway to replace it with Dragonfly's dma.

Re: FreeBSD – a lesson in poor defaults

#33

Post by floatboth »

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.

Re: FreeBSD – a lesson in poor defaults

#34

Post by floatboth »

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?

Uh… no? Unless you really customize all the options I guess. There's no reason to rebuild the exact same package you'll get from the repo.

E.g. I install all firefox's dependencies from pkg, then I build firefox from ports with the GTK3 option. Same with packages that use openssl (I use libressl). Never had any problems with that.

Re: FreeBSD – a lesson in poor defaults

#35

Post by mioelnir »

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.

You can specify poudriere which packages to build, it does not have to be all of them. This is in addition to the custom make.conf and options files. The resulting repository catalog will contain only the packages you specified, plus all their build- and runtime dependencies.

What it can not do is infer the list of ports from the custom make and port configurations.

Re: FreeBSD – a lesson in poor defaults

#36

Post by cperciva »

ComputerGuru wrote: post #3

I'd be interested in hearing @cpercival's take on this. He was the FreeBSD Security Officer for a while (but stepped down some years ago) and is definitely properly paranoid about security.

I find that thumper's rule is very useful when dealing with zealous members of the OpenBSD community.

Re: FreeBSD – a lesson in poor defaults

#37

Post by mioelnir »

zippergz wrote: post #18
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 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 the right choices.

With regards to OpenBSD, I think it was at the last EuroBSDCon in Stockholm during Henning's talk when he said that "ZFS was not the solution" or something to that effect. Quite rich, I thought, coming from a platform where software-mirroring and disk encryption is an either-or decision (at least was at the time).

Re: FreeBSD – a lesson in poor defaults

#38

Post by armitron »

cm3 wrote: post #14
craftkiller wrote: post #13

Earlier quoted context omitted.

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

And let's not forget that OpenBSD doesn't make use of modern hardware as well as Linux and FreeBSD or DragonflyBSD. SMP incompleteness is one of the issues.

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.

Re: FreeBSD – a lesson in poor defaults

#39

Post by Someone »

loeg wrote: post #5

This reads as unnecessarily nasty and mean-spirited. Sure, I am biased, I am a FreeBSD developer.

I find it direct and nasty, but not mean-spirited. I think he does that because he cares about this, and hasn't managed to get his message across.

And I think he has good points. In particular, ports running make as root makes every buffer overflow in your C compiler, linker, and whatever other tools build scripts run a potential root exploit. Yes, other security measures such as pledge can decrease that risk, but why run the risk at all?

Re: FreeBSD – a lesson in poor defaults

#40

Post by ceratopisan »

armitron wrote: post #38
cm3 wrote: post #14

Earlier quoted context omitted.

And let's not forget that OpenBSD doesn't make use of modern hardware as well as Linux and FreeBSD or DragonflyBSD. SMP incompleteness is one of the issues.

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?
Post reply on HN