Re:What does .NET have to do with this?!
on
Low-Bandwidth X
·
· Score: 1
.NET is not about remotely running
Windows applications.
.NET IS ACTUALLY about remotely running
Windows applications./Gian Filippo.
Re:Grunge dropping New Jack through a press table
on
Low-Bandwidth X
·
· Score: 1
It was far from me to say X =.NET or X = Java. Actually I didn't say that. I said Java and.NET (or JavaScript) are all technologies their proponents have tried to push on your client and, hence, on your desktop.
They (of course) have many advantages over X (you mean ICE, I guess;-) to run client/server, distributed apps. Infact you can use CORBA, BONOBO, XML-RPC, KParts or DCOM to distribute application's intelligence and use X to display it.
The problem, in my opinion, is if it's worth the pain to download a VM, a runtime environment and the component itself on the client to let it draw the screen, or is better to leave them at home and use X_PolyFillRectangles.
/Gian Filippo.
Can X be the next big thing?
on
Low-Bandwidth X
·
· Score: 2
This was, actually, the original title. Maybe we are naive,
but we think that computers will never be for the mass market
until the time they will cost as a TV, a game machine or a
cellular phone. I remember when my ZX Spectrum had to battle
against Commodore 64 for the premiership. In 80s computers
where a mass market phenomenon not more that they are today.
PS2 is something I'd pay more attention when we speak about
net economy.
In Europe, where mobile telephony is a mass market, nobody
cares what OS a telephone is running. The same is true in
the US. We think that, soon, nobody will pay attention to
the OS a computer does run. BTW, that OS will be Linux, your
desktop applications will run unmodified on fbdev and X, and
you'll pay a 32MB PDA with 32MB of ROM from which to boot,
no HD but a 1Mbps Internet connection 24x7x365 something
like 150$. This assumption let us believe server based
computing is a real alternative to the PC based architecture
which has ruled the world so far.
I read some posts talking about persistence of X connections
and resource usage. They were very good points. Infact we are
working hard on them. Persistence is not very difficult to
achieve, as it's mainly a matter of proxies reconnecting after
a network failure. In the future we'll think at 'freezing' X
clients and server, the way APMS does. Furthermore we think
that the VM technology experimented by VMWare (but also
available in Linux as virtual-machines running in user space)
are the right complement to make possible thousands of users
on the same host. Resource usage at client (X server) side
is not that bad already. mlview-dxpc tries to make possible
to run full-featured X desktops, as the one you are used to
at your -local- machine. I mean with thousands and thousands
of bitmap images coming from the net. If you test mlview-dxpc
you'll find that a huge amount of bandwidth (and memory) is
used by animated GIFs. This is simple to overcome. It's enough
an X extension to handle this at the widget-set level. Why
nobody has done this before? Because to run a browser on a low
bandwidth link was simply not possible, so why bother?
To rewrite an application from scratch is a tough task. This
is why Java didn't work and.NET won't. It's much simpler
to adapt a stable code base to different conditions. If
you have given a look at QT Embedded, you know that most of
the KDE compiles smoothly under it. I expect to be possible
to configure KDE in the Control Center for slow links in the
future (it's enough to disable animations in Konqueror and
display a few other things in a different way). I expect
also to have at least three different behaviours for your
usual GTK and QT applications: X running locally, X running
remotely, local framebuffer with low resource usage and small screens. In this
future world we'll be able to run agenda or MP3 player on the
local PDA and write full featured DOCs and browse the net
on the remote machine.
I read a post about a free X not being available on Win32 or platform XYZ.
An X server is a network server which
translates X protocol in graphic calls that it
redirects to the hardware.
It's simple to separate the two parts and, actually,
this is exactly what Xvnc, XGGI and Xfbdev do.
There is already a port of XFree86 for Win32,
together with GTK and GNOME desktop. I heard
GGI people have compiled it on almost
everything from the coffe machine to the Palm
and TinyX is now part of XFree86.
One last word about mlview-dxpc's performances compared to
other solutions... I think the best is to download and test
it yourself.
Slashdot Mirror
They (of course) have many advantages over X (you mean ICE, I guess ;-) to run client/server, distributed apps. Infact you can use CORBA, BONOBO, XML-RPC, KParts or DCOM to distribute application's intelligence and use X to display it.
The problem, in my opinion, is if it's worth the pain to download a VM, a runtime environment and the component itself on the client to let it draw the screen, or is better to leave them at home and use X_PolyFillRectangles.
In Europe, where mobile telephony is a mass market, nobody cares what OS a telephone is running. The same is true in the US. We think that, soon, nobody will pay attention to the OS a computer does run. BTW, that OS will be Linux, your desktop applications will run unmodified on fbdev and X, and you'll pay a 32MB PDA with 32MB of ROM from which to boot, no HD but a 1Mbps Internet connection 24x7x365 something like 150$. This assumption let us believe server based computing is a real alternative to the PC based architecture which has ruled the world so far.
I read some posts talking about persistence of X connections and resource usage. They were very good points. Infact we are working hard on them. Persistence is not very difficult to achieve, as it's mainly a matter of proxies reconnecting after a network failure. In the future we'll think at 'freezing' X clients and server, the way APMS does. Furthermore we think that the VM technology experimented by VMWare (but also available in Linux as virtual-machines running in user space) are the right complement to make possible thousands of users on the same host. Resource usage at client (X server) side is not that bad already. mlview-dxpc tries to make possible to run full-featured X desktops, as the one you are used to at your -local- machine. I mean with thousands and thousands of bitmap images coming from the net. If you test mlview-dxpc you'll find that a huge amount of bandwidth (and memory) is used by animated GIFs. This is simple to overcome. It's enough an X extension to handle this at the widget-set level. Why nobody has done this before? Because to run a browser on a low bandwidth link was simply not possible, so why bother?
To rewrite an application from scratch is a tough task. This is why Java didn't work and .NET won't. It's much simpler
to adapt a stable code base to different conditions. If
you have given a look at QT Embedded, you know that most of
the KDE compiles smoothly under it. I expect to be possible
to configure KDE in the Control Center for slow links in the
future (it's enough to disable animations in Konqueror and
display a few other things in a different way). I expect
also to have at least three different behaviours for your
usual GTK and QT applications: X running locally, X running
remotely, local framebuffer with low resource usage and small screens. In this
future world we'll be able to run agenda or MP3 player on the
local PDA and write full featured DOCs and browse the net
on the remote machine.
I read a post about a free X not being available on Win32 or platform XYZ. An X server is a network server which translates X protocol in graphic calls that it redirects to the hardware. It's simple to separate the two parts and, actually, this is exactly what Xvnc, XGGI and Xfbdev do. There is already a port of XFree86 for Win32, together with GTK and GNOME desktop. I heard GGI people have compiled it on almost everything from the coffe machine to the Palm and TinyX is now part of XFree86.
One last word about mlview-dxpc's performances compared to other solutions... I think the best is to download and test it yourself.