|
|
Log in / Subscribe / Register

Some things to expect in 2025

By Jonathan Corbet
January 2, 2025
We are reliably informed by the calendar that yet another year has begun. That can only mean one thing: the time has come to go out on a limb with a series of ill-advised predictions that are almost certainly not how the year will actually go. We have to try; it's traditional, after all. Read on for our view of what's coming and how it may play out.

The extensible scheduling class (sched-ext) will be a game changer. Already we have seen, in 2024, how the ability to load a CPU scheduler from user space as a set of BPF programs has unleashed a great deal of creativity; that was before sched-ext was part of a released kernel. In 2025, this feature will start showing up in more distributions, and more people will be able to play with it. The result will be a flood of new scheduling ideas, each of which can be quickly tested (and improved) on real systems. Some of those ideas will result in specialty schedulers included with focused distributions (systems for gaming, for example); others, hopefully, will eventually find their way into the kernel's EEVDF scheduler.

Code written in Rust will land in the kernel at an increasing rate over the course of the year as a result of the increased availability of abstractions and greater familiarity with the language in the kernel community. The Rust code that has been merged so far is mostly infrastructure and proofs of concept; in 2025, we'll see Rust code that end users will run — but they may never notice. The number of unstable language features needed by the kernel will drop significantly as those features are stabilized by the Rust community.

Another XZ-like backdoor attempt will come to light. Existing code bases have been scoured for attacks similar to those used against XZ; little has been found, but that does not mean that there are not other ongoing efforts, using different techniques, out there. The potential payoff for a government agency or other suitably well-funded organization is simply too high for all of them to ignore; somebody is surely trying something.

Increasingly, single-maintainer projects (or subsystems, or packages) will be seen as risky by their users. Security incidents like the XZ backdoor attempt will be part of that, but a project with a single maintainer is also subject to all of the other problems associated with burnout and insufficient time to do the job properly. Such a project will never be as reliable as one would like.

A major project will discover that it has merged a lot of AI-generated code, a fact that may become evident when it becomes clear that the alleged author does not actually understand what the code does. We depend on our developers to contribute their own work and to stand behind it; large language models cannot do that. A project that discovers such code in its repository may face the unpleasant prospect of reverting significant changes.

Meanwhile, we will see more focused efforts to create truly free generative AI systems, perhaps including the creation of one or more foundations to support the creation of the models. This work will include a great deal of innovation focused on reducing the resources that these models need, driven by the much lower level of resources available. The resulting code will help to increase the access to — and control over — these systems, with unknown results; not everybody will use them for good purposes.

We may also see the launch of one or more foundations aimed specifically at providing support for maintainers. Even companies that contribute enthusiastically to free-software projects often balk at supporting the maintainer role, despite the fact that projects don't work without maintainers. But perhaps some of those companies can be encouraged to support a separate entity that promises to solve — or at least improve — the maintainer situation for specific projects of interest. The maintainer role will still be severely under-supported at the end of the year, though.

Foundations supporting free-software work will continue to struggle in 2025, though, continuing the trend seen in 2024. The coming year does not look like a time of increasing generosity in general, so organizations that depend on the generosity of others will have their work cut out for them.

There will be more cloud-based products turned to bricks by manufacturers that go bankrupt or simply stop caring. Surveillance and data-breach problems with cloud-connected products will also happen with discouraging regularity over the course of the year; see the stories on air-fryer surveillance or the Volkswagen electric-vehicle data leak for recent examples. Perhaps 2025 will be the year when awareness of the downsides of extensive cloud connectivity will become more widespread. There is an opportunity for free-software alternatives, such as Home Assistant, to make inroads by demonstrating a better way to manage personal data. Truly taking advantage of that opportunity will require a user focus that is not always our community's strong point, but one can always hope.

As a corollary to the above, more fully open hardware will become available in 2025. The OpenWrt One, which hit the market in 2024, quickly sold out its initial production run. There is clearly an appetite for hardware that can be truly owned by its purchasers, and our community has the skills and tools needed to make such hardware. Expect some interesting projects to launch in the coming year.

