Live data from Hacker News

Migrate Everything from Linux to BSD

unixsheikh.com

151–160 of 169 posts

Re: Migrate Everything from Linux to BSD

#151

Earlier quoted context omitted.

I didn't understand that argument at all. The GPL mandates that companies release their code. That's it. There's no rule that the code has to be upstreamed or that the companies need to try to make other projects use it. To the extent such behavior is incentivized, it should be incentivized just as much with more permissively-licensed code.

I always understood the argument to be that for rapidly changing projects you might be forced to upstream your GPL code or face an uncomfortably high maintenance burden of constantly rebasing it. Linux almost purposefully does this, it's kind of like a "soft" vendor lock in. Linux kernel interfaces change regularly, and if you don't upstream your code you need to commit time to fixing what breaks. If you upstream, th…

But imagine if Linux used the BSD license and FreeBSD used the GPL license. Absent any other philosophical changes to how each project was managed, I don't think the incentives to upstream projects would be any different. Sony would dump a bunch of code on their website somewhere (which would be excellent, because others could study and use it as desired), and little else would change.

It's about project management, not licenses.

Re: Migrate Everything from Linux to BSD

#152

Earlier quoted context omitted.

> Gnome now refuses to run without systemd. Is that true? The gentoo documentation says that you can chose your init system independently of your desktop manager, and puts openrc+gnome as an example: https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd/Gen... You can also install GNOME on OpenBSD, which of course does not run systemd.

Not GNOME itself, but Gnome Display Manager: > After the transition from GNOME 2 to GNOME 3, configuring GDM is only possible through systemd as it no longer supports other init systems. https://access.redhat.com/documentation/en-us/red_hat_enterp...

not a big deal then, there's plenty of display managers, and you don't even need one to use gnome

Re: Migrate Everything from Linux to BSD

#153
post #81

Earlier quoted context omitted.

Systemd is a replacement for Unix. Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel +…

> Systemd is a replacement for Unix... I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland. 'Doing many things, none of them well' is actually the opposite of UNIX. https://en.wikipedia.org/wiki/Unix_philosophy

This needs to be stated yet again apparently - systemd is not one monolothic binary, it's a collection of tools in one repository.

Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX".

This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.

Re: Migrate Everything from Linux to BSD

#154

Earlier quoted context omitted.

> Systemd is a replacement for Unix... I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland. 'Doing many things, none of them well' is actually the opposite of UNIX. https://en.wikipedia.org/wiki/Unix_philosophy

This needs to be stated yet again apparently - systemd is not one monolothic binary, it's a collection of tools in one repository. Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX". This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fa…

A monolith does not necessarily mean a single binary.

Re: Migrate Everything from Linux to BSD

#155
post #38

Earlier quoted context omitted.

systemd isn't an init system and doesn't pretend to be one [note] - it's OS middleware with ambitions to becoming a distro unto itself. The systemd project assumes responsibility for numerous aspects of the system that have no technical justification for being under the same project umbrella. You might like systemd-homed, for instance, but it doesn't really have anything to do with the functions of init. Calling it a…

Honest question, if nobody likes systemd, then why is it still around and why is it so difficult for me to find a distro that hasn't adopted it?

[deleted]

Re: Migrate Everything from Linux to BSD

#156
post #42

Earlier quoted context omitted.

I noticed that, too: the author doesn't mention the many-splendored versions of *BSD. My personal favorite is FreeBSD. I like Linux, but I have mixed feelings about systemd, especially when I discovered that systemd runs its own DNS server, which prevents the DNS server I wrote from binding to port 53 using INADDR_ANY. Instead, I had to write code to enumerate the interfaces & corresponding IP addresses & bind to eac…

You know you turn that DNS server off by adding "DNSStubListener=no" to /etc/systemd/resolved.conf right?

Thanks for the tip.

It wasn't quite the solution I was looking for. I wanted my DNS server to "just work" for people who downloaded it—I didn't want to force them to re-configure systemd to accommodate my software.

Tweaking my software to accommodate systemd.resolved took ~4 hours. It was an enjoyable dive, but I'd rather not have had to do it on the first place.

I continue to think it's a bit of an overreach for Fedora to include a DNS server by default.

Re: Migrate Everything from Linux to BSD

#157
post #32

> DNS over HTTPS is by itself bad enough, and highly criticized with good reason The criticisms of DoH seem to be around removing the ability of third parties to snoop on your DNS queries. Am I missing something here? Like, yes, some of the use cases outlined in the linked wiki article [0] are arguably legitimate (parental controls, cybersecurity identification of C&C nodes), but then we quickly move into murkier ter…

If you want to prevent MitM attacks, run a local DNS server with DNSSEC. DoH is a trend in the wrong direction. The more IoT garbage begins using DoH, the less control over your privacy you will have. Solutions like pi-hole are rendered useless by DoH.

