Live data from Hacker News

Debian developer prompted to revisit FreeBSD after 20 years

changelog.complete.org

101–110 of 113 posts

Re: Debian developer prompted to revisit FreeBSD after 20 years

#101
post #77

Earlier quoted context omitted.

I want to add that the FreeBSD ports management team is probably too small to handle complicated release management and backporting schemes like you see with RHEL or Ubuntu. That said, nothing stops you from doing it if you wanted. You can set up your own binary package repository using Poudriere. That's what I do; I tend to update everything quarterly unless there's a serious security flaw in something.

Note there are quarterly ports branches you can track if you just want security fixes - you're not just limited to tracking HEAD: https://secure.freshbsd.org/search?project=freebsd-ports&bra...

Awesome. I didn't know about these. Thank you!

Re: Debian developer prompted to revisit FreeBSD after 20 years

#102
post #31

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vas…

pkgng + poudriere = my sysadmin sweet spot. I can customize package builds to my heart's content while continuing to use the FreeBSD package repositories (if I want). It'd be nice if pkgng would build stuff from the ports tree if necessary, like MacPorts does, but frankly pkgng is good enough as is. If I need more than FreeBSD's binary package set, I'm comfortable with building directly from ports (in case of one-off…

That's on the roadmap. Eventually pkg will auto build only what is necessary to update your custom packages from ports when you do a "pkg upgrade".

Re: Debian developer prompted to revisit FreeBSD after 20 years

#103
post #70

> and solid memory management What does he mean by this?

You'll often find FreeBSD using less memory to run the same software stack. I also tend to see more intelligent use of swap. I can't comment on the comparison of the filesystem cache performance.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#104
post #94

Earlier quoted context omitted.

Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration opti…

You could run: make config-recursive a couple of times to do the configuration up front. See also: https://www.freebsd.org/doc/handbook/ports-using.html

It's what I usually do, but it's still annoying as hell when more than a dozen packages are involved in the build chain :(.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#105
post #94
post #31

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vas…

Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration opti…

Add OPTIONS_UNSET=gnome to /etc/make.conf, plus whatever other options you want excluded system-wide. Ditto OPTIONS_SET. You can override for specific ports with ${PORTNAME}_SET/_UNSET too.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#106
post #94
post #31

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vas…

Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration opti…

When I have to do it manually, I usually build ports with -DBATCH=yes because I trust the defaults. The config-recursive target is a good one to know, but if I have to tweak package build settings, nowadays I'll set the appropriate OptionsNG knobs ahead of time in /etc/make.conf.

(I rarely install directly from ports, though. Instead, I use Poudriere to make my own package repository, and I have a version of make.conf set up for Poudriere that includes all of my package configuration tweaks.)

Re: Debian developer prompted to revisit FreeBSD after 20 years

#107
post #96

"GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations!" Looks like the author is still learning FreeBSD and hasn't read all relevant docs yet. 'man 8 gvinum' clearly says that raid5 _is_ supported: "To create a raid5 array on disks /dev/ada1 /dev/ada2 and /dev/ada3, with stripesize 493k you can use the raid5 command: gvinum raid5 -s 493k /dev/ada1 /d…

RAID5 is obsolete. In RAID5, if a disk breaks in an array and is replaced, the system has to read all of the remaining disks to rebuild the array. If a single byte is unreadable on any of those remaining disks, your array can’t be rebuilt and you have lost your data. With today’s disk sizes, the chance of this happening is larger than is acceptable. The interim solution is RAID6, which will work for some years to com…

Not true with mdadm. Yes, your unreadable single byte will translate into a corrupted file somewhere, but I've recovered plenty of mdadm RAID5 and RAID6 arrays that had lost one or both extra drives and suffered from UREs on the remaining disks. Love good software RAID!

Re: Debian developer prompted to revisit FreeBSD after 20 years

#108
post #36

Earlier quoted context omitted.

>> FreeBSD has been in the early stages of working on a launchd port for 10 years now. > There were several half-serious individual efforts, but I don't think the community / foundation were pursuing it seriously until quite recently. Kip Macy has been working hard to get it in as an init replacement recently. This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD), n…

> This is because iXsystems (Jordan Hubbard) hired Kip to implement it for FreeNAS (and, presumably PC-BSD), I believe EMC Isilon has also sponsored the work. > not because the FreeBSD community thinks it needs a new init system. Right. Kip is working on it because someone hired him too. But practically, this is how large-scale efforts get done. Some FreeBSD-using corporation hires / builds out a larger project in a…

And even now launchd is a more restrained projects than systemd.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#109
post #35

Earlier quoted context omitted.

I'd rather have OpenRC (edit: and I wouldn't mind upstart, either... it's pretty slick). You're creating a false dichotomy. Just because SysV-style initscripts are a mess doesn't mean systemd is the only viable option.

And you're creating a strawman. rodgerd didn't say that the only two options were SysVinit and systemd, but that the loudest critics of systemd wanted to keep SysVinit. Whether that's true or not is another point (and not objectively decidable since "loudest" is pretty subjective), but it's obviously not the false dichotomy you're accusing him of.

The field seems littered with straw men right now...

Re: Debian developer prompted to revisit FreeBSD after 20 years

#110
post #105
post #94

Earlier quoted context omitted.

Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration opti…

Add OPTIONS_UNSET=gnome to /etc/make.conf, plus whatever other options you want excluded system-wide. Ditto OPTIONS_SET. You can override for specific ports with ${PORTNAME}_SET/_UNSET too.

Ha! Yes, this would make it a lot easier, since I often end up disabling the same things anyway. Thank you!
Post reply on HN