If you choose to run BeOS R5 as a file inside of Windows, it will do nothing to any of your partitions. It is just a 500 mb image (of a BFS partition) inside of the Windows partition (you can also use the image file inside of an ext2 partition, but BeOS can't write to ext2, and as such it also can't write to the image file I believe) that BeOS R5 mounts and runs from. This unfortunetly means that you are limited to 500 mb since BFS apparently can't handle having the partition size changed.
If you decide you need more space for BeOS, or you get tired of loading Windows first, you can install BeOS onto its own partition (I believe that The BeTips Server has information on how to do this, and boot into it directly. There are two ways of doing this:
Use LILO on the MBR and add an entry for the BeOS partition
Use BeOS's bootloader, bootman, on the MBR and install LILO on the Linux partition
Provided you know how to make a partition, etc. neither of these methods should result in lose of data either. I use bootman as my main bootloader, and it works fine for loading Windows, Linux, OpenBSD, and BeOS. I installed BeOS after the other three OSes, and I had no problems with lose of bootloaders for anything. Of course, LILO also works at doing all of these (if I select Linux, it loads LILO where I can select any of the others instead of Linux again if I want to).
If you have important information on your Windows partition, you should A) back it up, and B) make a rescue disk. If you accidently wipe the MBR somehow and *NEED* to get to your work, you can always do an "disk/mbr" on your Windows partition, and that should allow your computer to boot straight into Windows. With Linux, you can always boot off of a resuce floppy (usually, at the LILO prompt, you type the kernel name, ie "vmlinuz" and then "root=/dev/hdwhatever drive and partition") and just re-run LILO to return the MBR to its previous state of Linux and Windows co-operation.
The only reason I can think of is that this way you can fiddle around with the controls on your computer, and have the picture go straight into your graphics program (via SANE and straight into the GIMP under Linux, or a TWAIN driver under Windows), without having to copy the files over the network and load them into your program each time, and you can then re-scan if the color wasn't perfect and see the results immediatly. Of course, the way I scan usually involves having to reset the page since it is crooked, cropped, etc., so I would end up running back and forth between the remote computer and scanner too much. Also, if the "server" is a computer somebody else is using, you wouldn't have to kick them off everytime you wanted to scan something.
And its late at night here, so maybe I'm missing the point, but isn't the server-client scanning setup closer to the single queue on the centralized computer example than the queue on each workstation, or is that what you were trying to say? If it is, then then how is a seperate queue per workstation better/possible? If none of that made sense, don't worry it's probably me, I think I'm going to bed now.
I haven't ever tried SANE either (since I only have the winmodem-like SCSI card that came with the scanner, and it isn't supported by Linux), but I still looked around at the website for SANE a while ago, and found that you can do exactly as described in the above message. saned runs as a server on the computer with the scanner, and then the clients all use SANE with the sane-net driver (the webpage calls it a backend, but I'm pretty sure it is like a driver) to access the remote scanner. A list of platforms that SANE supports is listed here, and there are also clients available for several other platforms, such as windows (which is likely to be in use if it is a home network), and even a CGI frontend to allow access over a web browser if there isn't a dedicated client available for your OS of choice. The list of related projects such as the mentioned clients can be found here, and SANE's website is here.
"28 MAR 00// Update 001_we got crushed by traffic. laughingsquid.com, thanks for holding on as long as you did. 002_to the good folks at sporkism.org who put us back up and everyone else who offered to mirror. thank you."
Which means that they got/.ed, and may have continued to have problems after the 28th.
It's kind of unfortunate that this story was posted after they got back up... is there really this much of a lead time before stories appear (it would seem so, with the "Are There Any Linux DVD Players" story running after the story about one coming out), or did Cliff just not bother trying to go there?
According to this post on the linux-kernel mailing list, Logitech doesn't want to release the information necessary to make a driver. But, there is hope, since Logitech has been known to do the right thing before.
Easel, by Human Touch Software includes support for Wacom tablets I think, and there is a driver on BeBits for Wacom USB PenPartner tablets here. There are also several other tablet drivers on BeBits, and as far as I know they all support pressure sensitivity, although I'm not sure if any programs other than Easel do. Oh, and Easel was recently made freeware so you'll probably want to check it out regardless of whether it supports your tablet or not.
Slashdot Mirror
If you decide you need more space for BeOS, or you get tired of loading Windows first, you can install BeOS onto its own partition (I believe that The BeTips Server has information on how to do this, and boot into it directly. There are two ways of doing this:
Provided you know how to make a partition, etc. neither of these methods should result in lose of data either. I use bootman as my main bootloader, and it works fine for loading Windows, Linux, OpenBSD, and BeOS. I installed BeOS after the other three OSes, and I had no problems with lose of bootloaders for anything. Of course, LILO also works at doing all of these (if I select Linux, it loads LILO where I can select any of the others instead of Linux again if I want to).
If you have important information on your Windows partition, you should A) back it up, and B) make a rescue disk. If you accidently wipe the MBR somehow and *NEED* to get to your work, you can always do an "disk /mbr" on your Windows partition, and that should allow your computer to boot straight into Windows. With Linux, you can always boot off of a resuce floppy (usually, at the LILO prompt, you type the kernel name, ie "vmlinuz" and then "root=/dev/hdwhatever drive and partition") and just re-run LILO to return the MBR to its previous state of Linux and Windows co-operation.
Of course, the way I scan usually involves having to reset the page since it is crooked, cropped, etc., so I would end up running back and forth between the remote computer and scanner too much.
Also, if the "server" is a computer somebody else is using, you wouldn't have to kick them off everytime you wanted to scan something.
And its late at night here, so maybe I'm missing the point, but isn't the server-client scanning setup closer to the single queue on the centralized computer example than the queue on each workstation, or is that what you were trying to say? If it is, then then how is a seperate queue per workstation better/possible? If none of that made sense, don't worry it's probably me, I think I'm going to bed now.
I haven't ever tried SANE either (since I only have the winmodem-like SCSI card that came with the scanner, and it isn't supported by Linux), but I still looked around at the website for SANE a while ago, and found that you can do exactly as described in the above message.
saned runs as a server on the computer with the scanner, and then the clients all use SANE with the sane-net driver (the webpage calls it a backend, but I'm pretty sure it is like a driver) to access the remote scanner. A list of platforms that SANE supports is listed here, and there are also clients available for several other platforms, such as windows (which is likely to be in use if it is a home network), and even a CGI frontend to allow access over a web browser if there isn't a dedicated client available for your OS of choice. The list of related projects such as the mentioned clients can be found here, and SANE's website is here.
"28 MAR 00 // Update 001_we got crushed by traffic. laughingsquid.com, thanks for holding on as long as you did. 002_to the good folks at sporkism.org who put us back up and everyone else who offered to mirror. thank you."
Which means that they got /.ed, and may have continued to have problems after the 28th.
It's kind of unfortunate that this story was posted after they got back up... is there really this much of a lead time before stories appear (it would seem so, with the "Are There Any Linux DVD Players" story running after the story about one coming out), or did Cliff just not bother trying to go there?
According to this post on the linux-kernel mailing list, Logitech doesn't want to release the information necessary to make a driver. But, there is hope, since Logitech has been known to do the right thing before.
Easel, by Human Touch Software includes support for Wacom tablets I think, and there is a driver on BeBits for Wacom USB PenPartner tablets here. There are also several other tablet drivers on BeBits, and as far as I know they all support pressure sensitivity, although I'm not sure if any programs other than Easel do. Oh, and Easel was recently made freeware so you'll probably want to check it out regardless of whether it supports your tablet or not.