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

Debian developer prompted to revisit FreeBSD after 20 years

changelog.complete.org

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Debian developer prompted to revisit FreeBSD after 20 years

#91

Post by [deleted] »

rodgerd wrote: post #32
andolanra wrote: post #23

Earlier quoted context omitted.

I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system. People were dissatisfied with systemd specifically , because of various architectural choices that it made. The fact that FreeBSD might adopt a new init doesn't in itself mean that those people will be scared off.

> I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system That's funny, because the loudest voices all seem to be insisting that an unholy shitpile of init scripts a la SysV was the One True Unix Way and had been forever (which shows how young they are, but I digress). The number of people pushing for smf/launchd equivalents (let alone working on them) is tiny…

[deleted]

Re: Debian developer prompted to revisit FreeBSD after 20 years

#92

Post by cthalupa »

The article seems kind of odd on some of its logic:

>Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is called GEOM. GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations!

Well, actually, it does support raid5, but also... With ZFS being a truly first class citizen, why not just use raid-z or zfs encryption instead of raid5 or luks?

>ZFS also does not support some common operations, like adding a single disk to an existing RAID5 group (which is possible with md-raid and many other implementations.) This is a ZFS limitation on all platforms.

No block pointer rewrite for ZFS, so no expanding of existing vdevs by adding disks, but you can still add more vdevs to increase the total pool size. You generally want specific numbers of disks based on raidz level for performance reasons anyway.

(In general) RAID isn't really a "consumer" thing, outside of maybe a basic home NAS type environment. If you're doing this for a server environment where RAID sees the majority of it's use, I don't think it's too onerous to have to add more vdevs instead of a single disk.

> Apparently this is because FreeBSD has nothing like Linux’s inotify.

Nothing like? kqueue/kevent. It's not 'exactly' like inotify, but it's definitely something like it. (It's also something like epoll, and others... kqueue is fairly big and replaces multiple linux equivalents)

I find it odd that the network stack isn't mentioned either. It's still significantly more performant than the linux network stack, and FreeBSD is pulling away even farther in this arena.

Things like https://wiki.freebsd.org/NetworkRSS , netmap being a first class citizen, etc (Netflix blogs on why they chose FreeBSD for their CDN devices are fascinating) are all pretty damn sweet.

Kind of nitpicky, I guess, especially since the author isn't claiming to be intimately familiar with the state of every part of modern FreeBSD

Re: Debian developer prompted to revisit FreeBSD after 20 years

#93

Post by cthalupa »

XorNot wrote: post #37
worklogin wrote: post #34

Earlier quoted context omitted.

Well, I don't believe that's true. All my understanding is that systemd does too much, not that we shouldn't have an init doing more than SysV. Event-based and dependency-based init systems are not controversial. Having an init system with inseparable and breaking changes to logging, IPC, etc. with its own DHCP client seem to be what people think is absurd.

Literally everything you wrote here is objectively wrong about systemd though. systemd is a package of separable utilities, plus an init system. Much like the GNU core utilities. The complaints about "doing too much" can never decide what too much means and usually start suggesting obvious, raw sore spots of SysV init are actually features.

> systemd is a package of separable utilities, plus an init system.

I might give it another look once the internal API between all of the core components is well documented, isn't changing every 17 seconds, and any work to rip out or replace components doesn't require you fight tooth and nail with the build system.

The theoretical possibility of systemd not being monolithic by way of tightly-knit incestuous dependencies doesn't mean much when the reality is that the deck is stacked against you if you try to replace any of those dependencies.

I'm not even against something being monolithic or 'different' - I run a ton of illumos based servers, I love SMF, and am looking forward to the FreeBSD implementation of a more modern and featureful init system.

(I'll disclaim I don't like Lennart or Kay - I've found their behavior to be ridiculous in quite a few ways, and that certainly colors my judgement... but my dislike for them stems from behaviors in relation to technical problems, so I wouldn't say said dislike is without merit)

Re: Debian developer prompted to revisit FreeBSD after 20 years

#94

Post by weland »

penland wrote: 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 options prior to starting the whole build process -- so I end up having to sit for the next two hours, pampering the build process and tuning (actually, mostly disabling) options every time it moves on to the next port. Needless to say, this isn't fun, especially since there's no easy way to tell what dependencies an option is going to pull (I remember being able to retrieve that information through a script I cobbled up but...).

I could probably script it to just go ahead with the default dependencies, but that gives terrible results (I try to install this little console tool and now it's pulling gnome-something-something because the console tool can be integrated with ImageMagick and that's compiled with support for this-weird-format which is provided by this-weird-lib which is part of the Gnome project and now I'm slowly compiling half the packages in Gnome even though I don't use a single program from the Gnome project).

Re: Debian developer prompted to revisit FreeBSD after 20 years

#95

Post by buster »

smutticus wrote: post #59
exacube wrote: post #29

Earlier quoted context omitted.

But not everyone that uses Linux compile X libs or Firefox themselves (a very tiny fraction do). Why does it make sense to have include headers and source?

Disk space is cheap. If it really is a problem for you then work around it. But for most of us installing dev files makes sense if we ever need to compile something against those .h files.

Disk space may be cheap but limited. It just makes no sense whatsoever to just put a lot of files on my disk i will NEVER care about. NEVER. And if i need them, i will install them. Usually i only want a freaking binary to run.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#96

Post by teddyh »

r3ddaem0n wrote: post #82

"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 come.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#97

Post by lmm »

rodgerd wrote: post #32
andolanra wrote: post #23

Earlier quoted context omitted.

I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system. People were dissatisfied with systemd specifically , because of various architectural choices that it made. The fact that FreeBSD might adopt a new init doesn't in itself mean that those people will be scared off.

> I don't think there were too many people in that debate who were dissatisfied with the idea of a new init system That's funny, because the loudest voices all seem to be insisting that an unholy shitpile of init scripts a la SysV was the One True Unix Way and had been forever (which shows how young they are, but I digress). The number of people pushing for smf/launchd equivalents (let alone working on them) is tiny…

> That's funny, because the loudest voices all seem to be insisting that an unholy shitpile of init scripts a la SysV was the One True Unix Way and had been forever (which shows how young they are, but I digress).

I don't think that's at all true. It's not been any of the arguments I've seen (e.g. it wasn't the case made by boycottsystemd.org ). If anything that sounds like a strawman from the systemd side.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#98

Post by lmm »

exacube wrote: post #29
floatboth wrote: post #25

"There are some other issues, too: FreeBSD ports make no distinction between development and runtime files like Debian’s packages do. So, just by virtue of wanting to run a graphical desktop, you get all of the static libraries, include files, build scripts, etc for XOrg installed." That's definitely a feature, not a bug! I hate how Linux distributions require you to install a thousand " -dev" or " -devel" packages.…

But not everyone that uses Linux compile X libs or Firefox themselves (a very tiny fraction do). Why does it make sense to have include headers and source?

It makes sense to install things in an upstream-supported way. It definitely makes sense to support e.g. standard autoconf macros for detecting dependent libraries. Otherwise, people who try to build software from source (which most linux users do eventually) will get very confused when their build fails. (I remember getting bug reports from debian users who had installed kdemultimedia and some but not all of the kdemultimedia-devel packages - meaning that autoconf would detect that the kdemultimedia headers were installed, but then the specific header I was using wasn't present).

If you can repackage without breaking the upstream-supported use cases then sure, go for it, if you want to.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#99

Post by rvanlaar »

weland wrote: post #94
penland wrote: 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…

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

Post reply on HN