They seem to occupy a bizarre state between "independent" analysts and "for-hire" research consultants that provide, surprisingly enough, the conclusions that the organisation commissioning the study expected in the first place.
Just a way to justify one's interests to management, it seems..
That's why telcos should administer their networks properly - they have complete control over the services are provided to end-users, and can QoS the devices if they really are causing that degree of problem.
Or, believe it or not, invest in their infrastructure (like most other places have..)
There's no good reason to disable tethering on foreign networks, apart from Apple being greedy cunts.
I'm quite glad I have a non-Apple UMTS device, but I do feel sorry for all the poor bastards that bought into the hype. And the limitations imposed after-the-fact.
Go with it. The GPL is about freedom of the end-user to adapt the software, not the freedom to be a cheapskate.
As long as you're releasing source, it's in the spirit (and practice) of the license. If you're adding something to it, which you have by porting it, it's ethically defensible.
ECU nowadays is a fairly generic term in automotive electronics - any module, be it a body electronics module, engine management system, immobiliser or such can be called an ECU.
GSM does include a country in the network identifiers.
For example, 505-01 is Telstra (Australia), and 505-02 is Optus (Australia). The 505 indicates Australia, and the latter two digits identify the network.
In my line of work (embedded system testing), we do a fair bit of product testing with Python. We have a SWIG wrapper around the National Instruments DAQmx API, which works pretty damn well (about as well as the C API), especially when doing buffered reads/writes.
You do tend to get about a 4ms RTT for any of the USB-based NI DAQ boxes, which means that it's best to combine the commands into a single write, if possible.
We also use Vector CANcases for network testing; again, a simple SWIG wrapper works wonders.
Unfortunately, I can't release any of our libraries as open source, but it's pretty damn easy to get going - about as easy, if not easier, than in C.
Outside of the US, very few telcos (historically speaking) offered unlimited local calls.
Even still, we've moved forward since then - sure, you may have been able to make an unlimited number of connections, but you were still only tying up 2 copper pairs in the ground - you, and the call recipient.
Contrast that to DSL, Cable etc., where you've got a much wider pipe. There's no way ISPs can offer a wide-enough pipe at a low price to everybody and not have some sort of contention ratio.
The difference is.. the telcos bill you for each call.
Do you want the ISPs to start billing per-megabyte? It's like any business - you advertise a maximum usage that is financially tenable for the business at a given price, with various usage assumptions factored in (time of day, contention ratio etc.), and offer that to the consumer.
Anyone going substantially above the expectations of what you get for your money would be subject to excess charges - someone has to pay for the above-average usage.
Granted, it's a stupid thing that American ISPs have advertised "unlimited" in the past, but there's no good reason to bitch now that they've come clean about exactly what they can handle, and what the expectations are.
They expect $XX per month, you expect YY gigabytes per month. What's wrong with putting that down on paper rather than "uh, yeah, use as much as we consider viable.. we'll tell you when you hit it"?
We could have unlimited internet plans.. but would everyone be willing to pay extra to expand the infrastructure?
The MISRA software development guidelines for C can make a lot of sense in embedded, real-time or safety-critical systems, and can also be applicable outside of that application domain.
On the whole though.. one thing that tends to be lacking in coding standards is an underlying reason behind many rules - it's hard for developers to judge the applicability of an exception if they don't know why the standard was introduced - common error? Past internal experience?
Slashdot Mirror
RIM seems to be particularly odd in chosing an architecture that gives a single point of failure.
Then again, given most crackberry users.. nothing of value was lost.
They seem to occupy a bizarre state between "independent" analysts and "for-hire" research consultants that provide, surprisingly enough, the conclusions that the organisation commissioning the study expected in the first place.
Just a way to justify one's interests to management, it seems..
Remind me again.. why do people listen to Gartner any more?
I can't think of a meaningful thing they've put out in the last 5 years.
I wish I had mod points. Straight to the (disappointing) core of it..
Works perfectly in Australia. I can pull, consistently, 2.5-3mbit at my desk, and about 2mbit on a train (travelling 60-80km/h).
That's why telcos should administer their networks properly - they have complete control over the services are provided to end-users, and can QoS the devices if they really are causing that degree of problem.
Or, believe it or not, invest in their infrastructure (like most other places have..)
Exactly - they've locked people out of using their phone for data.
Given that there's only one network kicking and screaming about tethering (AT&T) - why give everyone else hell for it?
Looking at my housemate's iPhone (newly 3.1'ed), that's precisely what they've done.
Carrier that doesn't give a shit either way about tethering, and the feature has been disabled.
Fuck AT&T and Apple with a rusty razorblade.
There's no good reason to disable tethering on foreign networks, apart from Apple being greedy cunts.
I'm quite glad I have a non-Apple UMTS device, but I do feel sorry for all the poor bastards that bought into the hype. And the limitations imposed after-the-fact.
Ever notice the 3G networks around the other parts of the world haven't needed to bitch and moan about data usage of smartphones?
About time they were prompted into investing some of the profits into the network, not into shareholders' collective pockets.
Employers administer drug tests now?
Go with it. The GPL is about freedom of the end-user to adapt the software, not the freedom to be a cheapskate.
As long as you're releasing source, it's in the spirit (and practice) of the license. If you're adding something to it, which you have by porting it, it's ethically defensible.
How is this a problem?
If companies want to take advantage of globalisation, what's wrong with consumers doing the same thing?
Just a bit of minor nitpicking..
ECU nowadays is a fairly generic term in automotive electronics - any module, be it a body electronics module, engine management system, immobiliser or such can be called an ECU.
And to save everyone googling..
KDE 4 or Windows 7 - ZDnet in Sydney
GSM does include a country in the network identifiers.
For example, 505-01 is Telstra (Australia), and 505-02 is Optus (Australia). The 505 indicates Australia, and the latter two digits identify the network.
In my line of work (embedded system testing), we do a fair bit of product testing with Python. We have a SWIG wrapper around the National Instruments DAQmx API, which works pretty damn well (about as well as the C API), especially when doing buffered reads/writes.
You do tend to get about a 4ms RTT for any of the USB-based NI DAQ boxes, which means that it's best to combine the commands into a single write, if possible.
We also use Vector CANcases for network testing; again, a simple SWIG wrapper works wonders.
Unfortunately, I can't release any of our libraries as open source, but it's pretty damn easy to get going - about as easy, if not easier, than in C.
SWIG makes it pretty bloody easy to wrap any C/C++ library for Python, or even Ruby, C#, Tcl, Perl, PHP et al.
http://www.swig.org/
Australia's had a constitution since federation, back in 1901.
The real issue there is that receiving a message, with no way to block it, costs the recipient money.
In what sort of world does that make sense?
It's not that hard to mirror said content outside the US..
Depends on your telco and location.
Outside of the US, very few telcos (historically speaking) offered unlimited local calls.
Even still, we've moved forward since then - sure, you may have been able to make an unlimited number of connections, but you were still only tying up 2 copper pairs in the ground - you, and the call recipient.
Contrast that to DSL, Cable etc., where you've got a much wider pipe. There's no way ISPs can offer a wide-enough pipe at a low price to everybody and not have some sort of contention ratio.
The difference is.. the telcos bill you for each call.
Do you want the ISPs to start billing per-megabyte? It's like any business - you advertise a maximum usage that is financially tenable for the business at a given price, with various usage assumptions factored in (time of day, contention ratio etc.), and offer that to the consumer.
Anyone going substantially above the expectations of what you get for your money would be subject to excess charges - someone has to pay for the above-average usage.
Granted, it's a stupid thing that American ISPs have advertised "unlimited" in the past, but there's no good reason to bitch now that they've come clean about exactly what they can handle, and what the expectations are.
They expect $XX per month, you expect YY gigabytes per month. What's wrong with putting that down on paper rather than "uh, yeah, use as much as we consider viable.. we'll tell you when you hit it"?
We could have unlimited internet plans.. but would everyone be willing to pay extra to expand the infrastructure?
The MISRA software development guidelines for C can make a lot of sense in embedded, real-time or safety-critical systems, and can also be applicable outside of that application domain.
On the whole though.. one thing that tends to be lacking in coding standards is an underlying reason behind many rules - it's hard for developers to judge the applicability of an exception if they don't know why the standard was introduced - common error? Past internal experience?
Gah.. I blame being kept awake by nightmares caused by SAE and ISO standards.. they're hell, dammit! :)