Yes, B and D are married, so by definition they don't ever talk to each other. And good catch, lol. I should have done the math rather than trying to keep it simple and naming all the permutations.
Let's look at what they said, exactly: "Thus, if the number of people on email doubles in a given year, the number of possible communications rises by a factor of four." This is in fact, a true statement. A bit of consideration should help you to realize that in this specific case, it is not only proportional to N squared, it is exactly N squared.
That in fact is a false statement. Assuming you have 2 people on an email, there is only one possible connection, A to B. If it doubles, there is A to B, A to C, A to D, B to C, and C to D. So by doubling the number of people on an email we have just increased the number of possible communicatiosn by a factor of 5. The statement they made was false. This is not the only false statement they made, just the first easily provable statement. The rest of the paper is just as bad, sorry.
Perhaps their credentials would be intimidating, if I didn't have my own. May I remind you this is slashdot, some of us have credentials from real schools, not 3rd rate schools like Penn State. Some of the guys mentioned likely contributed no more than a single quote and didn't write or approve the paper in whole.
From your paper: "For two-way interactive communications â" such as between fax machines or personal email â" the value of the network rises proportionally to N2, the square of the potential number of users (âoeMetcalfeÊs Lawâ). Thus, if the number of people on email doubles in a given year, the number of possible communications rises by a factor of four."
The first part is correct, that is what Metcalfe's Law states. It's about computing the value of a network given N number of connections. However, the second part which they state is based on the law (by using "Thus"), is incorrect. That is not what the law states, in fact if you read the detailed law in whole, you will see that it says that the number of possible connections rises proportioanlly to N squared, not N squared as they have stated in the paper.
From wikipedia: "Metcalfe's law characterizes many of the network effects of communication technologies and networks such as the Internet, social networking, and the World Wide Web. It is related to the fact that the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the triangular number n(n â' 1)/2, which is proportional to n2 asymptotically."
I can continue to rip your paper to shreds if you want, like fact that the title of the paper is about how bad monoculture is to security, yet their suggested "fixes" have absolutely nothing to do with changing that fact at all! And they came to these conclusions that don't support the paper's title after 19 pages of biased Microsoft bashing. So here's your paper summed up:
Monoculture is bad for security bash Microsoft for 19 pages. Pull conclusion out of behind by stating they need to publish APIs and become like IEEE/ITF/ISO that has no support from any of the previous 19 pages of bashing.
Wow, much easier to read, you should just post that instead of linking to that paper from now on. Saves your readers time in deciding that you have no clue what you are talking about.
Lol, I got 5 sentances before it became clear this wasn't an objective security paper. When they misapplied Metcalfe's law, I stopped reading. Wow, and this passes as a real security paper is some circles?
The EC case is based on the fact that Microsoft is considered a monopoly. That monopoly status was never tried in EU, and was referenced by the EC, so in effect, the US DoJ finding is part of the EC case.
To be fair, Netscape was the one that dropped their price for the browser to $0.00. Microsoft just matched it. At the time, you had to buy the Windows 95 Plus Pack in order to get IE.
Also, please note that the version of symphony used in that comparison is 1.3, which is not currently available to the public. If using 1.2, which is the latest version available, there are a lot more incompatibilities.
If by "very old versions" you mean the very latest standards, then yes. ODF 1.2 isn't a spec, it doesn't exist. The ODF committee is working on an update to 1.1 which tentatively they are calling 1.2, but it isn't near completion yet, the number could change and any of the specs could change. The formula section of the (tenatively 1.2) spec references/link to OpenFormula, which itself is not a standard, is not complete, and isn't available to the public. So OoO may have implemented what they think will become the ODF 1.2 specification, they haven't implemented it. Unless you are willing to conceed that OpenFormula needs to be OASIS/ISO certified first, and OASIS is run by sun.... Who also is in control of OoO, so I suppose in a way they would know. Nice of Sun/ODF/OoO to be using undocumented... I mean unpublished not yet standard file formats, isn't it? How nice they are so assured that whatever they want the spec to be, it will be, and it'll be approved, it's almost like they control the standards committee.
As for your objections, I'll just take point A as a case study. If ODF 1.1 is so incapable of storing formulas, then how do OpenOffice, KOffice, Google Docs and Symphony all manage to store spreadsheet formulas in it and manage to understand each other's formulas and have theirs be understood in turn?
Great in theory. Unfortunately, you just proved my point. Try it, symphony can't read formulas saved in OoO either. Ooops.
Like many newbie techies, you leap to conclusions before understanding the situation fully. I'm sorry that you don't understand what I said, perhaps in a few years after you've worked on larger projects you'll understand. Going against what you've said:
C++ does not understand ODF, or XML. So when you specify "the parser" you should say what parser you are referring to, because it's not in the standard C++ library.
That aside -- Yes, you can (likely) attach XML elements to C++ objects, as you described, but you incur a large performance (and much larger memory overhead) for doing such a thing. Anyone that has worked on a large scale application will tell you that design you gave will not function well once you start scaling it up. This design with perform terrible because it has too many on the fly conversions, and too deep of lookups for things that you will need quick access too.
Yes, Microsoft's designers likely have more than 5 years of experience, which is why they can see that: A) The ODF 1.1 spec does not have enough information to be able to store formulas. B) The method that OoO uses to store them leaves ambiguous references that can't be determined at run time, leading to the now semi-famous problem that OoO has making it think occasionally "1+2=1". Rather a bad thing for a spreadsheet. C) Even within the ODF world, there is incompatability. Try entering a simple spreadsheet using formulas in OoO, save it, then load it into lotus symphony. You'll get an unusable spreadsheet where every cell with a formula is garbage. So it's not just a Microsoft problem. D) Microsoft hadn't "already had done it right". Yes, there was a plug in on sourceforge that Microsoft help to get going, but it had many issues as well. When Microsoft decided to bring ODF inside and do it "right", this was one of the things that had to change. E) OoO is *NOT* ODF 1.1 compliant. Office 2007 *is* ODF 1.1 compliant, 100%. So to say use OoO as a reference would be bad considering that the EU and many governments are requiring ODF compliance.
As you can see there were many other options other than your "only one other option". There are lot more technical stuff, but if you really want to know the who, how, and why, google is your friend.
Also, if you are a fan of ODF, perhaps you should be thankful for Microsoft's implementation which is one of only applications out there that is 100% compliant with the spec. You should bash OoO for their poor implementation with proprietary extensions that were ill conceived and poorly thought out.
How does this invalidate the statement that ODF's arguments against OOXML were incomplete, and vendors would be unable to use it without looking at what Office does? Please reference ODF's official complaint.
Sorry, but this has absolutely nothing to do with anti-trust. Anti-trust is where one company that has a monopoly in one market uses that to unfairly compete in a second, unrelated market. This has nothing to do with anything other than the applications division of microsoft, and no secondary market, so no, this has nothing to do with anti-trust.
That would be true only if you are using the XML data as your primary data backing. No spreadsheet worth a crap would use XML as it's primary data backing, as XML doesn't scale well performance wise. So while your simple applications that work with XML on a limited basis, or in predicatable way, it just wouldn't work well in an application that needs to be able to process large amounts of data very quickly, possibly millions of times per second.
Wasn't that the whole argument that the ODF alliance made against the OOXML spec? Seems quite funny that the ODF spec suffers the same problem, but much worse. In fact, I do believe that Microsoft had already pointed out the deficiencies in the ODF spec a few years ago. Perhaps someone should fix the spec?
My post was not a troll, but making unprovable statements that don't include any facts that start with "I can't imagine" typically are. On the off chance I mistook your statement as a blatent troll, perhaps you could elaborate on what you meant by "I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter)". What was your reasoning for saying it? What idea were you trying to convey to us?
Did you mean to show us that you have a very limited imagination that couldn't possibly include any situation that you would EVER use MySQL, but perhaps other people with more imagination might be able to? Or were you trying to say that your imagination is large that you've thought about every conceivable situation that has happened, is currently happening, or will ever happen and in every case SQLite or Postgres is better, and we should take your word for it?
Not really interested in the serial numbers, I don't work for Dell or anything so it doesn't tell me anything in particular. I would be interested in knowing if your problem exists with the silverlight player though. If you still have netflix that is;-)
I'm no fan of DRM myself. I don't like it when people say DRM is the cause of a problem when it really isn't. Of course people typically rally around it and get out the pitch forks, but I'd rather figure out what the real problem is, and solve it. I'm not saying you didn't have a problem, and it may or may not be vista and/or DRM related, but I haven't come to that conclusion yet, but it's possible.
it's a programming language which splits up multiple threads of execution into different processes instead of threads.
That would be an incorrect definition of concurrent programming language. The actual implementation of executing multiple things isn't defined. There are many flaws in your "history lesson". OS/2 blew chunks when compared to NT at the time, and the SDK for OS/2 was a major pain to get anything working.
COM wasn't made after CORBA, it predated it, and it was developed by IBM. Much of CORBA was even based on COM, COM is mentioned all over the place in the original CORBA documentation. COM was licensed to Microsoft, which is why there was a sudden shift away from ActiveX controls and the like to the new.NET platform 8 years ago (license was expiring). I was never a huge fan of MFC, as it's design (document centric) didn't fit many of my needs. And as for the "nonstandard C" compilers, that's quite a joke as noone had a standard C compiler if it was worth anything. ANSI C was retarded and didn't support much of anything beyond hello world back then. Even your beloved OS/2's C compiler was mostly proprietary in nature. K&R C was even more popular and powerful and I would argue was a much better C standard than ANSI C at least at the time.
As for windows not supporting threads, I'm not sure where you got that from as most of my work back then all involved multi-threaded applications, and supported everything from NT 3.1 and up.
You must be thinking of a different monitor model. The Dell 2001FP doesn't support HDCP over DVI, which is the secure channel that you are talking about. Even then, it is only required for HD content, not streaming, and even then only if the require secure path option has been turned on for that particular title. And as far as I know, there still isn't a single title that has that option turned on.
I think the netflix support person you talked to didn't know what they were talking about. I have seen multiple articles on the subject but each of them links back to a single person having this problem (Davis Freeburg). As a side note, not that you still care, but netflix changed streaming players a while ago. It was available as an optional beta for the past year or so, and again, with my Dell 2405FPW which also does not support HDCP over DVI like your 2001FP, I have not had any problems with either.
The forget, but I think the problem software was either PowerDVD or AlcoholSoft, if that helps.
Yup, as I thought. One of the more popular DRM work arounds caused all kinds of problems. Namely the invalidation of DRM as you experienced, and often the ability to watch real HD-DVDs. It also caused some problems even reading some DVDs as well. I believe it was fixed in a later version of it, but it was around for quite some time (over a year).
The Dell 2001FP is one of the monitors I know works just fine (with DVI). Also, the 2407FPW works just fine, and the apple displays work just fine. Older sony TVs work with no issue, as does sharp tvs. Again, the problem wasn't with Vista, but some of the software you installed.
Really? Because I have quite a few older LCD monitors, and none of them have ever experienced any problem with watching netflix, either with the older player (the one described in the linked article), nor the newer silverlight based player. The same goes for the only three other people I personally know with older LCD monitors (of different brands), all of which have used netflix.
What you linked was a single incident, most likely caused by some other *ahem* software on the machine.
Some parts were stupid: Travelling through time via a black hole?
That wouldn't seem so stupid if you spent more time studying science. Sorry, if I'm a bit off, but going by what I recall from some of what Hawkings said, was that it's theoretically possible to travel faster than light around a black hole. And as everyone knows, if you could travel faster than light, you would travel back in time. Hence, our current best ideas on how to travel back in time (if possible) involve black holes. There is a lot more to it than that, but those are the basic principals involved.
Granted, I think there are some holes in the theory, but it's way beyond my cursory examination of the subject other than having read a number of his works, theories, and books on them. I'm not claiming anything other than it being a stupid idea isn't stupid at all.
Older LCD monitors display videos from Netflix just fine. The DRM isn't "added back in" for RC and RTM versions, they were there in the betas. Other than the PrintScreen comment, the rest is just wrong, sorry.
Actually it probably is. Way back in the day, one of the ways to get a DRM-less copy of a DVD was to run DVD software, and then have a background process that automated the "printscreen" 30 times a second to disk. There was an article on this loophole a few years back. Shortly after that video drivers, video codecs, and DVD playback software all attempted to disable printscreen while video was playing.
Slashdot Mirror
Yes, B and D are married, so by definition they don't ever talk to each other. And good catch, lol. I should have done the math rather than trying to keep it simple and naming all the permutations.
Let's look at what they said, exactly: "Thus, if the number of people on email doubles in a given year, the number of possible communications rises by a factor of four." This is in fact, a true statement. A bit of consideration should help you to realize that in this specific case, it is not only proportional to N squared, it is exactly N squared.
That in fact is a false statement. Assuming you have 2 people on an email, there is only one possible connection, A to B. If it doubles, there is A to B, A to C, A to D, B to C, and C to D. So by doubling the number of people on an email we have just increased the number of possible communicatiosn by a factor of 5. The statement they made was false. This is not the only false statement they made, just the first easily provable statement. The rest of the paper is just as bad, sorry.
Perhaps their credentials would be intimidating, if I didn't have my own. May I remind you this is slashdot, some of us have credentials from real schools, not 3rd rate schools like Penn State. Some of the guys mentioned likely contributed no more than a single quote and didn't write or approve the paper in whole.
From your paper:
"For two-way interactive communications â" such as between fax machines or personal email â" the value of the network rises proportionally to N2, the square of the potential number of users (âoeMetcalfeÊs Lawâ). Thus, if the number of people on email doubles in a given year, the number of possible communications rises by a factor of four."
The first part is correct, that is what Metcalfe's Law states. It's about computing the value of a network given N number of connections. However, the second part which they state is based on the law (by using "Thus"), is incorrect. That is not what the law states, in fact if you read the detailed law in whole, you will see that it says that the number of possible connections rises proportioanlly to N squared, not N squared as they have stated in the paper.
From wikipedia:
"Metcalfe's law characterizes many of the network effects of communication technologies and networks such as the Internet, social networking, and the World Wide Web. It is related to the fact that the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the triangular number n(n â' 1)/2, which is proportional to n2 asymptotically."
I can continue to rip your paper to shreds if you want, like fact that the title of the paper is about how bad monoculture is to security, yet their suggested "fixes" have absolutely nothing to do with changing that fact at all! And they came to these conclusions that don't support the paper's title after 19 pages of biased Microsoft bashing. So here's your paper summed up:
Monoculture is bad for security
bash Microsoft for 19 pages.
Pull conclusion out of behind by stating they need to publish APIs and become like IEEE/ITF/ISO that has no support from any of the previous 19 pages of bashing.
Wow, much easier to read, you should just post that instead of linking to that paper from now on. Saves your readers time in deciding that you have no clue what you are talking about.
Lol, I got 5 sentances before it became clear this wasn't an objective security paper. When they misapplied Metcalfe's law, I stopped reading. Wow, and this passes as a real security paper is some circles?
The EC case is based on the fact that Microsoft is considered a monopoly. That monopoly status was never tried in EU, and was referenced by the EC, so in effect, the US DoJ finding is part of the EC case.
To be fair, Netscape was the one that dropped their price for the browser to $0.00. Microsoft just matched it. At the time, you had to buy the Windows 95 Plus Pack in order to get IE.
BTW, here is a link to compatability issues between the major suppliers of ODF:
http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html
Also, please note that the version of symphony used in that comparison is 1.3, which is not currently available to the public. If using 1.2, which is the latest version available, there are a lot more incompatibilities.
If by "very old versions" you mean the very latest standards, then yes. ODF 1.2 isn't a spec, it doesn't exist. The ODF committee is working on an update to 1.1 which tentatively they are calling 1.2, but it isn't near completion yet, the number could change and any of the specs could change. The formula section of the (tenatively 1.2) spec references/link to OpenFormula, which itself is not a standard, is not complete, and isn't available to the public. So OoO may have implemented what they think will become the ODF 1.2 specification, they haven't implemented it. Unless you are willing to conceed that OpenFormula needs to be OASIS/ISO certified first, and OASIS is run by sun.... Who also is in control of OoO, so I suppose in a way they would know. Nice of Sun/ODF/OoO to be using undocumented... I mean unpublished not yet standard file formats, isn't it? How nice they are so assured that whatever they want the spec to be, it will be, and it'll be approved, it's almost like they control the standards committee.
As for your objections, I'll just take point A as a case study. If ODF 1.1 is so incapable of storing formulas, then how do OpenOffice, KOffice, Google Docs and Symphony all manage to store spreadsheet formulas in it and manage to understand each other's formulas and have theirs be understood in turn?
Great in theory. Unfortunately, you just proved my point. Try it, symphony can't read formulas saved in OoO either. Ooops.
Like many newbie techies, you leap to conclusions before understanding the situation fully. I'm sorry that you don't understand what I said, perhaps in a few years after you've worked on larger projects you'll understand. Going against what you've said:
C++ does not understand ODF, or XML. So when you specify "the parser" you should say what parser you are referring to, because it's not in the standard C++ library.
That aside -- Yes, you can (likely) attach XML elements to C++ objects, as you described, but you incur a large performance (and much larger memory overhead) for doing such a thing. Anyone that has worked on a large scale application will tell you that design you gave will not function well once you start scaling it up. This design with perform terrible because it has too many on the fly conversions, and too deep of lookups for things that you will need quick access too.
Yes, Microsoft's designers likely have more than 5 years of experience, which is why they can see that:
A) The ODF 1.1 spec does not have enough information to be able to store formulas.
B) The method that OoO uses to store them leaves ambiguous references that can't be determined at run time, leading to the now semi-famous problem that OoO has making it think occasionally "1+2=1". Rather a bad thing for a spreadsheet.
C) Even within the ODF world, there is incompatability. Try entering a simple spreadsheet using formulas in OoO, save it, then load it into lotus symphony. You'll get an unusable spreadsheet where every cell with a formula is garbage. So it's not just a Microsoft problem.
D) Microsoft hadn't "already had done it right". Yes, there was a plug in on sourceforge that Microsoft help to get going, but it had many issues as well. When Microsoft decided to bring ODF inside and do it "right", this was one of the things that had to change.
E) OoO is *NOT* ODF 1.1 compliant. Office 2007 *is* ODF 1.1 compliant, 100%. So to say use OoO as a reference would be bad considering that the EU and many governments are requiring ODF compliance.
As you can see there were many other options other than your "only one other option". There are lot more technical stuff, but if you really want to know the who, how, and why, google is your friend.
Also, if you are a fan of ODF, perhaps you should be thankful for Microsoft's implementation which is one of only applications out there that is 100% compliant with the spec. You should bash OoO for their poor implementation with proprietary extensions that were ill conceived and poorly thought out.
I'd give you a +1 Funny, if I hadn't already posted.
How does this invalidate the statement that ODF's arguments against OOXML were incomplete, and vendors would be unable to use it without looking at what Office does? Please reference ODF's official complaint.
Sorry, but this has absolutely nothing to do with anti-trust. Anti-trust is where one company that has a monopoly in one market uses that to unfairly compete in a second, unrelated market. This has nothing to do with anything other than the applications division of microsoft, and no secondary market, so no, this has nothing to do with anti-trust.
That would be true only if you are using the XML data as your primary data backing. No spreadsheet worth a crap would use XML as it's primary data backing, as XML doesn't scale well performance wise. So while your simple applications that work with XML on a limited basis, or in predicatable way, it just wouldn't work well in an application that needs to be able to process large amounts of data very quickly, possibly millions of times per second.
You must be confused, as that doesn't break ISO rules, and there are many examples of it.
Wasn't that the whole argument that the ODF alliance made against the OOXML spec? Seems quite funny that the ODF spec suffers the same problem, but much worse. In fact, I do believe that Microsoft had already pointed out the deficiencies in the ODF spec a few years ago. Perhaps someone should fix the spec?
My post was not a troll, but making unprovable statements that don't include any facts that start with "I can't imagine" typically are. On the off chance I mistook your statement as a blatent troll, perhaps you could elaborate on what you meant by "I can't imagine a scenario when I would chose to use MySQL (or MS SQL, for that matter)". What was your reasoning for saying it? What idea were you trying to convey to us?
Did you mean to show us that you have a very limited imagination that couldn't possibly include any situation that you would EVER use MySQL, but perhaps other people with more imagination might be able to? Or were you trying to say that your imagination is large that you've thought about every conceivable situation that has happened, is currently happening, or will ever happen and in every case SQLite or Postgres is better, and we should take your word for it?
Either you have a very limited imagination, or you are exaggerating because you are biased. In either case, you have rendered your opinion useless.
Not really interested in the serial numbers, I don't work for Dell or anything so it doesn't tell me anything in particular. I would be interested in knowing if your problem exists with the silverlight player though. If you still have netflix that is ;-)
I'm no fan of DRM myself. I don't like it when people say DRM is the cause of a problem when it really isn't. Of course people typically rally around it and get out the pitch forks, but I'd rather figure out what the real problem is, and solve it. I'm not saying you didn't have a problem, and it may or may not be vista and/or DRM related, but I haven't come to that conclusion yet, but it's possible.
it's a programming language which splits up multiple threads of execution into different processes instead of threads.
That would be an incorrect definition of concurrent programming language. The actual implementation of executing multiple things isn't defined. There are many flaws in your "history lesson". OS/2 blew chunks when compared to NT at the time, and the SDK for OS/2 was a major pain to get anything working.
COM wasn't made after CORBA, it predated it, and it was developed by IBM. Much of CORBA was even based on COM, COM is mentioned all over the place in the original CORBA documentation. COM was licensed to Microsoft, which is why there was a sudden shift away from ActiveX controls and the like to the new .NET platform 8 years ago (license was expiring). I was never a huge fan of MFC, as it's design (document centric) didn't fit many of my needs. And as for the "nonstandard C" compilers, that's quite a joke as noone had a standard C compiler if it was worth anything. ANSI C was retarded and didn't support much of anything beyond hello world back then. Even your beloved OS/2's C compiler was mostly proprietary in nature. K&R C was even more popular and powerful and I would argue was a much better C standard than ANSI C at least at the time.
As for windows not supporting threads, I'm not sure where you got that from as most of my work back then all involved multi-threaded applications, and supported everything from NT 3.1 and up.
You must be thinking of a different monitor model. The Dell 2001FP doesn't support HDCP over DVI, which is the secure channel that you are talking about. Even then, it is only required for HD content, not streaming, and even then only if the require secure path option has been turned on for that particular title. And as far as I know, there still isn't a single title that has that option turned on.
I think the netflix support person you talked to didn't know what they were talking about. I have seen multiple articles on the subject but each of them links back to a single person having this problem (Davis Freeburg). As a side note, not that you still care, but netflix changed streaming players a while ago. It was available as an optional beta for the past year or so, and again, with my Dell 2405FPW which also does not support HDCP over DVI like your 2001FP, I have not had any problems with either.
The forget, but I think the problem software was either PowerDVD or AlcoholSoft, if that helps.
Yup, as I thought. One of the more popular DRM work arounds caused all kinds of problems. Namely the invalidation of DRM as you experienced, and often the ability to watch real HD-DVDs. It also caused some problems even reading some DVDs as well. I believe it was fixed in a later version of it, but it was around for quite some time (over a year).
The Dell 2001FP is one of the monitors I know works just fine (with DVI). Also, the 2407FPW works just fine, and the apple displays work just fine. Older sony TVs work with no issue, as does sharp tvs. Again, the problem wasn't with Vista, but some of the software you installed.
Really? Because I have quite a few older LCD monitors, and none of them have ever experienced any problem with watching netflix, either with the older player (the one described in the linked article), nor the newer silverlight based player. The same goes for the only three other people I personally know with older LCD monitors (of different brands), all of which have used netflix.
What you linked was a single incident, most likely caused by some other *ahem* software on the machine.
Some parts were stupid:
Travelling through time via a black hole?
That wouldn't seem so stupid if you spent more time studying science. Sorry, if I'm a bit off, but going by what I recall from some of what Hawkings said, was that it's theoretically possible to travel faster than light around a black hole. And as everyone knows, if you could travel faster than light, you would travel back in time. Hence, our current best ideas on how to travel back in time (if possible) involve black holes. There is a lot more to it than that, but those are the basic principals involved.
Granted, I think there are some holes in the theory, but it's way beyond my cursory examination of the subject other than having read a number of his works, theories, and books on them. I'm not claiming anything other than it being a stupid idea isn't stupid at all.
Older LCD monitors display videos from Netflix just fine. The DRM isn't "added back in" for RC and RTM versions, they were there in the betas. Other than the PrintScreen comment, the rest is just wrong, sorry.
Actually it probably is. Way back in the day, one of the ways to get a DRM-less copy of a DVD was to run DVD software, and then have a background process that automated the "printscreen" 30 times a second to disk. There was an article on this loophole a few years back. Shortly after that video drivers, video codecs, and DVD playback software all attempted to disable printscreen while video was playing.