3 ms·

Every single thing on your list (except the info manager and maybe more obscure web browsers) has tens of thousands into the hundreds of millions of users. Exc

Every single thing on your list (except the info manager and maybe more obscure web browsers) has tens of thousands into the hundreds of millions of users. Except for the web browsers, none of the things you listed are the result of or otherwise benefited from meaningful forks. You will never understand, much less be able to make meaningful edits in afternoon to, the entire Linux kernel. Likely much the same for Perl and PGP (150K lines of C and a highly specialized domain respectively). You don't have the tools to edit IntelliJ or Word 97 (was that what that bullet point was about?) Lord help you if you're updating any of those things. I better not see anything higher than 2.X in your uname -a. You overwhelmingly don't follow this post's advice

iinnPP 3y ago
"You don't have to do all this. Their benefits are additive, but acting on even one of these suggestions is better than nothing."
- nickelpro 3y ago
  forgotmypw17 doesn't appear to follow any of these points except incidentally (most modern web browsers are forks of one another for complexity reasons, their preferred document editor is an EOL closed-source product therefore doesn't get updates)
  - forgotmypw17 3y ago
    If you look closely, each of them has a place in my regimen.
II2II 3y ago
It is probably best to say the author's advice is not practical and, for most people, not desirable. It is also worth adding the solution is problematic in the sense that being able to understand software from top to bottom is a skill set that few developers even have, even for the most trivial of applications. Most developers build their software on the shoulders of others. That said, the author's point about the trustworthiness of software is valid. In most cases software is more complex than individual users need it to be (and it is like that to serve a wider audience since software development is expensive). The complexity makes the software more vulnerable while making it easy to hide malicious intent.
- nickelpro 3y ago
  I agree with your first paragraph entirely and it's worded more generously than mine. I think there's something valid in your second, but on the whole simplicity is often a myth. Hardware is complex, the world is complex, the software stack simply reflects these complexities, it does not invent them. It feels great to have simple code until your environment no longer mirrors that code's assumptions. You have an MBR bootloader that assumes the A20 line is on the keyboard controller, upgrade hardware, and suddenly you can't boot anymore, bet you wish you had a more complex bootloader now. You have a graphics renderer that knows no one has more than 4GB of VRAM so it measures allocatable memory by allocating up to 4GB of textures until it gets E_OUT_OF_MEM. Except on modern cards it overflows its texture counter, bet you wish you had a more complex renderer. And this is ignoring inherent complexity, or the nature of handling errors even without changing hardware, but I've ranted enough on this. There is a narrowly valid point here but it is presented without caveat and thus far too broadly.

iinnPP 3y ago

"You don't have to do all this. Their benefits are additive, but acting on even one of these suggestions is better than nothing."

nickelpro 3y ago
forgotmypw17 doesn't appear to follow any of these points except incidentally (most modern web browsers are forks of one another for complexity reasons, their preferred document editor is an EOL closed-source product therefore doesn't get updates)
- forgotmypw17 3y ago
  If you look closely, each of them has a place in my regimen.

II2II 3y ago

It is probably best to say the author's advice is not practical and, for most people, not desirable. It is also worth adding the solution is problematic in the sense that being able to understand software from top to bottom is a skill set that few developers even have, even for the most trivial of applications. Most developers build their software on the shoulders of others. That said, the author's point about the trustworthiness of software is valid. In most cases software is more complex than individual users need it to be (and it is like that to serve a wider audience since software development is expensive). The complexity makes the software more vulnerable while making it easy to hide malicious intent.

nickelpro 3y ago
I agree with your first paragraph entirely and it's worded more generously than mine. I think there's something valid in your second, but on the whole simplicity is often a myth. Hardware is complex, the world is complex, the software stack simply reflects these complexities, it does not invent them. It feels great to have simple code until your environment no longer mirrors that code's assumptions. You have an MBR bootloader that assumes the A20 line is on the keyboard controller, upgrade hardware, and suddenly you can't boot anymore, bet you wish you had a more complex bootloader now. You have a graphics renderer that knows no one has more than 4GB of VRAM so it measures allocatable memory by allocating up to 4GB of textures until it gets E_OUT_OF_MEM. Except on modern cards it overflows its texture counter, bet you wish you had a more complex renderer. And this is ignoring inherent complexity, or the nature of handling errors even without changing hardware, but I've ranted enough on this. There is a narrowly valid point here but it is presented without caveat and thus far too broadly.