Slashdot Mirror

If you want to create a peripheral or software that works with the Bluetooth of the iPhone or the iPod (excepting the basic audio peripherals) you have to apply for Apple's "Made for iPod Licensing" program.
http://developer.apple.com/ipod/apply.html

If you need a Bluetooth chipset supporting the Apple protocols you can buy them from CSR.
http://www.embeddedstar.com/weblog/2009/07/28/csr-ipod-touch/

If Apple can achieve the sort of dominance in the consumer smartphone market that they have achieved with their iPods then this will pay off very well for them. They will make money from licensing and other companies phones won't be able to communicate with iPhones/iPods.

On the other hand, whether they are successful or not, this is bad for their users. This being /. I probably don't have to explain why standards are good.

At this time, if you want to e.g. sell a Bluetooth garage door opener for smartphones (yes, this really exists) you could support it on RIM, Nokia, MS, and even some LG and Samsung phones. I hope that Android phones join this camp.

I'm interested to see some of the things that people will do with Bluetooth now that the quality of the hardware and software support is getting good enough (it wasn't good enough on a lot of the older phones). It would be sad if the lure of proprietary were to curtail the potential of Bluetooth.

Get a good SSD, and that's more or less a solved problem and has turned into a myth. The main reason to not use SSD's is that most of the cheap ones are MLC which DO have limited writes. SLC chips are much more robust, and faster, if more expensive. That, and we're talking USB drives. USB is very slow for a drive interface.

Excerpt from War of the Disks: A Close-in Analysis of the Hard Disk Drive vs. the Solid State Disk
"Although the most common Flash chips have around 300,000 write cycles, the best Flash chips are rated at 1,000,000 write cycles"

I'd really like to see someone test this and put it to bed. These articles are speaking in theory, not practice. I remember reading articles only 2 years ago about people buying SSDs and having them wear-out in a matter of hours under intensive use. (One of them was a Slashdot article, but I'm too lazy to find it).

The motors/sensors etc on the machinery (ie, your heat source) should fead back into PLC controalers which are *bombproof*.

Only then well away from the machinery do you fead the signals from your PLC, into a computer to network and process data. (Or better than this, a robust NI fieldpoint network module to network the data, and process the data well away from the factory floor.)

Putting network switches in such a harsh environment in taking the piss. I'm not saying it can't be done, but you need to look at how everybody else reliably does it, and think why you are trying to do it another way.

Oh and BTW, 2000 F = 1093 C Most of us use SI units :-)

Intel and AMD CPUs shipping this year are going to support easy virtualization. Those hardware companies are pouring money into VM software, and that VM software is free, so anyone and everyone will be able to run VMMs on their stock machines. One way to limit some of the damage of viruses/spyware is to make it a habit to run with multiple VMs. Even grandmothers should do this. (on top of security, VMs have a wide range of other benefits that make them hard to sideline)

On the other hand, DRM is becoming more popular. MS will have its Next-Generation Secure Computing Base that will try to have sections of memory that are very secure and protected. Grandmothers are going to want to play their DVD's inside a VM, and play her secure .WMA files, and...

Multiplayer games are often hacked, and hacks can ruin a multiplayer game. Microsoft's new NGSCB promises to have a secure authenticated path from the USB hub to the software. Hackers come out with things like fishing bots that multiplayer game authors would really like to prevent. Normal players would like to play hack-free games, within a VM.

Is there an inevitable train wreck here?

Acording to this article the cards are based on Sun's Java Card technology.

Of course, I'm curious as to whether this stuff was flown before (seems not), and if not it seems to be a bit of a leap for JPL to take. Also, curious as to whether this allows more modern hardware. I have doubts myself.

They could have gone with... VxWorks

And they did, dipshit.

Is it true that spirit makes use of Java? Or does only the "client" software used to control it,use Java. Does it have an OS and if so which/or what type? Does it use a RTOS or Linux or a BSD?

We do use Java to write the rover command sequences. I wrote the software, RoSE (the Rover Sequence Editor), that we use for that; RoSE was also used to command both spacecraft in cruise.

RoSE is part of a suite called RSVP, the rest of which does 3-D visualization, simulation, and playback. Our 3-D stuff is very, very cool (I feel OK about saying this because I didn't write that part :-): we do kinematic simulations as the rover drives across the terrain; you can see it articulate realistically. If you've watched the press conferences, you've probably seen one of our playbacks. That visualization stuff is all in C and C++, though, not Java.

Java is also used upstream of RSVP, to do image browsing and to plan science goals for the sol. That's Maestro's role.

The rovers themselves run VxWorks, a well-known real-time Unix variant that's used a lot here at JPL.

I have a degree in computer science. The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

I don't just have a college degree. I'm a former university research fellow in computer science. I'm also a Java programmer. I'm not in the least ashamed to tell people so.

Because of the size and footprint issues, you can't do embedded with Java.

Oh dear, I think you'd better tell Nokia that. And IBM. I don't think they know. I'm sure they'd be grateful.