Moonsorrow is so epic. Kivenkantaja!

It’s the new trend in software engineering: Turd-Driven Development

That’s great news. I can’t wait. While KDE Plasma 6 works near perfectly SDDM has given me so many problems. I hope a homogenized architecture between KDE and the login manager will make it behave more consistently.

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

Judas Priest is the funnest shit ever to play on guitar. I never get tired of it. Painkiller!

As soon as I open the page I get a modal popup with this junk:

We and our up to 182 partners use cookies and tracking technologies. Some cookies and data processing are technically necessary, others help us to improve our offer and operate it economically.

The processing purposes are storing or accessing information on an end device; personalised advertising and content, measuring advertising performance and the performance of content, target group research and developing and improving offers; displaying external content (e.g. YouTube videos, podcasts, Twitter, quizzes), recommendations of own products and content, A/B testing, push notifications/communication, technically necessary cookies (security, login, forum).

By clicking the „Agree“ button, you consent to the processing of the data stored on your device or terminal equipment, such as personal identifiers or IP addresses, for these processing purposes in accordance with Section 25 (1) TDDDG (Telecommunications Digital Services Data Protection Act) and Art. 6 (1) (a) GDPR. In addition, you consent to providers in the USA also processing your data in accordance with Art. 49 (1) GDPR. In this case, it is possible that the transmitted data will be processed by local authorities.

You can consent to or reject individual data processing operations under Settings. You can edit or revoke your consent at any time via the „Cookies & Tracking“ link at the bottom of each page. Further details can be found in our privacy policy.

With our Pur subscription you can use heise.de without tracking, external banner and video advertising for €4.95 / month. Subscribers to our magazines or heise+ only pay €1.95 per month. You can find information on data processing in the Pur subscription in our privacy policy and in the FAQ.

With our pur subscription you use heise.de without tracking, external banner and video advertising. Alternatively, we and our up to 205 partners store and process cookies and other technologies on your device with your consent. We use these to optimise and continuously improve our website for you, as well as to display personalised advertising including profiling and editorial content.

And only Accept or Subcribe buttons.

No thanks.

“With our Pur subscription you can use heise.de without tracking, external banner and video advertising for €4.95 / month.”

Not letting me reject trackers without paying is some real garbage…

Duh, I missed that it was under Steam Input. Yeah, most likely that’s just controller polling. Amazing that somehow saves 6% battery.

Oh, you refer only to this specific patch. I’m not 100% sure about this patch, but there are other kinds of polling rates, including a global kernel polling rate which greatly affects performance, and tweaking it might perhaps save battery life. And I just mean in general it appears Valve invests a lot of time into mobile power efficiency and I wonder if some makes it upstream.

It has been my experience, which seems generally accepted online, that Linux is greatly outclassed by Windows when it comes to power efficiency on laptops during normal usage. So contributions of new ways in which power efficiency could be improved would be great.

I wonder how many of these updates make it from Steam Deck into mainstream Linux. Because my Deck lasts a lot longer on battery power than my Linux laptop does.

It’s been continuously surprising to me how much hatred some C and C++ devs have for Rust. While Rust isn’t perfect, and plenty of criticisms aimed at the language are well-reasoned, the borrow checker is IMO the logical next step forward in “zero-cost abstraction” which is one of the strongest core philosophies behind C and C++.

The R4L effort seems to be structured sensibly, starting out with only allowing Rust code in (new) drivers. From what I can tell there’s comparatively little that has to be maintained upstream, but even that is encountering aggressive pushback.

I can’t help but feel like some devs have spent so much of their professional careers learning how to avoid the many footguns of C(++) that they fundamentally resent Rust for being a language which avoids most these problems, allowing fast code to be written with fewer bugs in less time and with less effort. This feeling is based on having written lots of C++ code for over 20 years, and having personally encountered devs who deeply resent Rust just because it’s not C.

I love Supcom, but haven’t played it in a few years. Gotta try this!

Ah, fixed. Thanks

It’s so good. And also one of my most treasured 90s records I have on vinyl. Wish I had a pressing of Death’s Design too.

I doubt doing it in software like that outperforms sqrtss/sqrtsd. Modern CPUs can do the conversions and the floating point sqrt in approximately 20-30 cycles total. That’s comparable to one integer division. But I wouldn’t mind being proven wrong.

Well, yeah, but you asked why they didn’t use integer sqrt. It’s something many programming languages just don’t have. Or if they do, it’s internally implemented as a sqrt(f64) anyway, like C++ does.

Most CPUs AFAIK don’t have integer sqrt instructions so you either do it manually in some kind of loop, or you use floating point…

The builtin u64.isqrt seems to be available in nightly only, and additionally I guess the author didn’t want to use any external crates as part of their self-imposed challenge. Though I think there may be an off-by-one result with f64.sqrt I don’t think this functionally breaks their u64 code because they loop to root_n + 1.

https://doc.rust-lang.org/std/primitive.u64.html#method.isqrt

There isn’t even any memory management in their code. And arguably the most interesting part of the article is implementing a bignum type from scratch.

The author pointed out they also could’ve just called openssl prime -generate -bits 1024 if they weren’t trying to learn anything. Rebuilding something from scratch and sharing the experience is valuable.