What is lacking in the previous one? NTFS support in linux is mostly to read and write files from windows disks, right? I think all the NTFS linux drivers - even the fuse one before the Paragon one - have been alright at that.
Ubuntu switched to the Paragon NTFS driver by default. When I upgraded to kernel 6.5 (I think) from Ubuntu, I started getting frequent kernel panics, like every day. Soon, I noticed that I couldn't even compile a Rust project on an NTFS partition because the compiler was getting random file system errors, and compiling was at high risk of causing a kernel panic. The NTFS driver in that kernel version is just totally broken. I switched to the FUSE NTFS-3G, and then I stopped getting panics and can compile stuff again no problem.
Looking at kernel commits, it looks like the driver may have been fixed since, but I'm scared to use it after it had such major brokenness in that version.
It wound up being OK, but it had a long span of time where it was virtually unmaintained and turned out to be buggy at points. The newer NTFS driver is based off of the old read-only NTFS driver which subjectively many claim is cleaner (I honestly haven't done a head to head so idk) and they're having an easier time modernizing it with support for things like large folios. Seems like a good deal to me.
Personally: I used NTFS3 and it was alright. If anything the biggest thing I got hit by was an issue where the udisks2 mount call from Dolphin would result in NTFS-3g specific flags getting sent to it, causing the mount to fail. But in actual usage it actually worked just fine for me.
> Linux 7.1 is also notable for its code removals. Driven by AI-assisted bug reporting, ISDN and other old network driver code was removed to avoid that influx of bug reporting against those very rarely touched or used drivers for obsolete hardware.
Moving really old and unused code out of the kernel just to get less AI-assisted bug reports is IMO one of the best consequence ever of AI.
I love it.
We should start trimming the fat out of everything.
Presumably that old code was actually useful at the time it was added. It might not be used now, but it helped someone back then. One of the great things about early Linux was that it tried to run on every piece of hardware available. If Linus only wrote drivers (or allowed others to submit drivers) that worked on his personal computer, Linux would have never flourished this far.
Is the parent really being sarcastic? I read it as genuine.
There’s presumably plenty of code bloat in the kernel, and while no human would ever scan for bugs in a corner of the kernel that hasn’t been used or touched in decades, AI 100% will. And while those bug reports might be useless as bug reports, they seem promising as “why is this code even here?” flags.
I don't mean to be harsh, but if there's a codepath that is exercised on your hardware, but not on mine, I don't think it would be fair for me to deem it as "bloat". There are a TON of supported devices and use cases that are not my own, but are essential to someone else.
Sure, sure. I’m not arguing for removing drivers for uncommon devices, or even rare devices. But there’s a line somewhere. Maybe it’s at “devices that no longer exist.” But I think it’s somewhere before that. And I have no idea how you’d figure out which devices fall where around this hypothetical line. I can only hope that they had good justification for these removals.
Maybe that points to an architecture issue? Is kernel driver support general enough to support all hardware in theory? If so it should be on hardware to provide a compatible api IMO. Note: I really have no experience in any of this there is probably more important things to consider like security/control or something.
I remember working with a guy who apparently deleted more code than he added in his time at the company. I think it said more about the codebase than anything but it was good that someone was trying to make it better.
Funnily, I have been that guy at the last 3 places I've worked at. Every place has some amount of cruft code, and I love sniffing it out and deleting it.
It's ok, you can let go of Chesterton's ISDN phone pole now. Come, we have cable, we have fiber. Just for you, I'll even fire up a little hotspot from the palm of my hand as we walk away.
Chesterton's Fence only says to learn why the fence was erected, it gives no other guidance on what to do after that. There isn't too much mystery in why a device driver was made, so Chesterton's Fence yields next to nothing here.
That's good for your personal computing, but a renewing forest fire is good for all sorts of organizations. And species. It's a very good algorithm to run.
It's naturally de-ossifying and forces uptake of new methods and practices.
It gives you an opportunity to question assumptions and do things greenfield again.
The old unmaintained ISDN hardware for which the code has been removed is likely 20 years old, or so. The perfectly good laptops are usually 3-4 times younger.
FreeBSD and NetBSD aren't going anywhere and can be used for older hardware, for the amount of production and load bearing use Linux sees there's an enormous amount of cruft and garbage in it.
> very rarely touched or used drivers for obsolete hardware
I guess end users can not upgrade but a definition of obsolete would be nice.
To me, every HP printer ever is obsolete. But I assume someone else has an equally valid and different opinion. How does that go with computer hardware?
Is there anything particularly interesting about this? The first number of the version changes when the second number gets too big, not for any other reason.
But not a very accurate blogpost. "Here's why this literally cannot work (in theory)" to denigrate a system that actually works (in practice). Their goal is to convince people to stop using it because it personally inconveniences them, but they never provide an alternative solution that actually solves the problem (in practice) that Anubis actually solves (in practice). If leaving the problem unsolved (in practice) was a desirable option, the site owner would not have turned to Anubis in the first place.
before and after apache logs showing much less crap in them from bots. Do you think the maintainers of https://lore.kernel.org/ would leave something in that didn't work? It isn't perfect but I have run it on a (much smaller) web site getting hammered by bots and logged "before" and "after" and the difference is measurable.
Its literally trivially objectively measurable, this isn't something that is based in opinion.
You can throw it up on your own website and simply grep the logs if you don't trust it, or look for the analysis reports from people who have done exactly that.
Like the other commenter said, why would linux.org deploy and leave deployed a technology that did nothing? Do they just enjoy trolling users? I doubt it.
It's mostly surprising how many grown adult men go into a blind rage when confronted with a picture of a cartoon woman. In a lobsters thread about Anubis, a community member of 12 years got themselves permanently banned because they were frothing at the mouth with accusations of pedophilia against the developer and refused to apologise when given an opportunity by moderators. Telling on themselves, perhaps? It's funny, in a bizarre way, that this is a hill people will die on.
> ...they were frothing at the mouth with accusations of pedophilia against the developer...
I think I remember that thread. IIRC, it went something very, very roughly like this:
Future banned user: It weirds me out a bit how young the mascot looks. I've never been comfortable with cutesy, underage-looking mascots.
The dogpile: How dare you insinuate that the dev a pedophile? Don't you know how anti-trans that dogwhistle is?
and the conversation degraded from there.
I'll also note that you chipped in with
> It's mostly surprising how many grown adult men go into a blind rage when confronted with a picture of a cartoon woman.
when -AFAICT- noone in this subthread expressed anything more heated than "dislike of kawaii". But perhaps you were speaking more generally, and weren't inspired by any conversation that happened in this subthread.
Places that want to use Anubis but find the logo not professional enough are free to pay the author, IIRC it was major "professional support" benefit :D
- "Anyway, possible slight hiccups in the merge window aside, the news
today is 7.1."
- "nothing particularly interesting or scary stands out, which is as it should
be."
Yeah, it gets boring when the number change doesn't change and try improving everything at once, but the great thing is that freshness improves driven by number fomo and that tightens the improvement loop.
Exciting and risky things are always under flags, so if you really care you just build, configure, and bench your own kernel+system.
It’s fairly easy to build your own kernel packages from vanilla sources in Debian. I’m running the latest 7.0.x within a few hours of its release. The build takes about 30-45 minutes depending on how much time I spend on skimming the ChangeLog. YMMV.
If you don't actually need all the drivers, you can use "make localmodconfig" to substantially reduce that. My local kernels build in 90 seconds on a 32-thread desktop machine :)
The kernel is a lot more stable than people think: I run the daily linux-next on my Debian stable gaming PC to look for bugs, and I don't find very many.
You're being a bit disingenuous, it builds in 90 seconds because you build it daily and the vast majority of objects are unchanged and cached by ccache.
A stripped down cold build will literally take 90 seconds without caching on modern hardware.
The overwhelming majority of stuff that is being built is drivers, and most of them probably aren't needed for any specific user, so you can disable quite a lot of stuff.
Fwiw a full build of the fedora kernel config takes around 5-10m for my 12core ryzen 3900x, and it's definitely not the fastest CPU around.
I did that for a while because of compatibility issues with a newer laptop, it works but generally if there is no reason it's way easier to stay with the provided packages. Compiling weekly due to security patches becomes annoying over time for no real gain other than the version number
> It’s fairly easy to build your own kernel packages from vanilla sources in Debian.
IIRC, Debian has a command called "make-kpkg" which does nearly all the work for you, ending up with a installable package which works identically to the standard Debian kernel packages.
Wouldn't Forky/14 have this or newer when it releases next year? Debian moves slow - deliberately so, if you want fast use Arch or Fedora - but it does move.
Not a serious question but I'll give a serious answer anyway.
The last time I worried over which kernel was used in Debian Stable was... never. If I want a more recent kernel I run Debian unstable (Sid) which currently is at 7.0.12 (the current 'stable' kernel where 7.1 is 'mainline') but on my servers Stable (currently 'Trixie') does just fine with its 6.17.3 kernel. Debian 'Forky' will be released somewhere in 2027 with either a 7.0.x or 7.1.x kernel depending on how things go. The current kernel used in 'testing' (which will become 'stable' on the next release) is 7.0.10.
People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:
# Default to trixie
Package: *
Pin: release n=trixie
Pin-Priority: 990
# Very low priority for sid
Package: *
Pin: release n=unstable
Pin-Priority: 100
# Give backports medium priority
Package: *
Pin: release n=trixie-backports
Pin-Priority: 500
Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable:
> People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
Which is just as well, because that's not generally a good idea unless you really know what you're doing:
Granted, the kernel is probably the best thing to do it with, on account of their aggressive stance on compatibility and the narrowness of impact (no .so files in play).
Backports are meant to work well along stable packages, but I agree it's definitely not a good idea to start pulling from sid from trixie (for regular packages, kernel is fine), this is asking for a ruined system.
Chaing priority wholesale is not needed just to install kernel image and might break other packages. Just install kernel image from backports after enabling backports.
> apt install linux-image-amd64/stable-backports
Somehow installing with `trixie-backports` isn't picking up latest kernel for me. Used what is being displayed in `apt search linux-image-7`
> The last time I worried over which kernel was used in Debian Stable was... never.
It was briefly a little annoying to deal with wireguard. But it was only a bit annoying, and then they updated. That's the only time I recall specifically caring.
Yes, when that was a thing I just compiled the wireguard module myself to feed it to the virtual router. It was only needed for a short interval and was thereafter handled by dkms, i.e. no problem.
I know it's a bit of a meme but I'm on Debian Stable and I am running the backport kernel, which is on version 6.19. So only one minor version away from the current 7.0.
I wish more people would consider Debian for their devices. It is a very stable system, which I appreciate, and, unlike Ubuntu, it was really an "it just works" experience, without any of the friction points that smaller distros have. I installed Debian Trixie on a very recent device (granted, all AMD for compatibility) when Trixie was still the Testing version, and all the necessary drivers were present.
Now if only I could figure out how to build packages and contribute back to Debian... Also if only AMD could get their NPU support for Linux figured out...
Probably because it got popular as the easy Linux distro back in the 2000s and that label is sticking.
I remember that I attempted to install Debian on my laptop in 2009. It was ugly. I installed Ubuntu 8.04 and it was a totally different and much nicer experience. Because of that I've been on Ubuntu until they started pushing snaps very aggressively. I live booted Debian 11 and realized that its UI was exactly the same. I don't know when it happened during that dozen of years but there wasn't anymore a reason to stick to Ubuntu. I installed Debian 11 and got a faster machine with less background processes. I'm on Debian 13 now. I've been told that KDE is much better than what I attempted to use in 2014 so maybe I could give it a try, but it's unclear to me what I have to gain.
I prefer KDE (on Ubuntu, because I tried it and it's good enough) - it's got more stuff built into the OS in terms of settings. I tended to find that Gnome needs you to install more things to expose configuration settings, whereas KDE's configuration UI is pretty good.
For me, it was kubuntu. Back in late 2005 or early 2006. The reason? They were always pretty good at shipping the latest KDE. I had grown tired of hoping someone would compile a new version for my preferred distro.
So kubuntu it was, and has been ever since. I'm currently looking into whether I should change to something else - as I've started growing tired of Ubuntu/Kubuntu after some 20 odd years.
I'm of the belief that the more popular an OS is, the more maintainers it will have (and thus less bugs). The only thing about Ubuntu that I hated was its choice of windowing manager. That's why there are so many variants like KUbuntu, XUbuntu, etc. Are there other reasons to not like Ubuntu other than the windowing manager?
> Are there other reasons to not like Ubuntu other than the windowing manager?
Snap applications are still not “equal enough” to installed apps.
They have gotten better, but it’s not seamless and when you get burned it’s 2 hours debugging. Each time.
An app I use/help maintain regularly gets bug reports about sandboxed behavior. It’s understandable but the easiest fix is to install an unsandboxed version.
I personally have some extra steps in my workflow for printing from a snap application because it doesn’t just work and I don’t want to spend the hours needed to debug it.
Come on - at least make one substantive criticism in your post putting down Ubuntu.
I came to Ubuntu because Wine worked on it with no effort. Yes, this was a long time ago. I have certainly cursed some of their changes since then, but I don’t want to spend my time doing yet another sysadmin job, so the less I change the better.
Well, it starts with when I have to opt out of location services during install, and Ubuntu reserving usernames (admin, for example) and ends with how aggressively they shut down upstream repos… if they’re not being DDoSd. Package conflicts are miserable, so they tried to paper over it, adding yet another bullshit layer of things to debug when something invariably breaks.
I’d rather flip the question back on you, how is Ubuntu better than, say, Rocky? If you say “upgrading is easier” I’ll chuckle for the rest of the day.
Ubuntu offered a slightly prettier installation experience.
Sure, no matter which distro you were installing you still had to provide a hostname, a domain name, some IP info (maybe), and an opinion on partitioning - there's only so many ways to ask the user these questions - but the ubuntu installer was prettier.
Around the time it was gaining popularity, almost every 'reviewer' (blogger) seemed to waste about 85% of their distro reviews talking about the installer - as though this was somehow important. The big sell of Debian, and Debian-derivatives, is that you install once, and then it's just in-place upgrades forever. The distro-hoppers, Microsoft evacuees, content-creators, etc - didn't really get that.
Anyway, once Ubuntu was installed it was much the same to operate as a Debian box. Obviously there were some surprising differences. Unity. Mir. One Cloud. Wubi. Upstart. Bazaar.
Actually, I'm running the backports kernel which is at 7.0 today.
$ uname --kernel-release
7.0.10+deb13-amd64
If you run stable, Debian backports takes care of a lot of the popular stuff. Kernels, kernel modules, Rust/Cargo, CMake, Clangd, GPU firmware (AMD/Intel), GDB, LibreOffice, OpenShot video editor, and Wireguard are all kept current in backports. And there's way more than I mention here, of course. Worst case I can install unstable in a schroot and run some bleeding-egde software.
I did all of my distro hopping when I was young, 20+ years ago. I settled on Debian because life got busy and I had no time to fuss with broken software updates.
doesn't debian usually stick to LTS kernels? afaik 7.0 was designated as an LTS release so it'll probably be the version that next major release will ship with (next year maybe?)
Personally, I'm pretty excited for this commit which fixes the slow WiFi I've had with the combination of my ISP's modem/router and my laptop.
https://github.com/torvalds/linux/commit/711a9c018ad252b2807...
Hope it gets to Fedora soon!
Here's the mail for that for anyone curious
https://lore.kernel.org/all/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzq...
Looking forward for a new NTFS driver to try. I hope this new iteration will be better than ntfs3 from Paragon.
It’s good. I packaged it in my gentoo overlay and have been using it for a couple months, none of the weird issues ntfs3 had.
What is lacking in the previous one? NTFS support in linux is mostly to read and write files from windows disks, right? I think all the NTFS linux drivers - even the fuse one before the Paragon one - have been alright at that.
The Paragon v3 NTFS driver was in perpetual beta with a scary warning about data loss whenever it was enabled.
I think users moved on when they saw no real harm in continuing to use it.
Ubuntu switched to the Paragon NTFS driver by default. When I upgraded to kernel 6.5 (I think) from Ubuntu, I started getting frequent kernel panics, like every day. Soon, I noticed that I couldn't even compile a Rust project on an NTFS partition because the compiler was getting random file system errors, and compiling was at high risk of causing a kernel panic. The NTFS driver in that kernel version is just totally broken. I switched to the FUSE NTFS-3G, and then I stopped getting panics and can compile stuff again no problem.
Looking at kernel commits, it looks like the driver may have been fixed since, but I'm scared to use it after it had such major brokenness in that version.
It wound up being OK, but it had a long span of time where it was virtually unmaintained and turned out to be buggy at points. The newer NTFS driver is based off of the old read-only NTFS driver which subjectively many claim is cleaner (I honestly haven't done a head to head so idk) and they're having an easier time modernizing it with support for things like large folios. Seems like a good deal to me.
Personally: I used NTFS3 and it was alright. If anything the biggest thing I got hit by was an issue where the udisks2 mount call from Dolphin would result in NTFS-3g specific flags getting sent to it, causing the mount to fail. But in actual usage it actually worked just fine for me.
Current default for Arch is 7.0.10
Looking forward to 7.1 rolling out soon.
Fedora is in a few months I think. currently on 7.0.12
My favroite kernel version is 6.1.34. Traditional framebuffers for the win!
> Linux 7.1 is also notable for its code removals. Driven by AI-assisted bug reporting, ISDN and other old network driver code was removed to avoid that influx of bug reporting against those very rarely touched or used drivers for obsolete hardware.
Moving really old and unused code out of the kernel just to get less AI-assisted bug reports is IMO one of the best consequence ever of AI.
I love it.
We should start trimming the fat out of everything.
How about we stop adding the fat in the first place. cough. electron. cough.
Presumably that old code was actually useful at the time it was added. It might not be used now, but it helped someone back then. One of the great things about early Linux was that it tried to run on every piece of hardware available. If Linus only wrote drivers (or allowed others to submit drivers) that worked on his personal computer, Linux would have never flourished this far.
> Moving really old and unused code out of the kernel just to get less AI-assisted bug reports
Obviously, the parent is /s, but when I read this, I thought Linux was removing exploit paths that exercise rarely-used features.
On phone OSes at least, quirky rare formats and features are (were?) a common source of exploitable bugs.
Is the parent really being sarcastic? I read it as genuine.
There’s presumably plenty of code bloat in the kernel, and while no human would ever scan for bugs in a corner of the kernel that hasn’t been used or touched in decades, AI 100% will. And while those bug reports might be useless as bug reports, they seem promising as “why is this code even here?” flags.
I don't mean to be harsh, but if there's a codepath that is exercised on your hardware, but not on mine, I don't think it would be fair for me to deem it as "bloat". There are a TON of supported devices and use cases that are not my own, but are essential to someone else.
If you are still using ISDN you could maintain a fork.
This is one of the main examples of drivers that were removed.
Sure, sure. I’m not arguing for removing drivers for uncommon devices, or even rare devices. But there’s a line somewhere. Maybe it’s at “devices that no longer exist.” But I think it’s somewhere before that. And I have no idea how you’d figure out which devices fall where around this hypothetical line. I can only hope that they had good justification for these removals.
Maybe that points to an architecture issue? Is kernel driver support general enough to support all hardware in theory? If so it should be on hardware to provide a compatible api IMO. Note: I really have no experience in any of this there is probably more important things to consider like security/control or something.
Exploit paths in unloaded modules, I guess.
Code is liability. AI just made it harder to ignore.
>We should start trimming the fat out of everything.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry
One of my buddies was infamous for a while for being the "I deleted X lines of code today" guy.
>"Perfection is achieved..."
I, too, am a fan of RFC 1925.
I remember working with a guy who apparently deleted more code than he added in his time at the company. I think it said more about the codebase than anything but it was good that someone was trying to make it better.
Funnily, I have been that guy at the last 3 places I've worked at. Every place has some amount of cruft code, and I love sniffing it out and deleting it.
Chesterton's Fence...
It's ok, you can let go of Chesterton's ISDN phone pole now. Come, we have cable, we have fiber. Just for you, I'll even fire up a little hotspot from the palm of my hand as we walk away.
Chesterton's Fence only says to learn why the fence was erected, it gives no other guidance on what to do after that. There isn't too much mystery in why a device driver was made, so Chesterton's Fence yields next to nothing here.
This is the sort of thinking that had organizations buying all new desktops because the perfectly working ones they had won't run Windows 11.
I have 10 year old servers I'm still using because they run fine with linux.
That's good for your personal computing, but a renewing forest fire is good for all sorts of organizations. And species. It's a very good algorithm to run.
It's naturally de-ossifying and forces uptake of new methods and practices.
It gives you an opportunity to question assumptions and do things greenfield again.
The old unmaintained ISDN hardware for which the code has been removed is likely 20 years old, or so. The perfectly good laptops are usually 3-4 times younger.
FreeBSD and NetBSD aren't going anywhere and can be used for older hardware, for the amount of production and load bearing use Linux sees there's an enormous amount of cruft and garbage in it.
> very rarely touched or used drivers for obsolete hardware
I guess end users can not upgrade but a definition of obsolete would be nice.
To me, every HP printer ever is obsolete. But I assume someone else has an equally valid and different opinion. How does that go with computer hardware?
I’ve tried to submit code that removed old drivers from the kernel build in some distros, and they were universally rejected.
Everyone is afraid of breaking users until Torvalds says it’s ok.
Is there anything particularly interesting about this? The first number of the version changes when the second number gets too big, not for any other reason.
If you have an ad blocker, https://www.phoronix.com/review/linux-71-features-changes is a nice summary.
Yeah, my favorite $6 Linux machine is now supported (somewhat). :)
What SoC?
AI says probably Rockchip RV1103B which is Luckfox Pico Mini
AI is right. All hail AI. :D
LWN merge window part 1 https://lwn.net/Articles/1067250/ Part 2 https://lwn.net/Articles/1067785/
Did anyone see an anime avatar flash by for a fraction of a second before the content loaded? What was that?
That’s Anubis. [0]
[0]: https://anubis.techaro.lol
Anubis bot protection: https://anubis.techaro.lol
Anubis: https://github.com/TecharoHQ/anubis
blog post (pretty sure I've seen it on HN before) on the topic:
https://lock.cmpxchg8b.com/anubis.html
But not a very accurate blogpost. "Here's why this literally cannot work (in theory)" to denigrate a system that actually works (in practice). Their goal is to convince people to stop using it because it personally inconveniences them, but they never provide an alternative solution that actually solves the problem (in practice) that Anubis actually solves (in practice). If leaving the problem unsolved (in practice) was a desirable option, the site owner would not have turned to Anubis in the first place.
I'm totally out of the loop here, where's the evidence that this works in practice?
before and after apache logs showing much less crap in them from bots. Do you think the maintainers of https://lore.kernel.org/ would leave something in that didn't work? It isn't perfect but I have run it on a (much smaller) web site getting hammered by bots and logged "before" and "after" and the difference is measurable.
Its literally trivially objectively measurable, this isn't something that is based in opinion.
You can throw it up on your own website and simply grep the logs if you don't trust it, or look for the analysis reports from people who have done exactly that.
Like the other commenter said, why would linux.org deploy and leave deployed a technology that did nothing? Do they just enjoy trolling users? I doubt it.
uBlock Origin filter to block the anime girl from loading:
(c) https://news.ycombinator.com/item?id=46310941
Aw, but what have you against kawaii?
For me, it's a personal preference and in my opinion, it's less professional.
People always seem surprised when someone in CS or SWE doesn't care for anime or cutesy pictorial graphics of girls.
It's mostly surprising how many grown adult men go into a blind rage when confronted with a picture of a cartoon woman. In a lobsters thread about Anubis, a community member of 12 years got themselves permanently banned because they were frothing at the mouth with accusations of pedophilia against the developer and refused to apologise when given an opportunity by moderators. Telling on themselves, perhaps? It's funny, in a bizarre way, that this is a hill people will die on.
> ...they were frothing at the mouth with accusations of pedophilia against the developer...
I think I remember that thread. IIRC, it went something very, very roughly like this:
and the conversation degraded from there.
I'll also note that you chipped in with
> It's mostly surprising how many grown adult men go into a blind rage when confronted with a picture of a cartoon woman.
when -AFAICT- noone in this subthread expressed anything more heated than "dislike of kawaii". But perhaps you were speaking more generally, and weren't inspired by any conversation that happened in this subthread.
It also serves as a sort of "chud defense", in a way.
I like it.
If anything, its the opposite, going by the number of users with anime girl pfps on Twitter and other social media posting slurs and bigotry.
It's moreso only a loose indicator the user is between the ages of 14-30, if anything.
For some reason it's always underage girls.
How do you determine whether a drawing is "underage"?
Places that want to use Anubis but find the logo not professional enough are free to pay the author, IIRC it was major "professional support" benefit :D
If you don't want the anime girl pay for the support, otherwise you get the anime jackal. Seems like a fair deal to me.
everyone knows that penguins are much more professional
its the only weakness of the corpo-capitalist gestalt!
Breaking: Linus is on travel.
Did I miss something about this or is it just another number?
- "Anyway, possible slight hiccups in the merge window aside, the news today is 7.1." - "nothing particularly interesting or scary stands out, which is as it should be."
So, a number.
He's just writing about the changes since last week. Not about 7.1 as a whole. No last minute scary things means 7.1 released as planned.
But 7.1 new features can still be exciting.
Yeah, it gets boring when the number change doesn't change and try improving everything at once, but the great thing is that freshness improves driven by number fomo and that tightens the improvement loop.
Exciting and risky things are always under flags, so if you really care you just build, configure, and bench your own kernel+system.
Surprised nobody will spring for the inflight WiFi for Linus. Has to be some of the best return per dollar that could be spent!
Is it safe to assume we can see this in Debian Stable around 2036?
It’s fairly easy to build your own kernel packages from vanilla sources in Debian. I’m running the latest 7.0.x within a few hours of its release. The build takes about 30-45 minutes depending on how much time I spend on skimming the ChangeLog. YMMV.
I miss the days when my 486 took about 12 hours to compile a kernel
Or it took >15 minutes to generate PGP 2.x private keys due to entropy generation and prime calculations/tests.
what about your carbon footprint
I build using excess solar from my house. The build host is a small arm64 SBC that doesn’t require cooling in my passively cooled garage.
The resources behind your post likely have a larger carbon footprint.
Turn the shed light off overnight and you’re at net zero
> The build takes about 30-45 minutes
If you don't actually need all the drivers, you can use "make localmodconfig" to substantially reduce that. My local kernels build in 90 seconds on a 32-thread desktop machine :)
The kernel is a lot more stable than people think: I run the daily linux-next on my Debian stable gaming PC to look for bugs, and I don't find very many.
You're being a bit disingenuous, it builds in 90 seconds because you build it daily and the vast majority of objects are unchanged and cached by ccache.
No, I don't think that's what happening actually.
A stripped down cold build will literally take 90 seconds without caching on modern hardware.
The overwhelming majority of stuff that is being built is drivers, and most of them probably aren't needed for any specific user, so you can disable quite a lot of stuff.
Fwiw a full build of the fedora kernel config takes around 5-10m for my 12core ryzen 3900x, and it's definitely not the fastest CPU around.
No, 90 seconds is the clean build time without ccache.
try to build it with make clean first
I did that for a while because of compatibility issues with a newer laptop, it works but generally if there is no reason it's way easier to stay with the provided packages. Compiling weekly due to security patches becomes annoying over time for no real gain other than the version number
> It’s fairly easy to build your own kernel packages from vanilla sources in Debian.
IIRC, Debian has a command called "make-kpkg" which does nearly all the work for you, ending up with a installable package which works identically to the standard Debian kernel packages.
Wouldn't Forky/14 have this or newer when it releases next year? Debian moves slow - deliberately so, if you want fast use Arch or Fedora - but it does move.
Yes, best guess is forky will adopt the LTS kernel that will release at the end of this calendar year.
Not a serious question but I'll give a serious answer anyway.
The last time I worried over which kernel was used in Debian Stable was... never. If I want a more recent kernel I run Debian unstable (Sid) which currently is at 7.0.12 (the current 'stable' kernel where 7.1 is 'mainline') but on my servers Stable (currently 'Trixie') does just fine with its 6.17.3 kernel. Debian 'Forky' will be released somewhere in 2027 with either a 7.0.x or 7.1.x kernel depending on how things go. The current kernel used in 'testing' (which will become 'stable' on the next release) is 7.0.10.
People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
To do so, add the sources for trixie-backports and unstable, and add the following configuration (e.g. /etc/apt/preferences.d/trixie-sid-pin) so that the system knows which sources your prefer:
Now the system can access the latest kernel from unstable (and backports), while keeping everything else on stable:
I believe the kernel in backports gets updated only after it is live in unstable for at least a week, which lately still feels like forever.
> People don't usually understand that apt allows you to configure multiple sources across versions simultaneously, so you can e.g. run stable, but also selectively install from backports or unstable.
Which is just as well, because that's not generally a good idea unless you really know what you're doing:
https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...
Granted, the kernel is probably the best thing to do it with, on account of their aggressive stance on compatibility and the narrowness of impact (no .so files in play).
Backports are meant to work well along stable packages, but I agree it's definitely not a good idea to start pulling from sid from trixie (for regular packages, kernel is fine), this is asking for a ruined system.
Chaing priority wholesale is not needed just to install kernel image and might break other packages. Just install kernel image from backports after enabling backports.
> apt install linux-image-amd64/stable-backports
Somehow installing with `trixie-backports` isn't picking up latest kernel for me. Used what is being displayed in `apt search linux-image-7`
> The last time I worried over which kernel was used in Debian Stable was... never.
It was briefly a little annoying to deal with wireguard. But it was only a bit annoying, and then they updated. That's the only time I recall specifically caring.
Yes, when that was a thing I just compiled the wireguard module myself to feed it to the virtual router. It was only needed for a short interval and was thereafter handled by dkms, i.e. no problem.
The most recent Linux kernel releases are: 7.1, 7.0, 6.19, 6.18, …:
* https://en.wikipedia.org/wiki/Linux_kernel_version_history
7.0 is already present in forky (current testing), and available as a backport for trixie (current stable):
* https://packages.debian.org/search?keywords=linux-image-amd6...
* https://packages.debian.org/trixie-backports/linux-image-amd...
The default kernel for trixie/stable is 6.12, initially released in November 2024, and officially supported upstream until December 2028.
Just hope there’s never a Lillypad version
I know it's a bit of a meme but I'm on Debian Stable and I am running the backport kernel, which is on version 6.19. So only one minor version away from the current 7.0.
I wish more people would consider Debian for their devices. It is a very stable system, which I appreciate, and, unlike Ubuntu, it was really an "it just works" experience, without any of the friction points that smaller distros have. I installed Debian Trixie on a very recent device (granted, all AMD for compatibility) when Trixie was still the Testing version, and all the necessary drivers were present.
Now if only I could figure out how to build packages and contribute back to Debian... Also if only AMD could get their NPU support for Linux figured out...
I’ll never understand why people like Ubuntu. It’s a really hard toss up for me if I’d rather be stuck with Ubuntu or windows.
Probably because it got popular as the easy Linux distro back in the 2000s and that label is sticking.
I remember that I attempted to install Debian on my laptop in 2009. It was ugly. I installed Ubuntu 8.04 and it was a totally different and much nicer experience. Because of that I've been on Ubuntu until they started pushing snaps very aggressively. I live booted Debian 11 and realized that its UI was exactly the same. I don't know when it happened during that dozen of years but there wasn't anymore a reason to stick to Ubuntu. I installed Debian 11 and got a faster machine with less background processes. I'm on Debian 13 now. I've been told that KDE is much better than what I attempted to use in 2014 so maybe I could give it a try, but it's unclear to me what I have to gain.
I prefer KDE (on Ubuntu, because I tried it and it's good enough) - it's got more stuff built into the OS in terms of settings. I tended to find that Gnome needs you to install more things to expose configuration settings, whereas KDE's configuration UI is pretty good.
For me, it was kubuntu. Back in late 2005 or early 2006. The reason? They were always pretty good at shipping the latest KDE. I had grown tired of hoping someone would compile a new version for my preferred distro.
So kubuntu it was, and has been ever since. I'm currently looking into whether I should change to something else - as I've started growing tired of Ubuntu/Kubuntu after some 20 odd years.
I'm of the belief that the more popular an OS is, the more maintainers it will have (and thus less bugs). The only thing about Ubuntu that I hated was its choice of windowing manager. That's why there are so many variants like KUbuntu, XUbuntu, etc. Are there other reasons to not like Ubuntu other than the windowing manager?
> Are there other reasons to not like Ubuntu other than the windowing manager?
Snap applications are still not “equal enough” to installed apps.
They have gotten better, but it’s not seamless and when you get burned it’s 2 hours debugging. Each time.
An app I use/help maintain regularly gets bug reports about sandboxed behavior. It’s understandable but the easiest fix is to install an unsandboxed version.
I personally have some extra steps in my workflow for printing from a snap application because it doesn’t just work and I don’t want to spend the hours needed to debug it.
Come on - at least make one substantive criticism in your post putting down Ubuntu.
I came to Ubuntu because Wine worked on it with no effort. Yes, this was a long time ago. I have certainly cursed some of their changes since then, but I don’t want to spend my time doing yet another sysadmin job, so the less I change the better.
Well, it starts with when I have to opt out of location services during install, and Ubuntu reserving usernames (admin, for example) and ends with how aggressively they shut down upstream repos… if they’re not being DDoSd. Package conflicts are miserable, so they tried to paper over it, adding yet another bullshit layer of things to debug when something invariably breaks.
I’d rather flip the question back on you, how is Ubuntu better than, say, Rocky? If you say “upgrading is easier” I’ll chuckle for the rest of the day.
Ubuntu offered a slightly prettier installation experience.
Sure, no matter which distro you were installing you still had to provide a hostname, a domain name, some IP info (maybe), and an opinion on partitioning - there's only so many ways to ask the user these questions - but the ubuntu installer was prettier.
Around the time it was gaining popularity, almost every 'reviewer' (blogger) seemed to waste about 85% of their distro reviews talking about the installer - as though this was somehow important. The big sell of Debian, and Debian-derivatives, is that you install once, and then it's just in-place upgrades forever. The distro-hoppers, Microsoft evacuees, content-creators, etc - didn't really get that.
Anyway, once Ubuntu was installed it was much the same to operate as a Debian box. Obviously there were some surprising differences. Unity. Mir. One Cloud. Wubi. Upstart. Bazaar.
Check out FastFlowLM for AMD NPU support.
Debian unstable/testing? Is quite good too. As well as OpenSUSE.
> (granted, all AMD for compatibility)
I get that you mean that AMD is more compatible than... what? Intel? Arm?
Nvidia, I think? That's what people say but has never been my experience.
what doesn't just work in Ubuntu, compared with Debian?
Actually, I'm running the backports kernel which is at 7.0 today.
If you run stable, Debian backports takes care of a lot of the popular stuff. Kernels, kernel modules, Rust/Cargo, CMake, Clangd, GPU firmware (AMD/Intel), GDB, LibreOffice, OpenShot video editor, and Wireguard are all kept current in backports. And there's way more than I mention here, of course. Worst case I can install unstable in a schroot and run some bleeding-egde software.
I did all of my distro hopping when I was young, 20+ years ago. I settled on Debian because life got busy and I had no time to fuss with broken software updates.
The full list of what's available in trixie-backports, if anyone is curious: https://backports.debian.org/uploads/trixie-backports/
doesn't debian usually stick to LTS kernels? afaik 7.0 was designated as an LTS release so it'll probably be the version that next major release will ship with (next year maybe?)
They ship every other (boreal!) summer, so more like this time next year.
From 6 to 7
what a legend!
how many new code came from AI ？
3
yeah about 3 to 5 codes /s