Forgot your password?

Comment: Re:thanks for the info (Score 1) 371

by Yaztromo (#47634693) Attached to: Oracle Hasn't Killed Java -- But There's Still Time

You're welcome -- glad to help.

I should note that I am assuming that with 16GB of RAM you're running a 64-bit OS. If you're running a 32-bit OS (with PAE to access all the extra memory), you're going to be more constrained. While an OS with PAE can access quite a lot of RAM, 32-bit processes are still limited to a 32-bit virtual memory space (with a maximum addressable memory of 4GB, but functionally less on some OS's depending on whether or not they do things like mapping kernel memory into process memory space (Windows, I'm looking at you...)). On some OS's, Java also expects that the heap memory space will be completely contiguous (virtually, not physically), which may not seem like a problem until you run into a virus scanner or some such that loads some library resident into every single process ("DLL Injection") at the 2GB mark or some other fixed virtual memory location below the maximum (yeah, I'm looking at Windows again. Had this one bite a customer pretty badly a few years back who for some odd reason still insisted on running 32-bit Windows servers). 64-bit OS's can still support DLL Injection, but typically the injected memory location is so insanely high within VM (quite a large amount higher than you can physically install in your typical system), that it doesn't cause any problems.

The point being (before I go off into too long of a rant), on the off chance you're still running a 32-bit OS and 32-bit Java (I'm reasonably sure you can run 64-bit Java on OS X 1.6, even when booting with the 32-bit kernel), tuning may only take you so far for Java applications that are really memory hungry -- you'll still hit a wall well before even 1/4 of your installed RAM is used. In that case, upgrading to a 64-bit OS and 64-bit Java is highly recommended, if possible.

(As an aside, this is actually one reason why Android handset developers were quick to jump into using quad-core processors. When programming Android using Java, all of these memory and garbage collection issues arise, in a package with less RAM and less processing power than a standard PC. The best way to handle being able to create responsive applications under GC in such a model is to do as much of the GC as you can in the background on one or more independent cores to minimize whole-application pauses. Contract this to iOS which uses retain/release cycles (or better yet, Automatic Retain Counting, aka ARC) where memory management is either hand-coded by the developer, or resolved at compile time (in the case of ARC), requiring no GC at all).


Comment: Re:Pauses my 16 GB desktop working on 4K program (Score 1) 371

by Yaztromo (#47633539) Attached to: Oracle Hasn't Killed Java -- But There's Still Time

I use a few Java programs on my desktop, which has 16GB of RAM. One program I use is a little editor / mini-IDE for microcontrollers which have 4k of memory. While writing these 4K programs, Java will largely lock up the machine for 30 seconds, probably while it's doing GC.

Check your settings. For better or worse, Java doesn't run like other native programs (on most platforms at least) -- the maximum heap space it will allow programs to use is fixed at runtime (i.e.: it won't grow dynamically as memory allocations are requested). On the system I'm sitting at right now, the default is set to just under 2GB (Win7, JDK 1.7.0_45 (both 64-bit), 8GB RAM). No matter how much actual memory my application wants (or needs), this is the maximum that can be allocated for objects on the heap. Attempting to allocate any new objects once this 2GB of heap space won't use any free RAM available on the system; it will instead trigger garbage collection.

Additionally, with Java 7 at least, there are seven different garbage collection algorithms. The default is the Parallel Scavenger Collector, which is a "stop the world" collector. You might find on your system you have fewer pauses if you enable the Concurrent Mark/Sweep collector, in conjunction with the Parallel Copy Collector. Concurrent Mark/Sweep runs in the background, and only stops all application threads if it can't keep up with demand.

Tuning those should help with your specific performance issues. I completely recognise that none of this should be necessary in a well-written application; unfortunately for all too many Java developers, "I don't need to worry about garbage collection" also seems to mean "I don't need to care about the lifecycle of my objects", which of course isn't true. There are a lot of badly written Java applications out there, and in some ways understanding how Java handles memory is actually harder than understanding memory allocation in a lower-level language like C (Garbage Collection makes things pretty complex), and all too often I run into Java developers who simply have no idea how the JVM manages these things. IDEs for embedded systems always seem to be particularly bad for this. That's not entirely Java's fault -- you can write memory-efficient Java applications, it's just that too many Java developers (and frequently their managers) seem to think you can ignore memory issues with Java because it has Garbage Collection, as if it's some magical solution to memory allocation/deallocation.


Comment: Re:$7142.85 (Score 1) 419

by Yaztromo (#47568255) Attached to: A 24-Year-Old Scammed Apple 42 Times In 16 Different States

But.. but...but didn't mac's come with some magic magnetic connectors to safeguard them against cable strain ??

No. The MagSafe connector was never designed to eliminate cable strain. It was designed to break away from the laptop should you trip over the cable, preventing the laptop from being damaged.

Cable strain can come from many sources. The cable can simply be bent in a funny angle repeatedly over a long period of time. A MagSafe style connector isn't going to protect against that. Yanking out the cable by gripping the cable and pulling (as opposed to holding the connector directly) also causes cable strain, and again -- MagSafe won't help you here (other than by ensuring you can't also accidentally yank the laptop with the cable).

Even the very ad you linked emphasizes this -- the whole point is that the "PC" is damaged -- not the PC's power cord. Apple has never claimed you can't damage the cable by straining it inappropriately, and MagSafe was never designed nor marketed to prevent such damage.


Comment: Re:Wow ... (Score 1) 419

by Yaztromo (#47568071) Attached to: A 24-Year-Old Scammed Apple 42 Times In 16 Different States

When you pay for gas with a credit card and the pump asks you to punch in your zip code, it's not collecting marketing information. It's using the zip code as a (rather flimsy) security measure to protect against someone buying gas with a lost/stolen credit card.

I had never seen this done prior to a trip through the US earlier this year. Of course, it wouldn't accept my Canadian postal code (which is a six character mix of alternating letters and numbers). I had to cancel the transaction and go in and have the cashier run everything manually, and then go in after filling up to complete the transaction.

Not the end of the world, I suppose. I suspect we don't bother with doing that here in Canada due to a) stronger privacy laws and b) near global use of chip-and-pin for credit cards. At the time, my natural first thoughts were "why on EARTH would you need to even ask me that???". Now I know why, and will know better the next time I'm down that way.


Comment: Re:Customer service? (Score 5, Insightful) 928

That's all good reason for boarding them last - so they don't slow down those who can board quickly.

I promise the plane won't take off without you. What, are you in a hurry to cram yourself into an airline seat instead of enjoying the comfort of the airport lounge for another 10 minutes or so? Entitled much?


Comment: Re:it is the wrong way... (Score 5, Insightful) 291

by Yaztromo (#47479995) Attached to: Australia Repeals Carbon Tax

But because such penalties impact all businesses in whatever country is collecting them, it won't really change things - because all of those businesses will simply pass along the new government-mandated increase in their overhead along in the form of higher prices.

However, if you believe in capitalism this creates a space for an aggressive innovator to come in with new reduced-energy practices/processes, and pass those savings onto consumers, causing the existing players to either likewise update their practices/processes to compete, or have them diminish/die. Such changes don't happen overnight however -- it could take many years for the selective pressure to bear.


Comment: Re: Maybe, maybe not. (Score 1) 749

by Yaztromo (#47455149) Attached to: Obama Administration Says the World's Servers Are Ours

You apparently never heard of United States vs. Conrad Black


In this case, Black (born Canadian, but renounced his citizenship after becoming British in order to sit in the House of Lords), who was CEO of Hollinger International. As part of a series of criminal charges against him, he was ordered by a US court not to move or tamper with documents relating to the case. However, he and an accomplice were filmed removing boxes of paperwork from an office in Toronto, Ontario, Canada. He was charged and ultimately found guilty of obstruction of justice in the US for this, and served 48 months in prison.




"Eskimo Diet" Lacks Support For Better Cardiovascular Health 166

Posted by timothy
from the quit-your-blubbering-and-eat-this-wheat-germ dept.
jones_supa (887896) writes Monthly Prescribing Reference reports that the "Eskimo diet" hypothesis, suggested as a factor in the alleged low incidence of coronary artery disease (CAD) in Greenland Eskimos, seems not to be supported in the literature, according to a metastudy published in the Canadian Journal of Cardiology (abstract). Researchers found that only one study directly assessed the prevalence of CAD or CAD risk factors, and that study showed that CAD morbidity was similar among Inuit and American and European populations. In most studies, the prevalence of CAD was similar for Greenland Eskimos and Canadian and Alaskan Inuit and for non-Eskimo populations. The original studies from the 1970s that formed the basis of the supposed cardioprotective effect of the Eskimo diet did not examine the prevalence of CAD. "The totality of reviewed evidence leads us to the conclusion that Eskimos have a similar prevalence of CAD as non-Eskimo populations," the authors write. "To date, more than 5,000 papers have been published studying the alleged beneficial properties of omega-3 fatty acids not to mention the billion dollar industry producing and selling fish oil capsules based on a hypothesis that was questionable from the beginning."

Comment: Re: OR (Score 1) 250

From an iPhone on AT&T IPv6 does not work. Neither does it work on my Uverse connection.

That's the fault of the connection, however, and not the iPhone. iOS if fully IPv6 compatible; I take advantage of it all the time. I even wrote an IPv6 test utility for iOS a few years ago. You just need a WiFi router with autoconf advertising IPv6 routes, an you're all set.

The fact that all too many North American ISPs still haven't got their IPv6 implementations in play is the real story here. Computers and most smart phones are ready to connect -- they just need the ISP support to do it.


Comment: Re:Its Killer Feature (Score 1) 411

by Yaztromo (#47166621) Attached to: Apple WWDC 2014: Tim Cook Unveils Yosemite

I doubt it's high on Microsoft's priority list. Your earlier example shows a saving of a few hundred megabytes out of 8 GB, and RAM is really cheap.

I should point out that in my example, the memory pressure at the time was quite low. Had I pushed the memory pressure higher, the amount of compressed memory would also have been quite a bit higher.

RAM may be cheap, but there are still physical limits that can be hit on any given board or system before you reach the theoretical limits. I'm posting this on a 2009 iMac right now, and it has a maximum RAM configuration of 8GB (which is also how much RAM is installed). No matter how cheap RAM gets, this system can't accommodate any more.

Considering Mavericks was a free upgrade, installing it was like going up to 12GB of RAM or more -- for free. I don't have any metrics in front of me of the useful theoretical maximum compressed memory storage, I can only assume that it's somewhere in the neighbourhood of about (Installed RAM - 1GB)*2 at best (or in my case, 14GB. The 1GB is to ensure space is reserved for wired memory, which can't be swapped or compressed). I suspect it will be a bit less, depending on how compressible your data is (the algorithm used is optimized for a 2:1 compression ratio, however not all pages will be compressible to this degree; my understanding is that if a pair of pages can't be compressed into a single page, the compression routine stops for that pair of pages).

Note that as memory compression sits between the point where the OS identifies that it may need to evict old pages and the point where the pages are physically swapped to disk, the pages written to disk are also compressed (unless they were incompressible in the first place). This will roughly halve the amount of data that needs to be written to swap, meaning that the slowest operations of the paging to disk procedure is roughly halved in time as well.

As Windows machines swap as well, being able to halve the time required to read data from and write data to disk would be a huge boost. Being able to get a few million extra pages without the need to swap is an even bigger performance boost. I'll point out this ArsTechnica article on Apple's Compressed Memory subsystem -- note in particular the second graphic which shows a system under much heavier memory pressure, where a machine with 16GB of RAM has over 8GB compressed, and only 26.5MB (not a typo!) of data swapped to disk. That's a lot of data that didn't need to be written to a page file.


Comment: Re:Its Killer Feature (Score 5, Informative) 411

by Yaztromo (#47152217) Attached to: Apple WWDC 2014: Tim Cook Unveils Yosemite

you seem to know what you're talking about. can you explain this idea of memory compression, and what the heck the new activity monitor means? the old one made sense. Pie chart, showing free, available, and active. Now it's apparently using up all my memory I have 8 GB but it shows a line chart with a small amount of "memory pressure".

Sure -- I'll try to explain it the best I can. I won't make any specific judgements as to whether the new controls are better than the old, except to point out that there is more useful information in the new that wasn't present in the old. You're still perfectly welcome to prefer the old pie chart :). I'll try not to stray too far into the esoteric; if you need more details on a specific subject here, feel free to ask.

First a bit on the theory of memory management in general. In most modern operating systems like Mac OS X, each application appears to get it's own memory space, starting at '0' and running up to 0xffffffffffffffff (a fancy way of saying the addresses go from 0 to somewhere in the neighbourhood of 1.84*10E19 bytes of memory). To make things easier to deal with, the operating system breaks these up into chunks 4096 bytes in size called a 'page'. Now 1.84*10E19 bytes is probably way more memory than you have available on your system, but that's okay -- while conceptually an application can use any of that memory space for pretty much anything it wants, the operating system keeps track only of which pages have actually been allocated to each application. This system is called 'virtual memory': each application has its own virtually memory space to play with that doesn't interact with he memory of any other application. This is the value that shows in the "virtual memory" box in the activity monitor.

Now of course, you have real, physical memory in your machine, and you don't have a separate set for each application (in a physical sense -- you don't have one set of chips for Safari, and another set of chips for iPhoto, for example). The real memory has to hold the virtual memory somehow, and be able to map from one to the other. The operating system keeps a structure known as the Translation Lookaside Buffer that keeps this mapping for pages stored in physical memory. So it might have a bunch of entires for Safari, saying that the page consisting of what the application sees as memory area starting at 0x0000 and going to to 0x0FFF are stored in memory location 0x40000000 (the 1GB mark), the page of what the application sees as memory area starting at 0x1000 and going to 0x1FFF are in location 0x40096000, etc. In fact, the pages can be all over the place, and not even in order -- the operating system keeps track of all the used memory pages for the application wherever they are stored in memory. The amount of physical memory you have shows in the "Physical Memory" box of the activity monitor.

If you don't get all that, don't worry -- the main takeaway is that these pages can be stored in memory, and the operating system tracks of them when they are. Because we work with all of these pages, however, the operating system can also store them someplace else. Prior to Mavericks, this was always written to disk in the "swap" file (also sometimes known as a "page file"). This happened when memory pressure gets higher than the operating system can handle in RAM alone; that is, programs are asking for more virtual pages than the operating system can fit into real memory. To try to make room for new requests without unloading applications, the operating system will periodically go through the list of pages if memory pressure is high, find the least-used pages (you might have some application running that you put into the background and haven't touched in hours, for example, or applications which have reserved pages for things such as documents you haven't looked at in hours, even if you've otherwise used the application itself), and write them to disk. This is known as "swap". The pages of course are still there -- if memory pressure decreases, the operating system can load them again. Alternately, if you need to use the memory, the operating system will load it again, writing some other old, unused page to disk. The size on disk of all of these old pages sent out for long-term storage like this is displayed in the "Swap Used" box in the activity monitor.

When memory pressure is really high, this can get really ugly really fast. Everyone has hard drives that are massive compared to the physically available RAM, so the system can use this system until the hard drive is full. For many people, however, the system will become nearly unusable long before this point; if that "least used" page is one that hasn't been used in just a few milliseconds, and will be needed again in a few milliseconds (that is, all the pages have been used very recently and are expected to be used again), you can wind up in a situation where you're trying to write out some not-very-old pages in order to load some also not-very-old pages, and you're going back and forth doing this again and again and again, the the speed at which you can do so is slower than the need for the pages, slowing your system to a crawl. You've probably seen this before -- you load too many tabs in Safari and have a bunch of other stuff running, and all of a sudden the hard drive is running all the time and the system is unresponsive until you unload some tabs or programs and wait for the system to catch up to you (in effect, reducing the memory pressure). This phenomenon is known as "thrashing".

As an aside, modern operating systems take a shortcut when allocating memory to applications that request it. The memory page is typically only actually created when you put something into it. Empty pages are recorded by the system, but aren't given any real physical existence until you put something into them. This means you could (conceptually) ask for more pages than the system could ever handle -- an applications entire memory space in fact -- and no real memory pages will be used until you put something into them. This is the reason why you can sometimes see the "Virtual Memory" value exceeding the amount of RAM, and still have no swapping happening.

That brings me to "memory pressure" which you asked about. This is basically a measure of how responsive the system can be to give out new pages of memory when an application needs them. When it's a low, green line you effectively have no pressure -- the operating system can give pages immediately with little or no work to an application that asks for some new pages. When it's tall and red, the pressure is very high, with very little real RAM available to give out, lots of reliance on reading and writing pages to the hard drive swap file, and general slowness. You can think of this as the state where the programs you're running (including the operating system) has asked for way more RAM than you have, and the system is having a hard time rearranging the pages in order to make room for new requests. As the memory pressure gets higher, the probability of thrashing also increases.

Now, in Mavericks Apple introduced a new system they call "Compressed Memory". This subsystem basically sits in-between the point where the system looks for old pages to write to the swap file, and the actual writing of those pages to disk. Instead of writing those pages straight out to disk, the operating system finds pairs of pages and runs them through a compression algorithm, and then stores them as a single page in memory. In effect, you take two pages and jam them into one page, giving you an empty page to work with. Mavericks tries to do this with as many pages as possible instead of writing them out to disk, because it can do this operating a whole lot faster than writing all that data to disk, which is comparatively slow. The amount of memory the system is using to hold compressed data is listed in the bottom-right "Compressed" box in the activity monitor. Looking at mine right now, it says I have 392.3MB compressed. This is equal to over 102 million pages of data that the system has brought back available for application use by compressing those pages I haven't used in a long time. If memory pressure were to increase, more memory would be compressed. If pressure continues to increase, those least-used compressed pages will be swapped to disk (in compressed state).

The key to performance, of course, is not to write anything to swap if it can be avoided. Swap slows things down. Conceptually memory compression also slows things down, but it's so slight and imperceptible at the level it typically occurs at you'll never notice it as a user.

"App Memory" is the amount of memory actually in use by applications and the operating system itself. Memory pressure will be green so long as this value is less than your Physical Memory. "Wired Memory" is a special subset of memory that cannot be compressed, swapped, or written to disk -- typically because it's too core to the operating system (imaging if the operating system paged out to disk the code used to read pages from the disk! You'd be stuck in a paradox and the system would stop working. Much of the OS kernel is always flagged as "Wired").

Which leads me to the last value in the application monitor -- File Cache. It's well known in virtual memory circles that unused memory is wasted memory. Memory is very, very fast, and if you're not using it for anything at all, you're not gaining the benefit of its speed. For this reason, the operating system keeps a File Cache in memory where it stores bits and pieces of files it thinks you may need in the near future. It acts as a sort of predictive read-ahead of your hard drive: if you need a file in the cache, it will load in the blink of an eye without spending much time hitting the hard drive, making the system seem really, really fast. Modern OS designers use a file cache system that will use as much available memory as possible in order to benefit from this speed increase as many times as possible -- the larger the disk cache, the greater the probability you'll need something from that cache, and the faster the system will perform. As such, the File Cache claims nearly as many pages as are available in order to increase this probability, and give you a faster experience loading files (note that some number of pages is usually left free in order to have somewhere to swap to and from as the need arises, but it doesn't have to be particularly large: maybe just a few MB of space)

The magic of the File Cache is that, since it's typically a read-only copy of what's actually on your hard drive, if an application needs more memory than is available, the operating system can simply drop the pages int he cache with very little effort. They are never compressed or swapped (which would defeat the purpose -- why would you write data to the hard drive that already exists on the hard drive?) -- they just get dropped if an application needs more memory (perhaps by loading a new application). In this way, the File Cache will basically grow and shrink to fit into whatever free physical memory your system has at the time. This is why you may see your "Memory Used" value getting very close to the "Physical Memory" value, but with the Memory Pressure still down in the green and with no swap used: if you get into this situation and something asks for more memory pages, the OS will simply drop some of the disk cache pages and reassign them to the application.

For this reason, it's actually expected that Mavericks will always appear to be using all of your memory. Trying to fight this will actually hurt your performance. The truly important things to keep an eye on is the "Memory Pressure", as this is a much more exact guide to what you should expect performance wise as you use more memory. The old chart was great for people who know the ins and outs of virtual memory (like me), but it often led to users trying to do weird things to try to "clear out" RAM in order to see more free space. You have to trust that the operating system can do this faster and better than you can, but just seeing a pie chart showing all of your memory in use doesn't help. The "Memory Pressure" on the other hand is a much better measure, as only when it gets into the higher values should you start to look into doing something (such as unloading unused applications, browser tabs, documents, etc.).

I hope you didn't find this TL;DR -- I know it's long -- the system is unfortunately very complicated, and you could spend an entire university semester dealing with the subject in depth. When I taught 3rd year Operating Systems at a University I'd usually spend at least a week on this subject, and even then you'd just crack the surface and give as much background as you find here (albeit with some more algorithmic details). If you did find this TL;DR, here are the quick takeaways:

  1. Swapping to disk should be avoided as it slows your system down. Its main benefit is to allow you to use more memory that you physical have. Try to keep this value low.
  2. Mavericks tries to help you keep the swap size low by compressing pages before it has to write them to swap (with the hope the saved space means it never has to write to swap). And if it does eventually have to write to disk, it writes out the compressed pages, making swapping roughly twice as fast as it was prior to Mavericks.
  3. Try not to manually manage your memory. It's both okay and expected that the OS will try to use all of it. It does so to try to speed up your computer. If a program needs some of this used space, the OS will give it back immediately.
  4. The old memory pie chart is great for the uber-techies who understand virtual memory, but doesn't paint a useful picture if you don't. Memory Pressure is much, much more useful to laypeople, as it gives you an indication of when you should actually start to worry about reduced performance. When the memory pressure is low/green, the OS has lots of memory it can dole out at a moments notice (even if the Memory Used value is close to the Physical Memory value). When it's yellow, you'll start to see some performance degradation if you don't unload some stuff. When it's red, performance is already suffering and you should unload some stuff right away.
  5. Virtually Memory is your friend! Try not to second guess what the OS does with it -- it's smarter and faster than you are. You only need to take action if the Memory Pressure creeps into the red (or if it's yellow and you know you're going to need a bunch in short order). If you find you're frequently in the yellow or red, a RAM upgrade would be of tremendous help (and conversely, if it's always green a memory upgrade probably won't help you much.

Congrats if you made it to the end. That's my "short" version of a very complex topic. I hope it made sense and is useful to you.


Comment: Re:Its Killer Feature (Score 4, Interesting) 411

by Yaztromo (#47150467) Attached to: Apple WWDC 2014: Tim Cook Unveils Yosemite

Linux had the likes of zram, zcache, and zswap for years before Mavericks.

zram was only merged into the Linux kernel in 3.14, on March 30, 2014 -- well after Mavericks was released. And it's more about using a portion of compressed memory for swap -- it's a compressed RAM disk for swapping to, and isn't the same as Apple's transparent page compression system.

zswap is much more akin to what Apple's Memory Compression scheme achieves, and it was merged into the Linux kernel mainline in kernel version 3.11, which was released on September 2, 2013, just a few weeks before Mavericks was released.

So you have my apologies -- I wasn't aware of zswap until now. If the topic comes up again, I'll ensure I only compare that feature to Windows (which AFAIK still has nothing like this available).


Comment: Re:Its Killer Feature (Score 4, Interesting) 411

by Yaztromo (#47150029) Attached to: Apple WWDC 2014: Tim Cook Unveils Yosemite

Do you know C? Any desire to implement such a feature in Linux? Seems like a good idea, and your claim of dramatic performance improvement has got me thinking. Perhaps this would be a good way to dip my toes into kernel hacking, and perhaps I'm not the only one thinking that.

Yup -- I even wrote an experimental real-time kernel for the Atmel AT90 a few years back.

To be honest, I have considered it, as I'm also a Linux user (OS X makes a fantastic interface into a bunch of headless Linux servers that do the grunt work around here), and I'd love to have this support there as well. I currently have 285 processes running on my iMac, and while I'm not really putting a lot of memory pressure on the system (7.97GB used out of 8GB, with only 8.76GB of virtual memory active and no swap), however OS X has still managed to compress 395.6MB of memory, and I haven't noticed a thing. Indeed, it's probably saved me from having to page to disk at the moment to the tune of roughly 200MB. That's a lot of pages available for use pretty quickly without the need to load them from disk first.

What's stopping me? Time. I used to do a lot of Open Source software development, and have had a few projects of my own over the years that have seen some moderate success, and would like to contribute more to the community -- but that was before I had a wife, and before we had a child who has a lot of medical needs. After a long day of commercial application development, and driving my daughter from one appointment to another six days a week, my hobbies currently reflect my desire to get out from behind the keyboard and do things outdoors.

I lament that things have gone this way -- there's nothing more I'd love than to do some deeper research on the type of compression algorithms Apple is using in their memory compression scheme (WKdm, re-implement it as part of the Linux kernel, look at algorithms to quickly identify candidates for compression, and all that good stuff. I get giddy just thinking about it -- but the last thing I need on my plate right now is another project.

If someone decides to take this up, they have my moral support. Maybe in a few years I can start working on interesting stuff like this again, but right now it would probably burn me out to take on something of this size.


Man must shape his tools lest they shape him. -- Arthur R. Miller