I present you, the NeXT edition of FreeBSD. :)

OP
B

Beastie7

Aspiring Daemon

Reaction score: 580
Messages: 695

His article reeks the old classic "Corp will takeover mah Unix" type of argument. Fortunately, the projects management won't allow such a thing; this isn't Linux. Also, he seems to be pigeon-holing FreeBSD into one domain, then framing his argument around that. No justification of his suggestion either.
 

cpm@

Moderator
Staff member
Moderator
Developer

Reaction score: 950
Messages: 2,140

His article reeks the old classic "Corp will takeover mah Unix" type of argument. Fortunately, the projects management won't allow such a thing; this isn't Linux. Also, he seems to be pigeon-holing FreeBSD into one domain, then framing his argument around that. No justification of his suggestion either.

IMHO, this kind of articles are totally necessary to know at first hand if such goal will be well received by people, whether they like or not BSD. Particularly well-founded opinions. So we must not take him as a UNIX hater ;)
 
OP
B

Beastie7

Aspiring Daemon

Reaction score: 580
Messages: 695

I just don't find his FreeBSD is not OS X, launchd isn't FreeBSD argument very convincing. I'd be nice if the poster counter-argued with how his suggestions are better in concept, not in preconceived use. The whole point (IMO) of launchd is to make FreeBSD a better general platform, although more server inclined. I could see this making life simpler for users.
 

cpm@

Moderator
Staff member
Moderator
Developer

Reaction score: 950
Messages: 2,140

I'd like to hear Hubbard's voice and know what he thinks about such article or similar after he reads to the last dot.
 

fulminemizzega

New Member

Reaction score: 2
Messages: 2

Let's start with background, because I may write bullshit:

I do not have the same depth of knowledge of V.R. from what I read in his "Why FreeBSD should not adopt launchd" article, let's say that I'm able to understand half of it, I never developed a complex C application for a Unix system, nor I'm able to understand the kind of issues you need to take into account when you design and implement and IPC mechanism, to my knoledge IPC is "something you use to let different processes exchange bits of information", and that, for example, by leveraging this idea you can create things like notifications for the whole system, which I understand is a big deal if you want to make things dynamic.
I think I've firstly exposed myself to Linux about 7 years ago, now I'm two years old Gentoo user: I started with it on a VM, then decided to use it also on a desktop and on my laptop (which, I recognize now, was a bad choice). Aside from the great learning experience it has been for me (and still is), because I had been forced to look into linux kernel configuration and also into some user-space components, I wanted to run Gnome 3 on it, which at some point made me switch to systemd forcefully.
Now, my point of view may be kind of ridiculous if compared to the one of a sysadmin of 10^(10^10) hyper-super complex bsd/linux/unix/who-knows-what server/saving-the-world systems (thus "mission critical" and unbreakable I suppose..), who has been at it since forever and since forever runs services by writing shell scripts of the most refined species, but I may understand why they think systemd is a mess. The day I tried to do the migration (I just ran a VM with gnome 3 and some server-ish things), I didn't really understand why I needed to, I had some issues, did the whole thing, got it booting, then rolled back because something was not working (probably it was just another of my faults). Then some time passed, I took some to read about that systemd thing, found the reasonings, then after having to write a shell script to run a simple rtorrent inside screen, I decided to give it another try with some willingness to use it and I started to really think about that the whole bunch of rants I was reading about systemd weren't really true, even if they came from maybe great experts in the field (I don't think experts write or say "suck/fuck/screw/fiasco-<insert name> without very good arguments to support their thesis). I liked the unit file format for services, I liked also the way systemctl displays services, I started using journalctl, and just felt it was the right way to do things. I never liked filtering logs with regexps ,every time I needed them I had to relearn how to use them, just for a simple task that maybe was not even needed because the service had his log elsewhere.
So to sum up my background: I'm a Linux desktop user, have had some experience with FreeBSD and use it indirectly with FreeNAS, with some basic programming, scripting and system administration skill, with basic knowledge of how theoretically should work, I like systemd but I really had to mess with (like... writing or understanding init scripts) other init systems (Gentoo rc.d, Debian init and Ubuntu's upstart) only a few times, but I also must admit that I like the simplicity of rc.conf in FreeBSD (and really find disturbing seeing a vm booting and waiting for dhcp on an interface blocking everything else), and that I've never written an rc.d script for FreeBSD.

Now to the point: V.R. may probably have read only the slides from the talk, but I watched today the whole video, and I found things he wrote that I think are wrong even from my level of knowledge. I'll go through it from the beginning, clearly skipping the parts I don't understand, I'll try to reference the article with the schema <section name>/# of paragraph.
<launchd: a chimera architecture> / #2-3 (that is from "In the context of OS X, launchd is, among other things" to "and proceed to infer and extrapolate a specific architecture as if it were fiat."):
The only thing I'm able to answer here is that the NextBSD developers chose Mach because some part of Mach VM is already in the FreeBSD VM (Hubbard/Macy says that in the video), so it's easy to add. Then, once you have Mach IPC, you can add many things on top of it that are already field tested by many users, and the last thing you get is launchd. So I think the reason why the developers have gone down this way is to reuse tested and working code/ideas as much as possible.
#4: I don't know what UCSPI is and I have not looked it up, but the problem is still there, because instead of linking to liblaunch you will link to libImplementingUCSPI, or not? Where is the "undesirable lock-in"? If you are locked in non-proprietary software, is that still an issue? Then what should an application developer do, not use any "facility" available on the platform he/she is developing on? I may understand linking to as few system specific libs as possible, but then has a developer who wants to target different OSes to write less functional applications to avoid "lock-in"? In this specific case, does linking to liblaunch on one platform really create an issue?
#6-7: Aside from the process type thing, V.R. at the end of #6 says that FreeBSD is primarily used for server and embedded systems, which I agree with (at least for the server part), in #7 V.R. says that launchd can only do lazy loading of services on demand, now I don't know if this is true, but for an embedded system, why would you ever boot everything up at once? Embedded systems do not run on battery (not only phones or tablets are power constrained), or do not change their state? I may understand that for a server, but not for an embedded system, but since "embedded system" in the end means everything and nothing, I and the author are probably thinking to different kind of embedded systems. However, at a certain point in the talk Hubbard mentions a case when he had a developer asking for how to start a service after everything else with launchd, and he goes on saying that probably the hardest thing for developers used to the old rc.d init is changing their mindset and getting out of the linear boot system concept. I think V.R. here has the same issue, and from what I've understood, both systemd maintainers and launchd advice against recreating the old style dependency system (I don't know if it's Poettering that said to someone that old way dependency is not supported anymore and to fix his application). I don't think that the old rc.d way is wrong and the "new" (not so much) idea of systemd/launchd is right, but it appears that the launchd way is better for complex systems (which is, at the end of the day, what Hubbard talks about), and by complex systems he means for sure desktops and mobile devices (but I don't think that save-the-world systems are that simple*, otherwise we wouldn't need books, courses and sysadmins to manage them).

