Slashdot Mirror

I wish Andromeda were useful for me...but I have a frigging 128 kilobit upload limit. Which means any MP3s I played would be skippy-jumpy, 'cuz almost my entire collection is at a higher bitrate than that. Grumble.

OTOH, it's great for hosting a Mindterm java SSH client for me to connect in from the crippled-to-web-only check-your-mail computers at work to get my email and chat online with my friends via Tinyfugue.

Do you really need your laptop? If not, don't bring it.

Amen.

I travel to a pretty diverse range of countries on a fairly regular basis. I have long ago given up on toting a laptop around unless I specifically need it for a meeting.

Outside of the US (where I assume you're posting from) internet cafes are thick on the ground. In developed countries, the service is much faster than you'll get by dialing in, and quite often cheaper than the phone call.

I use the mindterm Java applet to provide an SSH terminal from my web server.

In some places, mainly in Asia, I've found Linux-based internet cafes where I could ssh home and tunnel X through the connection, running my home desktop on the screen.

Sun has no way of connecting back in to work from home. Sun.Net is a sad joke, providing only access to mail and calendar and such. The servers are (or at least they were) quite unreliable.

There is a terminal app, written in Java, but instead of using something normal and usable, they used some bizarre thing which interfaced with the security cards. I can understand the need for that, but the only way to use the system was through an extremely slow and unreliable applet, or by telneting to localhost and going through several gateways (each of which had a nasty habit of hanging right in the middle of working) to finally telnet (?!) to one's office workstation. X11 was, of course, unavailable, unless you wanted to go in through the modem pool, which was limited to 28.8kb/s.

When the only way to get in and maybe fix the emergency brewing at the office is that pathetic, it's a given that there will be unauthorized tunnels in use. I experimented with a few SSH-based things myself (made extremely painful due to the temperamental SOCKS proxy), but had the good sense and courtesy to be even more anal about security than is my wont.

Oh yeah. People liked to share passwords. Within earshot, or over unencrypted voice lines.

Somebody at Sun please work on fixing this. It hurts to remember.

--

Java-based SSH1/2 client

Stick it on your web page somewhere, and then you've got a client wherever you go!

You can also try Mindterm, a java implementation of an ssh client. It works well launched from a browser. The older version of the client is GPL'ed but it doesn't do ssh2. The newer version does ssh2 but it's still in beta and they haven't decided on the license yet.

Check out MindTerm. It's a free (GPL) pure Java implementation of an ssh client. Works wonderfully as an applet under the common browsers. So the best way to be sure you can always access your account is to install this on your webserver, then all you need is a web browser with a Java runtime. This even allows you access from things like knee-capped kiosks, where all you get is a browser.

First, who said you need a big budget for "proper software"?

I don't know how many people think of it but I've become very comfortable editing html over a telnet session with vi[m]. SSH with compression turned on is even better then telnet.

• Get vim and force yourself to learn what seems to be a weird interface, once you learn it it is very powerful: http://www.vim.org
• OpenSSH: http://www.openssh.com
• If you need a cross platform SSH Client, MindTerm is rather good despite the java bloat: http://www.mindbright.se/mindterm/
• If your using php and have more cpu cycles then bandwidth then my gzip code is a quick fix: http://Leknor.com/code/

Also, sed, ps, find, grep are great little utils. I recently relized I could write quick shell scripts on the command line like this:
$ for x in `ls *.html`; do echo $x; done
I know that is very simple but it gives you an idea where to start.

Leknor

I don't know anything about wireless but you might want to check out a java implementation of an ssh client, Mindterm. It can be run from within a browser (I set up a web page to launch Mindterm and use it all the time when confronted with a Windows machine). The recently released version (14.Nov) supports ssh2. The old versions (not ssh2) were free for "non-commercial, personal, system adminstration or evaluation" use but the new version claims it will expire in 30 days. However I think the code is available (but I don't see it on the website) so one could just disable that if the previous license applies.

if you have an account you can telnet to, you can install the mindjar java applet that I got from www.mindbright.se/mindterm. It allows me to read my email when I'm at the local supermarket, which has a PC with Windows but telnet is disconnected.

