> [switch to linux] It is almost a guarantee that most of the Software Exception requests will not function in this environment and most certainly not the DOS applications.
Actually, DOS applications are more likely to work properly, since dosemu, which provides a virtual machine which can run MS-DOS, freedos, or whatever, is pretty solid. The x86 architecture can virtualize a 16bit environment, which is how dosemu works. x86 can't virtualize an IA32 env, which is why vmware and plex86, etc are tricky.
I've seen plenty of reports of people moving legacy DOS apps to a linux machine with dosemu, usually with success. It's very likely to work if these are 16bit progs, but a lot of 32bit progs are OK too. Heck, Duke Nukem 3D works fine under dosemu; I've done it myself.
If you have in-house apps, you could try them under wine, the windows emulator. If they don't do anything fancy, you shouldn't have a problem. Last time I checked, wine wasn't up to running MS Excel well, but it could sort of show the spreadsheet... MS probably uses secret functionality that wine doesn't know it should provide. I don't know if typical VB programs that throw up a couple dialogs and show the results tend to run well with wine or not.
Anyway, don't write off letting your in-house stuff become "legacy" apps that use dosemu or wine to run. Set up a linux machine and try some of them, since it will be important to know how well it's going to work.
Run distributed.net or something during the winter to keep your bedroom warm:) CPUs dissipate a lot more heat when doing work than otherwise, esp. when the idle loop halts the CPU clock until the next interrupt. (Linux and WinNT do this on x86, and probably on other arches that support it.)
You couldn't really just power stuff from a thermoelectric generator, because the CPU barely runs above ambient temp while idling. (I've taken the heat sink off my k6-2 350MHz, and it barely gets warm to the touch while idling.) You'd have to let the power come from the power supply then.
However you went about it, it would not be a good idea to do this anyway. Thermodynamics dictates that the amount of power you can get is proportional to the temp difference between the heat source and its surroundings. You'd have to have a temperature difference across the generator, plus all the temp diff across the stuff that conducts the heat to the generator, and away from it. (With the small temp diff you'd be able to manage, the efficiency would be very low, so most of the heat would come out the other side anyway, and you'd have to get rid of it in the usual way.) You want to keep your CPU as cool as possible, so it doesn't burn out, so putting an extra thermal barrier in the way is not good.
Basically, you'd gain so little from generating power from waste heat that it would not be worth doing, besides the fact that doing it would have a direct negative effect on the cooling system.
Get your details here. If you haven't read any of Paul DeMone's Silicon Insider columns, but you like computer architecture, you need to check it out. Well written, pretty much unbiased, and usually quite insightful.
How did this get modded as being _that_ informative. Sure it's true (well, I have no reason to doubt it), but it's not really useful. The fact that the case hasn't melted yet has little to do with whether the silicon still works. High heat will let the doping additives in the silicon migrate, which is not good when there are feature with a size of 0.15 microns, or whatever the process size is. In other words, heat up a chip too much, and some of the transistors might stop transisting.
This is why people worry about overclocking, for one thing. They would just try it if the worst that could happen was that the case could melt! Heating up a semiconductor increases its conductivity, and makes it more likely that you will burn something out. (Well, part of the burnout risk from overclocking is from the higher clock speed directly (which produces higher currents), not just the resultant heating.)
aptitude in testing and unstable has come far enough to make a good step forward from dselect. Now that aptitude is good enough, don't bother investing time learning to use dselect. (If you use dselect currently, try aptitude.)
lftp does filename-completion if you hit tab, just like bash. It also supports using a proxy like squid for doing http or ftp access. You can background a transfer, and start other transfers going at the same time. (big deal, just open another xterm... but could be useful). I was going to post more output (from doing cd linux/kernel/v2.4, and cat ChangeLog-2.4.16), but the/. lameness filter kicked in. WTF!)
yeti:~$ cat/usr/share/doc/lftp/copyright
This package was debianized by Christoph Lameter on
Thu, 6 Feb 1997 18:50:09 -0800.
It's currently being maintained by Nicolás Lichtmaier
with sources downloaded from
d.net issues some duplicate work units, I think. This came up on the mailing list once, so you could probably search the archives if you're interested. I can't remember for sure if they actually doing this, or if someone just suggested it. I think the number was something like 15% of work units. Another thing was that if someone submits a suspiciously large number of work units, they might re-issue some of them (so they will be re-done, probably by other people's computers). If the numbers don't check out, they've caught a cheater, and they ban that person. They probably can also retroactively unsubmit all the work they've done, or at least get it re-checked.
device drivers, ip-stack, kernel - all need changing to be tuned to your special hardware and features offered. its not only the hardware that's the value-add, it is the software as well.
Ok, I understand that part of what makes people want to buy your product, and be willing to shell out for the price you ask, is that there is good software for it that makes it do what it's supposed to, and fast. What I don't understand is how releasing the source to that software interferes with adding value. Wouldn't it still add value if people could see the source?
I suppose part of your reluctance to release source would be reluctance to help your competitors. However, if you released your source under the (full, not lesser) GPL, your competitors couldn't use it in their product unless they also released their sources. If that happened, then your industry would be a software sharing utopia...:) OTOH, your competitors could look at the source to see how you do things, and then re-implement the good ideas themselves. There would be nothing illegal about that. The real question here is, how hardware-specific is your value-add? Would you be adding value to your competitors products too, if you released the source? If the answer is yes, then we have an example of the tragedy of the commons, or the so-called prisoner's dilemma. Human nature sucks:(
Of course you couldn't use readline, since they on purpose use the full GPL to stop proprietary people like you from using it. They figure that if you're going to keep your work to yourself, they'll keep their work to themselves when it comes to you.
You say
GPL is a total mess when it comes to a
commercial company that wants to ship a product
without fear of being told it has to release ALL
its code (even its local home-grown code).
You seem to be missing the point about the GPL, since the GPL is all about requiring you to release all the in-house code you develop and link to GPLed code.
You haven't mentioned the lesser GPL at all, for some reason. The LGPL is the one that only requires you to release changes made to code covered by it, and not code it is only linked to. (I suppose it could get messy when you have header files with significant macros, or something like that. I haven't worked on projects like yours, so I haven't had to deal with any of those problems.)
Holy overkill, no need to use TCP or any kind of network socket for local loopback. A simple pipe will do fine. (see pipe(2) and popen(3)) However you do the loopback, you still have the codec in a separate process from the rest of the app, so seeking and stuff like that might be slower. There wouldn't be much of a disadvantage for en/decoding a stream, since even a few memory->memory copies of the data would be small overhead compared to the codec runtime (I don't remember how fast flac is, but I don't think it is a real speed demon).
He's already considering switching from the lesser GPL to BSD-style. If he could do that, he can sell the priviledge of implementing using it in a proprietary system to whoever he wants. (AFAIK, it's likely that doing _either_ of those things will be a challenge, for the reasons you point out.)
The checking doesn't have to be done in-house. Depending on the nature of the problem, you can send out the same work unit to two or more clients, and compare the results. You can do less duplication by just trying to ferret out the cheaters with a few work units that have already been done.
The way this works in distributed.net's OGR (Optimal Golomb Ruler) contest is that the number of stubs examined is part of the returned information. The only way to know how many stubs you had to look at was to do all the work for the whole work unit. You can't find the right number to put any faster than you could look for an optimal golomb ruler, so there's no point just generating the number without doing the work correctly. This method of checking is applicable to any other task where you can generate a number that proves you did the work.
(For the record, I don't like d.net's RC5 contest any more than people who've posted here. It's totally deterministic, and thus a waste of time. AFAIK, the only reason people who know anything do it is for the statistics/ranking web page.)
The orbit it took around the black hole would have to include the starting point, i.e. the earth. (My intuition tells me you can't send something at a gravitational well from far away and have it orbit anywhere near circularly around the well, whether you're talking massless (and thus speed of light) stuff or normal matter.
Thus, when you wanted some data, you would just wait a few decades for it to orbit back to the earth. (Assuming you could find a massive enough body close enough, without any other massive bodies in the way to screw up an orbit.) If you wanted better data integrity, you could grab the data again after only one orbit, and store several days worth on a 2$ holographic cube, or whatever they're using instead of CDRs or hard drives by then:) This is safer than leaving going for multiple orbits.
BondHeadGuy has said that this is not for a surveillance system, etc. OTOH, lets talk about cameras in public places. It's not the face rec itself that bothers me, it's recording all the information generated. I don't like anyone having huge databases of who was where, when, that they can look for patterns in, etc.
Iff I can trust the people running the cams to destroy the video, and not keep any other record of any events the captured (i.e. no DB of names from recognized faces), after a week or so, then the cameras wouldn't really bother me. It's not going to be possible to find someone that everyone can trust to run the cameras, thus there shouldn't be [surveillance] cameras in public places.
(Also, the cameras definitely should not be hidden. If you look around to see if you are alone, you should be able to tell.)
So, the issue isn't expectation of privacy, at least not in a local, instantaneous sense. It's the expectation that nobody is snooping on you and keeping tabs on everything you do - long term privacy, global privacy.
Real time in this case doesn't have anything to do with latency. You're right that not having latency requirements makes it easier, but as you point out, you still have to get it compressed as fast as it is coming out of the cameras, sooner or later. This is what is meant by "real time". (non-realtime is when I rip a CD on my slow computer, and it takes longer than the play time of the CD to get it all compressed, and it doesn't matter because I control when the next CD starts.)
In other contexts, like robot control, where "real time" operating systems are used, timing does matter, as well as overall speed. Vid compression doesn't need any OS support for "real time" stuff, but it is still a realtime task if you can't turn off the camera and wait for the compressor to catch up.
just don't
collapse the wave function, or poof! we will all disappear
Nah, the worst that could happen would that everything would become deterministic and boring... Don't fall asleep during quantum...
OTOH, how would you collapse everything's wave function? Observering everything? Observing by shooting high energy particles... maybe he should be careful about collapsing wave functions...
Try the g2 graphics library. It's pretty simple, and can do win32, X11, PNG, JPEG, or postscript output.
http://g2.sourceforge.net/. I used it to do the graphics for a soap-bubble model program (I was looking at the dynamics of soap froths, etc.) I tweaked the code to use double buffering on the X display, and I've still got the patch to do that if anyone wants it. (I've sent it upstream already, but I don't know if it's incorporated or not.)
Remember, if they can get in
to get your pics (even if they encrypt the data), you can get in too.
Yes, but you may have to break RSA to do it. This isn't like the situation with DVDs and such where you have something that can get at the data, but it will only do it in a certain way. In this case, they don't have to give you anything that will have the decryption key in it. After it JPEG-encodes a picture, it could encrypt it with the company's public (RSA) key, so only the company's private key could decrypt it. You have no way to get at your picture, other than getting the data out before it's encrypted (making the camera a bit inconvenient, or at least bulkier with the stuff you've got hooked up to it.), or breaking RSA.
The only reason they might not do that (other than not thinking of it) is if they wanted the camera to be able to show you previous shots you've taken, etc. In that case, the situation is like DVDs, because the camera has to be able to decrypt the images, so the decryption key is in there somewhere. A way around that is to store thumbnails unencrypted, but leave the camera no way to read the encrypted full-quality images. It could delete one of them if you decided you didn't want it (which makes sense if you could see a thumbnail to know which photo it was).
I think the key is that it only makes sense (to me) to kill oneself in a situation where you would die anyway if you didn't act, or where life would not be worth living if you didn't act. Think of people stranded on a desert island. One might volunteer to let the others eat them, if they think they would all die without resorting to cannibalism, but help will come soon enough to save ones they love. Or, think of a helicopter that can't take off with the load it's carrying, and anyone not on it will be caught by an erupting volcano or something. If your kids are on the chopper, you may choose to stay behind to let them live, because you couldn't bear to let one of them stay behind.
I don't think any of these situations covers kamikaze terrorist attacks (or the originals: the Japanese). This can't happen without religion, I don't think. (The Japs were motivated by gaining honour for their families, and for themselves in the memory of others. I can't really understand it, not being a part of that culture. I regard myself as too important to give up. Not that I wouldn't do something dangerous that might even result in death, but I wouldn't kill myself on purpose, no matter what it accomplished. (except as detailed in my first paragraph: if life wouldn't be worth living...) In the case of terrorists, they are twisted by lack of proper education, and being indoctrinated in schools that interpret Islam in such a way that killing people seems like a good idea. They end up in these schools because they get fed there, and wouldn't eat otherwise, most of the time. (this was very well reported in an article by Ian Goldstein in the globe and mail, IIRC.) Anyway, since I don't think most terrorists would find the world unbearable to live in if they didn't give their lives for their cause, they must be motivated by something else: religion. They are scoring points for the afterlife.
> Are they going to sue him because of the use of illegal encryption technologie?
No, but that extra circumstantial evidence (that the sender had something to hide, thus she used illegal enc. inside the legal enc.) tells the feds that this is definitely someone to keep an eye on. They'll probably send in human spies after that, to see who she meets in coffee shops, etc.
As long as the penalty for using illegal encryption is harsh enough, not enough people will defy the law to achieve privacy, so use of illegal encryption would indicate someone worth spying on further. Needless to say, it would really suck to go to jail for a year for using SSH. (what if I SSH to my terrorist-friend's computer, and use talk(1) to communicate...)
However, I think steganography and/or chaffing are sufficient to make the above a moot point. If terrorists limited themselves to PGP inside weak-gov-cipher, then this would help. They're smarter than that.
Then there would be a message that didn't have the block cipher key public-key encrypted to Uncle Sam's key. Two messages with different recipients is different from one message with two recipients, because of the way PGP works. To add a recipient to a message, you add information to the message so that someone with the private key corresponding to the public key you are encrypting to can recover the block cipher key and read the text of the message.
FYI, RTLinux is a real-time layer that passes hardware interrupts to the rest of Linux. The rest of Linux runs as a task under rtlinux. This isn't the kind of thing you can easily make into a module. To do that, you'd have to make init_module() patch the machine code in other parts of the kernel.
Also FYI, rtlinux is not new. They've been around for a couple years. I guess the FSF just waited to see if anything was going to happen before they got nasty. The source code is available, and there is an "open patent license", similar to the GPL, but with a few restrictions about having to provide contact info to Yodaiken on commercial users of rtlinux, and having to send him diffs for any in-house changes, IIRC.
Yodaiken is _not_ limiting the chances of others, etc.. He is limiting the desire to, because such work would not be as Free as GPLed code.
Know the facts before you get too excited. This is/., remember?
Slashdot Mirror
Use HTML Tidy.
> [switch to linux] It is almost a guarantee that most of the Software Exception requests will not function in this environment and most certainly not the DOS applications.
Actually, DOS applications are more likely to work properly, since dosemu, which provides a virtual machine which can run MS-DOS, freedos, or whatever, is pretty solid. The x86 architecture can virtualize a 16bit environment, which is how dosemu works. x86 can't virtualize an IA32 env, which is why vmware and plex86, etc are tricky.
I've seen plenty of reports of people moving legacy DOS apps to a linux machine with dosemu, usually with success. It's very likely to work if these are 16bit progs, but a lot of 32bit progs are OK too. Heck, Duke Nukem 3D works fine under dosemu; I've done it myself.
If you have in-house apps, you could try them under wine, the windows emulator. If they don't do anything fancy, you shouldn't have a problem. Last time I checked, wine wasn't up to running MS Excel well, but it could sort of show the spreadsheet... MS probably uses secret functionality that wine doesn't know it should provide. I don't know if typical VB programs that throw up a couple dialogs and show the results tend to run well with wine or not.
Anyway, don't write off letting your in-house stuff become "legacy" apps that use dosemu or wine to run. Set up a linux machine and try some of them, since it will be important to know how well it's going to work.
Run distributed.net or something during the winter to keep your bedroom warm :) CPUs dissipate a lot more heat when doing work than otherwise, esp. when the idle loop halts the CPU clock until the next interrupt. (Linux and WinNT do this on x86, and probably on other arches that support it.)
You couldn't really just power stuff from a thermoelectric generator, because the CPU barely runs above ambient temp while idling. (I've taken the heat sink off my k6-2 350MHz, and it barely gets warm to the touch while idling.) You'd have to let the power come from the power supply then.
However you went about it, it would not be a good idea to do this anyway. Thermodynamics dictates that the amount of power you can get is proportional to the temp difference between the heat source and its surroundings. You'd have to have a temperature difference across the generator, plus all the temp diff across the stuff that conducts the heat to the generator, and away from it. (With the small temp diff you'd be able to manage, the efficiency would be very low, so most of the heat would come out the other side anyway, and you'd have to get rid of it in the usual way.) You want to keep your CPU as cool as possible, so it doesn't burn out, so putting an extra thermal barrier in the way is not good.
Basically, you'd gain so little from generating power from waste heat that it would not be worth doing, besides the fact that doing it would have a direct negative effect on the cooling system.
Check this page on the web site.
Get your details here. If you haven't read any of Paul DeMone's Silicon Insider columns, but you like computer architecture, you need to check it out. Well written, pretty much unbiased, and usually quite insightful.
How did this get modded as being _that_ informative. Sure it's true (well, I have no reason to doubt it), but it's not really useful. The fact that the case hasn't melted yet has little to do with whether the silicon still works. High heat will let the doping additives in the silicon migrate, which is not good when there are feature with a size of 0.15 microns, or whatever the process size is. In other words, heat up a chip too much, and some of the transistors might stop transisting.
This is why people worry about overclocking, for one thing. They would just try it if the worst that could happen was that the case could melt! Heating up a semiconductor increases its conductivity, and makes it more likely that you will burn something out. (Well, part of the burnout risk from overclocking is from the higher clock speed directly (which produces higher currents), not just the resultant heating.)
aptitude in testing and unstable has come far enough to make a good step forward from dselect. Now that aptitude is good enough, don't bother investing time learning to use dselect. (If you use dselect currently, try aptitude.)
> Nobody has written a proper interactive HTTP download client that doesn't look and act like a web browser.
:~> open http://www.ca.kernel.org/pub/
//
/. lameness filter kicked in. WTF!)
/usr/share/doc/lftp/copyright
t p/ client
Since you asked, I gave lftp's http support a try
yeti:~$ lftp
lftp
cd ok, cwd=/pub
lftp www.ca.kernel.org:/pub> ls
drwxr-xr-x - 2000-09-18 14:51
drwxr-xr-x - 2001-11-28 15:23 CPAN/
drwxr-xr-x - 2001-11-16 23:51 incoming/
drwxr-xr-x - 2000-10-21 21:40 linux/
drwxr-xr-x - 2001-11-29 08:01 mirrors/
drwxr-xr-x - 2001-11-28 11:53 misc/
drwxr-xr-x - 2000-10-17 18:09 software/
lftp does filename-completion if you hit tab, just like bash. It also supports using a proxy like squid for doing http or ftp access. You can background a transfer, and start other transfers going at the same time. (big deal, just open another xterm... but could be useful). I was going to post more output (from doing cd linux/kernel/v2.4, and cat ChangeLog-2.4.16), but the
yeti:~$ cat
This package was debianized by Christoph Lameter on
Thu, 6 Feb 1997 18:50:09 -0800.
It's currently being maintained by Nicolás Lichtmaier
with sources downloaded from
ftp://ftp.yars.free.net/pub/software/unix/net/f
d.net issues some duplicate work units, I think. This came up on the mailing list once, so you could probably search the archives if you're interested. I can't remember for sure if they actually doing this, or if someone just suggested it. I think the number was something like 15% of work units. Another thing was that if someone submits a suspiciously large number of work units, they might re-issue some of them (so they will be re-done, probably by other people's computers). If the numbers don't check out, they've caught a cheater, and they ban that person. They probably can also retroactively unsubmit all the work they've done, or at least get it re-checked.
Ok, I understand that part of what makes people want to buy your product, and be willing to shell out for the price you ask, is that there is good software for it that makes it do what it's supposed to, and fast. What I don't understand is how releasing the source to that software interferes with adding value. Wouldn't it still add value if people could see the source?
I suppose part of your reluctance to release source would be reluctance to help your competitors. However, if you released your source under the (full, not lesser) GPL, your competitors couldn't use it in their product unless they also released their sources. If that happened, then your industry would be a software sharing utopia... :) OTOH, your competitors could look at the source to see how you do things, and then re-implement the good ideas themselves. There would be nothing illegal about that. The real question here is, how hardware-specific is your value-add? Would you be adding value to your competitors products too, if you released the source? If the answer is yes, then we have an example of the tragedy of the commons, or the so-called prisoner's dilemma. Human nature sucks :(
Of course you couldn't use readline, since they on purpose use the full GPL to stop proprietary people like you from using it. They figure that if you're going to keep your work to yourself, they'll keep their work to themselves when it comes to you.
You say
GPL is a total mess when it comes to a
commercial company that wants to ship a product
without fear of being told it has to release ALL
its code (even its local home-grown code).
You seem to be missing the point about the GPL, since the GPL is all about requiring you to release all the in-house code you develop and link to GPLed code.
You haven't mentioned the lesser GPL at all, for some reason. The LGPL is the one that only requires you to release changes made to code covered by it, and not code it is only linked to. (I suppose it could get messy when you have header files with significant macros, or something like that. I haven't worked on projects like yours, so I haven't had to deal with any of those problems.)
Holy overkill, no need to use TCP or any kind of network socket for local loopback. A simple pipe will do fine. (see pipe(2) and popen(3)) However you do the loopback, you still have the codec in a separate process from the rest of the app, so seeking and stuff like that might be slower. There wouldn't be much of a disadvantage for en/decoding a stream, since even a few memory->memory copies of the data would be small overhead compared to the codec runtime (I don't remember how fast flac is, but I don't think it is a real speed demon).
He's already considering switching from the lesser GPL to BSD-style. If he could do that, he can sell the priviledge of implementing using it in a proprietary system to whoever he wants. (AFAIK, it's likely that doing _either_ of those things will be a challenge, for the reasons you point out.)
The checking doesn't have to be done in-house. Depending on the nature of the problem, you can send out the same work unit to two or more clients, and compare the results. You can do less duplication by just trying to ferret out the cheaters with a few work units that have already been done.
The way this works in distributed.net's OGR (Optimal Golomb Ruler) contest is that the number of stubs examined is part of the returned information. The only way to know how many stubs you had to look at was to do all the work for the whole work unit. You can't find the right number to put any faster than you could look for an optimal golomb ruler, so there's no point just generating the number without doing the work correctly. This method of checking is applicable to any other task where you can generate a number that proves you did the work.
(For the record, I don't like d.net's RC5 contest any more than people who've posted here. It's totally deterministic, and thus a waste of time. AFAIK, the only reason people who know anything do it is for the statistics/ranking web page.)
The orbit it took around the black hole would have to include the starting point, i.e. the earth. (My intuition tells me you can't send something at a gravitational well from far away and have it orbit anywhere near circularly around the well, whether you're talking massless (and thus speed of light) stuff or normal matter.
:) This is safer than leaving going for multiple orbits.
Thus, when you wanted some data, you would just wait a few decades for it to orbit back to the earth. (Assuming you could find a massive enough body close enough, without any other massive bodies in the way to screw up an orbit.) If you wanted better data integrity, you could grab the data again after only one orbit, and store several days worth on a 2$ holographic cube, or whatever they're using instead of CDRs or hard drives by then
BondHeadGuy has said that this is not for a surveillance system, etc. OTOH, lets talk about cameras in public places. It's not the face rec itself that bothers me, it's recording all the information generated. I don't like anyone having huge databases of who was where, when, that they can look for patterns in, etc.
Iff I can trust the people running the cams to destroy the video, and not keep any other record of any events the captured (i.e. no DB of names from recognized faces), after a week or so, then the cameras wouldn't really bother me. It's not going to be possible to find someone that everyone can trust to run the cameras, thus there shouldn't be [surveillance] cameras in public places.
(Also, the cameras definitely should not be hidden. If you look around to see if you are alone, you should be able to tell.)
So, the issue isn't expectation of privacy, at least not in a local, instantaneous sense. It's the expectation that nobody is snooping on you and keeping tabs on everything you do - long term privacy, global privacy.
Real time in this case doesn't have anything to do with latency. You're right that not having latency requirements makes it easier, but as you point out, you still have to get it compressed as fast as it is coming out of the cameras, sooner or later. This is what is meant by "real time". (non-realtime is when I rip a CD on my slow computer, and it takes longer than the play time of the CD to get it all compressed, and it doesn't matter because I control when the next CD starts.)
In other contexts, like robot control, where "real time" operating systems are used, timing does matter, as well as overall speed. Vid compression doesn't need any OS support for "real time" stuff, but it is still a realtime task if you can't turn off the camera and wait for the compressor to catch up.
Nah, the worst that could happen would that everything would become deterministic and boring... Don't fall asleep during quantum...
OTOH, how would you collapse everything's wave function? Observering everything? Observing by shooting high energy particles... maybe he should be careful about collapsing wave functions...
Try the g2 graphics library. It's pretty simple, and can do win32, X11, PNG, JPEG, or postscript output.
http://g2.sourceforge.net/. I used it to do the graphics for a soap-bubble model program (I was looking at the dynamics of soap froths, etc.) I tweaked the code to use double buffering on the X display, and I've still got the patch to do that if anyone wants it. (I've sent it upstream already, but I don't know if it's incorporated or not.)
You'd want a real router program (in kernel or not), to do non-equal cost multipath, esp. if your connections aren't all the same :)
Yes, but you may have to break RSA to do it. This isn't like the situation with DVDs and such where you have something that can get at the data, but it will only do it in a certain way. In this case, they don't have to give you anything that will have the decryption key in it. After it JPEG-encodes a picture, it could encrypt it with the company's public (RSA) key, so only the company's private key could decrypt it. You have no way to get at your picture, other than getting the data out before it's encrypted (making the camera a bit inconvenient, or at least bulkier with the stuff you've got hooked up to it.), or breaking RSA.
The only reason they might not do that (other than not thinking of it) is if they wanted the camera to be able to show you previous shots you've taken, etc. In that case, the situation is like DVDs, because the camera has to be able to decrypt the images, so the decryption key is in there somewhere. A way around that is to store thumbnails unencrypted, but leave the camera no way to read the encrypted full-quality images. It could delete one of them if you decided you didn't want it (which makes sense if you could see a thumbnail to know which photo it was).
I think the key is that it only makes sense (to me) to kill oneself in a situation where you would die anyway if you didn't act, or where life would not be worth living if you didn't act. Think of people stranded on a desert island. One might volunteer to let the others eat them, if they think they would all die without resorting to cannibalism, but help will come soon enough to save ones they love. Or, think of a helicopter that can't take off with the load it's carrying, and anyone not on it will be caught by an erupting volcano or something. If your kids are on the chopper, you may choose to stay behind to let them live, because you couldn't bear to let one of them stay behind.
I don't think any of these situations covers kamikaze terrorist attacks (or the originals: the Japanese). This can't happen without religion, I don't think. (The Japs were motivated by gaining honour for their families, and for themselves in the memory of others. I can't really understand it, not being a part of that culture. I regard myself as too important to give up. Not that I wouldn't do something dangerous that might even result in death, but I wouldn't kill myself on purpose, no matter what it accomplished. (except as detailed in my first paragraph: if life wouldn't be worth living...) In the case of terrorists, they are twisted by lack of proper education, and being indoctrinated in schools that interpret Islam in such a way that killing people seems like a good idea. They end up in these schools because they get fed there, and wouldn't eat otherwise, most of the time. (this was very well reported in an article by Ian Goldstein in the globe and mail, IIRC.) Anyway, since I don't think most terrorists would find the world unbearable to live in if they didn't give their lives for their cause, they must be motivated by something else: religion. They are scoring points for the afterlife.
> Are they going to sue him because of the use of illegal encryption technologie?
No, but that extra circumstantial evidence (that the sender had something to hide, thus she used illegal enc. inside the legal enc.) tells the feds that this is definitely someone to keep an eye on. They'll probably send in human spies after that, to see who she meets in coffee shops, etc.
As long as the penalty for using illegal encryption is harsh enough, not enough people will defy the law to achieve privacy, so use of illegal encryption would indicate someone worth spying on further. Needless to say, it would really suck to go to jail for a year for using SSH. (what if I SSH to my terrorist-friend's computer, and use talk(1) to communicate...)
However, I think steganography and/or chaffing are sufficient to make the above a moot point. If terrorists limited themselves to PGP inside weak-gov-cipher, then this would help. They're smarter than that.
Then there would be a message that didn't have the block cipher key public-key encrypted to Uncle Sam's key. Two messages with different recipients is different from one message with two recipients, because of the way PGP works. To add a recipient to a message, you add information to the message so that someone with the private key corresponding to the public key you are encrypting to can recover the block cipher key and read the text of the message.
FYI, RTLinux is a real-time layer that passes hardware interrupts to the rest of Linux. The rest of Linux runs as a task under rtlinux. This isn't the kind of thing you can easily make into a module. To do that, you'd have to make init_module() patch the machine code in other parts of the kernel.
/., remember?
Also FYI, rtlinux is not new. They've been around for a couple years. I guess the FSF just waited to see if anything was going to happen before they got nasty. The source code is available, and there is an "open patent license", similar to the GPL, but with a few restrictions about having to provide contact info to Yodaiken on commercial users of rtlinux, and having to send him diffs for any in-house changes, IIRC.
Yodaiken is _not_ limiting the chances of others, etc.. He is limiting the desire to, because such work would not be as Free as GPLed code.
Know the facts before you get too excited. This is