video: Benno Rice on "The Tragedy of systed"

I think that this is pretty interesting: <https://www.youtube.com/watch?v=o_AIw9bGogo>

These days people can laugh at the UNIX concept of connecting typewriters but in the lexicon of the 60's the typewriter was the person and the typwriting machine was the compositing device. Gotta love hacker humor tho. Unix is dead and all thats left is Linux and some rounding errors. & Ask grampa about getty. Having struggled somewhat with upgrading to systemd targets myself, his introduction of a concept of a system layer abstraction which is used for linking between kernel and user space in that dynamically described timing space is fascinating. In my opinion so far, systemd is not particularly a dll hell nor is it a static heaven. Maybe "compurgatory" is the term for this stage of change. Purgatory is about learning to change prior to enlightenment and absent a culture of contempt. Nice talk, thanks for posting. On Thu, Feb 7, 2019, 6:12 PM D. Hugh Redelmeier via talk <talk@gtalug.org wrote:
I think that this is pretty interesting:
<https://www.youtube.com/watch?v=o_AIw9bGogo> --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

On 02/08/2019 05:19 AM, Russell Reiter via talk wrote:
These days people can laugh at the UNIX concept of connecting typewriters but in the lexicon of the 60's the typewriter was the person and the typwriting machine was the compositing device. Gotta love hacker humor tho.
Back when I got into the business, Teletype machines were used for the console. When I first started working for CN Telecommunications (later CNCP & Unitel) I was a bench tech, overhauling Teletypes. A few years later I became a computer tech, working with minicomputers. I spent a lot of time watching long paper tapes running through the tape reader, loading software into the computers. Then, with the VAX 11/780, the console became an LSI-11 computer (microprocessor version of PDP-11), which could be switched between console mode and user terminal, with the STP (Switch Terminal Program) command. The LSI-11 was used for, among other things, loading the VAX microcode from 8" floppies.

