You don't need special QOS guaratees or priorities for VoIP: regular TCP/IP service is more than enough for VoIP; if they degrade regular TCP/IP service to the point that VoIP doesn't work anymore, games and all sorts of other applications won't work anymore either. The thought that voice needs special networks or service classes is why telephone companies missed the boat on VoIP in the first place--they just didn't get it.
The only way to kill VoIP is through explicit, service-specific filtering, and that's technically hard to do in general, and quite anticompetitive.
The definition of "rape" as "plunder and pillage" and as "abusive and improper treatment" both seem to apply in this context.
However, I think a simpler way of putting it is to say that many people seem to think that the Star Wars films have gotten progressively worse, and they didn't even start out so good.
But there is a simple solution: control your rubbernecking and avoid the disaster scene--just stop going to Star Wars movies. See, that wasn't so hard.
Yup, but is the X11->VNC=>VNC viewer really going to be more efficient than X11=>X server? I'm a hard sell on that one.
Sometimes it is, sometimes it is not. In this case, there probably is no real practical difference. The reason to use VNC on the Windows side is that it's small and simple. A self-contained, efficient X11 server (XGL?) would, of course, be an alternative for running Knoppix+coLinux under Windows.
But X11->VNC=>VNC is more efficient than X11->Simulated-Framebuffer=>MS-Windows, because the Simulated-Framebuffer=>MS-Windows part is inefficient.
The point of running a framebuffer is to support things like Qt/E or Gtk/FB or native framebuffer apps or so forth, not to replace {X,VNC} on the host.
Sure, and there are some special-purpose apps where that is useful. But we're talking about running Knoppix under Windows.
OTOH, having an area of memory that's a DirectX surface (mapped directly to video memory if possible) available to the coLinux instance as a framebuffer doesn't strike me as being all *that* hard (though I'm sure I'd understand what bits are tricky better if I tried to implement it), and that -would- be reasonably performant.
Yes, that would be. I think it would be great if someone did that.
Today, however, I think coLinux+VNC would be a better solution than QEMU+Simulated-Framebuffer, which is what Knoppix seems to have chosen.
Publicly financed open source software is not a "competitor" of Microsoft in the economic sense, it's the creation of a public good. The public good happens to kill Microsoft's business model, but that doesn't make it a competitor.
Furthermore, what makes you think that "punishing twice" wouldn't be taken into account in determining the amount? Giving $x to a competitor instead of $x to the EU would just amount to a different amount of punishment.
No, because using the power of the state of redirect wealth from Microsoft is a good thing (tm) because it punishes Microsoft who are obviously the source of all that is wrong in the IT sector.
Using the power of the state to redirect wealth can be a good thing (it can also be a bad thing--farm subsidies, for example). We use taxation for that. Microsoft probably doesn't pay its fair share. But that's an entirely unrelated matter.
This good thing is an even better thing: using the power of the state to enforce the law. Microsoft has broken the law, and they need to be punished for that. Enforcing laws is even more fundamental than taxation.
Microsoft will be killed by market forces (Linux, Firefox, etc) because 800 pound guerilla's can change direction about as fast as a two mile long freight train can stop.
Microsoft can be killed by market forces if they actually operate in a free market. In order to keep markets free, we have laws and we have enforcement of those laws. Those laws are lenient enough, but Microsoft still managed to violate them, so they need to be punished for their past behavior and forced to comply with the law.
If you are concerned about resource usage, then don't use Firefox either. The real reason not to use Java is that it is proprietary and not standards-based.
XUL may or may not be a reasonable choice, but people won't start using it until it works in IE. Since Microsoft won't do it, maybe people need to produce an XUL plugin for IE...
The fact that a UNIX system can be brought to its knees with a "fork bomb" is not a security problem or vulnerability. If you want to limit the number of processes a user can spawn, you can set that limit, but that limit is traditionally off by default, and it is so by choice.
The reason is that the expectation exists that logged in users will not attempt DOS attacks against the host they are logged into. And that expectation tends to be satisfied even in fairly hostile environments like a multi-user student server, not necessarily because people aren't tempted, but because people tend to be identifiable and accountable.
All ulimits are off by default on most Linux distributions, and that is a reasonable default for any UNIX system. It is even more reasonable on a system that is mostly used for infrastructure servers and workstations.
However, traditionally, UNIX systems keep a little memory and a process slot in reserve to allow a root user to log in and fix things. This may take minutes (if the system has started paging), but it generally works. If Linux doesn't do this, then that's a feature that should get added.
As for why BSD isn't susceptible to fork bombs, there are good reasons and there are bad reasons for that. A good reason would be if they somehow made the system do something reasonable in the general case of many processes. I suspect, however, that they either set the ulimits by default in the distribution, or that perhaps the difference is simply due to the swap space configurations; those would be bad reasons and would make me want to use BSD less. Either way, the whole article sounds like a BSD troll to me.
VNC is not exactly fast or efficient -- being a local display mechanism isn't what it's designed for, and it shows.
The VNC server is an optimized software implementation of X11, the same implementation you run on a framebuffer device. It sends screen deltas through an efficient IPC mechanism to a client.
You will have a hard time matching that with any kind of frame buffer emulation (as in QEMU or in future versions of coLinux). Think about it: if you run an X11 server on an emulated framebuffer, the framebuffer emulation gets no information about what parts of the frame buffer have been updated; it needs to figure all of that out and then reverse engineer graphics calls to the host window system. That's really hard. (There are a bunch of other implementation choices, but they are just as hard.)
Furthermore, VNC has different protocols for different connections, including one optimized for local connections.
Overall, VNC is probably the best choice for these kinds of applications even if you have a framebuffer emulation around. It might well be worth to think about not offering frame buffer emulation for coLinux at all. What would be useful for coLinux and QEMU would be access to the display hardware so that you can run something like X11 natively. But that's hard.
Think of it this way: let's say, the employee signed an agreement with Microsoft for access to Windows NT source code (maybe as part of a previous job). Then he used some Microsoft code in a new project at his current employer. Now, his current employer says that they just want to use this code and they don't care about the fact that it is derived from Microsoft code.
Sorry, guys, it doesn't work that way. GPL-derived code falls under the GPL. If an employee contaminates your company's source code with GPL-derived code, that's a matter between the company and the employee. A copyright holder doesn't have to give up his rights just because a company has incompetent management.
The company has to clean up their code and remove anything that is based on, or derived from, GPL'ed code. If they want to sue someone, they can sue the employee for damages, or maybe they can sue their own management for gross negligence. But comply with the GPL they must.
If you want two-factor authentication, you can already get it with Linux, either with a variety of tokens/devices, or with simple strike-out lists. The necessary packages are pre-packaged for Debian and probably lots of other distributions.
My impression is that it's not very popular. But if Microsoft wants to force their users to use it, good for them. I prefer my OS to give me a choice, and I have had that choice for many years now.
QEMU is the fastest thing going as far as Free emulators, given more improvements on the virtualization side, I think this will be *the* way to run Knoppix for Windows users that just want to try it out. The speed will come in time.
No, I think the way will be CoLinux, which already runs a lot faster than QEMU, and which will (in upcoming releases) give far better integration with the host OS.
QEMU is useful for lots of purposes, but for running Linux under Windows, coLinux is a better tool in my experience.
The only way to run X is by having an X server on your Windows box,
CoLinux works like a charm using VNC: you run a VNC server on the Linux side and a VNC client on the Windows side. A side-benefit is that you can actually disconnect from the coLinux process and reconnect later.
As far as I'm concerned, coLinux is the only way to go for running Linux under Windows these days; it is superior in just about every way to any of the commercial or free solutions.
If you don't restrict yourself to that subset of cases, then QEMU wins on account of having support for far more than just a custom build of the Linux kernel.
That's irrelevant for Knoppix. Furthermore, no, I have not wanted to run Freedos or the SLES9 installer. QEMU may be useful for someone for those cases, but that doesn't make it a good choice for Knoppix.
Besides, rather than spending a lot of time now trying to get QEMU integrated with Knoppix (and giving the user the false impression that Linux is slow), it would be better if all that effort were spent on actually making coLinux better. CoLinux is pretty much ready for prime-time; all the additions now (COFS, framebuffer) are just gravy.
Go into your router's port forwarding settings. Forward 4000-7000 as TCP to the computer running Azureus. As long as you haven't changed your port settings in Azureus, this will work.
That's not an option for many reasons. SOCKS4, SOCKS5, reverse proxy, ssh, and forwarding 1 port are options; none of those actually worked. I'm sure I made some mistake somewhere, but Azureus just wouldn't tell me where it was having problems.
Well, I agree, technically, it doesn't have to be. But if you try to buy or build a new home, you will find that, in reality, in the US, most of your choices for something average-to-nice come down to traditional construction. Furthermore, you'll have problems with resale value if you buy prefab.
As for configuring behind firewalls, all clients will be hard to do, because you will never get around the need to port-forward.
When three port forwarding methods don't work while forwarding to other applications works, the problem is with Azureus, not the port forwarding.
It's not even a technical problem: I'm sure, somehow, this works with Azureus if one just knew what buttons to push. The problem is insufficiently clear documentation and user interface--the fact that Azureus doesn't communicate about what it is doing: what IP address is it sending out? How is it checking connectivity? What steps can I use to debug the process?
Azureus has warned me since before 2.0 when I tried to stop seeding a file under 1:1 ratio and explained that it is not good for the community to share under 1:1.
Well, and it hasn't warned me, which means that there is some kind of hole in its warning system that causes it to warn some people and not others. I don't know whether that's a widespread problem, but if it is, it should probably get fixed.
In any case, a warning isn't enough; timing up/downloads so that, on average, people just achieve a 1:1 ratio would be.
The fact that much of the US still builds by nailing drywall and siding to a bunch of wooden beams is not for a lack of new building techniques--it's simply still cheaper and easier, mostly simply because it's what everybody else does (=economies of scale).
Hard-shelled structures created from inflatable templates are actually quite common. Usually, they are made by spraying concrete or polymer onto the inflatable shell. Alternatively, you first pour on the concrete, then inflate (it takes fairly little pressure to do so). The lining is some combination of fabric and water/air-proof plastic. Some of the templates are reusable, others become part of the structure.
Or maybe they just want to catch up to technology a bit?
Yes, IE7 needs to "catch up", but I was questioning why they bother with IE development at all. Their entire platform can "catch up" much more quickly by simply discontinuing IE altogether and shipping Mozilla instead, and they would save money as well.
The question is: why are they duplicating the browser development effort. At this point, that serves no obvious business purpose anymore.
Good god, man.... take a pill and relax a bit.:)
My question wasn't a "foaming-at-the-mouth" kind of question; Microsoft's behavior just really doesn't make any sense, other than as an expression of irrational pride and the typical not-invented-here syndrome of large companies.
Why does it make "good business sense" to spend millions of dollars on developing software they can get for free under a license that permits commercial usage?
So you missed the popup dialog that says "Not uploading as much as you have downloaded is bad for the BitTorrent network" when you stopped the file from seeding?! By default this will show whenever you stop a torrent that has less than 1:1 ratio.
Does it show when you just kill the application (which is what I do)? Does it show when you never figured out how to configure its proxy settings (which is probably one of the major reasons for "leeching")?
Or did you manage to turn it off in the options before you even knew what it was?
I'm not sure I have actually given too much thought. I found BitTorrent to be too much of a hassle: the first few times I tried using it, I was immediately targeted for a DOS attack. A few months later, I tried using it again on a different machine from behind a firewall with NAT and couldn't get it to work properly (tried SOCKS, proxies, and kernel-based forwarding), in part because I didn't find the Azureus diagnostics to be very informative. When I tried it again on another external machine, it was so slow that it wasn't worth it.
I'm sure lots of people are finding Bittorrent useful for all sorts of content, but for me and my needs, it didn't work well. So, eventually, I just gave up on Bittorrent and went back to direct downloads (we have a big mirror site of most of the stuff I care about anyway).
But the data is available in a distributed form only transiently; Bittorrent provides little incentive for people to make data available long-term. Other systems designed for this purpose actually do ensure that the data is stored long-term in distributed form.
So yes you can by say a region 2 DVD, but you will need a region 2 DVD player to view it
With DVD players now costing less than a two DVD boxed set and being not much larger, that really isn't much of an issue anymore.
Or you use a "hidden" setting in your DVD player which disables it. This last option is not strictly legal.
Of course, it is legal. The DVD player's manufacturer may have violated their agreement with the cartel that licenses the DVD standard and they may sue them, but you don't have any agreement with those people.
Slashdot Mirror
Look here. It's for FreeBSD, but it works the same way under many Linux distributions. You can either use a calculator or print a list.
You don't need special QOS guaratees or priorities for VoIP: regular TCP/IP service is more than enough for VoIP; if they degrade regular TCP/IP service to the point that VoIP doesn't work anymore, games and all sorts of other applications won't work anymore either. The thought that voice needs special networks or service classes is why telephone companies missed the boat on VoIP in the first place--they just didn't get it.
The only way to kill VoIP is through explicit, service-specific filtering, and that's technically hard to do in general, and quite anticompetitive.
The definition of "rape" as "plunder and pillage" and as "abusive and improper treatment" both seem to apply in this context.
However, I think a simpler way of putting it is to say that many people seem to think that the Star Wars films have gotten progressively worse, and they didn't even start out so good.
But there is a simple solution: control your rubbernecking and avoid the disaster scene--just stop going to Star Wars movies. See, that wasn't so hard.
Yup, but is the X11->VNC=>VNC viewer really going to be more efficient than X11=>X server? I'm a hard sell on that one.
Sometimes it is, sometimes it is not. In this case, there probably is no real practical difference. The reason to use VNC on the Windows side is that it's small and simple. A self-contained, efficient X11 server (XGL?) would, of course, be an alternative for running Knoppix+coLinux under Windows.
But X11->VNC=>VNC is more efficient than X11->Simulated-Framebuffer=>MS-Windows, because the Simulated-Framebuffer=>MS-Windows part is inefficient.
The point of running a framebuffer is to support things like Qt/E or Gtk/FB or native framebuffer apps or so forth, not to replace {X,VNC} on the host.
Sure, and there are some special-purpose apps where that is useful. But we're talking about running Knoppix under Windows.
OTOH, having an area of memory that's a DirectX surface (mapped directly to video memory if possible) available to the coLinux instance as a framebuffer doesn't strike me as being all *that* hard (though I'm sure I'd understand what bits are tricky better if I tried to implement it), and that -would- be reasonably performant.
Yes, that would be. I think it would be great if someone did that.
Today, however, I think coLinux+VNC would be a better solution than QEMU+Simulated-Framebuffer, which is what Knoppix seems to have chosen.
BSD did not use to have resource limits turned on by default; individual (academic) sites made that decision.
Publicly financed open source software is not a "competitor" of Microsoft in the economic sense, it's the creation of a public good. The public good happens to kill Microsoft's business model, but that doesn't make it a competitor.
Furthermore, what makes you think that "punishing twice" wouldn't be taken into account in determining the amount? Giving $x to a competitor instead of $x to the EU would just amount to a different amount of punishment.
No, because using the power of the state of redirect wealth from Microsoft is a good thing (tm) because it punishes Microsoft who are obviously the source of all that is wrong in the IT sector.
Using the power of the state to redirect wealth can be a good thing (it can also be a bad thing--farm subsidies, for example). We use taxation for that. Microsoft probably doesn't pay its fair share. But that's an entirely unrelated matter.
This good thing is an even better thing: using the power of the state to enforce the law. Microsoft has broken the law, and they need to be punished for that. Enforcing laws is even more fundamental than taxation.
Microsoft will be killed by market forces (Linux, Firefox, etc) because 800 pound guerilla's can change direction about as fast as a two mile long freight train can stop.
Microsoft can be killed by market forces if they actually operate in a free market. In order to keep markets free, we have laws and we have enforcement of those laws. Those laws are lenient enough, but Microsoft still managed to violate them, so they need to be punished for their past behavior and forced to comply with the law.
If you are concerned about resource usage, then don't use Firefox either. The real reason not to use Java is that it is proprietary and not standards-based.
XUL may or may not be a reasonable choice, but people won't start using it until it works in IE. Since Microsoft won't do it, maybe people need to produce an XUL plugin for IE...
The fact that a UNIX system can be brought to its knees with a "fork bomb" is not a security problem or vulnerability. If you want to limit the number of processes a user can spawn, you can set that limit, but that limit is traditionally off by default, and it is so by choice.
The reason is that the expectation exists that logged in users will not attempt DOS attacks against the host they are logged into. And that expectation tends to be satisfied even in fairly hostile environments like a multi-user student server, not necessarily because people aren't tempted, but because people tend to be identifiable and accountable.
All ulimits are off by default on most Linux distributions, and that is a reasonable default for any UNIX system. It is even more reasonable on a system that is mostly used for infrastructure servers and workstations.
However, traditionally, UNIX systems keep a little memory and a process slot in reserve to allow a root user to log in and fix things. This may take minutes (if the system has started paging), but it generally works. If Linux doesn't do this, then that's a feature that should get added.
As for why BSD isn't susceptible to fork bombs, there are good reasons and there are bad reasons for that. A good reason would be if they somehow made the system do something reasonable in the general case of many processes. I suspect, however, that they either set the ulimits by default in the distribution, or that perhaps the difference is simply due to the swap space configurations; those would be bad reasons and would make me want to use BSD less. Either way, the whole article sounds like a BSD troll to me.
VNC is not exactly fast or efficient -- being a local display mechanism isn't what it's designed for, and it shows.
The VNC server is an optimized software implementation of X11, the same implementation you run on a framebuffer device. It sends screen deltas through an efficient IPC mechanism to a client.
You will have a hard time matching that with any kind of frame buffer emulation (as in QEMU or in future versions of coLinux). Think about it: if you run an X11 server on an emulated framebuffer, the framebuffer emulation gets no information about what parts of the frame buffer have been updated; it needs to figure all of that out and then reverse engineer graphics calls to the host window system. That's really hard. (There are a bunch of other implementation choices, but they are just as hard.)
Furthermore, VNC has different protocols for different connections, including one optimized for local connections.
Overall, VNC is probably the best choice for these kinds of applications even if you have a framebuffer emulation around. It might well be worth to think about not offering frame buffer emulation for coLinux at all. What would be useful for coLinux and QEMU would be access to the display hardware so that you can run something like X11 natively. But that's hard.
Think of it this way: let's say, the employee signed an agreement with Microsoft for access to Windows NT source code (maybe as part of a previous job). Then he used some Microsoft code in a new project at his current employer. Now, his current employer says that they just want to use this code and they don't care about the fact that it is derived from Microsoft code.
Sorry, guys, it doesn't work that way. GPL-derived code falls under the GPL. If an employee contaminates your company's source code with GPL-derived code, that's a matter between the company and the employee. A copyright holder doesn't have to give up his rights just because a company has incompetent management.
The company has to clean up their code and remove anything that is based on, or derived from, GPL'ed code. If they want to sue someone, they can sue the employee for damages, or maybe they can sue their own management for gross negligence. But comply with the GPL they must.
If you want two-factor authentication, you can already get it with Linux, either with a variety of tokens/devices, or with simple strike-out lists. The necessary packages are pre-packaged for Debian and probably lots of other distributions.
My impression is that it's not very popular. But if Microsoft wants to force their users to use it, good for them. I prefer my OS to give me a choice, and I have had that choice for many years now.
QEMU is the fastest thing going as far as Free emulators, given more improvements on the virtualization side, I think this will be *the* way to run Knoppix for Windows users that just want to try it out. The speed will come in time.
No, I think the way will be CoLinux, which already runs a lot faster than QEMU, and which will (in upcoming releases) give far better integration with the host OS.
QEMU is useful for lots of purposes, but for running Linux under Windows, coLinux is a better tool in my experience.
The only way to run X is by having an X server on your Windows box,
CoLinux works like a charm using VNC: you run a VNC server on the Linux side and a VNC client on the Windows side. A side-benefit is that you can actually disconnect from the coLinux process and reconnect later.
As far as I'm concerned, coLinux is the only way to go for running Linux under Windows these days; it is superior in just about every way to any of the commercial or free solutions.
If you don't restrict yourself to that subset of cases, then QEMU wins on account of having support for far more than just a custom build of the Linux kernel.
That's irrelevant for Knoppix. Furthermore, no, I have not wanted to run Freedos or the SLES9 installer. QEMU may be useful for someone for those cases, but that doesn't make it a good choice for Knoppix.
Besides, rather than spending a lot of time now trying to get QEMU integrated with Knoppix (and giving the user the false impression that Linux is slow), it would be better if all that effort were spent on actually making coLinux better. CoLinux is pretty much ready for prime-time; all the additions now (COFS, framebuffer) are just gravy.
Go into your router's port forwarding settings. Forward 4000-7000 as TCP to the computer running Azureus. As long as you haven't changed your port settings in Azureus, this will work.
That's not an option for many reasons. SOCKS4, SOCKS5, reverse proxy, ssh, and forwarding 1 port are options; none of those actually worked. I'm sure I made some mistake somewhere, but Azureus just wouldn't tell me where it was having problems.
Well, I agree, technically, it doesn't have to be. But if you try to buy or build a new home, you will find that, in reality, in the US, most of your choices for something average-to-nice come down to traditional construction. Furthermore, you'll have problems with resale value if you buy prefab.
As for configuring behind firewalls, all clients will be hard to do, because you will never get around the need to port-forward.
When three port forwarding methods don't work while forwarding to other applications works, the problem is with Azureus, not the port forwarding.
It's not even a technical problem: I'm sure, somehow, this works with Azureus if one just knew what buttons to push. The problem is insufficiently clear documentation and user interface--the fact that Azureus doesn't communicate about what it is doing: what IP address is it sending out? How is it checking connectivity? What steps can I use to debug the process?
Azureus has warned me since before 2.0 when I tried to stop seeding a file under 1:1 ratio and explained that it is not good for the community to share under 1:1.
Well, and it hasn't warned me, which means that there is some kind of hole in its warning system that causes it to warn some people and not others. I don't know whether that's a widespread problem, but if it is, it should probably get fixed.
In any case, a warning isn't enough; timing up/downloads so that, on average, people just achieve a 1:1 ratio would be.
The fact that much of the US still builds by nailing drywall and siding to a bunch of wooden beams is not for a lack of new building techniques--it's simply still cheaper and easier, mostly simply because it's what everybody else does (=economies of scale).
Hard-shelled structures created from inflatable templates are actually quite common. Usually, they are made by spraying concrete or polymer onto the inflatable shell. Alternatively, you first pour on the concrete, then inflate (it takes fairly little pressure to do so). The lining is some combination of fabric and water/air-proof plastic. Some of the templates are reusable, others become part of the structure.
Have a look at Domtec and Binishells.
Neither is there about small form factor desktop machines: they have been around in the PC world for at least half a dozen years.
Or maybe they just want to catch up to technology a bit?
:)
Yes, IE7 needs to "catch up", but I was questioning why they bother with IE development at all. Their entire platform can "catch up" much more quickly by simply discontinuing IE altogether and shipping Mozilla instead, and they would save money as well.
The question is: why are they duplicating the browser development effort. At this point, that serves no obvious business purpose anymore.
Good god, man.... take a pill and relax a bit.
My question wasn't a "foaming-at-the-mouth" kind of question; Microsoft's behavior just really doesn't make any sense, other than as an expression of irrational pride and the typical not-invented-here syndrome of large companies.
Why does it make "good business sense" to spend millions of dollars on developing software they can get for free under a license that permits commercial usage?
So you missed the popup dialog that says "Not uploading as much as you have downloaded is bad for the BitTorrent network" when you stopped the file from seeding?! By default this will show whenever you stop a torrent that has less than 1:1 ratio.
Does it show when you just kill the application (which is what I do)? Does it show when you never figured out how to configure its proxy settings (which is probably one of the major reasons for "leeching")?
Or did you manage to turn it off in the options before you even knew what it was?
I'm not sure I have actually given too much thought. I found BitTorrent to be too much of a hassle: the first few times I tried using it, I was immediately targeted for a DOS attack. A few months later, I tried using it again on a different machine from behind a firewall with NAT and couldn't get it to work properly (tried SOCKS, proxies, and kernel-based forwarding), in part because I didn't find the Azureus diagnostics to be very informative. When I tried it again on another external machine, it was so slow that it wasn't worth it.
I'm sure lots of people are finding Bittorrent useful for all sorts of content, but for me and my needs, it didn't work well. So, eventually, I just gave up on Bittorrent and went back to direct downloads (we have a big mirror site of most of the stuff I care about anyway).
But the data is available in a distributed form only transiently; Bittorrent provides little incentive for people to make data available long-term. Other systems designed for this purpose actually do ensure that the data is stored long-term in distributed form.
So yes you can by say a region 2 DVD, but you will need a region 2 DVD player to view it
With DVD players now costing less than a two DVD boxed set and being not much larger, that really isn't much of an issue anymore.
Or you use a "hidden" setting in your DVD player which disables it. This last option is not strictly legal.
Of course, it is legal. The DVD player's manufacturer may have violated their agreement with the cartel that licenses the DVD standard and they may sue them, but you don't have any agreement with those people.