They definitely did damage - they reflashed the ROM with their code. This allowed them to use the bikes without paying for them. They stole a bike off the street and kept it for several months - this counts as theft in my book.
By their account, they modified approximately 170 of the bikes in Berlin. According to them it took about 12 minutes to hack 2 bikes - we'll assume that it only takes a tech 12 minutes to undo it which comes up with 17 hours of work just flashing the bikes back, not to mention the time that it takes to find all of the modified bikes. What if they broke any of the electronics while they were doing this? Do you think they left a little "Oops" note with an envelope and some cash - HAH!
I got drunk in the revolving restaurant in "God's Microphone" (what is the correct name for that thing) in Dallas one time. Coming back from the bathroom was a bit of an experience.
Secondly, you can't even get 54Mbps without paying thousands of dollars per month WITH WIRES Depends on where you live. I'm in Tokyo and I have 24 Mb/s DSL for about $35/mo. They're willing to pull a fiber to your house and do 100Mb/s for pretty close. Of course, that's just your connection to the ISP, beyond that your mileage will vary.
Once you do that it's more of a camera than a phone, isn't it?
Personally I'd rather have things integrate over a network rather than have all the functions stuffed into one gadget. It would be nice if my digital camera could send things out over my cell phone and that my PDA/address book could initiate calls over the phone and also display photos from the camera, etc.
to wash coffee out of a cup takes almost no water. if you use cold water, no energy. This will also get you a visit from the health department if you're doing it in a restaurant.
But they're still talking about the stations being a mile apart. Which means an average of a one-mile hike and a max of a two mile hike if your starting location and destination are exactly between stations.
Blech - the great thing about selling a software package, say targeted for home users/SOHO, is that your income is not limited by the number of hours you put in. You also don't have to go hang out at customer sites, spend you time on the phone trying to close contracts, find yourself changing features so that you can land that "big contract" (which then never shows up).
If you like doing those things, consulting is fine, but it's a really different lifestyle and business than selling a product.
Re:Left out some parts to the story
on
NeXTSTEP To Mac OS X
·
· Score: 2, Informative
In Spring of 1999, Apple shipped Mac OS X Server 1.0. In many respects, this is what was promised: Nextstep/Rhapsody on PowerPC hardware. It's a far cry from what we have in Mac OS X today, but that's because the requirements changed.
No, what was promised was that NextStep as it was would be a suitable desktop OS. Jobs' reality distortion field and Apple management's lack of understanding the Mac platform led this to be believed as a viable strategy. Next management did not understand the realities of the desktop and of trying to satisfy the Macintosh market. A server OS does not meet the requirements.
Not only does come with a X11 server but a lot of significant Unix software (Apache, MySQL, etc) is faceless. In terms of consumer desktop application, what the Unix side brings is basic infrastructure for a multi-user system.
And what does Apache and MySQL bring to a desktop OS ("faceless background app", by the way, was a favorite piece of Copland-speak that has survived apparently)? Multi-user is not a core feature in a desktop OS - memory protection and multi-processing is which Copland had. Again, whether Copland's complete lack of security would have proved fatal is an interesting point. Viruses, trojan horses, worms and other fun critters were not taken nearly as seriously in the pre-Internet era.
And cross-platform apps generally don't serve the platform or users as much as the developer.
Unfortunately the Mac needs cross platform apps in order to survive. The Mac market is too small to be hugely successful in. Go to a VC with a business plan that shows you running only on Mac and you'll get laughed out of the room (actually, your business plan will never make it out of the slush pile).
We clearly have different opinions on this, but I have a rather hard time seeing your parallel universe comparing favorably to one with Jobs, Cocoa, iMac, iPod/iTunes, iMovie, iPhoto, Final Cut Pro, etc. That's just my gut feeling.
I wonder sometimes what would have happened if the Next management had truly done an objective analysis of the merits of Copland and NextStep's kernel. I know for a fact that they did not because none of the key players who could have explained to them what was going on were consulted. Porting the NextStep API's to Copland was feasible and might have had them out of the gate years earlier. The Next team's level of arrogance was unmatched by anyone I've ever seen, well, outside of Apple. As far as an Apple level of arrogance, they fit in fairly well.
In any case, the reality we have is the reality we have. Jobs has done an admirable job of making lemonade out of the lemons left to him by prior Apple management. iTunes, incidentally, was developed outside of Apple by two of the key Copland developers who got disgusted and left after Next took over. So, perhaps the demise of Copland did save Apple.
Re:Did Copland failing actually help Apple succeed
on
NeXTSTEP To Mac OS X
·
· Score: 5, Informative
I worked on Copland. The failure of Copland was not really a failure of technology but a failure of management. There were a number of management failures that brought the project down.
In the winter of 1995 we got a mandate that the first Copland beta would be made available for the May 1996 World Wide Developers' Conference.
That winter two of the major tasks that were being handled were to bring in the new file system and the new I/O system, replacing the original Copland, hastily built, prototype systems. For the purposes of that build, Copland could be split into 4 major pieces: file system, I/O subsystem, kernel and higher level functionality.
We produced set of glue code such that either file system or I/O subsystem could be used together, allowing the new I/O subsystem to be tested without alterations to the rest of the system and the new file system to be tested with the old I/O subsystem.
In January of 1996, as we were approaching the end of that build cycle, the kernel team decided that they really, really, needed to change a bunch of API's that would break just about everything. At this point, a strong management decision would have been "WAIT - those changes can go into the next build, AFTER the I/O subsystem and file system have been tested". Instead, the kernel changes were allowed to proceed. At this point everything in the system was broken. Upgrading the old I/O subsystem to work with the new kernel API's was a huge amount of work so the ability to test the new file system against the old I/O subsystem was lost. Now, the entire system had to be tested together with every component in flux. Needless to say, the integration process for this build took forever and was probably the first death blow for the project.
As WWDC approached, we expected that pressure would be brought from management to make the deadline. Instead, as the time for all-nighters with free pizza came up in about March management looked at the schedule and decided that it could not be met. Having told everyone previously if this deadline was missed the company would be in deep doo-doo, management credibility went out the window. The number of late nighters (already not enough for a project so far behind schedule) dropped precipitously. This was the second death blow to the project.
Over the summer of 1996 we were very close to having the developer release ready. A senior engineer and tech lead had been on sabbatical and doing some serious thinking and came back with a paper that cast serious doubts on the approach that Copland was taking to emulating the Mac OS System 7 environment.
Classic Mac OS is more of a library than an operating system in that all of the operating system's data structures are in the same address as applications. Copland's approach to Classic Mac OS compatibility was to emulate EVERYTHING, including internal data structures that applications might use. For example, in Classic Mac OS there is a linked list (can't remember the name of the damned thing right now) of data structures for all of the open files. Applications would walk this list to find out who else had files open. In the Copland emulation environment the Copland file system would generate events for the emulation layer so that the emulation layer could keep this list current!
This approach was causing serious problems. The mandate from marketing was that 99% of applications had to run, warts and all and this was proving to be strictly impossible. The emphasis on providing an emulation layer had bushwhacked the "new api" such that there really wasn't much available to write apps that took advantage of the multi-tasking and memory protection that the OS provided. The paper written seriously critiqued this approach.
Unfortunately as this paper made its way up the management chain to people who did not really understand what it was talking about, the entire project began to be regarded as failed.
Copland had a number of technical failings, one of its
You're correct. However, they did not patent the procedures needed to buy an automobile. They just mentioned it as a possible use.
For this to be a reasonable patent, rather than a crap patent, they needed to actually document all of the steps that they go through for the calculations, etc. to sell an automobile in detail. This patent would be much narrower in scope as if you had a significantly different method than theirs you would be allowed to sell automobiles. The problem with this patent is that the functionality patented is trivial and hence incredibly broad.
A PHB knows nothing in terms of game development or game life cycles in general and is almost always a huge waste of time and resources. What area of expertise does a PHB have that could help in this decision? Precisely! The complete lack of understanding allows them to make a decision that has no right answer. Of course, a Magic 8 ball or coin toss would be about as useful as well....
should have noticed (notice that this is grammatical and makes sense. "Should of noticed" makes no sense and is a result of listening to people who do not enunciate)
authoratitive written material authoritative written material
The amount of effort required to make your own engine block from scratch (starting with raw steel but with the plans) is probably less that the amount of effort involved in calculating GE's quarterly results with paper and pencil.
This was actually the plan back around 1995. Apple and IBM were working on something called "CHRP" (Common Hardware Reference Platform) which was to be a design spec for a computer that could run MacOS (System 7 at the time, but moving to System 8 (the real System 8, Copland!) soon after), OS/2, AIX and Windows NT.
You may recall that at around this time, Intel entered the motherboard market and for a short time kicked the Taiwanese out on their butts. Hence, the Taiwanese were looking seriously at building CHRP motherboards and systems. Had Apple completed the spec on time and gotten it out there, things might have been quite different.
As it happened, internal politics killed CHRP inside Apple, IBM got tired of the nonsense and Microsoft put a bullet into the head of NT/PPC.
And if their business partners are being fucked, then they should stop being partners with Microsoft.
Unfortunately it's pretty hard to stop being a partner with Microsoft once you're in bed with the elephant.
I attended the first CIFS (the file sharing protocol formerly known as SMB) conference when I was working for Apple. Everyone else in the room was some form of Microsoft partner. A lot of them were smaller vendors that had tied themselves into one part of Microsoft's networking or another. Again and again during the course of the presentations Microsoft told these folks, "Oh and here's how we're changing things to screw you up." I witnessed a lot of un-nice comments coming from the other participants but I doubt any of them quit working with Microsoft.
Thin of it this way - we ship petroleum around in ships that float on top of the ocean. I think there'a lot more water than we could possibly put in use as a fuel (also, don't forget that as soon as you burn it/run it through a fuel cell the hydrogen recombines with oxygen and forms water again)
In my opinion, he could have stopped the car much earlier, but was panicked. To those who say he should have had no problem removing the smart card, try doing that while controlling a car at 120 mph on a non-empty highway (at one point, he had to overtake a truck by driving on the emergency lane!).
I had a situation like this when I was in college driving my old '77 Datsun pickup (this was in 1985 or '86). No electronics in that puppy, but the linkage that increased the idle revs when the air conditioner was on (air conditioner was long dead by the time I had this truck) broke, fell down and stuck the throttle on at full blast as I was going down the freeway.
Of coure, this being a '77 Datsun pickup, I think I topped out at less than 80 MPH but it was not a fun feeling. It took me a minute or so to figure out that I could drop into neutral (manual transmission) and turn the engine off (no power steering on that baby either:-) ). If the vehicle had had more horsepower and I had started out-accelerating other traffic and needed to steer around them I could have easily not had the presence of mind to handle the situation. You do not immediately think of turning the engine off while you're driving. It's just something you never do.
Slashdot Mirror
They definitely did damage - they reflashed the ROM with their code. This allowed them to use the bikes without paying for them. They stole a bike off the street and kept it for several months - this counts as theft in my book.
By their account, they modified approximately 170 of the bikes in Berlin. According to them it took about 12 minutes to hack 2 bikes - we'll assume that it only takes a tech 12 minutes to undo it which comes up with 17 hours of work just flashing the bikes back, not to mention the time that it takes to find all of the modified bikes. What if they broke any of the electronics while they were doing this? Do you think they left a little "Oops" note with an envelope and some cash - HAH!
I got drunk in the revolving restaurant in "God's Microphone" (what is the correct name for that thing) in Dallas one time. Coming back from the bathroom was a bit of an experience.
Use some sense
They're obviously going to use commodity drives inside of the bricks. The article has a typo in it, so what else is new?
Secondly, you can't even get 54Mbps without paying thousands of dollars per month WITH WIRES
Depends on where you live. I'm in Tokyo and I have 24 Mb/s DSL for about $35/mo. They're willing to pull a fiber to your house and do 100Mb/s for pretty close. Of course, that's just your connection to the ISP, beyond that your mileage will vary.
Please leave the Macintosh its market niche so that after Linux crushes Windows there will still be a place for Apple fanbois.
I didn't know Apu had children. I thought the QuikiMart was his entire life.
Once you do that it's more of a camera than a phone, isn't it?
Personally I'd rather have things integrate over a network rather than have all the functions stuffed into one gadget. It would be nice if my digital camera could send things out over my cell phone and that my PDA/address book could initiate calls over the phone and also display photos from the camera, etc.
I used to have cards that read "Speaker to Disk Drives" as my title when I was at Apple.
to wash coffee out of a cup takes almost no water. if you use cold water, no energy.
This will also get you a visit from the health department if you're doing it in a restaurant.
But they're still talking about the stations being a mile apart. Which means an average of a one-mile hike and a max of a two mile hike if your starting location and destination are exactly between stations.
Dude, that's what your Segway is for!
Oh, that one's easy. Engineering said "No way" and Sales said "No problem!" Haven't you ever played that game?
Blech - the great thing about selling a software package, say targeted for home users/SOHO, is that your income is not limited by the number of hours you put in. You also don't have to go hang out at customer sites, spend you time on the phone trying to close contracts, find yourself changing features so that you can land that "big contract" (which then never shows up).
If you like doing those things, consulting is fine, but it's a really different lifestyle and business than selling a product.
In Spring of 1999, Apple shipped Mac OS X Server 1.0. In many respects, this is what was promised: Nextstep/Rhapsody on PowerPC hardware. It's a far cry from what we have in Mac OS X today, but that's because the requirements changed.
No, what was promised was that NextStep as it was would be a suitable desktop OS. Jobs' reality distortion field and Apple management's lack of understanding the Mac platform led this to be believed as a viable strategy. Next management did not understand the realities of the desktop and of trying to satisfy the Macintosh market. A server OS does not meet the requirements.
Not only does come with a X11 server but a lot of significant Unix software (Apache, MySQL, etc) is faceless. In terms of consumer desktop application, what the Unix side brings is basic infrastructure for a multi-user system.
And what does Apache and MySQL bring to a desktop OS ("faceless background app", by the way, was a favorite piece of Copland-speak that has survived apparently)? Multi-user is not a core feature in a desktop OS - memory protection and multi-processing is which Copland had. Again, whether Copland's complete lack of security would have proved fatal is an interesting point. Viruses, trojan horses, worms and other fun critters were not taken nearly as seriously in the pre-Internet era.
And cross-platform apps generally don't serve the platform or users as much as the developer.
Unfortunately the Mac needs cross platform apps in order to survive. The Mac market is too small to be hugely successful in. Go to a VC with a business plan that shows you running only on Mac and you'll get laughed out of the room (actually, your business plan will never make it out of the slush pile).
We clearly have different opinions on this, but I have a rather hard time seeing your parallel universe comparing favorably to one with Jobs, Cocoa, iMac, iPod/iTunes, iMovie, iPhoto, Final Cut Pro, etc. That's just my gut feeling.
I wonder sometimes what would have happened if the Next management had truly done an objective analysis of the merits of Copland and NextStep's kernel. I know for a fact that they did not because none of the key players who could have explained to them what was going on were consulted. Porting the NextStep API's to Copland was feasible and might have had them out of the gate years earlier. The Next team's level of arrogance was unmatched by anyone I've ever seen, well, outside of Apple. As far as an Apple level of arrogance, they fit in fairly well.
In any case, the reality we have is the reality we have. Jobs has done an admirable job of making lemonade out of the lemons left to him by prior Apple management. iTunes, incidentally, was developed outside of Apple by two of the key Copland developers who got disgusted and left after Next took over. So, perhaps the demise of Copland did save Apple.
I worked on Copland. The failure of Copland was not really a failure of technology but a failure of management. There were a number of management failures that brought the project down.
In the winter of 1995 we got a mandate that the first Copland beta would be made available for the May 1996 World Wide Developers' Conference.
That winter two of the major tasks that were being handled were to bring in the new file system and the new I/O system, replacing the original Copland, hastily built, prototype systems. For the purposes of that build, Copland could be split into 4 major pieces: file system, I/O subsystem, kernel and higher level functionality.
We produced set of glue code such that either file system or I/O subsystem could be used together, allowing the new I/O subsystem to be tested without alterations to the rest of the system and the new file system to be tested with the old I/O subsystem.
In January of 1996, as we were approaching the end of that build cycle, the kernel team decided that they really, really, needed to change a bunch of API's that would break just about everything. At this point, a strong management decision would have been "WAIT - those changes can go into the next build, AFTER the I/O subsystem and file system have been tested". Instead, the kernel changes were allowed to proceed. At this point everything in the system was broken. Upgrading the old I/O subsystem to work with the new kernel API's was a huge amount of work so the ability to test the new file system against the old I/O subsystem was lost. Now, the entire system had to be tested together with every component in flux. Needless to say, the integration process for this build took forever and was probably the first death blow for the project.
As WWDC approached, we expected that pressure would be brought from management to make the deadline. Instead, as the time for all-nighters with free pizza came up in about March management looked at the schedule and decided that it could not be met. Having told everyone previously if this deadline was missed the company would be in deep doo-doo, management credibility went out the window. The number of late nighters (already not enough for a project so far behind schedule) dropped precipitously. This was the second death blow to the project.
Over the summer of 1996 we were very close to having the developer release ready. A senior engineer and tech lead had been on sabbatical and doing some serious thinking and came back with a paper that cast serious doubts on the approach that Copland was taking to emulating the Mac OS System 7 environment.
Classic Mac OS is more of a library than an operating system in that all of the operating system's data structures are in the same address as applications. Copland's approach to Classic Mac OS compatibility was to emulate EVERYTHING, including internal data structures that applications might use. For example, in Classic Mac OS there is a linked list (can't remember the name of the damned thing right now) of data structures for all of the open files. Applications would walk this list to find out who else had files open. In the Copland emulation environment the Copland file system would generate events for the emulation layer so that the emulation layer could keep this list current!
This approach was causing serious problems. The mandate from marketing was that 99% of applications had to run, warts and all and this was proving to be strictly impossible. The emphasis on providing an emulation layer had bushwhacked the "new api" such that there really wasn't much available to write apps that took advantage of the multi-tasking and memory protection that the OS provided. The paper written seriously critiqued this approach.
Unfortunately as this paper made its way up the management chain to people who did not really understand what it was talking about, the entire project began to be regarded as failed.
Copland had a number of technical failings, one of its
It's not a troll - that article was written at a 9th grade level at best. I read the whole thing looking for something interesting and there wasn't.
You're correct. However, they did not patent the procedures needed to buy an automobile. They just mentioned it as a possible use.
For this to be a reasonable patent, rather than a crap patent, they needed to actually document all of the steps that they go through for the calculations, etc. to sell an automobile in detail. This patent would be much narrower in scope as if you had a significantly different method than theirs you would be allowed to sell automobiles. The problem with this patent is that the functionality patented is trivial and hence incredibly broad.
How do you think the missiles got to their silos?
A PHB knows nothing in terms of game development or game life cycles in general and is almost always a huge waste of time and resources. What area of expertise does a PHB have that could help in this decision?
Precisely! The complete lack of understanding allows them to make a decision that has no right answer. Of course, a Magic 8 ball or coin toss would be about as useful as well....
Pedantic authoritative written material:
should of noticed
should have noticed (notice that this is grammatical and makes sense. "Should of noticed" makes no sense and is a result of listening to people who do not enunciate)
authoratitive written material
authoritative written material
Yah, all except the PRICE! $149 > $100
The amount of effort required to make your own engine block from scratch (starting with raw steel but with the plans) is probably less that the amount of effort involved in calculating GE's quarterly results with paper and pencil.
This was actually the plan back around 1995. Apple and IBM were working on something called "CHRP" (Common Hardware Reference Platform) which was to be a design spec for a computer that could run MacOS (System 7 at the time, but moving to System 8 (the real System 8, Copland!) soon after), OS/2, AIX and Windows NT.
You may recall that at around this time, Intel entered the motherboard market and for a short time kicked the Taiwanese out on their butts. Hence, the Taiwanese were looking seriously at building CHRP motherboards and systems. Had Apple completed the spec on time and gotten it out there, things might have been quite different.
As it happened, internal politics killed CHRP inside Apple, IBM got tired of the nonsense and Microsoft put a bullet into the head of NT/PPC.
And if their business partners are being fucked, then they should stop being partners with Microsoft.
Unfortunately it's pretty hard to stop being a partner with Microsoft once you're in bed with the elephant.
I attended the first CIFS (the file sharing protocol formerly known as SMB) conference when I was working for Apple. Everyone else in the room was some form of Microsoft partner. A lot of them were smaller vendors that had tied themselves into one part of Microsoft's networking or another. Again and again during the course of the presentations Microsoft told these folks, "Oh and here's how we're changing things to screw you up." I witnessed a lot of un-nice comments coming from the other participants but I doubt any of them quit working with Microsoft.
Thin of it this way - we ship petroleum around in ships that float on top of the ocean. I think there'a lot more water than we could possibly put in use as a fuel (also, don't forget that as soon as you burn it/run it through a fuel cell the hydrogen recombines with oxygen and forms water again)
In my opinion, he could have stopped the car much earlier, but was panicked. To those who say he should have had no problem removing the smart card, try doing that while controlling a car at 120 mph on a non-empty highway (at one point, he had to overtake a truck by driving on the emergency lane!).
:-) ). If the vehicle had had more horsepower and I had started out-accelerating other traffic and needed to steer around them I could have easily not had the presence of mind to handle the situation. You do not immediately think of turning the engine off while you're driving. It's just something you never do.
I had a situation like this when I was in college driving my old '77 Datsun pickup (this was in 1985 or '86). No electronics in that puppy, but the linkage that increased the idle revs when the air conditioner was on (air conditioner was long dead by the time I had this truck) broke, fell down and stuck the throttle on at full blast as I was going down the freeway.
Of coure, this being a '77 Datsun pickup, I think I topped out at less than 80 MPH but it was not a fun feeling. It took me a minute or so to figure out that I could drop into neutral (manual transmission) and turn the engine off (no power steering on that baby either