Symbian does provide a standard C library that you can use when porting applications.
Symbian does support global variables. The limitation is that you can't have a global variable in a library. Although this can be a problem when porting code, there are usually a number of workarounds (such as wrapping the code in a class, where the globals become member variables) that work well with a small amount of effort.
The only valid point that you make is that Symbian's cleanup method is a bit clumsy and certainly inferior to exceptions/destructors (I believe this is due to the limitations of GCC at the time the cleanup mechanism was designed) which could certainly do with improvement.
Newsflash: removing the code after the fact doesn't make them any less guilty.
Maybe not, but remember SCO are claiming that end-users owe them money for running Linux. If all code that could even conceivably have been "stolen" from SCO is removed, then even if SCO's claims turned out to be true, people can continue to run Linux without paying them a penny...
Thanks for the link, that's made my day;) Now I don't have to restrict myself to using the (restricted) free trial versions (the commercial versions were way overpriced!). I'd always intended to port OpenSSH "when I get round to it", now it looks like I won't have to:)
... on the Nokia 9210 (or 9290 for those in the US) for some time... both VNC and SSH ports have been available for (as far as I remember) over a year... ssh.com used to do a client too, but I can't see it on their site any more... I've found the ssh client very useful, e.g. it means I can set a task (e.g. a long compile) going, leave, then check up on it later from wherever I happen to be...
I would have ignored this as a troll, but it's been modded "+4 Interesting" so it's probably worth providing some perspective to the points raised..
1. Cisco routers suck at IPv6
Even if true, this can hardly be described as a shortcoming with the protocol (though I agree it might be a problem in its deployment).
2. There are too many addresses
In what way is it a problem to have too many addresses available? It's not compulsory to use them all;-). Indeed it's necessary to have them, since it's not possible to allocate the addresses in a way that doesn't waste addresses, and that's also scaleable, since it must be possible to perform aggregation in a way that reduces the size of the routing tables...
NAT is not a solution to everything. In particular it prevents a lot of peer-to-peer type applications (and I don't just mean downloading MP3s - IP telephony is a good example!)
3. IPv6 addresses are too large.
Erm... 128 bits is four times the size of IPv4's 32 bits. That means that the routing tables will take up at most four times what they do at the moment. Even assuming 200,000 prefixes (an overestimate according to this, the full FIB can be stored in under 10Mb. The full BGP table (including attributes) would obviously be larger - but we're hardly talking "extreme amounts of memory"!
4. The IPv6 header is too large
This is plain misleading. For most links the MTU is 1500 bytes or larger, so the difference is closer to 1%. For links where the overhead is significant (e.g. dial-up links) it's normal to use PPP header compression, which all but eliminates the extra overhead.
Rice's theorem, roughly speaking, shows that you can't write a compiler that gives a compile error if your program computes square roots, but works fine for all other programs - here the criterion for "correctness" is "doesn't compute the square root of the input data".
However, this doesn't rule out the correctness criterion "contains in its source a predicate calculus proof that it satisfies a property also specified in the source code".
Why not? From a technical point of view, the reason Rice's theorem does not apply here is that our compiler returns different values for programs that have exactly the same behavior (it will allow a square root program that proves it calculates a square root, but not one without such a proof, even though both compile to the same object code) - and therefore the set that it accepts is not the index set of a class of r.e. sets.
More informally, you can argue that this definition of "correctness" is "trivial", in that it can apply to a program that has any behavior: if you have a program that you wanted to run through this compiler, you could insert the specification "either terminates or doesn't" at the start, and it would compile - but wouldn't necessarily do what you wanted it to. However, the compiler is still useful, because if you do provide it with a full valid specification of what you want the program to do, and a proof that the program satisifies that spec, the compiler can check that your proof contains no mistakes.
(Of course this may take quite some effort, and it doesn't prove the specification you entered is the same one your customer wants solved, but that doesn't negate the fact that the compiler is possible!)
into a couple hundred of these things strung together in arbitrary combinations, your proof system necessarily breaks down.
No, that's simply false - for every natural way of combining two programs to make a larger program, there's a corresponding way to join the proofs together... the reason it's hard to apply formal methods to large systems is not that the proof systems break down, but that the programmer's patience does...
I'd go on, but this is already below the front page fold by five or ten pages, so who'd read it anyway?
In fact to get O(n^2) it doesn't matter which way the data is sorted. The algorithm works by choosing an element as a "pivot", then dividing the remaining data into two sets, the set of data lower than the "pivot", and the set greater than the "pivot" (and then sorting those two sets recursively). The algorithm is efficient when the two sets are of roughly equal size (as will often be the case when the data is random), but O(n^2) when one is significantly larger than the other.
Since most implementations pick the "pivot" as the first item in the list they're sorting, this gives the empty set as one of the sets, and the rest of the data as the other set, which is of course the worst case...
Applying a random permutation to the input data, or choosing the pivot randomly from the set, can help if you know in advance that the data is likely to be biased in such a way that the two sets will often have different sizes.
One of the main reasons for introducing CIDR was to keep down the size of the core routing table. Prior to CIDR, each new network was allocated IP address space that was unrelated to its ISP. This meant that, for your ISP to know how to reach my network, your ISP would have to have an entry in its routing table for my network, and so every ISP had to have an entry in their routing table for every customer of every ISP. Ouch!
With CIDR, my ISP has a chunk of address space (e.g. 192.168.0.0/16, obviously not a real example!), and I get allocated a part of that. Your ISP has a single route in its routing table that tells it how to get to my ISP, and then my ISP handles getting the packets to me. Your ISP doesn't need to care about how many customers my ISP has - a big win!
Introducing IPv6 doesn't affect this (other than making the routing tables much bigger with its longer addresses!) because the same problem will still exist.
Fortunately, it's also true that CIDR doesn't prevent routing around failures - it can restrict it in some circumstances, but it's not nearly as much to blame as the other, more commercial factors discussed in this thread.
(And though IPv6 may have fields in its headers for QoS facilities, the same problems as in IPv4 still have to be solved to get the guaranteed bandwidth, latency etc - upgrading everyone to v6 won't fix that either!)
Slashdot Mirror
- Symbian does provide a standard C library that you can use when porting applications.
- Symbian does support global variables. The limitation is that you can't have a global variable in a library. Although this can be a problem when porting code, there are usually a number of workarounds (such as wrapping the code in a class, where the globals become member variables) that work well with a small amount of effort.
- Symbian does provide on-target debugging
The only valid point that you make is that Symbian's cleanup method is a bit clumsy and certainly inferior to exceptions/destructors (I believe this is due to the limitations of GCC at the time the cleanup mechanism was designed) which could certainly do with improvement.Newsflash: removing the code after the fact doesn't make them any less guilty.
Maybe not, but remember SCO are claiming that end-users owe them money for running Linux. If all code that could even conceivably have been "stolen" from SCO is removed, then even if SCO's claims turned out to be true, people can continue to run Linux without paying them a penny...
Thanks for the link, that's made my day ;) Now I don't have to restrict myself to using the (restricted) free trial versions (the commercial versions were way overpriced!). I'd always intended to port OpenSSH "when I get round to it", now it looks like I won't have to :)
... on the Nokia 9210 (or 9290 for those in the US) for some time... both VNC and SSH ports have been available for (as far as I remember) over a year... ssh.com used to do a client too, but I can't see it on their site any more... I've found the ssh client very useful, e.g. it means I can set a task (e.g. a long compile) going, leave, then check up on it later from wherever I happen to be...
I would have ignored this as a troll, but it's been modded "+4 Interesting" so it's probably worth providing some perspective to the points raised..
1. Cisco routers suck at IPv6
Even if true, this can hardly be described as a shortcoming with the protocol (though I agree it might be a problem in its deployment).
2. There are too many addresses
In what way is it a problem to have too many addresses available? It's not compulsory to use them all ;-). Indeed it's necessary to have them, since it's not possible to allocate the addresses in a way that doesn't waste addresses, and that's also scaleable, since it must be possible to perform aggregation in a way that reduces the size of the routing tables...
NAT is not a solution to everything. In particular it prevents a lot of peer-to-peer type applications (and I don't just mean downloading MP3s - IP telephony is a good example!)
3. IPv6 addresses are too large.
Erm... 128 bits is four times the size of IPv4's 32 bits. That means that the routing tables will take up at most four times what they do at the moment. Even assuming 200,000 prefixes (an overestimate according to this, the full FIB can be stored in under 10Mb. The full BGP table (including attributes) would obviously be larger - but we're hardly talking "extreme amounts of memory"!
4. The IPv6 header is too large
This is plain misleading. For most links the MTU is 1500 bytes or larger, so the difference is closer to 1%. For links where the overhead is significant (e.g. dial-up links) it's normal to use PPP header compression, which all but eliminates the extra overhead.
Picky perhaps, but escape velocities are measured in km/s not km/s^2 (they are just speeds, not accelerations...)
... this page might help to explain...
Rice's theorem, roughly speaking, shows that you can't write a compiler that gives a compile error if your program computes square roots, but works fine for all other programs - here the criterion for "correctness" is "doesn't compute the square root of the input data".
However, this doesn't rule out the correctness criterion "contains in its source a predicate calculus proof that it satisfies a property also specified in the source code".
Why not? From a technical point of view, the reason Rice's theorem does not apply here is that our compiler returns different values for programs that have exactly the same behavior (it will allow a square root program that proves it calculates a square root, but not one without such a proof, even though both compile to the same object code) - and therefore the set that it accepts is not the index set of a class of r.e. sets.
More informally, you can argue that this definition of "correctness" is "trivial", in that it can apply to a program that has any behavior: if you have a program that you wanted to run through this compiler, you could insert the specification "either terminates or doesn't" at the start, and it would compile - but wouldn't necessarily do what you wanted it to. However, the compiler is still useful, because if you do provide it with a full valid specification of what you want the program to do, and a proof that the program satisifies that spec, the compiler can check that your proof contains no mistakes.
(Of course this may take quite some effort, and it doesn't prove the specification you entered is the same one your customer wants solved, but that doesn't negate the fact that the compiler is possible!)
into a couple hundred of these things strung together in arbitrary combinations, your proof system necessarily breaks down.
No, that's simply false - for every natural way of combining two programs to make a larger program, there's a corresponding way to join the proofs together... the reason it's hard to apply formal methods to large systems is not that the proof systems break down, but that the programmer's patience does...
I'd go on, but this is already below the front page fold by five or ten pages, so who'd read it anyway?
I agree with Tom7, I will read it...
In fact to get O(n^2) it doesn't matter which way the data is sorted. The algorithm works by choosing an element as a "pivot", then dividing the remaining data into two sets, the set of data lower than the "pivot", and the set greater than the "pivot" (and then sorting those two sets recursively). The algorithm is efficient when the two sets are of roughly equal size (as will often be the case when the data is random), but O(n^2) when one is significantly larger than the other.
Since most implementations pick the "pivot" as the first item in the list they're sorting, this gives the empty set as one of the sets, and the rest of the data as the other set, which is of course the worst case...
Applying a random permutation to the input data, or choosing the pivot randomly from the set, can help if you know in advance that the data is likely to be biased in such a way that the two sets will often have different sizes.
How do you arrive at those figures? Surely 20Amps * 120V = 2.4kW?
... not with these problems, at least!
One of the main reasons for introducing CIDR was to keep down the size of the core routing table. Prior to CIDR, each new network was allocated IP address space that was unrelated to its ISP. This meant that, for your ISP to know how to reach my network, your ISP would have to have an entry in its routing table for my network, and so every ISP had to have an entry in their routing table for every customer of every ISP. Ouch!
With CIDR, my ISP has a chunk of address space (e.g. 192.168.0.0/16, obviously not a real example!), and I get allocated a part of that. Your ISP has a single route in its routing table that tells it how to get to my ISP, and then my ISP handles getting the packets to me. Your ISP doesn't need to care about how many customers my ISP has - a big win!
Introducing IPv6 doesn't affect this (other than making the routing tables much bigger with its longer addresses!) because the same problem will still exist.
Fortunately, it's also true that CIDR doesn't prevent routing around failures - it can restrict it in some circumstances, but it's not nearly as much to blame as the other, more commercial factors discussed in this thread.
(And though IPv6 may have fields in its headers for QoS facilities, the same problems as in IPv4 still have to be solved to get the guaranteed bandwidth, latency etc - upgrading everyone to v6 won't fix that either!)