I am currently enrolled in the ACCIS BSCS program. I've been programming for years, but felt it would benefit me to take the next step and actually get the experience and, more importantly, the degree.
I did two years of undergrad at Virginia Tech back before the dot-com boom beckoned me into the Hells of the corporate world, so when it came time to decide whether or not ACCIS would be worth my while, I called the Virginia Tech Comp Sci department. One of the professors there was nice enough to speak with me. I asked him to look over the ACCIS BSCS curriculum for me and let me know if completion of that curriculum would be considered a good step towards entering the graduate studies at VT for a Comp Sci Masters Degree.
As soon as he emailed me back and "yes, it looks like a good curriculum and will more than satisfy the requirements for CS graduate studies at VT", I enrolled. I know you don't have to have a degree in any certain discipline to take graduate level courses, but he has a doctorate or two (including Comp Sci) and gave his stamp of approval. That's good enough for me.
Now if only I can actually get some time to do the work. It's hard with all of these website reviewrequests coming in;)
So much for having my homepage set to "http://cowboyneal-is-the-man.com".
j/k
In all actuality, I can say that ending this lame excuse for grabbing desktop real estate will save me loads of time. I have all kinds of administrative scripts that look up DNS records for my customers and report on live/dead/moved domains. SiteFinder threw quite a monkey wrench into the system.
I realize PlanetSide doesn't fit the RPG genre, that's why I said it mixes FPS and RPG. The persistence, storyline and the fact that PlanetSide allows you to play certain classes of characters kinda leans towards RPG. Of course, this still doesn't change the fact that it's primarily just an FPS set in a persistent world.
I personally have found PlanetSide to be quite enjoyable. Mixes FPS w/ RPG. Only downside is that its a Windows only game (for now). Anyone had any luck getting it to run under WINE?
If SCO goes after SGI and continues to go after their own customers, they will eventually obliterate their own customer base. This is just more proof of Mr. McBride's roadmap for SCO (which mysteriously resembles a downward spiral).
I'm just waiting for the SEC to wake up and realize that all of this was done so that the execs @ SCO could line their pockets.
SCO: You copied our Intellectual Property!!
[Company X]: No we didn't... that code's from the BSD codebase.
SCO: Oh... ok... well we're going to sue you anyways and revoke your UNIX license.
[Company X]: Whatever... go away or I'll replace you with a small shell script.
Yes... definitely a little satire in it. Even my wife asked me if I really planned on sending out invoices. For the record: I do. If I don't keep a record of it, I can't write it off as a business loss on taxes;)
Also for the record: I've never received any spam at that domain, and this really was changed just today. So while it is meant to invoke laughter, I do intend to do it. After all, it's much cheaper than the alternative: $25,000 per unsolicited commercial email under Commonwealth of Virginia law.
Wait a minute... every time I step foot in the hospital, they tell me to turn off my cell phone because it interferes with their equipment. If the phones have to be turned off, why are the doctors and nurses even carrying them?
I remember my first glimpse of Linux. It was on a classified Sun Sparc based system in a custom, portable, hardened, tempest platform. I first started working with it in (you ready for this?) 1995.
I remember being impressed about how amazingly fast it was compared to similar Windows based (3.1 and 3.11 at the time) systems. Good to see things haven't changed. DoD Linux systems are probably still blowing the doors off of their Windows counterparts.
I'm afraid I'll have to agree with Cnik70 on this one. I can remember struggling through Java programs back in the day and thinking to myself, "No way in Hell this will ever become what everyone is saying it will be." That was then, this is now. Internal benchmarks of our code under mod_perl, PHP, Python (Zope), and Java for our web development show Java (Tomcat) to be the winner by a landslide when it comes to scalability, performance, and rapid development. From what I understand, even eBay is switching to a Java platform (anyone know more about this?). Of course, this is all on the server side...
As far as GUI applications are concerned, the only thing that is slow about running Java GUI apps on modern hardware is the startup time. This can supposedly be taken care of with accelerator apps which keep a JVM running in the background just waiting for Java apps to be run. Even without such acceleration, I still use jEdit as my text editor of choice for all my programming needs (http://jedit.org/), and as a sysadmin I don't even program in Java (where jEdit is best applied). I usually stick to Perl/Python for automating systems administration scripts. Nevertheless, I find that the features, performance, and overall ease-of-use in jEdit save me loads of time (nice CVS integration too).
Bottom line, Java is already in enterprise computing environments and, with an experienced developer, ready for primetime in smaller applications as well.
Personally, I currently use TMDA to protect some of my accounts. It's a challenge/response system that uses whitelist/blacklist technology and sends a challenge to the unknown senders. This is quite effective at combatting spam since the challenge to a spam message usually ends up bouncing anyways.
The only problem with TMDA is that some people consider the challenge/response method to be quite rude (click here and do a search for "gunfighter" to read the responses to my comment(s) about TMDA). TMDA, and similar technologies, definitely place the responsibility for ensuring message delivery in the hands of the sender and receiver. In addition, there are other considerations such as the additional overhead of the extra messages. There are even cases where people who haven't properly configured such technologies end up getting into confirmation loops and screw up by sending a challenge to a legitimate mailing list.
To overcome these problems I've actually concocted, in cooperation with a fellow developer, an automated means of verifying the authenticity of an email message. While this may not stop spam cold in its tracks from the get-go, it will definitely be a step in the right direction. Instead of blocking entire IP blocks (or even individual IP addresses), companies, ISPs, and individuals will soon be able to compare against blacklists of individual users.
By using this technology in cooperation with a challenge/response-type filter, only individual senders flagged as potential spammers will be a) blocked or b) flagged as possible spam or c) receive a challenge/response. This will completely obsolete any and all current methods of dns or IP based blacklist(s).
Time-to-market is up in the air right now, but hopefully we'll have a prototype ready here in the next month or two. Hope to see you then.
I installed Gentoo at several of my customer sites. Some of the installations replaced Windows servers, others replaced Red Hat installations, and some are brand new servers.
I can tell you, without a doubt, that real, serious businesses are using Gentoo very successfully. Granted, someone less familiar with Linux could very easily have slapped up a RedHat9.x server for them in less time, but with Gentoo I was able to give the customers exactly what they wanted. I was able to give them a very robust, secure solution thanks to the minimalist nature of Gentoo. No features they didn't want, no services they didn't want, and everything went without a hitch (with the exception of one customer's PHP 4.3.2 thanks to his programmer naming some functions the same as the native PHP functions... duh).
Case in point: One local customer had been running a Samba server on RedHat with Win98 clients. They wanted to increase security by establishing a PDC for their domain AND move their website in house (Java-powered site running under Tomcat). I configured the RedHat Samba instance to use LDAP only to find that... Redhat's Samba doesn't (or didn't at the time) support LDAP! A Gentoo installation later (ok... so I went home and came back the next day while the Stage2 compiled... big deal), and it was as simple as 'USE="ldap" emerge samba tomcat' to get them up and running. They recently called me to say that they liked my idea of switching from their (albeit lacking and somewhat poorly designed by someone else) Java-based site to a Plone site. 'emerge apache plone' and away we go.
Actually, I'm sure his lawyer-type wife (as well as any other lawyer or person versed in trade secret law) can tell you why he's doing it. You see, there's this little precedent set in regards to trade secrets. If they've failed to enforce their NDA before, then they might not be able to make a claim against someone else who didn't uphold it.
I learned this when I left an employer and they realized I had worked there for ohhhhhh... about 3 years without signing their non-compete (duh!). The only thing they could sick a lawyer on me for was to protect their precious "trade secrets".
Their trade secrets were the following:
1) Their "best practices" methods of engineering, installing, and maintaining networks. Luckily, TCP/IP networking is pretty much common knowledge. The "best practices" are easily attainable from the Cisco and Microsoft websites (I helped them compile their best practices from those two websites). No way they could be considered a trade secret. This is analogous to the SCO fraudulent case as follows: They claim that the Linux OS couldn't have advanced without the inside knowledge attainable only from the UNIX source code. Unfortunately for SCO, if the "Enterprise kernel features HOWTO" is out there somewhere, SCO is screwed on this point.
2) Their special configuration and wiring of a modem to be used for a special out-of-band management device. Unfortunately, they had released the information to one of our suppliers. The supplier, in turn, posted it on their website. Doh! In the trade secret world, if one person can take a bit of information public, you can't make another person _not_ take it public. For example, BSD code is public, so they can't attack IBM for releasing a version of the same code. They tried to and LOST the case against BSD years ago. No enforcement against BSD == no enforcement against IBM.
3) Their last "trade secret" was supposedly their customer list. This one stumped me at first, because I (obviously) had knowledge about their customers. I knew who they were, their administrator/root passwords, their contact information, etc. etc. I even had a job offer or two from them. To use this information to my financial advantage _must_ be considered inappropriate use of a trade secret, right? WRONG! Their customer list is printed right on the back of one of their marketing brochures ("Look who we've done work for!"). Company name in hand, the phone book/Internet provided me with all of the contact information I wanted. As far as the customers' network layouts and passwords, those are proprietary information of the customers, not my former employers. Granted, it was a partial customer list and quite old. That didn't matter to me. The information I needed to get started was there. That was two and a half years ago. I've been stealing business from them ever since (not hard since they no longer provide the services I offered to their customers). This is much like SCO's earlier release of an old version of the UNIX source code. That earlier release could be enough to fry their case. Even though they are accusing IBM of raping their more recent versions, if the code in question is anywhere _near_ present in the old version, SCO is screwed.
Personally, I think SCO's case is going to fall... hard. If they had a real case, they would have shown the code long ago. Not just shown the code, but PROVED that they had it first and not the other way around. After all, Linux had many enterprise features before SCO's various *NIX flavors. Perhaps we should be sueing them for violation of the GPL?
The confirmation messages are sent to the Return-Path: header address. If you're using TMDA (or similar products) correctly, you will receive the user's confirmation request and be able to confirm delivery of your original message.
I disagree. It's not too drastic. I work for an ISP, and we recently piloted a similar program using Tagged Message Delivery Agent. I must say that it works flawlessly with almost zero false negatives. We even have a web interface so that people can go and look into their pending queue to manually approve or reject messages. Unconfirmed messages are automatically deleted after a week. For the mailing list problems Mr. Minh mentions in the parent post, this has proved to work great. When one of our customers gets a bank statement, he or she can manually approve that email for delivery. The approval adds the bank's from address to the user's whitelist, and all subsequent emailed bank statements pass through without the need for confirmation.
Read the TMDA FAQ and you'll get answers to many questions about the process. In addition, it will explain to you how you can set up your list so that less than 10% of your legitimate senders never even see a confirmation message. It explains how to handle mailing lists as well.
This IS the current answer because it is a mechanism used for delivery once the mail server has receives the message. It does not require all participants use it, yet it performs beautifully for those who choose to use it. Until the SMTP protocol and related software are re-written (and everybody upgrades en masse), this is definitely the answer. I promote the solution anywhere and everywhere I have the chance.
Sounds good to me. I have a project lying on sf "abandoned" that needs to be deleted. As soon as my wife and I put together the initial specs, we both switched jobs and our available time to devote to the project went from around 10 hours a week to -1 hours per week. The administrators of projects need to have the ability to delete their projects. This functionality may have been added since I last checked, but thus far the only way I've seen to delete projects is to email sf.net and have the system administrator(s) delete it for you.
I have the answer. Does that mean I get a portion of the supposed $10,000,000,000 people are going to spend on Spam control?
Anyone who wants to eliminate 99.99% of the spam from their inbox, just let me know. Stipulations are that you must either a) own your own domain and have control over the DNS and email administration of said domain or b) not mind switching to a new email address. I'll zap your spam in a jiffy.
I just attended a network security seminar at a small university in Virginia this past week. I manned the booth for my company, but between rush times I spent most of my time speaking with the people (sometimes competitors) from other booths. One of the engineers at another booth was kind enough to give me an RSA SecurID demo box with two key fobs and all the software I needed to set up a server.
Within an hour of arriving back at my hotel room, I had the software up and running (had to download the Win2K agent from the RSA website), and my login to my laptop was secured via SecurID. Once I arrived home last night, I set up the server on my home network, and now all of my workstations and server (Linux included!) are using RSA SecurID login.
You can run the server on NT/AIX/Solaris (probably more by now because I have an old kit), and there are agents out there for just about any operating system. In addition, you can have routers access the server as if it were a TACACS+ or RADIUS server.
Check the RSA website for more information. The part you'll care most about are the agents (client side of the equation), and I know for sure that there are agents available for Windows, Linux, and Solaris.
If you're looking to pay through the nose for software licenses, take a look at Citrix. You can load balance servers for high application availability. It's stable and proven software, but it's also very expensive. There are Citrix ICA clients for most Operating Systems, thus allowing you to access your applications remotely from most platforms.
On the other hand, if you're looking for a more cost effective solution then just use VNC to access your workstation(s) remotely.
There are plenty of thin client solutions available, it's just a matter of making sure you pick one that suits your a) needs and b) budget.
Slashdot Mirror
Is this the same 9th Circuit Court that ruled the U.S. Constitution as unconstitutional?
I am currently enrolled in the ACCIS BSCS program. I've been programming for years, but felt it would benefit me to take the next step and actually get the experience and, more importantly, the degree.
;)
I did two years of undergrad at Virginia Tech back before the dot-com boom beckoned me into the Hells of the corporate world, so when it came time to decide whether or not ACCIS would be worth my while, I called the Virginia Tech Comp Sci department. One of the professors there was nice enough to speak with me. I asked him to look over the ACCIS BSCS curriculum for me and let me know if completion of that curriculum would be considered a good step towards entering the graduate studies at VT for a Comp Sci Masters Degree.
As soon as he emailed me back and "yes, it looks like a good curriculum and will more than satisfy the requirements for CS graduate studies at VT", I enrolled. I know you don't have to have a degree in any certain discipline to take graduate level courses, but he has a doctorate or two (including Comp Sci) and gave his stamp of approval. That's good enough for me.
Now if only I can actually get some time to do the work. It's hard with all of these website review requests coming in
So much for having my homepage set to "http://cowboyneal-is-the-man.com".
j/k
In all actuality, I can say that ending this lame excuse for grabbing desktop real estate will save me loads of time. I have all kinds of administrative scripts that look up DNS records for my customers and report on live/dead/moved domains. SiteFinder threw quite a monkey wrench into the system.
How'd you know I was on dope?
Just kidding...
I realize PlanetSide doesn't fit the RPG genre, that's why I said it mixes FPS and RPG. The persistence, storyline and the fact that PlanetSide allows you to play certain classes of characters kinda leans towards RPG. Of course, this still doesn't change the fact that it's primarily just an FPS set in a persistent world.
And for the record, I have no market share.
I personally have found PlanetSide to be quite enjoyable. Mixes FPS w/ RPG. Only downside is that its a Windows only game (for now). Anyone had any luck getting it to run under WINE?
If SCO goes after SGI and continues to go after their own customers, they will eventually obliterate their own customer base. This is just more proof of Mr. McBride's roadmap for SCO (which mysteriously resembles a downward spiral).
I'm just waiting for the SEC to wake up and realize that all of this was done so that the execs @ SCO could line their pockets.
SCO: You copied our Intellectual Property!!
[Company X]: No we didn't... that code's from the BSD codebase.
SCO: Oh... ok... well we're going to sue you anyways and revoke your UNIX license.
[Company X]: Whatever... go away or I'll replace you with a small shell script.
Yes... definitely a little satire in it. Even my wife asked me if I really planned on sending out invoices. For the record: I do. If I don't keep a record of it, I can't write it off as a business loss on taxes ;)
Also for the record: I've never received any spam at that domain, and this really was changed just today. So while it is meant to invoke laughter, I do intend to do it. After all, it's much cheaper than the alternative: $25,000 per unsolicited commercial email under Commonwealth of Virginia law.
Finally, something to fill in the ????? in my
- Linux
- ?????
- Profit!!
business plan. Now I don't have to hide my email address(es) anymore!Given this course of action, even devices like my vacuum cleaner and mini-fridge will be vulnerable to DCOM exploits.
So does this change the...
1. [Insert crazy idea or technology here]
2. ??????
3. Profit!!
business model to...
1. NDA
2. [Insert crazy idea or technology here]
3. ??????
4. Profit!!
???
-- Gun
Wait a minute... every time I step foot in the hospital, they tell me to turn off my cell phone because it interferes with their equipment. If the phones have to be turned off, why are the doctors and nurses even carrying them?
-- Gun
I remember my first glimpse of Linux. It was on a classified Sun Sparc based system in a custom, portable, hardened, tempest platform. I first started working with it in (you ready for this?) 1995.
I remember being impressed about how amazingly fast it was compared to similar Windows based (3.1 and 3.11 at the time) systems. Good to see things haven't changed. DoD Linux systems are probably still blowing the doors off of their Windows counterparts.
-- Gun
I'm afraid I'll have to agree with Cnik70 on this one. I can remember struggling through Java programs back in the day and thinking to myself, "No way in Hell this will ever become what everyone is saying it will be." That was then, this is now. Internal benchmarks of our code under mod_perl, PHP, Python (Zope), and Java for our web development show Java (Tomcat) to be the winner by a landslide when it comes to scalability, performance, and rapid development. From what I understand, even eBay is switching to a Java platform (anyone know more about this?). Of course, this is all on the server side...
As far as GUI applications are concerned, the only thing that is slow about running Java GUI apps on modern hardware is the startup time. This can supposedly be taken care of with accelerator apps which keep a JVM running in the background just waiting for Java apps to be run. Even without such acceleration, I still use jEdit as my text editor of choice for all my programming needs (http://jedit.org/), and as a sysadmin I don't even program in Java (where jEdit is best applied). I usually stick to Perl/Python for automating systems administration scripts. Nevertheless, I find that the features, performance, and overall ease-of-use in jEdit save me loads of time (nice CVS integration too).
Bottom line, Java is already in enterprise computing environments and, with an experienced developer, ready for primetime in smaller applications as well.
-- Gun
Personally, I currently use TMDA to protect some of my accounts. It's a challenge/response system that uses whitelist/blacklist technology and sends a challenge to the unknown senders. This is quite effective at combatting spam since the challenge to a spam message usually ends up bouncing anyways.
The only problem with TMDA is that some people consider the challenge/response method to be quite rude (click here and do a search for "gunfighter" to read the responses to my comment(s) about TMDA). TMDA, and similar technologies, definitely place the responsibility for ensuring message delivery in the hands of the sender and receiver. In addition, there are other considerations such as the additional overhead of the extra messages. There are even cases where people who haven't properly configured such technologies end up getting into confirmation loops and screw up by sending a challenge to a legitimate mailing list.
To overcome these problems I've actually concocted, in cooperation with a fellow developer, an automated means of verifying the authenticity of an email message. While this may not stop spam cold in its tracks from the get-go, it will definitely be a step in the right direction. Instead of blocking entire IP blocks (or even individual IP addresses), companies, ISPs, and individuals will soon be able to compare against blacklists of individual users.
By using this technology in cooperation with a challenge/response-type filter, only individual senders flagged as potential spammers will be a) blocked or b) flagged as possible spam or c) receive a challenge/response. This will completely obsolete any and all current methods of dns or IP based blacklist(s).
Time-to-market is up in the air right now, but hopefully we'll have a prototype ready here in the next month or two. Hope to see you then.
-- GunSounds a lot like TMDA:
http://tmda.net/
-- Gun
I installed Gentoo at several of my customer sites. Some of the installations replaced Windows servers, others replaced Red Hat installations, and some are brand new servers.
I can tell you, without a doubt, that real, serious businesses are using Gentoo very successfully. Granted, someone less familiar with Linux could very easily have slapped up a RedHat9.x server for them in less time, but with Gentoo I was able to give the customers exactly what they wanted. I was able to give them a very robust, secure solution thanks to the minimalist nature of Gentoo. No features they didn't want, no services they didn't want, and everything went without a hitch (with the exception of one customer's PHP 4.3.2 thanks to his programmer naming some functions the same as the native PHP functions... duh).
Case in point: One local customer had been running a Samba server on RedHat with Win98 clients. They wanted to increase security by establishing a PDC for their domain AND move their website in house (Java-powered site running under Tomcat). I configured the RedHat Samba instance to use LDAP only to find that... Redhat's Samba doesn't (or didn't at the time) support LDAP! A Gentoo installation later (ok... so I went home and came back the next day while the Stage2 compiled... big deal), and it was as simple as 'USE="ldap" emerge samba tomcat' to get them up and running. They recently called me to say that they liked my idea of switching from their (albeit lacking and somewhat poorly designed by someone else) Java-based site to a Plone site. 'emerge apache plone' and away we go.
Actually, I'm sure his lawyer-type wife (as well as any other lawyer or person versed in trade secret law) can tell you why he's doing it. You see, there's this little precedent set in regards to trade secrets. If they've failed to enforce their NDA before, then they might not be able to make a claim against someone else who didn't uphold it.
I learned this when I left an employer and they realized I had worked there for ohhhhhh... about 3 years without signing their non-compete (duh!). The only thing they could sick a lawyer on me for was to protect their precious "trade secrets".
Their trade secrets were the following:
1) Their "best practices" methods of engineering, installing, and maintaining networks. Luckily, TCP/IP networking is pretty much common knowledge. The "best practices" are easily attainable from the Cisco and Microsoft websites (I helped them compile their best practices from those two websites). No way they could be considered a trade secret. This is analogous to the SCO fraudulent case as follows: They claim that the Linux OS couldn't have advanced without the inside knowledge attainable only from the UNIX source code. Unfortunately for SCO, if the "Enterprise kernel features HOWTO" is out there somewhere, SCO is screwed on this point.
2) Their special configuration and wiring of a modem to be used for a special out-of-band management device. Unfortunately, they had released the information to one of our suppliers. The supplier, in turn, posted it on their website. Doh! In the trade secret world, if one person can take a bit of information public, you can't make another person _not_ take it public. For example, BSD code is public, so they can't attack IBM for releasing a version of the same code. They tried to and LOST the case against BSD years ago. No enforcement against BSD == no enforcement against IBM.
3) Their last "trade secret" was supposedly their customer list. This one stumped me at first, because I (obviously) had knowledge about their customers. I knew who they were, their administrator/root passwords, their contact information, etc. etc. I even had a job offer or two from them. To use this information to my financial advantage _must_ be considered inappropriate use of a trade secret, right? WRONG! Their customer list is printed right on the back of one of their marketing brochures ("Look who we've done work for!"). Company name in hand, the phone book/Internet provided me with all of the contact information I wanted. As far as the customers' network layouts and passwords, those are proprietary information of the customers, not my former employers. Granted, it was a partial customer list and quite old. That didn't matter to me. The information I needed to get started was there. That was two and a half years ago. I've been stealing business from them ever since (not hard since they no longer provide the services I offered to their customers). This is much like SCO's earlier release of an old version of the UNIX source code. That earlier release could be enough to fry their case. Even though they are accusing IBM of raping their more recent versions, if the code in question is anywhere _near_ present in the old version, SCO is screwed.
Personally, I think SCO's case is going to fall... hard. If they had a real case, they would have shown the code long ago. Not just shown the code, but PROVED that they had it first and not the other way around. After all, Linux had many enterprise features before SCO's various *NIX flavors. Perhaps we should be sueing them for violation of the GPL?
-- S
The confirmation messages are sent to the Return-Path: header address. If you're using TMDA (or similar products) correctly, you will receive the user's confirmation request and be able to confirm delivery of your original message.
Click here for an explanation of the TMDA way.
-- Gun
I disagree. It's not too drastic. I work for an ISP, and we recently piloted a similar program using Tagged Message Delivery Agent. I must say that it works flawlessly with almost zero false negatives. We even have a web interface so that people can go and look into their pending queue to manually approve or reject messages. Unconfirmed messages are automatically deleted after a week. For the mailing list problems Mr. Minh mentions in the parent post, this has proved to work great. When one of our customers gets a bank statement, he or she can manually approve that email for delivery. The approval adds the bank's from address to the user's whitelist, and all subsequent emailed bank statements pass through without the need for confirmation.
Read the TMDA FAQ and you'll get answers to many questions about the process. In addition, it will explain to you how you can set up your list so that less than 10% of your legitimate senders never even see a confirmation message. It explains how to handle mailing lists as well.
This IS the current answer because it is a mechanism used for delivery once the mail server has receives the message. It does not require all participants use it, yet it performs beautifully for those who choose to use it. Until the SMTP protocol and related software are re-written (and everybody upgrades en masse), this is definitely the answer. I promote the solution anywhere and everywhere I have the chance.
-- Gun
BTW, it's just as costly, if not more, to have to rebuild your linux kernel, SSL, apache webserver, or samba installation when a bug is found there.
Naaa... just emerge sync; emerge -u world and head home for the evening.
Sounds good to me. I have a project lying on sf "abandoned" that needs to be deleted. As soon as my wife and I put together the initial specs, we both switched jobs and our available time to devote to the project went from around 10 hours a week to -1 hours per week. The administrators of projects need to have the ability to delete their projects. This functionality may have been added since I last checked, but thus far the only way I've seen to delete projects is to email sf.net and have the system administrator(s) delete it for you.
Depends. Do you own your own domain or are you an AOL/Yahoo!/MSN/Earthlink type customer?
See this post for more info.
I have the answer. Does that mean I get a portion of the supposed $10,000,000,000 people are going to spend on Spam control?
Anyone who wants to eliminate 99.99% of the spam from their inbox, just let me know. Stipulations are that you must either a) own your own domain and have control over the DNS and email administration of said domain or b) not mind switching to a new email address. I'll zap your spam in a jiffy.
I just attended a network security seminar at a small university in Virginia this past week. I manned the booth for my company, but between rush times I spent most of my time speaking with the people (sometimes competitors) from other booths. One of the engineers at another booth was kind enough to give me an RSA SecurID demo box with two key fobs and all the software I needed to set up a server.
Within an hour of arriving back at my hotel room, I had the software up and running (had to download the Win2K agent from the RSA website), and my login to my laptop was secured via SecurID. Once I arrived home last night, I set up the server on my home network, and now all of my workstations and server (Linux included!) are using RSA SecurID login.
You can run the server on NT/AIX/Solaris (probably more by now because I have an old kit), and there are agents out there for just about any operating system. In addition, you can have routers access the server as if it were a TACACS+ or RADIUS server.
Check the RSA website for more information. The part you'll care most about are the agents (client side of the equation), and I know for sure that there are agents available for Windows, Linux, and Solaris.
Good Luck!
If you're looking to pay through the nose for software licenses, take a look at Citrix. You can load balance servers for high application availability. It's stable and proven software, but it's also very expensive. There are Citrix ICA clients for most Operating Systems, thus allowing you to access your applications remotely from most platforms.
On the other hand, if you're looking for a more cost effective solution then just use VNC to access your workstation(s) remotely.
There are plenty of thin client solutions available, it's just a matter of making sure you pick one that suits your a) needs and b) budget.