Right, the VNC protocol has nothing to do with X. I should say, the default Linux VNC *implementation* is based on an X server.
As I recall AT&T was trying to create devices which combined the various technologies found in an average office-- a computer, a phone, video conferencing, etc.; hence, "Virtual Network Computing." Their device was a hardware VNC client (though I doubt it was really hardware; even the SunRay boxes are software based) connecting to some beefy centralized server. In the end the protocol took off since it was so simple and portable.
AT&T Cambridge really did some interesting things over the years. Their later pervasive computing research is quite cool.
Actually, RDP, VNC, and SunRays *are* the same thing. Their client sides are all networked framebuffers, they just use different protocols to get the bits from the server to the client. In addition, some of them try to optimize things by adding compression, caching, and higher level drawing operations. Then, some of them add authentication features like the SunRay smartcards.
To put it in terms of X, in a thin-client system, both the X clients and the X server are on the server side (thus the name). However, the X server doesn't draw pixels on a locally installed video card, but on the remote thin client. In fact, both Sunray and VNC use a modified X server to do this.
My university had a handful of Unix labs (HPUX and Solaris) around the campus, with some Windows 3.11 and 95 in a computing center to run Word. The only place Macs existed was a lab used to run the introductory CS class; the Macs were the classic types ("oscilloscopes") running flavors of Prolog, Lisp, and SML. This was around the time when Slackware was the most popular distro, and took up 30 floppies.
I recall a huge move to Windows PCs as I was leaving the place.
The utility of the internet is providing a common namespace for communication, be it the IP address space, or the domain names. As such, there must exist some entity that controls access to this namespace, or the system wouldn't work. Even if there were no DNS, and people remembered IP addresses, there would be competition for 5.5.5.5 etc. at the IANA. A centralized DNS is thus not only logical, but necessary.
(I can imagine some decentralized p2p-based DNS, but there would still need to be some sort of mechanism for agreement on who owns which name. Thus, there would still be a centralized point of control. A truly decentralized system where anyone can lay claim to any name, similar to gnutella, would not scale, and would not be useful due to overloading common names.)
Content would probably get cached better with BT than DNS because of the dynamically constructed network topology. The caching in DNS works as well as it does because it happens along the domain name hierarchy (duh). The default topology probably wouldn't be very efficient for content.
Further, DNS would need to be upgraded. There is a good reason that short-term, experimental applications are better done at the ends; read the End-to-end arguments in system design for further insights.
Face it, NT is not a real-time OS and so there is no guarantee that random drivers won't hang the system for arbitrary periods of time. IDE drivers in particular used to be a nuisance even on earlier Linux kernels until the preemptive and low-latency patches, as anyone attempting real-time disk-recording or sound filtering could tell you.
As far as being dumb for not yielding etc., I have to admit that I would have preferred using a non-thread based solution to this problem. Doesn't Win32 have some sort of async I/O or select()? Event-based programs are IMHO more elegant and hide fewer scheduling decisions from the programmer.
That reminds me of a large set of advanced math information published by Wolfram Research: see mathworld.wolfram.com. Individual pages have many hyperlinked terms which are very handy when exploring a certain subject. I don't know if I agree that it's a better way to teach the material though; I think books can work just as well, as long as the quality is there. After some time spent getting familiar with a good textbook, I find that I start building a sort of a mental map, and I can quickly flip pages to look stuff up. This is similar to how links work.
My interpretation of this claim is that perhaps instead of trying to find and fix holes, we should focus on using more secure tools and frameworks, so that they automatically eliminate a whole class of holes. Look at how much pain was caused industry-wide by using C/C++ with all the buffer overflow vulnerabilities, which are trivially avoided in different languages (e.g. Java).
My argument is that I believe that one of the reasons that you don't find things like rocket-powered vehicles in nature is that they have such a huge inherent complexity that it is almost improbable that you will ever reach even the simplest version of the machine, let alone a final, usable product.
Actually, a rocket engine seems pretty simple compared to the marvel that is even a single cell. The reason there are no naturally occuring rocket ships is probably that natural evolutionary processes look for solutions to a different problem; namely, building machines that are good at survival.
This is what we were originally arguing, that we will likely have a hard time beating natural self-replicating designs, i.e. designs good at survival. Beating nature in other solution spaces is easier, as with the rocket ship example.
You are joking, but you're not far from the truth: quoting a Washington Post article Showdown with the Linux gang (use foobarian@foo.com/foobar to log in):
"We went out one day and our Unix cows were missing," McBride said he told his father in trying to explain the case to him. "We looked in the Linux pen, and there's a bunch of them in there that have our brand on them . . . in this case the copyright. Someone took our cows and we want 'em back -- it's as simple as that."
It tends to create organisms which can only operate within a certain set of parameters.
I agree, but I'm afraid that this is because those parameters are the ones which lead to most efficient self-replicating machines. (I have no proof for this, just a pessimistic guess.)
We can adjust systems to operate in places to which nature would never send them.
Agreed for systems which are not self-replicating.
Great point. Also, consider that nature itself has, through millions of years of random experimentation, come as close as one can hope to self-replicating nano-machines: just look at any virus, bacterium, etc. I find it extremely unlikely that we will be able to do much better in terms of ability to replicate by harvesting external matter-- an ability closely related to deadliness to all sorts of life forms.
That is annoying beyond belief. With my bank, I just click a bookmark on a Firefox toolbar; no PINs, no account numbers, no nothing. (Of course, there is some amount of authentication required the first time, so the necessary cookies can be generated).
The convenience is definitely worth more to me than any negative events. You can even quantify it. Suppose my perceived value of not having to type any damn numbers into the little OTP calculator is $5 per login. Say I log in 200 times a year, that's $1000. Now what is the probability someone will swipe my entire account that year, which let's say holds $20k? Hell of a lot less than 1/20.
If only there was a way to somehow "trap" light emitted at a certain scene or event. We could take the trapped light, and release it at a latter time, effectivelly allowing anyone nearby to literally see history! Maybe we could even find a way to convert the light into electrical signals so we could transmit it at great distances. Better file a patent quick!
The pearl teas are usually rolled up with jasmine flower petals. Are you sure you are drinking pure green tea? Jasmine gives a distinct bitterness to the tea that I don't particularly like.
The only good green tea I ever had was from China, I couldn't find anything fresh locally.
Without big bombs to deter your enemies, you wouldn't be alive long enough to develop said good uses.
I recall an article about scientists at Los Alamos wishing to develop bombs as big and powerful as possible, precisely because the destructive power would make them much *less* likely to be used by the governments. Indeed, compare the cold war and the previous wars where entire nations were dying in the trenches. I sure prefer the former.
"Found cache easily. Coordinates a bit off, though. Took empty whiskey bottle, left Play-Doh."
"Took me a while to find this one, the GPS was all over the place. Cache is in bad shape and smells of liquor. TNLN, thanks for bringing us to this beautiful neighborhood!"
"Found the cache after some bushwhacking. Our kids enjoyed the chat with the cache owner. Took nothing, left some Ramen noodle soup."
I saw a bunch of e-machines on sale in my local Walmart. They were decent 2+ GHz boxes with LCD monitors included all for $500. They come packaged in huge cardboard boxes.
Slashdot Mirror
Right, the VNC protocol has nothing to do with X. I should say, the default Linux VNC *implementation* is based on an X server.
As I recall AT&T was trying to create devices which combined the various technologies found in an average office-- a computer, a phone, video conferencing, etc.; hence, "Virtual Network Computing." Their device was a hardware VNC client (though I doubt it was really hardware; even the SunRay boxes are software based) connecting to some beefy centralized server. In the end the protocol took off since it was so simple and portable.
AT&T Cambridge really did some interesting things over the years. Their later pervasive computing research is quite cool.
Actually, RDP, VNC, and SunRays *are* the same thing. Their client sides are all networked framebuffers, they just use different protocols to get the bits from the server to the client. In addition, some of them try to optimize things by adding compression, caching, and higher level drawing operations. Then, some of them add authentication features like the SunRay smartcards.
To put it in terms of X, in a thin-client system, both the X clients and the X server are on the server side (thus the name). However, the X server doesn't draw pixels on a locally installed video card, but on the remote thin client. In fact, both Sunray and VNC use a modified X server to do this.
My university had a handful of Unix labs (HPUX and Solaris) around the campus, with some Windows 3.11 and 95 in a computing center to run Word. The only place Macs existed was a lab used to run the introductory CS class; the Macs were the classic types ("oscilloscopes") running flavors of Prolog, Lisp, and SML. This was around the time when Slackware was the most popular distro, and took up 30 floppies.
I recall a huge move to Windows PCs as I was leaving the place.
(in case of slashdotting)
Google
Web Images Groups News Froogle more
Advanced Search
Preferences
Language Tools
Free! Manage and share your digital photographs. Download Picasa from Google.
Advertising Programs - Business Solutions - About Google
©2004 Google - Searching 4,285,199,774 web pages
The utility of the internet is providing a common namespace for communication, be it the IP address space, or the domain names. As such, there must exist some entity that controls access to this namespace, or the system wouldn't work. Even if there were no DNS, and people remembered IP addresses, there would be competition for 5.5.5.5 etc. at the IANA. A centralized DNS is thus not only logical, but necessary.
(I can imagine some decentralized p2p-based DNS, but there would still need to be some sort of mechanism for agreement on who owns which name. Thus, there would still be a centralized point of control. A truly decentralized system where anyone can lay claim to any name, similar to gnutella, would not scale, and would not be useful due to overloading common names.)
Content would probably get cached better with BT than DNS because of the dynamically constructed network topology. The caching in DNS works as well as it does because it happens along the domain name hierarchy (duh). The default topology probably wouldn't be very efficient for content.
Further, DNS would need to be upgraded. There is a good reason that short-term, experimental applications are better done at the ends; read the End-to-end arguments in system design for further insights.
Face it, NT is not a real-time OS and so there is no guarantee that random drivers won't hang the system for arbitrary periods of time. IDE drivers in particular used to be a nuisance even on earlier Linux kernels until the preemptive and low-latency patches, as anyone attempting real-time disk-recording or sound filtering could tell you.
As far as being dumb for not yielding etc., I have to admit that I would have preferred using a non-thread based solution to this problem. Doesn't Win32 have some sort of async I/O or select()? Event-based programs are IMHO more elegant and hide fewer scheduling decisions from the programmer.
That reminds me of a large set of advanced math information published by Wolfram Research: see mathworld.wolfram.com. Individual pages have many hyperlinked terms which are very handy when exploring a certain subject. I don't know if I agree that it's a better way to teach the material though; I think books can work just as well, as long as the quality is there. After some time spent getting familiar with a good textbook, I find that I start building a sort of a mental map, and I can quickly flip pages to look stuff up. This is similar to how links work.
My interpretation of this claim is that perhaps instead of trying to find and fix holes, we should focus on using more secure tools and frameworks, so that they automatically eliminate a whole class of holes. Look at how much pain was caused industry-wide by using C/C++ with all the buffer overflow vulnerabilities, which are trivially avoided in different languages (e.g. Java).
My argument is that I believe that one of the reasons that you don't find things like rocket-powered vehicles in nature is that they have such a huge inherent complexity that it is almost improbable that you will ever reach even the simplest version of the machine, let alone a final, usable product.
Actually, a rocket engine seems pretty simple compared to the marvel that is even a single cell. The reason there are no naturally occuring rocket ships is probably that natural evolutionary processes look for solutions to a different problem; namely, building machines that are good at survival.
This is what we were originally arguing, that we will likely have a hard time beating natural self-replicating designs, i.e. designs good at survival. Beating nature in other solution spaces is easier, as with the rocket ship example.
You are joking, but you're not far from the truth: quoting a Washington Post article Showdown with the Linux gang (use foobarian@foo.com/foobar to log in):
"We went out one day and our Unix cows were missing," McBride said he told his father in trying to explain the case to him. "We looked in the Linux pen, and there's a bunch of them in there that have our brand on them . . . in this case the copyright. Someone took our cows and we want 'em back -- it's as simple as that."
Yeehaw!
It tends to create organisms which can only operate within a certain set of parameters.
I agree, but I'm afraid that this is because those parameters are the ones which lead to most efficient self-replicating machines. (I have no proof for this, just a pessimistic guess.)
We can adjust systems to operate in places to which nature would never send them.
Agreed for systems which are not self-replicating.
Great point. Also, consider that nature itself has, through millions of years of random experimentation, come as close as one can hope to self-replicating nano-machines: just look at any virus, bacterium, etc. I find it extremely unlikely that we will be able to do much better in terms of ability to replicate by harvesting external matter-- an ability closely related to deadliness to all sorts of life forms.
They tried to upgrade to Linux but they didn't pay the $699 license fee!
That is annoying beyond belief. With my bank, I just click a bookmark on a Firefox toolbar; no PINs, no account numbers, no nothing. (Of course, there is some amount of authentication required the first time, so the necessary cookies can be generated).
The convenience is definitely worth more to me than any negative events. You can even quantify it. Suppose my perceived value of not having to type any damn numbers into the little OTP calculator is $5 per login. Say I log in 200 times a year, that's $1000. Now what is the probability someone will swipe my entire account that year, which let's say holds $20k? Hell of a lot less than 1/20.
If only there was a way to somehow "trap" light emitted at a certain scene or event. We could take the trapped light, and release it at a latter time, effectivelly allowing anyone nearby to literally see history! Maybe we could even find a way to convert the light into electrical signals so we could transmit it at great distances. Better file a patent quick!
The pearl teas are usually rolled up with jasmine flower petals. Are you sure you are drinking pure green tea? Jasmine gives a distinct bitterness to the tea that I don't particularly like.
The only good green tea I ever had was from China, I couldn't find anything fresh locally.
Without big bombs to deter your enemies, you wouldn't be alive long enough to develop said good uses.
I recall an article about scientists at Los Alamos wishing to develop bombs as big and powerful as possible, precisely because the destructive power would make them much *less* likely to be used by the governments. Indeed, compare the cold war and the previous wars where entire nations were dying in the trenches. I sure prefer the former.
Why couldn't you have used OO? It saves to powerpoint just fine, which would work on the XP machine you had to use.
Did anyone else read the "open sourcing innovation" as "outsourcing innovation"?
Great... imagine the logs:
"Found cache easily. Coordinates a bit off, though. Took empty whiskey bottle, left Play-Doh."
"Took me a while to find this one, the GPS was all over the place. Cache is in bad shape and smells of liquor. TNLN, thanks for bringing us to this beautiful neighborhood!"
"Found the cache after some bushwhacking. Our kids enjoyed the chat with the cache owner. Took nothing, left some Ramen noodle soup."
Why would I want to date a design pattern? Is this an April Fool's joke? Huh?
I saw a bunch of e-machines on sale in my local Walmart. They were decent 2+ GHz boxes with LCD monitors included all for $500. They come packaged in huge cardboard boxes.
Or even worse, install a bunch of disguised spam "access points" at busy places and let passersby do the spamming for you :)
On the other hand, it could turn out: more money => more of the same kind of officials => more bad patents per unit time.