Neither of the reasons you give justify anything close to 50% of CPU usage on a system within iTunes' minimum requirements and there's no reason to really continuously poll given that Windows can raise events when a device is attached anyway.
The figure cited in the blog was 26% CPU utilization, with a bazillion threads (no specific number give, but given that 4 cores on an 8 core machine were used, it couldn't have been that many.
The problem the service has is that it has a single work loop in order to manage events from a lot of disparate locations, and when it gets an event, it checks all possible people who want to do work. In this case, it's a timer event to go poll to see if an iDevice has been installed, and that causes a bunch of other stuff to run at an earlier time than it would have.
This is an artifact of the implementation using a GCD (Grand Central Dispatch) based design on top of BlueBox, which is an API layer that makes a Windows box look like a Carbon API (it hasn't been totally updated yet) Mac OS X box. The upper level software is designed for device arrival notification, rather than having a timer to kludge around the issue by forcing the polling.
Yeah, this does mean that you could effectively port any Mac OS X program to Windows by recompiling it, if Apple were to make the technology available, which they likely never will.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage().
AddDevice routine is used by device drivers to be notified when their device arrives at the bus (e.g. an USB bus).
Insufficient. I don't WANT to have to install a damn device driver to handle a general class of devices. This is the Microsoft model, and it is flawed. I want to write a program in userspace which gets notified when devices arrive, and then it goes out and sniffs their butt to see if it's a device I can claim, and if it is, then I claim it by opening it as a raw USB device and handle the device specific communications protocols in userspace. This is the Mac OS X / Linux / BSD model.
The benefits of this model over the model Microsoft wants us to use is that it allows us to deal with classes of devices without writing a new driver for the device -- or in this case, since we want to start a user space program, a new service for the device.
Conceptually, I suppose it's possible to build a Rube-Goldberg contraption that would consist of a device driver that used the mechanism you suggest, a service in userspace to talk to the Rube-Goldberg contraption, and then launch the application based on it being a device it recognized. That just trades unknown GUIDs for unknown vendor IDs, if not both them and device IDs as well.
Then we are left with replicating the Microsoft USB class driver functionality in its entirety, since the device will have been claimed by our USB driver, and that is the driver our service and application will end up having to talk to.
The notifications need to be able to go to windowless services.
Yes, agree. But they can. It is right there in the documentation.
But now we are back in the same boat of having to install new software - it's just a device driver, instead of a service. Or we can access a vendor/device ID table from the registry - but again, this new table has to be installed for the device to be used.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
That's the thing with GUIDs: It is perfectly safe to choose them during *development*. Generating a guid for a device or an event virtually guarantees that no other device or event will use the same ID. The main problem with GUIDs is that such "well-known" guids needs to be documented. But if Apple writes the device driver that broadcasts the event, surely they can find a way to use the clipboard and use the same GUID during notification registration.
This is the part that's insufficient about GUIDs: if I have a per-device GUID during device development, then I have to put it in the table somewhere, and that's an installation step before I can use the new device.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
I wasn't aware that they are eating CPU like iTunes. Citation?
iTunes is a pig when it polls, no question; PhoneTools and other software is less of a pig, but the main complaint of the OP was that it'
(3) The Windows APIs for device arrival notification suck and require polling rather than blocking a thread to wait
Thanks so much for sharing your knowledge. I'll call up our software engineers immediately and let them know that processing a DBT_DEVICEARRIVAL message in the message pump, or using RegisterDeviceNotification() in our service, can't possibly work and we should re-write those sections of code to poll for device change.
I have mod points, but there's no "-1 - ignorant" mod.
You do that.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage(). The notifications need to be able to go to windowless services. If they can't go to windowless services running and paused in the background, they are no good for causing the launching of a specific program when a device of a specific type arrives.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
Then call up the IronKey and other encrypted USB storage device folks and tell them about it, too, because, hey, they have to do a crypto handshake and need to be able to aske the same question AFTER the handshake.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
Then call the DataPilot folks, who have no idea in heck what the phone GUID would be when you plug in your stupid random phone, particularly if you are using their DataPilot Universal PRO Kit, which connect up to almost all the phones from Apple, Motorola, LG, Samsung, Sanyo, Sony Ericsson, and Audiovox.
I have more concrete examples, but I think you get the point.
This is a general problem. The current Microsoft APIs do not solve this general problem; they require either an open application window, or they require a service which polls. They are insufficient. If you can indeed call up your engineers, do so. Tell them the problem space their APIs are not solving, and request they fix the existing APIs or add new ones to address the problem.
Why is parent modded funny instead of informative?
It makes 3 good points:
(1) The periodic scanning is Apple looking for device arrivals (2) You can disable the service with no ill effects (3) The Windows APIs for device arrival notification suck and require polling rather than blocking a thread to wait
Memory latency. Beowulf clusters are good for things that are highly parallel *and* have a high degree of memory locality, ie. you rarely need to make memory calls between boxes.
True supercomputers use high-speed interconnects between systems for this reason, usually using something like Infiniband or a weird proprietary system, and usually with some network topology with numerous inter-system links. This gives them much lower latency when one system uses data in memory in another system.
True Supercomputers can solve non-highy-parallel problems.
I think you're giving them too much credit. The DHS, like the TSA, is a very stimulus-driven organism. More likely they discovered some suspicious activity was utilizing Dwolla with Bitcoin, and decided to break the link between the two. The intelligence community in the US generally avoids bad PR as long as possible.
Which is why the TSA is so beloved of us all, and why none of us cheered when Yukari Mihamae groped the TSA agent back...
Not trying to start a flame-war here, but I've been seeing a fair amount of strictly politics related postings here lately. Could anybody please explain to me how this is on topic for Slashdot?
I'm guessing the flashlight he had was a Google Firesword?
Yes, GITMO etc removes the moral high ground, but that doesn't change things like a difficult journalist getting assassinated as a present for Putin's birthday last year.
Actually GITMO is precisely to maintain the moral high ground by providing extraterritoriality. The extraterritoriality is what makes it safe from enforcement of US law, and makes the president and his underlings safe from accusations of violating US law by condoning events on its premises.
This is exactly why it has not been shut down, despite the campaign promises of several presidents, including Obama. Once sworn in, they get a thorough briefing on everything, which includes a little sit-down about GITMO with the White House General Council, after which it stays open to aboid personal criminal liability for the staff in the executive branch, up to and including the president.
I went to an awful lot of school to learn computer science. My shiny fancy degree got me an interview for a job. But guess what? None of the questions in the interview were answerable based on what I learned in school. I knew the answers because I wrote code for fun as a hobby, starting at the age of 15. But I knew the answers and got the job. And guess what? I have not used anything from school in the job. My job is all about the useful programming skills that I had to pick up to write fun little toy programs as a hobby.
There was an accreditation change in the mid 1980's that forced colleges to stop teaching programming languages directly, so instead of teaching C, they teach things like "database programming using C", and you're expected to pick the language up on your own, rather than as part of the curriculum. And yes, after that time, colleges started turning out people who practically could not program.
These days they teach "game programming in flash" for all those people who don't realize that Flash doesn't actually run on iPhones and think they will come up with the next great computer game. The Academy of Arts College in San Francisco is basically turning out a bunch of unemployable Flash programmers who couldn't program C to save their lives.
If you want a good education, you have to go to some place like Brown University, which provides self directed programs. You'll find these at the Ivy League schools, but a lot of universities or state colleges these days are basically diploma mills which arrange for you to spend 5 years there instead of 4 by choosing not to offer classes you would need to graduate when you are at that point in the program. The California State Universities are practically famous for that little trick.
"... give the the power to hack into computer systems..."
Why stop there?
They should also give them the power to leap tall buildings, x-ray vision, run faster than a speeding bullet. I mean if we are talking about legislating that they be able to do things they are innately incapable of doing, why just stop at the ability to hack?
And those content producers can either write their own damn browser plugin, or app for mobile devices.
The major problem with this stance, which is why it bothered me when RMS voiced it, is that we are increasingly moving towards thin client front ends with cloud back-ends in order to reduce front end costs. You can call this "the mainframe model", if you want a computing analogy, or "the POTS" model, if you want a communications analogy. The evolution of HTML has been strongly vectored in this direction, and continues to be vectored in this direction. The idea that plugins or apps are even supportable on the thinner and thinner client front end is becoming less realistic.
See this is WHY it's a problem. So let's say that I buy 2000$ worth of movies, music, ebooks from some BIG CONTENT provider, and then BIG CONTENT provider is bought by another one, and sells off the music business to some other content provider. Now when I visit their site or use their app I no longer have access to the music I already paid for.
THAT is the why DRM is bad and needs to go away.
This is not significantly different than when singles came out on 45RPM records, and you had to re-buy them on 33 1/3 RPM albums, and then re-buy them again on 8-Track tapes, and then re-buy them again on cassette tapes, and then re-buy them again on CDs.
What has changed with digital, and to be honest, for the music industry, it changed with the CD format, is that the medium on which the digital data is stored is fungible, which means the end of re-buying.
The music industry fought this in a number of ways, and we can easily see that: the DAT standard was perverted to ensure the recording frequency was at a beat frequency of the CD recording frequency to prevent non-buffered direct digital copying from CD to DAT being playable at the original recording frequency without artifacts, there was a Canadian DAT tax, and they were initially successful in causing DRM use on iTunes, but eventually unsuccessful, since CDN requirements meant that DRM had to be handled on equipment under the end-user's control.
The movie industry has been following this same trajectory, with the difference that they got into the game much later. Just as the music industry fought first the 8-Track, and later the cassette, the video industry fought consumer-recordable media in the form of VCRs. They are currently in the midst of attempting to go down the DRM path with Blu-Ray, which is having a difficult time, since forced firmware updates by new Blu-Ray DVDs coupled with running their code on your hardware to decode their content, which is how Blu-Ray DRM works, still has a lot of technical issues that are practically unfixable. On the network connected front, they are attempting to DRM the content streams, and, again, using client-side software under their control, decode the content only for playback.
Having a standard DRM mechanism in HTML5 dooms this effort to ultimate failure in the long term, even if you dislike the short term consequences. By disallowing the plug-in model, at some point, when (not if) the particular DRM is broken, it will be Game Over, just as it was for the music industry. And like the music industry, the movie industry will survive this event.
What is eventually dead, in this scenario, is the re-buy model that the music industry used to rely upon, and which the movie industry is still desperately trying to keep in place, even as the tent they are attempting to prop up turns to chewing gum around them.
If we take RMS' (and your) position, with proprietary plugins, this does two damaging things: (1) it litters the universe with incompatible plugins and transcoded content which is not portable, even should the DRM of a particular plugin be broken, and (2) it deflects the HTML vector from its eventual destination, good or bad (but without corresponding DRM required on the server side, there's no reason you couldn't run your own clo
So... what's the firmware? No need to keep it a secret.
The firmware which has been developed in house by each of these companies, and which is not available because the WNIC vendors would have to submit the firmware and hardware as a unit to the FCC for certification as an SDR (Software Defined Radio). As such, it would be a violation of both the WNIC vendor license agreements and the FCC regulations were it to be distributed. The first loses you your relationship with the WNIC vendor, the second gets you fined at best and thrown in Federal Prison at worst.
If you want to work with this code at Google, go to work for Google and join the Chrome OS networking team. I don't have the contact information for the appropriate teams at the other companies I'm sure are doing similar work. I'm going to guess there are more than six of them, but I will also guess that they are working under the same constraints, and I only know of six from having been aware of a connectathon having been held.
Google has zero control ver Android-based product productization. All those decisions are made by the device vendor during the final productization phase by the partner (read: device vendor). This is also why there are so many versions of Android out there; each device has its own Android variant based on the exact state of the source tree at the time they did a local replica in order to start the productization phase.
If Google moved productization in-house, they could cause a more uniform environment for specific release versions, but this would not control UI differences or configuration file differences or feature differences instituted by the partner.
Nor could they force a partner to update the version of Android running on their devices. Once fielded, this would require carrier recertification of the devices before it could be deployed, and it is against the partners best interests to update devices, as that would cannibalize sales of new devices.
Ad Hoc is against the carriers best interests, since the alternative is to charge you SMS charges instead, and it's against the partners best interestes to enable UI for it, since they sell through the carriers, and the carriers do not want it enabled.
So basically you are attempting the Sisyphean task of fighting both the carriers, and their thralls, the partners, and you are holding an uninvolved third party responsible for not doing your job for you.
Congratulations, now go make^H^H^H^Hlose a billion $$$!
Safeway is starting to offer this as a service; however, like WebVan, they reserve the right to substitute "equivalent" goods when they feel it's necessary.
Unless you click the "no substitutions" box on their web site. That wasn't so hard, now was it.
It's not an account option (I checked). It is a checkout option.
Seriously? You expect them to mine their databases so as to stop marketing peanut products to you? Where the fuck is the monetary incentive in that?
I don't sue them for killing my kid when I, as an informed engineer, can demonstrate their negligence. Likely they will not want this out, so they will want to settle, but me being out a kid, will not want a gag order and will start chanting "Class Action, Class Action!".
They've probably *already* injured someone who has not considered that there was data available and that their willful ignorance made them negligent.
This problem is more or less solved already. It can be done through ad hoc mesh networking, and there is firmware that can be used on Atheros and several other vendors chips.
The problem with deploying any of this is that the ability to do this with civilian devices disintermediates the cell phone user from the cell network providers. So there are huge buckets of money which Do No Want This Firmware Available Anywhere. Deploy it, and you mostly do not need cellular carriers, unless you need lower-than-voice-acceptable latency on your network for higher speed data (e.g. multiplayer video games).
The half a dozen companies that can already do this include Google; I used to sit about 200 feet from the office of the primary researcher.
Safeway does not suck as much as WebVan did, but they still suck.
To address your first point: According to their EDGAR filings, there are both distribution center and non-distribution center (store-based delivery).
For store-based delivery, according to the FAQ on their web site, they will offer control of substitutions at checkout. This assumes that their electronic inventory exactly matches their store inventory, and the items get instantly and magically pulled. If an in-store shopper grabs it before the person going around grabbing the stuff gets there, they substitute.
Now you are allowed to return a substituted item at no charge, but until you do, the cookies are sitting there for your kid to find. This is a highly imperfect system, and that hole leaves room for the problem.
There is also the possibility of overcommit for brand items, and there is the possibility of dishonesty. Admittedly, these likely apply to items such as toilet paper, but seriously, if you are out of toilet paper, and the choice is between the 1-ply store brand that's there, and the 3-ply Northern that's not there, or your hands, you are going to make the store brand container non-returnable by opening it.
Safeway seems to have learned some lessons from WebVan, but I would have to say, of the available lessons to be learned, they educated themselves on perhaps 10% of them.
So all in all, yeah, if you think not getting in a car for a 5 minute drive there and back is worth being grounded to your house for a 1 hour delivery window, and you think that and the marginal environmental savings are worth $9.95 a delivery (this is the per delivery charge, also according to their web site), then knock yourself out. Just make sure you check for post-checkout substitutions containing allergens.
Congratulations, now go make^H^H^H^Hlose a billion $$$!
Safeway is starting to offer this as a service; however, like WebVan, they reserve the right to substitute "equivalent" goods when they feel it's necessary.
When WebVan did that, we ended up with something with peanut oil in it instead of canola oil, which it's lucky we caught, or someone could have died.
When Safeway does it, it's going to be replacing name brands with Safeway brands, and it is more or less *always* be necessary, since they are sending the vans from the distribution center, which only stocks a few name brands. Toilet tissue? You get Safeway. Kleenex? You get Safeway tissue.
The asinine thing is that Safeway *already* does not use the frequency marketing card data to datamine it and say to themselves "Hmmmm... this card never buys anything containing peanuts, and hasn't for 10 years; let's flag them so that if they accidentally get something that has peanuts in it, they get an 'are you sure?' at the checkout". This despite the databases they already have on product ingredients and everything the card has *ever* been used to buy make this type of mining *trivial*.
Instead, the assholes print out $0.50 off coupons for exactly the products that we've been avoiding for 10 years, every time we buy an "equivalent" non-store brand version of the item. Of course it's cleverly based on the fact that on our next trip we are likely to be picking up one of the "equivalent" products that don't contain what amounts to rat poison, or might as well, for the allergic person.
How can you possibly maintain the following train of thought?
(1) "I think renaissance faire people are geeks" (2) "I think slashdot people are geeks" (3) "these groups form an equivalence set" (4) "ask slashdot how to market to geeks" (5) "slashdot tells me" (6) "market to geeks" (7) "reach the renaissance faire target market" (8) "Profit!"
Seriously, I hope that the OP doesn't think that geeks form a monolithic market block, any more than Anonymous all hold the same political positions on everything.
Slashdot Mirror
"The reason is two-fold."
Neither of the reasons you give justify anything close to 50% of CPU usage on a system within iTunes' minimum requirements and there's no reason to really continuously poll given that Windows can raise events when a device is attached anyway.
The figure cited in the blog was 26% CPU utilization, with a bazillion threads (no specific number give, but given that 4 cores on an 8 core machine were used, it couldn't have been that many.
The problem the service has is that it has a single work loop in order to manage events from a lot of disparate locations, and when it gets an event, it checks all possible people who want to do work. In this case, it's a timer event to go poll to see if an iDevice has been installed, and that causes a bunch of other stuff to run at an earlier time than it would have.
This is an artifact of the implementation using a GCD (Grand Central Dispatch) based design on top of BlueBox, which is an API layer that makes a Windows box look like a Carbon API (it hasn't been totally updated yet) Mac OS X box. The upper level software is designed for device arrival notification, rather than having a timer to kludge around the issue by forcing the polling.
Yeah, this does mean that you could effectively port any Mac OS X program to Windows by recompiling it, if Apple were to make the technology available, which they likely never will.
You do that.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage().
AddDevice routine is used by device drivers to be notified when their device arrives at the bus (e.g. an USB bus).
Insufficient. I don't WANT to have to install a damn device driver to handle a general class of devices. This is the Microsoft model, and it is flawed. I want to write a program in userspace which gets notified when devices arrive, and then it goes out and sniffs their butt to see if it's a device I can claim, and if it is, then I claim it by opening it as a raw USB device and handle the device specific communications protocols in userspace. This is the Mac OS X / Linux / BSD model.
The benefits of this model over the model Microsoft wants us to use is that it allows us to deal with classes of devices without writing a new driver for the device -- or in this case, since we want to start a user space program, a new service for the device.
Conceptually, I suppose it's possible to build a Rube-Goldberg contraption that would consist of a device driver that used the mechanism you suggest, a service in userspace to talk to the Rube-Goldberg contraption, and then launch the application based on it being a device it recognized. That just trades unknown GUIDs for unknown vendor IDs, if not both them and device IDs as well.
Then we are left with replicating the Microsoft USB class driver functionality in its entirety, since the device will have been claimed by our USB driver, and that is the driver our service and application will end up having to talk to.
The notifications need to be able to go to windowless services.
Yes, agree. But they can. It is right there in the documentation.
But now we are back in the same boat of having to install new software - it's just a device driver, instead of a service. Or we can access a vendor/device ID table from the registry - but again, this new table has to be installed for the device to be used.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
That's the thing with GUIDs: It is perfectly safe to choose them during *development*. Generating a guid for a device or an event virtually guarantees that no other device or event will use the same ID. The main problem with GUIDs is that such "well-known" guids needs to be documented. But if Apple writes the device driver that broadcasts the event, surely they can find a way to use the clipboard and use the same GUID during notification registration.
This is the part that's insufficient about GUIDs: if I have a per-device GUID during device development, then I have to put it in the table somewhere, and that's an installation step before I can use the new device.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
I wasn't aware that they are eating CPU like iTunes. Citation?
iTunes is a pig when it polls, no question; PhoneTools and other software is less of a pig, but the main complaint of the OP was that it'
(3) The Windows APIs for device arrival notification suck and require polling rather than blocking a thread to wait
Thanks so much for sharing your knowledge. I'll call up our software engineers immediately and let them know that processing a DBT_DEVICEARRIVAL message in the message pump, or using RegisterDeviceNotification() in our service, can't possibly work and we should re-write those sections of code to poll for device change.
I have mod points, but there's no "-1 - ignorant" mod.
You do that.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage(). The notifications need to be able to go to windowless services. If they can't go to windowless services running and paused in the background, they are no good for causing the launching of a specific program when a device of a specific type arrives.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
Then call up the IronKey and other encrypted USB storage device folks and tell them about it, too, because, hey, they have to do a crypto handshake and need to be able to aske the same question AFTER the handshake.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
Then call the DataPilot folks, who have no idea in heck what the phone GUID would be when you plug in your stupid random phone, particularly if you are using their DataPilot Universal PRO Kit, which connect up to almost all the phones from Apple, Motorola, LG, Samsung, Sanyo,
Sony Ericsson, and Audiovox.
I have more concrete examples, but I think you get the point.
This is a general problem. The current Microsoft APIs do not solve this general problem; they require either an open application window, or they require a service which polls. They are insufficient. If you can indeed call up your engineers, do so. Tell them the problem space their APIs are not solving, and request they fix the existing APIs or add new ones to address the problem.
Why is parent modded funny instead of informative?
It makes 3 good points:
(1) The periodic scanning is Apple looking for device arrivals
(2) You can disable the service with no ill effects
(3) The Windows APIs for device arrival notification suck and require polling rather than blocking a thread to wait
Memory latency. Beowulf clusters are good for things that are highly parallel *and* have a high degree of memory locality, ie. you rarely need to make memory calls between boxes.
True supercomputers use high-speed interconnects between systems for this reason, usually using something like Infiniband or a weird proprietary system, and usually with some network topology with numerous inter-system links. This gives them much lower latency when one system uses data in memory in another system.
True Supercomputers can solve non-highy-parallel problems.
The wall got smacked in the 1980's.
I think you're giving them too much credit. The DHS, like the TSA, is a very stimulus-driven organism. More likely they discovered some suspicious activity was utilizing Dwolla with Bitcoin, and decided to break the link between the two. The intelligence community in the US generally avoids bad PR as long as possible.
Which is why the TSA is so beloved of us all, and why none of us cheered when Yukari Mihamae groped the TSA agent back...
http://www.huffingtonpost.com/2011/07/17/yukari-mihamae-61yearold-_n_900969.html
The only real surprise in that case is that you can't buy T-shirts with her face on it.
Not trying to start a flame-war here, but I've been seeing a fair amount of strictly politics related postings here lately. Could anybody please explain to me how this is on topic for Slashdot?
I'm guessing the flashlight he had was a Google Firesword?
Yes, GITMO etc removes the moral high ground, but that doesn't change things like a difficult journalist getting assassinated as a present for Putin's birthday last year.
Actually GITMO is precisely to maintain the moral high ground by providing extraterritoriality. The extraterritoriality is what makes it safe from enforcement of US law, and makes the president and his underlings safe from accusations of violating US law by condoning events on its premises.
This is exactly why it has not been shut down, despite the campaign promises of several presidents, including Obama. Once sworn in, they get a thorough briefing on everything, which includes a little sit-down about GITMO with the White House General Council, after which it stays open to aboid personal criminal liability for the staff in the executive branch, up to and including the president.
'generates an attractive cartoon face OR graphic of a user's facial image'
So it can either be attractive OR look like you.
The Samsung testing was in the LMDS frequency band, which the FCC has auctioned off already in the US to cable providers:
http://en.wikipedia.org/wiki/Local_Multipoint_Distribution_Service
The FCC has already licensed this band for satellite downlink:
http://spectrumwiki.com/wiki/display.aspx?From=disp&f=28499999999
Which means it can't be used for 5G in the US like they are doing with NTT DoCoMo in the Samsung experiments.
So upgrade the clients to version 8. Problem solved.
Or are we worried about updating the bitcoin clients we've installed on our criminally trespassing/theft of services botnets?
I went to an awful lot of school to learn computer science. My shiny fancy degree got me an interview for a job. But guess what? None of the questions in the interview were answerable based on what I learned in school. I knew the answers because I wrote code for fun as a hobby, starting at the age of 15. But I knew the answers and got the job. And guess what? I have not used anything from school in the job. My job is all about the useful programming skills that I had to pick up to write fun little toy programs as a hobby.
There was an accreditation change in the mid 1980's that forced colleges to stop teaching programming languages directly, so instead of teaching C, they teach things like "database programming using C", and you're expected to pick the language up on your own, rather than as part of the curriculum. And yes, after that time, colleges started turning out people who practically could not program.
These days they teach "game programming in flash" for all those people who don't realize that Flash doesn't actually run on iPhones and think they will come up with the next great computer game. The Academy of Arts College in San Francisco is basically turning out a bunch of unemployable Flash programmers who couldn't program C to save their lives.
If you want a good education, you have to go to some place like Brown University, which provides self directed programs. You'll find these at the Ivy League schools, but a lot of universities or state colleges these days are basically diploma mills which arrange for you to spend 5 years there instead of 4 by choosing not to offer classes you would need to graduate when you are at that point in the program. The California State Universities are practically famous for that little trick.
"... give the the power to hack into computer systems ..."
Why stop there?
They should also give them the power to leap tall buildings, x-ray vision, run faster than a speeding bullet. I mean if we are talking about legislating that they be able to do things they are innately incapable of doing, why just stop at the ability to hack?
And those content producers can either write their own damn browser plugin, or app for mobile devices.
The major problem with this stance, which is why it bothered me when RMS voiced it, is that we are increasingly moving towards thin client front ends with cloud back-ends in order to reduce front end costs. You can call this "the mainframe model", if you want a computing analogy, or "the POTS" model, if you want a communications analogy. The evolution of HTML has been strongly vectored in this direction, and continues to be vectored in this direction. The idea that plugins or apps are even supportable on the thinner and thinner client front end is becoming less realistic.
See this is WHY it's a problem. So let's say that I buy 2000$ worth of movies, music, ebooks from some BIG CONTENT provider, and then BIG CONTENT provider is bought by another one, and sells off the music business to some other content provider. Now when I visit their site or use their app I no longer have access to the music I already paid for.
THAT is the why DRM is bad and needs to go away.
This is not significantly different than when singles came out on 45RPM records, and you had to re-buy them on 33 1/3 RPM albums, and then re-buy them again on 8-Track tapes, and then re-buy them again on cassette tapes, and then re-buy them again on CDs.
What has changed with digital, and to be honest, for the music industry, it changed with the CD format, is that the medium on which the digital data is stored is fungible, which means the end of re-buying.
The music industry fought this in a number of ways, and we can easily see that: the DAT standard was perverted to ensure the recording frequency was at a beat frequency of the CD recording frequency to prevent non-buffered direct digital copying from CD to DAT being playable at the original recording frequency without artifacts, there was a Canadian DAT tax, and they were initially successful in causing DRM use on iTunes, but eventually unsuccessful, since CDN requirements meant that DRM had to be handled on equipment under the end-user's control.
The movie industry has been following this same trajectory, with the difference that they got into the game much later. Just as the music industry fought first the 8-Track, and later the cassette, the video industry fought consumer-recordable media in the form of VCRs. They are currently in the midst of attempting to go down the DRM path with Blu-Ray, which is having a difficult time, since forced firmware updates by new Blu-Ray DVDs coupled with running their code on your hardware to decode their content, which is how Blu-Ray DRM works, still has a lot of technical issues that are practically unfixable. On the network connected front, they are attempting to DRM the content streams, and, again, using client-side software under their control, decode the content only for playback.
Having a standard DRM mechanism in HTML5 dooms this effort to ultimate failure in the long term, even if you dislike the short term consequences. By disallowing the plug-in model, at some point, when (not if) the particular DRM is broken, it will be Game Over, just as it was for the music industry. And like the music industry, the movie industry will survive this event.
What is eventually dead, in this scenario, is the re-buy model that the music industry used to rely upon, and which the movie industry is still desperately trying to keep in place, even as the tent they are attempting to prop up turns to chewing gum around them.
If we take RMS' (and your) position, with proprietary plugins, this does two damaging things: (1) it litters the universe with incompatible plugins and transcoded content which is not portable, even should the DRM of a particular plugin be broken, and (2) it deflects the HTML vector from its eventual destination, good or bad (but without corresponding DRM required on the server side, there's no reason you couldn't run your own clo
So... what's the firmware? No need to keep it a secret.
The firmware which has been developed in house by each of these companies, and which is not available because the WNIC vendors would have to submit the firmware and hardware as a unit to the FCC for certification as an SDR (Software Defined Radio). As such, it would be a violation of both the WNIC vendor license agreements and the FCC regulations were it to be distributed. The first loses you your relationship with the WNIC vendor, the second gets you fined at best and thrown in Federal Prison at worst.
If you want to work with this code at Google, go to work for Google and join the Chrome OS networking team. I don't have the contact information for the appropriate teams at the other companies I'm sure are doing similar work. I'm going to guess there are more than six of them, but I will also guess that they are working under the same constraints, and I only know of six from having been aware of a connectathon having been held.
Google don't even want to enable ad-hoc wifi in Android... https://code.google.com/p/android/issues/detail?id=82 .. but it can be added if you are willing to install a modified cyanogenmod: http://www.thinktube.com/android-tech/46-android-wifi-ibss
Google has zero control ver Android-based product productization. All those decisions are made by the device vendor during the final productization phase by the partner (read: device vendor). This is also why there are so many versions of Android out there; each device has its own Android variant based on the exact state of the source tree at the time they did a local replica in order to start the productization phase.
If Google moved productization in-house, they could cause a more uniform environment for specific release versions, but this would not control UI differences or configuration file differences or feature differences instituted by the partner.
Nor could they force a partner to update the version of Android running on their devices. Once fielded, this would require carrier recertification of the devices before it could be deployed, and it is against the partners best interests to update devices, as that would cannibalize sales of new devices.
Ad Hoc is against the carriers best interests, since the alternative is to charge you SMS charges instead, and it's against the partners best interestes to enable UI for it, since they sell through the carriers, and the carriers do not want it enabled.
So basically you are attempting the Sisyphean task of fighting both the carriers, and their thralls, the partners, and you are holding an uninvolved third party responsible for not doing your job for you.
Congratulations, now go make^H^H^H^Hlose a billion $$$!
Safeway is starting to offer this as a service; however, like WebVan, they reserve the right to substitute "equivalent" goods when they feel it's necessary.
Unless you click the "no substitutions" box on their web site. That wasn't so hard, now was it.
It's not an account option (I checked). It is a checkout option.
Try reading the web site.
Seriously, if you're allergic to peanuts, you can damn well check labels and/or ask.
Which doesn't work with a delivery system using online ordering.
What were you trying to sell me again?
Seriously? You expect them to mine their databases so as to stop marketing peanut products to you? Where the fuck is the monetary incentive in that?
I don't sue them for killing my kid when I, as an informed engineer, can demonstrate their negligence. Likely they will not want this out, so they will want to settle, but me being out a kid, will not want a gag order and will start chanting "Class Action, Class Action!".
They've probably *already* injured someone who has not considered that there was data available and that their willful ignorance made them negligent.
I'm just guessing here...
This problem is more or less solved already. It can be done through ad hoc mesh networking, and there is firmware that can be used on Atheros and several other vendors chips.
The problem with deploying any of this is that the ability to do this with civilian devices disintermediates the cell phone user from the cell network providers. So there are huge buckets of money which Do No Want This Firmware Available Anywhere. Deploy it, and you mostly do not need cellular carriers, unless you need lower-than-voice-acceptable latency on your network for higher speed data (e.g. multiplayer video games).
The half a dozen companies that can already do this include Google; I used to sit about 200 feet from the office of the primary researcher.
Safeway does not suck as much as WebVan did, but they still suck.
To address your first point: According to their EDGAR filings, there are both distribution center and non-distribution center (store-based delivery).
For store-based delivery, according to the FAQ on their web site, they will offer control of substitutions at checkout. This assumes that their electronic inventory exactly matches their store inventory, and the items get instantly and magically pulled. If an in-store shopper grabs it before the person going around grabbing the stuff gets there, they substitute.
Now you are allowed to return a substituted item at no charge, but until you do, the cookies are sitting there for your kid to find. This is a highly imperfect system, and that hole leaves room for the problem.
There is also the possibility of overcommit for brand items, and there is the possibility of dishonesty. Admittedly, these likely apply to items such as toilet paper, but seriously, if you are out of toilet paper, and the choice is between the 1-ply store brand that's there, and the 3-ply Northern that's not there, or your hands, you are going to make the store brand container non-returnable by opening it.
Safeway seems to have learned some lessons from WebVan, but I would have to say, of the available lessons to be learned, they educated themselves on perhaps 10% of them.
So all in all, yeah, if you think not getting in a car for a 5 minute drive there and back is worth being grounded to your house for a 1 hour delivery window, and you think that and the marginal environmental savings are worth $9.95 a delivery (this is the per delivery charge, also according to their web site), then knock yourself out. Just make sure you check for post-checkout substitutions containing allergens.
Congratulations, now go make^H^H^H^Hlose a billion $$$!
Safeway is starting to offer this as a service; however, like WebVan, they reserve the right to substitute "equivalent" goods when they feel it's necessary.
When WebVan did that, we ended up with something with peanut oil in it instead of canola oil, which it's lucky we caught, or someone could have died.
When Safeway does it, it's going to be replacing name brands with Safeway brands, and it is more or less *always* be necessary, since they are sending the vans from the distribution center, which only stocks a few name brands. Toilet tissue? You get Safeway. Kleenex? You get Safeway tissue.
The asinine thing is that Safeway *already* does not use the frequency marketing card data to datamine it and say to themselves "Hmmmm... this card never buys anything containing peanuts, and hasn't for 10 years; let's flag them so that if they accidentally get something that has peanuts in it, they get an 'are you sure?' at the checkout". This despite the databases they already have on product ingredients and everything the card has *ever* been used to buy make this type of mining *trivial*.
Instead, the assholes print out $0.50 off coupons for exactly the products that we've been avoiding for 10 years, every time we buy an "equivalent" non-store brand version of the item. Of course it's cleverly based on the fact that on our next trip we are likely to be picking up one of the "equivalent" products that don't contain what amounts to rat poison, or might as well, for the allergic person.
Seriously, this is a stupid idea.
AKA "How do I market to geeks?"
How can you possibly maintain the following train of thought?
(1) "I think renaissance faire people are geeks"
(2) "I think slashdot people are geeks"
(3) "these groups form an equivalence set"
(4) "ask slashdot how to market to geeks"
(5) "slashdot tells me"
(6) "market to geeks"
(7) "reach the renaissance faire target market"
(8) "Profit!"
Seriously, I hope that the OP doesn't think that geeks form a monolithic market block, any more than Anonymous all hold the same political positions on everything.
Learning functional programming
Oh, you mean like LISP, from 1958?
or asynchronous server development
Oh, you mean like in "Theories of Abstract Automata", written by Michael Arbib, and published in 1969?
is not really on the same level as learning how to tap the right sequence of icons to get to the iPad games.
You're right. The first two things are so old they fart dust, like the grandmother who's trying to learn the third thing...
They should go after laundromat cork boards next. Also billboards, movie theater screens, and bluetooth keyboard output.
This is about enabling interception of any communications, right?