Disclaimer: I’m told that many of the books that I love are considered dry, boring, long, and unexciting in the eyes of others (I certainly don’t think they are in the least!). So my opinions on this book as fascinating ought to be taken in this light. (End of disclaimer.)

I’m not sure how long ago Thomas Thiemann published his tome Modern Canonical Quantum General Relativity but I picked up a copy the other day when I was getting paper for my printer at the UC Davis bookstore. Please let me emphasize this is a technical monograph with the intended audience being mathematically savvy individuals, not an introductory text for the lazy layman (even the hyperactive layman may have some difficulty).

The forward is written by Christopher Isham, who gives a rather interesting personal background on his personal interest in quantum general relativity stemming from his encounter in 1969 with a researcher named Abdus Salam.
The approach taken was perturbative quantization, which Isham notes:

“The perturbative quantum field theory schemes foundered on interactable ultra-violet divergences and gave way to super-gravity — the super-symmetric extension of standard general relativity. In spute of initial optimism, this approach succumbed to the same disease and was eventually replaced by the far more ambitious superstring theories” (Forward, paragraph 2).

Isham continues to explain his interest in canonical quantum gravity and in particular the Wheeler-DeWitt equation. The Wheeler-DeWitt equation is the Hamiltonian constraint in general relativity, it is the constraint corresponding to the time re-parametrization invariance gauge. It should be unsurprising that it is nightmarishly complicated and extremely difficult to solve in its traditional form using the metric tensor as the canonical position variable.

Thomas Thiemann pioneered the Master Constraint programme and did a tremendous amount of work on the Hamiltonian constraint that deserves the utmost respect (see these technical papers for a “small” taste: “Quantum Spin Dynamics“,
“Quantum Spin Dynamics II. The Kernel of the Wheeler-DeWitt Constraint Operator“,
“QSD III : Quantum Constraint Algebra and Physical Scalar Product in Quantum General Relativity“,
“QSD IV : 2+1 Euclidean Quantum Gravity as a model to test 3+1 Lorentzian Quantum Gravity“,
“QSD V : Quantum Gravity as the Natural Regulator of Matter Quantum Field Theories“,
“QSD VI : Quantum Poincaré Algebra and a Quantum Positivity of Energy Theorem for Canonical Quantum Gravity“,
“Quantum Spin Dynamics VIII. The Master Constraint“,
“Testing the Master Constraint Programme for Loop Quantum Gravity I. General Framework“). He covers the quantum Wheeler-DeWitt equation in chapter 10 section 3 (”Derivation of the Hamiltonian Constraint Operator”) of his book.

The book is very well written (for a physics monograph). Even in the “Outline of the book”, Thiemann demonstrates a superior command of math. In this section of his book, he outlines and describes various other approaches to quantum gravity citing sources for the interested reader to read.
This is something I always appreciate in books.

Unfortunately, I am sick, so I have had plenty of time to read the book! I am however a slow reader because I’m also taking notes as I’m reading. It’s a force of habit I’ve had since I’ve started reading. This book is an excellent introduction to modern canonical quantum gravity, that is to say Loop Quantum Gravity.

It covers the steps taken to introduce the subject matter. He begins by introducing the (ADM) Hamiltonian formulation of general relativity and he does it with unparalleled clarity. Thiemann continues on this subject matter to deal with the gauge symmetries and their constraints and the geometric interpretation of these constraints. He found the Legendre transform and the gauge constraints, then gave a mathematical definition for functional differentiability (more precisely that “…a functional is functionally differentiable at…”).

I thought “Uhoh, Thiemann’s decided to go purely mathematical with his presentation!” But this initial fear was unfounded, I am relieved to report. Thiemann provides definitions from pure math on various mathematical objects that are relevant to the topic of each chapter and future chapters. This is actually something I appreciate, it allows the book to be more self-contained.

The next topic Thiemann tackles are the philosophical issues like the problem with time, locality in a relational formalism of general relativity, and various interpretations of quantum theory. This concludes chapter 2.

