Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Serious CGI Bug in MacOS X Servers 200

Posted by Hemos from the whoop-whoop-red-alert dept.
menthos writes "Multiple CGI queries appearently causes the MacOS X server kernel to do a "System Panic", making MacOS X almost useless as a web server. The German computer magazine c't has the story (in english) "
This discussion has been archived. No new comments can be posted.

Serious CGI Bug in MacOS X Servers More

Serious CGI Bug in MacOS X Servers

Comments Filter:

  • A nanokernel!! (Score:1)

    by Anonymous Coward
    A microkernel, but even smaller!!

    In their next release, they will feature a picokernel!!

  • This isn't quite accurate (Score:3)

    by Anonymous Coward on Friday June 04, 1999 @04:16AM (#1867546)
    First, so far many people running OS X Server have had difficulty getting this script to work. It also does not affect all CGI queries....just this ApacheBench thing specifically. If you disable the ability of someone to run ApacheBench, it wouldn't affect it at all. Apparently a lot of it has to do with what daemons are running, which is why so many people have failed to recreate this problem.
    It just isn't quite accurate for you to say that all multiple CGI queries can crash OS X Server, because that isn't the case.
  • I thought that OS X was supposed to be based off of BSD. As such how did a user level process crash the kernel? There are a couple things I thought of:
    1. The web server was running as super user (and hence could get to system memory?)
    2. There is a flaw in the kernel that allows user level processes to affect the system area.
    3. The kernel can't handle X many simultanious tasks
    4. The machine is actually run off of "Apache OS(tm) The Ficticious Web Server Operating system" and hence the web server WAS the kernel.

    I tend to think that there might be a flaw in the kernel letting user proccesses affect kernel space...

    Any other ideas?

  • Regardless of any bugs found in apache, how is it that a user level process was able to bring down the machine?

    I was curious as to how that could happen, especially when I thought that it was based off of BSD which doesn't allow user level processes to mess with the kernel space.
  • Right... I've seen crashes before... But always from something running in the Kernel or as a super user. (Read: X and kernel space networking)

    Apache is (or should be) niether... It's not part of the kernel and not running as super user. Why was it able to crash the entire machine?

    It seems to be a bug in the kernel allowing user level processes to screw with the kernel space.
  • There are 10 stories on my front page here... of them 4 mention Linux. The rest deal with topics that would be considered.. well.. "News for Nerds."


    Do you read any other tech news site? Every single one has an OS that they tend to favor... Whether it be MacOS, or BSD, or Windows, or Linux. complaining about it doesn't do anybody any good. If you don't like the stories posted, then you have three option.
    1. Stop reading it
    2. Read it and don't complain
    3. Find news stories you'd like to see and submit them. (and stop complaining about article you don't like)

    That way, everyone gets is happy. The people who like the site don't have to sift through garbage in order to read the real comments.

  • Hmmm... (Score:1)

    by Erich ( 151 )
    As a (put on sysadmin hat) system administrator, my natural inclination is to not trust things that haven't proven themselves. That is one reason why I don't use NT now, and wouldn't use NT5 for mission-critical things when it comes out, regardless of how stable Microsoft says it is.

    Similarly, based on the fact that Apple has only had experience making single-user non-memory-protected operating systems that sell mainly because they are easy-to-learn and look pretty, I refuse to switch my machines from BSD, Solaris, and Linux to Mac OS/X... at least not straight away. Apple has not proven to me yet that it can make a good server.

    Things like this deepen my lack of respect for the operating system for doing mission-critical things. A server should NEVER fail. Ever. Now, I know that my operating systems haven't done that. I have had crashes now and then. But BSD, Solaris, and Linux come darn close to never, ever crashing. They certainly wouldn't crash just by running a bunch of CGIs.

    Yes, I know this was a test scenario. Yes, I know that ordinary use might not run 32 cgi programs (or whatever) at the same time. That's no excuse for a kernel panic!

    I hope Apple patches whatever bug caused this. I hope that OS X server becomes a great and reliable server. But please forgive me if I say I don't trust it now, nor will I for quite a while.

  • no because it would have been. CGI crashes linux. get your fix here.
  • ...making MacOS X almost useless as a web server

    If a CGI kernel bug makes MacOS X almost useless as a web server, than the recent slew of Linux kernel bugs (filesystem corruption and Denial of Service attacks) would make Linux worse than useless as any sort of server. Why is it that an Apple bug makes the software "useless," while a serious Linux bug is considered minor?
  • There is a fundamental problem when an ICMP packet can bring about a kernel packet. Something is wrong here. It brings into question the Linux community's ability to (re)write a Unix. And that's why people start bashing.
  • Posted by Adelor Lyon:

    I haven't seen anyone mention that the shipping version of Mac OS X Server is actually version 1.1. The CD I have says it's version 1.1.

    Apple originally had a GM as 1.0, but later took it back in to do a bit more testing on it. I haven't been able to reproduce the crashing bug using the test cgi or any of my own.

    Just the facts, please. :)
  • Posted by Redalert:

    What I don't understand is how you sell something that doesn't have the performance of either Linux or FreeBSD. The only way I'd ever buy a Macintosh is if it had a Alpha/x86 processor or they went back to clones.

    I think the iMac is okay for the consumer market, but probably is badly in need of an upgrade. The other problem is who wants to be tied down to one computer with three shipping speeds. Too make matters worse the case while having a neat design is ugly, and their current OS 8.6 is outdated.

    Isn't it about time that Apple grew up and porting their Ui to Linux/other free unix. If I was in charge, and thank *** I'm not, I would at least put most of my time into the Yellow Box project for x86. Come on Apple time to grow up!

    Jeff
  • I tend to agree. This bug is described in the article as though it's the end of Mac OS X...
    and those of use who consider ourselves the open-minded Slashdot community, have mostly reacted as though this was 1) The end of the world or 2) proof that APple sucks.

    In truth, neither are true.

    Apple's trying something that could turn out to be very cool. Give them a chance.

  • The bug has been spotted, and reported -- now
    its up to the MacOS X engineers to fix it. Time
    will tell if they do a good job.

    So far as those of you screaming about Apple not
    getting it right first time, just remember that
    when Linux 2.2.0 came out

    ldd core

    run on any core dump file would cause an
    immediate system reboot (even if run by a user).

    Embarrassing bugs happen -- what counts is if
    (and how quickly) you fix them, the current
    state of the OSC/FSC is testament to this.

  • The problem is not fundamental to OS X, according to Apple sources.

    According to me, Unix kernels should not be whomped on by userland programs. So the problem is fundamental to Mac OS X.

  • Not Worthless (Score:4)

    by Wyatt Earp ( 1029 ) on Friday June 04, 1999 @04:16AM (#1867563)
    This got alot of coverage yesterday on the Macintosh sites.

    MacOsRumors talked about it and I am going to quote them.

    "1. This problem has so far been only reproduced when the 32+ CGI processes are spawned by a benchmarking CGI -- this problem may or may not actually affect other types of CGIs. It is very possible that it does not. Thus, the problem can be avoided simply by removing the Apache Benchmark CGI from the cgi-bin directory or setting its permissions to prevent it from running ("chmod 500 filename.cgi" should be sufficient).

    2. The problem is not fundamental to OS X, according to Apple sources. Although the specific issue has not yet been determined, it appears to be related to Apache's use of system resources (although the issue itself is apparently in the kernel) and is not likely to affect OS X under any other conditions. A patch is in development and should be available very soon."

    Since when does a bug make something "worthless", oh when it's made by Apple.
  • I've never used MacOS X, so I can't say whether it's worthless or not (System 7 , though.... eeew)


    However, blaming the Apache benchmark CGI is no excuse -- no user level process should be able to induce a kernel panic.


    I'm certain Apple will fix this quick-smart, though; probably a stack filling up or something.
    --

  • Actually, on the Darwin list people have talked about booting Mac OS X Server with a Darwin kernel.

    Darwin is Open Source. If this is a kernel issue, anyone can fix it and submit the changes, and make a binary kernel release available until Apple releases an official patch.

  • Nonetheless, a kernel panic is more stability IMO, because the reboot is less downtime than waiting for it to become happily responsive again.
  • Gee, a sound, solid and informative article and it is ranked 'only' 2! I'd say that this article was interesting and more meaningful than the articles rated three or higher.
  • This is probably some deadlock keeping a vital datastructure locked (eg memory allocation). That can quickly cause a total lockup and it's the sort of bug that's difficult to pin down the responsibility for - it results from an unclear deadlock avoidance policy, which I could imagine you easily get when you put a BSD kernel on a Mach kernel.

    It's not a big deal in the overall scheme of things, though obviously it's a PITA if you were trying to use MacOS X as a web server (brave thing to do on such a new OS!).

  • What the hell is it with Apple and crashing machines? I used to think (when I used apples) that computers just crashed!. Boy am I glad I was wrong. I work around tons of Macintoshes. Boy, if you want to know true performance take a look at OS 8.6 and its new, improved nanokernel Whats a nanokernel?? I installed this OS on one of my machines at work (an iMac) and watch its already miserable performance drop a good 40%. I then read somehwere (I think rumours) that it was sopposed to be that way, and really just felt like it was slower cos it was actully multitasking better than before. Whatever.... I think I will stick to Linux.
  • It seems like moderation is at an all time low these days// What gives?
  • Actually apple is pushing it as a web server as well. In my opinion, I think they have never really known what to do with it. I have tried for the last two years to get Apple engineers to even admit that it exists (I work in education) they always tell me that AppleShare IP is the only way to go for every problem you have with Macs on a network. That to me shows they have had not focus for the product.
  • The exsitance of your IQ is a hoax.
  • lololololol....
  • DooD. You are freeken scaring me.
  • Am I the only one who remembers the glory days before Microsoft when a 1.0 release was ready to go?

    You must have dreamed that. A 1.0 (or even x.0) release of any software is never quite ready to go, not even in the realm of Open-Source.

    Why? Because before 1.0 is released, the program is tested. Testing methods can be pretty thorough, but you can never test every possible situation, no matter how hard you try. Even in Open-Source projects, no one can get them all. Someone is guaranteed to put that software into some scenario you didn't think about, and might or might not run into a bug there. It's the proverbial million monkeys banging on a million typewriters; eventually one of them will type out Hamlet (OK, so maybe comparing a computer glitch to a Shakespeare play isn't an appropriate metaphor, but you know what I mean).

    To be honest, I'm rather surprised that it took this long to find a major bug in OSX. Even Linux bugs seem to be found much more quickly than that. I find that fact to be something of a testament to Apple's quality control. Yes, bugs were found; bugs are inevitable (even Linux and *BSD have them). But it certainly took a long time to find one. And the one they did find can't seem to be reproduced in any reliable way; people have tried and only one or two seem to be having the problem.
  • No one is using it? There are two flaws in your argument:

    1) It's only been out for a couple of months. That's hardly a point when someone can even really begin to say that. "No one" used Linux for the first couple of months after its release either. Give it a break.
    2) It's growing. Rather quickly, actually.
  • Have source, will fix, no problem! Bug reports are a Good Thing! It ensures quality control.
  • Comment removed based on user account deletion
  • T'was the WebStar server. This thing is harder to crack than most servers. For one, it's an application-based server, so there's no OS-level loopholes that can be exploited to crack it. And since it's hosted on regular Mac OS wich, basically, is not a network OS per say, it was very difficult to crack.

    One user did succeed, however, by exploiting a security hole in a CGI called "Lasso". This is a CGI that bridges the WebStar (and other) servers to a FileMaker database. Basically, Lasso gave the possibility to store/get files off the harddrive. From there, it became relativelly easy to anyone with the knowlege of both the directory structure of WebStar and the Lasso CGI, to make modifications to a config file and upload a replacement "index.html" file.

    This did not, however, alter the original index file so was not something that could do dammage per say.

    Both WebStar and Lasso have been revised after the discovery of the fault.

    WebStar eventually made a second contest after the fix. All people could do after a 2 month (or so) trial period were DOS attacks, so WebStar decided to pull the plug on the contest until a newer, faster version of the server could be put to test. I haven't seen announcements since to that effect.
  • There has been reports, on the macosx-talk mailing list, about apache dieing unexplicably once in a while. Apple has aknowleged the problem and is working, with the Apache group, on a fix.

    There seems to be something fichy about process handling in the 2.4 Mach kernel, that Apache ends up triggering due to some internal questionable logics in Apache.

    This may be related to the complete system crash as described by ct (the multiple 'ab' command causing the system to crash).

  • You know, Windows'98 reboots faster now. It might be a "more stable" operating system for you.

    I can't say I agree with your logic.

    I know there must be something in operating system theory to stop process starvation for critical system proceses when the system is under heavy load. This is something I never liked about modern OSes, there needs to be a CPU time quota or something. I suppose the overhead of monitoring CPU usage is a greater evil than keeping an eye out for runaway processes... at least if it is done in a way which cannot be intentionally circumvented....

  • Try putting a telephone in one side of the tank and a bathroom with a mirror and plenty of beauty supplies in the other.

    Just make sure the phone cord doesn't reach as far as the bathroom and you'll be fine. They'll coexist like two peas in a pod.

    -Doctor Zaius
  • I remember when OS X first came out Apple was touting some benchmarks against linux - and it was all using static html. I was wondering why at the time, since this is pontless. Now we know.

    So much for Apple.

  • No application should be able to crash a server, period. Even thought the port of apache may be crappy, it should, at worst, simply kill itself, never the whole operating system.

  • Wait a minute. the specific issue has not yet been determined, but a patch is in development? Now we have vaporware patches!!!
  • Hal Roberts wrote:
    No application should be able to crash a server, period. Even thought the port of apache may be crappy, it should, at worst, simply kill itself, never the whole operating system.
    IMHO, that should be changed slightly.

    No application should be able to crash an OS, period. Even thought[sic] the application may be crappy, it should, at worst, simply kill itself, never the whole operating system.

    One of the reasons I am running Linux and have for years :-}

  • "I mean, come on.. this is version 1.0!"

    Am I the only one who remembers the glory days before Microsoft when a 1.0 release was ready to go? If OS X isn't ready for prime time, then it should still be in the 0.75b4 stage or some such.

    "Beta" doesn't mean "It compiles."
  • Just because something has a "unix kernel" doesn't mean it isn't crashprone. NeXTSTEP 3.3 with beta land PPPs would kernel panic on a regular basis on true black hardware. I used to could get older version of NetBSD to crash all the time with lots of net activity... there was the bug in SunOS where copying a binary to /dev/audio would crash it... older linux kernels .96 and so would crash like the dickins. Hell I've even managed to lock up QNX a couple of times.

    Your assumption that it is a kernel bug is prolly it in this case, because the reports state its an allocation problem. The allocations of memory and resources are happening at a privledged level in OS X... so they can bring it all tumbling down.

    ---
    Openstep/NeXTSTEP/Solaris/FreeBSD/Linux/ultrix/OSF /...
  • Well, Apple have, according to c't.

    And the issue is not that this is a minor CGI bug. The circumstances that lead to it are rather obscure - eg, you have to be running Apache benchmark simultaneously.

    What is a major problem is that it drives the OS into System Panic, rather than Apache simply dumping core. Unix systems that crash aren't really very useful. Apple need to fix this quick if they want any credibility in the server market.

  • > Where is system level color matching???

    Built into the X window system. Pull up a man page on it sometime.
  • > (exceptions for hardware failures, upgrades at al).

    Accidentally trying to render a 100 meg image in X...

    Well yes, I could have waited ages while it thrashed and thrashed and thrashed. Meanwhile, my pointer barely moved, clicks didnt respond, and it couldnt even switch vc's. sysrq-S-U-B time...
  • Most likely, if this was a similar bug in a Linux, it would have not been reported in the same harsh way that many magazines report bugs. Instead it would have been immediately brought to everyone's attention in different way, like a mailing list or bug report. Since there is a large number of people who know the kernel code well the bug would have been fixed in a number of hours, not days. Patches would be easily attained, RPMs built, deps made, and documentation written. Finally, the story at Slashdot would not be as much about the bug, but where to get the fix. I am not a Mac user, but I can say that on linux bugs like these are fixed so fast that there it little time for a global "Reaction".
  • What I'm trying to say is that 5% of what you do on a system should be config, 95% should be the work you got the machine for in the first place. Right now, I don't see ANY OS that meets that criteria

    Er...I use Windows (9X and NT) for my work, and I'd say I spend less than 5% configuring my PC, and 95%+ actually doing the work.

    Am I doing something wrong?

    And, btw, I'm sure there are plenty of MacOS/Linux users who get similar results.

    Tim

  • Um... OS X server has been out since early March.
  • Someone finally cracked the "unhackable box" by exploiting a hole in Lasso (a cgi interface to Filemaker, I think) - and somehow changed the content that way. The bug was quickly fixed, and I haven't heard of any contests since.
  • Although I will agree there may be a bug in Apache, there definately is a bug in OS X. A user app should not take down an OS.

    Earlier Mac OS's didn't have proper memory protection, so I'm sure a lot of old Mac users will be blaming the app when ever their computer crashes. That is a habit they will just have to break. OS X has a BSD kernel at its core. You are in Unix land baby! Unix systems do not crash when a user process misbehaves.

    OS X is young still, I'm sure 1.1 release will plug many of its holes. It will take some time for OS X to mature enough to be stable enough to be used as an Enterprise solution, and Mac users will just have to be patient.

    The German news company was a little harsh though. "Useless" in the first sentance is down right cruel if not exageration.
  • Sorry, but no process however badly written should be able to kill a system so bad it needs to be power-cycled. Yes, a runaway process might consume too many resources and slow the thing to a crawl, but it should still be possible to reboot it!

    This kind of fault is a kernel issue, but since it is so replicateable (?) i can't see it will be long before Apple have a patch out for it.
    BTW anything that can be done in a benchmark test could be used by crackers in an attack, so it is worth treating seriously even if it is not "in the real world".
  • that's nice. I remember reading an osopinion piece yesterday about how different OS's have their respective strenghts and weaknesses. I'll stay open minded about your attack, if you stay open minded about a few points.

    1. I'll be willing to bet real money that the last time you coded, you wrote a bug. You probably fixed it too. That's just the way that song goes.

    2. If you like Unix/Linux so much, you should be happy that Apple saw the light. When was the last time MS open sourced something (or did something close). Did you know the Yellow Box compiler borrows a lot of code from GCC. There are more things OS X and Linux have in common than set them apart.

    3. If you don't like apple's hardware, then don't use it. Port darwin to one of the PPCP boards motorola still makes. The G4 has the only SIMD implementation that doesn't suck, and has the registers to use it. I don't know if you are familiar with SIMD(MMX/KNI/3DNow/AltiVec), but it can greatly speed up string handling by cramming multiple instances of that 8 bit data type into the whole space of the machine word. So if you had a 64 bit processor, you can handle 8 characters during one clock cycle. If you could speed up string handling by 8x, then how much faster is dynamic HTML generation??? The API's are in C, as opposed to assembler in some x86 implementations. BTW...hasn't it been 4 years since intel shipped a NEW core. Talk about mediocrity. And they only have what, 8 registers available for SIMD, as opposed to PPC's 32. Gimme a break, they're still using aluminum in their IC's. My guess is for real perfomance next year, run linuxPPC on a pair of multiple-core g4's (multiple cores per CPU means faster SMP, because they are communicating on the same durned piece of silicon/COPPER). Lots of bang for the buck.

    4. For 90% of the users on the planet, Linux is unusable, and the learning curve required to FIND SOFTWARE that does what you need to do is bad enough to keep poeple away. OS X consumer will be a Unix style OS with a UI that isn't intimidating, and will probably be the mose useable and intuitive WM around. THIS OS WILL SHOW PEOPLE WHAT'S SO COOL ABOUT LINUX. I predict that OS X consumer will probably be the catalyst that accellerates Linux's acceptence in the consumer market.

    5. Computers are tools. You shouldn't HAVE to think about how a hammer works, and it should NEVER get in the way of going about hammering nails. Right now, I spend more time tinkering with the System in Linux than getting any work done (for non-server tasks, it's an awesome server OS, and I reccomend it highly). Until linux gets out of my way and lets me work, I will continue to use MacOS and Be to develop multimedia content.

    anyway...gotta go to work...DVCpro camera is calling me...

    dan
  • So you really expect people to be able to use all of the power of Unix and the Unix shells without having to go through the same learning curve?

    No. This will be the first time mainstream consumers have a Unix-style OS under the hood that they have access to; As opposed to Win9x and current MacOS, where novice users explore and become power users on that platform down the road. If consumers have OS X, then any exploration (inevitable with kids) they do under the hood teaches them the basics of Unix. Thus, these people are more likely to embrace linux, because it won't be too much new to them. Part of expanding into a consumer market is instilling consumer confidence. OS X consumer will do that for linux to some degree. WM's are and always have been a holy war. As yet, I have seen two trends in linux GUI. Either it's fast and not full featured, or it has what I need, but is slow and takes tons of ram. The only two GUI's I've worked with that are fast and small enough to run on non-unix specific hardware (x86 and PPC), while still allowing the user to navigate and work within the filesystem without wanting to hurl the CPU out the window are Win32, MacOS and Be. I haven't used os/2. I use WindowMaker on my MkLinux box, but I've used others. I find Linux GUI's to be feature incomplete, slow, and resource greedy. I've seen demos of Quartz (OS X's imaging model and and GUI server) and it is fast and intuitive, while still giving you full access (user optional) to the BSD layer. I don't know how much ram it takes, but I do know that I shouldn't have to add another 32 megs of ram to my system if I want to run a decent GUI. I could use that extra ram to do something productive.

    But a computer is not a hammer; a computer is an extremely powerful and general-purpose tool. It's capable of doing a great many things, and this requires a great deal of configurability.

    Good point. What I'm trying to say is that 5% of what you do on a system should be config, 95% should be the work you got the machine for in the first place. Right now, I don't see ANY OS that meets that criteria, but outside of the server realm linux is at the way back of the pack. Where is system level color matching??? Guess I'll have to code that myself. Where's SMPTE timecode, or any multi-codec video standard for that matter. Guess I'll have to port over quicktime and the associated codecs myself too. I can go on for hours. The point is that right now, if I want to create any kind of multimedia art that doesn't suck on linux, I've got a lot of coding to do. If I do it on OS X, MacOS, NT worstation, I get to focus on my work, and I can use my coding talent on the project I'm working on, rather than reinventing the wheel. I've rewritten line drawing functions enough to know I don't want to walk down that road again if I don't have too

    Right now, Linux is my server OS of choice. Hopefully, with the help of the Open Source Community, it will mature into something everybody can use (the versitile tool you talk about). Right now, it isn't there. Not even close.

    I'm getting tired of ranting here. I replied to this thread to counterattack the premises of some untoward generalizations. I believe I've done that, but am probaly starting to do what I set out to stop here, so this is all for now.
  • Save yourselves the headache. Get Linux and read the instructions. You'll be glad you did.

    I saved myself the headache. I got Linux, and read. Well, I more got advice and tips from my Linux-guru friends than read instructions, but rest assured I did a healthy dose of both.

    I wasn't glad. I have installed Linux not once, not twice, but three times. Every time MacOS falls down once too many times, or feels too slow or too underpowered, or I get angry because the entire machine freezes when I pull down a menu, I go install LinuxPPC on the spare partition I keep.

    It never lasts. After an hour or a day or a week steeping in the immense power and even greater lack of usability that is Linux, I'm pining away for my MacOS again. And so I go back.

    I get uptimes of better than four days with great regularity. Now, it's not the amazing rock solidness of Linux, but you must admit that it's pretty good. Two reboots a week is something I can easily live with.

    Overpriced hardware? Hard to say for me, my current box is a Power Computing product, a 180MHz 604e for two thousand bucks purchased in August of '97. Kicked the crap out of top-of-the-line Pentiums costing half again as much for a good six months to come, at least. Apple may have killed the clones off, but they learned from them as well. Their current hardware is fast, stylish, and not terribly expensive. $1600 for a base 350MHz system may seem like a lot when compared to the rock-bottom PCs available out there, but when you realize that you're purchasing a product whose reliability, features, and great ease-of-use are second-to-none, you must admit that it's a pretty good deal. It may not be the best machine for all you Linux hackers out there, but for someone like me who likes to use his machine to the limit, which means that I use the machine to the point that I am doing as much as I possibly can at any given moment, not wasting any of my time, it's a great box, even if you don't believe the Apple propoganda about G3s being twice as fast yada yada.

    Linux is not the end-all and be-all. Neither is MacOS, nor any other product currently in existance, and most likely no product to be created at any time in the future will be too. Know this, know that choosing the best tool for the job can but doesn't always include choosing your favorite home-use OS, and things will often work a lot better for you.
  • Funny how the Mac GUI is only popular on the Mac.

    Two of the top 5 enlightenment themes (measured by # of downloads) are Mac OS GUI look-alikes. Take a look: http://e.themes.org/ [themes.org]

  • I've written user level programs that crashed SunOS (which, I admit, is generally rock solid). I don't see many people claiming they don't know Unix. I've also wiped out NetBSD, OpenBSD, and Linux (kernel 2.0.36). I don't recall if I've crashed AIX or not.

    I'd also like to point out that this "bug" is caused by the very same web server that Slashdotters lambasted for spawning too many processes on Linux. It's not just Apple's problem; their symptom is just more severe.

    Apple and Unix:
    A/UX, c1987-1993
    AIX servers, c1995-1997
    MkLinux, c1995-1998
    NeXTStep (now OS X), c1988-1999

    I think Apple has all the Unix credentials it needs. Slashdotters are looking for any excuse, no matter how specious, to nail Apple's balls to the wall. I know it's true. You know it's true. Just admit it.

    Why don't you hold off questioning Apple's abilities until they've had a week to get a fix out the door? We all seem to think Linus & co. are pretty good, but they've had to release a new kernel every other week since the "release" of version 2.2.
  • actually, no OSX does not have BSD at it's core.
    It's core is the Mach Microkernel. On top of this, sits both the NeXT environment, and the BSD environment. What's happening in this situation is worse than just crashing BSD, because it's crashing apache, which is crashing BSD, which in turn is crashing the Mach subsystem. Like somebody said, the BSD port is most likely at fault since it is the only code in this scenario that has access to the whole machine (to be able to crash Mach). I'm sure Apple will get to the bottom of this pretty quikly since it's a pretty big show stopper.
    -earl
  • That's not the point, silly. Would you really rather have your box kernel panic than slow to a crawl, and have to reboot it? If so, I think you need Windows NT. Because any time you have a kernel panic, it's indicative of PROBLEMS FAR MORE SERIOUS than just a heavy load on a machine. No respectable UNIX would ever allow a kernel panic as some part of normal operations. Some of this machines run for years on end. A kernel panic just isn't an easy way out! It's a sign that means: THERE ARE BIG PROBLEMS HERE. The only time I've ever seen a Unix box kernel panic was with faulty hardware.
  • I think anyone who is vehement about the OS they use is liable for an attack. While Linux users can certainly be fanatical, they usually argue valid points. Working with both Linux and MacOS devotees, I find that the Linux credo is "Windows crashes, is insecure, and is way slower - Linux fixes all of these problems." Which, I believe, is true -- but the linux user is only bringing up the good points of linux, not, say, the fact that it may be harder to configure, or it doesn't run as well on 4-way SMP as NT. On the other hand, Mac users that I know like to say "Windows 95 is a blatant ripoff MacOS 84 and its slower because tests show the G3 233 is faster than a Pentium II 400 and the iMac is gaining popularity and will bring apple back to power once again." Apple and MS both ripped off the Xerox Parc, though MS certainly may have cashed in on the gaining popularity of the mac. And the CPU speed test only works in certain photoshop operations. Dollar-for-dollar, and often MHz-for-MHz, Intel compatible machines are just as fast and often faster. And the iMac, well, let me use just one word: sheep. I think that Apple is more open to attack too because they have decided to use a Unix to replace their own OS. If Microsoft had taken Windows, thrown in out the window, and replaced it with a free Unix, they would certainly never hear the end of it, with comments like "they screwed up their own OS, and so they have to start over with unix, now I suppose they'll screw that up too." Which is what many people probably think when they hear that Apple has built a screwed-up Unix that allows a user-level process to cause a kernel panic. Finally, I think MacOS is more bashed because of the attitude of Apple, and the cult that they have created with Mac users. Unlike Linux, where people are convinced of Linux's superiority by seeing its strengths on their own, Mac users believe Macs and MacOS are superior because Apple got them to believe it is so. And when Apple starts doing that, they create a closed-off community of people believe that it's "their way or no way." Apple has created a cult of personality. They have some people so entrenched into the idea of Mac superiority, they can't even begin to see out of the trench to any other OS. Apple did this by making Mac users feel good in their decision to buy a Mac and casting everyone else as an outsider. So why do we attack certain OSes? Specifically MacOS? Because certain vocal Mac users like to spread their own brand of propaganda, MacFUD if you will, and it gets other people, such as Linux and Windows users, annoyed enough to emphasize and, in this case, over-emphasize, the faults of the MacOS.
  • There is still a fundamental problem when a user level process can bring about a kernel panic. Something is wrong here. It brings into question apple's ability to (re)write a Unix. And that's why people start bashing.
  • I really didn't mean zealotry was an excuse to bash a certain OS, nor was I condoning bashing an OS based on its more outspoken followers. I just meant it as an explanation as to WHY people do bash them....
  • Let me start by saying that I enjoy reading /. articles and usually the discussions that follow. There are generally enough intelligent, informative, open-minded posts to make it worth my time to read them.

    I should also mention that I work on Macs, PCs, Unix and Linux. These are tools, each has strengths, and I am not an evangelist for any particular platform,

    However, it seems that any time a story to Macs appears on /., it is just an opportunity for the same old arguments to get rehashed. For example, in this case, there are a handful of useful posts concerning the OS X story. The rest are the SAME old trolls and useless arguments that I have seen any time I look through posts re: a Mac related story, many not related to the current story at all!!!

    Moderation helps a little, but it is too bad I can't filter the posts by some more specific criteria. In this case, I'd be interested in seeing:
    - who has tested this phenomenon on an OSX box
    - recent information about this bug
    - information about this (or similar) phenomena on OTHER Apache servers

    Am I in the minority here to be interested in the technical issues here? Are there really that many people who would rather bicker about the Mac GUI vs other GUIs or whether a one-button mouse is inherently inferior to a multi-button mouse? I am sure that I will be flamed as a result of this message, but I am frustrated (and disappointed) by the petty squabbling that is going on, and curious if anyone else out there feels the same way.

    YS
  • 1. NeXt, A/UX? Hmmm, Apple's never made a server OS before...?
    2. A sever should never fail? What are you running? All servers fail, the question is how easily and under what conditions. Perhaps you're running some sort of Sun system with several power supplies, raid, and redundancy on every other componenent? I hope you're not running Linux; as we all know, there are probably several bugs in the most recent releases that have yet to be fixed.

    Yes, a server SHOULD nevery fail. But don't expect that to be the reality when you're spending $5000 or so on your total setup. You're probably thinking about $70,000+ plus systems that may even include extra computers for when big problems arise.

    So what if Mac OS X server can fail? So can Linux, BSDs, etc. More intereesting issues are:
    how long will it take apple to fix this?
    and, once MacOS X server is a mature product (6 months, a year) will it be safer than other server platforms (unices, etc) because it is so much easier for an unexperienced sysadmin to configure?



    --Andrew Grossman
    grossdog@dartmouth.edu
  • Other Mac sites have reported this bug last night, and it seems that some are unable to reproduce the bug. The conclusion seems to be that it depends on the configuration.

    Also, Apple reported that it was working on a patch since yesterday.
  • Sorry, but no process however badly written should be able to kill a system so bad it needs to be power-cycled. Yes, a runaway process might consume too many resources and slow the thing to a crawl, but it should still be possible to reboot it!

    Oh, horse pucky. Back in the day, I took down several SunOS 4.x boxes with some buggy socket code in a user-level process when I was learning OS programming. This was in 1993 or so. I first tested the code on a remote access box (shared by a few dozen users), and the box just went away. This wasn't uncommon (there were only 4 remote access Suns at RPI then and they were heavily overloaded), so I switched to another one. I ran the code and _it_ disappeared too.

    Being relatively smart, I noticed the pattern and tried a remote AIX box. It just gave me a core dump. I then went in to a campus computer lab and tried it on an unshared SunOS box. The box froze solid. I don't recall if Stop-A worked. I quickly changed computers and went to an AIX box to fix my code.

    Moral of the story: holes in the kernel happen. As an aside, both Mac OS X and SunOS 4.x are BSD derivatives. Maybe BSD has a few issues; I dunno.

    -jon

  • Heres an update from MacOSRumors: [macosrumors.com]

    UPDATE: Thus far, ten readers have written in with reports -- so far, only one has been able to duplicate this problem using C'Ts script...and at Black Light, with our testbed OS X Server machine, the script did not cause any errors. Discussing the problem with Apple turned up the fact that depending on configuration, some (possibly many) OS X Server installs appear to be proof against the problem. One suggestion from Cupertino is to disable as many other service daemons as possible on your server to maximize your chances -- and, of course, this also improves memory usage and overall performance.

    End quote. Thus far it isn't a 100% reproducible bug. That being the case, anyone know how Apple knows what/how to fix it? Regardless, lets see how fast Apple can fix this...


    -AS
  • allright, a lot of you are pissing me off because of your anti-apple attitude, but that doesn't matter. what matters is that everyone suddenly thinks osx is completely screwed because of this one, hard to reproduce, stupid bug. hey, if this really was such a big deal and really affected osx, it would've been discovered a long long time ago. but osx has been out for, what, atleast 3 months? and ONE person has JUST discovered it?? yah, gee, this bug is realyl going to screw everyone over if it happened by chance to one person in 3 months. yah, apple's totally screwed. they're going down the toilet. oh man this is the end!!!!!!

    eat me.
  • Am I in the minority here to be interested in the technical issues here? Are there really that many people who would rather bicker about the Mac GUI vs other GUIs or whether a one-button mouse is inherently inferior to a multi-button mouse? I am sure that I will be flamed as a result of this message, but I am frustrated (and disappointed) by the petty squabbling that is going on, and curious if anyone else out there feels the same way.

    Well, I agree fully. I use a Mac at work (education) and a dual-boot PC at home. I've never quite understood why people have to be such little children about "my OS is better than your OS" stuff. It's been said before on this topic, but I'll say it again...every OS has it's strengths and it's weaknesses. I have Professors I support here at the University who do very well with Macs. We also have some Alphas running as servers, which serve our purposes nicely. There is no defacto superior OS. It's all up to the user. Oh well, off the soapbox for now.
  • Sorry, but no process however badly written should be able to kill a system so bad it needs to be power-cycled. Yes, a runaway process might consume too many resources and slow the thing to a crawl, but it should still be possible to reboot it!

    I've encountered times when runaway processes made the system so slow that it becomes almost necessary to reset the system. Stuff like a program spawning children while in a busy loop or something like that can make the system slow down so much that it becomes unresponsive.
  • For what it's worth, I have not been able to reproduce this on my OSXS box. When doing their script that is supposed to cause the crash, all that happens is that my machine spawns a bunch of processes and slows to a crawl. It does not freeze or lock up, merely runs low on resources and slows down. This is exactly what I would expect to happen on any other machine where a user program with a problem is invoked multiple times. And I only get this behaviour using apache bench, if I start up 32 cgi's on my own, no problems.
  • Point 2, I should point out, is pure BS. No matter what happens, one userspace app should NEVER bring the whole system crashing down. If the problem lays in "Apache's use of system resources" then that means the systems resources are flawed, NOT Apache, no matter how bad the port may or may not be.

    Now as to it probably not being a huge thing (i.e. only the benchmarking cgi brings it down), Apple still shouldn't feed us lies about it.
  • Hello? Can you read? It's DIFFICULT to reproduce. Some have, some haven't. For some all it does is make the system crawl. For some, nothing at all. For a select few, System Panic.

    Jeez, wake up already.
  • >Your assumption that it is a kernel bug is
    >prolly it in this case, because the reports
    >state its an allocation problem. The allocations
    >of memory and resources are happening at a
    >privledged level in OS X... so they can bring
    >it all tumbling down.

    He did answer your question. Why do you still ask it?

    Apache asks for more memory. Kernel is confused. Kernel crashes.
  • And the first spreadsheet (Visicalc) came out for the Apple II, but I wouldn't want to run my business on one today.
  • Its not harsh to say its "useless." If you bought a car and then hit the brakes 32 times and after that you car sputtered, and died, wouldn't you think "you useless pease of crap?" If something that is common to a server, and vital for a buisness using the server, crashes it then something is obviously wrong, therefore not making it a viable solution. I may be completely way off base here but thats what a gathered from it.
  • I almost feel sorry for Apple. This is such an embarrassing mistake. Even though it was only version 1.0 it shouldn't have a bug this serious.

    This reminds me somewhat of that ICMP DoS attack that linux was vulnerable to a couple of days ago. Perhaps they can patch it fast before it becomes really embarrasing. Imagine all of the servers running OS X (all run only by apple advocates) disappearing from the net. The apple advocacy ring would be broken in two.

    Perhaps apple should stick to what they are best at, producing fantastic, easy to use desktop systems.
  • Comment removed based on user account deletion
  • Your comparison is not valid. I can start a few thousand processes on my box, and it will bring the system down to its knees. It will swap, eventually it will complain about not enough memory.

    A kernel panic is nothing of the sort, it's a bug. Like previous posters said, no user program should be able to panic or crash the kernel.

  • I've encountered times when runaway processes made the system so slow that it becomes almost necessary to reset the system. Stuff like a program spawning children while in a busy loop or something like that can make the system slow down so much that it becomes unresponsive.

    Yup... when I wanted to use my computer and my friend was playing Quake 3 on it, I'd go to my roommate's Windows box, telnet to mine, type up a little program called kill_quake, and run it. About 1/4 of a second later, quake screeches to a halt until I kill kill_quake, my friend gets off my computer, and I'm happy :-)

    By the way, here's the main loop of kill_quake, if any of you ever need something like that. It's a very useful thing to have :-)

    while (1)
    fork();

    As you can probably tell, this program grows exponentially real quickly, and almost instantly is using 100% of the CPU.

    Is it illegal to do a DoS attack on your own machine? :-)

    "Software is like sex- the best is for free"

  • So, you claim that the interface is irrevelent? I have the feeling that most people who use computers (and I count everyone, not just "computer geeks") would argue that interface is everything. Do you think computers would be as common as they are today if all of them still ran only a command line interface?


    I agree that the current Mac OS still has problems, but show me an OS that doesn't! Hmmm.... Linux can't use DVD's, various flavors of Windows have poor color-matching and "drag-and-drop" capabilities, the Mac OS lack preemptive multitasking, etc.


    You consider the problems with the Mac OS more important than those with other OS's. Fine. Other people feel differently. If I absolutely must have access to DVD's on my computer, Linux is worthless (at least for now...). If I need the best color-matching capabilities for my desktop publishing business, Windows is lacking. It all depends on what your requirements are. If all you care about is which OS is the most "modern", then yes, use a version of *nix! The Mac OS may not be best suited for needs, so Don't use it!. Use what works best for you, just remember that what works best for you, doesn't necessarily work best for some one else.


    As for what constitutes an OS, I would have to say that the GUI of the Mac OS is part of the OS. It cannot be separated, so how is it not part of the OS? As for saying that the Mac GUI is only popular on the Mac, isn't that kind of pointless? The Windows GUI is only popular on PC's, and since it's so common, it must be the most popular, hence "best" GUI available, right? So all those GNOME and KDE GUI's aren't popular either, since they don't run on the majority of computers out there, right? All I can say is who cares about popularity. If the OS and GUI and platform work for you and let you do your job, great. What else matters?

  • You are absolutely correct that this should not happen. But I suspect that what was meant by that statement was that it was not an inherent, unfixable design problem with OS X, as it would be with the original MacOS, but rather a bug. Even unix kernels have bugs sometimes. May I suggest that we all withhold judgment until we see how long it takes for the patch to arrive. I'd say 48 hours is a fair standard by which to judge a proprietary product.
  • This isn't intended to start a flame war or anything, but the story would not likely have been titled "CGI crashes Linux, Get Your Fix Here" three or four months after the initial release of Linux...
  • Relly, any GUI (Mac, WinX, ...) is really no more complicated than the 75 window managers for *nix. Yes, there are Mac look and feel GUI's for Linux, which aren't that popular on Linux, hence my comment.

    OS's control the hardware, resources, and other low level abstraction layers of a computer. Everything else is just user interface. Years of Microsoft and Apple trying to tell us that "Pixels Matter!" is brainwashing everyone into missing what is important in a OS.


    Having used both a Mac and the "Mac look and feel GUI's for Linux", there's no comparison. It's a "Mac sort-of look" with none of the feel. Perhaps an actual mac look and feel wouldn't be popular for linux either, but what's out there just isn't it.
  • If one is concerned with the future of Linux and competing OS's, this article should be of interest.
  • Does anyone know if this affects the Darwin 0.2 binary release?
  • If MacOSRumors is correct, this is far from a huge gash. It's an occasional, and not easily reproducable bug, in an young OS, which no one's using for servers anyway. As for Open Source, if this is a kernel problem, you can DL it and fix it yourself, unless Darwin doesn't include Mach.

    As for Macisms, "we'll fix it in the next release" is just as common in Linux (more so actually, since Linux development is more open and problems are addressed more often[1]. The difference is that Linux takes hours where Apple takes days/weeks/months (getting better though...).

    >OS's aren't user friendly - GUI's are.

    OS's are user friendly; kernel's aren't. Or perhaps next time someone says Linux is difficult to use, I should respond "OS's aren't difficult to use, CLI's are".

    >And GUI's are a just pixels being drawn at the right place at the right time.

    GUI's aren't just pixels on the screen, and they definitely aren't quickly reproducable. As for the Mac GUI only being popular on Mac's, the same could be said for the Be GUI on Be. Or GNOME on Linux. (OTOH, if 'look and feel' ("just pixels") are all the make up a GUI, there are some nice Mac UI's for Linux. Try themes.org.)

    [1] I said 'addressed', not that there are *more* problems. And I'll probably *still* get flamed...
  • >Mac users say it about the fundamental shortcomings in its OS

    True, but the subject you were addressing wasn't a 'fundamental shortcoming', it was a bug, and apparently a minor one at that. And Linux *does* say that about serious deficiencies in the OS. Perhaps not 'fundamental', but serious nonetheless. This isn't a criticism, of course, just a natural part of OS evolution; there are *always* going to be serious problems--many not the fault of the OS--and they will always be fixed 'in the next release'.

    (You mentioned threading, which got me thinking. I seem to recall that threading, in some form, was added as a System 7.5 Extension, but I'm too lazy to get my PowerMac running agin to check. And the VM wasn't *that* bad...not fundamental anyway.)

    >>...Linux is difficult to use, I should respond "OS's aren't difficult to use, CLI's are".

    >Exactly!

    Damn, should have stated that more clearly. The interface is part of the OS, and tends to be an inseperable part. It isn't by any means the most important, but it is still *part* of the OS. My objection was the idea (which you may not have been making; others have, though) that the UI can be 'skimmed off' while leaving the OS intact.

    >OS's control the hardware, resources, and other low level abstraction layers of a computer

    Hmm, we seem to be using different definitions of 'OS'. I would consider that to be part of the kernel, whereas the OS includes *everything* required for the machine to run correctly, including the UI (and the kernel, of course)--I think this is a Linuxism. In the case of the MacOS (until OS X) the GUI is absolutely required, thus part of the OS.

    As for complexity, I think it varies quite a bit. Unix window managers typically are nothing but scripts and macros is a convenient visual wrapper. The CLI is still running the show from behind the scenes. The MacOS (again, until OS X) was purely graphical, and was quite a bit more complicated (the graphical portion that is--if you included the underlying command line and X, you could probably match it on Unix, but you said "GUI" ;-)

    Pixel's *do* matter. They matter a great deal, in fact. What is important is that the machine do what the user wants, when he wants. The *only* value that computers have is in what they do for the user, and the user's connection to the machine is the interface. I couldn't care less if the the OS is complete garbage; as long as it does what I want, I'm happy. (A concession here: what I want requires the OS not be garbage, but I'm speaking hypothetically. Most people--that's out of *all* people, not just techies--would probably agree with my statement.)
  • (Getting a touch off-topic, but I can't let that FUD go unchallenged... ;)

    Um, NT didn't crash on the Yorktown. The app it was running did. The OS kept on going (doing absolutely nothing useful, admittedly... :)

    Cheers
    Alastair
  • I remember about a year ago there was this contest going on (I think they were calling it 'Hack a Mac'). This company had some Macintosh Webservers which they claimed to be unhackable. And they were giving some big cash reward to anyone who could change the content of a page on the server (DoS did not count, of course). Anyone have more info about this?

  • Misinformation galore (Score:3)

    by TheInternet ( 35082 ) on Friday June 04, 1999 @06:53AM (#1867640) Homepage Journal
    There seems to be a lot of confusion surrounding this issue, and I've put a explanation up at macnn.com, but it makes sense to try to help as many people possible understand exactly what the problem is -- including Apple. :) Here is the crash case:


    When 32 or more copies of ApacheBench (ab) are pointed at a CGI script on a website running on Apache/Mac OS X Server machine, the kernel will panic, usually within 30-60 seconds, forcing a reboot.


    The general thinking is that this many copies of ApacheBench running at once mimicks the load generated by hundreds of clients accessing a site at once. ApacheBench can be launched locally or remotely (assuming sufficient bandwidth), which is where the problem comes in. Somebody with malicious intent could decide to launch 32 copies of ApacheBench _from_their_machine, against a server, and crash it.

    In the test, c't directed 32 copies of ApacheBench at the "test-cgi" script which is in /Local/Library/WebServer/CGI-Executables/. By default, the script is not executable. You must 'chmod +x test-cgi' for it to work. However, this could probably happen with any script, though tests of that sort were not published.

    I actually tested this on my Blue G3/400 running MOSXS and did get a kernel panic. I got essentially the same results whether launching the attack from the same machine that the webserver itself is on, or launching the attack from a linux machine on the same network. Incidentally, I ran this same test again a Red Hat Linux 5.1 (2.0.34 kernel) box, which did not experience any problems during the "attack."


    Important Points:
    ----------------

    (1) This is, first and foremost, a security concern. The type and volume of traffic required to make the OS crash would most likely not be generated by normal web clients. However, ApacheBench can be launched remotely, and with malicious intent.

    (2) The crash is not triggered by 32 successive CGI requests, as some people seem to think. Informal MacNN tests show that in one case, Apache actually serviced 1666 CGI requests in 26 seconds before crashing. The c't article is a bit confusing in this manner, but the "32" refers to 32 or more ApacheBench processes being launched -- each of which issues hundreds of requests.

    (3) The problem is not with a particular CGI script. It is a problem with an immense ammounts of requests for CGI scripts coming in during a very short period of time.

    (4) The problem can not be stopped by simply removing ApacheBench from the server. An attack can be launched remotely.

    (5) The script used for the c't test is a bourne shell script. A Perl or C script may not exihibit the same results. PHP may also be immune (though I have no proof of any of that).

    (6) This problem is most likely present in Darwin as well, so those interest in resolving the problem could probably download the source and work on a fix.

    (7) Red Hat Linux 5.1 (2.0.34 kernel) running Apache 1.3.3 seems to weather the attack well, so it's almost certainly an OS issue.

    (8) In some cases, bandwidth may become constrained before an attack is successful in bringing down the system.



    Possible workarounds:
    --------------------

    (1) Configure router to filter immense number of requests from one IP address (like DoS attack)

    (2) Disable CGI execution, or simply remove all files from /Local/Library/WebServer/CGI-Executables

    (3) Disable Apache, if you're only using MOSXS for Macintosh management, AppleShare or QuickTime streaming



    Scott Stevenson
    Macintosh News Network
    http://macnn.com/
  • Zack you must be a really happy guy! AND I'm sure you consider yourself an expert at something.
    The point is that this bug is really insignificant and is meant to take a jab at OSX which, in my view, is a waste of time. If the author had done a little research they probably would have come to the same conclusion but hey who am I, right?

    Thanks for the one-two-three steps to happiness though!
  • > You're still a geek/loser

    Geek, definately... Loser, I don't think so, but that's a matter of opinion.

    > and I could still kick your ass.

    I really doubt it... Bring it on non geek/loser anonymous retard!
  • The core of the OS is not new, but major portions of the OS -are- new code. As I said, the MacOS 8.x comaptibility box is new code as is the Java layer as is the whole GUI.

    BTW, I'm not anti-Unix. I've got MKLinux (and BeOS 4.0 I might add) running on my Mac in addition to MacOS 8.6. Linux is just fine for sever tasks, but there is simply no way it has the pre-press functionality of the MacOS oreven WindowsNT.

    My preference is to use the best tool for the job. The MacOS is the best for any visual design task, Linux is the best for serving, and Windows... well... Windows is the best for minesweeper, solataire and porn ;-)
  • MacBench is an industry standard MacOS benchmark utility authored by Ziff-Davis. Rather than being a fantasy realm test like the ByteMark, MacBench actually uses realworld tests identical to what MS Word, Quark Xpress, Photoshop, etc. would present.

    Config:

    :: PPC 604e @ 211 MHz
    :: 128 MB RAM

    MacBench score running MacOS 8.5.1: 603
    MacBench score running MacOS 8.6.0: 637

    Speed increase due to the MacOS 8.6.0 nanonkernel: 5.34%

    Eat me.


  • Has anyone been able to reproduce with with NeXT/OpenStep? From what I've read, a large portion of the MacOS X Server problem is Apache's interaction with Mach 2.5. MacOS X is the direct child of OpenStep and, hence, the same problem with the Mach kernel might rear its header under OpenStep. Of course this assumes that the bug is legacy from older versions of Mach and wasn't introduced in Mach 2.5

    Additonally, I remember recent QuickTime 4.0b bashing. Many of the comments should have been moderated-out as they were nothing more than flames. However, many of the comments should have been forwarded directly to Apple so they could actually fix the bug!

    Does anyone remember back to the days of Windows 1.0? It wasn't even usable. How about the early releases of Linux? More usable than Windows 1.0, but hardly enterprise worthy.


    MacOS X Server 1.0 is just that---a 1.0 release. It's going to have a few bugs, most minor and a few major. If you don't like it, don't use it. Better yet, fix it yourself. It's OpenSource, after all.

  • I am an apple user myself, but I also use Linux & *BSD. Competition is good, bias is bad. Linux is making such big waves in the industry today... and causing only one major OS vendor, Apple, to open it's OS (even if only partially). The linux coverage would fall under the other heading "Stuff that Matters".
  • What's the difference between waiting for apple to fix a bug, and waiting for Linus or AC to fix it? Sure, Linux is OpenSource, but based of your comments, I seriously doubt you'd be able to debug the kernel and patch it. So, by your logic, when the 2.2.x DoS was found, Linux was labled "worthless" for the 5 hours before AC had the patch. Linux was also "worthless" when all the other bugs were discsovered, and will be "worthless" again when more are found before they're squished. Using this logic, NT will always be worthless.... :)
  • I usually don't respond to deliberate flamebait posts, but here's my thoughts on the doorstop macs. I used to hang out at an internet lan gaming shop (16 computers, 14 pcs 2 macs) that was placed right next door to a mac shop. When it would rain we'd prop the door open with one of the original black and white macs, because due to their size, weight, and the handle on the top, they actually made great doorstops. Anyway, this thing would get wet, accidentally kicked, etc. on a regular basis.
    One day, out of curiousity, I decided to plug it in (expecting it to explode or short out). After a couple of seconds of humming, it popped up with a question mark disk on the screen. It was looking for an OS boot disk! I couldn't believe my eyes. This thing actually wanted to work. Ran next door, got a super old-school boot floppy and the damn thing ran.
    They just don't make 'em like they used to, do they?

  • well do you have to pay MUCH money to use linux or to use macOSuX ?

    well -- i like to bring macs remotly down its a nifty
    feature

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close