Not only that but requirements like "must be at least 8 characters long and use a number" could actually weaken security... because you could do a 7 letter password appended with a number, which is weaker than an eight letter password without the number.
Previously, h264 support for Firefox was basically inevitable because there was no way in hell that Theora was going to overtake h264 as the dominant format.
It certainly wasn't inevitable.. Mozilla has said again and again, there is absolutely no legal way to include h264 support in Firefox.
Will the iPhone market survive the lack of games? Since most games do their game logic in a language that's not C/C++/ObjC. Be it Boo in Unity3D or Lua or whatever.
Given that, wouldn't ratcheting the list of app frameworks down to the native ones be the best way to start with great apps and that consistent iPhone experience?
No. The majority of the games on the iphone are written with intermediate "non-native" frameworks. Be it C# and Boo through Unity3D, or Lua for game logic.
Writing a game using nothing but native frameworks would be ridiculous.
Premiere, though the highest volume seller among editing suites at the time, was not preferred among professionals and had little marketshare on the Mac.
True. I'd say Avid and Media100 had a much higher mac marketshare in the 90s.
Surely Adobe saw the writing on the wall? they had about ten years to port.
Why? It's not like Apple has rewritten iTunes yet... iTunes is still a 32-bit carbon app.. and remains so, even on "64-bit only" Snow Leopard. Same goes with Front Row and DVD Player.
their original refusal to write a version of Premiere for OS X (which lead to the birth of Final Cut).
Wow.. talk about revisionist history. One, Adobe Premiere 6.5, which came out in 2002, was indeed a native OSX application. Two, the guy who created Final Cut was also the creator of Premiere. He was hired by Macromedia to create Final Cut. Apple bought Final Cut from Macromedia back in 1998, *before* OSX existed. (Apple also killed off the Windows version of Final Cut when they bought it)
Apple was extremely aggressive at killing Premiere and leveraging Final Cut.
In 2003, Apple announced a program for Premiere users to trade in their discs for a free copy of Final Cut Express or a $500 discount on Final Cut Pro.
As I recall it cost $4000 in 1985 and the GUI OS (with no command line interface) was specifically designed NOT to allow hacking, or at least make it very difficult.
I think the problem is that most people don't actually remember the first macs. Most people here probably don't even know that you couldn't actually program on the original macintosh. In order to write software for the macintosh, you had to use an Apple Lisa to do the development (even Apple did this).. there were no development tools for the original mac.
Under Scully, and later, Spindler, Apple certainly wasn't as monetarily successful
The thing is, under Scully, Apple was actually very successful.
During his tenure, Sculley increased Apple's sales from $800 million to $8 billion.
The problem was that he went after the low-end consumer market (the same market that many people here complain that Apple is ignoring today), margins were the same as IBM and Dell. The Apple board forced him out, and ever since, Apple has gone after the high-end, high margin, market exclusively.
Or you could, you know, pay a whole $99 for the iPhone dev program, which lets you and your friends run non-Apple-approved code on up to 100 devices running the iPhone OS.
Since I actually am in the iPhone dev program, let me clear something up for you. One, that 100 devices is for the life of the account. You cannot revoke a device. Two, your provisional license is only good for 4 months. You want to continue using your friends app after that? He has to reissue the app for you... every 4 months. Three, that's $99 per year.
So you'll have to pay $99 year after year just to use your own software (which you have to reinstall every 4 months).
No, they wanted to do it all along - the original stated goal of the iTMS from Apple themselves was no DRM, but they had no choice since the people providing the product would not play ball.
That's what Apple said.. but I remember a big rant from They Might Be Giants complaining that Apple *forced* them to have DRM on their own songs.
You think Sony is going to win. You are wrong. Look at how long the cat-and-mouse game over the PSP has continued. They are not capable of keeping people out of hardware they own.
I'd say they were very capable. It took 5 years for the PS3 to get its first hack. 2 weeks for Sony to patch it. Who's to say it won't take another 5 years?
The ironic part is that "hardware is cheap, developers aren't" is the primary reason for going with NoSQL. Throwing more hardware at NoSQL is brain-dead easy. Cassandra, et al, are designed to cluster extremely easy. SQL databases aren't. Replication is very tricky with most SQL databases... it certainly involves programmer time. Cassandra is as simple as turning on a new server and pointing to it.
Well--except that pesky material on the surface of a disk that can store either a '1' state or a '0' state. Most people call that a 'bit'.
That's not actually how magnetic media stores information. Instead they store it as a string of state changes. ++--+++ where 0 is stored as "no change" and 1 is stored as "polarity change". So that might actually be 010100.
Let's look at the Apple II floppy disk, just because I happen to have actual stats on that from writing an emulator.
The only part that's base-2 is the amount of data in a sector. 256 bytes. That 256 bytes is encoded in "6-and-2" encoding, making it actually take up 342 bytes on disk. Not base-2. There are 74 bytes of sector header, and self-syncing data attached to that, making each sector actually take up 416 bytes on disk. Not base-2. The self-syncing bytes are actually 6 sets of 10 bits each. 60 bits. Not base-2. Each track can hold approximately 6900 bytes. That allows around 16.5 sectors per track, but since you can't have half a sector (and the amount of data that can be stored on a track isn't absolute), they round down to 16 sectors per track, and leave the rest of the track unused. (Earlier formats only had 13 sectors per track because they used "5-and-3" encoding, so each sector took up more space on the track). The disk has 35 tracks per side. That's not base-2.
The only thing involved in this disk that is base-2 is the amount of data stored per sector, and that was a completely arbitrary decision to have it match RAM.. you could actually store more data on a disk if sectors didn't store exactly 256 bytes.
I don't understand the people here who claim that because a computer works in binary, that it should present information that way. A computer is good at converting from one base to another... humans aren't. Let the computer adapt to humans, not the other way around.
Computers are *already* converting to base-10 when they say "1.3 MB" anyway.. might as well go 100% base-10.
Unless YOU know of some way to make semiconductors work with ten states instead of two that I... and the entire rest of the industry... seem to have missed.)
The bus in your computer actually uses 3 states... so do most of the semiconductors in your computer.
Harddrives and floppy disks aren't bound by base-2 in the slightest.
A floppy disk is a great example, a track can have any number of bits stored on it. The OS cuts that track into sectors of whichever size it wants, this is *arbitrary*. Because of sector encoding on floppies, it's impossible to read only part of a sector... you have to read the entire sector. Early computers made sectors the same size as a page of RAM in order to load an entire sector into a single page of RAM.
These are all decisions made by programmers, nothing inherent in the computer relies on sector sizes to be base-2. Nothing inherent in the media requires anything to be base-2.
The thing is that *every* OS uses base-10 numbers, so they should be using base-10 prefixes.
"512" is base-10.. you want to use base-2 prefixes, you should be writing 0010 0000 0000 instead.
Slashdot Mirror
With Apple products, that's not really indicative of success.
3 years later, AppleTV is a niche market that Apple has all but abandoned.
It was a key scene in the beginning of WarGames.. :)
Pencil
Not only that but requirements like "must be at least 8 characters long and use a number" could actually weaken security... because you could do a 7 letter password appended with a number, which is weaker than an eight letter password without the number.
It certainly wasn't inevitable.. Mozilla has said again and again, there is absolutely no legal way to include h264 support in Firefox.
Really? You had to go back 9 years to find that one.
Will the iPhone market survive the lack of games? Since most games do their game logic in a language that's not C/C++/ObjC. Be it Boo in Unity3D or Lua or whatever.
No. The majority of the games on the iphone are written with intermediate "non-native" frameworks. Be it C# and Boo through Unity3D, or Lua for game logic.
Writing a game using nothing but native frameworks would be ridiculous.
True. I'd say Avid and Media100 had a much higher mac marketshare in the 90s.
Why? It's not like Apple has rewritten iTunes yet... iTunes is still a 32-bit carbon app.. and remains so, even on "64-bit only" Snow Leopard. Same goes with Front Row and DVD Player.
Wow.. talk about revisionist history. One, Adobe Premiere 6.5, which came out in 2002, was indeed a native OSX application. Two, the guy who created Final Cut was also the creator of Premiere. He was hired by Macromedia to create Final Cut. Apple bought Final Cut from Macromedia back in 1998, *before* OSX existed. (Apple also killed off the Windows version of Final Cut when they bought it)
Apple was extremely aggressive at killing Premiere and leveraging Final Cut.
I think the problem is that most people don't actually remember the first macs. Most people here probably don't even know that you couldn't actually program on the original macintosh. In order to write software for the macintosh, you had to use an Apple Lisa to do the development (even Apple did this).. there were no development tools for the original mac.
The thing is, under Scully, Apple was actually very successful.
The problem was that he went after the low-end consumer market (the same market that many people here complain that Apple is ignoring today), margins were the same as IBM and Dell. The Apple board forced him out, and ever since, Apple has gone after the high-end, high margin, market exclusively.
Since I actually am in the iPhone dev program, let me clear something up for you. One, that 100 devices is for the life of the account. You cannot revoke a device. Two, your provisional license is only good for 4 months. You want to continue using your friends app after that? He has to reissue the app for you... every 4 months. Three, that's $99 per year.
So you'll have to pay $99 year after year just to use your own software (which you have to reinstall every 4 months).
The ipad's battery is measured in hours.. the kindle's is measured in days.
That's what Apple said.. but I remember a big rant from They Might Be Giants complaining that Apple *forced* them to have DRM on their own songs.
I'd say they were very capable. It took 5 years for the PS3 to get its first hack. 2 weeks for Sony to patch it. Who's to say it won't take another 5 years?
Context for the Africa comment:
http://mybroadband.co.za/news/Wireless/11099.html
A community sues iBurst because they claim their tower was making them sick. iBurst reveals that the tower wasn't even on.
The ironic part is that "hardware is cheap, developers aren't" is the primary reason for going with NoSQL. Throwing more hardware at NoSQL is brain-dead easy. Cassandra, et al, are designed to cluster extremely easy. SQL databases aren't. Replication is very tricky with most SQL databases... it certainly involves programmer time. Cassandra is as simple as turning on a new server and pointing to it.
That's not actually how magnetic media stores information. Instead they store it as a string of state changes. ++--+++ where 0 is stored as "no change" and 1 is stored as "polarity change". So that might actually be 010100.
Well that's not true in the slightest.
Let's look at the Apple II floppy disk, just because I happen to have actual stats on that from writing an emulator.
The only part that's base-2 is the amount of data in a sector. 256 bytes.
That 256 bytes is encoded in "6-and-2" encoding, making it actually take up 342 bytes on disk. Not base-2.
There are 74 bytes of sector header, and self-syncing data attached to that, making each sector actually take up 416 bytes on disk. Not base-2.
The self-syncing bytes are actually 6 sets of 10 bits each. 60 bits. Not base-2.
Each track can hold approximately 6900 bytes. That allows around 16.5 sectors per track, but since you can't have half a sector (and the amount of data that can be stored on a track isn't absolute), they round down to 16 sectors per track, and leave the rest of the track unused. (Earlier formats only had 13 sectors per track because they used "5-and-3" encoding, so each sector took up more space on the track).
The disk has 35 tracks per side. That's not base-2.
The only thing involved in this disk that is base-2 is the amount of data stored per sector, and that was a completely arbitrary decision to have it match RAM.. you could actually store more data on a disk if sectors didn't store exactly 256 bytes.
I wish I had mod points for you.
I don't understand the people here who claim that because a computer works in binary, that it should present information that way. A computer is good at converting from one base to another... humans aren't. Let the computer adapt to humans, not the other way around.
Computers are *already* converting to base-10 when they say "1.3 MB" anyway.. might as well go 100% base-10.
The bus in your computer actually uses 3 states... so do most of the semiconductors in your computer.
Harddrives and floppy disks aren't bound by base-2 in the slightest.
A floppy disk is a great example, a track can have any number of bits stored on it. The OS cuts that track into sectors of whichever size it wants, this is *arbitrary*. Because of sector encoding on floppies, it's impossible to read only part of a sector... you have to read the entire sector. Early computers made sectors the same size as a page of RAM in order to load an entire sector into a single page of RAM.
These are all decisions made by programmers, nothing inherent in the computer relies on sector sizes to be base-2. Nothing inherent in the media requires anything to be base-2.
The commandline already uses SI prefixes. GNU switched a few years ago.
$ dd if=/dev/zero of=test bs=1KB count=1
1+0 records in
1+0 records out
1000 bytes (1.0 kB) copied, 0.00012736 s, 7.9 MB/s
The thing is that *every* OS uses base-10 numbers, so they should be using base-10 prefixes.
"512" is base-10.. you want to use base-2 prefixes, you should be writing 0010 0000 0000 instead.