* meaning that they would not benefit from having launchd/systemd

In #7 also there is this passage about daemontools and using it to restart services continuously until they all are running, I don't understand if V.R. just wants to say that even daemontools can act like a "standard eager service manager", or if he/she is saying that it is a good way to start a system while still having some launchd like functionality. I have to say though that the "let it crash" thing made me think of Frozen...
#8: This brings us to launchd not handling well non launchd daemons, while I think this can be improved, if you port every daemon to launchd is this still an issue? Does this porting require heavy involvement?
#9: (after the quote) The presence of "OtherJobEnabled" isn't a good thing for easying the migration from rc.d to launchd? Or the issue is just that since it exists, it will be abused?
#10: after watching the video, and considering that launchd handles cron functionality, why should it play well with crond? The (or one) point of launchd is centralizing system management, so that you don't need cron anymore. About the "LimitLoadTo" and "LowPriorityIO"... this looks just like V.R. needs to read documentation, they may be ambiguous but I think Hubbard mentions the latter in an example he made, and why it exists.
#12: This is the climax of the section, beginning since #4 and ending here. Then comes #13, and this is plain and simply false, as stated by Hubbard himself many times, like here (https://np.reddit.com/r/linux/comme...bard_sees_need_for_a_modern/cme6dh3?context=3), but also in the slides and in the talk. Parsing is not done in PID 1, and Hubbard many times says in the talk that PID 1 can not crash and for this reason it has to be really simple. From what Hubbard said in the talk, I infer that all the things V.R., or at least many of them, described in #4 to #12 are not in PID 1 but in launchctl (which does the parsing). This means that #13 is for sure false, while for #12 I can't say that because I've not read the sources, but it's very likely false. Still, another time, this launchd thing is not new, it works on many devices, as Hubbard said, if there were design or architectural issues, they would have already been found and fixed long ago. What I can say at this point is that this launchd architecture is not a chimera, by a long time it has been quite real.

<Mach: An anachronism> / #1-#5: (that is until "but they try to justify it on its own merits, too.") Hubbard/Macy states their reason for chosing Mach in the beginning of the talk (which I've already mentioned in previous #1). The #3... well... if OS X is Unix, then Apple has already dragged it into the 21st century with that IPC and it looks like it works well, so probably Hubbard and his team can do that for the 2nd time :) but this is just trolling. Some of this looks a bit like the criticism kdbus received (why this IPC, there's a better one like in 9P, it's bugged, ugly, nasty....)

<Neither Darwin nor BSD>/ : the answer to the big question has many answers... the simplest is that you can't run OS X on non Apple hardware without a continuous work of hacking (being there, done that, enjoyed it, but too much time consuming). Then I could say that since OS X is focused on desktop users, while it has many features that the NextBSD devs decided to port because they are good (or really good... the thing about libdispatch for example... when I saw that showed at some Apple event, I thought it was a really good idea, and seeing that now explained more in detail by Hubbard made me think even better of it), it does misses features that are really kernel related, like all the ZFS goodness (or even GEOM or geli, I still haven't read much about them). And also, ZFS can be a good desktop fs, and may be it could be used to reach something like this: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html (even though from what I know, ZFS deduplication is really heavy). So this project does have a sever identity crisis? I think that its developers have a really good idea of what they want to achieve, they want to achieve a more secure OS, which does not trust at all the applications it runs, that is able to manage multithreading in a good way, to simplify development of resource intensive applications, and really, if that's still nothing, they just want a place to experiment with FreeBSD with some really good ideas, maybe to try to improve FreeBSD. Hubbard explained in his talk his ideas about forking projects and then merging them later on.

I need to stop here, too long post, and I'm afraid to write too much bullshit at once. May you forgive me for my ignorance :D
 
D

Deleted member 48958

Guest


May be somebody know what happened with NextBSD? Is project dead now? Home page is broken, iso download link returns 404 error, no news from 2015...
 
D

Deleted member 48958

Guest


The website still works for me.
It works, but it's broken: "Menu" button is unclickable, main page background is broken:
Снимок экрана от 2016-07-26 02-07-08.png


In 2015 it looked like this
Снимок экрана от 2016-07-26 02-21-52.png


But project seems to be alive on Github page https://github.com/NextBSD/NextBSD ,
so may be they just don't want to maintain home page.
 

zspider

Aspiring Daemon

Reaction score: 112
Messages: 584

Looks dead in the water.

Although there are recent commits to the github.
 
Top