Linux disdain

[eekee]

I'm a little confused. Linux is an example of the "cathedral" development model, having until recently had a "benevolent dictator for life". It was Linus Torvalds himself who came up with the "benevolent dictator" part specifically to describe his position in respect to Linux. As for what the actual problem is, I'm not sure but I think there are multiple causes. Some of it is likely the politics of open source. Torvalds held a strong policy of "no policy in the kernel" which led to udev, widely hated for its complexity. This was a good personal decision for Torvalds himself: it kept him out of the intense debates and repeated policy changes which Linux has suffered over the positions and names of files and directories. It's just not a good decision for sysadmins or hobbyists. Looking at it like this, and considering big business also has its problems with departments fighting each other, I'm thinking the cathedral has some of the same problems as the bazaar.

Gerry Rzeppa of plain English programming once described the "monastery" development model: "An abbot and a small group of monks work together to make something amazing." I really like that one! I think many of the best projects are effectively this. Once they get popular enough to effectively become a cathedral, the rot sets in. Of course, most of our projects are more closely related to the hermitage...

[eekee]

Not 5 minutes after I posted that, I saw this in a Plan 9 mailing list and could not resist sharing:

But the misunderstanding of my use of "dark side" can't go
unchallenged. The Dark Side is what drives Linux development, the need
to discover new ways in which to make Linux and Gnu software larger
and larger, irrespective of whether that leads to greater
functionality or merely cosmetic, irrelevant decorations.

The writer was suffering under the weight of colleagues who viewed anything other than Linux with disdain.

I wanted to write something about the great GNU tendency to obesity, but I don't really have anything clear to say other than it obviously exists. I suspect it comes from being too free in accepting contributions, which reminds me I wrote but then deleted a bit about Linux having too many contributors for any one "dictator" to monitor, much less control.

[PeterX]

I'm a little confused. Linux is an example of the "cathedral" development model, having until recently had a "benevolent dictator for life".

I think Eric Raymond named the Linux kernel explicitely when he wrote about the "bazaar" style. And Linus was very open to ideas and contributions. As long as it didn't violate certain principles, it was "in". This doesn't mean there's no boss at all. "Bazaar style" means there is no careful central blueprint defining every detail.

Greetings
Peter

[Schol-R-LEA]

I'm a little confused. Linux is an example of the "cathedral" development model, having until recently had a "benevolent dictator for life". It was Linus Torvalds himself who came up with the "benevolent dictator" part specifically to describe his position in respect to Linux.

ObPedantic: It was actually Guido van Rossum who called himself the BDFL of Python; AFAIK, Linus has never really used the term, as he would have objected to the 'Benevolent' part - he always seems to have seen his role as being tougher than anyone else on the kernel team.

As for ESR's comment, he was referring to GNU/Linux as a whole ecosystem, I think, rather than the kernel specifically. The mainline kernel most certainly has never been a 'bazaar' model project, no matter what ESR might have said.

[PeterX]

As for ESR's comment, he was referring to GNU/Linux as a whole ecosystem, I think, rather than the kernel specifically. The mainline kernel most certainly has never been a 'bazaar' model project.

Look here:
https://en.wikipedia.org/wiki/The_Cathe ... the_Bazaar

The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process.

The mainline kernel most certainly has never been a 'bazaar' model project, no matter what ESR might have said.

Well, since ESR invented the terminology he's quite an authority. And I've read the book. And Linux was developped chaotically and open to any contribution as long as it was not complete trash.

[Schol-R-LEA]

As for ESR's comment, he was referring to GNU/Linux as a whole ecosystem, I think, rather than the kernel specifically. The mainline kernel most certainly has never been a 'bazaar' model project.

Look here:
https://en.wikipedia.org/wiki/The_Cathe ... the_Bazaar

The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process.

OK, fair point. I retract my assertion.

[PeterX]

Somone (I think on this forum) mentioned the "One guy in a room" dev model. He said this model is dangerous when it comes to producing usable software.

I searched this forum and the net but I couldn't find any text mentioning it. Does anybody know a reference to this "code model"?

Greetings
Peter

[AndrewAPrice]

Somone (I think on this forum) mentioned the "One guy in a room" dev model. He said this model is dangerous when it comes to producing usable software.

I searched this forum and the net but I couldn't find any text mentioning it. Does anybody know a reference to this "code model"?

In the corporate world, this is called an Individual Contributor.

[kzinti]

In the corporate world, this is called an Individual Contributor.

Mmm... That's not what it means where I work. An Individual Contributor (IC) is basically someone who is not a manager. All (but not only) engineers are ICs.

And it is a major corporation.

[eekee]

Huh... I might have to search my old kernel doc files, if I still have any old enough. (I'm pretty sure I've thrown away my really old Linux CDs with the photos of Torvalds in college. XD )

Somone (I think on this forum) mentioned the "One guy in a room" dev model. He said this model is dangerous when it comes to producing usable software.

I searched this forum and the net but I couldn't find any text mentioning it. Does anybody know a reference to this "code model"?

Greetings
Peter

It's "dangerous" because a lot of bugs aren't found until someone other than the original developer tries to use the software. Not just bugs, but UI design too. That's a very old "known fact". I don't know how true it is now; it dates from before there was any real research into UI and before test-driven development was common. (Of course, a sole developer might not think of all the necessary tests.) It was stock advice in the 80s and 90s, but even in the 90s it seemed to be older guys behind it. They didn't have "dev models", they just wrote about the specific problem of trying to do it all yourself.

