1 |
Alan McKinnon wrote: |
2 |
> Steven J. Long wrote: |
3 |
> > "POSIX 4: Programming for the Real World" (Gallmeister, 1995) |
4 |
> > "UNIX Network Programming vol 2: Interprocess Communications" (Stevens, 1999) |
5 |
> > |
6 |
> > More here: |
7 |
> > https://foss.aueb.gr/posix/ |
8 |
> |
9 |
> I'll look into those, but do take note those books are 14 and 18 years old |
10 |
|
11 |
Yes I am aware of that ;) The age is not the point. The content and its relevance are. |
12 |
Further, you want Lewine 1994, first published 1991, if you're at all concerned about |
13 |
portability, so make it 20 years; and that doesn't get you the deep insight that really |
14 |
matters: read the books on the site in order if you want that, doing the exercises if |
15 |
you want to actually implement stuff. And ask in #friendly-coders for some more books ;) |
16 |
|
17 |
> - that's eternity in our world. |
18 |
|
19 |
It's only really an eternity in compute-time, afaic. Calling something "innovation" |
20 |
doesn't make it innovative. And it certainly doesn't make it an invention. |
21 |
|
22 |
Nor is the speed with which fads and modern capitalism can move, any indication of |
23 |
progress. Sure a lot's "happened". But not much has changed. "One True Way" is still |
24 |
around, it's just mutated into "N+1 True Way", as we read something about "Plan to throw |
25 |
one away, you will anyway" and we've "innovated" that to "Throw every version away" as |
26 |
we don't know what an ABI promise means, and it's soo easy just to push a binary update, |
27 |
when you don't have to deal with the consequent service failure. |
28 |
|
29 |
> Basics never change, details do. Some features are here for the long |
30 |
> haul and I doubt anything will really change them: pipes, named pipes, |
31 |
> unix sockets and things of that ilk. |
32 |
|
33 |
Which is why a 14-year old book describing them is still valid. There's actually a |
34 |
decade of other books by Stevens before that, and APUE (on the site) was updated in 2005 |
35 |
by Rago (who was writing about SysV networking at the same time as the first UNP and |
36 |
APUE.) Stevens himself died unfortunately: a _great_ loss. |
37 |
|
38 |
If you look on the site, you'll see vol 1 of UNP was also updated. And that's where the |
39 |
"eternity of changes" have really taken place: in remote networking, not in local IPC, |
40 |
which is a solved problem. If you know the background. And a programmer always should |
41 |
(or get another job, if learning it is too much.) |
42 |
|
43 |
There are newer versions of both APUE and UNP vol 1, but I hear they're not as good. |
44 |
So I'll get them when they're a bit cheaper, and I have some idle time. |
45 |
|
46 |
> The real bugbear with IPC is people |
47 |
> reinventing the wheel over and over and over to do simple messaging - |
48 |
|
49 |
Which is exactly why it pays to know about the existing mechanisms instead of trying |
50 |
to reinvent them. What you're saying here is exactly my point. |
51 |
|
52 |
> writing little daemons that do very little except listen for a small |
53 |
> number of messages from localhost and react to them. |
54 |
> |
55 |
> Use a generic message bus for that! |
56 |
|
57 |
There's no need. Most apps have a select/poll routine (or the equivalent) in any case, |
58 |
especially the ones that respond to events, including pretty much all desktop apps. So |
59 |
either you respond to the IPC channel in the main event routine, or you do some in a |
60 |
thread. There's several mechanisms, and several methods to do different things. POSIX |
61 |
gives you the standardised components: it's up to you to put them together. |
62 |
|
63 |
wrt "a generic message bus" that's called a "message queue". And a programmer who finds |
64 |
them "too difficult to use" is basically a nub. I've read people say that because it's |
65 |
not an fd, it's not worth using. Which is completely amateur afaic: that's an awfully |
66 |
small comfort-zone. By all means push for an eventfd in POSIX: but in the meantime, be |
67 |
capable of more than one thing. |
68 |
|
69 |
AF_UNIX datagram sockets are fine too, and are in fact what dbus uses. As I said, I never |
70 |
actually criticised dbus itself: I'm fine with a desktop-session bus, to multiplex and |
71 |
broadcast the various events of user interest, and I quite liked the protocol when I first |
72 |
read up on it. |
73 |
|
74 |
To use that as basic plumbing for other things, is a bad idea imo. All you're doing is |
75 |
implementing a central point of failure, that has the additional borkage of being involved |
76 |
with user desktop events. A complete encapsulation nightmare imo. But I don't really |
77 |
care what other people do with their boxes: it doesn't affect me, so why should I? As |
78 |
others have pointed out, dbus is certainly not required for a production server, and I |
79 |
sincerely doubt it ever will be. There's too many experienced admins and coders who quietly |
80 |
earn a living off clean systems, without ever getting involved in mailing-list debates. |
81 |
|
82 |
> It fits nicely in the grand Unix tradition of do one job and do it well, |
83 |
|
84 |
See below wrt filesystems. |
85 |
|
86 |
> and few apps have passing messages around as their core function. Hand it off to the |
87 |
> system, that's what it's there for. |
88 |
|
89 |
Exactly: the operating-system. It's such a common problem, and it has wider implications |
90 |
to do with scheduling and priority that come up around synchronisation, that it's all been |
91 |
provided several times already. |
92 |
|
93 |
> One day I might well do an audit of a typical server base system and |
94 |
> count all the apps that have a hidden roll-your-own message process in |
95 |
> place. I'm certain the results will be scary. |
96 |
|
97 |
So long as you don't think using OS IPC counts as "roll-your-own." It doesn't: dbus is the |
98 |
"roll-your-own", or rather "use someone else's purportedly ready-rolled", only its developers |
99 |
want it to be the only mechanism, and used for everything, much like their plans for systemd. |
100 |
|
101 |
I gave up reading code for a lot of stuff, about a year after I started using Gentoo. I |
102 |
found it too disappointing, especially for apps I loved using. The real problem, imo, |
103 |
is that people don't pass around, review and patch code, in the way that they used to in |
104 |
the early days: every system was built from source, as Gentoo is now. The trend more and |
105 |
more is to obfuscated idiot-boxes where "everything is taken care of for you"; until you |
106 |
need something they didn't think of, when it gets tricky. The idiot-software keeps getting |
107 |
in your way, thinking it knows what you need better than you do, there's no plain-text config |
108 |
in sight, data is all kept in "efficient" binary (aka proprietary) format so it's impossible |
109 |
to debug, and the 'devs' keep whining about "use-cases" and wanting to question your motives, |
110 |
instead of helping you get the job done and out the door. |
111 |
|
112 |
People can deride me as living in some fantasy world, dreaming of days when there were only |
113 |
500 machines or w/e. It really doesn't bother me: to me it's like deriding the Calculus |
114 |
because it was derived in the 18th Century, and saying Arabic numerals are "too complex |
115 |
for the average user" so let's "simplify" and use IIIIII for 6. It merely displays a lack of |
116 |
fundamental knowledge, about the basics of CS: which is no longer what's taught in the IT |
117 |
Marketing depts of today. And fretting about ignorant opinion of the task in front of you is a |
118 |
recipe for failure. |
119 |
|
120 |
In this case, reinventing the basic OS is like saying let's have a userland daemon to mediate |
121 |
access to the hard-drive. "There's far too many apps that are basically small daemons that do |
122 |
little but wait and respond to filesystem activity, reacting to the contents of the files. Use |
123 |
a generic daemon for that!" |
124 |
|
125 |
You see my point? That's what libc is for, and it has an awful lot more specified in POSIX |
126 |
than Standard C. |
127 |
|
128 |
We all owe a deep debt to RMS for POSIX, and its public availability; without it Linux would |
129 |
never have got off the ground. |
130 |
|
131 |
"Good Programming is not learned from generalities, but by seeing how significant programs |
132 |
can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient |
133 |
and reliable, by the application of common sense and good programming practices. |
134 |
Careful study and imitation of good programs leads to better writing." |
135 |
-- Kernighan & Plauger (1978) |
136 |
|
137 |
It's a shame that so many youngsters think "new" == "good", and don't want to learn from the |
138 |
people who were in their shoes 30-50 years ago, and passed down the craft. (What else would |
139 |
they have done with it? ;) Personally I love reading the old simple stuff (and I mean really |
140 |
basic), as it keeps me grounded. But there's an awful lot more that isn't so simple, and the |
141 |
reason it's still around is obvious: "Damn, that shit works". Much like calculus still works. |
142 |
|
143 |
Regards, |
144 |
igli |
145 |
-- |
146 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |