At least for me the link to the page to find out which way your MP voted didn't work.

Try this one:
http://www.publications.parliament.uk/pa/cm200910/cmhansrd/cm100407/debtext/100407-0032.htm#1004088001556

Let me dissect the the "key design issues", I think this is the 5th time I've done this, but I'll bite yet again.

Crippled C++ support: Exceptions are supported, they have been for YEARS. You'd be hard pressed to find a Symbian phone out there that doesn't have exceptions. If you want STL then port it, I once had the set of STL I needed with a basic STLPort port - this was several years ago. Certainly when ROM/RAM space is tight STL is going to get in your way - Symbian enabled smartphone applications years before the high performance processors and huge amounts of RAM todays phones have.

Confusing and limited string handling: Even the author admits they don't know what they are talking about "The reason was apparently to save a few bytes on each string". A descriptor is a very simple concept, a "description" of a contiguous memory region. TBuf8 is a descriptor to an in place buffer (ala a C array), a TPtrC8 is a constant pointer to specified region of memory, they all have a common TDesC8 base class. Plus if you want a "proper" string class, then make one - then spend a few minutes understanding the subject matter to realize a TPtrC8 cast operator on the class will magically enable your class to work with the Symbian APIs.

Limited support for multi-threading: Symbian is fully preemptive multi-tasking (check out RThread, wow, I guess the author missed that)! Even the kernel is preemptive (hence being sufficiently real-time to implement a baseband on the application processor). Just because Active Objects exist doesn't mean they are the only things for multi-tasking. Hopefully now the code is out in the open you can see how the experts use them to implement asynchronous code without having to always be thinking in terms of locks.

Bad development environment: Well this is a fairly subjective subject - I haven't had any trouble, install SDK, install Carbide and start developing. I can only imagine how taxing this must be for someone who appears to know so much.


It might not be as "easy" to develop on Symbian, but it is worth being thoughtful in writing tight, low overhead code (which the Symbian APIs are all about). It's easy to throw CPU and memory at problems, something which programmers are too willing to do these days.

In Soviet Russia, ants magnify you!

But seriously, what am I going to do? I can't find %SystemRoot% on my Linux box.

I don't completely agree with you - I believe Xaedalus's point above is the main motivational fact.

The scary thing about your rational is that if ultimately those in power realise your point, that these systems they have put in place gives them that level of control over any form of uprising (namely being able to surgically quash them). However, following on from that, there would then be counter-tactics whereby "Citizens" would record all significant details about themselves in a publicly available medium, so that any actions against "Citizens" engaging in the uprising further fuels the uprising. The obvious reduco ad absurdum for this situation is that personal privacy will be in tatters, but maybe that is where society is heading anyway.

Regardless, given the nature of society now - current democratic processes are outdated. In the UK, after several years I am given the choice to select an individual candidate (of limited selection) where normally few will actually have a chance of being elected - and normally that candidate will belong to a party (of which there are even fewer selections). The party system ensures that the rate of change of political influence is painfully slow.

I'm not saying I have any answers - but as we submerse ourselves in this information age, political processes need to keep up.

My Bluetooth link runs up and down stairs without any problems - the "base-station" is using a Class 1 radio and actually reaches further than my WiFi router for all the laptops in my house.

Do you really want to be making a sweeping generalisation based on race? </flame>

Seriously though, I don't think you can draw such a sweeping statement - I often have meetings and discussions in pubs with colleagues from both my company and others. It's a great way to relax away from the corporate/political BS in the office, while coming up with good ideas and getting some actual stuff done. But maybe that is because I'm an engineer.

I think it's cultural influences that have the most significant impact - in the UK (or at least wherever I've been in the UK) going to the pub isn't universal frowned upon. It's quite an accepted part of life.

Mod parent up. Spot on.
BTW. Bluetooth v2.1 has a brand new security model, and does away with the "fixed" PIN codes like 1234.

The other key thing to mention is (as I've said before on /.) that I wouldn't want to use the USB mass storage class over wireless. Going out of range while updating key allocation tables on the disk isn't going to make anyone happy. At least with wired USB you've got the cable to stop you going too far.

The only real use-case for wireless USB I can see is printers. Bluetooth has been very good with compatibility, which means that even if they move to UWB a device will still have the old radio. A UWB is bound to eat power, so it's only going to be "cheaper" for a printer where all the infra-structure is set-up for USB and it has a power supply. If I was building a wireless mouse I would use Bluetooth with the old radio (what sort of mouse would need UWB speeds?!).