So far I’m on chapter 4, but I’m fascinated with the book. It is of a high quality and I recommend it for anyone remotely interested in modern developments of canonical quantum gravity…provided the reader has knowledge of classical general relativity and quantum theory. I can’t stress how well written this book is, it certainly makes up for the lack of such high quality books on the subject (there are how many others? One? How many are there on String theory? A thousand or two?).

And now back to studying for my classes and preparing for finals.

I went to the D programming conference back in August this year, and I ran into several interesting people. One was a former researcher of supergravity; I told him “Honestly I think supergravity is bullshit” he smiled and said “Yes, it pretty much is…”. He had a fantastically dry sense of humor (e.g. when giving his presentation he said “When you are programming, you don’t want to write harmful code…” I thought, yeah something that would harm the hardware; the speaker continues “…Like launching missiles.”). Another was an interesting software programmer that recommended me to the site “Common Sense Science“. It’s basically a pseudoscience site.

I looked through the links and noted that a number of them are to Creationist websites, which immediately told me this was as pseudoscientific as Lubos Motl and the Easter Bunny combined.  Looking at, e.g., the “Contradictions” page here are some of the problems:

“It is only a mathematical model consisting of equations and does not usually specify physical structure for elementary particles.”

I don’t know how well hidden this is, but historically science has always been described by mathematical models!

It’s complaining about the language that the theory is formulated in. Well, there’s a problem with this argument that Wittgenstein points out long ago: what can be said in one language can be said in any language, or languages are isomorphic (for the mathematicians out there ;)).

Their criticism that quantum mechanics does not specify the structure of subatomic particles is somewhat justified…since quantum mechanics explicitly assumes that we are dealing with point particles! I myself have entertained the view personally that subatomic particles could possibly have an “atomic” structure to them. Maybe they do, maybe they don’t, maybe we’ll never know!

But quantum theory works despite this “catastrophic contradiction” and even makes some of the best damn predictions in Human History! The Dirac Equation, Quantum Electrodynamics, the Hydrogen atom…need I continue?

“It frequently contradicts itself.”

It contradicts itself…because it contradicts itself.

Ah, well, it’s hard to argue against a tautology but this is a meaningless proposition. Old Wittgenstein should be rolling in his grave at a frequency that could generate power for all of Western Europe from this argument alone.

“It provides no mechanism for such fundamental processes as the exchange of energy.”

Actually, this is an interesting argument because I’ve dealt with dialecticians…philosophers obsessed with pseudoscience, holism, and “change”.

A thermodynamic process specifies the initial conditions of the process, then the final conditions when the process ends. Quantum theory does the same thing. So therefore, logically, thermodynamics is wrong! Despite being the one of most important things coming from the 19th Century (the other being the Stanley Steamer ;)).

The mechanism for exchanging energy, etc. is actually done through photons (Feynman diagrams anyone?). There is a sound explanation of what’s going on…and it dates back to the hydrogen atom quantization. Apparently these people never learned quantum theory, so “common sense” dictates they criticize it.

“Assumed properties of elementary particles.”

This argument is based on the previous argument, which is a considerably weak argument.

As I mentioned earlier, these people have links to Creationist websites…it turns out these people are Creationist philistines. For example, explaining life can only be done in the Judeo-Christian blah blah blah. After reading “can only be done with…Judeo-Christian” I stopped reading.

I refuse to part one pretty penny to purchase (yes, purchase) their technical papers since they appear to be crackpots already. (Nothing personal, dear Common Sense pseudo-Scientists, but I actually first derived the Lorentz factor by hand, geometrically from the two principles of Galilean relativity and the constancy of the speed of light back in high school…you mean to tell me that this is wrong because “there are contradictions” doesn’t jive with me.)

Alright, I know it’s been a while since I’ve last posted, so let me get everyone up to date. The school year has started and I’m taking a number of advanced math courses, which of course requires a lot of math proofs.

