Thursday, December 29, 2011

Happy new year from the book publishing department

My first book, A Mentoring Course on Smalltalk, is now available in PDF format. You can get it here (plus all my books are listed here). Enjoy!

Friday, December 16, 2011

Firefox 8 data cache cleaning

By default, my installation of Firefox uses up to 1 gb for file caching. Firefox uses a nice 16x256 (or similar) directory structure so that not all files are stored in the same directory. This is nice! However, when you ask Firefox to clear the cache, Firefox deletes files from this directory structure in (apparently) random order. This is Bad(TM):

  • That's a lot of directories! Using du -sh ? at the root cache directory will show that progress is made in a random fashion. Moreover, if you keep doing du -sh ? on the command line, then directories stay mostly cached and you can see progress is fast (meaning: slow, but not frozen molasses slow). If you wait a while, then directories don't stay cached and progress becomes (frozen molasses) slow again.
  • For some reason, it looks like OS X won't do write combining anywhere as efficiently if you delete files at random from the directory structure. The activity monitor showed about 4mb / sec disk writes throughout. However, the result was super slow deleting.

After about an hour, Firefox still had to delete about 700 mb of files. So I decided to help, and run commands such as rm `find F -type f -print` at the root of the cache directory. Apparently Firefox doesn't mind not finding files it wants to delete, and rm keeps going if it can't find a file to delete, so things went well. The rm command deletes files sequentially in the same directories, so I expected it to run faster. And yes indeed, it was quicker by a lot. I was done deleting the rest of the files in no time. I should also point out that, even though at times there were effectively two rm threads (Firefox, and the command line), actual disk i/o throughput was not higher and remained at about 4 mb / sec. Nevertheless, actual deleting performance was way faster.

Firefox developers: please delete cache files sequentially, yes? Also, Memshrink is awesome and it makes a huge difference, please keep going!

Sunday, December 11, 2011

Windows 7 32 bit install freeze while "Completing installation..."

On a Macbook Pro, installing Windows 7 32 bits on the boot camp partition may freeze after the first successful reboot at the "Completing installation..." phase. Also, when you kill the computer to unfreeze it, your installation is trashed and you have to start over again. There are a multitude of suggestions on how to deal with this problem on the web. This is a summary of what I figured out.

After the first reboot, I told the installer to boot into safe mode. This stops the installation from proceeding and trashing the install when it crashes. With e.g.: shift+f10, open a command prompt and then execute compmgmtlauncher. This brings up the computer management console. Look under the device manager and browse through the devices. In my case, I could freeze the computer just by looking at the ethernet controller. Interesting...

But how to work around it? Disabling the device didn't help because the installer crashed anyway. So I took out memory from the machine and left it with 2 gb of RAM (and no, the memory is not bad). At this point, the device manager didn't hang anymore after browsing the ethernet controller. When I rebooted and let the installation proceed, this time it completed successfully. Note that the installer recognized and installed the ethernet controller drivers correctly. Once Windows 7 was installed, I restored the memory back to what it was before. Everything seems to work fine so far.

