Apple tied itself to T-Mobile is that if you want just one provider to deal with, all over Europe, you don't have much in the way of options. Though they didn't go with T-Mobile in the UK.
So all these companies who thought they'd make a bundle on a mobile data offering with no killer application lost out. IMO the real problem was they priced themselves out of the market with tarrifs that made even simple stuff like web browsing and staying connected to IM networks prohibitively expensive.
Finally in the last few years we have started to see mobile data that is actually affordable though often still with extremely high overage rates.
And I doubt that after building the towers, etc. necessary, there will be any significant cost difference when choosing between 2G and 3G. IMO the real question in poorer and/or more rural areas is range. The longer the range you can go with one cell site the less cell sites you need to cover low density areas. A cell site costs quite a bit to setup and maintain (high speed data line, cell equipment, backup power system etc etc).
Does anyone know how the range of UMTS compares to the range of GSM?
now you'd be lucky to ever identify the value of a resister on a circuit board Well I could probablly lift it off the board with a set of heated tweezers, measure it and then solder it back on, annoying but certainly possible (at least down to 0603 package, probablly smaller).
Also while there are 32 bit embedded processors the 8 bit and 16 bit ones are still availible and afaict are still selling well. For many applications a pic in a dil or soic package on a 2 layer board is plenty and for low volume stuff MUCH cheaper than trying to deal with multi layer boards and/or parts small enough that you need professional assembly (yes it is possible to DIY with TQFP packages but it's not something I'd reccomend)
....and what the high street experiances may be different. Afaict the people who buy computers in high street chains are usually those who don't know any better.
It probablly also makes a difference that dell is loading a proper linux distro rather than the crappy vendor specific stuff that some vendors have been loading.
Then again, maybe due to the fact that this has the kernel executing said code, its not a userland issue after all. The real problem (apart from the NULL==0 thing) is that a userland app managed to put code at position 0 of the kernel space in the first place. Some operating systems (linux does and i'm pretty sure windows does too, not sure about others) use a design where the user processes address space remains mapped during calls into the kernel. The kernel address space is then placed at a different location (linux typically uses 0-3G for the userland app and 3G-4G for the kernel) and is always mapped but made inaccessible when in usermode.
This design makes kernel/user modeswitches much simpler and faster and makes it much easier for the kernel to read the parameters it is passed by userland applications. Unfortunately if the devs get things wrong it can open up classes of security holes that would not be possible in a model with completely seperate address spaces.
P.S. there was a patch to linux to make it use completely seperate kernel/user address spaces (the goal being to let user apps use more memory at the cost of performance). I've no idea if it is still curent though.
Try this one: 'No. Because it's a freaking LOCAL EXPLOIT Remember what "LOCAL EXPLOIT" means, it means anyone who can run code on the machine as an ordinary user can exploit it. Not that they need physical access or anything like that
and nearly no-one uses Linux for multi-user systems now that everyone can afford their OWN FREAKING COMPUTER.'
I see a couple of issues with that statement.
1: While computers are cheap enough rackspace with reliable power, and fast reliable internet links isn't, so very often servers are shared. Being able to run cgi scripts or similar is quite sufficiant to exploit an issue like that. 2: The vulnerability can be combined with other vulnerabilities to make something that is far worse than either would be alone. Combine a remote nonprivilaged code execution vulnerability with a local root vulnerability and the combination is effectively a remote root vulnerability.
Linux isn't much better, if I have code running under your user account I can change your menus and your path. Then next time you use su/sudo/the "root terminal" menu entry I get root.
The whole principle of a user having low permissions and then under that low permission environment doing something to gain higher permissions is fundamentally insecure.
but they can overcome loss of a center, tail-mounted engine and all control surfaces by using the engines to keep themselves in the air. IIRC of the times all control services have been lost and the pilots have attempted to fly on engines alone only once have the pilots managed to bring the plane down in a survivable manner.
IIRC nasa did some experiments with computers landing on engines alone and managed to get them doing it so well that they just looked like normal landings.
The basic problem reamins though computers can only deal with situations they have been programed to deal with. Humans at least have some chance of working out new situations on the fly.
There are also things that humans are much better at than computers even when both know in advance that it may be an issue, things like picking the best landing site from a set of bad choices.
But it all comes down to trusting your staff. In the case of outsourcing it also comes down to trusting your outsourcing providers staff. These are people you did not chose and have no particular loyalty to your company. Further you have little knowlage/control over how they are treated. There may also be far more of them than if you had a dedicated IT staff.
The military has a somewhat different attitude to safety than civilian operations. The reason for this is pretty obvious, when one of the major risks is being killed by an enemy stuff that reduces that risk is worthwhile even if it increases other risks.
The civilian authorities in (reasonablly) peaceful countries OTOH are working from a different standpoint. UAVs are simply an extra risk to them which does not reduce any other risk. That means LOTs of beuracracy and risk assesment before they are approved.
Plus it won't be just one UAV, they need to make regulations that will accomodate a general increase in UAV use.
My guess is that because they don't have to worry about the safety of the occupants and they know the exact weight they would cut the margins finer on the power.
I'm sure you could build a uav with manouverability better than a fighter jet but for the majority of work UAVs do you want a plane that is optimised for other things (low speed flying, range, time in the air etc).
IIRC airliners are designed to have enough power that they can limp home with a whole engine down (though thier range is considerably reduced).
Nine Inch Nails did this with Ghosts. There were, IIRC, about 6 different options to acquire the album that ranged from free, to $300. AND IT SOLD WELL!!!! (looking at this RIAA???) Though while they released the album under CC-BY-NC they didn't tell you that it meant you could legally torrent the entire thing.
But while it did sell well does anyone know hot it's sales compared to other albums from NIN? Were the sales just the result of NIN's huge fanbase and nothing to do with the unusual release format?
How much of your 99 cent purchase at the itunes store goes to the artist, when the music is being licensed to the itunes store through traditional record companies? Very little, from what I have read. pennies on the buck. That is down to the contracts between the artists and the record companies.
Itunes is part of the problem. Itunes doesn't really have any control over how the artist and the major label decide to split the money apple pays them.
It is a bit crappy though that apple won't deal direct with independent artists so they have to use another middleman who will take a cut (though nowhere near as big a cut as the record companies would).
the one thing that can prove me wrong is if someone can show me that selling your music the traditional way is still more profitable than going it on your own, due to the sheer quantity of sales. IMO it all depends on what connections you already have. There are loads of bands who would love to make music full time but simply don't have the connections to sell sufficiant copies or run big enough concerts to make real money. So they spend most of thier time working a dayjob and play pubs on the weekend.
Then someone offers them a record deal, even if they make hardly any money off the record deal itself it brings them sufficiant fame to run big concerts that bring in money.
The way to make the real big bucks is to get a major label deal, come out the other side THEN either go it alone or negotiate a much better contract with a major label. The thing is very few bands have the staying power to do that.
The DRM issue is is a serious one It is although at least for the moment it seems to have gone away for music. Apple cornered the music industry into a choice of giving up DRM or letting apple continue to be the only outlet to sell music online to iPod owners.
The 8 bit processors on the other hand tend to be pretty good at the low level stuff, PICs for example can toggle a pin on one clock cycle and read back how the hardware responded to that pin on the next, they are also prety cheap. So in embedded systems you often see a 16 or 32 bit main processor to do the real work and then one or more little 8 bit microcontrollers to do all the fiddly hardware stuff that the main processor doesn't want to be bothered with. This design also may make the software easier as you don't have to learn about the driver development interface for the OS that runs on the big processor.
For $30 you can get a nice embedded processor that supports Ethernet, serial, PCI-E, generic I/O and more without requiring a separate bridge chip. yeah but expect to spend thousands of dollars worth of design time and prototyping costs to develop a board but on it.
For low volume stuff I can certainly see the advantage of using a PC based board as the main processer and then using an 8 bit micro (which can be accomodated on a relatively cheap 2 layer PCB or even stripboard) connected by serial or USB as an IO processor.
The developer doesn't even have to put the code online, they just have to put it in the same CD as the binaries, and they can charge whatever they want. That *might* work for an expensive peice of software that is only sold to a few customers.
It won't work for mass market software, one person will buy a copy and redistribute it (yes this happens anyway but since the software is GPL it's legal). Furthermore they can even rebrand the software so that users associate it more with them than with you.
but under the GPL you are a derivative work if you're using their library That is what the FSF's FAQ says but the license itself (v2 at least) is silent on the matter of what constitutes a derivitive work.
IANAL but I suspect it really depends on how much if anything you use from the project you are linking against (though headers, interface definitions from the library taken at link time or whatever). Until we have some lawsuits setting precedent though we won't know for sure.
Does anyone know good ways to connect the embedded processor to a standard PC motherboard? RS-232 is becoming rare. Ethernet overwhelms the small processors with data. Any good embedded communication solutions for networked motor drive and control applications? USB can be an option provided you aren't too latency sensitive either directly into a microcontroller with USB support (e.g. the pic18f2455/2550/4455/4550 series) or through a USB uart chip.
For lower latency I'd probablly say your best bet is to either search out a motherboard with RS-232 (while most big brand machines don't have it anymore it is still relatively common in the whitebox segment afaict) or use a PCI serial card.
There is also SMBUS though you will likely need to do some soldering to connect to it (you can pick it off from a memory module IIRC, it's only a couple of wires).
As for ethernet TCP is IMO a bit much for 8-bit processors but if you use UDP and keep your protocol simple it should be doable. Especially if you can dedicate a network interface and hence keep the junk down.
Indeed, developing for wintel using somethign like C#, delphi, VB (either classic or.net) or java is going to be a lot easier and more plesent than developing for an embedded platform. Even lintel is likely to be easier to work with than say linux on arm.
Linux on arm is a possibility but the state of floating point (you pretty much have to use a distro specialised to your particular hardware if you want decent floating point performance) and java (yes some arms have built in java support but accessing it is a pain) on arm linux is a mess.
Slashdot Mirror
Apple tied itself to T-Mobile is that if you want just one provider to deal with, all over Europe, you don't have much in the way of options.
Though they didn't go with T-Mobile in the UK.
So all these companies who thought they'd make a bundle on a mobile data offering with no killer application lost out.
IMO the real problem was they priced themselves out of the market with tarrifs that made even simple stuff like web browsing and staying connected to IM networks prohibitively expensive.
Finally in the last few years we have started to see mobile data that is actually affordable though often still with extremely high overage rates.
And I doubt that after building the towers, etc. necessary, there will be any significant cost difference when choosing between 2G and 3G.
IMO the real question in poorer and/or more rural areas is range. The longer the range you can go with one cell site the less cell sites you need to cover low density areas. A cell site costs quite a bit to setup and maintain (high speed data line, cell equipment, backup power system etc etc).
Does anyone know how the range of UMTS compares to the range of GSM?
There are still new phones being sold though that are GSM* only. Hell even the expensive iphone only got 3G in it's second iteration.
And while heavy/rich users may change thier phones every couple of years lighter users often don't.
Given these factors I don't see GSM going away any time soon.
*In GSM I include GSM packet data extentions like GRPS and EDGE.
The article you linked says the A380 is "sold out until 2014", seems like a pretty good position to be in during a recession to me.
now you'd be lucky to ever identify the value of a resister on a circuit board
Well I could probablly lift it off the board with a set of heated tweezers, measure it and then solder it back on, annoying but certainly possible (at least down to 0603 package, probablly smaller).
Also while there are 32 bit embedded processors the 8 bit and 16 bit ones are still availible and afaict are still selling well. For many applications a pic in a dil or soic package on a 2 layer board is plenty and for low volume stuff MUCH cheaper than trying to deal with multi layer boards and/or parts small enough that you need professional assembly (yes it is possible to DIY with TQFP packages but it's not something I'd reccomend)
IIRC the rnli do beach lifegaurd services as well....
....and what the high street experiances may be different. Afaict the people who buy computers in high street chains are usually those who don't know any better.
It probablly also makes a difference that dell is loading a proper linux distro rather than the crappy vendor specific stuff that some vendors have been loading.
Then again, maybe due to the fact that this has the kernel executing said code, its not a userland issue after all. The real problem (apart from the NULL==0 thing) is that a userland app managed to put code at position 0 of the kernel space in the first place.
Some operating systems (linux does and i'm pretty sure windows does too, not sure about others) use a design where the user processes address space remains mapped during calls into the kernel. The kernel address space is then placed at a different location (linux typically uses 0-3G for the userland app and 3G-4G for the kernel) and is always mapped but made inaccessible when in usermode.
This design makes kernel/user modeswitches much simpler and faster and makes it much easier for the kernel to read the parameters it is passed by userland applications. Unfortunately if the devs get things wrong it can open up classes of security holes that would not be possible in a model with completely seperate address spaces.
P.S. there was a patch to linux to make it use completely seperate kernel/user address spaces (the goal being to let user apps use more memory at the cost of performance). I've no idea if it is still curent though.
Try this one: 'No. Because it's a freaking LOCAL EXPLOIT
Remember what "LOCAL EXPLOIT" means, it means anyone who can run code on the machine as an ordinary user can exploit it. Not that they need physical access or anything like that
and nearly no-one uses Linux for multi-user systems now that everyone can afford their OWN FREAKING COMPUTER.'
I see a couple of issues with that statement.
1: While computers are cheap enough rackspace with reliable power, and fast reliable internet links isn't, so very often servers are shared. Being able to run cgi scripts or similar is quite sufficiant to exploit an issue like that.
2: The vulnerability can be combined with other vulnerabilities to make something that is far worse than either would be alone. Combine a remote nonprivilaged code execution vulnerability with a local root vulnerability and the combination is effectively a remote root vulnerability.
Linux isn't much better, if I have code running under your user account I can change your menus and your path. Then next time you use su/sudo/the "root terminal" menu entry I get root.
The whole principle of a user having low permissions and then under that low permission environment doing something to gain higher permissions is fundamentally insecure.
but they can overcome loss of a center, tail-mounted engine and all control surfaces by using the engines to keep themselves in the air.
IIRC of the times all control services have been lost and the pilots have attempted to fly on engines alone only once have the pilots managed to bring the plane down in a survivable manner.
IIRC nasa did some experiments with computers landing on engines alone and managed to get them doing it so well that they just looked like normal landings.
The basic problem reamins though computers can only deal with situations they have been programed to deal with. Humans at least have some chance of working out new situations on the fly.
There are also things that humans are much better at than computers even when both know in advance that it may be an issue, things like picking the best landing site from a set of bad choices.
But it all comes down to trusting your staff.
In the case of outsourcing it also comes down to trusting your outsourcing providers staff. These are people you did not chose and have no particular loyalty to your company. Further you have little knowlage/control over how they are treated. There may also be far more of them than if you had a dedicated IT staff.
Can't the rich just use thier private jet to fly somewhere else and get treated?
Don't they already use autoland systems to land commercial airliners in zero visibility conditions?
The military has a somewhat different attitude to safety than civilian operations. The reason for this is pretty obvious, when one of the major risks is being killed by an enemy stuff that reduces that risk is worthwhile even if it increases other risks.
The civilian authorities in (reasonablly) peaceful countries OTOH are working from a different standpoint. UAVs are simply an extra risk to them which does not reduce any other risk. That means LOTs of beuracracy and risk assesment before they are approved.
Plus it won't be just one UAV, they need to make regulations that will accomodate a general increase in UAV use.
My guess is that because they don't have to worry about the safety of the occupants and they know the exact weight they would cut the margins finer on the power.
I'm sure you could build a uav with manouverability better than a fighter jet but for the majority of work UAVs do you want a plane that is optimised for other things (low speed flying, range, time in the air etc).
IIRC airliners are designed to have enough power that they can limp home with a whole engine down (though thier range is considerably reduced).
Nine Inch Nails did this with Ghosts. There were, IIRC, about 6 different options to acquire the album that ranged from free, to $300. AND IT SOLD WELL!!!! (looking at this RIAA???)
Though while they released the album under CC-BY-NC they didn't tell you that it meant you could legally torrent the entire thing.
But while it did sell well does anyone know hot it's sales compared to other albums from NIN? Were the sales just the result of NIN's huge fanbase and nothing to do with the unusual release format?
How much of your 99 cent purchase at the itunes store goes to the artist, when the music is being licensed to the itunes store through traditional record companies? Very little, from what I have read. pennies on the buck.
That is down to the contracts between the artists and the record companies.
Itunes is part of the problem.
Itunes doesn't really have any control over how the artist and the major label decide to split the money apple pays them.
It is a bit crappy though that apple won't deal direct with independent artists so they have to use another middleman who will take a cut (though nowhere near as big a cut as the record companies would).
the one thing that can prove me wrong is if someone can show me that selling your music the traditional way is still more profitable than going it on your own, due to the sheer quantity of sales.
IMO it all depends on what connections you already have. There are loads of bands who would love to make music full time but simply don't have the connections to sell sufficiant copies or run big enough concerts to make real money. So they spend most of thier time working a dayjob and play pubs on the weekend.
Then someone offers them a record deal, even if they make hardly any money off the record deal itself it brings them sufficiant fame to run big concerts that bring in money.
The way to make the real big bucks is to get a major label deal, come out the other side THEN either go it alone or negotiate a much better contract with a major label. The thing is very few bands have the staying power to do that.
The DRM issue is is a serious one
It is although at least for the moment it seems to have gone away for music. Apple cornered the music industry into a choice of giving up DRM or letting apple continue to be the only outlet to sell music online to iPod owners.
The 8 bit processors on the other hand tend to be pretty good at the low level stuff, PICs for example can toggle a pin on one clock cycle and read back how the hardware responded to that pin on the next, they are also prety cheap. So in embedded systems you often see a 16 or 32 bit main processor to do the real work and then one or more little 8 bit microcontrollers to do all the fiddly hardware stuff that the main processor doesn't want to be bothered with. This design also may make the software easier as you don't have to learn about the driver development interface for the OS that runs on the big processor.
For $30 you can get a nice embedded processor that supports Ethernet, serial, PCI-E, generic I/O and more without requiring a separate bridge chip.
yeah but expect to spend thousands of dollars worth of design time and prototyping costs to develop a board but on it.
For low volume stuff I can certainly see the advantage of using a PC based board as the main processer and then using an 8 bit micro (which can be accomodated on a relatively cheap 2 layer PCB or even stripboard) connected by serial or USB as an IO processor.
The developer doesn't even have to put the code online, they just have to put it in the same CD as the binaries, and they can charge whatever they want.
That *might* work for an expensive peice of software that is only sold to a few customers.
It won't work for mass market software, one person will buy a copy and redistribute it (yes this happens anyway but since the software is GPL it's legal). Furthermore they can even rebrand the software so that users associate it more with them than with you.
but under the GPL you are a derivative work if you're using their library
That is what the FSF's FAQ says but the license itself (v2 at least) is silent on the matter of what constitutes a derivitive work.
IANAL but I suspect it really depends on how much if anything you use from the project you are linking against (though headers, interface definitions from the library taken at link time or whatever). Until we have some lawsuits setting precedent though we won't know for sure.
Does anyone know good ways to connect the embedded processor to a standard PC motherboard? RS-232 is becoming rare. Ethernet overwhelms the small processors with data. Any good embedded communication solutions for networked motor drive and control applications?
USB can be an option provided you aren't too latency sensitive either directly into a microcontroller with USB support (e.g. the pic18f2455/2550/4455/4550 series) or through a USB uart chip.
For lower latency I'd probablly say your best bet is to either search out a motherboard with RS-232 (while most big brand machines don't have it anymore it is still relatively common in the whitebox segment afaict) or use a PCI serial card.
There is also SMBUS though you will likely need to do some soldering to connect to it (you can pick it off from a memory module IIRC, it's only a couple of wires).
As for ethernet TCP is IMO a bit much for 8-bit processors but if you use UDP and keep your protocol simple it should be doable. Especially if you can dedicate a network interface and hence keep the junk down.
Indeed, developing for wintel using somethign like C#, delphi, VB (either classic or .net) or java is going to be a lot easier and more plesent than developing for an embedded platform. Even lintel is likely to be easier to work with than say linux on arm.
Linux on arm is a possibility but the state of floating point (you pretty much have to use a distro specialised to your particular hardware if you want decent floating point performance) and java (yes some arms have built in java support but accessing it is a pain) on arm linux is a mess.