New Group Calls For Boycotting Systemd

[Michael_S]

in general less code is faster, with C at least
C translates fairly direct to machine code so ofc writing more C code will give more machine code

and then come optimizing compilers that use magic (pattern matching and some other evaluations) to "compact" and rearrange things to give less code and be more cpu friendly

some other compiler optimizations like loop unrolling do make more instructions (by repeating them) to avoid the need of the cpu to "settle" after some instructions (notably floating point operations, division and memory access)

there are optimizations that come from the algorithm used, that is mostly related to mathematics (and more complex logical problems, see grep for that)
they can make the code complex or complicated or bout (where complex means bigger and complicated means harder for a human to understand)

then there is over usage of library/system calls
(like calling strlen in a loop even thou the length of the string does not change, that a compiler can not optimize since it does not know what strlen() does)

and ofc there is cache trashing and inefficient memory usage due to poor choices in memory management (data structures, malloc, dynamic libraries and idk)


note that division takes way more time then addition, subtraction and even multiplication
square root takes even more time
syscalls take a fair amount (less on amd64)
branching (notably conditional branching), as written; but not much
and so on and so fort

so ye, simpler programs usually run faster
also load faster as there is less to read of the disk
statically linked programs load and run even faster then that (load, in most cases, in some id expect not)


felt like writing a bit

(won't talk where the thing comes in all this as i really don't want stupid replies)

I believe the architecture profoundWHALE was describing is when you use a relatively small amount of C code to write a scripting language interpreter like Perl or Bash, and then write the rest of your application in the scripting language. That code will generally run slower than writing the whole application directly in (well written) C. So in that case, more C code and less scripting language code gives greater speed.

If on the other hand you're looking at two different applications to accomplish the exact same task, both written in C, then I agree that usually the smaller one will be faster.

[gens]

I believe the architecture profoundWHALE was describing is when you use a relatively small amount of C code to write a scripting language interpreter like Perl or Bash, and then write the rest of your application in the scripting language. That code will generally run slower than writing the whole application directly in (well written) C. So in that case, more C code and less scripting language code gives greater speed.

oh
well, most scripting languages can not alter the behavior of the interpreter
(or do much of anything outside of the languages confined behavior (speaking for interpreters, although same goes for compilers most of the time))
(note that shell language is turing complete)
and where is less undefined behavior there is, naturally, less room to f up (some people do find a way)

[gens]

some bollocks

to be semi on topic
"shell overhead" is not notable in the context of booting a system as a shell can do that small amount of simple logic very fast
most of the time is spent waiting for things to be read of the disk

and no, the "solutions" to making things that depend on other things start as soon as they can are not proper
making programs deamonize themselves only after (and if) they set up the service that they provide is (as some do) (plus it allows a process to return an error code if it fails to do so)

and no, i won't discuss this last part any further (ty)

[blackiwid]

I remember back in the day when Linux was designed by, developed by and (perhaps most importantly) used by... people who could form sentences that made actual sense.

I love how people that dont have arguments just try to throw blend granates always, its funny maybe also a bit sad... but who cares... trolls be trolls, if u hate because u love to hate... nice for u...

I dont get why u are talking here anyway this article gave u a link for retards to go to systemdhaters.org or something like that. there u find the 1% of linux users that think like u do... everybody else dont care at all...

But show me my 1-2 spelling or other mistakes I made that is more imporatant to show that, if u have no argument

[psychoticmeow]

I love how people that dont have arguments just try to throw blend granates always, its funny maybe also a bit sad... but who cares... trolls be trolls, if u hate because u love to hate... nice for u...

I dont get why u are talking here anyway this article gave u a link for retards to go to systemdhaters.org or something like that. there u find the 1% of linux users that think like u do... everybody else dont care at all...

But show me my 1-2 spelling or other mistakes I made that is more imporatant to show that, if u have no argument

