I'm absolutely sure that the students will have much more time to drink beer, but also I'm sure they won't ever be my competitors.
At least, I know how to read books (and if somebody does not know that, the primary knowledge is usually comes from the paper, just because there is no hyperlinks, and you have to read before you've understood that you had to read that before).
Well, not sure, is this "new" exploit technique worth our attention, if in those operating systems the system directory is writeable by anyone by default?
I'm not sure everybody will agree with my opinion, but I think the primary quality factor of any GUI or other receptor of an interactive influence is the predictability of the result. I'm not sure any of our gestures can always have predictable results provided that we often don't really know what caused us to make exactly that kind of gesture (I assume you're a human, not a robot, and I assume you like beer and so on). Of course, I'm not talking about toys where any result can be interesting, funny etc.
As to my opinion, the future of the UI can be described as follows:
The results of any operation should be predictable, even if you are not familiar with the object you're trying to control (well-designed GUIs already work this way).
Every time, you are given the options that you consider to be most logical in this context. (Not many UIs do that, we tend to be happy even if our shell can do at least a primitive filename competion, or if there is expected item in the preferences dialog box.)
UI should tell the user what can/should be done now, not a user should try to tell something the GUI.
Okay, I could write a lot more, but it's time to sleep here in Siberia. The most important thing to say is that the existing technologies do not bring us the possibilities they really can bring us right now.
Closing AT&T Labs UK would not change much in the VNC status.
The "official" VNC was unsupported for years, and
currently it lacks important features available in the derived
products. Today, there is no much sense to use the official VNC
distribution at all. For example, TightVNC is much more advanced in many aspects.
The development on the VNC code base was never stopped. Many people
issued various ports and additions, and currently there is at least
two major projects maintaining VNC-derived code bases: TightVNC and TridiaVNC. TightVNC is free,
TridiaVNC includes both free and commercial versions.
Being the maintainer of TightVNC, I can say that the
code base is in the state of active development, the latest version
was released on March 24, 2002, and the next version is to be
released in May. And I have no plans to stop the development.
The TightVNC project is open
to contributors, so I don't see a reason to create another branch
from the "official" VNC sources.
Well, TightVNC has been mentioned here already but being the TightVNC developer, I'd like to add a number of points.
First, to make things clear, TightVNC is a VNC version which mostly concentrates on low bandwidth usage. It can be more than usable on modem connections (starting from 14.4 kbps) but actual bandwidth requirements strongly depend on screen contents and color depth. If you want best performance over a slow link, first of all remove colorful wallpaper from your desktop (and maybe restrict color depth to 8 bits in VNC viewer).
Next point. Most users know TightVNC for its 1.1 version which may be considered outdated at this moment. TightVNC development has made notable progress since then and bandwidth requirements are decreased a lot. Although new 1.2 release is not ready at this point, but (1) there are preview versions including most 1.2 functionality and (2) I hope it will be released less than in a week counting from now (I only have to do several changes in Win32 version).
To let you know more what TightVNC is, here is a brief list of features for upcoming release, from new version of its homepage:
Local cursor handling. Cursor
movements do not generate screen updates any
more, remote cursor movements are processed
locally by the viewer, so you do not see
remote cursor pointer moving too slow behind
the local cursor.
Efficient compression algorithms.
New Tight encoding is optimized for slow
and medium-speed connections and thus generates much less traffic as compared to traditional
VNC encodings.
Configurable compression levels.
You can choose any appropriate level of
compromise between compression ratios and coding
speed, depending on the your connection speed
and processor power.
Optional JPEG compression. If you
don't care too much about perfect image quality,
you can enable JPEG coder which would compress
color-rich screen areas much more efficiently
(and image quality level is configurable
too).
Operating under Unix and Windows.
All new features listed above are available
in both Unix and Win32 versions of TightVNC.
Web browser access. TightVNC
includes Java viewer with support for Tight
encoding and local cursor feature (viewer applet
may be accessed via built-in HTTP server as in
the standard VNC).
Automatic SSH tunneling on Unix.
Unix version of TightVNC viewer can tunnel
connections via SSH automatically using local SSH
or OpenSSH client installation.
And more. A number of other
improvements, performance optimizations and
bugfixes, from me and from other people.
As you can see, most major changes introduced in TightVNC are related to efficient bandwidth usage.
> Ruby's iterators exist to work around the fact that functions aren't first class objects in Ruby. They exist because a programmer can't write higher order functions in Ruby.
1. Iterator bodies are first class objects in Ruby (anonymous instances of the Proc class).
2. Iterator bodies in Ruby are used exactly as higher order functions (they act as true closures).
In the publication you're referring to, C++-style iterators are being compared to Lisp-style mapping functions. But Ruby-style "iterators" are in fact those mapping functions derived from Lisp. So those "weakness signs" actually do not apply to Ruby (that article actually tells that one of weaknesses of C++ or Java is that they do _not_ support iterators in the Smalltalk/Ruby meaning of this word).
> As beautiful as "pure" languages like Java and Haskell and Ruby are,
There is no more "pure" in Ruby than in Perl. You don't have to create objects at all. Just arrange your code in procedures if you like (you don't have to know that all procedures are in fact methods anyway). And you can use "for" construct if you don't like iterator syntax.
By the way, I'm not a fan of "object-oriented" programming and I don't like languages like C++ or Java. But I do like Ruby and probably I'll switch to Ruby programming in my future projects (I used Perl for several years).
And the main thing I hate in Python is it's indentation-dependent syntax. I don't mind other people might like it, but for me -- no thanks.
I am developing TightVNC software which features a number of efficient bandwidth optimizations for well-known VNC software suite, and I'd like to share my opinion and experience on low-bandwidth remote desktop solutions. I think TightVNC and future versions of TridiaVNC may be a better alternatives as compared to X in all its flavours (with LBX, DXPC etc.) and I'll try to explain why in the text below. In short, I don't feel much pain using TightVNC over 33.6 Kbps dial-up connection.
Speaking of X and TightVNC, each choice has its specific benefits and drawbacks. First, let's look at strong sides of TightVNC (many points are applicable to the standard VNC, except for the bandwidth usage):
TightVNC requires minimum amount of code at the client (user's) side. The client does not require installation and it's size is about 200..300 KBytes. Moreover, you can access any remote system when no native client available: your remote desktop may be accessed from any Java-enabled Web browser, just type the hostname and port number of TightVNC's internal httpd.
TightVNC is truly multi-platform in its design and complexity level. Developing a new client is very simple task, the protocol is very simple. There are clients for X and Win32 environments and platform-neutral Java client (only 30 KB of compressed byte code!).
TightVNC is better suited for operation in network environment in general. For example, it just skips screen areas that are obsoleted at the moment when a client asks for screen update.
TightVNC does not deal with fonts on the client side: therefore it does not depend on font sets on the client system and does not require configuring font servers etc.
Compression level in Tight encoder is configurable on the client side and there is a possibility to enable lossy JPEG compression with adjustable image quality. If you don't care about every pixel appearence but just want to get work done, JPEG compression with low image quality level will efficiently use limited bandwidth even on most complex desktop contents.
From my real-life experience, TightVNC session is usually more bandwidth-friendly as compared to X with SSH compression, but X and VNC are very different in their architectures, and there are situations where X is more efficient. And it's not always simple to compare X and VNC.
The main problem of X is its complexity. X was intended to be too flexible and universal by design, but this also means that underlying techniques and protocols are extremely complicated. I often imagine X died under the pressing of it's own complexity.
Now about weakness points of the TightVNC:
TightVNC always exports the whole screen when X deals with separate windows.
VNC was not designed to be secure. There is a number of serious security flaws. X is not perfect in this sense, too, but it's a bit better.
Most impressive TightVNC features (local cursor support, JPEG compression, Tight Encoder 1.2) are still in the development phase. While Unix code and Java viewer are ready, Win32 version is not -- there are known bugs at this moment (to be solved in a week).
There are problems with internationalization in TightVNC.
Maybe I've forgotten to say something above, but now it's too late and I have to go now.
Slashdot Mirror
I'm absolutely sure that the students will have much more time to drink beer, but also I'm sure they won't ever be my competitors.
At least, I know how to read books (and if somebody does not know that, the primary knowledge is usually comes from the paper, just because there is no hyperlinks, and you have to read before you've understood that you had to read that before).
--
With Best Wishes,
Constantin
Well, not sure, is this "new" exploit technique worth our attention, if in those operating systems the system directory is writeable by anyone by default?
I'm not sure everybody will agree with my opinion, but I think the primary quality factor of any GUI or other receptor of an interactive influence is the predictability of the result. I'm not sure any of our gestures can always have predictable results provided that we often don't really know what caused us to make exactly that kind of gesture (I assume you're a human, not a robot, and I assume you like beer and so on). Of course, I'm not talking about toys where any result can be interesting, funny etc.
As to my opinion, the future of the UI can be described as follows:
- The results of any operation should be predictable, even if you are not familiar with the object you're trying to control (well-designed GUIs already work this way).
- Every time, you are given the options that you consider to be most logical in this context. (Not many UIs do that, we tend to be happy even if our shell can do at least a primitive filename competion, or if there is expected item in the preferences dialog box.)
- UI should tell the user what can/should be done now, not a user should try to tell something the GUI.
- Okay, I could write a lot more, but it's time to sleep here in Siberia. The most important thing to say is that the existing technologies do not bring us the possibilities they really can bring us right now.
--With Best Wishes,
Constantin
First, to make things clear, TightVNC is a VNC version which mostly concentrates on low bandwidth usage. It can be more than usable on modem connections (starting from 14.4 kbps) but actual bandwidth requirements strongly depend on screen contents and color depth. If you want best performance over a slow link, first of all remove colorful wallpaper from your desktop (and maybe restrict color depth to 8 bits in VNC viewer).
Next point. Most users know TightVNC for its 1.1 version which may be considered outdated at this moment. TightVNC development has made notable progress since then and bandwidth requirements are decreased a lot. Although new 1.2 release is not ready at this point, but (1) there are preview versions including most 1.2 functionality and (2) I hope it will be released less than in a week counting from now (I only have to do several changes in Win32 version).
To let you know more what TightVNC is, here is a brief list of features for upcoming release, from new version of its homepage:
As you can see, most major changes introduced in TightVNC are related to efficient bandwidth usage.
> Ruby's iterators exist to work around the fact that functions aren't first class objects in Ruby. They exist because a programmer can't write higher order functions in Ruby.
1. Iterator bodies are first class objects in Ruby (anonymous instances of the Proc class).
2. Iterator bodies in Ruby are used exactly as higher order functions (they act as true closures).
In the publication you're referring to, C++-style iterators are being compared to Lisp-style mapping functions. But Ruby-style "iterators" are in fact those mapping functions derived from Lisp. So those "weakness signs" actually do not apply to Ruby (that article actually tells that one of weaknesses of C++ or Java is that they do _not_ support iterators in the Smalltalk/Ruby meaning of this word).
> As beautiful as "pure" languages like Java and Haskell and Ruby are,
There is no more "pure" in Ruby than in Perl. You don't have to create objects at all. Just arrange your code in procedures if you like (you don't have to know that all procedures are in fact methods anyway). And you can use "for" construct if you don't like iterator syntax.
By the way, I'm not a fan of "object-oriented" programming and I don't like languages like C++ or Java. But I do like Ruby and probably I'll switch to Ruby programming in my future projects (I used Perl for several years).
And the main thing I hate in Python is it's indentation-dependent syntax. I don't mind other people might like it, but for me -- no thanks.
I am developing TightVNC software which features a number of efficient bandwidth optimizations for well-known VNC software suite, and I'd like to share my opinion and experience on low-bandwidth remote desktop solutions. I think TightVNC and future versions of TridiaVNC may be a better alternatives as compared to X in all its flavours (with LBX, DXPC etc.) and I'll try to explain why in the text below. In short, I don't feel much pain using TightVNC over 33.6 Kbps dial-up connection.
Speaking of X and TightVNC, each choice has its specific benefits and drawbacks. First, let's look at strong sides of TightVNC (many points are applicable to the standard VNC, except for the bandwidth usage):
From my real-life experience, TightVNC session is usually more bandwidth-friendly as compared to X with SSH compression, but X and VNC are very different in their architectures, and there are situations where X is more efficient. And it's not always simple to compare X and VNC.
The main problem of X is its complexity. X was intended to be too flexible and universal by design, but this also means that underlying techniques and protocols are extremely complicated. I often imagine X died under the pressing of it's own complexity. Now about weakness points of the TightVNC:
Maybe I've forgotten to say something above, but now it's too late and I have to go now.
--
With Best Wishes,
Constantin