I’ve always approached math proofs as a sort of “construction” exercise…like masonry for the mind. The problem is that I’m of the Homer Simpson School of masonry.

Anyways, in my spare time I’ve been doing things like quantizing the Newton-Cartan theory (canonically), finding the canonical conjugate momentum to the Cartan tetrad using the Einstein-Hilbert Lagrangian then working out the consequences of this (and comparing them to loop quantum gravity), and of course pursuing women.

Something rather interesting, which Dr. Woit has been angry about, is that materialism is kind of…being completely abandoned by String theorists. Indeed, Lubos Motl has boasted this! Call me “old fashioned” (or, if you are one of those rapscallion kids, “old school”), but isn’t materialism one of those foundations of Western science?! You know, along with causality and formal logic?

Coincidentally, I have been arguing a lot with philosophers (damn philosophers!) about what is “antiscience”. They would like to believe that criticizing a scientific hypothesis without providing a suitable alternative hypothesis is scientific…but this is comparable to saying, in the middle of a conversation with a friend, “You’re a <insert profanity here>!” Then refusing to speak with this friend any further. A philosopher brought up his crack pot idea that it is “society/culture/ethics” which really influence the behavior of particles and matter…and after an experiment of thinking very hard for him to physically disappeared, he remained. Thus I scientifically disproved his hypothesis, but he doesn’t believe me :-\

I don’t understand why Americans are so afraid of science. Which brings me to a funny anecdote. The other night I was dragged to the see “The Passion of the Christ”…against my will, as you would expect. I got kicked out for being too vocal. When the lights darkened and the movie was about to begin, I said loudly “I wonder if this will have a happy ending?” I owe this witticism to Groucho, of course. Then several scenes later, someone is riding a horse, and I ask again loudly “What? He isn’t riding a dinosaur? This isn’t very accurate according to the Bible.” Finally when Jesus was arrested, I asked “Wait, then when did he bury the dinosaur bones?” I guess not everyone there liked my views.

I’m leaving town for a week, so no one get worried over my absence.

I also wanted to quickly announce my programming blog “Object Oriented Kool Aid“. So far I am writing about my analysis of file systems and virtual file systems. I might include “How-tos” on programming file systems and/or virtual file systems. I have a lot to ramble on about and I thought that it deserved its own place separate from here.

That’s all, have a great week everyone!

Update: (5:49 PM PST 11 August 2007) I’m back at work studying technical papers and writing file systems, so no avenging of death is required.

Update 2: (9:12 PM PST 11 August 2007) I noticed that the spam program has deleted upwards of 20 comments, so if you commented here and its not posted please post it again!

Some compadres (numero uno and numero…2) filled out a questionaire that came about from the Emacs/Vi flame wars.

- How did you learn programming? Were any schools of any use? Or maybe you didn’t even bother with ending any schools ?

Well I first learned how to program in a High School course. I took AP programming (a college level course) which focused on object oriented programming in Java, and at the same time normal programming which focused on Karel++, C++, and Java.

The course was taught by Dr. Gregory Winston Neat who worked at JPL, which was just down the street from the High School. He was perhaps the best teacher I had in High School, he kept encouraging us to do things that were seemingly impossible.

My friend and I first tried to make an operating system then for our AP final project. It was a simple program which was written to the floppy disk boot sector that printed out to the screen “Raffi and Alex are cool”. Raffi was my partner in that project. That’s how I became interested in operating systems.

The courses I took were enough to push me to learn more. I learned Python, Perl, Scheme/Lisp, and C on my own within that year, as well as some x86 assembly.

I do intend to take a C++ course Winter quarter next year to help my friend out; it’s the so-called “weeder” course for computer science. It’s insanely difficult and has a failure rate of some ridiculously high rate like 80%…or something.

- What do you think is the most important skill every programmer should posses?

Hmm…I think perhaps the ability to think critically is the most important skill to have.

Recently, I went to my friends place to talk about programming and math. He was surprised I came dressed in a suit without a laptop.

