[FUG-BR] Fwd: Re: relaunchd: a portable clone of launchd

[Otacílio]

Oi pessoal

Vi o email a seguir na lista dos hackers e algumas coisas me chamaram a 
atenção. Uma delas é que o autor aponta alguns pontos que, segundo a 
visão dele, o FreeBSD precisa resolver no futuro. Um dos pontos é o 
sistema de comunicação entre processos, o IPC. Eu queria que alguém mais 
experiente comentasse esses pontos. Principalmente as deficiências e o 
que precisa ser feito. Outra coisa que me chamou a atenção é que ele diz 
que mesmo quando alguém fornece código, ele passa um tempão para ser 
revisado, que tem pouco manpower, etc.  Dá até vontade de tentar 
escrever algo, pois eu tenho bons skills em programação, mas não tem 
como desenvolver código para o kernel sem a orientação de alguém 
experiente sobre as deficiências e a organização do dele. Eu até comprei 
o livro The Design and Implementation of FreeBSD Operating System, mas 
acho que ele fica um pouco aquém de explicar os subsistemas do kernel, 
de um ponto mais próximo ao programador e menos teórico.


[]'s
-Otacílio
-------- Mensagem encaminhada --------
Assunto: 	Re: relaunchd: a portable clone of launchd
Data: 	Mon, 11 Jan 2016 14:25:52 +0200
De: 	Dan Partelly <dan_partelly em rdsor.ro>
Para: 	Jordan Hubbard <jordanhubbard em icloud.com>
CC: 	FreeBSD Hackers <freebsd-hackers em freebsd.org>, Jonathan de Boyne 
Pollard <J.deBoynePollard-newsgroups em ntlworld.com>, Dmitry Sivachenko 
<trtrmitya em gmail.com>, Mark Heily <mark em heily.com>, Peter Beckman 
<beckman em angryox.com>



> It’s this latter point that makes me roll my eyes a bit whenever folks use phrases like “the linux way” or “the BSD way” since I’m not entirely sure that those “ways”, at least not as I first heard them articulated back in the 1990’s, actually exist anymore.

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’s and data structures  to support DRM , OFED and god knows what else.

But this is a general problem not only limited to Linux.

FreeBSD has NDIS emulation to support some Wifi devices.
FreeBSD has Solaris API/ datastruct  wrappers and adapters to support ZFS/
NextBSD has now dragged  “half" 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

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.

> What problems are we here to solve, and what are the specific details of those problems?”

It is my oppinion that FreeBSD needs to solve the following techical problems in the future:

— 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
all this functionality should be expose as libraries & demon services. 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.

2. Of secondary importance is to build some demons to allow access to geom, network , wifi management and so on and  implement a proper auto mounter . Let go to the 80s
and not use scaffolding of shell scripts to implement any of those.

Those two points also help a great deal towards having softtware appliances which has only what you need and nothing else on them.

— problem OS configuration and updating in a higly concurrent world ---
3. Transactional OS wide configuration databases.

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.

— problem OS wide IPC mechanism to build a high performance pub/sub system , to cope with the very dynamic world we move forward.

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

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.

— problem of service management and fault management:

6. Much needed components of enterprise.
  
Frankly, I like the direction Solaris took with Service management and faults management.

> What I DO know won’t move the ball forward (on any field, in any game) is arguing about this like it was a religious debate of some sort, where sweeping generalizations are preferred over far more pragmatic questions of “What problems are we here to solve, and what are the specific details of those problems?”

I raise some of those problems in past. Especially the problem of binary code reuse . My perception was that nobody really gives a damn.   The answers where interesting: libxo is in base because someone coded it , libxofication of utils proceeds in BSD , no matter that is a half assed solution which offers a fast hack to appliance vendors like juniper mostly,  Others complained that people talk and nobody contributes code , yet when you contribute code they dont look at it with months, and so on.



> In my last job, a lot of the questions revolved around “how do we stick this OS into mobile devices with small batteries?” and those sorts of pragmatic concerns informed a lot of our engineering work.

Yes. See, One thing I hear for decades is the Unix desktop. And everybody and their mother started to write Windows managers, desktops , whatever. We have OSes like PCBSD, which likes to masquerade itself like a desktop. Yet it seems that nobody realised that a modern desktop , one which is not a Rupe Goldberg contraption, or even worse, the software frankenstein’s monster  depends heavily on almost all the probem domains I outlined above. Ironically, the some of the same base technologies which can be used
to driver enteripise features like service management and fault management, would enable the polar opposite, the user desktop.

