There's a major difference you're not realizing. Java does not use 'arrays' in the classical sense (probably like many other languages with a VM).
In fact, a Java array is not even necessarily in the same congtiguous block of memory, while an array in C is. This holds for arrays of Objects as well as arrays of primitive types.
A Java array is essentially like any other object managed by the JVM but with syntactical support for indexing.
If you've ever used a C struct and some function pointers before, you could easily create a managed array 'class' in C. 'Object oriented' programming in C is used far more than you might think.
Poorly written code is the cause of buffer overflows, and naive programmers tend to make that very apparent when they write in C.
A few months ago, wasn't he going on about an economic rescue something or other?
In my opinion (although I am Canadian, but my opinion applies equally to my homeland as well), civil budgets should be one of the primary figures available to all on data.gov. That way, careless spending could be fairly easily monitored (potentially automatically).
This is utterly ridiculous... do people really find it that difficult to change the theme if they don't like it?
I promise, that it will not be torturous, nor will it inflict physical or psychological pain on anyone to simply go to System, Preferences, and Appearance to change the theme to what they've grown accustomed to.
It is Shuttleworth's distribution, and he can do with it what he wants. If he believes that these slight aesthetic changes will make him more money, then he has the freedom to make those changes.
Similarly, anyone else has the freedom to modify the default installation ISO to use the classic theme, if they prefer.
today's smartphones are all about the 'software stack,' not the 'radio stack,'
The referenced article is not exactly valid. The author is spouting off historical common-knowledge to hopefully gain literary credibility, and must lack the technical expertise to be authoritative on the topic... more about that later.
The entire point of the article is to say that Microsoft approves of Apple for suing other companies (both Nokia and HTC now) over software patents.
The systems in question (mobile devices with loads of integrated wireless technology) are a sort of fusion of tightly-coupled hardware and software. Essentially, the software part is a device driver, whether it's communicating with an RF frontend or reading bytes from a capacitive touchscreen (which is why Apple has no grounds to be suing anybody right now). Also, Apple originally denied licensing their touchscreen software to Nokia in the first place, so they are essentially monopolizing it.
What this boils down to, is that some things are patentable while others are not. The capacitive touchscreen design - the physical form, the novel arrangement of metals and plastics and capacitive material - is patentable. The RF Frontend is (potentially) patentable, novel dedicated circuits for decoding baseband information are patentable. Reading bytes from an N-pin connector and interpreting those bytes is not patentable.
Now, to address the 'radio stacks are trivial comment': although the baseband portion (i decline to use the term radio here) does use a large part of software, that concept is already quite old.
Software-defined-radio was originally designed back when certain radio technologies were still young and they needed an easily reconfigurable transceiver. Transceiver technology has had quite a bit of time to mature since then, and now that we are approaching the theoretical limit of wireless channel capacity, companies are turning toward dedicated silicon. Dedicated circuits have the benefit of increased speed as well as the benefit of decreased power consumption (all that and more!), when compared to a general purpose dsp. When it's economically viable for a company to produce a dedicated circuit, then they usually will, and they should seek a patent for that device.
The aforementioned dedicated circuits ARE patentable, but the software used to control them is NOT.
This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.
On the other hand, I do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise. However, the electrical & computer systems on automobiles should really be considered one in the same. They are the left and right hands of an entity and need to communicate effectively with each other. If there is electrical interference, then the signal processing system should take that into consideration and filter it out. If there is too much electrical interference, then the electronics should be re-designed!
Wouldn't it be hilarious if you were pedestering in some urban center, and you notice two guys with the same 'sun glasses'. Then those two guys notice eachother, and then a virtual light-saber battle ensues?
Then somebody takes out their Nexus One to instantly upload a video of that event to youtube, and by the time you pedester to your destination, you could backtrack on Google Maps and find a link to an augmented video of the entire event. Wouldn't that be cool?
Yeah, it would be pretty cool. Of course, I would never engage in a virtual battle like that personally because that is waaaay beyond my geek tolerance, but it would be entertaining as a spectator;-)
( 0 - 1 ) mod 8 = 255 mod 8 ?
Could also be some lazy ass not properly checking the sign of a return value (-1 often usually means error), and then passing it to another function as an unsigned value.
Funny that people often think that dsp / computer engineers have less pressure to be legally responsible for the breakages caused by their broken code. If a wall fell over and killed someone because the engineer messed up the decimal point, then there would definitely be some legal action.
First of all, it's important to distinguish that RS-232 is just a signalling convention. RS-232 requires an RS-232 transceiver, exactly the same way that USB requires a USB transceiver. Both of these technologies are for serial communication. Both of these technologies can be backed by a UART (see Catsoulis) but USB often skips the UART backend, opting for direct access instead. What you're really talking about is replacing the traditional RS-232 transceiver with a USB transceiver on devices. Sure, why not?
Reason 1) a UART is absolutely crucial for OS debugging, boot loader debugging, and recovery from corrupt nand, because it's cheap, simple, and sufficient. Often (especially when reverse engineering a device) a UART can be the only way to interact with the OS during the porting phase.
Reason 2) Although most (decent) OS have a USB stack that will work in both host and device mode simultaneously, often there is some external hardware preventing direct usage of an OTG or USB-device port (e.g. VBUS sensing). Interfacing with a UART requires no knowledge of external circuitry aside from pin configuration.
Reason 3) Lower-level 'operating systems' that run on microcontrollers or DSP often do not have such a sophisticated USB stack. UARTs are just simpler.
So now that we know complete replacement is unlikely... I can tell you that the USB console you're asking for is already here (with varying protocols). The protocol is determined by the device in question (either statically or at runtime) and will typically be one of i) CDC Ethernet / RNDIS, or ii) CDC Modem, but custom protocols are also possible.
CDC Ethernet is essentially what you're looking for in terms of 'auto-negotiating' baud rates, but you still need to configure the Ethernet / IP layers. Drivers exist for most decent host operating systems, and even Windows!
The device in question needs to have an OTG or USB-device port, neither of which you're likely to see on x86 or x86_64 chips without external hardware (AFAIK manufacturers assume that x86 chips are always the host in a USB transaction). On the other hand, most ARM SoC have had an OTG or USB-device port for years already.
I completely agree with this statement. Having personally hacked android on to 3 devices that it was never intended to run on, I can say that the Android platform is even more consistent than windows mobile, or the iPhone OS. In fact, its even more consistent than a standard desktop Linux like Ubuntu. Furthermore, Linux (which is of course the pivotally important part of Android) runs on more platforms than any other operating system in existence. Linux itself does more than provide a 'consistent' API, it provides a POSIXly correct API, which is fathoms more than any other mobile OS can say.
As for variations between hardware (e.g. some device supporting multi-touch, some not) - the same API is running on all of them - there are no differences, Android uses what the Linux kernel provides.
Lastly, with respect to different UI features provided by various companies (HTC Sense, MotoBlur, etc), developers target their apps according to a common API. The presentation (the look and feel of the UI) is also done according to a certain API.
This topic really is a non-issue, whoever even brought it up likely forgot to eat their wheaties this morning.
Sorry, but I have to agree with the EFF. I really do like apple hardware, but I can't say that I'm a big fan of their software. Come on - a 1GHz device that doesn't support multi-tasking?? Sure, the UI is cute, but seriously. Even after several weeks of using OS X on a desktop or a MacBook Pro, I still wished that it was running Linux so that I could at least have a choice about what desktop environment to use.
Furthermore, the LACK of freedom of choice is exactly the reason that I don't buy apple products. You're correct in assuming that there is some choice, but the only choice you can make is "to buy or not to buy". The choice stops there.
Don't forget, that the only reason Linux ever ran on any Apple hardware is because someone was able to find a way to load the kernel (i.e. exploit), reverse engineer the hardware, and so on. Luckily, due to the hard work of a lot of dedicated community members, Linux runs superbly on Mac hardware, even on their iPod:).
It would seem that many people outside of the US, including Canada and Germany, upon visiting www.google.com/phone have been receiving an error message saying "Sorry, the Nexus One phone is not available in your country."
I guess it doesn't go on sale in those countries until some undisclosed date.
Slashdot Mirror
After almost a month!
There's a major difference you're not realizing. Java does not use 'arrays' in the classical sense (probably like many other languages with a VM).
In fact, a Java array is not even necessarily in the same congtiguous block of memory, while an array in C is. This holds for arrays of Objects as well as arrays of primitive types.
A Java array is essentially like any other object managed by the JVM but with syntactical support for indexing.
If you've ever used a C struct and some function pointers before, you could easily create a managed array 'class' in C. 'Object oriented' programming in C is used far more than you might think.
Poorly written code is the cause of buffer overflows, and naive programmers tend to make that very apparent when they write in C.
The best thing to come out of New Zealand since Brett and Jermaine!
A few months ago, wasn't he going on about an economic rescue something or other?
In my opinion (although I am Canadian, but my opinion applies equally to my homeland as well), civil budgets should be one of the primary figures available to all on data.gov. That way, careless spending could be fairly easily monitored (potentially automatically).
This is utterly ridiculous... do people really find it that difficult to change the theme if they don't like it?
I promise, that it will not be torturous, nor will it inflict physical or psychological pain on anyone to simply go to System, Preferences, and Appearance to change the theme to what they've grown accustomed to.
It is Shuttleworth's distribution, and he can do with it what he wants. If he believes that these slight aesthetic changes will make him more money, then he has the freedom to make those changes.
Similarly, anyone else has the freedom to modify the default installation ISO to use the classic theme, if they prefer.
Translation: This will weigh less than 1/10th of most engineering textbooks.
Why didn't they come out with this 10 years ago!?
The referenced article is not exactly valid. The author is spouting off historical common-knowledge to hopefully gain literary credibility, and must lack the technical expertise to be authoritative on the topic... more about that later.
The entire point of the article is to say that Microsoft approves of Apple for suing other companies (both Nokia and HTC now) over software patents.
The systems in question (mobile devices with loads of integrated wireless technology) are a sort of fusion of tightly-coupled hardware and software. Essentially, the software part is a device driver, whether it's communicating with an RF frontend or reading bytes from a capacitive touchscreen (which is why Apple has no grounds to be suing anybody right now). Also, Apple originally denied licensing their touchscreen software to Nokia in the first place, so they are essentially monopolizing it.
What this boils down to, is that some things are patentable while others are not. The capacitive touchscreen design - the physical form, the novel arrangement of metals and plastics and capacitive material - is patentable. The RF Frontend is (potentially) patentable, novel dedicated circuits for decoding baseband information are patentable. Reading bytes from an N-pin connector and interpreting those bytes is not patentable.
Now, to address the 'radio stacks are trivial comment': although the baseband portion (i decline to use the term radio here) does use a large part of software, that concept is already quite old.
Software-defined-radio was originally designed back when certain radio technologies were still young and they needed an easily reconfigurable transceiver. Transceiver technology has had quite a bit of time to mature since then, and now that we are approaching the theoretical limit of wireless channel capacity, companies are turning toward dedicated silicon. Dedicated circuits have the benefit of increased speed as well as the benefit of decreased power consumption (all that and more!), when compared to a general purpose dsp. When it's economically viable for a company to produce a dedicated circuit, then they usually will, and they should seek a patent for that device.
The aforementioned dedicated circuits ARE patentable, but the software used to control them is NOT.
So true.
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux
The smallest Linux ELF binary to print ’Hello world!’
This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.
On the other hand, I do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise. However, the electrical & computer systems on automobiles should really be considered one in the same. They are the left and right hands of an entity and need to communicate effectively with each other. If there is electrical interference, then the signal processing system should take that into consideration and filter it out. If there is too much electrical interference, then the electronics should be re-designed!
Wouldn't it be hilarious if you were pedestering in some urban center, and you notice two guys with the same 'sun glasses'. Then those two guys notice eachother, and then a virtual light-saber battle ensues?
Then somebody takes out their Nexus One to instantly upload a video of that event to youtube, and by the time you pedester to your destination, you could backtrack on Google Maps and find a link to an augmented video of the entire event. Wouldn't that be cool?
Yeah, it would be pretty cool. Of course, I would never engage in a virtual battle like that personally because that is waaaay beyond my geek tolerance, but it would be entertaining as a spectator ;-)
I think Yahoo has actually been slashdotted :o
This could actually be somewhat useful.
( 0 - 1 ) mod 8 = 255 mod 8 ? Could also be some lazy ass not properly checking the sign of a return value (-1 often usually means error), and then passing it to another function as an unsigned value. Funny that people often think that dsp / computer engineers have less pressure to be legally responsible for the breakages caused by their broken code. If a wall fell over and killed someone because the engineer messed up the decimal point, then there would definitely be some legal action.
JTAG is intentionally excluded from my argument
First of all, it's important to distinguish that RS-232 is just a signalling convention. RS-232 requires an RS-232 transceiver, exactly the same way that USB requires a USB transceiver. Both of these technologies are for serial communication. Both of these technologies can be backed by a UART (see Catsoulis) but USB often skips the UART backend, opting for direct access instead. What you're really talking about is replacing the traditional RS-232 transceiver with a USB transceiver on devices. Sure, why not?
Reason 1) a UART is absolutely crucial for OS debugging, boot loader debugging, and recovery from corrupt nand, because it's cheap, simple, and sufficient. Often (especially when reverse engineering a device) a UART can be the only way to interact with the OS during the porting phase.
Reason 2) Although most (decent) OS have a USB stack that will work in both host and device mode simultaneously, often there is some external hardware preventing direct usage of an OTG or USB-device port (e.g. VBUS sensing). Interfacing with a UART requires no knowledge of external circuitry aside from pin configuration.
Reason 3) Lower-level 'operating systems' that run on microcontrollers or DSP often do not have such a sophisticated USB stack. UARTs are just simpler.
So now that we know complete replacement is unlikely... I can tell you that the USB console you're asking for is already here (with varying protocols). The protocol is determined by the device in question (either statically or at runtime) and will typically be one of i) CDC Ethernet / RNDIS, or ii) CDC Modem, but custom protocols are also possible.
CDC Ethernet is essentially what you're looking for in terms of 'auto-negotiating' baud rates, but you still need to configure the Ethernet / IP layers. Drivers exist for most decent host operating systems, and even Windows!
The device in question needs to have an OTG or USB-device port, neither of which you're likely to see on x86 or x86_64 chips without external hardware (AFAIK manufacturers assume that x86 chips are always the host in a USB transaction). On the other hand, most ARM SoC have had an OTG or USB-device port for years already.
+1, again
+1
I completely agree with this statement. Having personally hacked android on to 3 devices that it was never intended to run on, I can say that the Android platform is even more consistent than windows mobile, or the iPhone OS. In fact, its even more consistent than a standard desktop Linux like Ubuntu. Furthermore, Linux (which is of course the pivotally important part of Android) runs on more platforms than any other operating system in existence. Linux itself does more than provide a 'consistent' API, it provides a POSIXly correct API, which is fathoms more than any other mobile OS can say.
As for variations between hardware (e.g. some device supporting multi-touch, some not) - the same API is running on all of them - there are no differences, Android uses what the Linux kernel provides.
Lastly, with respect to different UI features provided by various companies (HTC Sense, MotoBlur, etc), developers target their apps according to a common API. The presentation (the look and feel of the UI) is also done according to a certain API.
This topic really is a non-issue, whoever even brought it up likely forgot to eat their wheaties this morning.
Chuck Norris doesn't even need to attack them, they just submit because they know he could fry their CPU with a single packet!
Sorry, but I have to agree with the EFF. I really do like apple hardware, but I can't say that I'm a big fan of their software. Come on - a 1GHz device that doesn't support multi-tasking?? Sure, the UI is cute, but seriously. Even after several weeks of using OS X on a desktop or a MacBook Pro, I still wished that it was running Linux so that I could at least have a choice about what desktop environment to use.
Furthermore, the LACK of freedom of choice is exactly the reason that I don't buy apple products. You're correct in assuming that there is some choice, but the only choice you can make is "to buy or not to buy". The choice stops there.
Don't forget, that the only reason Linux ever ran on any Apple hardware is because someone was able to find a way to load the kernel (i.e. exploit), reverse engineer the hardware, and so on. Luckily, due to the hard work of a lot of dedicated community members, Linux runs superbly on Mac hardware, even on their iPod :).
Does it work without a backlight in direct sunlight too?
Version 2.0 !
please tell me someone thought this was a funny name before i did...
Apparently My browser's UA was the first of its kind after 25,430 visitors ;-) My guess is that it has to do with the Chrome build number.
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.43 Safari/532.5
14.63 bits of entropy and shrinking!
It would seem that many people outside of the US, including Canada and Germany, upon visiting www.google.com/phone have been receiving an error message saying "Sorry, the Nexus One phone is not available in your country."
I guess it doesn't go on sale in those countries until some undisclosed date.