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_parte...@rdsor.ro>
Para: Jordan Hubbard <jordanhubb...@icloud.com>
CC: FreeBSD Hackers <freebsd-hack...@freebsd.org>, Jonathan de Boyne
Pollard <j.deboynepollard-newsgro...@ntlworld.com>, Dmitry Sivachenko
<trtrmi...@gmail.com>, Mark Heily <m...@heily.com>, Peter Beckman
<beck...@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 <jordanhubb...@icloud.com> wrote:
On Jan 10, 2016, at 2:36 AM, Dan Partelly <dan_parte...@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-hack...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