Distributions for mobile devices will see a resurgence in interest in the coming year. In the early days of Android, it was common to replace a phone vendor's software with CyanogenMod or another derivative; it was the best way to get the most control and functionality out of the device. As Android improved, many of us stopped going to that extra effort. Increasing privacy and security concerns, paired with increasing quality on the part of the alternative distributions, will start to drive some users away from stock Android once again.

Finally, global belligerence will make itself felt in our community. The world as a whole does not appear to be headed in a peaceful direction; even if new conflicts do not spring up, the existing ones will be enough to affect the development community. Developers from out-of-favor parts of the world may, again, find themselves excluded, regardless of any personal culpability they may have for the evil actions of their governments or employers.

This is being written in the US, where politics have taken a distinct "us versus them" turn; such trends are not limited to this country, though. That attitude runs strongly against the foundations our community was built on; we are building systems for everybody, accepting the contributions of anybody who is willing and able to help. We have shown that it is possible to build a global community that can accomplish amazing things and change the world. This coming year would be a good one in which to show that we are still capable of doing that. As some strive to tear our institutions down, we can work to make our institutions stronger than ever.

LWN will begin its 27th year of publication in January; we are one institution that is proud to have been a part of the Linux and free-software communities for so long, and we have no intention of stopping now. Whatever happens in 2025, we'll be here to write about it and, hopefully, spread some light and understanding. And, of course, we'll return to these predictions in December to have a good laugh at just how far off they turned out to be.

Best wishes to all of you; LWN would not be what it is without our readers. We wish an especially happy and prosperous 2025 to our subscribers; without you, we would not have been around for all these years.


to post comments

Not a long limb

Posted Jan 2, 2025 16:34 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Those predictions all look pretty reasonable to me!

Obligatory Joke

