Bluetooth (the technology) actually is much better than other interconnects, because the specifications go to the use-case level.
Equally for Bluetooth hardware there exists a standardised interfaces; so the same USB driver, for example, *should* work for all USB Bluetooth hardware. In fact this hardware interface specification encourages a partition where the higher levels protocols run in the OS.
What you describe is certainly not an implementation I would ever expect to see - Linux has a pretty sane implementation for example.
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.
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.
Its an anglo-saxon thing. It isn't much better in the UK, believe me.
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?!).
Firewire (or IEEE 1394) is a more expensive protocol to implement due to the p2p nature of it. IEEE 1394 devices have to be able to determine how to talk/respond to other devices all sharing the same bus. USB has a single host driving everything, as such devices can be a lot more "dumb". The result is that it is much cheaper to implement USB devices (such as flash disks) than it is with IEEE 1394.
With Microsoft throwing it's weight behind USB too, Firewire has all but disappeared. It's a shame really as IEEE 1394 is a much nicer interface - USB is very clunky, especially the "real world" USB implementations.
>> - they use symbian OS for all their phones. a system which names the devices A,B,C etc... and runs itself on drive "C". I wonder where that idea came from?
Names the devices A,B,C? I assume you mean drives not devices. And if you want to know where that came from it was 86-DOS (I'm willing to be corrected if I'm wrong). And one could argue that they don't run "on drive "C"" as most of the OS binaries will be off the "Z" drive which is the standard volume mapping to the ROM image.
I don't what a filesystem metaphor was to do with arguing similarity of performance characteristics. Perhaps you could quantify your claims?
I haven't used a "unsmart" phone for a while, so I cannot say how they perform compared to the smartphones I've been using for the past few years. They've always seemed pretty useable to me (I must be used to them), but they could be much more intuitive (I know my gf wouldn't have a clue how to use it).
I am assuming (and hope) the UI guys are taking a long hard look at usability for smartphones as they continue to get "smarter"
or worse, a const char* to a HBufC16
In this case I'm assuming a standard C string (although there is TPtrC constructor that will take a length too).
TPtrC8 ps("This is my example");
HBufC16* hw = HBufC16::New(ps.Length());
CnvUtfConverter::ConvertToUnicodeFromUtf8(hw, ps);// Could have used Utf7 here if needed.
Those were from the top of my head (it wouldn't compile anyway though:). I personally don't think descriptors are too hard to work with once you've grasp the concept that they are "containers" for strings/data rather than strings/data themselves.
Very, very little. You can blow the stack easily with a few recursive calls.
Yes, that was my point:)
It starts with a ridiculous indentation convention then builds until you can't stand writing Symbian code anymore
You don't have to follow the indentation convention Symbian follows surely, or do you mean it gets to you when reading the header files, example code, etc?
Well, we aren't all going to like the same things. With the amount of ill informed "Symbian bashing" on the Internet, it is nice to be presented with an fair argument by someone who has used it in earnest.
I've posted a few comments in this thread already....mostly clearing up mis-conceptions.
Also, there are no nice and clean C++ exceptions in Symbian, you've got to manually write your exception cleanup stack using ugly macros.
Pre-v9: Correct
Post-v9: Incorrect - infact Symbian "leaves" are now done in terms of C++ exceptions! (try it out yourself using intrumentation)
Symbian is archaic enough to assume that all software has to be able to run in ROM, which has introduced all kinds of resource & memory use weirdness.
Wha..? I don't understand? Surely you should be praising it for this fact as it is clever enough to not have to load into RAM code that is on ROM (I believe it is called execute-in-place)! Certainly apps installed after you've purchase a phone don't go into ROM.....
Oh, I see, you're talking about the Pre-v9 limitation of no static data in dlls. Post-v9 dlls can have static data btw.
You can make an ex-Symbian programmer explode by repeating the "TDesC" mantra a few times.
What is it? Symbian's foresight in encapsulating size with data from the ground up means that buffer-overflow attacks against OS executables that result in arbitary-code execution are incredibly rare (if not completely non-existant);) (Although I should also note that the "Active Object paradigm" also helps in this area)
I've done Symbian programming only in "C++" and I'm never going back.
How come?
Seriously, I appreciate programming in C++ for a Linux app is different to programming a Symbian app, but surely any programmer should be able to program in different environments. There seems to be a general mis-conception that Symbian forces you to do it in its own "wacky" way, but that is simply not the case. You have your standard primitives of process, threads, semaphores, etc. One can easily wrap up C-strings into TPtrC's etc. And you don't "got to manually write your exception cleanup stack", you can handle it your own way. And since v9 onward, a lot of the truely frustrating limitations (i.e. static data, exceptions, etc.) have been eliminated.
The facilities provided in Symbian are there to help the programmer write good, tight, robust code.
* You can do multi-tasking with threads (context switches?), or you can use Active Objects (no context switches).
* You can use C-style arrays/strings (stack overflow?) or you can use descriptors (stack overflow will panic your app).
* To handle cleanup on an exception, you can put all your objects on the stack (how much space is on the stack?) or you can put them on the heap and used the CleanupStack (much more resource friendly).
I personally like the Symbian "style", and I think learning to do it properly (rather than just dismiss the unusual as broken) has made me a better programmer.
p.s. I think the reason for all these misconceptions is due to a lack of abundant example code of a significant size and of a high quality.
Symbian doesn't mandate the organisation you are complaining about, they produce the base OS. For a phone a UI is built on top of Symbian, normally you'll see Symbian based phones operating S60 or UIQ. In this case it is the UI that is "lacking organisation", not the OS.
I'm always reading the same biased opinions here in slashdot about the usability of mobile phones. Spot on!
I agree with symbian being pretty nasty to use, slow and ugly Nasty to use? Ugly? Those sound very much like comments on the UI. Symbian doesn't do the UI, just the base OS. For UIs see S60 and UIQ.
And while in some peoples opinion Symbian may be slower than propriety phone OSs (which with my experience of some v9 based phones is not the case), it is because it is a complete multi-threading, real-time OS providing an open platform!
So what you're saying is that to stand a better chance of getting a PS3 you had to own a Xbox360? Wow, the costs really did start to add up for the potential PS3 owner!
Re:Can this succeed in what Bluetooth is failing?
on
USB To Go Wireless
·
· Score: 1
but can this fix the Bluetooth mess (different vendors' devices don't talk to each other, no standard API, etc.)?
Bluetooth goes a long way to try and avoid the "mess" you talk about with it's qualification program. I agree it isn't perfect, but it's the companies that produce non-compliant devices that should be blamed, not Bluetooth as a technology.
And "no standard API" is completely wrong, how much of a "standard API" do you want for a wireless technology? Most technologies simply provide protocols which ultimately are just data pipes for stuffing bits over the air with (e.g. 802.11). Bluetooth defines not only protocols, but profiles - which are standard ways for using the protocols to do actual use-cases - that's as close as a wireless technology get to providing a "standard API".
Try sending a set of contact details (such as a vCard) to a random set of PCs using WiFi and then try using Bluetooth. Would you say WiFi is as good as or better than Bluetooth for having "different vendors' devices talk to each other"?
I'm curious to know how Bluetooth is limiting you? I've written several applications using Bluetooth, both using it as a protocol data pipe (L2CAP using a socket style interface), and using profiles such OPP. I've found Bluetooth to be the most flexible method of wireless communication.
And there in lies the problem... prompting the user. Social Engineering works because people don't know what they are doing and because people are gullible. "Press ok to update your phone for roaming" or "Press ok to update firmware on your phone" along with a little note of why it is needed and end it with this is a free text and people will be pushing ok all day long.
In Symbian OS v9 and onwards this problem is eliminated too. With the capability model, apps have to be signed to use potentially dangerous APIs.
Slashdot Mirror
Bluetooth (the technology) actually is much better than other interconnects, because the specifications go to the use-case level.
Equally for Bluetooth hardware there exists a standardised interfaces; so the same USB driver, for example, *should* work for all USB Bluetooth hardware. In fact this hardware interface specification encourages a partition where the higher levels protocols run in the OS.
What you describe is certainly not an implementation I would ever expect to see - Linux has a pretty sane implementation for example.
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.
Its an anglo-saxon thing. It isn't much better in the UK, believe me.
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.
/.) 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.
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
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?!).
Firewire (or IEEE 1394) is a more expensive protocol to implement due to the p2p nature of it. IEEE 1394 devices have to be able to determine how to talk/respond to other devices all sharing the same bus. USB has a single host driving everything, as such devices can be a lot more "dumb". The result is that it is much cheaper to implement USB devices (such as flash disks) than it is with IEEE 1394.
With Microsoft throwing it's weight behind USB too, Firewire has all but disappeared. It's a shame really as IEEE 1394 is a much nicer interface - USB is very clunky, especially the "real world" USB implementations.
>> - they use symbian OS for all their phones. a system which names the devices A,B,C etc... and runs itself on drive "C". I wonder where that idea came from?
Names the devices A,B,C? I assume you mean drives not devices. And if you want to know where that came from it was 86-DOS (I'm willing to be corrected if I'm wrong). And one could argue that they don't run "on drive "C"" as most of the OS binaries will be off the "Z" drive which is the standard volume mapping to the ROM image.
I don't what a filesystem metaphor was to do with arguing similarity of performance characteristics. Perhaps you could quantify your claims?
I haven't used a "unsmart" phone for a while, so I cannot say how they perform compared to the smartphones I've been using for the past few years. They've always seemed pretty useable to me (I must be used to them), but they could be much more intuitive (I know my gf wouldn't have a clue how to use it).
I am assuming (and hope) the UI guys are taking a long hard look at usability for smartphones as they continue to get "smarter"
some psuedo C++ to keep things quick
or
or worse, a const char* to a HBufC16
In this case I'm assuming a standard C string (although there is TPtrC constructor that will take a length too).
Those were from the top of my head (it wouldn't compile anyway though
Very, very little. You can blow the stack easily with a few recursive calls.
Yes, that was my point
It starts with a ridiculous indentation convention then builds until you can't stand writing Symbian code anymore
You don't have to follow the indentation convention Symbian follows surely, or do you mean it gets to you when reading the header files, example code, etc?
Well, we aren't all going to like the same things. With the amount of ill informed "Symbian bashing" on the Internet, it is nice to be presented with an fair argument by someone who has used it in earnest.
I've posted a few comments in this thread already....mostly clearing up mis-conceptions.
;)
Also, there are no nice and clean C++ exceptions in Symbian, you've got to manually write your exception cleanup stack using ugly macros.
Pre-v9: Correct
Post-v9: Incorrect - infact Symbian "leaves" are now done in terms of C++ exceptions! (try it out yourself using intrumentation)
Symbian is archaic enough to assume that all software has to be able to run in ROM, which has introduced all kinds of resource & memory use weirdness.
Wha..? I don't understand? Surely you should be praising it for this fact as it is clever enough to not have to load into RAM code that is on ROM (I believe it is called execute-in-place)! Certainly apps installed after you've purchase a phone don't go into ROM.....
Oh, I see, you're talking about the Pre-v9 limitation of no static data in dlls. Post-v9 dlls can have static data btw.
You can make an ex-Symbian programmer explode by repeating the "TDesC" mantra a few times.
What is it? Symbian's foresight in encapsulating size with data from the ground up means that buffer-overflow attacks against OS executables that result in arbitary-code execution are incredibly rare (if not completely non-existant)
(Although I should also note that the "Active Object paradigm" also helps in this area)
I've done Symbian programming only in "C++" and I'm never going back.
How come?
Seriously, I appreciate programming in C++ for a Linux app is different to programming a Symbian app, but surely any programmer should be able to program in different environments. There seems to be a general mis-conception that Symbian forces you to do it in its own "wacky" way, but that is simply not the case. You have your standard primitives of process, threads, semaphores, etc. One can easily wrap up C-strings into TPtrC's etc. And you don't "got to manually write your exception cleanup stack", you can handle it your own way. And since v9 onward, a lot of the truely frustrating limitations (i.e. static data, exceptions, etc.) have been eliminated.
The facilities provided in Symbian are there to help the programmer write good, tight, robust code.
* You can do multi-tasking with threads (context switches?), or you can use Active Objects (no context switches).
* You can use C-style arrays/strings (stack overflow?) or you can use descriptors (stack overflow will panic your app).
* To handle cleanup on an exception, you can put all your objects on the stack (how much space is on the stack?) or you can put them on the heap and used the CleanupStack (much more resource friendly).
I personally like the Symbian "style", and I think learning to do it properly (rather than just dismiss the unusual as broken) has made me a better programmer.
p.s. I think the reason for all these misconceptions is due to a lack of abundant example code of a significant size and of a high quality.
Symbian doesn't mandate the organisation you are complaining about, they produce the base OS. For a phone a UI is built on top of Symbian, normally you'll see Symbian based phones operating S60 or UIQ. In this case it is the UI that is "lacking organisation", not the OS.
I'm always reading the same biased opinions here in slashdot about the usability of mobile phones.
Spot on!
I agree with symbian being pretty nasty to use, slow and ugly
Nasty to use? Ugly? Those sound very much like comments on the UI. Symbian doesn't do the UI, just the base OS. For UIs see S60 and UIQ.
And while in some peoples opinion Symbian may be slower than propriety phone OSs (which with my experience of some v9 based phones is not the case), it is because it is a complete multi-threading, real-time OS providing an open platform!
So what you're saying is that to stand a better chance of getting a PS3 you had to own a Xbox360?
Wow, the costs really did start to add up for the potential PS3 owner!
Bluetooth goes a long way to try and avoid the "mess" you talk about with it's qualification program. I agree it isn't perfect, but it's the companies that produce non-compliant devices that should be blamed, not Bluetooth as a technology.
And "no standard API" is completely wrong, how much of a "standard API" do you want for a wireless technology? Most technologies simply provide protocols which ultimately are just data pipes for stuffing bits over the air with (e.g. 802.11). Bluetooth defines not only protocols, but profiles - which are standard ways for using the protocols to do actual use-cases - that's as close as a wireless technology get to providing a "standard API".
Try sending a set of contact details (such as a vCard) to a random set of PCs using WiFi and then try using Bluetooth. Would you say WiFi is as good as or better than Bluetooth for having "different vendors' devices talk to each other"?
I'm curious to know how Bluetooth is limiting you? I've written several applications using Bluetooth, both using it as a protocol data pipe (L2CAP using a socket style interface), and using profiles such OPP. I've found Bluetooth to be the most flexible method of wireless communication.
There is this also http://shop.psiloc.com/en/Application,65575,Mobile +Mouse.
I tried this as a demo at least 9 months ago, it did work, but it wasn't the best mouse I've ever used.
And there in lies the problem... prompting the user. Social Engineering works because people don't know what they are doing and because people are gullible. "Press ok to update your phone for roaming" or "Press ok to update firmware on your phone" along with a little note of why it is needed and end it with this is a free text and people will be pushing ok all day long.
In Symbian OS v9 and onwards this problem is eliminated too. With the capability model, apps have to be signed to use potentially dangerous APIs.