[nullplan]

It's "dangerous" because a lot of bugs aren't found until someone other than the original developer tries to use the software. Not just bugs, but UI design too. That's a very old "known fact". I don't know how true it is now; it dates from before there was any real research into UI and before test-driven development was common. (Of course, a sole developer might not think of all the necessary tests.) It was stock advice in the 80s and 90s, but even in the 90s it seemed to be older guys behind it. They didn't have "dev models", they just wrote about the specific problem of trying to do it all yourself.

It is still true. Of course, it depends on the people individually, but I have seen my fair share of UI disasters that happened because no external set of eyes ever looked it over. Arguably I'm working on one every workday, but let's not get into that. You just very often get interfaces that are stiflingly awkward to use, and not just user interfaces. I have seen APIs that encode maximum buffer length as a decimal string printed into the buffer itself, rather than just add another parameter. I have seen people check if an input is a valid floating-point number by parsing it with atof(), then printing it again and checking if the strings are equal. And of course, UI designs that hide the important stuff behind fifteen different menus, and the average workflow has more clicks than a school for dolphin telegraph operators. All of these things "work" (as in, are functioning correctly), but you really needed someone to give these people a WTF face and making them fix it.

Unfortunately, you can also get a room full of "one guy in a room" guys, and then code review doesn't help. Having five people convinced that that is just how programming works makes it hard to move forward. I have a codebase that was written in German. I can only guess how awful it must be to work with code like that if you don't speak German. And I still have to thank my lucky stars I don't work with Java, as Java allows the use of all Unicode letters for identifiers.

[eekee]

Oh no... I remember nightmare bain-breaker UIs from the 90s; they were normal then. I'd forgotten they were still around in workplaces. Great line BTW, "More clicks than a school for dolphin telegraph operators." I'm thankful I've only had to use one bad desktop GUI in the last 15 years, but on Android, EveryCircuit is pretty bad. The back button does insanely inconsistent things. There's no way to search your own circuits so finding a circuit can require literally an hour of scrolling. Of course, the actual chance of finding it is low. There are other faults. In the last few months, they've been making silly changes under the banner of "improving the UI" without even touching the serious faults.

Java allows all of unicode too, now? I remember the Go team touting this feature as a good thing when Go was launched. This reminds me of when I tried to use the last stable release of SP-Forth. Most of the comments were in Russian. Some of the defined words were in Cyrillic characters. The files were in two different character encodings, neither of which were UTF-8. The last stable release was old; I should have updated, but it was easier to just fall back to Gforth.

Oh! Speaking of GNU complexity and bloat: Gforth! It's bad. It was already bad in the mid-00s. Parts of SP-Forth were more readable despite the Russian comments! I may be exaggerating; I no longer have a SP-Forth install to check, but I do recall feeling happier with SP-Forth. Anyway, Pforth is 100 times more readable than Gforth. And don't get me started on Gforth's rapid, recent namespace bloat -- this despite its own author saying its compiler's whole design is no longer a good idea and a fresh start would be good. But I think the namespace bloat is probably related to increased development of net2o, and that is interesting. (I still need to decide on namespace management techniques for my Forth.)

[nullplan]

Great line BTW, "More clicks than a school for dolphin telegraph operators."

Thanks, though I cannot take credit. I stole it off of Zero Punctuation. As a foreigner, that web series single-handedly taught me more English than the decade of public school English I had before i started watching.

Java allows all of unicode too, now?

At least I was under that impression. It has been a while since I used it, and never came across any character in it that wasn't in ASCII outside of string or character literals. Nor any need for such, honestly.

This reminds me of when I tried to use the last stable release of SP-Forth. Most of the comments were in Russian. Some of the defined words were in Cyrillic characters.

That must have been fun to work with without a Russian input method.

The files were in two different character encodings, neither of which were UTF-8.

Oh god. Probably ISO-8859-X (I forget which one had Cyrillic in it) and KOI-8. So probably one file from Russia and one from Ukraine or so. And of course if your editor detects it wrong, you can no longer read (or copy into Google Translate) any of it. At least when encodings break in German, you can still read most of it.

[AndrewAPrice]

Mmm... That's not what it means where I work. An Individual Contributor (IC) is basically someone who is not a manager. All (but not only) engineers are ICs.

We have a slightly different definition.

From https://www.indeed.com/career-advice/fi ... ontributor :

Individual contributors are employees who ... manage their one-person team on projects and tasks.

We use it to describe someone who is working on their own project that nobody else is also working on, with really no one to be accountable to (until performance review time!) The majority of engineers are doing regular standups with a small team, working together to get through a pool of tasks or at least in parallel on features (e.g. backend and frontend engineers working together.)

[kzinti]

Aside from one sentence at the beginning, it doesn't sound like they are saying an IC works by himself. It does mention that an IC may be working alone, but that's not necessarily always the case. It certainly is not on my team where there is a strong emphasis on collaboration. We are structured into groups of 3 to 10 people to work on the same backlog, have sprints and daily stand-up meetings (i.e. all the management du-jour stuff you would expect).

I think you are talking about a "lone wolf", not an Individual Contributor. Lone wolves are the one working by themselves. https://www.profocustechnology.com/gene ... evelopers/

Not terribly important here, just a bit confusing to read .