Mercurial > hg > aboriginal

comparison www/FAQ.html @ 1234:d6e6c9ddf7f9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Yet more FAQ massaging.
author Rob Landley <rob@landley.net>
date Sun, 05 Sep 2010 00:02:21 -0500
parents 8a88cae14011
children 5c7b6fb032ba
comparison
equal deleted inserted replaced
1233:a4734fc22a6d 1234:d6e6c9ddf7f9
3 <title>Frequently Asked Questions</title> 3 <title>Frequently Asked Questions</title>
4 4
5 <ul> 5 <ul>
6 <li><p><a href=#where_start>Q: Where do I start?</a></p></li> 6 <li><p><a href=#where_start>Q: Where do I start?</a></p></li>
7 7
8 <li><p><a href=#building><h1>Building System Images</h1></a></p></li>
9 <ul>
8 <li><p><a href=#source_tour>Q: What's all this source code for?</a></p></li> 10 <li><p><a href=#source_tour>Q: What's all this source code for?</a></p></li>
9 11
10 <li><p><a href=#name_change>Q: Didn't this used to be called Firmware Linux?</a></p></li>
11
12 <li><p><a href=#add_package>Q: How do I add $PACKAGE to my system image's root filesystem?</a></p></li> 12 <li><p><a href=#add_package>Q: How do I add $PACKAGE to my system image's root filesystem?</a></p></li>
13 13
14 <li><p><a href=#ubuntu_mispackaged_qemu>Q: ./run-emulator.sh says qemu-system-mips isn't found, but I installed qemu. Why isn't this working?</a></p></li>
15
16 <li><p><a href=#case_sensitive_patch>Q: I added my uClibc patch to sources/patches but it didn't do anything, what's wrong?</a></p></li> 14 <li><p><a href=#case_sensitive_patch>Q: I added my uClibc patch to sources/patches but it didn't do anything, what's wrong?</a></p></li>
17 15
18 <li><p><a href=#package_breaks>Q: Why did package build $NAME die because it couldn't find $PREREQUISITE, even though it's installed?</a></p></li> 16 <li><p><a href=#package_breaks>Q: Why did package build $NAME die because it couldn't find $PREREQUISITE, even though it's installed?</a></p></li>
19 17
20 <li><p><a href=#environment_sanitizing>Q: Why isn't the build listening to the environment variables I set?</p></li> 18 <li><p><a href=#environment_sanitizing>Q: Why isn't the build listening to the environment variables I set?</p></li>
19 </ul>
21 20
22 <li><p><a href=#debugging><h1>Debugging questions</h1></a></p></li> 21 <li><p><a href=#debugging><h1>Debugging questions</h1></a></p></li>
23 22
24 <ul> 23 <ul>
25 <li><p><a href=#debug_logging>Q: How do I get better log output?</p></li> 24 <li><p><a href=#debug_logging>Q: How do I get better log output?</p></li>
25 <li><p><a href=#debug_test>Q: How do I run my own build snippets without editing the build scripts?</a></p></li>
26 <li><p><a href=#debug_source>Q: How do I play around with package source code?</p></li> 26 <li><p><a href=#debug_source>Q: How do I play around with package source code?</p></li>
27 <ul> 27 <ul>
28 <li><p><a href=#debug_package_cache>Q: What's the package cache for?</a></p></li> 28 <li><p><a href=#debug_package_cache>Q: What's the package cache for?</a></p></li>
29 <li><p><a href=#debug_working_copies>Q: What are working copies for?</a></p></li> 29 <li><p><a href=#debug_working_copies>Q: What are working copies for?</a></p></li>
30 </ul> 30 </ul>
31 </ul> 31 </ul>
32 </ul> 32
33 33 <li><p><a href=#other><h1>Other questions</h1></a></p></li>
34 <a name=where_start /><h2>Q: Where do I start?</h2> 34
35 <ul>
36 <li><p><a href=#name_change>Q: Didn't this used to be called Firmware Linux?</a></p></li>
37
38 <li><p><a href=#ubuntu_mispackaged_qemu>Q: ./run-emulator.sh says qemu-system-mips isn't found, but I installed qemu. Why isn't this working?</a></p></li>
39
40 <li><p><a href=#windows>Q: Do you care about windows?</a></p></li>
41 </ul>
42 </ul>
43
44 <hr /><a name=where_start /><h2>Q: Where do I start?</h2>
35 45
36 <p>The project provides development and test environments for lots of different 46 <p>The project provides development and test environments for lots of different
37 hardware platforms, based on busybox and uClibc and configured to run under 47 hardware platforms, based on busybox and uClibc and configured to run under
38 QEMU.</p> 48 QEMU.</p>
39 49
81 If you don't want to install mercurial, you can grab a 91 If you don't want to install mercurial, you can grab a
82 <a href=http://impactlinux.com/hg/aboriginal/archive/tip.tar.bz2>tarball</a> of the current code at 92 <a href=http://impactlinux.com/hg/aboriginal/archive/tip.tar.bz2>tarball</a> of the current code at
83 any time.</p> 93 any time.</p>
84 </li> 94 </li>
85 95
86 <ul>
87 <li><p>Download a prebuilt cross compiler and cross-compile stuff with it.</p> 96 <li><p>Download a prebuilt cross compiler and cross-compile stuff with it.</p>
88 97
89 <p>Go <a href=screenshots>here</a> and download the appropriate 98 <p>Go <a href=screenshots>here</a> and download the appropriate
90 cross-compiler-<b>$TARGET</b>.tar.bz2 for your $TARGET, extract it, add its 99 cross-compiler-$TARGET.tar.bz2 for your $TARGET, extract it, add its
91 "bin" directory to your $PATH, and use the appropriate $TARGET-cc and 100 "bin" directory to your $PATH, and use the appropriate $TARGET-cc and
92 $TARGET-ld and so on to compile your program. (The tool names have prefixes 101 $TARGET-ld and so on to compile your program. (The tool names have prefixes
93 so they can be in the same $PATH as your host's existing compiler.)</p> 102 so they can be in the same $PATH as your host's existing compiler.)</p>
94 </li> 103 </li>
95 104
96 </ul>
97
98 <p>If all else fails, look at the pretty 105 <p>If all else fails, look at the pretty
99 <a href=screenshots>screenshots</a>.</p> 106 <a href=screenshots>screenshots</a>.</p>
100 107
101 <a name=source_tour /><h2>Q: What's all this source code for?</h2> 108 <hr /><a name=building />
109 <h1>Building System Images</h1>
110
111 <p>The build scripts compile the system images from source code. Along
112 the way, they create the cross compilers and root filesystem tarballs too.
113 If you just want to use the prebuilt binary tarballs to mess around with
114 native environments for various targets, you don't need to care about the
115 build scripts.</p>
116
117 <p>But if you want to understand how it all works, and how to reproduce it,
118 then you do.</p>
119
120 <p>Start by running (or reading) "build.sh", it calls everything else.</p>
121
122 <hr /><a name=source_tour /><h2>Q: What's all this source code for?</h2>
102 123
103 <p>A: The basic outline is:</p> 124 <p>A: The basic outline is:</p>
104 125
105 <ul> 126 <ul>
106 <li><p><b>Top level</b> - The build stages. The file build.sh calls the rest of these scripts in order (but you can call 'em directly too), and the file config lists all the envirionment variables you can set to change the default behavior.</p></li> 127 <li><p><b>Top level</b> - The build stages. The file build.sh calls the rest of these scripts in order (but you can call 'em directly too), and the file config lists all the envirionment variables you can set to change the default behavior.</p></li>
113 134
114 <li><p><b>packages</b> - Downloaded source packages. If you "rm -rf packages", 135 <li><p><b>packages</b> - Downloaded source packages. If you "rm -rf packages",
115 the script download.sh re-populates it by calling wget on various URLs.</p></li> 136 the script download.sh re-populates it by calling wget on various URLs.</p></li>
116 </ul> 137 </ul>
117 138
118 <a name=name_change /><h2>Q: Didn't this used to be called Firmware Linux?</h2> 139 <hr /><a name=add_package /><h2>Q: How do I add $PACKAGE to my system image's root filesystem?</h2>
119 140
120 <p>A: Yup. The name changed shortly before the 1.0 release in 2010.</p> 141 <p>A: Build an ext2 or ext3 formatted system image instead of squashfs, one
121 142 with enough extra space to install your package in.</p>
122 <p>The name "Aboriginal Linux" is based on a synonym for "native", as in 143
123 native compiling. It implies it's the first Linux on a new system, and also 144 <p>Aboriginal Linux builds squashfs images by default, and the prebuilt binary
124 that it can be replaced. It turns a system into something you can do 145 tarballs in
125 native development in, terraforming your environment so you can use it
126 to natively build your deployment environment (which may be something else
127 entirely).</p>
128
129 <p>Aboriginal Linux is cross compiled, but after it boots you shouldn't need
130 to do any more cross compiling. (Except optionally using the cross compiler
131 as a native building accelerator via distcc.) Hence our motto,
132 "We cross compile so you don't have to".</p>
133
134 <p>The old name didn't describe the project very well. (It also had tens
135 of millions of Google hits, most of which weren't this project.) If you're
136 really bored, there's a page on <a href=history.html>the history of the
137 project</a>.</p>
138
139 <a name=add_package /><h2>Q: How do I add $PACKAGE to my system image's root filesystem?</h2>
140
141 <p>A: Use the rw-system-image instead of the system-image. This gives
142 you a writeable root filesystem with enough extra space to install your
143 package in.</p>
144
145 <p>FWL builds squashfs images by default, and the prebuilt binary tarballs in
146 the downloads/binaries directory are built with the default values. Squashfs 146 the downloads/binaries directory are built with the default values. Squashfs
147 is a read-only compressed filesystem, which means it's pretty durable (you 147 is a read-only compressed filesystem, which means it's pretty durable (you
148 never need to fsck it), but also a bit limiting. The dev-environment.sh 148 never need to fsck it), but also a bit limiting. The dev-environment.sh
149 script attaches a 2 gigabyte ext2 image to /dev/hdb (which is mounted on 149 script attaches a 2 gigabyte ext2 image to /dev/hdb (which is mounted on
150 /home) so you always have writeable space to build stuff in, but that doesn't 150 /home) so you always have writeable space to build stuff in, but that doesn't
166 As always, your new system image is created in the "build" subdirectory.</p> 166 As always, your new system image is created in the "build" subdirectory.</p>
167 167
168 <p>Note: since this is a writeable image, you'll have to fsck it. You can 168 <p>Note: since this is a writeable image, you'll have to fsck it. You can
169 also use "tune2fs -j" to turn it into an ext3 image.</p> 169 also use "tune2fs -j" to turn it into an ext3 image.</p>
170 170
171 <a name=ubuntu_mispackaged_qemu /><h2>Q: ./run-emulator.sh says qemu-system-$TARGET isn't found, but I installed the qemu package and the executable "qemu" is there. Why isn't this working?</h2> 171 <p>Alternately, you can boot from squashfs using the dev-environment.sh
172 172 script and copy it to a writeable chroot in the /home directory. The
173 <p>A: You're using Ubuntu, aren't you? You need to install 173 gentoo-stage1 build in sources/native-builds does this like so:</p>
174 "qemu-kvm-extras" to get the non-x86 targets.</p> 174
175 175 <blockquote><pre>
176 <p>The Ubuntu developers have packaged qemu in an <strike>actively 176 mkdir gentoo-stage1
177 misleading</strike> "interesting" way. They've confused the emulator QEMU 177 find / -xdev | cpio -m -v -p /home/gentoo-stage1
178 with the virtualizer KVM.</p> 178
179 179 echo Restarting init script in chroot
180 <p>QEMU is an emulator that supports multiple hardware 180
181 targets, translating the target code into host code a page at a time. KVM 181 for i in mnt proc sys dev
182 stands for Kernel Virtualization Module, a kernel module which allows newer x86 182 do
183 chips with support for the "VT" extension to run x86 code in a virtual 183 mount --bind /$i gentoo-stage1/$i
184 container.</p> 184 done
185 185
186 <p>The KVM project started life as a fork of QEMU (replacing QEMU's CPU 186 chroot gentoo-stage1 /mnt/init
187 emulation with a kernel module providing VT virtualization support, but 187
188 using QEMU's device emulation for I/O), but KVM only ever offered a 188 for i in mnt proc sys dev
189 small subset of the functionality of QEMU, and current versions of QEMU have 189 do
190 merged KVM support into the base package. (QEMU 0.11.0 can automatically 190 umount gentoo-stage1/$i
191 detect and use the KVM module as an accelerator, where appropriate.)</p> 191 done
192 192
193 <p>It's a bit like the X11 project providing a "drm" module (for 3D acceleration 193 tar cvjf gentoo-stage1.tar.bz2 gentoo-stage1
194 and such), which was integrated upstream into the Linux kernel. The Linux 194 </pre></blockquote>
195 kernel was never part of the X11 project, and vice versa, and pretending the 195
196 two projects were the same thing would be wrong.</p> 196 <hr /><a name=case_sensitive_patch /><h2>Q: I added a uClibc patch to sources/patches but it didn't do anything, what's wrong?</h2>
197
198 <p>That said, on Ubuntu the "qemu" package is an alias for "qemu-kvm", a
199 package which only supports i386 and x86_64 (because that's all KVM supports
200 when running on an x86 PC). In order to install the rest of qemu (support
201 for emulating arm, mips, powerpc, sh4, and so on), you need to install
202 the "qemu-kvm-extras" package (which despite the name has nothing whatsoever
203 to do with KVM).</p>
204
205 <p>Support for non-x86 targets is part of the base package when you build QEMU
206 from source. If you ignore Ubuntu's packaging insanity and build QEMU
207 from source, you shouldn't have to worry about this strangely named
208 artificial split.</p>
209
210 <a name=case_sensitive_patch /><h2>Q: I added a uClibc patch to sources/patches but it didn't do anything, what's wrong?</h2>
211 197
212 <p>The Linux filesystem is case sensitive, so the patch has to start with 198 <p>The Linux filesystem is case sensitive, so the patch has to start with
213 "uClibc-" with a capital C.</p> 199 "uClibc-" with a capital C.</p>
214 200
215 <a name=package_breaks /><h2>Q: Why did the $NAME package build die 201 <hr /><a name=package_breaks /><h2>Q: Why did the $NAME package build die
216 with a complaint that it couldn't find $PREREQUISITE, even though that's 202 with a complaint that it couldn't find $PREREQUISITE, even though that's
217 installed on the host? (For example, distcc and python.)</h2> 203 installed on the host? (For example, distcc and python.)</h2>
218 204
219 <p>Because you skipped the host-tools.sh step, and because installing a package 205 <p>Because you skipped the host-tools.sh step, and because installing a package
220 on the host isn't the same as installing it on the target.</p> 206 on the host isn't the same as installing it on the target.</p>
228 detect that libtool exists, or that the host has Python or Perl installed, 214 detect that libtool exists, or that the host has Python or Perl installed,
229 and configure the packages to make use of things that the cross compiler's 215 and configure the packages to make use of things that the cross compiler's
230 headers and libraries don't have, and that the target root filesystem 216 headers and libraries don't have, and that the target root filesystem
231 may not have installed.</p> 217 may not have installed.</p>
232 218
233 <a name=environment_sanitizing /><h2>Q: Why isn't the build listening to the environment variables I set?</h2> 219 <hr /><a name=environment_sanitizing /><h2>Q: Why isn't the build listening to the environment variables I set?</h2>
234 220
235 <p>Quick answer: export NO_SANITIZE_ENVIRONMENT=1.</p> 221 <p>Quick answer: export NO_SANITIZE_ENVIRONMENT=1.</p>
236 222
237 <p>Long answer: you probably deleted the commented out variables from "config" 223 <p>Long answer: you probably deleted the commented out variables from "config"
238 and then tried to set them on the command line. The environment sanitizing 224 and then tried to set them on the command line. The environment sanitizing
239 logic has a whitelist of variables, but also looks at config to see what 225 logic has a whitelist of variables, but also looks at config to see what
240 variables are exported in there (whether they're commented out or not) and 226 variables are exported in there (whether they're commented out or not) and
241 lets those through from the environment as well. If you remove them from 227 lets those through from the environment as well. If you remove them from
242 config, it won't let them through from the environment.</p> 228 config, it won't let them through from the environment.</p>
243 229
244 <a name="debugging" /><h1>Debugging questions</h1> 230 <hr /><a name="debugging" /><h1>Debugging questions</h1>
245 231
246 <a name="debug_logging" /><h2>Q: How do I get better log output from the build?</h2> 232 <hr /><a name="debug_logging" /><h2>Q: How do I get better log output from the build?</h2>
247 233
248 <h3><b>Get a verbose, single-processor log of the build output.</b></h3> 234 <h3><b>Get a verbose, single-processor log of the build output.</b></h3>
249 235
250 <p>When something goes wrong, re-run your build with a couple extra variables, 236 <p>When something goes wrong, re-run your build with a couple extra variables,
251 and log the output with "tee":</p> 237 and log the output with "tee":</p>
291 <p>The script "more/report-recorded-commands.sh" prints out a list of all 277 <p>The script "more/report-recorded-commands.sh" prints out a list of all
292 commands used by each build stage. (Comparing the host-tools version 278 commands used by each build stage. (Comparing the host-tools version
293 to a run without host-tools can be instructive; that's the extra stuff 279 to a run without host-tools can be instructive; that's the extra stuff
294 ./configure is picking up out of the host environment.)</p> 280 ./configure is picking up out of the host environment.)</p>
295 281
296 <a name=debug_source /><h2>Q: How do I play around with package source code?</p></h2> 282 <hr /><a name=debug_test /><h2>Q: How do I run my own build snippets without editing the build scripts?</p></h2>
283
284 <p>A: Use the more/test.sh script</p>
285
286 <p>The more/test.sh script's first argument is the target to build for, and
287 the rest of its arguments are a command line to run as if building for that
288 target. It sets up the same context for building for an $ARCH the scripts use
289 (adds the appropriate cross compiler to the $PATH if it's been build, sets
290 all the shell functions and environment variables, and so on), and then runs
291 the rest of the command line in that context.</p>
292
293 <p>Examples:</p>
294 <blockquote><pre>
295 more/test.sh armv5l build_section busybox
296 more/test.sh mips getconfig linux
297 </pre></blockquote>
298
299 <p>You can also write your own script and source sources/include.sh and
300 call read_arch_dir yourself at the top of it, but that's pretty much all
301 test.sh does.</p>
302
303 <hr /><a name=debug_source /><h2>Q: How do I play around with package source code?</p></h2>
297 304
298 <p>The source code used by package builds lives in several directories, each 305 <p>The source code used by package builds lives in several directories, each
299 with a different purpose:</p> 306 with a different purpose:</p>
300 307
301 <ul> 308 <ul>
345 after each successful build. If you want to look at clean source, you 352 after each successful build. If you want to look at clean source, you
346 want the package cache. If you want to look at the state of a failed 353 want the package cache. If you want to look at the state of a failed
347 build to see how it was configured or re-run portions of it, you want the 354 build to see how it was configured or re-run portions of it, you want the
348 working copy.</p> 355 working copy.</p>
349 356
350 <a name=debug_package_cache /><h2>Q: What's the package cache for?</p></h2> 357 <hr /><a name=debug_package_cache /><h2>Q: What's the package cache for?</p></h2>
351 358
352 <p>The package cache contains clean architecture-independent source code, 359 <p>The package cache contains clean architecture-independent source code,
353 which you can edit, use to run modified builds and create patches, and easily 360 which you can edit, use to run modified builds and create patches, and easily
354 revert to its original condition. The package cache avoids re-extracting the 361 revert to its original condition. The package cache avoids re-extracting the
355 same tarballs over and over, but also provides a place you can make temporary 362 same tarballs over and over, but also provides a place you can make temporary
429 <blockquote><pre> 436 <blockquote><pre>
430 rm -rf build/packages 437 rm -rf build/packages
431 EXTRACT_ALL=1 ./download.sh 438 EXTRACT_ALL=1 ./download.sh
432 </pre></blockquote> 439 </pre></blockquote>
433 440
434 <a name=debug_working_copies /><h2>Q: What are working copies for?</p></h2> 441 <hr /><a name=debug_working_copies /><h2>Q: What are working copies for?</p></h2>
435 442
436 <p>Working copies are target-specific copies of package source where builds 443 <p>Working copies are target-specific copies of package source where builds
437 actually happen. The build scripts clone a fresh working copy for each build, 444 actually happen. The build scripts clone a fresh working copy for each build,
438 then run configure, make, and install commands in the new copy. They leave the 445 then run configure, make, and install commands in the new copy. They leave the
439 aftermath of failed builds lying around for analysis; to keep the working 446 aftermath of failed builds lying around for analysis; to keep the working
472 <p>If you want to search just the generated files and not the snapshot of 479 <p>If you want to search just the generated files and not the snapshot of
473 the source, use "find $PACKAGE -links 1". If you want to search just 480 the source, use "find $PACKAGE -links 1". If you want to search just
474 the source files and not the generated files, that's what the package 481 the source files and not the generated files, that's what the package
475 cache is for.</p> 482 cache is for.</p>
476 483
477 <pre> 484 <hr /><a name=name_change /><h2>Q: Didn't this used to be called Firmware Linux?</h2>
478 TODO: 485
479 - more/test.sh ARCH build_section thingy 486 <p>A: Yup. The name changed shortly before the 1.0 release in 2010.</p>
480 </pre> 487
488 <p>The name "Aboriginal Linux" is based on a synonym for "native", as in
489 native compiling. It implies it's the first Linux on a new system, and also
490 that it can be replaced. It turns a system into something you can do
491 native development in, terraforming your environment so you can use it
492 to natively build your deployment environment (which may be something else
493 entirely).</p>
494
495 <p>Aboriginal Linux is cross compiled, but after it boots you shouldn't need
496 to do any more cross compiling. (Except optionally using the cross compiler
497 as a native building accelerator via distcc.) Hence our motto,
498 "We cross compile so you don't have to".</p>
499
500 <p>The old name didn't describe the project very well. (It also had tens
501 of millions of Google hits, most of which weren't this project.) If you're
502 really bored, there's a page on <a href=history.html>the history of the
503 project</a>.</p>
504
505 <hr /><a name=ubuntu_mispackaged_qemu /><h2>Q: ./run-emulator.sh says qemu-system-$TARGET isn't found, but I installed the qemu package and the executable "qemu" is there. Why isn't this working?</h2>
506
507 <p>A: You're using Ubuntu, aren't you? You need to install
508 "qemu-kvm-extras" to get the non-x86 targets.</p>
509
510 <p>The Ubuntu developers have packaged qemu in an <strike>actively
511 misleading</strike> "interesting" way. They've confused the emulator QEMU
512 with the virtualizer KVM.</p>
513
514 <p>QEMU is an emulator that supports multiple hardware
515 targets, translating the target code into host code a page at a time. KVM
516 stands for Kernel Virtualization Module, a kernel module which allows newer x86
517 chips with support for the "VT" extension to run x86 code in a virtual
518 container.</p>
519
520 <p>The KVM project started life as a fork of QEMU (replacing QEMU's CPU
521 emulation with a kernel module providing VT virtualization support, but
522 using QEMU's device emulation for I/O), but KVM only ever offered a
523 small subset of the functionality of QEMU, and current versions of QEMU have
524 merged KVM support into the base package. (QEMU 0.11.0 can automatically
525 detect and use the KVM module as an accelerator, where appropriate.)</p>
526
527 <p>It's a bit like the X11 project providing a "drm" module (for 3D acceleration
528 and such), which was integrated upstream into the Linux kernel. The Linux
529 kernel was never part of the X11 project, and vice versa, and pretending the
530 two projects were the same thing would be wrong.</p>
531
532 <p>That said, on Ubuntu the "qemu" package is an alias for "qemu-kvm", a
533 package which only supports i386 and x86_64 (because that's all KVM supports
534 when running on an x86 PC). In order to install the rest of qemu (support
535 for emulating arm, mips, powerpc, sh4, and so on), you need to install
536 the "qemu-kvm-extras" package (which despite the name has nothing whatsoever
537 to do with KVM).</p>
538
539 <p>Support for non-x86 targets is part of the base package when you build QEMU
540 from source. If you ignore Ubuntu's packaging insanity and build QEMU
541 from source, you shouldn't have to worry about this strangely named
542 artificial split.</p>
543
544 <hr /><a name=windows /><h2>Q: Do you care about windows?</h2>
545
546 <p>A: Not really, but <a href=http://www.davereyn.co.uk/download.htm>this
547 guy does</a>. You can download his prebuilt binary QEMU versions for Windows,
548 and launch the various prebuilt binary Linux system images under them for
549 each target. Then if you want to rebuild the system images from source, or
550 build more software for a given target, you can do so natively within a
551 system image.</p>
552
553 <p>If you want to cross compile from Cygwin or mingw or something, you're on
554 your own. Emulating a Linux system (thereby bypassing Windows entirely) is
555 fairly straightforward, assuming somebody else has already done the work of
556 porting the emulator. Trying to make Windows run posix apps is an unnatural
557 act involving ceremonial headgear and animal sacrifice just to get it to
558 fail the same way twice.</p>
559
560
481 561
482 <!--#include file="footer.html" --> 562 <!--#include file="footer.html" -->
483 </html> 563 </html>