For a different approach to this problem, check out the XML Windowing Toolkit; its "display server" runs as a Java Applet, or ActiveX control, so there's nothing to download/install. There's also a native Linux client.
I think that the larger picture here is simply that Windows (even NT derivitaves) isn't really a multiuser OS. The kernel is technically multiuser-capable, but just about every other part of the OS has been designed by lazy programmers with the assumption that there is only one user on the system, and Microsoft isn't interested/able to go through the effort to remove that assumption.
The lack of ubiquitous remote shell / remote gui on Win32 is the main reason that this assumption has gone unchallenged for so long. Unix ships with the ability to have multiple users simultaneously logged in remotely by default, which is why it's been so well tested for stuff like this.
I agree completely. And if you still want a rich, non-HTML GUI on your computer while still running nothing more than an HTTP server on the device, you might want to check out XWT.
This only happens on laptops with the nipple mouse.
The nipple needs to recalibrate itself every once in a while -- if it notices that the cursor is drifting at a perfectly even pace for more than a few seconds, it figures that it is miscalibrated (since real humans don't move the mouse at a perfectly even pace), and recenters itself.
Yep, I much prefer Haskell to Java. Only problem is that every time I mention it, I spend the next hour explaining what it is and why functional programming is a good idea =)
The amount of Servlet/J2EE/JDBC Java code out there vastly exceeds the amount of AWT code.
Sun's entire java.sun.com site runs on J2EE, which does not use AWT. Sure, the applets use AWT, simply because it's impossible to create an applet that doesn't use AWT (java.applet.Applet extends java.awt.Component).
Re:If you're worried about threading/memory bugs
on
Valgrind 1.0.0 Released
·
· Score: 5, Funny
you obviously have no idea what you're talking about
$ grep Megacz/usr/src/gcc-3.1/MAINTAINERS
Adam Megacz adam@xwt.org
Yeah, I probably know absolutely nothing about gcj...
GCJ supports everything in Java 1.2 except for AWT (most people aren't using Java for GUIs anyways), almost all of the 1.3 stuff, and a large portion of the 1.4 stuff.
Most Java software out there today (Tomcat, etc) is designed for Java 1.2. Not much changed in 1.3/1.4.
In a pinch, you can actually take the.jar's from Sun's Java distro, run them through GCJ, and get native code binaries. You can't redistribute these, but it's handy if you're writing server code rather than shrinkwrapped software.
If you're worried about threading/memory bugs
on
Valgrind 1.0.0 Released
·
· Score: 1, Redundant
You could write your code in Java (shuder!), and then use the Java frontend to GCC to compile it down to a blazingly fast 100% native-code binary. And you can do it all without ever using non-free software (unlike Sun's compilers/JVMs).
How is this a bad thing?
on
L0pht And The FBI
·
· Score: 2, Interesting
The rush to publish and take credit for discovering and patching a new exploit hobbles the positive efforts of blackhats with a social conscience (though admittedly no one knows how big a category that is).
Exploits are getting disclosed (and patched) more rapidly. How is this a bad thing? Wasn't it just a week ago that Slashdot was running articles deriding Microsoft for attempting to prevent the dissemination of vulnerability info?
I must agree that the whole find-exploit-get-VC thing is nonsense, but the losers in that game are the investors, and I really don't care if they get screwed.
Technically, you can argue that UDP is not "connectionless", because when I send a UDP packet from my laptop, it causes it to dial up my ISP, making a PPP "connection" to the ISP.
The idea is to introduce as little channel state (as few nested channels) as possible. BEEP is essentially "TCP over TCP".
Is everybody still inventing his own application layer protocol?
Stateless, connectionless servers are a good idea (HTTP, NFS, SMTP); for this reason, most people are going with web services calls (XML-RPC or SOAP) and using HTTP pipelining to erase the TCP connection negotiation overhead. This solves 95% of the problems that BEEP is designed for.
If you're still convinced that you really, really, really need a stateful connection, XATP is much simpler and gets the job done just as well as BEEP.
shameless XWT plug? what does this have to do with anything?
The article is about availability. My post lets people know about an open source tool called dnsfailover that can help them improve their availability. It also mentions the XWT Cluster as a real-life example of said software in action.
The XWT Cluster has achieved some very high availability on the cheap by using machines at several mom-and-pop data centers across the country. The machines are clustered into a peered (no master) failover configuration with the open source dnsfailover package. If any machine fails, the others will remove it from the DNS records; when it comes back on line, it gets added back in.
By spreading our risk across several data centers in different cities, with no single point of failure in the cluster, we don't have to worry about incompetent network administrators, power failures, a/c failures, backhoes, or nukes. Being able to skip out on all those expensive options saves a ton of money.
I've been toying with the idea of an XWT->HTML compiler... both environments use the same langauge (ECMA compliant JavaScript). There would probably have to be a rather large 'standard library' that translates XWT library calls to browser.* calls, but I think it's possible.
Is there anything you see in the XWT Mail demo or the widget sampler that couldn't be done in DHTML?
Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client.
Just like Curl, XWT includes a turing-complete language interpreter, meaning that you can implement any amount logic you like on the client side. If you absolutely need to use other languages on the client, you can do that too.
I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.
A 1028 page reference and 18 different "int" types, for starters. I dunno, I just don't think things have to be that complicated. A complete, comprehensive technical description of XWT fits on 15 pages when I print it out.
I don't know how it works out in XWT
XWT also transmits UIs as source (not binary). The JavaScript interpreter I use has the ability to compile JavaScript into Java Bytecodes (which then get JITted into native code), but I've found that because XWT operates at such a high level, all the performance-intensive stuff (layout, rendering, networking) is already running as native code in the XWT Engine, so this feature actually doesn't boost performance that much.
My empirical experiments with this have really changed my thinking on interpreted vs compiled -- if you make high-level primitives available to the interpreted code, and you make sure those primitives are hand-coded in a low level language and extremely well optimized, you really don't need to compile your code. It's the old 80/20 rule all over again.
I tried out rebol about 6-9 months ago and they had a pretty easy-to-access demo on their site. Now when I go to www.rebol.com, I can't seem to find it -- only some "evaluation request" form I submit for a sales rep to contact me. I'd like to see what they've been up to lately....
The Java version of XWT will support window maximization if you are running Java 1.4 or later (Maximization was not supported in jdk1.3). The Linux native binary doesn't support maximization yet; I'm working on it.
Wow, I had never seen Remote AWT before. Very cool idea.
Unfortunately RAWT still operates at a lower level than XWT -- it pushes pixels, lines, and mouse clicks over the network, not widget descriptions. The result is that RAWT will perform poorly over the public backbone or a slow link just like X11 and VNC -- simply scrolling a scrollbar requires a response from the server.
The other big difference is that XWT is much easier to code in -- you don't have to be a programmer. It's closer to the level of HTML+JS.
Finally, XWT runs as super-fast native code on Linux and Win32. RAWT is still encumbered by the slowness of AWT and JIT JVMs.
RAWT seems really cool though if you already have a Java app that you want to make remote and don't want to use an X Server
Slashdot Mirror
I don't run the webserver in question.
Also, what if the inept secretary down the hall (who has no idea what robots.txt is) decides to run this thing?
So if I choose to run this client, how do I know that it won't accidentally index content that is only accessible from behind my firewall?
Wow, PicoGUI is pretty impressive.
For a different approach to this problem, check out the XML Windowing Toolkit; its "display server" runs as a Java Applet, or ActiveX control, so there's nothing to download/install. There's also a native Linux client.
California Labor Code, section 2870 states that no matter what you signed, your employer cannot claim ownership of intellectual property which:
I don't think that it is fair to characterize the original developers of Windows as lazy.
No, and I don't consider them lazy. The people I consider lazy are the developers who didn't fix this design in future versions of windows.
The Macintosh developers made similar decisions when they implemented MacOS on an 8 MHz 68000 with 128K of RAM.
Yep, and Apple had the common sense to ditch that design and use a real OS for Mac OS X.
Awesome exploit, props to Foon.
I think that the larger picture here is simply that Windows (even NT derivitaves) isn't really a multiuser OS. The kernel is technically multiuser-capable, but just about every other part of the OS has been designed by lazy programmers with the assumption that there is only one user on the system, and Microsoft isn't interested/able to go through the effort to remove that assumption.
The lack of ubiquitous remote shell / remote gui on Win32 is the main reason that this assumption has gone unchallenged for so long. Unix ships with the ability to have multiple users simultaneously logged in remotely by default, which is why it's been so well tested for stuff like this.
I agree completely. And if you still want a rich, non-HTML GUI on your computer while still running nothing more than an HTTP server on the device, you might want to check out XWT.
This only happens on laptops with the nipple mouse.
The nipple needs to recalibrate itself every once in a while -- if it notices that the cursor is drifting at a perfectly even pace for more than a few seconds, it figures that it is miscalibrated (since real humans don't move the mouse at a perfectly even pace), and recenters itself.
Yep, I much prefer Haskell to Java. Only problem is that every time I mention it, I spend the next hour explaining what it is and why functional programming is a good idea =)
The amount of Servlet/J2EE/JDBC Java code out there vastly exceeds the amount of AWT code.
Sun's entire java.sun.com site runs on J2EE, which does not use AWT. Sure, the applets use AWT, simply because it's impossible to create an applet that doesn't use AWT (java.applet.Applet extends java.awt.Component).
you obviously have no idea what you're talking about
$ grep Megacz /usr/src/gcc-3.1/MAINTAINERS
Adam Megacz adam@xwt.org
Yeah, I probably know absolutely nothing about gcj...
There is no "GNU version of Java".
GCJ supports everything in Java 1.2 except for AWT (most people aren't using Java for GUIs anyways), almost all of the 1.3 stuff, and a large portion of the 1.4 stuff.
Most Java software out there today (Tomcat, etc) is designed for Java 1.2. Not much changed in 1.3/1.4.
In a pinch, you can actually take the .jar's from Sun's Java distro, run them through GCJ, and get native code binaries. You can't redistribute these, but it's handy if you're writing server code rather than shrinkwrapped software.
You could write your code in Java (shuder!), and then use the Java frontend to GCC to compile it down to a blazingly fast 100% native-code binary. And you can do it all without ever using non-free software (unlike Sun's compilers/JVMs).
The rush to publish and take credit for discovering and patching a new exploit hobbles the positive efforts of blackhats with a social conscience (though admittedly no one knows how big a category that is).
Exploits are getting disclosed (and patched) more rapidly. How is this a bad thing? Wasn't it just a week ago that Slashdot was running articles deriding Microsoft for attempting to prevent the dissemination of vulnerability info?
I must agree that the whole find-exploit-get-VC thing is nonsense, but the losers in that game are the investors, and I really don't care if they get screwed.
The idea is to introduce as little channel state (as few nested channels) as possible. BEEP is essentially "TCP over TCP".
No state is maintained from one HTTP connection to the next, nor from one SMTP connection to the next.
Is everybody still inventing his own application layer protocol?
Stateless, connectionless servers are a good idea (HTTP, NFS, SMTP); for this reason, most people are going with web services calls (XML-RPC or SOAP) and using HTTP pipelining to erase the TCP connection negotiation overhead. This solves 95% of the problems that BEEP is designed for.
If you're still convinced that you really, really, really need a stateful connection, XATP is much simpler and gets the job done just as well as BEEP.
shameless XWT plug? what does this have to do with anything?
The article is about availability. My post lets people know about an open source tool called dnsfailover that can help them improve their availability. It also mentions the XWT Cluster as a real-life example of said software in action.
The XWT Cluster has achieved some very high availability on the cheap by using machines at several mom-and-pop data centers across the country. The machines are clustered into a peered (no master) failover configuration with the open source dnsfailover package. If any machine fails, the others will remove it from the DNS records; when it comes back on line, it gets added back in.
By spreading our risk across several data centers in different cities, with no single point of failure in the cluster, we don't have to worry about incompetent network administrators, power failures, a/c failures, backhoes, or nukes. Being able to skip out on all those expensive options saves a ton of money.
actually you can do this with html now.
I've been toying with the idea of an XWT->HTML compiler... both environments use the same langauge (ECMA compliant JavaScript). There would probably have to be a rather large 'standard library' that translates XWT library calls to browser.* calls, but I think it's possible.
Is there anything you see in the XWT Mail demo or the widget sampler that couldn't be done in DHTML?
Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client.
Just like Curl, XWT includes a turing-complete language interpreter, meaning that you can implement any amount logic you like on the client side. If you absolutely need to use other languages on the client, you can do that too.
I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.
A 1028 page reference and 18 different "int" types, for starters. I dunno, I just don't think things have to be that complicated. A complete, comprehensive technical description of XWT fits on 15 pages when I print it out.
I don't know how it works out in XWT
XWT also transmits UIs as source (not binary). The JavaScript interpreter I use has the ability to compile JavaScript into Java Bytecodes (which then get JITted into native code), but I've found that because XWT operates at such a high level, all the performance-intensive stuff (layout, rendering, networking) is already running as native code in the XWT Engine, so this feature actually doesn't boost performance that much.
My empirical experiments with this have really changed my thinking on interpreted vs compiled -- if you make high-level primitives available to the interpreted code, and you make sure those primitives are hand-coded in a low level language and extremely well optimized, you really don't need to compile your code. It's the old 80/20 rule all over again.
Where are the demos on their site?
I tried out rebol about 6-9 months ago and they had a pretty easy-to-access demo on their site. Now when I go to www.rebol.com, I can't seem to find it -- only some "evaluation request" form I submit for a sales rep to contact me. I'd like to see what they've been up to lately....
The Java version of XWT will support window maximization if you are running Java 1.4 or later (Maximization was not supported in jdk1.3). The Linux native binary doesn't support maximization yet; I'm working on it.
Unfortunately RAWT still operates at a lower level than XWT -- it pushes pixels, lines, and mouse clicks over the network, not widget descriptions. The result is that RAWT will perform poorly over the public backbone or a slow link just like X11 and VNC -- simply scrolling a scrollbar requires a response from the server.
The other big difference is that XWT is much easier to code in -- you don't have to be a programmer. It's closer to the level of HTML+JS.
Finally, XWT runs as super-fast native code on Linux and Win32. RAWT is still encumbered by the slowness of AWT and JIT JVMs.
RAWT seems really cool though if you already have a Java app that you want to make remote and don't want to use an X Server
XWT is a client-server application, where the client just happens to auto-download transparently.