Your thoughts about init system

FreeBSD need a better init as 'sinit'. Less lines of code is a very modern feature. Only do init job in init is the more modern way to think.
And of course I can argue this point.

But the FreeBSD has a very decent and robust init and if you have bad feeling with RC, share your experimentation with other init system.

For me, RC is the good choice inside FreeBSD regarding others tools and global philosophy (Unix way, "do one things ..." and so on).
 
That's the worst take possible, see "undefined behavior".
There are ways to mitigate C's shortcomings. E.g. IIRC vigole posted some links to the CEI SEI CERT guidelines, & IIRC some notable organisations have commited to follow these: restrict to a subset of C features, and comply to certain algorithmically provable policies.
 
  • Thanks
Reactions: a6h
I don't consider undefined behavior a "shortcoming". It's a deliberate design decision in the language, one that is of course "dangerous" because it requires the programmer to know exactly what they do, but it enables two valuable things:
  • Aggressive optimizations during compilation
  • Close to no runtime overhead
Instead of restricting yourself to a subset, I prefer really studying the standard, so you will spot UB and avoid it. Admittedly, a steep learning curve, and an unfamiliar experience for those who only know "fully defined" languages that will catch errors at least at runtime. Not knowing what you do in C can have fatal consequences.

All I said is, it's a very wrong assumption that a C compiler would always complain about programming errors, relying on that is begging for disaster.

edit:
I'm surprised. At least at a first glance, this doesn't contain any bullshit as many of these coding guidelines do. Also, it doesn't seem to restrict the programmer to a "subset" (at least not, if you don't consider undefined or implementation-defined behavior a part of the "full set").
 
  • Thanks
Reactions: a6h
I'm surprised. At least at a first glance, this doesn't contain any bullshit as many of these coding guidelines do.
AFAIK it's focused on security guideline, than optimisation. IIRC I've read about SEI CERT guideline in Deitel C book -- many years ago, thus I could be wrong.

[EDIT]:
Such guidelines, such as SEI CERT, will prevent neophytes from developing bad habits.
For example gets is officially being deprecated in C++11, and was removed in C++14.
But there're many old and/or unedited online tutorials on the web with gets examples.

SEI CERT Guideline for C++
 
There is one in thing and that is that "sh" scripts can easily have syntax errors.
Whereas for instance a C compiler informs you on the error.
I would also say it is very easy to make mistakes in the systemd .ini files that go unnoticed.

Especially when they add hacks like:

Code:
InitFlags=
InitFlags=-a

The first entry clears the flags, the second appends flags. You need both.
 
There is one in thing and that is that "sh" scripts can easily have syntax errors.
This is true of any interpreted language. I liked to find problems on a large PHP project I worked on simply by opening files in an IDE that did static analysis.
 
OK now you gave an example with the 2nd worse programming language... it is well known & commonly accepted nerd folk wisdom that sh(1)ell scripts are more error prone than other languages.
 
Back
Top