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

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

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.

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

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

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?

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