Is it "your property" if you produced in in a partnership with several others, with one of the conditions of the partnership being its release?
Sure, the university probably owns the dollar fifty worth of DV tape or whatever medium it ended up on; but that isn't exactly what is holding up the process...
I'd like to argue with you, and on what seem like plausible grounds; but they aren't plausible grounds that have actually held out as often as one might like, so I think I'm going to end up agreeing:
In a rational world, without decision-making being like steering an aircraft carrier, RIM would be sitting pretty: They have a massive legacy subscriber base(which is dwindling over time; but reasonably slowly and predictably, and will be paying out for some years to come), they have a pretty attractive(to carriers and kids) 'featurephone' offering with BBM, email, and good battery life. Nobody will mistake it for an iPhone; but it's dirt cheap by comparison. They also have an existing handset supply chain and set ofcarrier contacts/channels. How could that go badly? Yeah, they do eventually have to wind down their legacy products; but those legacy products will give them about a zillion startups worth of cash with which to come up with new products that suck less!
However, that sort of re-invention just seems to be really, really hard. Kodak is like 6 inches from death, despite having a huge pile of foundational work in digital photography, plus industrial scale photochemical expertise, Microsoft and Apple both had to absorb outside teams to make their transitions from the technologically lousy OS that served them in their youth to the new one actually work(NT with an infusion of DEC, OSX with NeXT), even Big Blue, the Behemoth of corporate sales might, nearly managed to squander a massive pile of legacy cash and was on its way to being murdered by clones of its own invention.
Naively, I just can't shake the sense that having a legacy money tree to shake would be a good thing; but empirically it seems to be a dead-hand-of-the-past sort of affair, weighing on your future decision making...
Incidentally, how does endorsement key signing get handled in field applications of TPMs?
Obviously, an endorsement key that is simply unsigned would fail; but signing stuff is easy, it's just that most people won't care about your signature.
Does the vendor of the application choose which TPM vendors(of which there are a decent number, and which change sometimes) to trust the signatures of? Do the SSL CAs, who've done such a fantastic job, get roped in to this as roots of trust?
I recognize that it would be(barring a decapping and chip-level analysis of a genuine TPM) impossible for my soft-TPM or microcontroller-attached-to-the-LPC-bus to impersonate a, say, Infineon TPM; but it should be entirely possible for it to show as a genuine, signed, SporePoint Security LLC, TPM, signed with a set of keys generated by me.
Do you think that the loss of the lucrative market of "people who want to serve more than 25,000 embeds of your mapping data per day, for free" will necessarily strike Google as a bad thing(or any of their competitors as somebody worth attracting)?
Not as cut-and-dried as Google's; and they don't have a pay tier(though you can just run your own mirror and pay for that directly); but they also don't approve of use heavy enough to be problematic given their hosting resources. Not a huge surprise, really.
That's the sort of function that would probably be the work of a weekend to add if you just wanted it to work on your computer(crudest case, just a wrapper that automatically creates a cron job/scheduled task to delete at the desired time in the future; if you wanted it to still work if the file is moved/copied you'd need a metadata facililty and a scrubber task that kills files at their marked expiration times).
Now, on the other hand, if you want a system that is even possible for random 3rd party systems and devices to voluntarily adhere to(even after http uploads, metadata getting sheared off by a trip across a fat32 flash drive, handling for both HFS+ and NTFS metadata storage variants, etc, etc. support for mobile devices, web services where files are blobs in a DB, etc) You Have Fun With That, as they say.
And, of course, if you want 'trusted' expiration on random 3rd party systems, nothing short of a dystopian step back from general purpose computing will do...
Don't worry, user, of course you own those little files of yours.
We just want to install some robust Technological Protection Measures to preserve your ownership of those files across all devices and platforms and legal systems aligned with international norms... Totally harmless, nothing to worry about.
I certainly don't have anything against caffeine per se(not exactly a non-user here), I just found it a strange choice to be coupling with items also intended as food, since the effects at higher doses are somewhat unpleasant, and a strange choice to be researching, because there are already so many delivery options, running the gamut from palatable and non-portable to endurable and virtually indestructible.
Given the amount of legacy investment(not just on RIM's part; but on the part of some of their bigger corporate customers) in their proprietary stuff, its relatively good uptime history, and the fact that some people still value its particular set of advantages and disadvantages, it seems insane for RIM to scrap it. Consider, which of the following seems easier and less risky:
1. Scrap proprietary BBM/BIS/etc. and attempt to recreate featureset of the same in midflight with some sort of decentralized setup.
Or:
2. Keep all the various RIM-specific tricks around; and take advantage of the fact that flash is cheap by buying or building an IMAP/Activesync mail client that runs on your handsets(and has a bunch of centralized knobs and switces to keep the BES admins of the world happy). If the customer wants a classic blackberry, turn it off. If they want a decentralized offering, turn it on. If they want both, turn both on.
I'm surprised that they'd be using caffeine: 1. It's already dirt cheap and readily available in a wide variety of convenient forms. Coffee(with varying tradeoffs between goodness and portability), tea(ditto), water, pills, assorted energy-shot things, etc, etc. It's a readily water-soluble alkaloid stimulant. Not hard to work with.
Perhaps more importantly, caffeine is actually a mediocre alertness aid. In sufficient quantity it will prevent you from sleeping; but the jittery, dubiously-lucid, feeling that it provides isn't exactly "wakefulness". Not really a win for clear thinking or straight shooting. It seems like some exploration of Modafinil, or related drugs, if any, would be more productive.
That stuff isn't nearly as readily available in already common, light, nonperishable forms, and when it prevents you from sleeping you just don't feel sleepy. The effect is uncanny.
I wonder how difficult it would be... It is quite common for people with serious respiratory disorders(emphysema and similarly ghastly ones) to have to use supplemental oxygen more or less continually once their lung function drops too far to keep their blood oxygenated with an ordinary atmospheric gas mixture. Given this comparatively common and plausible use(especially common among fairly frail old people that even hardened TSA agents might refrain from gate-raping too violently), you could likely carry a tank without attracting excessive suspicion.
What I don't know is whether you could sneak the somewhat tougher requirements of storing liquid oxygen into a package that appears to be tackling the easier task of storing pressurized gaseous oxygen...
Paper isn't usually the feedstock(cotton fibers are preferred); but my good friend Nitrocellulose is arguably a 'paper-based-explosive'. Heck, assuming your print head can take the pain, you could even use an inkjet to apply the nitric acid to the paper and produce a printed, paper-based explosive for the printed, paper-based explosive detector to detect...
True enough. It also has an OS modified quite heavily indeed to work around those constraints(eg. the quasi-multitasking, specialized, constrained, special-purpose background processes, rather than applications just running in the background, and so forth.)
My point was, by no means, that such a device was useless; but that just grabbing a contemporary linux distro, changing the compile target, and expecting it to work well for heavy desktop use would likely prove unrealistic. Because you essentially can't buy an x86 with less than a gig of RAM and an Atom, and even your 300-400 Best Buy cheapies frequently come with substantially more than that, the footprint for "basic desktop" has broadened pretty enormously.
Nothing stops you from turning back the clock(and for devices with sufficient volume, prebuilt options to suit will be available); but you will have to make changes.
I recognize an attempt at cynicism; but the answer is really "both".
The relevant faces of the Nation-State of Mexico, however corrupt some of their departments are, would definitely take issue with American troops. They are quite clear on that point, which is one of the reasons that we do not use the same level of overt force in Mexico that we do in other parts of Latin America.
The drug cartels are a slightly more complex matter: they have an overwhelming interest in moving product and making money, and are willing to do pretty much anything that advances those goals. Sometimes that leads to conflict with US forces(the occasional border patrol guy, suspected DEA narcs, Americans caught up in gang violence, and so on); but, on the whole, it isn't good business to pick fights that you don't need to. At present, the vast bulk of the direct violence and more subtle corruption and subversion are being borne by the Mexican people and state; because they are the ones who are in the way. If we were to march in, we would be the ones in the way, and it would be expected that the cartels would start fighting and/or corrupting us as efficiently as possible. Given how unpleasant a time Mexico is having in dealing with the problem, we'd be pretty stupid to voluntarily walk in and take that on for ourselves...
I strongly suspect(as a linux user who has done some school dept. IT work, largely Windows with a sprinkle of Mac) that "they", the students, will neither lose nor gain all that much.
Some of the admin layers will have it tough(so they probably just won't switch those people), because that is where the spreadsheet-jockies, the users of obscure proprietary student information systems, etc, etc. congregate. The techies will be split: the microsoft crew will resent losing relevant skill, the FOSS-enthusiasts-just-working-a-job will be gung-ho.
As for the students, though, I doubt they'll see much change. Unless the computers are the explicit focus or means of pedagogy(as in something like the OLPC experiment), which is rare and nontrivial to do. Think what you will of their results, they built a previously unavailable sort of hardware along with a new security model and a variety of other tweaks to get that going. In the majority of cases, 'educational' computers are just tools. The teachers want them to be working, reliable, and running the browser/word processor/whatever required to get the classwork done. Admin wants them to be not disruptive, to be a not excessively good porn source, and IT delivers as it can. Because most of 'educational' IT is so peripheral to learning(yes, there are plenty of arguments for why office is better than LibreOffice. None of them have any bearing on whether you'll be able to learn to write a decent essay by writing a bunch of crap essays and revising. VI might be pushing it a little; but notepad should be enough), it is good that they are going with the cheaper option, to free up money that can be better used; but I'd expect virtually no change in how pupils are expected to interact with technology.
Hey, you are using OSS! You can make changes however you want! No, actually, your user account on our system is locked down to keep you out of trouble, just like it was on Windows. The school wants you to be able to log in, get your files, and use programs X, Y, and, Z. We've delivered.
Outside of strictly vocational schools(later in the student's progress, so they will still be fresh when they hit the workforce), where learning specific tools might be what the doctor ordered, or outside of ground-up computers-in-education-rethinks, which make student exploration of the computer a focus, not a problem, educational use of computers is really incredibly generic. Web, email, word processing, copy-pasting.
A minority of specialist users will simply be un-switchable, certain specialized software isn't multi-platform, has no real competitors, and is too costly to try to duplicate. It just isn't worth it. The vast bulk, though, really get a very constrained view of computers at school. It barely matters what they run.
At present, it looks comparatively similar to the situation on the BCM devices that show up in routers: There is a general purpose CPU, with well known and GCC supported instructions, and a way to get Linux up and going; but the further you get from 'boot a kernel image and chat with it on TTY0' the more likely it is that the feature is NDA or supported by a giant blob.
At present, I don't think that anybody is doing 2GB of PoP RAM, even the dual-core-monster-smartphones that cost 10-20 times as much cap out at half to a quarter of that...
ARM's push for the server world will presumably make (relatively) cheap ARM boards with substantial RAM available; but until that happens, treating ARM boards like contemporary desktops just isn't going to work. They are arguably wasteful and expensive in many applications; but the x86s of the world are brutally powerful.
Depending on what computer the poster is using, or willing to use for EEPROM work, you don't necessarily have to count parallel out, either.
There are, to my knowledge, no USB->Parallel converters that are the genuine article, rather than a somewhat dodgy USB Printer class horror, and the degree to which today's "USB->Serial" converters succeed in fooling hardware or software expecting a real serial port can be pretty variable(though much better than with parallel)
However, if your computer of choice has a PCI, PCIe, PCMCIA, or Expressport slot available, you can get a good-honest-old-fashioned serial, parallel, or combo card for comparatively little money(more than the USB dongles; but easily cheap enough to be worth it if it means getting a good deal on a programmer with an "outdated" interface)...
Are you unfamiliar with the "Mérida Initiative"("Plan Mexico" to skeptics)? For reasons, um, wholly unrelated to that incident where the border between Mexico and the US shifted abruptly some time back, Mexico takes considerable offense at the idea of US troops on its soil. We've settled for rolling out just about all the various instruments of policy-by-proxy we have available there and elsewhere in Latin America(Plan Columbia, Central American Regional Security Initiative, Caribbean Basin Security Initiative, likely the Western Hemisphere Institute for Security Cooperation in some capacity)
We've carefully avoided doing anything terribly effective; because Prohibition 2.0 is Going Just Fine Thanks For Asking; but unless our plans involve a shooting war with Mexico, an overt military presence in the area seems unlikely(and dubiously productive, most drug production is protected by means other than brute force, which makes soldiers less useful than they might be).
That would depend, in part, on a couple of things:
1. How "3rd party" are the 3rd parties? Shit does get smuggled sometimes; but people have been known to wink that their Dubai based VARs so long as the money is there...
2. How independent of the mothership are Blue Coat's censorship appliances. Some enterprise gear is relatively independent. Buy it, plug it in, the only remaining contact with the vendor is a warranty call if needed. Some enterprise gear is virtually a rented extension of the vendor's own network: You plug it in, it phones home more or less constantly for updates, with status reports, to go into cripple-mode if the service contract isn't paid up, to initiate service calls for shot FRUs, etc. If Blue Coat's devices are the former, smuggling should be pretty trivial. If the latter, I'd want to hear a very convincing account of how the re-allocation of equipment was hidden from them. It certainly wouldn't be impossible to keep a device from phoning home(software pirates do that sort of thing routinely, and there are other proxying and such tricks that could theoretically be used); but if Blue Coat knew that serial #s X,Y,Z were routinely phoning in for updates from IPs in Syria, and just sort of whistled a happy tune, they are't exactly blameless.
According to the whitepaper for their "Webpulse" 'cloud-based infrastructure', which appears to be integrated into their various perimeter security appliances, their devices are in more or less constant contact with them, and data including unclassifed URLs and binaries may be sent back to them from the security appliances for analysis and the release of detection rulesets to the customerbase.
Unless Syria was running some sneaky scheme for cloaking the location of their Blue Coat devices, or was turning off their most marketed features and running them dumb, Blue Coat should have been well aware of what was going on, and roughly where...
I am pretty surprised that AMD didn't include notification of this factor in their original release press materials, along with some sort of demo/benchmark/application with hardcoded CPU affinities/etc., that would have gone a fair way to mitigating people's displeasure(yes, it wouldn't have helped people with their workloads now, and yes it would have been dogged by "controversy" over whether the vender demos were rigged or not; but it would have been something).
Aside from the PR fuckup, though which has no reasonable explanation that I can come up wit, I'm not sure that they really had a choice: Their execution units, while they share FPUs, are substantially more independent that the HT "core" is, so marking it as an HT core would likely have led to fairly shitty performance, and from a die that is paying a pretty sizeable size penalty to have those independent bits that HT doesn't. Also, if they did mark them as HT cores, the odds that they'd be able to wring their own special treatment atypical core designation out of the schedulers for Windows N+1 and Linux 3.XX would not be improved...
Thinking back, when Intel first released HT, it pretty much blew for people using Windows2000, which was still quite a few of them, since the 2k scheduler just naively assumed that HT cores and real cores were and loaded them accordingly. Results were Not Good. As of XP, and possibly a very late 2k service pack, the situation improved.
I'm assuming that AMD is scrambling to have this included in mainline Linux as soon as possible, and are likely petitioning Redmond as well; but unless their wheedling powers are greater now than they were during the x86-64 introduction(where MS dragged their feet for ages until Intel decided that it was a cool idea after all), I'm not sure that the could get scheduler support for their new core type included any faster.
The PR handling seems little short of insane, and none of this is going to help them move units; but the option of just setting the HT bit presumably was nixed for some reason.
To me, Bulldozer's shared-FPU design looks rather like they wanted some of the specialized-workload advantage of the UltraSPARC T-series CPUs; but with somewhat less extreme trade-offs(The T1 had a single FPU shared between 8 physical cores, which proved to be a little too extreme and was beefed up in the T2). There are a fair number of server tasks that are FPU light; but have lots of threads, often do well with a lot of RAM, and are fairly cost sensitive.
Not at all a good recipe for a workstation or scientific computing device(which shows in that some of the present Phenoms stack up uncomfortably well with the newer architecture); but there are a lot of server loads that can use as many cheap threads as you can throw at them; but don't really hit the FPU all that hard...
Slashdot Mirror
What are your sins? What are you afraid of?
Is it "your property" if you produced in in a partnership with several others, with one of the conditions of the partnership being its release?
Sure, the university probably owns the dollar fifty worth of DV tape or whatever medium it ended up on; but that isn't exactly what is holding up the process...
I'd like to argue with you, and on what seem like plausible grounds; but they aren't plausible grounds that have actually held out as often as one might like, so I think I'm going to end up agreeing:
In a rational world, without decision-making being like steering an aircraft carrier, RIM would be sitting pretty: They have a massive legacy subscriber base(which is dwindling over time; but reasonably slowly and predictably, and will be paying out for some years to come), they have a pretty attractive(to carriers and kids) 'featurephone' offering with BBM, email, and good battery life. Nobody will mistake it for an iPhone; but it's dirt cheap by comparison. They also have an existing handset supply chain and set ofcarrier contacts/channels. How could that go badly? Yeah, they do eventually have to wind down their legacy products; but those legacy products will give them about a zillion startups worth of cash with which to come up with new products that suck less!
However, that sort of re-invention just seems to be really, really hard. Kodak is like 6 inches from death, despite having a huge pile of foundational work in digital photography, plus industrial scale photochemical expertise, Microsoft and Apple both had to absorb outside teams to make their transitions from the technologically lousy OS that served them in their youth to the new one actually work(NT with an infusion of DEC, OSX with NeXT), even Big Blue, the Behemoth of corporate sales might, nearly managed to squander a massive pile of legacy cash and was on its way to being murdered by clones of its own invention.
Naively, I just can't shake the sense that having a legacy money tree to shake would be a good thing; but empirically it seems to be a dead-hand-of-the-past sort of affair, weighing on your future decision making...
Incidentally, how does endorsement key signing get handled in field applications of TPMs?
Obviously, an endorsement key that is simply unsigned would fail; but signing stuff is easy, it's just that most people won't care about your signature.
Does the vendor of the application choose which TPM vendors(of which there are a decent number, and which change sometimes) to trust the signatures of? Do the SSL CAs, who've done such a fantastic job, get roped in to this as roots of trust?
I recognize that it would be(barring a decapping and chip-level analysis of a genuine TPM) impossible for my soft-TPM or microcontroller-attached-to-the-LPC-bus to impersonate a, say, Infineon TPM; but it should be entirely possible for it to show as a genuine, signed, SporePoint Security LLC, TPM, signed with a set of keys generated by me.
Who sets the 'trusted' signers?
Do you think that the loss of the lucrative market of "people who want to serve more than 25,000 embeds of your mapping data per day, for free" will necessarily strike Google as a bad thing(or any of their competitors as somebody worth attracting)?
http://wiki.openstreetmap.org/wiki/API_usage_policy
Not as cut-and-dried as Google's; and they don't have a pay tier(though you can just run your own mirror and pay for that directly); but they also don't approve of use heavy enough to be problematic given their hosting resources. Not a huge surprise, really.
That's the sort of function that would probably be the work of a weekend to add if you just wanted it to work on your computer(crudest case, just a wrapper that automatically creates a cron job/scheduled task to delete at the desired time in the future; if you wanted it to still work if the file is moved/copied you'd need a metadata facililty and a scrubber task that kills files at their marked expiration times).
Now, on the other hand, if you want a system that is even possible for random 3rd party systems and devices to voluntarily adhere to(even after http uploads, metadata getting sheared off by a trip across a fat32 flash drive, handling for both HFS+ and NTFS metadata storage variants, etc, etc. support for mobile devices, web services where files are blobs in a DB, etc) You Have Fun With That, as they say.
And, of course, if you want 'trusted' expiration on random 3rd party systems, nothing short of a dystopian step back from general purpose computing will do...
Are you saying that quoting Wittgenstein in a paper that is ostensibly concerned with file structures is pretentious, content-free twaddle?
Couldn't be...
Don't worry, user, of course you own those little files of yours.
We just want to install some robust Technological Protection Measures to preserve your ownership of those files across all devices and platforms and legal systems aligned with international norms... Totally harmless, nothing to worry about.
I certainly don't have anything against caffeine per se(not exactly a non-user here), I just found it a strange choice to be coupling with items also intended as food, since the effects at higher doses are somewhat unpleasant, and a strange choice to be researching, because there are already so many delivery options, running the gamut from palatable and non-portable to endurable and virtually indestructible.
Given the amount of legacy investment(not just on RIM's part; but on the part of some of their bigger corporate customers) in their proprietary stuff, its relatively good uptime history, and the fact that some people still value its particular set of advantages and disadvantages, it seems insane for RIM to scrap it. Consider, which of the following seems easier and less risky:
1. Scrap proprietary BBM/BIS/etc. and attempt to recreate featureset of the same in midflight with some sort of decentralized setup.
Or:
2. Keep all the various RIM-specific tricks around; and take advantage of the fact that flash is cheap by buying or building an IMAP/Activesync mail client that runs on your handsets(and has a bunch of centralized knobs and switces to keep the BES admins of the world happy). If the customer wants a classic blackberry, turn it off. If they want a decentralized offering, turn it on. If they want both, turn both on.
I'm surprised that they'd be using caffeine: 1. It's already dirt cheap and readily available in a wide variety of convenient forms. Coffee(with varying tradeoffs between goodness and portability), tea(ditto), water, pills, assorted energy-shot things, etc, etc. It's a readily water-soluble alkaloid stimulant. Not hard to work with.
Perhaps more importantly, caffeine is actually a mediocre alertness aid. In sufficient quantity it will prevent you from sleeping; but the jittery, dubiously-lucid, feeling that it provides isn't exactly "wakefulness". Not really a win for clear thinking or straight shooting. It seems like some exploration of Modafinil, or related drugs, if any, would be more productive.
That stuff isn't nearly as readily available in already common, light, nonperishable forms, and when it prevents you from sleeping you just don't feel sleepy. The effect is uncanny.
I wonder how difficult it would be... It is quite common for people with serious respiratory disorders(emphysema and similarly ghastly ones) to have to use supplemental oxygen more or less continually once their lung function drops too far to keep their blood oxygenated with an ordinary atmospheric gas mixture. Given this comparatively common and plausible use(especially common among fairly frail old people that even hardened TSA agents might refrain from gate-raping too violently), you could likely carry a tank without attracting excessive suspicion.
What I don't know is whether you could sneak the somewhat tougher requirements of storing liquid oxygen into a package that appears to be tackling the easier task of storing pressurized gaseous oxygen...
Paper isn't usually the feedstock(cotton fibers are preferred); but my good friend Nitrocellulose is arguably a 'paper-based-explosive'. Heck, assuming your print head can take the pain, you could even use an inkjet to apply the nitric acid to the paper and produce a printed, paper-based explosive for the printed, paper-based explosive detector to detect...
True enough. It also has an OS modified quite heavily indeed to work around those constraints(eg. the quasi-multitasking, specialized, constrained, special-purpose background processes, rather than applications just running in the background, and so forth.)
My point was, by no means, that such a device was useless; but that just grabbing a contemporary linux distro, changing the compile target, and expecting it to work well for heavy desktop use would likely prove unrealistic. Because you essentially can't buy an x86 with less than a gig of RAM and an Atom, and even your 300-400 Best Buy cheapies frequently come with substantially more than that, the footprint for "basic desktop" has broadened pretty enormously.
Nothing stops you from turning back the clock(and for devices with sufficient volume, prebuilt options to suit will be available); but you will have to make changes.
I recognize an attempt at cynicism; but the answer is really "both".
The relevant faces of the Nation-State of Mexico, however corrupt some of their departments are, would definitely take issue with American troops. They are quite clear on that point, which is one of the reasons that we do not use the same level of overt force in Mexico that we do in other parts of Latin America.
The drug cartels are a slightly more complex matter: they have an overwhelming interest in moving product and making money, and are willing to do pretty much anything that advances those goals. Sometimes that leads to conflict with US forces(the occasional border patrol guy, suspected DEA narcs, Americans caught up in gang violence, and so on); but, on the whole, it isn't good business to pick fights that you don't need to. At present, the vast bulk of the direct violence and more subtle corruption and subversion are being borne by the Mexican people and state; because they are the ones who are in the way. If we were to march in, we would be the ones in the way, and it would be expected that the cartels would start fighting and/or corrupting us as efficiently as possible. Given how unpleasant a time Mexico is having in dealing with the problem, we'd be pretty stupid to voluntarily walk in and take that on for ourselves...
I strongly suspect(as a linux user who has done some school dept. IT work, largely Windows with a sprinkle of Mac) that "they", the students, will neither lose nor gain all that much.
Some of the admin layers will have it tough(so they probably just won't switch those people), because that is where the spreadsheet-jockies, the users of obscure proprietary student information systems, etc, etc. congregate. The techies will be split: the microsoft crew will resent losing relevant skill, the FOSS-enthusiasts-just-working-a-job will be gung-ho.
As for the students, though, I doubt they'll see much change. Unless the computers are the explicit focus or means of pedagogy(as in something like the OLPC experiment), which is rare and nontrivial to do. Think what you will of their results, they built a previously unavailable sort of hardware along with a new security model and a variety of other tweaks to get that going. In the majority of cases, 'educational' computers are just tools. The teachers want them to be working, reliable, and running the browser/word processor/whatever required to get the classwork done. Admin wants them to be not disruptive, to be a not excessively good porn source, and IT delivers as it can. Because most of 'educational' IT is so peripheral to learning(yes, there are plenty of arguments for why office is better than LibreOffice. None of them have any bearing on whether you'll be able to learn to write a decent essay by writing a bunch of crap essays and revising. VI might be pushing it a little; but notepad should be enough), it is good that they are going with the cheaper option, to free up money that can be better used; but I'd expect virtually no change in how pupils are expected to interact with technology.
Hey, you are using OSS! You can make changes however you want! No, actually, your user account on our system is locked down to keep you out of trouble, just like it was on Windows. The school wants you to be able to log in, get your files, and use programs X, Y, and, Z. We've delivered.
Outside of strictly vocational schools(later in the student's progress, so they will still be fresh when they hit the workforce), where learning specific tools might be what the doctor ordered, or outside of ground-up computers-in-education-rethinks, which make student exploration of the computer a focus, not a problem, educational use of computers is really incredibly generic. Web, email, word processing, copy-pasting.
A minority of specialist users will simply be un-switchable, certain specialized software isn't multi-platform, has no real competitors, and is too costly to try to duplicate. It just isn't worth it. The vast bulk, though, really get a very constrained view of computers at school. It barely matters what they run.
At present, it looks comparatively similar to the situation on the BCM devices that show up in routers: There is a general purpose CPU, with well known and GCC supported instructions, and a way to get Linux up and going; but the further you get from 'boot a kernel image and chat with it on TTY0' the more likely it is that the feature is NDA or supported by a giant blob.
At present, I don't think that anybody is doing 2GB of PoP RAM, even the dual-core-monster-smartphones that cost 10-20 times as much cap out at half to a quarter of that...
ARM's push for the server world will presumably make (relatively) cheap ARM boards with substantial RAM available; but until that happens, treating ARM boards like contemporary desktops just isn't going to work. They are arguably wasteful and expensive in many applications; but the x86s of the world are brutally powerful.
Depending on what computer the poster is using, or willing to use for EEPROM work, you don't necessarily have to count parallel out, either.
There are, to my knowledge, no USB->Parallel converters that are the genuine article, rather than a somewhat dodgy USB Printer class horror, and the degree to which today's "USB->Serial" converters succeed in fooling hardware or software expecting a real serial port can be pretty variable(though much better than with parallel)
However, if your computer of choice has a PCI, PCIe, PCMCIA, or Expressport slot available, you can get a good-honest-old-fashioned serial, parallel, or combo card for comparatively little money(more than the USB dongles; but easily cheap enough to be worth it if it means getting a good deal on a programmer with an "outdated" interface)...
Are you unfamiliar with the "Mérida Initiative"("Plan Mexico" to skeptics)? For reasons, um, wholly unrelated to that incident where the border between Mexico and the US shifted abruptly some time back, Mexico takes considerable offense at the idea of US troops on its soil. We've settled for rolling out just about all the various instruments of policy-by-proxy we have available there and elsewhere in Latin America(Plan Columbia, Central American Regional Security Initiative, Caribbean Basin Security Initiative, likely the Western Hemisphere Institute for Security Cooperation in some capacity)
We've carefully avoided doing anything terribly effective; because Prohibition 2.0 is Going Just Fine Thanks For Asking; but unless our plans involve a shooting war with Mexico, an overt military presence in the area seems unlikely(and dubiously productive, most drug production is protected by means other than brute force, which makes soldiers less useful than they might be).
That would depend, in part, on a couple of things:
1. How "3rd party" are the 3rd parties? Shit does get smuggled sometimes; but people have been known to wink that their Dubai based VARs so long as the money is there...
2. How independent of the mothership are Blue Coat's censorship appliances. Some enterprise gear is relatively independent. Buy it, plug it in, the only remaining contact with the vendor is a warranty call if needed. Some enterprise gear is virtually a rented extension of the vendor's own network: You plug it in, it phones home more or less constantly for updates, with status reports, to go into cripple-mode if the service contract isn't paid up, to initiate service calls for shot FRUs, etc. If Blue Coat's devices are the former, smuggling should be pretty trivial. If the latter, I'd want to hear a very convincing account of how the re-allocation of equipment was hidden from them. It certainly wouldn't be impossible to keep a device from phoning home(software pirates do that sort of thing routinely, and there are other proxying and such tricks that could theoretically be used); but if Blue Coat knew that serial #s X,Y,Z were routinely phoning in for updates from IPs in Syria, and just sort of whistled a happy tune, they are't exactly blameless.
According to the whitepaper for their "Webpulse" 'cloud-based infrastructure', which appears to be integrated into their various perimeter security appliances, their devices are in more or less constant contact with them, and data including unclassifed URLs and binaries may be sent back to them from the security appliances for analysis and the release of detection rulesets to the customerbase.
Unless Syria was running some sneaky scheme for cloaking the location of their Blue Coat devices, or was turning off their most marketed features and running them dumb, Blue Coat should have been well aware of what was going on, and roughly where...
I am pretty surprised that AMD didn't include notification of this factor in their original release press materials, along with some sort of demo/benchmark/application with hardcoded CPU affinities/etc., that would have gone a fair way to mitigating people's displeasure(yes, it wouldn't have helped people with their workloads now, and yes it would have been dogged by "controversy" over whether the vender demos were rigged or not; but it would have been something).
Aside from the PR fuckup, though which has no reasonable explanation that I can come up wit, I'm not sure that they really had a choice: Their execution units, while they share FPUs, are substantially more independent that the HT "core" is, so marking it as an HT core would likely have led to fairly shitty performance, and from a die that is paying a pretty sizeable size penalty to have those independent bits that HT doesn't. Also, if they did mark them as HT cores, the odds that they'd be able to wring their own special treatment atypical core designation out of the schedulers for Windows N+1 and Linux 3.XX would not be improved...
Thinking back, when Intel first released HT, it pretty much blew for people using Windows2000, which was still quite a few of them, since the 2k scheduler just naively assumed that HT cores and real cores were and loaded them accordingly. Results were Not Good. As of XP, and possibly a very late 2k service pack, the situation improved.
I'm assuming that AMD is scrambling to have this included in mainline Linux as soon as possible, and are likely petitioning Redmond as well; but unless their wheedling powers are greater now than they were during the x86-64 introduction(where MS dragged their feet for ages until Intel decided that it was a cool idea after all), I'm not sure that the could get scheduler support for their new core type included any faster.
The PR handling seems little short of insane, and none of this is going to help them move units; but the option of just setting the HT bit presumably was nixed for some reason.
To me, Bulldozer's shared-FPU design looks rather like they wanted some of the specialized-workload advantage of the UltraSPARC T-series CPUs; but with somewhat less extreme trade-offs(The T1 had a single FPU shared between 8 physical cores, which proved to be a little too extreme and was beefed up in the T2). There are a fair number of server tasks that are FPU light; but have lots of threads, often do well with a lot of RAM, and are fairly cost sensitive.
Not at all a good recipe for a workstation or scientific computing device(which shows in that some of the present Phenoms stack up uncomfortably well with the newer architecture); but there are a lot of server loads that can use as many cheap threads as you can throw at them; but don't really hit the FPU all that hard...
So then SSDs suck because you have to tweak the IO scheduler(elevator)?
How can you even Dream of trusting any drive that isn't good enough for solid, proven, CHS addressing?