Date: Mon, 11 Jan 2016 23:53:59 -0800 From: Hubbard Jordan <jkh@ixsystems.com> To: Dan Partelly <dan_partelly@rdsor.ro> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@ntlworld.com>, Dmitry Sivachenko <trtrmitya@gmail.com>, Mark Heily <mark@heily.com>, Peter Beckman <beckman@angryox.com> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> In-Reply-To: <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro> References: <5687D3A9.5050400@NTLWorld.com> <CAGfo=8kXzNVKy9gx0jkME4iRRyrgrsfpPnW3nYrZC0gysapPcg@mail.gmail.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <alpine.BSF.2.20.1601081020270.34827@nog2.angryox.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
> I personally use those terms a bit tongue in check. BSDs have very = limited manpower , and so they are forced to use source code from = foreign OSes in the most straightforward way possible, which means = wrappers . (else see the fiasco with the DRM drivers in FreeBSD so far, = there is plainly too much effort to port Linux DRM code to BSD without = wrappers and adapters. Dragonfly did it the right way ) . So , you need = to wrappers and adapters to Linux specific API=E2=80=99s and data = structures to support DRM , OFED and god knows what else.=20 I don=E2=80=99t disagree with the =E2=80=9Climited manpower=E2=80=9D = statement (it=E2=80=99s manifestly obvious), but perhaps a less negative = way of looking at this is to say that since OSes have become largely = commoditized (a natural consequence of changing educational trends in = computer science), we=E2=80=99re better off not reinventing any wheels = and simply adopting whatever off-the-shelf technologies and solutions = allow the mission goals to be achieved in the shortest period of time. > But this is a general problem not only limited to Linux.=20 Indeed. There=E2=80=99s also arguably a sweet spot between =E2=80=9Cemula= te all the things=E2=80=9D (and convince some segment of your own fan = base that you=E2=80=99re dying because nobody uses the =E2=80=9Cnative = offerings=E2=80=9D) and =E2=80=9Cemulate the most strategic things=E2=80=9D= vs spending so much time re-inventing wheels for the sake of it that = you miss the window of relevance entirely. > FreeBSD has NDIS emulation to support some Wifi devices.=20 Yes, the infamous =E2=80=9CProject Evil=E2=80=9D. :) I don=E2=80=99t = know how much that has actually been used in production scenario, but it = was an interesting project. > FreeBSD has Solaris API/ datastruct wrappers and adapters to support = ZFS/ Which has been a pretty huge success, really. ZFS is very stable on = FreeBSD (comparatively speaking to ZFS on Linux) and has opened some = entirely new markets for it. Had FreeBSD insisted on =E2=80=9Cdoing it = natively=E2=80=9D it=E2=80=99s pretty arguable that OpenZFS would have = gone its own way and ZFS would be an unstable science experiment that = nobody would trust their bits to. Sure, there is still some weirdness = with ARC behavior and the memory consumption of features like Dedup = (which is more OpenZFS=E2=80=99s fault than FreeBSD=E2=80=99s) but the = shims work well and make it possible for the same code base to build on = Illumos, which is still the reference code base, and FreeBSD. I=E2=80=99d= say this has been a Big Win. DTrace has also been a similar win, and is more =E2=80=9Cforeign DNA=E2=80= =9D in FreeBSD. You=E2=80=99d like to see more of Solaris=E2=80=99 SMF = in FreeBSD, and I agree. I wouldn=E2=80=99t mind Solaris Doors, either. = It would have made NDMP support far more of a drop-in than it has been = so far. I think we=E2=80=99re in violent agreement so far on the = subject of Solaris DNA! > NextBSD has now dragged =E2=80=9Chalf" of mach kernel inside to : 1. = Implement a better and more flexible IPC mechanism than Unix domain = sockets / posix message queues (Truth is, IPC sucks in Linux and BSDs. = It is my opinion that Windows LPC/ALPC are way better designed. and 2: = To easily port launchd/notifyd/whateverd That=E2=80=99s mostly all true, though I think Mach IPC=E2=80=99s = feature set deserves just a wee bit more respect than it traditionally = gets (or is fully described above). =20 The fact is, IPC on Unix has traditionally sucked and nobody has yet to = provide an alternative to Mach IPC which ticks all the same boxes. A = hierarchical namespace that can be used to create privilege domains = (providing a very key ability to control who can talk to who) - Check. = Supports service discovery as an intrinsic property without the presence = of a filesystem (e.g. pre-mountroot) - Check. Provides audit trailers = in every message that make it possible to validate who you=E2=80=99re = talking to and create =E2=80=9Ctrusted delegates=E2=80=9D for certain = services that would otherwise be forced to be in the kernel - Check. = The ability to pass shared memory descriptors out-of-band for large = messages - Check. That=E2=80=99s not even a full list, but it covers = some features that OS X and iOS use in many different ways to good = effect. Believe me, if there was something better, with the right high-level = semantics (which alternatives like L4 IPC do not provide) combined with = low-level capabilities like allowing the kernel to talk to userspace = using the very same IPC mechanisms, we=E2=80=99d use it. Since there = isn=E2=80=99t, we stick things like XPC (which NextBSD is doing a = clean-room implementation of) on top of Mach IPC to avoid the horror of = using MIG and doing RPC programming from the 1980s, and we spend the = time we=E2=80=99d otherwise have to spend creating an entirely new and = unproven IPC mechanism (which might very well fail to impress anyone = after we finished) and focus instead on creating the services that use = it. Seems like a reasonable example of =E2=80=9Ccode re-use=E2=80=9D to = me! > Now this is all good and dandy, but who will audit all this code for = bugs and security ? Some bugs will become manifest fast, but others may = lurk in those layers for years. I agree, which is actually all the more reason to adopt existing code. = It=E2=80=99s been vetted. It=E2=80=99s been tested. It=E2=80=99s been = used for many years across many different releases of software on = literally millions of devices. Seriously, how much better than that can = anyone reasonably expect or hope for? If there=E2=80=99s a way to set = the bar even higher for auditing / proving the efficacy of a body of = code, I=E2=80=99d be more than willing to learn about what that is. You = can probably imagine that a lot of people, both paid and unpaid, have = attacked the hell out of every byte of code in iOS and OS X. The = jailbreaking community alone has certainly had the incentive, and with = incentive comes inventiveness. > =E2=80=94 problem : binary code reuse --- > 1. Many utilites from BSD base are monolithic and closed, yet they = provide higher level interfaces to OS configuration. It is my opinion = that=20 > all this functionality should be expose as libraries & demon services. Violent agreement, for the most part. I don=E2=80=99t know how we=E2=80=99= d define =E2=80=9Call the functionality=E2=80=9D of course, and the idea = of wrapping everything from df(1) to yacc(1) would obviously cause = someone to question the sanity of any person proposing such a blanket = approach to the utilities in question, but you=E2=80=99d hardly be the = first person to suggest wrapping or re-writing all of the more useful = building-block commands in terms of libraries and services. Taking an = aggressively SOA-oriented approach is obviously what has allowed = companies like Amazon to encompass the almost unbelievable amount of = territory they now do without collapsing under their own weight, so if = anyone needs an existence proof, there it is (along with countless = others). > This is the very base upon which enterprise grade tools are built. = Libxo is not a proper solution to this problem. It should not exist in = FreeBSD base, yet somehow it slipped inside, and I seen on some papers = from BSD conferences that some even discussed to put it inside the OS = kernel . I frankly cant imagine what those ppl are/wehre thinking.=20 Oh, I dunno, I think you=E2=80=99re being a little harsh. I=E2=80=99ve = looked at libxo and I think it=E2=80=99s reasonable enough as a generic = text output library. But that=E2=80=99s all it is. It=E2=80=99s not a = policy, it=E2=80=99s certainly nothing like what we=E2=80=99re = describing above, it=E2=80=99s just a building block. Perhaps the = bigger criticisms should be reserved for what it=E2=80=99s not, instead: 1. It=E2=80=99s not a plan to actually take a set of commands like find, = xargs, du, ls and so on and impose some structure on them. It=E2=80=99s = certainly not a proposal which even attempts to identify =E2=80=9Cthe = right commands=E2=80=9D and postulate a set of use case scenarios that = will allow the user to create some truly interesting shell scripts which = use these new structured input/output capabilities to do things not = formerly possible. I speak from a little experience here as we did that science experiment = back around 2007 or so, just to see what it might look like to create a = subset of Unix command which all spoke XML natively, and the results = were surprisingly elegant when able to decouple =E2=80=9Cmechanism=E2=80=9D= from =E2=80=9Cpresentation=E2=80=9D (a command which simply stats a = file and presents the information from it as an XML blob doesn=E2=80=99t = have to worry about multi-column output or human readability concerns - = that=E2=80=99s for another tool further down the pipeline to do). I = kind of have no interest in this topic, however, because it just sets = off the =E2=80=9Cyou can have my 80 column, ISO-Latin1 text commands = when you pry them (and my VT100 terminal emulator) from my cold, dead = fingers!!=E2=80=9D crowd. :-) 2. It doesn=E2=80=99t provide one of the APIs MOST lacking from *BSD = right now, which is how to set and get structured preference information = for a utility of any complexity. Yeah, I=E2=80=99m talking about the = equivalent of CFPreferences here (and the services equivalent of = cfprefsd) - since everyone already expects me to quote Apple APIs, why = disappoint them? :) The biggest consumers of structured data are = actually services trying desperately to find a KVS somewhere, not people = writing shell scripts. Oh yeah, you touch on that later. More in a = second. > =E2=80=94 problem OS configuration and updating in a higly concurrent = world --- > 3. Transactional OS wide configuration databases.=20 Which, of course, we use every day with FreeNAS. When you=E2=80=99re an = appliance, you=E2=80=99re not allowed to look through half of /etc (or = export half of /etc as part of a =E2=80=9Csave configuration=E2=80=9D = operation) and yeah, we do it through a database abstraction layer that = lets anything from postgres to mongodb provide the actual storage. I = suppose it=E2=80=99s arguable whether the =E2=80=9Cconfiguration = database library + service=E2=80=9D actually needs to live in base, but = there are so many utilities that will continue to roll their own = otherwise, it seems silly not to. > 4. In a world where hundreds of machines, bee-it physical or virtual = are interconnected and talking to each other , safe concurrent access to = OS configuration will become soon very important. This is already the case. Most chef / puppet / vagrant setups bend over = backwards to try and impose order on what are otherwise rather = uncooperative OS instances deployed in the hundreds or thousands. > 4. A new high performance IPC system should be introduced IMO. It = should allow both fast synchronous operation ( like solaris doors) and = asynchronous operations, working with kevent/kqueue. It should allow = kernel endpoints, and should cater to security concerns. It should be a = minimal API , not a full buss Right. Mach IPC. :-) > 5. a user mode pub / sub message bus. use the IPC api to implement a = high performance , OS wide, message bus. It should present clear = abstractions to clients, to insulate them from using syscalls directly. = It should sum some already existing mechanisms, such as devd. XPC + system notifications do a pretty good job of this. It depends on = what you=E2=80=99re =E2=80=9Csubscribing=E2=80=9D to. A distributed = notification? Some peer-to-peer communication from another system = service? A configuration knob that can change dynamically? It=E2=80=99s = tempting to try and fold them into a single pub/sub namespace, but = it=E2=80=99s not clear to me that this is a good thing or not, or if = it=E2=80=99s simple better to allow each of the above services to = provide a nice call-back mechanism that works with a universal glue = library (like, *cough cough* XPC and/or libdispatch). > =E2=80=94 problem of service management and fault management: >=20 > 6. Much needed components of enterprise.=20 Do you know how much of Solaris SMF escaped into Illumos before Oracle = slammed the door there? I=E2=80=99ve honestly never looked. > I raise some of those problems in past. Especially the problem of = binary code reuse . My perception was that nobody really gives a damn. I think the problem with the FreeBSD community in general is that there = ARE people who give a damn, but they are essentially blocked into = ineffectiveness by another caucus who doesn=E2=80=99t want any of these = things to change. It=E2=80=99s like the Senate - you have Republicans = and Democrats who see eye-to-eye on almost nothing and their principle = power is in being able to block whatever initiatives =E2=80=9Cthe other = side=E2=80=9D proposes and, well, Democracy Inaction. :-) > Others complained that people talk and nobody contributes code , yet = when you contribute code they dont look at it with months, and so on. Hence us trying to just prove the =E2=80=9Cworking code=E2=80=9D = requirement first in NextBSD and if nobody looks, well, that=E2=80=99s = OK too - we can still use it for our own purposes. Maybe some other = Appliance vendors will jump into the mix and use it for their purposes = too. We have more progress to make before I=E2=80=99d even try to = =E2=80=9Csell=E2=80=9D it for any purpose whatsoever yet, however. One = step at a time. > Yes. See, One thing I hear for decades is the Unix desktop. Which I still think will probably never succeed for as long as the X = Window System is in the mix because its APIs, and the mechanisms it = forces into place, are just a horror show, even with all the KDE / Gnome = libraries and services that folks tried to add on top to paper over the = differences. You can=E2=80=99t polish a turd, you can only paint it. = :-) And yeah, I wrote Window Managers (like awm) and widget libraries = and such Back In The Day for X. I was a believer. Then I tried to port = Lotus 1-2-3 to it. :( - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?76E6AF2A-917B-41EB-883A-C27AB2BB9F71>