I guess Gentoo Hardened meant the difficulty level in this case.
Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
31–40 of 50 posts
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#32Earlier quoted context omitted.
'a weaker developer' is the opposite of the standard definition of 'a 10x developer'. if you are going to use phrases to mean the opposite of their conventional meaning you should warn people so they can avoid arguing with you on the assumption that you're using them to mean what everyone else uses them to mean
Why should I do that? An "argument" about nothing is hilarious.
> Why should I do that?
Because what you chose to do instead is exceptionally obnoxious behavior, which degrades the quality of discourse on this site.
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#33This is honestly wild. 99% of devs would have found a work around and moved on. Going so far as to create a multi-kernel test bench to narrow down the source of the instability is a level of dedication I have not personally seen, and I respect it.
By the same token, you might be the first person I have ever seen give respect to the 1x developer. I respect that. We could no doubt all learn a thing or two from the 1x developer that doesn't rush through everything with quick solutions.
I believe the 10x developer thing is stupid, and based on perspective. Watching someone work faster than you doesn't mean they are doing better work, and on the other hand could mean perhaps you are maybe a 1/10th developer.
That said, if a 10x developer does exist, Marcan is one of the few of them. What a ridiculous statement.
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#34(2017) Previous discussion: https://news.ycombinator.com/item?id=15845118
Ah, I remember 2017’s HN where the mere word “Go” in the title made posts skyrocket to 498 points. In 2024 the title should’ve contained “Rust” for the same outcome. Quite curious what will be required in 2031.
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#35I'm pretty confident in my computer abilities, but when I read stuff like this I feel like I have no skills at all compared to this guy. Like I'm still a high school athlete and he's an Olympian (also he was only 26 when he wrote the article).
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#36I feel like I still didnt fully understand what's going on here. Is the following correct? "Threads hava a 'canonical' stack that the OS auto-grows for you as you use more of it. But you can also create your own stack by putting any value you want in RSP. This is what the Go program did, and the vDSO, assuming it ran on an auto-growing stack, tried to probe it, which lead to corruption."
The problem is that the vDSO (which is compiled as part of the kernel but runs in userspace) does a stack probe for security reasons, trying to see if it will overrun the stack. It does this by checking if at least a page’s worth of data is accessible. If not, it will (typically) fault. However, Go programs use a stack size so small that they may have other data a page away, which means the problem may mess with that data and cause bad things to happen.
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#37> Over the course of 22 kernel builds, I managed to simplify the config so much that the kernel had no networking support, no filesystems, no block device core, and didn’t even support PCI (still works fine on a VM though!).
Flashbacks to a job where I was asked to figure out why a newer kernel was crashing. This was a very frustrating time, because I had (have) basically zero real C/C++ experience but I'd helped out with Bitbake recipes and everyone else was busy or moved to other projects.
To cut a multiweek tale of dozens of recompilations short: The kernel was fine. The headless custom hardware was fine. The problem was a hypervisor misconfiguration, overwriting part of the kernel address space. All of our kernels have been corrupt, but this was the first one where the layout meant it mattered.
A month of frustration, two characters to fix, the highest ratio I've encountered so far.
My reward for struggling through a complex problem I was unqualified for? "Great, now we need to backport security patches from the main Linux kernel to the SoC vendor's custom fork..."
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#38Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#39Earlier quoted context omitted.
> means that a 1x developer will take around 10 hours to get to the same place A "workaround" isn't an adequate substitute for actual the understanding and fixing of the root cause of a bug. What you think is a 10x developer is, in fact, a short-term 10x developer, medium-term 1x developer, long-term -10x developer. Their work while seemingly great at first is just accrued debt with an incredibly high interest rate.…
> A "workaround" isn't an adequate substitute for actual the understanding and fixing of the root cause of a bug. Right, hence why we recognize that a 10x developer is a weaker developer. Was there something that implied that a weak developer is a substitute for a talented developer for you to say this, or are you just pulling words out of thin air?
Are you working on a diploma in douchebaggery? Good news, you're succeding.
Re: Debugging an evil Go runtime bug: From heat guns to kernel compiler flags (2017)
#40Earlier quoted context omitted.
'a weaker developer' is the opposite of the standard definition of 'a 10x developer'. if you are going to use phrases to mean the opposite of their conventional meaning you should warn people so they can avoid arguing with you on the assumption that you're using them to mean what everyone else uses them to mean
Why should I do that? An "argument" about nothing is hilarious.
This comment reminds me of my 10 years old sister. She finds pointless arguments hilarious too.