Live data from Hacker News

FreeBSD Jails for Fun and Profit (2020)

topikettunen.com

151–160 of 161 posts

Re: FreeBSD Jails for Fun and Profit (2020)

#151
post #144

Earlier quoted context omitted.

It might be because it would require reimplementing all the system-specific Docker parts from scratch. Not sure though. BSD doesn't really have any licensing issues, thanks to BSD license, but politics is directly related to project size. In FreeBSD it's pretty much unnoticeable, but in Linux it can be a huge deal.

That has not been my experience. The issues are with licenses other than BSD but that's the same in Linux; Linux can also use BSD code, a lot of Linux code is actually dual licensed as BSD already.

It’s not - Linux does have problems with licenses which are incompatible with GPL, such as MPL/CDDL. BSD doesn’t, because you can’t have license incompatibility without throwing GPL in the mix - it’s the only Open Source license that can be incompatible with others.

FreeBSD does avoid pulling restrictively licensed (closed source or GPL) code into the base system itself, but a Docker port would be third party (ports/packages), not the base system.

Re: FreeBSD Jails for Fun and Profit (2020)

#152
post #151

Earlier quoted context omitted.

That has not been my experience. The issues are with licenses other than BSD but that's the same in Linux; Linux can also use BSD code, a lot of Linux code is actually dual licensed as BSD already.

It’s not - Linux does have problems with licenses which are incompatible with GPL, such as MPL/CDDL. BSD doesn’t, because you can’t have license incompatibility without throwing GPL in the mix - it’s the only Open Source license that can be incompatible with others. FreeBSD does avoid pulling restrictively licensed (closed source or GPL) code into the base system itself, but a Docker port would be third party (ports/…

Not really, with Linux it's the same as it would be in BSD if they wanted to avoid conflicts with GPL. You put that code in an optional module and have the user compile it. I am unsure as to why BSD people seem to think that using BSD means you can avoid problems with the GPL, if you use any GPL code for any reason (and there's a lot of it) then you have to pay attention to these things. If you insist on only running BSD and CDDL code then you can avoid it, but that's going back to putting politics over software again, the kind of thing that you were saying you were trying to avoid.

Re: FreeBSD Jails for Fun and Profit (2020)

#154
post #137

Earlier quoted context omitted.

Sorry, then I must be remembering some other issue. The effort to port docker to BSD seems to have disappeared. >And yes, having to use root is a major issue. Looks fixable though. AFAIK it took a long time to get this to work on Linux, there are a lot of security issues that it can cause.

Docker is practically dead, no wonder if disappeared :-) Many things are hellishly complicated in Linux, due to politics and technical difficulties. Case in point: when I’ve started to work on NFSv4 ACLs, support in Linux was “worked on”, there was a prototype. It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs, from file systems to userspace tools, shipped decade ago. In Linux it’s still not there.

> It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs

You are right, but ironically we have to thank Microsoft for that ;)

Re: FreeBSD Jails for Fun and Profit (2020)

#155
post #151

Earlier quoted context omitted.

It’s not - Linux does have problems with licenses which are incompatible with GPL, such as MPL/CDDL. BSD doesn’t, because you can’t have license incompatibility without throwing GPL in the mix - it’s the only Open Source license that can be incompatible with others. FreeBSD does avoid pulling restrictively licensed (closed source or GPL) code into the base system itself, but a Docker port would be third party (ports/…

Not really, with Linux it's the same as it would be in BSD if they wanted to avoid conflicts with GPL. You put that code in an optional module and have the user compile it. I am unsure as to why BSD people seem to think that using BSD means you can avoid problems with the GPL, if you use any GPL code for any reason (and there's a lot of it) then you have to pay attention to these things. If you insist on only running…

Nope - FreeBSD is almost free of GPL, and will probably become entirely GPL-free in 2022: https://wiki.freebsd.org/GPLinBase.

Also, it’s not politics - it’s mostly just that the old GNU cruft is being replaced, and newer, better solutions prefer more liberal licensing, see GCC vs LLVM.

Re: FreeBSD Jails for Fun and Profit (2020)

#156
post #154
post #137

Earlier quoted context omitted.

Docker is practically dead, no wonder if disappeared :-) Many things are hellishly complicated in Linux, due to politics and technical difficulties. Case in point: when I’ve started to work on NFSv4 ACLs, support in Linux was “worked on”, there was a prototype. It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs, from file systems to userspace tools, shipped decade ago. In Linux it’s still not there.

> It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs You are right, but ironically we have to thank Microsoft for that ;)

Why, apart from inventing them (in Windows NT) in the first place?

Re: FreeBSD Jails for Fun and Profit (2020)

#158
post #156
post #154

Earlier quoted context omitted.

> It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs You are right, but ironically we have to thank Microsoft for that ;)

Why, apart from inventing them (in Windows NT) in the first place?

Well the posix conglomerate had such big problems implementing a ACL (mostly because of blabla)... Then Microsoft did one for NT which was then took over to NFS, later the posix peoples decided on a ACL but no one wanted it anymore. However FreeBSD supports both, but the NFS/Microsoft one is the standard.

Re: FreeBSD Jails for Fun and Profit (2020)

#159
post #94

Earlier quoted context omitted.

And how is it mixing and matching these APIs? Given that there's an OCI-compatible runner for jails (runj, compatible with runc -- which is what docker uses to start containers), it seems to me that Docker isn't in actually using the flexibility afforded by the APIs here, but is just using a relatively fixed set of options. If I'm wrong: what is it using, and what problems is this flexibility solving?

I haven't tested runj but just from looking at it, it seems it is not fully compatible with everything that runc does because the OCI itself specifies a lot of Linux-specific functionality.

Can you provide some examples?

Re: FreeBSD Jails for Fun and Profit (2020)

#160
post #12

Earlier quoted context omitted.

Yes, but in a sense that's the essence of why the technology got left behind. Jails were a mechanism for expert admins to play with container ideas. What the market actually wanted was Docker. And what Docker needed was Linux containers (complicated, flexible, piecewise technology) and not jails, which were higher level abstractions (but yet not high enough) with jargon and framework assumptions that didn't match Doc…

The "market" did not want Docker. Docker as a product failed. There are many reasons why FreeBSD jails count not get out for FreeBSD land, one, very important thing is the Linux community's NIH attitude.

> The "market" did not want Docker. Docker as a product failed.

Docker as a paid product failed. Docker as a company is failing. "Docker" in the sense I meant (of the software people use to launch containers), is pervasive and dominant. It won. And jails, in comparison, "lost", because jails didn't really do what Docker wanted. And what the market wanted was Docker.

Post reply on HN