This maybe true, but it isn't what the user is paying for - they are paying for the service.
If it's too expensive, don't use it! Personally I think texting is convenient and less intrusive than interrupting a person with a phone call to ask a quick question which is neither urgent or important (e.g. where are you going out tonight). I use it a lot and pay the extra, and am happy for this service.
...was to make an RC car controlled by DTMF tones hooked up by a microphone on top of the car. I would then put my mobile phone on it, set it to auto answer, and then call it to drive around.
Of course, the shielding for the audio circuts would have to be well shielded to avoid TDMA noise, but I'm sure that's simple to design around.
And of course, because they are cheaper than handhelds, both to purchase and to maintain
I wonder if this is because the smart phones are subsidised by the phone networks, who make additional income from a contract and services (voice, SMS, MMS, GPRS, downloading games/ringtones etc.. and any other features that can be used from the smartphone).
I'd doubt that the Bill Of Materials is much different for both device...
Well, really it is simple. If you want everything to be more reliable you will have to pay more for it - development and debugging cost money and time. Time to market is often an important factor and hence the software will be released with testing only to ensure some mean time to failure, if that.
Software could be more reliable, but it would also cost more, and most consumers don't like that... (or know what software is!).
Urban performance legend #1: Synchronization is really slow
I'm not sure about this. I read advice on the web saying the synchronisation was slow and so changed all instances of Vectors into ArrayLists in a program I was writing. The program is very simple and just reads binary data and translates into strings, yet making this change certainly made the program run a lot faster (about 5%).
Urban performance legend #2: Declaring classes or methods final makes them faster
Well, lets face it - it can't make them any slower, can it?
Urban performance legend #3: Immutable objects are bad for performance
When I use the in built JVM profiling for my program, I find that code in the String class is the largest bottleneck by far. The program does a number of string concatenation using '+', and changing this such improved things a fair amount, although doesn't stop the String class having the largest bottleneck. I'm using the Java 1.4.1 JDK tools - maybe commercial compilers & JVMs are better, who knows
Essentially, higher level languages should result in faster code than lower level ones, since the compiler has more scope for optimisation and also gets more information about what the program is trying to do, although this Urban performance legends article seems a bit shaky to me.
Maybe I'm just depressed or something, but I kinda agree that software is on the downfall, in the Western world anyway.
There are lots of shit hot programmers in India and other places full of cheap labour; software is starting to go the way of Nike trainers and consumer electronics goods - manufactured and assembled far away for a fraction of the costs of development in the Western world.
There also aren't a huge number of great new things to build - increasingly it is cheaper to buy off the shelf components and modify them; who in their right might would try to build a competitive database when there are already hundreds of mature engines out there ready to choose from.
Maybe as a software engineer the only roles will be in research and development, or specialist niche applications (embedded?) - certainly I recon it's gonna be shrinking over the next 10 years.
Can't mobile IP already do this? Surely this is more about the billing, allowing the network to keep charging the user per octet for some 'service' even when they go onto a wireless lan, which may or maynot be free to use. Likely the network hosts the mobile IP home agent on their network somewhere and charges the subscriber per octet forwarded through it to outside their network....
Now lets also check what a 128MB MMC card costs, a mear 35UKP or around $50.
Adding $50 to the bill of materials for a phone is *huge*.
So as far as I can see all they need to do is provide a MMC/SD slot somewhere on the phone.
Some phones already support MMC cards. The problem is more one of marketing. If you go through the effort of adding mapping support to the handset, you want to be sure that people buying the phone can and will use it - otherwise you've just increased the price of the phone software for nothing.
So what's to prevent phones right now from doing mapping?
Nothing really - take a look at the Garmin NavTalk for an example of a GSM phone that also provides mapping applications.
Couldn't someone write up a java applet or some other fuctionality that could do this on existing phones? The worst thing you should need is a minor firmware revision to allow java to access the GPS data.
The problem you're up against is the amount of memory required to store the map data, and also getting access to specialist map information. This is probably the constraint that prevents most phones from containing such functionality by default - adding memory increases the bill of materials, and consumers don't like that.
Of course, there is nothing to stop you using a wap/web browser on your phone and using a service like Multimap to get your map data (although you'll need to be in coverage and pay for the GSM or GPRS call depending on how you want to get your data).
That's great. As a non-subscriber I have the benefit of better filtered/corrected stories where the people that subscribe are doing the purification before it hits my eyes. Net result = I get better content - woohoo!
On the other hand, I've seen C and C++ programmers come up with the most amazingly fucked up atrocities to get around the strongly-typed nature of those languages
I use free-online as my ISP in the UK. They are pretty cool, giving me 250MB of webspace, a shell account on a Redhat box for CGI (has gcc and other stuff installed), MySQL, Perl, PHP and support for Frontpage extensions (urm, maybe not so good). No ports blocked either, and I don't think they are against running servers:)
A good price too - much better than AOL broadband and that crap. I think that these folks are the uber geek-friendly ISP in the UK - I'm certainly very happy.
When the current is on, the window is clear. But flip a switch to turn the current off and the glass goes opaque
Hmmm, shame it isn't the otherway around - sounds like it's going to waste lots of juice given that the window is probably going to be in 'clear' mode 99% of the time.
That is a nasty attack, but most firewalls of any sort block packets from the outside pretending to be from the inside, since there are _way_ too many Bad Things that can be done otherwise,
Phew! Let's hope Jolt have good firewalls!
Also, it's actually not as nasty an attack as it looks, because the server is probably on an Ethernet behind a router
Erm, it will probably loop straight back in the computer (at the IP layer) without even touching the network device since the source IP address would become that of the server! (Assuming not blocked by a firewall, as you point out)
It would be possible to send the UDP packets at the game server with the source IP addresses spoofed to be the IP address of the game server itself. Nasty.
This would probably be self limiting since as the server slows down it would reduce the amount of packets it sends to itself, but it would probably be pretty nasty to the server as it sends and recieves flood loads of crap.
Hmm - so each payphone is going to have the bandwidth of [roughly] 1 DSL line. This doesn't sound like much.
The other problem I forsee is that people living near to phone boxes may just decide to use the WiFi instead of getting DSL installed depending on how it's priced - this would be bad since the WiFi bandwidth could get used up by these static users (Although the phone company wouldn't care if they still got cash).
On the plus side, it may mean that many more exchanges get DSL capability installed.
... up until this point I thought it looked quite good. Unless you can turn it off and get around it, it's not going to be too good for embedded realtime systems - a reserve for C for quite a while now.
Also not sure about the intrinsic thing in Phobos - isn't it the job of the compiler to spot processor specific optimisations and apply them in a transparent manner?
A very different approach to Google - from this months Wired:
"Over the years, Brin and Page have resisted pressure to run banners, opting instead for haiku-like text ads and unintrusive sponsored links. They've taken a stand against pop-ups and pop-unders..."
Apparently the sponsored link sites aren't even allowed to use popups.
I guess though, The Viking maybe worried that not having the correct skill could quickly preclude him from a job he might like to do (jobs I've applied for have had some form of brief C and Java test).
The results show the demand for people with different language skills, but gives little insight into the type of jobs that are available, or the languges that they use.
Much more interesting would be a breakdown of the different tech sectors vs languages used, although I'm guessing that most of it would be fairly obvious (Web stuff using mainly php and perl, C for embedded etc...)
From the question, it sounds like The Viking is trying to work out which language will give him the most job opportunies. My advice would be to select at least a couple of tech sectors to refine the search and then re-generate the stats. It might be that there are lots of very similar opportunities for VB programmers which The Viking would find to be boring as shit. Better to find a language with the maximal spread across different job types:)
Slashdot Mirror
This maybe true, but it isn't what the user is paying for - they are paying for the service.
If it's too expensive, don't use it! Personally I think texting is convenient and less intrusive than interrupting a person with a phone call to ask a quick question which is neither urgent or important (e.g. where are you going out tonight). I use it a lot and pay the extra, and am happy for this service.
... it was some sysadmin or the person who setup the network!
That's like blaming the ethernet for hacking my box!
...was to make an RC car controlled by DTMF tones hooked up by a microphone on top of the car. I would then put my mobile phone on it, set it to auto answer, and then call it to drive around.
Of course, the shielding for the audio circuts would have to be well shielded to avoid TDMA noise, but I'm sure that's simple to design around.
And of course, because they are cheaper than handhelds, both to purchase and to maintain
I wonder if this is because the smart phones are subsidised by the phone networks, who make additional income from a contract and services (voice, SMS, MMS, GPRS, downloading games/ringtones etc.. and any other features that can be used from the smartphone).
I'd doubt that the Bill Of Materials is much different for both device...
Well, really it is simple. If you want everything to be more reliable you will have to pay more for it - development and debugging cost money and time. Time to market is often an important factor and hence the software will be released with testing only to ensure some mean time to failure, if that.
Software could be more reliable, but it would also cost more, and most consumers don't like that... (or know what software is!).
Urban performance legend #1: Synchronization is really slow
I'm not sure about this. I read advice on the web saying the synchronisation was slow and so changed all instances of Vectors into ArrayLists in a program I was writing. The program is very simple and just reads binary data and translates into strings, yet making this change certainly made the program run a lot faster (about 5%).
Urban performance legend #2: Declaring classes or methods final makes them faster
Well, lets face it - it can't make them any slower, can it?
Urban performance legend #3: Immutable objects are bad for performance
When I use the in built JVM profiling for my program, I find that code in the String class is the largest bottleneck by far. The program does a number of string concatenation using '+', and changing this such improved things a fair amount, although doesn't stop the String class having the largest bottleneck. I'm using the Java 1.4.1 JDK tools - maybe commercial compilers & JVMs are better, who knows
Essentially, higher level languages should result in faster code than lower level ones, since the compiler has more scope for optimisation and also gets more information about what the program is trying to do, although this Urban performance legends article seems a bit shaky to me.
Simple, you make the disk last for 49 hours, so even the faulty ones expire after 48 hours. No one will complain about the extra free hour
Mike
Maybe I'm just depressed or something, but I kinda agree that software is on the downfall, in the Western world anyway.
There are lots of shit hot programmers in India and other places full of cheap labour; software is starting to go the way of Nike trainers and consumer electronics goods - manufactured and assembled far away for a fraction of the costs of development in the Western world.
There also aren't a huge number of great new things to build - increasingly it is cheaper to buy off the shelf components and modify them; who in their right might would try to build a competitive database when there are already hundreds of mature engines out there ready to choose from.
Maybe as a software engineer the only roles will be in research and development, or specialist niche applications (embedded?) - certainly I recon it's gonna be shrinking over the next 10 years.
Can't mobile IP already do this? Surely this is more about the billing, allowing the network to keep charging the user per octet for some 'service' even when they go onto a wireless lan, which may or maynot be free to use. Likely the network hosts the mobile IP home agent on their network somewhere and charges the subscriber per octet forwarded through it to outside their network....
Now lets also check what a 128MB MMC card costs, a mear 35UKP or around $50.
Adding $50 to the bill of materials for a phone is *huge*.
So as far as I can see all they need to do is provide a MMC/SD slot somewhere on the phone.
Some phones already support MMC cards. The problem is more one of marketing. If you go through the effort of adding mapping support to the handset, you want to be sure that people buying the phone can and will use it - otherwise you've just increased the price of the phone software for nothing.
So what's to prevent phones right now from doing mapping?
Nothing really - take a look at the Garmin NavTalk for an example of a GSM phone that also provides mapping applications.
Couldn't someone write up a java applet or some other fuctionality that could do this on existing phones? The worst thing you should need is a minor firmware revision to allow java to access the GPS data.
The problem you're up against is the amount of memory required to store the map data, and also getting access to specialist map information. This is probably the constraint that prevents most phones from containing such functionality by default - adding memory increases the bill of materials, and consumers don't like that.
Of course, there is nothing to stop you using a wap/web browser on your phone and using a service like Multimap to get your map data (although you'll need to be in coverage and pay for the GSM or GPRS call depending on how you want to get your data).
That's great. As a non-subscriber I have the benefit of better filtered/corrected stories where the people that subscribe are doing the purification before it hits my eyes. Net result = I get better content - woohoo!
Try looking here and here. The second link gives the perfect examples:
C and C++ cannot be called strongly typed. Try Haskell instead
On the other hand, I've seen C and C++ programmers come up with the most amazingly fucked up atrocities to get around the strongly-typed nature of those languages
Erm, neither C or C++ have strong type checking.
I use free-online as my ISP in the UK. They are pretty cool, giving me 250MB of webspace, a shell account on a Redhat box for CGI (has gcc and other stuff installed), MySQL, Perl, PHP and support for Frontpage extensions (urm, maybe not so good). No ports blocked either, and I don't think they are against running servers :)
A good price too - much better than AOL broadband and that crap. I think that these folks are the uber geek-friendly ISP in the UK - I'm certainly very happy.
When the current is on, the window is clear. But flip a switch to turn the current off and the glass goes opaque
Hmmm, shame it isn't the otherway around - sounds like it's going to waste lots of juice given that the window is probably going to be in 'clear' mode 99% of the time.
That is a nasty attack, but most firewalls of any sort block packets from the outside pretending to be from the inside, since there are _way_ too many Bad Things that can be done otherwise,
Phew! Let's hope Jolt have good firewalls!
Also, it's actually not as nasty an attack as it looks, because the server is probably on an Ethernet behind a router
Erm, it will probably loop straight back in the computer (at the IP layer) without even touching the network device since the source IP address would become that of the server! (Assuming not blocked by a firewall, as you point out)
It would be possible to send the UDP packets at the game server with the source IP addresses spoofed to be the IP address of the game server itself. Nasty.
This would probably be self limiting since as the server slows down it would reduce the amount of packets it sends to itself, but it would probably be pretty nasty to the server as it sends and recieves flood loads of crap.
Hope a patch comes out soon...
I wonder how this compares with email?
Probably, and the best bit is that the networks will probably still charge the user for making a call over the free spectrum - nice.
Mike
Hmm - so each payphone is going to have the bandwidth of [roughly] 1 DSL line. This doesn't sound like much.
The other problem I forsee is that people living near to phone boxes may just decide to use the WiFi instead of getting DSL installed depending on how it's priced - this would be bad since the WiFi bandwidth could get used up by these static users (Although the phone company wouldn't care if they still got cash).
On the plus side, it may mean that many more exchanges get DSL capability installed.
... up until this point I thought it looked quite good. Unless you can turn it off and get around it, it's not going to be too good for embedded realtime systems - a reserve for C for quite a while now.
Also not sure about the intrinsic thing in Phobos - isn't it the job of the compiler to spot processor specific optimisations and apply them in a transparent manner?
A very different approach to Google - from this months Wired:
Apparently the sponsored link sites aren't even allowed to use popups.
I agree wholeheartedly.
I guess though, The Viking maybe worried that not having the correct skill could quickly preclude him from a job he might like to do (jobs I've applied for have had some form of brief C and Java test).
The results show the demand for people with different language skills, but gives little insight into the type of jobs that are available, or the languges that they use.
Much more interesting would be a breakdown of the different tech sectors vs languages used, although I'm guessing that most of it would be fairly obvious (Web stuff using mainly php and perl, C for embedded etc...)
From the question, it sounds like The Viking is trying to work out which language will give him the most job opportunies. My advice would be to select at least a couple of tech sectors to refine the search and then re-generate the stats. It might be that there are lots of very similar opportunities for VB programmers which The Viking would find to be boring as shit. Better to find a language with the maximal spread across different job types :)