The comment I made was focused on a specific set of situations -- that was not claimed to apply in different situations -- and where there are exceptions. Take it for what it's worth.
Agreed. I was relaying her remarks only, for her specalty. Still, I'd hate to have my nose, vocal cords, or chunks of my lungs removed and still die when reducing risk to those areas is so easy -- as long as you're not addicted to smoking or drinking of course.
Cancer is one of the medical institutions major source of income, if it were cured, what would we do with all the stupid research centers? Many people think that cancer can be cured by using good food, lots of greens, no meat, etc. But really nobody considers this because it doesn't make money.
Another datapoint. I used to date an Otolaryngologist (ears, nose, and throat) who worked at NIH (a (the?) main US national medical center).
In normal conversation, she would talk about the large number of cancer patients she had and how hard it was for them to stop smoking or drinking alcohol even after they were diagnosed.
One day, curious, I asked how many cancer patients she had over the years that didn't smoke, drink, or both. 30 seconds went by. A frown developed on her face. "I think, maybe, two over the past 10 years. One I know was the wife of a smoker." She went on to explain that most were both alcoholics and 1+ pack a day smokers, though nearly all the rest were either heavy smokers or drinkers.
While cancer treatment and diagnosis wasn't her primary responsibility, it was a large part of the practice's business and (when money was available) research. Other problems they encountered were related to smoking -- especially cronic childhood ear/throat infections where one or both of the parents were heavy smokers.
Take it for what it's worth. Me, I love going out with friends for a good beer or two (quality over quantity) and snacks. Her observations keep me out of the smokey bar area, though.
If more people used [SCSI devices], [SCSI] would be a cheaper solution, and would fix all of IDE's problems without re-inventing the wheel--it's a solution that, right now, works.
All my systems are SCSI-based, usually with one or two IDE devices added as adjuncts. While it is true that many of IDE's failings could be solved by using SCSI instead, the focus of each interface is entirely different. Both SCSI and IDE are valuable on thier own merits;
SCSI: A complex protocol to control propriatory and diverse devices transfered on standardized cables and handled by propriatory controllers. Hardware control of the device is handled by the protocol layer that is supported by a propriatory hardware and software layer plus the electronics on the device. These added layers are required because SCSI devices are so diverse and the controller-to-system interface is not standardized. SCSI devices can be any type of data storage unit (from simple hard drives to chained optical juke boxes), all types of scanners, network interfaces, and other standard and custom devices. The SCSI protocol allows extentions on a per-device basis. SCSI controlers require a chipset-specific software layer to link them to the rest of the system.
IDE: A single physical and protocol interface located primarily on the drive itself. IDE was designed to be a cheap and simple extention of x86 chipsets for specific data storage devices; hard drives. CD, DVD, and enhancements to the IDE chipsets were added later. Because the drive electronics masks the true nature of the drive attached, and the system-side IDE support is generic, no chipset-specific drivers are required. (Yes, some IDE chipsets are garbage and require special support to prevent data loss. Most of these defects occured because the testing done was limited to "does it work with Windows 3.x/9x?" and things like DMA were largely ignored. Oops!)
All things considered SCSI would probably be cheaper now if it were used as the standard interface on x86 systems back before IDE, though it's impossible that it could underprice IDE just because of the propriatory nature of the hardware-heavy controller chipsets -- each flavor with it's own unique set of features. Keep in mind that Apple used SCSI as it's standard till reciently and switched to IDE mainly because of cost.
That said, I wish both IDE and SCSI devices a heart felt and fond "get lost". Newer device interfaces are cheap, fairly generic, fast, and allow arbitrary devices to be attached.
I don't expect a complete switch to happen soon, though fiber channel has replaced some of the functions that SCSI devices used to perform on the high end, and IDE is too cheap to pass up on the low end.
As a long time mac advocate, forced windows user and linux sysadmin . . . explain to me how mac advocates are significantly different than linux geeks who insist that Linux is the one true un*x, the one to rule them all . ..
Except for online, I have yet to meet either a Mac or Linux user who sees one and only one OS. I've met OS/2 and Amiga fanatics, though that list is quite small (1 for Amiga, 2 for OS/2).
I consider myself a Linux advocate yet I have no problem if someone has a good reason to use an 'alternative' platform. I've used everything from Solaris and BSD through Windows and MacOS. If a reference source is available, I can usually cope with anything.
I've met some Windows users in real life that seem a bit too aggressive and unyeilding.
In general, the Mac users I've talked to are not zealots. I -- someone who doesn't own a Mac -- had to talk two of them into keeping thier macs or buying a new one.
These are not geeks, gurus, or deep into graphic design. They see Windows PCs everywhere and think that they are missing something since Windows is so popular. Asking them a few simple questions usually eliminates doubt and they stick with Apple out of inertia;
* They have a Mac.
* While they can use Windows there is no reason to not keep or buy a Mac.
The point isn't that you're running graphics mode, or not. The point is that COMMAND.COM thinks that it can get to the first meg of memory without that pesky text thing taking up space at B000h-B7FFh (remember, the ROMs at 0xA000-0xAFFF, 0xB800-0xC800, and 0xF000-0xFFFF are all gone thanks to QEMM).
Video memory typically starts at A000, and can start lower. Video ROMs are typically at C000-C800. B000-B800 is for monochrome (MGA). With that trivia out of the way...
While the book you quote is good, you're out of your element. For one, I don't need to quote his book as I was there and know what I'm talking about .
Loading something somewhere means nothing if it can't survive there. Adapters can initialize from A000-10000h without warning the OS or memory manager. This means corrupted programs or data. To use one piece of memory or another required much machine-specific tinkering. To use a contiguous block required quite a few rare circumstances.
Loading anything above 1M leads to the program thinking (rightly) that it is still in the first meg. -- and it will attempt to write into the first meg if it can be executed at all. Usually, it can't. _DOS_ programs in the first meg run in real mode meaning that they will do things that are illegal in protected mode unless rewritten. _All_ programs above the first meg run in protected mode or don't run at all. (Nit: A small space called the HMA at 1M+ through 1M+~64K can still execute in real mode, though they would have to be patched or they would still attempt to write into the first 64K.)
Once you handle all those problems in your code you end up with a protected mode program that no longer needs real mode. No real mode, no reason to use the first meg -- just allocate the memory from the OS/memory manager and let it mess with the first meg if it needs to. That's why DOS sucked so bad -- no memory to do jack unless you avoided it entirely.
I worked at Qualitas -- makers of 386MAX (similar to QEMM). I debugged and tested MAX, compressed system BIOSes, a seperate 286 memory manager (yes, they existed), and a memory diagnostics program (RamExam). Shulman's book is a wee bit thicker because of the work that I and a few others at Qualitas did using debuggers that could do odd things like boot DOS from DOS -- not a big deal now, but an unreal thing to design back in the day unless you had specialized hardware.
I'll agree with the dancing part & women. I'm adding it to my list of weekly activities. Salsa dancing looks like the way to go; lots of body contact.
Dance is not recommened for geek girls looking for dates though. A former girlfriend of mine was shocked to find that most of the men who were attracted to dance clases were gay or talked into going with thier wives. I ofcourse laughed -- most real men at night are at the gym, a bar, or home watching something blow up on TV. Yet, you can't argue with the ratio -- just don't look gay if you're not.
Not possible in _graphics_mode_. Reason: Graphics memory at the time was in the 640K+ range. As soon as a program enabled that uses graphics, it accesses the remapped conventional memory and you have contention for the same address space.
IF you have a program that can write outside that space for graphics operations, and you remap just about everything, you could theoretically get most of the first meg as conventional -- in theory only or in short run tests where you don't care what works or how well it works.
You're on the right track; if the code depends on hardware events, you have to deal with timing issues.
Another frequent reason is memory offsets. A slight difference on similar hardware (or with different drivers or software) may allow one system to 'work' (it's corrupting or accessing it's own address space -- BAD), or 'fail' (you get an int13 or other error -- actually a good thing; you are told something is wrong).
Apple already used a cross platform OS as the core of OSX; BSD.^
As we've seen with the other software from applications, services (Apache...), and operating systems (*BSDs, Linux,...), porting to different hardware cleans up quite a few bugs -- from system design mistakes to simple coding errors that 'work' mostly by accident.
Even if there's zero reason to release an x86 port of OSX (or later), the benifits for the PPC OSX still exist.
1. Int13 (hex 0D) is an Intel CPU generated error code. (Don't shoot the messenger -- the CPU reports the violation and is very very rarely the reason for the failure.)
2. If the same software works on one machine but does not work on a similar machine it's often not worth the time to find out why it's failing. (Good guess: it's probably faulty hardware -- dammaged or designed broken.)
In addition...
3. Int13 can be caused by faulty hardware or software. Bad software usually wins the coin toss. Since it happens in this case while using a compiler, I'd say software is the likely cause -- the compiler or (hate to say) your source.
4. Only occurs when the processor is in protected mode. Simply stated; you've got no process isolation in an Intel processor's initial mode at boot time, in DOS (not a command prompt) and while in the system BIOS (aka "real" mode).
5. Protected mode enables the Intel MMU (memory management unit) and requires a program (usually the OS) to manage the GDT (general [memory] descriptor table).
6. If improperly managed by the GDT control program, processes can bleed into other areas. A proper response by the OS to violating and attempting to modify/read areas it is not allowed to use is to close the process and flag the error.
7. In quite a few situations, violations (int13 and otherwise) are OK and expected. These violations are used to trigger responses such as virtual memory page swapping and interrupt handling. Anything outside an expected violation may point to hardware failure, software corruption (by an errant program), or
8. Failures that happen on the OS level can only be cought _after_ the violation _as_long_as_ the process does not nuke critical parts of the OS or the GDT. This means that a violation that is announced usually means your system is in a suspect (possibly instable) state.
9. This is why few things should run as extentions to the OS (ring 0) and should be run at the user level (ring 3).
Rant: Video and other hardware drivers should never run at the OS level let alone other programs that are not part of the OS that specifically is designed to manage memory and other core system hardware. Limited and focused use of OS level resources is a necessity -- because if the OS is corrupted, all bets are off including sane int13 handling
I'll second the comment on Bynari's InsightConnector and I'll add a plug for InsightServer. Much of what they offer is based on open source and open protocols. After checking into it, I found a few more tempting pluses;
* They respond to email! Yep, real people and reasonable answers -- no BS. Also, when one employee reciently went on vacation, his boss followed up instead of waiting a few more days for him to return. Excellent.
* Bynari provides a 1 month trial version with free support during the trial. (Smart, because if it works well you'll be more likely to buy it and won't likely need support after the first 30 days.)
* A new InsightServer licence is about the same price as upgrading from Exchange 5.5 to 2000.
* They have both low end (x86 PC) and high end (IBM mainframe) versions so either scaling up or testing the waters with a PC first are both options.
* Feature-for-feature mapping of Exchange vs. InsightServer so that Outlook clients that you do have (including calendering) work the same.
At first, I thought you were a genius. While I can't use that tactic where I'm working now (only a couple people wouldn't know something is up and that _I_ was the source) for the unknowledgable, it would be highly effective.
The problem comes in when your tactic is discovered and you loose trust; people think that you are working against them or spying on them. That ding to my relationships is not needed and is harmful. I want to be known to be reliable and trustworthy, even if those who I help aren't 100% of the time.
Because of that, I would have to side with those who push policy first...and only then, in the open, let people know that certian resources may not be allowed at all times.
...though it's been about 8 years and the BIOSes I debugged were for IBM PS/2. IBM rarely updated thier BIOS code and they were justified in doing so.
That said, as a meer admin and user I take it as a rule of thumb that if a new system is acting flaky for no obvious reason, firmware upgrades are on the short list of things to check into along with RAM and video drivers.
Sales skills are my weakness too. (On my shelf is "Selling for Dummies" -- unread because I just don't like sales, bought just like other 'good for you' things.)
Unix people, YES. Unix shops, not enough. Evangelists? First time mentioned in this thread. Unix (plus open source) makes sense by itself...so it has a practical reason to be promoted. Making more Unix jobs seems like a good idea...and consistant with what you've said...so you agree with me?
You're ahead of me. That said, if Unix folks apply only for Unix-only shops it won't help make more Unix jobs. That's not a personal problem for you. For the up and comming it's a bonus.
Even though I'm unemployed, and HAVE been for a while, I will not accept a job where more than 50% of my time is on a Microsoft technology.
Pah! I'm working at a place that has 95% MS clients and 75% MS servers. If I was picky, I would also be unemployed right now...but there's another part.
In two months, were're likely to switch the mail/groupware servers from Exchange 5.5 to one of Bynari's commercial offerings running on Linux .
Why isn't this primarily MS shop upgrading to Exchange 2000? After all, the MS Exchange 2k upgrade price is about the same as switching to Bynari's offerings. The main reason is simple: Because I was there when the CIO was making the upgrade decisions. That the IT staff is sick of constantly filtering out mail server exploits by spam houses is a big bonus.
With a Unix-style server, any number of well known and reliable filters can be added to the mail stream if Bynari's filters aren't enough. In short: Problems are solved by a process not a product. Unix-style operating systems and open source allow you to control the process better.
If the transition from Exchange comes off w/o a hitch, I'm sure that there will be more changes over the next 6 months from MS and closed offerings to Unix-style operating systems and more open source. The next most noted grumble from the IT staff is IIS security holes. Since we already use Apache some what, switching to it is a fair bet.
Will the transition be 100%? Unlikely. Yet, without my gentle and informed advice, we'd just upgrade what we have. I take it as a bonus that most of the costs will be lower...reducing the pressure on the IT budget and maybe just maybe making the company stronger.
Slashdot Mirror
The comment I made was focused on a specific set of situations -- that was not claimed to apply in different situations -- and where there are exceptions. Take it for what it's worth.
Agreed. I was relaying her remarks only, for her specalty. Still, I'd hate to have my nose, vocal cords, or chunks of my lungs removed and still die when reducing risk to those areas is so easy -- as long as you're not addicted to smoking or drinking of course.
Another datapoint. I used to date an Otolaryngologist (ears, nose, and throat) who worked at NIH (a (the?) main US national medical center).
In normal conversation, she would talk about the large number of cancer patients she had and how hard it was for them to stop smoking or drinking alcohol even after they were diagnosed.
One day, curious, I asked how many cancer patients she had over the years that didn't smoke, drink, or both. 30 seconds went by. A frown developed on her face. "I think, maybe, two over the past 10 years. One I know was the wife of a smoker." She went on to explain that most were both alcoholics and 1+ pack a day smokers, though nearly all the rest were either heavy smokers or drinkers.
While cancer treatment and diagnosis wasn't her primary responsibility, it was a large part of the practice's business and (when money was available) research. Other problems they encountered were related to smoking -- especially cronic childhood ear/throat infections where one or both of the parents were heavy smokers.
Take it for what it's worth. Me, I love going out with friends for a good beer or two (quality over quantity) and snacks. Her observations keep me out of the smokey bar area, though.
All my systems are SCSI-based, usually with one or two IDE devices added as adjuncts. While it is true that many of IDE's failings could be solved by using SCSI instead, the focus of each interface is entirely different. Both SCSI and IDE are valuable on thier own merits;
IDE: A single physical and protocol interface located primarily on the drive itself. IDE was designed to be a cheap and simple extention of x86 chipsets for specific data storage devices; hard drives. CD, DVD, and enhancements to the IDE chipsets were added later. Because the drive electronics masks the true nature of the drive attached, and the system-side IDE support is generic, no chipset-specific drivers are required. (Yes, some IDE chipsets are garbage and require special support to prevent data loss. Most of these defects occured because the testing done was limited to "does it work with Windows 3.x/9x?" and things like DMA were largely ignored. Oops!)
All things considered SCSI would probably be cheaper now if it were used as the standard interface on x86 systems back before IDE, though it's impossible that it could underprice IDE just because of the propriatory nature of the hardware-heavy controller chipsets -- each flavor with it's own unique set of features. Keep in mind that Apple used SCSI as it's standard till reciently and switched to IDE mainly because of cost.
That said, I wish both IDE and SCSI devices a heart felt and fond "get lost". Newer device interfaces are cheap, fairly generic, fast, and allow arbitrary devices to be attached.
I don't expect a complete switch to happen soon, though fiber channel has replaced some of the functions that SCSI devices used to perform on the high end, and IDE is too cheap to pass up on the low end.
Except for online, I have yet to meet either a Mac or Linux user who sees one and only one OS. I've met OS/2 and Amiga fanatics, though that list is quite small (1 for Amiga, 2 for OS/2).
I consider myself a Linux advocate yet I have no problem if someone has a good reason to use an 'alternative' platform. I've used everything from Solaris and BSD through Windows and MacOS. If a reference source is available, I can usually cope with anything.
I've met some Windows users in real life that seem a bit too aggressive and unyeilding.
These are not geeks, gurus, or deep into graphic design. They see Windows PCs everywhere and think that they are missing something since Windows is so popular. Asking them a few simple questions usually eliminates doubt and they stick with Apple out of inertia;
* They have a Mac.
* While they can use Windows there is no reason to not keep or buy a Mac.
* They stick with Apple.
I'd rather read JPJ's comments from the Legal Times where he published them. Anyone have a link?
Video memory typically starts at A000, and can start lower. Video ROMs are typically at C000-C800. B000-B800 is for monochrome (MGA). With that trivia out of the way...
While the book you quote is good, you're out of your element. For one, I don't need to quote his book as I was there and know what I'm talking about .
Loading something somewhere means nothing if it can't survive there. Adapters can initialize from A000-10000h without warning the OS or memory manager. This means corrupted programs or data. To use one piece of memory or another required much machine-specific tinkering. To use a contiguous block required quite a few rare circumstances.
Loading anything above 1M leads to the program thinking (rightly) that it is still in the first meg. -- and it will attempt to write into the first meg if it can be executed at all. Usually, it can't. _DOS_ programs in the first meg run in real mode meaning that they will do things that are illegal in protected mode unless rewritten. _All_ programs above the first meg run in protected mode or don't run at all. (Nit: A small space called the HMA at 1M+ through 1M+~64K can still execute in real mode, though they would have to be patched or they would still attempt to write into the first 64K.)
Once you handle all those problems in your code you end up with a protected mode program that no longer needs real mode. No real mode, no reason to use the first meg -- just allocate the memory from the OS/memory manager and let it mess with the first meg if it needs to. That's why DOS sucked so bad -- no memory to do jack unless you avoided it entirely.
I worked at Qualitas -- makers of 386MAX (similar to QEMM). I debugged and tested MAX, compressed system BIOSes, a seperate 286 memory manager (yes, they existed), and a memory diagnostics program (RamExam). Shulman's book is a wee bit thicker because of the work that I and a few others at Qualitas did using debuggers that could do odd things like boot DOS from DOS -- not a big deal now, but an unreal thing to design back in the day unless you had specialized hardware.
I'll agree with the dancing part & women. I'm adding it to my list of weekly activities. Salsa dancing looks like the way to go; lots of body contact.
Dance is not recommened for geek girls looking for dates though. A former girlfriend of mine was shocked to find that most of the men who were attracted to dance clases were gay or talked into going with thier wives. I ofcourse laughed -- most real men at night are at the gym, a bar, or home watching something blow up on TV. Yet, you can't argue with the ratio -- just don't look gay if you're not.
IF you have a program that can write outside that space for graphics operations, and you remap just about everything, you could theoretically get most of the first meg as conventional -- in theory only or in short run tests where you don't care what works or how well it works.
Another frequent reason is memory offsets. A slight difference on similar hardware (or with different drivers or software) may allow one system to 'work' (it's corrupting or accessing it's own address space -- BAD), or 'fail' (you get an int13 or other error -- actually a good thing; you are told something is wrong).
This is not an exhaustive list. Happy hunting...
As we've seen with the other software from applications, services (Apache...), and operating systems (*BSDs, Linux, ...), porting to different hardware cleans up quite a few bugs -- from system design mistakes to simple coding errors that 'work' mostly by accident.
Even if there's zero reason to release an x86 port of OSX (or later), the benifits for the PPC OSX still exist.
^ - Corrections & clarifacations apprecated.
Correction: GDT = Global Descriptor Table. It's been a while since I've delt with this.
1. Int13 (hex 0D) is an Intel CPU generated error code. (Don't shoot the messenger -- the CPU reports the violation and is very very rarely the reason for the failure.)
2. If the same software works on one machine but does not work on a similar machine it's often not worth the time to find out why it's failing. (Good guess: it's probably faulty hardware -- dammaged or designed broken.)
In addition...
3. Int13 can be caused by faulty hardware or software. Bad software usually wins the coin toss. Since it happens in this case while using a compiler, I'd say software is the likely cause -- the compiler or (hate to say) your source.
4. Only occurs when the processor is in protected mode. Simply stated; you've got no process isolation in an Intel processor's initial mode at boot time, in DOS (not a command prompt) and while in the system BIOS (aka "real" mode).
5. Protected mode enables the Intel MMU (memory management unit) and requires a program (usually the OS) to manage the GDT (general [memory] descriptor table).
6. If improperly managed by the GDT control program, processes can bleed into other areas. A proper response by the OS to violating and attempting to modify/read areas it is not allowed to use is to close the process and flag the error.
7. In quite a few situations, violations (int13 and otherwise) are OK and expected. These violations are used to trigger responses such as virtual memory page swapping and interrupt handling. Anything outside an expected violation may point to hardware failure, software corruption (by an errant program), or
8. Failures that happen on the OS level can only be cought _after_ the violation _as_long_as_ the process does not nuke critical parts of the OS or the GDT. This means that a violation that is announced usually means your system is in a suspect (possibly instable) state.
9. This is why few things should run as extentions to the OS (ring 0) and should be run at the user level (ring 3).
Rant: Video and other hardware drivers should never run at the OS level let alone other programs that are not part of the OS that specifically is designed to manage memory and other core system hardware. Limited and focused use of OS level resources is a necessity -- because if the OS is corrupted, all bets are off including sane int13 handling
While true for the initial installation, I bet the number using recovery disks makes up for those who don't install at all.
...and I'm all out of mod points.
I'll second the comment on Bynari's InsightConnector and I'll add a plug for InsightServer. Much of what they offer is based on open source and open protocols. After checking into it, I found a few more tempting pluses;
* They respond to email! Yep, real people and reasonable answers -- no BS. Also, when one employee reciently went on vacation, his boss followed up instead of waiting a few more days for him to return. Excellent.
* Bynari provides a 1 month trial version with free support during the trial. (Smart, because if it works well you'll be more likely to buy it and won't likely need support after the first 30 days.)
* A new InsightServer licence is about the same price as upgrading from Exchange 5.5 to 2000.
* They have both low end (x86 PC) and high end (IBM mainframe) versions so either scaling up or testing the waters with a PC first are both options.
* Feature-for-feature mapping of Exchange vs. InsightServer so that Outlook clients that you do have (including calendering) work the same.
The problem comes in when your tactic is discovered and you loose trust; people think that you are working against them or spying on them. That ding to my relationships is not needed and is harmful. I want to be known to be reliable and trustworthy, even if those who I help aren't 100% of the time.
Because of that, I would have to side with those who push policy first...and only then, in the open, let people know that certian resources may not be allowed at all times.
Which packages? RedHat supplied? Seriously.
Failures found in lower levels of a company are always management's fault. You can't blame a lack of oversight on the unsupervised.
That said, as a meer admin and user I take it as a rule of thumb that if a new system is acting flaky for no obvious reason, firmware upgrades are on the short list of things to check into along with RAM and video drivers.
Sales skills are my weakness too. (On my shelf is "Selling for Dummies" -- unread because I just don't like sales, bought just like other 'good for you' things.)
Unix people, YES. Unix shops, not enough. Evangelists? First time mentioned in this thread. Unix (plus open source) makes sense by itself...so it has a practical reason to be promoted. Making more Unix jobs seems like a good idea...and consistant with what you've said...so you agree with me?
You're ahead of me. That said, if Unix folks apply only for Unix-only shops it won't help make more Unix jobs. That's not a personal problem for you. For the up and comming it's a bonus.
Pah! I'm working at a place that has 95% MS clients and 75% MS servers. If I was picky, I would also be unemployed right now...but there's another part.
In two months, were're likely to switch the mail/groupware servers from Exchange 5.5 to one of Bynari's commercial offerings running on Linux .
Why isn't this primarily MS shop upgrading to Exchange 2000? After all, the MS Exchange 2k upgrade price is about the same as switching to Bynari's offerings. The main reason is simple: Because I was there when the CIO was making the upgrade decisions. That the IT staff is sick of constantly filtering out mail server exploits by spam houses is a big bonus.
With a Unix-style server, any number of well known and reliable filters can be added to the mail stream if Bynari's filters aren't enough. In short: Problems are solved by a process not a product. Unix-style operating systems and open source allow you to control the process better.
If the transition from Exchange comes off w/o a hitch, I'm sure that there will be more changes over the next 6 months from MS and closed offerings to Unix-style operating systems and more open source. The next most noted grumble from the IT staff is IIS security holes. Since we already use Apache some what, switching to it is a fair bet.
Will the transition be 100%? Unlikely. Yet, without my gentle and informed advice, we'd just upgrade what we have. I take it as a bonus that most of the costs will be lower...reducing the pressure on the IT budget and maybe just maybe making the company stronger.
[Does happy dance.]