FireWire does in fact use SCSI, but not at the level of the 1394 spec.
Transport of SCSI command descriptor blocks is provided by the Serial Bus 2 protocol (SBP2).
If you configure a Linux system to use firewire storage, you will find that Linux' SCSI is a client of the SBP2 driver, which in turn is a client of the 1394 driver.
SBP2 is more general than SCSI, although that's its most common use. It can also be used to transport IDE commands.
Otherwise what you say is correct. The SCSI part just comes at a higher layer in the protocol stack.
WiebeTech demonstrated FireWire Encrypt working at the MacWorld Expo.
It uses software to allow the user to enter their passphrase from the keyboard. By the time of the expo, I had got the AES encryption working in the FireWire/IDE bridge but had only done the passphrase application for Mac OS X.
I've since got it working for Mac OS 9 (and earlier Mac OS versions). Windows and Linux remain before the product can ship. I don't expect either to be hard to do but they do require some work because they have to do some raw FireWire I/O.
I think it is best that I not comment any beyond this until FireWire Encrypt ships. But I think users will like what they see.
It draws its own widgets, but uses switchable renderers so it maintains the platform look and feel. It uses the Appearance Manager if it is available on the Mac OS. It put the menu bar in the windows on Windows and across the top of the screen on the Mac.
It supports Mac OS (68k, PowerPC, classic and Carbon), Win32, BeOS x86 and Linux. It would not be hard to bring it to a totally new platform.
It is in C++, is multithreaded, and provides a complete solution - not just GUI but TCP networking, file I/O, streams and persistent storagge.
If you use it, I suggest you use the version in
CVS as a lot of work has been done since the last release. A new release is planned soon.
ZooLib is under the MIT License and the Cookbook is under the GNU Free Documentation License.
ZooLib has actually been around longer than even wxWindows, but it was only placed into open source in the fall of 2000. Among the applications written with it is Knowledge Forum.
I still remember my old Compuserve ID, 72377,623. I got Compuserve around 1988 or so, when I was trying to become a Mac developer.
I interviewed with Dave Johnson of Working Software, and he asked me if I was part of the Mac developer community.
I replied that I didn't know any others, I was studying Mac programming very much in isolation.
He told me to get a Compuserve account, so I did. It was still expensive, but I managed to afford it by that time because I was working as a programmer.
For a long time I gave out my email address as 72377.623@compuserve.com.
Sorry, I always called them billboards, even at the time.
While Colonel Hughes certainly deserves his status as a pioneer, based on my reading of the article, I don't think he was actually on the Internet in the 1970's.
The reporter is apparently too young to remember that before the Internet was available to the public, there were things called "billboards".
Billboards could be networked in the sense that you could send email or transfer files between them, but it was more like store and forward networking rather than a fully connected net like we have today.
They mention that Colonel Hughes subscribed to The Source. That was a commercial billboard that was around before CompuServe. I guess it went out of business because CompuServe became more popular.
I considered subscribing to the source when I bought an ASCII terminal and 1200 baud modem in 1983, but decided not to because it was exhorbitantly expensive, being charged by the minute of connection time. I couldn't afford that on my college student budget.
The Source was really a big timesharing computer that lots of people logged into, not really a network at all.
I'm pretty sure it took more than ten years for the Internet to have more than a hundred hosts.
Colonel Hughes might have been able to access it if he was still in the military at the time, but it wasn't widely available even to the military.
To illustrate how unavailable the Internet was back then - I got the money to buy that ASCII terminal by working as a summer research assistant for an astronomer at CalTech.
The astronomy department was considering gettings its two VAXen connected to the ARPANet (it wasn't called the Internet yet). I don't mean "two main computers", I mean "two computers" - everyone used vt100 terminal to compute, and took turns at the extraordinarily expensive Grinnel image processing workstations, which had a 512 by 512 resolution and were the size of a refrigerator, mostly consisting of RAM.
Anyway, a couple machine at Tech were already connected to the ARPANet, I believe just the Physics and Computer Science UNIX VAXen.
After quite some heated debate within the department, it was decided that the expense of getting connected to the ARPANet just wasn't worth it. They felt it was a better use of the department's money to invest in research, instrumentation and traditional computing resources.
For example, they bought a third VAX, an 11/750, that was smaller than the two 11/780's we had. It came with a newfangled GUI workstation (that I could never figure out how to use) that was also the subject of much debate, and set the department back $150,000.
It could routinely support a couple dozen simultaneous terminal users. But I don't think it had the computing power of a 33 Mhz 80386 PC.
Chuck meant his Power Koding page as a joke, sure, but he may not have realized when he wrote it that people used to write software that way for a good reason.
Mike wrote his first D compiler the normal way until it worked right, then "compressed the source code" to make the interpreter work right.
I saw the source, and it looked just like all those obfuscated C code entries.
I haven't booted BeOS in a while but I'm about to, to hopefully help roll out a new release of
ZooLib soon.
I would also like to add support for BeOS PowerPC to ZooLib, but probably won't for this release. It doesn't work with my PowerLogix CPU upgrade, but you can still get Newer Technology CPUs that are supposed to work.
I'm still using the 8500 I used to port Spellswell to the BeOS. I'm typing into it right now in fact. But mostly these days I run Debian on it. I managed to install OS X on it, but it doesn't work too well. For OS X I have an iBook.
I don't recall what Mike's text adventure compiler was called, but what you describe sounds like it.
A friend of mine at CalTech named Mike Roberts created a language called D when he was in high school, because his parents wouldn't shell out for a BASIC compiler for his DOS PC. We were both in the high school class of '82 so this would have been around '81 or so.
Unfortunately, his original D compiler was written in BASIC, which he ran interpreted, so compilation was slow. In order to speed up the interpreter, he used the sort of "source code compression" that is illustrated at Chuck's Power Koding - removing any unnecessary spaces, using long source lines and having as few actual lines as possible.
(This kind of ancient interpreter didn't use byte codes - if you looped ten times, you'd parse the loop's source code ten times!)
We suggested that he rewrite his D compiler in D so he could get it to compile faster. He decided to do that, and worked really hard at it but got it working after some time.
As a complication he improved the language, but it meant that his old compiler wouldn't compile the newer kind of D code. I think what he did was make two revisions of the D-written compiler, one written in the old syntax that would understand the new, but could be compiled by the BASIC version and then an update that was written in the new D that could compile itself.
It was a sort of mix of Pascal but with lots of convenient stuff like BASIC string handling mixed in. I don't think the language would have made any computer scientists happy - D was designed to suit Mike's personal style.
He used it at first to write an Adventure-style game (a text adventure) that he and another friend designed.
Later he wrote a text-adventure compiler, where he could write a specification file for a text adventure, process it, and an executable file for a text adventure would be generated.
He didn't have to get a real summer job because he was selling these generated games to game software publishers!
Mike was an amazing programmer. He taught me a lot of what I knew about C and x86 assembly early on.
This was all on 640 kb 8088 DOS PC's that were outfitted with whizzy 10 MB hard drives. The students in the computational physics lab were expected to use the hard drives only during class, and to store their personal files on floppy when we weren't actively working at the PC's.
So his D language compiler would fit on a floppy. The old 5 1/4" inch kind, that really flopped. I think they stored 360kb.
I wonder whether we would all be better off if programmers designed their own personal languages just to suit their own personal styles. Yes, there would be portability problems but wouldn't we be more productive?
I got my own chance to hack a whacky compiler. This was a team effort though and I was just a contributor.
Star Sapphire Common Lisp manages to run a complete common lisp environment with MicroEmacs on a 640kb DOS 8088 PC.
The way it does that is by swapping to an 8 MB backing store file. But the 8088 doesn't have an MMU, you say? That's right - we operated the virtual memory
manually, by writing C code that would explicitly get or put each lisp cons from or into the VM system with a function call.
It made it... interesting... to operate on complicated data structures. I designed the implementation of the lisp scoping rules, among other things.
Oh yeah, and I was the source code control system and project manager. We didn't have a network - networks were way too expensive in 1986. What I did was wait until late when all the other programmers went home, copy the changes off all their machines onto floppy, integrate them on one machine and then copy the new release onto everyone's PC.
I had considered the problem before the show, but I didn't have time to address it.
FireWire Encrypt was a suprisingly difficult product to implement, and I was working on the show demo right up until the morning that James Wiebe had to catch a plane to go to San Fransisco.
A number of concerns have been raised about various aspects of the products, but I guess one good thing about showing a demo instead of selling finished product at the booth is that we now have the opportunity to address them before we ship.
So my plan is to use diffie-hellman key exchange to send the key to the FireWire Encrypt.
My client WiebeTech LLC is demonstrating FireWire Encrypt at booth #1651 at the show.
It is a sector-level hard drive encryptor that aims to be very easy to use as well as portable. It uses the Advanced Encryption Standard's Rijndael Algorithm.
It is easy to use because the only software the user needs to install is a simple applet that allows entry of the passphrase. There is no complicated operating system-level software to install or configure.
The encryption implementation itself is entirely contained within a FireWire to IDE bridge.
The FireWire connection also makes the product portable, because FireWire is an external hot-pluggable serial bus.
MacCentral covers the FireWire encrypt
here. You can read WiebeTech's press release about it in Microsoft Word format
here.
I issued a press release (my first ever!) to annouced that I developed the software for WiebeTech. I posted the press release at
http://www.wiebetech.com/press/. Sorry I just have Word format available at the moment, but I will post it in HTML in a little while. I'm tired!
WiebeTech is demonstrating FireWire Encrypt working with Mac OS X at the show, but we plan to support the product on Windows, Linux and classic Mac OS by the time the product is released to the public. (I personally run Slackware on my x86 box and Debian on my PowerPC Macintosh 8500).
In a number of comments so far, Bruce has asked that people register their Open Source books at
Creative Commons.
So I went there to register
The ZooLib Cookbook, but found that they only provide for registration of books licensed under one of the licenses that they themselves publish.
The ZooLib Cookbook is licensed under the GNU Free Documentation License, so I can't register it there. I really don't want to change the license just to register my book.
Bruce, may I suggest you recommend to people that they register at The Assayer instead?
The Assayer also allows readers to post reviews.
And perhaps you could lobby the folks at the creative commons to allow the registration of books on their site that are under other licenses, as long as the licenses are compatible with their aims.
I only have a few chapters written so far, and have a lot of work left to do to complete it, but I have made it my New Year's Resolution to complete it by the end of the year.
To make it more convenient to write, I have used
Fink to install DocBook, OpenJade and psgml on my iBook. (Note - fink's psgml is in unstable).
ZooLib is a multithreaded C++ cross-platform application framework. You can write a single set of sources and compile native applications for Mac OS (classic, 68k and OS X native), Windows, BeOS and Linux, with very little need for platform-specific client code.
ZooLib itself is fairly portable, it could be brought to a completely new platform in a few weeks of work by someone experienced with it.
So you see I write about all kinds of things. I've never had much luck at writing fiction or poetry though.
The wonderful thing about the web is that just anyone can publish and anyone can read what you write. I get thousands of people reading my writing at my website each month. I think that's just wonderful.
One more - my New Year's Resolution is that by the end of the year I will finish writing
The ZooLib Cookbook.
I prefer programming in C++ because I find it easier to just take responsibility for my memory.
Using reference counting is one big help. And knowing how to write exception safe code is another. Yes, it's a difficult subject, but it is something you can learn.
It may be easier to write leak-free Java than C++, but I suspect that because many Java programmers blithely assume their code can't leak, there may well be more leaky Java programs than C++ ones.
I used to work at a web shop where we used the Enhydra Java application server. Enhydra is pretty well written, but the applications that the company originally developed for it were pretty sad. As a result they had to restart their servlet process every few hours because the JVM ran out of memory!
The article compares loading graphics in BMP format for C++ vs. GIF or JPG format for Java.
It doesn't seem to acknowledge the widespread availability of file format libraries that are suitable for use with C++, such as libjpeg from the
Independent Jpeg Group.
It also repeats the commonly stated claim that Java is free from memory leaks. Nothing could be further from the truth. While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program.
How does Java leak memory? Simple. Just hold references to memory you don't need anymore. Holding a reference to any node in a DOM Tree will prevent the entire tree from being garbage collected. That's an easy way to leak tens of megabytes.
Garbage collection is no substitute for responsible memory management.
It also says that in C++, you have to implement graphics calls by coding to the native API of the OS. It says in Java, you have a portable way to do that.
But that's just bullshit. The article makes no mention of cross-platform application frameworks, a number of which were around before Java was ever dreamed off. If you use ZooLib, for example, to code in C++, you can do everything you want with graphics with no need for platform-specific code. There's lots of other cross-platform frameworks, such as wxWindows and Mozilla, even GTK+.
My earliest memory is from when I was about 2. I remember my mother picking me up from a day care center. She took me to see my father's U.S. Navy ship coming back into port. This was at the base in San Diego, California.
I remember all the men lined up on the ship in their dress whites and the band playing Anchors Aweigh.
This was during the Vietnam War (1966). I don't know whether dad had come back from the war or just a voyage around the Pacific somewhere.
I have spotty memories of being 2 and 3 years old. I can remember continuously starting at about 4 years old. My mother finds it hard to believe that I can remember being so young.
For a while I was into taking panoramic photos, where I set my camera on a tripod and take pictures at angular increments around the vertical (or sometimes horizontal) axis of the camera. I'd stitch them together with Live Picture's PhotoVista.
PhotoVista was meant for making QuickTime VR-like images, where you can scroll the panorama around in a web page using a viewer plugin or Java applet. But I always thought it was cooler to have just a photographic banner.
I have a panorama I took at burning man on
this page. The panorama in that page is quite small so that it will fit on your screen - click it and you'll get a greatly enlarged view where you can see some detail (including the PhotoVista Demo Version watermark!).
I have promised the organizers of Burning Man that I'd give them a hi-res panorama on CD that they can print and hang in their office, but I've never gotten it together to make it for them. I'll try to do that sometime soon.
You can find a few other examples of my photography, art and music
here. I have a lot of stuff on PhotoCD that I mean to put on the site, but again I've been too busy to deal with it. There are several MP3's of my piano compositions though.
I'm not sure if PhotoVista is still published. Live Picture was bought out by MGI Software, who were then themselves purchased by Roxio (the Easy CD Creator people). Roxio has an inexpensive graphics bundle package, but I don't know whether PhotoVista is included. Besides stitching the images, it would handle such things as lens distortion quite nicely.
I have a couple panoramas I took up on the Eiffel Tower that are still waiting to be scanned.
Lots of people are posting comments here wondering why anyone would use a Darwin system and not just regular BSD.
I've been up all night doing some Mac OS X device programming. Entirely from userspace code, using the gdb-based ProjectBuilder GUI debugger to debug it. No lockups and no rebooting (although that can happen by programming the IOKit. But it's less common than with kernel space programming.)
It is quite nice.
You can write device drivers for OS X, but you often don't need to, there are interfaces exported to userspace to allow you to do a lot of stuff.
The userspace interface for OS X' IOKit is based on (ducking) Microsoft COM. I've never heard much that's real positive about COM, but the way it's used here seems to make sense, in that you can instantiate C++ objects that talk to the kernel.
That is, the user code access to the kernel is largely done through C++ class interfaces. There are a few file-based hardware interfaces like in traditional Unix. I think that's mostly for compatibility with legacy code, and you still have to use the IOKit to obtain a file descriptor, rather than opening a file by giving its pathname.
While the kernel is indeed a BSD-derivative on top of Mach, the driver architecture has been completely replaced. In its place is a system of "kernel extensions" whose code is written in C++.
If you want to write a driver that extends an existing driver in some way, you subclass the existing one and add your specialization in the subclass.
Let's see if I can find you some documentation on this...
I think the IOKit driver architecture is a signficant advance over the driver architecture employed by any traditional Unix or Linux kernel. May I timidly suggest that some of them would do well to adopt it.
Of course there is the question of license compatibility between the BSD or GPL and APSL. But you could adopt the architecture by rewriting the code, rather than adopting the actual Darwin source code.
Of course, most Linux hackers aren't into programming C++.
I understand that 80486 chips are still quite popular for embedded applications.
It's not just that the simpler chips are more reliable, but they use less power, generate less heat, cost less and take up less space and don't weigh as much.
I have heard that the ARM chip is the most popular for embedded applications these days, and many of the ARM chips in use are quite tiny, have no cache and run in the 40 Mhz range, like the ARM7TDMI.
68000-based chips from Motorola are also very popular.
And check out uCLinux, a linux port to several microprocessors that run without a memory management unit.
Why bother with an MMU when there's no disk to swap to, and the failure of a user program would mean the failure of the whole system?
That computer has more ram than the embedded device I've spent the last couple of months programming.
Although I have the advantage of having a whopping 64k of ROM. I only have to use the RAM for my data. I would expect that computer also has to store the program binary in the 2k. Overlays, anyone?
Lately I've been finding it worth my time to spend a few hours recoding some functions in order to shave just a few bytes off their stack usage.
Kids these days, assuming everyone's got 128 megabytes for their application. They just don't code 'em like they used to.
You can get the most out of your system if you build a custom kernel. This will also allow you to update your kernel before your distro supplies a new binary, apply bug-fix patches sooner, and support drivers and other features that aren't part of the main kernel distribution.
Slashdot Mirror
Transport of SCSI command descriptor blocks is provided by the Serial Bus 2 protocol (SBP2).
If you configure a Linux system to use firewire storage, you will find that Linux' SCSI is a client of the SBP2 driver, which in turn is a client of the 1394 driver.
SBP2 is more general than SCSI, although that's its most common use. It can also be used to transport IDE commands.
Otherwise what you say is correct. The SCSI part just comes at a higher layer in the protocol stack.
It uses software to allow the user to enter their passphrase from the keyboard. By the time of the expo, I had got the AES encryption working in the FireWire/IDE bridge but had only done the passphrase application for Mac OS X.
I've since got it working for Mac OS 9 (and earlier Mac OS versions). Windows and Linux remain before the product can ship. I don't expect either to be hard to do but they do require some work because they have to do some raw FireWire I/O.
I think it is best that I not comment any beyond this until FireWire Encrypt ships. But I think users will like what they see.
-
http://zoolib.sourceforge.net/
It draws its own widgets, but uses switchable renderers so it maintains the platform look and feel. It uses the Appearance Manager if it is available on the Mac OS. It put the menu bar in the windows on Windows and across the top of the screen on the Mac.It supports Mac OS (68k, PowerPC, classic and Carbon), Win32, BeOS x86 and Linux. It would not be hard to bring it to a totally new platform.
It is in C++, is multithreaded, and provides a complete solution - not just GUI but TCP networking, file I/O, streams and persistent storagge.
If you use it, I suggest you use the version in CVS as a lot of work has been done since the last release. A new release is planned soon.
I have started writing a tutorial called The ZooLib Cookbook.
ZooLib is under the MIT License and the Cookbook is under the GNU Free Documentation License.
ZooLib has actually been around longer than even wxWindows, but it was only placed into open source in the fall of 2000. Among the applications written with it is Knowledge Forum.
I interviewed with Dave Johnson of Working Software, and he asked me if I was part of the Mac developer community.
I replied that I didn't know any others, I was studying Mac programming very much in isolation.
He told me to get a Compuserve account, so I did. It was still expensive, but I managed to afford it by that time because I was working as a programmer.
For a long time I gave out my email address as 72377.623@compuserve.com.
Sorry, I always called them billboards, even at the time.
The reporter is apparently too young to remember that before the Internet was available to the public, there were things called "billboards".
Billboards could be networked in the sense that you could send email or transfer files between them, but it was more like store and forward networking rather than a fully connected net like we have today.
They mention that Colonel Hughes subscribed to The Source. That was a commercial billboard that was around before CompuServe. I guess it went out of business because CompuServe became more popular.
I considered subscribing to the source when I bought an ASCII terminal and 1200 baud modem in 1983, but decided not to because it was exhorbitantly expensive, being charged by the minute of connection time. I couldn't afford that on my college student budget.
The Source was really a big timesharing computer that lots of people logged into, not really a network at all.
I'm pretty sure it took more than ten years for the Internet to have more than a hundred hosts.
Colonel Hughes might have been able to access it if he was still in the military at the time, but it wasn't widely available even to the military.
To illustrate how unavailable the Internet was back then - I got the money to buy that ASCII terminal by working as a summer research assistant for an astronomer at CalTech.
The astronomy department was considering gettings its two VAXen connected to the ARPANet (it wasn't called the Internet yet). I don't mean "two main computers", I mean "two computers" - everyone used vt100 terminal to compute, and took turns at the extraordinarily expensive Grinnel image processing workstations, which had a 512 by 512 resolution and were the size of a refrigerator, mostly consisting of RAM.
Anyway, a couple machine at Tech were already connected to the ARPANet, I believe just the Physics and Computer Science UNIX VAXen.
After quite some heated debate within the department, it was decided that the expense of getting connected to the ARPANet just wasn't worth it. They felt it was a better use of the department's money to invest in research, instrumentation and traditional computing resources.
For example, they bought a third VAX, an 11/750, that was smaller than the two 11/780's we had. It came with a newfangled GUI workstation (that I could never figure out how to use) that was also the subject of much debate, and set the department back $150,000.
It could routinely support a couple dozen simultaneous terminal users. But I don't think it had the computing power of a 33 Mhz 80386 PC.
Mike wrote his first D compiler the normal way until it worked right, then "compressed the source code" to make the interpreter work right.
I saw the source, and it looked just like all those obfuscated C code entries.
I haven't booted BeOS in a while but I'm about to, to hopefully help roll out a new release of ZooLib soon.
I would also like to add support for BeOS PowerPC to ZooLib, but probably won't for this release. It doesn't work with my PowerLogix CPU upgrade, but you can still get Newer Technology CPUs that are supposed to work.
I'm still using the 8500 I used to port Spellswell to the BeOS. I'm typing into it right now in fact. But mostly these days I run Debian on it. I managed to install OS X on it, but it doesn't work too well. For OS X I have an iBook.
I don't recall what Mike's text adventure compiler was called, but what you describe sounds like it.
I have lost touch with Mike over the years.
Unfortunately, his original D compiler was written in BASIC, which he ran interpreted, so compilation was slow. In order to speed up the interpreter, he used the sort of "source code compression" that is illustrated at Chuck's Power Koding - removing any unnecessary spaces, using long source lines and having as few actual lines as possible.
(This kind of ancient interpreter didn't use byte codes - if you looped ten times, you'd parse the loop's source code ten times!)
We suggested that he rewrite his D compiler in D so he could get it to compile faster. He decided to do that, and worked really hard at it but got it working after some time.
As a complication he improved the language, but it meant that his old compiler wouldn't compile the newer kind of D code. I think what he did was make two revisions of the D-written compiler, one written in the old syntax that would understand the new, but could be compiled by the BASIC version and then an update that was written in the new D that could compile itself.
It was a sort of mix of Pascal but with lots of convenient stuff like BASIC string handling mixed in. I don't think the language would have made any computer scientists happy - D was designed to suit Mike's personal style.
He used it at first to write an Adventure-style game (a text adventure) that he and another friend designed.
Later he wrote a text-adventure compiler, where he could write a specification file for a text adventure, process it, and an executable file for a text adventure would be generated.
He didn't have to get a real summer job because he was selling these generated games to game software publishers!
Mike was an amazing programmer. He taught me a lot of what I knew about C and x86 assembly early on.
This was all on 640 kb 8088 DOS PC's that were outfitted with whizzy 10 MB hard drives. The students in the computational physics lab were expected to use the hard drives only during class, and to store their personal files on floppy when we weren't actively working at the PC's.
So his D language compiler would fit on a floppy. The old 5 1/4" inch kind, that really flopped. I think they stored 360kb.
I wonder whether we would all be better off if programmers designed their own personal languages just to suit their own personal styles. Yes, there would be portability problems but wouldn't we be more productive?
I got my own chance to hack a whacky compiler. This was a team effort though and I was just a contributor. Star Sapphire Common Lisp manages to run a complete common lisp environment with MicroEmacs on a 640kb DOS 8088 PC.
The way it does that is by swapping to an 8 MB backing store file. But the 8088 doesn't have an MMU, you say? That's right - we operated the virtual memory manually, by writing C code that would explicitly get or put each lisp cons from or into the VM system with a function call.
It made it ... interesting ... to operate on complicated data structures. I designed the implementation of the lisp scoping rules, among other things.
Oh yeah, and I was the source code control system and project manager. We didn't have a network - networks were way too expensive in 1986. What I did was wait until late when all the other programmers went home, copy the changes off all their machines onto floppy, integrate them on one machine and then copy the new release onto everyone's PC.
Kids these days. Don't know when ya got it good.
FireWire Encrypt was a suprisingly difficult product to implement, and I was working on the show demo right up until the morning that James Wiebe had to catch a plane to go to San Fransisco.
A number of concerns have been raised about various aspects of the products, but I guess one good thing about showing a demo instead of selling finished product at the booth is that we now have the opportunity to address them before we ship.
So my plan is to use diffie-hellman key exchange to send the key to the FireWire Encrypt.
-
MacObserver
-
MacBuyersGuide
WiebeTech also now supports ATA-6 (large IDE drives) in its FireWire bridge product line.(WiebeTech is my consulting client. I did the firmware and user interface for FireWire Encrypt).
It is a sector-level hard drive encryptor that aims to be very easy to use as well as portable. It uses the Advanced Encryption Standard's Rijndael Algorithm.
It is easy to use because the only software the user needs to install is a simple applet that allows entry of the passphrase. There is no complicated operating system-level software to install or configure.
The encryption implementation itself is entirely contained within a FireWire to IDE bridge.
The FireWire connection also makes the product portable, because FireWire is an external hot-pluggable serial bus.
MacCentral covers the FireWire encrypt here. You can read WiebeTech's press release about it in Microsoft Word format here.
I issued a press release (my first ever!) to annouced that I developed the software for WiebeTech. I posted the press release at http://www.wiebetech.com/press/. Sorry I just have Word format available at the moment, but I will post it in HTML in a little while. I'm tired!
I have more technical details on the product in my Kuro5hin diary.
WiebeTech is demonstrating FireWire Encrypt working with Mac OS X at the show, but we plan to support the product on Windows, Linux and classic Mac OS by the time the product is released to the public. (I personally run Slackware on my x86 box and Debian on my PowerPC Macintosh 8500).
Thank you for your attention.
So I went there to register The ZooLib Cookbook, but found that they only provide for registration of books licensed under one of the licenses that they themselves publish.
The ZooLib Cookbook is licensed under the GNU Free Documentation License, so I can't register it there. I really don't want to change the license just to register my book.
Bruce, may I suggest you recommend to people that they register at The Assayer instead?
The Assayer also allows readers to post reviews.
And perhaps you could lobby the folks at the creative commons to allow the registration of books on their site that are under other licenses, as long as the licenses are compatible with their aims.
I only have a few chapters written so far, and have a lot of work left to do to complete it, but I have made it my New Year's Resolution to complete it by the end of the year.
To make it more convenient to write, I have used Fink to install DocBook, OpenJade and psgml on my iBook. (Note - fink's psgml is in unstable).
ZooLib is a multithreaded C++ cross-platform application framework. You can write a single set of sources and compile native applications for Mac OS (classic, 68k and OS X native), Windows, BeOS and Linux, with very little need for platform-specific client code.
ZooLib itself is fairly portable, it could be brought to a completely new platform in a few weeks of work by someone experienced with it.
A brief introduction to ZooLib is on it's homepage at http://zoolib.sourceforge.net/.
Thank you for your attention.
I started out wanting to be a scientist. Then I became a programmer, which I've been doing for fifteen years.
But I got into writing I think mainly by writing email and usenet posts, and more recently web pages.
Here are a few of the things I have written:
-
Is This the America I Love?
-
Why I Write
-
Pointers, References and Values
So you see I write about all kinds of things. I've never had much luck at writing fiction or poetry though.The wonderful thing about the web is that just anyone can publish and anyone can read what you write. I get thousands of people reading my writing at my website each month. I think that's just wonderful.
One more - my New Year's Resolution is that by the end of the year I will finish writing The ZooLib Cookbook.
Using reference counting is one big help. And knowing how to write exception safe code is another. Yes, it's a difficult subject, but it is something you can learn.
It may be easier to write leak-free Java than C++, but I suspect that because many Java programmers blithely assume their code can't leak, there may well be more leaky Java programs than C++ ones.
I used to work at a web shop where we used the Enhydra Java application server. Enhydra is pretty well written, but the applications that the company originally developed for it were pretty sad. As a result they had to restart their servlet process every few hours because the JVM ran out of memory!
It doesn't seem to acknowledge the widespread availability of file format libraries that are suitable for use with C++, such as libjpeg from the Independent Jpeg Group.
It also repeats the commonly stated claim that Java is free from memory leaks. Nothing could be further from the truth. While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program.
How does Java leak memory? Simple. Just hold references to memory you don't need anymore. Holding a reference to any node in a DOM Tree will prevent the entire tree from being garbage collected. That's an easy way to leak tens of megabytes.
Garbage collection is no substitute for responsible memory management.
It also says that in C++, you have to implement graphics calls by coding to the native API of the OS. It says in Java, you have a portable way to do that.
But that's just bullshit. The article makes no mention of cross-platform application frameworks, a number of which were around before Java was ever dreamed off. If you use ZooLib, for example, to code in C++, you can do everything you want with graphics with no need for platform-specific code. There's lots of other cross-platform frameworks, such as wxWindows and Mozilla, even GTK+.
I remember all the men lined up on the ship in their dress whites and the band playing Anchors Aweigh.
This was during the Vietnam War (1966). I don't know whether dad had come back from the war or just a voyage around the Pacific somewhere.
I have spotty memories of being 2 and 3 years old. I can remember continuously starting at about 4 years old. My mother finds it hard to believe that I can remember being so young.
PhotoVista was meant for making QuickTime VR-like images, where you can scroll the panorama around in a web page using a viewer plugin or Java applet. But I always thought it was cooler to have just a photographic banner.
I have a panorama I took at burning man on this page. The panorama in that page is quite small so that it will fit on your screen - click it and you'll get a greatly enlarged view where you can see some detail (including the PhotoVista Demo Version watermark!).
I have promised the organizers of Burning Man that I'd give them a hi-res panorama on CD that they can print and hang in their office, but I've never gotten it together to make it for them. I'll try to do that sometime soon.
You can find a few other examples of my photography, art and music here. I have a lot of stuff on PhotoCD that I mean to put on the site, but again I've been too busy to deal with it. There are several MP3's of my piano compositions though.
I'm not sure if PhotoVista is still published. Live Picture was bought out by MGI Software, who were then themselves purchased by Roxio (the Easy CD Creator people). Roxio has an inexpensive graphics bundle package, but I don't know whether PhotoVista is included. Besides stitching the images, it would handle such things as lens distortion quite nicely.
I have a couple panoramas I took up on the Eiffel Tower that are still waiting to be scanned.
I've been up all night doing some Mac OS X device programming. Entirely from userspace code, using the gdb-based ProjectBuilder GUI debugger to debug it. No lockups and no rebooting (although that can happen by programming the IOKit. But it's less common than with kernel space programming.)
It is quite nice.
You can write device drivers for OS X, but you often don't need to, there are interfaces exported to userspace to allow you to do a lot of stuff.
The userspace interface for OS X' IOKit is based on (ducking) Microsoft COM. I've never heard much that's real positive about COM, but the way it's used here seems to make sense, in that you can instantiate C++ objects that talk to the kernel.
That is, the user code access to the kernel is largely done through C++ class interfaces. There are a few file-based hardware interfaces like in traditional Unix. I think that's mostly for compatibility with legacy code, and you still have to use the IOKit to obtain a file descriptor, rather than opening a file by giving its pathname.
While the kernel is indeed a BSD-derivative on top of Mach, the driver architecture has been completely replaced. In its place is a system of "kernel extensions" whose code is written in C++.
If you want to write a driver that extends an existing driver in some way, you subclass the existing one and add your specialization in the subclass.
Let's see if I can find you some documentation on this...
-
kernel extensions tutorials
-
IOKit Fundamentals
-
Writing an IOKit Device Driver
-
Accessing Hardware from Applications (that is, from userspace)
I think the IOKit driver architecture is a signficant advance over the driver architecture employed by any traditional Unix or Linux kernel. May I timidly suggest that some of them would do well to adopt it.Of course there is the question of license compatibility between the BSD or GPL and APSL. But you could adopt the architecture by rewriting the code, rather than adopting the actual Darwin source code.
Of course, most Linux hackers aren't into programming C++.
The Linux kernel has support for a variety of hardware watchdog devices you can use on PC's.
It's not just that the simpler chips are more reliable, but they use less power, generate less heat, cost less and take up less space and don't weigh as much.
I have heard that the ARM chip is the most popular for embedded applications these days, and many of the ARM chips in use are quite tiny, have no cache and run in the 40 Mhz range, like the ARM7TDMI.
68000-based chips from Motorola are also very popular.
And check out uCLinux, a linux port to several microprocessors that run without a memory management unit.
Why bother with an MMU when there's no disk to swap to, and the failure of a user program would mean the failure of the whole system?
When I'm at my wittiest, she just sort of rolls her eyes, groans, and goes back to whatever she was doing.
My wife, on the other hand, has heard quite enough of them from me.
Although I have the advantage of having a whopping 64k of ROM. I only have to use the RAM for my data. I would expect that computer also has to store the program binary in the 2k. Overlays, anyone?
Lately I've been finding it worth my time to spend a few hours recoding some functions in order to shave just a few bytes off their stack usage.
Kids these days, assuming everyone's got 128 megabytes for their application. They just don't code 'em like they used to.
My article Why We Should All Test the New Linux Kernel gives some tips on how to get started building new kernels (although it emphasizes testing the development patches).
The #kernelnewbies IRC channel has a website at www.kernelnewbies.org that you will find helpful.
And finally there is of course The Linux Kernel HOWTO.