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

51–60 of 113 posts

Re: Debian developer prompted to revisit FreeBSD after 20 years

#51

Post by felixgallo »

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…

1) the unholy shitpile of init scripts was only a problem because the desktop guys who wrote the particular shitpile in question had no idea what they were doing. BSD is proof that you can write clean, sensible init scripts.

2) "which shows how young they are" -- what in particular is your issue with older, more experienced people, and how is that a problem enough for you to call it out?

Re: Debian developer prompted to revisit FreeBSD after 20 years

#52

Post by GalacticDomin8r »

SpartanJ wrote: post #8
vezzy-fnord wrote: post #2

Apparently this is because FreeBSD has nothing like Linux’s inotify. It has kqueue, which is a generic event mechanism that can take the place of inotify, signalfd, eventfd, timerfd and others on Linux systems. It has a bit of a learning curve, but it's actually neat. Concerning platform support, that has always been NetBSD's shining ground.

This is true but not entirely accurate. The use case that he's mentioning, an application like Dropbox, that relies on a good file system watcher wouldn't be totally feasible with kqueue, since you're pretty much limited by the number of open file descriptors the OS allows to handle, if i don't remember wrong this number in FreeBSD is below 10000 by default, so it's limited for that use case. And that's also why OS X…

> if i don't remember wrong this number in FreeBSD is below 10000 by default

You are wrong.

ulimit -Hn; ulimit -Sn 467631 467631

Now try that on RedHat/CentOS as a default non-root user.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#53

Post by GalacticDomin8r »

olavgg wrote: post #30
Scramblejams wrote: post #24

Earlier quoted context omitted.

Not only that, but it also misses the point in the original context. Missing an inotify equivalent can be a handicap for a number of different applications. Whether kqueue is an acceptable alternative sounds like it's worthy of a separate discussion.

No kqueue is not an acceptable alternative as it uses file descriptors to "watch" for changes :(

Um, yes it is.

https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2

Re: Debian developer prompted to revisit FreeBSD after 20 years

#54

Post by acdha »

bashinator wrote: post #39
rodgerd wrote: post #32

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 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…

I really like upstart, and am quite disappointed that Canonical caved on it. It seems to be an honest improvement on SYSV with standardized configs, while still doing One Thing, Well.

I use upstart on my Ubuntu servers but it's still pretty green: upstart still doesn't offer any reliable way to keep a process restarted after a transient failure (once it hits respawn limit it will never try again) and if its view of the world becomes wrong (i.e. a script's expect fork is wrong) all commands will hang until you manually kill the processes and use telinit to get it to restart.

The fact that it took four releases to add the setuid/setgid statements kind of tells you all you need to know about how many sysadmins the developers talked to.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#55

Post by rodgerd »

felixgallo wrote: post #51
rodgerd wrote: post #32

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 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…

1) the unholy shitpile of init scripts was only a problem because the desktop guys who wrote the particular shitpile in question had no idea what they were doing. BSD is proof that you can write clean, sensible init scripts. 2) "which shows how young they are" -- what in particular is your issue with older, more experienced people, and how is that a problem enough for you to call it out?

> BSD is proof that you can write clean, sensible init scripts.

Which, it turns out, are wholly underwhelming for many things people now want their init system doing. Hence launchd, SMF, and Jordan Hubbard's interest in an equivalent. But I guess the BSD developers working on the former and latter don't know what they're doing either, right?

> what in particular is your issue with older, more experienced people

I'm sorry you're struggling to read, but it's quite the opposite: anyone around long enough knows SysVisms were derided widely when they were introduced.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#56

Post by rodgerd »

bashinator wrote: post #39
rodgerd wrote: post #32

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 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…

I really like upstart, and am quite disappointed that Canonical caved on it. It seems to be an honest improvement on SYSV with standardized configs, while still doing One Thing, Well.

I initially leaned towards it, but (a) the even model is something I find less pleasant to work with than the dependency model, and (b) the original author disowned it as unfixable.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#57

Post by Alupis »

Sanddancer wrote: post #38
XorNot wrote: post #37

Earlier quoted context omitted.

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.

So, how does one completely excise journald from a box running systemd. I'm not talking about passing messages through, I'm talking about complete, utter, wiping out?

journald is a dependency for systemd, but systemd is not a dependency of journald... in other words you can use journald on a system that does not have systemd.

What you imply is equivalent to wanting to run Gnome without libgnome.

If you want text logs, configure journald to pass things into rsyslog or whatever other logging subsystem you prefer (there are many).

Re: Debian developer prompted to revisit FreeBSD after 20 years

#58

Post by rodgerd »

edohyiez wrote: post #47
amyjess wrote: 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.

Precisely. Thanks you.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#59

Post by smutticus »

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?

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.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#60

Post by xenophonf » 

    but there is no way with FreeBSD, like there is with
    Debian, to say “never even show me packages that aren’t
    DFSG-free.”
I would be very surprised to discover non-free software in FreeBSD's binary package repository. However, if this is a concern, one needs to set LICENSES_REJECTED in /etc/make.conf, at which point FreeBSD Ports will not build anything with a license that matches. If a company's concerned about the licenses of the binary packages provided by FreeBSD, it could simply set up its own internal binary package repository using poudriere, and use poudriere to filter out software with the unwanted licenses.

See /usr/ports/Mk/bsd.licenses.mk (https://raw.githubusercontent.com/freebsd/freebsd-ports/mast...) for the gory details.

Post reply on HN