Ordering a model with a manual transmission should help alleviate this. I've driven a standard Honda Insight and (if you only use the battery for passing maneuvers) a quick 5-3 downshift is more than enough to pass vehicles going at or slightly above legal highway speeds.
It actually does a better job of passing than some six-cylinder automatics. Of course, therein lies the problem -- most North American drivers expect an automatic. Continuously-Variable tranmissions (CVTs, found in the Prius, Insight, hybrid Civic and oddly, the FWD Audi A4) help a little, but they're not as quick to kick down as a manual.
Driving a hybrid is like driving a slightly weak four-cylinder, except that the hybrids usually have much more low-end torque. Its an active driving experience (ie, you have to pay attention to how you shift, rather than just flooring the accelerator), which 6- and 8-cylinder cruiser drivers aren't interested in.
however the problem was that voltage transients could occur if you did this.
Well no. Apple put in safeguards against this in every Mac from either the II (or IIx, or IIcx, not sure) onwards. You can yank and hot-plug ADB devices with impunity on any modern Mac. If you did manage to torch a 9500, then you did something very nasty -- speaking which, I don't think that anyone ever made PCI ADB boards. You could go PCI->USB->ADB with something like Griffin's USB>ADB adapter, though
Some ADB device drivers (Gravis Gamepad, ahem, ahem) had issues with this sort of thing, but generally it works as well or better than Windows' implementation of hot-plug via USB.
Care to back up this statement? I've used and supported both versions of IE (like it or not) and I've not seen any reason to say that the MacOS version is better than the Win32 counterpart.
IE 5 for the Mac was (once) the most standards-compliant browser. This was about a year ago, give or take -- Mozilla has probably since tied or eclipsed it. It wasn't any faster or more capable than IE for Windows, but it did do better in compliance tests.
Its a very nice browser, if a little long in the tooth and in need of an update. Progressing rendering would be nice.
So please explain to me why Microsoft is vilified on the site because they refuse to let OEMs change the look and feel of the Windows desktop? What your saying is that it's OK for Apple but not MS?
Because Apple doesn't have OEMs making Macintosh clones. Apple makes the hardware and the software. If Apple still allowed clones (which, depending on your opinion is either a good thing or bad thing) then maybe this arguement would be valid.
Apple is very much concerned with selling a "tight" system. Apple sells a branded product; as a result, look and feel is more important to them then, say, Dell (who sells a commodity product where a consistent interface takes a back seat to power and/or price).
Now I'm not sure if its such a good idea for Apple to lean on developers who produce products with a non-standard (or just plain ugly) interface. Its really up to the developer to make his/her/their product look like a Mac app, especially since Mac users are more intolerant of un-Mac like products.
On the other hand, maybe Apple should've slapped Microsoft down for Word 6 for Macintosh.:)
BTW, I thought MS fought the look and feel battle with Apple ages ago when Apple took them to court over Windows looking like Apple's OS. Didn't the judge rule in favor of MS, and wouldn't that still apply to everyone copying Aqua's look and feel?
That suit was more generic: it was more like "the concept of a GUI". Protecting Aqua is about protecting a brand or an image. Its the same thing that prevents one car manufacturer (Daewoo, for example) from rampantly poaching another's body design (say, Porsche's Boxster). What Apple wants to avoid is
Someone outright cloning the whole interface (and maing money off Apple's design and interface work)
Making an application that weakens Aqua as an asset (either by using it outside the Mac OS or by creating an Aqua app that grossly violates the UI guidlines and makes the system harder to use).
That's what Apple wants. Whether this is wrong or right depends on your own views.
As far as I understand (not much, admittedly), MacOSX handle Mac OS9 by loading OS9 and letting it handle its executable.
Sort of -- it does boot up a Mac OS system, but its not entirely a closed box (the traditional Finder isn't run and a few services are directly piped to their MacOS X equivalent rather than run in a box. The CPU certainly isn't virtualised.
Its sort ot a hybrid between stuff like VMWare and the VDM system Windows NT uses to run DOS and Win16 applications.
If I'm correct, I don't see much difference than using VMware to run windows/linux.
Interesting question, can you run Mac OS9 on VMWare on x86?
Firstly, no, because VMware creates a virtual i386 PC, not a virtual Macintosh.
There are programs that will let you run a virtual Mac on an i386 PC but you need a copy of the ROM from a real Mac (which is copyrighted). I think most of the Mac emulators emulate a 680x0-based (non-PowerPC) Mac, so you would be limited to using Mac OS 8.1, but the PPC is a much easier CPU to virtualise than most of the i386 compatibles, so this may have changed.
If you were to put an Aqua skin on BSD, you are damn close to having a copy of Mac OS X.
No, you're not. For the record:
OSX is not based on *BSD. It's based on Mach 3.0 and has a (for lack of a better word) compatibility layer that's based on FreeBSD (3.2, I think).
It does not include X-Windows -- the windowing system is completely different. Aqua sits atop the Apple's Quartz display engine, which works a little bit like Display Postscript but uses PDF instead.
It would be hard to port an OS X application to other UNIXes because the app is written for Quartz and Aqua, not for X-Windows.
Quartz and Aqua are much more complex and (save for the ability to do remote displays, which Quartz does not do at all) much more capable than X.
Slap an Aqua-like skin on Gnome or KDE running on XFree 4 on FreeBSD -- you won't get transparency, scaling, font handling or colour correction to the same degree (if at all). The only thing both systems share is the console-accessible userland. The kernels different and the GUI is vastly different.
Ask a Mac user how to get a file listing of every file in a directory into a text document.
Lets see here...
Open the folder
Choose select all from the edit menu (or hiot command-A
Open SimpleText (or BBEdit, or Alpha, or, if you're a masochist, MacVim or EMACS) and hit Edit menu>Paste
Boy, that was hard. Want me to show you how get a list of files by type? [grin]
Sorry, I'm being snotty here, but it is possible. Granted, I can't grep that list..wait, if I use BBEdit, I can!)
Re:Reminds me of...A BIG mistake by Apple
on
OS X on x86?
·
· Score: 2
The iMac will run OSX quite well. There may be some speed issues running Classic applications on a system with less than 96-128MB of RAM, but native Carbon/Cocoa stuff works very well.
I've installed the public beta on a 233MHz iMac (64MB, Rage Pro), a 350MHz iMac (64MB, Rage 128 Pro) and a G4 (192MB, Rage 128 Pro). All of those systems ran the (admittedly few) native applications well. The two iMacs took a bit of a pounding when running Classic apps, but there were still quite usable.
Any G3/G4-based Mac (save for the original PowerBook G3 -- the 3500 model) will have no trouble with OSX. Some (like the early iMacs) would benefit from a RAM upgrade, but that's an easy, inexpensive update.
Come on, I think people are intelligent enough these days to be able to deal with more than one mouse button
Many people in Apple's target market aren't suited to 2+ button mice. Its not really a valid criticism -- Apple's serving Apple customers.
The operating system supports (sort of) two button mice, so its not really that limiting. Many applications don't support Apple's method of accessing the second mouse button (Microsoft, Netscape, ahem!) but that's not really Apple's fault -- if the developers don't want to use the system's services, that's their choice. OS X should do a better job of this, but if someone (Microsoft, Netscape) decides to write their apps with their own proprietary input handling and menu routines, Apple can't really be blamed.
I'm actually glad they stick to one button mice. Do end-user support for Windows and the MacOS and just try to explain right-click to someone over the phone. Its much nicer to just say "Hold down the control key and press the mouse button on..."
Re:Hardware support for new Macs, but will it inst
on
OpenBSD 2.8 Released
·
· Score: 1
I'd hope they'd install, I could sure use some more security than the Mac's current state.
If you mean more security than the classic MacOS, you won't get much from OpenBSD. The MacOS doesn't listen on any ports and doesn't provide a way to manipulate the rest of the operating system. Arguably, if its security you want, you can't really do better than the classic MacOS.
Mind you, its not security by design, its security by lobotimization. And the performance isn't great. But of all the things one can harp on the MacOS for, network security isn't one of them.
As to why someone would want MacOS X, well... There's those tiny little details like Quartz and Cocoa (aka: probably the best imaging model and one of the best APIs, respectively). But if you're going to run a server, those don't really matter, do they?
Run Netscape -- I just dare ya! X Apps? 16MB? Eh? [grin]
To be fair, OS X is more akin to running Linux + X + KDE/GNOME, which really doesn't start to work well with less than 64MB. Another point is that Apple tends to be more realistic about their RAM requirements than, say, Microsoft. When Apple says 64MB, you can probably swing with 32 or 48 plus virtual memory unless any single app (say VIrtualPC) needs a large chunk of memory.
The RAM requirement for Windows 95 was four megabytes (seriously, read the side of the box!); for NT 4, its sixteen. I don't have a copy of Windows 98 or 2000, but I recall (in Win2K's case) that the box requirements aren't really truthful.
A replacement for X? why?.. is X(XF86) not good enough? I wonder.
X has issues. It handles certain things reasonably well (displaying information on different terminals to different users across the network is probably the big one) but it has some pretty annoying limitations:
It handles fonts badly. There's no built-in way of antialiasing fonts, nor do fonts scale all that well. You can rely on add-on toolkits (like Motif, Qt or GTK) to overcome some of this, but what then you're locked into picking and choosing programs based on their parent toolkit. If X implemented this [properly] itself, then you wouldn't have these issues.
X doesn't handle screen dpi properly. Neither, for that matter, does Windows or the current MacOS. What happens when we screens arrive than can display 200dpi? Those icons that looked great at 1024x768x100dpi suddenly shrink to the size of half a rice grain. And the text below those icons...
X is very much bitmap-depedent. As above, bitmaps don't work that well when you start scaling stuff to different dpi's. Having just about everything drawn as a vector (or, if not, as a large and easily-scaled bitmap) will help. Again, Apple's Quartz works this way.
X is very much mired in an older way of handling displays. Windows has similar problems. The current MacOS does a slightly better job with font display, but is still unscaled-bitmap limited. Try X on a 1600x1200 display and see how small the icons, toolbars and window manager'ed window titlebars. Try changing the font to 18- or 22-point to compensate. See how badly this gets handled.
These are some of the issues Berlin hopes to overcome.
What I'd like to see in X/Berlin/UNIX-in-general is a link between the screen and printed output. Right now it's pretty hit-and-miss with X (Windows is a little better and the MacOS is pretty much bang on). I had hopes for the adoption of Display Postscript to solve this. For gamers or coders, this doesn't matter. For a web or [especially] a paper graphic designer this is a huge limitation of X. I'd trade 10-25% of X's speed for guaranteed output to print. As it stands, Apple's Quartz is probably the front-runner here.
X may suit you. X doesn't suit me. X is most certainly not suitable for everyone and needs improvement. Or replacement. Berlin is a step in the right direction.
Actually, do yourself a favour and forget that the RTL8139 even exists. It's a horrible, cheap and (in some cases) buggy card. I had one in a built-from-scrap workstation that locked up under traffic (under 2.2.12->2.2.15) waaaay too easily.
Replaced it with a Digital 21041-based card and things have been flawless since.
Well, as it turns out, either one or more of the hard disks and/or the motherboard's IDE adapter is broken.
If you buy crappy SCSI components they won't work properly either. Poor quality is not technology-specific.
No, but poor technology is more likely to show up in a standard designed to save money than a standard designed with higher technical merit. (Aside: the reason for IDE's existence was to allow hard disks to be plugged into a PC with minimal controller circuitry). You don't see very many bad SCSI peripherals, but that's probably because the SCSI market is one where the margin is a little better and manufacturers are less likely to skimp.
Another side note, though: there are some, well, less-than-stellar SCSI adapters available these days (no doubt shooting for the budget CD-ROM burning crowd). Not having a bus-mastering SCSI controller is sort of self-defeating. One might as well buy IDE and save money.
Obviously, no one is forcing anything down anyone's throat, as you proved by dropping in a SCSI controller.
I had the option, what with working in a largish company, of having two older Compaq servers I could garrote for parts. This would have annoyed me plenty were it my home PC and I'd found out my motherboard's IDE support was broken.
I'd like to see on-board SCSI become a commodity, but it would probably be done cheaply and there would be problems. However, its a nice sign, seeing AIC-7xxx chipset-equipped boards for only $50 more than the standard models. I hope IEEE-1394/FireWire/iLink gains more ground. It really looks like a well-thought-out storage standard.
What is UP with SCSI, anyway? You pay an order of magnitude more for the controller, and 1.5-2x for every device thereafter. Sure, it's better tech, but nowhere close to TWICE as good. I can only picture some smug bastards at the hd companies cackling evilly at the folly of the users paying so much for technology that didn't cost them a penny more than IDE to make.
I've always wondered that myself. If I understand IDE design intent correctly, the burden of circuit complexity falls on the drive manufacturer as opposed to the motherboard/adapter maker. (which is why they're not called IDE controllers) SCSI drives put the onus on the controller. I can see why the bargain basement IDE drives would be cheaper (ie, Quantum's el-cheapo BigFoot line) because they're skimping on every aspect of the drive. But why the ATA/66 and U2W versions of the same drive have such different price points, I can ony guess:
If you have faith in the manufacturers, its an economy of scale thing
If you think they're evil, its gouging the high-end market.
Moral, intellectual-property and patent-silliness issues aside, this will be a really amusing situation as it develops. One big semi-evil corporation going up against a bunch of mostly-evil corporations about the stupid/evil patenting of a concept that's being used for evil purposes by the aforementioned evil corporations.
Ok, so maybe evil is a strong word. Still, the number of bad karma sources (laywers, patents, banner ads, DoubleClick, domain name abuse, commercialisation of the Internet and multinational corporations) in one place has to count for something.
You're right, it is a little like feudalism, only the serfs don't have to get involved [grin].
Anyway I am going Adaptec 29160N and Quantumn Atlas 18.4Gb 160 scsi. screw ide.
Second that. Up until two days ago, I was getting really annoyed with having to pay a 1.5-2x premium for SCSI hard disks. Then I tried to set up a system with three hard disks and one CD-ROM, all IDE/ATA.
Well, as it turns out, either one or more of the hard disks and/or the motherboard's IDE adapter is broken. Nothing at all functions as a Secondary Slave (without appearing to the system as either a 32TB drive or an IDE floppy or something even wierder) nor will the CD-ROM function unless it's set up as a master device. This wasn't Linux-specific either: it happened in BIOS, in Windows, in FreeBSD....
So I decided to try installing an old Future Domain IDE controller, only to discover that FreeBSD won't recognize anything plugged into the third or fourth IDE adapters. Arg! Screw this, I sez -- So I haul out a slower, older Adaptec 2940, plug in five surplus narrow SCSI devices, set IDs, set termination, off to the races.
IDE should've been humanely put down years ago. Thank you, oh thank you, to the budget PC industry for forcing a twisted, augmented, Frankensteined hack of disk interface down my throat at every turn. It's even infected the low-end workstations, too (Apple, Sun, SGI). I can't help but think what a difference it would have made to the PC world if someone (chipset or motherboard makers) had made SCSI onboard. No crufty or incompatible parallel devices, no brain-dead BIOS limitations, no DMA-that-isn't.
Between IDE and the holdovers from the PC-XT and PC-AT (fifteen interrupts, half of which are already gone? 640k base memory limits? the ISA bus?)....
I've taken a numbe of courses offered via web-based systems and I've always been really disappointed by how badly the technology has been implemented. It usually suffers from one of the following:
Java/Javascript problems: I always end up using both Netscape (4.7x) and IE (5.x) because neither seems to be free from choking on Java/Javascript
Browser incompatibility: It seems like designers/coders usually target one platform and one browser with these systems (IE4.x/Windows) and just let other users rot. They're not too forgiving of low-power PCs or low-speed connections, either.
Speed: They're either using an underpowered server, a slow connection, or horribly inefficient code. Slashdot, speed daemon that it is, whups the courseware I've seen. [grin]
Ease of Use: Most instructors have real difficulty administering their courses. Assignments get losts, posts get deleted, student accounts disappear. These are CS instructors too, I can only imagine the grief and pain Humanities people go through.
The few sucessful forums I've seen use a mailing list. [with a separate address for sumbissions] The security isn't good, but the forum is very easy to use for both students and instructors. News would be an improvement in that you could support threaded discussions more eaily, but that would probably be offset by the pain involved in having to handle large binaries in broken newsreaders.
Personally, if they could do a web forum right, then I'd be a little more forgiving. The few I've seen have been bad to terrible, and they'll always be pretty slow compared to a mailing list or newsgroup.
But yah, one of the reasons that they arent here already is that we tax things to hell. So maybe they wont move for that reason too:)
First thing I thought was: "Those bastards [the BC government], how could they even think about something this sleazy?"
But then I thought "Health care funding from the taxes levied on both Microsoft the company and its better-paid employees" and it brought a smile to my face.
It's starting to look like 1990 all over again with a handfull of Computer companies providing all you could want at prices that DIYers couldn't try to beat.
When I stop seeing Slashdot posts that say stuff like:
"Why should I buy a G4/Ultra10/RS-6000/SGI O2 when I can get a Athlon for $1500 from my local shop" or....
"Why buy an S/390 when I can have a Beowulf cluster of Athlons?"
...then I'll agree that the screwdriver-shop market is dying. [grin]
The screwdriver-shop market is here to stay. There's too many hardware hackers (from genuine Do-It-Yourself hobbyists to low-budget professionals to 31337 h4x0r5) around now for that market to disappear. I happen to like built-for-me hardware (well, good stuff, like the G4) but I can see the value in screwdriver-shop PCs for some situations.
...things like Firwire and this new mouse will be standard.
It looks like there's a lot of crossover between the likes of Apple, IBM et al and the Franken-PC market. You can get Firewire (aka IEEE-1394) PCI cards for your PC, and Apple's mouse is probably going to be a standard USB model, so (provided it obeys the USB HID specs) you can use it on your PC as well.
I'd like to see Firewire/IEEE-1394 support on PC motherboards, but I don't imagine Intel (ahem, USB 2.0) would be too thrilled with that idea.
I can't help you with NIS-to-SMB/NMB/SAM Database integration (between an NT Server and a NIS Server) -- you'll probably need to use Microsoft's NIS Server for WinNT or Samba on UNIX.
Windows95 used to include the Sun PC-NFS client that might do what you're asking, but I'm not sure (as the last time I used Windows95 was several months ago and I don't have a test system to mess with).
If you're just trying to get Windows (NT) to log into an NIS domain, you can have a look at NISGINA. There's a neat article at LinuxWorld here. I poked around with this before I discovered Samba, but never really tested is. NISGINA's hopme page is here. NISGINA (and it's subsidiary utilities) come with source, too (which is nice).
Sun (I think..) also makes an NIS/NFS client for Win32 -- there's a technical run-through here. It's called the Solstice NFS Client for Windows and it probably doesn't come cheap.
Now, if anywone knows where I can get a cheap/free Macintosh NIS/NFS client... (and yes, I know about Netatalk, but I'd like to try anyways)
Slashdot Mirror
Ordering a model with a manual transmission should help alleviate this. I've driven a standard Honda Insight and (if you only use the battery for passing maneuvers) a quick 5-3 downshift is more than enough to pass vehicles going at or slightly above legal highway speeds.
It actually does a better job of passing than some six-cylinder automatics. Of course, therein lies the problem -- most North American drivers expect an automatic. Continuously-Variable tranmissions (CVTs, found in the Prius, Insight, hybrid Civic and oddly, the FWD Audi A4) help a little, but they're not as quick to kick down as a manual.
Driving a hybrid is like driving a slightly weak four-cylinder, except that the hybrids usually have much more low-end torque. Its an active driving experience (ie, you have to pay attention to how you shift, rather than just flooring the accelerator), which 6- and 8-cylinder cruiser drivers aren't interested in.
Pity, really..
Of course 7.5 would crash on a 7600. The 7600 needs 7.6 at the very least. :)
however the problem was that voltage transients could occur if you did this.
Well no. Apple put in safeguards against this in every Mac from either the II (or IIx, or IIcx, not sure) onwards. You can yank and hot-plug ADB devices with impunity on any modern Mac. If you did manage to torch a 9500, then you did something very nasty -- speaking which, I don't think that anyone ever made PCI ADB boards. You could go PCI->USB->ADB with something like Griffin's USB>ADB adapter, though
Some ADB device drivers (Gravis Gamepad, ahem, ahem) had issues with this sort of thing, but generally it works as well or better than Windows' implementation of hot-plug via USB.
Hey, anyone remember Access.bus?
IE 5 for the Mac was (once) the most standards-compliant browser. This was about a year ago, give or take -- Mozilla has probably since tied or eclipsed it. It wasn't any faster or more capable than IE for Windows, but it did do better in compliance tests.
Its a very nice browser, if a little long in the tooth and in need of an update. Progressing rendering would be nice.
Because Apple doesn't have OEMs making Macintosh clones. Apple makes the hardware and the software. If Apple still allowed clones (which, depending on your opinion is either a good thing or bad thing) then maybe this arguement would be valid.
Apple is very much concerned with selling a "tight" system. Apple sells a branded product; as a result, look and feel is more important to them then, say, Dell (who sells a commodity product where a consistent interface takes a back seat to power and/or price).
Now I'm not sure if its such a good idea for Apple to lean on developers who produce products with a non-standard (or just plain ugly) interface. Its really up to the developer to make his/her/their product look like a Mac app, especially since Mac users are more intolerant of un-Mac like products.
On the other hand, maybe Apple should've slapped Microsoft down for Word 6 for Macintosh. :)
That suit was more generic: it was more like "the concept of a GUI". Protecting Aqua is about protecting a brand or an image. Its the same thing that prevents one car manufacturer (Daewoo, for example) from rampantly poaching another's body design (say, Porsche's Boxster). What Apple wants to avoid is
- Someone outright cloning the whole interface (and maing money off Apple's design and interface work)
- Making an application that weakens Aqua as an asset (either by using it outside the Mac OS or by creating an Aqua app that grossly violates the UI guidlines and makes the system harder to use).
That's what Apple wants. Whether this is wrong or right depends on your own views.Sort of -- it does boot up a Mac OS system, but its not entirely a closed box (the traditional Finder isn't run and a few services are directly piped to their MacOS X equivalent rather than run in a box. The CPU certainly isn't virtualised.
Its sort ot a hybrid between stuff like VMWare and the VDM system Windows NT uses to run DOS and Win16 applications.
Firstly, no, because VMware creates a virtual i386 PC, not a virtual Macintosh. There are programs that will let you run a virtual Mac on an i386 PC but you need a copy of the ROM from a real Mac (which is copyrighted). I think most of the Mac emulators emulate a 680x0-based (non-PowerPC) Mac, so you would be limited to using Mac OS 8.1, but the PPC is a much easier CPU to virtualise than most of the i386 compatibles, so this may have changed.
No, you're not. For the record:
Slap an Aqua-like skin on Gnome or KDE running on XFree 4 on FreeBSD -- you won't get transparency, scaling, font handling or colour correction to the same degree (if at all). The only thing both systems share is the console-accessible userland. The kernels different and the GUI is vastly different.
Lets see here...
- Open the folder
- Choose select all from the edit menu (or hiot command-A
- Open SimpleText (or BBEdit, or Alpha, or, if you're a masochist, MacVim or EMACS) and hit Edit menu>Paste
Boy, that was hard. Want me to show you how get a list of files by type? [grin]Sorry, I'm being snotty here, but it is possible. Granted, I can't grep that list..wait, if I use BBEdit, I can!)
The iMac will run OSX quite well. There may be some speed issues running Classic applications on a system with less than 96-128MB of RAM, but native Carbon/Cocoa stuff works very well.
I've installed the public beta on a 233MHz iMac (64MB, Rage Pro), a 350MHz iMac (64MB, Rage 128 Pro) and a G4 (192MB, Rage 128 Pro). All of those systems ran the (admittedly few) native applications well. The two iMacs took a bit of a pounding when running Classic apps, but there were still quite usable.
Any G3/G4-based Mac (save for the original PowerBook G3 -- the 3500 model) will have no trouble with OSX. Some (like the early iMacs) would benefit from a RAM upgrade, but that's an easy, inexpensive update.
Many people in Apple's target market aren't suited to 2+ button mice. Its not really a valid criticism -- Apple's serving Apple customers.
The operating system supports (sort of) two button mice, so its not really that limiting. Many applications don't support Apple's method of accessing the second mouse button (Microsoft, Netscape, ahem!) but that's not really Apple's fault -- if the developers don't want to use the system's services, that's their choice. OS X should do a better job of this, but if someone (Microsoft, Netscape) decides to write their apps with their own proprietary input handling and menu routines, Apple can't really be blamed.
I'm actually glad they stick to one button mice. Do end-user support for Windows and the MacOS and just try to explain right-click to someone over the phone. Its much nicer to just say "Hold down the control key and press the mouse button on..."
If you mean more security than the classic MacOS, you won't get much from OpenBSD. The MacOS doesn't listen on any ports and doesn't provide a way to manipulate the rest of the operating system. Arguably, if its security you want, you can't really do better than the classic MacOS.
Mind you, its not security by design, its security by lobotimization. And the performance isn't great. But of all the things one can harp on the MacOS for, network security isn't one of them.
As to why someone would want MacOS X, well... There's those tiny little details like Quartz and Cocoa (aka: probably the best imaging model and one of the best APIs, respectively). But if you're going to run a server, those don't really matter, do they?
Run Netscape -- I just dare ya! X Apps? 16MB? Eh? [grin]
To be fair, OS X is more akin to running Linux + X + KDE/GNOME, which really doesn't start to work well with less than 64MB. Another point is that Apple tends to be more realistic about their RAM requirements than, say, Microsoft. When Apple says 64MB, you can probably swing with 32 or 48 plus virtual memory unless any single app (say VIrtualPC) needs a large chunk of memory.
The RAM requirement for Windows 95 was four megabytes (seriously, read the side of the box!); for NT 4, its sixteen. I don't have a copy of Windows 98 or 2000, but I recall (in Win2K's case) that the box requirements aren't really truthful.
No, that's what the Origin series are for. (ie, pistol-whipping these usurper Intel systems)
- It handles fonts badly. There's no built-in way of antialiasing fonts, nor do fonts scale all that well. You can rely on add-on toolkits (like Motif, Qt or GTK) to overcome some of this, but what then you're locked into picking and choosing programs based on their parent toolkit. If X implemented this [properly] itself, then you wouldn't have these issues.
- X doesn't handle screen dpi properly. Neither, for that matter, does Windows or the current MacOS. What happens when we screens arrive than can display 200dpi? Those icons that looked great at 1024x768x100dpi suddenly shrink to the size of half a rice grain. And the text below those icons...
- X is very much bitmap-depedent. As above, bitmaps don't work that well when you start scaling stuff to different dpi's. Having just about everything drawn as a vector (or, if not, as a large and easily-scaled bitmap) will help. Again, Apple's Quartz works this way.
X is very much mired in an older way of handling displays. Windows has similar problems. The current MacOS does a slightly better job with font display, but is still unscaled-bitmap limited. Try X on a 1600x1200 display and see how small the icons, toolbars and window manager'ed window titlebars. Try changing the font to 18- or 22-point to compensate. See how badly this gets handled.These are some of the issues Berlin hopes to overcome.
What I'd like to see in X/Berlin/UNIX-in-general is a link between the screen and printed output. Right now it's pretty hit-and-miss with X (Windows is a little better and the MacOS is pretty much bang on). I had hopes for the adoption of Display Postscript to solve this. For gamers or coders, this doesn't matter. For a web or [especially] a paper graphic designer this is a huge limitation of X. I'd trade 10-25% of X's speed for guaranteed output to print. As it stands, Apple's Quartz is probably the front-runner here.
X may suit you. X doesn't suit me. X is most certainly not suitable for everyone and needs improvement. Or replacement. Berlin is a step in the right direction.
Does IBM still make PowerPC-based laptops? I remember they did have a few models available a while back,but I've never found anything on IBM's site.
Replaced it with a Digital 21041-based card and things have been flawless since.
Jesus, that was funny...
No, but poor technology is more likely to show up in a standard designed to save money than a standard designed with higher technical merit. (Aside: the reason for IDE's existence was to allow hard disks to be plugged into a PC with minimal controller circuitry). You don't see very many bad SCSI peripherals, but that's probably because the SCSI market is one where the margin is a little better and manufacturers are less likely to skimp.
Another side note, though: there are some, well, less-than-stellar SCSI adapters available these days (no doubt shooting for the budget CD-ROM burning crowd). Not having a bus-mastering SCSI controller is sort of self-defeating. One might as well buy IDE and save money.
I had the option, what with working in a largish company, of having two older Compaq servers I could garrote for parts. This would have annoyed me plenty were it my home PC and I'd found out my motherboard's IDE support was broken.
I'd like to see on-board SCSI become a commodity, but it would probably be done cheaply and there would be problems. However, its a nice sign, seeing AIC-7xxx chipset-equipped boards for only $50 more than the standard models. I hope IEEE-1394/FireWire/iLink gains more ground. It really looks like a well-thought-out storage standard.
I've always wondered that myself. If I understand IDE design intent correctly, the burden of circuit complexity falls on the drive manufacturer as opposed to the motherboard/adapter maker. (which is why they're not called IDE controllers) SCSI drives put the onus on the controller. I can see why the bargain basement IDE drives would be cheaper (ie, Quantum's el-cheapo BigFoot line) because they're skimping on every aspect of the drive. But why the ATA/66 and U2W versions of the same drive have such different price points, I can ony guess:
- If you have faith in the manufacturers, its an economy of scale thing
- If you think they're evil, its gouging the high-end market.
It's probably a bit of both.Ok, so maybe evil is a strong word. Still, the number of bad karma sources (laywers, patents, banner ads, DoubleClick, domain name abuse, commercialisation of the Internet and multinational corporations) in one place has to count for something.
You're right, it is a little like feudalism, only the serfs don't have to get involved [grin].
Second that. Up until two days ago, I was getting really annoyed with having to pay a 1.5-2x premium for SCSI hard disks. Then I tried to set up a system with three hard disks and one CD-ROM, all IDE/ATA.
Well, as it turns out, either one or more of the hard disks and/or the motherboard's IDE adapter is broken. Nothing at all functions as a Secondary Slave (without appearing to the system as either a 32TB drive or an IDE floppy or something even wierder) nor will the CD-ROM function unless it's set up as a master device. This wasn't Linux-specific either: it happened in BIOS, in Windows, in FreeBSD....
So I decided to try installing an old Future Domain IDE controller, only to discover that FreeBSD won't recognize anything plugged into the third or fourth IDE adapters. Arg! Screw this, I sez -- So I haul out a slower, older Adaptec 2940, plug in five surplus narrow SCSI devices, set IDs, set termination, off to the races.
IDE should've been humanely put down years ago. Thank you, oh thank you, to the budget PC industry for forcing a twisted, augmented, Frankensteined hack of disk interface down my throat at every turn. It's even infected the low-end workstations, too (Apple, Sun, SGI). I can't help but think what a difference it would have made to the PC world if someone (chipset or motherboard makers) had made SCSI onboard. No crufty or incompatible parallel devices, no brain-dead BIOS limitations, no DMA-that-isn't.
Between IDE and the holdovers from the PC-XT and PC-AT (fifteen interrupts, half of which are already gone? 640k base memory limits? the ISA bus?)....
- Java/Javascript problems: I always end up using both Netscape (4.7x) and IE (5.x) because neither seems to be free from choking on Java/Javascript
- Browser incompatibility: It seems like designers/coders usually target one platform and one browser with these systems (IE4.x/Windows) and just let other users rot. They're not too forgiving of low-power PCs or low-speed connections, either.
- Speed: They're either using an underpowered server, a slow connection, or horribly inefficient code. Slashdot, speed daemon that it is, whups the courseware I've seen. [grin]
- Ease of Use: Most instructors have real difficulty administering their courses. Assignments get losts, posts get deleted, student accounts disappear. These are CS instructors too, I can only imagine the grief and pain Humanities people go through.
The few sucessful forums I've seen use a mailing list. [with a separate address for sumbissions] The security isn't good, but the forum is very easy to use for both students and instructors. News would be an improvement in that you could support threaded discussions more eaily, but that would probably be offset by the pain involved in having to handle large binaries in broken newsreaders.Personally, if they could do a web forum right, then I'd be a little more forgiving. The few I've seen have been bad to terrible, and they'll always be pretty slow compared to a mailing list or newsgroup.
Somehow, neither Bill Van Der Zalm nor Glen Clark really strike me as "Dark Lord" types. Goofy Lords, maybe... [grin]
First thing I thought was: "Those bastards [the BC government], how could they even think about something this sleazy?"
But then I thought "Health care funding from the taxes levied on both Microsoft the company and its better-paid employees" and it brought a smile to my face.
When I stop seeing Slashdot posts that say stuff like:
The screwdriver-shop market is here to stay. There's too many hardware hackers (from genuine Do-It-Yourself hobbyists to low-budget professionals to 31337 h4x0r5) around now for that market to disappear. I happen to like built-for-me hardware (well, good stuff, like the G4) but I can see the value in screwdriver-shop PCs for some situations.
It looks like there's a lot of crossover between the likes of Apple, IBM et al and the Franken-PC market. You can get Firewire (aka IEEE-1394) PCI cards for your PC, and Apple's mouse is probably going to be a standard USB model, so (provided it obeys the USB HID specs) you can use it on your PC as well.
I'd like to see Firewire/IEEE-1394 support on PC motherboards, but I don't imagine Intel (ahem, USB 2.0) would be too thrilled with that idea.
Windows95 used to include the Sun PC-NFS client that might do what you're asking, but I'm not sure (as the last time I used Windows95 was several months ago and I don't have a test system to mess with).
If you're just trying to get Windows (NT) to log into an NIS domain, you can have a look at NISGINA. There's a neat article at LinuxWorld here. I poked around with this before I discovered Samba, but never really tested is. NISGINA's hopme page is here. NISGINA (and it's subsidiary utilities) come with source, too (which is nice).
Sun (I think..) also makes an NIS/NFS client for Win32 -- there's a technical run-through here. It's called the Solstice NFS Client for Windows and it probably doesn't come cheap.
Now, if anywone knows where I can get a cheap/free Macintosh NIS/NFS client... (and yes, I know about Netatalk, but I'd like to try anyways)