I'm a huge DS9 fan, but I find this really tough to swallow.
Babylon 5 had a heavy story arc. Later, Deep Space 9 developed a story arc.
So did TNG. Remember the Klingons? That was spread out over several years.
Babylon 5 used CGI heavily when Trek was using models. Of course Trek now uses CGI; perhaps that one was inevitable, but they probably adopted it sooner because of the example of Babylon 5.
Technology increases at the speed that it is researched.
After Babylon 5, JMS had a short-lived series called Crusade. The ship in Crusade had a limited amount of time to find a cure that would save the lives of all humans on Earth. Now we find out that Enterprise is turning into Crusade -- they will have to go and stop the Xindi super-weapon.
And new hair styles? Given that Babylon 5 was famous for its wild hair styles, I was amazed they were hyping this.
I don't really see "them" hyping this, rather reporters and Slashdot. I saw "them" casually mention it. And why shouldn't they?
All that said -- I'll try to hope. Stopping a superweapon is closer to "Trek with phasers" than preachy episodes like "Cogenitor". I'd like to see it be fun and exciting, with far less lecturing.
I still need to consider whether I liked or hated Cogenitor, heh. But not that much different than I, Borg or The Outcast for instance. Although Enterprise took a much darker conclusion.
I really think anyone who views Enterprise as that much worse than TNG is relying on nostalgia, rather than the actually TNG episodes. I find Enterprise the most interesting Star Trek series so far by a wide margin (although comparing anything to the granddaddy of them all is apples to lemons).
The source code to Apple's Rendezvous implementation is already available for download. It includes implementations for Windows, Mac OS X, Mac OS 9 (yes, they're different stacks) and Posix.
I've only tried the Windows implementation (I'm only interested in Windows and Mac OS X, and I think it's a safe bet that Mac OS X works). It seemed to work perfectly.
Ultimately, all an emulator does is convert instructions from one architecture to another. It's almost always more efficient to translate instructions in blocks
To come up with a really primitive, simple example, imagine a simple instruction set with a load, add, and branch if zero-set.
Code might look like this:
lda avar
add bvar
bre label
Now imagine we were translating to an instruction set that had mostly the same instructions, but needed a compare instruction to set our conditional flag
Instruction-by-instruction conversion might turn out like this:
lda avar
tstz
add bvar
tstz
bre label
Now if the conversion was done on the entire block, we might end up with this:
lda avar
add bvar
tstz
bre label
Granted, this is a pretty simple example, but I hope it makes my point. Block conversions allow a great deal more optimization than instruction conversions.
This optimization might sound like a lot of work for the host processor, but if the block in question is a tight loop you more than make that up.
It's 3.5MB, and it's just been hit by the slashdot effect. If the administrators don't remove it, Microsoft is apparently willing to subsidize the bandwidth required for thousands to download it.
Asimov's psychohistory was the study of mob mechanics.
Pyschohistory is better explained in the tail of the Robot series and the prequels to the Foundation series than in the "main" Foundation series itself.
I've had speeds that were simply impossible at some times (like immediately after a power failure) with my cable. Expect they happened, and I got them. Cable is consistently faster than anything else.
But my friend who lives 15 minutes away complains of his unreliable and slow connection that the same cable company can't seem to fix despite repeated efforts. He says this was explained as his distance from the major street in the area, which has the line running along it... which just happens to be the street I live on.
Cable can be much faster, or it can be much slower. It can be more reliable, or less. Helpful? No, not really. The only real advice I have for anyone is see which is cheaper, and try that first.
You should really rethink that. A phone in a PDA sounds useful, but the reality is that the form factors are incompatible. What makes a good PDA makes a lousy phone, and vice versa.
A separate phone/PDA that link together with Bluetooth is much more useful.
The requirements for phones and handheld computers are opposed. What makes a good phone makes a crappy handheld, and what makes a good handheld makes a crappy phone. This should be intuitively obvioous, but a great many people miss it: Consider the simple example jotting down a phone number someone it giving you over the phone, for instance. Or consider the size of phone you want to work with, compared with how small you want to write.
Instead, purchase two devices: A handheld and a phone. Make sure both have Bluetooth. This gives you the functionality of a combo device but without profile or multitasking compromises.
I store a lot of reference materials in my Clie. Things like recepie and drink databases. I'd like to store a full dictionary in there, but it's a bit small for that. I've written a program that stores a database of people in RAM. And, of course, I'd like to be able to keep a few pictures in there. My Clie doubles as a (crappy -- it's a older model) digital camera. Add it all up, and I could use about 20 MB of RAM at the moment. With a camera with better resolution, I would need more.
Gigabytes of storage aren't necessary, but I'm glad that we'll see new Palm handhelds go past 16 MB. You needn't worry about battery life suddenly dropping to unusable levels. That has always been a priority to Palm.
The real question is why PalmOS is such a pathetic mess on that kind of hardware. PalmOS gives you the programming experience and APIs of a low-end DOS machine on CPUs that are perfectly capable of running a full UNIX workstation environment.
Pardon me, but I don't think you've ever actually programmed the Palm. The Palm OS SDK is the cleanest SDK I've dealt with. The functions are very logically named and organized. Comparing it to DOS is insane. DOS didn't even really have an API, just a couple interrupts and low mem variables which development tool engineers built runtime libraries over.
A better comparison might be the classic Macintosh SDK, but designed by people who had already experienced the pain that Macintosh APIs grew into. The Palm has opaque objects, logical names, constants for everything, and a really well thought out event/notification model.
The great fault I find with it is the lack of standard C functions -- which makes sense, since you wouldn't want to include even a small subset of it with each Palm application. I've found most of those can be mapped to Palm OS traps with a simple #define, though.
Now, if you're not really talking about the APIs but the lack of threading for user applications... that's a licensing issue with the kernel, which I think is going to be replaced with Palm OS 6.
(Frankly, I'm a bit worried about this. It's possible to really screw things up with bad threading code, and I bet a lot of the shareware developers don't really understand threading very well. As part of being so easy to program, the Palm has attracted some programmers who don't really understand what they're doing. I hope PalmSource codes their OS to treat applications as potentially destructive code and does it well. They've done a really good job protecting RAM, but threading is another animal entirely.)
The system ROM is not *always* flash. The lower end devices tend to be real ROM.
Also... you probably know this, but you didn't mention it: The built in applications are stored in ROM. Except on Sony models -- they store a lot of their junk in database RAM. On a modern Sony device 16MB probably translates to 12-14MB or so.
Oh, and please don't be insulted by this. I take along a small case of CDs including quite a few I know I don't really need. I just haven't had to use them since Apple released the permissions fix tool.:)
It's never happened to me. I mean, I grant it's possible under OS 9. but under OS X the OS looks out for itself.
Diskwarrior will take care of all structural problems. First Aid will take care of all permission issues. If you have any other issues, you're either running as a super user on a regular basis (which you shouldn't) or you've got a hardware problem. Neither is resolvable with a CD.
I've never needed anything other than Diskwarrior on the road to fix up problems.
Unless you plan to install Mac OS X on others' machines, that's all you need. And in that case, you need to worry about whether or not they have a license to it. Easier just to not bring the CD so you have an easy excuse.
So far, the one I've been most impressed with push or pull clipboards with Rendezvous across Mac OS X systems. It's a bit of a security issue if you don't have it reasonably configured, of course.
So what have y'all seen that impressed you?
I don't know the answer, but don't use "and"!
on
Eleventy What?
·
· Score: 1
159 is formally "one hundred fifty nine," not "one hundred and fifty nine."
"And" is for decimal places, as in 159.7 = one hundred fifty nine and seven tenths.
Slashdot Mirror
I'm a huge DS9 fan, but I find this really tough to swallow.
So did TNG. Remember the Klingons? That was spread out over several years.
Technology increases at the speed that it is researched.
God knows we never saw the "save Earth against next to impossible odds!" plot before Crusade.
I don't really see "them" hyping this, rather reporters and Slashdot. I saw "them" casually mention it. And why shouldn't they?
I still need to consider whether I liked or hated Cogenitor, heh. But not that much different than I, Borg or The Outcast for instance. Although Enterprise took a much darker conclusion.
I really think anyone who views Enterprise as that much worse than TNG is relying on nostalgia, rather than the actually TNG episodes. I find Enterprise the most interesting Star Trek series so far by a wide margin (although comparing anything to the granddaddy of them all is apples to lemons).
The source code to Apple's Rendezvous implementation is already available for download. It includes implementations for Windows, Mac OS X, Mac OS 9 (yes, they're different stacks) and Posix.
I've only tried the Windows implementation (I'm only interested in Windows and Mac OS X, and I think it's a safe bet that Mac OS X works). It seemed to work perfectly.
Since when do you have a right to have your email accepted by the other server?
Ultimately, all an emulator does is convert instructions from one architecture to another. It's almost always more efficient to translate instructions in blocks
To come up with a really primitive, simple example, imagine a simple instruction set with a load, add, and branch if zero-set.
Code might look like this:
lda avar
add bvar
bre label
Now imagine we were translating to an instruction set that had mostly the same instructions, but needed a compare instruction to set our conditional flag
Instruction-by-instruction conversion might turn out like this:
lda avar tstz
add bvar
tstz
bre label
Now if the conversion was done on the entire block, we might end up with this:
lda avar
add bvar
tstz
bre label
Granted, this is a pretty simple example, but I hope it makes my point. Block conversions allow a great deal more optimization than instruction conversions.
This optimization might sound like a lot of work for the host processor, but if the block in question is a tight loop you more than make that up.
(No text.)
It's 3.5MB, and it's just been hit by the slashdot effect. If the administrators don't remove it, Microsoft is apparently willing to subsidize the bandwidth required for thousands to download it.
True. My problem is more that the mapping files are fairly incomplete.
Asimov's psychohistory was the study of mob mechanics.
Pyschohistory is better explained in the tail of the Robot series and the prequels to the Foundation series than in the "main" Foundation series itself.
I've had speeds that were simply impossible at some times (like immediately after a power failure) with my cable. Expect they happened, and I got them. Cable is consistently faster than anything else.
But my friend who lives 15 minutes away complains of his unreliable and slow connection that the same cable company can't seem to fix despite repeated efforts. He says this was explained as his distance from the major street in the area, which has the line running along it... which just happens to be the street I live on.
Cable can be much faster, or it can be much slower. It can be more reliable, or less. Helpful? No, not really. The only real advice I have for anyone is see which is cheaper, and try that first.
You should really rethink that. A phone in a PDA sounds useful, but the reality is that the form factors are incompatible. What makes a good PDA makes a lousy phone, and vice versa.
A separate phone/PDA that link together with Bluetooth is much more useful.
It likely has about 3MB of extra applications. My Clie NR70V is similiar.
I liked Daredevil, too.
Spiderman... well, it was a bit over the top, but I certainly can't call it bad.
I've been wondering this for a while. It doesn't really seem to have any advantages over Graffiti, save for being a bit easier to learn.
I think of it more as a "satisfy the lawyers" change than an improvement.
The requirements for phones and handheld computers are opposed. What makes a good phone makes a crappy handheld, and what makes a good handheld makes a crappy phone. This should be intuitively obvioous, but a great many people miss it: Consider the simple example jotting down a phone number someone it giving you over the phone, for instance. Or consider the size of phone you want to work with, compared with how small you want to write.
Instead, purchase two devices: A handheld and a phone. Make sure both have Bluetooth. This gives you the functionality of a combo device but without profile or multitasking compromises.
I store a lot of reference materials in my Clie. Things like recepie and drink databases. I'd like to store a full dictionary in there, but it's a bit small for that. I've written a program that stores a database of people in RAM. And, of course, I'd like to be able to keep a few pictures in there. My Clie doubles as a (crappy -- it's a older model) digital camera. Add it all up, and I could use about 20 MB of RAM at the moment. With a camera with better resolution, I would need more.
Gigabytes of storage aren't necessary, but I'm glad that we'll see new Palm handhelds go past 16 MB. You needn't worry about battery life suddenly dropping to unusable levels. That has always been a priority to Palm.
The real question is why PalmOS is such a pathetic mess on that kind of hardware. PalmOS gives you the programming experience and APIs of a low-end DOS machine on CPUs that are perfectly capable of running a full UNIX workstation environment.
Pardon me, but I don't think you've ever actually programmed the Palm. The Palm OS SDK is the cleanest SDK I've dealt with. The functions are very logically named and organized. Comparing it to DOS is insane. DOS didn't even really have an API, just a couple interrupts and low mem variables which development tool engineers built runtime libraries over.
A better comparison might be the classic Macintosh SDK, but designed by people who had already experienced the pain that Macintosh APIs grew into. The Palm has opaque objects, logical names, constants for everything, and a really well thought out event/notification model.
The great fault I find with it is the lack of standard C functions -- which makes sense, since you wouldn't want to include even a small subset of it with each Palm application. I've found most of those can be mapped to Palm OS traps with a simple #define, though.
Now, if you're not really talking about the APIs but the lack of threading for user applications... that's a licensing issue with the kernel, which I think is going to be replaced with Palm OS 6.
(Frankly, I'm a bit worried about this. It's possible to really screw things up with bad threading code, and I bet a lot of the shareware developers don't really understand threading very well. As part of being so easy to program, the Palm has attracted some programmers who don't really understand what they're doing. I hope PalmSource codes their OS to treat applications as potentially destructive code and does it well. They've done a really good job protecting RAM, but threading is another animal entirely.)
The system ROM is not *always* flash. The lower end devices tend to be real ROM.
Also... you probably know this, but you didn't mention it: The built in applications are stored in ROM. Except on Sony models -- they store a lot of their junk in database RAM. On a modern Sony device 16MB probably translates to 12-14MB or so.
I have to admit, my first instinct was to make a joke about it until I went through a few of the replies.
If this was about the information getting out there, it could (for instance) be put up on GNUtella or somesuch anonymously.
No, this is about profiting from the adventure. Even pre-DMCA, this was a no-no.
I've read repeatedly that some percentage of all email is spam. I think the number that usually gets thrown around is 40%.
I can't remember the last time I got that much legitimate email...
I really wonder how these stats are gathered.
Oh, and please don't be insulted by this. I take along a small case of CDs including quite a few I know I don't really need. I just haven't had to use them since Apple released the permissions fix tool. :)
It's never happened to me. I mean, I grant it's possible under OS 9. but under OS X the OS looks out for itself.
Diskwarrior will take care of all structural problems. First Aid will take care of all permission issues. If you have any other issues, you're either running as a super user on a regular basis (which you shouldn't) or you've got a hardware problem. Neither is resolvable with a CD.
Things don't just happen anymore.
I've never needed anything other than Diskwarrior on the road to fix up problems.
Unless you plan to install Mac OS X on others' machines, that's all you need. And in that case, you need to worry about whether or not they have a license to it. Easier just to not bring the CD so you have an easy excuse.
Unless this thread is all about piracy, heh.
I'm curious what other people have found...
So far, the one I've been most impressed with push or pull clipboards with Rendezvous across Mac OS X systems. It's a bit of a security issue if you don't have it reasonably configured, of course.
So what have y'all seen that impressed you?
159 is formally "one hundred fifty nine," not "one hundred and fifty nine."
"And" is for decimal places, as in 159.7 = one hundred fifty nine and seven tenths.