Long long time ago (circa '95), in some lonely dark corner of faraway India, in a dingy college dorm that I can't believe I lived in, I had this notion of opening up my 386 and wiring the speaker terminals to a pair of headphones, jack snipped off. No sound card, just replaced crappy PC speakers by regular headphones..MOD file for the Ghostbusters theme (mod is basically a MIDI plus sounds of instruments/ short spoken phrases thrown into the header).
People put on the headphones, their eyes *shone* in wonder, and they said one word: "F**k". It was incredible.
The sweetest, most informative, and most memorable categories in my experience map to the same book: 101 Stories about Chemistry, author unknown, MIR publications (Moscow) (which i believe shut down a few years ago). My uncle presented me a copy when I was a seventh grader, and it is appealing to a geek of any age. I have read it countless times, till someone stole it from me. It is essentially anecdotal, with cute cartoons such as a statue of Napolean on a pedastal grimacing at a chemist dude holding a hair and a bottle of Arsenic (from the uber-poisoning story). Catalysis, rare elements, poisons, many many concepts are developed and explained in a fascinating way through real stories. Suffice to say that this book singlehandedly retained my (a Computer scientist's) healthy interest in Chemistry.
It's a surprisingly uncommon book. Google doesn't know about it.
Here's a plea. Look for this book in your local library or junk book store. It's worth it. Especially Muscovite readers with perhaps better access to old MIR books.
The other plea. If anyone, anywhere in the world is willing to sell me one or two copies of this book at ANY reasonable price, please, *please* contact me. Thanks. Sitaram.
A simple trick that's both day-to-day-useful and gets even systems-literate folk (including my advisor) gaping is this:
I have two machines on my desk; one main Linux box in text console mode, and one by-the-side windows box running cygwin and sshd. I use Lynx (by preference) on the Linux box for most of my text-only web browsing. But occasionally when I want graphics, I happily hit this magic key sequence, and *poof* an Internet Explorer pops up on the windows box.
The trick is to have a special bookmark file under lynx multi-bookmarks; when you "add-bookmark" to this file, a little daemon shellscript polls it every second, grabs the URL, and runs "ssh windowsbox IEXPLORE.EXE url". No big shakes!
Here's a non-media-hyped article
on
Time Travel
·
· Score: 1
.. with a decent physics-looking explanation: an interview with April Holladay on Wonderquest.com. p.s. I hope this venture succeeds.
The problem with hierarchical file systems is that we have to choose one of them. I would love to see a storage system where we can use both ways _at the same time_. A system that groups file depending on relationships they have. Such that 'ls/etc' gives me all config files for all apps, and 'ls/usr/local/mutt' shows me all mutt-related files, including it's config file(s). I have no idea how to implement such a beast
A good many years back, I used userfs and Linux-1.3.47 to hack up a file system for managing packages. This was for a course project in my undergrad sophomore year, six years ago. Semantics were nice: ls/usr/bin did the usual thing, ls/usr/.emacs/bin showed emacs binaries, cd/.emacs switched you to a "view" of the filesystem restricted to emacs files, and all such nifty stuff. These ".emacs" type directories were internally generated by the kernel, and were invisible when you normally said "ls". It rocked the pants off slackware's/var/adm/packages based manager, and sometimes, I think, off rpm too, maybe.
We learnt some valuable lessons, especially applicable to developers of MOM and similar systems:
On the long run, it was systematic, and yet cumbersome to use. Suppose you cd/.emacs/usr/share/docs; and then you want to switch to docs of vim, and you had to go all the way down. This was fixable in theory.. and would have been worth it too..
We only grazed the issues modification and upgrade. The idea was to cd/.emacs and tar -zxvf emacs-upgrade.tar.gz. Dependencies can be a bitch.
Lastly, it (automatically) supported one nifty feature, that of cd/.emacs; tar zcvf ~/emacs.tar.gz *. This sort of thing, with added semantics like tar options to avoid.o file etc. can be marvellous for developers, compared to what's there now.
SO I think there's potential in this direction, for stuff inconceivable from user space.
I'd love to be contacted with ideas/suggestions/questions/whatever, or if you want me to dig up the code or documentation.
What a wonderfully orgasmically sensational news headline! "802.11g Approved By IEEE 54 mb/s on 2.4 gigahertz". Thank god for geeks.
--
"C line noise" anagrams with "sonic edlin", and as accidental inventions go, grunting "burp" to save file seems thought-provoking.
At the heart of any optimal task switching, there's conceptually a simple, adaptive mechanism that weighs the (measurable) cost of switching tasks against the (expected) benefits of sticking on. Several nice comments on this thread describe this idea for CPU scheduling. On similar lines, I just published a paper on anticipatory disk scheduling (to appear in the Symposium on operating systems principles, October 2001). Idea is that synchronous I/O makes processes issue requests one after another, so the operating system deliberately tries to service many requests from each process before context switching. Unnecessary context switching can get very expensive, and the trick is to outweigh expected benefits against costs while scheduling requests.
This principle can be consciously used in meatspace. We all have unique levels of tolerance and overhead for context switching: measure it! For example, while coding two pieces of software, use a metric such as the number of lines modified in the last hour (diff old new | wc -l): very very hazy, but still useful. Then on each context switch, extrapolate to the next hour based on the past hour. Compare that with the number of lines actually coded for the other project in the next hour. Congratulations, this is your context switch overhead ratio.
Modulo coffee consumption, this number gives an acceptable personalized context switch frequency. There are other factors like taking a quick break to another project, but to a first approximation, this works.
// today's my 24th birthday. just felt like telling someone.//
I often clear up programmer blocks by forcing myself to rethink the code differently. For example,
1. change code indentation from 8 to 2 or vice versa, so nothing looks familar anymore. Turn off syntax highlighting and turn it back on sometime later.
2. mentally pretend not to know anything about the code being stared at, and scan the code as if describing it to myself.
3. erase whiteboard thoroughly, and draw a colorful block diagram of the code structure and dynamics (especially useful for event-driven code).
4. write up the whole thing in pseudocode, starting from scratch. Once I took this all the way - I took an afternoon off and wrote a working FreeBSD VM subsystem simulator, and immediately identified the elusive bug in the module I was writing.
Other than that, of course, slashdot and userfriendly breaks help the most:)
(flipped through replies but didn't find too much on this)
As far as possible, stick to occasional generation of static web pages, rather than generating them on the fly with mod_perl or mod_php or CGIs or whatever. With clever design, I think a huge number of websites can be converted to a statically generatable version, escalating performance in a big way. You can run the html generator (which could be just CGI >foo.html) using either a cron job, or run "make" whenever you update any content.
As an example, I've always wondered why/. doesn't do static page generation - people's user profiles comprise a fairly small set of look-and-feel options. Apart from that "page generated for Mr. Foo Bar by a marauding flock of random geese" thang, there are only so many combinations for the rest of the page, and generating them in one shot would make/. pages *so* much quicker to load. Likewise, regenerate only the required pages on every update (article or comment). You don't lose any customizability that way, and gain hugely on response time and webserver throughput.
Slashdot Mirror
Long long time ago (circa '95), in some lonely dark corner of faraway India, in a dingy college dorm that I can't believe I lived in, I had this notion of opening up my 386 and wiring the speaker terminals to a pair of headphones, jack snipped off. No sound card, just replaced crappy PC speakers by regular headphones. .MOD file for the Ghostbusters theme (mod is basically a MIDI plus sounds of instruments/ short spoken phrases thrown into the header).
People put on the headphones, their eyes *shone* in wonder, and they said one word: "F**k". It was incredible.
It's a surprisingly uncommon book. Google doesn't know about it.
Here's a plea. Look for this book in your local library or junk book store. It's worth it.
Especially Muscovite readers with perhaps better access to old MIR books.
The other plea. If anyone, anywhere in the world is willing to sell me one or two copies of this book at ANY reasonable price, please, *please* contact me.
Thanks. Sitaram.
.. Here [ps.gz] published in NDSS '02.
A simple trick that's both day-to-day-useful and gets even systems-literate folk (including my advisor) gaping is this:
I have two machines on my desk; one main Linux box in text console mode, and one by-the-side windows box running cygwin and sshd. I use Lynx (by preference) on the Linux box for most of my text-only web browsing. But occasionally when I want graphics, I happily hit this magic key sequence, and *poof* an Internet Explorer pops up on the windows box.
The trick is to have a special bookmark file under lynx multi-bookmarks; when you "add-bookmark" to this file, a little daemon shellscript polls it every second, grabs the URL, and runs "ssh windowsbox IEXPLORE.EXE url". No big shakes!
.. with a decent physics-looking explanation: an interview with April Holladay on Wonderquest.com.
p.s. I hope this venture succeeds.
The problem with hierarchical file systems is that we have to choose one of them. I would love to see a storage system where we can use both ways _at the same time_. A system that groups file depending on relationships they have. Such that 'ls /etc' gives me all config files for all apps, and 'ls /usr/local/mutt' shows me all mutt-related files, including it's config file(s). I have no idea how to implement such a beast
/usr/bin did the usual thing, ls /usr/.emacs/bin showed emacs binaries, cd /.emacs switched you to a "view" of the filesystem restricted to emacs files, and all such nifty stuff. These ".emacs" type directories were internally generated by the kernel, and were invisible when you normally said "ls". It rocked the pants off slackware's /var/adm/packages based manager, and sometimes, I think, off rpm too, maybe.
/.emacs/usr/share/docs; and then you want to switch to docs of vim, and you had to go all the way down. This was fixable in theory.. and would have been worth it too..
/.emacs and tar -zxvf emacs-upgrade.tar.gz. Dependencies can be a bitch.
/.emacs; tar zcvf ~/emacs.tar.gz *. This sort of thing, with added semantics like tar options to avoid .o file etc. can be marvellous for developers, compared to what's there now.
A good many years back, I used userfs and Linux-1.3.47 to hack up a file system for managing packages. This was for a course project in my undergrad sophomore year, six years ago. Semantics were nice: ls
We learnt some valuable lessons, especially applicable to developers of MOM and similar systems:
On the long run, it was systematic, and yet cumbersome to use. Suppose you cd
We only grazed the issues modification and upgrade. The idea was to cd
Lastly, it (automatically) supported one nifty feature, that of cd
SO I think there's potential in this direction, for stuff inconceivable from user space.
I'd love to be contacted with ideas/suggestions/questions/whatever, or if you want me to dig up the code or documentation.
What a wonderfully orgasmically sensational news headline! "802.11g Approved By IEEE 54 mb/s on 2.4 gigahertz". Thank god for geeks.
--
"C line noise" anagrams with "sonic edlin", and as accidental inventions go, grunting "burp" to save file seems thought-provoking.
At the heart of any optimal task switching, there's conceptually a simple, adaptive mechanism that weighs the (measurable) cost of switching tasks against the (expected) benefits of sticking on. Several nice comments on this thread describe this idea for CPU scheduling. On similar lines, I just published a paper on anticipatory disk scheduling (to appear in the Symposium on operating systems principles, October 2001). Idea is that synchronous I/O makes processes issue requests one after another, so the operating system deliberately tries to service many requests from each process before context switching. Unnecessary context switching can get very expensive, and the trick is to outweigh expected benefits against costs while scheduling requests.
// today's my 24th birthday. just felt like telling someone. //
This principle can be consciously used in meatspace. We all have unique levels of tolerance and overhead for context switching: measure it! For example, while coding two pieces of software, use a metric such as the number of lines modified in the last hour (diff old new | wc -l): very very hazy, but still useful. Then on each context switch, extrapolate to the next hour based on the past hour. Compare that with the number of lines actually coded for the other project in the next hour. Congratulations, this is your context switch overhead ratio.
Modulo coffee consumption, this number gives an acceptable personalized context switch frequency. There are other factors like taking a quick break to another project, but to a first approximation, this works.
I often clear up programmer blocks by forcing myself to rethink the code differently. For example,
:)
1. change code indentation from 8 to 2 or vice versa, so nothing looks familar anymore. Turn off syntax highlighting and turn it back on sometime later.
2. mentally pretend not to know anything about the code being stared at, and scan the code as if describing it to myself.
3. erase whiteboard thoroughly, and draw a colorful block diagram of the code structure and dynamics (especially useful for event-driven code).
4. write up the whole thing in pseudocode, starting from scratch. Once I took this all the way - I took an afternoon off and wrote a working FreeBSD VM subsystem simulator, and immediately identified the elusive bug in the module I was writing.
Other than that, of course, slashdot and userfriendly breaks help the most
I'd submitted this story a while back, and HTMLized it for easy viewing. HTH.
(flipped through replies but didn't find too much on this)
/. doesn't do static page generation - people's user profiles comprise a fairly small set of look-and-feel options. Apart from that "page generated for Mr. Foo Bar by a marauding flock of random geese" thang, there are only so many combinations for the rest of the page, and generating them in one shot would make /. pages *so* much quicker to load. Likewise, regenerate only the required pages on every update (article or comment). You don't lose any customizability that way, and gain hugely on response time and webserver throughput.
As far as possible, stick to occasional generation of static web pages, rather than generating them on the fly with mod_perl or mod_php or CGIs or whatever. With clever design, I think a huge number of websites can be converted to a statically generatable version, escalating performance in a big way. You can run the html generator (which could be just CGI >foo.html) using either a cron job, or run "make" whenever you update any content.
As an example, I've always wondered why