So quit yer-FUD. Yes, the VMs in the browsers suck, but JDK1.1.8 is super solid on Solaris and NT, and probably on all of IBM's platforms like OS/2, OS/390, etc.
Maybe safe-to-restart web backends can "survive" better than GUI applications. But show me _any_ implementation of Java that allows Hotjava to go through entire java.sun.com without crashing by some definitely not Java-level fatal error.
because right now all implementations of it are still unreliable -- the reliability of application should be limited by its developer's stupidity, not by bugs in the language implementation, and in Java so far the user has better chance to get burned by the JVM bug than by actual flaw in the program, even when program is very buggy.
I haven't seen their specifications, but if it's yet another "everyone must switch to Unicode to get any kind of language support (unless he is already using iso8859-1 that coincides with first 256 Unicode characters)", cyrillic and asian languages support will become a nightmare.
1.I already exempted systems programming. You may as well bring up assembly language too.
Then what kind of applications are you talking about? Buffer overflow in a program that never uses anything but the data it produced before, can't compromise the system anyway. And if a program is a mailreader, text editor or web server, the same rules as for "system" software apply.
2.bzzt! thanks for playing. Many other languages such as Ada and Eiffel are "bootstrapped" from C into a subset compiler, and then fully rewritten in their own programming language and used to compile themselves. You obviously know zero about compiler technology. I suggest taking a course or reading the Dragon book.
I am familiar with that. The point still stands -- implementation does not necessarily works correctly, nothing gives a hard proof that combination of generated code plus system libraries plus OS still follow the rules that were supposed to be implemented.
So? The point it it's safeER, not completely safe. With a fully debugged string/buffer/collections library with assertions and bounds checking, less programmers will "reinvent" them and there will be less bugs.
This has nothing to do with language -- only with libraries. And "standard" libraries that come with C++ can help only with extremely dumb cases of buffer overflows, so "increase" of safety exists only if a programmer doesn't think at all. To eliminate the theoretical possibility of buffer overflows one has to eliminate pointers, and this can't keep system simple and efficient enough to be implemented well -- look at Java.
The facts are, stronger typed languages produce less bugs, period. Years of study by the military and NASA (do a google search) bear this out.
Why should I trust them? Military pushed Ada for ages and achieved nothing -- they have to "justify" their wasted time somehow.
WRONG! In many if not most of the cases, the compiler has sufficiently enough information to *PROVE* that an invalid array access can't occur, and hence can remove bounds checking code altogether. This occurs for example, when variable is incremented monotonically, like most iteration code which accounts for most loops.
Problems start when functions are being called, and cross-dependencies between data structures in them (not necessarily even data structures that exist at the same time and definitely ones that didn't exist when libraries were compiled) come into play.
Web Apps in particular are a perfect example. Their performance is easily bounded by network, disk, memory, and database performance long before CPU even matters. The CPU spends most of its time waiting for I/O to complete.
This only applies to primitive applications that do nothing but wait for database to give result, then do something trivial to represent it. "Web application" that performs complex calculation on its own or its backend application that keeps track of various parameters that are not stored in database will be still CPU-bound. If a lot of amateurs manage to stick database and high-latency access to it everywhere where it doesn't belong, it doesn't mean that this is correct or even sane way to solve those problems.
Any book on scalability will tell you this. And, when it comes down to CPU bound apps, 80-90% of the CPU time is spent in 10% of the code, so it makes sense to concentrate your risky optimized bounds-check free code there.
This won't improve security because in most of cases exactly the same code is most likely to contain buffer overflows, and in various conditions distribution of time spend in different pieces of code may change thus opening an easy DoS vulnerability (ex: almost all routers DoS).
I'm simply amazed at the number of so-called programmer geeks on slashdot that don't understand Knuth's Law or Amdahl's Law. People who have orgasms over Mhz ratings, and then wonder why some code on a 90Mhz sun will rock their 300Mhz pentium application.
How is it relevant? You still can't take already implemented and optimized application and make its equivalent on the same hardware with the same performance if you will reimplement every part of it in less efficient way.
I'm sorry, but C simply isn't the right tool for every job. It has it's place in systems programming, much like Perl is great at text processing. It sucks for everything else, and I speak as someone with 13 years C experience. I guess, I decided that it is better to know and use multiple programming languages than to rely on only one.
Most of things still can't be implemented in inefficient language and be expected to remain usable. If one is afraid of buffer overflows, he should get more benefit from buffer-overflow protection tricks in function calls, nonexecutable stack, etc. -- and even that is considered too expensive in the terms of performance in most of cases. And if someone claims that his language can eliminate all possible, or even most of classes of security bugs, he is lying, and Java is the best example of this so far.
It's wrong to rely on it as a way to make program secure or even correct -- it's the last thing that prevents something extremely bad from happening in the case when things are bad already.
My computer will run "rented" software, and then it will self-destruct, possibly leaving my data hijacked in some format, only that software can read, so I will have to rent it again until either that data, that company or me will die.
My computer will run some client, software will run somewhere else, and all my data will be sent to the company that provides this service.
No, the reason you use C is because the development tools in Linux suck for any language exception C. (g++ sucked until recently too)
And the reason for that is the unusability of all languages other than C for system programming. Not to mention that all other commonly used languages are implemented in C, and implementations had their own security holes -- the "nicer" is the language, the larger are its implementation holes: perl had suid bugs in many versions, java crashes so much, it has to have some of that exploitable, etc.
Even C++ would be better than C, since a large majority of the buffer overflows are idiots using the stdio str*/mem* routines without supplying buffer lengths, or trying to code up their own collection routines (vector, list, tree, etc) c++ and STL would fix a lot of it. The fact is, C is not type safe. C++ offers more type-safety.
Yet after working in commercial software development I can testify that security bugs are abundant in C++ code, too.
Eiffel offers design-by-contract assertions which would prevent a lot of the buggy libraries that float around from causing security holes.
How?
And Java of course, is like chroot()ing your code, since it can't modify memory, disk, or network resources without specifically allowing it to.
This is irrelevant because program that does something useful must be allowed to do it anyway. But the main problem with java is its own bugginess, so one can never be sure if his program will be even running at the time when it will be necessary unless something is keeping an eye on it (=> DoS),and no one knows how many exploitable bugs are in Java implementations.
The fact is, all the of the reasons to use C don't apply to developing daemons and application level code. You could make an argument for sticking with C for kernel work. But as an application language, it's far too sloppy and dangerous.
Every other language is worse for most of purposes.
Also, bounds checking *doesn't* lead to a performance hit.
Sure it does.
Most modern compilers can remove the vast majority of bounds checks when optimizing
What are you smoking? Bounds checking code, once introduced can be optimized, yet the result will still produce enormous performance hit, especially considering that it should be performed at least once per array per function for every local variable.
, and with Eiffel, you can turn them off for a "production build", but leave them on while developing/debugging.
If they won't be there, how can they protect you from the attack? the whole point of attack is to create condition that never occured in development in testing, so it will be able to produce unexpected case of buffer overflow.
I'm sick of C hacks making the "speed" argument when they usually don't understand how to make things scalable anyway (HINT: it's not CPU in the vast majority of cases)
It *is* CPU -- if you look what is it comes down to in the end. Except, of course, in some braindead cases that no decent programmer should produce anyway. After problems of braindamaged communications with poorly-designed other software and inefficient libraries were solved, all my projects finally hit the limit of performance, imposed by CPU, what could be well proven by the results of profiling. And the only solution was to get a better compiler and faster box.
Witness the hundreds of "me too" replies to the Katz articles.
Um... What Katz articles are you talking about? Most of replies to them on Slashdot are hostile.
All the geeks assume they will be rich, have big houses, expensive cars, and will be the boss of their mocking jocks. This is hardly the image of a VW Beetle driving flower child liberal.
Huh? Geeks, just like people who "assume they will be rich", don't think much about money, however for completely different reason -- because money aren't what they are after in the first place. They neither accept the system of values where money are very important (because knowledge is more important for them than luxury), nor are afraid of becoming extremely poor (because they know that their knowledge and abilities will always be useful). I personally worry more about my work negatively affecting my education (long hours, a lot of work and stress leave little time and energy for studying) than being unable to get rich -- I am aware that even if I will, it won't leave me less things to worry about, and I think that this is very common among geeks.
This also has nothing to do with people that take pride in being or pretending being poor -- geeks don't see anything "noble" in depriving themselves of things that they need unless there is some understandable reason for it.
I'm not talking local apps, linux is fine for that. But for runing X GUI apps on a remote computer Hummingbird eXcels. This is from actual experience. I've tried SUSE, RH5.x and RH6.0, FreeBSD 2.x and 3.0. on a wide range of hardware platforms (486 to PII). For running our (2D) GIS located remotely on our SGI Origin 2000, None of the above compare to eXceed on NT on similar hardware. What platforms have YOU tested, and what type of Apps do you run remotely????? motjuste@hotmail.com
Mostly XEmacs, but sometimes all kinds of Motif and GTK applications. Remote boxes are Solaris, Linux and FreeBSD.
Is it over local network or over some slow high-latency WAN? If local, something should be wrong with network configuration or hardware or poorly supported network card -- I have never seen significant speed decrease in properly configured network. Or you have Linux box placed behind a slow router. Or you managed to eat the network bandwidth with huge amount of trafic over NFS. Or you managed to configure 100BaseT card in Linux box as 10BaseT -- some old Vortex and other drivers don't recognize fast Ethernet when used with new cards, I have seen this problem at my home network. If the network is "remote" and slow or high-latency, you probably have forgot to enable lbxproxy or ssh X compression on Linux.
Internet can be used for criminal activity, and it make that activity easier to perform and harder to prosecute. Yet this does not justifiy any form of attack on freedom and privacy, and the only thing, government can do is to act within existing laws and educate public about safety, reasonal behavior and responsibility in anything related to the Internet.
It doesn't take a working group, created by EO, to come to this conclusion -- actually it doesn't take anything because everyone who have seen anything remotely related to the Internet, already heard that. This means that EO was issued to achieve something else, most likely to create long and emotionally charged document that is supposed to justify new laws that reduce freedom in this country -- possibly with a goal of selective application.
Organisms have redundancy at the level where viruses don't exist -- virus works at the level below cell, all organism's functions are performed at the level above cell. Small number of infected cells can't affect the functionality of organism, and this allows immune system to detect virus before becoming incapacitated. Winning strategy for a virus is to multiply fast enough to cover the damage done by the immune system, and transfer to someone else in large quantities -- so enough cells at eny given moment will produce copies of the virus even if large percentage of those copies and cells are being destroyed. HIV can damage the immune system, however strategy that relies on that is very dangerous for a virus -- because other viruses are constantly around, its damage to the organism can cause death faster than virus can be transmitted to others, and if, say, HIV was transmitted over the air, it would cause huge epidemy and die out just because there will be no people around to carry it. HIV survived because it's carried without noticeable damage for a long time and has chance to be transmitted before seriously damaging the immune system.
Computers perform all their functionality at the same level as "viruses" -- single disruption of something important changes the behavior of computer as a whole. This means that relatively simple virus has a good chance to render any immune system useless. Also the damage to "immune system" can remain unnoticed for a long time -- it's not like everyone constantly runs infected binaries. This makes any actions that specifically target "immune system" very efficient -- damage the thing that transmits your signature anywhere, or the thing that fixes executables, and you are safe. However all kinds of "passive" defense (uid/ACL/chroot/sandbox/jail-like mechanisms), while nonexistent in biology (because there is nothing to make them from but cells, and virus attacks cells) can be easily made in computer system -- if system is designed well enough, one can be sure that virus can't touch anything outside some set of things, and those things can be limited to something more or less expendable.
See my previous comment. fhttpd, FTP/HTTP server that I wrote, runs its modules, including php, as separate processes (possibly under different uids and even on different boxes/terminals/... if user configures so), so among other benefits, reliability of the server does not significantly decrease if one module is broken, and debugging/tracing/... of modules is actually doable with existing tools.
Check the list of apache httpd processes and look if any of them disappeared when connection dropped. If they did, use strace -p on processes that are about to die to confirm that they died on some signal (repeat tests until process that you are strace'ing will get the request). Then if it indeed a crash use gdb (with "attach" command) to catch the moment of crash in the same way.
Or install fhttpd with php module enabled on some testing box, change php module configuration from local (that is set by default in root-fhttpd.conf but commented out) to remote (comment out the "tail" of php application definition fhttpd.conf, starting from/usr/local/sbin/php), restart fhttpd and run fhttpd php module manually, connecting it with fhttpd, entering password, etc. under gdb. If php will crash, gdb will catch it. If it won't, you still have gdb to figure out what happened.
IMHO X feels slow because you can see separate widgets being redrawn in cases when Windows does double-buffering that works simultaneously on multiple widgets in the same window. Redraw time may be the same, but looking at static picture that changes at once makes it feel that the whole process happened faster.
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
This happens because you use relatively high-latency or slow network without lbxproxy or compressed ssh X forwarding.
Re:The X protocol is too slow and chatty
on
Is X The Future?
·
· Score: 1
If I remotely start Applix-UNIX on a SUN it runs faster than a remote Applix-NT. Whether this is just my imagination or real, I dunno. I don't think this is important anyway, since it's always subjectivity that counts.
Most likely you run it over low-latency line, forwarded over ssh X proxy in compressed mode while other have high-latency line and no proxies.
Isn't it true that organisations only render evidence inadmissable as evidence if they don't gather it under a warrant? This means, they can do as much wiretapping as they like when out fishing for criminals, then they can apply for a warrant to get the evidence needed to nail the criminals.
No, the fact of illegal search or wiretap not only invalidates it as an evidence against the person who was searched or wiretapped but can also get them sued just for doing it regardless of the reasons or purpose. There probably can be a lot of trouble with proof (unless they attempted to use it in court -- that makes proof of their illegal activities self-evident), however once it's proven, they are guilty.
And HOW, pray tell, are you going to do this, when you distribute the source code? You can't prevent people from modifying your GPL'd source code. Haven't you ever read the GPL?
I will just keep code with warnings on my site -- if everyone will do that, upgrades from developers' sites will make even the dumbest PHB think that there is something very wrong with that version if everyone calls it sabotaged.
Alternative for offrnding company is to make their closed world, "port" large percentage of software and keep users from using developers' sites for upgrades, but at the scale of Open Source development it's impossible, and people can get very suspicious.
Where does it say that the government does NOT have the right to tap data/voice transmissions? If they don't have the right to do this, why would they have the right to tap, for instance, the phone of a mafia boss?
There is no any "rights" for the government -- government in some cases can do various things (such as wiretapping, searches, arrests, etc.) yet there is nothing that guarantees that they will be successful. I believe that even if someone will issue an order for search inside some volcano, volcano still has no obligation to become accessible for police. If someone orders to arrest the whole population of AIDS virus, virus still will remain where it was no matter what government will do until government (or someone else) will develop a cure. In the same way government can order a wiretap of ssh connection between my boxes, yet I have absolutely no obligation to make it readable for them -- if they can break the encryption, good for them, and if not -- tough cookies.
Then one day, a friend would offer to install some wicked free app that didn't come from MS, and it wouldn't work. And the MS Person(tm) would blame the developer of the program, not Microsoft.
Not one application -- thousands of them will stop working. People have to from time to time download applications from developers' sites even if they are in distributions because distributions lag behind development, and if everything will stop working, distribution will lose its credibility instantly.
Slashdot Mirror
Because null pointer exception is not what Java program can generate by itself.
So quit yer-FUD. Yes, the VMs in the browsers suck, but JDK1.1.8 is super solid on Solaris and NT, and probably on all of IBM's platforms like OS/2, OS/390, etc.
Maybe safe-to-restart web backends can "survive" better than GUI applications. But show me _any_ implementation of Java that allows Hotjava to go through entire java.sun.com without crashing by some definitely not Java-level fatal error.
because right now all implementations of it are still unreliable -- the reliability of application should be limited by its developer's stupidity, not by bugs in the language implementation, and in Java so far the user has better chance to get burned by the JVM bug than by actual flaw in the program, even when program is very buggy.
Hey, I'm still waiting for a palm pilot web browser that doesn't suck.. need more connectivity.. need more connectivity..
ProxiWeb works fine for me -- what do you expect, frames and javascript?
I haven't seen their specifications, but if it's yet another "everyone must switch to Unicode to get any kind of language support (unless he is already using iso8859-1 that coincides with first 256 Unicode characters)", cyrillic and asian languages support will become a nightmare.
No, but any IP caught scanning closed ports goes into the deny table for a while. ipchains is SOOOO handy that way.
Nice. Now one spoofs large number of IPs in his requests, and all of them suddently will be denied -- DoS again.
1.I already exempted systems programming. You may as well bring up assembly language too.
Then what kind of applications are you talking about? Buffer overflow in a program that never uses anything but the data it produced before, can't compromise the system anyway. And if a program is a mailreader, text editor or web server, the same rules as for "system" software apply.
2.bzzt! thanks for playing. Many other languages such as Ada and Eiffel are "bootstrapped" from C into a subset compiler, and then fully rewritten in their own programming language and used to compile themselves. You obviously know zero about compiler technology. I suggest taking a course or reading the Dragon book.
I am familiar with that. The point still stands -- implementation does not necessarily works correctly, nothing gives a hard proof that combination of generated code plus system libraries plus OS still follow the rules that were supposed to be implemented.
So? The point it it's safeER, not completely safe. With a fully debugged string/buffer/collections library with assertions and bounds checking, less programmers will "reinvent" them and there will be less bugs.
This has nothing to do with language -- only with libraries. And "standard" libraries that come with C++ can help only with extremely dumb cases of buffer overflows, so "increase" of safety exists only if a programmer doesn't think at all. To eliminate the theoretical possibility of buffer overflows one has to eliminate pointers, and this can't keep system simple and efficient enough to be implemented well -- look at Java.
The facts are, stronger typed languages produce less bugs, period. Years of study by the military and NASA (do a google search) bear this out.
Why should I trust them? Military pushed Ada for ages and achieved nothing -- they have to "justify" their wasted time somehow.
WRONG! In many if not most of the cases, the compiler has sufficiently enough information to *PROVE* that an invalid array access can't occur, and hence can remove bounds checking code altogether. This occurs for example, when variable is incremented monotonically, like most iteration code which accounts for most loops.
Problems start when functions are being called, and cross-dependencies between data structures in them (not necessarily even data structures that exist at the same time and definitely ones that didn't exist when libraries were compiled) come into play.
Web Apps in particular are a perfect example. Their performance is easily bounded by network, disk, memory, and database performance long before CPU even matters. The CPU spends most of its time waiting for I/O to complete.
This only applies to primitive applications that do nothing but wait for database to give result, then do something trivial to represent it. "Web application" that performs complex calculation on its own or its backend application that keeps track of various parameters that are not stored in database will be still CPU-bound. If a lot of amateurs manage to stick database and high-latency access to it everywhere where it doesn't belong, it doesn't mean that this is correct or even sane way to solve those problems.
Any book on scalability will tell you this. And, when it comes down to CPU bound apps, 80-90% of the CPU time is spent in 10% of the code, so it makes sense to concentrate your risky optimized bounds-check free code there.
This won't improve security because in most of cases exactly the same code is most likely to contain buffer overflows, and in various conditions distribution of time spend in different pieces of code may change thus opening an easy DoS vulnerability (ex: almost all routers DoS).
I'm simply amazed at the number of so-called programmer geeks on slashdot that don't understand Knuth's Law or Amdahl's Law. People who have orgasms over Mhz ratings, and then wonder why some code on a 90Mhz sun will rock their 300Mhz pentium application.
How is it relevant? You still can't take already implemented and optimized application and make its equivalent on the same hardware with the same performance if you will reimplement every part of it in less efficient way.
I'm sorry, but C simply isn't the right tool for every job. It has it's place in systems programming, much like Perl is great at text processing. It sucks for everything else, and I speak as someone with 13 years C experience. I guess, I decided that it is better to know and use multiple programming languages than to rely on only one.
Most of things still can't be implemented in inefficient language and be expected to remain usable. If one is afraid of buffer overflows, he should get more benefit from buffer-overflow protection tricks in function calls, nonexecutable stack, etc. -- and even that is considered too expensive in the terms of performance in most of cases. And if someone claims that his language can eliminate all possible, or even most of classes of security bugs, he is lying, and Java is the best example of this so far.
Bounds checking can be used -- but:
Yeah, great.
No, the reason you use C is because the development tools in Linux suck for any language exception C. (g++ sucked until recently too)
And the reason for that is the unusability of all languages other than C for system programming. Not to mention that all other commonly used languages are implemented in C, and implementations had their own security holes -- the "nicer" is the language, the larger are its implementation holes: perl had suid bugs in many versions, java crashes so much, it has to have some of that exploitable, etc.
Even C++ would be better than C, since a large majority of the buffer overflows are idiots using the stdio str*/mem* routines without supplying buffer lengths, or trying to code up their own collection routines (vector, list, tree, etc) c++ and STL would fix a lot of it. The fact is, C is not type safe. C++ offers more type-safety.
Yet after working in commercial software development I can testify that security bugs are abundant in C++ code, too.
Eiffel offers design-by-contract assertions which would prevent a lot of the buggy libraries that float around from causing security holes.
How?
And Java of course, is like chroot()ing your code, since it can't modify memory, disk, or network resources without specifically allowing it to.
This is irrelevant because program that does something useful must be allowed to do it anyway. But the main problem with java is its own bugginess, so one can never be sure if his program will be even running at the time when it will be necessary unless something is keeping an eye on it (=> DoS),and no one knows how many exploitable bugs are in Java implementations.
The fact is, all the of the reasons to use C don't apply to developing daemons and application level code. You could make an argument for sticking with C for kernel work. But as an application language, it's far too sloppy and dangerous.
Every other language is worse for most of purposes.
Also, bounds checking *doesn't* lead to a performance hit.
Sure it does.
Most modern compilers can remove the vast majority of bounds checks when optimizing
What are you smoking? Bounds checking code, once introduced can be optimized, yet the result will still produce enormous performance hit, especially considering that it should be performed at least once per array per function for every local variable.
, and with Eiffel, you can turn them off for a "production build", but leave them on while developing/debugging.
If they won't be there, how can they protect you from the attack? the whole point of attack is to create condition that never occured in development in testing, so it will be able to produce unexpected case of buffer overflow.
I'm sick of C hacks making the "speed" argument when they usually don't understand how to make things scalable anyway (HINT: it's not CPU in the vast majority of cases)
It *is* CPU -- if you look what is it comes down to in the end. Except, of course, in some braindead cases that no decent programmer should produce anyway. After problems of braindamaged communications with poorly-designed other software and inefficient libraries were solved, all my projects finally hit the limit of performance, imposed by CPU, what could be well proven by the results of profiling. And the only solution was to get a better compiler and faster box.
Witness the hundreds of "me too" replies to the Katz articles.
Um... What Katz articles are you talking about? Most of replies to them on Slashdot are hostile.
All the geeks assume they will be rich, have big houses, expensive cars, and will be the boss of their mocking jocks. This is hardly the image of a VW Beetle driving flower child liberal.
Huh? Geeks, just like people who "assume they will be rich", don't think much about money, however for completely different reason -- because money aren't what they are after in the first place. They neither accept the system of values where money are very important (because knowledge is more important for them than luxury), nor are afraid of becoming extremely poor (because they know that their knowledge and abilities will always be useful). I personally worry more about my work negatively affecting my education (long hours, a lot of work and stress leave little time and energy for studying) than being unable to get rich -- I am aware that even if I will, it won't leave me less things to worry about, and I think that this is very common among geeks.
This also has nothing to do with people that take pride in being or pretending being poor -- geeks don't see anything "noble" in depriving themselves of things that they need unless there is some understandable reason for it.
I'm not talking local apps, linux is fine for that. But for runing X GUI apps on a remote computer Hummingbird eXcels. This is from actual experience. I've tried SUSE, RH5.x and RH6.0, FreeBSD 2.x and 3.0. on a wide range of hardware platforms (486 to PII). For running our (2D) GIS located remotely on our SGI Origin 2000, None of the above compare to eXceed on NT on similar hardware. What platforms have YOU tested, and what type of Apps do you run remotely????? motjuste@hotmail.com
Mostly XEmacs, but sometimes all kinds of Motif and GTK applications. Remote boxes are Solaris, Linux and FreeBSD.
Is it over local network or over some slow high-latency WAN? If local, something should be wrong with network configuration or hardware or poorly supported network card -- I have never seen significant speed decrease in properly configured network. Or you have Linux box placed behind a slow router. Or you managed to eat the network bandwidth with huge amount of trafic over NFS. Or you managed to configure 100BaseT card in Linux box as 10BaseT -- some old Vortex and other drivers don't recognize fast Ethernet when used with new cards, I have seen this problem at my home network. If the network is "remote" and slow or high-latency, you probably have forgot to enable lbxproxy or ssh X compression on Linux.
This is very, very odd. You definitely severely misconfigured something on Linux box if it manages to run XF86 slower than Exceed.
Internet can be used for criminal activity, and it make that activity easier to perform and harder to prosecute. Yet this does not justifiy any form of attack on freedom and privacy, and the only thing, government can do is to act within existing laws and educate public about safety, reasonal behavior and responsibility in anything related to the Internet.
It doesn't take a working group, created by EO, to come to this conclusion -- actually it doesn't take anything because everyone who have seen anything remotely related to the Internet, already heard that. This means that EO was issued to achieve something else, most likely to create long and emotionally charged document that is supposed to justify new laws that reduce freedom in this country -- possibly with a goal of selective application.
Organisms have redundancy at the level where viruses don't exist -- virus works at the level below cell, all organism's functions are performed at the level above cell. Small number of infected cells can't affect the functionality of organism, and this allows immune system to detect virus before becoming incapacitated. Winning strategy for a virus is to multiply fast enough to cover the damage done by the immune system, and transfer to someone else in large quantities -- so enough cells at eny given moment will produce copies of the virus even if large percentage of those copies and cells are being destroyed. HIV can damage the immune system, however strategy that relies on that is very dangerous for a virus -- because other viruses are constantly around, its damage to the organism can cause death faster than virus can be transmitted to others, and if, say, HIV was transmitted over the air, it would cause huge epidemy and die out just because there will be no people around to carry it. HIV survived because it's carried without noticeable damage for a long time and has chance to be transmitted before seriously damaging the immune system.
Computers perform all their functionality at the same level as "viruses" -- single disruption of something important changes the behavior of computer as a whole. This means that relatively simple virus has a good chance to render any immune system useless. Also the damage to "immune system" can remain unnoticed for a long time -- it's not like everyone constantly runs infected binaries. This makes any actions that specifically target "immune system" very efficient -- damage the thing that transmits your signature anywhere, or the thing that fixes executables, and you are safe. However all kinds of "passive" defense (uid/ACL/chroot/sandbox/jail-like mechanisms), while nonexistent in biology (because there is nothing to make them from but cells, and virus attacks cells) can be easily made in computer system -- if system is designed well enough, one can be sure that virus can't touch anything outside some set of things, and those things can be limited to something more or less expendable.
See my previous comment. fhttpd, FTP/HTTP server that I wrote, runs its modules, including php, as separate processes (possibly under different uids and even on different boxes/terminals/... if user configures so), so among other benefits, reliability of the server does not significantly decrease if one module is broken, and debugging/tracing/... of modules is actually doable with existing tools.
Check if httpd processes die in some odd way.
Check the list of apache httpd processes and look if any of them disappeared when connection dropped. If they did, use strace -p on processes that are about to die to confirm that they died on some signal (repeat tests until process that you are strace'ing will get the request). Then if it indeed a crash use gdb (with "attach" command) to catch the moment of crash in the same way.
Or install fhttpd with php module enabled on some testing box, change php module configuration from local (that is set by default in root-fhttpd.conf but commented out) to remote (comment out the "tail" of php application definition fhttpd.conf, starting from /usr/local/sbin/php), restart fhttpd and run fhttpd php module manually, connecting it with fhttpd, entering password, etc. under gdb. If php will crash, gdb will catch it. If it won't, you still have gdb to figure out what happened.
Anyone know WHY X feels slower?
IMHO X feels slow because you can see separate widgets being redrawn in cases when Windows does double-buffering that works simultaneously on multiple widgets in the same window. Redraw time may be the same, but looking at static picture that changes at once makes it feel that the whole process happened faster.
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
This happens because you use relatively high-latency or slow network without lbxproxy or compressed ssh X forwarding.
If I remotely start Applix-UNIX on a SUN it runs faster than a remote Applix-NT. Whether this is just my imagination or real, I dunno. I don't think this is important anyway, since it's always subjectivity that counts.
Most likely you run it over low-latency line, forwarded over ssh X proxy in compressed mode while other have high-latency line and no proxies.
11 is not a version number.
#define X_PROTOCOL 11 /* current protocol version */ /* current minor version */
#define X_PROTOCOL_REVISION 0
Isn't it true that organisations only render evidence inadmissable as evidence if they don't gather it under a warrant? This means, they can do as much wiretapping as they like when out fishing for criminals, then they can apply for a warrant to get the evidence needed to nail the criminals.
No, the fact of illegal search or wiretap not only invalidates it as an evidence against the person who was searched or wiretapped but can also get them sued just for doing it regardless of the reasons or purpose. There probably can be a lot of trouble with proof (unless they attempted to use it in court -- that makes proof of their illegal activities self-evident), however once it's proven, they are guilty.
And HOW, pray tell, are you going to do this, when you distribute the source code? You can't prevent people from modifying your GPL'd source code. Haven't you ever read the GPL?
I will just keep code with warnings on my site -- if everyone will do that, upgrades from developers' sites will make even the dumbest PHB think that there is something very wrong with that version if everyone calls it sabotaged.
Alternative for offrnding company is to make their closed world, "port" large percentage of software and keep users from using developers' sites for upgrades, but at the scale of Open Source development it's impossible, and people can get very suspicious.
Large-scale boycott however is very easy.
Where does it say that the government does NOT have the right to tap data/voice transmissions? If they don't have the right to do this, why would they have the right to tap, for instance, the phone of a mafia boss?
There is no any "rights" for the government -- government in some cases can do various things (such as wiretapping, searches, arrests, etc.) yet there is nothing that guarantees that they will be successful. I believe that even if someone will issue an order for search inside some volcano, volcano still has no obligation to become accessible for police. If someone orders to arrest the whole population of AIDS virus, virus still will remain where it was no matter what government will do until government (or someone else) will develop a cure. In the same way government can order a wiretap of ssh connection between my boxes, yet I have absolutely no obligation to make it readable for them -- if they can break the encryption, good for them, and if not -- tough cookies.
Then one day, a friend would offer to install some wicked free app that didn't come from MS, and it wouldn't work. And the MS Person(tm) would blame the developer of the program, not Microsoft.
Not one application -- thousands of them will stop working. People have to from time to time download applications from developers' sites even if they are in distributions because distributions lag behind development, and if everything will stop working, distribution will lose its credibility instantly.
If I have such a perverted system I don't want some application installer bitching about it.
Installer should bitch about _particular_ modifications that are considered harmful (say, having major system utilities depend on COM support).