While hardly comprehensive test tools, there are some nice load generation tools that have some pretty remarkably features for their price (free). Check out WebBench (www.webbench.com) which does a nice job of harnessing a ton of machines to generate as much load as you can dream up. Then there is WAST (Web Application Stress Tool) from Microsoft. WAST has some nice features as far as scriptability goes, you just need to be warm and fuzzy with WSH to do it. On the Unix side you can use things like http_load, however it doesn't offer nearly the tweakability that WebBench offers.
On the commercial side, check out the Spirent Caw box. I've used that a far amount and it does an excellent job at capturing data and generating a lot of load from a single system. Great for when rack space is at a premium and you want an appliance-like solution.
This will not be an uber-hit with a game -- it will be a hit with video messaging. This has the potential to be idiot proof enough for my mom to use which means the idea of my 5 year old niece sending grand-ma videos at anytime without having to know what a phone is, how it works, or worry about long distance charges, is absolutely fantastic. Sure, you can set this up with PCs today, but my impression of PC software at this time is that it is too complex and too expensive for a five year old and her grand-ma (who can't type) to use.
You're right about the varying levels of documentation. However, I disagree with your assertion that a good programmer cannot be a good writer. The best programmers I have ever worked with were all good writers.
Bottom line: if you can clearly articulate what it is you're saying, you can clearly articulate what it is you want your program to do, which in turn means you'll be able to write a clear and easy to follow program. Writing well has a lot more to do with thought process than it has to do with grammar. Think about it in terms of software engineering and programming -- you can teach a monkey to write code (and many monkeys do).
That said, it *is* difficult to write a lot while coding a lot. This has a lot more to do with focus on your job than it does your skillset.
The opinion of a bunch of programmers should not concern you in the least bit. The opinion of a bunch of hiring managers should!
If you're going to go for a MS and you're open to non-CS degrees, consider an MBA but don't go after a writing degree. If an MBA isn't your cup of tea, go for the MS in CS.
That said, definately work on your writing skills. This will open you up to a lot of opportunities outside of writing code including sales, marketing, management, and yes, tech writing. Of course, if you want to stick to the engineering side of the world, you'll get a lot more respect from both your peers and your management if you can effectively communicate your ideas. This means being a proficient writer as well as someone who can give a presentation.
Not comfortable with writing? You can start with some classes. I would recommend creative writing over english courses since you'll actually get a lot more practice and feedback in creative writing. If you go for the MS/CS, there is nothing stopping you from taking undergrad writing courses at the same time. Follow that up with taking on some writing projects such as some documentation for an open source package -- there are a lot of HOWTOs out there that could stand some time and attention. Not sure how you can improve them? Go back and read well-received books and try to understand what it is about them that made them so accessible. (e.g. the author took the time to explain the big picture and then followed up with a good example and explained all of the commands/parameters in detail.) Of course, don't forget that with an MS/CS, you'll need to write a masters thesis that can easily turn into a 80-100 page document. (My thesis was 128 pages!)
I've made the transition from code monkey to marketing monkey. I end up helping a lot of sales reps on calls because of my technical background and ability to "geek-meld" in one sentence and pitch "value propositions" in the next.
There are several key parts to the pitch:
o Give the other guy an out that makes him look good.
This means opening with "I might be missing something but," or "Would it contradict the big picture if we..." In each case you give the receiver of the idea a chance to explain what it is their doing and educate you.
o Read the crowd
A good DJ doesn't just play songs, he guides the crowd and builds energy. He spends a lot of time looking at facial expressions and watching how people dance -- what are they reacting to? What kicks the energy up a notch? What makes them roll their eyes, etc. You have to do the same with your audience. If they're being terse and not really responding, back off. They don't want to talk about your suggestion and pushing it is only going to irritate them. If you manage to make them stop and think about it, don't jump in too quickly. Let them ease into the idea. Don't forget to show the benefits to them in terms of how it'll make them look, etc.
o Be ready to drop it
This is crucial. Your idea may not fit in a bigger picture an established process, or you may be improving something that doesn't present a really good return. (e.g. optimizing the snot out of a loop that that takes 1 second to run, once an hour isn't nearly as useful as optimizing the loop that runs 1000 times a second) Of course, you may simply be simply be stepping on a toe and the person wants you to back off. Don't write off the possibility that the current idea is too far down the path to change (e.g. don't put someone in a tough spot because they just spent $500k on web caches when squid and some PCs would have sufficed -- the money is spent and you can only make people look bad)
o Don't repeat yourself and be ready to support the existing idea
If the idea was heard and rejected, don't keep going back in a huff. You'll only annoy and piss off everyone. Once you've done your pitch and it has been ignored/dropped/whatever, support the decision that was made. Your ideas will be better received in the future when your managers know that you'll still support the team.
For something that complex, no single tool will do it for you. That said, consider doing your documents in layers. Having a single document that includes all of the gory details of such a large network will be useless. Instead, do a document that describes the high level architecture, then open up each cloud into another document and describe the network topology there, then open up those clouds into documents that get into individual host level information. It is the only reliable way to grow the diagram as necessary and make it possible for others to understand what is going on at a glance.
If you can only get a sales rep, don't bother. Most are trained towards talking with decision maker types and focus on business value. You'll want a sales engineer or someone techier.
One good way to approach this is to invite local CTO's to come speak. Start by contacting the marketing group at a company -- they have the power to arrange for speaking engagements that the strong techs can speak at. Frame it as a way to get local students/engineers familiar with the company and for a chance to have the CTO to get a look at what recent grads are doing. Companies, during any market climate, are always looking for extraordinary talent and welcome opportunities to peek inside the local university. Note that if you do get someone with hiring power to show up, make it clear that unless okayed in advance, don't drop a 100 resumes on the person.
Another source to look at is the school's graduate program. Talk to the faculty about researchers that are comfortable with presenting and have some interesting research going on. You're bound to have a grad student or PhD candidate that would love to talk about what they do and you're certain to get a truly technical talk from someone who can answer real questions.
It really depends on the band, their needs, their own access to equipment, etc. Electronic artists, for example, can completely produce their own CD from each song to the final track layout without having to touch a studio. Many well known artists such as Fat Boy Slim are almost entirely done in their basements, etc. In those cases you're looking at about $20-$30k worth of gear from start to finish. DJ's have it even easier -- my setup, including the computer and legal (yes, I paid for it full price) software amounted to about $4000.
Artists that actually need a sound studio are in for paying a lot more because it takes a lot more people to actually make things happen, along with space, equipment, etc. Get into bigger acts and you're talking about a lot more expensive people too since "my cousin who did the high school play audio" isn't going to be the same guy who mixes down a Top 40 album.
Just to be fair to earthlink, while the tech was being dishonest they do have a good reason for blocking outbound port 25 connections: spam. Earthlink forces everyone to use their mail relay so that they can control the outflow of spam and minimize it to the best of their ability.
Linux Administration: A Beginners Guide by Steve Shah is really good. It was reviewed on Slashdot a while back and I even remember it being on the front page of linux.org for a while. When I checked on the Amazon reviews, they were almost all good.
My experience with it is that it is very easy to read and quite complete. The thing I liked most about it was that the author didn't assume I was an idiot and wanted to use GUI tools -- he actually assumes worst case scenarios where all you have access to is the CLI and you need to be able to sysadmin work that way. Something I wish more books would do.
Another thing I really liked was that the author knew that his book was not the end-all-be-all of sysadmin books and gave references to other books as appropriate. I ended up picking up a lot of his recommended texts (TCP/IP Illus. Vol. 1 being my new favorite.)
The coverage of security is good. It isn't a list of "do this and you are secure", but rather a lot of good techniques for keeping your system clean like watching for what ports are being listened to and using lsof and netstat for reporting. He also reminds readers to check for upgrades on software frequently.
Anyway, I recommend it to folks who ask me about Linux books.
Not to mention that if the economy "isn't ready to welcome me," you should seriously look at why that is the case. It's going to be a long time before we see another boom where anyone with a pulse can find work. If you need to refine your skills, consider doing that now while you have the freedom to do so in academia before you find yourself trying to do it at the office and not getting very far...
First off, you are being responsible for running up2date regularly.
HOWEVER...
When someone puts a server on the Internet, they have a responsibility to secure it. The fact that they play Quake on their "desktop" doesn't change the fact that they're running a server application.
If I'm going to get on my dad's case about visiting windowsupdate.microsoft.com once a week, you can bet I'm going to get on a server owner's case about not subscribing to the appropriate vendor lists for security updates. Taking on the responsibility for running a server (however small or seemingly insignificant) includes the responsibility to keep it up to date.
Oh, and keep in mind that this particular exploit is taking advantage of a problem found weeks ago. Vendor patches have been out for a while.
Since you didn't specify that the smart people have to be geeks, I thought I'd share Linux Administration: A Beginners Guide. It's a good sysadmin book for people who aren't Dummies and is especially good for Windows sysadmins who want to move over to The Force. It actually gives the dirt on effective use of the CLI, compiling your own servers, and other useful sysadmin tasks. What really impressed me was the fact that even though the book was published in early 2001 (January I think), it is still easy to apply the knowledge to current versions of everything since the author actually bothers to explain the underlying protocols and build processes that have applied since./configure has been around.
And how many Win98 servers do you find in the wild? Not many... There are still a small handful of NT4 boxen, but most admins moved to at least SP3 if not SP6 by 1998. Windows 2000 and XP don't have the ISN problem. MacOS 8 and MacOS 9 were not meant to be server OS's and were never sold as such.
What's funny? All said and done, very few people are going to try an ISN attack when there are so many easier app level attacks against servers already available.
Not so fast... There are a lot of older computers that schools have no use for. Older PC's are especially of finite use because they don't run the applications the students need them to run. Most academic apps need Windows and even those apps that can be Linux driven need something quicker than a Pentium-II. Could anyone imagine running a modern window manager (e.g. KDE or GNOME) and OpenOffice on a P2 with 64 megabytes of memory? It's just not going to work...
If you really want to help out your neighborhood school, donate money. Money allows schools to address what their real needs are because they actually see the pain points. For all we know, a school may have just received an incredible budget to buy new computers while being denied a budget for books.
The web cache is exhibiting correct behavior. When a forward proxy cache (transparent or not) gets a request in the form of GET http://www.site.com/ http/1.1, it will use the www.site.com address instead regardless of what original dns name you went to (www.google.com in your example). In the transparent case where the GET statement looks more like GET/content.html http/1.1, it will use the original destination address.
In other words, it's your client that's broken. See RFC 2616 for details.
The unfortunate truth is that more often than not, sites simply don't set their cache controls correctly. They forget that caches don't exist just on the server side but that they exist on the client side as well. Section 13 of RFC 2616 explains how they work in great detail and it really should be mandatory reading for any site administrator.
If you're still looking for more information on web caching, check out Content Delivery Networks by Scot Hull. It was just released and is available on Amazon. There is an enlightening section on web caching that should clearly explain why what you're seeing is in fact correct behavior.
TerminatorX is a great tool, but this is so much more powerful. The ability to quickly queue to an arbitrary point in the song, back-cue, and of course all the fun things you can make your decks do with the start/stop buttons, backspins, and even just turning the decks off for that winding down sound. For scratch DJ's, the interface is a lot more intuitive than TerminatorX because the little things that change how the record spins (slipmats, the fact that the record is really spinning, torque, etc.) is something you can't reproduce with a mouse wheel and a busted turntable.
Best of all, this integrates into an existing setup. I can mix real records with MP3's in real time.
The most significant flaw I can see with this (and it may very well not be an issue) is that of what I hear when cueing. My mixer has a nice set of options for the cue headphones and anything new I get would have to either match it or beat it.
The biggest advantage TerminatorX has over this is going to be price. I already have/use TerminatorX and spent my $400 on a new Gina24 sound card from EchoAudio. (Mmmmm... Tasty...) But I'd be willing to bet that this will be the next big thing in DJ technology. God Willing, it'll stop the featuritis that a lot of the CD vendors have...
I used to work with a fellow who was in Parker Bros. during the Atari heyday and even into the PC gaming arena for a short while. What he says makes a lot of sense and it does lead me to believe it to be true...
For each new game that came out, four were actually made. The reason for this was that it cost $250,000 to produce a game and about $3-4M to actually market and sell the damn thing. Thus, it was crucial that they picked winners. Looking at the type of games that Parker Bros. was coming out with, you can easily see how these games were not destined to be classics... The loss of developing 3 losers for every winner was covered in the returns made on the one game that was released. While it may still sound like a weird way to do it, the return on investment proved it to be the correct thing to do. They were able to release new games on a regular basis without worrying about a single game bogging down their cycle.
Note for those who dispute development costs: The ratio of marketing costs to development costs still holds true for a lot of development that happens today for a variety of different products. A dozen cubicals of programmers is a lot cheaper than TV spots, magazine ads, distribution, packaging, art work, product placement in stores, etc...
So we can see how it was entirely possible for a LOTR game to not be selected because by comparison to the other games coming out at the time, it sucked. How could such a classic suck? As someone mentioned earlier... How exactly are you going to get a 1,000 page book filled with rich imagery into a 4k cart running on a 2600? The people who would buy such a game (LOTR fans) would have held it up to a higher expectation and been disapointed. The rest of the world would have said "Lord of the who?" and ignored it. And *click*... There goes $4M down the drain...
The start of every call from them (and I used to get a lot from them for some reason) was "How are you today?" I started answering "Lousy." This led to "Is now a good time to talk?" Answer: "No." After two calls like this, they stopped calling.
People who take the time who make it out to a LUG are generally the types who are going to be interesting. There have to be at least a handful of people who are doing something that is interesting enough to warrant a 30 minute talk on the subject. What makes these types of talks esp. interesting is that because everyone in the audience has context about the person, the area, etc. they can ask very specific questions that couldn't otherwise be asked.
Another thing to consider is getting locals who are doing interesting things. They don't all have to be OSS related -- just interesting and related to technology in some way. Local universities are a gold mine of people doing interesting research who would love to talk about it for the cost of a dinner.
Look back at the history of computing and you'll see that this was how a lot of user groups started. Back then, there weren't "big names that everyone heard of" to make a draw. Rather, there were group members that went up to the front and gave a 10-15 minute chat on their latest hack. They knew their audience, the audience knew them, and the level of technical detail appealed to everyone.
Can no one read? Go back. Look again. It says it supports any LPD compliant printer! JetDirect always has supported LPD out of the box! Geez.
(If the obvious hasn't struck you yet, Linux uses LPD to print.)
Read Peter Salus's work on the history of Unix. His work is (in my opinion) the style of history we need.
There are also a number of other authors who are recording the happenings and putting them into books. Stuff like Fire in the Valley, Nerds and Nerds 2.01 come to mind.
For an especially great book on computer history, check out "Computer: A History of the Information machine" by Martin Campbell-Kelly and William Aspray (1997)
The point here is that: (1) There are already a number of people doing it. (2) Look at what's there and seek out holes in coverage. (3) Please, please, please -- work on your writing skills. A so-so history book that is well written is much better than a good history book that is poorly written.
Having taught lab sections before, I can tell you that nothing gets more interest from students than games. (Although network security comes in a close second... but that may be too abstract for most students.) The purpose of games are clear, the concepts are easy to grasp, there is some kind of visual feedback, and in the end the students have something that they can easily show off to others. The tough part is keeping the students from getting in over their heads. I'd suggest pushing for D&D type games since they don't require any kind of high performance graphics (although graphics can be part of it). You can also do Myst type things as well (puzzles).
By breaking the students up into teams, you can get them thinking in an OOP-like way by having each team member spec out their module and API, thus clearly defining how they work with other members of the team while drawing boundaries on whose doing what. (This also makes grading easier when accusations occur of some students not carrying their weight.) You can also encourage them to use other tools to help them make the game more interesting. e.g. sound editors for special effects, graphics editors for visuals, etc.
Slashdot Mirror
While hardly comprehensive test tools, there are some nice load generation tools that have some pretty remarkably features for their price (free). Check out WebBench (www.webbench.com) which does a nice job of harnessing a ton of machines to generate as much load as you can dream up. Then there is WAST (Web Application Stress Tool) from Microsoft. WAST has some nice features as far as scriptability goes, you just need to be warm and fuzzy with WSH to do it. On the Unix side you can use things like http_load, however it doesn't offer nearly the tweakability that WebBench offers.
On the commercial side, check out the Spirent Caw box. I've used that a far amount and it does an excellent job at capturing data and generating a lot of load from a single system. Great for when rack space is at a premium and you want an appliance-like solution.
This will not be an uber-hit with a game -- it will be a hit with video messaging. This has the potential to be idiot proof enough for my mom to use which means the idea of my 5 year old niece sending grand-ma videos at anytime without having to know what a phone is, how it works, or worry about long distance charges, is absolutely fantastic. Sure, you can set this up with PCs today, but my impression of PC software at this time is that it is too complex and too expensive for a five year old and her grand-ma (who can't type) to use.
You're right about the varying levels of documentation. However, I disagree with your assertion that a good programmer cannot be a good writer. The best programmers I have ever worked with were all good writers.
Bottom line: if you can clearly articulate what it is you're saying, you can clearly articulate what it is you want your program to do, which in turn means you'll be able to write a clear and easy to follow program. Writing well has a lot more to do with thought process than it has to do with grammar. Think about it in terms of software engineering and programming -- you can teach a monkey to write code (and many monkeys do).
That said, it *is* difficult to write a lot while coding a lot. This has a lot more to do with focus on your job than it does your skillset.
The opinion of a bunch of programmers should not concern you in the least bit. The opinion of a bunch of hiring managers should!
If you're going to go for a MS and you're open to non-CS degrees, consider an MBA but don't go after a writing degree. If an MBA isn't your cup of tea, go for the MS in CS.
That said, definately work on your writing skills. This will open you up to a lot of opportunities outside of writing code including sales, marketing, management, and yes, tech writing. Of course, if you want to stick to the engineering side of the world, you'll get a lot more respect from both your peers and your management if you can effectively communicate your ideas. This means being a proficient writer as well as someone who can give a presentation.
Not comfortable with writing? You can start with some classes. I would recommend creative writing over english courses since you'll actually get a lot more practice and feedback in creative writing. If you go for the MS/CS, there is nothing stopping you from taking undergrad writing courses at the same time. Follow that up with taking on some writing projects such as some documentation for an open source package -- there are a lot of HOWTOs out there that could stand some time and attention. Not sure how you can improve them? Go back and read well-received books and try to understand what it is about them that made them so accessible. (e.g. the author took the time to explain the big picture and then followed up with a good example and explained all of the commands/parameters in detail.) Of course, don't forget that with an MS/CS, you'll need to write a masters thesis that can easily turn into a 80-100 page document. (My thesis was 128 pages!)
Best of luck...
Exactly.
I've made the transition from code monkey to marketing monkey. I end up helping a lot of sales reps on calls because of my technical background and ability to "geek-meld" in one sentence and pitch "value propositions" in the next.
There are several key parts to the pitch:
o Give the other guy an out that makes him look good.
This means opening with "I might be missing something but," or "Would it contradict the big picture if we..." In each case you give the receiver of the idea a chance to explain what it is their doing and educate you.
o Read the crowd
A good DJ doesn't just play songs, he guides the crowd and builds energy. He spends a lot of time looking at facial expressions and watching how people dance -- what are they reacting to? What kicks the energy up a notch? What makes them roll their eyes, etc. You have to do the same with your audience. If they're being terse and not really responding, back off. They don't want to talk about your suggestion and pushing it is only going to irritate them. If you manage to make them stop and think about it, don't jump in too quickly. Let them ease into the idea. Don't forget to show the benefits to them in terms of how it'll make them look, etc.
o Be ready to drop it
This is crucial. Your idea may not fit in a bigger picture an established process, or you may be improving something that doesn't present a really good return. (e.g. optimizing the snot out of a loop that that takes 1 second to run, once an hour isn't nearly as useful as optimizing the loop that runs 1000 times a second) Of course, you may simply be simply be stepping on a toe and the person wants you to back off. Don't write off the possibility that the current idea is too far down the path to change (e.g. don't put someone in a tough spot because they just spent $500k on web caches when squid and some PCs would have sufficed -- the money is spent and you can only make people look bad)
o Don't repeat yourself and be ready to support the existing idea
If the idea was heard and rejected, don't keep going back in a huff. You'll only annoy and piss off everyone. Once you've done your pitch and it has been ignored/dropped/whatever, support the decision that was made. Your ideas will be better received in the future when your managers know that you'll still support the team.
Best of luck...
For something that complex, no single tool will do it for you. That said, consider doing your documents in layers. Having a single document that includes all of the gory details of such a large network will be useless. Instead, do a document that describes the high level architecture, then open up each cloud into another document and describe the network topology there, then open up those clouds into documents that get into individual host level information. It is the only reliable way to grow the diagram as necessary and make it possible for others to understand what is going on at a glance.
If you can only get a sales rep, don't bother. Most are trained towards talking with decision maker types and focus on business value. You'll want a sales engineer or someone techier.
One good way to approach this is to invite local CTO's to come speak. Start by contacting the marketing group at a company -- they have the power to arrange for speaking engagements that the strong techs can speak at. Frame it as a way to get local students/engineers familiar with the company and for a chance to have the CTO to get a look at what recent grads are doing. Companies, during any market climate, are always looking for extraordinary talent and welcome opportunities to peek inside the local university. Note that if you do get someone with hiring power to show up, make it clear that unless okayed in advance, don't drop a 100 resumes on the person.
Another source to look at is the school's graduate program. Talk to the faculty about researchers that are comfortable with presenting and have some interesting research going on. You're bound to have a grad student or PhD candidate that would love to talk about what they do and you're certain to get a truly technical talk from someone who can answer real questions.
It really depends on the band, their needs, their own access to equipment, etc. Electronic artists, for example, can completely produce their own CD from each song to the final track layout without having to touch a studio. Many well known artists such as Fat Boy Slim are almost entirely done in their basements, etc. In those cases you're looking at about $20-$30k worth of gear from start to finish. DJ's have it even easier -- my setup, including the computer and legal (yes, I paid for it full price) software amounted to about $4000.
Artists that actually need a sound studio are in for paying a lot more because it takes a lot more people to actually make things happen, along with space, equipment, etc. Get into bigger acts and you're talking about a lot more expensive people too since "my cousin who did the high school play audio" isn't going to be the same guy who mixes down a Top 40 album.
Just to be fair to earthlink, while the tech was being dishonest they do have a good reason for blocking outbound port 25 connections: spam. Earthlink forces everyone to use their mail relay so that they can control the outflow of spam and minimize it to the best of their ability.
Linux Administration: A Beginners Guide by Steve Shah is really good. It was reviewed on Slashdot a while back and I even remember it being on the front page of linux.org for a while. When I checked on the Amazon reviews, they were almost all good.
My experience with it is that it is very easy to read and quite complete. The thing I liked most about it was that the author didn't assume I was an idiot and wanted to use GUI tools -- he actually assumes worst case scenarios where all you have access to is the CLI and you need to be able to sysadmin work that way. Something I wish more books would do.
Another thing I really liked was that the author knew that his book was not the end-all-be-all of sysadmin books and gave references to other books as appropriate. I ended up picking up a lot of his recommended texts (TCP/IP Illus. Vol. 1 being my new favorite.)
The coverage of security is good. It isn't a list of "do this and you are secure", but rather a lot of good techniques for keeping your system clean like watching for what ports are being listened to and using lsof and netstat for reporting. He also reminds readers to check for upgrades on software frequently.
Anyway, I recommend it to folks who ask me about Linux books.
Not to mention that if the economy "isn't ready to welcome me," you should seriously look at why that is the case. It's going to be a long time before we see another boom where anyone with a pulse can find work. If you need to refine your skills, consider doing that now while you have the freedom to do so in academia before you find yourself trying to do it at the office and not getting very far...
First off, you are being responsible for running up2date regularly.
HOWEVER...
When someone puts a server on the Internet, they have a responsibility to secure it. The fact that they play Quake on their "desktop" doesn't change the fact that they're running a server application.
If I'm going to get on my dad's case about visiting windowsupdate.microsoft.com once a week, you can bet I'm going to get on a server owner's case about not subscribing to the appropriate vendor lists for security updates. Taking on the responsibility for running a server (however small or seemingly insignificant) includes the responsibility to keep it up to date.
Oh, and keep in mind that this particular exploit is taking advantage of a problem found weeks ago. Vendor patches have been out for a while.
Since you didn't specify that the smart people have to be geeks, I thought I'd share Linux Administration: A Beginners Guide. It's a good sysadmin book for people who aren't Dummies and is especially good for Windows sysadmins who want to move over to The Force. It actually gives the dirt on effective use of the CLI, compiling your own servers, and other useful sysadmin tasks. What really impressed me was the fact that even though the book was published in early 2001 (January I think), it is still easy to apply the knowledge to current versions of everything since the author actually bothers to explain the underlying protocols and build processes that have applied since ./configure has been around.
Anyway, highly recommended.
"So, is your mother really proud of you? I mean, having chosen a career in telemarketing and all."
And how many Win98 servers do you find in the wild? Not many... There are still a small handful of NT4 boxen, but most admins moved to at least SP3 if not SP6 by 1998. Windows 2000 and XP don't have the ISN problem. MacOS 8 and MacOS 9 were not meant to be server OS's and were never sold as such.
What's funny? All said and done, very few people are going to try an ISN attack when there are so many easier app level attacks against servers already available.
Not so fast... There are a lot of older computers that schools have no use for. Older PC's are especially of finite use because they don't run the applications the students need them to run. Most academic apps need Windows and even those apps that can be Linux driven need something quicker than a Pentium-II. Could anyone imagine running a modern window manager (e.g. KDE or GNOME) and OpenOffice on a P2 with 64 megabytes of memory? It's just not going to work...
If you really want to help out your neighborhood school, donate money. Money allows schools to address what their real needs are because they actually see the pain points. For all we know, a school may have just received an incredible budget to buy new computers while being denied a budget for books.
The web cache is exhibiting correct behavior. When a forward proxy cache (transparent or not) gets a request in the form of GET http://www.site.com/ http/1.1, it will use the www.site.com address instead regardless of what original dns name you went to (www.google.com in your example). In the transparent case where the GET statement looks more like GET /content.html http/1.1, it will use the original destination address.
In other words, it's your client that's broken. See RFC 2616 for details.
The unfortunate truth is that more often than not, sites simply don't set their cache controls correctly. They forget that caches don't exist just on the server side but that they exist on the client side as well. Section 13 of RFC 2616 explains how they work in great detail and it really should be mandatory reading for any site administrator.
If you're still looking for more information on web caching, check out Content Delivery Networks by Scot Hull. It was just released and is available on Amazon. There is an enlightening section on web caching that should clearly explain why what you're seeing is in fact correct behavior.
You can become a US citizen by applying for it. All you need to do is have a green card and live in the country for five years.
TerminatorX is a great tool, but this is so much more powerful. The ability to quickly queue to an arbitrary point in the song, back-cue, and of course all the fun things you can make your decks do with the start/stop buttons, backspins, and even just turning the decks off for that winding down sound. For scratch DJ's, the interface is a lot more intuitive than TerminatorX because the little things that change how the record spins (slipmats, the fact that the record is really spinning, torque, etc.) is something you can't reproduce with a mouse wheel and a busted turntable.
Best of all, this integrates into an existing setup. I can mix real records with MP3's in real time.
The most significant flaw I can see with this (and it may very well not be an issue) is that of what I hear when cueing. My mixer has a nice set of options for the cue headphones and anything new I get would have to either match it or beat it.
The biggest advantage TerminatorX has over this is going to be price. I already have/use TerminatorX and spent my $400 on a new Gina24 sound card from EchoAudio. (Mmmmm... Tasty...) But I'd be willing to bet that this will be the next big thing in DJ technology. God Willing, it'll stop the featuritis that a lot of the CD vendors have...
I used to work with a fellow who was in Parker Bros. during the Atari heyday and even into the PC gaming arena for a short while. What he says makes a lot of sense and it does lead me to believe it to be true...
For each new game that came out, four were actually made. The reason for this was that it cost $250,000 to produce a game and about $3-4M to actually market and sell the damn thing. Thus, it was crucial that they picked winners. Looking at the type of games that Parker Bros. was coming out with, you can easily see how these games were not destined to be classics... The loss of developing 3 losers for every winner was covered in the returns made on the one game that was released. While it may still sound like a weird way to do it, the return on investment proved it to be the correct thing to do. They were able to release new games on a regular basis without worrying about a single game bogging down their cycle.
Note for those who dispute development costs: The ratio of marketing costs to development costs still holds true for a lot of development that happens today for a variety of different products. A dozen cubicals of programmers is a lot cheaper than TV spots, magazine ads, distribution, packaging, art work, product placement in stores, etc...
So we can see how it was entirely possible for a LOTR game to not be selected because by comparison to the other games coming out at the time, it sucked. How could such a classic suck? As someone mentioned earlier... How exactly are you going to get a 1,000 page book filled with rich imagery into a 4k cart running on a 2600? The people who would buy such a game (LOTR fans) would have held it up to a higher expectation and been disapointed. The rest of the world would have said "Lord of the who?" and ignored it. And *click*... There goes $4M down the drain...
The start of every call from them (and I used to get a lot from them for some reason) was "How are you today?" I started answering "Lousy." This led to "Is now a good time to talk?" Answer: "No." After two calls like this, they stopped calling.
People who take the time who make it out to a LUG are generally the types who are going to be interesting. There have to be at least a handful of people who are doing something that is interesting enough to warrant a 30 minute talk on the subject. What makes these types of talks esp. interesting is that because everyone in the audience has context about the person, the area, etc. they can ask very specific questions that couldn't otherwise be asked.
Another thing to consider is getting locals who are doing interesting things. They don't all have to be OSS related -- just interesting and related to technology in some way. Local universities are a gold mine of people doing interesting research who would love to talk about it for the cost of a dinner.
Look back at the history of computing and you'll see that this was how a lot of user groups started. Back then, there weren't "big names that everyone heard of" to make a draw. Rather, there were group members that went up to the front and gave a 10-15 minute chat on their latest hack. They knew their audience, the audience knew them, and the level of technical detail appealed to everyone.
Can no one read? Go back. Look again. It says it supports any LPD compliant printer! JetDirect always has supported LPD out of the box! Geez.
(If the obvious hasn't struck you yet, Linux uses LPD to print.)
Read Peter Salus's work on the history of Unix. His work is (in my opinion) the style of history we need.
There are also a number of other authors who are recording the happenings and putting them into books. Stuff like Fire in the Valley, Nerds and Nerds 2.01 come to mind.
For an especially great book on computer history, check out "Computer: A History of the Information machine" by Martin Campbell-Kelly and William Aspray (1997)
The point here is that: (1) There are already a number of people doing it. (2) Look at what's there and seek out holes in coverage. (3) Please, please, please -- work on your writing skills. A so-so history book that is well written is much better than a good history book that is poorly written.
Having taught lab sections before, I can tell you that nothing gets more interest from students than games. (Although network security comes in a close second... but that may be too abstract for most students.) The purpose of games are clear, the concepts are easy to grasp, there is some kind of visual feedback, and in the end the students have something that they can easily show off to others. The tough part is keeping the students from getting in over their heads. I'd suggest pushing for D&D type games since they don't require any kind of high performance graphics (although graphics can be part of it). You can also do Myst type things as well (puzzles).
By breaking the students up into teams, you can get them thinking in an OOP-like way by having each team member spec out their module and API, thus clearly defining how they work with other members of the team while drawing boundaries on whose doing what. (This also makes grading easier when accusations occur of some students not carrying their weight.) You can also encourage them to use other tools to help them make the game more interesting. e.g. sound editors for special effects, graphics editors for visuals, etc.
-Steve