The only meaningful difference is that the Skype application comes pre-configured for their network. SIP softphones have to be manually configured by their users.
Anyone using nVidia GPUs for compute cards in a data center is using the closed nVidia drivers. Anyone not using them for that purpose likely doesn't even have any nVidia hardware in the first place.
Eh? Free SIP clients have been around for much longer than Skype. SIP hardware has been around for much longer than Skype hardware. I have one sitting on my desk right now. Just because Skype became popular, does that mean the entire rest of the industry should abandon their existing IP communications protocol?
Mirrors are not backups. You are correct about that. They are merely redundancy. Snapshots ARE backups. You can do whatever you want to the original copy, the the snapshot will remain undisturbed. Snapshots are simply not physical backups, however they can be if you export them to a backup server.
You're missing the point. Users CANNOT create a working implementation, as that implementation is supposed to be protecting against the user. If the user is not trusted, how can any code written by the user be trusted? How would the CDM be able to verify that the code is actually doing what it is supposed to be doing, protecting the content from the user, rather than dumping it unencrypted to the hard drive? The only way DRM works is if every piece of code is authorized and signed by a central authority, and every piece of code will only interface with other signed code.
The source can be open, but the application itself cannot. If the user tries to compile their own version of the application, it will be lacking the private keys necessary to authenticate with the CDM. If the user cannot compile a working version on their own without going through the same lengthy, costly review process, then DRM cannot be openly implemented.
Implementing crypto openly is easy. All you have to do is publish the standard. While traditional crypto protects content from third parties, with DRM, the user IS that third party. The crypto is protecting the content from the user.
Not thieves, necessarily, but criminals, yes. You put a lock on something you do not want people to access, and have not given them access. By very definition, attempting to access that object/room is an act of trespassing, a criminal action. The lock is there to delay a criminal from committing that criminal action long enough that you can spot it and prevent it.
If you're individually restarting machines, then it would be better for those handful of machines to pull an image from the image server, and not disrupt the other compute nodes. If you're restarting a whole bunch of machines, it's better to push the images out to all the nodes simultaneously using multicast, rather than bog down the network with all kinds of redundant unicast traffic.
Locks are not supposed to keep people out. Anyone in the security industry will tell you that. Locks exist to keep people out long enough that they will still be there during your next security sweep. They are merely a delaying tactic.
Now one could argue that DRM is the same thing. It's a delaying tactic to allow the copyright owner time to get those first sales, before the content makes it into illegal distribution. The trouble is that while DRM systems themselves may take a while to crack, they can always be bypassed, and bypassed immediately, by someone who captures the raw content. That means the lead time for the content owner is on the order of minutes to hours. Often times, the pirated copies are released BEFORE the official ones.
On the other hand, if someone wants to make the claim that those few hours of difference in release time are actually the most meaningful to a distributor, it could be argued that six orders of magnitude between that and copyright expiration must certainly be absurd.
DRM is not a standard that can be openly implemented. It necessitates a central licensing group that oversees product that touches DRM'd content, and verifies that it will uphold DRM. Who do you suggest should run this ultimate authority on who is allowed to write web browsers? It has nothing to do with morality, it has to do with going against the core foundation of openness on the internet.
The truth is that DRM actually is useful, but not for what most people are misled to believe. DRM is not to prevent piracy. Its long track record of being completely impotent in that regard is plenty argument for that fact. DRM restricts what the honest consumer is allowed to do with their purchased content. That allows the content producer to sell the same content to the consumer repeatedly. That is the ONLY purpose for DRM to exist, and the sooner the public begins to understand that, the sooner the public will refuse to accept DRM, and the sooner DRM will die.
You're missing a key point. In order for DRM to work, everything needs to be a totally opaque blob, including your browser, your graphics drivers, and your operating system. Any sensible CDM (yes, Flash is not a sensible CDM) is going to require the browser be tested and signed that it will uphold the restrictions of the DRM. Your signed browser will require your operating system be signed before it allows the DRM bits to operate. Your signed operating system will require all your hardware drivers be signed, and so on...
It's a huge clusterfuck with the end result that free software loses out. And if anyone mentions that CDMs don't have to be for DRM, they're an idiot. If all you want is conditional access and security, there are plenty of openly usable and widely implemented encryption protocols that can give you that.
That's a horribly inaccurate analogy. Bittorrent is like a restaurant. If you have two people holding a conversation in a restaurant, everything is fine. Even if you have several pairs talking, it's really not a problem. When you have a full restaurant and everyone is holding their own independent discussions, no one can hear a damn thing. If your network is using a hub, you would be stupid, but that's what you would get. Assuming you're using switches like a rational person, chances are not everyone is on the same switch. If they were, you would have sufficiently few developers that they would have no problem just sequentially pulling the new images off a shared server. So, further assuming you have developers networked through a branching topology, bittorrent is not topology aware. It will not attempt to favor those peers close to it on the network, and thus will quickly clog your trunk lines between switches.
Your analogy is an accurate description of broadcast or multicast networking. Why aren't you using multicast networking? Have your developers run a client that joins a certain multicast group. At a certain, scheduled time of the day, the server pushes new images onto that group, and to any client listening on that group. The client then reconstructs the image, and stores it on the hard drive of each developer. One person talks; everyone receives. No physical link ever has to transmit more than that one original copy of the file. Anyone whose machine is not available for the update can then download it manually from the central server at their leisure.
That's stupid. Why use bittorrent when a standard http server would do just fine? It's not like they don't have nice servers sitting on the campus backbone ready and available to do precisely that.
I wonder how much of that is poor CIFS implementation or configuration. I can do 115-120MB/s either way between my (Win7) desktop and my SAMBA server in my basement.
Stop using shitty networking gear that squashes multicast traffic. Use erasure or fountain coding to transmit your datagrams so clients can compute ones they missed. Have clients individually request any remaining lost datagrams over unicast.
Torrents are a very specific solution to a very limited problem in networking; specifically, people being too cheap to invest in proper co-located servers for on-demand traffic. Stop trying to apply it everywhere else.
That is NOT the case for Windows x86. That is the case for the default configuration of Windows x86. It could be modified to the users' preference using a boot flag.
Single-mode fiber has practically infinite bandwidth. If you need more, you just multiplex another LASER at a slightly different frequency. Some high density WDM systems run as many as 160 independent signals down a single fiber pair.
That 3.3GB cap is likely because you have 512MB towards your video memory, and another couple hundred MB consumed elsewhere. All accessible memory gets lumped into the same 4GB cap. Why not make a separate swap partition independent of your encrypted system partition?
Slashdot Mirror
Does it actually detect gestures, or does it really just measure the approximate size of the object pressed against the screen?
The only meaningful difference is that the Skype application comes pre-configured for their network. SIP softphones have to be manually configured by their users.
All that means is ZFS gets forked, and FreeBSD, OpenIndiana, Nexenta, or one of the other Solaris clones takes primary ownership.
Anyone using nVidia GPUs for compute cards in a data center is using the closed nVidia drivers. Anyone not using them for that purpose likely doesn't even have any nVidia hardware in the first place.
I'm still waiting for my FSF Skype clone.
Eh? Free SIP clients have been around for much longer than Skype. SIP hardware has been around for much longer than Skype hardware. I have one sitting on my desk right now. Just because Skype became popular, does that mean the entire rest of the industry should abandon their existing IP communications protocol?
Mirrors are not backups. You are correct about that. They are merely redundancy. Snapshots ARE backups. You can do whatever you want to the original copy, the the snapshot will remain undisturbed. Snapshots are simply not physical backups, however they can be if you export them to a backup server.
Is there any indication this will ever be able to detect position, as opposed to just the size and duration of something in proximity to the monitor?
You're missing the point. Users CANNOT create a working implementation, as that implementation is supposed to be protecting against the user. If the user is not trusted, how can any code written by the user be trusted? How would the CDM be able to verify that the code is actually doing what it is supposed to be doing, protecting the content from the user, rather than dumping it unencrypted to the hard drive? The only way DRM works is if every piece of code is authorized and signed by a central authority, and every piece of code will only interface with other signed code.
The source can be open, but the application itself cannot. If the user tries to compile their own version of the application, it will be lacking the private keys necessary to authenticate with the CDM. If the user cannot compile a working version on their own without going through the same lengthy, costly review process, then DRM cannot be openly implemented.
Implementing crypto openly is easy. All you have to do is publish the standard. While traditional crypto protects content from third parties, with DRM, the user IS that third party. The crypto is protecting the content from the user.
Not thieves, necessarily, but criminals, yes. You put a lock on something you do not want people to access, and have not given them access. By very definition, attempting to access that object/room is an act of trespassing, a criminal action. The lock is there to delay a criminal from committing that criminal action long enough that you can spot it and prevent it.
If you're individually restarting machines, then it would be better for those handful of machines to pull an image from the image server, and not disrupt the other compute nodes. If you're restarting a whole bunch of machines, it's better to push the images out to all the nodes simultaneously using multicast, rather than bog down the network with all kinds of redundant unicast traffic.
Locks are not supposed to keep people out. Anyone in the security industry will tell you that. Locks exist to keep people out long enough that they will still be there during your next security sweep. They are merely a delaying tactic.
Now one could argue that DRM is the same thing. It's a delaying tactic to allow the copyright owner time to get those first sales, before the content makes it into illegal distribution. The trouble is that while DRM systems themselves may take a while to crack, they can always be bypassed, and bypassed immediately, by someone who captures the raw content. That means the lead time for the content owner is on the order of minutes to hours. Often times, the pirated copies are released BEFORE the official ones.
On the other hand, if someone wants to make the claim that those few hours of difference in release time are actually the most meaningful to a distributor, it could be argued that six orders of magnitude between that and copyright expiration must certainly be absurd.
DRM is not a standard that can be openly implemented. It necessitates a central licensing group that oversees product that touches DRM'd content, and verifies that it will uphold DRM. Who do you suggest should run this ultimate authority on who is allowed to write web browsers? It has nothing to do with morality, it has to do with going against the core foundation of openness on the internet.
The truth is that DRM actually is useful, but not for what most people are misled to believe. DRM is not to prevent piracy. Its long track record of being completely impotent in that regard is plenty argument for that fact. DRM restricts what the honest consumer is allowed to do with their purchased content. That allows the content producer to sell the same content to the consumer repeatedly. That is the ONLY purpose for DRM to exist, and the sooner the public begins to understand that, the sooner the public will refuse to accept DRM, and the sooner DRM will die.
You're missing a key point. In order for DRM to work, everything needs to be a totally opaque blob, including your browser, your graphics drivers, and your operating system. Any sensible CDM (yes, Flash is not a sensible CDM) is going to require the browser be tested and signed that it will uphold the restrictions of the DRM. Your signed browser will require your operating system be signed before it allows the DRM bits to operate. Your signed operating system will require all your hardware drivers be signed, and so on...
It's a huge clusterfuck with the end result that free software loses out. And if anyone mentions that CDMs don't have to be for DRM, they're an idiot. If all you want is conditional access and security, there are plenty of openly usable and widely implemented encryption protocols that can give you that.
That's a horribly inaccurate analogy. Bittorrent is like a restaurant. If you have two people holding a conversation in a restaurant, everything is fine. Even if you have several pairs talking, it's really not a problem. When you have a full restaurant and everyone is holding their own independent discussions, no one can hear a damn thing. If your network is using a hub, you would be stupid, but that's what you would get. Assuming you're using switches like a rational person, chances are not everyone is on the same switch. If they were, you would have sufficiently few developers that they would have no problem just sequentially pulling the new images off a shared server. So, further assuming you have developers networked through a branching topology, bittorrent is not topology aware. It will not attempt to favor those peers close to it on the network, and thus will quickly clog your trunk lines between switches.
Your analogy is an accurate description of broadcast or multicast networking. Why aren't you using multicast networking? Have your developers run a client that joins a certain multicast group. At a certain, scheduled time of the day, the server pushes new images onto that group, and to any client listening on that group. The client then reconstructs the image, and stores it on the hard drive of each developer. One person talks; everyone receives. No physical link ever has to transmit more than that one original copy of the file. Anyone whose machine is not available for the update can then download it manually from the central server at their leisure.
That's stupid. Why use bittorrent when a standard http server would do just fine? It's not like they don't have nice servers sitting on the campus backbone ready and available to do precisely that.
I wonder how much of that is poor CIFS implementation or configuration. I can do 115-120MB/s either way between my (Win7) desktop and my SAMBA server in my basement.
Use multicast for this.
Stop using shitty networking gear that squashes multicast traffic. Use erasure or fountain coding to transmit your datagrams so clients can compute ones they missed. Have clients individually request any remaining lost datagrams over unicast.
Torrents are a very specific solution to a very limited problem in networking; specifically, people being too cheap to invest in proper co-located servers for on-demand traffic. Stop trying to apply it everywhere else.
How would you use bittorrent to distribute the OS? Hint... it's something a bit more complex than your typical system BIOS.
Careful not to release the smoke when you mess with that wiring harness.
That is NOT the case for Windows x86. That is the case for the default configuration of Windows x86. It could be modified to the users' preference using a boot flag.
Single-mode fiber has practically infinite bandwidth. If you need more, you just multiplex another LASER at a slightly different frequency. Some high density WDM systems run as many as 160 independent signals down a single fiber pair.
Even plenum rated cable?
That 3.3GB cap is likely because you have 512MB towards your video memory, and another couple hundred MB consumed elsewhere. All accessible memory gets lumped into the same 4GB cap. Why not make a separate swap partition independent of your encrypted system partition?