i keep a mindterm page on my linux box so that i can ssh in and do stuff from any relatively modern java-enabled browser (IE >= 4, NS > 4.06). handy for checking mail from cyber-cafes while traveling. if you have a JVM installed, it'd also be a great way to get a full-on terminal window under mac or winXX. way better than the lame telnet clients that are usually available. the license is GPL, but there are some restrictions due to the RSA algorithm that's used :(

tim

Except that on Windows, ssh is not a stock part of the OS (there are /no/ free versions that I'm aware of, and even the pay versions don't seem to support tunnelling[1], etc), ...

The best thing about a Java implementation is that you can run it off anybodys computer without a lot of grumpy installation. I've always missed SSH when I've come to some random, locked-down machine.

-Lars

Internet cafes see a lot of people using telnet to access university accounts during holidays. Until the ubiquitous Windows-based net cafes around the world all get ssh, this is going to piss some people off.

For what it's worth, the PuTTY SSH client for Windows is only a few hundred K, and is a monolithic executable; it doesn't have any configuration files floating around etc.

If running your own executables is disallowed, then you have to look to other options: most cyber cafes allow Java, right? In that case, you probably want to look at MindTerm - a free (GPL'd) Java SSH implementation.

Besides which, university accounts ought to have decent security to protect root. So there are a few dodgy logins here and there. It's worth it just to be able to read your email anywhere.

I don't think there's any excuse for poor security, when it only takes a few minutes of web searching to turn up good alternatives. Also, it's not just 'a few dodgy logins' - compromised accounts get an attacker through the 'security perimeter' of the network, an easy way to get past external firewalls for example. They also provide an excellent staging post for attacks against other systems on the network.

Cheers, Nick.

Psycot|X forgot his password

Check out mindterm (a Java SSH implementation) and PuTTY (a Free Windoze Telnet/SSH)

Which quite naturally, requires an SSH client on the other end. I'm not allowed to install software on my machine at work, it's a reprimand if I do.
Mindterm SSH client. Many computers has a Java enabled webbrowser.

Given what a royal cock-up Netscape's "support" for UNIX platforms (at least Linux and IRIX) has been, using non-Windows machines for Web browsing is looking like less of an option every day. Unless you don't mind your browser crashing lots.

I've recently taken to using NT machines at university for browsing the Web, and just using MindTerm (a pure Java SSH client) to log in and check my mail. And I'm no Microsoft zealot.

Aside: anyone know whether there's a Windows Media player for MacOS?

I recommend Tera Term Pro and the TTSSH extension if you must use Windows. Or use MindTerm, which is a Java-based SSH client. I've used both, and they both work well with any SSH 1.x server. (Including OpenSSH.)

Remember all the talk about how, if Linux loses the battle over browser compatibility, it loses the war for the desktop?

This, my friends, is a large reason why.

Only two things have prevented ASPs from becoming an integral part of the standard computing experience:

A) Lack of widespread high speed networking.
B) Immature tools for representing quality interfaces over HTML/Java/etc.

