What about embedded software? I read the FAQ/introduction and couldn't see anything about embedded software. In fact, I can't see how this language would cope with embedded things, where type castings and volatile addresses are *needed*.
Strikes me that a lot of code out there has to be written in low level languages because of the application, and ironically, these applications may just be the ones that need securing the most (think of a cascading failure in a router for example, depending on the data and network, it could be very very bad).
I could be entirely wrong, and embedded OCaml might exist - if not, I'm sure it's been though about - but I just don't see how it can work for embedded code (well, I guess you can abstract the device interaction from a core written in OCaml, but that still leaves the IO risky - that's probably where you want secure code right?).
I thought that the exponential behaviour of worms was deliberate to use all bandwidth and cause disruptions. I guess the slower worm being proposed would carry some other payload and probably be more damaging to individual machines instead...
Assuming that you can shield the airframe and electronics from GSM/DCS/PCS RF to make it all safe, the technology of putting a 'mini-network' onto the plane is simple - take a look at these guys that make nanoBTS and nanoBSC's - two of the components you need to make a mobile network (okay, you'll need a MSC and some databases, but they are just software on a PC).
In summary, you are saying that you made a quick (but not entirely dirty) solution in Perl to gain market postion, but it won't scale. To make it scale you need a more considered solution written in C (or any other lower level language), which you intend to implement in pieces - starting at the bottle necks.
So actually, you probably don't want to mix C and Perl at all (you even say that you hate Perl), but were forced to by market pressure and probably a lack of capital (and skill from the sound of it) to make the whole system in C in the first place. I think you are agreeing with me here afterall - thanks.
Oh, and I'm not a college student, or dumb; what is dumb is your attitude.
I can't think of any real reason to actually do so
I agree. Scripting seems best for a quick and dirty approach, while actually writing some C or C++ takes more time and consideration. I can't see why you want to mix the two, unless of course you need some low level access to hardware that Perl doesn't offer directly...
Seems like a simple similarity index for emails would do this. Something like the % of words or n-grams that are common between emails would work - anything higher than 95% is probably a spam dupe.
Ignoring the from address would also be a good start.
I remember somewhere there was a metric to determine if posts in usenet groups were spam or not. The method was something like this:
1) For each time a duplicate of the suspect message is found within one group, increment the count. 2) For each time a duplicate of the suspect message is found in a different group, square the count.
A certain threshold then isolates the spam.
So, my question is, why can Hotmail not implement a similar system to guess the spam across all the users mailboxes. Seems to me that they have a huge advantage of managing millions of accounts over which they should be able to generate stats to remove spam for all.
Or maybe Hotmail want everyone to get spam so that they are more likely to purchase extra mailbox space...
Not really - your GSM phone has to cope with the effect of travelling toward/away from a base station and will compensate when transmitting for this. It is practical and cheap.
GPS data would also allow for constructing the network based on position as well as direction
But would incur a penalty of needing some central server to process positions and generate routing information - quite impractical if the system is to scale to x million cars.
Re:Nationwide?
on
HighWLAN
·
· Score: 2, Insightful
Actually, you could use frequency measurements (aka dopler) to determine if cars are moving towards or away from each other; GPS isn't needed.
I find this almost impossible to belive; multiple phones with the same IMEI would really f**k the network and the IMEI would hopefully get blacklisted just because of this.
The problem for the network is knowing in which cell a particular phone is. Every now an again, the phone performs a location area update to tell the network. If different phones with the same IMEI do this, the network would get a fair bit confused and would be unable to page the correct users.
Automated merging will never be good enough to fully understand a problem and to correctly merge code - many subtle and hard to find bugs have and can be introduced by an automated merging system that doens't understand the system as a whole.
The major problem with large height is that your cellphone might appear in many cells simultaneously and the networks might become confused.
The network doesn't get confused. All that happens is that the handset makes measurements on all the cells and then selects the best one to camp onto. Once the handset has picked a cell, it will start communicating to that single cell
A bigger problem is that the GSM specification states the maximum timing advance allowable, which directly limits the cell radius to 35km. This means that there would need to be a base station, with power and a connection back to it's network, within 35km of the climber....
Doesn't mkisofs make a file system, i.e. the data on the track, making the ISO format completely the wrong one for describing the data between the tracks?
Or are you considering adding an extra ~25nm to the start radial offset of the recorder and then burn a second track with the image between the first?
Writing a webserver for a pocket calculator maybe, but modern handhelds and mobile devices are so powerful that they are close to early desktops in power and storage.
Seriously, I think much of open source software begins as something that gets built by an individual to make his job easier, that he decides to feed back to the community
This is the reason for the software I have made...
The problem is when the software is no longer useful to you and people keep asking for help and bug fixes - it's hard to leave it
I used to listen to BCC Radio 1 through Winamp, but don't now that I would have to use Real and be subject to it's anoying updates and poor performance.
Slashdot Mirror
What about embedded software? I read the FAQ/introduction and couldn't see anything about embedded software. In fact, I can't see how this language would cope with embedded things, where type castings and volatile addresses are *needed*.
Strikes me that a lot of code out there has to be written in low level languages because of the application, and ironically, these applications may just be the ones that need securing the most (think of a cascading failure in a router for example, depending on the data and network, it could be very very bad).
I could be entirely wrong, and embedded OCaml might exist - if not, I'm sure it's been though about - but I just don't see how it can work for embedded code (well, I guess you can abstract the device interaction from a core written in OCaml, but that still leaves the IO risky - that's probably where you want secure code right?).
You can normally tell these companies at interview...
If you use some memory, use it again right away
That type of memory is called a 'register' in the CPU. The compiler will perform the optimisation you describe using these 'registers' for you.
I thought that the exponential behaviour of worms was deliberate to use all bandwidth and cause disruptions. I guess the slower worm being proposed would carry some other payload and probably be more damaging to individual machines instead...
Mike
Assuming that you can shield the airframe and electronics from GSM/DCS/PCS RF to make it all safe, the technology of putting a 'mini-network' onto the plane is simple - take a look at these guys that make nanoBTS and nanoBSC's - two of the components you need to make a mobile network (okay, you'll need a MSC and some databases, but they are just software on a PC).
In summary, you are saying that you made a quick (but not entirely dirty) solution in Perl to gain market postion, but it won't scale. To make it scale you need a more considered solution written in C (or any other lower level language), which you intend to implement in pieces - starting at the bottle necks.
So actually, you probably don't want to mix C and Perl at all (you even say that you hate Perl), but were forced to by market pressure and probably a lack of capital (and skill from the sound of it) to make the whole system in C in the first place. I think you are agreeing with me here afterall - thanks.
Oh, and I'm not a college student, or dumb; what is dumb is your attitude.
I can't think of any real reason to actually do so
I agree. Scripting seems best for a quick and dirty approach, while actually writing some C or C++ takes more time and consideration. I can't see why you want to mix the two, unless of course you need some low level access to hardware that Perl doesn't offer directly...
NIC's MAC address to identify your computer
Shouldn't that read "NIC's MAC address to identify your NIC"? And even then, it isn't fool proof as the MAC address can be changed...
Yup - aimbot users ruin UT Tournament for me :(
... if I could use it to prevent spy/slimeware installing itself on my computer.
Sadly I don't think it will extend to this.
Seems like a simple similarity index for emails would do this. Something like the % of words or n-grams that are common between emails would work - anything higher than 95% is probably a spam dupe.
Ignoring the from address would also be a good start.
I remember somewhere there was a metric to determine if posts in usenet groups were spam or not. The method was something like this:
1) For each time a duplicate of the suspect message is found within one group, increment the count.
2) For each time a duplicate of the suspect message is found in a different group, square the count.
A certain threshold then isolates the spam.
So, my question is, why can Hotmail not implement a similar system to guess the spam across all the users mailboxes. Seems to me that they have a huge advantage of managing millions of accounts over which they should be able to generate stats to remove spam for all.
Or maybe Hotmail want everyone to get spam so that they are more likely to purchase extra mailbox space...
Nope - you recieve the bursts for the 802.11 data and measure the difference between the expected and actual frequency recieved.
Silly!
substantially more expensive than a GPS
Not really - your GSM phone has to cope with the effect of travelling toward/away from a base station and will compensate when transmitting for this. It is practical and cheap.
GPS data would also allow for constructing the network based on position as well as direction
But would incur a penalty of needing some central server to process positions and generate routing information - quite impractical if the system is to scale to x million cars.
Actually, you could use frequency measurements (aka dopler) to determine if cars are moving towards or away from each other; GPS isn't needed.
I find this almost impossible to belive; multiple phones with the same IMEI would really f**k the network and the IMEI would hopefully get blacklisted just because of this.
The problem for the network is knowing in which cell a particular phone is. Every now an again, the phone performs a location area update to tell the network. If different phones with the same IMEI do this, the network would get a fair bit confused and would be unable to page the correct users.
Have a look at this picture taken on 20th of August 1991 in Spain. Seems that the company has never heard of the trademark on UNIX either...
They've made a virtual machine that copies x86 architecture - all the benefits of Java debugging bought to C/C++. Nice.
Automated merging will never be good enough to fully understand a problem and to correctly merge code - many subtle and hard to find bugs have and can be introduced by an automated merging system that doens't understand the system as a whole.
Try qgallery instead.
The major problem with large height is that your cellphone might appear in many cells simultaneously and the networks might become confused.
The network doesn't get confused. All that happens is that the handset makes measurements on all the cells and then selects the best one to camp onto. Once the handset has picked a cell, it will start communicating to that single cell
A bigger problem is that the GSM specification states the maximum timing advance allowable, which directly limits the cell radius to 35km. This means that there would need to be a base station, with power and a connection back to it's network, within 35km of the climber....
Doesn't mkisofs make a file system, i.e. the data on the track, making the ISO format completely the wrong one for describing the data between the tracks?
Or are you considering adding an extra ~25nm to the start radial offset of the recorder and then burn a second track with the image between the first?
Damit I don't know!
Mike
What is so impressive about this?
Writing a webserver for a pocket calculator maybe, but modern handhelds and mobile devices are so powerful that they are close to early desktops in power and storage.
Mike
Seriously, I think much of open source software begins as something that gets built by an individual to make his job easier, that he decides to feed back to the community
This is the reason for the software I have made... The problem is when the software is no longer useful to you and people keep asking for help and bug fixes - it's hard to leave it
Yup - and it is absolutely cracking.
I used to listen to BCC Radio 1 through Winamp, but don't now that I would have to use Real and be subject to it's anoying updates and poor performance.