Posted Jan 2, 2025 18:18 UTC (Thu) by NUXI (subscriber, #70138) [Link] (11 responses)

It will also finally be the year of the linux desktop!

Obligatory Joke

Posted Jan 2, 2025 18:31 UTC (Thu) by pizza (subscriber, #46) [Link] (10 responses)

> It will also finally be the year of the linux desktop!

... the year of Linux on the *Microsoft* Desktop, that is..

Obligatory Joke

Posted Jan 2, 2025 18:43 UTC (Thu) by gmprice (subscriber, #167884) [Link] (9 responses)

Didn't WSL2 release in like 2020? :P

Obligatory Joke

Posted Jan 5, 2025 13:09 UTC (Sun) by butlerm (subscriber, #13312) [Link] (3 responses)

I hope Microsoft brings back WSL1 or lets someone else do so. Better support for Cygwin would be great too. The original WSL in some ways is better, cleaner, and simpler for software that doesn't need things like support for direct GPU integration, Wayland, and Vulkan, to name a few.

Obligatory Joke

Posted Jan 5, 2025 14:01 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

Except for all the subtle ways that it was *not* actually Linux. We basically ended up punting on issues filed against it for some projects because the answers inevitably boiled down to "well, Microsoft didn't implement some subtlety correctly, go complain to them".

Obligatory Joke

Posted Jan 5, 2025 14:55 UTC (Sun) by butlerm (subscriber, #13312) [Link] (1 responses)

In cases like that Microsoft should release the necessary parts under an appropriate open source license and let someone else do it.

Obligatory Joke

Posted Jan 6, 2025 0:15 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I mean, sure, but I'd rather do something useful with my time than wait for the heat death of the universe. Until then, WSL1 bugs go in the "if you can't reproduce it on a real Linux, go talk to Microsoft" bucket.

Obligatory Joke

Posted Jan 6, 2025 17:55 UTC (Mon) by tesarik (subscriber, #52705) [Link] (4 responses)

That's wrong. The next step is Linux Subsystem for Windows, which will present native Windows desktop on a Linux kernel. Micosoft can then finally cut their R&D costs by maintaining only one kernel instead of two…

Obligatory Joke

Posted Jan 10, 2025 12:00 UTC (Fri) by anton (subscriber, #25547) [Link] (3 responses)

I have expected Microsoft to implement Windows as an API layer on Linux (essentially like WINE, but with the authority and funds of Microsoft behind it) for about 20 years, with the benefit that they would get a better kernel and would need less maintenance effort.

Microsoft has not gone there. I expect that they considered that approach, too, but that their current approach gives them more benefits, maybe just marketing, but maybe there are technical considerations, too: E.g., having software like Crowdstrike probably would not be very stable if they go with the mainline kernel, and sticking with one specific kernel increases the maintenance burden, so they might just as well stick with their current kernel.

Obligatory Joke

Posted Jan 10, 2025 19:24 UTC (Fri) by raven667 (guest, #5198) [Link] (2 responses)

Aside from the long tail of compatibility that they want to support to keep existing business, I believe they also use the Windows kernel as the basis for Azure, so they might see it as a competitive advantage against Amazon, VMware, etc. to have their own kernel hackers and their own customization. The cost of changing might not be something they can recoup given they seem to be in a sustainable state now when it comes to base OS kernel support. Whether Exchange, SharePoint or the Azure management plane are a steaming pile or not is unrelated to the quality and brand of the underlying kernel.

Obligatory Joke

Posted Jan 10, 2025 20:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> I believe they also use the Windows kernel as the basis for Azure

As I understand, most of the networking-level hardware in Azure actually runs Linux ( https://www.wired.com/2015/09/microsoft-using-linux-run-c... ).

As for the hypervisor, the current generation of AWS products uses custom hardware to completely decouple the hypervisor from the underlying guest OS. So the type of a kernel that runs on this hardware is not really that important, in the grand scheme of things.

Obligatory Joke

Posted Jan 11, 2025 1:35 UTC (Sat) by raven667 (guest, #5198) [Link]

Yeah, pretty much all datacenter networking hardware runs Linux now, AFAICT.

I was thinking of the hypervisor, as you said AWS has their own in-house thing, so did VMware and effectively, so does MS.

Risks versus other risks

Posted Jan 2, 2025 18:35 UTC (Thu) by pizza (subscriber, #46) [Link]

> Increasingly, single-maintainer projects (or subsystems, or packages) will be seen as risky by their users.

...Unfortunately, "seen as risky" won't actually result in additional maintainers or even non-minor contributors stepping up. And in in the situtation where that does happen, it turns out new contributors are an even riskier proposition.

On Android distros

Posted Jan 2, 2025 18:42 UTC (Thu) by sionescu (subscriber, #59410) [Link] (25 responses)

> Distributions for mobile devices will see a resurgence in interest

It will be interesting to see how this will interact with the device security attestation that's built into Android. Many banking apps will refuse to run on a device that was unlocked or has even one app installed from an unknown source (i.e. neither the Google Play store nor the manufacturer store).

On Android distros

Posted Jan 2, 2025 21:26 UTC (Thu) by epa (subscriber, #39769) [Link] (11 responses)

Presumably if you control the distribution all the way down to the kernel, you could program it to hide the apps that are installed or change the ‘unlocked’ flag.

On Android distros

Posted Jan 2, 2025 21:50 UTC (Thu) by intelfx (subscriber, #130118) [Link] (4 responses)

> Presumably if you control the distribution all the way down to the kernel, you could program it to hide the apps that are installed or change the ‘unlocked’ flag.

The "remote attestation" thing (read: pervasive DRM facilitated by hardware) is explicitly designed to mitigate this... unfortunate possibility (unfortunate, of course, in the eyes of the commercial interests).

On Android distros

Posted Jan 2, 2025 22:06 UTC (Thu) by epa (subscriber, #39769) [Link] (3 responses)

Yes, I guess it depends on whether you have open hardware or there are some parts of the system (a TPM) that not even the kernel can fully control.

On Android distros

Posted Jan 3, 2025 2:12 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Most (all?) mobile devices have two systems in one chipset, one is running Android (or other high-level OS) and the other one runs proprietary RTOS and certified to drives the radio.

Guess which one is in charge of everything and couldn't be easily touched and/or changed?

On Android distros

Posted Jan 3, 2025 8:56 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

That’s true but I think it is not what we were talking about. A banking app does not check whether your phone’s radio is operating within FCC parameters. It may ask to list the apps installed at the Linux level or whether the user has root access (which does not give you control over the locked-down radio hardware).

The question is whether there is a third piece of hardware, the TPM, which can be queried from user space but isn’t under the device owner’s control, so you cannot tell it to say you are running a particular software stack when you aren’t.

If you do have root you could in principle attach a debugger to the misbehaving app and alter its memory to make it run anyway, but that wouldn’t help with a cryptographically strong attestation to a remote server using a private key locked inside the TPM.

On Android distros

Posted Jan 3, 2025 14:56 UTC (Fri) by khim (subscriber, #9252) [Link]

> A banking app does not check whether your phone’s radio is operating within FCC parameters.

Sure, but the existence of separate, “hidden” and “secret” world means this quesion

> The question is whether there is a third piece of hardware, the TPM, which can be queried from user space but isn’t under the device owner’s control, so you cannot tell it to say you are running a particular software stack when you aren’t.

Has very definitive and obvious answer: yes, there is such a piece of hardware. And you can not forge it.

Of course many banking apps look for things that shouldn't concern them (things like what other apps are installed), and these can be easily forged by suitable firmware.

But if they just look for the attestation then this couldn't be forged.

> If you do have root you could in principle attach a debugger to the misbehaving app and alter its memory to make it run anyway, but that wouldn’t help with a cryptographically strong attestation to a remote server using a private key locked inside the TPM.

Of course our world is not perfect and we couldn't have nice things: because in certain places hacked Chinese phones are extremely popular (they are cheaper but need hacked ROM to stop phoning to the Chinese landlords) banks couldn't just trust the attestation. Instead they invent elaborate schemes that allow the use of some of these hacked phones, but not all hacked phones.

Whether it'll work on your device depends on the bank and the phase of the moon.

On Android distros

Posted Jan 2, 2025 22:10 UTC (Thu) by excors (subscriber, #95769) [Link] (5 responses)

The kernel may not be low-level enough - the Google Play Integrity API reports a few different levels of integrity, and I believe the strongest requires Verified Boot and hardware attestation to prove you're running a certified, locked, unrooted, official bootloader/kernel/etc (https://developer.android.com/google/play/integrity/verdi...). If an app requires that level of integrity, and is willing to sacrifice compatibility with older Android devices and niche device configurations, no amount of fiddling with software will get around it (barring severe bugs in the implementation).

GrapheneOS notes that instead of using the Play Integrity API, apps could use AOSP's lower-level attestation API and choose to accept devices that match a list of "official GrapheneOS verified boot keys" (https://grapheneos.org/articles/attestation-compatibility...), which should provide a similar level of assurance without being tied to the proprietary Google Play Services. But I don't know if any serious apps actually do that.

On Android distros

Posted Jan 3, 2025 11:31 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

What is to stop the API reporting that it's certified and unrooted when running a custom distribution?

On Android distros

Posted Jan 3, 2025 12:08 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

The app connects to some online service (e.g. your bank) which controls all the sensitive data this system is trying to protect. (It's not meant to protect purely offline apps). The app uses the API to get a securely signed attestation report, which it forwards to the online service for verification (checking the root certificate is signed by Google's attestation root key, the Verified Boot details say it's running trustworthy firmware, etc). The app/kernel/firmware can't forge the signatures, because the hardware does a reasonable job at keeping the private keys secret, so the server would reject a fake report and the app wouldn't have access to your money/secrets/etc.

On Android distros

Posted Jan 3, 2025 14:01 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

So you're saying the signature for the attestation report comes from the TPM (not the Linux operating system).

On Android distros

Posted Jan 3, 2025 16:25 UTC (Fri) by excors (subscriber, #95769) [Link]

Basically, yes.

(Technically it's not called a TPM, probably because that's a specific ISO standard and they don't implement that, but it's a vaguely similar idea. On Pixel phones there's a small 'secure' OS running on the main CPU in parallel to Linux, using ARM TrustZone for isolation; plus a security core on the main SoC, with its own dedicated CPU/RAM/etc running another OS; plus a physically separate security chip with yet another simple OS. Some combination of those are used for Verified Boot, attestation, etc. See https://security.googleblog.com/2021/10/pixel-6-setting-n...)

On Android distros

Posted Jan 10, 2025 13:30 UTC (Fri) by anton (subscriber, #25547) [Link]

According to the German Wikipedia, GrapheneOS works with a number of banking apps (the bank where I have my main account is listed). I don't know if these apps use the attestation API, but it certainly looks encouraging.

On Android distros

Posted Jan 2, 2025 22:13 UTC (Thu) by leromarinvit (subscriber, #56850) [Link] (12 responses)

> Many banking apps will refuse to run on a device that was unlocked or has even one app installed from an unknown source (i.e. neither the Google Play store nor the manufacturer store).

Funnily enough, I've seen more issues running banking apps on stock Android. Root it and hide everything but base system stuff using MagiskHide (or whatever it is called now), and poof, the problem is gone.

The day they start effectively locking rooted devices out is the day I'll quit my account there, making sure they know why (not that I expect them to care). First of all, because it's the only language they'll understand. But even more importantly in practice, dealing with such restrictions just complicates daily tasks too much. They decided I have to use their app to confirm transactions - not what I'd have preferred, but fine, I'll go along as long as it doesn't cause too much friction. But they sure as hell don't get to decide what hardware or software I'll run their app on.

On Android distros

Posted Jan 3, 2025 6:10 UTC (Fri) by merge (subscriber, #65339) [Link]

I don't use stuff that ties an online account to one specific device (that qualifies as what I tell my kids to be a "large" computer - phone/tablet/tv...). I always want to be able to switch devices easily.

I don't have a google account. When I'm asked to use the banking apps I ask "why would I create an account with google or apple company now? that doesn't feel right for wanting to use online banking." nobody in a bank has a good answer for that and I now use a "cardtan" device ("small computer", i.e. non-connected uC-based).

Similar story for the "legal services" app in my country where I use a fido2 key instead of an app.

While the app-solutions are what people are primarily shown and using, I guess there's good reasons for why this is not the only technical solution for critical services. I hope there's even a law that requires that, not sure.

On Android distros

Posted Jan 3, 2025 9:06 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (10 responses)

I believe they will be happy to let you go. The cost of losing one client is much much less than the cost of fraud the banks are on the hook for. They minimise their risk by requiring certain platforms with known security profile.

You may be tech savvy enough to secure your device, but you're an outlier among banks customers. It is safe (less risky) to NOT serve such complaining liability. Sorry, that's life.

(I've worked in three different banks in EU, I know some internals).

On Android distros

Posted Jan 3, 2025 9:43 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> I believe they will be happy to let you go. The cost of losing one client is much much less than the cost of fraud the banks are on the hook for. They minimise their risk by requiring certain platforms with known security profile.

The problem is they are trying to force everyone on to mobile. I wanted to read the small print for a loan. So I logged on to the "bank" to look for it. Next thing I know, "give us your mobile so we can finish everything ..." with NO apparent way to bypass it!

With fat fingers and aging eyes, do you really think I want to read the small print on a screen I can hardly see!!!

I've got no security conscious stuff on my personal phone (other than 2FA for work), and I have no intention of putting anything such on it. Anything of note (that doesn't require a PHONE) gets done on a minimum 15" screen. Usually with a 24" monitor attached.

Cheers,
Wol

On Android distros

Posted Jan 3, 2025 13:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

That's really terrible. Here in Canada, all of the banks still support almost all banking via a vanilla web browser rather than forcing you to use an app. The only exception is remote cheque deposits.

If my bank forces me to use a mobile device, I'll switch banks. If all of them do, I suspect there will be a legal challenge, probably on the basis of accessibility. I doubt the mobile banking apps support visually-impaired users.

On Android distros

Posted Jan 3, 2025 19:31 UTC (Fri) by Wol (subscriber, #4433) [Link]

It was actually Volkswagen Finance. "Take out a finance deal and get a £4K discount" iirc. But from what I could make out, they added all the interest up front when calculating the repayments, and I didn't trust them to refund the finance charges if I repaid it early. That was what I wanted to check, and I got the distinct impression any refund was discretionary ... so if you took the loan to get the discount, then repaid it after a month or two, you could end up out of pocket. I chose not to take the risk.

Cheers,
Wol

On Android distros

Posted Jan 5, 2025 0:08 UTC (Sun) by jkingweb (subscriber, #113039) [Link]

> Here in Canada, all of the banks still support almost all banking via a vanilla web browser rather than forcing you to use an app. The only exception is remote cheque deposits.

RBC has a lower limit for Interac transfers via the Web than their app, too.

On Android distros

Posted Jan 3, 2025 16:20 UTC (Fri) by busman (subscriber, #7333) [Link] (1 responses)

Why mobile apps need such draconian measures while desktop browsers don't? I can happily use Firefox on Linux without my banks complaining but having *less* functionality in mobile clients is somehow more dangerous (for some of them)?

On Android distros

Posted Jan 3, 2025 17:01 UTC (Fri) by excors (subscriber, #95769) [Link]

I think it's not about "need" - it's a tradeoff between security and compatibility. There's no practical way to do this kind of integrity verification on PCs, and blocking access from all PCs would drive away too many customers, so the banks will put up with a certain level of fraud from keylogging malware etc. But there is a practical way to do it on modern phones, and blocking access from unverified phones would only drive away a small number of customers, so they've decided the reduction in fraud makes that worthwhile.

(My bank also makes the app much more convenient than the website - e.g. I can set up new payments through the app with just a fingerprint (and maybe facial recognition if it's a large amount of money), whereas on the website I need to type in my ID and password and then insert my physical card into a card reader to generate authorisation codes to type in. There's always a security vs convenience tradeoff, but the improved security of the phone platform means they can increase convenience and still keep fraud within acceptable levels.)

On Android distros

Posted Jan 4, 2025 5:12 UTC (Sat) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

Here in good ol' 'merica, I know of at least one major brokerage firm (perhaps THE largest) that doesn't even require 2FA ... anywhere :)

For that reason, I strongly suspect the "rooted Android = no banking app" problem is likely specific to over-regulated Europeans.

On Android distros

Posted Jan 4, 2025 13:32 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

> For that reason, I strongly suspect the "rooted Android = no banking app" problem is likely specific to over-regulated Europeans.

By "over-regulated" I guess you mean the banks can't tell the customer to suck it up if money vanishes from their account without the customer being involved?

Because banking regulations don't say anything about Android phones, rooted or otherwise. Or even apps.

On Android distros

Posted Jan 5, 2025 9:13 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (1 responses)

my bank in italy retired the 2fa hardware tokens and moved to sending the otp via sms. They said it was because of european regulations. I went to read the regulation and it said to use hw tokens, prefer to avoid otp apps and absolutely never send the otp in clear text.

Banca san paolo if you are wondering. A very large bank.

On Android distros

Posted Jan 5, 2025 9:37 UTC (Sun) by Wol (subscriber, #4433) [Link]

Sounds right. Lorry drivers are allowed to drive a maximum of 13 consecutive days without a 2-day (45hrs to be pedantic) break.

One of my colleagues - responsible for enforcing the regs !!! - insisted that meant "one break every second week", and then designed our enforcement system to only look back 8 days. I still think he doesn't understand what's wrong - he hates the system I wrote to replace it ...

Cheers,
Wol

Notable by its absence

Posted Jan 3, 2025 6:08 UTC (Fri) by alison (subscriber, #63752) [Link] (7 responses)

Inspired by reading Corbet's ever informative report about contributors to each kernel, the looming question is what effect Intel's evident difficulties will have. As has oft been noted, many companies will support developers who write device drivers for their own hardware or contribute to arch/ for their processors. Fewer are employers who are willing to underwrite more fundamental, hardware-agnostic improvements and innovation in kernel/, tools, and tests. Among the latter group, the long-term principal contributors have been Intel and Redhat. Samsung, Google, Meta and Huawei among others have been stepping up, but filling a hole left by a diminished Intel contribution would be painful indeed.

Notable by its absence

Posted Jan 3, 2025 15:40 UTC (Fri) by willy (subscriber, #9762) [Link] (6 responses)

I think you missed at least one employer who makes significant contributions to mm, fs and other core functionality ;-)

It's interesting to watch where the contributions come from; originally it was mostly distros (RH, SuSE, etc). Then the traditional Unix vendors (IBM, HP, SGI, Sun, Digital, etc). Then came the consumer HW vendors (as you say, Samsung, Huawei, etc). The big employers right now are the cloud vendors (Google, Meta, Microsoft, Oracle, Huawei, Alibaba).

We survived the Intel layoffs of 2016. Anyone good got snapped up immediately, and I can promise you there is no shortage of demand to hire people who already have dozens of kernel commits. People will undoubtedly change their focus when moving to a new employer, but the pace of contributions will not slacken.

Notable by its absence

Posted Jan 3, 2025 22:55 UTC (Fri) by cschaufler (subscriber, #126555) [Link] (5 responses)

I can't agree that the pace of contributions will not slacken. Think of the maintainers of IA64, who's specific skills may not translate well to other architectures. Maintainers who leave one job frequently find reduced support for their projects in the next. Some maintainers who are let go decide to leave the open source community entirely, either by taking unrelated positions or retiring.

Notable by its absence

Posted Jan 4, 2025 13:45 UTC (Sat) by willy (subscriber, #9762) [Link] (4 responses)

Yes, when Intel laid me off in 2016, I had a good long think about whether I wanted to continue working on the kernel and indeed in open source at all.

Ultimately I decided to keep working on the kernel, but not on DAX. Which decision has been vindicated, unfortunately, by Intel's inability to bring a successful product to market.

But I disagree that the hypothetical ia64 maintainer would have few transferrable skills. An architecture maintainer must be a jack-of-all-trades. They typically know a fair bit about mm, fs, firmware, and device drivers.

Anyway, my point is that kernel hackers remain in high demand and are only out of work for as long as they want to be (modulo other constraints like work visas and so on). You really have to try hard to be an unemployable kernel hacker.

Notable by its absence

Posted Jan 4, 2025 18:30 UTC (Sat) by alison (subscriber, #63752) [Link] (3 responses)

willy notes:
>kernel hackers remain in high demand and are only out of work for as long as they want to be

Clearly! But a kernel hacker's next gig might be writing out-of-tree scheduler extensions for fintech, or supporting a private fork of bcachefs. We can't count on new employers being as generous with core-kernel support as the biggest code contributors have been historically.

Notable by its absence

Posted Jan 4, 2025 19:54 UTC (Sat) by willy (subscriber, #9762) [Link] (2 responses)

That absolutely could happen! It's happened before; one could include the Lustre folks who, while not closed source, are out of tree and make few contributions to the mainline.

I certainly have had offers to do closed source projects ... and haven't accepted them. I used to get offers to be CTO at various startups which is hilarious from multiple points of view (I would be a terrible CTO). I was also offered the opportunity to work on NVMe firmware.

I'm not saying I can't be bought, but it'd have to be a lot of money or a really interesting project for me to find it worth doing. I did take close to three years off from kernel contributions while I was at Intel to work on NVMe, and I think we can all agree that worked out well for everyone.

There are still a lot of companies who are interested in hiring kernel developers to contribute to upstream. Anecdotally, that seems to be the largest pain point -- they want to get their changes upstream but don't know how to do it. Hiring someone with a track record of getting patches upstream is a good way of solving this problem with money.

Notable by its absence

Posted Jan 6, 2025 4:41 UTC (Mon) by tim-day-387 (subscriber, #171751) [Link] (1 responses)

Slightly off-topic, but Lustre is still working (perhaps slowly) towards inclusion in mainline. The code is in much better shape compared to when the client was kicked out of staging. Of course, there's still a lot more to be done. But I'm optimistic Lustre could land in mainline someday.

There's a tracking ticket in the Lustre Jira and an update from James Simmons at LUG24 about the ongoing work for those curious.

Notable by its absence

Posted Jan 6, 2025 16:47 UTC (Mon) by joib (subscriber, #8541) [Link]

Seems the big mistake last time was that the in tree version was more or less a fork occasionally maintained by a few people, whereas users and developers ignored it and continued with the out of tree version.

If they want to make a success of it this time, I think they will need to adopt an upstream first approach.

Number of exploits

Posted Jan 3, 2025 7:52 UTC (Fri) by jezuch (subscriber, #52988) [Link]

Perhaps we should bet on the *number* of XZ-like "incidents" (wait, no catchy name and logo?) we find.

I may be an AI

Posted Jan 4, 2025 1:04 UTC (Sat) by SLi (subscriber, #53131) [Link] (1 responses)

> A major project will discover that it has merged a lot of AI-generated code, a fact that may become evident when it becomes clear that the alleged author does not actually understand what the code does. We depend on our developers to contribute their own work and to stand behind it; large language models cannot do that. A project that discovers such code in its repository may face the unpleasant prospect of reverting significant changes.

I'll have to remember to check if I'm an AI next time I don't understand what code I have written does.

It happens enough, and I'm not convinced my best guess after staring at it is necessarily fundamentally that different from an AI's guess at what a piece of code does (well, I think I still do a slightly better job there than the AIs, but then I like to remind people that generalist LLMs are very new technology).

I may be an AI

Posted Jan 5, 2025 18:40 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

I distinctly remember writing some code for a system, that was designed to do X, to make it do Y instead of X. It was long and ugly and involved multiple nested loops. It had incredibly poor performance, taking over a minute to do something that ought to finish in seconds.

One day, I had an epiphany, and restructured it so that the loops were nested differently and we iterated in a different overall order. This literally cut the execution time in half. Subsequently, I was entirely unable to explain how I saved that much performance with such a trivial refactor. It was in Python, with lots of indirection and hash map lookups, so no, this was not a simple case of cache locality. I think it probably involved early returns and avoiding some redundant iterations, but it was a long time ago and I do not remember the details.

The story has a happy ending: We decided to go back to doing X (instead of Y), so the code was deleted, everything went back to reasonable performance, and nobody has to try and understand it anymore. Y was a dumb idea in the first place, and we really only did it as a stopgap as part of a tech migration, so we're probably not going to try and do it again.

more fully open hardware ...

Posted Jan 7, 2025 0:46 UTC (Tue) by vimja (subscriber, #91577) [Link] (1 responses)

> As a corollary to the above, more fully open hardware will become available in 2025.

Everyone go check out the mnt reform next open hardware over on Crowdsupply.

more fully open hardware ...

Posted Jan 16, 2025 14:28 UTC (Thu) by brunowolff (guest, #71160) [Link]

I'm hoping Raptor Computing Systems gets some new products this year. They were involved with getting a new Openpower processer developed, but there hasn't been any public updates for a while on how that is going.
Those guys are very serious about owner controlled computing.

Open source LLM models

Posted Jan 16, 2025 10:52 UTC (Thu) by davidgerard (guest, #100304) [Link]

> we will see more focused efforts to create truly free generative AI systems, perhaps including the creation of one or more foundations to support the creation of the models.

IBM/Red Hat has been talking up for a while a pile of LLM models trained on open source code under specific licenses:

https://www.redhat.com/en/about/press-releases/red-hat-de... -- press release from last May

but it's not clear how available any of this is. I've asked if anyone's using this in the wild and yet to hear a peep.

Flame Boy Ant Pip

Posted Jan 20, 2025 14:07 UTC (Mon) by overhung-jujitsu (guest, #175503) [Link]

The United States has not recently "taken an us-versus-them turn" in its political discourse through natural evolution. Instead of being a natural & passing tide, the observed tribalization may be a synthetic behavioral-change strategy, actualized by surveillance-capitalist third parties working outside the spotlight. Does not each year of human suffering without changes in power provide us more evidence that our world is unfolding as Shoshana Zuboff outlined in "The Age of Surveillance Capitalism" (2019)?

A pattern: "What appears as B versus C is, in fact, B subdivided into {B and C} or {B and C and D...}, such that the relationship becomes A versus (B versus C...), where A represents those who can modify behavior among members of the original B." The merging of GNU/free software with the fabricated "open source movement" – rather than the conflict itself being entirely fabricated–seems like an inverse variatant of the same con.

To what extent should we factor when modeling threats to free software currently neutral but possibly adversarial in future A's?


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds