I have the CD of that recording (which does the digital cannons bit even better - if CD is good at one thing, it's low frequencies).
The last time I ever used the PA rig at University, I sound-checked using that CD (IMHO, the best way to sound check a rock rig is against classical music). Not really audiophile quality, but if you haven't heard digital cannons coming out of an 8kW horn-loaded PA system, you haven't lived...
We had people come in from other parts of the building saying 'what was that - do it again...)
Hmm... not sure whether the parent has really worked on a mobile phone platform. I've worked extensively on several: many proprietary RTOS platforms, Linux and Windows Mobile, with a little Symbian thrown in.
Linux is a kernel. A pretty good one, I grant, but it only provides kernel services. The key to a mobile device is what sits on top of the kernel, and Linux has less of a good story to tell. Look at Windows mobile or Symbian and you'll notice that they each provide a well-defined set of telephony oriented services and APIs and a set of applications which use these.
If you want to build a product based on Symbian or Windows Mobile, you basically just have to implement a set of well-defined APIs and device drivers for your platform and you're good to go. While this is far from being a trivial undertaking, it provides a stable environment for 3rd party application developers, who stand a reasonable chance that their application will work as expected on any device supporting the OS.
The Linux situation is fast-developing, but there's no question that the rich telephony middleware layer isn't really there yet. There are a variety of different consortia, all of which have websites with "white papers" and some of which have formal API documents. To my knowledge, however, none has anything close to a complete, commercial quality implementation of a reasonably full suite of telephony middleware and user applications. I don't doubt that this will eventually arrive (there's a lot of pressure in that direction), but there's no 'standard' that I can see.
Let's just look at UI and application framework: there are at least two common options and a rich variety of more-or-less unsupported options: QTopia (which is probably the most mature right now, but costs $$$) and GTK+ (which is free but less mature on embedded platforms). If I'm an application developer, which do I target. Unlike Linux desktop machines, most of which resolve the problem by installing most of the libraries for both, space is at a premium on mobile devices - so QTopia devices require QT for the UI (and lock out GTK+ applications) and GTK+ devices do the converse. This is important to operators as a QTopia based phone is sufficiently different to a GTK+ based phone that they would really need to treated as separate platforms even though the kernel is the same.
At least the UI frameworks exist and work pretty well. What about the code to do things like: * Manage a SIM-based phonebook * Interface with a CDMA or UMTS modem (which needs to be specified
in an abstract way to support the many different chipsets out there) * Implement the SIM toolkit * Implement all of the user notifications required for SMS, supplementary
services, SIM and so on. * Gracefully manage multiple network connections in a seamless manner
(upmarket device probably has cellular packet service, Bluetooth,
WiFi, possibly tethered connection to desktop machine, IrDA,...) * Secure update of the software images on the device * Over the air provisioning of connections and services
I could go on, but I guess the point is made.
Sadly, Linux for embedded mobile devices risks becoming marginalized by a repeat of the 'desktop wars': several incompatible implementations of some pretty basic services which end up fragmenting the market because none achieves critical mass. Success means reducing the number of 'initiatives' (probably to one) and showing us the code. Enough of the white papers...
I have to disagree (but strongly suspect that I am working in a very different area than parent...)
For the type of work my team does, CS is invaluable. We deal with issues related to multithreaded and multi-core synchronization daily. People without CS (or maybe Maths/Physics/Electronics major) just don't 'get' the issues we have to deal with. I find it very difficult to recruit graduate level engineers (MSc/PhD generally) with the skills I need.
What *I* look for are CS/Electronics/Maths/Physics majors with an interest in computing. I do want to see an education and not just 'training' (many UK universities seem to have basically turned into Java training shops - fine as far as it goes, but it doesn't cut it in my team).
The bottom line is that different roles within the computing world require different skills. Some basically just require training, others require deep theoretical knowledge (and of course, the applicable knowledge varies from position to position).
However, there will always be a place for the highly educated with a strong theoretical background - and those will generally be the best and most interesting jobs. Must add, however, that it probably won't be the *majority* of jobs...
1) You should try to get a phone which supports the 850 band, as this gives far better in-building coverage than 1900. 2) The network you choose probably makes more difference than the phone you choose. Choose the network with the best coverage in your area, if you're in a poor service location. 3) There's not that much difference between the sensitivity of different GSM phones - they all have to meet the same RF specifications, and few beat them by very much. However, an external (stubby) antenna, while possibly causing an unsightly bulge in your trousers, will probably give silghtly better reception in practice than one with an internal patch antenna, if only because you won't get the attenuation from your hand while you're holding it. 4) Please, please don't use the signal strength meter as a guide. A true story: some years back I was working for a manufacturer whose new phone was slated by a magazine for "poor sensitivity". We tested the review phone when it came back and it was working very well. We loaded some new software which showed full signal strength for a relatively poor signal (about -97dBm, IIRC), and sent it (exactly the same phone) back. In the next issue the magazine printed a note to say that they had since tested a new sample of our phone which was much more sensitive... 5) If you're really still looking at marginal differences, Motorola phones often have slightly better sensitivity than average in the 1900MHz band. Alternatively (may not be what you're looking for as UMTS, not GSM), phones with the Qualcomm chipsets can be tuned to turn in very good performance. I have an LG U880 which pulls a signal when most others fail. I must admit an interest here, as a Qualcomm employee, but our GSM/GPRS implementation really is among the best around.
UMA has only just passed through the standardization process - and in record time, it must be said - so it's no surprise that few devices support it as yet. It's only a matter of time (and unlikely to be a long time at that). It's very much a market driven standard.
The 'base station' is registered with a GSM network because it uses GSM network components to support billing. Basically it terminates a GSM Gb interterface (which is another way of saying that it looks to a GSM network like a GPRS node), and voice (or other data) is carried as IP packets terminating at an SGSN.
The UMA design is really quite clever - it will straightforwardly allow almost any IP-capable wireless technology to use the GPRS network and billing components. It would be easy to make an access box which could 'talk' to a CDMA phone, but it doesn't really (at least as currently implemented) map to CDMA as CDMA systems use an IS-41 (or completely different) network design.
I must preface this by saying that I'm not an expert on EV-DO. I do, however, know quite a lot about mobile networks, and the information below is certainly valid for GPRS and WCDMA networks. Since it's a function of efficiently managing resources for multiple access on a cellular network, I'd expect EV-DO to behave similarly.
The key thing to remember is that it takes the network some time to allocate resources to you. When you first request to send a packet, some sort of channel must be set up.
This typically means something like: Phone pages network for access. Network grants access channel for signalling. Phone requests a channel for data transfer. Network grants this. Initial channel may well be quite low data rate (system usually turns up the data rate only if it believes you need it). You send the first packet. This takes, as noted, something around 0.5 sec.
Once you have a data connection, the system will normally hold it open for some time (configured by the network), and then drop it. It's important not to allow this to happen. Setting keep-alive to, say, 10 sec (exact value depending on system - determine by experiment) will help to keep the data connection in an operational state.
I should say that exactly how the network will behave is extremely configurable, and there is a delicate trade-off (for the network operator) between allocating resources efficiently between multiple users, and the latenies involved in configuring channels more often than necessary.
In my experience, even GPRS is usable with ssh, and WCDMA can do X and Citrix quite nicely, but you need to know how to keep the connections active.
Having worked in embedded products with both Linux and WinCE, I feel in somewhat of a position to comment.
Both platforms had advantages and disadvantages. In general, Microsoft has *far* better documentation, and is simpler to get up and running (MS basically provides a step by step guide to the things you need to do, and it has pretty much minimised them).
Linux is more difficult to get started with as the documentation and instructions on what to do do not really exist for embedded products (the parent is wrong on this point - there's no 'mobile phone HOWTO...', or really anything approaching a good reference), and the developer population is much smaller in the embedded space than on the desktop (many of them work for your competitors, too, so may not help out much!). However, having the source is *really* a boon once you have some understanding of the platform.
A simple example: under MS, we had no way to hook into the ARM exception handler, and one of our (very gifted) guys had to look until he found the right entry point - by disassembling part of the kernel. A lucky guess finally found the right place to set a breakpoint. Under Linux... you set a breakpoint at the line of code you wanted.
In the embedded space, there is often no particular advantage in portability between Linux and MS, as the legacy codebase probably wasn't based on either - an embedded RTOS such as pSOS+ is more likely, or even a proprietary kernel. Thus you have a porting job in either case.
I should also note that the MS eVC++ compiler produces *far* better code than GCC (which is pretty sucky on ARM, but excellent on x86).
So far as platform is concerned, MS provides a very strong integrated suite of apps. Linux provides... a kernel. There are third parties who can provide the rest of the things you need to build a phone (generally not free, though).
I would say, overall, that you can get to market pretty quickly with either - just depends on the product you are trying to get to that market.
It's clear that many of the people here haven't worked as a contractor, and don't really understand the concerns of the corporates who might hire your services.
I should preface by saying that my direct experience applies to the UK. I guess that you're in the United States, although you don't say (it's wise to do so when asking legal-type questions). However, since the US has a similar legal system to the UK, at least some of what I say is likely to be applicable.
I've worked in all of the different positions: as freelance contractor, as PHB-type and as Director of a medium-sized consulting company, so hopefully I can give some insight into what is important. However, IANAL, and would recommend legal advice if you're really unhappy about sopme aspect of a contract.
First thing: you really need limited liability and professional indemnity insurance. In the UK you can buy a company for around £100. I guess you should be able to get a ready-made corporation in the US for something similar. This protects your personal assets in the event that a contract goes bad. Professional indemnity insurance will cover you if (for example) an exploding blogsnatch factory controlled by a database you worked on suddenly explodes for some unlikely database-related reason. It's pretty cheap (about £300 p.a. in the UK). These things protect you. I recommend them highly, even though I never had recourse to use them.
For all those who say 'present your own contract', I'd have to say that, for most freelancers this simply isn't an option. You'll need to start with what is offered to you or go hungry.
What does a conract mean
This may seem a little strange, but generally a contract tells a story - it really should say what is expected of you and what you get in return. Try to read past the legalese and understand what it is trying to say.
Although many contracts are really quite poorly drafted, you should find at least the following:
The scope of the work you will perform, at least in broad outline. This should include key tools and skills you will provide
The expected duration of the work. This may be on a time-and-materials basis (billable hours) or on a deliverables basis (a database to store foo).
The working environment (you work at home, at their office, you travel for them, etc)
What and when you will be paid
Who owns the final work, and when
So first go through and understand what is being asked.
Negotiation time
You do have some power to modify a contract, but understand that companies have their red-lines as well. The usual procedure is something like the following:
Company sends copy of draft contract to you
You provide a copy marked-up in ink with proposed changes (I always initial every proposed change and the bottom of every page)
Both sides get together to work through the propsed changes and come up with something mutually acceptable
This is where the advantage of trading as a company arises: even the most pointy of PHBs can understand that a company has several customers, hence a company cannot possibly agree to 'all your code are belong to us'. You'll have no problem with this type of clause if you're incorporated.
However, the company needs to know, for certain, that they own the code you create for them. This means that you may need to address:
Ownership of any 'library' code or scripts you use in projects for multiple customers. Best to grant a non-exclusive license to use the code as they please in this case
That any code you write on 'their' time belongs to them - you will not put it back into your 'library' and use for other customers. You need to be very careful about this, as it's really a key concern.
That you are in a position to grant them such rights to your code. This is a very key issue with GPL (and similarly licensed) code. You do not have the right to do 'whatever you like' with GPL code, and y
Write your code as clearly as possible. Make it work (functionally).
Use a profiler to identify the bottlenecks. Many people have mentioned this, often quoting (usually slightly inaccurately) Knuth. In my experience, I almost never guess where the bottlenecks lie. Good tools are vital for this.
Get the algorithm right. A superbly optimised bubblesort will never beat an unoptimised quicksort for any reasonable data set (and if the data set is small, why are you optimising?)
(Mostly) trust the compiler. I'll expand on this, as it's really the thrust of your question...
Compiler optimisers
I've used quite a few compilers - both desktop and embedded - in anger. Most of the desktop compilers are really quite good at micro-optimisation. The embedded compilers are more of a mixed bunch.
More specifically
Register allocation: nearly every modern compiler does quite a good job of this. GCC allows you to allocate specific registers to variables. You should almost never do this, as it nearly always screws up the register allocation algorithm (the main exception is when you're doing syscalls which don't use a normal C calling convention). Use the register keyword sparingly (if at all) - modern compilers nearly always guess correctly!.
Instruction sequencing: most compilers make a reasonable attempt to sequence instructions so that, for example, a register-register operation follows a memory-register operation. This generally prevents pipeline stalls as well as can be expected. This is one area where there are significant differences between compilers. On the ARM, ARM-supplied tools are far ahead of any of the others, for example.
Loop unrolling: few compilers do this very often in practice, as it causes rapid explosion in code size. You may be wise to do this yourself, if it really matters.
Common subexpression elimination. Quite a few compilers do a good job of this.
Inlining: most compilers do this quite well, making a reasonable compromise between speed and size. You should be careful, however. Most compilers won't let you force code to be inline (and, in some cases, it cannot be (e.g. recursive functions)), so code which relies on a function being inlined is very bad indeed. If you need to ensure this, use a macro (even though they're evil).
Inter-file optimisations - a few compilers will perform optimisations across multiple files. This works better than I (sceptically) originally expected. About 5-10% gain in speed/code size for the ARM, for example.
Code positioning optimisations. Example - some CPUs will only allow a limited branch range, so branches to code which is beyond this have to go via intermediate branches (veneers). This slows life down quite a lot as you have extra code in every call and return, and a high probability of a cache miss. Good compilers (well, it's often the linker that does the work) often have strategies for minimising the impact of this issue.
GCC (for x86 and PowerPC) is a very good compiler these days. Some of the other ports (notably ARM) are pretty poor at optimising for instruction set features (some optimisations come for free on all ports as they are done before code generation)
Microsoft, much maligned though they are, produce good compilers, although I have found that their 'maximum' optimisation level can sometimes be a little too aggressive, and produce unexpected results in some cases (I found this with eVC++ for ARM, for example).
You may guess what I do for a living if I say that the ARM toolset produces superb code, with optimisations which can account for specific characteristics of Cache, MMU and pipeline. It is difficult to better this compiler in assembler unless you really know what you're doing.
Things compilers generally cannot do
A C compiler generally cannot know whether pointer aliasing (i.e. more than one pointer pointing to the same place) is possible in a giv
Frankly, this is no surprise to those of us who have seen the standardisation process at work for a number of years. I work in mobile telecomms, so no surprise if I take my examples from there:
IMT2000 (which was supposed to choose one 'World' standard fro 3G phones) ended up choosing three (UMTS, CDMA2000 and FOMA) as the Europeans, Americans and Japanese couldn't agree)
UMTS has two completely different modes: TDD and FDD, because powerful interests in the GSM industry couldn't agree on which to choose.
The 3GPP standards are full of redundant mechanisms which are supposed to be mandatory, but are unnecessary.
I could go on, but...
Thing is, you have to look at what standardisation represents to the participants. It's an opportunity to gain licensing revenue from your patent portfolio, so you need to get as much of your IPR into the standard as possible.
To do this, companies often make short-term alliances (i.e., I'll vote for this technology of yours if you vote for these technologies of mine) as a means to push the process in a preferred direction.
In the case of UWB, there are two groups of companies each (probably) with significant IPR in one of the two technologies, so who stand to gain big bucks if their preferred solution is chosen. Each group is powerful enough to block the other, but not powerful enough to prevail. After a period of deadlock, this is the only real way out.
You can't even make a purely technical argument for one or other technology. OFDMA is slightly more spectrally efficient than CDMA (with the emphasis on 'slightly'), but seems better suited to 'broadcast' style applications than to 'many bidirectional paths' of communication. The differences are small, but each side can claim that they are 'right'.
As other psoters have suggested, the market will decide. The UMTS TDD mode I mentioned earlier is virtually unheard of in the marketplace: all of the major UMTS systems use WCDMA (although many of the ideas in TDD have surfaced in the Chinese TD-SCDMA standard - no surprise as Siemens was a major backer of UMTS TDD, and is now doing R&D in China for a system using similar technology).
If you remember that standardisation is politics, with interoperability as both the price and outcome of the political process, then you won't be far wrong.
I'm working on an embedded Linux project, so had to put together a Linux build host. We're basically a Windows XP house, so the in-house IT people don't know much about Linux. They gave me a copy of RHEL WS and left me to get on with it.
This is the *worst* distro I've ever used (I've used Debian (preferred), SuSE, Slackware and Lin--whatever, over many years).
HW support is appalling: my box is a twin CPU HP server with an ATI Radion 9800 (I think). Should be normal fodder for an 'Enterprise' Linux
1) Detected the graphics card incorrectly, leaving me with no X. Offered no way to fall back to the framebuffer or SVGA without reinstalling (at least that I could see, or find in the 'support' pages). Back to good old 'edit XF86Config by hand, then.
2) Ships with a seriously broken version of Kerberos that won't talk to Active Server 2003. This is a reported bug which turns out to have been outstanding of nearly a year, and you can't connect to a Windows AD domain until it is fixed. RH seem to have no interntion of fixing the problem, but you basically pay the $$$ to connect the thing to a Windows network, right.
3) Developer packages seriously broken. Missing header files, incorrect configurations. The whole thing is a mess. I've basically had to remove most of them (at least they're optional) and install from source.
4) Up2date is really slow. I often see modem-like transfer speeds during update (over a T3 connection...). Clearly their servers can't help. I generally see far better speeds for Debian mirrors on my home ADSL link.
Unfortunately, RHEL is the corporate 'standard'. I'd never pay money for it, and strongly recommend almost anything else. I have no objection to the price (for corporate purposes $300 per year or so is nothing), but I have a strong objection to paying top prices for an inferior product.
If you don't need support (and know what you're doing), I'd recommend Debian. Otherwise, SuSE is so far ahead of RHEL it's not funny.
To be honest, and this is after using Ocaml extensively for a while, Ocaml's object system doesn't really work very well. I loved the language before I started to use the OO features, but working on LablGTK2 drove me crazy. The syntax (both for open types, and for keyword arguments) is ugly and poorly documented.
For command line software (mainly short scripts and 'parser' type applications), I still love the speed (both of development, and execution) of Ocaml, but I don't touch it for GUI programming any more.
I'm also inclined to agree that the core developers at Inria have moved on to other things. Whether this is because some of the language 'features' are seen as dead-ends (I'd suggest the implementation of OO polymorphism is one which doesn't meet real-world needs), or whether their research interests have somply moved on is not clear.
While many (including myself) complain at the lack of an elegent GUI interface, I've also looked into what would be needed to do such a thing myself (my poison of choice was wxWidgets, as I use Mac, Linux and Windows regularly, and *much* prefer having native look and feel. Gtk is really only fine for Linux), and the work involved looked very painful, unless you would accept an ugly interface to the C bindings for wx (I looked at using the wxEiffel C bindings as a starting point).
I know there's a fledgling wxCaml in the works, and I wish them luck. I agree that it would be a shame to see the language wither on the vine, although I fear that this is what is happening.
Having said that (and I speak as a real-time embedded developer), I am utterly convinced that many of the ideas embodied in Ocaml (type inference, functional/imperative programming mix etc) are the future of high-performance programming, and will eventually largely replace C for all but the lowest level tasks.
I doubt that Ocaml will be the language to do that, however. It will probably be a successor which learns from its shortcomings and builds on its (many) strengths. Probably a language yet to be written, in fact.
I initally used thebook as a resource for learning Ocaml. My review would be more like:
Language Core
This covers the basics of the language, although the presentation of material is somewhat disjointed, which makes the book challenging to use as a reference in the first programming steps.
The book is clearly a translation, and in some areas the translation is not especially literate, although the meaning of the text is always pretty clear.
The worst problem with the book is that it is severely out of date with respect to the latest distribution of Ocaml. The aspect that had me tearing my hair out was the lack of coverage of open types - something which is essential to using a GUI toolkit, and which is somewhat complex as there are rules which may come as slightly odd to those used to the implementation of polymorphism in other languages.
Development tools
This section gives a good overview of many of the tools available, and is probably the best part of the book. The major ommission is Ocamlp4, which, again, post-dates the book's authorship. Users on Windows (bow your heads in shame... this is Slashdot) will find that their platform is not really covered, which is a shame, as there are a few differences from Windows.
The rest
Coverage of libraries is way out of date. For a modern user, the only serious GUI choice is LablGtk2, and it is not covered at all. There are other problems in a similar vein.
The book contains a number of extended examples. While these smack of being 'undergraduate projects', they do indicate some of the techniques and paradigms of programming in Ocaml.
Conclusion
I wouldn't recommend this book. It's too far out of date (imagine buying a book on Perl 4 or Python 1.5). Since the Ocaml manuals are quite comprehensive, and there's an excellent tutorial at merjis.com, which is fast paced and does cover modern language features, there's really no need for this without a significant update. Sorry.
The whole introduction of UMA into the GSM specs was a masterful piece of politics, masterminded by.... the cellular operators.
UMA allows cellular networks to offer new, enhanced network features to subscribers very quickly and easily, and still bill them via their cellphone accounts.
Most newer mobile phones are entirely able to operate as modems, and WiFi (or anything else: ultra-wideband, even a good old 100Base-T Ethernet connection) *could* be built into a phone.
If you start to think about a phone as offering a universal modem capability in the future, you're getting close. Expect to see the first combined 3G + WiFi PCMCIA cards pretty soon. The UMA box is just what you need to take advantage of such a product.
It seems like no-one has really gotten the point, so I'll try to explain.
What's really going on here is GSM has one thing to offer to wireless technologies which many of them need: a reliable, proven billing system, supporting roaming between networks, which gives the ability to access millions of paying subscribers (who already have cellphones).
There has been a realisation that there are somethimes reasons why it may be better to use a short-distance, but high speed technology in preference to a cellular (even 3G) based service.
Things it probably isn't about:
Handover between WiFi networks (you need lots of other protocol support)
Handover between different cellular technology (e.g. 1x and GSM) - we already know how to do that, in theory, just no need for now (phones with 1x and GSM support are just around the corner, and work very well).
What is it?
What we are talking about is basically a gateway box which allows some other technology to talk to the GSM A/Gb interface, which is what connects the Base Station System (BSS) to the Mobile Switching Centre (MSC) (for voice calls) and the GPRS packet network.
This enables a network which can speak IP to interface with a network which speaks GSM/GPRS. The data traffic goes through the GPRS core network (SGSN to GGSN to Internet), and voice traffic (e.g. VoIP) could be routed straight to the MSC, and hence to the PSTN (or Plain Old Telephone System).
Everything which passes through a GSM/GPRS core network is subject to authentication and billing, so all of a sudden, you can have more interesting payment plans than are typical for WiFi networks - pay as you go, pay per MB, unlimited packages etc... (look at all the cellular plans out there).
The probability is that you'll also need to start seeing SIM cards in laptops - GSM security is pretty much premised on using a SIM card (although you could get out of using one if really required.
UMTS is based on GSM (Global System for Mobile Communications) technology that supports data rates of up to 384 kilobits per second, Cingular said. An enhanced version called High Speed Downlink Packet Access would offer peak data rates of 14.4mbps. GSM is well-established in Europe but less widely used in the United States.
I'm quite surprised to see such an inept statement from ZDNet. UMTS is an umbrella term which covers the set of specifications for GSM, WCDMA and their interworking.
In this case, Cingular is focussing on WCDMA which, at the air interface layer has more in common with CDMA2000 than with GSM. WCDMA uses a CDMA-based air interface with upper protocol layers based on GSM (you could view this as like moving from copper Ethernet to fibre: the upper protocol is still TCP/IP, but faster...)
At the risk of starting a flame war, I think it's reasonable to say that today, GSM/WCDMA has a more highly evolved set of upper layers than CDMA2000, but CDMA2000 has a better optimised radio interface (EV-DO is considerably faster than the 384 kbit/s you can get with WCDMA - I know colleagues who consistently get around 800 kbit/s real data rates with EV-DO modems, where around 200 kbit/s is more realistic for WCDMA).
While, as explained above, I wouldn't like to characterise either CDMA2000 EV-DO or WCDMA as superior to the other, I think it is reasonable to state that EV-DO is the more mature and stable system right now. I use a 3G mobile in the UK, and there are still a few glitches around the edges, although things are improving rapidly (the main issue is handover between WCDMA and GSM, which is technically very challenging, and isn't an issue in CDMA2000 networks). I will say that if you're interested in data on the move, both EV-DO and WCDMA offer a user experience which is subjectively very similar to using a DSL connection, and is light years ahead of using GPRS (or CDMA2000-1X) in the performance offered.
HSDPA is at least a couple of years away from deployment in commercial networks, and probably won't initially work at 14.4 Mbit/s.
As for the issue of travelling... Well, WCDMA phones (almost) all have GSM capability, so will work in most parts of the world (the only place my GSM phone failed to work in the last five years was rural Laos!), and dual-mode CDMA2000 phones with GSM capability are extremely close to market, which will enable global roaming for CDMA users on GSM networks. From a practical point of view, users of either type of network will have the option of near global roaming.
I suppose I would summarise by saying that both systems are 'good enough' for most data users, and both will offer global roaming. Most people will probably be quite happy to choose based on price plan and phone they like best...
Are you sure you actualy design mobile phones for living? You sound as clueless as Anna Kournikova!
Quite sure, thank you. I also put my name to my opinions...
First of all, every study I have seen has Windows Smartphone and Windows CE embeded far cheaper to deploy by hardware companies than Linux is (its not even close), so you are either lying or making things up.
Well, I'm not an analyst who writes studies. I implement this stuff, so I'm speaking from experience, not from comparing Powerpoint presentations to see which contains the larger number of buzzwords.
Cost of deployment is not a phrase you use when developing a phone. We are not corporate IT depertments. What matters are engineering cost, time to market, bill of materials, license costs and sellling price. You trade these off against one another.
And then, look att your platform. Most protocol stacks were written to run under small RTOS executives that don't present anything like a Posix (or Win32) API.
Now, if you have a separate processor to run applications, talking to your proprietary RTOS (which runs the protocol stack), porting Symbian or Windows Smartphone is fairly straightforward, and this is probably the best way to go. However, an apps processor costs $$$, and uses extra battery power.
If you want to loose the applications processor, you have to port your protocol stack to run under the new OS. Bear in mind that layer 1 of your stack is very heavily interrupt driven, and that the whole stack was written to run under a very non-standard API and you have a very tricky problem. It is not a breeze to do this, but a very significant engineering effort.
Now, the Linux API is, paradoxically, slightly easier to port to than Symbian or Windows. The reason is that:
Symbian is C++ top to bottom, with an unusual OO driver model, so you'll have to make significant changes to your device drivers (all of them), and hope that you don't get bitten by C++ type safety (unlikely, in my experience)
Windows CE has a very well thought out device driver model, but one which expects most device driver code to run in user mode as a thread. This is a really good idea, but it simply isn't the way in which most embedded device drivers are written, so you have a major porting exercise on your hands.
Now, a very big win with Symbian (Series 60, more precisely) and Windows Smartphone is that you get a UI and some key applications with the system. This is a very big deal, as that's an enormous amount of engineering effort.
Currently there's no obvious Linux UI candidate (QT Embedded is aimed more at PDA form factors, and costs $$$ anyway). However, many phone manufacturers already have UIs, and anyway, in many respects, the operators look on smart devices as simply a platform for Java/MIDP.
In such a scenario, a Linux port may make sense. This is because of my other point, which you managed to completely misunderstand.
I said that "licensing fees for embedded OS are way below those for, say Windows XP Home". You say: "where exacty did you see this Microsoft smartphone which had Windows XP embeded in it? LOL!".
What I meant is that if an copy of Windows XP Home (i.e for a PC, you know, the big beige box under your desk) costs, say, $100 (or a price that most/. readers could relate to), Windows Smartphone or Symbian cost significantly less than that (can't say what though).
Even so, over a production run of several million phones, the difference in licensing fees between free, but porting your UI and some 10s of $ pays for quite a lot of engineering effort, and may let you sell your phione for less.
So what I'm really saying is that you look at the resources you have, the number of phones you expect to sell and the hardware BOM... and you make an engineering decision. There are good reasons to go with any of the systems. If you have an apps processor, you'd have t
I design mobile phone software for a living, and have done so for 15 years, so I feel qualified to comment on some of these issues:
- Yes, Linux smartphones will probably be a little cheaper than those using Symbian or MS Smartphone, but the difference isn't large: licensing fees for embedded OS are way below those for, say Windows XP Home. Don't forget that in may parts of the World, operators subsidise phones, so this small difference may not even be noticable to the end purchaser.
- Of course anyone offering a Linux-based smartphone will abide by the GPL: this means that they'll publish kernel code and any patches. However, don't expect to see GPL'd protocol stacks or device drivers any time soon. Same goes for the UI, which will likely be proprietary all the way. This means that you don't get to review the protocol stack software and fix any bugs in it.
- A Linux smartphone could be developer-friendly, but I doubt it. Operators really don't want open devices, and while they're paying the subsidies, they get what they want. You could go buy an unlocked version at full price (say $600) instead of getting it free on your plan, of course.
So, to summarise, a Linux smartphone will, unfortunately, mean DRM, operator lock-down and only slightly lower pricing for most users, unless enough potential customers go to the operators and insist on openness and no DRM.
The manufacturers are perfectly capable of providing open devices (in fact, they would prefer to, as we actually like having a vibrant developer community). Symbian, Qualcomm and Microsoft all offer pretty good developer support, if only you could get a phone which isn't locked down. Normally there's a PC-based emulator/debug environment, a cross-compiler/linker and lots of sample code available for free (as in beer) download....or alternatively, you could join a company which manufactures this stuff, and get paid to hack it;-)
Actually, you exaggerate slightly. You get a very good set of sample device drivers, sample BSPs for some commercial cards and a few other bits, but you don't quite get everything.
For one thing (very pertinent to a smartphone), you probably won't get much of a protocol stack - which is fine, as you're supposed to provide that for yourself. What you do get (on Windows Smartphone for sure, Symbian, I'm pretty sure) is a well designed interface between the application layer (which is provided) and the protocol stack.
Of course, if you go to an OEM (Qualcomm, Nokia, TI, Infineon or whoever), you'll also get the protocol stack and a complete reference design - and few people ever stray far from the reference.
Despite a few glib comments that 'Linux runs Java, and that's all you need', Linux does not have a standardised smartphone UI (please don't say X: I love it, but I'm unlikely to need full network transparency to my telephone...)
I'm working on porting a real cellular protocol stack to Windows Smartphone as we speak.
Despite being no fan of Microsoft desktop products, I have to say that in many respects, Smartphone is a very well thought out product. They have a slick, and very well designed UI, a decent set of apps, and a kernel which is relatively easy to get to work on a new platform.
I agree with the poster who complains about the MS build system (dreadful), but it does the job, but the kernel itself really does have some good things going for it.
Symbian is a great operating system platform, but porting an existing protocol stack (written, as they nearly all are, in plain old C) to Symbian with its 'C++ from the ground up goodness' (polymorphic device drivers, anyone?) is an enormous task - there are something like 10,000 source files in the system I'm dealing with, and the thought of doing a Symbian port is, frankly, terrifying.
The other (non-technical) problem is that Symbian seems to be snatching defeat from the jaws of victory by becoming increasingly dominated by Nokia (which is great if you're Nokia, not so good if you're anyone else). If the platform had remained true to its original promise of being a real consortium, it would probably have a much more successful future ahead.
Linux is a great option at the low end, but there is no decent smartphone UI (QTopia is more aimed at pen controlled devices), so you'd have to roll your own, which takes away from the standardisation aspect of having a 'real' OS. FreeBSD is even better, to be honest because (I wish it weren't so, but this is business reality) corporates are often scared of the GPL.
In any event, the way thing look in Europe, all any smartphone really has to do is be a decent platform for Java - operators aren't interested in supporting multiple platforms, and Java already has some traction. SavaJe seems, from what I can tell, to be basically that, but you could certainly roll a similar UI in Java for an embedded Linux kernel and have a great solution.
As the main story points out, this is a very price sensitive market. Symbian and MS Smartphone basically cost about the same, and enough to make a free platform highly attractive. It's the lack of a suitable, standardised, UI which causes the problem.
Re:We had been thinking about using kylix
on
Kylix in Limbo
·
· Score: 1
I've been working for some time now with wxPython. As a development environment it's great - there are a few behavioural oddities between Win32 and Linux, but none has yet caused me any real problems.
Couple of issues, though: - wxPython documentation is patchy: some is excellent, some areas are non-existant - Distributing a finished application is the worst nightmare of DLL hell. In order to enable my users to run the application on Win32, I need to deliver:
* Python installer
* wxWindows installer
* wxPython installer
* a bunch of libraries (Numeric and matplotlib are the main ones)
* my application
I've yet to pursuade any of the installer options to automate this under Windows. Linux is trivial: a 5 line shell script with apt-get to a local archive does the trick nicely:-)
I used Boa as a convenient way to construct my GUI framework - it's an excellent piece of work in that respect, and has the best debugger I've yet found for Python. However, once the GUI framework was implemented, I changed back to editing in JEdit - I'd concur with the comment about tab controls, but Boa is quite excellent considering it's basically the work of one guy.
I'll also make a gratuitous plug for matplotlib. It's shaping up into a great lightweight charting toolkit. I've written a (currently pre-alpha) wxPython backend for this, and have been very impressed at what John Hunter, the architect has done with the GTK and GD backends.
I've had the (probably unusual) experience of using headhunters as a software engineering manager, as an engineer and (which is the unusual part) I've also worked in a role which involved business development for an outsourcing consultancy (which means I've at least a fair idea what headhunters encounter from their clients).
What I'm saying applies only to the UK market - things are doubtless different elsewhere.
First thing is that there are literally thousands of headhunter agencies - ranging in size from 'one man and a dog' to multinational corporates. Only a small percentage have more than a minimal understanding of the market in which they are operating. In addition, staff turnover is generally quite high - I've heard of headhunters with an annual employee turnover of 115%!
Now my advice - for the UK market - is to ignore the company and look for the people. My favourite headhunter (in the embedded/telecomms sector) has worked for at least four different companies since I have known him (about 5 years now). On my behalf as an engineer, he has always:
- put my CV forward to jobs for which I was both well suited and which I found interesting. - asked my permission before submitting my CV to a company. - been well informed and honest about what a role was (I've never had that sinking feeling at an interview arranged by him that I was being interviewed for a different job than the one I thought I was being interviewed for) - been honest about the salary on offer
To me as an employer, he always: - Worked for some time with me to understand what I was looking for. Not just technically, but also in personality (for team fit), amount of travel required in the role etc. - Let me know honestly what candidates thought shortly after the interview.
To my mind, this is the level of service that I would expect, and it is all too rarely achieved.
For those who complain about headhunters who submit CVs without asking, you should understand that there are websites containing tens of thousands of CVs, which you can access for a subscription (and virtually all headhunters have subscriptions to all of them). Often, by placing your CV on the website, you've granted permission for distribution already.
Also, have some sympathy for the headhunter. The ethics of the business are that if a CV is submitted by more than one headhunter, the first one to submit will be used if the person is eventually employed. These people have to work very quickly.
Employers often demand an unreasonably fast response (I've seen a requirement from a large multinational to submit at least 20 CVs for each position within 24 hours of the job description being provided, or you can't do business with them). It simply isn't possible to do a thorough job in such circumstances, so many (probably most) resort to simple keyword' matching on CVs.
In short:
If you're an engineer:
- Find two to five good headhunters (people, not companies!) and stick with them. - Make it clear that you expect your CV to be passed on only with your permission. - Ask the headhunter the identity of the company to which you are being submitted (and let him/her know if you've already been submitted there by someone else - it avoids wasting their valuable time). - Ask about the realistic salary on offer - and make it clear if this does not meet your expectations. - Spend time explaining your skills, aspirations and preferences.
If you're an employer: - Spend time talking to a few headhunters before you decide which ones you will accept CVs from. - Find out what they charge (and be realistic, they need to charge about 10% of starting salary to make a profit, so 15% is not an outrageous figure if the service is good). - Take time to create an accurate job description, detailing what skills, work and personality are required. - Work with only a few headhunters, and make it clear that if they send unsuitable CVs, all their submissions will end up in the bin, u
I've been away from the Internet for a week or so, so apologies for the wait for a reply.
You're right to identify spectrum as a scarce resource, and the 3G networks generally do try to make a better job of allocating it than current technologies - you should get about 3-5 times the number of voice conversations in the same spectrum as you would with a 2G technology. You could argue that that isn't a great improvement, but it's really the start of things - GSM networks have been optimised way beyond the expectations of the original design.
Actually it isn't too dificult to do multicasting and the like provided that the use of uplink resources (i.e. from user to network) is minimal or (preferably) eliminated. Whether it's something with real uses rather beyond showing your mates that you can watch a football match on your phone is another question, but I could imagine multicasting e.g. local traffic information.
It's true that many of the new services which are being hyped are rather greedy of bandwidth (384 kbit/s videocall anyone?), but I really doubt that these will be used very heavily - and if they are, the user will have to pay dearly for using all that bandwidth.
It's certainly true that some customers on one of the commercial 3G networks have had difficulty making video calls on their shiny new toys as the network was 'busy' (despite relatively few subscribers as yet) - as you say, the resource is limited.
The theoretical limit for GPRS is somewhere in the 170 kbit/s area, but this depends on a very good channel (unlikely), a network supporting coding scheme 4 (unlikely) and no users sharing the same radio resources (unlikely). I've never seen more than 58kbit/s in a cabled RF environment with coding scheme 2 (which is what everyone uses in parctice) and no other users of the resources. This is probably good enough for many mobile applications, although I'll note, once more, that GPRS is slow in performing reselection between cells while a transfer is taking place.
Actually, in the UK at least, the most compelling reason to choose the 3G network ('3') is that is's quite a lot cheaper than the established GSM players - you get about five times as many minutes for a given subscription as you would anywhere else here, and the phones are being practically given away.
I'd be the first to agree that the 3G phones on the market today are little better than prototypes. They're bulky and use more power than GSM because they are, effectively, two phones inside: GSM and WCDMA (more accurately, there are two separate chipsets). This will change, and pretty soon. I, for one, have a phone in my hand which is little bigger than a current GSM phone, and has about four days standby time, but supports data up to 384 kbit/s (you'll reliably see no more than about 45kbit/s on GPRS with UK networks). You'll be able to buy something like it in a few months time.
GSM (and 1x) are mature technologies - they've been around for a long time, and there has been plenty of time to perfect them.
Fact is, at least for GSM, in many locations the networks are already at maximum capacity *for voice*, so 3G is needed simply to keep pace with the demand for voice calling. GPRS is OK for some data applications, but is very poorly suited to streaming/multicast applications (mainly due to the fact that it is slow in selecting between cells, and typically looses at least a couple of seconds of data).
I'd probably agree that 3G was launched too early, and with too much hype, but make no mistake, it is coming, and as it matures it should represent a compelling technology for many users.
What do I use Python for? Pretty much anything which doesn't require real-time performance (which means most things).
To expand, I work in the Mobile Telecomms realm, so most end-user code is real-time embedded C which tends to be heavily optimised for both speed and size.
Python is great for writing simulations, tools for processing logfiles, regression test suites (you do test, right!), and GUIs (which almost never need to have very high performance).
Strengths:
* I'm surprised that few people have mentioned that Python is much more expressive than C, C++ or Java - you simply get the job done in fewer lines of code, and the code is exceptionally easy to read.
* There is a rich set of built-in data types, and good support for basic Object Orientation - it's not the most OO implementation out there, but it's more than good enough for most designs. The fact that lists and dictionaries are part of the language means you can concentrate on expressing the problem, rather than implementing yet another linked list class.
* Very simple, regular, syntax. BTW, I'm neither especially for nor against the whitespace thing. It does mean that most Python code is stylistically similar, so it's easy to read other people's code, but it is a pain if you use different editors (or differently configured editors) to work on modules written by others: if I edit code where spaces were used for indenting and I use tabs, the code will behave unexpectedly, because Python sees a tab as equal to a single space. This can occasionally be very annoying, and difficult to track down)
* The dynamic typing and reflection are a joy to use - simple yet powerful.
* The ability to use a functional programming style when appropriate, without enforcing it (I personally find using FP all the time a little too rigorous - I just don't always think recursively).
* The library covers most things - and there are excellent, really easy to use hooks to GUI libraries (I mainly use WxWindows and some Qt).
* Easy to call C/C++ modules using SWIG - in fact it's almost trivial, so you can prototype in Python and replace the speed bottlenecks with C or C++ code to get good system performance. The profiler is quite helpful in doing this.
* Code is usually extremely portable between Linux, other Unices and Windows.
Weaknesses:
* I've yet to find a really good debugger. About the best I've found is the one in Boa Constructor, but it's some way behind using, say, DDD on C++ code.
* Performance isn't the best for serious number crunching, but it's adequate for most things.
* It's painful to package up finished code into a 'product'. If I use Python + WxWindows + WxPython to implement a GUI for a performance analysis tool, I'll need to deliver three installers along with my code. Fortunately my end-users for this stuff are also software engineers, so they generally get the install right!
Why learn another programming language?
This is more a philosophical question. You can do anything in any Turing complete programming language (that'll be all of them, then), if you must.
However, different languages tend to engender different ways of thinking about problems, so by leaning a new language, you learn new ways of thinking which can often help you in other languages you know.
I try to learn a new language each year (so far: C, C++, Java, Shell scripting, Python, Erlang, SDL, Lisp, Perl and more assemblers than I care to remember). I've gained the most from learning C, Python and Erlang, as they each represent very different approaches to a problem.
It's still C which earns my bread and butter - nothing else really comes close for hard real-time work - but some of the techniques I've found natural in Python have proven to translate surprisingly well into C - I'd probably not have thought of doing things that way if I didn't learn Python.
I'd recommend any programmer who works primarily in C or C++ to learn a scripting
Slashdot Mirror
Completely OT, but...
I have the CD of that recording (which does the digital cannons bit even better - if CD is good at one thing, it's low frequencies).
The last time I ever used the PA rig at University, I sound-checked using that CD (IMHO, the best way to sound check a rock rig is against classical music). Not really audiophile quality, but if you haven't heard digital cannons coming out of an 8kW horn-loaded PA system, you haven't lived...
We had people come in from other parts of the building saying 'what was that - do it again...)
Happy memories
Hmm... not sure whether the parent has really worked on a mobile phone platform. I've worked extensively on several: many proprietary RTOS platforms, Linux and Windows Mobile, with a little Symbian thrown in.
...)
Linux is a kernel. A pretty good one, I grant, but it only provides kernel services. The key to a mobile device is what sits on top of the kernel, and Linux has less of a good story to tell. Look at Windows mobile or Symbian and you'll notice that they each provide a well-defined set of telephony oriented services and APIs and a set of applications which use these.
If you want to build a product based on Symbian or Windows Mobile, you basically just have to implement a set of well-defined APIs and device drivers for your platform and you're good to go. While this is far from being a trivial undertaking, it provides a stable environment for 3rd party application developers, who stand a reasonable chance that their application will work as expected on any device supporting the OS.
The Linux situation is fast-developing, but there's no question that the rich telephony middleware layer isn't really there yet. There are a variety of different consortia, all of which have websites with "white papers" and some of which have formal API documents. To my knowledge, however, none has anything close to a complete, commercial quality implementation of a reasonably full suite of telephony middleware and user applications. I don't doubt that this will eventually arrive (there's a lot of pressure in that direction), but there's no 'standard' that I can see.
Let's just look at UI and application framework: there are at least two common options and a rich variety of more-or-less unsupported options: QTopia (which is probably the most mature right now, but costs $$$) and GTK+ (which is free but less mature on embedded platforms). If I'm an application developer, which do I target. Unlike Linux desktop machines, most of which resolve the problem by installing most of the libraries for both, space is at a premium on mobile devices - so QTopia devices require QT for the UI (and lock out GTK+ applications) and GTK+ devices do the converse. This is important to operators as a QTopia based phone is sufficiently different to a GTK+ based phone that they would really need to treated as separate platforms even though the kernel is the same.
At least the UI frameworks exist and work pretty well. What about the code to do things like:
* Manage a SIM-based phonebook
* Interface with a CDMA or UMTS modem (which needs to be specified
in an abstract way to support the many different chipsets out there)
* Implement the SIM toolkit
* Implement all of the user notifications required for SMS, supplementary
services, SIM and so on.
* Gracefully manage multiple network connections in a seamless manner
(upmarket device probably has cellular packet service, Bluetooth,
WiFi, possibly tethered connection to desktop machine, IrDA,
* Secure update of the software images on the device
* Over the air provisioning of connections and services
I could go on, but I guess the point is made.
Sadly, Linux for embedded mobile devices risks becoming marginalized by a repeat of the 'desktop wars': several incompatible implementations of some pretty basic services which end up fragmenting the market because none achieves critical mass. Success means reducing the number of 'initiatives' (probably to one) and showing us the code. Enough of the white papers...
I have to disagree (but strongly suspect that I am working in a very different area than parent...)
For the type of work my team does, CS is invaluable. We deal with issues related to multithreaded and multi-core synchronization daily. People without CS (or maybe Maths/Physics/Electronics major) just don't 'get' the issues we have to deal with. I find it very difficult to recruit graduate level engineers (MSc/PhD generally) with the skills I need.
What *I* look for are CS/Electronics/Maths/Physics majors with an interest in computing. I do want to see an education and not just 'training' (many UK universities seem to have basically turned into Java training shops - fine as far as it goes, but it doesn't cut it in my team).
The bottom line is that different roles within the computing world require different skills. Some basically just require training, others require deep theoretical knowledge (and of course, the applicable knowledge varies from position to position).
However, there will always be a place for the highly educated with a strong theoretical background - and those will generally be the best and most interesting jobs. Must add, however, that it probably won't be the *majority* of jobs...
I assume that you're in the United States.
A few simple rules of thumb should see you clear:
1) You should try to get a phone which supports the 850 band, as this gives far better in-building coverage than 1900.
2) The network you choose probably makes more difference than the phone you choose. Choose the network with the best coverage in your area, if you're in a poor service location.
3) There's not that much difference between the sensitivity of different GSM phones - they all have to meet the same RF specifications, and few beat them by very much. However, an external (stubby) antenna, while possibly causing an unsightly bulge in your trousers, will probably give silghtly better reception in practice than one with an internal patch antenna, if only because you won't get the attenuation from your hand while you're holding it.
4) Please, please don't use the signal strength meter as a guide. A true story: some years back I was working for a manufacturer whose new phone was slated by a magazine for "poor sensitivity". We tested the review phone when it came back and it was working very well. We loaded some new software which showed full signal strength for a relatively poor signal (about -97dBm, IIRC), and sent it (exactly the same phone) back. In the next issue the magazine printed a note to say that they had since tested a new sample of our phone which was much more sensitive...
5) If you're really still looking at marginal differences, Motorola phones often have slightly better sensitivity than average in the 1900MHz band. Alternatively (may not be what you're looking for as UMTS, not GSM), phones with the Qualcomm chipsets can be tuned to turn in very good performance. I have an LG U880 which pulls a signal when most others fail. I must admit an interest here, as a Qualcomm employee, but our GSM/GPRS implementation really is among the best around.
UMA has only just passed through the standardization process - and in record time, it must be said - so it's no surprise that few devices support it as yet. It's only a matter of time (and unlikely to be a long time at that). It's very much a market driven standard.
The 'base station' is registered with a GSM network because it uses GSM network components to support billing. Basically it terminates a GSM Gb interterface (which is another way of saying that it looks to a GSM network like a GPRS node), and voice (or other data) is carried as IP packets terminating at an SGSN.
The UMA design is really quite clever - it will straightforwardly allow almost any IP-capable wireless technology to use the GPRS network and billing components. It would be easy to make an access box which could 'talk' to a CDMA phone, but it doesn't really (at least as currently implemented) map to CDMA as CDMA systems use an IS-41 (or completely different) network design.
I must preface this by saying that I'm not an expert on EV-DO. I do, however, know quite a lot about mobile networks, and the information below is certainly valid for GPRS and WCDMA networks. Since it's a function of efficiently managing resources for multiple access on a cellular network, I'd expect EV-DO to behave similarly.
The key thing to remember is that it takes the network some time to allocate resources to you. When you first request to send a packet, some sort of channel must be set up.
This typically means something like: Phone pages network for access. Network grants access channel for signalling. Phone requests a channel for data transfer. Network grants this. Initial channel may well be quite low data rate (system usually turns up the data rate only if it believes you need it). You send the first packet. This takes, as noted, something around 0.5 sec.
Once you have a data connection, the system will normally hold it open for some time (configured by the network), and then drop it. It's important not to allow this to happen. Setting keep-alive to, say, 10 sec (exact value depending on system - determine by experiment) will help to keep the data connection in an operational state.
I should say that exactly how the network will behave is extremely configurable, and there is a delicate trade-off (for the network operator) between allocating resources efficiently between multiple users, and the latenies involved in configuring channels more often than necessary.
In my experience, even GPRS is usable with ssh, and WCDMA can do X and Citrix quite nicely, but you need to know how to keep the connections active.
Having worked in embedded products with both Linux and WinCE, I feel in somewhat of a position to comment.
Both platforms had advantages and disadvantages. In general, Microsoft has *far* better documentation, and is simpler to get up and running (MS basically provides a step by step guide to the things you need to do, and it has pretty much minimised them).
Linux is more difficult to get started with as the documentation and instructions on what to do do not really exist for embedded products (the parent is wrong on this point - there's no 'mobile phone HOWTO...', or really anything approaching a good reference), and the developer population is much smaller in the embedded space than on the desktop (many of them work for your competitors, too, so may not help out much!). However, having the source is *really* a boon once you have some understanding of the platform.
A simple example: under MS, we had no way to hook into the ARM exception handler, and one of our (very gifted) guys had to look until he found the right entry point - by disassembling part of the kernel. A lucky guess finally found the right place to set a breakpoint. Under Linux... you set a breakpoint at the line of code you wanted.
In the embedded space, there is often no particular advantage in portability between Linux and MS, as the legacy codebase probably wasn't based on either - an embedded RTOS such as pSOS+ is more likely, or even a proprietary kernel. Thus you have a porting job in either case.
I should also note that the MS eVC++ compiler produces *far* better code than GCC (which is pretty sucky on ARM, but excellent on x86).
So far as platform is concerned, MS provides a very strong integrated suite of apps. Linux provides... a kernel. There are third parties who can provide the rest of the things you need to build a phone (generally not free, though).
I would say, overall, that you can get to market pretty quickly with either - just depends on the product you are trying to get to that market.
It's clear that many of the people here haven't worked as a contractor, and don't really understand the concerns of the corporates who might hire your services.
I should preface by saying that my direct experience applies to the UK. I guess that you're in the United States, although you don't say (it's wise to do so when asking legal-type questions). However, since the US has a similar legal system to the UK, at least some of what I say is likely to be applicable.
I've worked in all of the different positions: as freelance contractor, as PHB-type and as Director of a medium-sized consulting company, so hopefully I can give some insight into what is important. However, IANAL, and would recommend legal advice if you're really unhappy about sopme aspect of a contract.
First thing: you really need limited liability and professional indemnity insurance. In the UK you can buy a company for around £100. I guess you should be able to get a ready-made corporation in the US for something similar. This protects your personal assets in the event that a contract goes bad. Professional indemnity insurance will cover you if (for example) an exploding blogsnatch factory controlled by a database you worked on suddenly explodes for some unlikely database-related reason. It's pretty cheap (about £300 p.a. in the UK). These things protect you. I recommend them highly, even though I never had recourse to use them.
For all those who say 'present your own contract', I'd have to say that, for most freelancers this simply isn't an option. You'll need to start with what is offered to you or go hungry.
What does a conract mean
This may seem a little strange, but generally a contract tells a story - it really should say what is expected of you and what you get in return. Try to read past the legalese and understand what it is trying to say.
Although many contracts are really quite poorly drafted, you should find at least the following:
So first go through and understand what is being asked.
Negotiation time
You do have some power to modify a contract, but understand that companies have their red-lines as well. The usual procedure is something like the following:
This is where the advantage of trading as a company arises: even the most pointy of PHBs can understand that a company has several customers, hence a company cannot possibly agree to 'all your code are belong to us'. You'll have no problem with this type of clause if you're incorporated.
However, the company needs to know, for certain, that they own the code you create for them. This means that you may need to address:
Compiler optimisers
I've used quite a few compilers - both desktop and embedded - in anger. Most of the desktop compilers are really quite good at micro-optimisation. The embedded compilers are more of a mixed bunch.
More specifically
GCC (for x86 and PowerPC) is a very good compiler these days. Some of the other ports (notably ARM) are pretty poor at optimising for instruction set features (some optimisations come for free on all ports as they are done before code generation)
Microsoft, much maligned though they are, produce good compilers, although I have found that their 'maximum' optimisation level can sometimes be a little too aggressive, and produce unexpected results in some cases (I found this with eVC++ for ARM, for example).
You may guess what I do for a living if I say that the ARM toolset produces superb code, with optimisations which can account for specific characteristics of Cache, MMU and pipeline. It is difficult to better this compiler in assembler unless you really know what you're doing.
Things compilers generally cannot do
Frankly, this is no surprise to those of us who have seen the standardisation process at work for a number of years. I work in mobile telecomms, so no surprise if I take my examples from there:
I could go on, but...
Thing is, you have to look at what standardisation represents to the participants. It's an opportunity to gain licensing revenue from your patent portfolio, so you need to get as much of your IPR into the standard as possible.
To do this, companies often make short-term alliances (i.e., I'll vote for this technology of yours if you vote for these technologies of mine) as a means to push the process in a preferred direction.
In the case of UWB, there are two groups of companies each (probably) with significant IPR in one of the two technologies, so who stand to gain big bucks if their preferred solution is chosen. Each group is powerful enough to block the other, but not powerful enough to prevail. After a period of deadlock, this is the only real way out.
You can't even make a purely technical argument for one or other technology. OFDMA is slightly more spectrally efficient than CDMA (with the emphasis on 'slightly'), but seems better suited to 'broadcast' style applications than to 'many bidirectional paths' of communication. The differences are small, but each side can claim that they are 'right'.
As other psoters have suggested, the market will decide. The UMTS TDD mode I mentioned earlier is virtually unheard of in the marketplace: all of the major UMTS systems use WCDMA (although many of the ideas in TDD have surfaced in the Chinese TD-SCDMA standard - no surprise as Siemens was a major backer of UMTS TDD, and is now doing R&D in China for a system using similar technology).
If you remember that standardisation is politics, with interoperability as both the price and outcome of the political process, then you won't be far wrong.
Couldn't agree more.
I'm working on an embedded Linux project, so had to put together a Linux build host. We're basically a Windows XP house, so the in-house IT people don't know much about Linux. They gave me a copy of RHEL WS and left me to get on with it.
This is the *worst* distro I've ever used (I've used Debian (preferred), SuSE, Slackware and Lin--whatever, over many years).
HW support is appalling: my box is a twin CPU HP server with an ATI Radion 9800 (I think). Should be normal fodder for an 'Enterprise' Linux
1) Detected the graphics card incorrectly, leaving me with no X. Offered no way to fall back to the framebuffer or SVGA without reinstalling (at least that I could see, or find in the 'support' pages). Back to good old 'edit XF86Config by hand, then.
2) Ships with a seriously broken version of Kerberos that won't talk to Active Server 2003. This is a reported bug which turns out to have been outstanding of nearly a year, and you can't connect to a Windows AD domain until it is fixed. RH seem to have no interntion of fixing the problem, but you basically pay the $$$ to connect the thing to a Windows network, right.
3) Developer packages seriously broken. Missing header files, incorrect configurations. The whole thing is a mess. I've basically had to remove most of them (at least they're optional) and install from source.
4) Up2date is really slow. I often see modem-like transfer speeds during update (over a T3 connection...). Clearly their servers can't help. I generally see far better speeds for Debian mirrors on my home ADSL link.
Unfortunately, RHEL is the corporate 'standard'. I'd never pay money for it, and strongly recommend almost anything else. I have no objection to the price (for corporate purposes $300 per year or so is nothing), but I have a strong objection to paying top prices for an inferior product.
If you don't need support (and know what you're doing), I'd recommend Debian. Otherwise, SuSE is so far ahead of RHEL it's not funny.
I'd have to agree with both of your points.
To be honest, and this is after using Ocaml extensively for a while, Ocaml's object system doesn't really work very well. I loved the language before I started to use the OO features, but working on LablGTK2 drove me crazy. The syntax (both for open types, and for keyword arguments) is ugly and poorly documented.
For command line software (mainly short scripts and 'parser' type applications), I still love the speed (both of development, and execution) of Ocaml, but I don't touch it for GUI programming any more.
I'm also inclined to agree that the core developers at Inria have moved on to other things. Whether this is because some of the language 'features' are seen as dead-ends (I'd suggest the implementation of OO polymorphism is one which doesn't meet real-world needs), or whether their research interests have somply moved on is not clear.
While many (including myself) complain at the lack of an elegent GUI interface, I've also looked into what would be needed to do such a thing myself (my poison of choice was wxWidgets, as I use Mac, Linux and Windows regularly, and *much* prefer having native look and feel. Gtk is really only fine for Linux), and the work involved looked very painful, unless you would accept an ugly interface to the C bindings for wx (I looked at using the wxEiffel C bindings as a starting point).
I know there's a fledgling wxCaml in the works, and I wish them luck. I agree that it would be a shame to see the language wither on the vine, although I fear that this is what is happening.
Having said that (and I speak as a real-time embedded developer), I am utterly convinced that many of the ideas embodied in Ocaml (type inference, functional/imperative programming mix etc) are the future of high-performance programming, and will eventually largely replace C for all but the lowest level tasks.
I doubt that Ocaml will be the language to do that, however. It will probably be a successor which learns from its shortcomings and builds on its (many) strengths. Probably a language yet to be written, in fact.
I initally used thebook as a resource for learning Ocaml. My review would be more like:
Language Core
This covers the basics of the language, although the presentation of material is somewhat disjointed, which makes the book challenging to use as a reference in the first programming steps.
The book is clearly a translation, and in some areas the translation is not especially literate, although the meaning of the text is always pretty clear.
The worst problem with the book is that it is severely out of date with respect to the latest distribution of Ocaml. The aspect that had me tearing my hair out was the lack of coverage of open types - something which is essential to using a GUI toolkit, and which is somewhat complex as there are rules which may come as slightly odd to those used to the implementation of polymorphism in other languages.
Development tools
This section gives a good overview of many of the tools available, and is probably the best part of the book. The major ommission is Ocamlp4, which, again, post-dates the book's authorship. Users on Windows (bow your heads in shame... this is Slashdot) will find that their platform is not really covered, which is a shame, as there are a few differences from Windows.
The rest
Coverage of libraries is way out of date. For a modern user, the only serious GUI choice is LablGtk2, and it is not covered at all. There are other problems in a similar vein.
The book contains a number of extended examples. While these smack of being 'undergraduate projects', they do indicate some of the techniques and paradigms of programming in Ocaml.
ConclusionI wouldn't recommend this book. It's too far out of date (imagine buying a book on Perl 4 or Python 1.5). Since the Ocaml manuals are quite comprehensive, and there's an excellent tutorial at merjis.com, which is fast paced and does cover modern language features, there's really no need for this without a significant update. Sorry.
Mod chia_monkey up, he's right.
The whole introduction of UMA into the GSM specs was a masterful piece of politics, masterminded by.... the cellular operators.
UMA allows cellular networks to offer new, enhanced network features to subscribers very quickly and easily, and still bill them via their cellphone accounts.
Most newer mobile phones are entirely able to operate as modems, and WiFi (or anything else: ultra-wideband, even a good old 100Base-T Ethernet connection) *could* be built into a phone.
If you start to think about a phone as offering a universal modem capability in the future, you're getting close. Expect to see the first combined 3G + WiFi PCMCIA cards pretty soon. The UMA box is just what you need to take advantage of such a product.
It seems like no-one has really gotten the point, so I'll try to explain.
What's really going on here is GSM has one thing to offer to wireless technologies which many of them need: a reliable, proven billing system, supporting roaming between networks, which gives the ability to access millions of paying subscribers (who already have cellphones).
There has been a realisation that there are somethimes reasons why it may be better to use a short-distance, but high speed technology in preference to a cellular (even 3G) based service.
Things it probably isn't about:
What is it?
What we are talking about is basically a gateway box which allows some other technology to talk to the GSM A/Gb interface, which is what connects the Base Station System (BSS) to the Mobile Switching Centre (MSC) (for voice calls) and the GPRS packet network.
This enables a network which can speak IP to interface with a network which speaks GSM/GPRS. The data traffic goes through the GPRS core network (SGSN to GGSN to Internet), and voice traffic (e.g. VoIP) could be routed straight to the MSC, and hence to the PSTN (or Plain Old Telephone System).
Everything which passes through a GSM/GPRS core network is subject to authentication and billing, so all of a sudden, you can have more interesting payment plans than are typical for WiFi networks - pay as you go, pay per MB, unlimited packages etc... (look at all the cellular plans out there).
The probability is that you'll also need to start seeing SIM cards in laptops - GSM security is pretty much premised on using a SIM card (although you could get out of using one if really required.
I'm quite surprised to see such an inept statement from ZDNet. UMTS is an umbrella term which covers the set of specifications for GSM, WCDMA and their interworking.
In this case, Cingular is focussing on WCDMA which, at the air interface layer has more in common with CDMA2000 than with GSM. WCDMA uses a CDMA-based air interface with upper protocol layers based on GSM (you could view this as like moving from copper Ethernet to fibre: the upper protocol is still TCP/IP, but faster...)
At the risk of starting a flame war, I think it's reasonable to say that today, GSM/WCDMA has a more highly evolved set of upper layers than CDMA2000, but CDMA2000 has a better optimised radio interface (EV-DO is considerably faster than the 384 kbit/s you can get with WCDMA - I know colleagues who consistently get around 800 kbit/s real data rates with EV-DO modems, where around 200 kbit/s is more realistic for WCDMA).
While, as explained above, I wouldn't like to characterise either CDMA2000 EV-DO or WCDMA as superior to the other, I think it is reasonable to state that EV-DO is the more mature and stable system right now. I use a 3G mobile in the UK, and there are still a few glitches around the edges, although things are improving rapidly (the main issue is handover between WCDMA and GSM, which is technically very challenging, and isn't an issue in CDMA2000 networks). I will say that if you're interested in data on the move, both EV-DO and WCDMA offer a user experience which is subjectively very similar to using a DSL connection, and is light years ahead of using GPRS (or CDMA2000-1X) in the performance offered.
HSDPA is at least a couple of years away from deployment in commercial networks, and probably won't initially work at 14.4 Mbit/s.
As for the issue of travelling... Well, WCDMA phones (almost) all have GSM capability, so will work in most parts of the world (the only place my GSM phone failed to work in the last five years was rural Laos!), and dual-mode CDMA2000 phones with GSM capability are extremely close to market, which will enable global roaming for CDMA users on GSM networks. From a practical point of view, users of either type of network will have the option of near global roaming.
I suppose I would summarise by saying that both systems are 'good enough' for most data users, and both will offer global roaming. Most people will probably be quite happy to choose based on price plan and phone they like best...
You sound as clueless as Anna Kournikova!
Quite sure, thank you. I also put my name to my opinions...
First of all, every study I have seen has Windows Smartphone and Windows CE embeded far cheaper to deploy by hardware companies than Linux is (its not even close), so you are either lying or making things up.
Well, I'm not an analyst who writes studies. I implement this stuff, so I'm speaking from experience, not from comparing Powerpoint presentations to see which contains the larger number of buzzwords.
Cost of deployment is not a phrase you use when developing a phone. We are not corporate IT depertments. What matters are engineering cost, time to market, bill of materials, license costs and sellling price. You trade these off against one another.
And then, look att your platform. Most protocol stacks were written to run under small RTOS executives that don't present anything like a Posix (or Win32) API.
Now, if you have a separate processor to run applications, talking to your proprietary RTOS (which runs the protocol stack), porting Symbian or Windows Smartphone is fairly straightforward, and this is probably the best way to go. However, an apps processor costs $$$, and uses extra battery power.
If you want to loose the applications processor, you have to port your protocol stack to run under the new OS. Bear in mind that layer 1 of your stack is very heavily interrupt driven, and that the whole stack was written to run under a very non-standard API and you have a very tricky problem. It is not a breeze to do this, but a very significant engineering effort.
Now, the Linux API is, paradoxically, slightly easier to port to than Symbian or Windows. The reason is that:
Now, a very big win with Symbian (Series 60, more precisely) and Windows Smartphone is that you get a UI and some key applications with the system. This is a very big deal, as that's an enormous amount of engineering effort.
/. readers could relate to), Windows Smartphone or Symbian cost significantly less than that (can't say what though).
Currently there's no obvious Linux UI candidate (QT Embedded is aimed more at PDA form factors, and costs $$$ anyway). However, many phone manufacturers already have UIs, and anyway, in many respects, the operators look on smart devices as simply a platform for Java/MIDP.
In such a scenario, a Linux port may make sense. This is because of my other point, which you managed to completely misunderstand.
I said that "licensing fees for embedded OS are way below those for, say Windows XP Home". You say: "where exacty did you see this Microsoft smartphone which had Windows XP embeded in it? LOL!".
What I meant is that if an copy of Windows XP Home (i.e for a PC, you know, the big beige box under your desk) costs, say, $100 (or a price that most
Even so, over a production run of several million phones, the difference in licensing fees between free, but porting your UI and some 10s of $ pays for quite a lot of engineering effort, and may let you sell your phione for less.
So what I'm really saying is that you look at the resources you have, the number of phones you expect to sell and the hardware BOM... and you make an engineering decision. There are good reasons to go with any of the systems. If you have an apps processor, you'd have t
I design mobile phone software for a living, and have done so for 15 years, so I feel qualified to comment on some of these issues:
...or alternatively, you could join a company which manufactures this stuff, and get paid to hack it ;-)
- Yes, Linux smartphones will probably be a little cheaper than those using Symbian or MS Smartphone, but the difference isn't large: licensing fees for embedded OS are way below those for, say Windows XP Home. Don't forget that in may parts of the World, operators subsidise phones, so this small difference may not even be noticable to the end purchaser.
- Of course anyone offering a Linux-based smartphone will abide by the GPL: this means that they'll publish kernel code and any patches. However, don't expect to see GPL'd protocol stacks or device drivers any time soon. Same goes for the UI, which will likely be proprietary all the way. This means that you don't get to review the protocol stack software and fix any bugs in it.
- A Linux smartphone could be developer-friendly, but I doubt it. Operators really don't want open devices, and while they're paying the subsidies, they get what they want. You could go buy an unlocked version at full price (say $600) instead of getting it free on your plan, of course.
So, to summarise, a Linux smartphone will, unfortunately, mean DRM, operator lock-down and only slightly lower pricing for most users, unless enough potential customers go to the operators and insist on openness and no DRM.
The manufacturers are perfectly capable of providing open devices (in fact, they would prefer to, as we actually like having a vibrant developer community). Symbian, Qualcomm and Microsoft all offer pretty good developer support, if only you could get a phone which isn't locked down. Normally there's a PC-based emulator/debug environment, a cross-compiler/linker and lots of sample code available for free (as in beer) download.
Actually, you exaggerate slightly. You get a very good set of sample device drivers, sample BSPs for some commercial cards and a few other bits, but you don't quite get everything.
For one thing (very pertinent to a smartphone), you probably won't get much of a protocol stack - which is fine, as you're supposed to provide that for yourself. What you do get (on Windows Smartphone for sure, Symbian, I'm pretty sure) is a well designed interface between the application layer (which is provided) and the protocol stack.
Of course, if you go to an OEM (Qualcomm, Nokia, TI, Infineon or whoever), you'll also get the protocol stack and a complete reference design - and few people ever stray far from the reference.
Despite a few glib comments that 'Linux runs Java, and that's all you need', Linux does not have a standardised smartphone UI (please don't say X: I love it, but I'm unlikely to need full network transparency to my telephone...)
I'm working on porting a real cellular protocol stack to Windows Smartphone as we speak.
Despite being no fan of Microsoft desktop products, I have to say that in many respects, Smartphone is a very well thought out product. They have a slick, and very well designed UI, a decent set of apps, and a kernel which is relatively easy to get to work on a new platform.
I agree with the poster who complains about the MS build system (dreadful), but it does the job, but the kernel itself really does have some good things going for it.
Symbian is a great operating system platform, but porting an existing protocol stack (written, as they nearly all are, in plain old C) to Symbian with its 'C++ from the ground up goodness' (polymorphic device drivers, anyone?) is an enormous task - there are something like 10,000 source files in the system I'm dealing with, and the thought of doing a Symbian port is, frankly, terrifying.
The other (non-technical) problem is that Symbian seems to be snatching defeat from the jaws of victory by becoming increasingly dominated by Nokia (which is great if you're Nokia, not so good if you're anyone else). If the platform had remained true to its original promise of being a real consortium, it would probably have a much more successful future ahead.
Linux is a great option at the low end, but there is no decent smartphone UI (QTopia is more aimed at pen controlled devices), so you'd have to roll your own, which takes away from the standardisation aspect of having a 'real' OS. FreeBSD is even better, to be honest because (I wish it weren't so, but this is business reality) corporates are often scared of the GPL.
In any event, the way thing look in Europe, all any smartphone really has to do is be a decent platform for Java - operators aren't interested in supporting multiple platforms, and Java already has some traction. SavaJe seems, from what I can tell, to be basically that, but you could certainly roll a similar UI in Java for an embedded Linux kernel and have a great solution.
As the main story points out, this is a very price sensitive market. Symbian and MS Smartphone basically cost about the same, and enough to make a free platform highly attractive. It's the lack of a suitable, standardised, UI which causes the problem.
I've been working for some time now with wxPython. As a development environment it's great - there are a few behavioural oddities between Win32 and Linux, but none has yet caused me any real problems.
:-)
Couple of issues, though:
- wxPython documentation is patchy: some is excellent, some areas are non-existant
- Distributing a finished application is the worst nightmare of DLL hell. In order to enable my users to run the application on Win32, I need to deliver:
* Python installer
* wxWindows installer
* wxPython installer
* a bunch of libraries (Numeric and matplotlib are the main ones)
* my application
I've yet to pursuade any of the installer options to automate this under Windows. Linux is trivial: a 5 line shell script with apt-get to a local archive does the trick nicely
I used Boa as a convenient way to construct my GUI framework - it's an excellent piece of work in that respect, and has the best debugger I've yet found for Python. However, once the GUI framework was implemented, I changed back to editing in JEdit - I'd concur with the comment about tab controls, but Boa is quite excellent considering it's basically the work of one guy.
I'll also make a gratuitous plug for matplotlib. It's shaping up into a great lightweight charting toolkit. I've written a (currently pre-alpha) wxPython backend for this, and have been very impressed at what John Hunter, the architect has done with the GTK and GD backends.
I've had the (probably unusual) experience of using headhunters as a software engineering manager, as an engineer and (which is the unusual part) I've also worked in a role which involved business development for an outsourcing consultancy (which means I've at least a fair idea what headhunters encounter from their clients).
What I'm saying applies only to the UK market - things are doubtless different elsewhere.
First thing is that there are literally thousands of headhunter agencies - ranging in size from 'one man and a dog' to multinational corporates. Only a small percentage have more than a minimal understanding of the market in which they are operating. In addition, staff turnover is generally quite high - I've heard of headhunters with an annual employee turnover of 115%!
Now my advice - for the UK market - is to ignore the company and look for the people. My favourite headhunter (in the embedded/telecomms sector) has worked for at least four different companies since I have known him (about 5 years now). On my behalf as an engineer, he has always:
- put my CV forward to jobs for which I was both well suited and which I found interesting.
- asked my permission before submitting my CV to a company.
- been well informed and honest about what a role was (I've never had that sinking feeling at an interview arranged by him that I was being interviewed for a different job than the one I thought I was being interviewed for)
- been honest about the salary on offer
To me as an employer, he always:
- Worked for some time with me to understand what I was looking for. Not just technically, but also in personality (for team fit), amount of travel required in the role etc.
- Let me know honestly what candidates thought shortly after the interview.
To my mind, this is the level of service that I would expect, and it is all too rarely achieved.
For those who complain about headhunters who submit CVs without asking, you should understand that there are websites containing tens of thousands of CVs, which you can access for a subscription (and virtually all headhunters have subscriptions to all of them). Often, by placing your CV on the website, you've granted permission for distribution already.
Also, have some sympathy for the headhunter. The ethics of the business are that if a CV is submitted by more than one headhunter, the first one to submit will be used if the person is eventually employed. These people have to work very quickly.
Employers often demand an unreasonably fast response (I've seen a requirement from a large multinational to submit at least 20 CVs for each position within 24 hours of the job description being provided, or you can't do business with them). It simply isn't possible to do a thorough job in such circumstances, so many (probably most) resort to simple keyword' matching on CVs.
In short:
If you're an engineer:
- Find two to five good headhunters (people, not companies!) and stick with them.
- Make it clear that you expect your CV to be passed on only with your permission.
- Ask the headhunter the identity of the company to which you are being submitted (and let him/her know if you've already been submitted there by someone else - it avoids wasting their valuable time).
- Ask about the realistic salary on offer - and make it clear if this does not meet your expectations.
- Spend time explaining your skills, aspirations and preferences.
If you're an employer:
- Spend time talking to a few headhunters before you decide which ones you will accept CVs from.
- Find out what they charge (and be realistic, they need to charge about 10% of starting salary to make a profit, so 15% is not an outrageous figure if the service is good).
- Take time to create an accurate job description, detailing what skills, work and personality are required.
- Work with only a few headhunters, and make it clear that if they send unsuitable CVs, all their submissions will end up in the bin, u
I've been away from the Internet for a week or so, so apologies for the wait for a reply.
You're right to identify spectrum as a scarce resource, and the 3G networks generally do try to make a better job of allocating it than current technologies - you should get about 3-5 times the number of voice conversations in the same spectrum as you would with a 2G technology. You could argue that that isn't a great improvement, but it's really the start of things - GSM networks have been optimised way beyond the expectations of the original design.
Actually it isn't too dificult to do multicasting and the like provided that the use of uplink resources (i.e. from user to network) is minimal or (preferably) eliminated. Whether it's something with real uses rather beyond showing your mates that you can watch a football match on your phone is another question, but I could imagine multicasting e.g. local traffic information.
It's true that many of the new services which are being hyped are rather greedy of bandwidth (384 kbit/s videocall anyone?), but I really doubt that these will be used very heavily - and if they are, the user will have to pay dearly for using all that bandwidth.
It's certainly true that some customers on one of the commercial 3G networks have had difficulty making video calls on their shiny new toys as the network was 'busy' (despite relatively few subscribers as yet) - as you say, the resource is limited.
The theoretical limit for GPRS is somewhere in the 170 kbit/s area, but this depends on a very good channel (unlikely), a network supporting coding scheme 4 (unlikely) and no users sharing the same radio resources (unlikely). I've never seen more than 58kbit/s in a cabled RF environment with coding scheme 2 (which is what everyone uses in parctice) and no other users of the resources. This is probably good enough for many mobile applications, although I'll note, once more, that GPRS is slow in performing reselection between cells while a transfer is taking place.
Actually, in the UK at least, the most compelling reason to choose the 3G network ('3') is that is's quite a lot cheaper than the established GSM players - you get about five times as many minutes for a given subscription as you would anywhere else here, and the phones are being practically given away.
I'd be the first to agree that the 3G phones on the market today are little better than prototypes. They're bulky and use more power than GSM because they are, effectively, two phones inside: GSM and WCDMA (more accurately, there are two separate chipsets). This will change, and pretty soon. I, for one, have a phone in my hand which is little bigger than a current GSM phone, and has about four days standby time, but supports data up to 384 kbit/s (you'll reliably see no more than about 45kbit/s on GPRS with UK networks). You'll be able to buy something like it in a few months time.
GSM (and 1x) are mature technologies - they've been around for a long time, and there has been plenty of time to perfect them.
Fact is, at least for GSM, in many locations the networks are already at maximum capacity *for voice*, so 3G is needed simply to keep pace with the demand for voice calling. GPRS is OK for some data applications, but is very poorly suited to streaming/multicast applications (mainly due to the fact that it is slow in selecting between cells, and typically looses at least a couple of seconds of data).
I'd probably agree that 3G was launched too early, and with too much hype, but make no mistake, it is coming, and as it matures it should represent a compelling technology for many users.
What do I use Python for?
Pretty much anything which doesn't require real-time performance (which means most things).
To expand, I work in the Mobile Telecomms realm, so most end-user code is real-time embedded C which tends to be heavily optimised for both speed and size.
Python is great for writing simulations, tools for processing logfiles, regression test suites (you do test, right!), and GUIs (which almost never need to have very high performance).
Strengths:
* I'm surprised that few people have mentioned that Python is much more expressive than C, C++ or Java - you simply get the job done in fewer lines of code, and the code is exceptionally easy to read.
* There is a rich set of built-in data types, and good support for basic Object Orientation - it's not the most OO implementation out there, but it's more than good enough for most designs. The fact that lists and dictionaries are part of the language means you can concentrate on expressing the problem, rather than implementing yet another linked list class.
* Very simple, regular, syntax. BTW, I'm neither especially for nor against the whitespace thing. It does mean that most Python code is stylistically similar, so it's easy to read other people's code, but it is a pain if you use different editors (or differently configured editors) to work on modules written by others: if I edit code where spaces were used for indenting and I use tabs, the code will behave unexpectedly, because Python sees a tab as equal to a single space. This can occasionally be very annoying, and difficult to track down)
* The dynamic typing and reflection are a joy to use - simple yet powerful.
* The ability to use a functional programming style when appropriate, without enforcing it (I personally find using FP all the time a little too rigorous - I just don't always think recursively).
* The library covers most things - and there are excellent, really easy to use hooks to GUI libraries (I mainly use WxWindows and some Qt).
* Easy to call C/C++ modules using SWIG - in fact it's almost trivial, so you can prototype in Python and replace the speed bottlenecks with C or C++ code to get good system performance. The profiler is quite helpful in doing this.
* Code is usually extremely portable between Linux, other Unices and Windows.
Weaknesses:
* I've yet to find a really good debugger. About the best I've found is the one in Boa Constructor, but it's some way behind using, say, DDD on C++ code.
* Performance isn't the best for serious number crunching, but it's adequate for most things.
* It's painful to package up finished code into a 'product'. If I use Python + WxWindows + WxPython to implement a GUI for a performance analysis tool, I'll need to deliver three installers along with my code. Fortunately my end-users for this stuff are also software engineers, so they generally get the install right!
Why learn another programming language?
This is more a philosophical question. You can do anything in any Turing complete programming language (that'll be all of them, then), if you must.
However, different languages tend to engender different ways of thinking about problems, so by leaning a new language, you learn new ways of thinking which can often help you in other languages you know.
I try to learn a new language each year (so far: C, C++, Java, Shell scripting, Python, Erlang, SDL, Lisp, Perl and more assemblers than I care to remember). I've gained the most from learning C, Python and Erlang, as they each represent very different approaches to a problem.
It's still C which earns my bread and butter - nothing else really comes close for hard real-time work - but some of the techniques I've found natural in Python have proven to translate surprisingly well into C - I'd probably not have thought of doing things that way if I didn't learn Python.
I'd recommend any programmer who works primarily in C or C++ to learn a scripting