Thanks to the DMCA, GitHub has no meaningful choice other than to comply with the take-down request, unfortunately. It's now down to the repository owners to ask GitHub to reinstate them, at which point it becomes a legal matter between them and Sony, with GitHub being free of any legal liability to Sony (at least with respect to the DMCA). It's not particularly newsworthy that they caved - it would have been far more newsworthy if they hadn't.
I concur. Working Effectively with Legacy Code, by Michael C. Feathers, should be considered the definitive guide book for working one's way through exactly the kind of scenario you've described.
You've painted a very black-and-white, either-or scenario. I think that the anti-copyright sentiment often expressed here on Slashdot is generally targeted against the locking up of our culture by large media organisation with deep pockets used to lobby congress and trample upon individuals with punitive lawsuits.
I believe an insistence that copyright be respected for GPL licenced software sits perfectly well with a desire for a more balanced copyright regime - one with much shorter copyright durations, and where people are free to exercise their fair-use rights without being criminalised by the DMCA.
It's probably worth noting that a chip cheap enough to be economically attractive for use in mobile phones, that can also decode 1080p video, may also be targeting significant other markets. HD TVs and set-top boxes, for example - there's a fair number of those sold each year.
Terminal velocity is somewhat of a red-herring here. If you were to drop a meteorite from a standing start from a high enough point (lets say you're in a hot air balloon), then terminal velocity is the asymptotic speed that the meteorite would approach as the acceleration due to gravity is cancelled out by air-resistance. But an actual meteorite doesn't hit the ground from a standing start. It could have been travelling at many times the speed of sound when it entered the atmosphere. Sure, its trip through the atmosphere would have slowed it down a little, but there's no guarantee that it would have dropped to terminal velocity before striking the ground.
I'm sure there are plenty of examples of meteorites leaving impact craters that are many times their size. I'm no expert, but I presume that they would also have had to have been travelling faster than terminal velocity in order to leave such marks on the ground. (Hmm, it's late - anyone know what tense I used in my last sentence? I sure don't!)
IANAL, but couldn't you, as the defendant, simply waive your right to a jury trial. You'd be better off with a technical ruling from a judge in this scenario.
That's true for BT phone lines, but Virgin Media do indead run coax to the house (despite their adverts, where Samuel Jackson's claims that fibre runs to the house).
You're right of course. My original description of finalizers was rather simplistic. The best advice I can give to new Java developers (or C# developers, come to think of it), is to completely avoid using finalizers to dispose of non-memory resources such as file streams, sockets and database connections. It's just too easy to introduce bugs this way, and they're often the type of bug that's hard for a new developer to track down the cause.
There are two common alternatives to using finalizers. The first is to avoid retaining references to non-memory resources, wherever possible. As bckrispi mentioned above, it's good practice to close sockets and file streams as soon as you've finished with them (or in the case of database connections, relinquish then to a common pool).
The second is to expose lifecycle management methods on your class, typically by providing a close() or dispose() method, which passes the responsibility of lifecycle management to the code using your class. Needless to say, the first option is definitely preferred over the second.
In 15 years of Java and C# coding, I can honestly say that the only time finalizers have been useful is in trying to detect the case where client code hasn't invoked the relevant close() or dispose() method, in order to issue a debug logging call so that this can be trapped, and then make a final attempt to call close() or dispose() within the finalizer and hope for the best.
Finalizers are only superficially similar to destructors in C++. In C++, destructors are frequently used to deallocate resources, typically memory or internal references to other objects, that were allocated during construction. The Java garbage collection model makes this kind of activity unnecessary. Objects that are no longer in use are simply reclaimed by the garbage collector behind the scenes. Finalizers are invoked during garbage collection, but there are a number of restrictions placed upon code running in a finalizer. These restrictions are severe enough that the best advice is simply to avoid using finalizers. Here's a good IBM Developerworks article that describes the problems with finalizers.
Hmm! It's been mentioned a couple of times that every democracy has to be a republic. We don't have a republic here in the UK - we have a monarchy. But we still have a representative democracy. We all elect MPs to sit in the House of Commons in parliament and represent us. I agree that, constitutionally, it's a rather odd way to go about things, though. Parliament makes the decisions, but the Queen still nominally retains power as she has to rubber stamp everything.
Unlike microfiches, the digital nature of DVD storage means that the archived data can be duplicated onto fresh disks every 15 years or so (with a statistically insignificant loss of data, thanks to the error correction mechanisms). Even though individual DVDs won't last as long as microfiche, it's possible to periodically duplicate the data, and thus archive it indefinitely.
It basically comes down to a question of cost. I'll bet that the average cost of archiving data on DVDs in this way is far less than keeping the same data on microfiche, over, say 100 years (or until a better/cheaper archiving solution arrives).
Furthermore, once the microfiches reach the end of their shelf life, however long that might be, the cost of duplicating several filing cabinets full of crumbling microfiches would be much higher than duplicating a few dozen DVDs every decade or so.
Known as 'big-O' notation, it's a way of describing the efficiency of an algorithm. A quick google search for 'big o notation' led to this page which has a fairly clear explaination, provided your maths isn't too rusty.
Basically it's an expression of how much computation is required to execute an algorithm on a problem of size n.
O(n^2) indicates that the amount of computation required to execute the algorithm is of the order of n squared. That it, if you double the size of a problem, it will take the algorithm appropximately four times the amount of computation to solve.
O(n log n) indicates that the amount of computation required to execute the algorithm is of the order of n times the logarithm of n.
O(1) indicates that the amount of computation required to execute the algorithm is fixed and is independent of n.
If you look at how these different functions 'blow up' as n increases, you can see that for large problems we ideally look to use O(1) and O(log n) algorithms. O(n), O(n log n) and O(n^2) algorithms have significant scaleability issues and generally should only be used for problems where there is no practical alternative, where you can be sure that n will never be large enough to cause problems due to excessive computation.
Why the hell should you carry around a colour TFT screen whilst listening to music?
No one's suggesting that you need to. The iPod and a miriad of memory and HD based music players will already do that job for you without the need for a large colour display. What sets this apart from music players is that it's a video player. Obviously if that's not what you want, you'd be wasting your money here and an iPod will do just fine. But for those who want portable video, the iPod doesn't cut the mustard.
It seems a little unfair to criticise this device with respect to the iPod, when they are essentially different types of device. It's like complaining about a new model of television because you only want to listen to the radio. I'm sure plenty of people would find enjoyment in an episode or two of the Simpsons or Futurama during an otherwise uneventful commuter trip, or even just whilst lounging about in the garden or on the beach
Even if Eclipse is too late, perhaps it's worth a look at IBM's first Java IDE offering - VisualAge for Java. I used version 3.0 around 1997, and I'm fairly certain it had this feature (though it was quite some time ago).
Well why should unlimited apply to either the time spent using the service or the amount of data transfered? Unlimited should mean that you can use the service whenever you like (i.e. without any time restrictions) and transfer as much data as you like (subject to your maximum bandwidth, of course)? Is this not what unlimited means - i.e. without any imposed limits on the service? If any such limited terms and conditions are specified in the smallprint of the terms and conditions, then the claim of 'unlimited' seems bogus to me.
Slashdot Mirror
Thanks to the DMCA, GitHub has no meaningful choice other than to comply with the take-down request, unfortunately. It's now down to the repository owners to ask GitHub to reinstate them, at which point it becomes a legal matter between them and Sony, with GitHub being free of any legal liability to Sony (at least with respect to the DMCA). It's not particularly newsworthy that they caved - it would have been far more newsworthy if they hadn't.
If you live n the UK, why would you be looking for a US carrier?
T-Mobile is a German company, owned by Deutsche Telecom, I believe. They have customers all over Europe, as well as in the US.
I concur. Working Effectively with Legacy Code, by Michael C. Feathers, should be considered the definitive guide book for working one's way through exactly the kind of scenario you've described.
You've painted a very black-and-white, either-or scenario. I think that the anti-copyright sentiment often expressed here on Slashdot is generally targeted against the locking up of our culture by large media organisation with deep pockets used to lobby congress and trample upon individuals with punitive lawsuits.
I believe an insistence that copyright be respected for GPL licenced software sits perfectly well with a desire for a more balanced copyright regime - one with much shorter copyright durations, and where people are free to exercise their fair-use rights without being criminalised by the DMCA.
It's probably worth noting that a chip cheap enough to be economically attractive for use in mobile phones, that can also decode 1080p video, may also be targeting significant other markets. HD TVs and set-top boxes, for example - there's a fair number of those sold each year.
Terminal velocity is somewhat of a red-herring here. If you were to drop a meteorite from a standing start from a high enough point (lets say you're in a hot air balloon), then terminal velocity is the asymptotic speed that the meteorite would approach as the acceleration due to gravity is cancelled out by air-resistance. But an actual meteorite doesn't hit the ground from a standing start. It could have been travelling at many times the speed of sound when it entered the atmosphere. Sure, its trip through the atmosphere would have slowed it down a little, but there's no guarantee that it would have dropped to terminal velocity before striking the ground. I'm sure there are plenty of examples of meteorites leaving impact craters that are many times their size. I'm no expert, but I presume that they would also have had to have been travelling faster than terminal velocity in order to leave such marks on the ground. (Hmm, it's late - anyone know what tense I used in my last sentence? I sure don't!)
Oh my!
IANAL, but couldn't you, as the defendant, simply waive your right to a jury trial. You'd be better off with a technical ruling from a judge in this scenario.
That's true for BT phone lines, but Virgin Media do indead run coax to the house (despite their adverts, where Samuel Jackson's claims that fibre runs to the house).
You're right of course. My original description of finalizers was rather simplistic. The best advice I can give to new Java developers (or C# developers, come to think of it), is to completely avoid using finalizers to dispose of non-memory resources such as file streams, sockets and database connections. It's just too easy to introduce bugs this way, and they're often the type of bug that's hard for a new developer to track down the cause.
There are two common alternatives to using finalizers. The first is to avoid retaining references to non-memory resources, wherever possible. As bckrispi mentioned above, it's good practice to close sockets and file streams as soon as you've finished with them (or in the case of database connections, relinquish then to a common pool).
The second is to expose lifecycle management methods on your class, typically by providing a close() or dispose() method, which passes the responsibility of lifecycle management to the code using your class. Needless to say, the first option is definitely preferred over the second.
In 15 years of Java and C# coding, I can honestly say that the only time finalizers have been useful is in trying to detect the case where client code hasn't invoked the relevant close() or dispose() method, in order to issue a debug logging call so that this can be trapped, and then make a final attempt to call close() or dispose() within the finalizer and hope for the best.
Finalizers are only superficially similar to destructors in C++. In C++, destructors are frequently used to deallocate resources, typically memory or internal references to other objects, that were allocated during construction. The Java garbage collection model makes this kind of activity unnecessary. Objects that are no longer in use are simply reclaimed by the garbage collector behind the scenes. Finalizers are invoked during garbage collection, but there are a number of restrictions placed upon code running in a finalizer. These restrictions are severe enough that the best advice is simply to avoid using finalizers. Here's a good IBM Developerworks article that describes the problems with finalizers.
Hmm! It's been mentioned a couple of times that every democracy has to be a republic. We don't have a republic here in the UK - we have a monarchy. But we still have a representative democracy. We all elect MPs to sit in the House of Commons in parliament and represent us. I agree that, constitutionally, it's a rather odd way to go about things, though. Parliament makes the decisions, but the Queen still nominally retains power as she has to rubber stamp everything.
Unlike microfiches, the digital nature of DVD storage means that the archived data can be duplicated onto fresh disks every 15 years or so (with a statistically insignificant loss of data, thanks to the error correction mechanisms). Even though individual DVDs won't last as long as microfiche, it's possible to periodically duplicate the data, and thus archive it indefinitely.
It basically comes down to a question of cost. I'll bet that the average cost of archiving data on DVDs in this way is far less than keeping the same data on microfiche, over, say 100 years (or until a better/cheaper archiving solution arrives).
Furthermore, once the microfiches reach the end of their shelf life, however long that might be, the cost of duplicating several filing cabinets full of crumbling microfiches would be much higher than duplicating a few dozen DVDs every decade or so.
It's short for Member of Parliament.
Known as 'big-O' notation, it's a way of describing the efficiency of an algorithm. A quick google search for 'big o notation' led to this page which has a fairly clear explaination, provided your maths isn't too rusty.
Basically it's an expression of how much computation is required to execute an algorithm on a problem of size n.
O(n^2) indicates that the amount of computation required to execute the algorithm is of the order of n squared. That it, if you double the size of a problem, it will take the algorithm appropximately four times the amount of computation to solve.
O(n log n) indicates that the amount of computation required to execute the algorithm is of the order of n times the logarithm of n.
O(1) indicates that the amount of computation required to execute the algorithm is fixed and is independent of n.
If you look at how these different functions 'blow up' as n increases, you can see that for large problems we ideally look to use O(1) and O(log n) algorithms. O(n), O(n log n) and O(n^2) algorithms have significant scaleability issues and generally should only be used for problems where there is no practical alternative, where you can be sure that n will never be large enough to cause problems due to excessive computation.
Why the hell should you carry around a colour TFT screen whilst listening to music?
No one's suggesting that you need to. The iPod and a miriad of memory and HD based music players will already do that job for you without the need for a large colour display. What sets this apart from music players is that it's a video player. Obviously if that's not what you want, you'd be wasting your money here and an iPod will do just fine. But for those who want portable video, the iPod doesn't cut the mustard.
It seems a little unfair to criticise this device with respect to the iPod, when they are essentially different types of device. It's like complaining about a new model of television because you only want to listen to the radio. I'm sure plenty of people would find enjoyment in an episode or two of the Simpsons or Futurama during an otherwise uneventful commuter trip, or even just whilst lounging about in the garden or on the beach
Even if Eclipse is too late, perhaps it's worth a look at IBM's first Java IDE offering - VisualAge for Java. I used version 3.0 around 1997, and I'm fairly certain it had this feature (though it was quite some time ago).
Well why should unlimited apply to either the time spent using the service or the amount of data transfered? Unlimited should mean that you can use the service whenever you like (i.e. without any time restrictions) and transfer as much data as you like (subject to your maximum bandwidth, of course)? Is this not what unlimited means - i.e. without any imposed limits on the service? If any such limited terms and conditions are specified in the smallprint of the terms and conditions, then the claim of 'unlimited' seems bogus to me.