Just FYI, jackass (make that "stupid", or perhaps, "special" jackass), the reason this is a story isn't because there's a C64 emulator for the iPhone. Rather, it's a story because Apple pulled it from their app store because you could run a BASIC interpreter on it, and only allowed it back on the app store after the interpreter was pulled.
I mean, jebus, is it so much to ask that you just read the "stupid" article summary?
If they can use solar energy on the moon to create liquid H and O to refuel spacecraft it could provide a much needed boost into the outer solar system.
Or they could just use the solar energy directly as part of an ion drive, end up with less energy loss, and probably get to the destination in the same amount of time (factoring in the time it takes to actually produce the fuel in the first place).
Unless you think there's no point in exploration period, which ignores the entirety of human history and a good portion of its technological advances.
I think *you've* missed the point of exploration. Humanity has *never* explored just 'cuz it'd be cool. Exploration has always been in the search of new resources to exploit and new riches to acquire. Hell, the entire reason the old world conquered the new was to find new resources, be it gold, spices, drugs, slaves, etc.
That was a pretty ignorant post on He3 mining due to the exaggerated cost estimate, lack of local manufacture, and ignorance of other materials found in lunar regolith.
Given that the moon is composed of largely the same minerals as those on earth, you'd have to massively deplete our terrestrial resources before mining the moon became even *remotely* cost effective.
Even if it does require half a million tons of equipment, that equipment can be made on the Moon rather than launched from Earth at $40k or even $4k per ton.
Uh... from what, exactly? Or do you plan to bootstrap and entire manufacturing sector on the moon and *then* start mining He3?
If you can get the overall fusion power infrastructure including lunar mining to under say, a couple of trillion dollars, then you could switch over the US electricity and heating infrastructure completely to lunar-fueled fusion power. My view is that this mining infrastructure could probably be made and deployed for hundreds of billions of dollars *or less* once manufacture is established on the Moon.
Wait wait... let me get this straight. *If* you can build a fusion power infrastructure *and* lunar mining, including an *entire manufacturing base on the moon*, for under a *couple of trillion dollars*, a moonbase is suddenly worthwhile?
Wow. That's a really convincing argument, there.::rollseyes::
Or we could just get Hydrogen-Boron fusion working, which runs at lower temperatures, and uses materials easily available on earth.
But you're right. I'm sure your idea is much better.
All of these would be byproducts of such a vast mining operation. Revenue from this operation would be more than just He3.
None of which is worth the cost of retrieval. All are exceedingly common, save for helium, which, conveniently, is a by-product of H-H fusion, and so if we ever did manage to develop controlled fusion, we could just make it ourselves.
What about Cheaper mission costs if shuttles can be assembled on the moon and then launched from there with low orbit?
Yes, because that's *so* much cheaper than just building them in orbit. Yes, let's ferry all those materials hundreds of thousands of miles to the moon and then sink them in another gravity well... that'll be *so* much better.
The hold up? Probably the part where a base on the moon is pointless and exceedingly expensive? I mean, sure, it'd be cool... but let's be reasonable, here: there is *nothing* on the moon worth getting (and before you He3-fusion wankers chime in, go read this).
And that should do it. After a fair bit of disk-churning, you should have a Matroska file containing all of the elements from the original DVD title.
Some emphasis added.
Right. The original DVD *title*. ie, the video content of the DVD.
Seriously, read the steps. It involves pulling out the various video and audio titles, and generating a combined Matroska container with that data in it. But nowhere are the *menus* actually ripped. Only the content itself is transformed in that process, producing a multi-program multiplex containing a bunch of programs composed of a video and multiple audio tracks.
Again, I researched this. Heavily. Last I checked, there was a script which attempted to analyze the DVD menu structure and then create a Matroska analog but it simply didn't work. Again, things may have changed since then, but that was the state of the world the last I checked, and the site you linked to provides no evidence that things have changed (that's not to say things haven't, just that that site doesn't address the issue being discussed).
Now, maybe in the last 6 months to a year some sort of MKV revolution has happened, and it's probably time I re-researched this. Here's hoping you're right and my information is out of date.:)
Uh, no, that page describes how to rip a DVD to Matroksa in order to preserve the actual video content, audio channels, and subtitle streams. There's *nothing* in there about ripping the actual menu structure, and AFAIK, the Matroska menu spec a) is in it's infancy, b) has no tooling to make DVD -> MKV w/ menus actually doable, and c) isn't supported by any players out there.
Hardly. Case in point: I refuse to by a huge TV because, frankly, I don't have the room, and I consider it nothing more than conspicuous consumption. So I've settled on a 32" TV... which is, TBH, still huge, but I happen to watch it from a couch that's a good 12-14 feet away (it's on an angle, so the viewing distance varies a bit). And from that distance, at that screen size, SD and HD are indistinguishable simply due to physical limitations in the human eye related to angular resolution.
So unless I plan to buy a huge TV, or move my couch half-way across the room, HD is pointless. And I can't imagine I'm the only one in that boat. Furthermore, for those where the difference in resolution would be visually distinguishable, many simply don't consider the upgrade worth the bother, as SD is good enough (particularly given the quality of a decent DVD upscaler).
I'm even surprised dvds became so popular. The thing that drives me nuts about dvds is the damn menus they put at the start. I just want to watch the movie.
Don't assume, just because that's your preference, that it applies to everyone. Given the presence of extra content on most DVDs, not to mention DVDs for TV programs where multiple episodes appear on a single disc, a menuing system for accessing that content makes a ton of sense. In fact, one of the reasons I haven't bothered to try and rip my DVD collection is that no format will *preserve* those menus (and all the content they provide access to), save for a straight ISO rip, which has the problem of immense size.
That said, having portions of a DVD that actively disable controls (ie, FF, RWD, etc) is flat out evil (which is why my DVD player is Xine).
And as an aside, the reason BR is DOA is that a) they're frickin' expensive, and b) HD penetration is still not all that impressive, and for your average consumer, the upgrade just ain't worth the trouble (and yes, videophiles, you can fuck off... I said *average* consumer).
In software engineering, the delegation pattern is a technique where an object outwardly expresses certain behaviour but in reality delegates responsibility for implementing that behavior to an associated object in an Inversion of Responsibility. The delegation pattern is the fundamental abstraction that underpins composition (also referred to as aggregation), mixins and aspects.
I'm hoping that was just a misunderstanding, and that you really do know the difference.
And Go absolutely supports delegation through it's mechanism of dynamic interfaces. Specifically, a type can be defined as implementing some set of methods (thus conforming to an interface), but can then dispatch those calls to a contained object which actually implements that interface.
Though, as an aside, I don't know where you get the silly idea that Go doesn't support something akin to delegates as they're defined in C#... anonymous delegates are a superset of delegates in general, and are nothing more than statically typed closures, which Go absolutely supports.
IIRC, they neglected to call fsync when writing out configuration data, and the POSIX spec states that unless you call fsync, there's no guarantees that the data actually hits the disk right away. Combine that with the fact that ext4 extended the delay between write() and physical write out to disk (which, I believe, they've changed, although I could be wrong about that), and a sudden crash can result in data loss/corruption due to blocks having never been written out.
So, that said, it's absolutely true that KDE4 was making invalid assumptions about the behaviour of the underlying storage, which resulted in corruption. But it's also true that ext4's unusually long sync times exacerbated the problem. As such, I'd say there's plenty of blame to go around.
I disagree. I frankly don't consider that to really be copyright infringement.
Uhuh. Well, you can redefine "copyright infringement" all you want, but the rest of the world says that *is* copyright infringement.
So it sounds like what you really meant to say was "copyright infringement is never justified... using my definition of copyright infringement". Which is pretty meaningless, as far as arguments go.
Doing that does not violate copyright; disabling the DRM that prevents you from doing that is not a copyright violation.
Ugh, you really lack any form of reading comprehension, don't you? Okay, let me outline this very slowly.
1) Customer acquires content, content is DRM protected. 2) Customer is unable to defeat DRM because it actually works. 3) Customer fires up bittorrent client and downloads an unprotected copy illegally.
Do you get it now? Do you see how none of those steps actually involve defeating the DRM? That the individual is forced to resort to piracy because DRM prevents them from exercising the rights they are by law entitled to?
Except Apple's look and feel lawsuit against Microsoft has already been thrown out. About 20 years ago. So Microsoft can copy "look and feel" all they want, they have the legal precedents to do so.
Uhhh... no. According to Wikipedia, Apple won because the court ruled that:
"Apple cannot get patent-like protection for the idea of a graphical user interface, or the idea of a desktop metaphor [under copyright law]."
and, that (and this is a Wikipedia quote):
"The court established that Apple could not make copyright claims based on these ideas and could only make claims on the precise expression of them."
So, with that said, if Apple could demonstrate that Microsoft copied specific expressions of certain ideas, then they absolutely would have the basis for a lawsuit.
True object oriented systems include features such as data abstraction and encapsulation, polymorphism, and inheritance. Lose one and you may have objects of some sort, but you've also lost one of the fundamental building blocks of OOP and design.
Might I suggest you don't know as much about the area as you think you do. Object oriented development, as a methodology, is far more broad than your narrow vision of it. For example, delegation can take the place of inheritance as a method of composing functionality (and, in fact, for most applications, delegation is superior to inheritance as it reduced coupling between components).
What you've described isn't copyright infringement, it's defeating technical measures that prevent copying
Re-read my post. What I described is plain ol' piracy.
The fact is, for the average consumer, existing DRM technology is enough to ensure they can't exercise their fair use rights. As such, piracy is the only option available to them, and this is the scenario I described in my original post.
Now, according to you, that act of piracy is unjustifiable. I happen to think that's ridiculous.
Even if that had been a good tutorial on GnuStep (I didn't even notice a bad tutorial there), it wouldn't answer what I was asking for.
That's why you read Apple's docs. After all, if you were working with Mono, you'd read Microsoft's documentation, right? Apple's is no different. Their documentation describes OpenStep, and that's what GNUStep implements. As such, that documentation is perfectly useful, even if it was originally written with Mac developers in mind.
Yah but mono ain't C# at the end of the day is it.
Huh? Mono's implementation of C# will always be C#, as the language spec is open and standardized.
It will always be that bastard language child that sorta looks like it's dad.
I can only assume you're talking about the class library, here. Of course, C# and it's stack is no different than C + POSIX, here. The basic libraries and functionality are, again, standardized, and Mono implements those. In addition, it provides a stack of APIs to integrate with various OSS technologies (Gtk, Gnome, various databases, etc).
'course, I'm not sure what your point is. Mono implements the standard, just like gcc and glibc implement a standard. Mono then adds a bunch of it's own stuff. I don't see a problem here.
And really do we want to have a copy of something that is associated with the most hacked OS on the planet? No!
Uhh... why? Frankly, you sound like an idiot, here. C# and the related APIs are a decent piece of technology. Ignoring it because it was produced by the same company that produced Windows is completely idiotic.
But that's just my opinion.:)
Clearly an ignorant, uneducated one. But, this is Slashdot... I expect little else.
Actually, you're quite wrong. Go is *specifically* designed to act as a new systems-level programming language akin to C++ or D. Of course, it inherits a number of features from various high-level languages (not the least of which is an integrated GC), but in the end, it's meant to be used as a replacement for C/C++/Objective-C/D, rather than, say, Python or Perl.
I've long argued, especially when it comes to games and entertainment related media, there's absolutely NO justification in copyright infringement EVER.
Really? I buy a movie but technological measures prevent me from format shifting that content, despite the law giving me that very right under the fair use doctrine, and you're saying I'm not justified in acquiring that content illegally so that I can exercise those rights?
Slashdot Mirror
Just FYI, jackass (make that "stupid", or perhaps, "special" jackass), the reason this is a story isn't because there's a C64 emulator for the iPhone. Rather, it's a story because Apple pulled it from their app store because you could run a BASIC interpreter on it, and only allowed it back on the app store after the interpreter was pulled.
I mean, jebus, is it so much to ask that you just read the "stupid" article summary?
If they can use solar energy on the moon to create liquid H and O to refuel spacecraft it could provide a much needed boost into the outer solar system.
Or they could just use the solar energy directly as part of an ion drive, end up with less energy loss, and probably get to the destination in the same amount of time (factoring in the time it takes to actually produce the fuel in the first place).
Unless you think there's no point in exploration period, which ignores the entirety of human history and a good portion of its technological advances.
I think *you've* missed the point of exploration. Humanity has *never* explored just 'cuz it'd be cool. Exploration has always been in the search of new resources to exploit and new riches to acquire. Hell, the entire reason the old world conquered the new was to find new resources, be it gold, spices, drugs, slaves, etc.
That was a pretty ignorant post on He3 mining due to the exaggerated cost estimate, lack of local manufacture, and ignorance of other materials found in lunar regolith.
Given that the moon is composed of largely the same minerals as those on earth, you'd have to massively deplete our terrestrial resources before mining the moon became even *remotely* cost effective.
Even if it does require half a million tons of equipment, that equipment can be made on the Moon rather than launched from Earth at $40k or even $4k per ton.
Uh... from what, exactly? Or do you plan to bootstrap and entire manufacturing sector on the moon and *then* start mining He3?
If you can get the overall fusion power infrastructure including lunar mining to under say, a couple of trillion dollars, then you could switch over the US electricity and heating infrastructure completely to lunar-fueled fusion power. My view is that this mining infrastructure could probably be made and deployed for hundreds of billions of dollars *or less* once manufacture is established on the Moon.
Wait wait... let me get this straight. *If* you can build a fusion power infrastructure *and* lunar mining, including an *entire manufacturing base on the moon*, for under a *couple of trillion dollars*, a moonbase is suddenly worthwhile?
Wow. That's a really convincing argument, there. ::rollseyes::
Or we could just get Hydrogen-Boron fusion working, which runs at lower temperatures, and uses materials easily available on earth.
But you're right. I'm sure your idea is much better.
All of these would be byproducts of such a vast mining operation. Revenue from this operation would be more than just He3.
None of which is worth the cost of retrieval. All are exceedingly common, save for helium, which, conveniently, is a by-product of H-H fusion, and so if we ever did manage to develop controlled fusion, we could just make it ourselves.
What about Cheaper mission costs if shuttles can be assembled on the moon and then launched from there with low orbit?
Yes, because that's *so* much cheaper than just building them in orbit. Yes, let's ferry all those materials hundreds of thousands of miles to the moon and then sink them in another gravity well... that'll be *so* much better.
The hold up? Probably the part where a base on the moon is pointless and exceedingly expensive? I mean, sure, it'd be cool... but let's be reasonable, here: there is *nothing* on the moon worth getting (and before you He3-fusion wankers chime in, go read this).
Right. The original DVD *title*. ie, the video content of the DVD.
Seriously, read the steps. It involves pulling out the various video and audio titles, and generating a combined Matroska container with that data in it. But nowhere are the *menus* actually ripped. Only the content itself is transformed in that process, producing a multi-program multiplex containing a bunch of programs composed of a video and multiple audio tracks.
Again, I researched this. Heavily. Last I checked, there was a script which attempted to analyze the DVD menu structure and then create a Matroska analog but it simply didn't work. Again, things may have changed since then, but that was the state of the world the last I checked, and the site you linked to provides no evidence that things have changed (that's not to say things haven't, just that that site doesn't address the issue being discussed).
Now, maybe in the last 6 months to a year some sort of MKV revolution has happened, and it's probably time I re-researched this. Here's hoping you're right and my information is out of date. :)
Uh, no, that page describes how to rip a DVD to Matroksa in order to preserve the actual video content, audio channels, and subtitle streams. There's *nothing* in there about ripping the actual menu structure, and AFAIK, the Matroska menu spec a) is in it's infancy, b) has no tooling to make DVD -> MKV w/ menus actually doable, and c) isn't supported by any players out there.
'course, I'd *love* to be proven wrong. :)
Hardly. Case in point: I refuse to by a huge TV because, frankly, I don't have the room, and I consider it nothing more than conspicuous consumption. So I've settled on a 32" TV... which is, TBH, still huge, but I happen to watch it from a couch that's a good 12-14 feet away (it's on an angle, so the viewing distance varies a bit). And from that distance, at that screen size, SD and HD are indistinguishable simply due to physical limitations in the human eye related to angular resolution.
So unless I plan to buy a huge TV, or move my couch half-way across the room, HD is pointless. And I can't imagine I'm the only one in that boat. Furthermore, for those where the difference in resolution would be visually distinguishable, many simply don't consider the upgrade worth the bother, as SD is good enough (particularly given the quality of a decent DVD upscaler).
I'm even surprised dvds became so popular. The thing that drives me nuts about dvds is the damn menus they put at the start. I just want to watch the movie.
Don't assume, just because that's your preference, that it applies to everyone. Given the presence of extra content on most DVDs, not to mention DVDs for TV programs where multiple episodes appear on a single disc, a menuing system for accessing that content makes a ton of sense. In fact, one of the reasons I haven't bothered to try and rip my DVD collection is that no format will *preserve* those menus (and all the content they provide access to), save for a straight ISO rip, which has the problem of immense size.
That said, having portions of a DVD that actively disable controls (ie, FF, RWD, etc) is flat out evil (which is why my DVD player is Xine).
And as an aside, the reason BR is DOA is that a) they're frickin' expensive, and b) HD penetration is still not all that impressive, and for your average consumer, the upgrade just ain't worth the trouble (and yes, videophiles, you can fuck off... I said *average* consumer).
Too bad the language doesn't support delegates either. (As does Objective-C.)
Umm, I never said "delegate". I said "delegation". ie, the design pattern, not the language feature. As in:
I'm hoping that was just a misunderstanding, and that you really do know the difference.
And Go absolutely supports delegation through it's mechanism of dynamic interfaces. Specifically, a type can be defined as implementing some set of methods (thus conforming to an interface), but can then dispatch those calls to a contained object which actually implements that interface.
Though, as an aside, I don't know where you get the silly idea that Go doesn't support something akin to delegates as they're defined in C#... anonymous delegates are a superset of delegates in general, and are nothing more than statically typed closures, which Go absolutely supports.
IIRC, they neglected to call fsync when writing out configuration data, and the POSIX spec states that unless you call fsync, there's no guarantees that the data actually hits the disk right away. Combine that with the fact that ext4 extended the delay between write() and physical write out to disk (which, I believe, they've changed, although I could be wrong about that), and a sudden crash can result in data loss/corruption due to blocks having never been written out.
So, that said, it's absolutely true that KDE4 was making invalid assumptions about the behaviour of the underlying storage, which resulted in corruption. But it's also true that ext4's unusually long sync times exacerbated the problem. As such, I'd say there's plenty of blame to go around.
I disagree. I frankly don't consider that to really be copyright infringement.
Uhuh. Well, you can redefine "copyright infringement" all you want, but the rest of the world says that *is* copyright infringement.
So it sounds like what you really meant to say was "copyright infringement is never justified... using my definition of copyright infringement". Which is pretty meaningless, as far as arguments go.
Doing that does not violate copyright; disabling the DRM that prevents you from doing that is not a copyright violation.
Ugh, you really lack any form of reading comprehension, don't you? Okay, let me outline this very slowly.
1) Customer acquires content, content is DRM protected.
2) Customer is unable to defeat DRM because it actually works.
3) Customer fires up bittorrent client and downloads an unprotected copy illegally.
Do you get it now? Do you see how none of those steps actually involve defeating the DRM? That the individual is forced to resort to piracy because DRM prevents them from exercising the rights they are by law entitled to?
If your suggestion for learning to use Objective-C is that I use Apple's guides, then that's a reasonable reason to avoid Objective-C.
Please, that's idiotic. Do you avoid Java because you're afraid of using Sun's docs?
Except Apple's look and feel lawsuit against Microsoft has already been thrown out. About 20 years ago. So Microsoft can copy "look and feel" all they want, they have the legal precedents to do so.
Uhhh... no. According to Wikipedia, Apple won because the court ruled that:
"Apple cannot get patent-like protection for the idea of a graphical user interface, or the idea of a desktop metaphor [under copyright law]."
and, that (and this is a Wikipedia quote):
"The court established that Apple could not make copyright claims based on these ideas and could only make claims on the precise expression of them."
So, with that said, if Apple could demonstrate that Microsoft copied specific expressions of certain ideas, then they absolutely would have the basis for a lawsuit.
Issue 9 is kind of a mouthful to pronounce, plus it might be weird in some other languages (like in french where issue means exit)
Meh, in conversation just shorten it to I9 and you're good to... *cough*. Yeah.
True object oriented systems include features such as data abstraction and encapsulation, polymorphism, and inheritance. Lose one and you may have objects of some sort, but you've also lost one of the fundamental building blocks of OOP and design.
Might I suggest you don't know as much about the area as you think you do. Object oriented development, as a methodology, is far more broad than your narrow vision of it. For example, delegation can take the place of inheritance as a method of composing functionality (and, in fact, for most applications, delegation is superior to inheritance as it reduced coupling between components).
What you've described isn't copyright infringement, it's defeating technical measures that prevent copying
Re-read my post. What I described is plain ol' piracy.
The fact is, for the average consumer, existing DRM technology is enough to ensure they can't exercise their fair use rights. As such, piracy is the only option available to them, and this is the scenario I described in my original post.
Now, according to you, that act of piracy is unjustifiable. I happen to think that's ridiculous.
Even if that had been a good tutorial on GnuStep (I didn't even notice a bad tutorial there), it wouldn't answer what I was asking for.
That's why you read Apple's docs. After all, if you were working with Mono, you'd read Microsoft's documentation, right? Apple's is no different. Their documentation describes OpenStep, and that's what GNUStep implements. As such, that documentation is perfectly useful, even if it was originally written with Mac developers in mind.
Yah but mono ain't C# at the end of the day is it.
Huh? Mono's implementation of C# will always be C#, as the language spec is open and standardized.
It will always be that bastard language child that sorta looks like it's dad.
I can only assume you're talking about the class library, here. Of course, C# and it's stack is no different than C + POSIX, here. The basic libraries and functionality are, again, standardized, and Mono implements those. In addition, it provides a stack of APIs to integrate with various OSS technologies (Gtk, Gnome, various databases, etc).
'course, I'm not sure what your point is. Mono implements the standard, just like gcc and glibc implement a standard. Mono then adds a bunch of it's own stuff. I don't see a problem here.
And really do we want to have a copy of something that is associated with the most hacked OS on the planet? No!
Uhh... why? Frankly, you sound like an idiot, here. C# and the related APIs are a decent piece of technology. Ignoring it because it was produced by the same company that produced Windows is completely idiotic.
But that's just my opinion. :)
Clearly an ignorant, uneducated one. But, this is Slashdot... I expect little else.
No inheritance? Yeah, that's a "relaxed" approach all right...
You *are* away that inheritance isn't a requirement for object orientation, right? Or do you not consider Javascript or Self object oriented?
Objective-C appears to have it's points, but all the texts on it I've been able to find are very heavy into Apple specific libraries, and so useless.
Huh? This sure doesn't look that Apple specific to me...
Actually, you're quite wrong. Go is *specifically* designed to act as a new systems-level programming language akin to C++ or D. Of course, it inherits a number of features from various high-level languages (not the least of which is an integrated GC), but in the end, it's meant to be used as a replacement for C/C++/Objective-C/D, rather than, say, Python or Perl.
I've long argued, especially when it comes to games and entertainment related media, there's absolutely NO justification in copyright infringement EVER.
Really? I buy a movie but technological measures prevent me from format shifting that content, despite the law giving me that very right under the fair use doctrine, and you're saying I'm not justified in acquiring that content illegally so that I can exercise those rights?
Interesting.