Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncovering a 24-year-old bug in the Linux Kernel (2021)

engineering.skroutz.gr

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#61

Post by c0mptonFP »

freedomben wrote: post #40
c0mptonFP wrote: post #5

Earlier quoted context omitted.

> We need more people and companies like this, who are willing to go beyond "oh it fails randomly sometimes" and track down the underlying issues. I absolutely disagree. Most capable engineers I know have this urge to go down rabbit holes and fix any issue, this is nothing special. Everyone wants to be the hero that found a bug deep in the stack, make a glorious pull request, and be celebrated in the community. I muc…

This opinion is a popular one these days (particularly since it complements the demands of business nicely by maximizing personal/company profit), but it is a big part of the reason why the majority of software these days is so unreliable and buggy. It results in hacks on top of hacks to paper over problems in the lower levels of the abstraction tower that is modern software, and it results in tons of "WTF" bugs that…

It's popular because these war stories you find in blog posts are pure survivorship bias.

If I'd let every fucking team member go on an exploratory bug hunt whenever they feel like it (hint: that would be always) we would never get anything done.

What if they don't find anything? Is this issue really worth 2 weeks of dev time? That's 15k down the drain for a senior engineer, if not more.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#62

Post by StayTrue »

rrdharan wrote: post #20
halukakin wrote: post #11

Could someone provide link(s) on how regular snapshots of databases can be taken like this? (Googling didn't help much, maybe I'm googling for the wrong keywords.) For me, backing up the database is a few-hour-long process. Restoring it for a developer again is a few hours process. I read about snapshots before but haven't realized they could be this effective.

It’s the lack of clarity on how they manage access control for what should be regulated data that surprises me, more than the technology achievement.

Article says data is anonymized before dev use. Pretty standard practice.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#63

Post by Taniwha »

It's worth remembering that before Linux (and to some extent Unix) we only had proprietary operating systems from hardware companies - who probably wouldn't have had the resources to find and fix a bug like this, and often customers wouldn't have had access to source to fix it themselves

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#64

Post by MatthiasPortzel »

c0mptonFP wrote: post #61
freedomben wrote: post #40

Earlier quoted context omitted.

This opinion is a popular one these days (particularly since it complements the demands of business nicely by maximizing personal/company profit), but it is a big part of the reason why the majority of software these days is so unreliable and buggy. It results in hacks on top of hacks to paper over problems in the lower levels of the abstraction tower that is modern software, and it results in tons of "WTF" bugs that…

It's popular because these war stories you find in blog posts are pure survivorship bias. If I'd let every fucking team member go on an exploratory bug hunt whenever they feel like it (hint: that would be always) we would never get anything done. What if they don't find anything? Is this issue really worth 2 weeks of dev time? That's 15k down the drain for a senior engineer, if not more.

From a short-term business perspective, sure, it doesn't make financial sense.

As a user of software, though, I want someone to fix the bug. I want software that doesn't have bugs. So let me repeat my original statement. We need more like this that are willing to spend engineer time fixing bugs, even upstream bugs in open source projects. Instead of prioritizing shoving half-baked features out the door for next week's press release.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#66

Post by nine_k »

themoonisachees wrote: post #56
perth wrote: post #50

Earlier quoted context omitted.

And even if you did reach out to customer support, it would rarely ever get dev attention unless most people have the issue. Even in that case, it sometimes still gets a fat wontfix, like the famous OneDrive file corruption bug.

Raising this bug in windows (how? Microsoft sells support, barely, but you can't talk to the ipv4 stack dev anyway) woul get you laughed out of the chat room because it can't posibly be the ip stack's fault.

IDK; I found bugs in Oracle database software in early 2000s, contacted the (corporate) tech support, and got the bugs confirmed, and fixed in subsequent releases.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#67

Post by nine_k »

xani_ wrote: post #59
justin_oaks wrote: post #44

I love when you're using open source software and can find the bug yourself, even if it's deep down the stack. Imagine if this bug were somewhere in closed source software. You'd have to reach out to the software's customer support team. Every time I reach out to customer support I expect to have an unpleasant experience. It is rarely otherwise.

Kinda why I'm not a fan of cloud, same black box problem.

OTOH if you find a bug, the cloud provider likely has more clout to demand a fix from the vendor, if the software us not open source. Possibly the bug affects the cloud provider's bottom line.

But if the bug is obscure and has little impact, bad luck!

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#68

Post by cryptonector »

Taniwha wrote: post #63

It's worth remembering that before Linux (and to some extent Unix) we only had proprietary operating systems from hardware companies - who probably wouldn't have had the resources to find and fix a bug like this, and often customers wouldn't have had access to source to fix it themselves

> It's worth remembering that before Linux (and to some extent Unix) we only had proprietary operating systems from hardware companies - who probably wouldn't have had the resources to find and fix a bug like this, and often customers wouldn't have had access to source to fix it themselves

UC Berkeley was a hardware company? TIL.

Companies like Sun had thousands of engineers working on their operating systems, and they very much could and did find and fix obscure bugs, both on their own as well as based on customer bug reports. Some customers did have access to source code -- I know because I've seen that myself. And customers that didn't have access to source code could still do clever things to diagnose problems. In this case, for example, a packet trace should be enough to diagnose the nature of the bug, though one would indeed need source code to write a fix.

Of course it's much better for customers facing obscure bugs to have access to the source code.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#69

Post by c0mptonFP »

MatthiasPortzel wrote: post #64
c0mptonFP wrote: post #61

Earlier quoted context omitted.

It's popular because these war stories you find in blog posts are pure survivorship bias. If I'd let every fucking team member go on an exploratory bug hunt whenever they feel like it (hint: that would be always) we would never get anything done. What if they don't find anything? Is this issue really worth 2 weeks of dev time? That's 15k down the drain for a senior engineer, if not more.

From a short-term business perspective, sure, it doesn't make financial sense. As a user of software, though, I want someone to fix the bug. I want software that doesn't have bugs. So let me repeat my original statement. We need more like this that are willing to spend engineer time fixing bugs, even upstream bugs in open source projects. Instead of prioritizing shoving half-baked features out the door for next week'…

I wish, brother. I wish it was more like that...

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#70

Post by xwolfi »

xani_ wrote: post #58
didgetmaster wrote: post #6

As someone who thrives on tracking down rare but annoying bugs in a debugger, I love stories like this. It is not just bugs that cause real failures which can be headaches; but also bugs that just slow things down unexpectantly. They can sometimes go undetected for decades like this one. I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in…

> As someone who thrives on tracking down rare but annoying bugs in a debugger, As someone that is cursed to inevitably find some obscure bug the second I start using some piece of software I'm happy I'm not the only one > I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in terms of wasted time and energy "Using JS for backend is ecoterror…

Even for frontend, repurposing on the frontend stuff that were done in the past on the backend can be ecoterrorism squared.

For instance, a small team of 40 people found no issue sending 4MB of json english to chinese string localisation to each website visitor for angular to translate. 1 million visitor a month in Hong Kong alone, 4 million MB + a few second of mapping per user per month completely pointless...

Post reply on HN