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.
Uncovering a 24-year-old bug in the Linux Kernel (2021)
11–20 of 84 posts
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#12I remember when this was originally posted, but I voted it up again because I think it's such an excellent story, and excellent programming. 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. => https://news.ycombinator.com/item?id=26102241 Previous Discussion (497 points - 41 comments)
> 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…
I think this was well prioritized; they struggled with the issue at times, found a temporary workaround, but when that workaround stöd being efficient and the bug hit them everyday, they decided to track down the source. Then they reported upstream, it was reproduced, and someone patched it, and rolled out new, fixed kernels.
That is a perfect example of how things works and should work. They contributed to the community. I think it was a great prioritization.
I'm certain there were lots of other people hitting this bug and killing processes or rebooting to get around it. The troubleshooting and reporting done here, silently saved a lot of of other people a lot of efforts - now and in the future. I don't think they were after it to be heroes; they just shared their story, which I'm sure will encourage others to maybe do the same one day.
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#13I remember when this was originally posted, but I voted it up again because I think it's such an excellent story, and excellent programming. 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. => https://news.ycombinator.com/item?id=26102241 Previous Discussion (497 points - 41 comments)
> 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…
[deleted]
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#14Could 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.
can't most COW dilesystems like BTRFS or ZFS take a snapshot at a point in time instantly?
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#15I remember when this was originally posted, but I voted it up again because I think it's such an excellent story, and excellent programming. 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. => https://news.ycombinator.com/item?id=26102241 Previous Discussion (497 points - 41 comments)
> 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…
At the company level, it is indeed more expensive to fix upstream rather thank work around it, but on a macro scale it is much more beneficial.
In my opinion fixing upstream whenever possible even if not the best short-term solution should be considered the price to pay for using OSS.
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#16I remember when this was originally posted, but I voted it up again because I think it's such an excellent story, and excellent programming. 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. => https://news.ycombinator.com/item?id=26102241 Previous Discussion (497 points - 41 comments)
> 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 _is_ the meaningful stuff. Engineers might have the urge, but most don’t have the opportunity, because they need to focus on the currently fashionable framework.
A good rule of thumb regarding meaningful battles is to ignore everything promoted by companies like Google or Facebook - everything they do is either going to be abandoned in five years, or makes sense only in the context of solving problems nobody else have.
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#17how odd to see a write up from skroutz.gr blog being at the first page of HN...
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#18I remember when this was originally posted, but I voted it up again because I think it's such an excellent story, and excellent programming. 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. => https://news.ycombinator.com/item?id=26102241 Previous Discussion (497 points - 41 comments)
> 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…
No post body was provided.
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#19Could 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.
can't most COW dilesystems like BTRFS or ZFS take a snapshot at a point in time instantly?
LVM does the same but at the block level.
https://wiki.archlinux.org/title/Create_root_filesystem_snap...
Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)
#20Could 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.