The judicious use of the extensions offered in Internet Explorer 5 arguably makes somewhat irrelevant the former(there's still the problem in that it's not particularly efficient or stable to have application functionality dependant upon a network connection; but then again it's arguable a server is much more likely to Autorecover much more reliably than a desktop OS) and almost totally obviates the latter.

The only thing preventing more applications from being designed in this manner is the fact that IE5 is nowhere near ubiquitous. Don't laugh--critical applications are already being designed according to Microsoft's master plan: Dialpad.Com, the surprisingly effective free Voice-Over-IP-To-Any-Landline-Telephone, is written in Java with some kind of Windows specific extensions.

Why? Two reasons: One, Sun has utterly bungled Java beyond belief when it comes to deploying new libraries, and two, Dialpad figures (witheringly reasonably) that the majority of their users can successfully *use* Windows specific extensions.

Of course, the fact that Dialpad apparently works successfully on Netscape for Windows hints at broken not-quite-cross-platform code somewhere in the pipeline. (Probably some native methods being used.) Either that, or the system's intentionally limited. I doubt that though--Dialpad actually added detailed Linux Masq instructions to their site. (Joy!)

Dialpad, incidentally, is a fascinating case study in how an ASP can operate. They are actually entirely standards-compliant, using H.323 to move their voicestreams around. However, they implemented a system they call Split-323(patent patending, which is slightly silly since the core concept is found all over the place) where most of the heavy H.323 lifting is done on the server side, with only the voice codec'ing remaining for the client to execute. Quite nifty, and is likely the general paradigm we're likely to see for systems that traditionally required binary application deployment--a small application, usually net-deployed, that executes whatever specifically requires a presence on the individual host(in this case, digital audio in, out, and compression) with the rest being left on some server out on the global Internet.

I said this is what we're likely to see. I didn't say it's the greatest idea known to man.

On the one hand, ASP style deployments work beautifully for applications that are inherently communication oriented. Dialpad is about connecting to other phone lines. MindTerm, the mind-bogglingly(sorry) cool Java deployed and amazingly full featured and GPL'd SSH client, brings high end communicative security in package that requires no installation beyond accessing a web page.

But do we really want non-communication based applications to require a network connection?

Pundits like to go on and on about how broadband is going to be all over the place in a few years. Bruce Schnier, author of Applied Cryptography and creator of the excellent Blowfish encryption algorithm, observed that while high end processing power will increase on and on ad infinitum, the low end never goes away--it just gets smaller, deployed for never-before imagined applications, etc. Smoothly scaling performance from the high end to the extremely low end is, therefore, a value. I posit that bandwidth is much the same way--maximum speeds will get higher and higher(indeed, in the course of the last 5 years I've gone from a 2400bit link to a 1,500,000bit link!), but there's always going to be something puttering along damn slowly and not entirely reliably. Look at the proliferation of wireless technologies proudly proclaiming speeds that are laughable in wired realm but are actually pretty cool once made wireless.

It's the wireless side, specifically laptops, that suffer the most from the ASP paradigm--wireless bandwidth is far more scarce, and many applications already deployed on them are intrinsically non-communication oriented. To force laptops to initiate connections whenever basic applications are to be used removes much of the freedom intrinsic in a battery powered, portable computing environment.

On the flip side, I'll be the first to admit that laptops have been made much less free by the degree to which communicative uses have taken over the actual applications people run. The concept that a laptop would become almost entirely useless, though, without Net.Mommy somehow being able to tunnel a link to it is rather bothersome nonetheless.

Security is a far more pressing concern. People fail to grasp the vast amount of security embedded in the simple fact that their files are located on their hard drives, in their homes, on a machine that is running no remote access services and is not permanently connected to the Internet. This security is eroded constantly by a disturbingly large number of intentional(in the RealNetworks fiasco) and unintentional(insert browser vulnerability here) ways, but literally moving the location of an application from onsite to a remote location introduces an incredible number of possible points of attack, from data corruption to privacy violation / industrial espionage.

A perfect example: GPS-Assisted Destination Routing. Take something like Mapquest.Com vs. a traditional CD-ROM based Street Atlas USA.

Mapquest requires no CD-ROM sale, would never have out of data information on the marketplace, could probably add a Dialpad-style applet to receive location data from a GPS receiver, and would probably require some form of wireless connectivity a la (the soon to be ridiculously oversubscribed) Ricochet service.

In comparison, Street Atlas USA does require a CD-ROM sale, would eventually suffer from stale data, would have GPS easily integratable with the core application, and would require no (expensive) wireless networking to function.

How easy it is to ignore that Mapquest would be receiving up-to-the-minute accurate positional and destination data for whoever's using their service. Combine the ridiculously pitiful privacy standards that Corporate America operates under with constant pressure from VC's to find sources of funding and the ease at which Net vendors can pass off security and privacy lapses as "accidental occurances which have already been fixed" and suddenly the ASP picture becomes much more dangerous for the end user.

The bottom line is, when it comes to security, trust, no matter how great, is no competition to a brick wall: Security Through Impossibility is simultaneously the simplest and most effective means by which sensitive data can be protected from malicious agents. ASP's demand much trust to be usable, and while benefits from ease of deployment and harms from reduced functionality and accessiblity are significant concerns for any business considering employing an ASP, one has to wonder at what times it is justified to remove the brick wall inherent in on-site deployed solutions.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

I'm not surprised VB is so popular. Look how many Windows desktops there are out there, and look at how god-awful Visual C++ code is. VB has a pretty nice development environment, and is (apparently--I'm not a VB guy) great for quick and dirty Windows GUI apps.

The fact that the entire language seems to me like a gigantic glueball(in the sense of it binds everything together, it picks up some rather shocking cruft, and you'll sometimes get stabbed by something locked inside) doesn't take away from the fact that glue can be great for whipping things together--just ask TCL developers.

Past that, I'm not surprised Java hasn't overtaken C. Beyond the whole speed factor, C is just alot cleaner for the non-expert programmer to mess around in. Particularly when it comes to making patches to existing codebases, there's just so much less to need to figure out in C than in a fully object oriented language such as Java. Granted, when C is forced to do things C does not like to do, C gets very crufty(thus the recent complaining I've been hearing about lsh's pseudo-object system), but a) There's a massive codebase out there written in C, b) There's a massive amount of deployed C code(this isn't the same as a), and c) C is less daunting for a moderately skilled programmer to mess with.