I think that he didn’t realize that my laptop isn’t my computer. My ability to solve problems is my computer.

- Do you think mathematics and/or physics are an important skill for a programmer? Why?

Hahaha, what a loaded question to ask a theoretical physicist!

I think that any programmer that hasn’t read Polya’s How to Solve It is not a good programmer. That’s my bias though, as I see programming somewhat as a parallel to what geometry was to the Ancient Greeks.

Eventually, physics will become necessary when quantum computing becomes more wide spread. I think that physics for programmers teaches them how to solve problems quite well.

- What do you think will be the next big thing in computer programming? X-oriented programming, y language, quantum computers, what?

Uh, hmm…perhaps quantum computers?

It depends how big you want to talk about…of course quantum computing will be a big thing, just as an object oriented operating system would be big. Although the former is bigger than the latter I suppose. It depends on your perspective.

The biggest step forward for the end user would be having cheap, powerful, multiple core RISC processor computers. That would be nice

- If you had three months to learn one relativly new technology, which one would You choose?

Uh…well, if I had three months straight without sleep to study a new field, I would choose nanotechnology applied to medicine.

I have always eagerly looked forward to every stride forward in medicine, and I think that nano-medicine would be the next penicillin.

- What do you think makes some programmers 10 or 100 times more productive than others?

Well, the same thing that makes mathematicians more productive: amphetimines and coffee.

- What are your favourite tools (operating system, programming/scripting language, text editor, version control system, shell, database engine, other tools you can’t live without) and why do you like them more than others?

Hmm…

OS: Linux (really, I don’t care specifics, any *nix is good with me)

Programming Language: C/C++/D/Java

Text Editor: Emacs or Jedit

Shell: BASH

Scripting Language: Python/Perl/Lisp/Scheme

Database engine: nihil

Laptop: AlienWare Sentia m3400…or something like that

Preferred processor: any RISC processor

Preferred Desktop Architecture: Pizza Box/Luggable architecture (think of a modern Apple ][ c that’s really light weight and upgradeable).

- What is your favourite book related to computer programming?

Well, uh perhaps Polya’s How to Solve It, which teaches the most important aspects on how to solve math problems which can be applied to programming.

On the other hand, SICP has been very influential on me. I carried it around like a bible back in High School Programming.

Then again, Tanenbaum and Woodhull’s Operating Systems Design and Implementation (Third Edition) is like my programming bible at the current moment…along with various other operating system books.

- What is Your favourite book NOT related to computer programming?

Misner, Thorne, and Wheeler’s Gravitation is my favorite book. Period.

- What are your favourite music bands/performers/compositors?

Well, this is a long response. I’m a musician you know (I play violin and viola).

I like: The Clash, Brahms, Bach, Flogging Molly, Vivaldi, Rossini, Judas Priest, Led Zeppelin, Miles Davis, Emerson Lake & Palmer, Duke Ellington, van Halen, Bebop Jazz, Hard Bop, Jethro Tull, Ink Spots, Motörhead, Louis Armstrong, Iced Earth, Cannonball Adderly, Man-O-War, Mozart, Aerosmith, Deep Purple, Black Sabbath, etc., but neither Beethoven nor Wagner.

Mark Twain accurately stated “Wagner’s music is better than it sounds”.

As for why I dislike Beethoven, I dislike it only to spite one of my friends who dislikes Bach to spite me.

In Loop Quantum Gravity, the Immirzi parameter is somewhat troubling…largely because it’s such an odd value.

It was once calculated to be some ugly value like:

Or something like that. Bizarre!

Well, a paper came out that argued that:

Microscopic state counting for a black hole in Loop Quantum Gravity yields a result proportional to horizon area, and inversely proportional to Newton’s constant and the Immirzi parameter. It is argued here that before this result can be compared to the Bekenstein-Hawking entropy of a macroscopic black hole, the scale dependence of both Newton’s constant and the area must be accounted for. The two entropies could then agree for any value of the Immirzi parameter, if a certain renormalization property holds.

