Boy, this will REALLY piss off the those entertainment fat cats...
They got upset because transferring a portion of their catalog no longer had a "cost" associated with it. What are they gonna do when transferring their entire catalog no longer even has a time-cost associated with it?
What the hell? I go to kings games. In LA, in march, on a Saturday afternoon. I've been to hockey games were it was 90 degrees outside. The capitals stadium must have really poor air control if they have problems with that.
Confirming this. In my experience, most jailbreakers do it to run "illicit" apps, rather than to "pirate" legitimate ones. You want to run an emulator? You want to customize your phone in a non apple-approved way? you want to run an X rated app? Jailbreak. Note that I have seen jail broken phones doing all of those things, and in most cases, the apps were all paid for.
If apple allowed an open market, or, at most, did some basic sanity checks (to filter out malicious or incompetent apps that can cause harm), there would not be a jailbreaking problem.
The adoption of a new technology is generally not driven by those who dominate once it is widespread. It tends to be driven by early adopters, who are willing to spend the money to try out a new technology. They either prove it, or they have tons of problems. As soon as somebody proves a technology is viable, a business shmuck at some large company can make a successful pitch that "This is the future, etc, etc...and it's already proven technology so the company doesn't have to worry about hiccups, etc, etc".
That is why Porn killed Betamax. Not because Porn represents a large market share, but because Porn was willing to be an early adopter of VHS. They proved that video sales and rental via VHS was viable. Once that happened, the major video players we unwilling to take a bet on Betamax, no matter how superior it was, because they looked at the Porn industry and saw that VHS was already in use, and therefore, the business plan and technical hurdles were done for them, guaranteed.
Generally, yes. My point was that older programs like that (hell, new programs too, who are we kidding) tend to have poor behavioral documentation, meaning that small features and bits of logic which are important to the company are captured only in code. Meaning you needed to start the rewrite before the old geezers who maintained the old system retired, because otherwise you will have new engineers who are not familiar with the language or tools, trying to dig ultra-deep into unfamiliar software for answers.
Hell, to your point that the language being COBOL doesn't matter that much, you're probably right. Take any competent C programmer who has never looked at large open source project X, and ask him to find and modify the code for feature Y. It will take him waaaaay longer on his own than if he has access to a programmer who has been hacking on the source for a while.
Hmmm. credentials please? citations maybe? I don't claim to be an expert, but blanket dissmisiveness with no details or citations is not going to convince me, since I do know a hell of a lot about both computers and arithmetic in alternative bases.
My opinions are just that, opinions, especially regarding tertiary machines, since, to my knowledge, a truly usable one has never been demonstrated.
So it's possible that what I said is not actually true, but my opinion is based on first hand experience and opinions of others who have been in the field of computing for a very long time. So as I said, it will take more than a general statement with no backup to change my mind.
wait a minute...you just said that linux skills won't get you chicks, but the quote states that computer hacking skills are included. Even if you consider that linux skills != computer hacking skills, then surely it's not a far stretch from there, and at the very least, linux skills are probably a prerequisite to computer hacking skills...
Who the hell would go through the trouble of gold plating and diamond encrusting a monsters balls? sheesh, there are some bored motherf****rs out there...
I do in fact believe that there are infinite possible bases. The problem is creating unique symbols. It is not enough to claim you have a base-1024 number system, you must create 1024 unique symbols for the system. For an infinity-base number system, you need infinite unique symbols.
The limit to creation of computers which function in bases other than two is mostly limited by the capabilities of the human brain. We have enough trouble juggling binary. each additional number adds significantly increasing complexity.
I believe that it has been theorized that the most efficient machine would actually be tertiary (i.e. one more than binary), and numbers past that have diminishing returns. The Tertiary system would offer several distinct advantages in data manipulation, especially in dealing with odd numbers. It also offers a third state for decision making, although debate rages over what the best use for that third state would be, probably something akin to "maybe". Arguably, The third "maybe" state of a decision is a primary limiting factor in the creation of AI, since the "maybe" state is a critical part of human intelligence and decision making.
Theoretically, a base-10 computer would also be an excellent choice. Even though exceedingly complex to design at a electronic level, the advantages would be immeasurable (programming in the same base as we naturally think would make everything far easier and less error prone). Even though base-10 is significantly more complex, the alignments of the patterns of numbers are such that it optimizes the use of the number system quite well. This is exactly why humans naturally went to it without quite understanding what they had done.
Why would you want to replace 2 billion lines of working COBOL code?
Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.
"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"
Well, what's what is that:
a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.
(a) implies problem #2:
b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.
Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.
This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...
Boy, this will REALLY piss off the those entertainment fat cats...
They got upset because transferring a portion of their catalog no longer had a "cost" associated with it. What are they gonna do when transferring their entire catalog no longer even has a time-cost associated with it?
IIIIIIRONYYYYYYYYY.
Most of the games of that era run better under UNIX and WINE. Case and Point - Dungeon Keeper 2 runs beautifully on Mac OS X.
They already have their own lossless format (and it can handle 24-bit as well). it's called ALAC, which is ironically close to your joke..
How long until the witch hunts begin, and we start removing undesirable thoughts/people/etc?
We have already started trying. Just ask Julian Assange.
The man who sells a phony vacuum cleaner is a liar. The man who buys one is an idiot.
If you use the wrong tool for the job, I call that failing. But it's not the tool that failed. It's you.
bite-proof mosquitoes? I didn't realize that there was a big problem with people biting mosquitoes!
We needed both complete railroad networks, and a governable West. And we got both.
You haven't been to the west, have you?
What the hell? I go to kings games. In LA, in march, on a Saturday afternoon. I've been to hockey games were it was 90 degrees outside. The capitals stadium must have really poor air control if they have problems with that.
Confirming this. In my experience, most jailbreakers do it to run "illicit" apps, rather than to "pirate" legitimate ones. You want to run an emulator? You want to customize your phone in a non apple-approved way? you want to run an X rated app? Jailbreak. Note that I have seen jail broken phones doing all of those things, and in most cases, the apps were all paid for.
If apple allowed an open market, or, at most, did some basic sanity checks (to filter out malicious or incompetent apps that can cause harm), there would not be a jailbreaking problem.
The adoption of a new technology is generally not driven by those who dominate once it is widespread. It tends to be driven by early adopters, who are willing to spend the money to try out a new technology. They either prove it, or they have tons of problems. As soon as somebody proves a technology is viable, a business shmuck at some large company can make a successful pitch that "This is the future, etc, etc...and it's already proven technology so the company doesn't have to worry about hiccups, etc, etc".
That is why Porn killed Betamax. Not because Porn represents a large market share, but because Porn was willing to be an early adopter of VHS. They proved that video sales and rental via VHS was viable. Once that happened, the major video players we unwilling to take a bet on Betamax, no matter how superior it was, because they looked at the Porn industry and saw that VHS was already in use, and therefore, the business plan and technical hurdles were done for them, guaranteed.
We didn't do 1984, but HS Freshman English we read Animal Farm
It's not off topic. There is no topic in the original post...
'how can you have any pudding if you don't eat your meat?'
I say mod this +1 just for having a post which deserves to be modded down, but manages not to fit into any of the -1 categories.
But, But, But...if they name things consistently, people will learn the scheme and be able to properly identify the varying levels of suckage...
No, it's not that anything is possible in Vegas, just that whatever _IS_ possible stays there.
Don't Tase me Bro!
I think I know the story first hand thank you.
Generally, yes. My point was that older programs like that (hell, new programs too, who are we kidding) tend to have poor behavioral documentation, meaning that small features and bits of logic which are important to the company are captured only in code. Meaning you needed to start the rewrite before the old geezers who maintained the old system retired, because otherwise you will have new engineers who are not familiar with the language or tools, trying to dig ultra-deep into unfamiliar software for answers.
Hell, to your point that the language being COBOL doesn't matter that much, you're probably right. Take any competent C programmer who has never looked at large open source project X, and ask him to find and modify the code for feature Y. It will take him waaaaay longer on his own than if he has access to a programmer who has been hacking on the source for a while.
Hmmm. credentials please? citations maybe? I don't claim to be an expert, but blanket dissmisiveness with no details or citations is not going to convince me, since I do know a hell of a lot about both computers and arithmetic in alternative bases.
My opinions are just that, opinions, especially regarding tertiary machines, since, to my knowledge, a truly usable one has never been demonstrated.
So it's possible that what I said is not actually true, but my opinion is based on first hand experience and opinions of others who have been in the field of computing for a very long time. So as I said, it will take more than a general statement with no backup to change my mind.
wait a minute...you just said that linux skills won't get you chicks, but the quote states that computer hacking skills are included. Even if you consider that linux skills != computer hacking skills, then surely it's not a far stretch from there, and at the very least, linux skills are probably a prerequisite to computer hacking skills...
Then he's guilty of libel and your computer is guilty of slander.
i.e "My computer just slandered me with your libel"
Who the hell would go through the trouble of gold plating and diamond encrusting a monsters balls? sheesh, there are some bored motherf****rs out there...
I do in fact believe that there are infinite possible bases. The problem is creating unique symbols. It is not enough to claim you have a base-1024 number system, you must create 1024 unique symbols for the system. For an infinity-base number system, you need infinite unique symbols.
The limit to creation of computers which function in bases other than two is mostly limited by the capabilities of the human brain. We have enough trouble juggling binary. each additional number adds significantly increasing complexity.
I believe that it has been theorized that the most efficient machine would actually be tertiary (i.e. one more than binary), and numbers past that have diminishing returns. The Tertiary system would offer several distinct advantages in data manipulation, especially in dealing with odd numbers. It also offers a third state for decision making, although debate rages over what the best use for that third state would be, probably something akin to "maybe". Arguably, The third "maybe" state of a decision is a primary limiting factor in the creation of AI, since the "maybe" state is a critical part of human intelligence and decision making.
Theoretically, a base-10 computer would also be an excellent choice. Even though exceedingly complex to design at a electronic level, the advantages would be immeasurable (programming in the same base as we naturally think would make everything far easier and less error prone). Even though base-10 is significantly more complex, the alignments of the patterns of numbers are such that it optimizes the use of the number system quite well. This is exactly why humans naturally went to it without quite understanding what they had done.
Why would you want to replace 2 billion lines of working COBOL code?
Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.
"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"
Well, what's what is that:
a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.
(a) implies problem #2:
b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.
Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.
This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...