However, I must say that the reason Java hasn't displaced VB down to third(VB/Java address a different market than C, if you think about it) is that Sun royally and utterly bungled its deployment. VB projects "compile" down to an .EXE and a few random .DLL's that might have to be installed. C code compiles to executable files and some libraries that you probably already had anyway.

Java development with the JDK is laughably awful, and will someday be a textbook example of how not to burden your coders and your users.

From what I've seen--and I'm sure the experts can enlighten all of us further--merely getting javac to function(got everything in the right folder? Got your path environment set right? Sacrifice the correct barnyard animal?), then executing that Java app(better nuke the henhouse just to be sure) is far beyond the difficulty in even writing a simple Hello World!

The fact that code never compiled into a single file didn't help either--web deployment was a mess, with forty web server connections for a single semi-useful app. JAR finally fixed this, but THAT standard got mangled by CABs.

Don't even get me started on Code Signing--there are three, three, three ways to go for this little project.

Alot of the problems wouldn't have been as significant if javac was as straightforward to play with on your average Linux distribution as, say, gcc. The non-free aspect of Java destroyed this possibility--and Sun's new "Gotcha Source" License isn't helping.

Java came out of the gate hard to install, harder to deploy, slow to load, and slower to run.

Things have gotten better--J++ and the MS VM have been instrumental in this regard--but the core usability of Java is farrrrr less than VB, and even less than C.

Actually, I had just about given up on Java until I found the one company that has truly understood the promise of Java. Mindbright. I've already written about these geniuses here, but suffice it to say, the fact that there's now a extremely high quality Java deployed SSH and SSH-VNC(VNC into those hosts behind the IP Masq, all via SSH) solution is amazing, and caused a complete reversal as to my opinion of the viability of Java as a useful platform.

Using something written in a language on a daily basis will do that. ;-) So, yes, overall I'm still quite hopeful.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

A curious thing happened on my way to Freshmeat.

Where the hell did Mindbright come from?

Mindbright, for those who don't know, makes the GPL'd Mindterm java applet. It's an incredible SSH client written in 100% Portable Java and has completely changed my perceptions of what a quality Java applet can do.

Suddenly, I have a SSH client at any web browser I sit at. And it's fast, to boot.

If that wasn't enough to impress me, MindVNC is a merge of their SSH classes and the GPL VNC Java client. (VNC is essentially a remote frame buffer--the display is rendered or copied into a virtual screen then sent over the network.) You authenticate against the ssh server that hosts the Java app, and you can VNC to any terminal the remote sshd can access--yes, this means you can connect to your bastion IP Masqing host, then VNC to some 10.* machine behind the firewall, all through a secure link.

The relevance to the story is in simple and speedy deployment of tools--any and every machine with a Java VM can immediately and securely access both text and X based applications with minimal deployment pain. This exceedingly low pain for large scale client deployment via Java may actually benefit VNC in surprisingly powerful ways. Since the VNC system has been ported all over the place, from svgalib linux to windows, and as it poses an open source, well tested, very portable, and highly functional remote access platform, it may just end up becoming a formidable force as the years go on.

