The process of setting up the new kratom went smoothly enough. I began by completely formatting the drive, then I decided which approach I would take to partitioning the drive in the indicated way: 20GB to Windows and the rest to Linux out of an 80GB drive, then further partition the Windows side in two subpartitions, 12GB and 8GB respectively...
It was immediately clear that the best approach would be to first install Windows on the whole drive, and then proceed to install Linux, resizing the NTFS partition to obtain sufficient space. This is a good idea for many reasons, including:
1) It prevents Windows from messing with the MBR:
Windows overwrites the MBR during setup, wiping away any bootloaders that one's Linux distro may have installed. Since Windows' own bootloader (while supposedly offering some multi-boot capabilities) won't support booting Linux, this means the Linux boot loader (GRUB, LILO, etc) would have to be installed twice (including once *manually*! the gods forbid).
2) It simplifies the process of partitioning the disk:
Several distro installers and partitioning tools in the Linux world easily support resizing of partitions formatted in other filesystems (including NTFS). Therefore this approach allows us to take advantage of the automation provided by both operating systems' installers: we let Windows install itself on the whole drive in its absolute monarch kind of way, let it write on the MBR etc, and then we move over to SuSE where YaST very quickly and efficiently lets us resize the NTFS partition and installs Linux in the regained space. This seems to be the way of least resistance. Otherwise, we would have to manually partition the drives, with more possibility for human error. Important caveats here are: virtual memory (pagefile) MUST be disabled in Windows and the NTFS partition must have been defragmented before doing the resizing.
Installing and setting up Windows XP Professional SP2:
Following the above scheme, I proceeded to install Windows. This went smoothly for the duration of the DOS-like, text-only part of the Windows setup.
At the stage where it attempts to boot into Windows itself, however, I received an error message from the BIOS: "Error loading operating system", accompanied by boot failure. At this point I tried several things, including recreating the Windows partition, installing an alternate version of Windows, installing Linux first, and so on. None of those things worked, but they made me realize that the problem was a BIOS issue, independent of the operating system used. Finally, after some advanced searching, I found a webpage referring to a similar issue. I decided to try its suggestions and, sure enough, it worked. The short version is that there appears to be some kind of issue with the BIOS on 64-bit systems detecting the size of the hard drive correctly, unless all hard drives are set to LBA in the CMOS setup (instead of "cable select" or other setting). While I was in the CMOS setup, I took the opportunity to disable the useless SATA RAID detection at boot time. At some point around here, I also installed SuSE to a minimum, so that I could get the partitioning scheme right.
Once Windows was fully installed and partitioned as indicated above, I had to manually install the latest driver pack to enable networking, sound and the correct video settings. Windows wasn't able to enable basic services as it's supposed to, this appears to be a weakness in its ability to deal with integrated devices (the nVidia motherboard in this machine has built-in NIC and sound/video adapters). The video settings required some tinkering to correct some fuzziness in how the display was rendered on LCD. By the way, if you ever have to do this, do not attempt to use the Microsoft ClearType tool which you may find with a websearch. It's a useless piece of junk that will subtly insult your intelligence with its first-grader type interface, while making you jump through a few ridiculous hoops disguised as "settings", which have NO effect. Seriously. Try it next time you forget why you used to be so pissed off at Microsoft products.
Anyway, I then proceeded to install the software that had been requested. I collected the following applications: Creative Suite, Firefox, Java, Openssh, Openssl, Mirc, Jedit, Homesite, OpenOffice, Thunderbird, iTunes, winCVS, Actual Search'n Replace, Eclipse, ACDSee, Nero, Norton Ghost and Symantec Antivirus. Some had to be downloaded, some I had, some had to be otherwise found. I installed and minimally configured everything. Then I went ahead and did the minimal security patching, optimizing and configuring that every new installation of Windows should get. This closes the most obvious of security holes (such the UPnP service), makes Windows less cluttered (disabling system popups, themes and some memory-hogging visual frills; changing the playskool type defaults in terms of UI with something more suited to a non-brain damaged adult, etc) and somewhat more stable (setting the pagefile size to a static value, disabling useless services), and generally a bit less stressful to use. Additionally, I installed the Pagefile Defragmenter. This free tool allows defragmentation of the Windows pagefile (which can not be performed with Defrag), by defragmenting it before Windows boots. This helps avoid virtual memory-related slowdowns. Finally, Norton Ghost was used to make a backup of the drive on a DVD.
Installing and setting up SuSE 9.2 Professional (with comparisons to Gentoo) :
Once done with Windows, I moved back to the Linux side. At this point I had a working system with KDE and whatever applications come by default with SuSE. I must say that the installation was extremely easy and pleasant, both visually and otherwise. This is a point for SuSE when weighed against Gentoo, my choice distro. Gentoo by comparison takes much longer in terms of initial setup. However, I appreciate how this allows for better customization of the system. At the end of a Gentoo setup one knows in detail what is installed and what isn't, and has already memorized how to change any one element on that particular system, should the need arise. YaST, SuSE's tool for installing packages (rpm based, aiming at full compliance with the jpackage system -- see jpackage.org), works by allowing the user to search for packages, or alternatively one can install categories of packages, such as "Java", "KDE", etc. The packages, at this stage in the installation, are installed from the SuSE DVD. Later, once the system has been booted for the first time, YaST can connect to a server to update its packages list and download any updates. By contrast, Gentoo's package management system (Portage), is capable of building an entire system from the latest versions of all packages involved; everything just gets downloaded from a list of mirrors. They are fetched as source, then built. This of course introduces a bunch of overhead, and it takes quite a while to build a basic system with KDE. Gentoo however comes also in other versions, including one containing most common packages in binary form, which allows the user to get a basic system going quickly, and still use Portage for future upgrades, etc. Moreover, the selection in terms of variety of packages and their versions seemed poorer on the YaST side. The vast majority of popular packages become available in Portage within days after official release, and the very latest version of a wide variety of kernels is always immediately obtainable. This without any manual downloading of any packages. But in YaST, many packages seemed to still be stuck at some stable release from a while ago, which is fine in terms of functionality, but it prevents those who wish to from easily upgrading. There does seem to be a daily release of patches, etc, so I'm assuming that in the case of important security issues a way to upgrade packages to a secure version is offered right away. Still, I like Gentoo's greater flexibility and (so far -- I've been using it for about 1.5 years) reliability, from this point of view.
Anyway, once booted into KDE (which looks fantastic -- the crystal clear definition of the LCD screen is particularly remarkable when compared to the best I was able to get Windows to do), I installed the requested packages: Tomcat, Eclipse, Jedit, Xchat, Apache 2, Php 4, Imagemagick, Wine, Openoffice, Firefox, Thunderbird, Ant, and Sun Java. KDE was installed automatically during setup. Right away there was a problem with the Java plugin and Firefox (the plugin was not recognized by Firefox as installed, and sites using Java complained about it not being enable in the browser).
It was particularly disappointing here that no versions of Java in the 1.5 branch are yet available in YaST, despite having been considered stable already for a while. Manually installing Java 1.5.0-2 did not fix the issue, so I decided to stick with YaST and revert. I was able to workaround the issue by installing a 32-bit version of Firefox. I attempted to at least install the latest version of 32-bit Firefox, using a rpm package from the jpackage site (supposed to be compatible with YaST). Didn't go over well -- YaST claimed to have installed it successfully, but the About Firefox dialog showed it still as a 64-bit version, presumably the one that YaST had installed earlier by default. I quickly nuked the whole "external downloaded RPMs" idea, and went back to the 32-bit firefox provided by SuSE. Moral of the story: caution should be used when upgrading Firefox. I would expect the Java support to break if Firefox is upgraded to a 64-bit version. This must be carefully checked in YaST, in the "Versions" tab for the selected package. Some online reports suggest that an alternate, free JRE called Blackdown (which is also the default in Gentoo and, I must say, seems a bit slower than Sun's) might work with 64-bit Firefox. Because of the vagueness of the claim, and the fact that this machine is to be used to develop Java, I decided to accept the distro's limitations, not investigate further down that route, and stick with Sun Java 1.4.2.
That's pretty much it. The machine should be ready to use comfortably both in Windows and Linux.
We have a somewhat complicated dev setup, although not terribly so. It makes it complicated to get the php library directories set up.
The live server is reasonably straight forward. A single web dir for all the files. PHP uses server root instead of document root for its include directives, which is really a big pain in the ass... especially when it comes to working .htaccess files.
Setting the php_value include_path in .htaccess is preferred for a lot of reasons, not the least of which it makes it easy to change where the libraries for a given directory tree or application are. However there are a handful of problems with this, the top two are that include_path cannot be additive and that the include is relative to system root and not document root.
Not Additive: php_value include_path replaces the previous value for include_path. This is a bit of a design flaw with PHP. Other pathing systems allow adding or replacing. This means that everytime the include_path is set, one has to know and reiterate every previous library directory. These can be kind of complicated for a sophisticated site. In fact, in many cases they cannot be derived without logic and thus are NOT settable in .htaccess, destroying the functionality of this. Awful.
System Root not Document Root. Unlikely most other .htaccess directives which are relative to Document Root, PHP decided to make the file paths absolute, which means that it is difficult or impossible to create include_path values that can handle a complicated tree of applications and active pages.
In our case, one of our main development setups is that we have a single web server that serves files from a variety of directories within the development trees. So fire.localdev runs off one drive while earth.localdev runs off another. In order to keep their libraries separate, the library paths MUST not be set using absolute (server root based) paths.
I came up with two solutions for this, one ugly and one not so bad. The ugly one is to include the whole list of possible relative directories:
php_value include_path .:./lib:../lib:../../lib:../../../lib:../../../../lib
you get the idea. Beautiful, no? no.
The other, slightly less ugly, version is to add entries to the
<VirtualHost ...>
ServerName fire.localdev
DocumentRoot /www/fire.dev.root
php_value include_path ".:/www/fire.dev.root/lib"
</VirutalHost>
<VirtualHost ...>
ServerName earth.localdev
DocumentRoot /www/earth.dev.root
php_value include_path ".:/www/earth.dev.root/lib"
</VirutalHost>
Advanced Sharing must be turned on!
Tools->Folder Options->View->use simple file sharing : OFF
I have the following directory structure:
d:\erowid.org\a_writeable\
d:\erowid.org\b_readonly\
d:\erowid.org\file.txt
I want to have a single windows share of the erowid.org directory so that
other machines can see this. I currently have this as a share named
"erowid.org". I want the share to be world readable, but writeable only for the directories and users that I specify.
I want to have the b_readonly directory and file.txt be read only. I want the
a_writeable directory to be writeable by anyone allowed to use the share.
This could be a specific user or it could be Everyone, it doesn't really
matter. I'd prefer per-user control, but whatever.
The top level share (drive) must be set to share this folder.
For that top level (drive), Security tab, then set allow boxes as appropriate for various users and groups.
Don't use a deny as a method of limiting allow unless absolutely necessary.
By default, these inherit down. Each subdirectory can have inheritance turned on or off (default is on). If you want a subdir to have less perms than its parent, turn off inheritance, then start the new allows as desired.
Generally only use deny when you are saying "joe doesn't get access to this", don't use denies to create normal permissions. Only to explicitly deny access as an exception.
---
There are lots of little things that can get set wrong here.
One of them is that sometimes folders have default perms set to allow writes and directory creates, so these need to be set off. In the case of erowid.org there were two "Users" entries in the permissions and one was set different than the other.