Since virtually none of the most popular domains are signed, going to the trouble of installing a local DNSSEC server isn't actually going to protect you from anything. Meanwhile: if you're in North America, your ISP is almost certainly collecting and warehousing your DNS queries, and DoH immediately breaks that. Plenty of people use DoH through Pi-holes, for what it's worth.

Re: Migrate Everything from Linux to BSD

#158
post #92

Earlier quoted context omitted.

I was careful not to include any value judgements in my comment. I simply wanted to lay to rest this "init system" business. However, you ask a good question. Lots of people do like it, supposedly. But I think there's a large clue to its controversial nature in that people still call it an "init system", and pointing out that it isn't is interpreted by some as an attack. Basically, it started out as an init system, w…

> Basically, it started out as an init system... But systemd started to expand into its "middleware" position, absorbing vital system functions like udev. Not true. From the start it was positioned as much more than an init system. This is clear just skimming the blog post announcing systemd http://0pointer.de/blog/projects/systemd.html Among other things, it talks about: -deferring launch of some services until they…

Sure, but most of that introductory post was about service management, and mount management, which are two areas the init system was traditionally heavily involved in. Sure, the init system might not technically have concerned itself with either, but a lot of the ordering considerations were very heavily concerned with both of those.

Now, no one will argue that systemd's service management capabilities far exceed what most historical init systems did. Heck, the traditional init system had interior service management to window's Service Control Manager implementation, since the classic init could not for example give a list of running services. And systemd is far more flexible and feature rich than Window's options now.

systemd-boot and timedated on the other hand are pretty darn disconnected from anything a classic init system was concerned with. It does feel like a lot of the non service/mount management parts of systemd are basically a grab bag of random stuff.

Re: Migrate Everything from Linux to BSD

#159
post #122

Earlier quoted context omitted.

Split DNS is a stupid, stupid idea. But DoH doesn't sound like an improvement.

It was a fine simple solution until DoH. In some internal environments the internal traffic volume can be much higher than the few services that might be publicly exposed. Sure lots of ways you could do it - get a fat edge firewall to hairpin the traffic + support Internet access but you end up paying a lot more for all the threat licenses on the oversized edge. Could add many more tiers, maybe more translations or o…

Hiding a DNS entry doesn't do anything to hide the machine. How long do you think a newly exposed IP address, without a DNS entry, will last before it is probed?

Re: Migrate Everything from Linux to BSD

#160
post #143
post #125

Earlier quoted context omitted.

You can use Bhyve and run Docker in a Linux virtual machine. Docker works similarly under MacOS using the Hypervisor Framework. FreeBSD would need to radically change in order to implement Docker natively.

FreeBSD had "containers" - jails - a decade before linux: https://docs.freebsd.org/en/books/handbook/jails/ I still don't understand why Docker was not made to run on jails as well.

I'm not sure the default jail utility is quite as flexible as what Linux namespaces+cgroups can do. It does look like most of what really matters does exist in some form, and I'd guess any important cases that don't exist could be fixed with a few new simple sysctl options.

However, BSD's do not guarantee that their userlands will work with a mismatched kernel. Sure, it often does work, hence why jails only give a warning on mismatch rather than refuse to run at all.

Also containers are most useful when most containers you want are actually available for your platform. Unless you use the Linux Emulation features, I'd suspect that relatively few containers would be mode available to run on FreeBSD. And the problem with Linux personality systems is that while many programs will work fine with them, there will always be some Linux syscalls that are unimplemented, or have important limitations/differences. So while many programs may work, some will not work. Even if the system call is fully supported, not all use cases will be. For example, not every file system Linux supports will be mountable, and programs could be using loopback mounts that need such support for weird reasons (I'd bet has made an app-bundle system for linux that relies on loopback mounting ext4).

There is a reason why Microsoft abandoned the personality like implementation of WSL1 in favor of virtualization for WSL2. Now admittedly, things are not nearly as bad on FreeBSD, since implementing one Unix-like personality in a different Unix is going to be easier and work better than trying to implement it on a decidedly non-Unix kernel. But even so, there will always be some programs (however obscure) that won't work right, while virtualization can largely avoid that. (Albeit with new limitations like not being able to easily access host hardware).

Noth of the above is at all a dealbreaker. containerd and docker support windows containers which have many of the above mentioned concerns, and many additional ones like the restrictions on distributing the windows base images.

What really needs to happen for jail support for docker is to come up with the FreeBSD specific options for the OCI spec, implement an OCI runtime based on jails, add support for setting the OS specific options in containerd, and implement needed network support in dockerd. (containerd leaves networking setup to its caller, as docker has different opinions than kubernetes for example).

The containerd people will almost certainly not object to the needed patches. If I had to guess, the docker maintainer's big concerns over a moby patch will be the overhead of supporting the needed patches (since FreeBSD will rightfully be seen as far more niche than Linux), and that the end-user experience of various docker command lines work more or less as users expect. (I.e. not more different from docker-on-linux than docker-for-windows-containers is). None of this is at all insurmountable.

Post reply on HN