(Emphasis added). Fascinating!

The paper is called “Renormalization and black hole entropy in Loop Quantum Gravity” by Ted Jacobson.

There was a second paper that crossed my eye because of something that stuck out from Carlip’s Class. This student with a British accent asked why not place the universe within a box? We do it for the Hydrogen atom, among other things, so why not do it for quantum gravity?

Well, the obvious answer is the philosophical problems with this in the context of classical general relativity. However, a paper has come out about this very subject! It’s very exciting purely from the nostalgic feeling the abstract conjures:

The curvature perturbation in a box by David H. Lyth

The stochastic properties of cosmological perturbations are best defined through the Fourier expansion in a finite box. I discuss the reasons for that with reference the curvature perturbation, and explore some issues arising from it.

Next on the reading List is a lengthy piece dealing with particle propagators in arbitrary backgrounds.

This piece fascinates me partially because it comforts my inner general relativist in dealing with background independency (or more spacifically, a sort of pseudo-background independency) for quantum theory.

Particle propagation in non-trivial backgrounds: a quantum field theory approach by Daniel Arteaga

The basic aim of the thesis is the study of the propagation of particles and quasiparticles in non-trivial backgrounds from the quantum field theory point of view. By “non-trivial background” we mean either a non-vacuum state in Minkowski spacetime or an arbitrary state in a curved spacetime. Starting with the case of a flat spacetime, the basic properties of the particle and quasiparticle propagation are analyzed using two different methods other than the conventional mean-field-based techniques: on the one hand, the quantum state corresponding to the quasiparticle excitation is explicitly constructed; on the other hand, the spectral representation of the two-point propagators is analyzed. Both methods lead to the same results: the energy and decay rate of the quasiparticles are determined by the real and imaginary parts of the retarded self-energy respectively. These general results are applied to two particular quantum systems: first, a scalar particle immersed in a thermal graviton bath; second, a simplified atomic model, seizing the opportunity to connect with other statistical and first-quantized approaches. In the second part of the thesis the results are extended to curved spacetime. Working with a quasilocal quasiparticle concept the flat-spacetime results are recovered. In cosmology, within the adiabatic approximation, it is possible to go beyond the flat spacetime results and find additional effects due to the universe expansion. The cosmologically-induced effects are analyzed, obtaining that there might be an additional contribution to the particle decay due to the universe expansion. In the de Sitter case, this additional contribution coincides with the decay rate in a thermal bath in a flat spacetime at the corresponding de Sitter temperature.

Fascinating papers, all of them well worth reading.

So, you want to program Lisp on a slow/old computer? Use Liskell, it’s Haskell and Lisp combined into a new language.

The example given on the home page of Liskell in action is actually pretty interesting:

(define (fact n)

(if (== n 0)
1
(* n (fact (- n 1))))))))

Compare this to the old school Haskell:

fact n =

if n == 0

then 1

else n * (fact (n - 1)))

It has the beauty of Lisp and the speed as well as efficiency of Haskell. It’s a beautiful language for those that like functional languages (all eyes turn to John Armstrong :P).

OK, I am working on the explanation of Unix-like file systems intended for programmers that don’t know anything about the Unix-like file system structure. This is a rough draft, and I know the appendix is sketchy, it needs to be - well - written. I think I did a half decent job, but it occurs to me as I write the technical documentation that there is no explanation of the Unix-like file system concept. So please please please help me by demanding clarification at points!

Cheers!
AngryPhysicist

Revision 1 Added more information about how the directory really is-a file.

An Introduction to Unix-like File Systems

What the hell’s a file system?

A file system is used nowadays to manage the hard disk, floppy disk, and well any block device. It uses files to centralize data, and directories to organize files and other directories.

The hard disk has a geometry (see the appendix) so the file system has to “respect” this. There are various approaches to making a file system, we shall inspect the Unix approach specifically since this is a manual for a Unix-like operating system.

