Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.
It will be gamed, just as pagerank was.
Significant raise of reports
41–50 of 164 posts
Re: Significant raise of reports
#42The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…
It was the best of times, it was the worst of times. Best/better because yes, QA actually existed and was important for many companies - QA could "stop ship" before the final master was pressed if they found something (hehe as it was usually games) "game breaking". If you search around on folklore or other historical sites you can find examples of this - and programmers working all night with the shipping manager hov…
This was the big thing. There were tons of bugs. Not really bugs but vulnerabilities. Nothing a normal user doing normal things would encounter, but subtle ways the program could be broken. But it didn't matter nearly as much, because every computer was an island, and most people didn't try to break their own computer. If something caused a crash, you just learned "don't do that."
Even so, we did have viruses that were spread by sharing floppy disks.
Re: Significant raise of reports
#43The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…
Before 2000 fixing a bug the user would notice was expensive - you had to mail them a new disk/cd. As such there was a lot more effort put into testing software to ensure there were no bugs users would notice.
However before 2000 (really 1995) the internet was not a thing for most people. There were a few viruses around, but they had it really hard to propagate (they still managed, but compared to today it was much harder). Nobody worried about someone entering something too long in various fields - it did happen, but if you made your buffers "large" (say 100 bytes) most forms didn't have to worry about checking for overflow because nobody would type that much anyway. Note the assumption that a human was typing things on a keyboard into fields to create the buffer overflow. Thus a large portion of modern attacks weren't an issue - we are much better at checking buffer sizes now than there - they knew back then they should, but often got away with being lazy and not doing it. If a vulnerability exists but is never exploited do you care - thus is today better is debatable.
In the 1990s the US had encryption export laws, if you wanted to protect data often it was impossible. Modern AES didn't even exist until 2001, instead we had DES (when you cared triple DES which was pretty good even by today's standards) - but you were not allowed to use it in a lot of places. I remember the company I worked for at the time developed their own encryption algorithm for export, with the marketing(!) saying something like "We think it is good, but it hasn't been examined near as well as DES so you should only use it if you legally you can't use DES"
As an end user though, software was generally better. They rarely had bugs anyone would notice. This came at the expense of a lot more testing, and features took longer to develop. Even back then it was a known trade off, and some software was known to be better than others because of the effort the company put into making it work before release. High risk software (medical) is still developed with a lot of extra testing and effort today.
As for the second part - software back then was plenty complex. Sure today things are more complex, but I don't think that is the issue. In fact in some ways things were more complex because extra effort was put into optimization (200mhz CPUs were the top end expensive servers, most people only had around 90mhz, and more than one core was something only nerds knew was possible and most of them didn't have it). As such a lot of effort was put into complex algorithms that were faster at the expensive of being hard to maintain. Today we have better optimize rs and faster CPUs so we don't write as much complex code trying to get performance.
Re: Significant raise of reports
#44Re: Significant raise of reports
#45The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…
Programs didn’t auto save and regularly crashed. It was extremely common to hear someone talk about losing hours of work. Computers regularly blue screened at random. Device drivers weren’t isolated from the kernel so you could easily buy a dongle or something that single-handedly destabilized your system. Viruses regularly brought the white-collar economy to its knees. Computer games that were just starting to come online and be collaborative didn’t do any validation of what the client sent it (this is true sometimes now, but it was the rule back then).
Re: Significant raise of reports
#46Re: Significant raise of reports
#47Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.
It will be gamed, just as pagerank was.
Re: Significant raise of reports
#48> I don't know how long this pace will last. I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog Hopefully these same tools will also help catch security bugs at the point they're written. Maybe one day we'll reach a point where the discovery of new, live vulnerabilities is extremely rare?
Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
Re: Significant raise of reports
#49The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…
Re: Significant raise of reports
#50Earlier quoted context omitted.
It was the best of times, it was the worst of times. Best/better because yes, QA actually existed and was important for many companies - QA could "stop ship" before the final master was pressed if they found something (hehe as it was usually games) "game breaking". If you search around on folklore or other historical sites you can find examples of this - and programmers working all night with the shipping manager hov…
"everything was local" This was the big thing. There were tons of bugs. Not really bugs but vulnerabilities. Nothing a normal user doing normal things would encounter, but subtle ways the program could be broken. But it didn't matter nearly as much, because every computer was an island, and most people didn't try to break their own computer. If something caused a crash, you just learned "don't do that." Even so, we d…
Nowadays those bugs still exist but a vast majority of bugs are security issues - things you have to fix because others will exploit them if you don't.