Yet what we see instead of someone asking those questions is people jumping into coding layer after layer of half assed solutions, which only make the situation worse.

If people would at least agree on what has to be done, some would surely study those problems and find some cool solutions to implement.


I like your NextBSD effort, save the fact you guys dragged half of Mach kernel in it. I can understand why you did it, but I dont have to like it. I think a new slim IPC mechanism
should be written , and that the major enterpises depending on BSD should fork money to cover the development costs. Im happy that they use BSD techs, but with very few
exceptions they contribute almost nothing back.



> On 10 Jan 2016, at 20:32, Jordan Hubbard <jordanhubbard em icloud.com> wrote:
>
>
>> On Jan 10, 2016, at 2:36 AM, Dan Partelly <dan_partelly em rdsor.ro> wrote:
>>
>> Copying the linux way of doing things should not be a goal of the BSDs.
>
> I’ve been trying to stay out of this since the discussion has, at least in points, seemed a little on the “fnarr!  fnarr!” polemic side (rather than focusing, as one would hope to see in a group called “Hackers”, on the engineering details and specific technical pros-and-cons of each approach), but I guess I can no longer resist.  As one of the “launchd stake-holders” in the discussion, and one I hope to have at a conference in the near future since email is a terrible communications medium for really getting ones point’s across (and avoiding lots of points that exist in the mind of the reader but not your own), let me just say that our goals with NeXTBSD continue to be the following, though not necessarily always in the following order:
>
> 1. Stay in sync with FreeBSD-current, just to keep divergence to a minimum
>
> 2. Get all of the base technologies we are targeting (launchd et al) fully working and as faithful in implementation to their upstream origins (for the exact same reasons as #1) as possible.  We’re not slavishly following Apple, we’ll take any suitably licensed technology that achieves our goals (see point #4).
>
> 3. Start migrating all of the older facilities, like /etc/rc and preferences files, to the new models - this one is really the “long pole” and why we’re just staying quiet until this work is largely completed and ready to show, since otherwise you’re largely debating the pros and cons of vaporware vs vaporware.
>
> 4. Use the specific and pragmatic world of Enterprise and Software Appliance requirements to drive the feature set of the technologies we choose and the urgency with which we pick them.
>
> It’s this latter point that makes me roll my eyes a bit whenever folks use phrases like “the linux way” or “the BSD way” since I’m not entirely sure that those “ways”, at least not as I first heard them articulated back in the 1990’s, actually exist anymore.
>
> Yeah, BSD has /usr/src and Linux has collections of packages and a distro-centric model of looking at the universe, but those are increasingly superficial distinctions when compared to the far more pertinent distinctions today around *what* is being packaged and to what purpose.  What do application stacks look like in the year 2016 and forward?  How does mass-deployment work on your OS?  Where are the privilege domains around disparate collections of software drawn, and how do you manage them?  Do you have effective security models for allowing entirely untrusted software to run on your OS?   How are you managing storage in clustered / hybrid (local + cloud) environments, and how hard is it to bend the OS to your will as a DevOps person tasked with any or all of the above?
>
> I’m not pretending to have answers to even half of those questions myself, don’t get me wrong, but I think the questions are important just to staying alive.   In my last job, a lot of the questions revolved around “how do we stick this OS into mobile devices with small batteries?” and those sorts of pragmatic concerns informed a lot of our engineering work.  My current job asks questions about Enterprise deployment and how to create Software Appliances that have everything you need and nothing you don’t in them, the Linux folks also complicating the picture with “Containers” and “Docker Apps” (kudos to them though - they managed to take a handful of things that had existed for years and make them suddenly new and sexy again) and now I need answers for those, too.
>
> What I DO know won’t move the ball forward (on any field, in any game) is arguing about this like it was a religious debate of some sort, where sweeping generalizations are preferred over far more pragmatic questions of “What problems are we here to solve, and what are the specific details of those problems?”
>
> This is also why I’m doing all of that stuff in a branch called NextBSD.  Who has time for religious debate when you’re trying to just get code to work and solve a very specific set of problems? :-)
>
> - Jordan
>

_______________________________________________
freebsd-hackers em freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe em freebsd.org"