Live data from Hacker News

Debian developer prompted to revisit FreeBSD after 20 years

changelog.complete.org

71–80 of 113 posts

Re: Debian developer prompted to revisit FreeBSD after 20 years

#71

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

A lot of non-Free software also disallows redistribution, so it's not permissible to put it in the binary repository. It's possible that free but not Free (e.g., zero-cost binary-only software) software could be included in the repository.

pkg metadata does include license information -- see https://github.com/freebsd/pkg/issues/20, but I am not sure of plans to provide user-facing control over acceptable licenses at the moment. It's a good idea though and I'll see if we can make it happen.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#72
post #57

Earlier quoted context omitted.

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).

So systemd is not a system of separable utilities then. Remove journald and systemd doesn't work.

Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald. not sure what your point is...

Re: Debian developer prompted to revisit FreeBSD after 20 years

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

I've been using "dselect" for 15+ years on Debian now :-)

But it is not simplistic.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#74
If you happen to try FreeBSD don't let that be your only impression of BSD based systems. Try OpenBSD too, if your hardware is supported and all the software you use is available you won't be disappointed. OpenBSD more or less just works provided the previous conditions are true.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#75
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. > It seems like progress with openlaunchd is going well, but there are certain things related to Mach IPC that…

>> 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 way that is acceptable to the community and it is incorporated into base.

I do think the community has come to more or less that consensus at this point, though. The camp that is fine with /etc/rc hasn't started raising loud complaints about the idea incorporating a backwards-compatible launchd to replace rc.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#76

Earlier quoted context omitted.

> 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 And on Linux inotify is bound by /proc/sys/fs/inotify/max_user_watches. Six of one, half dozen the other. FreeBSD file descriptor limit is arbitrary and can be raised to INT_MAX (2 billion). That should be plenty. > i must say that the kqueue implementation w…

> And on Linux inotify is bound by /proc/sys/fs/inotify/max_user_watches. Six of one, half dozen the other. FreeBSD file descriptor limit is arbitrary and can be raised to INT_MAX (2 billion). That should be plenty. Yes, on Linux you're limited to max_user_watches, and you can edit that value, just like you say with kqueue... but you need root access, so for end user applications this is not really a solution. With i…

> With inotify i use one watch per-folder, with kqueue you need to do it by file ( of course you can watch the folder changes, but you need to keep a copy of the file states in that folder, and then re-stat that files to find out what file was changed, not even close to an ideal solution ). So for example in my use case with inotify i can watch 65536 folders, and with kqueue less than 10000 files ( that could be a single folder! ).

Ah, I looked at inotify API briefly and did not notice that directory watches return file changes. That does make it easier to use than kevent vnode watches. Mea culpa.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#77

Earlier quoted context omitted.

I really like that FreeBSD has binary package management. I started my journey into Unix almost 10 years ago with FreeBSD Unleashed. I am considering writing a comparison command-to-command of apt-get vs. pkg, and differences in behavior. * Are packages from the FreeBSD repos pinned the same way Ubuntu packages are, relase to release? Are there multiple repos (comparable to universe/multiverse, updates/backports)? *…

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

Re: Debian developer prompted to revisit FreeBSD after 20 years

#78

Earlier quoted context omitted.

I really like that FreeBSD has binary package management. I started my journey into Unix almost 10 years ago with FreeBSD Unleashed. I am considering writing a comparison command-to-command of apt-get vs. pkg, and differences in behavior. * Are packages from the FreeBSD repos pinned the same way Ubuntu packages are, relase to release? Are there multiple repos (comparable to universe/multiverse, updates/backports)? *…

Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse). A pkgng repository can contain older versions of packages, but "/latest" is tree of symlinks to the most recent versions in the repo. The FreeBSD Ports Tree isn't tagged, so there's nothing equivalent to…

> Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).

And it's worth pointing out that the per-branch repositories are all built from the same sources — ports is not branched. The only reason to have separate release-branched binary repositories is for ABI bumps between stable releases.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#79
post #72

Earlier quoted context omitted.

So systemd is not a system of separable utilities then. Remove journald and systemd doesn't work.

Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald. not sure what your point is...

My point is that the following statement made further upthread is fundamentally incorrect as an assessment of systemd:

>systemd is a package of separable utilities, plus an init system. Much like the GNU core utilities.

The response was:

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

The point is that if the utilities are truly separable from the init system (as was claimed by the first point as an indication that the person they were responding to didn't "get" systemd) then that would be simple. Note the person responding is responding to the assertion that they fundamentally misunderstand systemd. Their point is to show that they do not.

Your first response adds nothing to the conversation:

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

Good point, except that's not what the person you're responding to asked for.

My observation is that systemd isn't just "an init system with separable utilities" that was originally claimed. You seem to agree with me.

Your last point, however, would have been helpful above:

> Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald.

That would have answered the actual question asked.

Re: Debian developer prompted to revisit FreeBSD after 20 years

#80
post #72

Earlier quoted context omitted.

So systemd is not a system of separable utilities then. Remove journald and systemd doesn't work.

Anyone could implement their own journaling subsystem against the api and it would work... it doesn't have to be journald. not sure what your point is...

Well, as vertex-four pointed out that API is not stable, and as far as I've seen there's no expectation that it ever will be. Feel free to correct me - for me this is the nub of the issue and I'd be happy to hear otherwise.
Post reply on HN