Write your arguments better and they will be easier to comprehend. Of course you're nowhere near as bad as gens who writes lines and lines of text with almost no structure to it.

"English, motherfucker, do you speak it?"

[gens]

Of course you're nowhere near as bad as gens who writes lines and lines of text with almost no structure to it.

read again
ignore the lack of capital letters and dots (take special note to commas, something they don't teach that good in schools as it is considered too complicated)
also go f yourself as the context is there and very precise

[psychoticmeow]

read again
ignore the lack of capital letters and dots (take special note to commas, something they don't teach that good in schools as it is considered too complicated)
also go f yourself as the context is there and very precise

I'm sorry, but what's wrong with writing like a normal person? Your posts are like some kind of brain virus, if I read to many of them I get a headache.

[sdack]

to be semi on topic
"shell overhead" is not notable in the context of booting a system as a shell can do that small amount of simple logic very fast
most of the time is spent waiting for things to be read of the disk

and no, the "solutions" to making things that depend on other things start as soon as they can are not proper
making programs deamonize themselves only after (and if) they set up the service that they provide is (as some do) (plus it allows a process to return an error code if it fails to do so)

and no, i won't discuss this last part any further (ty)

The problem is not the shell and not even how daemons start. It is the number of preemptive process starts in general. Mobile phones get turned on and off within seconds and people do it only for checking messages. It does not actually need all daemons at boot up and yet is it being done. UNIX has always offered a solution to this problem, the inetd, which starts daemons on demand and with a very user-friendly design. Inetd has not evolved much, probably because it never needed a lot of daemon processes in the past and so its function got forgotten when people started creating all sorts of new daemon processes for Linux. Hence systemd was invented, copying inetd in mind, but with an all system dominating design and being unfriendly to maintain to the despair of a lot of people.

[profoundWHALE]

I believe the architecture profoundWHALE was describing is when you use a relatively small amount of C code to write a scripting language interpreter like Perl or Bash, and then write the rest of your application in the scripting language. That code will generally run slower than writing the whole application directly in (well written) C. So in that case, more C code and less scripting language code gives greater speed.

If on the other hand you're looking at two different applications to accomplish the exact same task, both written in C, then I agree that usually the smaller one will be faster.

I should clarify a bit:
In that post I was referring to basic human error: Less typing means less mistakes. Often people will use javascript, or python, or some other something that isn't nearly as fast as say, just C code, but it is much easier to read, harder to screw up, and less to write.

On the other hand, if you're talking about using C vs C, then I would say simple is always better (assuming it does the exact same thing) and usually not worth the little bits of speed you might get. When I say simple, it often means shorter, but not always. I find that if it's easily understood, it's also easy to debug, and that wins over really confusing short or long code any day.

"If you can't explain it simply, you don't understand it well enough."

"Make everything as simple as possible, but not simpler."

[Paul-L]

OK, I'll leave this here, from Matthew Garrett a.k.a mjg59; he did stuff with ACPI, solved issues with Secure Boot and UEFI (one that I was personally facing with a Samsung Laptop), worked with Canonical, Red Hat, provides patches for Linux and yada yada.

Opinion on systemd (some bits)

I like it! We ship Upstart in our product and, while clearly better than sysvinit, it's honestly just not very good - the version in 12.04 can't even reexec itself without losing state, which means you can't load new selinux policy (for example). That did get fixed later, but spending years in that state isn't a great advert. systemd is more reliable, more functional, has developed a significantly larger development community and doesn't have a CLA (these points may be related)

Freedom of choice in Linux has always been about having access to the source code, permission to modify it and permission to distribute that modified source code. systemd does nothing to change that.

Have you ever tried building a GNU userspace environment from scratch? Not just following LFS, but actually bootstrapping by hand? Userspace is already far more intertwined than you think. It's always been difficult to replace individual components.

Answered here.

http://www.reddit.com/r/linux/comments/2fddvg/im_matthew_garrett_kernel_developer_firmware/ck8586q