> I'm curious as to whether 3rd party software firewalls for windows are > impacted by this or not.
If the firewall is configured to allow Remote Desktop Connection traffic through, e.g., because it is used to administer headless servers, a very common practice for outfits that have Microsoft servers, then which firewall you use is not the real issue.
> If not, then this hole (and others which are likely to follow) would provide > a good justification for purchasing and deploying a 3rd party solution.
Along similar lines, if you have a different remote administration facility, such as PC Anywhere or VNC, you could use that in the interim and configure your firewalls (hardware, software, all of them) to discard RDC traffic until you get the patch deployed. (And if next month there's a VNC vulnerability, you could do the reverse, discard VNC traffic and use Remote Desktop instead, until you get VNC patched. Seems to me like it's worth having more than one solution for remote administration, for precisely this reason.)
> Isn't a firewall supposed to block incoming connections unless > specifically allowed?
That is the way you set up your firewall if you are following security best practices, yes. But not all firewalls are configured that way (some are configured so that they only block known types of problem traffic), and software firewalls in any case can still be vulnerable even if they are theoretically set up correctly, if there is a flaw in the OS (although that doesn not appear to be the issue in this case).
As far as the specific instance in this story, the hole is in Remote Desktop, something many firewalls are likely to be configured to let through, because it's frequently used to administer things that are behind firewalls. The closest equivalent for non-Microsoft systems is VNC, but it's a bigger deal than that, because Windows doesn't include an equivalent for ssh, so Remote Desktop typically gets used for that too. Our firewall at work forwards in Remote Desktop traffic to one particularly mission-critical system, but fortunately it's set up so that it only lets the traffic in from one specific source IP address, so I am not panicked over this, although I will nonetheless be installing the patch when I get half a chance. Things like this *need* to be plastered all over the major tech news services like slashdot, so that people in this sort of situation are aware of the issue. Some network administrators might even be in a situation where the best thing to do is to temporarily change the firewall ruleset to discard the type of traffic in question, until they can get the patch deployed.
> all it takes is one worm on someone's laptop to bypass the corporate firewall
That's why you don't just firewall the borders; you firewall each small LAN segment (e.g., each suite of rooms) from the rest of the world, allowing through to other subnets only what is needed. This doesn't prevent any individual computer from being compromised, but it reduces the impact so that the whole network doesn't go down (assuming that the compromised system isn't a core mission-critical server or firewall; those hopefully are not running on Microsoft systems or at least are much better protected than the desktops, and, above all else, they're not sitting on the desks of ordinary users with no security sense or training, but rather locked up in the back of the IT department; ideally you can't get to them (physically) without ducking under cables and squeezing through a narrow space between a workbench and a cluttered table, or some similar management-deterring arrangement.
> And running Apache as root is a Really Bad Idea (tm).
Anything that handles untrusted data (e.g., connections from the internet, or email) should NOT be running as root and ABSOLUTELY should not have write permissions outside its own home directory. Preferably it should be chrooted.
Apache has for years supported running as a user with limited privileges; most distros give it its own user account and its own group, so it definitely should not be running as root. (Yes, you launch it as root, but it changes users when it forks, before it starts looking at the data coming in on the socket.) Configuring it to run as root is an action the user must have taken deliberately -- and yes, that was a Bad Idea.
Last I checked (which admittedly was several years ago now), sendmail still *required* to be run as root, so that it could write files in various places where it has no business writing files, such as within other users' home directories. Bad programmer, no cookie.
> It has been labelled 'The Worst Movie Ever' by the Golden Turkey Awards
Clearly, the Golden Turkey Awards have never reviewed The Creeping Terror, the movie with acting that makes William "Excessive Dramatic Pause" Shattner seem stunningly on-the-ball by comparison, Jim Carey sophisticated, and Home Shopping Club announcers believable; special effects that would boggle your mind with their badness if you had to watch an eighth-grade class drama project that used them; camerawork that makes the Blair Witch Project look both conventional and brilliant; a plot more simplistic than Scooby Doo, more hackneyed than I Love Lucy, and yet more convoluted than The Fifth Element; shallower and worse character development than an Olson Twins movie, combining more stereotypes than the Smurfs with more smarmy preachyness than the Brady Bunch; writing so bad, SNL skit-writers would roll over in their graves; scenery that combines humdrum with unrealistic; lighting that manages to be too light to be dramatic and too dark to clearly show all the action, sometimes in the same scene; a sound track that would make Hanna Barbara cringe; a more transparently non-existent budget than anything ever done by Monty Python; all the humor and hilarity of televised professional bowling tournaments, combined with all the deep emotion of RFC 2616; and more. If there is anything else in the history of B-movie cinematography that even *approaches* the fantastically execrable, horrifically abominable, catastrophically horrendous piece of flotsam that is The Creeping Terror, I am sure I would not believe it even if I were to see it. I would be *deeply* surprised to discover another movie bad enough that it would deserve to be called "much better than The Creeping Terror"; any other B-movie I have seen would be insulted by such a comparison. If they made C-movies, D-movies, and F-movies, The Creeping Terror would make them *all* look like blockbusters. The *ONLY* thing I can say in its favor is that the sequel they tried to leave it open for was, thankfully, apparently never made.
You need
Firesomething.
Right now, as it happens, I'm browsing in
Mozilla Waterdingo. (The choices for the
brand, modifier, and noun are all fully
customizable, of course. At one point I
had made all the modifiers things like
Battle and Fear and Death and whatnot, and
the nouns were various weapons, so I got
results like Mozilla TerrorAxe and Netscape
ConquestDaggar; a couple of re-installs
later I'm currently just using the defaults.)
> Previously, it was necessary to use a third party stack to > access the Internet to use the Web and Gopher.
I know that was true in Windows 3.1 and 3.11 for Workgroups. (The one most folks used was made by Trumpet.) I do not know what the situation was in the first release of NT.
> It's something that I would like to find an authoritative reference for.
As far as what actually shipped, I still have the Win95 OSR2 CD that came with my January-1998 PC, but I don't need to check, because I'm quite certain that when I installed the network card I had to manually go into the setup (right click on Network Neighborhood, choose Properties) and hit the Add button, choose Protocol, select Microsoft under vendor, and choose TCP/IP. They also had "IPX/SPX Compatible Protocol" in there (apparently they were afraid of trademarks just calling it IPX/SPX) and at least one other thing, I forget what. My memory of this is quite clear because I re-installed Windows a couple of times and had to redo it. This is OSR2, but I have many times seen lists of the differences between Win 95 A and OSR2, and this has never been on any of the lists, so I imagine it probably was not changed. (Things I know about that were changed: added FAT32, with accompanying changes in format and fdisk, as well as of course the filesystem itself, added half-baked USB drivers that never worked with any actual USB hardware, added several promotional icons on the desktop and in the start menu, fixed a couple of minor bugs. FAT32 was the only thing to get excited about.)
But you were probably wanting documentation on Microsoft's internal decision process? There probably never was any, officially, outside of Microsoft. Just rumours, probably. That's how it usually is.
What we do know, though, is what Microsoft was encouraging people to use. As I said, file and print sharing by default used NetBEUI. You could bind it to IPX/SPX or TCP/IP, but the default was to not bind it to those protocols. Additionally, if you read the press releases and documentation and stuff Microsoft was putting out at the time, it was all about their NT networking stuff, WINS in the role that DNS fills today, and so on. Then circa 1999, when they were starting to get serious about NT5/Win2000, they suddenly started talking about using TCP/IP "natively". That sounds a little too technical, so when Win2K actually shipped their marketing department rephrased it "Built for the Internet". (My thoughts at the time were along the lines of, "Yeah, Windows 2000 may be built for the internet, but the internet was built for Unix.")
The thing is, Windows networking is still very much its own proprietary setup, *very* different from the way the internet is set up, and it's *very* confusing for someone with prior experience mainly with TCP/IP and the internet. They use some of the same words, but they use them in different ways. For instance, a "domain" is not anything to do with DNS, but an authentication mechanism. However, when you "log on to" a domain, you are not then working on the domain controller server; you're still working on your local system, and your profile is stored on your local system, and everything is done on your local system. (I'm confused about whether even the authentication is done on the domain controller, since I appear to be able to log in to a domain even when the domain controller is physically powered down. This worries me, since I am concerned that information (such as a hash function result) about the password needed to log on as domain administrator may be distributed to the individual systems on the domain. I wish I knew how to find that out for sure, because if it's true it means one compromised workstation has quite serious implications for the PDC and the whole network.) If you want to actually log on (in the Unix/internet/TCP/IP sense) to the PDC, you use Remote Desktop or some other solution. It's all very confusing for someone who mostly knows internet stuff and standard protocols. If Microsoft ever develops an OS that *really* uses the standard internet protocols natively, ssl and so on, I think I'd get pretty excited.
> While Lynx is cool and all I think it was because of the graphic > capacity of the web that made it grow and killed of gopher.
Having graphics embedded in pages (as opposed to just at the end of a link, like gopher could do) may have accelerated it, but it would have happened anyway. The real genius of the web is that any part of any page can link to anything else on the internet (not just on the web); this made the web useful for creating cross-site topical indeces of, among other things, Gopher. (Yes, people used to create web-based indices that included Gopher links. Really. Granted, ftp links were much more common; I think about a third of Yahoo consisted of ftp links at one time. They linked to usenet also, and telnet sites, and TN3270, and other things.) The other way around wouldn't work: a gopher site couldn't serve as an index of other gopher sites, ftp, and the web. Then CGI-based search tools came along and made Archie look kludgy and painful by comparison, and the rest is history.
> Didn't Win95 almost ship without a TCP/IP stack?
No, but it shipped with it turned off by default. You had to go into the Network Neighborhood properties and Add Protocol and all that jazz to get it turned on. Also, SMB/CIFS didn't bind to TCP/IP by default, only to NetBEUI.
Basically, TCP/IP had the same level of support as IPX/SPX.
In an office filled with coworkers incessantly chitter-chattering among themselves about nothing of any consequence, it's sometimes a wonder I get anything done at all. I estimate about a third of my "work" time is spent losing my train of thought due to the incessant meaningless chatter and then attempting to regain it.
Losing my train of thought due to the ringing phone and then attempting to regain it afterwards also accounts for a significant portion of my time, but there's nothing my employer could do about that; we have to answer the phone, of course.
NOTHING the schools can do will solve the problem of deadbeat parents who don't look at their kids' homework, don't discuss with them what they're studying, don't teach them anything at home either, and, in general, don't bother to raise their kids. Sure, a small handful of kids, maybe 1%, are so self-motivated that they will do well even though their parents don't give a lick. But most kids, if their parents don't care, will flunk out if you let them or, if you inflate their grades so that they can't flunk, coast.
You want to fix the schools? Fix the *people*, fix *society*, fix our *culture*, and the schools will get better.
It's called viper-mode, and Emacs has come with it included for years. (If you don't understand why Emacs has to come with a vi clone included, then you clearly don't understand Emacs.)
...not ship the books out until, you know, they're ready to be released?
Nah, that would be too *straightforward*, and it might actually *work*, and above all it wouldn't give them anyone to *sue*, so obviously they couldn't use that plan, now could they? Sheesh.
OTOH, while this particular quirk of the book publishing and distribution system it bizarre and unnecessary, it's not DRM in any normal sense of that term. All they're trying to control is the initial distribution until the release date. The book is still just an ordinary book once you do get your hands on it.
For your Dvorak keyboard, get one that has a noticeably different feel from the standard cheapo QWERTY keyboards you're likely to run into. Something with buckling-spring feedback is best. An IBM Model M will do in a pinch, or you can go all out and get an Avant Stellar, if you have the budget for that. (Yes, it costs a lot. It's worth it, though. Among other things, a keyboard like that will let you customize your layout in ways that you otherwise can't easily do -- e.g., you can move the shift and ctrl keys around, which if done right can relieve your pinkies of the need to be hyperextended frequently, something Dvorak won't do.)
Anyway, even a cheap used IBM Model M that you can pick up on ebay for practically nothing will have a quite different feel from today's cheapo squishy compact membrane keyboards that most PCs come with out of the box (and which, therefore, is what most people use).
So when you sit down to type at one, your fingers will feel the difference. At first you will find yourself using the wrong layout sometimes and mistyping until you stop and think, but after a few weeks of switching back and forth on a daily basis, you will find that your fingers automatically "know" where to go based on how the keys feel. When the keys feel squishy, your fingers will automagically go to the QWERTY positions.
They're not designed for the same purpose. The GPL is designed to exert pressure on other people to behave in a certain way (mainly, to contribute back their changes) and to grant them fewer rights if they do not. The BSD license was designed to allow the code to be used by just about anyone for just about any purpose, so it grants its freedoms a bit more freely.
If you are implementing something like a networking protocol or file format reference implementation, then your most important goal is widespread adoption, and in that case you need to go with a BSD-style license (or just plain public domain). This allows vendors to roll your implementation into their proprietary products.
For an end-user application, such as a music player, that concern is less important, and so other considerations become relevant. At that point you ask yourself, "Am I comfortable with allowing FooCorp to incorporate my music player into FooMedia Center and distribute it under a proprietary license?" If you are comfortable with that, you can go with a BSD-style license, but if not, you will want to opt for a more restrictive license, such as the GPL (or LGPL, if you want to allow non-GPLed code to link against yours).
Ask yourself: if Microsoft or Apple incorporates your code into some portion of their operating system, do you rejoice because it's seeing widespread adoption, or do you get angry because they're stealing your work? In the former case, you want the BSD license, or something very like it; in the latter case, the GPL is more your cup of tea.
Also for a smaller project you may ask yourself this: if other people contribute patches, and then you go get a new job, do you want to ensure that you have the freedom to roll this code (that is mostly yours but contains others' patches) into one of your new employer's proprietary products? If you want to leave yourself that option, you consider the BSD license; if you would prefer, OTOH, that the code you've worked on *not* be rolled into a future employer's proprietary products, you would probably be happier with the GPL or perhaps LGPL (again, depending on how you feel about linking).
> Last time I checked Windows had horrific High Performance Clustering
I have no personal experience with that, but I suspect you're right, based on extrapolation upward, given that, at the low-end, recent Windows versions seem to require more hardware to do almost anything.
> In addition, the licensing issues to go along with Windows 2003 advanced > server or whatever you need to get HPC is ridiculous.
That's irrelevant for this article. This CIO was dealing with systems at the high end of enterprise servers, where your tape backup system goes into five figures. On that kind of budget, a site license for anything Microsoft has ever written will fit nicely under "Miscellaneous". Robustness and how well the hardware can be utilized are much more important considerations.
For small business, or for desktop scenerios, the licenses are a big issue, but not here.
> I wonder if it might be better to have the root domain servers be > distributed throughout the world (run as non-profit organizations, > with only minimal fees required to maintain the servers, and > executive salaries at these orgs capped).
Yes, but which countries' governments do you trust to allow said organizations to do their job without needless government interference to meet political agendas? On the other hand, which countries' governments do you trust to require said organizations to follow the relevant international guidelines (e.g., ICANN rules)?
It's not a simple question, and it wouldn't be right to rush headlong into the first answer that is proposed. The root servers are *important*, and any changes should be handled with great care after careful consideration. I'm not saying that having all the root servers in the US is the right answer, but it has worked so far and should hopefullly continue to work long enough to allow enough time for proposed "better" systems to be carefully considered. I don't for example think there's a need to rush to get the root servers out of the US in the next few months, as there might be if the US government were immanently likely to dismantle or otherwise screw up the whole thing otherwise.
There are not very many countries that I would trust with a root nameserver. Fewer than I would trust with nuclear weapons. The US, the UK, probably Australia, probably Japan, possibly New Zealand, and precious few others. I would not really trust a root nameserver in China, for instance, although I have no problem trusting them with nuclear capability. There is at least one entire continent (you probably can guess which, no, I don't mean Antarctica) that has *no* countries on it I'd trust with a root nameserver. Do you see the problem?
I've got a set of rules for choosing a firewall...
First, it should be external. It's quite simple, really: with an internal (software) firewall, if the host OS's TCP/IP stack has a vulnerability, the firewall and the host OS can be compromised together in one action. With an external firewall, compromising the firewall and compromising the protected systems will always be two separate steps. This makes the attacker's life that much harder.
Second, it should preferably run on a different operating system from the protected systems. (If you are protecting a heterogenous network, choose a different OS from the most important protected system.) This means that the two steps (compromising the firewall and compromising the protected system) will be *different* in nature. This makes the attacker's life that much harder.
Third, the firewall should be based on technology that the systems administrator is familiar with. This makes it more manageable for you, and a better-managed firewall is a more effective firewall.
Finally, the firewall should, to the greatest extent possible, isolate the protected systems from *eachother*, as well as from the rest of the world. If you just throw everything together on one subnet behind the firewall, and then you expose one vulnerable service to the internet via a single forwarded port, your whole network (potentially) can be compromised. If the protected systems are isolated from one another, it limits the damage if one is compromised, because getting to the others doesn't get significantly easier as a result.
For protecting Windows servers, I would probably personally choose a Linux IP-Tables setup for the firewall, mainly because of my third rule, but if you are comfortable with BSD that would be an excellent choice too, possibly better. They also make hardware dedicated firewall boxes you can buy, and while the quality varies, one of these is almost certainly a better choice than a software firewall running on the servers themselves, because of rules 1 and 2.
It has to do with the size (and focus) of your employer. In a Fortune 50 company with an IT focus, many of the employees can be highly specialized, e.g., you might have somebody who does nothing but administer Oracle databases running on Solaris. At the other end of the spectrum, many much smaller outfits hire a one-man IT department, who is expected to unjam printers, administer databases, teach introductory internet classes, write firewall rulesets, support end users, create newsletters, assign IP addresses, install software, make purchase recommendations, and fix hardware and software problems on Macs, Windows PCs, Linux boxes, and whatever other platforms the organization happens to have. (We're phasing out the VMS system this summer...) When you have this kind of job, your official job title can be anything (mine is "Technology Coordinator"), but people usually just call you The Computer Guy. Frequently you end up also doing non-computer work for part of your work time, to cover for days off, vacations, and other things, to fill out your schedule, or just to be "part of the team".
The good news is that a generalist is not expected to be the leading expert on anything, and often you have outsourced support contracts for the more difficult or mission-critical systems.
I suspect that in a more medium-sized outfit you'd have some in-between level of both expertise required in your specific are and competence (or at least dabbling) required outside your area of expertise.
I thought this was common knowledge. It has to do with the optical properties of the atmosphere. Objects viewed through a thicker atmosphere (or at more of an angle, so that the light passes through an effectively thicker slice of the atmosphere) look larger because the light is diffracted more -- like when you look through a convex lens. It's related to the reason why sunsets are red, the noonday sun yellow, and the rest of the sky blue (because blue light diffracts more readily than red), which is why when the moon (or sun, for that matter) appears larger, it also appears redder.
More stuff (clouds, dust, whatever) in the atmosphere means a larger, redder moon and prettier, more elaborate sunsets.
C'mon, this isn't exactly quantum mechanics. More like high-school physics.
Once you've been talked into doing something once, precedent makes it *much* harder to say no thereafter. I had a former employer that asked me to falsify records, though it wasn't stated that way. It was, "You check to make sure that this thing is thus-and-such, and then you record it", but the first time I wrote down an accurate but unacceptable value, it became, "You CAN'T put THAT down!" I shrugged and said, "That's what it was." They had somebody else take the book and change it, a compromise I was willing to live with at the time. Anyway, my point is that because I refused the first time, it thereafter was easy to refuse subsequently, and before very long an understanding developed that I couldn't be asked to do that.
That is the position you want to take. It may not totally protect you if everyone in the whole company goes down in flames, but it CAN reasonably be expected to keep a target from being painted on your particular chest. (Well, a legal target anyway. Some bosses hold grudges, which could be a different kind of target, but if you think you have that kind of boss you probably should be looking for another job already anyway.) But if you did the thing the first time, you may have to take that position on your *next* job.
Slashdot Mirror
> I'm curious as to whether 3rd party software firewalls for windows are
> impacted by this or not.
If the firewall is configured to allow Remote Desktop Connection traffic through, e.g., because it is used to administer headless servers, a very common practice for outfits that have Microsoft servers, then which firewall you use is not the real issue.
> If not, then this hole (and others which are likely to follow) would provide
> a good justification for purchasing and deploying a 3rd party solution.
Along similar lines, if you have a different remote administration facility, such as PC Anywhere or VNC, you could use that in the interim and configure your firewalls (hardware, software, all of them) to discard RDC traffic until you get the patch deployed. (And if next month there's a VNC vulnerability, you could do the reverse, discard VNC traffic and use Remote Desktop instead, until you get VNC patched. Seems to me like it's worth having more than one solution for remote administration, for precisely this reason.)
> Isn't a firewall supposed to block incoming connections unless
> specifically allowed?
That is the way you set up your firewall if you are following security best practices, yes. But not all firewalls are configured that way (some are configured so that they only block known types of problem traffic), and software firewalls in any case can still be vulnerable even if they are theoretically set up correctly, if there is a flaw in the OS (although that doesn not appear to be the issue in this case).
As far as the specific instance in this story, the hole is in Remote Desktop, something many firewalls are likely to be configured to let through, because it's frequently used to administer things that are behind firewalls. The closest equivalent for non-Microsoft systems is VNC, but it's a bigger deal than that, because Windows doesn't include an equivalent for ssh, so Remote Desktop typically gets used for that too. Our firewall at work forwards in Remote Desktop traffic to one particularly mission-critical system, but fortunately it's set up so that it only lets the traffic in from one specific source IP address, so I am not panicked over this, although I will nonetheless be installing the patch when I get half a chance. Things like this *need* to be plastered all over the major tech news services like slashdot, so that people in this sort of situation are aware of the issue. Some network administrators might even be in a situation where the best thing to do is to temporarily change the firewall ruleset to discard the type of traffic in question, until they can get the patch deployed.
> all it takes is one worm on someone's laptop to bypass the corporate firewall
That's why you don't just firewall the borders; you firewall each small LAN segment (e.g., each suite of rooms) from the rest of the world, allowing through to other subnets only what is needed. This doesn't prevent any individual computer from being compromised, but it reduces the impact so that the whole network doesn't go down (assuming that the compromised system isn't a core mission-critical server or firewall; those hopefully are not running on Microsoft systems or at least are much better protected than the desktops, and, above all else, they're not sitting on the desks of ordinary users with no security sense or training, but rather locked up in the back of the IT department; ideally you can't get to them (physically) without ducking under cables and squeezing through a narrow space between a workbench and a cluttered table, or some similar management-deterring arrangement.
> And running Apache as root is a Really Bad Idea (tm).
Anything that handles untrusted data (e.g., connections from the internet, or email) should NOT be running as root and ABSOLUTELY should not have write permissions outside its own home directory. Preferably it should be chrooted.
Apache has for years supported running as a user with limited privileges; most distros give it its own user account and its own group, so it definitely should not be running as root. (Yes, you launch it as root, but it changes users when it forks, before it starts looking at the data coming in on the socket.) Configuring it to run as root is an action the user must have taken deliberately -- and yes, that was a Bad Idea.
Last I checked (which admittedly was several years ago now), sendmail still *required* to be run as root, so that it could write files in various places where it has no business writing files, such as within other users' home directories. Bad programmer, no cookie.
> Running as a normal user is annoying at best
> due to all the stupid Windows software.
And at worst you can't use certain software at all. My question is, do you really want to use software that's that braindead anyhow?
> It has been labelled 'The Worst Movie Ever' by the Golden Turkey Awards
Clearly, the Golden Turkey Awards have never reviewed The Creeping Terror, the movie with acting that makes William "Excessive Dramatic Pause" Shattner seem stunningly on-the-ball by comparison, Jim Carey sophisticated, and Home Shopping Club announcers believable; special effects that would boggle your mind with their badness if you had to watch an eighth-grade class drama project that used them; camerawork that makes the Blair Witch Project look both conventional and brilliant; a plot more simplistic than Scooby Doo, more hackneyed than I Love Lucy, and yet more convoluted than The Fifth Element; shallower and worse character development than an Olson Twins movie, combining more stereotypes than the Smurfs with more smarmy preachyness than the Brady Bunch; writing so bad, SNL skit-writers would roll over in their graves; scenery that combines humdrum with unrealistic; lighting that manages to be too light to be dramatic and too dark to clearly show all the action, sometimes in the same scene; a sound track that would make Hanna Barbara cringe; a more transparently non-existent budget than anything ever done by Monty Python; all the humor and hilarity of televised professional bowling tournaments, combined with all the deep emotion of RFC 2616; and more. If there is anything else in the history of B-movie cinematography that even *approaches* the fantastically execrable, horrifically abominable, catastrophically horrendous piece of flotsam that is The Creeping Terror, I am sure I would not believe it even if I were to see it. I would be *deeply* surprised to discover another movie bad enough that it would deserve to be called "much better than The Creeping Terror"; any other B-movie I have seen would be insulted by such a comparison. If they made C-movies, D-movies, and F-movies, The Creeping Terror would make them *all* look like blockbusters. The *ONLY* thing I can say in its favor is that the sequel they tried to leave it open for was, thankfully, apparently never made.
You need Firesomething. Right now, as it happens, I'm browsing in Mozilla Waterdingo. (The choices for the brand, modifier, and noun are all fully customizable, of course. At one point I had made all the modifiers things like Battle and Fear and Death and whatnot, and the nouns were various weapons, so I got results like Mozilla TerrorAxe and Netscape ConquestDaggar; a couple of re-installs later I'm currently just using the defaults.)
> Yes, I believe it to be a bad thing when major news sources
Oh, in that case, yeah. For a moment there, I thought you were talking about MSNBC content, but if it's major news sources, that's different.
> Previously, it was necessary to use a third party stack to
> access the Internet to use the Web and Gopher.
I know that was true in Windows 3.1 and 3.11 for Workgroups. (The one most folks used was made by Trumpet.) I do not know what the situation was in the first release of NT.
> It's something that I would like to find an authoritative reference for.
As far as what actually shipped, I still have the Win95 OSR2 CD that came with my January-1998 PC, but I don't need to check, because I'm quite certain that when I installed the network card I had to manually go into the setup (right click on Network Neighborhood, choose Properties) and hit the Add button, choose Protocol, select Microsoft under vendor, and choose TCP/IP. They also had "IPX/SPX Compatible Protocol" in there (apparently they were afraid of trademarks just calling it IPX/SPX) and at least one other thing, I forget what. My memory of this is quite clear because I re-installed Windows a couple of times and had to redo it. This is OSR2, but I have many times seen lists of the differences between Win 95 A and OSR2, and this has never been on any of the lists, so I imagine it probably was not changed. (Things I know about that were changed: added FAT32, with accompanying changes in format and fdisk, as well as of course the filesystem itself, added half-baked USB drivers that never worked with any actual USB hardware, added several promotional icons on the desktop and in the start menu, fixed a couple of minor bugs. FAT32 was the only thing to get excited about.)
But you were probably wanting documentation on Microsoft's internal decision process? There probably never was any, officially, outside of Microsoft. Just rumours, probably. That's how it usually is.
What we do know, though, is what Microsoft was encouraging people to use. As I said, file and print sharing by default used NetBEUI. You could bind it to IPX/SPX or TCP/IP, but the default was to not bind it to those protocols. Additionally, if you read the press releases and documentation and stuff Microsoft was putting out at the time, it was all about their NT networking stuff, WINS in the role that DNS fills today, and so on. Then circa 1999, when they were starting to get serious about NT5/Win2000, they suddenly started talking about using TCP/IP "natively". That sounds a little too technical, so when Win2K actually shipped their marketing department rephrased it "Built for the Internet". (My thoughts at the time were along the lines of, "Yeah, Windows 2000 may be built for the internet, but the internet was built for Unix.")
The thing is, Windows networking is still very much its own proprietary setup, *very* different from the way the internet is set up, and it's *very* confusing for someone with prior experience mainly with TCP/IP and the internet. They use some of the same words, but they use them in different ways. For instance, a "domain" is not anything to do with DNS, but an authentication mechanism. However, when you "log on to" a domain, you are not then working on the domain controller server; you're still working on your local system, and your profile is stored on your local system, and everything is done on your local system. (I'm confused about whether even the authentication is done on the domain controller, since I appear to be able to log in to a domain even when the domain controller is physically powered down. This worries me, since I am concerned that information (such as a hash function result) about the password needed to log on as domain administrator may be distributed to the individual systems on the domain. I wish I knew how to find that out for sure, because if it's true it means one compromised workstation has quite serious implications for the PDC and the whole network.) If you want to actually log on (in the Unix/internet/TCP/IP sense) to the PDC, you use Remote Desktop or some other solution. It's all very confusing for someone who mostly knows internet stuff and standard protocols. If Microsoft ever develops an OS that *really* uses the standard internet protocols natively, ssl and so on, I think I'd get pretty excited.
> While Lynx is cool and all I think it was because of the graphic
> capacity of the web that made it grow and killed of gopher.
Having graphics embedded in pages (as opposed to just at the end of a link, like gopher could do) may have accelerated it, but it would have happened anyway. The real genius of the web is that any part of any page can link to anything else on the internet (not just on the web); this made the web useful for creating cross-site topical indeces of, among other things, Gopher. (Yes, people used to create web-based indices that included Gopher links. Really. Granted, ftp links were much more common; I think about a third of Yahoo consisted of ftp links at one time. They linked to usenet also, and telnet sites, and TN3270, and other things.) The other way around wouldn't work: a gopher site couldn't serve as an index of other gopher sites, ftp, and the web. Then CGI-based search tools came along and made Archie look kludgy and painful by comparison, and the rest is history.
> Didn't Win95 almost ship without a TCP/IP stack?
No, but it shipped with it turned off by default. You had to go into the
Network Neighborhood properties and Add Protocol and all that jazz to get it
turned on. Also, SMB/CIFS didn't bind to TCP/IP by default, only to NetBEUI.
Basically, TCP/IP had the same level of support as IPX/SPX.
In an office filled with coworkers incessantly chitter-chattering among themselves about nothing of any consequence, it's sometimes a wonder I get anything done at all. I estimate about a third of my "work" time is spent losing my train of thought due to the incessant meaningless chatter and then attempting to regain it.
Losing my train of thought due to the ringing phone and then attempting to regain it afterwards also accounts for a significant portion of my time, but there's nothing my employer could do about that; we have to answer the phone, of course.
> will incorporate the print head in the printer itself
In exactly what way is this "new"?
NOTHING the schools can do will solve the problem of deadbeat parents who don't look at their kids' homework, don't discuss with them what they're studying, don't teach them anything at home either, and, in general, don't bother to raise their kids. Sure, a small handful of kids, maybe 1%, are so self-motivated that they will do well even though their parents don't give a lick. But most kids, if their parents don't care, will flunk out if you let them or, if you inflate their grades so that they can't flunk, coast.
You want to fix the schools? Fix the *people*, fix *society*, fix our *culture*, and the schools will get better.
> Next up, writing a VI clone in LISP!
It's called viper-mode, and Emacs has come with it included for years. (If you don't understand why Emacs has to come with a vi clone included, then you clearly don't understand Emacs.)
...not ship the books out until, you know, they're ready to be released?
Nah, that would be too *straightforward*, and it might actually *work*, and above all it wouldn't give them anyone to *sue*, so obviously they couldn't use that plan, now could they? Sheesh.
OTOH, while this particular quirk of the book publishing and distribution system it bizarre and unnecessary, it's not DRM in any normal sense of that term. All they're trying to control is the initial distribution until the release date. The book is still just an ordinary book once you do get your hands on it.
For your Dvorak keyboard, get one that has a noticeably different feel from the standard cheapo QWERTY keyboards you're likely to run into. Something with buckling-spring feedback is best. An IBM Model M will do in a pinch, or you can go all out and get an Avant Stellar, if you have the budget for that. (Yes, it costs a lot. It's worth it, though. Among other things, a keyboard like that will let you customize your layout in ways that you otherwise can't easily do -- e.g., you can move the shift and ctrl keys around, which if done right can relieve your pinkies of the need to be hyperextended frequently, something Dvorak won't do.)
Anyway, even a cheap used IBM Model M that you can pick up on ebay for practically nothing will have a quite different feel from today's cheapo squishy compact membrane keyboards that most PCs come with out of the box (and which, therefore, is what most people use).
So when you sit down to type at one, your fingers will feel the difference. At first you will find yourself using the wrong layout sometimes and mistyping until you stop and think, but after a few weeks of switching back and forth on a daily basis, you will find that your fingers automatically "know" where to go based on how the keys feel. When the keys feel squishy, your fingers will automagically go to the QWERTY positions.
They're not designed for the same purpose. The GPL is designed to exert pressure on other people to behave in a certain way (mainly, to contribute back their changes) and to grant them fewer rights if they do not. The BSD license was designed to allow the code to be used by just about anyone for just about any purpose, so it grants its freedoms a bit more freely.
If you are implementing something like a networking protocol or file format reference implementation, then your most important goal is widespread adoption, and in that case you need to go with a BSD-style license (or just plain public domain). This allows vendors to roll your implementation into their proprietary products.
For an end-user application, such as a music player, that concern is less important, and so other considerations become relevant. At that point you ask yourself, "Am I comfortable with allowing FooCorp to incorporate my music player into FooMedia Center and distribute it under a proprietary license?" If you are comfortable with that, you can go with a BSD-style license, but if not, you will want to opt for a more restrictive license, such as the GPL (or LGPL, if you want to allow non-GPLed code to link against yours).
Ask yourself: if Microsoft or Apple incorporates your code into some portion of their operating system, do you rejoice because it's seeing widespread adoption, or do you get angry because they're stealing your work? In the former case, you want the BSD license, or something very like it; in the latter case, the GPL is more your cup of tea.
Also for a smaller project you may ask yourself this: if other people contribute patches, and then you go get a new job, do you want to ensure that you have the freedom to roll this code (that is mostly yours but contains others' patches) into one of your new employer's proprietary products? If you want to leave yourself that option, you consider the BSD license; if you would prefer, OTOH, that the code you've worked on *not* be rolled into a future employer's proprietary products, you would probably be happier with the GPL or perhaps LGPL (again, depending on how you feel about linking).
> Last time I checked Windows had horrific High Performance Clustering
I have no personal experience with that, but I suspect you're right, based on extrapolation upward, given that, at the low-end, recent Windows versions seem to require more hardware to do almost anything.
> In addition, the licensing issues to go along with Windows 2003 advanced
> server or whatever you need to get HPC is ridiculous.
That's irrelevant for this article. This CIO was dealing with systems at the high end of enterprise servers, where your tape backup system goes into five figures. On that kind of budget, a site license for anything Microsoft has ever written will fit nicely under "Miscellaneous". Robustness and how well the hardware can be utilized are much more important considerations.
For small business, or for desktop scenerios, the licenses are a big issue, but not here.
> I wonder if it might be better to have the root domain servers be
> distributed throughout the world (run as non-profit organizations,
> with only minimal fees required to maintain the servers, and
> executive salaries at these orgs capped).
Yes, but which countries' governments do you trust to allow said organizations to do their job without needless government interference to meet political agendas? On the other hand, which countries' governments do you trust to require said organizations to follow the relevant international guidelines (e.g., ICANN rules)?
It's not a simple question, and it wouldn't be right to rush headlong into the first answer that is proposed. The root servers are *important*, and any changes should be handled with great care after careful consideration. I'm not saying that having all the root servers in the US is the right answer, but it has worked so far and should hopefullly continue to work long enough to allow enough time for proposed "better" systems to be carefully considered. I don't for example think there's a need to rush to get the root servers out of the US in the next few months, as there might be if the US government were immanently likely to dismantle or otherwise screw up the whole thing otherwise.
There are not very many countries that I would trust with a root nameserver. Fewer than I would trust with nuclear weapons. The US, the UK, probably Australia, probably Japan, possibly New Zealand, and precious few others. I would not really trust a root nameserver in China, for instance, although I have no problem trusting them with nuclear capability. There is at least one entire continent (you probably can guess which, no, I don't mean Antarctica) that has *no* countries on it I'd trust with a root nameserver. Do you see the problem?
I've got a set of rules for choosing a firewall...
First, it should be external. It's quite simple, really: with an internal (software) firewall, if the host OS's TCP/IP stack has a vulnerability, the firewall and the host OS can be compromised together in one action. With an external firewall, compromising the firewall and compromising the protected systems will always be two separate steps. This makes the attacker's life that much harder.
Second, it should preferably run on a different operating system from the protected systems. (If you are protecting a heterogenous network, choose a different OS from the most important protected system.) This means that the two steps (compromising the firewall and compromising the protected system) will be *different* in nature. This makes the attacker's life that much harder.
Third, the firewall should be based on technology that the systems administrator is familiar with. This makes it more manageable for you, and a better-managed firewall is a more effective firewall.
Finally, the firewall should, to the greatest extent possible, isolate the protected systems from *eachother*, as well as from the rest of the world. If you just throw everything together on one subnet behind the firewall, and then you expose one vulnerable service to the internet via a single forwarded port, your whole network (potentially) can be compromised. If the protected systems are isolated from one another, it limits the damage if one is compromised, because getting to the others doesn't get significantly easier as a result.
For protecting Windows servers, I would probably personally choose a Linux IP-Tables setup for the firewall, mainly because of my third rule, but if you are comfortable with BSD that would be an excellent choice too, possibly better. They also make hardware dedicated firewall boxes you can buy, and while the quality varies, one of these is almost certainly a better choice than a software firewall running on the servers themselves, because of rules 1 and 2.
Oh, did I leave off the /g regex modifier? Sorry about that.
It has to do with the size (and focus) of your employer. In a Fortune 50 company with an IT focus, many of the employees can be highly specialized, e.g., you might have somebody who does nothing but administer Oracle databases running on Solaris. At the other end of the spectrum, many much smaller outfits hire a one-man IT department, who is expected to unjam printers, administer databases, teach introductory internet classes, write firewall rulesets, support end users, create newsletters, assign IP addresses, install software, make purchase recommendations, and fix hardware and software problems on Macs, Windows PCs, Linux boxes, and whatever other platforms the organization happens to have. (We're phasing out the VMS system this summer...) When you have this kind of job, your official job title can be anything (mine is "Technology Coordinator"), but people usually just call you The Computer Guy. Frequently you end up also doing non-computer work for part of your work time, to cover for days off, vacations, and other things, to fill out your schedule, or just to be "part of the team".
The good news is that a generalist is not expected to be the leading expert on anything, and often you have outsourced support contracts for the more difficult or mission-critical systems.
I suspect that in a more medium-sized outfit you'd have some in-between level of both expertise required in your specific are and competence (or at least dabbling) required outside your area of expertise.
I thought this was common knowledge. It has to do with the optical properties of the atmosphere. Objects viewed through a thicker atmosphere (or at more of an angle, so that the light passes through an effectively thicker slice of the atmosphere) look larger because the light is diffracted more -- like when you look through a convex lens. It's related to the reason why sunsets are red, the noonday sun yellow, and the rest of the sky blue (because blue light diffracts more readily than red), which is why when the moon (or sun, for that matter) appears larger, it also appears redder.
More stuff (clouds, dust, whatever) in the atmosphere means a larger, redder moon and prettier, more elaborate sunsets.
C'mon, this isn't exactly quantum mechanics. More like high-school physics.
Once you've been talked into doing something once, precedent makes it *much* harder to say no thereafter. I had a former employer that asked me to falsify records, though it wasn't stated that way. It was, "You check to make sure that this thing is thus-and-such, and then you record it", but the first time I wrote down an accurate but unacceptable value, it became, "You CAN'T put THAT down!" I shrugged and said, "That's what it was." They had somebody else take the book and change it, a compromise I was willing to live with at the time. Anyway, my point is that because I refused the first time, it thereafter was easy to refuse subsequently, and before very long an understanding developed that I couldn't be asked to do that.
That is the position you want to take. It may not totally protect you if everyone in the whole company goes down in flames, but it CAN reasonably be expected to keep a target from being painted on your particular chest. (Well, a legal target anyway. Some bosses hold grudges, which could be a different kind of target, but if you think you have that kind of boss you probably should be looking for another job already anyway.) But if you did the thing the first time, you may have to take that position on your *next* job.