I still don't understand why people bash Nvidia because of the binary drivers they provide. In spite of Linux being low on the desktop count, Nvidia is nice enought to provide current drivers for all of their latest cards. They were quick to support the 2.6 kernel. If the driver works and works well why does it matter whether it's open or not?
Oh, little things, like the reassurance of being able to continue to use the hardware I've paid for even if nVidia don't feel like continuing to develop the drivers if-and-when the kernel API changes - like with the recent 4k stacks issue. That, and Free drivers are more stable that proprietary drivers in my experience, and when they aren't, you can look at the code to try to figure out why, rather than crossing your fingers and waiting for a driver update that may never come.
Ditto for the free DVD players (e.g. VLC), even when they're running on Windows. My laptop has an RPC-2 UJDA-720 DVD-Rom/CD-RW combo drive. I've successfully played a foreign region DVD using VLC under Windows XP with no drive-region changing, or Windows hacks.
Either you haven't worked with people who tech computers (especially home computers), or you are going out of your way to miss the point.
No, I got the point alright - and that's why I said that for non-tech-savvy users, they're probably better off buying a whole new machine (complete with 2-3 year warranty too!) than paying a technician (who may well be utterly incompetent - as you point out) to try to fix their existing machine. This was why I've never gotten into doing "PC Doctor" work as a sideline; I'd either have to be unethical, unprofessional, or deal with stupid-but-rich customers. No thanks.
For geeks, or for folks who can borrow a geek in exchange for food/beer/pizza/sexual favours, of course, it's a different matter.
I'm agreeing with you, but you don't seem to have realised it...
The sure-fire option is to buy a new computer, and with today's wonderful credit, it's not hard for "Joe Sixpack" who blew tons of cash on an over-priced computer in the first place.
And I hate to be so blunt, with with the very wide range of proficiency in techs that work with the average home user's computer, that $60-$80/hr may be harder to justify than a whole new $800-$1000 computer.
In the UK, right now, it's possible to buy a Celeron 2.4GHz, 256M, 80G HDD, Intel-on-Intel motherboard, DVD-Rom/CD-writer combo machine with 17" CRT for about 300-400GBP. A (decent) plumber earns about 60GBP an hour - I don't see why a decent computer technician should charge a lower rate than that. Now think of how much onsite remedial work that technician can do for 400/60=6hrs 40m - you'd be lucky to do a single data backup/OS+Application reinstall/patch/restore cycle in that amount of time if you're working onsite at the customer's premises or home (as opposed to working on several machines in parallel in a workshop). For rational customers, buying a new machine is probably the best thing to do with their money, especially when they don't have the technical savvy to tell the difference between broken/worn-out hardware and a misconfigured/hacked/infected/corrupted OS install.
Immunix for one. Alternatively, taking a slightly different path towards pro-active security measures, Red Hat has recently included exec-shield (as seen previously in Fedora Core 1 onwards) in RHEL3 update 3. FC2 includes SELinux, so that'll probably turn up in RHEL eventually, too.
Actually, with debian, dpkg does that for you. It basically says:
"I found these programs running that might have a problem if they're not restarted. Can I restart them? [Y/n]"
That's new to me, and pretty neat, actually - karma points for Debian. I wonder, though, whether it's actually dpkg that does that, or some well-packaged libraries (which, IMHO, is where Debian's true value lies).
Methinks somebody is doing a thorough code review of open source image libraries, the stolen NT code (remember the Windows BMP vuln?), and, where source can't be obtained, thinking about where it might be vulnerable.
I wouldn't be surprised if people are just testing the proof-of-concept demonstration files intended to break other image decoding code and finding that it breaks their code too, maybe in a slightly different way. It's not uncommon for separate programmers to make the same thinkos even if they've never seen each other's code (and especially if the original data spec is unclear, undefined or ambiguous on a given point).
The scary thing is that the sorts of problem we're seeing here apply to any "active" data format - i.e. one where the file isn't simply read and taken as-is (e.g. a plain text file), but is actually made up of "commands" which are interpreted as the file is used. We've seen similar problems with PostScript, PDF, MP3, wmv and probably more besides. The thing about this one is that short of HTML, JPEGs are probably the single most-commonly accessed type of active file - and from sources which may not be trustworthy too!
Intel-branded boards are dead easy to find in the UK (though generally only mail order - fairs and mom n' pop shops frequently only sell cheap junk, though this has changed over the last few years and you can find Abit, MSI, Asus and Gigabyte quite easily), so I'm surprised you're finding them difficult to find in North America.
Have you tried using price comparison sites together with the Intel model numbers? (e.g. D865PERLX). If you need other model numbers, try checking dabs.com or Intel's site first.
Personally, I'm pretty happy with Intel-based Asus and Gigabyte as they generally have more features for the same price as Intel's boards and have proven to be compatible and reliable for me. On the other hand, I can't help but notice that the quality vendors seem to use Intel-on-Intel boards in their top-of-the-line server hardware.
Patching applications does not require a reboot in Linux. Ever.
Strictly speaking, that's correct, but if you update a widely used library (e.g. glibc) then you'll still need to restart all the applications that use it in order that they use the updated version of the library, otherwise they'll still be using the unlinked-but-not-gone-until-closed version. By the time you've done that, rebooting might well be the quickest thing to do, especially if you have lots of network-reachable services that are vulnerable because they inherit some flaw from the library in question.
Blanche de Chambly (Unibroue), Guinness, and Strongbow cider.
I can't comment on the first two, but if you're going to drink something described as cider, at least drink a realcider or scrumpy. Strongbow is nasty chemical stuff - the equivalent of comparing UK-brewed Fosters XXXX with a good Belgian, German or Czech lager.
The last two should even be on sale in most UK supermarkets.
In the event that an individual pays for a specific service (such as the use of a JPEG processor) and the service is not rendered correctly (such as the JPEG processor executing arbitrary code on the machine in question), the individuals who originally promised to render the service should be held responsible and should repair this problem at their own expense. It works that way in other industries. Really.
I'm not aware of any distro vendor that keeps their errata secret (though Red Hat do "only" provide src.rpms for their RHEL errata). On the other hand, one of the things that used to annoy me when I was supporting users of expensive security software was that the patches would be inseparably combined remedial fixes mixed with new features. As a result, the manufacturers wouldn't let me give the patches to customers without a (expensive) current support contract, even if they had a support contract when they bought the flawed software. That's BS, IMNSHO.
If MS can be sued, then the programmers working on Linux distros should be vulnerable, too.
Call me biased, but I think that as FOSS code comes with source code (and thus a customer is able to independently determine for himself whether any given package is securely implemented), there is a case for making software that comes with source code exempt from any such litigation, and especially so if no money changes hands.
Of course, Microsoft and all the other vendors of proprietary software wouldn't like it that way.:-]
Finally, part of the value distro vendors provide is QA. Conceivably, they would still be liable if found to be negligent in their QA process.
you also need to measure total number of vulnerabilities
The study I referred to measures total number of days of recess over all each OS for the year of 1999. That's where I got my ratios of 1:2:3 for Linux:Windows:Solaris. Go read the link, and you'll see what I mean.
and impact of each vulnerability (that is, num of setups a vuln actually affects, plus total num of vulns - if it takes them 1 hour to patch a vuln, but they get 24 vuln's a day, but it takes someone else 4 hours to patch, but only get one vuln a day, which is better?).
I think we can probably say that the difficulty-to-exploit will be approximately equal between all remotely-exploitable vulnerabilities (regardless of platform or package, assuming similarly-configured defensive features), and likewise between all locally-exploitable vulnerabilites regardless of platform. So the only thing that would really matter is the ratio of locally-exploitable to remotely-exploitable vulnerabilities and the total number. Sun did better on the latter than both Red Hat and Microsoft but, Linux ships a greater range of software in the standard distro than both and did better than Microsoft.
As it happens, I think it's pretty hard to say which of Solaris or Red Hat Linux is more secure based on the numbers in this study (and it was the assertion that "Solaris is more secure than Linux" that I was refuting). But I think it's fair to say that whichever way you cut it, both are more secure than Windows, and have numbers to back that assertion up.
Second b/c you're only measuring what's known, but there are a sizeable number of vulnerabilities that are not known. Is it possible to measure this?
I'm happy to work on the basis that until someone knows about a vulnerability it doesn't exist. In effect, the period of recess in the study is the minimal period of recess (since it's safest to assume that some blackhat discovered each vulnerability and started exploiting it some time before it ended up up Bugtraq or even full-disclosure).
Third b/c you're not at all measuring an OS's ability to be secured, that is, what secure features come built-in to the OS versus what have to be compiled as an addon or what has to be coded from scratch or what exists as someone's untested code. But what features does the OS come with to provide ACL's, resource exhaustion protection, etc?
Apart from filesystem ACLs (which I think are over-complex bunk in the most common scenarios), I'd say that Windows is the poorest of the three for every category you've mentioned. Between Solaris and Red Hat Linux, it's harder to say - Sun have Trusted Solaris, whereas SELinux has only gone into FC2 and RHEL3 has recently gotten exec-shield, support for hardware No eXecute pages in Update 3 and is under evaluation for EAL3+/CAPP. Historically, Solaris has certainly provided more options for securing machines, but RHL is catching up fast and implementing things that Solaris probably won't have for quite some time.
Fourth, well i'm bored with this now, but don't forget hardware's impact on security.
No eXecute pages? In RHEL3u3 now if it's running pm an AMD64 or newer Pentium 4 CPU. If you're referring to something else, please elaborate. Remember that RHEL3 is available and supported on IBM S/390 and zSeries hardware as well as bog-standard x86.
Or, even better, use RH or Fedora and their printing system, which integrates foomatic as well as the gimp-print and Omni collections of printer drivers for ghostscript. My guide to buying a printer for Linux:
If you have the budget, buy a PostScript device,; you won't be disappointed.
If not PostScript, how about a PCL device?
If not a PCL device, check to see what's available for the price you're prepared to pay, then check linuxprinting.org or redhat-config-printer-gui for compatibility, buy and configure (it's never taken me longer than 5 minutes).
Does anyone else use the same printing setup as RH/Fedora? Mandrake?
Because, for the life of me, I couldn't find any adequate metric that defines security using an agreed, quantitative metric within the Information Security industry.
Oh wait, that's right, there is none.
I'd say that the time of recess between the general community being aware of a vulnerability and a workable patch being available is a pretty good measure. But, according to this article, In 1999, Red Hat's "at risk" time was half that of Sun's (presumably then-current versions of Solaris), and a third of Microsoft's (presumably Windows NT 4). And that's with all the stuff that's included in the RH distribution for which there aren't equivalents included in Windows or Solaris.
Of course, it would be interesting to get more up-to-date stats, or stats for distros that are touted by some as being more security-conscious (e.g. Debian, OpenBSD).
Binary diffs/deltas just record the changes from one binary file to another. If my original file was:
123567890ABCEEE
and I modified it to become:
1234567890ABD
Then convention would require me to distribute the second version as a replacement for the first. Using a binary diff, I could distribute a command file that represents something like:
[insert,4,1]4;[delete,13,16];[append]D;
(i.e. insert 1 character '4' at position 4, delete characters at original positions 13-16, then append D to the end). Of course, the command file itself probably wouldn't be using ASCII to represent those commands. A real command file might look something like:
(where each of those is a single byte). For short files, like the example I've given, there isn't much of a win (or any!), but for longer files (e.g. the mozilla binary), it's much more likely that binary deltas will be shorter than a complete new copy.
Actually, Red Hat were using binary diffs a long time ago - see rhmask. Of course, when they switched from shipping some proprietary software (CDE, Red Baron, Metrolink's(?) X11) to only shipping 100% FOSS, rhmask fell into disuse.
It probably wouldn't take much to take rhmask and update it to use xdelta or something, though. Note what the xdelta manpage says about using it on compressed data, though:
Gzip processing Attempting to compute a delta between compressed input files usually results in poor compression. This is because small differences between the original contents causes changes in the compression of whole blocks of data. To simplify things, Xdelta implements a special case for gzip(1) compressed files. If any version input to the delta command is recognized as having gzip compression, it will be automatically decom- pressed into a temporary location prior to comparison.
[...]
There is one potential problem when automatically processing gzip com- pressed files, which is that the recompressed content does not always match byte-for-byte with the original compressed content. The uncom- pressed content still matches, but if there is an external integrity check such as cryptographic signature verification, it may fail.
That would clash with rpm's MD5 and GPG signature checking.
In a recent interview posted on HERT today, he says: 'I've become entirely jaded towards security as a whole (or rather, people's complete lack of it)
I second that. It's gotten to the point that I refer to security as 'The Gloomy Engineering Discipline' (suggestions for a catchier phrase welcome) in a nod to economics.
The only certainty is that everyone gets 0wn3d eventually, and all one can really hope to do is delay that day and limit the damage caused.:(
Secrets and lies discusses security not cryptography and does and excellent job at it. Although I had the vegue concept that no security system is really secure before I read the book, I came away from my reading thanking Schneier for drilling the idea into my head so that I would not be naive. It is the best book on security I have read and I recommend it to anyone interested in this facinating field.
For example, IIRC, the fork() call on Windows is VERY slow for some reason that I don't remember.
UNIX is designed in such a way that process creation is very cheap, therefore lots of UNIX programs use fork to achieve parallelism. OTOH, Windows is designed around the threading model, so no particular attention has been made to make process creation similarly cheap.
Maybe some of the new tech patents will 'accidently' get burned.. we can only hope
Actually, no. At least not the ones that genuinely are innovative.
I'd quite like to see the expiry date on all of them mysteriously reduce by 2/3rds or so, but I'd hate to see that ingenuity lost forever and need to be re-invented.
The problem with tech patents is that the tech industry is still incredibly immature and developing at a rapid rate. Patent durations that make sense for mechanical devices aren't really appropriate for tech patents at this stage in the game.
Eventually, I'd like to see patents and copyrights "self-tune" according to some metric like the median number of registered works per capita (i.e. if almost everyone in the country has a few hundred registered works in their name - as opposed to their slavemaster^Wemployer's name - then it would appear hardly any protection is necessary as somehow people are innovating and creating and managing to make doing so a profitable enterprise). I expect this would integrate well with rms' thoughts on "functional" (i.e. programs, devices), "creative" (fiction, music) and "representative" (memoirs, manifestos) works (see section 7 of linked article).
To elaborate, 3/5 of those stories were other people's fault.
The other two (plus a couple more that killed the hardware involved) were from at least half a lifetime ago.
In the meantime, I've learnt from my own and others' mistakes. For me, this mainly involves double-checking mechanical stuff before I do it, since I don't appear to have intuitive ability in that area.;-)
Now, I don't know about you, but I'd rather hire someone who recognises the mistakes they've made (and has learnt from them), than someone who claims to have never made a mistake.
The iDX4/100 CPU that was supposed to be powered by 3.3v but was configured by the vendor without the motherboard's voltage regulator module, so was running off 5.0v (I fought to have them replace it anyway).
The sound board that needed a new edge connector fitted after I slipped on some stairs whilst carrying it, landed on it and ripped the old connector off, together with some tracks.
The PCs that were under a leaking air conditioning unit at a former employer and got soaked in water and/or coolant. Once dried out, they worked (mostly) and were given the hostnames 'itchy' and 'scratchy' in order to make people suitably nervous about using them for anything important. One of them even had a failing hard disc, so I partitioned around the failed sectors.
The 17" CRT monitor that was dropped (NOT by me!) down some stairs in 1998 whilst the same employer was moving buildings. It acquired a large crack in the case, but is still working fine.
The M68000 CPU that had several pins bent and re-bent whilst I was attempting to fit it to a new socket on an Amiga accelerator card (that in turn fitted into the original CPU socket on the Amiga motherboard).
Slashdot Mirror
Oh, little things, like the reassurance of being able to continue to use the hardware I've paid for even if nVidia don't feel like continuing to develop the drivers if-and-when the kernel API changes - like with the recent 4k stacks issue. That, and Free drivers are more stable that proprietary drivers in my experience, and when they aren't, you can look at the code to try to figure out why, rather than crossing your fingers and waiting for a driver update that may never come.
--
--
No, I got the point alright - and that's why I said that for non-tech-savvy users, they're probably better off buying a whole new machine (complete with 2-3 year warranty too!) than paying a technician (who may well be utterly incompetent - as you point out) to try to fix their existing machine. This was why I've never gotten into doing "PC Doctor" work as a sideline; I'd either have to be unethical, unprofessional, or deal with stupid-but-rich customers. No thanks.
For geeks, or for folks who can borrow a geek in exchange for food/beer/pizza/sexual favours, of course, it's a different matter.
I'm agreeing with you, but you don't seem to have realised it...
--
And I hate to be so blunt, with with the very wide range of proficiency in techs that work with the average home user's computer, that $60-$80/hr may be harder to justify than a whole new $800-$1000 computer.
In the UK, right now, it's possible to buy a Celeron 2.4GHz, 256M, 80G HDD, Intel-on-Intel motherboard, DVD-Rom/CD-writer combo machine with 17" CRT for about 300-400GBP. A (decent) plumber earns about 60GBP an hour - I don't see why a decent computer technician should charge a lower rate than that. Now think of how much onsite remedial work that technician can do for 400/60=6hrs 40m - you'd be lucky to do a single data backup/OS+Application reinstall/patch/restore cycle in that amount of time if you're working onsite at the customer's premises or home (as opposed to working on several machines in parallel in a workshop). For rational customers, buying a new machine is probably the best thing to do with their money, especially when they don't have the technical savvy to tell the difference between broken/worn-out hardware and a misconfigured/hacked/infected/corrupted OS install.
--
--
That's new to me, and pretty neat, actually - karma points for Debian. I wonder, though, whether it's actually dpkg that does that, or some well-packaged libraries (which, IMHO, is where Debian's true value lies).
--
I wouldn't be surprised if people are just testing the proof-of-concept demonstration files intended to break other image decoding code and finding that it breaks their code too, maybe in a slightly different way. It's not uncommon for separate programmers to make the same thinkos even if they've never seen each other's code (and especially if the original data spec is unclear, undefined or ambiguous on a given point).
The scary thing is that the sorts of problem we're seeing here apply to any "active" data format - i.e. one where the file isn't simply read and taken as-is (e.g. a plain text file), but is actually made up of "commands" which are interpreted as the file is used. We've seen similar problems with PostScript, PDF, MP3, wmv and probably more besides. The thing about this one is that short of HTML, JPEGs are probably the single most-commonly accessed type of active file - and from sources which may not be trustworthy too!
--
Have you tried using price comparison sites together with the Intel model numbers? (e.g. D865PERLX). If you need other model numbers, try checking dabs.com or Intel's site first.
Personally, I'm pretty happy with Intel-based Asus and Gigabyte as they generally have more features for the same price as Intel's boards and have proven to be compatible and reliable for me. On the other hand, I can't help but notice that the quality vendors seem to use Intel-on-Intel boards in their top-of-the-line server hardware.
--
Strictly speaking, that's correct, but if you update a widely used library (e.g. glibc) then you'll still need to restart all the applications that use it in order that they use the updated version of the library, otherwise they'll still be using the unlinked-but-not-gone-until-closed version. By the time you've done that, rebooting might well be the quickest thing to do, especially if you have lots of network-reachable services that are vulnerable because they inherit some flaw from the library in question.
--
I can't comment on the first two, but if you're going to drink something described as cider, at least drink a real cider or scrumpy. Strongbow is nasty chemical stuff - the equivalent of comparing UK-brewed Fosters XXXX with a good Belgian, German or Czech lager.
The last two should even be on sale in most UK supermarkets.
--
I'm not aware of any distro vendor that keeps their errata secret (though Red Hat do "only" provide src.rpms for their RHEL errata). On the other hand, one of the things that used to annoy me when I was supporting users of expensive security software was that the patches would be inseparably combined remedial fixes mixed with new features. As a result, the manufacturers wouldn't let me give the patches to customers without a (expensive) current support contract, even if they had a support contract when they bought the flawed software. That's BS, IMNSHO.
--
Call me biased, but I think that as FOSS code comes with source code (and thus a customer is able to independently determine for himself whether any given package is securely implemented), there is a case for making software that comes with source code exempt from any such litigation, and especially so if no money changes hands.
Of course, Microsoft and all the other vendors of proprietary software wouldn't like it that way. :-]
Finally, part of the value distro vendors provide is QA. Conceivably, they would still be liable if found to be negligent in their QA process.
--
The study I referred to measures total number of days of recess over all each OS for the year of 1999. That's where I got my ratios of 1:2:3 for Linux:Windows:Solaris. Go read the link, and you'll see what I mean.
and impact of each vulnerability (that is, num of setups a vuln actually affects, plus total num of vulns - if it takes them 1 hour to patch a vuln, but they get 24 vuln's a day, but it takes someone else 4 hours to patch, but only get one vuln a day, which is better?).
I think we can probably say that the difficulty-to-exploit will be approximately equal between all remotely-exploitable vulnerabilities (regardless of platform or package, assuming similarly-configured defensive features), and likewise between all locally-exploitable vulnerabilites regardless of platform. So the only thing that would really matter is the ratio of locally-exploitable to remotely-exploitable vulnerabilities and the total number. Sun did better on the latter than both Red Hat and Microsoft but, Linux ships a greater range of software in the standard distro than both and did better than Microsoft.
As it happens, I think it's pretty hard to say which of Solaris or Red Hat Linux is more secure based on the numbers in this study (and it was the assertion that "Solaris is more secure than Linux" that I was refuting). But I think it's fair to say that whichever way you cut it, both are more secure than Windows, and have numbers to back that assertion up.
Second b/c you're only measuring what's known, but there are a sizeable number of vulnerabilities that are not known. Is it possible to measure this?
I'm happy to work on the basis that until someone knows about a vulnerability it doesn't exist. In effect, the period of recess in the study is the minimal period of recess (since it's safest to assume that some blackhat discovered each vulnerability and started exploiting it some time before it ended up up Bugtraq or even full-disclosure).
Third b/c you're not at all measuring an OS's ability to be secured, that is, what secure features come built-in to the OS versus what have to be compiled as an addon or what has to be coded from scratch or what exists as someone's untested code. But what features does the OS come with to provide ACL's, resource exhaustion protection, etc?
Apart from filesystem ACLs (which I think are over-complex bunk in the most common scenarios), I'd say that Windows is the poorest of the three for every category you've mentioned. Between Solaris and Red Hat Linux, it's harder to say - Sun have Trusted Solaris, whereas SELinux has only gone into FC2 and RHEL3 has recently gotten exec-shield, support for hardware No eXecute pages in Update 3 and is under evaluation for EAL3+/CAPP. Historically, Solaris has certainly provided more options for securing machines, but RHL is catching up fast and implementing things that Solaris probably won't have for quite some time.
Fourth, well i'm bored with this now, but don't forget hardware's impact on security.
No eXecute pages? In RHEL3u3 now if it's running pm an AMD64 or newer Pentium 4 CPU. If you're referring to something else, please elaborate. Remember that RHEL3 is available and supported on IBM S/390 and zSeries hardware as well as bog-standard x86.
--
If you have the budget, buy a PostScript device,; you won't be disappointed.
If not PostScript, how about a PCL device?
If not a PCL device, check to see what's available for the price you're prepared to pay, then check linuxprinting.org or redhat-config-printer-gui for compatibility, buy and configure (it's never taken me longer than 5 minutes).
Does anyone else use the same printing setup as RH/Fedora? Mandrake?
--
Oh wait, that's right, there is none.
I'd say that the time of recess between the general community being aware of a vulnerability and a workable patch being available is a pretty good measure. But, according to this article, In 1999, Red Hat's "at risk" time was half that of Sun's (presumably then-current versions of Solaris), and a third of Microsoft's (presumably Windows NT 4). And that's with all the stuff that's included in the RH distribution for which there aren't equivalents included in Windows or Solaris.
Of course, it would be interesting to get more up-to-date stats, or stats for distros that are touted by some as being more security-conscious (e.g. Debian, OpenBSD).
--
Yeah, VMS.
--
--
It probably wouldn't take much to take rhmask and update it to use xdelta or something, though. Note what the xdelta manpage says about using it on compressed data, though:
That would clash with rpm's MD5 and GPG signature checking.
----
I second that. It's gotten to the point that I refer to security as 'The Gloomy Engineering Discipline' (suggestions for a catchier phrase welcome) in a nod to economics.
The only certainty is that everyone gets 0wn3d eventually, and all one can really hope to do is delay that day and limit the damage caused. :(
--
Now read Security Engineering by Ross Anderson. ;-)
--
UNIX is designed in such a way that process creation is very cheap, therefore lots of UNIX programs use fork to achieve parallelism. OTOH, Windows is designed around the threading model, so no particular attention has been made to make process creation similarly cheap.
More info at this link and this one.
--
Actually, no. At least not the ones that genuinely are innovative.
I'd quite like to see the expiry date on all of them mysteriously reduce by 2/3rds or so, but I'd hate to see that ingenuity lost forever and need to be re-invented.
The problem with tech patents is that the tech industry is still incredibly immature and developing at a rapid rate. Patent durations that make sense for mechanical devices aren't really appropriate for tech patents at this stage in the game.
Eventually, I'd like to see patents and copyrights "self-tune" according to some metric like the median number of registered works per capita (i.e. if almost everyone in the country has a few hundred registered works in their name - as opposed to their slavemaster^Wemployer's name - then it would appear hardly any protection is necessary as somehow people are innovating and creating and managing to make doing so a profitable enterprise). I expect this would integrate well with rms' thoughts on "functional" (i.e. programs, devices), "creative" (fiction, music) and "representative" (memoirs, manifestos) works (see section 7 of linked article).
--
The other two (plus a couple more that killed the hardware involved) were from at least half a lifetime ago.
In the meantime, I've learnt from my own and others' mistakes. For me, this mainly involves double-checking mechanical stuff before I do it, since I don't appear to have intuitive ability in that area. ;-)
Now, I don't know about you, but I'd rather hire someone who recognises the mistakes they've made (and has learnt from them), than someone who claims to have never made a mistake.
--
The iDX4/100 CPU that was supposed to be powered by 3.3v but was configured by the vendor without the motherboard's voltage regulator module, so was running off 5.0v (I fought to have them replace it anyway).
The sound board that needed a new edge connector fitted after I slipped on some stairs whilst carrying it, landed on it and ripped the old connector off, together with some tracks.
The PCs that were under a leaking air conditioning unit at a former employer and got soaked in water and/or coolant. Once dried out, they worked (mostly) and were given the hostnames 'itchy' and 'scratchy' in order to make people suitably nervous about using them for anything important. One of them even had a failing hard disc, so I partitioned around the failed sectors.
The 17" CRT monitor that was dropped (NOT by me!) down some stairs in 1998 whilst the same employer was moving buildings. It acquired a large crack in the case, but is still working fine.
The M68000 CPU that had several pins bent and re-bent whilst I was attempting to fit it to a new socket on an Amiga accelerator card (that in turn fitted into the original CPU socket on the Amiga motherboard).
--