The fact that you run some protocol over HTTP
(and that's essentially is what SOAP is, I think)
does not make firewalls less useful. It just requires newer firewalls that "know" how SOAP looks and can burn few more CPU cycles and detect it. So with new gen firewalls, you will be able to say I "allow HTTP, I prohibit SOAP"... Stateful inspection, man.... Firewalls are not what they were used to be, they don't look at the port alone anymore
X11 is not a good window system for a home desktop user. It, indeed, lets you do much more than the home desktop user would normally want (I mean network GUI features). This I would call bloat.
Next, there are inherently bad design decision in X11 that started to impact the usability of it: A good example would be that cursor and fonts are by design 1-bit deep bitmaps, meaning no simple way to introduce color cursors or antialiased fonts.
(Fonts, BTW, is the weakest spot in X11 design, right after idiotic design that makes you write quite different code for truecolor and low-color displays)
Most of those shortcomings are now being addressed in toolkits like GTK and QT/KDEToolkit, but that does not improve the X11, just those 2 toolkits.
On the other hand, we should stick to X at least until we have reasonably good port of GTK or QT/KDE to some different platform. The price of loosing X would be inability to iteroperate with other UNIX systems, and, at the same time, would mean that we need to develop new GUI framework.
Berlin is a good example of what happens when you drop X. The idea is OK, the human resources are not adequate to do it in reasonable time.
The only other GUI I've heard of is Photon (right?) and it does seem to have few virtues of X, like network-transparent graphics, and a thin design. I did not develop for it and have no idea how good/bad it is.
Win2000 comes with network transparent GUI as well, and, unlike X, it works nicely over 36kpbs modem lines. (slow a bit) That GUI is a standard win32 gui from the developer's point of view, and we all know what we think about it.
The fact that you run some protocol over HTTP
(and that's essentially is what SOAP is, I think)
does not make firewalls less useful. It just requires newer firewalls that "know" how SOAP looks and can burn few more CPU cycles and detect it. So with new gen firewalls, you will be able to say I "allow HTTP, I prohibit SOAP"... Stateful inspection, man.... Firewalls are not what they were used to be, they don't look at the port alone anymore
X11 is not a good window system for a home
desktop user. It, indeed, lets you do much
more than the home desktop user would normally
want (I mean network GUI features). This
I would call bloat.
Next, there are inherently bad design decision in
X11 that started to impact the usability of it:
A good example would be that cursor and fonts are
by design 1-bit deep bitmaps, meaning no simple way to introduce color cursors or antialiased fonts.
(Fonts, BTW, is the weakest spot in X11 design,
right after idiotic design that makes you write
quite different code for truecolor and low-color
displays)
Most of those shortcomings are now being
addressed in toolkits like GTK and QT/KDEToolkit,
but that does not improve the X11, just those 2
toolkits.
On the other hand, we should stick to X at least
until we have reasonably good port of GTK or QT/KDE to some different platform. The price of
loosing X would be inability to iteroperate with
other UNIX systems, and, at the same time, would
mean that we need to develop new GUI framework.
Berlin is a good example of what happens when you
drop X. The idea is OK, the human resources are not adequate to do it in reasonable time.
The only other GUI I've heard of is Photon (right?) and it does seem to have few virtues of X, like network-transparent graphics, and a thin design. I did not develop for it and have no idea how good/bad it is.
Win2000 comes with network transparent GUI as well, and, unlike X, it works nicely over 36kpbs modem lines. (slow a bit)
That GUI is a standard win32 gui from the developer's point of view, and we all know what we think about it.