While it's not part of the election, once a President gets in office, he's basically campaigning for re-election
How about reforming the Presidential term limits so that a single person can only serve one term as president? This would avoid the idiocy of having the (arguably) most powerful person in the world spending their time campaigning instead of working and would reduce the effect of incumbency (the Vice President would still have an unfair advantage, especially since they typically seem to just sit around on their thumbs anyway)
I think this was true several years ago, but we've been using the word count of the page (after stripping markup) for a long time now (since at least Apr 2000 according to CVS).
This approach generates some false positives, but in general, it's pretty good. Still, this is something that we'll be able to improve upon now that we can leave a bunch of the ugly stuff to Apple's WebCore/JavaScriptCore.
OmniWeb's shortcuts have been around since at least Apr, 1998 (compared to May, 2001 according to Old Mozilla Releases). They were around in less featureful incarnations back to 1996 or 1997, judging from what I see in CVS.
Remember, OmniWeb is one of the oldest browsers still around:
We love it when other browsers copy OmniWeb's features (and we've certainly copied features from other places). What is even better is that with WebCore/JavaScriptCore we have to spend less time futzing with web standards (if they can be called that) and can work on honest-to-goodness innovations.
Actually, IBM appears to be devoting some time to working on GCC support for PPC. In particular, they are working on auto-vectorization (i.e., you write scalar code and it gets turned into Alti.., er, VMX code).
Fcast seems way more complicated than it needs to be.
Say that you have a file that you want to send to a lot of people. These people are going to want to get the file as fast as possible, but they are also all going to have differing speed connections.
Now, as the sender of the file, we would like to minimize the number of packets we send, but we don't have to ensure that we only send each packet once, we just need to be better than sending every packet once to every recipient.
So, instead of using one multicast channel, use a bunch. Each channel broadcasts at some lowest common denominator speed which can be picked based on your intended recipient's networks (if you don't know, you need 14.4kbps or something like that). Then, compute the time it will take to transmit the entire file at that speed. Time shift each channel by channelNumber*totalTime/numberOfChannels and start broadcasting all of them continuously, at the prechosen speed.
Now, as a receiver, you know how much bandwidth the sender has to you (or at least you can figure it out). Simply subscribe to the largest number of channels you can w/o getting dropped packets over some threshold. You might get some duplicate packets from wrap around between the beginning and ending of the transmission, but those can be tossed.
If packets are lost, you could either request specific packets from the server (if you have only a few and the server isn't too loaded), or you could just jump on the channel that will have that packet soonest (and onto another channel if you miss it again, rinse, wash, repeat).
Assuming a constant base channel speed (which seems reasonable until broadband access is more wide spread), the trade off here is the number of channels. By increasing the number of channels, the sender has to repeat each packet more times, but the clients can have better maximum throughput and less time to wait to replace dropped packets.
There is probably some additional cost at the routing layer for all these people subscribing and unsubscribing from extra channels, but I assume (maybe incorrectly) that the routing layer would be able to handle this problem since it would be distributed across a whole bunch of routers.
Rodney Brooks, the director of the AI Lab at MIT, seems to have made a great deal of progress with his subsumption architecture. He proposes that the hard parts of AI are not the planning and cognitive exercises, but rather the parts of intelligence that you find in lower life forms like insects, small mammals and such.
3D hardware needs to be seen as an enabling technology. The faster the hardware is, the more Carmack can do with it:)
But the 3D vendors can't really advertise with, "Hey, if you buy our board, it will fast enough for some way cool games that haven't been invented yet". So instead, they have to post framerates using current title, something that gamers can relate to easier.
Apple has done lots of work on Mach since they grabbed 2.5 (and later the OSF stuff). They have a totally new driver architecture, vm enhancements, and tons of other stuff.
You do all realize that the primary author of Mach (Avadis Tevanian) is the VP of Software (or something to that effect) at Apple now?
... and I've even heard that he still occasionally commits kernel fixes:)
OmniWeb3 (a NEXTSTEP, MacOS X Server and Yellow Box/NT browser) supports it. I just looked at the PNG test page and we apparently fail the "Images with non-square pixels and/or pixels with physical dimensions" test. Guess I'll go fix that:)
Slashdot Mirror
While it's not part of the election, once a President gets in office, he's basically campaigning for re-election
How about reforming the Presidential term limits so that a single person can only serve one term as president? This would avoid the idiocy of having the (arguably) most powerful person in the world spending their time campaigning instead of working and would reduce the effect of incumbency (the Vice President would still have an unfair advantage, especially since they typically seem to just sit around on their thumbs anyway)
Well, you could have looked at an OmniWeb bookmarks file :)
My bookmarks file has, for example:
I think this was true several years ago, but we've been using the word count of the page (after stripping markup) for a long time now (since at least Apr 2000 according to CVS).
This approach generates some false positives, but in general, it's pretty good. Still, this is something that we'll be able to improve upon now that we can leave a bunch of the ugly stuff to Apple's WebCore/JavaScriptCore.
Actually ... checks CVS... (yes, I work for Omni)
OmniWeb's shortcuts have been around since at least Apr, 1998 (compared to May, 2001 according to Old Mozilla Releases). They were around in less featureful incarnations back to 1996 or 1997, judging from what I see in CVS.
Remember, OmniWeb is one of the oldest browsers still around:
We love it when other browsers copy OmniWeb's features (and we've certainly copied features from other places). What is even better is that with WebCore/JavaScriptCore we have to spend less time futzing with web standards (if they can be called that) and can work on honest-to-goodness innovations.
Actually, IBM appears to be devoting some time to working on GCC support for PPC. In particular, they are working on auto-vectorization (i.e., you write scalar code and it gets turned into Alti.., er, VMX code).
All you have to do is go to the Motorola site and look a bit: http://www.mot.com/SPS/RISC/smartnetworks/arch/pow erpc/doclib.htm
Fcast seems way more complicated than it needs to be.
Say that you have a file that you want to send to a lot of people. These people are going to want to get the file as fast as possible, but they are also all going to have differing speed connections.
Now, as the sender of the file, we would like to minimize the number of packets we send, but we don't have to ensure that we only send each packet once, we just need to be better than sending every packet once to every recipient.
So, instead of using one multicast channel, use a bunch. Each channel broadcasts at some lowest common denominator speed which can be picked based on your intended recipient's networks (if you don't know, you need 14.4kbps or something like that). Then, compute the time it will take to transmit the entire file at that speed. Time shift each channel by channelNumber*totalTime/numberOfChannels and start broadcasting all of them continuously, at the prechosen speed.
Now, as a receiver, you know how much bandwidth the sender has to you (or at least you can figure it out). Simply subscribe to the largest number of channels you can w/o getting dropped packets over some threshold. You might get some duplicate packets from wrap around between the beginning and ending of the transmission, but those can be tossed.
If packets are lost, you could either request specific packets from the server (if you have only a few and the server isn't too loaded), or you could just jump on the channel that will have that packet soonest (and onto another channel if you miss it again, rinse, wash, repeat).
Assuming a constant base channel speed (which seems reasonable until broadband access is more wide spread), the trade off here is the number of channels. By increasing the number of channels, the sender has to repeat each packet more times, but the clients can have better maximum throughput and less time to wait to replace dropped packets.
There is probably some additional cost at the routing layer for all these people subscribing and unsubscribing from extra channels, but I assume (maybe incorrectly) that the routing layer would be able to handle this problem since it would be distributed across a whole bunch of routers.
How does this compare to your approach?
3D hardware needs to be seen as an enabling technology. The faster the hardware is, the more Carmack can do with it :)
But the 3D vendors can't really advertise with, "Hey, if you buy our board, it will fast enough for some way cool games that haven't been invented yet". So instead, they have to post framerates using current title, something that gamers can relate to easier.
Apple has done lots of work on Mach since they grabbed 2.5 (and later the OSF stuff). They have a totally new driver architecture, vm enhancements, and tons of other stuff.
You do all realize that the primary author of Mach (Avadis Tevanian) is the VP of Software (or something to that effect) at Apple now?
OmniWeb3 (a NEXTSTEP, MacOS X Server and Yellow Box/NT browser) supports it. I just looked at the PNG test page and we apparently fail the "Images with non-square pixels and/or pixels with physical dimensions" test. Guess I'll go fix that :)
:)
http://www.omnigroup.com/Software
(and yes, I work for them -- heck, I own them