IMO: the recording industry paid Apple to be the heavy here. Apple needs the recording industry. This was just a classic corporate black-bag job.... Someone has to man the gallows... this time it was Steveo's turn.
On the other hand.... Apple may have been trying to get into to streaming and the recording industry told them NO!
Seems like this might lead to a higher density computational framework. How about some computational LEGO bricks?
We know from Apple's example(s) that a functional system will fit into a very small form factor, and consume minimal power, even while running flat-out.
IIRC: The iPod Touch G3 is running a 600MHz A8 can run flat-out for 3 - 6 hours on ~1200mAH (~4.44W) battery without getting particularly warm. (unlike a MacBook(pro)) I could see a 4 - 8 watt budget being reasonable for a complete 1 - 2 GHz ARM server-brick, with 4GB of memory and a 80GB FLASH drive in the chassis. SDHC/MMC for kernel image and app storage?
With a reasonable "brick" design it should be possible to stack a lot of these systems into a very compact space and add a few channels of GigE or, 4-way-LVDS links, with GigE bridges at the edges of the array. Power would also be provided at the edges of the array.
With a decent cabinet design clusters could be convection cooled. Cost per unit might be spectacularly low if the input power is 3.7 - 12 VDC.
If the brick-to-brick mesh interconnect is fast enough, who cares if the local storage is limited to 32b addresses?
2.5" or 3.5" form factor?
Need more mass storage? Notice that modern hard-drives don't have full size controller boards anymore? Put the computational unit in the other half of the drive-controller foot-print.
Now.... how are ya gonna program this? IMO: The compiler geeks need to get off their collective duffs and figure out a C-like language that parallelizes well... without shared memory. Maybe something similar to XMOS XC?
It's not uncommon for PVT and DVT units to be assembled with poor quality 'proofs' of the cases. Since they are for internal use no one cares what the silkscreens look like.... or even fit and finish. Devs and EEs get shitty looking ones.
1) The device Gizmoto got their paws on is either a DVT or PVT device. Having worked for Apple years ago, I can tell you with some certainty that the device depicted in the photos is either a development prototype or a production prototype. (In one of the teardown photos I am very sure a PVT/DVT sticker is visible on the battery.)
2) The unit was probably removed from the lab it was being used in without authorization. 3) From the buzz floating around the story it seems that who ever liberated it then got drunk and lost track of it. 4) Someone lifted it. (finders keepers? or more sneakily?) 4a)The someone who lifted it passed it off to someone who knew it wasn't a released model. 4b) I think that some money may have changed hands at this point. 5) New 'owner' blogs about the phone after playing with it for a while. 6) Apple manages to brick the phone remotely. Not sure how long this took. 7) Gizmoto tracks down the new 'owner' and after getting some confirmation decides to buy the phone for $5K. 8) Gizmoto does a teardown piece and publishes it. 9) Gizmoto receives an email from Apple's General Council bluntly ordering them to hand over the device.
The clowns at Gizmoto are fuxed. So is the guy who sold it to them.... and maybe even the person who 'found' it at the bar. The (EX)employee who brought it to the bar is might face charges too.
Potential violations: a) Theft (CA State) b) Possession of stolen property (CA State) c) transfer of stolen property/Making stolen property available for sale (CA State) d) Transfer of stolen property across state lines (FED if it got sent to NY for examination) e) various violations of UTSA... (Civil - for publishing trade secrets)
The really stupid part of it is that the entire adventure is well documented in public.
Enjoy your blaze of glory guys... I'm sure they are gonna love ya reeel good in prison.
The latest showdown I read put the fastest HDDs a distant LAST in every category that matters for active storage devices versus SSD. So it makes sense that for cloud enterprise these drives even at high premiums are full of win in that market segment.
This is great for small runs with flexible designs. Large players can't hit their sweet spots, but small run designers can by designing layouts to support several different packaging footprints for passives. It requires a little fancy dancing to alter the design to keep up with available parts. The big guys can't do it.
It won't be flash. It will likely be a PCM or some variant of QF that does it. A film coating over lower density CMOS gates is simpler and potentially more reliable than Isolated Gate approaches. In much the same way that DRAM variants have relegated SRAM to specialized applications, FLASH is likely going to get replaced before too long. Decreasing the cell foot-print by using a more space efficient cell is usually more effective at reducing cost per bit than decreasing feature size.
Rethinking storage and memory tech is cheaper(in the long run) than shrinking feature size on an existing design.
By the same reasoning ARM is likely to hand Intel it's ass in a few more generations, on several critical specs.
Lucky bastard, obviously the peyote still grows wild and free in abundance down there. Although, given the hypothesis as put forth in the article, I sense there's a pipeline for good B.C. bud running down there too.
Psilocybe cubensis is readily available in that region as well.
Without the Kennedy imperative to get Apollo to the moon, integrated circuits would not have happened when they did. I'm sure it would have come later, but it would have been sitting in limbo for many years while corporate leaders navel-gazed the market potential....
Huge improvements in miniaturization just would not have had gotten the needed funding to drive them into commercialization. Apollo was the test case that early efforts needed to convince the investors that micro-electronics would be viable.
I think it would be fair to say that we'd probably still be on dial-up connections using 8/16 bit computers right now if it weren't for the drive to create the first multi-gate ICs that made the control computer in the LLM possible.
I take it the "Clippy Bit" you are referring to was the RESET#/NMI# switch button plastics.
For the record you might want to know that the plastic chunk you seem to be referring to was INCLUDED with every mac model that shipped with that feature. It was removable so that the gum-chewing, over enthusiastic 12 year-old in the office -- with more curiosity than sense -- couldn't walk up to your machine, and pull a "Oh, what does THAT *Poke* do?" Thus rebooting your machine or throwing it into the MacsBug debugger. No sensible Mac User installed in on ANY mac that supported it unless they were developing software.. It was too easy to bump it with a coffee mug or have desk-clutter fall against it.
That many people lost the clippy bit, broke it, or never installed it is a very different issue. It was only useful for programming and debugging. By the time MacOS 6 (1987) came out the developer tools were free (as in beer) if you downloaded the disk images from Apple's servers, or available for cost of 'crunchy-disks' & 'Dead Trees' if you wanted to get a more tangible experience.
The serial port WAS standard it just wasn't RS-232... it was RS-422.... which could support longer cables and higher data rates (than vanilla RS-232) AND AppleTalk at up to 256Kbps. More enterprising developers found they could get RS-422 to run at up to 1 Mb by using better cables. The firmware supported this. Adapting it to RS-232 was trivial.
The case was locked down due to safety issues.... it had deadly voltages running on the Analog Board. UL and other standards bodies would not have allowed Apple to sell it if it wasn't closed up tight. It was built like a consumer television because it was MANDATED to be built that way. If one didn't follow proper safety procedures, poking around in the "compact" Macs could send the dabbler to the hospital or the morgue, or burn their house down.
Granted, the mouse, keyboard and floppy-drive ports were proprietary(at first), but that was a sensible restriction in the early days, since Apple didn't have a game plan yet for opening up the platform. They did not forget their Apple// heritage.... they learned from it. Apple also got a great object lesson from watching IBM get it's ass handed to it by the clone markets. (A lesson Spindler forgot when he licensed the platform.... which almost killed Apple.)
Closed platform, my ass... the schematics and theory of operation documents for the early Macs were available on Apple's websites as soon as the developer tools were released, and made available for every mac that was released subsequently.
So far I see nothing different in the iPod/iPhone ecology. Apple is carefully scripting the exposure of the platform innards as they see a way to do it without getting painted into a corner.
That Job's is not afraid of rattle cages, and busting a few heads (that needed busting, IMO) makes things interesting....
The big lesson here, is that if you don't have a clear path to open aspects of your platform to 3rd party development, DO NOT OPEN THEM! Ignoring that lesson will get the platform PWND by developers that don't give a shit about pissing in the pool for a short term gain. Apple has been screwed by that dynamic before, on both the Mac and Apple// platforms; by large and small developers; through ignorance and/or caprice. I do not fault Apple for being cautious with their platforms, they have been burned by being too open before, and some companies, like IBM, have lost entire markets due to being too open.
As a developer, or user, you are not responsible for the the gestalt economics of Apple's platforms, but Apple is responsible for every product that rides on their platforms. They are the ones that will be punished by the market if some asshat leaves a floater in their pool to make a few quick bucks.
Exercise for the/. crowd: Compare and contrast Apple with Sony, Nintendo, and Microsoft-XBox.... or even Atari...
A straight-forward solver (no heuristics) will not find a single tour in thousands of hours of searching, even if it's code is highly optimized. However if you code in a simple heuristic,(Warnsdorff's rule) even a bone-headed implementation will easily find thousands of solutions per second on a single (100MHz) CPU. To be fair, finding all possible solutions (open and closed) to the problem, took a very large and fast MPP well over a month.
Ah well.... maybe I'll try to write a solver that runs on a GPU to get a solution set that doesn't require a bazillion dollars of hardware and millions of watt hours of energy to generate.
This material has a tunable band-gap by using different combinations and ratios of S, Pb, Cu, Ti, Cd, Hg, Te, Ag, etc. Silicon sensors and their exotic equivalents have fixed, and very limited band-gaps. Additionally silicon based sensors have a rather limited quantum efficiency which is about 40% to 50% efficient under idea configurations. CMOS imagers are anything but idea configurations.
OmniVision's innovation of using BSI didn't increase their efficiency to 80%, it reduced the number of photons absorbed by interfering metalization. area over front-side illuminated solutions... under ideal conditions. This is where the 40% - 50% efficiency numbers come from, and they cannot say so with a straight face because the trenching around the sensor's pixels reduced the coverage over the array... increasing the gaps between pixels.
With this new material they get increased conversion efficiency from the material and increased active area within the pixel with the first-surface configuration. (the metal area is hidden under the photo-sensitve layer, with no trenching. With the tunable band-gap they also get to target IR solutions with sensitivity to wave lengths >1000nm. Si can't do that at all. With other tunings they get improved visible light sensitivity.
While the material is far more toxic than silicon-only solutions, it is a lot cheaper to deposit. Don't eat the film and you should be fine:)
This stinks.. He was apparently convicted for not collapsing into an unconscious heap of flesh when he was repeatedly punched by a sworn officer.
On a personal note: I found myself in a similar predicament with a city cop once.... I found it useful to feign unconsciousness when struck. I was not arrested in the end. Though without financial resources I was unable to bring suit against the officer or the city even though there were plenty of witnesses around for me to call upon.
That I was not shot or incarcerated seems like a bonus now... live and learn.
Slashdot Mirror
War is hell.
People get hurt... and when they get hurt enough they take up torches and pitchforks. It is now just a matter of time.
Notice Steve is not doing much to stop end users from hackintoshing.... he only went after commercialized solutions...
I'm visualizing a set of Russian nesting dolls.... why is that?
Your itunes capable friends might appreciate you at Christmas?.... Just a thought.
if I had mod points you'd get one. Thank you for this opinion. :D
MPAA has not given up on DRM yet.
RIAA did. End of story.
IMO: the recording industry paid Apple to be the heavy here. Apple needs the recording industry. This was just a classic corporate black-bag job.... Someone has to man the gallows... this time it was Steveo's turn.
On the other hand.... Apple may have been trying to get into to streaming and the recording industry told them NO!
YMMV.
Seems like this might lead to a higher density computational framework.
How about some computational LEGO bricks?
We know from Apple's example(s) that a functional system will fit into a very small form factor, and
consume minimal power, even while running flat-out.
IIRC: The iPod Touch G3 is running a 600MHz A8 can run flat-out for 3 - 6 hours on
~1200mAH (~4.44W) battery without getting particularly warm. (unlike a MacBook(pro))
I could see a 4 - 8 watt budget being reasonable for a complete 1 - 2 GHz ARM server-brick,
with 4GB of memory and a 80GB FLASH drive in the chassis. SDHC/MMC for kernel image and app storage?
With a reasonable "brick" design it should be possible to stack a lot of these systems
into a very compact space and add a few channels of GigE or, 4-way-LVDS links,
with GigE bridges at the edges of the array. Power would also be provided at the edges
of the array.
With a decent cabinet design clusters could be convection cooled.
Cost per unit might be spectacularly low if the input power is 3.7 - 12 VDC.
If the brick-to-brick mesh interconnect is fast enough, who cares if the local storage is limited to 32b addresses?
2.5" or 3.5" form factor?
Need more mass storage? Notice that modern hard-drives don't have full size controller boards anymore?
Put the computational unit in the other half of the drive-controller foot-print.
Now.... how are ya gonna program this? IMO: The compiler geeks need to get off their collective duffs and
figure out a C-like language that parallelizes well... without shared memory. Maybe something similar to XMOS XC?
You are seriously bucking the group-think around here.... hence getting modded to hell.
Too bad.
FWIW: I agree with your assessment. I have been very happy with GoDaddy's service as well.
Gizmoto burned this guy to deflect attention away from their CPC violations, and off the clown who DID pinch it.
We only have hearsay that the party who took possession at the bar contacted Apple to return it.
It seems more likely that the engineer who screwed up called in to Apple ASAP and reported it missing.... hence the remote bricking...
There's a large credibility gap between the events at the bar, and the $5K that got it to Gizmoto's people.
It's not uncommon for PVT and DVT units to be assembled with poor quality 'proofs' of the cases. Since they are for internal use no one cares what the silkscreens look like.... or even fit and finish. Devs and EEs get shitty looking ones.
1) The device Gizmoto got their paws on is either a DVT or PVT device. Having worked for Apple years ago, I can tell you with some certainty that the device depicted in the photos is either a development prototype or a production prototype.
(In one of the teardown photos I am very sure a PVT/DVT sticker is visible on the battery.)
2) The unit was probably removed from the lab it was being used in without authorization.
3) From the buzz floating around the story it seems that who ever liberated it then got drunk and lost track of it.
4) Someone lifted it. (finders keepers? or more sneakily?)
4a)The someone who lifted it passed it off to someone who knew it wasn't a released model.
4b) I think that some money may have changed hands at this point.
5) New 'owner' blogs about the phone after playing with it for a while.
6) Apple manages to brick the phone remotely. Not sure how long this took.
7) Gizmoto tracks down the new 'owner' and after getting some confirmation decides to buy the phone for $5K.
8) Gizmoto does a teardown piece and publishes it.
9) Gizmoto receives an email from Apple's General Council bluntly ordering them to hand over the device.
The clowns at Gizmoto are fuxed. So is the guy who sold it to them.... and maybe even the person who 'found' it at the bar.
The (EX)employee who brought it to the bar is might face charges too.
Potential violations:
a) Theft (CA State)
b) Possession of stolen property (CA State)
c) transfer of stolen property/Making stolen property available for sale (CA State)
d) Transfer of stolen property across state lines (FED if it got sent to NY for examination)
e) various violations of UTSA... (Civil - for publishing trade secrets)
The really stupid part of it is that the entire adventure is well documented in public.
Enjoy your blaze of glory guys... I'm sure they are gonna love ya reeel good in prison.
The latest showdown I read put the fastest HDDs a distant LAST in every category that matters for active storage devices versus SSD. So it makes sense that for cloud enterprise these drives even at high premiums are full of win in that market segment.
This is great for small runs with flexible designs. Large players can't hit their sweet spots, but small run designers can by designing layouts to support several different packaging footprints for passives. It requires a little fancy dancing to alter the design to keep up with available parts. The big guys can't do it.
It won't be flash. It will likely be a PCM or some variant of QF that does it. A film coating over lower density CMOS gates is simpler and potentially more reliable than Isolated Gate approaches. In much the same way that DRAM variants have relegated SRAM to specialized applications, FLASH is likely going to get replaced before too long. Decreasing the cell foot-print by using a more space efficient cell is usually more effective at reducing cost per bit than decreasing feature size.
Rethinking storage and memory tech is cheaper(in the long run) than shrinking feature size on an existing design.
By the same reasoning ARM is likely to hand Intel it's ass in a few more generations, on several critical specs.
Maybe subconsciously you are steering your custies towards HDDs because your margins are better on those than SSD?
Part of what $5.6bln in bonuses buys Goldman is a lot of foot-soldiers willing to take one for the team, if needs be....
Lucky bastard, obviously the peyote still grows wild and free in abundance down there. Although, given the hypothesis as put forth in the article, I sense there's a pipeline for good B.C. bud running down there too.
Psilocybe cubensis is readily available in that region as well.
Parent makes a really good point.
Without the Kennedy imperative to get Apollo to the moon, integrated circuits would not have happened when they did. I'm sure it would have come later, but it would have been sitting in limbo for many years while corporate leaders navel-gazed the market potential....
Huge improvements in miniaturization just would not have had gotten the needed funding to drive them into commercialization. Apollo was the test case that early efforts needed to convince the investors that micro-electronics would be viable.
I think it would be fair to say that we'd probably still be on dial-up connections using 8/16 bit computers right now if it weren't for the drive to create the first multi-gate ICs that made the control computer in the LLM possible.
I take it the "Clippy Bit" you are referring to was the RESET#/NMI# switch button plastics.
For the record you might want to know that the plastic chunk you seem to be referring to was INCLUDED with every mac model that shipped with that feature. It was removable so that the gum-chewing, over enthusiastic 12 year-old in the office -- with more curiosity than sense -- couldn't walk up to your machine, and pull a "Oh, what does THAT *Poke* do?" Thus rebooting your machine or throwing it into the MacsBug debugger. No sensible Mac User installed in on ANY mac that supported it unless they were developing software.. It was too easy to bump it with a coffee mug or have desk-clutter fall against it.
That many people lost the clippy bit, broke it, or never installed it is a very different issue. It was only useful for programming and debugging. By the time MacOS 6 (1987) came out the developer tools were free (as in beer) if you downloaded the disk images from Apple's servers, or available for cost of 'crunchy-disks' & 'Dead Trees' if you wanted to get a more tangible experience.
The serial port WAS standard it just wasn't RS-232... it was RS-422.... which could support longer cables and higher data rates (than vanilla RS-232) AND AppleTalk at up to 256Kbps. More enterprising developers found they could get RS-422 to run at up to 1 Mb by using better cables. The firmware supported this. Adapting it to RS-232 was trivial.
The case was locked down due to safety issues.... it had deadly voltages running on the Analog Board. UL and other standards bodies would not have allowed Apple to sell it if it wasn't closed up tight. It was built like a consumer television because it was MANDATED to be built that way. If one didn't follow proper safety procedures, poking around in the "compact" Macs could send the dabbler to the hospital or the morgue, or burn their house down.
Granted, the mouse, keyboard and floppy-drive ports were proprietary(at first), but that was a sensible restriction in the early days, since Apple didn't have a game plan yet for opening up the platform. They did not forget their Apple // heritage.... they learned from it. Apple also got a great object lesson from watching IBM get it's ass handed to it by the clone markets. (A lesson Spindler forgot when he licensed the platform.... which almost killed Apple.)
Closed platform, my ass... the schematics and theory of operation documents for the early Macs were available on Apple's websites as soon as the developer tools were released, and made available for every mac that was released subsequently.
So far I see nothing different in the iPod/iPhone ecology. Apple is carefully scripting the exposure of the platform innards as they see a way to do it without getting painted into a corner.
That Job's is not afraid of rattle cages, and busting a few heads (that needed busting, IMO) makes things interesting....
The big lesson here, is that if you don't have a clear path to open aspects of your platform to 3rd party development, DO NOT OPEN THEM! Ignoring that lesson will get the platform PWND by developers that don't give a shit about pissing in the pool for a short term gain. Apple has been screwed by that dynamic before, on both the Mac and Apple // platforms; by large and small developers; through ignorance and/or caprice. I do not fault Apple for being cautious with their platforms, they have been burned by being too open before, and some companies, like IBM, have lost entire markets due to being too open.
As a developer, or user, you are not responsible for the the gestalt economics of Apple's platforms, but Apple is responsible for every product that rides on their platforms. They are the ones that will be punished by the market if some asshat leaves a floater in their pool to make a few quick bucks.
Exercise for the /. crowd:
Compare and contrast Apple with Sony, Nintendo, and Microsoft-XBox.... or even Atari...
Ah tilting at windmills.
Years ago, I spent a lot of time working on the Knight's Tour problem. http://en.wikipedia.org/wiki/Knight's_tour
A straight-forward solver (no heuristics) will not find a single tour in thousands of hours of searching, even if it's code is highly optimized. However if you code in a simple heuristic,(Warnsdorff's rule) even a bone-headed implementation will easily find thousands of solutions per second on a single (100MHz) CPU. To be fair, finding all possible solutions (open and closed) to the problem, took a very large and fast MPP well over a month.
Ah well.... maybe I'll try to write a solver that runs on a GPU to get a solution set that doesn't require a bazillion dollars of hardware and millions of watt hours of energy to generate.
WOOSH!.... it was a Han solo paraphrase.... lighten up.
Who dat?
Who dat who say, "Who dat?"
Who dat who say, "Who dat?" when I say, "Who dat?"
This material has a tunable band-gap by using different combinations and ratios of S, Pb, Cu, Ti, Cd, Hg, Te, Ag, etc. Silicon sensors and their exotic equivalents have fixed, and very limited band-gaps. Additionally silicon based sensors have a rather limited quantum efficiency which is about 40% to 50% efficient under idea configurations. CMOS imagers are anything but idea configurations.
OmniVision's innovation of using BSI didn't increase their efficiency to 80%, it reduced the number of photons absorbed by interfering metalization. area over front-side illuminated solutions... under ideal conditions. This is where the 40% - 50% efficiency numbers come from, and they cannot say so with a straight face because the trenching around the sensor's pixels reduced the coverage over the array... increasing the gaps between pixels.
With this new material they get increased conversion efficiency from the material and increased active area within the pixel with the first-surface configuration. (the metal area is hidden under the photo-sensitve layer, with no trenching. With the tunable band-gap they also get to target IR solutions with sensitivity to wave lengths >1000nm. Si can't do that at all. With other tunings they get improved visible light sensitivity.
While the material is far more toxic than silicon-only solutions, it is a lot cheaper to deposit. Don't eat the film and you should be fine :)
This stinks.. He was apparently convicted for not collapsing into an unconscious heap of flesh when he was repeatedly punched by a sworn officer.
On a personal note: I found myself in a similar predicament with a city cop once.... I found it useful to feign unconsciousness when struck. I was not arrested in the end. Though without financial resources I was unable to bring suit against the officer or the city even though there were plenty of witnesses around for me to call upon.
That I was not shot or incarcerated seems like a bonus now... live and learn.