Source files are simply ASCII text files. ASCII denotes a particular way of encoding letters into bit patterns. In an ASCII file, each character has eight bits all to itself. This creates a potential "alphabet" of 256 distinct characters, in that eight binary digits can form that many unique patterns. In practice, of course, we tend to limit ourselves to the familiar letters and digits. The bit-patterns used to represent those letters and digits are the same ones that were physically punched into the paper tape by my high school teletype, which in turn were the same one used by the telegraph industry for decades previously. ASCII text files, in other words, are telegrams, and as such they have no typographical frills. But for the same reason they are eternal, because the code never changes, and universal, because every text editing and word processing software ever written knows about this code.
Therefore just about any software can be used to create, edit, and read source code files. Object code files, then, are created from these source files by a piece of software called a compiler, and forged into a working application by another piece of software called a linker.
The triad of editor, compiler, and linker, taken together, form the core of a software development system. Now, it is possible to spend a lot of money on shrink-wrapped development systems with lovely graphical user interfaces and various ergonomic enhancements. In some cases it might even be a good and reasonable way to spend money. But on this side of the road, as it were, the very best software is usually the free stuff. Editor, compiler and linker are to hackers what ponies, stirrups, and archery sets were to the Mongols. Hackers live in the saddle, and hack on their own tools even while they are using them to create new applications. It is quite inconceivable that superior hacking tools could have been created from a blank sheet of paper by product engineers. Even if they are the brightest engineers in the world they are simply outnumbered.
In the GNU/Linux world there are two major text editing programs: the minimalist vi (known in some implementations as elvis) and the maximalist emacs. I use emacs, which might be thought of as a thermonuclear word processor. It was created by Richard Stallman; enough said. It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer--i.e., if someone else is getting paid to worry about how your words are formatted and printed--emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. For page layout and printing you can use TeX: a vast corpus of typesetting lore written in C and also available on the Net for free.
I could say a lot about emacs and TeX, but right now I am trying to tell a story about how to actually install Linux on your machine. The hard-core survivalist approach would be to download an editor like emacs, and the GNU Tools--the compiler and linker--which are polished and excellent to the same degree as emacs. Equipped with these, one would be able to start downloading ASCII source code files (/src) and compiling them into binary object code files (/bin) that would run on the machine. But in order to even arrive at this point--to get emacs running, for example--you have to have Linux actually up and running on your machine. And even a minimal Linux operating system requires thousands of binary files all acting in concert, and arranged and linked together just so.
Several entities have therefore taken it upon themselves to create "distributions" of Linux.  If you are an Egyptian, of course, you see it the other way; tour guides exist to keep brutish outlanders from traipsing through your mosques and asking you the same questions over and over and over again.
Some of these tour guides are commercial organizations, such as Red Hat Software, which makes a Linux distribution called Red Hat that has a relatively commercial sheen to it. In most cases you put a Red Hat CD-ROM into your PC and reboot and it handles the rest. Just as a tour guide in Egypt will expect some sort of compensation for his services, commercial distributions need to be paid for. In most cases they cost almost nothing and are well worth it.
I use a distribution called Debian (the word is a contraction of "Deborah" and "Ian") which is non-commercial. It is organized (or perhaps I should say "it has organized itself") along the same lines as Linux in general, which is to say that it consists of volunteers who collaborate over the Net, each responsible for looking after a different chunk of the system. These people have broken Linux down into a number of packages, which are compressed files that can be downloaded to an already functioning Debian Linux system, then opened up and unpacked using a free installer application.  You can download all Debian packages over the Net, but most people will want to have them on a CD-ROM. Several different companies have taken it upon themselves to decoct all of the current Debian packages onto CD-ROMs and then sell them. I buy mine from Linux Systems Labs. The cost for a three-disc set, containing Debian in its entirety, is less than three dollars. But (and this is an important distinction) not a single penny of that three dollars is going to any of the coders who created Linux, nor to the Debian packagers. It goes to Linux Systems Labs and it pays, not for the software, or the packages, but for the cost of stamping out the CD-ROMs.
Every Linux distribution embodies some more or less clever hack for circumventing the normal boot process and causing your computer, when it is turned on, to organize itself, not as a PC running Windows, but as a "host" running Unix. This is slightly alarming the first time you see it, but completely harmless. When a PC boots up, it goes through a little self-test routine, taking an inventory of available disks and memory, and then begins looking around for a disk to boot up from. In any normal Windows computer that disk will be a hard drive. But if you have your system configured right, it will look first for a floppy or CD-ROM disk, and boot from that if one is available.
Linux exploits this chink in the defenses. Your computer notices a bootable disk in the floppy or CD-ROM drive, loads in some object code from that disk, and blindly begins to execute it. But this is not Microsoft or Apple code, this is Linux code, and so at this point your computer begins to behave very differently from what you are accustomed to. Cryptic messages began to scroll up the screen. If you had booted a commercial OS, you would, at this point, be seeing a "Welcome to MacOS" cartoon, or a screen filled with clouds in a blue sky, and a Windows logo. But under Linux you get a long telegram printed in stark white letters on a black screen. There is no "welcome!" message. Most of the telegram has the semi-inscrutable menace of graffiti tags.
Dec 14 15:04:15 theRev syslogd 1.3-3#17: restart. Dec 14 15:04:15 theRev kernel: klogd 1.3-3, log source = /proc/kmsg started. Dec 14 15:04:15 theRev kernel: Loaded 3535 symbols from /System.map. Dec 14 15:04:15 theRev kernel: Symbols match kernel version 2.0.30. Dec 14 15:04:15 theRev kernel: No module symbols loaded. Dec 14 15:04:15 theRev kernel: Intel MultiProcessor Specification v1.4 Dec 14 15:04:15 theRev kernel: Virtual Wire compatibility mode. Dec 14 15:04:15 theRev kernel: OEM ID: INTEL Product ID: 440FX APIC at: 0xFEE00000 Dec 14 15:04:15 theRev kernel: Processor #0 Pentium(tm) Pro APIC version 17 Dec 14 15:04:15 theRev kernel: Processor #1 Pentium(tm) Pro APIC version 17 Dec 14 15:04:15 theRev kernel: I/O APIC #2 Version 17 at 0xFEC00000. Dec 14 15:04:15 theRev kernel: Processors: 2 Dec 14 15:04:15 theRev kernel: Console: 16 point font, 400 scans Dec 14 15:04:15 theRev kernel: Console: colour VGA+ 80x25, 1 virtual console (max 63) Dec 14 15:04:15 theRev kernel: pcibios_init : BIOS32 Service Directory structure at 0x000fdb70 Dec 14 15:04:15 theRev kernel: pcibios_init : BIOS32 Service Directory entry at 0xfdb80 Dec 14 15:04:15 theRev kernel: pcibios_init : PCI BIOS revision 2.10 entry at 0xfdba1 Dec 14 15:04:15 theRev kernel: Probing PCI hardware. Dec 14 15:04:15 theRev kernel: Warning : Unknown PCI device (10b7:9001). Please read include/linux/pci.h Dec 14 15:04:15 theRev kernel: Calibrating delay loop.. ok - 179.40 BogoMIPS Dec 14 15:04:15 theRev kernel: Memory: 64268k/66556k available (700k kernel code, 384k reserved, 1204k data) Dec 14 15:04:15 theRev kernel: Swansea University Computer Society NET3.035 for Linux 2.0 Dec 14 15:04:15 theRev kernel: NET3: Unix domain sockets 0.13 for Linux NET3.035. Dec 14 15:04:15 theRev kernel: Swansea University Computer Society TCP/IP for NET3.034 Dec 14 15:04:15 theRev kernel: IP Protocols: ICMP, UDP, TCP Dec 14 15:04:15 theRev kernel: Checking 386/387 coupling... Ok, fpu using exception 16 error reporting. Dec 14 15:04:15 theRev kernel: Checking 'hlt' instruction... Ok. Dec 14 15:04:15 theRev kernel: Linux version 2.0.30 (root@theRev) (gcc version <IP_ADDRESS>) #15 Fri Mar 27 16:37:24 PST 1998 Dec 14 15:04:15 theRev kernel: Booting processor 1 stack 00002000: Calibrating delay loop.. ok - 179.40 BogoMIPS Dec 14 15:04:15 theRev kernel: Total of 2 processors activated (358.81 BogoMIPS). Dec 14 15:04:15 theRev kernel: Serial driver version 4.13 with no serial options enabled Dec 14 15:04:15 theRev kernel: tty00 at 0x03f8 (irq = 4) is a 16550A Dec 14 15:04:15 theRev kernel: tty01 at 0x02f8 (irq = 3) is a 16550A Dec 14 15:04:15 theRev kernel: lp1 at 0x0378, (polling) Dec 14 15:04:15 theRev kernel: PS/2 auxiliary pointing device detected -- driver installed. Dec 14 15:04:15 theRev kernel: Real Time Clock Driver v1.07 Dec 14 15:04:15 theRev kernel: loop: registered device at major 7 Dec 14 15:04:15 theRev kernel: ide: i82371 PIIX (Triton) on PCI bus 0 function 57 Dec 14 15:04:15 theRev kernel: ide0: BM-DMA at 0xffa0-0xffa7 Dec 14 15:04:15 theRev kernel: ide1: BM-DMA at 0xffa8-0xffaf Dec 14 15:04:15 theRev kernel: hda: Conner Peripherals 1275MB - CFS1275A, 1219MB w/64kB Cache, LBA, CHS=619/64/63 Dec 14 15:04:15 theRev kernel: hdb: Maxtor 84320A5, 4119MB w/256kB Cache, LBA, CHS=8928/15/63, DMA Dec 14 15:04:15 theRev kernel: hdc: , ATAPI CDROM drive Dec 15 11:58:06 theRev kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Dec 15 11:58:06 theRev kernel: ide1 at 0x170-0x177,0x376 on irq 15 Dec 15 11:58:06 theRev kernel: Floppy drive(s): fd0 is 1.44M Dec 15 11:58:06 theRev kernel: Started kswapd v <IP_ADDRESS> Dec 15 11:58:06 theRev kernel: FDC 0 is a National Semiconductor PC87306 Dec 15 11:58:06 theRev kernel: md driver 0.35 MAX_MD_DEV=4, MAX_REAL=8 Dec 15 11:58:06 theRev kernel: PPP: version 2.2.0 (dynamic channel allocation) Dec 15 11:58:06 theRev kernel: TCP compression code copyright 1989 Regents of the University of California Dec 15 11:58:06 theRev kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. Dec 15 11:58:06 theRev kernel: PPP line discipline registered. Dec 15 11:58:06 theRev kernel: SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256). Dec 15 11:58:06 theRev kernel: eth0: 3Com 3c900 Boomerang 10Mbps/Combo at 0xef00, 00:60:08:a4:3c:db, IRQ 10 Dec 15 11:58:06 theRev kernel: 8K word-wide RAM 3:5 Rx:Tx split, 10base2 interface. Dec 15 11:58:06 theRev kernel: Enabling bus-master transmits and whole-frame receives. Dec 15 11:58:06 theRev kernel: 3c59x.c:v0.49 1/2/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html Dec 15 11:58:06 theRev kernel: Partition check: Dec 15 11:58:06 theRev kernel: hda: hda1 hda2 hda3 Dec 15 11:58:06 theRev kernel: hdb: hdb1 hdb2 Dec 15 11:58:06 theRev kernel: VFS: Mounted root (ext2 filesystem) readonly. Dec 15 11:58:06 theRev kernel: Adding Swap: 16124k swap-space (priority -1) Dec 15 11:58:06 theRev kernel: EXT2-fs warning: maximal mount count reached, running e2fsck is recommended Dec 15 11:58:06 theRev kernel: hdc: media changed Dec 15 11:58:06 theRev kernel: ISO9660 Extensions: RRIP_1991A Dec 15 11:58:07 theRev syslogd 1.3-3#17: restart. Dec 15 11:58:09 theRev diald[87]: Unable to open options file /etc/diald/diald.options: No such file or directory Dec 15 11:58:09 theRev diald[87]: No device specified. You must have at least one device! Dec 15 11:58:09 theRev diald[87]: You must define a connector script (option 'connect'). Dec 15 11:58:09 theRev diald[87]: You must define the remote ip address. Dec 15 11:58:09 theRev diald[87]: You must define the local ip address. Dec 15 11:58:09 theRev diald[87]: Terminating due to damaged reconfigure.The only parts of this that are readable, for normal people, are the error messages and warnings. And yet it's noteworthy that Linux doesn't stop, or crash, when it encounters an error; it spits out a pithy complaint, gives up on whatever processes were damaged, and keeps on rolling. This was decidedly not true of the early versions of Apple and Microsoft OSes, for the simple reason that an OS that is not capable of walking and chewing gum at the same time cannot possibly recover from errors. Looking for, and dealing with, errors requires a separate process running in parallel with the one that has erred. A kind of superego, if you will, that keeps an eye on all of the others, and jumps in when one goes astray. Now that MacOS and Windows can do more than one thing at a time they are much better at dealing with errors than they used to be, but they are not even close to Linux or other Unices in this respect; and their greater complexity has made them vulnerable to new types of errors.
FALLIBILITY, ATONEMENT, REDEMPTION, TRUST, AND OTHER ARCANE TECHNICAL CONCEPTS
Linux is not capable of having any centrally organized policies dictating how to write error messages and documentation, and so each programmer writes his own. Usually they are in English even though tons of Linux programmers are Europeans. Frequently they are funny. Always they are honest. If something bad has happened because the software simply isn't finished yet, or because the user screwed something up, this will be stated forthrightly. The command line interface makes it easy for programs to dribble out little comments, warnings, and messages here and there. Even if the application is imploding like a damaged submarine, it can still usually eke out a little S.O.S. message. Sometimes when you finish working with a program and shut it down, you find that it has left behind a series of mild warnings and low-grade error messages in the command-line interface window from which you launched it. As if the software were chatting to you about how it was doing the whole time you were working with it.
Documentation, under Linux, comes in the form of man (short for manual) pages. You can access these either through a GUI (xman) or from the command line (man). Here is a sample from the man page for a program called rsh:
"Stop signals stop the local rsh process only; this is arguably wrong, but currently hard to fix for reasons too complicated to explain here."
The man pages contain a lot of such material, which reads like the terse mutterings of pilots wrestling with the controls of damaged airplanes. The general feel is of a thousand monumental but obscure struggles seen in the stop-action light of a strobe. Each programmer is dealing with his own obstacles and bugs; he is too busy fixing them, and improving the software, to explain things at great length or to maintain elaborate pretensions.
In practice you hardly ever encounter a serious bug while running Linux. When you do, it is almost always with commercial software (several vendors sell software that runs under Linux). The operating system and its fundamental utility programs are too important to contain serious bugs. I have been running Linux every day since late 1995 and have seen many application programs go down in flames, but I have never seen the operating system crash. Never. Not once. There are quite a few Linux systems that have been running continuously and working hard for months or years without needing to be rebooted.
Commercial OSes have to adopt the same official stance towards errors as Communist countries had towards poverty. For doctrinal reasons it was not possible to admit that poverty was a serious problem in Communist countries, because the whole point of Communism was to eradicate poverty. Likewise, commercial OS companies like Apple and Microsoft can't go around admitting that their software has bugs and that it crashes all the time, any more than Disney can issue press releases stating that Mickey Mouse is an actor in a suit.
This is a problem, because errors do exist and bugs do happen.  Commercial OS vendors, as a direct consequence of being commercial, are forced to adopt the grossly disingenuous position that bugs are rare aberrations, usually someone else's fault, and therefore not really worth talking about in any detail. This posture, which everyone knows to be absurd, is not limited to press releases and ad campaigns. It informs the whole way these companies do business and relate to their customers. If the documentation were properly written, it would mention bugs, errors, and crashes on every single page. If the on-line help systems that come with these OSes reflected the experiences and concerns of their users, they would largely be devoted to instructions on how to cope with crashes and errors.
But this does not happen. Joint stock corporations are wonderful inventions that have given us many excellent goods and services. They are good at many things. Admitting failure is not one of them. Hell, they can't even admit minor shortcomings.
Of course, this behavior is not as pathological in a corporation as it would be in a human being. Most people, nowadays, understand that corporate press releases are issued for the benefit of the corporation's shareholders and not for the enlightenment of the public. Sometimes the results of this institutional dishonesty can be dreadful, as with tobacco and asbestos. In the case of commercial OS vendors it is nothing of the kind, of course; it is merely annoying.
Some might argue that consumer annoyance, over time, builds up into a kind of hardened plaque that can conceal serious decay, and that honesty might therefore be the best policy in the long run; the jury is still out on this in the operating system market. The business is expanding fast enough that it's still much better to have billions of chronically annoyed customers than millions of happy ones.
Most system administrators I know who work with Windows NT all the time agree that when it hits a snag, it has to be re-booted, and when it gets seriously messed up, the only way to fix it is to re-install the operating system from scratch. Or at least this is the only way that they know of to fix it, which amounts to the same thing. It is quite possible that the engineers at Microsoft have all sorts of insider knowledge on how to fix the system when it goes awry, but if they do, they do not seem to be getting the message out to any of the actual system administrators I know.
Because Linux is not commercial--because it is, in fact, free, as well as rather difficult to obtain, install, and operate--it does not have to maintain any pretensions as to its reliability. Consequently, it is much more reliable. When something goes wrong with Linux, the error is noticed and loudly discussed right away. Anyone with the requisite technical knowledge can go straight to the source code and point out the source of the error, which is then rapidly fixed by whichever hacker has carved out responsibility for that particular program.
As far as I know, Debian is the only Linux distribution that has its own constitution (http://www.debian.org/devel/constitution), but what really sold me on it was its phenomenal bug database (http://www.debian.org/Bugs), which is a sort of interactive Doomsday Book of error, fallibility, and redemption. It is simplicity itself. When had a problem with Debian in early January of 1997, I sent in a message describing the problem to<EMAIL_ADDRESS>My problem was promptly assigned a bug report number (#6518) and a severity level (the available choices being critical, grave, important, normal, fixed, and wishlist) and forwarded to mailing lists where Debian people hang out. Within twenty-four hours I had received five e-mails telling me how to fix the problem: two from North America, two from Europe, and one from Australia. All of these e-mails gave me the same suggestion, which worked, and made my problem go away. But at the same time, a transcript of this exchange was posted to Debian's bug database, so that if other users had the same problem later, they would be able to search through and find the solution without having to enter a new, redundant bug report.
Contrast this with the experience that I had when I tried to install Windows NT 4.0 on the very same machine about ten months later, in late 1997. The installation program simply stopped in the middle with no error messages. I went to the Microsoft Support website and tried to perform a search for existing help documents that would address my problem. The search engine was completely nonfunctional; it did nothing at all. It did not even give me a message telling me that it was not working.
Eventually I decided that my motherboard must be at fault; it was of a slightly unusual make and model, and NT did not support as many different motherboards as Linux. I am always looking for excuses, no matter how feeble, to buy new hardware, so I bought a new motherboard that was Windows NT logo-compatible, meaning that the Windows NT logo was printed right on the box. I installed this into my computer and got Linux running right away, then attempted to install Windows NT again. Again, the installation died without any error message or explanation. By this time a couple of weeks had gone by and I thought that perhaps the search engine on the Microsoft Support website might be up and running. I gave that a try but it still didn't work.
So I created a new Microsoft support account, then logged on to submit the incident. I supplied my product ID number when asked, and then began to follow the instructions on a series of help screens. In other words, I was submitting a bug report just as with the Debian bug tracking system. It's just that the interface was slicker--I was typing my complaint into little text-editing boxes on Web forms, doing it all through the GUI, whereas with Debian you send in an e-mail telegram. I knew that when I was finished submitting the bug report, it would become proprietary Microsoft information, and other users wouldn't be able to see it. Many Linux users would refuse to participate in such a scheme on ethical grounds, but I was willing to give it a shot as an experiment. In the end, though I was never able to submit my bug report, because the series of linked web pages that I was filling out eventually led me to a completely blank page: a dead end.
So I went back and clicked on the buttons for "phone support" and eventually was given a Microsoft telephone number. When I dialed this number I got a series of piercing beeps and a recorded message from the phone company saying "We're sorry, your call cannot be completed as dialed."
I tried the search page again--it was still completely nonfunctional. Then I tried PPI (Pay Per Incident) again. This led me through another series of Web pages until I dead-ended at one reading: "Notice-there is no Web page matching your request."
I tried it again, and eventually got to a Pay Per Incident screen reading: "OUT OF INCIDENTS. There are no unused incidents left in your account. If you would like to purchase a support incident, click OK-you will then be able to prepay for an incident...." The cost per incident was $95.
The experiment was beginning to seem rather expensive, so I gave up on the PPI approach and decided to have a go at the FAQs posted on Microsoft's website. None of the available FAQs had anything to do with my problem except for one entitled "I am having some problems installing NT" which appeared to have been written by flacks, not engineers.
So I gave up and still, to this day, have never gotten Windows NT installed on that particular machine. For me, the path of least resistance was simply to use Debian Linux.
In the world of open source software, bug reports are useful information. Making them public is a service to other users, and improves the OS. Making them public systematically is so important that highly intelligent people voluntarily put time and money into running bug databases. In the commercial OS world, however, reporting a bug is a privilege that you have to pay lots of money for. But if you pay for it, it follows that the bug report must be kept confidential--otherwise anyone could get the benefit of your ninety-five bucks! And yet nothing prevents NT users from setting up their own public bug database.
This is, in other words, another feature of the OS market that simply makes no sense unless you view it in the context of culture. What Microsoft is selling through Pay Per Incident isn't technical support so much as the continued illusion that its customers are engaging in some kind of rational business transaction. It is a sort of routine maintenance fee for the upkeep of the fantasy. If people really wanted a solid OS they would use Linux, and if they really wanted tech support they would find a way to get it; Microsoft's customers want something else.
As of this writing (Jan. 1999), something like 32,000 bugs have been reported to the Debian Linux bug database. Almost all of them have been fixed a long time ago. There are twelve "critical" bugs still outstanding, of which the oldest was posted 79 days ago. There are 20 outstanding "grave" bugs of which the oldest is 1166 days old. There are 48 "important" bugs and hundreds of "normal" and less important ones.
Likewise, BeOS (which I'll get to in a minute) has its own bug database (http://www.be.com/developers/bugs/index.html) with its own classification system, including such categories as "Not a Bug," "Acknowledged Feature," and "Will Not Fix." Some of the "bugs" here are nothing more than Be hackers blowing off steam, and are classified as "Input Acknowledged." For example, I found one that was posted on December 30th, 1998. It's in the middle of a long list of bugs, wedged between one entitled "Mouse working in very strange fashion" and another called "Change of BView frame does not affect, if BView not attached to a BWindow."
This one is entitled
R4: BeOS missing megalomaniacal figurehead to harness and focus developer rage
and it goes like this:
Be Status: Input Acknowledged BeOS Version: R3.2 Component: unknown Full Description: The BeOS needs a megalomaniacal egomaniac sitting on its throne to give it a human character which everyone loves to hate. Without this, the BeOS will languish in the impersonifiable realm of OSs that people can never quite get a handle on. You can judge the success of an OS not by the quality of its features, but by how infamous and disliked the leaders behind them are. I believe this is a side-effect of developer comraderie under miserable conditions. After all, misery loves company. I believe that making the BeOS less conceptually accessible and far less reliable will require developers to band together, thus developing the kind of community where strangers talk to one- another, kind of like at a grocery store before a huge snowstorm. Following this same program, it will likely be necessary to move the BeOS headquarters to a far-less-comfortable climate. General environmental discomfort will breed this attitude within and there truly is no greater recipe for success. I would suggest Seattle, but I think it's already taken. You might try Washington, DC, but definitely not somewhere like San Diego or Tucson.
Unfortunately, the Be bug reporting system strips off the names of the people who report the bugs (to protect them from retribution!?) and so I don't know who wrote this.
So it would appear that I'm in the middle of crowing about the technical and moral superiority of Debian Linux. But as almost always happens in the OS world, it's more complicated than that. I have Windows NT running on another machine, and the other day (Jan. 1999), when I had a problem with it, I decided to have another go at Microsoft Support. This time the search engine actually worked (though in order to reach it I had to identify myself as "advanced"). And instead of coughing up some useless FAQ, it located about two hundred documents (I was using very vague search criteria) that were obviously bug reports--though they were called something else. Microsoft, in other words, has got a system up and running that is functionally equivalent to Debian's bug database. It looks and feels different, of course, but it contains technical nitty-gritty and makes no bones about the existence of errors.
As I've explained, selling OSes for money is a basically untenable position, and the only way Apple and Microsoft can get away with it is by pursuing technological advancements as aggressively as they can, and by getting people to believe in, and to pay for, a particular image: in the case of Apple, that of the creative free thinker, and in the case of Microsoft, that of the respectable techno-bourgeois. Just like Disney, they're making money from selling an interface, a magic mirror.
Accordingly, it was the case until recently that the people who wrote manuals and created customer support websites for commercial OSes seemed to have been barred, by their employers' legal or PR departments, from admitting, even obliquely, that the software might contain bugs or that the interface might be suffering from the blinking twelve problem. They couldn't address users' actual difficulties. The manuals and websites were therefore useless, and caused even technically self-assured users to wonder whether they were going subtly insane.
When Apple engages in this sort of corporate behavior, one wants to believe that they are really trying their best.  But when Microsoft does it, one almost cannot help becoming a paranoid conspiracist. Obviously they are hiding something from us! And yet they are so powerful! They are trying to drive us crazy!
This approach to dealing with one's customers was straight out of the Central European totalitarianism of the mid-Twentieth Century. The adjectives "Kafkaesque" and "Orwellian" come to mind. It couldn't last, any more than the Berlin Wall could, and so now Microsoft has a publicly available bug database. It's called something else, and it takes a while to find it, but it's there.
They have, in other words, adapted to the two-tiered Eloi/Morlock structure of technological society. If you're an Eloi you install Windows, follow the instructions, hope for the best, and dumbly suffer when it breaks. If you're a Morlock you go to the website, tell it that you are "advanced," find the bug database, and get the truth straight from some anonymous Microsoft engineer.
But once Microsoft has taken this step, it raises the question, once again, of whether there is any point to being in the OS business at all. Customers might be willing to pay $95 to report a problem to Microsoft if, in return, they get some advice that no other user is getting. This has the useful side effect of keeping the users alienated from one another, which helps maintain the illusion that bugs are rare aberrations. But once the results of those bug reports become openly available on the Microsoft website, everything changes. No one is going to cough up $95 to report a problem when chances are good that some other sucker will do it first, and that instructions on how to fix the bug will then show up, for free, on a public website. And as the size of the bug database grows, it eventually becomes an open admission, on Microsoft's part, that their OSes have just as many bugs as their competitors'. There is no shame in that; as I mentioned, Debian's bug database has logged 32,000 reports so far. But it puts Microsoft on an equal footing with the others and makes it a lot harder for their customers--who want to believe--to believe.
MEMENTO MORI
Once the Linux machine has finished spitting out its jargonic opening telegram, it prompts me to log in with a user name and a password. At this point the machine is still running the command line interface, with white letters on a black screen. There are no windows, menus, or buttons. It does not respond to the mouse; it doesn't even know that the mouse is there. It is still possible to run a lot of software at this point. Emacs, for example, exists in both a CLI and a GUI version (actually there are two GUI versions, reflecting some sort of doctrinal schism between Richard Stallman and some hackers who got fed up with him). The same is true of many other Unix programs. Many don't have a GUI at all, and many that do are capable of running from the command line.
Of course, since my computer only has one monitor screen, I can only see one command line, and so you might think that I could only interact with one program at a time. But if I hold down the Alt key and then hit the F2 function button at the top of my keyboard, I am presented with a fresh, blank, black screen with a login prompt at the top of it. I can log in here and start some other program, then hit Alt-F1 and go back to the first screen, which is still doing whatever it was when I left it. Or I can do Alt-F3 and log in to a third screen, or a fourth, or a fifth. On one of these screens I might be logged in as myself, on another as root (the system administrator), on yet another I might be logged on to some other computer over the Internet.
Each of these screens is called, in Unix-speak, a tty, which is an abbreviation for teletype. So when I use my Linux system in this way I am going right back to that small room at Ames High School where I first wrote code twenty-five years ago, except that a tty is quieter and faster than a teletype, and capable of running vastly superior software, such as emacs or the GNU development tools.
It is easy (easy by Unix, not Apple/Microsoft standards) to configure a Linux machine so that it will go directly into a GUI when you boot it up. This way, you never see a tty screen at all. I still have mine boot into the white-on-black teletype screen however, as a computational memento mori. It used to be fashionable for a writer to keep a human skull on his desk as a reminder that he was mortal, that all about him was vanity. The tty screen reminds me that the same thing is true of slick user interfaces.
The X Windows System, which is the GUI of Unix, has to be capable of running on hundreds of different video cards with different chipsets, amounts of onboard memory, and motherboard buses. Likewise, there are hundreds of different types of monitors on the new and used market, each with different specifications, and so there are probably upwards of a million different possible combinations of card and monitor. The only thing they all have in common is that they all work in VGA mode, which is the old command-line screen that you see for a few seconds when you launch Windows. So Linux always starts in VGA, with a teletype interface, because at first it has no idea what sort of hardware is attached to your computer. In order to get beyond the glass teletype and into the GUI, you have to tell Linux exactly what kinds of hardware you have. If you get it wrong, you'll get a blank screen at best, and at worst you might actually destroy your monitor by feeding it signals it can't handle.
When I started using Linux this had to be done by hand. I once spent the better part of a month trying to get an oddball monitor to work for me, and filled the better part of a composition book with increasingly desperate scrawled notes. Nowadays, most Linux distributions ship with a program that automatically scans the video card and self-configures the system, so getting X Windows up and running is nearly as easy as installing an Apple/Microsoft GUI. The crucial information goes into a file (an ASCII text file, naturally) called XF86Config, which is worth looking at even if your distribution creates it for you automatically. For most people it looks like meaningless cryptic incantations, which is the whole point of looking at it. An Apple/Microsoft system needs to have the same information in order to launch its GUI, but it's apt to be deeply hidden somewhere, and it's probably in a file that can't even be opened and read by a text editor. All of the important files that make Linux systems work are right out in the open. They are always ASCII text files, so you don't need special tools to read them. You can look at them any time you want, which is good, and you can mess them up and render your system totally dysfunctional, which is not so good.
At any rate, assuming that my XF86Config file is just so, I enter the command "startx" to launch the X Windows System. The screen blanks out for a minute, the monitor makes strange twitching noises, then reconstitutes itself as a blank gray desktop with a mouse cursor in the middle. At the same time it is launching a window manager. X Windows is pretty low-level software; it provides the infrastructure for a GUI, and it's a heavy industrial infrastructure. But it doesn't do windows. That's handled by another category of application that sits atop X Windows, called a window manager. Several of these are available, all free of course. The classic is twm (Tom's Window Manager) but there is a smaller and supposedly more efficient variant of it called fvwm, which is what I use. I have my eye on a completely different window manager called Enlightenment, which may be the hippest single technology product I have ever seen, in that (a) it is for Linux, (b) it is freeware, (c) it is being developed by a very small number of obsessed hackers, and (d) it looks amazingly cool; it is the sort of window manager that might show up in the backdrop of an Aliens movie.
Anyway, the window manager acts as an intermediary between X Windows and whatever software you want to use. It draws the window frames, menus, and so on, while the applications themselves draw the actual content in the windows. The applications might be of any sort: text editors, Web browsers, graphics packages, or utility programs, such as a clock or calculator. In other words, from this point on, you feel as if you have been shunted into a parallel universe that is quite similar to the familiar Apple or Microsoft one, but slightly and pervasively different. The premier graphics program under Apple/Microsoft is Adobe Photoshop, but under Linux it's something called The GIMP. Instead of the Microsoft Office Suite, you can buy something called ApplixWare. Many commercial software packages, such as Mathematica, Netscape Communicator, and Adobe Acrobat, are available in Linux versions, and depending on how you set up your window manager you can make them look and behave just as they would under MacOS or Windows.
But there is one type of window you'll see on Linux GUI that is rare or nonexistent under other OSes. These windows are called "xterm" and contain nothing but lines of text--this time, black text on a white background, though you can make them be different colors if you choose. Each xterm window is a separate command line interface--a tty in a window. So even when you are in full GUI mode, you can still talk to your Linux machine through a command-line interface.
There are many good pieces of Unix software that do not have GUIs at all. This might be because they were developed before X Windows was available, or because the people who wrote them did not want to suffer through all the hassle of creating a GUI, or because they simply do not need one. In any event, those programs can be invoked by typing their names into the command line of an xterm window. The whoami command, mentioned earlier, is a good example. There is another called wc ("word count") which simply returns the number of lines, words, and characters in a text file.
The ability to run these little utility programs on the command line is a great virtue of Unix, and one that is unlikely to be duplicated by pure GUI operating systems. The wc command, for example, is the sort of thing that is easy to write with a command line interface. It probably does not consist of more than a few lines of code, and a clever programmer could probably write it in a single line. In compiled form it takes up just a few bytes of disk space. But the code required to give the same program a graphical user interface would probably run into hundreds or even thousands of lines, depending on how fancy the programmer wanted to make it. Compiled into a runnable piece of software, it would have a large overhead of GUI code. It would be slow to launch and it would use up a lot of memory. This would simply not be worth the effort, and so "wc" would never be written as an independent program at all. Instead users would have to wait for a word count feature to appear in a commercial software package.
GUIs tend to impose a large overhead on every single piece of software, even the smallest, and this overhead completely changes the programming environment. Small utility programs are no longer worth writing. Their functions, instead, tend to get swallowed up into omnibus software packages. As GUIs get more complex, and impose more and more overhead, this tendency becomes more pervasive, and the software packages grow ever more colossal; after a point they begin to merge with each other, as Microsoft Word and Excel and PowerPoint have merged into Microsoft Office: a stupendous software Wal-Mart sitting on the edge of a town filled with tiny shops that are all boarded up.
It is an unfair analogy, because when a tiny shop gets boarded up it means that some small shopkeeper has lost his business. Of course nothing of the kind happens when "wc" becomes subsumed into one of Microsoft Word's countless menu items. The only real drawback is a loss of flexibility for the user, but it is a loss that most customers obviously do not notice or care about. The most serious drawback to the Wal-Mart approach is that most users only want or need a tiny fraction of what is contained in these giant software packages. The remainder is clutter, dead weight. And yet the user in the next cubicle over will have completely different opinions as to what is useful and what isn't.
The other important thing to mention, here, is that Microsoft has included a genuinely cool feature in the Office package: a Basic programming package. Basic is the first computer language that I learned, back when I was using the paper tape and the teletype. By using the version of Basic that comes with Office you can write your own little utility programs that know how to interact with all of the little doohickeys, gewgaws, bells, and whistles in Office. Basic is easier to use than the languages typically employed in Unix command-line programming, and Office has reached many, many more people than the GNU tools. And so it is quite possible that this feature of Office will, in the end, spawn more hacking than GNU.
But now I'm talking about application software, not operating systems. And as I've said, Microsoft's application software tends to be very good stuff. I don't use it very much, because I am nowhere near their target market. If Microsoft ever makes a software package that I use and like, then it really will be time to dump their stock, because I am a market segment of one.
GEEK FATIGUE
Over the years that I've been working with Linux I have filled three and a half notebooks logging my experiences. I only begin writing things down when I'm doing something complicated, like setting up X Windows or fooling around with my Internet connection, and so these notebooks contain only the record of my struggles and frustrations. When things are going well for me, I'll work along happily for many months without jotting down a single note. So these notebooks make for pretty bleak reading. Changing anything under Linux is a matter of opening up various of those little ASCII text files and changing a word here and a character there, in ways that are extremely significant to how the system operates.
Many of the files that control how Linux operates are nothing more than command lines that became so long and complicated that not even Linux hackers could type them correctly. When working with something as powerful as Linux, you can easily devote a full half-hour to engineering a single command line. For example, the "find" command, which searches your file system for files that match certain criteria, is fantastically powerful and general. Its "man" is eleven pages long, and these are pithy pages; you could easily expand them into a whole book. And if that is not complicated enough in and of itself, you can always pipe the output of one Unix command to the input of another, equally complicated one. The "pon" command, which is used to fire up a PPP connection to the Internet, requires so much detailed information that it is basically impossible to launch it entirely from the command line. Instead you abstract big chunks of its input into three or four different files. You need a dialing script, which is effectively a little program telling it how to dial the phone and respond to various events; an options file, which lists up to about sixty different options on how the PPP connection is to be set up; and a secrets file, giving information about your password.
Presumably there are godlike Unix hackers somewhere in the world who don't need to use these little scripts and options files as crutches, and who can simply pound out fantastically complex command lines without making typographical errors and without having to spend hours flipping through documentation. But I'm not one of them. Like almost all Linux users, I depend on having all of those details hidden away in thousands of little ASCII text files, which are in turn wedged into the recesses of the Unix filesystem. When I want to change something about the way my system works, I edit those files. I know that if I don't keep track of every little change I've made, I won't be able to get your system back in working order after I've gotten it all messed up. Keeping hand-written logs is tedious, not to mention kind of anachronistic. But it's necessary.
I probably could have saved myself a lot of headaches by doing business with a company called Cygnus Support, which exists to provide assistance to users of free software. But I didn't, because I wanted to see if I could do it myself. The answer turned out to be yes, but just barely. And there are many tweaks and optimizations that I could probably make in my system that I have never gotten around to attempting, partly because I get tired of being a Morlock some days, and partly because I am afraid of fouling up a system that generally works well.
Though Linux works for me and many other users, its sheer power and generality is its Achilles' heel. If you know what you are doing, you can buy a cheap PC from any computer store, throw away the Windows discs that come with it, turn it into a Linux system of mind-boggling complexity and power. You can hook it up to twelve other Linux boxes and make it into part of a parallel computer. You can configure it so that a hundred different people can be logged onto it at once over the Internet, via as many modem lines, Ethernet cards, TCP/IP sockets, and packet radio links. You can hang half a dozen different monitors off of it and play DOOM with someone in Australia while tracking communications satellites in orbit and controlling your house's lights and thermostats and streaming live video from your web-cam and surfing the Net and designing circuit boards on the other screens. But the sheer power and complexity of the system--the qualities that make it so vastly technically superior to other OSes--sometimes make it seem too formidable for routine day-to-day use.
Sometimes, in other words, I just want to go to Disneyland.
The ideal OS for me would be one that had a well-designed GUI that was easy to set up and use, but that included terminal windows where I could revert to the command line interface, and run GNU software, when it made sense. A few years ago, Be Inc. invented exactly that OS. It is called the BeOS.
ETRE
Many people in the computer business have had a difficult time grappling with Be, Incorporated, for the simple reason that nothing about it seems to make any sense whatsoever. It was launched in late 1990, which makes it roughly contemporary with Linux. From the beginning it has been devoted to creating a new operating system that is, by design, incompatible with all the others (though, as we shall see, it is compatible with Unix in some very important ways). If a definition of "celebrity" is someone who is famous for being famous, then Be is an anti-celebrity. It is famous for not being famous; it is famous for being doomed. But it has been doomed for an awfully long time.
Be's mission might make more sense to hackers than to other people. In order to explain why I need to explain the concept of cruft, which, to people who write code, is nearly as abhorrent as unnecessary repetition.
If you've been to San Francisco you may have seen older buildings that have undergone "seismic upgrades," which frequently means that grotesque superstructures of modern steelwork are erected around buildings made in, say, a Classical style. When new threats arrive--if we have an Ice Age, for example--additional layers of even more high-tech stuff may be constructed, in turn, around these, until the original building is like a holy relic in a cathedral--a shard of yellowed bone enshrined in half a ton of fancy protective junk.
Analogous measures can be taken to keep creaky old operating systems working. It happens all the time. Ditching an worn-out old OS ought to be simplified by the fact that, unlike old buildings, OSes have no aesthetic or cultural merit that makes them intrinsically worth saving. But it doesn't work that way in practice. If you work with a computer, you have probably customized your "desktop," the environment in which you sit down to work every day, and spent a lot of money on software that works in that environment, and devoted much time to familiarizing yourself with how it all works. This takes a lot of time, and time is money. As already mentioned, the desire to have one's interactions with complex technologies simplified through the interface, and to surround yourself with virtual tchotchkes and lawn ornaments, is natural and pervasive--presumably a reaction against the complexity and formidable abstraction of the computer world. Computers give us more choices than we really want. We prefer to make those choices once, or accept the defaults handed to us by software companies, and let sleeping dogs lie. But when an OS gets changed, all the dogs jump up and start barking.
The average computer user is a technological antiquarian who doesn't really like things to change. He or she is like an urban professional who has just bought a charming fixer-upper and is now moving the furniture and knicknacks around, and reorganizing the kitchen cupboards, so that everything's just right. If it is necessary for a bunch of engineers to scurry around in the basement shoring up the foundation so that it can support the new cast-iron claw-foot bathtub, and snaking new wires and pipes through the walls to supply modern appliances, why, so be it--engineers are cheap, at least when millions of OS users split the cost of their services.
 Sometimes this is actually possible. Adding more RAM to your system is a good example of an upgrade that is not likely to screw anything up.
Alas, very few upgrades are this clean and simple. Lawrence Lessig, the whilom Special Master in the Justice Department's antitrust suit against Microsoft, complained that he had installed Internet Explorer on his computer, and in so doing, lost all of his bookmarks--his personal list of signposts that he used to navigate through the maze of the Internet. It was as if he'd bought a new set of tires for his car, and then, when pulling away from the garage, discovered that, owing to some inscrutable side-effect, every signpost and road map in the world had been destroyed. If he's like most of us, he had put a lot of work into compiling that list of bookmarks. This is only a small taste of the sort of trouble that upgrades can cause. Crappy old OSes have value in the basically negative sense that changing to new ones makes us wish we'd never been born.
All of the fixing and patching that engineers must do in order to give us the benefits of new technology without forcing us to think about it, or to change our ways, produces a lot of code that, over time, turns into a giant clot of bubble gum, spackle, baling wire and duct tape surrounding every operating system. In the jargon of hackers, it is called "cruft." An operating system that has many, many layers of it is described as "crufty." Hackers hate to do things twice, but when they see something crufty, their first impulse is to rip it out, throw it away, and start anew.
If Mark Twain were brought back to San Francisco today and dropped into one of these old seismically upgraded buildings, it would look just the same to him, with all the doors and windows in the same places--but if he stepped outside, he wouldn't recognize it. And--if he'd been brought back with his wits intact--he might question whether the building had been worth going to so much trouble to save. At some point, one must ask the question: is this really worth it, or should we maybe just tear it down and put up a good one? Should we throw another human wave of structural engineers at stabilizing the Leaning Tower of Pisa, or should we just let the damn thing fall over and build a tower that doesn't suck?
Like an upgrade to an old building, cruft always seems like a good idea when the first layers of it go on--just routine maintenance, sound prudent management. This is especially true if (as it were) you never look into the cellar, or behind the drywall. But if you are a hacker who spends all his time looking at it from that point of view, cruft is fundamentally disgusting, and you can't avoid wanting to go after it with a crowbar. Or, better yet, simply walk out of the building--let the Leaning Tower of Pisa fall over--and go make a new one THAT DOESN'T LEAN.
For a long time it was obvious to Apple, Microsoft, and their customers that the first generation of GUI operating systems was doomed, and that they would eventually need to be ditched and replaced with completely fresh ones. During the late Eighties and early Nineties, Apple launched a few abortive efforts to make fundamentally new post-Mac OSes such as Pink and Taligent. When those efforts failed they launched a new project called Copland which also failed. In 1997 they flirted with the idea of acquiring Be, but instead they acquired Next, which has an OS called NextStep that is, in effect, a variant of Unix. As these efforts went on, and on, and on, and failed and failed and failed, Apple's engineers, who were among the best in the business, kept layering on the cruft. They were gamely trying to turn the little toaster into a multi-tasking, Internet-savvy machine, and did an amazingly good job of it for a while--sort of like a movie hero running across a jungle river by hopping across crocodiles' backs. But in the real world you eventually run out of crocodiles, or step on a really smart one.
Speaking of which, Microsoft tackled the same problem in a considerably more orderly way by creating a new OS called Windows NT, which is explicitly intended to be a direct competitor of Unix. NT stands for "New Technology" which might be read as an explicit rejection of cruft. And indeed, NT is reputed to be a lot less crufty than what MacOS eventually turned into; at one point the documentation needed to write code on the Mac filled something like 24 binders. Windows 95 was, and Windows 98 is, crufty because they have to be backward-compatible with older Microsoft OSes. Linux deals with the cruft problem in the same way that Eskimos supposedly dealt with senior citizens: if you insist on using old versions of Linux software, you will sooner or later find yourself drifting through the Bering Straits on a dwindling ice floe. They can get away with this because most of the software is free, so it costs nothing to download up-to-date versions, and because most Linux users are Morlocks.
The great idea behind BeOS was to start from a clean sheet of paper and design an OS the right way. And that is exactly what they did. This was obviously a good idea from an aesthetic standpoint, but does not a sound business plan make. Some people I know in the GNU/Linux world are annoyed with Be for going off on this quixotic adventure when their formidable skills could have been put to work helping to promulgate Linux.
Indeed, none of it makes sense until you remember that the founder of the company, Jean-Louis Gassee, is from France--a country that for many years maintained its own separate and independent version of the English monarchy at a court in St. Germaines, complete with courtiers, coronation ceremonies, a state religion and a foreign policy. Now, the same annoying yet admirable stiff-neckedness that gave us the Jacobites, the force de frappe, Airbus, and ARRET signs in Quebec, has brought us a really cool operating system. I fart in your general direction, Anglo-Saxon pig-dogs!
To create an entirely new OS from scratch, just because none of the existing ones was exactly right, struck me as an act of such colossal nerve that I felt compelled to support it. I bought a BeBox as soon as I could. The BeBox was a dual-processor machine, powered by Motorola chips, made specifically to run the BeOS; it could not run any other operating system. That's why I bought it. I felt it was a way to burn my bridges. Its most distinctive feature is two columns of LEDs on the front panel that zip up and down like tachometers to convey a sense of how hard each processor is working. I thought it looked cool, and besides, I reckoned that when the company went out of business in a few months, my BeBox would be a valuable collector's item.
Now it is about two years later and I am typing this on my BeBox. The LEDs (Das Blinkenlights, as they are called in the Be community) flash merrily next to my right elbow as I hit the keys. Be, Inc. is still in business, though they stopped making BeBoxes almost immediately after I bought mine. They made the sad, but probably quite wise decision that hardware was a sucker's game, and ported the BeOS to Macintoshes and Mac clones. Since these used the same sort of Motorola chips that powered the BeBox, this wasn't especially hard.
Very soon afterwards, Apple strangled the Mac-clone makers and restored its hardware monopoly. So, for a while, the only new machines that could run BeOS were made by Apple.
By this point Be, like Spiderman with his Spider-sense, had developed a keen sense of when they were about to get crushed like a bug. Even if they hadn't, the notion of being dependent on Apple--so frail and yet so vicious--for their continued existence should have put a fright into anyone. Now engaged in their own crocodile-hopping adventure, they ported the BeOS to Intel chips--the same chips used in Windows machines. And not a moment too soon, for when Apple came out with its new top-of-the-line hardware, based on the Motorola G3 chip, they withheld the technical data that Be's engineers would need to make the BeOS run on those machines. This would have killed Be, just like a slug between the eyes, if they hadn't made the jump to Intel.
So now BeOS runs on an assortment of hardware that is almost incredibly motley: BeBoxes, aging Macs and Mac orphan-clones, and Intel machines that are intended to be used for Windows. Of course the latter type are ubiquitous and shockingly cheap nowadays, so it would appear that Be's hardware troubles are finally over. Some German hackers have even come up with a Das Blinkenlights replacement: it's a circuit board kit that you can plug into PC-compatible machines running BeOS. It gives you the zooming LED tachometers that were such a popular feature of the BeBox.
My BeBox is already showing its age, as all computers do after a couple of years, and sooner or later I'll probably have to replace it with an Intel machine. Even after that, though, I will still be able to use it. Because, inevitably, someone has now ported Linux to the BeBox.
At any rate, BeOS has an extremely well-thought-out GUI built on a technological framework that is solid. It is based from the ground up on modern object-oriented software principles. BeOS software consists of quasi-independent software entities called objects, which communicate by sending messages to each other. The OS itself is made up of such objects, and serves as a kind of post office or Internet that routes messages to and fro, from object to object. The OS is multi-threaded, which means that like all other modern OSes it can walk and chew gum at the same time; but it gives programmers a lot of power over spawning and terminating threads, or independent sub-processes. It is also a multi-processing OS, which means that it is inherently good at running on computers that have more than one CPU (Linux and Windows NT can also do this proficiently).
For this user, a big selling point of BeOS is the built-in Terminal application, which enables you to open up windows that are equivalent to the xterm windows in Linux. In other words, the command line interface is available if you want it. And because BeOS hews to a certain standard called POSIX, it is capable of running most of the GNU software. That is to say that the vast array of command-line software developed by the GNU crowd will work in BeOS terminal windows without complaint. This includes the GNU development tools-the compiler and linker. And it includes all of the handy little utility programs. I'm writing this using a modern sort of user-friendly text editor called Pe, written by a Dutchman named Maarten Hekkelman, but when I want to find out how long it is, I jump to a terminal window and run "wc."
As is suggested by the sample bug report I quoted earlier, people who work for Be, and developers who write code for BeOS, seem to be enjoying themselves more than their counterparts in other OSes. They also seem to be a more diverse lot in general. A couple of years ago I went to an auditorium at a local university to see some representatives of Be put on a dog-and-pony show. I went because I assumed that the place would be empty and echoing, and I felt that they deserved an audience of at least one. In fact, I ended up standing in an aisle, for hundreds of students had packed the place. It was like a rock concert. One of the two Be engineers on the stage was a black man, which unfortunately is a very odd thing in the high-tech world. The other made a ringing denunciation of cruft, and extolled BeOS for its cruft-free qualities, and actually came out and said that in ten or fifteen years, when BeOS had become all crufty like MacOS and Windows 95, it would be time to simply throw it away and create a new OS from scratch. I doubt that this is an official Be, Inc. policy, but it sure made a big impression on everyone in the room! During the late Eighties, the MacOS was, for a time, the OS of cool people-artists and creative-minded hackers-and BeOS seems to have the potential to attract the same crowd now. Be mailing lists are crowded with hackers with names like Vladimir and Olaf and Pierre, sending flames to each other in fractured techno-English.
The only real question about BeOS is whether or not it is doomed.
Of late, Be has responded to the tiresome accusation that they are doomed with the assertion that BeOS is "a media operating system" made for media content creators, and hence is not really in competition with Windows at all. This is a little bit disingenuous. To go back to the car dealership analogy, it is like the Batmobile dealer claiming that he is not really in competition with the others because his car can go three times as fast as theirs and is also capable of flying.
Be has an office in Paris, and, as mentioned, the conversation on Be mailing lists has a strongly European flavor. At the same time they have made strenuous efforts to find a niche in Japan, and Hitachi has recently begun bundling BeOS with their PCs.  They are staying clear, for now, of Microsoft's overwhelmingly strong position in North America. They are trying to get themselves established around the edges of the board, as it were, in Europe and Japan, where people may be more open to alternative OSes, or at least more hostile to Microsoft, than they are in the United States.
What holds Be back in this country is that the smart people are afraid to look like suckers. You run the risk of looking naive when you say "I've tried the BeOS and here's what I think of it." It seems much more sophisticated to say "Be's chances of carving out a new niche in the highly competitive OS market are close to nil."
It is, in techno-speak, a problem of mindshare. And in the OS business, mindshare is more than just a PR issue; it has direct effects on the technology itself. All of the peripheral gizmos that can be hung off of a personal computer--the printers, scanners, PalmPilot interfaces, and Lego Mindstorms--require pieces of software called drivers. Likewise, video cards and (to a lesser extent) monitors need drivers. Even the different types of motherboards on the market relate to the OS in different ways, and separate code is required for each one. All of this hardware-specific code must not only written but also tested, debugged, upgraded, maintained, and supported. Because the hardware market has become so vast and complicated, what really determines an OS's fate is not how good the OS is technically, or how much it costs, but rather the availability of hardware-specific code. Linux hackers have to write that code themselves, and they have done an amazingly good job of keeping up to speed. Be, Inc. has to write all their own drivers, though as BeOS has begun gathering momentum, third-party developers have begun to contribute drivers, which are available on Be's web site.
But Microsoft owns the high ground at the moment, because it doesn't have to write its own drivers. Any hardware maker bringing a new video card or peripheral device to market today knows that it will be unsalable unless it comes with the hardware-specific code that will make it work under Windows, and so each hardware maker has accepted the burden of creating and maintaining its own library of drivers.
MINDSHARE
The U.S. Government's assertion that Microsoft has a monopoly in the OS market might be the most patently absurd claim ever advanced by the legal mind. Linux, a technically superior operating system, is being given away for free, and BeOS is available at a nominal price. This is simply a fact, which has to be accepted whether or not you like Microsoft.
Microsoft is really big and rich, and if some of the government's witnesses are to be believed, they are not nice guys. But the accusation of a monopoly simply does not make any sense.
What is really going on is that Microsoft has seized, for the time being, a certain type of high ground: they dominate in the competition for mindshare, and so any hardware or software maker who wants to be taken seriously feels compelled to make a product that is compatible with their operating systems. Since Windows-compatible drivers get written by the hardware makers, Microsoft doesn't have to write them; in effect, the hardware makers are adding new components to Windows, making it a more capable OS, without charging Microsoft for the service. It is a very good position to be in. The only way to fight such an opponent is to have an army of highly competetent coders who write equivalent drivers for free, which Linux does.
But possession of this psychological high ground is different from a monopoly in any normal sense of that word, because here the dominance has nothing to do with technical performance or price. The old robber-baron monopolies were monopolies because they physically controlled means of production and/or distribution. But in the software business, the means of production is hackers typing code, and the means of distribution is the Internet, and no one is claiming that Microsoft controls those.
Here, instead, the dominance is inside the minds of people who buy software. Microsoft has power because people believe it does. This power is very real. It makes lots of money. Judging from recent legal proceedings in both Washingtons, it would appear that this power and this money have inspired some very peculiar executives to come out and work for Microsoft, and that Bill Gates should have administered saliva tests to some of them before issuing them Microsoft ID cards.
But this is not the sort of power that fits any normal definition of the word "monopoly," and it's not amenable to a legal fix. The courts may order Microsoft to do things differently. They might even split the company up. But they can't really do anything about a mindshare monopoly, short of taking every man, woman, and child in the developed world and subjecting them to a lengthy brainwashing procedure.
Mindshare dominance is, in other words, a really odd sort of beast, something that the framers of our antitrust laws couldn't possibly have imagined. It looks like one of these modern, wacky chaos-theory phenomena, a complexity thing, in which a whole lot of independent but connected entities (the world's computer users), making decisions on their own, according to a few simple rules of thumb, generate a large phenomenon (total domination of the market by one company) that cannot be made sense of through any kind of rational analysis. Such phenomena are fraught with concealed tipping-points and all a-tangle with bizarre feedback loops, and cannot be understood; people who try, end up (a) going crazy, (b) giving up, (c) forming crackpot theories, or (d) becoming high-paid chaos theory consultants.
Now, there might be one or two people at Microsoft who are dense enough to believe that mindshare dominance is some kind of stable and enduring position. Maybe that even accounts for some of the weirdos they've hired in the pure-business end of the operation, the zealots who keep getting hauled into court by enraged judges. But most of them must have the wit to understand that phenomena like these are maddeningly unstable, and that there's no telling what weird, seemingly inconsequential event might cause the system to shift into a radically different configuration.
To put it another way, Microsoft can be confident that Thomas Penfield Jackson will not hand down an order that the brains of everyone in the developed world are to be summarily re-programmed. But there's no way to predict when people will decide, en masse, to re-program their own brains. This might explain some of Microsoft's behavior, such as their policy of keeping eerily large reserves of cash sitting around, and the extreme anxiety that they display whenever something like Java comes along.
I have never seen the inside of the building at Microsoft where the top executives hang out, but I have this fantasy that in the hallways, at regular intervals, big red alarm boxes are bolted to the wall. Each contains a large red button protected by a windowpane. A metal hammer dangles on a chain next to it. Above is a big sign reading: IN THE EVENT OF A CRASH IN MARKET SHARE, BREAK GLASS.
What happens when someone shatters the glass and hits the button, I don't know, but it sure would be interesting to find out. One imagines banks collapsing all over the world as Microsoft withdraws its cash reserves, and shrink-wrapped pallet-loads of hundred-dollar bills dropping from the skies. No doubt, Microsoft has a plan. But what I would really like to know is whether, at some level, their programmers might heave a big sigh of relief if the burden of writing the One Universal Interface to Everything were suddenly lifted from their shoulders.
THE RIGHT PINKY OF GOD
In his book The Life of the Cosmos, which everyone should read, Lee Smolin gives the best description I've ever read of how our universe emerged from an uncannily precise balancing of different fundamental constants. The mass of the proton, the strength of gravity, the range of the weak nuclear force, and a few dozen other fundamental constants completely determine what sort of universe will emerge from a Big Bang. If these values had been even slightly different, the universe would have been a vast ocean of tepid gas or a hot knot of plasma or some other basically uninteresting thing--a dud, in other words. The only way to get a universe that's not a dud--that has stars, heavy elements, planets, and life--is to get the basic numbers just right. If there were some machine, somewhere, that could spit out universes with randomly chosen values for their fundamental constants, then for every universe like ours it would produce 10^229 duds.
Though I haven't sat down and run the numbers on it, to me this seems comparable to the probability of making a Unix computer do something useful by logging into a tty and typing in command lines when you have forgotten all of the little options and keywords. Every time your right pinky slams that ENTER key, you are making another try. In some cases the operating system does nothing. In other cases it wipes out all of your files. In most cases it just gives you an error message. In other words, you get many duds. But sometimes, if you have it all just right, the computer grinds away for a while and then produces something like emacs. It actually generates complexity, which is Smolin's criterion for interestingness.
Not only that, but it's beginning to look as if, once you get below a certain size--way below the level of quarks, down into the realm of string theory--the universe can't be described very well by physics as it has been practiced since the days of Newton. If you look at a small enough scale, you see processes that look almost computational in nature.
I think that the message is very clear here: somewhere outside of and beyond our universe is an operating system, coded up over incalculable spans of time by some kind of hacker-demiurge. The cosmic operating system uses a command-line interface. It runs on something like a teletype, with lots of noise and heat; punched-out bits flutter down into its hopper like drifting stars. The demiurge sits at his teletype, pounding out one command line after another, specifying the values of fundamental constants of physics:
universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 1.673e-27....
and when he's finished typing out the command line, his right pinky hesitates above the ENTER key for an aeon or two, wondering what's going to happen; then down it comes--and the WHACK you hear is another Big Bang.
Now THAT is a cool operating system, and if such a thing were actually made available on the Internet (for free, of course) every hacker in the world would download it right away and then stay up all night long messing with it, spitting out universes right and left. Most of them would be pretty dull universes but some of them would be simply amazing. Because what those hackers would be aiming for would be much more ambitious than a universe that had a few stars and galaxies in it. Any run-of-the-mill hacker would be able to do that. No, the way to gain a towering reputation on the Internet would be to get so good at tweaking your command line that your universes would spontaneously develop life. And once the way to do that became common knowledge, those hackers would move on, trying to make their universes develop the right kind of life, trying to find the one change in the Nth decimal place of some physical constant that would give us an Earth in which, say, Hitler had been accepted into art school after all, and had ended up his days as a street artist with cranky political opinions.
Even if that fantasy came true, though, most users (including myself, on certain days) wouldn't want to bother learning to use all of those arcane commands, and struggling with all of the failures; a few dud universes can really clutter up your basement. After we'd spent a while pounding out command lines and hitting that ENTER key and spawning dull, failed universes, we would start to long for an OS that would go all the way to the opposite extreme: an OS that had the power to do everything--to live our life for us. In this OS, all of the possible decisions we could ever want to make would have been anticipated by clever programmers, and condensed into a series of dialog boxes. By clicking on radio buttons we could choose from among mutually exclusive choices (HETEROSEXUAL/HOMOSEXUAL). Columns of check boxes would enable us to select the things that we wanted in our life (GET MARRIED/WRITE GREAT AMERICAN NOVEL) and for more complicated options we could fill in little text boxes (NUMBER OF DAUGHTERS: NUMBER OF SONS:).
Even this user interface would begin to look awfully complicated after a while, with so many choices, and so many hidden interactions between choices. It could become damn near unmanageable--the blinking twelve problem all over again. The people who brought us this operating system would have to provide templates and wizards, giving us a few default lives that we could use as starting places for designing our own. Chances are that these default lives would actually look pretty damn good to most people, good enough, anyway, that they'd be reluctant to tear them open and mess around with them for fear of making them worse. So after a few releases the software would begin to look even simpler: you would boot it up and it would present you with a dialog box with a single large button in the middle labeled: LIVE. Once you had clicked that button, your life would begin. If anything got out of whack, or failed to meet your expectations, you could complain about it to Microsoft's Customer Support Department. If you got a flack on the line, he or she would tell you that your life was actually fine, that there was not a thing wrong with it, and in any event it would be a lot better after the next upgrade was rolled out. But if you persisted, and identified yourself as Advanced, you might get through to an actual engineer.
What would the engineer say, after you had explained your problem, and enumerated all of the dissatisfactions in your life? He would probably tell you that life is a very hard and complicated thing; that no interface can change that; that anyone who believes otherwise is a sucker; and that if you don't like having choices made for you, you should start making your own.
Copyright © 1999 by Neal Stephenson