The Unix Approach: Inodes

It should be emphasized EVERYTHING “IS-A” FILE! Unix is (sorta) object oriented like that, that’s one of the appeals to it. Any operation that can be done on a file (read, write, open, close, etc.) can be performed on directories, devices, etc.

The file system is key to the Unix philosophy…everything “is-a” file after all! The file system is like the heart of Unix…so it is worthy to spend time to discuss the idea behind the Unix-like file systems. We shall use pseudo-code that is similar to C# or D.

The basic idea is this: everything is a file. A file is represented by a data structure called an inode (index node). The inode (also written as “i-node”, “index-node”, etc.) has fields that store information about the file or the addresses of the blocks. If you are unfamiliar with disk geometry, there is an appendix on it. A toy inode could be:

struct inode{
uint mode;
uint size;
uint *blocks[MAX_ADDRESSES];
}

There are only three simple fields that really define an inode. One tells us what sort of file we are dealing with. In unix, we have ordinary files and directories, as well as file representation of the various devices, pipes, and sockets. (The last two, pipes and sockets, are a sort of data structure used in interprocess communication.)

The next thing that gives us information about the file is the size of the file, which is given to us by the field uint size.

Last, and by no stretch of the imagination least, uint *blocks[MAX_ADDRESSES]. This field is the pointers to the various blocks that the inode stores the data in. Typically, the last several blocks are so-called indirect blocks. They hold addresses to blocks which are then used to hold addresses to more blocks. Singly indirect blocks use 1 indirect block (that is, the address it refers to is a block full of addresses; the exact number of addresses is equal to (the size of the block in bytes) / (the size of the variable one uses for addressing in bytes)). TO figure out how much data storage this gives us, we have the number of addresses in the indirect block given, we shall call it N. Now, each address refers to a block of data, so there is: N * (size of a block in bytes) bytes per singly indirect block.

A doubly indirect block uses a block that is full of addresses to another indirect block. That is to say, the address referred to us by the inode is a block full of addresses. These addresses refer us to more blocks which are chalk full of addresses. These addresses then refer us to the data. To figure out how many addresses it refers to, we simply figure: (1 block of addresses) * (X bytes per block) * (1 address per Y bytes) = number of addresses referring us in the first indirect block. We previously called this N. Now, each address refers us to what is pragmatically a singly indirect block. So we have: N * ( N * (size of a block in bytes) ) = bytes supported in a doubly indirect block.

There is also the triply indirect block. If you haven’t spotted the pattern so far, here’s the trick: for an Z indirect block, it supports N**Z * (size of a block in bytes) bytes. So for our triply indirect block, it is: N * (N * (N * (size of a block in bytes) ) ) bytes.

To figure out how many bytes an inode supports total, simply sum up the direct blocks with the indirect blocks. It’s a simple sum.

The Organization of the Disk

The basic structure of the inode approach more or less organizes the hard disk (or any block device really) into several components. We shall briefly cover this organization here.

The first important block is the zeroeth block: the boot block. It is the block that is loaded into memory after bios. It must be preserved at all costs.

Then we have two bit map blocks. The first is the inode bitmap. The idea is that the disk has a finite space (despite our wishes!). There are only so many inodes that are needed. So we allocate a section of space for these inodes. We need to keep track of whether these inodes are being used or are free. We use a bitmap to do this. A bitmap is really just a collection of bits (ones and zeroes). The first bit refers to the first inode, the second bit refers to the second inode, etc. We indicate whether an inode is used by a 1 and it is free by representing it with a 0 in the bitmap.

The second bitmap that follows this is the block bitmap. Just as the inode kept track of the free and used inodes, the block bitmap tracks the blocks and whether they are free or taken.

Now we have the space allocated to the inodes. This is the inode table. It is the contiguous space of inodes that keeps track of, and organizes, the disk.

The rest of the disk is used for the data directly (or as indirect blocks full of addresses). They do not hold inodes, etc.