| From: Russell Reiter via talk <talk@gtalug.org> | These days people can laugh at the UNIX concept of connecting typewriters | but in the lexicon of the 60's the typewriter was the person and the | typwriting machine was the compositing device. Not in the 1960's. Perhaps in the 1860's. In the 1960's I had a typewriter. And it wasn't a human (slaves had been emancipated; actually before 1860 in Upper Canada). And we didn't think of typewriters as doing compositing. If you did it, you did it with a board and with wax as temporary glue (but ordinary people didn't do that). I'm pretty sure that they used the word "typewriter" since "Teletype" was and is a registered trademark of Teletype Corporation (registered 1916) (now called Teletype LLC). If I remember correctly, at the time, Teletype Corporation was owned by ATT. Under US trademark law, if the owner of a trademark allows the name to be widely used generically, they lose the trademark. Think "Aspirin" (no longer protected in US but still Bayer's in Canada, I think). At the time, UNIX seemed to call the devices TTYs. Generically. The industry called them "terminals", but that's a terrible name. It kind of means "endpoint of a circuit". But then a lineprinter, a papertape reader, a lamp could all be called terminals. "Typewriter" was a pretty good term. Ordinary folks knew what a typewriter was. Originally UNIX ran on the DEC PDP-7 and then PDP-11. They came with a real Teletype model 33 or 35. Horrible but amazing (supposedly a design based on a German WWII device; no machined parts!). I managed to get UNIX to support an IBM 2741, which was an IBM Selectric typewriter with a serial connection. This was not easy since the 2741 used a totally different character set ("tilt rotate code") and was half-duplex on a line-of-text basis. When CRT terminals came in, there was a struggle for naming them (not to mention architecting them): - glass TTYs - VDU (Video Display Unit) - [CRT] terminal <== the winner in my world | Unix is dead and all thats left is Linux and some rounding errors. & Ask | grampa about getty. MacOS and offshoots are somewhat UNIX and quite widespread. But, sadly, his point is valid.

On Fri, Feb 8, 2019, 12:15 PM D. Hugh Redelmeier via talk <talk@gtalug.org wrote:
| From: Russell Reiter via talk <talk@gtalug.org>
| These days people can laugh at the UNIX concept of connecting typewriters | but in the lexicon of the 60's the typewriter was the person and the | typwriting machine was the compositing device.
Not in the 1960's. Perhaps in the 1860's.
In the 1960's I had a typewriter. And it wasn't a human (slaves had been emancipated; actually before 1860 in Upper Canada).
And we didn't think of typewriters as doing compositing. If you did it, you did it with a board and with wax as temporary glue (but ordinary people didn't do that).
I went to a vocational school which had a full blown print shop and touch typing classes for students in the administrative track. Our curriculum and textbooks were a little out of date, but I specifically recall the definition of a typewriter as a person and the typewriting machine as the tool. Although that may have been in a historical context, academically speaking, I always remember that distinction. I also remember running bristol board through the waxer and cutting and pasting typewritten text in preparation for creating photo offset printing plates. Also some wierd tool where you could insert a font wheel, which came in several point sizes for headlines etc. You dialed each letter one by one, just like a dymo label tool, except the result was printed and not embossed and then it was pasted up to create a photo negative which was used in order to create the positive plate for offset printing. I probably should have said compositing process in my origional post. Certainly the people who took touch typing as part of secretarial and administrative course work wouldn't call it a compositing machine.
I'm pretty sure that they used the word "typewriter" since "Teletype" was and is a registered trademark of Teletype Corporation (registered 1916) (now called Teletype LLC). If I remember correctly, at the time, Teletype Corporation was owned by ATT.
Under US trademark law, if the owner of a trademark allows the name to be widely used generically, they lose the trademark. Think "Aspirin" (no longer protected in US but still Bayer's in Canada, I think).
I remember at one point that it was Xerox corporation who tried to sue in order to stop employees from saying take this to the copy room and Xerox it, unless an actuall Xerox machine was being used. That one didnt get out of the gate.
At the time, UNIX seemed to call the devices TTYs. Generically.
The industry called them "terminals", but that's a terrible name. It kind of means "endpoint of a circuit". But then a lineprinter, a papertape reader, a lamp could all be called terminals.
"Typewriter" was a pretty good term. Ordinary folks knew what a typewriter was.
Originally UNIX ran on the DEC PDP-7 and then PDP-11. They came with a real Teletype model 33 or 35. Horrible but amazing (supposedly a design based on a German WWII device; no machined parts!).
I managed to get UNIX to support an IBM 2741, which was an IBM Selectric typewriter with a serial connection. This was not easy since the 2741 used a totally different character set ("tilt rotate code") and was half-duplex on a line-of-text basis.
When CRT terminals came in, there was a struggle for naming them (not to mention architecting them):
- glass TTYs
- VDU (Video Display Unit)
- [CRT] terminal <== the winner in my world
| Unix is dead and all thats left is Linux and some rounding errors. & Ask | grampa about getty.
MacOS and offshoots are somewhat UNIX and quite widespread.
But, sadly, his point is valid.
I liked what he said at the end about finding what you like about systemd and working with that. Along with affirming that no one should have sent Lennart Pottering death threats over systemd development. A little good humored dissent is one thing, a culture of contempt is quite another. Kudos to the presenter for framing some of the more divisive issues of teamwork in a most humane way. ---
Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

On Fri, Feb 8, 2019 at 3:07 PM Russell Reiter via talk <talk@gtalug.org> wrote:
On Fri, Feb 8, 2019, 12:15 PM D. Hugh Redelmeier via talk <talk@gtalug.org wrote:
| From: Russell Reiter via talk <talk@gtalug.org>
| These days people can laugh at the UNIX concept of connecting typewriters | but in the lexicon of the 60's the typewriter was the person and the | typwriting machine was the compositing device.
Not in the 1960's. Perhaps in the 1860's.
In the 1960's I had a typewriter. And it wasn't a human (slaves had been emancipated; actually before 1860 in Upper Canada).
And we didn't think of typewriters as doing compositing. If you did it, you did it with a board and with wax as temporary glue (but ordinary people didn't do that).
I went to a vocational school which had a full blown print shop and touch typing classes for students in the administrative track. Our curriculum and textbooks were a little out of date, but I specifically recall the definition of a typewriter as a person and the typewriting machine as the tool. Although that may have been in a historical context, academically speaking, I always remember that distinction.
I also remember running bristol board through the waxer and cutting and pasting typewritten text in preparation for creating photo offset printing plates. Also some wierd tool where you could insert a font wheel, which came in several point sizes for headlines etc. You dialed each letter one by one, just like a dymo label tool, except the result was printed and not embossed and then it was pasted up to create a photo negative which was used in order to create the positive plate for offset printing.
I probably should have said compositing process in my origional post. Certainly the people who took touch typing as part of secretarial and administrative course work wouldn't call it a compositing machine.
I'm pretty sure that they used the word "typewriter" since "Teletype" was and is a registered trademark of Teletype Corporation (registered 1916) (now called Teletype LLC). If I remember correctly, at the time, Teletype Corporation was owned by ATT.
Under US trademark law, if the owner of a trademark allows the name to be widely used generically, they lose the trademark. Think "Aspirin" (no longer protected in US but still Bayer's in Canada, I think).
I remember at one point that it was Xerox corporation who tried to sue in order to stop employees from saying take this to the copy room and Xerox it, unless an actuall Xerox machine was being used. That one didnt get out of the gate.
On Thu, Feb 7, 2019 at 8:11 PM o1bigtenor <o1bigtenor@gmail.com> wrote:
Greetings
We've 'chatted' occasionally on NewAGTalk.
I'm trying to figure out how to minimize lamb losses when lambing in colder times of the year in the barn. You look to have been doing this for a while so I thought I would ask and pic your brain to improve my live lamb rates.
I have figured out how to maximize the lamb drop rate. Now I would like to reduce my losses from birth to say a week.
One think I'm wondering - - - what range of temperature do you prefer for your ewes when they're lambing fairly fresh sheared in the barn At the time, UNIX seemed to call the devices TTYs. Generically.
The industry called them "terminals", but that's a terrible name. It kind of means "endpoint of a circuit". But then a lineprinter, a papertape reader, a lamp could all be called terminals.
"Typewriter" was a pretty good term. Ordinary folks knew what a typewriter was.
Originally UNIX ran on the DEC PDP-7 and then PDP-11. They came with a real Teletype model 33 or 35. Horrible but amazing (supposedly a design based on a German WWII device; no machined parts!).
I managed to get UNIX to support an IBM 2741, which was an IBM Selectric typewriter with a serial connection. This was not easy since the 2741 used a totally different character set ("tilt rotate code") and was half-duplex on a line-of-text basis.
When CRT terminals came in, there was a struggle for naming them (not to mention architecting them):
- glass TTYs
- VDU (Video Display Unit)
- [CRT] terminal <== the winner in my world
| Unix is dead and all thats left is Linux and some rounding errors. & Ask | grampa about getty.
MacOS and offshoots are somewhat UNIX and quite widespread.
But, sadly, his point is valid.
I liked what he said at the end about finding what you like about systemd and working with that. Along with affirming that no one should have sent Lennart Pottering death threats over systemd development. A little good humored dissent is one thing, a culture of contempt is quite another. Kudos to the presenter for framing some of the more divisive issues of teamwork in a most humane way.
I appreciated this talk a lot. Made my wife sit through it to grin! He showed what was good AND what was bad about it and also lightly poked at the less than positive way it was introduced. What was impressive was that he could use humor in most interesting ways and yet wasn't denigrative in the process. Helped me to 'understand' things a bit better although I still am not clear on whether to move further into systemd or not. When it comes to containers - - - well I got royally burned by them suckers about a year ago so whilst I think that they're a great idea the implementation needs to be different than lxd before I'm going to touch the idea again. (LXD itself isn't the largest part of the problem. Its LXD has chosen to rely upon snapd and both have embraced the concept of the programmer knowing everything and the users being idiots that don't know how to keep a system up to date. If I had the skills I would be working on forking LXD - - - its a great idea.) Dee

On Fri, 8 Feb 2019 at 16:18, o1bigtenor via talk <talk@gtalug.org> wrote:
I appreciated this talk a lot. Made my wife sit through it to grin! He showed what was good AND what was bad about it and also lightly poked at the less than positive way it was introduced. What was impressive was that he could use humor in most interesting ways and yet wasn't denigrative in the process. Helped me to 'understand' things a bit better although I still am not clear on whether to move further into systemd or not.
The other interesting thing I recently watched that was rather interesting was the following... Is It Time to Rewrite the Operating System in Rust? https://www.infoq.com/presentations/os-rust His eventual thesis was that while there are interesting things about this, there's too much already vested/invested in drivers and such for it to be terribly worthwhile. He observed that the notion that gave him "cold sweats" was the thought of having to rewrite ZFS (he's a Solaris developer at whatever Joyent is now) in Rust. He points at 4 concepts, of which 3 would make sense: 1. One could rewrite the OS in Rust, but that is an extraordinarily large project 2. It might be attractive to add some hooks so that *new* modules that get added in are written in Rust. I'm using Remacs these days, which is gradually, function by function, getting rewritten into Rust. Ooh, "git pull"; apparently (reverse) got implemented today. Perhaps the *next* nifty new filesystem would have improved type safety and such. 3. Reimplement parts of user space. The conspicuous relevant observation made in the talk was that he wouldn't have done SystemD in C, but rather in Rust. (Perhaps he might reimplement SMF in Rust; that's the Solaris thing...) Reimplementing individual services that run in user space isn't nearly as scary as #1. Doing one command at a time shouldn't scare us too much; I don't care too much what language is used to implement /usr/bin/cat 4. Reimplement firmware. Which is a surprisingly scary area that we don't play with terribly much. I reboot systems sufficiently rarely that this perhaps oughtn't be valuable to me; improving firmware is nevertheless a thing, and I'm a bit scared of what's out there.
When it comes to containers - - - well I got royally burned by them suckers about a year ago so whilst I think that they're a great idea the implementation needs to be different than lxd before I'm going to touch the idea again. (LXD itself isn't the largest part of the problem. Its LXD has chosen to rely upon snapd and both have embraced the concept of the programmer knowing everything and the users being idiots that don't know how to keep a system up to date. If I had the skills I would be working on forking LXD - - - its a great idea.)
What "blandly" scares me about containers is that they might represent a way of bundling up our 2038 bugs and preserving them until they cause the world to cascade down in burning ashes in 2038. I'm definitely a bit scared at the notion that containers let us keep "bad old stuff" around in pretty bad ways. Every time I see an error message like the following one, I worry about containerization... ----------------------------------------------------- Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/5.0-rc-3/userguide/command_line_interface.html#sec:c... ----------------------------------------------------- That Gradle complaint obviously isn't actually about a containerization problem; it's a low grade compatibility problem (that I don't understand, because I really don't know Gradle, a Java-based build tool very intimately). Nobody has any incentive to fix whatever the problem is, and "container world" seems to be pretty rife with "oh, there was a little problem that we'll just ignore because it doesn't much matter today." The notion in "Dockerworld" of having minimal containers where you don't have a lot of extra crap that you're packing into the containers is appealing, but I'm not sure how under control this is. What does it mean to "keep system up to date?" There's just enough philosophical oddness to that that I'm left sufficiently off-put by it all. In a containerized world, I'll bet SystemD isn't the best application for managing things, because it's rather centred on being process 1, and a horde of containers has a horde of process 1's. You need a distributed service manager, and I'm not sure we have that just yet. There's *lots* of interesting research to be done in that area, no doubt! -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"

On Fri, Feb 8, 2019 at 4:35 PM Christopher Browne via talk <talk@gtalug.org> wrote:
On Fri, 8 Feb 2019 at 16:18, o1bigtenor via talk <talk@gtalug.org> wrote:
I appreciated this talk a lot. Made my wife sit through it to grin! He showed what was good AND what was bad about it and also lightly poked at the less than positive way it was introduced. What was impressive was that he could use humor in most interesting ways and yet wasn't denigrative in the process. Helped me to 'understand' things a bit better although I still am not clear on whether to move further into systemd or not.
The other interesting thing I recently watched that was rather interesting was the following...
Is It Time to Rewrite the Operating System in Rust? https://www.infoq.com/presentations/os-rust
His eventual thesis was that while there are interesting things about this, there's too much already vested/invested in drivers and such for it to be terribly worthwhile.
He observed that the notion that gave him "cold sweats" was the thought of having to rewrite ZFS (he's a Solaris developer at whatever Joyent is now) in Rust.
He points at 4 concepts, of which 3 would make sense:
1. One could rewrite the OS in Rust, but that is an extraordinarily large project
2. It might be attractive to add some hooks so that *new* modules that get added in are written in Rust. I'm using Remacs these days, which is gradually, function by function, getting rewritten into Rust. Ooh, "git pull"; apparently (reverse) got implemented today. Perhaps the *next* nifty new filesystem would have improved type safety and such.
3. Reimplement parts of user space. The conspicuous relevant observation made in the talk was that he wouldn't have done SystemD in C, but rather in Rust. (Perhaps he might reimplement SMF in Rust; that's the Solaris thing...) Reimplementing individual services that run in user space isn't nearly as scary as #1. Doing one command at a time shouldn't scare us too much; I don't care too much what language is used to implement /usr/bin/cat
4. Reimplement firmware. Which is a surprisingly scary area that we don't play with terribly much. I reboot systems sufficiently rarely that this perhaps oughtn't be valuable to me; improving firmware is nevertheless a thing, and I'm a bit scared of what's out there.
When it comes to containers - - - well I got royally burned by them suckers about a year ago so whilst I think that they're a great idea the implementation needs to be different than lxd before I'm going to touch the idea again. (LXD itself isn't the largest part of the problem. Its LXD has chosen to rely upon snapd and both have embraced the concept of the programmer knowing everything and the users being idiots that don't know how to keep a system up to date. If I had the skills I would be working on forking LXD - - - its a great idea.)
What "blandly" scares me about containers is that they might represent a way of bundling up our 2038 bugs and preserving them until they cause the world to cascade down in burning ashes in 2038.
I'm definitely a bit scared at the notion that containers let us keep "bad old stuff" around in pretty bad ways. Every time I see an error message like the following one, I worry about containerization... ----------------------------------------------------- Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/5.0-rc-3/userguide/command_line_interface.html#sec:c... -----------------------------------------------------
That Gradle complaint obviously isn't actually about a containerization problem; it's a low grade compatibility problem (that I don't understand, because I really don't know Gradle, a Java-based build tool very intimately).
Nobody has any incentive to fix whatever the problem is, and "container world" seems to be pretty rife with "oh, there was a little problem that we'll just ignore because it doesn't much matter today."
There's that and then there's the 'our software doesn't have any bugs' thinking which when on a forced updating program means when there is one - - - EVERYTHING goes for !@#$%^!
The notion in "Dockerworld" of having minimal containers where you don't have a lot of extra crap that you're packing into the containers is appealing, but I'm not sure how under control this is.
What does it mean to "keep system up to date?" There's just enough philosophical oddness to that that I'm left sufficiently off-put by it all.
Well to Canonical it means that you will be updating your system at least every month - - - their preference is every day but you can back it off to once a month. If you try to shut that 'feature' off - - - - life does get interesting (which is why I want nothing to do with it as a result!).
In a containerized world, I'll bet SystemD isn't the best application for managing things, because it's rather centred on being process 1, and a horde of containers has a horde of process 1's. You need a distributed service manager, and I'm not sure we have that just yet. There's *lots* of interesting research to be done in that area, no doubt!
There are few people who seem to be looking at the 'big picture' and trying to map out ways and means to move forward. Means that there is much duplication of effort and needed backtracking too bad!
-- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
A 56 cal rifle shot? (LOL) Dee

The notion in "Dockerworld" of having minimal containers where you don't have a lot of extra crap that you're packing into the containers is appealing, but I'm not sure how under control this is.
What does it mean to "keep system up to date?" There's just enough philosophical oddness to that that I'm left sufficiently off-put by it all.
Well to Canonical it means that you will be updating your system at least every month - - - their preference is every day but you can back it off to once a month. If you try to shut that 'feature' off - - - - life does get interesting (which is why I want nothing to do with it as a result!).
I know I am walking into this one. Why do you not want to update your system on a regular basis? Bugs will always be there (including whatever you are running). The distro I work for, we try to limit updates to once a month, since we recognize the fact that customers cannot always reboot on a whim. Having said that, those updates are fairly important, and should be applied as soon as possible. Most distros won't foist a new version on you, it will be a stable update. Also, if you don't trust the distro's update and testing, why are you using that distro in the first place? Why not build something of your own? Let's not get into a situation where we are not updating our systems and running with known vulnerabilities, which normally have exploits already available. Dhaval

That link did not work. A quick google resulted in https://youtu.be/6AeWu1fZ7bY Is it the same talk? David Thornton @northdot9 https://wiki.quadratic.net On Thu, Feb 7, 2019, 6:12 PM D. Hugh Redelmeier via talk, <talk@gtalug.org> wrote:
I think that this is pretty interesting:
<https://www.youtube.com/watch?v=o_AIw9bGogo> --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

That is sooper odd. That link didn't work for me on my phone, but now on my lappy, it does. The message I got on my phone was "You can't see that video because that user was removed." And I saw a black cat go by twice just now as well. :) David On Fri, Feb 8, 2019 at 10:14 AM James Knott via talk <talk@gtalug.org> wrote:
On 02/08/2019 08:21 AM, David Thornton via talk wrote:
That link did not work.
I did for me.
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- David Thornton https://wiki.quadratic.net https://github.com/drthornt/ https://twitter.com/northdot9/

On 2019-02-08 8:21 a.m., David Thornton via talk wrote:
That link did not work.
A quick google resulted in
The original link worked for me. The non-shortened URL for it is: https://www.youtube.com/watch?v=o_AIw9bGogo The google search turned up a video on the same topic given at a different conference by the same person. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick

| From: David Thornton via talk <talk@gtalug.org> | That link did not work. I wonder why. URLs copied from a browser can have mysterious problems. Or give up personal information. Long ones with & or ? in them sometimes can be edited to remove everything after that character (eg. newegg.ca links). I've just discovered a way to ask YouTube for a canonical link: "share" and then "COPY" (on my desktop Firefox). Here's the resuslt: <https://youtu.be/o_AIw9bGogo< This looks the link I sent, with a substitution. | > <https://www.youtube.com/watch?v=o_AIw9bGogo> But this short one could not possibly work with everything after ? removed. | A quick google resulted in | | https://youtu.be/6AeWu1fZ7bY | | Is it the same talk? No. He gave the talk first at BSDCan and then a couple of weeks ago at Linux Conf Australia. I understand that there was considerable revision.

On 2019-02-08 11:40 a.m., D. Hugh Redelmeier via talk wrote:
| > <https://www.youtube.com/watch?v=o_AIw9bGogo>
But this short one could not possibly work with everything after ? removed.
If you remove the part after the ? you remove the part that tells YouTube which video you want to watch. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick

On Thu, Feb 7, 2019, 6:13 PM D. Hugh Redelmeier via talk <talk@gtalug.org wrote:
I think that this is pretty interesting:
Interesting indeed. It's sad, the "culture of contempt" that has grown up in this particular place, and the speaker captures quite well the dangers and ironies. In his culture (BSD), their risk is of... - laughing at the foolish Linux people - we're still using OUR init, come join us to stay in the past - launchd is pretty cool, tho it's proprietary Apple and doesn't solve as many problems as SystemD Partly, SystemD suffers a cultural problem because Lennart isn't as, I don't know, charismatic, as would have been useful. I suspect that it's a good candidate for being written in a safer language than C; there's a rich and troublesome "culture of contempt" there, too, alas. - there's a culture of "it's better because I know how to write safe C" - also, one of concomitant contempt for C++ (some overlap there) - another group involves the notion that Go and Rust are new and cool, and wonderful due to being new kids on the block... I was pleased at how he got to the description of problems being solved; there truly are substantive problems, that matter, not addressed by previous tools. Personally, I see that SystemD attacks problems we need to get solved. I have experienced some minor problems in dealing with it, but nothing that seems remotely worthy of the opprobrium thrown at it. There's a social problem that sides seem not to be successfully listening to others. It gets illustrated nicely by the resignations of Debian team members after SystemD integration, where (quoting wikipedia): "All four justified their decision on the public Debian mailing list and in personal blogs with their exposure to extraordinary stress-levels related to ongoing disputes on systemd integration within the Debian and open-source community that rendered regular maintenance virtually impossible." That's something of an attempt to fold all of their reasons together, but I think there's still some truth to it. Culture of contempt, indeed.

On Thu, Feb 7, 2019, 6:13 PM D. Hugh Redelmeier via talk <talk@gtalug.org wrote:
I think that this is pretty interesting:
Interesting indeed. It's sad, the "culture of contempt" that has grown up in this particular place, and the speaker captures quite well the dangers and ironies. In his culture (BSD), their risk is of... - laughing at the foolish Linux people - we're still using OUR init, come join us to stay in the past - launchd is pretty cool, tho it's proprietary Apple and doesn't solve as many problems as SystemD Partly, SystemD suffers a cultural problem because Lennart isn't as, I don't know, charismatic, as would have been useful. I suspect that it's a good candidate for being written in a safer language than C; there's a rich and troublesome "culture of contempt" there, too, alas. - there's a culture of "it's better because I know how to write safe C" - also, one of concomitant contempt for C++ - Go and Rust are new and cool, and wonderful due to being new kids on the block... I was pleased at how he got to the description of problems being solved; there truly are substantive problems, that matter, not addressed by previous tools. Personally, I see that SystemD attacks problems we need to get solved. I have experienced some minor problems in dealing with it, but nothing that seems remotely worthy of the opprobrium thrown at it. There's a social problem that sides seem not to be successfully listening to others.
participants (8)
-
Christopher Browne
-
D. Hugh Redelmeier
-
David Thornton
-
Dhaval Giani
-
James Knott
-
Kevin Cozens
-
o1bigtenor
-
Russell Reiter