Calendar Management System
Current Calendar: null
Results
Add/Remove Date
Schedule Meeting
Close Timeslot
Meeting Board
Opps!
There is no available calendar exists, do you want to create one?
Warning!
Are you sure you want to delet it?


The goal of crosslink is to visualize the network of grouped nodes
You can install the released version of crosslink from github with:
remotes::install_github("zzwch/crosslink", build_vignettes = TRUE)
Or download the compressed file Link, then run
remotes::install_local(path = "./crosslink-master.zip", build_vignettes = TRUE)
Examples of typical crosslink usage.
library(crosslink)
# generate a CrossLink object
cl <- crosslink(demo$nodes, demo$edges, demo$cross.by, odd.rm = F,spaces = "flank")
# set headers if needed
cl %<>% set_header(header = c("A","B","C","D","E","F"))
# plot the network
# By default, node color is coded and node size is proportional to its degree (calculated internally).
# And edge color is coded by the cross group of the edge's source node.
cl %>% cl_plot()
Users can also custom the aesthetics for node, edge, label and header by using cl_plot, which wrapped multiple ggplot2::geom_* functions in one interface. Please see below (Plotting modules) for more details.
This is a basic example of the basic function of crosslink packages,including 1). Input data 2). Generate CrossLink class 3). Coordinate transformation 4). Layout modules 5). Plotting modules
crosslink needs two files as input.
a. nodes (must have two columns: node name and node type)
b. edges data (must have two columns: source node and target node).
Here, crosslink uses the function ‘gen_demo’ to generate demo data.
n <- 6
demo <- gen_demo(n_cross = n,n_node = 4:(n+3), n_link = 3:(n+1), seed = 66)
nodes <- demo$nodes
edges <- demo$edges
cross.by <- demo$cross.by
crosslink can generate an object of crosslink class for plot.
# users can define 'odd.rm' to choose if remove the nodes have zero relationship with any other nodes when generate crosslink class
# user can set intervals between nodes and gaps through spaces and gaps.
cl <- crosslink(nodes, edges, cross.by, odd.rm = F,spaces = "flank")
# Header can be customized through 'set_header'
cl %<>% set_header(header = c("A","B","C","D","E","F"))
The default
layout is initialized by crosslink
function.
cl %>% cl_active() # get currrently active layout information of a CrossLink object
And, currently active layout will be based on for transforming coordinates. You can set another layout as active layout. All available layouts can be listed. See layout modules
to set more layouts.
cl %>% cl_layouts() # get all available layouts in a CrossLink object
cl_active(cl) <- "default" # set your favorate layout
Coordinate transformation consists of affine transformation and functional transformation. The tf_affine
function contains tf_rotate
, tf_shift
, tf_shear
, tf_flip
and tf_scale
function. The tf_fun
interface allows user to custom transforming function.
Note : The active layout before transformation will be based on to perform transforming, and the transformed coordinates will be stored in ‘transforming’ layout (Default, set layout
to change it, and a novel layout is permitted.).
# tf_rotate, rotating in a specific angle with (x,y) as the center.
cl %>% tf_rotate(x=0,y=1,angle = 45) %>% cl_plot()
# tf_shift, shifting a relative distance according to x-axis or y-axis
cl %>% tf_shift(x=1,y=-1) %>% cl_plot()
# tf_shear
cl %>% tf_shear(axis = "x",angle = 60) %>% cl_plot()
# tf_flip, flip the figure according to x-axis or y-axis
cl %>% tf_flip(axis = "y") %>% cl_plot()
# tf_scale
cl %>% tf_scale(x=0, y=1, scale.x = 5, scale.y = 5) %>% cl_plot()
# tf_fun, coordinate transformation according to custom-defined function
cl %>% tf_fun(fun = sin,along = "y",xrange.from=c(0,0.5*pi)) %>% cl_plot()
# combined transformation functions
cl %>% tf_flip(axis = "y") %>% tf_fun(fun = sin,along = "y",xrange.from=c(0,0.5*pi)) %>% cl_plot()
Different layout styles can be stored in a CrossLink object.
Because ‘default’ layout is routinely used as base layout for the layout module, it is strongly recommended not to override the ‘default’ layout (Important), unless you have known the transformation and layout modules well!
Several commonly used layout styles are predefined, including row, column, arc, polygon and hive. And crosses can be placed in one or multiple layouts.
Note : The ‘set_header’ function can be called to conveniently place headers after layouting.
# The 'default' layout is actually column.
cl %>% cl_plot()
# layout by column
cl %>% layout_column(layout_save = "column") %>% cl_plot()
# layout by row
cl %>% layout_row(layout_save = "row") %>% cl_plot()
# layout by arc, set header after transformation
cl %>% layout_arc(angles = 60,crosses = c("E","F"), layout_save = "arc") %>% set_header(hjust = 0.5, vjust = 1)%>% cl_plot()
# layout by polygon (list of angles must have the same length with crosses)
cl %>% layout_polygon(layout_save = "polygon") %>% cl_plot()
# layout by hive
cl %>% layout_hive(layout_save = "hive") %>% cl_plot()
We introduce this wrapper function cl_plot
in three steps.
a. quick plotting (cl_plot
)
b. aesthetic settings ( The color, size, type and text of the nodes and lines in the network)
c. combination of the network diagram with the corresponding node annotation graph in aligning coordinates
# aesthetic settings based on ggplot2 system, some specific examples are shown below.
# show available variables for aesthetic setting
cl %>% show_aes()
# set colors, shapes and size of nodes
# cross:a named list of arguments for crosses. usage same as ggplot2::geom_point(). Set NULL to use default settings, or Set NA to not show.
cl %>% cl_plot(cross = list(mapping = aes(color = type, shape= type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(6, "Dark2"),
guide = guide_legend(ncol = 2)),
size = scale_size_continuous(range = c(1,5),
guide = guide_legend(ncol = 2)),
shape = scale_shape_manual(values = c(13:18),
guide = guide_legend(ncol = 2))
)
))
# set colors, linetypes and size of edges
# link: a named list of arguments for links. usage same as ggplot2::geom_segment(). Set NULL to use default settings, or Set NA to not show.
cl %>% cl_plot(link = list(mapping = aes(color = src.cross, linetype =src.cross, size = src.degree),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(5, "Dark2"),
guide = guide_legend(ncol = 2)),
size = scale_size_continuous(range = c(1,3),
guide = guide_legend(ncol = 2)),
linetype = scale_linetype_manual(values = c(1:6),
guide = guide_legend(ncol = 2))
)
),
cross = list(show.legend = F) # disable cross's legends
)
# set header styles
# header: a named list of arguments for headers. usage same as ggplot2::geom_text(). Set NULL to use default settings, or Set NA to not show.
cl %>% cl_plot(header = list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size = 5.5
))
# set aesthetics (e.g., color, size, position) of labels
# label: a named list of arguments for labels of nodes. usage same as ggplot2::geom_text(). Set NULL to use default settings, or Set NA to not show.
cl %>% cl_plot(label = list(mapping = aes(color = type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"),
guide = guide_legend(ncol = 2))
),
nudge_y = -0.3, size = 4
))
# set figure theme
# add: other gg object to be added to final plot, such as theme().
theme_use <- theme(legend.position = "top", aspect.ratio = 1,
axis.title = element_blank(),
axis.text = element_blank(),
axis.ticks = element_blank(),
panel.grid = element_blank(),
panel.background = element_blank())
cl %>% cl_plot(add = theme_use)
# combined all aesthetic settings.
cl %>% cl_plot(cross = list(mapping = aes(color = type, shape= type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"),
guide = guide_legend(ncol = 2)),
size = scale_size_continuous(range = c(1,5),
guide = guide_legend(ncol = 2)),
shape = scale_shape_manual(values = c(13:18),
guide = guide_legend(ncol = 2))
)
),
link = list(mapping = aes(x = x + 0.1, xend = xend -0.1,
color = src.cross,linetype =src.cross, size = src.degree),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"),
guide = guide_legend(ncol = 2)),
size = scale_size_continuous(range = c(1,3),
guide = guide_legend(ncol = 2)),
linetype = scale_linetype_manual(values = c(1:6),
guide = guide_legend(ncol = 2))
),
size = 1.5
),
header = list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"),
guide = guide_legend(ncol = 2))),
size = 5.5
),
label = list(nudge_y = -0.3, size = 4
),
add = theme_use
)
# cl_annotation： add annotation figure.
# top, bottom, left or right : ggplot object
# top.by, bottom.by, left.by, right.by : name of cross by which to align ggplot
ann.data <- data.frame(F=factor(paste0("F",c(1:10)),levels=paste0("F",c(10:1))),value=sample(size = 10,x=c(1:10)))
ann.data %>% ggplot(mapping = aes(x=F,y=value))+geom_bar(stat="identity")+coord_flip() -> rgtAnn
cl %>% cl_plot(annotation=cl_annotation(right= rgtAnn,right.by ="F"))
There are several examples and practical applications.
generate a CrossLink object
cl <- crosslink(demo$nodes, demo$edges, demo$cross.by, odd.rm = F,spaces = "flank")
cl %<>% set_header(header = c("A","B","C","D","E","F"))
cl %>% layout_row() %>%
set_header(hjust = 0, vjust = 0.5) %>%
cl_plot(cross = list(mapping = aes(fill=type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2")),
fill = scale_fill_manual( values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=8,shape=24, color = "black"
),
link = list(mapping = aes(color = src.cross),
size=1.5, linetype=1),
label = list(color="white"),
header = list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5, show.legend = F
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
cl %>%
tf_rotate(angle = 10, by.each.cross = T) %>%
cl_plot(cross = list(mapping = aes(fill = type),
scale = list(fill = scale_fill_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=10, shape=24, color = "black"
),
link = list(mapping = aes(color = src.cross),
size=1.5, linetype=1),
label = list(color="white"),
header = list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5, show.legend = F
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
cl %>% layout_polygon() %>%
#tf_rotate(angle = 45, by.each.cross = F) %>% # If the grouping is 4, rotate by this parameter and change from diamond to square
cl_plot(cross = list(mapping = aes(color = type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=10,shape=16
),
link = list(geom = "curve",
mapping = aes(color = src.cross),
size=1.5, linetype=1
),
label = list(color="white"),
header= list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
cl %>% layout_hive(angles=rep(60,6)) %>% #length of angles must be same with the numbers of groups
cl_plot(cross = list(mapping = aes(color = type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=10,shape=18
),
link = list(geom = "curve", curvature = -0.5,
mapping = aes(color = src.cross),
size=1.5, linetype=1),
label = list(color="white"),
header= list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
cl %>% layout_arc(angles = 45) %>% #length of angles must be same with the numbers of crosses
cl_plot(cross = list(mapping = aes(color = type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=10, shape=18
),
link = list(mapping = aes(color = src.cross),
size=1, linetype=2),
label = list(color="white"),
header= list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
cl %>%
layout_polygon(crosses = c("A","B","C","D"), layout_save = "combined") %>%
layout_row(crosses = c("E", "F"), layout_save = "combined") %>%
tf_rotate(crosses=c("A","B","C","D"), x = 0, y = 0, angle = -45) %>%
tf_scale(crosses = c("E", "F"), x = 0.5, y = 0.5, scale.x = sqrt(2), scale.y = 3) %>%
cl_align(crosses.1 = c("A","B","C","D"), crosses.2 = c("E", "F"),
align.x = T, align.y = T,
anchor.1 = c(0.5, 0),
anchor.2 = c(0.5, 2)) %>%
cl_plot(cross = list(mapping = aes(color = type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=10,shape=19
),
link = list(color="grey75",size=1,linetype=3),
label = list(color="white"),
header = list(mapping = aes(color= cross),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2"))),
size=5
)
) %>%
cl_void(th = theme(aspect.ratio = 1))
library(dplyr)
library(reshape)
theme_classic() +
theme(axis.text = element_blank(),
axis.line.x = element_blank(),
axis.ticks.x = element_blank()) ->theme_use2
## crosslink project
cl <- crosslink(example$nodes,example$edges,cross.by="type")
cl %>% cl_plot()
cl <- set_header(cl,header=unique(get_cross(cl)$cross))
cl %>% layout_polygon(crosses = c("Mir","Meth","Gene","Drug"),layout_based = "default") %>%
tf_rotate(crosses= c("Mir","Meth","Gene","Drug"),angle = rep(45,4),layout="default") %>%
tf_shift(x=0.2*(-1),y=1.5,crosses=c("Mir","Meth"),layout="default") -> cl
# plot annotation
top <- nodes$id[nodes$type == "Mir"] # set the order as you like
bottom <- nodes$id[nodes$type == "Gene"] # set the order as you like
right <- nodes$id[nodes$type == "Meth"] # set the order as you like
# Top plot
topAnn <- mirData %>%
mutate(mir_f = factor(mir, top)) %>%
ggplot(mapping = aes(x=mir,y=-lfc)) +
geom_bar(fill = "#E7298A",
stat = "identity",
width = 0.5) +
labs(x = NULL, y = "log2(Fold Change)") +
theme_use2
topAnn
# Bottom plot
botAnn <- geneData %>%
mutate(meth_f = factor(gene, bottom)) %>%
ggplot(mapping = aes(x=gene,y=-lfc)) +
geom_bar(fill = RColorBrewer::brewer.pal(8, "Dark2")[c(1:5,7:9)][2],
stat = "identity",
width = 0.5) +
labs(x = NULL, y = "Difference") +
theme_use2
botAnn
# right plot
rgtAnn <- methData %>%
mutate(mir_f = factor(meth, right)) %>%
ggplot(mapping = aes(x=meth,y=-lfc)) +
geom_bar(fill = RColorBrewer::brewer.pal(8, "Dark2")[c(1:5,7:9)][3],
stat = "identity",
width = 0.5) +
labs(x = NULL, y = "log2(Fold Change)") +
theme_use2 +
coord_flip()
rgtAnn
# left plot
mat = matrix(sample(1:100, 64, replace = T), nrow = 8)
colnames(mat)=as.character(cl@cross$Drug)
ggplot(data = melt(mat), aes(X1, X2, fill = value))+
geom_tile(color = "white")+
scale_fill_gradient2(low = "blue", high = "darkgreen", mid = "white",midpoint = 0) +
xlab("")+ylab("")+theme_classic()+
theme(legend.position = "right",
axis.line = element_blank(),
axis.ticks = element_blank(),
axis.text = element_blank()) -> lftAnno
lftAnno
Combine network plot and four annotation plots
cl_plot(cl,
annotation=cl_annotation(top = topAnn,top.by = "Mir",top.height = 0.5,
bottom = botAnn,bottom.by = "Gene",bottom.height = 0.5,
right = rgtAnn,right.by ="Meth",right.width = 0.5,
left = lftAnno,left.by = "Drug" ,left.width = 0.5),
cross = list(mapping = aes(color = type,size=degree,shape=type),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Dark2")[c(1:5,7:9)]),
shape = scale_shape_manual(values = 15:23),
size = scale_size_continuous(range=c(1,5)))),
link = list(mapping = aes(color = type,linetype=type,size=cor),
scale = list(color = scale_color_manual(values = RColorBrewer::brewer.pal(8, "Set1")[c(1:5,7:9)]),
linetype=scale_linetype_manual(values = c(1:4)),
size=scale_size(range = c(1,2)))),
header=NA,
label = list(color="black"
,angle=c(rep(0,8),rep(90,10),rep(0,10),rep(90,6))
,nudge_x=c(rep(-2,8),rep(0,10),rep(2,10),rep(0,6))
,nudge_y=c(rep(0,8),rep(-2,10),rep(0,10),rep(2,6))),
add = theme(panel.background = element_blank(),
axis.title = element_blank(),
panel.grid = element_blank(),
axis.ticks = element_blank(),
axis.text = element_blank()))


Dear [[USERNAME]]
A new user account for [[SITENAME]] has been created for you. When you are ready to select a password, please click the link below. You'll then receive a new link that will allow you to enter a password.


Processors can be used to add additional steps to the execution of CodeDocs. Just add them to the configuration if you need them. You can also create your own Processors by implementing \CodeDocs\ProcessorInterface.
Here's a list of built-in processors:
| Processor | Description |
|---|---|
| CopyExportFiles | Copies generated doc files to a given directory |
| CreateFilesFromTopics | Creates files from Topic-Annotations |


About
Slim is a template language whose goal is reduce the syntax to the essential parts without becoming cryptic.
The initial design of Slim is what you see on the home page. It started as an exercise to see how much could be removed from a standard html template (<, >, closing tags, etc...). As more people took an interest in Slim, the functionality grew and so did the flexibility of the syntax.
While your Slim template can look more like Haml by using the id and class shortcuts, their use is optional. Slim will strive to maintain simplicity, but not everyone's definition of a readable syntax is the same. To this end, Slim provides optional syntax support so you can make it your own. The docs will show you the options.
Slim uses Temple and Tilt. If you want to learn how Slim works, you'll need to study these projects.
Source: stonean/slim | Slim logo & site design & site design by activestylus


Yield:
x
Width:
px
Background alpha:
Background color:
Use Gaussian downscale
Do not enlarge bitmaps
Make root HTML elements transparent
PNG output
JPEG output
%
Canvas
or just drop it, paste the SVG source
, it can even be a PNG, JPEG, whatever
, only SVG is supported
(rich text is also supported)