Directories in Unix Like File Systems

Well, we see what a file is (it’s just a collection of blocks basically!). What about a directory? It seems a little more complicated. The directory is a file. However, unlike an ordinary file that stores data, a directory has special entries within it. The directory entry is a glorified pointer to a file. It stores the file name, the inode number of the file, and sometimes other fields that are useful.

We treat the directory as a file. A file is an inode. An inode stores addresses to blocks of memory for data. A directory, however, has no data other than these glorified links called directory entries. Well, since we cannot really change the structure of the inode, we need to simply change the data that are stored on the blocks. We use things called directory entries, a data structure often shortened to dir_entry. Let us look at a simplistic one:

struct dir_entry {
char name[NAME_LENGTH];
int inodeNumber;
}

This is the simplest directory entry. It has two fields that are really important: the name of the entry within the directory, and the inode number.

The inode number refers to the inode being the Nth inode in the inode table. This is useful if we wish to know where the inode is, and if we would just so happen like to actually access the data.

Supposing that the maximum length of the name is 256 (i.e. #define NAME_LENGTH 256), then the size of a dir_entry is: (256 char) * (1 byte per char) + (1 int) * (4 bytes per int) = 256+4 = 260 bytes. That is roughly half of a sector (512/2 = 206, I know I know!). And an inode can refer to (supposing that there are 16 addresses all together) 16 blocks directly (I’m lazy, so I won’t try to calculate out “What if we use 1 singly indirect block? What if we use 1 doubly indirect block? What if…?”). Thus, in a handwavy lazy fashion, there are at most 32 entries in a directory this way…yes yes this also assumes that 1 block is 1 sector big (and 1 sector is 512 bytes). <!–I lied, I will calculate out how many dir_entry there are for: 1 singly indirect block, 1 singly and 1 doubly indirect block, and 1 singly 1 doubly and 1 triply indirect blocks. Well, for a singly indirect block using 4 bytes for addressing, we have (512 bytes per block) * (1 address per 4 bytes) = (512/4) addresses = 128 addresses. Thus if each refers to a block, we have (128 blocks) * (512 bytes per block) = 65536 bytes. Thus for an inode with 15 direct addresses and 1 singly indirect block, we have (15 addresses + 128 addresses) * (512 bytes) = 73,216 bytes. There are 281.6 directory entries, round it down and we have 281 directory entries.

Suppose now we have 14 direct blocks, 1 singly indirect block, and 1 doubly indirect block. The doubly indirect block has 128 addresses that refers to 128 addresses, or (128 addresses) * (128 addresses) = 16,384 addresses. Now, to add together all the addresses: (14 direct addresses) + (128 singly indirect addresses) + (16384 doubly indirect addresses) = 16,526 addresses. Now this supports: (16526 blocks) * (512 bytes per block) = 8,461,312 bytes. This in turn supports (8461312 bytes) * (1 dir_entry per 260 bytes) = 32543.507692308 dir_entries. We round down to 32,543 directory entries.

For 13 direct blocks, 1 singly indirect block, 1 doubly indirect block, and 1 triply indirect block, let us calculate this one out. We know how many addresses there are for direct, singly indirect, and doubly indirect blocks, but we are ignorant of the number of addresses supported by the triply indirect block. Let us figure it out now. There is a block that has addresses to other blocks full of addresses to other blocks. That is (128 addresses) * (128 addresses) * (128 addresses) = 2,097,152 addresses. Now this inode supports: (13 direct addresses) + (128 singly indirect addresses) + (16384 doubly indirect addresses) + (2097152 triply indirect addresses) = 2,113,677 addresses. This in turn supports a total of: (2113677 addresses) * (1 block per address) * (512 bytes per block) = 1,082,202,624 bytes. Now, each directory entry is 260 bytes, so that means that this inode approach supports (1082202624 bytes) * (1 dir_entry per 260 bytes) = 4162317.784615385 directory entries. We round this down to become 4,162,317 directory entries.
–>

Appendix: Disk Geometry

Disk geometry is an interesting concept in and of itself. The hard disk is divided into atoms of 512 byte sectors. Typically file systems use a “block” concept, where there are 1, 2, 4, 8, or sometimes 16 sectors in a block. Note how it’s always a multiple of 2 (2**0, 2**1, 2**2, etc.).

The Brief Anecdote

OK, so I was talking with the lead developer of Brainix and we hit a snag. Largely because it’s a microkernel, it’s indescribably difficult to program correctly. So, we said to each other “What should we do?”

Our conclusion was, well, nonexistent. That’s right, we didn’t come to a conclusion (we’re too cool to solve problems ). What I suspect will happen is we’ll end up making Brainix a hybrid kernel with the drivers running in the user-space so the Operating System won’t crash so much.

We’ll try making the operating system Unix-like…but in doing so we’ll try to resolve some problems like: the devices are supposed to be represented as files, but there is an ambiguity over the “block device” vs. “character device” dichotomy (e.g. the Network device is neither apparently). Perhaps we’ll make a more object oriented approach to solve this problem.

I suggested that we should start using the D programming language and using javadoc in-code documentation so that: 1) it’s easier to program, 2) it’s easier for “newbies” to learn the operating system concepts. We’ll see how things turn out I guess. A “problem” that arises is that either we can’t use classes (we can just as easily use structs) or we will have to hack together our own special compiler from the GNU D Compiler front-end (we may have to “slightly” change the Object class). This problem depends on whether we want to focus on embedded systems (or really old computer systems) or if we want to make operating systems for “recent” computers (i.e. with at least 512 megs of RAM, 1 GHz processor, etc. etc. etc.).

