Well, if it works, they'll apply it. Saving 30% on your electricity bill would probably save a lot of money.
this post was submitted on 07 Mar 2025
108 points (98.2% liked)
Linux
6323 readers
242 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
This is the actual change if you're curious: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80b6f094756f
And the paper: https://dl.acm.org/doi/abs/10.1145/3626780
That's way more than 30 lines or code and also their "We didn’t add anything." claim seems to be nonsense.
Most of what you're looking at there is tests and comments, the actual additional code is minimal (I'm not gonna try and count the lines on my phone)
Are one of those lines exec "shutdown -p now" ?
[ $((RANDOM % 100 + 1)) -le 30 ] && shutdown -p now
And yet we write giant web applications in frameworks like django and ExpressJS
Honestly I'm surprised Golang hasn't taken off more.
Because programmer hourly pay is way higher than server hourly cost. Abundant nodejs developers can pump shitty code faster, therefore delivering features faster. That’s all shareholders care about.
Almost like a system where the only consideration is maximizing profit margins isn't ideal. ://
If I'm ever in politics I'll prioritize cooperatives. Nothing wrong with profit, but it doesn't have to be the only thing a corporation cares about.
See, in not so sure about that. Go has a lot of issues, things it doesn't do well, but one thing it is good at is being simple. I would argue that it's certainly not more complex than JavaScript, and in many cases, is easier simply because there are fewer "gotcha" edge cases that impact new developers. And Go is slowly eliminating those gotchas (such as the loop variable shadowing issue).
Your argument holds for Rust v JS; the Rust learning curve is higher, and you have to understand many more technical computing topics to write good code. But I don't think the same holds for Go. Anyone capable of learning JS is capable of learning Go, in nearly the same time.
Maybe you're saying that there's a veritable legion of JS script monkeys, and so it's cheaper because of supply and demand. I'd agree with that. JS programming skills are certainly far more fungible between companies, which encourages new developers to choose it. I just don't think it has as much to do with language complexity or difficulty.
There’s also Dart with its similar syntax to JS, strong type and null safety, and ahead of time compilation with hot reload. And yet it only really started getting adoption after being chosen as the language for Flutter.
I said nothing about the difficulty of learning. JS/TS developers are easier to find and are cheaper, and the current climate wants everybody to be full-stack developers. The cost savings of Go isn’t there :(
You're right, you didn't mention difficulty, but you did say
Abundant nodejs developers can pump shitty code faster, therefore delivering features faster.
I don't believe developers can write code faster in JS than that can in Go. And the truism is still true: just as 9 women can't make a baby in one month, at a fairly early point you can't develop an application faster just by throwing more people at it.
I object to that basic premise: that dumping a hoard of developers on a problem is somehow going to get it done more quickly, or more cheaply. In fact, the only guarantee of that approach is that the quality of going to suffer.
I fully agree. Sadly, in reality, mid-level managers will happily sacrifice quality for speed, and before the whole thing falls apart, they move to another company with better pay.
This is so universally true across domains, I wonder if the collapse of the Career Employee model - motivated mostly by companies, but workers have also had a hand in this - isn't a huge factor in the enshittification of products. In the US, at least.
It really does cross careers. My wife is dealing with someone at work who's making horrible (for the company) decisions for his organization because they buy him short-term benefit and will probably result in a better bonus for him this year. But it's almost guaranteed to be a shit show someone's going to have to clean up in 5 years, but the guy in question doesn't give a fuck about 5 years because his plan is to retire within the next 3. It's a specific interest of a more general issue: nobody expects anymore to be in the same job, and maybe not in the same company, 10 years from today, and companies are are bad about applying consequences over periods longer than a year.
Everybody bitches about the mess the previous person left them, but nobody gets penalized for a bad decision they made 5 years ago. And people aren't stupid; they know this.
A typical data center rack holds about 40 servers, each with at least two networking interfaces. According to Boote, the Ethernet interfaces of a single rack draw 160 watts in total.
“Reducing the power draw of a data center, which may have hundreds or thousands of racks, would be akin to an energy savings of switching a building from incandescent to more energy efficient LED lighting and be well worth the investment,” he told LinuxInsider.
According to Boote, this optimization fixes a part of the kernel written when lower-speed Ethernet interfaces drew a fraction of today’s electrical needs. The networking stack design did not account for the growing power budget required by modern networking interfaces.
“By changing the priority of how the computers schedule tasks during high bandwidth events, a computer can better deal with networking traffic and prioritize energy expenditure in a way that makes sense for modern hardware and architectures,” he reasoned.
He explained that IRQ suspension enhances network performance while maintaining low latency during low-traffic conditions by reducing unnecessary CPU interruptions during high-traffic periods.
Am I overtired or is this nonsense?
He explained that IRQ suspension enhances network performance, while maintaining low latency during low-traffic conditions. It accomplishes this by reducing unnecessary CPU interruptions during high-traffic periods.
Maybe that makes more sense? The original was definitely a run-on sentence, and needed some punctuation.
I think, you have to read it like this:
He explained that IRQ suspension enhances network performance ... by reducing unnecessary CPU interruptions during high-traffic periods. It also maintains low latency during low-traffic conditions.
See, that makes sense. You're probably right. They didn't paren their parenthetical.
If workload LIKE ‘%AI%’ then ignore