Those who don't think projects should be allowed to fork--at all--need to see the amazing work that Mindbright's been allowed to do on the shoulders of the GPL. (The analogue to scientific development wasn't accidental.) More work is left to be done--the Mindterm client could use telnet support, and VNC could seriously use a "single app" mode that sizes the desktop to that exact size of the remote application, translating resizings on the client to resize attempts on the remote app.

The seed of possibility is definitely there, though.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Before I say anything, I want to commend Hannibal on an absolutely excellent article that clarified issues I thought I understood and illuminated much of the technological history behind the technology we each use every day.

I am completely impressed.

That being said, I'd like to take a moment and theorize on the direction microprocessor design is likely to go. This is my theory; you're welcome to disagree and in fact eagerly await commentary from those far deeper in the industry than I. Insert Slashdot Self-Correcting Nature here.

Of all the chasms in the computer world, there are few as vast as the speed differential between general purpose processors programmed to execute a given task and hard-coded ASICs(Application Specific Integrated Circuits) designed to meet the functional needs of a given process. (OK, granted, Internet -> Local Network -> Hard Drive -> System Memory -> Processor Cache -> Processor Registers is pretty vast too, but cut me some slack here.)

Telephony is a joke without ASICs--I haven't found a voice over IP solution that operates in software well enough to even be used as a room to room intercom over a 100BaseT Lan--but it's actually reasonably lag-free with hardware encoding.

Similarly, huge banks of boxen rendering frames for movies became significantly less impressive to me when I realized how many banks of Pentium Processors it would take to match, say, a single Voodoo 2. While, in recent times 3D Rendering has gotten shots in the arm on the general purpose x86 architecture via both MMX and KNI, the order of magnitude difference in speed makes CPU rendering of realtime 3D graphics almost useless.

(Then again, Sumea is probably the single coolest thing I've done with Java, short of Mindterm.)

As I observed in the Amiga newsgroup, shove a couple of custom ASICs in a box and you can run a highly competitive multitasking OS in 512K of RAM, with unmatched graphical support to boot.

But ASICs have their limitations--while they're fast at what they do, they're extremely inflexible. You can't merely program in a new transparency algorithm, nor implement Depth of Field in an architecture that totally lacks it. The inflexibility of ASICs dooms their long term viability.

CPU's are flexible but slow, ASICs are inflexible but fast. It's a dichotomy the industry is on the verge of smashing.

I dub the coming processor design specificiation(which, as the article correctly noted, is all RISC/CISC really are) XISC, for eXtensible Instruction Set Computing. XISC essentially specifies that the underlying computational structures--be they microcode or raw gate arrays--ought to be dynamically reconfigurable to meet the needs of the process.

Just as the lack of a quick bilinear filter function(SIMD stuff) on older Intel chips doomed them as far as efficient 3D in relation to customized ASICs, the ability to insert such a command directly into the internal microcode of a processor has a theoretical chance of executing at extremely high speeds for a non-dedicated processor.

Transmeta, also known as the only reason many people willingly acknowledge the US Patent Office, appears to be spearheading the XISC drive. Their patents refer to technologies that automatically cache microcode translations, that provide backwards-flow in case of a broken emulate, and so on. They've often been "accused" of developing a chip that can emulate any chip--in the XISC context, a chip optimized to execute the instruction set most required by any given process.

If you accept that performance drops in the orders of magnitude are suffered when a processor lacks the appropriate design for a given set of requests, it's quite obvious that intelligent designers seeking to execute a quantum leap in system performance would try to allow processors to acquire any necessary designs to achieve much higher speeds.

Of course, most of my chip designer friends would be happy to remind me that much of the speed of ASICs comes from their hard coded nature--the literal gates correspond to whatever output is desired, no translation is necessary.

Of course, here's where FPGA's come in. Field Programmable Gate Arrays are chips whose internal gate structure can be rewritten on command, sometimes many thousands of time per second. They can't be clocked as fast as true ASICs, nor are the yields as high, but one quickly morphing chip can do the job of three or four in a digital camera. With at least one company(someone give me a name!) developing a language for programmatically defining instruction sets for a FPGA processor, the technology for XISC is obviously in development.

Ah, but not all is not fair thee well. In fact, while on the topic of 3D chips, the Rendition Verite chipset had a programmable RISC core, and the chip ended up failing because it could not scale in speed like 3DFX's Voodoo could. Developers could write new 3D instructions, but didn't (in general) because it was just too hard. (Yes, Carmack did.)

That's why there's such a powerful force towards automation in this XISC evo/revolution, such as the FPGA language and Transmeta's automated Microcode translations that stay in memory so as to speed up future similar instruction requests. In an ideal world, a developer merely compiles a chunk of code that profiles as heavy usage directly into CPU microcode, or at least specifies in some way that a given routine ought to be run through the "special ops" part of the system.

Whether the world will become ideal is a point of question. Whether we will have instruction sets that morph is almost obvious, it's just a matter of when will the bridge between ASICs and CPU's finally be resolved.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com