You can always use a Map and reflection to do a "switch of Strings". Sure it isn't as elegant as it could be, and you have to choose the Map type (Tree vs Hash) but the option is there.
Java could add syntactic sugar to do this for you, like some of the stuff in JDK1.5 I guess...
which AFAIK is hard on linux as there's no non-blocking file IO.
Surely if you have 10 threads of execution, or 10 processes for that matter, all waiting to read and write to the disk it doesn't matter if the IO is non-blocking or not; the kernel or HDD controller should still be able to optimise the order in which IO requests are served to minimise the seeking required.
I'm just suprised that this technology wasn't already in use... I can remember reading about the elevator algorithm as an example of a disk scheduler at university some time ago. Seems obvious, although perhaps difficult to implement well though - good job to the Linux folk!
It's obvious that this guy has some programming ntalent. I wonder if Google will chase him down and we'll see this at labs.google.com soon?
If they did track him down, I'm guessing it would be for his bright ideas as opposed to programming talent - lots of people can program, but fewer can come up with excellent ideas like this.
I often wonder if commercial companies are always this fastidious.
I'd guess not, because depending on the company and their business, they could be losing lots of money for every minute their systems are off-line. That's not to say that Open Source can't make money though.
Writing code to deal directly with a combinatorial explosion of possible situations is never a practical approach.
As I said previously, I would expect meta-data to be added to an intermediate representation of the program such that machine code generation remains distinct from parsing and compiling. Avoiding the combinatorial explosion is just an implementation issue, which I don't see as important.
don't know what the revolution is that you have in mind.
I'm not in the business of designing new programming languages, and rarely think that making new languages is good since it is such a widely researched topic already. I don't think I'd be particularly good at it either! However, some of the syntax you mentioned earlier would be useful for explaining rough probabilities of branches, as would the ability to define pure functions where it is guaranteed that the same output will always be guaranteed from the same input. One thing I would see as useful would be telling the compiler that each time I call something such as strlen(), the result will be the same unless I've written to the input pointer (through an alias or not). I've already seen some compilers that support a __pure keyword for function declarations, and it would have been nice if that were a C99 feature too. Declaring functions with their input ranges would be cool, this is something that would fit nicely into Java (out of range values could throw an exception in a similar way to NullPointerException) and allow the compiler to better judge flow though the function, or replace it with a lookup table (depending on speed/size optimisation setting) if it were a pure function.
It would also be nice if a construct similar to switch statements were to be provided where it was possible to indicate which events are most likely to happen; currently the compilers I've experienced determine if the switch statment is 'dense' or 'sparse' and decide to generate either a lookup table or a number of tests in sequence. Certainly, given the probabilities of various options, a compiler could decide how to order serial test to be most efficient in testing the most frequent match first vs generating the constants to test against eg.
switch(x) {
case 'a':.... break;
case 'b':.... break;
case 'c':.... break;
}
It's easy to compare against 'a', then add 1 to 'a' and make the next test, and so on, but it might be better to compare against 'c', deduct 2, test 'a' and then add 1 to test against 'b' last. Certainly runtime analysis could help determine this, but as mentioned before, JIT isn't always viable for every situation. I'm not even sure that Java or C require serial tests for a switch statement to be in declaration order, if it did then that would be somewhat useful at least. Two types of switch statement might be good, a 'switch' where the compiler is free to determine the test order, and a 'shunt' (don't laugh!) where the test order is meaningful (but could be ignored by the compiler if required or better optimisation is possible for other criteria).
I'm sure that there are other examples of places where interesting hints could be provided in a non-intrusive manner, and you probably have a good idea as to some too.
RE: ZPL - it sounds like an intersting language. I'll look into, along with HP's Dynamo - thanks for the suggestions:)
Having the programmer annotate programs with branch frequency info seems to me like a desperate last resort.
I agree, it's not very elegant at all. This was encountered in a C compiler for a DSP, where the programmer is expected to have a good knowledge of the average inputs to a function (for example, it might be a buffer of IQ samples to be equalised), and so can give the compiler hints that it would never be able to determine through static analysis alone. For embedded work, runtime analysis and JIT is also difficult since RAM is often a restricted (it's expensive) and code maybe in ROM. If it is realtime too, it becomes even harder - which is why this compiler used #pragmas.
Anyway, the point is your original statement regarding the optimizer's ability to deal with low-level languages was simply false. High-level languages have the disadvantage that the optimizer must be familiar with each construct of the language and deal with it differently. If the high-level language gets "lowered" a into uniform constructs (eg. if-then, do-unless, exception throws, and loops all become control-flow graphs with branch frequency annotations) then the optimizer can deal with them all uniformly. Otherwise, it needs to deal with an explosion of different language feature combinations to do a good job
I don't think it was false at all, you answer how it would work in your 'Otherwise,' clause. High level languages, with features as you speculate would need a new compiler to deal with it, and certainly you wouldn't be able to write a new front end for an existing compiler and expect it to just generate optimal code from the intermediate quadruples (although it would still generate executable code); a method for processing meta data containing 'hints' as well as quads would need to be developed. In short, the intermediate language would need to be upgraded, which could be done such that existing compiler backends ignore the meta-data if not present, and front ends are not obliged to generate it. It's just like some instruction sets have bits in branch instructions to indicate whether the branch is likely to be taken or not - that is a form of meta-data.
I'm open to the idea of revolution as opposed to evolution of existing compiler technology, of which most of the break throughs were acomplished many years ago. JIT certainly has a lot to still to offer, but there are still many applications that could benefit greatly from improved static optimistaion, in my opinion.
Optimizers "reverse-engineer" code to figure out what it does, then transform it into better code that does the same thing. Higher-level languages sometimes help (perhaps they provide better branch probabilities, aliasing info, escape info, etc.), but even with low-level code like quadruples, optimizers can still do a hell of a lot more than loop unrolling and peepholing.
Granted. The problem will be that the optimiser is always going to be imperfect at figuring out what code is trying to do from low level representations, such as quadruples, where some optimisations may or maynot already have been applied, especially given that different compilers will optimise differently. For the same reasons, byte code decompilers are never going to be perfect in returning original source code from byte code.
I think we both agree that compilers should, at least in theory, be better at optimising code given more hints, and this is something a good high level language should be implicitly supplying as a part of the constructs and features of language (some C compilers currently use #pragmas for compiler hints such as avg loop counts and branch probablilities).
I suppose that the C99 'restrict' keyword will allow the compiler to assume that each compiler is pointing at a different address, and force the programmer to write code without aliased pointers, undoing my example. But the rest of C99 is about syntactic sugar and back filling deficiencies in C (e.g. long long as a defacto 64-bit type, and finally a bool type!), right?
There does not exist any high-level language that results in code that is faster than C
This is irrelevant; this doesn't say anything about it holding forever. Remember that it used to be common place to program in assembly language to get performance, but that is quite rare for all but DSP or embedded apps these days, and some of those DSP compilers are really good too. Also don't forget the higher level languages are easier to program, which is a benefit of sorts.
Maybe you should look at HP's Dynamo sometime.
Thankyou. I've looked at it a bit, and as far as I can tell it is hardware/software assist for converting code between instruction formats. I don't really see this as wholy relevant, but I guess this is all about where and when you do the compiling; interpreted programs never get compiled,.NET is compile at install on a system, Java is famously just-in-time, C and C++ are compiled once well before load/installing, and assembly code is compiled in the programmers head!
Generating low level code at different times certainly effects portability, but I don't think it really has to be coupled with performance. Hence I would love compile at install for Java, and I really like GCJ and hope it does really well too!
In terms of compiler optimisation, the higher the language the better. Strict typing and a language that allows the compiler to infer more about the call tree should enable better global optimisation. Lower level languages suffer from the problem that the programmer is explictly describing how to do something, and not what it is trying to do; thus the compiler can just unroll loops and perform peephole optimisations.
If a language was sufficently high enough that you could describe to the compiler that you were implementing a recursive function (e.g. shell sort), the compiler should then be able to perform fold-unfold optimisation and convert the code into a more efficient tail iterative function. Fans of Haskell and similar languages might recognise this. Some C compilers will convert recursion to iteration where possible, but this is only in simple cases.
The fact is that today, even as C has reached maturity and as high level as it is, there are still some optimisations that are impossible because of subtleties of the language. For example, multiple pointers may point to the same memory, but depending on how the pointers are assigned, the compiler has no idea that this is the case, and has to follow the code in a literal fashion.
My personal view is that languages like Java still have a lot to offer. I would like to see a lot more investment in the compiler to perform better optimisations, and would also like to see a compile on install system for Java like C#; if I run an applcation it would atleast be nice if the compiled parts were cached somewhere. This I believe could make good performance gains, and it's interesting that Sun's Server Hotspot VM actually performs more optimisation when compiling a class than the Client VM, however, because of the increase in time taken to load and compile a class, the Client VM omits some optimisation techniques to favour speedier loading. I guess this descision is to make GUI's more responsive and reduce app load times; compile at install would remove this constraint. We should be going to higher level languages, not lower, and concentrate on getting to compiler correct.
Err... if this is GSM then that's not is entirely accurate in my professional opinion.
If the phone is in idle mode, i.e. not in call, it will monitor the surrounding cells and select (called camping) the cell with the best selection value which is a function of signal strength and some other parameters set by the network. Also, cells will be grouped into location areas, also known as paging areas, and it is only when the mobile moves from one area to another that it transmits to the network to inform that it has moved to a new location area. Therefore, normally it is only possible to track the user to a location area, which may span a number of cells, each of which could be upto ~35km in radius.
There is a extension called EOTD which uses neigbour cell timing and signal strength estimations to calculate positioning information, but this requires extra support in the base stations and mobile, and isn't widely deployed. Also, since the mobile has to make measurements and report them to the network, this is only done if the network requests it; it would drain your battery to constantly report position.
In dedicate mode, when making a call, the mobile does report signal strengths of the top 6 neigbour cells to the network reasonably frequently, and it would be possible to track a user in a call as you describe, but that's pretty obvious IMHO - you want to make a phone call, so something has to know roughly where you are.
I don't dispute that the network knows where you are, but the average case has a lot lower resolution than you imply.
Looking over the site, I found this where I was expecting to download the source:
"We are currently performing a internal round of reviews with a expert group of security researchers and cryptographers. Depending on the results of this review and the time it takes us to implement the relevant recommendations, our current plan is to have the Source available for Download"
So it sounds like they plan to publish the source if no flaws are found, else they will not i.e. security though obscurity:(
Incidentally, I was wondering how this could work, being that the stuff transmitted to/from the network on a digital cell phone is already encoded for speech and can't really carry much data, and can only be encrypted if the network chooses. I'm guessing that the way it works is to setup a GSM (it's european right) circuit switched data call and use that as the transport, effectively giving voice over IP. I would imagine that the call quality will drop in this case, since various things are done differently in the network for data as opposed voice, and I would expect a higher latency and much less guarantee over how the network will handle the data; in short, it's a hack that might not work too well in practice...
Seems unlikely. Given enough packets, you could process them to find entire routes; spoofed packets would probably just yeild unconnected dots or some noise. Even if the spoofed packets were skillfully crafted to lead routes back to others making fake tails, they would have to be crafted such that they correlated with actual routers that could route between suggested IP addresses. Finally, the spoofed routing packets would also cause extra rooting packets to be sent, and so re-enforce the trail leading to the spoofer.
Spoofing these routing packets may add to the noise, but it certainly wouldn't prevent the true source(s) of the DDos being identified; at worse it would yeild some false avenues to explore.
I saw a posting on/. a long time ago on how to solve this. It's not my idea, but it is very simple and very clever.
Essentially what you do is program the routers on the internet such that every 1000,000'th packet they forward, they also send an additional packet onto the destination stating how the router routed the packet - i.e. the link it came in on, and the link it went out on.
Anyone getting a Dos attack of any sort will then get extra traffic that will reveal the route taken by the Dos packets, even if the source IP addresses are spoofed. Sure this adds to the Dos attack, but filtering these packets should be easy, and they atleast help find the source(s).
Doing this should make it very hard to 'hide' on the internet if you transmit any sort of volume of traffic from some location. The only problem is updating all the routers to do this.
I'm using Runtime.exec() as a dirty hack to interface to a file revision system. Using regular expressions to parse output, almost like writing a script.
A C++ API is available, but I don't have time to wrap that up in a native interface yet, but might do one day.
I wrote a Java program that would BSOD XP after about 20 minutes of running. The online crash analysis told me that Microsoft were aware of the problem and looking into it.
I tried the same program on Linux and found that I had a file descriptor leak (through Runtime.exec() calls), it would throw an exception citing "Too many open files" after around 20 minutes. The box stayed up just fine though...
Still seems like there are some bugs in XP that are not driver or HW related...
As for the cellphone towers. Usually those things are placed some distance from the population
Not always though. In the UK there has been a lot of publicity given to the fact that some towers have been placed near schools or in the middle of vilages etc... Also there are smaller cells known as pico cells that maybe located indoors (e.g. in shopping centres) and close to population, although granted they tranmit at much weaker power.
The 13 September 2003 issue of New Scientist has a special report on this topic:
Special Report
No one has yet proved that cellphones are bad for you. Is it time to give up on the hunt for potential dangers? p.12
Unfortunately it isn't online (yet?). The interesting point from the article (I got it in paper form) is that the WHO is going to stop researching into the health effects of mobile phone use in another ~3 years unless a link is discovered; the article says that they have many other things that could do with the research funding, and the lack of credible or reproducable evidence so far is perhaps evidence in itself?
They could use my parents as they have never had a cell phone and I do not think they have even used a cell phone.
Owning a cell phone isn't so much the issue since they don't continously transmit, unlike the cell towers which generate a contant emission for mobility (so handsets can 'see' the network and make measurements). When a phone is idle, it is pretty much just that and even during a call, transmission at the handset will be reduced to just signalling if you don't make any noise (a technique called DTX).
... and researchers are avoiding work with dangerous pathogens, choosing more innocuous micro-organisms.
This shouldn't be a problem providing that the same tests/results can be performed/achieved, in which case, I would wonder why a scientist would prefer to work with the dangerious pathogen in any case.
I don't see why you would want specific hardware for this. Adding another chip to a product will make it larger, use more power and cost more.
The article says that they have "Hardwared IP and Software IP which [is] needed to build a portable music player" but realistically most portable music players will surely contain a general purpose CPU or DSP, meaning that they need only a good reference implementation which can be ported to common platforms (e.g. ARM) with little optimisation.
Slashdot Mirror
You can always use a Map and reflection to do a "switch of Strings". Sure it isn't as elegant as it could be, and you have to choose the Map type (Tree vs Hash) but the option is there.
Java could add syntactic sugar to do this for you, like some of the stuff in JDK1.5 I guess...
which AFAIK is hard on linux as there's no non-blocking file IO.
Surely if you have 10 threads of execution, or 10 processes for that matter, all waiting to read and write to the disk it doesn't matter if the IO is non-blocking or not; the kernel or HDD controller should still be able to optimise the order in which IO requests are served to minimise the seeking required.
I'm just suprised that this technology wasn't already in use... I can remember reading about the elevator algorithm as an example of a disk scheduler at university some time ago. Seems obvious, although perhaps difficult to implement well though - good job to the Linux folk!
It's obvious that this guy has some programming ntalent. I wonder if Google will chase him down and we'll see this at labs.google.com soon?
If they did track him down, I'm guessing it would be for his bright ideas as opposed to programming talent - lots of people can program, but fewer can come up with excellent ideas like this.
I often wonder if commercial companies are always this fastidious.
I'd guess not, because depending on the company and their business, they could be losing lots of money for every minute their systems are off-line. That's not to say that Open Source can't make money though.
Writing code to deal directly with a combinatorial explosion of possible situations is never a practical approach.
As I said previously, I would expect meta-data to be added to an intermediate representation of the program such that machine code generation remains distinct from parsing and compiling. Avoiding the combinatorial explosion is just an implementation issue, which I don't see as important.
don't know what the revolution is that you have in mind.
I'm not in the business of designing new programming languages, and rarely think that making new languages is good since it is such a widely researched topic already. I don't think I'd be particularly good at it either! However, some of the syntax you mentioned earlier would be useful for explaining rough probabilities of branches, as would the ability to define pure functions where it is guaranteed that the same output will always be guaranteed from the same input. One thing I would see as useful would be telling the compiler that each time I call something such as strlen(), the result will be the same unless I've written to the input pointer (through an alias or not). I've already seen some compilers that support a __pure keyword for function declarations, and it would have been nice if that were a C99 feature too. Declaring functions with their input ranges would be cool, this is something that would fit nicely into Java (out of range values could throw an exception in a similar way to NullPointerException) and allow the compiler to better judge flow though the function, or replace it with a lookup table (depending on speed/size optimisation setting) if it were a pure function.
It would also be nice if a construct similar to switch statements were to be provided where it was possible to indicate which events are most likely to happen; currently the compilers I've experienced determine if the switch statment is 'dense' or 'sparse' and decide to generate either a lookup table or a number of tests in sequence. Certainly, given the probabilities of various options, a compiler could decide how to order serial test to be most efficient in testing the most frequent match first vs generating the constants to test against eg.
.... break; .... break; .... break;
switch(x) {
case 'a':
case 'b':
case 'c':
}
It's easy to compare against 'a', then add 1 to 'a' and make the next test, and so on, but it might be better to compare against 'c', deduct 2, test 'a' and then add 1 to test against 'b' last. Certainly runtime analysis could help determine this, but as mentioned before, JIT isn't always viable for every situation. I'm not even sure that Java or C require serial tests for a switch statement to be in declaration order, if it did then that would be somewhat useful at least. Two types of switch statement might be good, a 'switch' where the compiler is free to determine the test order, and a 'shunt' (don't laugh!) where the test order is meaningful (but could be ignored by the compiler if required or better optimisation is possible for other criteria).
I'm sure that there are other examples of places where interesting hints could be provided in a non-intrusive manner, and you probably have a good idea as to some too.
RE: ZPL - it sounds like an intersting language. I'll look into, along with HP's Dynamo - thanks for the suggestions :)
Ok, I'll agree with that.
Thanks, Patrick.
Having the programmer annotate programs with branch frequency info seems to me like a desperate last resort.
I agree, it's not very elegant at all. This was encountered in a C compiler for a DSP, where the programmer is expected to have a good knowledge of the average inputs to a function (for example, it might be a buffer of IQ samples to be equalised), and so can give the compiler hints that it would never be able to determine through static analysis alone. For embedded work, runtime analysis and JIT is also difficult since RAM is often a restricted (it's expensive) and code maybe in ROM. If it is realtime too, it becomes even harder - which is why this compiler used #pragmas.
Anyway, the point is your original statement regarding the optimizer's ability to deal with low-level languages was simply false. High-level languages have the disadvantage that the optimizer must be familiar with each construct of the language and deal with it differently. If the high-level language gets "lowered" a into uniform constructs (eg. if-then, do-unless, exception throws, and loops all become control-flow graphs with branch frequency annotations) then the optimizer can deal with them all uniformly. Otherwise, it needs to deal with an explosion of different language feature combinations to do a good job
I don't think it was false at all, you answer how it would work in your 'Otherwise,' clause. High level languages, with features as you speculate would need a new compiler to deal with it, and certainly you wouldn't be able to write a new front end for an existing compiler and expect it to just generate optimal code from the intermediate quadruples (although it would still generate executable code); a method for processing meta data containing 'hints' as well as quads would need to be developed. In short, the intermediate language would need to be upgraded, which could be done such that existing compiler backends ignore the meta-data if not present, and front ends are not obliged to generate it. It's just like some instruction sets have bits in branch instructions to indicate whether the branch is likely to be taken or not - that is a form of meta-data.
I'm open to the idea of revolution as opposed to evolution of existing compiler technology, of which most of the break throughs were acomplished many years ago. JIT certainly has a lot to still to offer, but there are still many applications that could benefit greatly from improved static optimistaion, in my opinion.
Optimizers "reverse-engineer" code to figure out what it does, then transform it into better code that does the same thing. Higher-level languages sometimes help (perhaps they provide better branch probabilities, aliasing info, escape info, etc.), but even with low-level code like quadruples, optimizers can still do a hell of a lot more than loop unrolling and peepholing.
Granted. The problem will be that the optimiser is always going to be imperfect at figuring out what code is trying to do from low level representations, such as quadruples, where some optimisations may or maynot already have been applied, especially given that different compilers will optimise differently. For the same reasons, byte code decompilers are never going to be perfect in returning original source code from byte code.
I think we both agree that compilers should, at least in theory, be better at optimising code given more hints, and this is something a good high level language should be implicitly supplying as a part of the constructs and features of language (some C compilers currently use #pragmas for compiler hints such as avg loop counts and branch probablilities).
I suppose that the C99 'restrict' keyword will allow the compiler to assume that each compiler is pointing at a different address, and force the programmer to write code without aliased pointers, undoing my example. But the rest of C99 is about syntactic sugar and back filling deficiencies in C (e.g. long long as a defacto 64-bit type, and finally a bool type!), right?
There does not exist any high-level language that results in code that is faster than C
This is irrelevant; this doesn't say anything about it holding forever. Remember that it used to be common place to program in assembly language to get performance, but that is quite rare for all but DSP or embedded apps these days, and some of those DSP compilers are really good too. Also don't forget the higher level languages are easier to program, which is a benefit of sorts.
Maybe you should look at HP's Dynamo sometime.
Thankyou. I've looked at it a bit, and as far as I can tell it is hardware/software assist for converting code between instruction formats. I don't really see this as wholy relevant, but I guess this is all about where and when you do the compiling; interpreted programs never get compiled, .NET is compile at install on a system, Java is famously just-in-time, C and C++ are compiled once well before load/installing, and assembly code is compiled in the programmers head!
Generating low level code at different times certainly effects portability, but I don't think it really has to be coupled with performance. Hence I would love compile at install for Java, and I really like GCJ and hope it does really well too!
In terms of compiler optimisation, the higher the language the better. Strict typing and a language that allows the compiler to infer more about the call tree should enable better global optimisation. Lower level languages suffer from the problem that the programmer is explictly describing how to do something, and not what it is trying to do; thus the compiler can just unroll loops and perform peephole optimisations.
If a language was sufficently high enough that you could describe to the compiler that you were implementing a recursive function (e.g. shell sort), the compiler should then be able to perform fold-unfold optimisation and convert the code into a more efficient tail iterative function. Fans of Haskell and similar languages might recognise this. Some C compilers will convert recursion to iteration where possible, but this is only in simple cases.
The fact is that today, even as C has reached maturity and as high level as it is, there are still some optimisations that are impossible because of subtleties of the language. For example, multiple pointers may point to the same memory, but depending on how the pointers are assigned, the compiler has no idea that this is the case, and has to follow the code in a literal fashion.
My personal view is that languages like Java still have a lot to offer. I would like to see a lot more investment in the compiler to perform better optimisations, and would also like to see a compile on install system for Java like C#; if I run an applcation it would atleast be nice if the compiled parts were cached somewhere. This I believe could make good performance gains, and it's interesting that Sun's Server Hotspot VM actually performs more optimisation when compiling a class than the Client VM, however, because of the increase in time taken to load and compile a class, the Client VM omits some optimisation techniques to favour speedier loading. I guess this descision is to make GUI's more responsive and reduce app load times; compile at install would remove this constraint. We should be going to higher level languages, not lower, and concentrate on getting to compiler correct.
Err... if this is GSM then that's not is entirely accurate in my professional opinion.
If the phone is in idle mode, i.e. not in call, it will monitor the surrounding cells and select (called camping) the cell with the best selection value which is a function of signal strength and some other parameters set by the network. Also, cells will be grouped into location areas, also known as paging areas, and it is only when the mobile moves from one area to another that it transmits to the network to inform that it has moved to a new location area. Therefore, normally it is only possible to track the user to a location area, which may span a number of cells, each of which could be upto ~35km in radius.
There is a extension called EOTD which uses neigbour cell timing and signal strength estimations to calculate positioning information, but this requires extra support in the base stations and mobile, and isn't widely deployed. Also, since the mobile has to make measurements and report them to the network, this is only done if the network requests it; it would drain your battery to constantly report position.
In dedicate mode, when making a call, the mobile does report signal strengths of the top 6 neigbour cells to the network reasonably frequently, and it would be possible to track a user in a call as you describe, but that's pretty obvious IMHO - you want to make a phone call, so something has to know roughly where you are.
I don't dispute that the network knows where you are, but the average case has a lot lower resolution than you imply.
C will still be the staple of low end embedded systems for a long time I should think..
Looking over the site, I found this where I was expecting to download the source:
:(
"We are currently performing a internal round of reviews with a expert group of security researchers and cryptographers. Depending on the results of this review and the time it takes us to implement the relevant recommendations, our current plan is to have the Source available for Download"
So it sounds like they plan to publish the source if no flaws are found, else they will not i.e. security though obscurity
Incidentally, I was wondering how this could work, being that the stuff transmitted to/from the network on a digital cell phone is already encoded for speech and can't really carry much data, and can only be encrypted if the network chooses. I'm guessing that the way it works is to setup a GSM (it's european right) circuit switched data call and use that as the transport, effectively giving voice over IP. I would imagine that the call quality will drop in this case, since various things are done differently in the network for data as opposed voice, and I would expect a higher latency and much less guarantee over how the network will handle the data; in short, it's a hack that might not work too well in practice...
Seems unlikely. Given enough packets, you could process them to find entire routes; spoofed packets would probably just yeild unconnected dots or some noise. Even if the spoofed packets were skillfully crafted to lead routes back to others making fake tails, they would have to be crafted such that they correlated with actual routers that could route between suggested IP addresses. Finally, the spoofed routing packets would also cause extra rooting packets to be sent, and so re-enforce the trail leading to the spoofer.
Spoofing these routing packets may add to the noise, but it certainly wouldn't prevent the true source(s) of the DDos being identified; at worse it would yeild some false avenues to explore.
I saw a posting on /. a long time ago on how to solve this. It's not my idea, but it is very simple and very clever.
Essentially what you do is program the routers on the internet such that every 1000,000'th packet they forward, they also send an additional packet onto the destination stating how the router routed the packet - i.e. the link it came in on, and the link it went out on.
Anyone getting a Dos attack of any sort will then get extra traffic that will reveal the route taken by the Dos packets, even if the source IP addresses are spoofed. Sure this adds to the Dos attack, but filtering these packets should be easy, and they atleast help find the source(s).
Doing this should make it very hard to 'hide' on the internet if you transmit any sort of volume of traffic from some location. The only problem is updating all the routers to do this.
Hi,
I agree.
I'm using Runtime.exec() as a dirty hack to interface to a file revision system. Using regular expressions to parse output, almost like writing a script.
A C++ API is available, but I don't have time to wrap that up in a native interface yet, but might do one day.
Hope that help,
Mike
Naaa,
I wrote a Java program that would BSOD XP after about 20 minutes of running. The online crash analysis told me that Microsoft were aware of the problem and looking into it.
I tried the same program on Linux and found that I had a file descriptor leak (through Runtime.exec() calls), it would throw an exception citing "Too many open files" after around 20 minutes. The box stayed up just fine though...
Still seems like there are some bugs in XP that are not driver or HW related...
Thanks
Surely this sort of stuff is more for managing multiple displays in airports and train stations than the business user?
Textpad rocks!
As for the cellphone towers. Usually those things are placed some distance from the population
Not always though. In the UK there has been a lot of publicity given to the fact that some towers have been placed near schools or in the middle of vilages etc... Also there are smaller cells known as pico cells that maybe located indoors (e.g. in shopping centres) and close to population, although granted they tranmit at much weaker power.
The 13 September 2003 issue of New Scientist has a special report on this topic:
Special Report
No one has yet proved that cellphones are bad for you. Is it time to give up on the hunt for potential dangers? p.12
Unfortunately it isn't online (yet?). The interesting point from the article (I got it in paper form) is that the WHO is going to stop researching into the health effects of mobile phone use in another ~3 years unless a link is discovered; the article says that they have many other things that could do with the research funding, and the lack of credible or reproducable evidence so far is perhaps evidence in itself?
They could use my parents as they have never had a cell phone and I do not think they have even used a cell phone.
Owning a cell phone isn't so much the issue since they don't continously transmit, unlike the cell towers which generate a contant emission for mobility (so handsets can 'see' the network and make measurements). When a phone is idle, it is pretty much just that and even during a call, transmission at the handset will be reduced to just signalling if you don't make any noise (a technique called DTX).
This shouldn't be a problem providing that the same tests/results can be performed/achieved, in which case, I would wonder why a scientist would prefer to work with the dangerious pathogen in any case.
I don't see why you would want specific hardware for this. Adding another chip to a product will make it larger, use more power and cost more.
The article says that they have "Hardwared IP and Software IP which [is] needed to build a portable music player" but realistically most portable music players will surely contain a general purpose CPU or DSP, meaning that they need only a good reference implementation which can be ported to common platforms (e.g. ARM) with little optimisation.
These guys make a GSM/GPRS base station that is powered over Ethernet.
Cool huh?
Remove the pilot from the plane and let if either fly by itself or be remote control...