But I wish to present a conjecture:

AngryPhysicist’s Conjecture: It is impossible to have an efficient Microkernel that is also POSIX-compliant. It’s one or the other, but not both.

Remark: It is possible to have an efficient microkernel! It just can’t easily be Unix-like.
I’m actually a little sad that we are departing the microkernel approach, but we’re doing something that is easier to program. Perhaps first we should write a debugger for the operating system (supposing we want to make life easier for ourselves — real programmers don’t use debuggers though, they program in binary)? That would require us to figure out how to make a debugger though…

Now, on to the paper:

Generalized Lagrange Transforms: Finsler Geometry Methods and Deformation Quantization of Gravity by Sergiu I. Vacaru

ABSTRACT: We propose a natural Fedosov type quantization of generalized Lagrange models and gravity theories with metrics lifted on tangent bundle, or extended to higher dimension, following some stated geometric/ physical conditions (for instance, nonholonomic and/or conformal transforms to some physically important metrics or mapping into a gauge model). Such generalized Lagrange transforms define canonical nonlinear connection, metric and linear connection structures and model almost Kahler geometries with induced canonical sympletic structure and compatible affine connection. The constructions are possible due to a synthesis of the nonlinear connection formalism developed in Finsler and Lagrange geometries and deformation quantization methods.

I thought this was an interesting paper, Carlip remarked he never saw an attempt at Deformation Quantization of Gravity. Well, there you have it.

I have stumbled upon a few gems worth noting. First off, there is the Metalinguistic Abstraction. It’s a “good read” as far as blogs go, with respect to programming.

There is also an Object Oriented version of Unix out: UnixLite. It’s (unfortunately) written in C++, but it’s interesting (to me at least) to observe an object oriented unix-like operating system’s source code. It is a “toy” operating system, but don’t let that fool you: you could possibly hack it into a full blown Linux clone.

Interestingly, Minix3 has just recently announced they ported SQLite. It appears to be trying to become a server operating system, but it still has this air of being a toy to it (a certain je ne sais quoi as the French would say, if I remember how to spell in French).

I am considering going back to Davis a wee bit early (i.e. next Saturday perhaps?), so I will be busy meeting with old acquaintances and so on and so forth.