It's actually designed to be a spam generating spy device anyway, while remaining unrooted. Give a look at the permissions required by ad-supported applications.
N900's "crippled radio" has a pretty standard 900 / 1700 / 2100 HSDPA support, which according to Wikipedia covers Europe, Asia, Africa, Oceania, Brazil, Canada, Dominican Republic and Venezuela. And apparently T-Mobile somewhere in the USA.
That makes quite a lot of people and some of them might be reading Slashdot, don't you think?
I don't know any list which includes local broadcasters; this site (it's in Italian, but there's not much text anyway, you just choose a city and it spits out frequencies) gives some coverage information, but only for nation-wide channels. Typically each town receives its local tv stations and those from neighbouring cities, adding ~10 channels to the count.
By the way, I have to correct my post, because not all of the channels are free-to-air, many are encrypted.
Does this apply to the whole Europe? I live in a god-forgotten small town in southern Europe and still I receive about 70 free-to-air channels on DVB-T, most of which come from small or local broadcasters.
On DVB-S I receive many more than the 999 channels my decade-old receiver is able to memorize, and that includes TBN broadcast in my language.
By this reasoning, no programming language is "basically really original".
The point of my post wasn't that Java hadn't roots in older languages, it was that many newer languages have roots in Java.
For instance, Microsoft - let's say so - drew quite a lot of inspiration from Java when they designed the language they now recommend for Windows development. Evidently they found in Java some value you don't recognize.
What I found "original" in Java was the way it was put together:
no-nonsense design, with all complex features from C (preprocessor...) and C++ (multiple inheritance...) stripped;
well-defined (and simple) relationship between the namespace and the filesystem;
establishment of the class as the new atomic unit for code structure (so classes replace enums/struct/unions, importing classes replaces libraries...);
self-documenting code and standardized tools to manage it;
enforcement of programming best practices: fixed bound checking, automatic memory management, compile-time consistency checks (the original Java compiler never generated warnings!);
design of the virtual machine and of the output binary format standardized at language level;
all of this, with a focus on implementability rather than academic elegance (unicode everywhere, primitive types for speed...).
I actually liked the "blue collar" orientation of the original Java. When CS professors meddled with the language, we got Java 5's generics:-) .
Well, it's better than "A Smalltalk ripoff with deficiencies", which is what Java is. Oh, some people rather argue that it's "C++ ripoff with deficiencies", but that's even worse. ~
On a serious note, though, the entire history of computer science is "ripping off" someone, and even more so when it comes to languages. Ultimately it's all a rip off FORTRAN, Algol-60 and Lisp, since everyone else came after and mostly rehashed those same ideas, sometimes adding little bits in between.
While I somewhat agree with you and I think that "ripping off" is normal and should even be encouraged, let's give the credit where it belongs. While Java reuses Smalltalk concepts (bytecode and object orientation?), Java and Smalltalk are two completely different languages, with diverging philosophies and incomparable syntax. Can you say the same about Java and the original C#? Some code could be converted between the languages with a battery of regexp substitutions!
Python with Gtk+ or Qt is a much better cross-platform environment than Java: easier to develop for, with better desktop integration, and nicer looking UIs.
It depends. Gtk+ is "better integrated" only if you're using Gnome. On Windows or even KDE, Gtk+ applications don't look much less "alien" than Java applications using the native toolkit. You can use Qt from Java, too, if you really want to - Qt is not more "native" to Python than it is to Java.
Also, Java is orders of magnitude faster than Python.
Gtk+, Qt, and wx all are cross-platform toolkits, better than anything Java has ever provided.
Java provides a standard library comprising a lot of stuff out of the box: collections, string handling, math, network access, serialization, 2d vector graphics, data compression, reflection, internationalization, accessibility, text encoding, an opentype renderer, multimedia, a document editor with html rendering support, image I/O, a midi wavetable, a javascript interpreter, xml I/O, a compiler interface, fullscreen graphics. All of this is available with identical functionality across all of the supported platforms (there are no second-class citizens). I don't know any other single development platform that provides *all* of this.
While this has nothing to do with the language and the virtual machine, a difference I see between Java and.NET is in the implementation of the standard library. In Java I can "step into" the source code of standard classes up to the most abstract level, and unless we're talking about something performance-critical, I always read pure Java source code, which I can understand and learn.
In.NET, more often I stumble in some "sealed" class that is a thin wrapper of some Windows object, from which you can even obtain some OS-specific handle, and are encouraged to use P/Invoke to access Windows-specific features.
It looks like a very different philosophy to me, and definitely something that advantages a Windows-only implementation.
There's a clear distinction between honesty and rudeness. Your analogy would be appropriate if the alternative was between telling your wife that you think she's fat, in the most appropriate way, or keeping it for yourself, which is clearly the wrong choice.
And instead you would be trying to juggle the fun of "Application x runs only on Foobar version y, Application xx runs only on Foobar version y SP2, and Foobar y and Foobar y SP2 don't get along at all."
HDCP does not protect content which has already been ripped. HDCP was designed for the sole purpose of preventing people from "ripping" content they paid for, so the GP is right, except for the fact that DVDs do not require HDCP, so he should be talking about blu-ray / hd-dvd / digital downloads instead.
HDCP also makes his hardware more expensive, more power-hungry and more complex, thus more likely to be buggy (I've heard many stories of troubles due to HDCP incompatibilities/bugs).
I still don't know your opinion about two facts I mentioned in my post, which seem pretty evident to me:
1) Geohot himself said his exploit could be used to run pirated games. Is he wrong about his own work?
2) OtherOS was the preferred way for end users to apply to their console any exploit found by hackers. For instance, geohot's hack required Linux (and some hardware). Such exploits could patch GameOS from Linux, to play games in GameOS. The least Sony could do, from their point of view of course, would be to deprive the users of this commodity.
And I would also add, 3) Less OtherOS-enabled consoles in the wild means less curious eyes peeking at Sony's hypervisor bugs.
As for running games under Linux, I do not have sufficient technical knowledge of the console to speculate about the feasibility of such an option. After having OtherOS dumped, I don't see why an architecture with virtualization support couldn't emulate a different operating system, even by ripping and patching the game code if necessary. It's not a matter of running two kernels at the same time, but rather of making one kernel expose the application interface of the other. Or, a jailbroken Linux kernel might even kexec a patched image of OtherOS if necessary. I think the problems would probably derive more from Cell's security features than from technical limitations.
Oh, please, do not deny what is evident. Once you got full control of the hardware, nothing stops you from dumping OtherOS and running pirated games from Linux. Or more easily, patch the OtherOS to allow running backup copies: geohot himself showed on his blog (only screenshots of) a evidently patched OtherOS.
See how geohot was happy to admit he was searching for the Cell root key and that his exploit could be used to run pirate games.
The point of removing the OtherOS was not to stop hackers from analysing the PS3, it was to remove a convenient way for *end users* to apply hackers' findings on their machines.
Sadly for Sony, somebody found an even more convenient way...
I think you have to see it as a next-gen tv out. HDMI will probably be *the* preferred way to connect video sources and sinks together, even when "HD" features are not strictly required.
Example use case 1: you're on holiday at the end of a day and want to show your friends the pictures you've taken that morning.
Example use case 2: you're in a hotel room and there's nothing good on TV, so you might watch a movie you stored on your phone.
As for the iPhone, it is traditionally slow in getting new features, for instance it got a front facing camera in 2010. You'll see that next year's iPhone will have a (an?) HDMI output.
From what he says I understand that 5 megapixels on a cellphone are gimmick, no matter how expensive the phone is, because it's not technically possible to build a lens + sensor combination which is able to achieve a 5 megapixel still image in a smartphone form factor. Is there a physical law that dictates this? Aren't we well above the diffraction limit in current phone cameras?
See for yourself, I've not found much Qualcomm information but Texas Instruments publishes a lot of documentation about their smartphone platforms.
From a quick read of the user quide I see that their OMAP3 platform apparently has two modules for the camera interface; a "Camera ISP" module which fetches data from the CCD in raw, yuv, rgb or jpeg format, and a "IVA" module, which appears to be a DSP with hardcoded functionality for mainstream codecs but can also be programmed for what they call "emerging" codecs. This module can then DMA its output to the application CPU module. All the cores are on the same SOC and are interconnected with two Sonics buses, one of which must bear the bandwidth of the data coming from the sensor.
What's impressive is that there is much less hardcoded logic involved than one might think. The OMAP4 leaflet claims its IVA core can deliver 30fps 1080p encoding and decoding for h.264 hp, mpeg4 asp, vc-1 ap, mpeg2 mp and on2 vp7.
No, I think the CCD feeds the stream using some proprietary bus to some ASIC, and this one makes the compressed frames available to application CPUs via some kind of DMA. I think this, because not even desktop CPUs can compress 1080p h.264 in realtime, and we're talking about a phone here.
The point is that you can't have all the pixels if the movie resolution is limited to 720p. You lose them in the camera. We're talking about movies here, not photos.
Slashdot Mirror
100 meg java SDK [...] yes its bloated
The java SDK takes 554M when installed. The android SDK takes 1,1G. Define "bloat".
It's actually designed to be a spam generating spy device anyway, while remaining unrooted. Give a look at the permissions required by ad-supported applications.
That makes quite a lot of people and some of them might be reading Slashdot, don't you think?
By the way, I have to correct my post, because not all of the channels are free-to-air, many are encrypted.
On DVB-S I receive many more than the 999 channels my decade-old receiver is able to memorize, and that includes TBN broadcast in my language.
The point of my post wasn't that Java hadn't roots in older languages, it was that many newer languages have roots in Java.
For instance, Microsoft - let's say so - drew quite a lot of inspiration from Java when they designed the language they now recommend for Windows development. Evidently they found in Java some value you don't recognize.
What I found "original" in Java was the way it was put together:
I actually liked the "blue collar" orientation of the original Java. When CS professors meddled with the language, we got Java 5's generics :-) .
Qt is not part of Java.
Neither it is part of Python or Ruby, and the same is true for GTK+; what's the point?
If only; many of those libraries are add-ons that don't work properly, or don't work at all on, say, Linux.
The ones I mentioned are core libraries. They are included and, bugs apart, should work the same in Windows, Linux, Solaris and OS X.
Well, if you load a class that exposes such array, you *can* tell what the generic type is through reflection, using getGenericType().
While I somewhat agree with you and I think that "ripping off" is normal and should even be encouraged, let's give the credit where it belongs. While Java reuses Smalltalk concepts (bytecode and object orientation?), Java and Smalltalk are two completely different languages, with diverging philosophies and incomparable syntax. Can you say the same about Java and the original C#? Some code could be converted between the languages with a battery of regexp substitutions!
Python with Gtk+ or Qt is a much better cross-platform environment than Java: easier to develop for, with better desktop integration, and nicer looking UIs.
It depends. Gtk+ is "better integrated" only if you're using Gnome. On Windows or even KDE, Gtk+ applications don't look much less "alien" than Java applications using the native toolkit. You can use Qt from Java, too, if you really want to - Qt is not more "native" to Python than it is to Java.
Also, Java is orders of magnitude faster than Python.
Gtk+, Qt, and wx all are cross-platform toolkits, better than anything Java has ever provided.
Java provides a standard library comprising a lot of stuff out of the box: collections, string handling, math, network access, serialization, 2d vector graphics, data compression, reflection, internationalization, accessibility, text encoding, an opentype renderer, multimedia, a document editor with html rendering support, image I/O, a midi wavetable, a javascript interpreter, xml I/O, a compiler interface, fullscreen graphics. All of this is available with identical functionality across all of the supported platforms (there are no second-class citizens). I don't know any other single development platform that provides *all* of this.
In .NET, more often I stumble in some "sealed" class that is a thin wrapper of some Windows object, from which you can even obtain some OS-specific handle, and are encouraged to use P/Invoke to access Windows-specific features.
It looks like a very different philosophy to me, and definitely something that advantages a Windows-only implementation.
There's a clear distinction between honesty and rudeness. Your analogy would be appropriate if the alternative was between telling your wife that you think she's fat, in the most appropriate way, or keeping it for yourself, which is clearly the wrong choice.
That might be why Sun also produces a Fortran compiler.
because there are competing languages
You must take into account how much of their original design was "inherited" from Java.
And instead you would be trying to juggle the fun of "Application x runs only on Foobar version y, Application xx runs only on Foobar version y SP2, and Foobar y and Foobar y SP2 don't get along at all."
HDCP also makes his hardware more expensive, more power-hungry and more complex, thus more likely to be buggy (I've heard many stories of troubles due to HDCP incompatibilities/bugs).
1) Geohot himself said his exploit could be used to run pirated games. Is he wrong about his own work?
2) OtherOS was the preferred way for end users to apply to their console any exploit found by hackers. For instance, geohot's hack required Linux (and some hardware). Such exploits could patch GameOS from Linux, to play games in GameOS. The least Sony could do, from their point of view of course, would be to deprive the users of this commodity.
And I would also add, 3) Less OtherOS-enabled consoles in the wild means less curious eyes peeking at Sony's hypervisor bugs.
As for running games under Linux, I do not have sufficient technical knowledge of the console to speculate about the feasibility of such an option. After having OtherOS dumped, I don't see why an architecture with virtualization support couldn't emulate a different operating system, even by ripping and patching the game code if necessary. It's not a matter of running two kernels at the same time, but rather of making one kernel expose the application interface of the other. Or, a jailbroken Linux kernel might even kexec a patched image of OtherOS if necessary. I think the problems would probably derive more from Cell's security features than from technical limitations.
See how geohot was happy to admit he was searching for the Cell root key and that his exploit could be used to run pirate games.
The point of removing the OtherOS was not to stop hackers from analysing the PS3, it was to remove a convenient way for *end users* to apply hackers' findings on their machines.
Sadly for Sony, somebody found an even more convenient way...
Example use case 1: you're on holiday at the end of a day and want to show your friends the pictures you've taken that morning.
Example use case 2: you're in a hotel room and there's nothing good on TV, so you might watch a movie you stored on your phone.
As for the iPhone, it is traditionally slow in getting new features, for instance it got a front facing camera in 2010. You'll see that next year's iPhone will have a (an?) HDMI output.
From what he says I understand that 5 megapixels on a cellphone are gimmick, no matter how expensive the phone is, because it's not technically possible to build a lens + sensor combination which is able to achieve a 5 megapixel still image in a smartphone form factor. Is there a physical law that dictates this? Aren't we well above the diffraction limit in current phone cameras?
From a quick read of the user quide I see that their OMAP3 platform apparently has two modules for the camera interface; a "Camera ISP" module which fetches data from the CCD in raw, yuv, rgb or jpeg format, and a "IVA" module, which appears to be a DSP with hardcoded functionality for mainstream codecs but can also be programmed for what they call "emerging" codecs. This module can then DMA its output to the application CPU module. All the cores are on the same SOC and are interconnected with two Sonics buses, one of which must bear the bandwidth of the data coming from the sensor.
What's impressive is that there is much less hardcoded logic involved than one might think. The OMAP4 leaflet claims its IVA core can deliver 30fps 1080p encoding and decoding for h.264 hp, mpeg4 asp, vc-1 ap, mpeg2 mp and on2 vp7.
No, I think the CCD feeds the stream using some proprietary bus to some ASIC, and this one makes the compressed frames available to application CPUs via some kind of DMA. I think this, because not even desktop CPUs can compress 1080p h.264 in realtime, and we're talking about a phone here.
The point is that you can't have all the pixels if the movie resolution is limited to 720p. You lose them in the camera. We're talking about movies here, not photos.
Whoops, it's probably "exposure" not "exposition". Sorry, not my language :P