I'm not sure how it requires a HOWTO, at least if you have Unix/Linux on both ends. Install ssh client on desktop, ssh server on remote host; make sure ssh server is running on remote host. Make sure both are configured to allow X-Forwarding (many installations disable this by default). Have X server installed and running on your desktop machine--run Gnome, KDE, Xfce, whatever you like. Install xterm on your remote host. Call up a local terminal in your desktop X. SSH to your remote host. Echo $DISPLAY. It should be "localhost:10,0", or localhost something. If not, something is not setting up correctly. If it is, issue the xterm command. See the remote xterm pop up on your desktop. Doling it from a local terminal is just to simplify troubleshooting; once you've confirmed it's working, issuing "ssh remotehost xterm" from launcher will do just fine.
Anything that kills bacteria is an antibiotic. If it kills people too, it's also a poison, and thus not a very useful antibiotic, but it's still an antibiotic.
I can't speak for your installation. I have a Debian remote server without X installed, without xvfb installed, and I can run xterm from it on my local X server without problem.
In order to run an X program on a headless box on Debian I had to install xvfb (which is a "fake" X server), which pulled in x11-common, xserver-common, xauth, and a few other minor X packages. It's certainly not "full X", but it's enough of X that I'm not sure I can say I'm not installing X.
Generally, no, you don't have to install xvfb. There are apparently some badly designed X clients that somehow manage to require a pseudo-X server local to them, even though they're not using it, but properly designed ones (the vast majority) do not.
In fact, it's not even appropriate to say you're installing X on the remote host, because you're not. X is on your desktop machine, the remote host just runs an X client that accesses it.
The question I (personally) have is how safe X forwarding over ssh is.
It's data run over an encrypted ssh connection. The remote host is not accepting any connections other than the one you used to start your ssh session to do this. Your desktop is not accepting any connections at all to this. It's not any different in any essential security aspect from using scp to copy files.
You are blaming the media for reporting the result of polls?
This is not reporting the result of a pool. This is reporting a fiction. This is declaring a winner when the result is in fact a tie, becuase they have to have a winner.
It works very well indeed, but in 4.0.1 and 4.0.2 it only works with WiFi.
If it was simply nonfunctional in 3G, you'd have some justification for this statement. Something that *crashes the whole phone* when you try to use it in 3G cannot, under any standards, be said to "work very well."
Back in the days DOS, most non-trivial applications where bigger then the OS.
MS-DOS wasn't an operating system; it didn't have hardly any of the functions that even back then were regarded as basic to an OS. MS-DOS was a program loader strapped to a command interpreter.
Same thing they did before mass media made it possible to have a career as a model. They haven't come up with a computer that can do the world's oldest profession yet.
If you log them into the app instead of a window manager, then crashing the app will return them to the login screen--for which the only logon they know will just bring up the app again.
I'm afraid if you want it actually locked-down, you're pretty screwed. You can't really disable things like switching to a tty with ctrl-alt-f1 without "changing the OS configuration."
Stopping all the getty processes would do a pretty good job of sealing up that hole. There's probably a fancy way of disabling the hot keys as well, but if there's no process to log on with, I guarantee there won't be a problem.
Slashdot Mirror
I'm not sure how it requires a HOWTO, at least if you have Unix/Linux on both ends. Install ssh client on desktop, ssh server on remote host; make sure ssh server is running on remote host. Make sure both are configured to allow X-Forwarding (many installations disable this by default). Have X server installed and running on your desktop machine--run Gnome, KDE, Xfce, whatever you like. Install xterm on your remote host. Call up a local terminal in your desktop X. SSH to your remote host. Echo $DISPLAY. It should be "localhost:10,0", or localhost something. If not, something is not setting up correctly. If it is, issue the xterm command. See the remote xterm pop up on your desktop. Doling it from a local terminal is just to simplify troubleshooting; once you've confirmed it's working, issuing "ssh remotehost xterm" from launcher will do just fine.
Anything that kills bacteria is an antibiotic. If it kills people too, it's also a poison, and thus not a very useful antibiotic, but it's still an antibiotic.
I can't speak for your installation. I have a Debian remote server without X installed, without xvfb installed, and I can run xterm from it on my local X server without problem.
Generally, no, you don't have to install xvfb. There are apparently some badly designed X clients that somehow manage to require a pseudo-X server local to them, even though they're not using it, but properly designed ones (the vast majority) do not.
In fact, it's not even appropriate to say you're installing X on the remote host, because you're not. X is on your desktop machine, the remote host just runs an X client that accesses it.
It's data run over an encrypted ssh connection. The remote host is not accepting any connections other than the one you used to start your ssh session to do this. Your desktop is not accepting any connections at all to this. It's not any different in any essential security aspect from using scp to copy files.
People have started putting good design into websites? When did this happen? Why haven't I noticed it?
Myanmar has made minor, if promising, moves in a democratic direction. "Partially democratized"? Not hardly.
This is not reporting the result of a pool. This is reporting a fiction. This is declaring a winner when the result is in fact a tie, becuase they have to have a winner.
If it was simply nonfunctional in 3G, you'd have some justification for this statement. Something that *crashes the whole phone* when you try to use it in 3G cannot, under any standards, be said to "work very well."
...but not the one they need right now.
Forgotten, hell. Picasso said it--"Good artists copy, great artists steal."
For a lot of specialized software, you don't have a choice. You buy it and use it, or you can't do business.
They're first becuase they're first--which means they're powerful, which means you don't piss them off by trying to make them *not* first.
At least you can read the complaint. You get a handle you can use to fight back. China? "Nope, you can't see it. No, we're not going to tell you why."
"These 5 Technologies Belong to Users--until they break, at which point you will of course be expected to fix them. Isn't that what we pay you for?"
So it's obvious. So why aren't you doing it? And why are you dismissing it out of hand? I'd never leave a valuable laptop sitting in a car like that.
Oh, and a crappy file system. You got that too.
MS-DOS wasn't an operating system; it didn't have hardly any of the functions that even back then were regarded as basic to an OS. MS-DOS was a program loader strapped to a command interpreter.
Same thing they did before mass media made it possible to have a career as a model. They haven't come up with a computer that can do the world's oldest profession yet.
The point is, given the materials, you should be able to make a template yourself from scratch in under half an hour.
If you log them into the app instead of a window manager, then crashing the app will return them to the login screen--for which the only logon they know will just bring up the app again.
Stopping all the getty processes would do a pretty good job of sealing up that hole. There's probably a fancy way of disabling the hot keys as well, but if there's no process to log on with, I guarantee there won't be a problem.
"Don't worry! You'll be fine for the next month...probably..."
I suspect none, because Adobe wrote the spec.
Or maybe it's just that their service techs are in more bars.