Systemd Is Approaching 1.3 Million Lines While Poettering Lost Top Contributor Spot For 2019

[kgonzales]

Could be some of those Outreachy diversity pigeons. Fly in, $h!t all over, commit a few token gesture LoC, then fly off to "contribute" elsewhere.

Oh I did not know you had a view into the productivity or quality of the projects coming from the Outreachy program. I am interested in seeing your statistics.

[RomuloP]

I put it in the horror literature category.

I understand you, utopia fantasies can be terrifying when you focuses on how damn wrong they go down the hill... But at last to me, there is more than pure terror in Unix Philosophy.

[jacob]

I understand you, utopia fantasies can be terrifying when you focuses on how damn wrong they go down the hill... But at last to me, there is more than pure terror in Unix Philosophy.

Let me rephrase it: to me, Unix Philosophy is not an utopia, it's a dystopia. As a software design doctrine it's utterly wrong at a very fundamental level. I don't see it as a nice idea that doesn't really work well in practice, rather I consider it to be a terrible idea that wotks exactly as expected, i.e. terribly.

[aht0]

You are like some religious sect..

Worse than Friday in mosque.

[RomuloP]

Let me rephrase it: to me, Unix Philosophy is not an utopia, it's a dystopia. As a software design doctrine it's utterly wrong at a very fundamental level. I don't see it as a nice idea that doesn't really work well in practice, rather I consider it to be a terrible idea that wotks exactly as expected, i.e. terribly.

1. Well to me, in the real world, utopias are always dystopias and vice-versa, what varies is only the intensity of the disaster it produces or delusion it comes from. What I said was that Unix Philosophy is far away from a "worst scenario", in my view. I think that to you it was the worst possible, ok we disagree. ¯\_(ツ)_/¯

2. Software design doctrines are always utterly wrong in my view, every-problem boiler plate doctrines are fantasies, at last to me. Software design guidelines and advice's are always for specific cases, some times the case represents 90% of the software out there, some times not.

3. There exist good advises in Unix Philosophy I think, that work great in specific cases, but the moment it was named a doctrine, and the guidelines where written so raw and so universally it has gone downhill fast, honestly software engineering is a very fictional plus marketed place today, it should not even be named engineering to start , anyway, Unix Philosophy is just another case of many. Not absolutely everything should be a file or plain text and modularity would not be taken as *put whatever vision you want of how to divide software components here*.

[oiaohm]

Not absolutely everything should be a file.

Everything is a file in Unix world idea is kind of right thinking that the only form of handle unix apis have is a file. Fun of race conditions when you don't use a proper handle/atomic. So that one has a major grain of truth and where you don't do that you really do need to look closely if what you are doing is right or wrong.

[RomuloP]

Everything is a file in Unix world idea is kind of right thinking that the only form of handle unix apis have is a file. Fun of race conditions when you don't use a proper handle/atomic. So that one has a major grain of truth and where you don't do that you really do need to look closely if what you are doing is right or wrong.

A good example is /proc, how slow it is, how it lacks standardization and what a big security problem it is, not to point the waste of resource remedying it in the last years, a feature there just for the sake of "convenience". Simply to start, caring about race conditions everywhere is a bad idea, if you don't need it will just be a performance penalty for free.

The truth is a proper API for this case should have been implemented from the beginning, so we could securely, fast or thread safely monitor/manipulate processes. And no it must not be through file concepts, there is not a single feature that only the "everything is a file" concept expose and some good features it lack.

And, well, this is the problem of Unix Philosophy, it not only ratify bad solutions because somewhere those ideals will fail, but it mandate them as the only right way of thinking, because it is said to be the right think to do everywhere or with everything, so the rest is bad, right? I mean, what a waste, you're reinventing the wheel, breaking a good standard, blablabla.

[RomuloP]

It's sad how the people with the least clue always have the most say...

From the bottom of my heart, I expect this generalization of yours really helps you in some way to lead better with discordance as I believe it will do nothing to change people's mind, neither the facts that top takes seconds in some systems through dozens of open/read/close calls plus text parsing tend to change some minds. I guess Web parsing bloat is horrible but parsing text in what would be expected to be near hardware calls, don't. ¯\_(ツ)_/¯

[aht0]

It's sad how the people with the least clue always have the most say...

Waiting with great curiosity, expand on his shortcomings, explain us his mistakes please..?

[RomuloP]

Waiting with great curiosity, expand on his shortcomings, explain us his mistakes please..?

I guess most Unix philosophy believers think that anyone criticizing it want to ban every concept of it or start everything over again... 🤔 Anyway I've always asked myself, how we should interpret "everything is a file"? After some maturation it turned clear how much it sounds like those infinite knowledge messages, like "never say never"...

Well while designing /proc someone really took the concept almost true to the core.

I really would like to know, if there existed a /attr directory containing all file's flags, how many would be the true believers. Imagine what a joy, would we separate in files to be true to the core? Or just make a entry per file and read -> parse -> write. Imagine the awesome speed we would face changing a huge directory attribute recursively.