Quoth the heathen: > But NO, window managers must remain ordinary > applications, otherwise X turns into something > brain damaged like Windows or a Mac.
Brain damaged? Who's spouting FUD now? Mac's have Window Managers too:
[localhost:~] david% ps axwww | grep Core 73 ?? Ss 3:15.50/System/Library/CoreServices/WindowServer 228 ?? Ss 0:00.29/System/Library/CoreServices/coreservicesd 272 ?? Ss 0:00.10/System/Library/CoreServices/SecurityServer 286 ?? Ss 0:00.71/System/Library/CoreServices/loginwindow.app/login window console 289 ?? Ss 0:03.53/System/Library/CoreServices/pbs 303 ?? S 0:05.07/System/Library/CoreServices/Finder.app/Contents/M acOS/Finder -psn_0_262145 304 ?? S 0:01.21/System/Library/CoreServices/Dock.app/Contents/Mac OS/Dock -psn_0_393217 306 ?? S 0:08.16/System/Library/CoreServices/SystemUIServer.app/Co ntents/MacOS/SystemUIServer -psn_0_655361
Why do all these companies think that USB 2.0 is ok? Has anyone ever benchmarked USB 2.0? It is sssssslllllooooowwww! [1] Some needs to smack these designers and make them put a REAL bus (like FireWire) on these devices. When you are talking about significant ammounts of data its very important that your bus be as fast as it can be. Sadly, USB 2.0 just doesn't cut it.
I've been waiting for some company to come out with an iPod competitor to drive the prices down, but no one is going to be able to compete (in my mind) until they make a FireWire version.
-David
[1] We've run many tests at our company with USB 2.0 and FireWire to ATA bridges, and without fail the USB 2.0 are (at best!) half the speed of FireWire. This is especially pathetic when you see that USB's max bandwidth is 480 Mbits, and FireWire is 400. I don't know if its inefficient protocols, crappy drivers, crappy host bus chips or crappy bridge chips but whatever it is USB 2.0 is substandard. Avoid it.
We used to joke about some people who coded for us because thay all abbreviated their variables in the most obnoxious manner. The standard seemed to be: drop the vowels of every variable, function, and file name. It was very difficult to deal with.
For example: CntNmTrcks()... How is that possibly better than CountNumberOfTracks()?
This of course caused me to counter back with overly verbose variable names like: FixStupidWriteBugInSectorCountRegisterButOn lyOnTue sdaysFlag and such.
Now my *FAVORITE* abbreviation was one that came back from a Japanese company that modified some of our code for production tests. They kept abbreviating "Count" by dropping just the "o".:-) I fell off my chair when I first saw it...
That is horrible. Aren't these the guys that were installing the spyware with their filesharing app a little while ago? If not (and even if it is) then it's one more company to avoid. I'm starting to think that people should avoid all these file-sharing companies--they apparently can't be trusted.
By the way, I'm don't think it's necessarily correct to say the Apple hardware doesn't support ATA/100 and therefore doesn't support large disks. It seems the article and some of the posts here are confusing speed with large capacity capability. You can still do 48bit LBA in PIO mode if you want. Just this week I stuck a 160BG drive in an ancient Pentium 100 computer--and I used the whole disk (why you ask? It was for a backup server--large disk, extra cheap computer sitting around). There's no way the on-board IDE chip could have been ata/100 compliant. However, linux plus the ATA patch I installed supported the 48 Bit LBA commands from the ATA-6 spec, so I was able to use the whole disk. In PIO mode too.:-)
I mention this because it's quite possible that the solution to this problem is a little software update from Apple. You computer may not be obsolete yet.:)
Right this second (stock kernel 2.4.14), it sucks. It locks up my machines every time I try to load SBP-2. However, going to the sourceforge 1394 code and getting an older version from 6/1/1 allows me to mount my drive and use it just fine.
The Kernel guys seem to be focusing on cameras rather than on good SBP-2 support.
Is hot-swappability really supported (just umount and unplug, plug and mount)?
No. it only creates/dev/sd* devices when you load the module initially. There is some way to cause the kernel to go rescan for SCSI devices, and this is purported to work, however I have never done it.
Are there any recommendations for PCI Firewire cards for Linux?
Make sure the card supplies external power. Some crappy board manufactures don't supply power to the bus in an effort to reduce cost. This is bad bad bad. Aside from that, they are all basically the same. I recommend the Maxtor host adapter.
How many drives can reasonably fit before power becomes an issue (I assume the less expensive drives obtain power from the port)?
Actually, the only drives that run exlusively off power from the port are the 2.5 inch drives which are more expensive. The 3.5" drives require too much power to be powered exclusively through the bus.
Best case: Firewire can supply 45 watts (from the spec). Those 2.5" drives use about 7 watts.
Realistic: Only FireWire on Macintoshes supplies any kind of decent wattage: about 30. FireWire PCI cards with external power connectors only supply about 18 watts.
So: 2 bus powered drives on a PC, 4 on a mac, with 6 being the theoretical maximum.
External powered drives basically use no bus power so there's no limit there.
I've been running with the ext3 patch for a couple months now and I really like it. There's nothing like locking up your system while testing some crazy hardware, and booting back up with no fsck... I'm glad its finally "blessed"!
Getting back to computers, what about where the anti-virus-virus causes inadvertant damage to the system because it has an unusual configuration, different software, etc. So instead of fixing the webserver, it utterly kills it. That could happen very easily if you binary patch even a slightly different version of the executable than you were expecting. Then what?
Well, then suck it up, I say... They've had plenty of time to fix their dumb server. And at least if it's dead then it's not spreading a virus around anymore!
I consider the 8086 and its nasty chip architecture to be a pretty big screwup... Back then there were much more elegant processor designs. Anything by motorolla was much more straight forward with nicer instruction sets and register designs.
The only reason intel is the giant they are today is because IBM used the crappy 8086 in the PC.
Someone mentioned quake mods, which are written in QuakeC. This is an excellent idea. Games Games Games make the world go round.
The question is, Quake 1 or Quake 3?
Quake 1 engine source code is released and free, making it an attractive program to mess with. Gameplay code is also available and since its in QuakeC it's close to C so that they can play with the gameplay pretty easily. Quake 1 is a relatively old game and will run on most hardware (since schoolsght not have the latest and greatest), and has ports to every OS imagineable.
Quake 3 doesn't have the game engine code released, but it DOES have all the gameplay code released. The gameplay code is in straight C this time (not quakeC) which is plus. If you compile up their code into a mod, it will run on Macs, PCs and Linux, which is a nice plus as well. The downside is that students would have to buy a copy for homework, and the school would have to buy copies for the labs (to be legal).
I would vote for Quake 3 since it is the hot ticket at the moment and the most fun to play, but Quake 1 would also be a good choice because the engine is exposed and ready to be tweaked and it can be purchased very cheaply.
Does anyone know if the current 1394 drives that are essentially IDE with a bridge to 1394 have the same CPU time consumming properties of IDE?
No. Even in PIO mode, the bridge is doing the pio-ing, not the main processor. To the FireWire card, it doesn't even know the device is ATA! (Its sending SCSI commands that the bridge translates to ATA). And Its pure DMA from the FireWire card to main memory.
I really don't see what the big fuss is about SCSI starting to fade out when there is a superior standard in place. What really needs to happen is for true IEEE 1394 based drives to come out. The IDE bridge chips are starting to become the speed bottleneck, giving the bad impression that the 1394 drives can't perform.
This is not the case to my knowledge. We get the same performance on a drive through a bridge that we get through the IDE port. Most ide HDAs don't have a very fast raw transfer rates. Where you need the high bus bandwidth is when you hook multiple disks up together and, say, RAID them. The fastest we've seen off an IDE disk is around 13MB/s sustained and this can be done even with pio. We dont even turn on DMA in our bridges by defualt unless we've thoroughly tested a drive because so many crappy ata disks dont do dma correctly. The whole ATA bus is a huge kludge. But its cheap... Perhaps those two concepts are related??? SCSI is solid and you just don't see the problems between multiple device that you do with ATA. This is because the BUS was actually designed and not hacked together. FireWire is also very well thought out. So far there are some growing pains, but when it stabalizes in the near future it will be a far superior solution than SCSI. I agree with your sentiment:
I really don't see what the big fuss is about SCSI starting to fade out when there is a superior standard in place.
That said, SCSI still handles multiple requests better.
SCSI handles multiple request at all! There is no "disconnect" in ATA--You cant tell both master and slave to do something at the same time. This is why its bad to have your cd-rom on the same bus as your disk, because it will slow it down horribly.
Slashdot Mirror
> but... no smoking.. :(
Thank the lord!
Quoth the heathen:
/System/Library/CoreServices/WindowServer /System/Library/CoreServices/coreservicesd /System/Library/CoreServices/SecurityServer /System/Library/CoreServices/loginwindow.app/login window console /System/Library/CoreServices/pbs /System/Library/CoreServices/Finder.app/Contents/M acOS/Finder -psn_0_262145 /System/Library/CoreServices/Dock.app/Contents/Mac OS/Dock -psn_0_393217 /System/Library/CoreServices/SystemUIServer.app/Co ntents/MacOS/SystemUIServer -psn_0_655361
> But NO, window managers must remain ordinary
> applications, otherwise X turns into something
> brain damaged like Windows or a Mac.
Brain damaged? Who's spouting FUD now? Mac's have Window Managers too:
[localhost:~] david% ps axwww | grep Core
73 ?? Ss 3:15.50
228 ?? Ss 0:00.29
272 ?? Ss 0:00.10
286 ?? Ss 0:00.71
289 ?? Ss 0:03.53
303 ?? S 0:05.07
304 ?? S 0:01.21
306 ?? S 0:08.16
Mac OS X is less brain damaged than you think.
-David
Cost of FireWire card: < $20
Why do all these companies think that USB 2.0 is ok? Has anyone ever benchmarked USB 2.0? It is sssssslllllooooowwww! [1] Some needs to smack these designers and make them put a REAL bus (like FireWire) on these devices. When you are talking about significant ammounts of data its very important that your bus be as fast as it can be. Sadly, USB 2.0 just doesn't cut it.
I've been waiting for some company to come out with an iPod competitor to drive the prices down, but no one is going to be able to compete (in my mind) until they make a FireWire version.
-David
[1] We've run many tests at our company with USB 2.0 and FireWire to ATA bridges, and without fail the USB 2.0 are (at best!) half the speed of FireWire. This is especially pathetic when you see that USB's max bandwidth is 480 Mbits, and FireWire is 400. I don't know if its inefficient protocols, crappy drivers, crappy host bus chips or crappy bridge chips but whatever it is USB 2.0 is substandard. Avoid it.
We used to joke about some people who coded for us because thay all abbreviated their variables in the most obnoxious manner. The standard seemed to be: drop the vowels of every variable, function, and file name. It was very difficult to deal with.
... How is that possibly better than CountNumberOfTracks()?
n lyOnTue sdaysFlag and such.
:-) I fell off my chair when I first saw it...
For example: CntNmTrcks()
This of course caused me to counter back with overly verbose variable names like:
FixStupidWriteBugInSectorCountRegisterButO
Now my *FAVORITE* abbreviation was one that came back from a Japanese company that modified some of our code for production tests. They kept abbreviating "Count" by dropping just the "o".
-David
That is horrible. Aren't these the guys that were installing the spyware with their filesharing app a little while ago? If not (and even if it is) then it's one more company to avoid. I'm starting to think that people should avoid all these file-sharing companies--they apparently can't be trusted.
Let's hear it for open source gnutella clients!
-David
By the way, I'm don't think it's necessarily correct to say the Apple hardware doesn't support ATA/100 and therefore doesn't support large disks. It seems the article and some of the posts here are confusing speed with large capacity capability. You can still do 48bit LBA in PIO mode if you want. Just this week I stuck a 160BG drive in an ancient Pentium 100 computer--and I used the whole disk (why you ask? It was for a backup server--large disk, extra cheap computer sitting around). There's no way the on-board IDE chip could have been ata/100 compliant. However, linux plus the ATA patch I installed supported the 48 Bit LBA commands from the ATA-6 spec, so I was able to use the whole disk. In PIO mode too. :-)
:)
I mention this because it's quite possible that the solution to this problem is a little software update from Apple. You computer may not be obsolete yet.
Right this second (stock kernel 2.4.14), it sucks. It locks up my machines every time I try to load SBP-2. However, going to the sourceforge 1394 code and getting an older version from 6/1/1 allows me to mount my drive and use it just fine.
The Kernel guys seem to be focusing on cameras rather than on good SBP-2 support.
Is hot-swappability really supported (just umount and unplug, plug and mount)?
No. it only creates /dev/sd* devices when you load the module initially. There is some way to cause the kernel to go rescan for SCSI devices, and this is purported to work, however I have never done it.
Are there any recommendations for PCI Firewire cards for Linux?
Make sure the card supplies external power. Some crappy board manufactures don't supply power to the bus in an effort to reduce cost. This is bad bad bad. Aside from that, they are all basically the same. I recommend the Maxtor host adapter.
How many drives can reasonably fit before power becomes an issue (I assume the less expensive drives obtain power from the port)?
Actually, the only drives that run exlusively off power from the port are the 2.5 inch drives which are more expensive. The 3.5" drives require too much power to be powered exclusively through the bus.
Best case: Firewire can supply 45 watts (from the spec). Those 2.5" drives use about 7 watts.
Realistic: Only FireWire on Macintoshes supplies any kind of decent wattage: about 30. FireWire PCI cards with external power connectors only supply about 18 watts.
So: 2 bus powered drives on a PC, 4 on a mac, with 6 being the theoretical maximum.
External powered drives basically use no bus power so there's no limit there.
-David
Yay!
-David
Well, then suck it up, I say... They've had plenty of time to fix their dumb server. And at least if it's dead then it's not spreading a virus around anymore!
-David
I consider the 8086 and its nasty chip architecture to be a pretty big screwup... Back then there were much more elegant processor designs. Anything by motorolla was much more straight forward with nicer instruction sets and register designs.
The only reason intel is the giant they are today is because IBM used the crappy 8086 in the PC.
-David
Someone mentioned quake mods, which are written in QuakeC. This is an excellent idea. Games Games Games make the world go round.
The question is, Quake 1 or Quake 3?
Quake 1 engine source code is released and free, making it an attractive program to mess with. Gameplay code is also available and since its in QuakeC it's close to C so that they can play with the gameplay pretty easily. Quake 1 is a relatively old game and will run on most hardware (since schoolsght not have the latest and greatest), and has ports to every OS imagineable.
Quake 3 doesn't have the game engine code released, but it DOES have all the gameplay code released. The gameplay code is in straight C this time (not quakeC) which is plus. If you compile up their code into a mod, it will run on Macs, PCs and Linux, which is a nice plus as well. The downside is that students would have to buy a copy for homework, and the school would have to buy copies for the labs (to be legal).
I would vote for Quake 3 since it is the hot ticket at the moment and the most fun to play, but Quake 1 would also be a good choice because the engine is exposed and ready to be tweaked and it can be purchased very cheaply.
-David
No. Even in PIO mode, the bridge is doing the pio-ing, not the main processor. To the FireWire card, it doesn't even know the device is ATA! (Its sending SCSI commands that the bridge translates to ATA). And Its pure DMA from the FireWire card to main memory.
I really don't see what the big fuss is about SCSI starting to fade out when there is a superior standard in place. What really needs to happen is for true IEEE 1394 based drives to come out. The IDE bridge chips are starting to become the speed bottleneck, giving the bad impression that the 1394 drives can't perform.
This is not the case to my knowledge. We get the same performance on a drive through a bridge that we get through the IDE port. Most ide HDAs don't have a very fast raw transfer rates. Where you need the high bus bandwidth is when you hook multiple disks up together and, say, RAID them. The fastest we've seen off an IDE disk is around 13MB/s sustained and this can be done even with pio. We dont even turn on DMA in our bridges by defualt unless we've thoroughly tested a drive because so many crappy ata disks dont do dma correctly. The whole ATA bus is a huge kludge. But its cheap... Perhaps those two concepts are related??? SCSI is solid and you just don't see the problems between multiple device that you do with ATA. This is because the BUS was actually designed and not hacked together. FireWire is also very well thought out. So far there are some growing pains, but when it stabalizes in the near future it will be a far superior solution than SCSI. I agree with your sentiment:
I really don't see what the big fuss is about SCSI starting to fade out when there is a superior standard in place.
-David
SCSI handles multiple request at all! There is no "disconnect" in ATA--You cant tell both master and slave to do something at the same time. This is why its bad to have your cd-rom on the same bus as your disk, because it will slow it down horribly.
-David