Please put in the sockets and signals that Qt implement? Those are damn nice.
I like the libsigc-- ones better, far more runtime checking, adaptors, and I think they are even faster. OSS license, and avail. on sourceforge. They are not GTK+ specific, even though it was originally designed for use there.
That isn't surprising at all. The C runtime is very straight forward (except for setjump/longjump). It is pretty clear how things can/should be implemented. C++ does a lot more for you, and it is unclear how they might do it (either because it's hard to guess how anyone might do it, or it's just hard to guess how this one compiler does it).
(the STL's "runtime complexity" requirements is a good start, but it is just big O, the constants can still kill you)
I don't think you will find a higher level language then C with a simpler to guess performance model (unless the model is "everything written in Tcl is slow"). I mean for all Eiffel's wonderful features, or Modula-3's, I don't think looking at two functions and guessing which is faster is among them.
I can't think of any high level language has a simpler runtime then C. That is both high complement, and damnation.
Umm, my major problem with C++ is execution time. I try and write as little as possible in C++, sticking mainly to C and Perl for anything which needs to execute quickly.
Some things in C++ are quite slow, but no slower then simulating them in C. Faster in many cases. The C++ STL sort function seems to be about an order of magnitude faster then C's qsort (operating on char, short, and int's).
In fact the STL in general is quite fast, normally faster then the C equivalent (when one exists), definitely faster then what one would whip up in an hour.
C++'s virtual functions are slow. Quite slow. But faster then C calling through a pointer. Sometimes insanely faster because the C++ compiler can actually tell what type the pointer will be at run time. C can almost never tell.
If the only thing you care about is execution speed, use C++. Use the STL. Use C's I/O. Avoid virtual functions, except when you would have used a function pointer before.
I'm going to ignore the bit where you think Perl makes faster code then C++ (I do admit it could in some cases, but not normally).
This is not to say that I think C++ is a wonderful language. I rather dislike it. I love the STL. Everything else in C++ seems to have been done better elsewhere. Still the language has value, if only because of the wide availability.
The i860 was widely used for embedded applications. It's successor, the i960, is still available for Intelligent I/O (I2O) usage.
The i960 was out a fair number of years before the i860. The i860 was a floating point monster for it's day (and the first superscaler I ever used). Oki tried to sell a line of workstations based on it. In fact I think they sold well to NTT, but they didn't sell well in the USA. The only embedded use I know of was in SGI's Reality Engine as geometry engines.
plus a couple hundred for the photographer since they usually cost more than the girls
I wonder why. A lot of places seem to have over exposed (as in too much light) photos because cameras left in matrix meter mode on that much untanned flesh tends to meter wrong. Anyone who has photographed nudes in an art class could do better.
Plus they seldom use the rule of thirds, or set the shutter time to pick up motion.
Otherwise I'd be severely disappointed, but I'm sure you meant multiprocessor.
Both. Getting a multiprocessor kernel to boot is a pain. Getting it to do fsck and some other I/O is a pain. Getting it to run all the other userland boot code isn't so hard (once the I/O works). Going to multiuser mode isn't really hard, but then the network services start up and having anyone poke at them can be a chore. Having a user actually login and run crap is also another level of pain.
Mac users not liking OS X has nothing to do with Unix. On a consumer level, the OS isn't Unix at all, unless you want it to be.
I'll admit they mostly don't. A few complain about not being able to change all the files and stuff. Many complain about the slowness, which I assume has something to do with it being run on top of Unix and not retuned enough. Well that, and Objective C's late binding:-)
Most just don't care for the new finder and look n' feel, and yeah that has nothing to do with Unix.
The launch of Mac OS X is turning Apple into the largest distributor of Unix, and more specifically BSD Unix. Now anyone with a desire to run Unix can purchase it for about the same cost as a Microsoft operating system. For the regular user, it looks and acts just like a MacOS user would expect.
No it doesn't. Go to MacNN and see how many Mac users find it quite different. Not all of them dislike it. Many like the changes. Many do not. Look at the threads on making the Finder more "Mac like", or even for running the old OS9 Finder. Look at Apple's own movies of how different OSX is. Or head back to MacNN and watch them bitch about how much worse the Dock is then the application bar.
Now I like OSX, but I'm not a Mac user. I'm a Unix geek. I bought a Mac to run OSX, and I can tell you it feels totally different, to the point that OS9 apps that run under Classic "emulation" are jarring.
With the PDQ 6035 you can also use the voice memo feature to record -both sides- of a conversation.
That's pretty cool. My Samsung SCH 3500 has a record feature as well, but I never tryed it (except for memos which it does when you are not on a call).
I do recall the instructions saying it may be illegal to use it in some states though (some states require both parties in a phone conservation to agree to recording, other require only one).
As always, I'm not a lawyer, so don't rely on me for legal advice.
Consider PCI: There is no spec for what the bootrom of the card will contain. Usually, it contains only Intel x86 real mode code. The prevents the card from being used as-is in anything else: Your Alpha, your iMac, your Sun, all are out of luck when you plug this card in (unless they have x86 emulators to run the boot code.)
There is definitely a spec. You can have x86 code in the ROM (for "compatibility"), or OpenFirmware. Which is exactly what you wanted.
The big problem is nobody is required to do a OF boot ROM, and the even bigger problem is not with the cards, but BIOSes which don't support OpenFirmware. So rather then having the choice of doing x86 which only works on 95% of the market, or OpenFirmware which works on 100%, card makers have the choice of 5% or 95%. Most of them choose the 95% one, and sometimes make a second boot ROM "for Macintosh" (it'll work on PCI SPARCs and the like though).
I think the PCI spec even lets you have both ROM images at once, but nobody seems to do it, so there may be a problem with that.
Still, for a primarallrly Intel spec it was a good start.
Apple figured this out long ago when they came up with NuBus. Plug and Play is a crock of shit. It always breaks sooner or later.
TI did NuBus (I think), but the idea of a geographically addressed bus isn't new. I seem to recall the Apple II bus working that way (but I'm not sure, I never owned one). EISA (I think) does as well. Some of the very old DEC busses did.
The problem is if you don't assign enough space to a device you end up being forced to page flip and do other unplesent things. If the bus had been designed in 1990 people would have looked at existing cards and decided 16M was far more then anything needed (1M was about as much as any PC video card of the era had). Now your Nvida card with 64M VRAM (or SGRAM or whatever) would be really painful to access. If you assign too much space you cramp either the amount of RAM that can be used, or the number of expansion cards you can have.
At the very least, add a feature to the BIOS to let the user choose plug'n'play or manually assign resources to SPECIFIC SLOTS so that from the card's point of view, it has ONLY those resources to choose from.
Some BIOSes did this, back when there was a mix of PnP and non PnP cards in most systems it was really useful. I haven't had a problem in years though, so I'm not gonna put this high on my list of stuff I want to change in the world.
The analogies of the PDA to the PCs (and laptops) of 10 to 15 years continues, both in terms of clock speed and ram. The only major differance is the apparent lack of storage space (maybe I didn't look hard enough) conpared to the old PCs.
It has a compact flash slot. A 32M (Lexar) Compact Flash is under $100 from my local computer store. Let's see 15 years ago, in 1986... I owned a 512K 8Mhz 68000 Atari ST. During 86 I saved up for a whole summer, and finally my dad gave me an extra $200 and I bought a $650 20MEG hard drive (it was a SCSI drive with a SCSI to ATSI converter).
So I would say they aren't too far off on mass storage. Of corse I think the more expensive Macs of the era came with hard disks, same with the PCs. Programs were still pretty small, most fit one one or at least a few floppy disks.
The problem with a combination phone and PDA is that half the time when I want to write something down, someone's telling it to me over the phone. I don't want to have to take someone's address and phone number down by pulling the phone away from my ear every few numbers...
The Qualcomm PDQ has that problem, I expect a lot of people use the little headsets. The Visor Phone (I forget the real name) requires (I think) use of a headset.
Regrettably the headsets are either too bulky to carry (the ones with a mic boom), or don't sound that great (ones like Jabrea's with the in-ear mic). Both kinds are uncomfortable to me, and both take time to put on. They also seem to do worse in a noisy environment (a convertible with the top down).
Also, I would be very reluctant to loan (or borrow!) a phone where the head set was the only thing that worked.
Re:To whom? Re:Another Benefit of Free software.
on
Eazel On The Ropes
·
· Score: 2
I understand your argument completely, and it is a very valid one, but one may argue that it is this specific 'benefit' of Free Software (giving away your program open-source for free) that might make them go under. So it is a benefit to whom? Not to poor eazel I think...
It isn't a benefit that they go under. I'm not sure that doing free software makes you go under any more or less often the closed software.
The benefit is as a user of open source software you aren't totally screwed if the vender goes bankrupt. It may be hard to find support, but if you are willing to pay enough, it can be had. The benefit an OSS vender has is they can go in and tell potential customers that in the off chance that they don't make it, the customer is safe.
If you had your choice of two small bisnesses that made exactly the product you needed, and one was OSS and one wasn't, you should pick the OSS one because even if they go bankrupt you can still get some support. If there is one small OSS bisness and one huge closed source one, then it might work out different (like based on the quality of the existing code, or how you think the future will play out, or prices, or...).
if we didn't have censorware, a large portion of the students would be spending the majority of their "research" time on playboy.com and porn and all sorts of things that are not at all related to what they are supposed to be doing.
I think part of the point is that with censorware they may not go to playboy.com, but they can still got to genitalhospital.com, or a few thousand other porn sites, while you are blocked from some ligitmate research sites because they have the word breast, or are hosted on the same megaserver as some porn site, or promote abortion (making it harder to research Roe v. Wade)...
It still is. If you go into a UUNET HUB and unplug a GW nothing happens (well after routing converges again). Same if you take out a TR, or XR, I forget the difference. Other big ISPs are similar.
And if you look at the older way it was redundant, take out a long haul link and things route around, well it still works, take out a long haul link and traffic flows along the ones that still exist (even if they are a very different path).
What isn't redundant? Your link to the ISP probably isn't. The router you land on at the ISP's hub probably isn't. With enough money you can buy two links, better yet to two different ISPs. Most ISPs don't have more then two exit routers per hub, so if both go you are screwed. Some hubs only have two exits. I expect some ISPs aren't even that good, but you do get what you pay for. Don't buy connectivity from a cut rate provider and complain that they aren't redundant. What else? Well whoever you want to talk too might not have redundant connections. Sometimes a whole ISP can do something that screws them (load a Cisco or Juniper code release that has a bad bug that didn't show up in their or your testing...or screw up your L2 fabric or...), but the other ISPs are still alive and kicking. They can all talk to each other if while you are dead (unless they don't really have a backbone, but just wholesale for the dead ISP, and only the dead ISP, but again you get what you pay for)
With your argument, because some guy in an SUV cut you off, or a granny in a buick is driving 10 under the speed limit in the left hand freeway lane, it makes all cars bad, and you won't drive them.
Of corse not! It just means I won't drive a SUV or Buick!
Hopefully he comes out Ok. I mean I have never met him, but anyone that makes something as cool as photo.net is allright in my book. Plus he seems pretty cool from what I can tell by reading his tutorials and such...
Oh, I have one (probably more then one). I also know that a few bugs linger after any testing and are only found in real life use. I had one bug stand five years of daily use. It took three years to show up the first time, two more to get enough debug info, and then I fixed it in half an hour.
Or maybe I just don't want to go back to an unprotected environment after so many years of using them...
with a Linux PDA you could do all sorts of things. You could run various server daemons, code, browse the web, etc, but why?
Well, the one big advantage of Linux would be the new shareware scratchpad scribbling thing couldn't accidentally overwrite my calendar or memo pad info. PalmOS has pretty much no memory protection. Not only no protection, but everything that would normally be stored on the hard drive is sitting around unprotected in RAM (except the small amount in FLASH or ROM).
That's the main reason I haven't written any PalmOS apps. Sure it would be great to have a custom darkroom timer, but it's more important to me that the whole thing not go up in smoke.
Does AMD's 64-bit path have any mindshare at all in comparison with Intels?
Not nearly as much as far as I can tell. Then again it doesn't need as much.
To run IA64 code you need a IA64 OS. To run 64 bit AMD code you need a minor change to the context switching code (you need to save 64 bits of data per GPR, and twice as many GPRs). Of corse you need more OS support for a 64 bit address space.
To produce good code for the IA64 you need some extremely advanced compiler technology. Unrolling loops isn't enough, you have to modulo schedule them. Good AMD64 code is hardly different from normal x86 code.
Now there are IA64 OSes, and at least a compiler or two. Intel did get something for their hype machine efforts, and for having some machines around for people to test on. I don't think the AMD 64 bit stuff is as far along, but it won't take long to catch up.
Besides a lot of the IA64 mind share is folks calling it the "iTanic", AMD may not want that kind of mind share:-)
AMD spends their R&D budget trying to emulate Intel. Intel spends their R&D budget working on new stuff.
I don't think anything in the IA64 is as useful as SMT (as seen in the next gen Alpha, and rumored to be in the next IBM Power CPU). Pretty much everything in the IA64 has been seen before BTW. I do admit it is more innovative then the 64 bit AMD CPU though, but not all innovations are worth the price of buy in...
Of corse two years ago I felt differently about the IA64 (and I have a stack of IA64 docs to show for it), and in two years I may change my mind again...
I'm so tired of getting really worked up about the Itsy here on/. only to discover that they're STILL NOT MAKING IT AVAILABLE TO THE GENERAL PUBLIC!
I used one at a Usenix wrap party, or maybe one of the other parties that happen at Usenix. It was fast enough (it wasn't lightning fast though). The display was nice enough. The rock n' scroll was very cool. But it was heavy. For a PDA not noticeably larger then a Palm Pilot it felt like it was at least four times as heavy. It would never ever be comfortable in a shirt pocket. It wouldn't even be as unobtrusive in pants pocket. I wouldn't use it as a PDA just because I wouldn't carry it around.
Of corse if you were to spin a new design of it it couldn't help but get lighter...
Slashdot Mirror
I like the libsigc-- ones better, far more runtime checking, adaptors, and I think they are even faster. OSS license, and avail. on sourceforge. They are not GTK+ specific, even though it was originally designed for use there.
That isn't surprising at all. The C runtime is very straight forward (except for setjump/longjump). It is pretty clear how things can/should be implemented. C++ does a lot more for you, and it is unclear how they might do it (either because it's hard to guess how anyone might do it, or it's just hard to guess how this one compiler does it).
(the STL's "runtime complexity" requirements is a good start, but it is just big O, the constants can still kill you)
I don't think you will find a higher level language then C with a simpler to guess performance model (unless the model is "everything written in Tcl is slow"). I mean for all Eiffel's wonderful features, or Modula-3's, I don't think looking at two functions and guessing which is faster is among them.
I can't think of any high level language has a simpler runtime then C. That is both high complement, and damnation.
No "it" was "Java", of corse C++ can do generics as well as the STL, the STL is just normal C++ code. (well better designed then most, but still...)
Well garbage collection alone is a pretty big step towards higher level. Now if it could just do generic algorithms as well as the STL....
Some things in C++ are quite slow, but no slower then simulating them in C. Faster in many cases. The C++ STL sort function seems to be about an order of magnitude faster then C's qsort (operating on char, short, and int's).
In fact the STL in general is quite fast, normally faster then the C equivalent (when one exists), definitely faster then what one would whip up in an hour.
C++'s virtual functions are slow. Quite slow. But faster then C calling through a pointer. Sometimes insanely faster because the C++ compiler can actually tell what type the pointer will be at run time. C can almost never tell.
If the only thing you care about is execution speed, use C++. Use the STL. Use C's I/O. Avoid virtual functions, except when you would have used a function pointer before.
I'm going to ignore the bit where you think Perl makes faster code then C++ (I do admit it could in some cases, but not normally).
This is not to say that I think C++ is a wonderful language. I rather dislike it. I love the STL. Everything else in C++ seems to have been done better elsewhere. Still the language has value, if only because of the wide availability.
The i960 was out a fair number of years before the i860. The i860 was a floating point monster for it's day (and the first superscaler I ever used). Oki tried to sell a line of workstations based on it. In fact I think they sold well to NTT, but they didn't sell well in the USA. The only embedded use I know of was in SGI's Reality Engine as geometry engines.
I had two in my office for about a year.
I wonder why. A lot of places seem to have over exposed (as in too much light) photos because cameras left in matrix meter mode on that much untanned flesh tends to meter wrong. Anyone who has photographed nudes in an art class could do better.
Plus they seldom use the rule of thirds, or set the shutter time to pick up motion.
I could do a better job. Hey, where do I sign up?
Both. Getting a multiprocessor kernel to boot is a pain. Getting it to do fsck and some other I/O is a pain. Getting it to run all the other userland boot code isn't so hard (once the I/O works). Going to multiuser mode isn't really hard, but then the network services start up and having anyone poke at them can be a chore. Having a user actually login and run crap is also another level of pain.
I think past that is an actual release :-)
I'll admit they mostly don't. A few complain about not being able to change all the files and stuff. Many complain about the slowness, which I assume has something to do with it being run on top of Unix and not retuned enough. Well that, and Objective C's late binding :-)
Most just don't care for the new finder and look n' feel, and yeah that has nothing to do with Unix.
No it doesn't. Go to MacNN and see how many Mac users find it quite different. Not all of them dislike it. Many like the changes. Many do not. Look at the threads on making the Finder more "Mac like", or even for running the old OS9 Finder. Look at Apple's own movies of how different OSX is. Or head back to MacNN and watch them bitch about how much worse the Dock is then the application bar.
Now I like OSX, but I'm not a Mac user. I'm a Unix geek. I bought a Mac to run OSX, and I can tell you it feels totally different, to the point that OS9 apps that run under Classic "emulation" are jarring.
That's pretty cool. My Samsung SCH 3500 has a record feature as well, but I never tryed it (except for memos which it does when you are not on a call).
I do recall the instructions saying it may be illegal to use it in some states though (some states require both parties in a phone conservation to agree to recording, other require only one).
As always, I'm not a lawyer, so don't rely on me for legal advice.
There is definitely a spec. You can have x86 code in the ROM (for "compatibility"), or OpenFirmware. Which is exactly what you wanted.
The big problem is nobody is required to do a OF boot ROM, and the even bigger problem is not with the cards, but BIOSes which don't support OpenFirmware. So rather then having the choice of doing x86 which only works on 95% of the market, or OpenFirmware which works on 100%, card makers have the choice of 5% or 95%. Most of them choose the 95% one, and sometimes make a second boot ROM "for Macintosh" (it'll work on PCI SPARCs and the like though).
I think the PCI spec even lets you have both ROM images at once, but nobody seems to do it, so there may be a problem with that.
Still, for a primarallrly Intel spec it was a good start.
TI did NuBus (I think), but the idea of a geographically addressed bus isn't new. I seem to recall the Apple II bus working that way (but I'm not sure, I never owned one). EISA (I think) does as well. Some of the very old DEC busses did.
The problem is if you don't assign enough space to a device you end up being forced to page flip and do other unplesent things. If the bus had been designed in 1990 people would have looked at existing cards and decided 16M was far more then anything needed (1M was about as much as any PC video card of the era had). Now your Nvida card with 64M VRAM (or SGRAM or whatever) would be really painful to access. If you assign too much space you cramp either the amount of RAM that can be used, or the number of expansion cards you can have.
Some BIOSes did this, back when there was a mix of PnP and non PnP cards in most systems it was really useful. I haven't had a problem in years though, so I'm not gonna put this high on my list of stuff I want to change in the world.
It has a compact flash slot. A 32M (Lexar) Compact Flash is under $100 from my local computer store. Let's see 15 years ago, in 1986... I owned a 512K 8Mhz 68000 Atari ST. During 86 I saved up for a whole summer, and finally my dad gave me an extra $200 and I bought a $650 20MEG hard drive (it was a SCSI drive with a SCSI to ATSI converter).
So I would say they aren't too far off on mass storage. Of corse I think the more expensive Macs of the era came with hard disks, same with the PCs. Programs were still pretty small, most fit one one or at least a few floppy disks.
Displays are still a bit behind though.
The Qualcomm PDQ has that problem, I expect a lot of people use the little headsets. The Visor Phone (I forget the real name) requires (I think) use of a headset.
Regrettably the headsets are either too bulky to carry (the ones with a mic boom), or don't sound that great (ones like Jabrea's with the in-ear mic). Both kinds are uncomfortable to me, and both take time to put on. They also seem to do worse in a noisy environment (a convertible with the top down).
Also, I would be very reluctant to loan (or borrow!) a phone where the head set was the only thing that worked.
It isn't a benefit that they go under. I'm not sure that doing free software makes you go under any more or less often the closed software.
The benefit is as a user of open source software you aren't totally screwed if the vender goes bankrupt. It may be hard to find support, but if you are willing to pay enough, it can be had. The benefit an OSS vender has is they can go in and tell potential customers that in the off chance that they don't make it, the customer is safe.
If you had your choice of two small bisnesses that made exactly the product you needed, and one was OSS and one wasn't, you should pick the OSS one because even if they go bankrupt you can still get some support. If there is one small OSS bisness and one huge closed source one, then it might work out different (like based on the quality of the existing code, or how you think the future will play out, or prices, or...).
I think part of the point is that with censorware they may not go to playboy.com, but they can still got to genitalhospital.com, or a few thousand other porn sites, while you are blocked from some ligitmate research sites because they have the word breast, or are hosted on the same megaserver as some porn site, or promote abortion (making it harder to research Roe v. Wade)...
It still is. If you go into a UUNET HUB and unplug a GW nothing happens (well after routing converges again). Same if you take out a TR, or XR, I forget the difference. Other big ISPs are similar.
And if you look at the older way it was redundant, take out a long haul link and things route around, well it still works, take out a long haul link and traffic flows along the ones that still exist (even if they are a very different path).
What isn't redundant? Your link to the ISP probably isn't. The router you land on at the ISP's hub probably isn't. With enough money you can buy two links, better yet to two different ISPs. Most ISPs don't have more then two exit routers per hub, so if both go you are screwed. Some hubs only have two exits. I expect some ISPs aren't even that good, but you do get what you pay for. Don't buy connectivity from a cut rate provider and complain that they aren't redundant. What else? Well whoever you want to talk too might not have redundant connections. Sometimes a whole ISP can do something that screws them (load a Cisco or Juniper code release that has a bad bug that didn't show up in their or your testing...or screw up your L2 fabric or...), but the other ISPs are still alive and kicking. They can all talk to each other if while you are dead (unless they don't really have a backbone, but just wholesale for the dead ISP, and only the dead ISP, but again you get what you pay for)
Still, that's not too bad.
Did you expect it to be better?
Of corse not! It just means I won't drive a SUV or Buick!
Hopefully he comes out Ok. I mean I have never met him, but anyone that makes something as cool as photo.net is allright in my book. Plus he seems pretty cool from what I can tell by reading his tutorials and such...
The part I thought was optimistic was the press release where they promised to have a fix available at least 30,000 years in advance.
Oh, I have one (probably more then one). I also know that a few bugs linger after any testing and are only found in real life use. I had one bug stand five years of daily use. It took three years to show up the first time, two more to get enough debug info, and then I fixed it in half an hour.
Or maybe I just don't want to go back to an unprotected environment after so many years of using them...
Well, the one big advantage of Linux would be the new shareware scratchpad scribbling thing couldn't accidentally overwrite my calendar or memo pad info. PalmOS has pretty much no memory protection. Not only no protection, but everything that would normally be stored on the hard drive is sitting around unprotected in RAM (except the small amount in FLASH or ROM).
That's the main reason I haven't written any PalmOS apps. Sure it would be great to have a custom darkroom timer, but it's more important to me that the whole thing not go up in smoke.
Not nearly as much as far as I can tell. Then again it doesn't need as much.
To run IA64 code you need a IA64 OS. To run 64 bit AMD code you need a minor change to the context switching code (you need to save 64 bits of data per GPR, and twice as many GPRs). Of corse you need more OS support for a 64 bit address space.
To produce good code for the IA64 you need some extremely advanced compiler technology. Unrolling loops isn't enough, you have to modulo schedule them. Good AMD64 code is hardly different from normal x86 code.
Now there are IA64 OSes, and at least a compiler or two. Intel did get something for their hype machine efforts, and for having some machines around for people to test on. I don't think the AMD 64 bit stuff is as far along, but it won't take long to catch up.
Besides a lot of the IA64 mind share is folks calling it the "iTanic", AMD may not want that kind of mind share :-)
I don't think anything in the IA64 is as useful as SMT (as seen in the next gen Alpha, and rumored to be in the next IBM Power CPU). Pretty much everything in the IA64 has been seen before BTW. I do admit it is more innovative then the 64 bit AMD CPU though, but not all innovations are worth the price of buy in...
Of corse two years ago I felt differently about the IA64 (and I have a stack of IA64 docs to show for it), and in two years I may change my mind again...
I used one at a Usenix wrap party, or maybe one of the other parties that happen at Usenix. It was fast enough (it wasn't lightning fast though). The display was nice enough. The rock n' scroll was very cool. But it was heavy. For a PDA not noticeably larger then a Palm Pilot it felt like it was at least four times as heavy. It would never ever be comfortable in a shirt pocket. It wouldn't even be as unobtrusive in pants pocket. I wouldn't use it as a PDA just because I wouldn't carry it around.
Of corse if you were to spin a new design of it it couldn't help but get lighter...