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

Ubuntu Linux Jail on FreeBSD 12.2-Release

wiki.freebsd.org

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#51

Post by arminiusreturns »

Denvercoder9 wrote: post #46
throw0101a wrote: post #28

Earlier quoted context omitted.

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc. And all are in one repo with tight coupling. For an "init system".

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

Please checkout the progression of Devuan if you are wanting to understand just how viral systemd is in modern linux. If it wasn't so tightly coupled, why did it take 2 years to decouple it?

https://sysdfree.wordpress.com/2017/08/16/112/

https://nosystemd.org/

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#52

Post by zrm »

Denvercoder9 wrote: post #46
throw0101a wrote: post #28

Earlier quoted context omitted.

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc. And all are in one repo with tight coupling. For an "init system".

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

Suppose I want to write my own competitor to systemd-resolvd. I want it to work with systemd-networkd, in the same way as systemd-resolvd does. Or just patch dnsmasq or unbound to be able to do that. Is there a stable interface for that? An RFC I can read? Any guarantee they won't change the interface and break my version, while they update both of theirs together?

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#53

Post by hedora »

accountofme wrote: post #48
djsumdog wrote: post #6

I wish there was a usable Docker Engine API implementation that could run containers in jails using zfs for image layering. There is a Docker for FreeBSD port, but last time I checked, it was super old. Having Docker as a first class citizen on FreeBSD would make it really incredibly as a server OS.

Having played with SmartOS containers using linux compatibility (not docker). I will say this: Use native containers for that OS. The slight differences that you will find, will drive you up the wall. They will be esoteric and happen at the worst time. And i should say I love SmartOS, it is a really cool bit of tech... I just love simplicity more, and a compatibility layer is never simple.

Yeah. I can’t even get some Linux containers to run under $ESCOTERIC_DEBIAN_BASED_DISTRO.

The ancient rhel something something doesn’t like the debian other thing, and I even saw a changelog about broken kernel compatibility and flipping a flag in proc or cmdline but then I forgot what it said.

Whatever. Life is short. Docker is in no way independent of the host kernel. Spend time debugging something else.

SmartOS is great though. I wish they’d take over the world.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#54

Post by cchdmdldkdjfdk »

accountofme wrote: post #48
djsumdog wrote: post #6

I wish there was a usable Docker Engine API implementation that could run containers in jails using zfs for image layering. There is a Docker for FreeBSD port, but last time I checked, it was super old. Having Docker as a first class citizen on FreeBSD would make it really incredibly as a server OS.

Having played with SmartOS containers using linux compatibility (not docker). I will say this: Use native containers for that OS. The slight differences that you will find, will drive you up the wall. They will be esoteric and happen at the worst time. And i should say I love SmartOS, it is a really cool bit of tech... I just love simplicity more, and a compatibility layer is never simple.

https://en.wikipedia.org/wiki/SmartOS

If linux comes out with tools remotely approaching the quality of either freebsd or solaris planning everyone should drop what they're doing to go watch. Linux ain't gonna improve itself, and the pains of docker are an excellent entry to pressuring linux devs to do anything that can improve userspace experience, an otherwise deeply unlikely prospect. It took them more than a decade to implement basic jailing after BSDs and the tech is still, shall we say, extremely rough....

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#55

Post by yjftsjthsd-h »

hedora wrote: post #53
accountofme wrote: post #48

Earlier quoted context omitted.

Having played with SmartOS containers using linux compatibility (not docker). I will say this: Use native containers for that OS. The slight differences that you will find, will drive you up the wall. They will be esoteric and happen at the worst time. And i should say I love SmartOS, it is a really cool bit of tech... I just love simplicity more, and a compatibility layer is never simple.

Yeah. I can’t even get some Linux containers to run under $ESCOTERIC_DEBIAN_BASED_DISTRO. The ancient rhel something something doesn’t like the debian other thing, and I even saw a changelog about broken kernel compatibility and flipping a flag in proc or cmdline but then I forgot what it said. Whatever. Life is short. Docker is in no way independent of the host kernel. Spend time debugging something else. SmartOS is…

> Yeah. I can’t even get some Linux containers to run under $ESCOTERIC_DEBIAN_BASED_DISTRO.

I would love any details you can provide; that sounds interesting. (I'm an OS nerd)

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#56

Post by yjftsjthsd-h »

nix23 wrote: post #37
centimeter wrote: post #29

Earlier quoted context omitted.

FreeBSD's point of distinction is that it's carefully designed and fitted together, compared to Linux's comparatively heavy use of glue. I also haven't heard credible reports of it being slow, except for things it's not really used for (like drivers for consumer wifi cards).

Well Linux is just a kernel, so it's a bit unfair to call it glued together...but the rest (a ditro)...lot of glue and clay...sometimes also pure mud.

Nobody uses just the kernel alone, so I think it's fair to consider the other required components when looking at the system.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#57

Post by yjftsjthsd-h »

etaioinshrdlu wrote: post #35
throw0101a wrote: post #28

Earlier quoted context omitted.

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc. And all are in one repo with tight coupling. For an "init system".

It sounds like systemd wants to be an OS kernel.

No, it wants to be 90% of the OS except the kernel (the other 10% is libc and a package manager).

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#58

Post by darthrupert »

centimeter wrote: post #29
zokula wrote: post #12

Earlier quoted context omitted.

> Having Docker as a first class citizen on FreeBSD would make it really incredibly as a server OS. Now if only if FreeBSD wasnt an slow, unstable, glued together example of an OS.

FreeBSD's point of distinction is that it's carefully designed and fitted together, compared to Linux's comparatively heavy use of glue. I also haven't heard credible reports of it being slow, except for things it's not really used for (like drivers for consumer wifi cards).

That’s what systemd is giving the Linux world, though. A carefully designed system for a lot of very essential things, so that distros will need to apply less glue.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#59

Post by mulmen »

yjftsjthsd-h wrote: post #56
nix23 wrote: post #37

Earlier quoted context omitted.

Well Linux is just a kernel, so it's a bit unfair to call it glued together...but the rest (a ditro)...lot of glue and clay...sometimes also pure mud.

Nobody uses just the kernel alone, so I think it's fair to consider the other required components when looking at the system.

But FreeBSD is an operating system. The userland and kernel are developed together, in the same source tree AFAIK. With Linux you have to glue a user land on to use the kernel, which is a "distribution" which is actually an operating system.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#60

Post by microtonal »

hedora wrote: post #53
accountofme wrote: post #48

Earlier quoted context omitted.

Having played with SmartOS containers using linux compatibility (not docker). I will say this: Use native containers for that OS. The slight differences that you will find, will drive you up the wall. They will be esoteric and happen at the worst time. And i should say I love SmartOS, it is a really cool bit of tech... I just love simplicity more, and a compatibility layer is never simple.

Yeah. I can’t even get some Linux containers to run under $ESCOTERIC_DEBIAN_BASED_DISTRO. The ancient rhel something something doesn’t like the debian other thing, and I even saw a changelog about broken kernel compatibility and flipping a flag in proc or cmdline but then I forgot what it said. Whatever. Life is short. Docker is in no way independent of the host kernel. Spend time debugging something else. SmartOS is…

To give this argument some more meat with an example: some older glibc versions use vsyscalls and not vDSO. And kernels in some modern distributions disable vsyscall emulation. This is a problem because people use CentOS 5 or 6 images to build binaries that are compatible with many historical glibc versions.

If the host system does not enable vsyscall emulation, running binaries on such old distributions will lead to segfaults. (Which can be resolved by booting the host kernel with vsyscall=emulate.)

Post reply on HN