No, not at all. The net neutrality debate is about whether ISPs can throttle content based on the content's particular source, not on the content type.
That's one formulation. Others are more general, and address the fact that the reason the source matters to the would-be-throttler is specifically because of its content type; or equivalently, that the source can be viewed as an attribute of the type. (Video from ISP != Video from third-party, etc.) And in any case, claiming that throttling all encrypted traffic is even vaguely neutral boggles the mind... this fits clearly in the core of any kind of common-sense definition of neutral data carriage.
Consider the costs for one employee to own one car for 5 years. Ballpark figures: car at $30K, insurance $1K/year, maintainance and fuel $2K/year, $45K total, $9K/year. If that employee doesn't need to own that car, one could argue that his/her salary can be $9K less. Does that employee's shuttle service cost that much? No way...
Now, not ever employee can (finally) do without owning an automobile. But many can. And Google wouldn't need to spend as much supporting parking lots (they have a BIG parking problem anyway). So net costs to the company could easily go down because they stop externalizing transportation costs to employees, and into their salaries.
Maybe that accounting is a bit of a pipe dream right now, but eventually people will start to account for costs that certain industries (oil, auto, steel, rubber, etc) would rather be scattered into individual paychecks... and notice how much waste is factored into our current industrial structures. Google IS cutting those costs right now.
They print out a standard ballot, which is deposited in the ballot box.
And they're counted by the same machines that count hand-filled ballots.
From a voting-integrity perspective, that's exactly what voting
machines should do! Play to the strengths of computer tech -- namely
flexible UI that can help address issues of handicap and language, and
producing low-spoilage ballots -- while
not sacrificing auditability.
The team that designed that voting tech is the **FIRST** one I've ever
heard of doing the obviously-correct thing:
make voting easier, not counting.
Ooh, I hate to reply to myself, but this is good news.
It turns out that Atmel just published the AVR32 Java Technical Reference Manual
giving exactly the information I was asking about. Probably about 40 hours before I posted; sigh.
I guess that Atmel guy was wrong when he said they couldn't publish that information...
I've only skimmed those docs, so I can only say that they look like the right thing but clearly
omit things like "how to invoke a synchronized method" (marked as TBD)... but it's the first
revision, and Atmel's pretty good about revising such stuff.
So part of my question is answered! Not the ARM part, which is too bad since ARM is the widely
available platform, not AVR32.
Secondly, Sun largely (but not exclusively) maintaining control over Java means that they can continue to innovate with some measure of centralized control.
Centralized control isn't "open".
It means that Sun has the power to quash innovations it doesn't like,
or delay them until they can't be as effective,
or otherwise tilt the playing field.
That's the point of the "control" after all.
Fourth, Sun has invited a wide range of stakeholders into the JCP, including the Apache Foundation.
While it has excluded an even wider range... those too small to fork over the $$$ to join,
or too open to agree to strangling discussions with non-JCP participants for a year or two
before the JCP proposal gets to an all-but-complete late draft stage.
So what's the problem here?
Lack of openness on Sun's part.
Providing some access to the source code, at this extremely late date,
isn't much of a fix for a process that's fundamentally not open...
for a game that's stacked in favor of a certain model that hasn't even
done all that well for Sun's shareholders.
You don't need to be from IBM to be extremely skeptical about Sun's
record of open sourcing Java. They have repeatedly promised to do that,
and never done it. It's been many years now...
Do you maybe recall
the whole bit about pushing Java through ECMA? The reason that fell
down is that ECMA required real openness, and Sun was unwilling to let
the reins loose enough to achieve that. So they created their own
quasi-open "Community Process", which they control to a degree
that is completely incompatible with truly open standards. There are
in fact checklists that must be followed to get an ISO standard mark,
and many of the bullet items were things that Sun just refused to do.
People that are (still) pissed off at Sun about this are widespread
in the industry, and are not just from IBM.
Let's not forget that the Java on cellphones, J2ME, is a small subset of J2SE or J2EE.
The interpreter may not speed up too much J2SE code.
J2ME API's (maybe VM?) seem to be open source already...
My question isn't about J2ME or any blob of Sun code though.
It's about actually having an open technical ecosystem.
That said:
subset... no matter.
Once you have the virtual machine, it's up to you what
class libraries you put into it. Hardly anyone cares about the minimal
subset of J2ME, except that it allows the Java(tm) brand without forcing
all the J2SE/J2EE bloatware and legacy design crappola.
Remember, those oldest Java APIs were written by people who really did not
understand multithreading, efficient OO, or often even that much about Java.
speed... well now that's exactly the reason to want access
to the hardware interpreter that's already present. That, and expecting
the bytecodes to be a relatively efficient (and, one hopes, portable)
program representation. That wireless handheld doesn't have gobs of memory
or CPU to burn; the priority is long life out of a small battery.
Efficiency is usually more important then speed.
open source APIs... don't care. Last I heard, programming interfaces
(APIs) could not be copyrighted. Implementations could be, sure... but having
seen a lot of Sun's code, I certainly prefer the option of using something that
doesn't target a 1 GHz machine with 1 GByte of RAM and 1 GPixel display... since
each of those numbers is around four to eight times too big for even a high end
embedded handheld platform.
Remember that "run everywhere" mantra about Java? It would work a lot better
if the runtime footprint of the JVM were bearable. For embedded systems, J2SE
(and J2EE) are all but completely out of the picture. If the JVM core were all
in the hardware, the rest of the system could be quite reasonably small...
It would be interesting to know exactly how the chipmakers went about implementing the interpreters in hardware and/or firmware.
Hardware, not firmware. Some documentation talks about "bytecode accelerator",
other docs are more explicit: there's a significant subset of the Java bytecodes
that are directly executed by the hardware, just like "native" instructions.
There's a CPU mode bit that says it's executing those bytecodes rather than the
native instructions, and various types of context switches (irq, syscall, escape
to native code, implement "complex" instructions in native code, etc.) will save
restore that bit as well as other context in the Java thread.
So what's needed is to know what instructions are directly interpreted, how
to perform the context switches, and similar stuff. Routine systems programming
information, which Sun would stop locking down if it actually cared about an
open programming ecosystem.
Still wondering if this means they'll be opening up specs on how the ARM Java acceleration
works... it would be nice to have some of those free JVMs able to use that to speed up their
bytecode interpretation.
For those of you who don't know about this, most modern ARM CPUs -- like the ARM-926ejs
as found in the Nokia 770 and many cell phones -- include three processor modes:
(1) pure 32bit ARM instructions, (2) a 16-bit compressed version of ARM instructions
called "Thumb", widely used in microcontrollers, (3) an 8-bit Java bytecode interpreter.
The first two have public documentation.
But ARM won't give docs to the last out, because Sun won't let them do that; you
need a separate licence from Sun to get those documents.
So it's fully within Sun's power to open up some widely available Linux-savvy hardware
to run Java a lot better...
There's another CPU that's in the same kind of boat, the new AVR32 from Atmel.
You may have noticed that Linux 2.6.19-rc includes initial support for that architecture.
AVR32 CPUs have analogues of (1) and (3) above... but again, Atmel won't give docs to
the Java acceleration out, because Sun won't let them do that.
(And for background info: yes AVR32 is very new, likely its audience today is almost
all developers, only one model of chip available so far.)
So how about it, Sun... are you really going to open Java up??
There are a lot of embedded CPUs that have "Java Acceleration" built in.
I'm specifically concerned with ARM's Jazelle -- as found in ARM926ejs CPUs
like the one in the Nokia 770, for example, and all ARM v6 CPUs -- but there
is also Atmel's new AVR32 (Linux port is in the MM tree) and there are a
few other processors that do the same thing.
But you can't get specs on how to use that stuff... and if you ask the
chip vendors, the answer is that it's Sun's fault. To get specs, you must
sign agreements with Sun. That's for basic stuff like how to preserve the
relevant processor context, and how to enter or exit the "execute Java bytecodes"
CPU mode, and of course exactly what bytecodes exist. (They just accelerate
the bytecodes... some things need to punt to runtime code.)
What that means is that for example GCC can't use that CPU acceleration
by having its Java runtime (GCJ/GIJ) build on it... one assumes that this
means a performance penalty for at least the bytecode interpretation parts
of almost every Java runtime environment, though
of course it would be interesting seeing how things like HotSpot affect the
performance numbers. (The CPUs that have Java bytecode acceleration are by
the way not ones that normally have big CPU caches, high clock rates, or
very much memory to waste on the stuff HotSpot does.)
So my question: Is this "Open Sourced Java" going to cover ARM's Jazelle?
And the AVR32 Java acceleration? And other chips?
Or is it going to be the same-old, same-old? Folk working with embedded
systems want to know... the big system bloatware that that Sun ships is not
especially useful. Finally loosening the reins on the bytecode acceleration
hardware would be a much more useful step.
Most drivers don't need to run in kernel mode (read: any USB device driver)
Clue: don't forget to look at the _upper_ levels like the network and TTY stacks, to
which those drivers connect. The cases where Linux-USB user mode drivers are OK are those
where the upper level is essentially a userspace application... never those cases where
the upper level is a complex kernel framework. And most USB drivers fit into the latter
category.
The traditional reason why microkernels suck is because every layer crossing switches from something that costs one procedure call into something about 50x more expensive... and there are a LOT of layer crossings in a driver stack.
A true open government technique would be putting all
the documents on line, not just those selected by the
Bushist thugs that invaded the country in hope that they
might tell some favorable-to-US-war-criminals stories.
Disclosure: Resident of California.
I recall voting against this proposition,
using a paper ballot (we have the choice),
though I have no idea if my vote was actually counted.
In this case I wonder if maybe it's not possible for all of the following to be true about each member of such an advisory board:
knowedgeable about the specialized subject matter
capable of making informed judgements about it
free of financial interest in the outcomes
unbiased
The board is supposed to be chosen based on "knowledge and experience";
that implies that they're "in the field", and so the first two are clearly
true but the last two probably are not.
Would we want people _not_ to be knowledgeable about that matter?
I don't think so; that would ensure bad decisions.
There's enough specialization involved that there's no other way to
make informed judgements, as I understand things.
But that basically means people are getting paid to work in that
field, so there's no way they can be completely free of financial
interest in the series of outcome.
How much conflict is acceptable?
Catch-22
For that matter, "unbiased" is in practice impossible.
If you could get people who don't have a financial interest,
they may still have so-called "religious" interests.
(Right, we believe life is sacred.
Except if your skin color doesn't match ours, or maybe you're a woman.
Or maybe your politics are different, or you have some
resource -- oil maybe? -- we want.)
And with this much money, kickbacks can easily create
conflicts of interest where none existed before.
Now, I'd absolutely agree that the Bushistas have damaged
an important-for-humanity area of scientific research, and I
support doing that work, especially here in California where
frankly a lot of the work it would be done in any case.
(Even given the way our school systems got trashed by Prop-13.)
I read that strong "pass" for stem-cell research as being
fundamentally an extremely well deserved
slap in the face to certain fascist trends.
But I don't quite see how throwing that much money into
a process that's brand new (and hence by definition broken)
is the solution we want.
Odd how Bill Gates doesn't really like to tell the side of the
story where he stole PDP-10 time from a Seattle company (which
went out of business), one of the Universities in Seattle (which
kicked him and Paul Allen out when they found out about it), and
even Harvard University.
Yes, the PDP-10 time used to run 8080 simulators. Used to
write that initial Basic interpreter... stolen.
There were plenty of fiscally conservative Democrats too,
not to mention the tech boom.
Most of those "fiscally conservative Republicans" are
still there, but this time they're more into looting that
nice budget surplus, pocketing the bucks for their business
buddies. The "Peace Dividend" is now unquestionably gone
into already-fat corporate pockets.
This is an end-run around the requirement to provide complete and accurate
protocol documentation, for the purposes of third party inter-operation.
Notice how any third party that uses that code in lieu of the protocol
documentation is now unable to inter-operate without forking money over
to Microsoft... sleazy.
Of course, many of us have long suspected that Microsoft really doesn't
understand software engineering disciplines well enough to make their products
adhere to such specifications. They may think "here's the code"
is the best they can
do without actually revising their development practices. Well, tough
noogies, this is just the price for their previous abusive practices.
It's not news that strong partisans are, well, partisan.
The thing to notice here is that the article subject is repeating
a meme that is a Republican talking point,
getting used more and more desperately to hide rampant criminality.
No, both parties do NOT run the K street project, and the last time there
was a Democratic administration, the federal deficit SHRANK, and
we were more or less at peace with the world.
The real problem is when organizations that have traditionally been neutral arbiters, holding people to truth in public discussions, are taking sides.
That's why little-d democracy in the US is in such serious trouble lately.
It's virtually impossible to get out messages which highlight cases where
the Republican talking points are flat-out lies ("nobody could have anticipated"
New Orleans levee troubles, planes used as terror weapons, energy companies
rigging markets, etc). Lies that are shaking the constitutional foundation
of the country... rather unlike anything that's attributable to the Democrats.
Partisanship isn't so much an issue.
The problem is the extermination of honesty in
traditionally non-partisan (not bipartisan) circles.
"This year's leap second is an assault on the American public," says commentator Bill O'Reilly. "The reason the leap second is even being proposed is because of America Haters, because of Iraqi hate mongers, and let's be honest, Shiites. Why would you add a second to the year unless you're an anti-American hate monger?
I remember liberals at a party saying, 'let's add a second to the year' and I was the only one who spoke up against it. Why would they want to add a second to the year? Because it gives them a second longer to hate Bush.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?
A few things, yes.
First, that this resembles TI's OMAP chips... found in quite a lot
of cell phones. In some ways DaVinci is nicer to work with since it's
cleaner internally (fewer busses, bridges, clock domains) and externally
(pin muxing is a nightmare on OMAP). You might say that the reason
the ARM/DSP/Linux combo is now mainstream has a lot to do with preceding
generations of TI product.
Second, that this integrates essentially the top of the line DSP series
from TI... and TI is a major player in the DSP business. You've compared
that to the "XScale DSP" capabilties, which I have to take as a joke.
Third, that even its ARM is fast compared to other stuff TI has done.
Peak clock rate is half again as fast, and the memory bus is 32 bits.
(OMAP is slower and thinner, which helps give it phenominal battery life.)
So with respect to the people who've commented that the DSP programming
is sort of a different world... that's why there's a fast ARM.
Fourth, the peripheral set is way cool. Not just Video, which is
the reason folk are most interested in the DSP. But also high speed
interfaces that most ARMs don't integrate... like Ethernet, high
speed USB (OTG -- either host or peripheral), and IDE. Not just the
usual sorts of expansion connector: CompactFlash, MMC/SD,
MemoryStick, SmartMedia/NAND, etc.
... in short, this is interesting because it's a better/faster version
of something that's already proven to be successful. This time targetted
at video more than, say, cell phone.
What exactly will you be wanting to run your digital TV, by the way?
More likely this than some x86 heating element...
...are weak. A low end Pocket PC device will cost you about $110 these days. And those specs are on the low end of Pocket PC devices these days. The only advantage is a bigger screen and the notion of running a free OS. The flash memory that thing takes is uncommon and not larger than 512MB. Why not an SD/MMC slot? Or better yet, Compact Flash?
Those low end devices don't come with 802.11 support though.
And if they support CF, they suck battery power up the wazoo.
I far prefer having this longish battery life.
The SIZE -- physical dimensions, weight, etc -- of N770 are
actually quite nice. Much bigger and I'd feel uncomfortable
putting it in my pocket. Much smaller and I'd not be able to
use it in the can...;)
One of the interesting things about OMAP is the integrated
DSP. I've been lax, and haven't checked out how my N770 uses
it (or if it does)... but I'm certain that the VOIP codecs
will be using it, even if some of the current audio/video stuff
might not yet use it.
Why would you want SD, anyway? Espcially on hardware where
you're shaving every ounce of weight?
Nokia doesn't use SD, so far as I can tell, just MMC.
It's unrealistic to expect them to change corporate policy
just for this product.
As for adding software... just download the packages from
the web, over the wireless link. No need for SD.
Admittedly a 220-odd MHz ARM isn't blazingly fast. But
it's not like it's used for number crunching (that's what
DSPs are for!), and this is certainly fine for web browsing
at my local coffee shop. Or even at home.
One way to look at this is historically. And in the historical
sense, community infrastructure has only very recently come to be
seen as something that governments "should" stay out of... you know,
because if they were to offer service near cost, then more money would
stay in the hands of citizens; there wouldn't be as many ways
the corporate oligarchies could rip them off.
Notice by the way that your example of a "stable grid" for electricity assumes artificial scarcity. No reason that we couldn't
be using lots of local energy sources -- methane from recycling,
wind, solar, a factory's off-hour capacity -- and have an economy
that's not so readily gamed by the Enrons of this world.
The problem is that the prosecutors (plaintiffs?) were trying to achieve a certain result - spanking Microsoft. To accomplish this, they used the method to hand: demanding debundling.
Well, "un"bundling, but yes.
The problem was abuse-of-monopoly, and bundling was just
one part of that.
Unbundling couldn't possibly "make right" the damage.
What ever happened to "Justice"?
In the U.S.A. I know it's sold to the biggest corporate
bidder, but it's sad that the rest of the world is
being forced into that same straitjacket.
When the court system is prevented from
using more creative
remedies, they are left with ones that didn't really
address the problem... just treating a minor symptom.
More creative and effective solutions would however been things
that MSFT could probably have prevented... like putting
equal investment into bundling "competitive" products for
a few years, starting with making the APIs and protocols
no longer "proprietary".
In sort... this wasn't the right means, but it was
the only one available.
So no surprise that the ends didn't match.
Quoting the anon coward since I've no mod points today:
It's an ARM 9 based omap 1710 with up to 220mhz and a DSP. It's a nice platform / processor but the 800x480 screen make the processor sweat =)
The integrated lcd controller is probably not being used;
or maybe it is. 160 KB SRAM dedicated to it.
If this catches on, the omap 2420 based version will be
much fun to see. Those are based on ARM11 -- armv6, rather
than armv5tej -- and have much more video horsepower.
Problem is, many states don't have laws against frivilous [sic] lawsuits...
But many, including California, have laws against SLAPP lawsuits,
and this would seem to fit firmly into that category.
SLAPP == Strategic Lawsuit Against Public Participation, as I recall.
Where "public participation" has to do with maintaining the
Commons, e.g. if Corporation X sues Joe Penguin for speaking up
against it in a public forum, then Joe can relatively
inexpensively file to have it dismissed as a SLAPP suit...
and Joe can collect triple damages if it's established that
the suit was just to prevent Joe from opposing that
toxic waste dump (or equivalent).
This is why we need tort reform like Newt Gingrich was touting in his contract with America...
Two things wrong there, and before you even finished the
sentence!
We don't need "tort reform" in any sense that's been
widely discussed. The abusers of the legal system are
primarily corporations; look at the statistics.
In this case, it's a corporation suing... in other cases,
it's often corporations selling faulty products since they
know Deep Pockets Win, except in class action lawsuits which
can tap many pocket.
But all the "reforms" so far
presented by Republicans (and corporate lawyers) are geared
at removing what limited recourse individuals have against
those corporations.
That should be Contract on America to be
precise. Yes, the title has been widely misquoted forever,
but if you look at the details you see what's up.
That article was rather devoid of essential facts; I'd
really like to know if for example California's SLAPP statute
could apply. (Many other states have them too.)
Slashdot Mirror
That's one formulation. Others are more general, and address the fact that the reason the source matters to the would-be-throttler is specifically because of its content type; or equivalently, that the source can be viewed as an attribute of the type. (Video from ISP != Video from third-party, etc.) And in any case, claiming that throttling all encrypted traffic is even vaguely neutral boggles the mind ... this fits clearly in the core of any kind of common-sense definition of neutral data carriage.
Consider the costs for one employee to own one car for 5 years. Ballpark figures: car at $30K, insurance $1K/year, maintainance and fuel $2K/year, $45K total, $9K/year. If that employee doesn't need to own that car, one could argue that his/her salary can be $9K less. Does that employee's shuttle service cost that much? No way ...
Now, not ever employee can (finally) do without owning an automobile. But many can. And Google wouldn't need to spend as much supporting parking lots (they have a BIG parking problem anyway). So net costs to the company could easily go down because they stop externalizing transportation costs to employees, and into their salaries.
Maybe that accounting is a bit of a pipe dream right now, but eventually people will start to account for costs that certain industries (oil, auto, steel, rubber, etc) would rather be scattered into individual paychecks ... and notice how much waste is factored into our current industrial structures. Google IS cutting those costs right now.
From a voting-integrity perspective, that's exactly what voting machines should do! Play to the strengths of computer tech -- namely flexible UI that can help address issues of handicap and language, and producing low-spoilage ballots -- while not sacrificing auditability.
The team that designed that voting tech is the **FIRST** one I've ever heard of doing the obviously-correct thing: make voting easier, not counting.
Ooh, I hate to reply to myself, but this is good news.
It turns out that Atmel just published the AVR32 Java Technical Reference Manual giving exactly the information I was asking about. Probably about 40 hours before I posted; sigh. I guess that Atmel guy was wrong when he said they couldn't publish that information ...
I've only skimmed those docs, so I can only say that they look like the right thing but clearly omit things like "how to invoke a synchronized method" (marked as TBD) ... but it's the first
revision, and Atmel's pretty good about revising such stuff.
So part of my question is answered! Not the ARM part, which is too bad since ARM is the widely available platform, not AVR32.
Centralized control isn't "open". It means that Sun has the power to quash innovations it doesn't like, or delay them until they can't be as effective, or otherwise tilt the playing field. That's the point of the "control" after all.
While it has excluded an even wider range ... those too small to fork over the $$$ to join,
or too open to agree to strangling discussions with non-JCP participants for a year or two
before the JCP proposal gets to an all-but-complete late draft stage.
Lack of openness on Sun's part. Providing some access to the source code, at this extremely late date, isn't much of a fix for a process that's fundamentally not open ...
for a game that's stacked in favor of a certain model that hasn't even
done all that well for Sun's shareholders.
You don't need to be from IBM to be extremely skeptical about Sun's record of open sourcing Java. They have repeatedly promised to do that, and never done it. It's been many years now ...
Do you maybe recall the whole bit about pushing Java through ECMA? The reason that fell down is that ECMA required real openness, and Sun was unwilling to let the reins loose enough to achieve that. So they created their own quasi-open "Community Process", which they control to a degree that is completely incompatible with truly open standards. There are in fact checklists that must be followed to get an ISO standard mark, and many of the bullet items were things that Sun just refused to do.
People that are (still) pissed off at Sun about this are widespread in the industry, and are not just from IBM.
My question isn't about J2ME or any blob of Sun code though. It's about actually having an open technical ecosystem. That said:
Remember that "run everywhere" mantra about Java? It would work a lot better if the runtime footprint of the JVM were bearable. For embedded systems, J2SE (and J2EE) are all but completely out of the picture. If the JVM core were all in the hardware, the rest of the system could be quite reasonably small ...
Hardware, not firmware. Some documentation talks about "bytecode accelerator", other docs are more explicit: there's a significant subset of the Java bytecodes that are directly executed by the hardware, just like "native" instructions. There's a CPU mode bit that says it's executing those bytecodes rather than the native instructions, and various types of context switches (irq, syscall, escape to native code, implement "complex" instructions in native code, etc.) will save restore that bit as well as other context in the Java thread.
So what's needed is to know what instructions are directly interpreted, how to perform the context switches, and similar stuff. Routine systems programming information, which Sun would stop locking down if it actually cared about an open programming ecosystem.
Still wondering if this means they'll be opening up specs on how the ARM Java acceleration works ... it would be nice to have some of those free JVMs able to use that to speed up their
bytecode interpretation.
For those of you who don't know about this, most modern ARM CPUs -- like the ARM-926ejs as found in the Nokia 770 and many cell phones -- include three processor modes: (1) pure 32bit ARM instructions, (2) a 16-bit compressed version of ARM instructions called "Thumb", widely used in microcontrollers, (3) an 8-bit Java bytecode interpreter. The first two have public documentation. But ARM won't give docs to the last out, because Sun won't let them do that; you need a separate licence from Sun to get those documents. So it's fully within Sun's power to open up some widely available Linux-savvy hardware to run Java a lot better ...
There's another CPU that's in the same kind of boat, the new AVR32 from Atmel. You may have noticed that Linux 2.6.19-rc includes initial support for that architecture. AVR32 CPUs have analogues of (1) and (3) above ... but again, Atmel won't give docs to
the Java acceleration out, because Sun won't let them do that.
(And for background info: yes AVR32 is very new, likely its audience today is almost
all developers, only one model of chip available so far.)
So how about it, Sun ... are you really going to open Java up??
There are a lot of embedded CPUs that have "Java Acceleration" built in. I'm specifically concerned with ARM's Jazelle -- as found in ARM926ejs CPUs like the one in the Nokia 770, for example, and all ARM v6 CPUs -- but there is also Atmel's new AVR32 (Linux port is in the MM tree) and there are a few other processors that do the same thing.
But you can't get specs on how to use that stuff ... and if you ask the
chip vendors, the answer is that it's Sun's fault. To get specs, you must
sign agreements with Sun. That's for basic stuff like how to preserve the
relevant processor context, and how to enter or exit the "execute Java bytecodes"
CPU mode, and of course exactly what bytecodes exist. (They just accelerate
the bytecodes ... some things need to punt to runtime code.)
What that means is that for example GCC can't use that CPU acceleration by having its Java runtime (GCJ/GIJ) build on it ... one assumes that this
means a performance penalty for at least the bytecode interpretation parts
of almost every Java runtime environment, though
of course it would be interesting seeing how things like HotSpot affect the
performance numbers. (The CPUs that have Java bytecode acceleration are by
the way not ones that normally have big CPU caches, high clock rates, or
very much memory to waste on the stuff HotSpot does.)
So my question: Is this "Open Sourced Java" going to cover ARM's Jazelle? And the AVR32 Java acceleration? And other chips?
Or is it going to be the same-old, same-old? Folk working with embedded systems want to know... the big system bloatware that that Sun ships is not especially useful. Finally loosening the reins on the bytecode acceleration hardware would be a much more useful step.
Clue: don't forget to look at the _upper_ levels like the network and TTY stacks, to which those drivers connect. The cases where Linux-USB user mode drivers are OK are those where the upper level is essentially a userspace application ... never those cases where
the upper level is a complex kernel framework. And most USB drivers fit into the latter
category.
The traditional reason why microkernels suck is because every layer crossing switches from something that costs one procedure call into something about 50x more expensive ... and there are a LOT of layer crossings in a driver stack.
Certainly about "any USB driver".
A true open government technique would be putting all the documents on line, not just those selected by the Bushist thugs that invaded the country in hope that they might tell some favorable-to-US-war-criminals stories.
Do not be decieved.
Disclosure: Resident of California. I recall voting against this proposition, using a paper ballot (we have the choice), though I have no idea if my vote was actually counted.
In this case I wonder if maybe it's not possible for all of the following to be true about each member of such an advisory board:
The board is supposed to be chosen based on "knowledge and experience"; that implies that they're "in the field", and so the first two are clearly true but the last two probably are not.
Would we want people _not_ to be knowledgeable about that matter? I don't think so; that would ensure bad decisions. There's enough specialization involved that there's no other way to make informed judgements, as I understand things.
But that basically means people are getting paid to work in that field, so there's no way they can be completely free of financial interest in the series of outcome. How much conflict is acceptable? Catch-22
For that matter, "unbiased" is in practice impossible. If you could get people who don't have a financial interest, they may still have so-called "religious" interests. (Right, we believe life is sacred. Except if your skin color doesn't match ours, or maybe you're a woman. Or maybe your politics are different, or you have some resource -- oil maybe? -- we want.) And with this much money, kickbacks can easily create conflicts of interest where none existed before.
Now, I'd absolutely agree that the Bushistas have damaged an important-for-humanity area of scientific research, and I support doing that work, especially here in California where frankly a lot of the work it would be done in any case. (Even given the way our school systems got trashed by Prop-13.) I read that strong "pass" for stem-cell research as being fundamentally an extremely well deserved slap in the face to certain fascist trends.
But I don't quite see how throwing that much money into a process that's brand new (and hence by definition broken) is the solution we want.
Odd how Bill Gates doesn't really like to tell the side of the story where he stole PDP-10 time from a Seattle company (which went out of business), one of the Universities in Seattle (which kicked him and Paul Allen out when they found out about it), and even Harvard University.
Yes, the PDP-10 time used to run 8080 simulators. Used to write that initial Basic interpreter ... stolen.
Pot. Kettle. Black.
There were plenty of fiscally conservative Democrats too, not to mention the tech boom.
Most of those "fiscally conservative Republicans" are still there, but this time they're more into looting that nice budget surplus, pocketing the bucks for their business buddies. The "Peace Dividend" is now unquestionably gone into already-fat corporate pockets.
This is an end-run around the requirement to provide complete and accurate protocol documentation, for the purposes of third party inter-operation.
Notice how any third party that uses that code in lieu of the protocol documentation is now unable to inter-operate without forking money over to Microsoft ... sleazy.
Of course, many of us have long suspected that Microsoft really doesn't understand software engineering disciplines well enough to make their products adhere to such specifications. They may think "here's the code" is the best they can do without actually revising their development practices. Well, tough noogies, this is just the price for their previous abusive practices.
It's not news that strong partisans are, well, partisan. The thing to notice here is that the article subject is repeating a meme that is a Republican talking point, getting used more and more desperately to hide rampant criminality. No, both parties do NOT run the K street project, and the last time there was a Democratic administration, the federal deficit SHRANK, and we were more or less at peace with the world.
The real problem is when organizations that have traditionally been neutral arbiters, holding people to truth in public discussions, are taking sides.
That's why little-d democracy in the US is in such serious trouble lately. It's virtually impossible to get out messages which highlight cases where the Republican talking points are flat-out lies ("nobody could have anticipated" New Orleans levee troubles, planes used as terror weapons, energy companies rigging markets, etc). Lies that are shaking the constitutional foundation of the country ... rather unlike anything that's attributable to the Democrats.
Partisanship isn't so much an issue. The problem is the extermination of honesty in traditionally non-partisan (not bipartisan) circles.
Wait ... don't you know that
leap second lovers are traitors?
I think he's on (to) something.
A few things, yes.
First, that this resembles TI's OMAP chips ... found in quite a lot
of cell phones. In some ways DaVinci is nicer to work with since it's
cleaner internally (fewer busses, bridges, clock domains) and externally
(pin muxing is a nightmare on OMAP). You might say that the reason
the ARM/DSP/Linux combo is now mainstream has a lot to do with preceding
generations of TI product.
Second, that this integrates essentially the top of the line DSP series from TI ... and TI is a major player in the DSP business. You've compared
that to the "XScale DSP" capabilties, which I have to take as a joke.
Third, that even its ARM is fast compared to other stuff TI has done. Peak clock rate is half again as fast, and the memory bus is 32 bits. (OMAP is slower and thinner, which helps give it phenominal battery life.) So with respect to the people who've commented that the DSP programming is sort of a different world ... that's why there's a fast ARM.
Fourth, the peripheral set is way cool. Not just Video, which is the reason folk are most interested in the DSP. But also high speed interfaces that most ARMs don't integrate ... like Ethernet, high
speed USB (OTG -- either host or peripheral), and IDE. Not just the
usual sorts of expansion connector: CompactFlash, MMC/SD,
MemoryStick, SmartMedia/NAND, etc.
... in short, this is interesting because it's a better/faster version of something that's already proven to be successful. This time targetted at video more than, say, cell phone. What exactly will you be wanting to run your digital TV, by the way? More likely this than some x86 heating element...
Costs $300 retail? That's comparable to the N770. NOT comparable to the $100 low-end job the other writer described.
Those low end devices don't come with 802.11 support though. And if they support CF, they suck battery power up the wazoo. I far prefer having this longish battery life.
The SIZE -- physical dimensions, weight, etc -- of N770 are actually quite nice. Much bigger and I'd feel uncomfortable putting it in my pocket. Much smaller and I'd not be able to use it in the can ... ;)
One of the interesting things about OMAP is the integrated DSP. I've been lax, and haven't checked out how my N770 uses it (or if it does) ... but I'm certain that the VOIP codecs
will be using it, even if some of the current audio/video stuff
might not yet use it.
Why would you want SD, anyway? Espcially on hardware where you're shaving every ounce of weight? Nokia doesn't use SD, so far as I can tell, just MMC. It's unrealistic to expect them to change corporate policy just for this product.
As for adding software ... just download the packages from
the web, over the wireless link. No need for SD.
Admittedly a 220-odd MHz ARM isn't blazingly fast. But it's not like it's used for number crunching (that's what DSPs are for!), and this is certainly fine for web browsing at my local coffee shop. Or even at home.
Neither road nor car is a "service". They're both objects.
Policing roads ... service.
Cleaning them, snowplowing, maintaining ... service.
Your position is clearly bogus!
One way to look at this is historically. And in the historical sense, community infrastructure has only very recently come to be seen as something that governments "should" stay out of ... you know,
because if they were to offer service near cost, then more money would
stay in the hands of citizens; there wouldn't be as many ways
the corporate oligarchies could rip them off.
Notice by the way that your example of a "stable grid" for electricity assumes artificial scarcity. No reason that we couldn't be using lots of local energy sources -- methane from recycling, wind, solar, a factory's off-hour capacity -- and have an economy that's not so readily gamed by the Enrons of this world.
Well, "un"bundling, but yes. The problem was abuse-of-monopoly, and bundling was just one part of that. Unbundling couldn't possibly "make right" the damage. What ever happened to "Justice"? In the U.S.A. I know it's sold to the biggest corporate bidder, but it's sad that the rest of the world is being forced into that same straitjacket.
When the court system is prevented from using more creative remedies, they are left with ones that didn't really address the problem ... just treating a minor symptom.
More creative and effective solutions would however been things
that MSFT could probably have prevented ... like putting
equal investment into bundling "competitive" products for
a few years, starting with making the APIs and protocols
no longer "proprietary".
In sort ... this wasn't the right means, but it was
the only one available.
So no surprise that the ends didn't match.
Quoting the anon coward since I've no mod points today:
The integrated lcd controller is probably not being used; or maybe it is. 160 KB SRAM dedicated to it.
If this catches on, the omap 2420 based version will be much fun to see. Those are based on ARM11 -- armv6, rather than armv5tej -- and have much more video horsepower.
Linux 2.6.12 ... ;)
But many, including California, have laws against SLAPP lawsuits, and this would seem to fit firmly into that category. SLAPP == Strategic Lawsuit Against Public Participation, as I recall. Where "public participation" has to do with maintaining the Commons, e.g. if Corporation X sues Joe Penguin for speaking up against it in a public forum, then Joe can relatively inexpensively file to have it dismissed as a SLAPP suit ...
and Joe can collect triple damages if it's established that
the suit was just to prevent Joe from opposing that
toxic waste dump (or equivalent).
Two things wrong there, and before you even finished the sentence!
That article was rather devoid of essential facts; I'd really like to know if for example California's SLAPP statute could apply. (Many other states have them too.)
That's an OS used in deeply embedded environments called "cell phones". There's a real-time version.
Or is that all userspace code, not kernel code? Looked to me like both use C++.