That's the curse and blessing of our profession: efficiency of work is almost impossible to measure once you go beyond very simple code.

You can feel like a hero for changing three characters and finally fixing that nasty, or you can feel like an absolute disgrace for needing days to find such a simple fix. Your manager employs the same duality of judgement

But did you add 3 characters? Gotta bump up that code count bruh.

Theres an ancient Apple story about how LoC is a stupid metric from when they were programming the Lisa.

i’m partial to the more relaxing sleep(500)/linux os, but to each their own

What you refer to as Linux, is actually called Forkbomb/Linux, or as I've recently taken to calli-[Process Killed]

Yes. Also the required clock cycles depends a lot on individual CPU architectures.

For example division: Some CPUs have hardwired logic to compute the division operation directly on circuit level. Others are basically running a for loop with substraction. The difference in required clock cycles for a division operation can then be huge.

Another example: is it a scalar or superscalar CPU?

A rather obvious example: the bit width of the CPU. 32 bit systems compute 64 bit data much more inefficiently than 64 bit systems.

Then there is other stuff like branch prediction, or system dependencies like memory bus width and clock, cache size and associativity etc. etc..

Long story short: When evaluating the performance of code, multiple performance metrics have to be considered simultaneously and prioritized according to the development goals.

Lines of code is usually a veeery bad metric. (I sometimes spend hours just to write a few lines of code. But those are good ones then.) Cycles per code segment is better, but also not good (except you are developing for a very specific target system). Do benchmarking, profiling, run it on different systems and maybe design individual performance metrics based on your expectations.

Lifree

It shows that Unix’s implementation of echo uses 10 lines of code, other *nixen use 60 to 100, and gnu uses 250. The implication being, I suppose, that GNU has such a high line of code count because it’s very verbose or padded

Implementation is the actual code with the logic that does the thing you want it do, as opposed to the command, which is how you tell the system what it should do.

The command can be the same on multiple OSs, but the implementation can be different.

In case of Linux and the coreutils (which are the basic programs you need beside the kernel to make a functioning system, stuff like mkdir) the most common implementation of all the coreutils is the one made by GNU. Stallmann did a lot of work on that so he wants credit for making a big part of the OS.

The same program (echo) implemented in different operating systems (and the GNU version).

That's a good point, thank you for your time

I mean I don't think there must be a heated debate about it you know. You can call it GNU because you probably value more GNU, some others call it GNU/Linux and some Linux. It's okay as long as it's understandable

I mean X does suck. Unfortunately, it's still the better choice sometimes. At least Wayland is clearly better than the other X.

If you're asking how to do something, and most of the responses are "why would you want to do that?" It means you can't do it.

This has been pretty much my experience with every time I've gotten the "Linux" itch...

It's so bad that most of the time googling doesn't help because the top twenty results are just someone else getting shit on for asking the same question.

I once asked for a clarification on a tutorial I found, and the only reply I got was berating me for trying to use systemd.

GNL (GNU isn't Linux) / Linux

So say GNU instead of GNU linux kek

Arch/linux = 0.5 or so right

Linux want to be called an operating system but it's a kernel.

if only there was a way to combine these two...

And hardware can't talk to it. Has it ever occurred to you that there's more at stake here? That companies feel the need to lock away hardware in order to drive their profit line.

At least GNU has something interesting to say about computer science. And for what it's worth, it's telling to know that you woild rather disparage GNU rather than the purposeful decisions made by executives and manufactuers to render both hardware and software undocumented and subjugating.

But no! That's "unfixable" and we need to learn how to "deal with it." God forbid anyone makes a ruckus about it. Freedom for me but not for thee in this fast paced economy.

You picked the status quo and are now complaining that people reject the status quo.