From this experience, it looks like device recognition during the installation may induce failures when you have more than 2 gb of RAM. How bothersome :(.

Tuesday, December 06, 2011

Holiday Lulu coupons

FYI, Lulu is running interesting coupons these days. First they had free shipping, and now they offer 30% off until Wednesday with the coupon WINTERSAVE305. So if you wanted to get anything from Lulu you didn't get before, this is a good time to do that.

Monday, December 05, 2011

Talking about GC at Willamette University on 9/12

Willamette University's Math Department graciously gave me a slot in their colloquiums. I will be speaking about garbage collection on December 9th at 4pm. I hope you can make it! See you at the Ford building on Thursday.

Update: the talk was well received by an audience of mostly students from the Math and CS departments. I'd guess there were between 40 and 50 people, it was hard to tell because the room was full all the way to the back. I'd like to thank Willamette University again for this opportunity.

Monday, November 28, 2011

The wonderful world of e^x cores and threads

Let's compare the performance of several SPARC machines at running some integer workloads. Fortunately the SPEC folks already compiled the relevant (and voluminous) results. In particular, we will look at the SPARC T2, T2+ and T3 CPUs against the Fujitsu SPARC64-VII and SPARC64-VII+ CPUs.

Unfortunately there are a multitude of numbers to look at. How many CPUs does the machine have? How many cores per CPU? How many threads per core? What's the speed of the CPU in question? How many concurrent test instances are running? And, finally, how long did it take for the machine to finish the workload? To simplify these matters, first we will look at three figures:

  1. Throughput, defined as concurrent test instances over time taken.
  2. Throughput per core per GHz * 1000. This number gives us how much performance is being driven by core.
  3. Throughput per thread per GHz * 1000. This number gives us how much performance is being driven per theoretically executable thread.

With these 3, the higher the better. To simplify, we will note the results as follows.

  • Chip name (chips x cores x threads @ GHz): #1, #2, #3.
First, lets' look at some GCC batch runs.
  • SPARC T2 (1x8x8 @ 1.582): 0.008, 0.646, 0.081.
  • SPARC T2+ (2x8x8 @ 1.582): 0.014, 0.555, 0.069.
  • SPARC T2+ (4x8x8 @ 1.596): 0.030, 0.589, 0.074.

We can see a number of things in these. For example, looking at raw throughput is misleading in a number of ways. First, it hides the number of threads the CPU is capable of running, so it doesn't give us a good idea of how efficient the CPU is. Second, compare the first two lines: we added another CPU, but we did not get 2x the throughput (0.008 to 0.014). In other words, adding CPUs is not necessarily making your box more efficient. We should also look at the throughput per core and thread. Between the first two lines, we added twice as many cores and yet we lost a bunch of throughput. The last result for the T2+ shows some improvement, although the base GHz is higher by roughly 7%...

But we have more, we can look at some T3 SPARCs.

  • SPARC T3 (1x16x8 @ 1.649): 0.012, 0.472, 0.059.
  • SPARC T3 (2x16x8 @ 1.649): 0.025, 0.465, 0.058.
  • SPARC T3 (4x16x8 @ 1.649): 0.049, 0.464, 0.058.

Nice, we can see the T3s have twice as many cores as the T2s, and yet as we add chips the performance does not suffer as much as with the T2s. However, we should also note the T2s had better throughput per core-GHz and per thread-GHz. So, again, we see we add more computing resources but the effective efficiency is lower.

There are basically two vendors of SPARC CPUs that I could find. One is Sun Oracle and it sells the SPARC T CPUs. Another vendor is Fujitsu, and it sells SPARC64 CPUs. Through several iterations, they've taken an older SPARC64-V all the way to a SPARC64-IX. This last CPU was recently used in a top 500 super computer entry. How does it stack up to Oracle's offerings? Well, at first it's hard to tell because SPARC64s run much faster than T2, T2+ and T3 CPUs, yet they have less cores and their cores run less concurrent threads. What a mess! But our 3 figures are discriminating enough. Let's take a look.

  • SPARC64-VII (4x4x2 @ 2.53): 0.012, 0.304, 0.152.
  • SPARC64-VII (8x4x2 @ 2.53): 0.024, 0.298, 0.149.

At first glance, it would seem as if the T2+ and T3 CPU configurations above achieve more throughput than the SPARC64-VII. In fact, the SPARC64-VII scores less throughput per core-GHz. But a closer look will reveal the SPARC64-VII above pushes between 2 and 3 times more work per thread-GHz. And that's after taking out the effect of the GHz difference, which is not even 2x in favor of the SPARC64. In other words, the SPARC64-VII's thread execution is just more efficient than that of Sun Oracle's SPARC offerings. And that's for a somewhat slow SPARC64-VII, here are a couple more numbers.

  • SPARC64-VII (16x4x2 @ 2.88): 0.066, 0.360, 0.180.
  • SPARC64-VII (32x4x2 @ 2.88): 0.126, 0.340, 0.170.

Here we see the effect of the speed increase in terms of throughput per GHz figures. And again we see that with more execution capabilities, there is less effective throughput. Fortunately the T3 and the SPARC64-VII chips scale well with increased CPUs. Nevertheless, the net efficiency of the SPARC64-VII is higher, and I'm guessing it's because with less execution machinery the CPU can spend more energy just plowing forward.

Unfortunately there are no results for SPARC T4 CPUs. However, we know they will run at 2.8GHz or higher, and have 8 cores per CPU each of which can run 8 threads. Plugging in the numbers for the T2s (which have the same number of threads per CPU), we can see the individual cores should be about 2x faster than those in T2s to match a SPARC64-VII on throughput per thread. Moreover, SPARC64-VII+ chips are faster and seem a bit more efficient as well. Unfortunately I could not find results for SPARC-VIII or SPARC-IX chips. In the mean time, though... Sun Oracle SPARC chips don't necessarily look all that great :(...

Thursday, November 17, 2011

Assessments 1.53

Changes with this version: improved the RB status bar to report skipped checks, and also deleted some dead code from the RB status bar.


Due diligence continues to pay off

At work, we recently fixed a number of instances of memcpy() that should have been memmove() because the objects involved overlapped (thus violating e.g.: POSIX and C99). One particular instance of memcpy() had been wrong since at least 1990, only to be exposed by relatively recent versions of glibc. The fact that wrong code has been undetected for at least 21 years illustrates that it is very easy for programs to merely appear to work and, thus, that it is incredibly important to always pay attention to the relevant specifications.

Speaking of paying attention, we also found sometimes we use a Duff device instead of memcpy() / memmove() / memset() because of an interface impedance mismatch: the C library functions work with bytes, and we need to copy, move or set pointer size values. Alas, our Duff device is currently written in a way that requires way too many assembler instructions. So now I have a new Duff device prototype that does the same work in about half the instructions on x86, Power and SPARC. Preliminary tests show a measurable performance improvement, which is visible both on micro and macro benchmarks.

Moving along...

Doctoral Symposium CIBSE 2012

DOCTORAL SYMPOSIUM CIBSE 2012 (Buenos Aires, Argentina)


The Organizing Committee of the XIVIbero-American Conference on Software Engineering (CIbSE 2012) are pleased to invite PhD students in the Software Engineering and related areas to participate actively in the Doctoral Symposium CIbSE 2012 by submitting papers describing their doctoral work.

The CIbSE 2012 Doctoral Symposium is an international forum for PhD students to discuss their research goals, methodology, and early results, in a critical but supportive and constructive environment. It will be performed in a one-day session. Selected students will present their work and receive constructive feedback both from a panel of experts and from other Doctoral Symposium students. The students will also have the opportunity to seek advice on various aspects of completing a Ph.D. and performing research in Software Engineering.

Format of the Submissions

The PhD students interested in participating in the Doctoral Symposium should take into account the following items to submit their works.
Provide a clear description of the research problem being addressed.
Motivate the proposed research (i.e. state why the research work is being conducted, and what benefits the research will bring).
Outline the current knowledge of the problem domain, briefly describe what existing work the research builds upon (citing key papers), and also briefly describe any existing solutions that have been developed or are currently being developed (citing key papers).
Clearly present preliminary results from the research work, and propose a plan of research for completing the PhD.
Point out the contributions of the applicant to the solution of the problem, and state in what aspects the suggested solution is different, new or better as compared to existing approaches to the problem.

Submitted papers must not exceed 6 pages in Springer LNCS format ( Papers may be written in English, Spanish or Portuguese.

What and how to Submit

Papers must be sent in PDF format to Gabriela Arévalo (gabriela (dot) b (dot) arevalo (at) by December 20th, 2011. In addition, you must also attach an “expectation and benefits” statement (1 page maximum, in PDF format) describing the kind of advice you would like to receive and how this would help you in your research. You should seek your supervisor’s guidance when preparing this statement. So, each submission must consist of the following files:
Attached PDF with your research paper submission (maximum 6 pages)
Attached PDF with your expectation and benefits statement (maximum 1 page)

Please state [CIbSE 2012] Doctoral Symposium- Submission as the subject of the e-mail. The body of the email should also contain: Title, abstract (200 words), keywords, and student and advisor (name, e-mail address, affiliation and postal address).

Evaluation of Submissions

Submitted papers will be subject to a review process by an international Program Committee. The selected submissions will be published as part of the proceedings of the CIbSE 2012 Conference.

Program Committee

Alejandra Garrido (Universidad Nacional de La Plata, Argentina)
Alexandre Bergel (Universidad de Chile, Chile)
Catalina Mostaccio (Universidad Nacional de La Plata, Argentina)
Eduardo Bonelli (Universidad Nacional de Quilmes, Argentina)
Gabriela Robiolo (Universidad Austral, Argentina)
Hernán Astudillo (Universidad Técnica Federico Santa María, Chile)

Important Dates

Submission Deadline: December 20th, 2011
Notification: February 20th, 2012
Camera Ready version: February 28th, 2012

Tuesday, November 08, 2011

Smalltalks 2011 (short) report

Hello, this is the Smalltalks 2011 report.

The conference was quite good, we had a good time. I did not attend all the talks due to hosting duties. Talks were fantastic. We had at least 310 registrations. By the second day we had around 210 unique attendees, which is awesome. We're still working on the final tally, so it's probably a bit higher than that. Here are some random comments.

Ian Piumarta's To Trap A Better Mouse was awesome. He examined how languages are divided into an open class of words (nouns, verbs etc) which change all the time and which describe the entities we want to talk about, and a closed class of words (prepositions, articles, pronouns) which hardly ever changes. The closed class effectively dictates what thoughts can be expressed in the language, because they encode the possible relational patterns between words in sentences. With that in mind, he took a look at open / closed word classes in *computer* languages and the effect those have in how easy it is to express a certain program in a given language. He emphasized that text substitution with ad-hoc parsers can have a tremendous power because then we can easily change from a bad (limiting) representation to a better (enabling) representation. He suggested looking at Earley parsers in favor of PEGs, LL, LR, and similar parsers because Earley parsers can eat both left and right recursive grammars, plus all context free languages, see here.

Gerardo Richarte and Javier Burroni posted updates on their Smalltalk based GC implementation. Now they have limited forms of multithreaded GCs. Interestingly, they tend to go slower. We speculated cache poisoning is the culprit, because usually GC algorithms end up looking like "couple instructions, uncached memory fetch" cycles. If you cannot easily partition spaces so that different CPUs go after memory areas, things look like they will be more painful.

On Saturday, I really liked Ian Piumarta and Kim Rose's talk on what happens when technological advances are promised to revolutionize education. Almost immediately, they are trivialized and dumbed down so that all kids (and adults) have to do is to mash up pre-existing stuff (think of clip art collages) instead of doing anything creative. This is a problem because it builds up the inertia that causes training to pass for an actual education. There were plenty of examples, and plenty of evidence. The situation is somewhat depressing, really, because with things like Facebook, Twitter, and SMS, all we do is emphasize immediate gratification and zero effort as a successful or productive expenditure of time. Without the time (and, thanks to dumbed down technology, without the incentive) to concentrate on anything, we cannot really hope for much. This is an issue that really resonated with Alan Kay's observation that when technology is too easy then there's no effort to actually do something good, so the vast majority of the results are trivial.

You can see the rest of the schedule at FAST's website. Some talks have been shown at other conferences, and videos of such talks are either available now or should become available soon at e.g.: ESUG's youtube video channel. I apologize in advance for not writing up reports on every talk I attended, but we will also post the videos from Smalltalks 2011 at our website soon and I don't want to give out (too many) spoilers :).

From all of us at FAST, we thank you for coming and making this conference a success. See you in Smalltalks 2012!

Wednesday, November 02, 2011

Smalltalks 2011 streamed live starting tomorrow

Smalltalks 2011 starts tomorrow, and will be shown live here. Enjoy, and see you in the morning!

Wednesday, October 26, 2011

Overheard the other day

"... I would like to be a genius but I'm only gifted, so I work hard..." --- Unknown

Monday, October 10, 2011

Update on the garbage

I have been working on Cincom Smalltalk garbage collection for a while. Here is a quick summary:

  • On the image side, I retuned the memory management and got real application code speed ups ranging from 10% to 2.5x. Some particular cases run O(10x) faster.
  • On the VM side, I enhanced stack overflow management on both the incremental and stop-the-world GCs. The improvements easily scored 20% faster execution.
  • A while ago, I posted about a prototype for a new GC implementation that ran up to 35% faster in the common case. This new GC is already shipping with our next release's internal builds. The finished product runs up to 40% faster.
As part of this effort, I fixed several subtle bugs that will no longer pester our customers from time to time.

Lately, the scavenger has been getting some attention because we found a couple small problems that should be fixed. Working with something like the scavenger requires thorough attention to details, because the end product must Work No Matter What(TM). But it is not efficient to put in this kind of effort for just a few tiny changes, to then forget about the scavenger and move on to something else. Thus, we will take this opportunity to improve several scavenger sections I had already identified as needing work.

There is always the unexpected with these type of endeavors. Back when I was working on the incremental and stop-the-world GCs, the existing implementation did not initially suggest there would be a lot to optimize. I could not have predicted the stack overflow improvements or the 40% speed up for the GC. These were surprise realizations that came from paying close attention to the code. Due diligence does pay off.

I've been wondering what I will run into with the new space scavenger. So far, the changes result in a net deletion of about 250 LOC. This includes removing effectively duplicated code that, if all goes well, will not come back. But why bother deleting code? Because deleting code you don't need is critical. If you don't have to pay attention to unnecessary code, you can spend more time concentrating on the code that is actually useful, and the result is a significantly better product. In the past few years, the VisualWorks VM's source code base has shrunk by about 30%.

But back to the scavenger. Besides code deletion and clarification, I did some rewriting to improve algorithmic efficiency. In one particular case, the new improved implementation also causes optimizing compilers to output about 15% less assembler instructions. And, right now, I'm working on an improved class table management mechanism for our 64 bit VMs. Already, it looks like a slightly faster 64 bit scavenger is possible.

More to come!

Saturday, July 02, 2011

Feeling lucky?

Check out these dice...

Wednesday, June 29, 2011

And this doesn't just apply to phones

Here is this article stating phones are basically tamagotchis for adults. Really, just phones? How many of our other gadgets are also tamagotchis?

Tuesday, June 28, 2011

To cloud, or not to cloud...

Since storage prices are falling faster than bandwidth prices, the suggestion is that local storage is cheaper than cloud storage --- says cloud storage company report...

Tuesday, June 21, 2011

Tuesday, June 14, 2011

Assessments 1.50

I just published Assessments 1.50 with a compatibility improvement for SUnit 4.x. Enjoy!

Friday, June 10, 2011

Factorial tuning competition

Paul Baumann is running a competition to speed up #factorial. Here are the rules, check it out!

Tuesday, May 24, 2011

One liner

Someone gave this to me today. On Linux, compile the following viznut.c:

#include <math.h>

main(v,i,z,n,u,t){for(v=-1;;)for(n=pow(1.06,"`cW`g[`cgcg[eYcb^bV^eW^be^bVecb^"[++v&31]+(v&64)/21),i=999;i;putchar(128+((8191&u)>i?0:i/8)-((8191&(z+=n))*i-->>16)))u+=v&1?t/2: (t=v&6?t:n/4);}

like this: gcc viznut.c
-lm -o viznut.

Then, execute ./viznut >/dev/dsp.

Friday, May 20, 2011

VM memory management update

As some of you know, I've been working on VisualWorks' memory policies and garbage collectors for a while. I gave a talk on the subject at Smalltalks 2010 (see here), and I was quite happy to report significant performance improvements: faster allocation, faster code execution, and faster (e.g.: 2.5x) real applications.

For the next release (after VW 7.8), I added a time-constrained, self-adjusting IGC mechanism to the memory policies. Also, I added the possibility to turn off the IGC on demand, which is useful for performance considerations. And now, I have a working prototype for a more efficient GC. For example, in a reasonably configured image with about 30mb of perm space and 100mb of old space, the new GC runs 35% faster. Although the new code has not gone through all the testing necessary for a GC yet, the 35% performance improvement should hold barring major surprises. There are a few things to do that should help edge case performance further.

Moving along...

Monday, May 09, 2011

Impressive hardware...

A workable computer running Linux and OpenGL, basically as large as a USB flash drive, for $25. Impressive... now if we could mostly write equally impressive software to solve problems worthy of our attention...

Friday, April 29, 2011

FTP server address change

The FTP server can now be reached at Enjoy!

Friday, April 01, 2011

6581 SID, the gift that keeps on giving

A SID chip, famously used for sound on the C64, has 3 synthetized voices. The older 6581 chips had a number of design defects because there was no time to finalize the implementation. For example, the filter didn't work right, and the output had DC bias because of electronic issues. However, these problems allowed people to hack the 6581 SID to no end. Here's an example, achieved about 25 years after the C64 was introduced. On a C64, you can have:

  • 4 channels of 8 bit sampled digital output,
  • 2 channels of SID sound,
  • have the filter apply to the sampled output as well,
  • and still have enough CPU time to do your own stuff.
This page here has this link to an mp3 file that has been taken off from a C64. At first you do not think much of it, but the C64 I know *never* sounded like that... the mp3 sounds like it belongs to an Amiga instead!

Tuesday, March 15, 2011

Old joke for a world that does not change

Might God have patented this round nuthouse idea?

Saturday, March 05, 2011

Fundamentally, we do not understand

A lot of what we do is simple in nature but complex in practice because our workload is huge. For example, preparing an invoice is simple but preparing 10^7 invoices requires computers.

Similarly, in computer programming, it's relatively simple to write a function such as printf(). But to use that function effectively is much more difficult because of the possible interactions with other pieces of software. Evaluating each possible interaction does not take much time. But in today's software world, in which nobody has the time and energy to read and understand every single specification involved, doing a perfect job of interaction evaluation becomes impossible. Even if you think you are done, how do you know you did not miss something?

With this in mind, check out this article: software is being used by law firms to analyze documents, precisely because of the above problems. Ah, how I would like some software to show me all the specification violations implied in a program.

But the real issue is not that I can't beat a computer at chess or at Jeopardy. The real issue is why we have engineered our existence so that, even when considering every day tasks, it is not possible to understand what's going on. Why do we need so much complexity? What is the ultimate goal attained by playing this game? We should also consider the consequences of our actions. Are we sure we like the outcome?

In the future, software will be able to do much more than merely "google" documents. What would happen if the only way to change your world was to get an extremely advanced software degree (or equivalent expertise), so that you can write some software that beats other software at behaving like a human? What does that even mean? For instance, in a lawsuit, is your success predicated on the software you can afford? Phrases such as "a lawyer will be appointed to represent you" fundamentally assume all lawyers are at least competent. What happens when "competent" is far removed from what you can buy if you have enough money? And what happens when you can buy an AI that will tirelessly prove you right irrespective of the circumstance?

To me, this situation seems like some optimization challenge. Perhaps the way to optimize is not to help us solve larger piles of relatively simple problems faster but to eliminate the simple problems altogether. After all, we do not determine 1000 mod 5 is zero by repeated subtraction.

Friday, March 04, 2011

Follow the herd, lose your individuality

Check it out: evidence that agreeing to a "popular" opinion, even half-heartedly, actually changes your point of view. So, for example, louder music is better, and dynamic range compressed remasterings of old music are better. It doesn't matter that you think different, as long as you're exposed to other people that think these crappy recordings are good. Eventually, your brain will adapt to match.

Huh... so should we even listen to statements such as these?

  • The US unemployment rate is improving.
  • However, real estate will go through a double-dip even though unemployment was deemed the primary cause of buyer uncertainty.
  • Government employee unions caused huge budget deficits, so we need to cut their benefits while we cut business taxes so that more jobs are created. Or we need to cut business taxes because there isn't enough consumption to support more hires. Take your pick. But if we cut government employee salaries, those government employees will pay less for other things, so really it's a spending cut that ultimately will affect businesses... huh?
  • When you're done with the above, how about Blue Shield increasing health insurance premiums by 59%? Those are claimed to be "fair" increases. But how about unemployment and already low salaries, who's going to pay that? In any case, even the article spells out the truth: "California, which has 7 million uninsured people, the largest number of any single state, is mired in a $6 billion budget shortfall. "Until then, insurers continue to have the power to say 'No, we won't reduce rates,' and consumers have to say 'Yes, we will pay these higher rates,'" said Heller.". So, in other words, because we cut business taxes (or because of unions, or whatever you picked from before), then we the people have to either pay more taxes, or pay more health insurance. Huh. Where's my salary hike to put up with that? And why shouldn't businesses pay more taxes too?
And after you consider all these issues, and after you listen to all the published "popular" opinions, what happens to your brain? How do you know if you can even claim to be an "independent" thinker anymore?

I tell you, watch what you listen to, because it may corrupt your mind. And now, stop watching TV.

Saturday, January 29, 2011

FTP server changes

I will be retiring the old FTP server and replacing it with a new one. Anonymous FTP will replace the old smalltalk account. This change should be finalized in a bit.

Wednesday, January 12, 2011

Hard lesson to learn

See here: what happens when you think the spec does not apply to you because you are special*. In short: huge computer security problems, and huge embarrassment...

But it's such a valuable lesson, you know? Realizing there are many more specs than any human can possibly read, and the full extent of the consequences, is a sobering experience. These specs tell you how to write C code, how to call OS APIs, how to boot a machine, how to use a graphics card, how to use a compiler, etc. Those specs also state how you're supposed to do stuff so that the resulting behavior is well defined, as opposed to undefined (see video above). That also means we do not have the means to ensure proper software behavior because ultimately we do not understand how it is meant to work correctly.

Thus, regardless of typing and safe compilers and whatever, how can we make sure our software really works when we cannot absorb all the material necessary to prove our software correct? Alas, in the mean time, this is the world we live in today. Back to reading more specs...

* e.g.: because you can sue anybody who disagrees into compliance.

Saturday, January 01, 2011

Chapter 6 is done

I just finished Fundamentals II's chapter 6. Besides all the wonderful material, this chapter weighs in at 78 exercises of all kinds. I really like the result. The draft is at 158 pages right now. It's time for a little break before I start with chapter 7, on threading.

By the way, how fitting that I get to write about threading now. At work, I have to fix this condition that leads to HPS scheduling the wrong Smalltalk process until you hit ctrl-y. Fortunately it's rare, but it should never happen to begin with. I had fixed a problem where signal handlers would smash the wrong stack page's stack limit, but there are some critical section style holes that need to be closed before the general scheduling functionality can be proven to work in every single case.