Although the rolling muffler does look a bit odd (it seems like it does
several more turns than it should) the tires rolling upslope and bumping
into one another also feels "wrong". It really doesn't seem like there's enough momentum
for this to happen, and it's curious that this section, unlike most of
the other parts of the ad, occurs right at the left margin of the screen.
Perhaps this is the cheat, and perhaps the cheat is as simple as having some
dude just offscreen poking the tires to keep 'em moving. That said, I can't
see why they'd set up such a (relatively) unimpressive section and then
have it need intervention.
It's certainly a nice ad (and one that actually addresses a real value
proposition), and a million times better than its predecessor, the horrid
meaningless "okay" ad, which also suffered from far more oily voiceover
from Garrison Keillor than the "just works" one. THat said, it's rather
long, and becomes somewhat tiresome on the n-th showing - I wish they'd
make a shorter version, perhaps with just the cool walking wipers.
I don't quite know what it is that they've improved, but JVM startup time seems to have gotten dramatically better somewhere betweek JDK1.3 and JDK1.4.1. On my mainstream winXP machine I can have a text-mode java HelloWorld running to completion in 0.2 secs (tested using cygwin's "time" command). That's a huge improvement over the several seconds it used to take, and makes writing little command line utilities in java a practical prospect.
Previously, the startup slowdown was due to the system having to load, verify, and link the twenty or so classes a simple program depends upon. Pjava and J2ME-CDC solved that by storing an image of the heap with the system classes already loaded, verified, and linked (and quickened) so the system was run-ready almost immediately. I wonder if the J2SE folks picked up on that? Alternatively, they could just be skipping the verify for those classes in the signed rt.jar, and offline preverify them prior to signature - the verifier always was the slow part of the process.
Your point about threads is well taken, and applies more generally to much of java programming. Java's language and libraries make it all to easy to write architecturally-slow programs - you really still have to fully understand what you're doing in order to write a decent program, regardless of the language.
There's a strong inverse correlation between job title and importance. Influential, important people have jobs like "doctor", "lawyer", "president". Doctors _aren't_ called "advanced internal healthcare treatment professional". Consequently, if you want to sound like a lowly prole with a job title that's supposed to make up for your tiny salary, get yourself a long title full of "power" words.
Opera has some one feature that (as far as I can tell) mozilla doesn't. It has a really easy way to change the rendering enging to run in a number of different modes, including small screen, text, accessibility, high contrast, and the rather fun CBM=64 lookielikie mode. Mozilla can do some of this, but Opera's handy menu access (view->style->usermode->xxx) makes testing the many pages of ones website for accessibility quite easy.
I'd really like a "tandem" mode, where the browser would automatically open each page in both normal and accessibility, or normal and text-only, modes (in two parallel windows, naturally).
In testing my own website for IE6, Mozilla-1.3, and Opera 7, I seem always to find the same thing:
It's not fiction, per se, as the fundamental physics is sound. Liftport saying it could be finished within a decade from now is plain silly. Every part of the endeavour entails inventing most of the necessary technology as you go.
As to falling down, there's good news and there's bad. The counterweight, counterstrand, and the geostationary terminus will stay up. If the terrestrial strand were to break, the worst case would probably be at a fairly high altitude, wrapping itself around the planet as you suggest (for the record, it's rather less than one equatorial circumference long). Now, the elevator's proponents will tell you that the carbon nanofibres that compose the terrestrial strand will break up due to atmospheric fiction heating them until they turn back into elemental carbon (a nice graphitic rain) and/or CO and CO2. This may be untrue - it's quite possible that the cable will disintegrate unto small nanotube fragments, which will be aerostatic at a variety of altitutes (aerostatic means they stay at much the same altitude without expending energy, the way pollen and safeway carrier bags do). So it's very possible that tons of aerostatic but chemically intact nanotubes will rain to earth over the year or so following the cable's failure. One recent study indicates that inhalation of nanotubes is extremely harmful to the lung (causing significant auto-immune scarring of the tissue surrounding the locii at which the nanotubes land).
Don't get me wrong - a space elevator is an amazing idea, and it's really the only thing that'll deliver the incremental-cost-to-space the space shuttle was promised to do. But don't underestimate the huge scale of the civil engineering project needed to build this, dwarfing the Panama canal and the chunnel. You'd need that next-gen shuttle thing just to haul into orbit the huge amount of
stuff. That's geostationary orbit remember, a whole lot higher than the shuttle can go -
everything out there boosted itself out with a sizeable motor of its own. Lifting hundreds or thousands of tons of construction material, workers, habitats, air, water, food, etc., is itself a space programme unparalleled in history.
Highlift (et al) are going a vital job - figuring out the basic technology of thie enterprise, writing the real project plan, sketching the logistics, and guestimating the construction cost. Someone (probably someone else) will have to figure out the economics of this thing - when will there be enough traffic wanting to get into space, and at what price, comparing this against the cost of the structure and figuring out when to build, where, and to what scale. Everyone in this phase has an awesome task ahead of them - the planners of the worlds great canals, bridges, tunnels, and dams all had lesser examples from which they could extrapolate - there's never been structure like the elevator, and even your minimal working model is 40 thousand miles long and costs a Dr Evil sum.
Once you get to the construction phase, then you're talking about a huge corporation with major government entanglements (as all great works of civil engineering have a big strategic impact). Canals like those at Suez and Panama were built only once there was a large volume of traffic going the long, expensive way (around the capes) which made the prospect attractive for investors. And the Chunnel and the Oresund link show that just 'cos everyone wants something doesn't mean you get it any time sooner than it becomes (kinda) economic.
Still, it'll happen, just as soon as everyone is sick of going to work in another rustly old rocket.
Foolish Child! Surely you don't believe the "far coast" heresy?
Lake Michigan has no "both coasts". There's nothing west of Manistee but endless waves and the occasional dragon. Get your facts straight next time, or be shunned.
Last time I read the OTEC literature (which, I admit, was a couple of years ago)
the prevailing thought was that there were only a handful of places on earth
where a coastal OTEC would be viable. You needed to have a location with a
large temperature difference between the water at different depths, and have
the relief of the seafloor be sufficiently steep that you didn't have to
trail pipes out tens of miles in order to harness this differential. Hence there
being only a few steep'n'tropical locations, like the Hawaiian one.
When I was about ten I read one of those cool-science-futures-for-kids magazines,
which showed a floating OTEC with a vertical downpipe - that makes more sense, as it
doesn't rely on rare coastal relief. I
believe Bruce Sterling's novel Islands in the Net also had similar floating OTECs.
Perhaps building such a device of the necessary
scale (you have to pump a lot of water around, after all) just isn't economic?
Even if you do get mass OTEC production working, its quite debateable if it's
really such a good idea. It's a lot of effort (money, materials, time) devoted
to something that doesn't generate a terribly impressive amount of energy, and
by its very nature it both warms the deep water and cools the surface water, which
will have localised environmental consequences.
I despair that everyone is concentrating on renewable resources while so many
people (particularly in hot western US states) live in essentially uninsulated
houses with single glazed windows. Biomas, geothermal, wind, solar, and ocean
generation are all expensive and uncertain - tripleglazed solarglass windows
and super-thick wall insulation are available fairly cheaply right now, are guaranteed
to pay for themselves way before a windmill, an OTEC, or even a biomass plant.
Yet still we're paying to air condition the sky.
SCO is in the same position as Intergraph before it, and is trying the same gag.
They're a formerly large and influential company, fallen to the point of minnowhood.
They have no prospect of growing significantly, have no revenue, and no significant
human capital. So they've gone the patent litigation route.
There's no obvious "strikebacks" at such a company (they're a lot like a "litigation proof"
private citizen). Consumer actions or intensified competition won't work, as that
is intended to interfere with revenue streams they don't have in the first place.
Large tech companies (particularly IBM) might normally unleash a broadside of retaliatory
IP lawsuits, but again SCO won't care much - that would interfere with revenue they
don't have or enjoin actions they aren't taking. Their current claim is huge, but
they'll try to negociate a more "reasonable" sum with IBM - one that would probably
be less than the cost to IBM of the litigation.
Intel wouldn't roll over for Intergraph, and I'd guess IBM won't for SCO.
...which naturally gives them an exc^h^h^hright to permanently break
interoperability with OpenOffice, Koffice, etc. It's like Trusted Computing
and signed Xbox images - they're not trying to shut out competition,
but if that incidentally happens, they're not going to cry about it.
Two years ago I attended a talk at Stanford University's Computer Science
department (non-coincidentally the Gates Building) given by Shamus Blackley,
then head-honcho of Xbox.
After his talk and demo, he was asked whether Linux would run on the Xbox
(I think it was the first question asked). His answer (I'm paraphrasing)
was interesting:
in theory, yes (as it was intel/nvidia hardware)
they wouldn't go out of their way to stop it
but they did go out of their way to make the xbox hard to hack
and he wasn't sure there was a way that, in the light of #3, that running it would be practical
His talk hadn't mentioned code signing, so no-one asked him whether they'd sign a
linux image. I figure he's right on that last point - it's easy to imagine a
signed "aint-it-cool" general purpose linux image being quickly coopted into a
wrapper that allowed copied games to be played.
So perhaps the question should be "why would Microsoft _want_ to sign an Xbox linux
image?". I doubt "so they can sell more Xboxes" is going to be persuasive
enough.
Essentially they're selling a Sinclair C5 with one less wheel,
no seat, at seven times the cost.
It's an interesting marketing lesson, showing that neat technical features
don't necessarily turn into value propositions that would make a customer
actually want to cough up the money. Its amazon.com page tries in vain to
sell it, protesting its uncanny ability to go backwards, go up slopes (gasp!),
and even "self balance". The trouble is - people with fully functional legs can
do all those things for free right now, and people without generally can't use
a segway.
And Dean - it's five thousand dollars!. I can wear my underpants
on my head, shove two pencils up my nose and look like a maniac for free.
This is laudable (at least in theory), and hopefully a sign that Switzerland
is continuing to shrug off its rather shakey reputation w.r.t democracy.
In Switzerland, women were unable to vote on national issues until 1971, and voting on regional issues was restricted in some cantons of the country until 1990.
Perhaps, on the internet, no-one knows you're a woman.
Maybe the developers are just too lazy to build their systems "from scratch" like they used to. I personally can't see the benefit of using an embedded OS. What am I missing?
It's a good question, and one automotive developers haven't really had to worry
about until recently. When all they had to code was realtime control code
for those 70-odd microcontrollers, they certainly didn't need an OS.
But the developers (or rather their marketing departments) have bigger ideas.
A car is no longer but a conveyance - it's an environment, an entertainment
centre, a home. So they mandate navigation, remote and stored diagnostics,
centralised control of various settings (A/C, seat position, etc.), radio
stations, RDS, CD control, media (MP3 etc.), radio, video (disney for the kids), and
all of this controlled by voice input and giving voice output. Those are
requirements a workstation or PC could scarely manage five years ago.
Add to that the significant issue that most of those applications will
be coming from third party vendors. Anyone implementing such a system
has little choice but to put in a decent 32 bit microprocessor, a
fair chunk of RAM (several meg, going on 16), and a half-decent OS.
WinCE (for automotive, whatever...) is certainly the worst choice.
QNX, VxWorksAE, or Embedded(orRT)Linux would certainly be better -
but the fundamental problem remains - this is HARD to get right.
Don't be fooled into thinking this is just an amusing diversion, where the
worst that can happen is that your radio doesn't work for a while. This is
a major safety issue - simply because the "infotainment system" doesn't have
a wire to the steering or the accelerator doesn't mean it can't kill you.
Imagine you're driving through a busy freeway intersection, at high speed
in pretty heavy traffic. Suddenly the radio turns on, to a bad (noisy)
channel, at FULL VOLUME. IT HURTS. YOU'RE SURPRISED. YOU LOSE CONCENTRATION
FOR A SECOND OR TWO. YOU DIE. So do your kids, and those of the guy in the
subaru in front. The lady in the dodge behind you loses a leg.
Also, don't think this is confined to high-end cars like BMW and Cadillac -
auto manufacturers try out new stuff in the high-end lines before they
push it further down the product line. Soon you won't be able to buy a
vehicle without this stuff. And __nobody__ is doing a good job of
making it.
If memory serves, isn't one of the reasons a full "on screen" TV guide
presently costs $s is that the publishers of TV guide hold a US
patent on all such EPGs ?
Hell, if that isn't the most obvious of the many "put paper thing on
computer" patents.
Only in very high stakes cases will forensics require anything more than a dd image
It's tough for me to think of a case that's higher-stakes than this one.
and if they can get what they need from a dd image, why bother?
That's a totally egregious misstatement of proper evidence gathering - the
investigator is not trying to "get what they need". Instead the
investigator should capture as much information as is possible. Its for
a prosecutor to cherry-pick the body of devidence in order to build their case, and for defence
counsel to likewise pick out exculpatory evidence.
Sure, in practice it's highly unlikely that a remapped LBA contains the only
copy of an incriminating or exculpatory email, but given the huge stakes
here it shouldn't be too much "bother".
Hey, there's something else - they're doing checksum calculation not on
the disk image (/dev/hda) but on the partition image (/dev/hda1) -
which means they're not entirely capturing everything that's potentially
on the disk (in particular: the boot sector, the MBR, and any other partitions).
Now, the document says the examiner determined that there was only one
partition, and that he used a "a Linux Boot CD" - this implies (it's not
terribly clear what that actually is) that he used linux's fdisk command
(or diskdruid or something) to determine that there was indeed only one
partition - by examining the current contents of the drive's partition
table.
Doing this doesn't capture any space not currently assigned to a partition -
in particular, if another partition were present but was then deleted, or if
the extant FAT32 partition were resized (say with partition magic).
Infact it's rather unusual for a windows laptop to only have one FAT32
partition - many (most?) vendor-created laptops ship with a sleep-to-disk
partition on the disk as well (Dell seems to always to this on windows
systems).
In a non-forensic setting, these gripes would be beyond pedantic, but given
the seriousness of the crime concerned, and the alleged technical skill
of the terrorist groups implicated, these omissions are not immaterial. I
do hope that they're omissions only in this document and that the examiners
actual procedure did properly image, checksum and examine _all_ of the
disk's contents.
Neglecting the STEM/SQUID recovery issues mentioned above, it's rather
dissapointing to see the feds using only a generic imager like dd to
image the disk, as it's not quite a full image of all the
stuff on the disk.
The contents any LBA that is in the drive's remap table (i.e. blocks
that the drive electronics have previously determined either to be
bad or going bad) aren't captured by dd - the drive instead sends
the data payload corresponding to the LBA's remapped physical address.
The bad/bad-ish block remains, and its data is quite possibly still
valid (or perhaps valid but for a couple of localised errors). These
blocks thus hold tiny slivers of data stored on the drive sometime
in the past (the last thing written before the block went bad).
Although this missed data represents a microscopic fraction of the
total data on the disk it could, at least in theory, contain recoverable
data of an evidenciary nature. The only way to see this is a drive-vendor
specific low-level read - I don't know much about the other two tools
the article describes, but it doesn't sound like those do that either.
Given that there's only a handful of drive manufacturers left, and the
(non-servo) parts of the firmware on their drives doesn't vary hugely
between models, it really wouldn't be too hard for law-enforcement
types to have proper physical-level imaging tools for any drive they're
likely to encounter.
Crichton not admirable
on
Prey
·
· Score: 3, Insightful
Crichton really doesn't write books - he writes "treatments" - stories
so easily turned into movie scripts as to really not work properly
as books in their own right. He's far from the only perpetrator
of this. Here's some telltale features of such faux-books:
very few characters
few locations, and most of those easily built as sets
an exciting, action-based finale
a largely linear plotline
lots of dialog, and little effort expended on writing that would be lost
in translation to the screen (description, introspection)
plenty of violence, but little or no sex or sexual/vulgar language
(after all, there's less money in R-rated movies, and sex and pottymouthery
gets you an R far more readily than does violence)
Sphere may be the worst book I've ever (tried) to read, but it made
a reasonable (rental) movie.
Wolfram are relying (quite sensibly) on the fact that those technical
(but not computer-technical) people who've invested significant effort
in mastering the appropriate program for their profession
(e.g. AutoCAD, 3DS, Photoshop, Word, Excel, Mathematica)
henceforth use their one tool as if it were a universal tool, a
digital swiss-army-knife.
I've seen a menu done in AutoCAD and a 3d mechanical drawing done in
photoshop - both to quite hysterical results.
Wolfram know that there are _lots_ of users who'd much rather persuade
their employer/institution to buy lots of gridMathematica licences than
have they themselves switch to working in Fortran.
Is there an open-source or free-software product in the Mathematica / Matlab / Maple etc. space ?
How to the free solutions, if they exist, compare with their (darned expensive) commercial bretheren in general, and in particular is there anything like grid support?
My former employer (large computer company) would regularly hold sales
meetings which worldwide sales employees of a given division would attend.
Because of the distribution of staff around the world, it was pretty
obvious that the meetings should occur either on the west coast of the
US or in Hawaii.
They learned through bitter experience that the controllers regarded
Hawaii as "junket city" and San Jose as "get work done city", and so
they could only get stuff approved for San Jose. This dispite the fact
that flights to San Jose were at least as expensive as those to Hawaii,
and hotel accomodation (for several hundred people, for a week) was
considerably more expensive.
So the meetings were always in San Jose (or some other hideous Silicon
Valley heckhole), at twice the price their Hawaiian equivalents would have
been.
I'd be interested to see if anyone can justify this, I just don't feel overall comfortable with the concept of UNIX cloning.
Okay, here's a few, and there's many more from whence these came:
You're the lab manager for a large university. You just bought seven
hundred identical PCs. You have one week to install a customised kernel,
a variety of applications, and lots of site-specific settings onto each machine.
You're the above lab manager and several hundred of those machines will
sit in a public lab with no grown-up to police them. Experience tells you
that student pranksters will do stuff to these machines on a pretty regular
basis. Each student is supposed to keep all their work (on an ongoing basis)
purely on their network-mounted directory. So you want to periodically
(ideally nightly) have the machines return to a known software state.
You're the lab manager for the QA department of a large software company. A lot
of the tests that the testers perform involve installing new software,
performing the necessary patches - these must be performed on machines with
exactly the correct software setup, otherwise the test is invalid.
Generally, running each test takes less than an hour. You don't want
testers sitting waiting for their (rare) test machines to reinstall any
longer than absolutely necessary.
You're the production manager for a large PC company. You make production
runs of thousands of identical machines each day. Time is short, and
the production engineers won't let you specialise a given harddrive on the
line until its actually inserted into a machine (very common), so you want
to very quickly have production machines netboot and pull down their software
image. Every minute a machine spends on the production line cost the
company a dollar.
At least as far as the kernels are concerned, ChorusOS and QNX-neutrino are
quite similar - both are realtime, microkernel based, protected-mode embeddable OSes,
available for a number of microprocessors and embedded boards. Most of this
(with the exception of the micrkernel part) is also true for Windriver's
VxWorks AE RTOS.
VxWorks' and QNX's advantage over ChorusOS was a combination of wider
BSP support and very mature toolchains. ChorusOS big advantage was that
it was specifically targetted at distributed applications - this is a issue
for applications that combine real-time performance with data-centre-like
reliablility (particularly telco).
Slashdot Mirror
It's certainly a nice ad (and one that actually addresses a real value proposition), and a million times better than its predecessor, the horrid meaningless "okay" ad, which also suffered from far more oily voiceover from Garrison Keillor than the "just works" one. THat said, it's rather long, and becomes somewhat tiresome on the n-th showing - I wish they'd make a shorter version, perhaps with just the cool walking wipers.
Previously, the startup slowdown was due to the system having to load, verify, and link the twenty or so classes a simple program depends upon. Pjava and J2ME-CDC solved that by storing an image of the heap with the system classes already loaded, verified, and linked (and quickened) so the system was run-ready almost immediately. I wonder if the J2SE folks picked up on that? Alternatively, they could just be skipping the verify for those classes in the signed rt.jar, and offline preverify them prior to signature - the verifier always was the slow part of the process.
Your point about threads is well taken, and applies more generally to much of java programming. Java's language and libraries make it all to easy to write architecturally-slow programs - you really still have to fully understand what you're doing in order to write a decent program, regardless of the language.
And my job description? I'm a
I'd really like a "tandem" mode, where the browser would automatically open each page in both normal and accessibility, or normal and text-only, modes (in two parallel windows, naturally).
In testing my own website for IE6, Mozilla-1.3, and Opera 7, I seem always to find the same thing:
As to falling down, there's good news and there's bad. The counterweight, counterstrand, and the geostationary terminus will stay up. If the terrestrial strand were to break, the worst case would probably be at a fairly high altitude, wrapping itself around the planet as you suggest (for the record, it's rather less than one equatorial circumference long). Now, the elevator's proponents will tell you that the carbon nanofibres that compose the terrestrial strand will break up due to atmospheric fiction heating them until they turn back into elemental carbon (a nice graphitic rain) and/or CO and CO2. This may be untrue - it's quite possible that the cable will disintegrate unto small nanotube fragments, which will be aerostatic at a variety of altitutes (aerostatic means they stay at much the same altitude without expending energy, the way pollen and safeway carrier bags do). So it's very possible that tons of aerostatic but chemically intact nanotubes will rain to earth over the year or so following the cable's failure. One recent study indicates that inhalation of nanotubes is extremely harmful to the lung (causing significant auto-immune scarring of the tissue surrounding the locii at which the nanotubes land).
Highlift (et al) are going a vital job - figuring out the basic technology of thie enterprise, writing the real project plan, sketching the logistics, and guestimating the construction cost. Someone (probably someone else) will have to figure out the economics of this thing - when will there be enough traffic wanting to get into space, and at what price, comparing this against the cost of the structure and figuring out when to build, where, and to what scale. Everyone in this phase has an awesome task ahead of them - the planners of the worlds great canals, bridges, tunnels, and dams all had lesser examples from which they could extrapolate - there's never been structure like the elevator, and even your minimal working model is 40 thousand miles long and costs a Dr Evil sum.
Once you get to the construction phase, then you're talking about a huge corporation with major government entanglements (as all great works of civil engineering have a big strategic impact). Canals like those at Suez and Panama were built only once there was a large volume of traffic going the long, expensive way (around the capes) which made the prospect attractive for investors. And the Chunnel and the Oresund link show that just 'cos everyone wants something doesn't mean you get it any time sooner than it becomes (kinda) economic.
Still, it'll happen, just as soon as everyone is sick of going to work in another rustly old rocket.
Lake Michigan has no "both coasts". There's nothing west of Manistee but endless waves and the occasional dragon. Get your facts straight next time, or be shunned.
When I was about ten I read one of those cool-science-futures-for-kids magazines, which showed a floating OTEC with a vertical downpipe - that makes more sense, as it doesn't rely on rare coastal relief. I believe Bruce Sterling's novel Islands in the Net also had similar floating OTECs. Perhaps building such a device of the necessary scale (you have to pump a lot of water around, after all) just isn't economic?
Even if you do get mass OTEC production working, its quite debateable if it's really such a good idea. It's a lot of effort (money, materials, time) devoted to something that doesn't generate a terribly impressive amount of energy, and by its very nature it both warms the deep water and cools the surface water, which will have localised environmental consequences.
I despair that everyone is concentrating on renewable resources while so many people (particularly in hot western US states) live in essentially uninsulated houses with single glazed windows. Biomas, geothermal, wind, solar, and ocean generation are all expensive and uncertain - tripleglazed solarglass windows and super-thick wall insulation are available fairly cheaply right now, are guaranteed to pay for themselves way before a windmill, an OTEC, or even a biomass plant. Yet still we're paying to air condition the sky.
SCO is in the same position as Intergraph before it, and is trying the same gag. They're a formerly large and influential company, fallen to the point of minnowhood. They have no prospect of growing significantly, have no revenue, and no significant human capital. So they've gone the patent litigation route.
There's no obvious "strikebacks" at such a company (they're a lot like a "litigation proof" private citizen). Consumer actions or intensified competition won't work, as that is intended to interfere with revenue streams they don't have in the first place. Large tech companies (particularly IBM) might normally unleash a broadside of retaliatory IP lawsuits, but again SCO won't care much - that would interfere with revenue they don't have or enjoin actions they aren't taking. Their current claim is huge, but they'll try to negociate a more "reasonable" sum with IBM - one that would probably be less than the cost to IBM of the litigation.
Intel wouldn't roll over for Intergraph, and I'd guess IBM won't for SCO.
...which naturally gives them an exc^h^h^hright to permanently break interoperability with OpenOffice, Koffice, etc. It's like Trusted Computing and signed Xbox images - they're not trying to shut out competition, but if that incidentally happens, they're not going to cry about it.
After his talk and demo, he was asked whether Linux would run on the Xbox (I think it was the first question asked). His answer (I'm paraphrasing) was interesting:
His talk hadn't mentioned code signing, so no-one asked him whether they'd sign a linux image. I figure he's right on that last point - it's easy to imagine a signed "aint-it-cool" general purpose linux image being quickly coopted into a wrapper that allowed copied games to be played.
So perhaps the question should be "why would Microsoft _want_ to sign an Xbox linux image?". I doubt "so they can sell more Xboxes" is going to be persuasive enough.
Essentially they're selling a Sinclair C5 with one less wheel, no seat, at seven times the cost.
It's an interesting marketing lesson, showing that neat technical features don't necessarily turn into value propositions that would make a customer actually want to cough up the money. Its amazon.com page tries in vain to sell it, protesting its uncanny ability to go backwards, go up slopes (gasp!), and even "self balance". The trouble is - people with fully functional legs can do all those things for free right now, and people without generally can't use a segway.
And Dean - it's five thousand dollars!. I can wear my underpants on my head, shove two pencils up my nose and look like a maniac for free.
this and this
In Switzerland, women were unable to vote on national issues until 1971, and voting on regional issues was restricted in some cantons of the country until 1990.
Perhaps, on the internet, no-one knows you're a woman.
It's a good question, and one automotive developers haven't really had to worry about until recently. When all they had to code was realtime control code for those 70-odd microcontrollers, they certainly didn't need an OS.
But the developers (or rather their marketing departments) have bigger ideas. A car is no longer but a conveyance - it's an environment, an entertainment centre, a home. So they mandate navigation, remote and stored diagnostics, centralised control of various settings (A/C, seat position, etc.), radio stations, RDS, CD control, media (MP3 etc.), radio, video (disney for the kids), and all of this controlled by voice input and giving voice output. Those are requirements a workstation or PC could scarely manage five years ago. Add to that the significant issue that most of those applications will be coming from third party vendors. Anyone implementing such a system has little choice but to put in a decent 32 bit microprocessor, a fair chunk of RAM (several meg, going on 16), and a half-decent OS.
WinCE (for automotive, whatever...) is certainly the worst choice. QNX, VxWorksAE, or Embedded(orRT)Linux would certainly be better - but the fundamental problem remains - this is HARD to get right.
Don't be fooled into thinking this is just an amusing diversion, where the worst that can happen is that your radio doesn't work for a while. This is a major safety issue - simply because the "infotainment system" doesn't have a wire to the steering or the accelerator doesn't mean it can't kill you. Imagine you're driving through a busy freeway intersection, at high speed in pretty heavy traffic. Suddenly the radio turns on, to a bad (noisy) channel, at FULL VOLUME. IT HURTS. YOU'RE SURPRISED. YOU LOSE CONCENTRATION FOR A SECOND OR TWO. YOU DIE. So do your kids, and those of the guy in the subaru in front. The lady in the dodge behind you loses a leg.
Also, don't think this is confined to high-end cars like BMW and Cadillac - auto manufacturers try out new stuff in the high-end lines before they push it further down the product line. Soon you won't be able to buy a vehicle without this stuff. And __nobody__ is doing a good job of making it.
Hell, if that isn't the most obvious of the many "put paper thing on computer" patents.
It's tough for me to think of a case that's higher-stakes than this one.
and if they can get what they need from a dd image, why bother?
That's a totally egregious misstatement of proper evidence gathering - the investigator is not trying to "get what they need". Instead the investigator should capture as much information as is possible. Its for a prosecutor to cherry-pick the body of devidence in order to build their case, and for defence counsel to likewise pick out exculpatory evidence.
Sure, in practice it's highly unlikely that a remapped LBA contains the only copy of an incriminating or exculpatory email, but given the huge stakes here it shouldn't be too much "bother".
Now, the document says the examiner determined that there was only one partition, and that he used a "a Linux Boot CD" - this implies (it's not terribly clear what that actually is) that he used linux's fdisk command (or diskdruid or something) to determine that there was indeed only one partition - by examining the current contents of the drive's partition table.
Doing this doesn't capture any space not currently assigned to a partition - in particular, if another partition were present but was then deleted, or if the extant FAT32 partition were resized (say with partition magic).
Infact it's rather unusual for a windows laptop to only have one FAT32 partition - many (most?) vendor-created laptops ship with a sleep-to-disk partition on the disk as well (Dell seems to always to this on windows systems).
In a non-forensic setting, these gripes would be beyond pedantic, but given the seriousness of the crime concerned, and the alleged technical skill of the terrorist groups implicated, these omissions are not immaterial. I do hope that they're omissions only in this document and that the examiners actual procedure did properly image, checksum and examine _all_ of the disk's contents.
The contents any LBA that is in the drive's remap table (i.e. blocks that the drive electronics have previously determined either to be bad or going bad) aren't captured by dd - the drive instead sends the data payload corresponding to the LBA's remapped physical address. The bad/bad-ish block remains, and its data is quite possibly still valid (or perhaps valid but for a couple of localised errors). These blocks thus hold tiny slivers of data stored on the drive sometime in the past (the last thing written before the block went bad).
Although this missed data represents a microscopic fraction of the total data on the disk it could, at least in theory, contain recoverable data of an evidenciary nature. The only way to see this is a drive-vendor specific low-level read - I don't know much about the other two tools the article describes, but it doesn't sound like those do that either.
Given that there's only a handful of drive manufacturers left, and the (non-servo) parts of the firmware on their drives doesn't vary hugely between models, it really wouldn't be too hard for law-enforcement types to have proper physical-level imaging tools for any drive they're likely to encounter.
Sphere may be the worst book I've ever (tried) to read, but it made a reasonable (rental) movie.
I've seen a menu done in AutoCAD and a 3d mechanical drawing done in photoshop - both to quite hysterical results.
Wolfram know that there are _lots_ of users who'd much rather persuade their employer/institution to buy lots of gridMathematica licences than have they themselves switch to working in Fortran.
How to the free solutions, if they exist, compare with their (darned expensive) commercial bretheren in general, and in particular is there anything like grid support?
Because of the distribution of staff around the world, it was pretty obvious that the meetings should occur either on the west coast of the US or in Hawaii.
They learned through bitter experience that the controllers regarded Hawaii as "junket city" and San Jose as "get work done city", and so they could only get stuff approved for San Jose. This dispite the fact that flights to San Jose were at least as expensive as those to Hawaii, and hotel accomodation (for several hundred people, for a week) was considerably more expensive.
So the meetings were always in San Jose (or some other hideous Silicon Valley heckhole), at twice the price their Hawaiian equivalents would have been.
Okay, here's a few, and there's many more from whence these came:
VxWorks' and QNX's advantage over ChorusOS was a combination of wider BSP support and very mature toolchains. ChorusOS big advantage was that it was specifically targetted at distributed applications - this is a issue for applications that combine real-time performance with data-centre-like reliablility (particularly telco).