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

[oiaohm]

Because it's one thing you can question and by ignoring everything else you can sort of taint the whole "Unix philosophy" as a "bad", "wrong"..?

I will go into this.

1.
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

You get counter examples to this all the time like command.com, all Unix shells, databases, busybox... Making every program do one thing well can equal bigger memory foot print and more performance overhead. So following this can be completely wrong.

Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

This can lead to not creating libraries or not providing IPC interfaces when you should. This is a memory foot print and operation tasking problem that can kill performance. Binary input formats can be way more compact. The don't insist on interactive input is what has lead to some of the security problems. Everything in this has to be taken with a grain of salt as it can lead to you doing programs wrong.

Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

First part of this is ok and should be a objective. Second part take with a strict grain of salt as at times you have to keep clumsy parts for application compatibility. So it might pay to have a directive here to spend a little validating your design idea to avoid clumsy parts up front if possible.

Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them

This directive backfires. First part kind of ok. But adding tools to a project that you that you expect to throw out latter is a path to documentation hell in future for end users.


2.
Make it easy to write, test, and run programs.

This lacks key stuff it why we have C. Yes C is fairly easy to write test and run programs. It also makes it insanely simple to screw it up completely.

Really this need to be "Make it easy to write, test and run programs that by design is low in defects" what we are starting to go after with

Interactive use instead of batch processing

If you have not noticed this one conflicts with "Don't insist on interactive input." Expect the output of every program to be input to another is about batch processing. This is not uncommon with those writing different so called Unix philosophy to in fact have very different points of view. There is such thing as too far batch processing just as there is such thing as too far interactive.

Economy and elegance of design due to size constraints ("salvation through suffering").

This lead to our buffer overflow bugs. Where pointers to stuff never had a size value because having a size value would increase space required. Thank you for being unwilling to waste a little bit of memory and processing power for these size constraints is the cause of 80%+ of all the reported security bugs. So this idea is not exactly great.

Self-supporting system: all Unix software is maintained under Unix

This one is when you really scratch head why do we have independent project at all if you follow that statement. Yes that says there should be no third party software at all. Does this sound like a really sane idea to you. 100 percent does not to me. Was sane at the time not now.

So, what's precisely wrong with these concepts listed here?

Basically lots is wrong. Different Unix philosophys from different people if you read them carefully they conflict in places.

We really do need to sit down some how and write a new set of design rules that everyone agrees on. The history items like Unix philosophy have bugs sometimes unattended ones.

[RomuloP]

You guys are discussing this from the wrong end.

Let me quote something from Wikipedia article titled as "Unix philosophy". It does not mention "everything is a file" anywhere at all! Where'd you even picked it..

It sure is not, if you understand like so... what is wrong with those statements is the same thing that is wrong with agile manifesto... That is, people will start filling the gaps. It is Unix Philosophy as much as Scrum is agile.

How many definitions out there exist for "make it easy to write programs", seriously it is not even wrong, it is beyond wrong and right, who would explicitly advocate in favor of making it harder to write programs?

[aht0]

Please read it again. Unix everything is a file. That does not say everything should be placed in a massive stack of directories.

All the properties information that is over proc in a mess of directories in reality could be in extended attributes that can be read by a single syscall.

Really everything is a file is not justification to /proc directory mess at all. Yes /proc suffers from race conditions. Remember under proc its pid to directory. Unix everything as a file means that it should be PID to File not directory so /proc is a item that is technically wrong and you just raised it as a arguement against everything is a file.

You guys are discussing this from the wrong end.

Let me quote something from Wikipedia article titled as "Unix philosophy". It does not mention "everything is a file" anywhere at all! Where'd you even picked it up and why'd you discuss it so exhaustively? Because it's one thing you can question and by ignoring everything else you can sort of taint the whole "Unix philosophy" as a "bad", "wrong"..?

https://en.wikipedia.org/wiki/Unix_philosophy

1.

• Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
• Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
• Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
• Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them

2.

• Make it easy to write, test, and run programs.
• Interactive use instead of batch processing
• Economy and elegance of design due to size constraints ("salvation through suffering").
• Self-supporting system: all Unix software is maintained under Unix.

So, what's precisely wrong with these concepts listed here?

[RomuloP]

Please read it again. Unix everything is a file. That does not say everything should be placed in a massive stack of directories.

All the properties information that is over proc in a mess of directories in reality could be in extended attributes that can be read by a single syscall.

Really everything is a file is not justification to /proc directory mess at all. Yes /proc suffers from race conditions. Remember under proc its pid to directory. Unix everything as a file means that it should be PID to File not directory so /proc is a item that is technically wrong and you just raised it as a arguement against everything is a file.

I know, in fact we can say directories existing are a specification error, unless directories are out of "everything" universe and I'm not judging you, everybody can just have it's own "everything" meaning, or we can just vary "file" meaning, everything is a file descriptor, or a file system entry.

It is so fun! And yes, the funny thing is that you're right, be the entire /proc behind a single file (in fact this solution is a candidate submitted hahaha), a file per PID, the way it is today, or any schema involving files, files descriptors, system entries, it would still honor "everything is a file", just adjust your "file" and "everything" for each case and it will be fine.

Thanks for your vision, I appreciate, even if I disagree you really can tell what it really mean, I ask you don't take me wrong, but if you take I wouldn't mind , I'm not here expecting anyone to really prove what the guy that wrote this really meant if not the writer itself.

Anyway this philosophy could be perfectly elaborated in their mind and I really believe they knew how to write great systems... It's just that they suck to write guidelines, in my view. Concrete specifications to a single software case with concrete objective is just in another quality level in my view.

[RomuloP]

Everything you say is just rambling verbal diarrhea, spoken like someone who's never done any systems programming. You have zero useful insight about anything and your "points" are all just non-sequiturs. It's almost as if you're trolling...

And everything you say sounds like only ranting... Ah, yes, it IS ranting. Don't mind if I don't care.

[oiaohm]

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.

Please read it again. Unix everything is a file. That does not say everything should be placed in a massive stack of directories.

All the properties information that is over proc in a mess of directories in reality could be in extended attributes that can be read by a single syscall.

Really everything is a file is not justification to /proc directory mess at all. Yes /proc suffers from race conditions. Remember under proc its pid to directory. Unix everything as a file means that it should be PID to File not directory so /proc is a item that is technically wrong and you just raised it as a arguement against everything is a file.

[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.

[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]

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. ¯\_(ツ)_/¯

[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.