
I moved to Linux and it's even better than I expected - steven
https://medium.com/backchannel/i-moved-to-linux-and-it-s-even-better-than-i-expected-9f2dcac3f8fb#.s1lp4nf0d
======
webwanderings
> Chromebook sold by various manufacturers. But it comes with more
> limitations, and requires users to be totally comfortable — I’m not

Tell that to the grandma. Believe me, I'm no Google Chrome fan, but Google
Chrome OS is what Linux would never be. It is a completely different target
audience. Microsoft, and Apple eventually, should be worried (and they are
most likely worried - given the number of cheap Windows 10 laptops I have been
seeing lately).

~~~
Piskvorrr
The biggest sign of MS worries is the current push for Win10 - aggressive to
the extreme, right up to practices that I personally consider malware ("you
_want_ that upgrade, and admit that you'll _like_ it. Your 'no' means nothing
to us. Here, let's re-enable that Clippylike abomination of GWX.exe; trust us,
_that 's_ what you actually want.").

------
commentzorro
_> No one should ever have to open a command-line window and type “sudo apt-
get update” or other such instructions._

Hear Hear. Command line support over the phone is a nightmare.

~~~
Piskvorrr
...or "press Windows key, type 'cmd', press Ctrl+Enter, confirm the dialog,
type 'regedit'" \- you know the drill ;)

OTOH, with a little bit of forethought, command-line support over the phone
has been unnecessary for years (screen+x11vnc+autossh+openssh-server). "Just
click that icon over there...good. Now I can see both the console and the
display;" I'm aware there are such commercial options for any OS - in Linux,
this is quite simple to do by yourself.

~~~
commentzorro
How do you get past needing to explain to someone how to port forward their
comcast/verizon/etc. router to get to that point in the first place?

~~~
Piskvorrr
I avoid it :) I had a lot of control over the HW+SW deployment, hence the
software was preinstalled (although I could imagine scripting an on-demand
installer as well). With reverse SSH (the workstation connects to a server
outside the NAT), no port forwarding is necessary. Although the tunnel-in-
tunnel method used introduces additional network overhead and latency, it is
acceptable for an occasional remote session (VPNs were considered, but
ultimately on-demand userspace tools without a need for permission elevation
were chosen), and has performed admirably over a wide variety of connections
;-)

Specifically:

\- the workstation has screen, autossh, openssh-client, openssh-server and
x11vnc preinstalled.

\- there's a (local user-initiated) script, launched via a desktop icon

\- that opens a GNU Screen session

\- inside the screen, it autossh-s into a limited account on a jumphost and
remote-forwards a (preconfigured) 127/8 address:port back to 127.0.0.1:22

\- this makes the workstation's SSH server accessible on the jumphost

\- (actually, several jumphosts are used - not everything is accessible from
everywhere on the Internet, but I've yet to see a case when no jumphost can be
contacted)

\- remote user connects to workstation via SSH to jumphost and thence the
forwarded SSH tunnel

\- localforwards a port for a VNC connection

\- runs x11vnc at workstation

\- connects to x11vnc via the localforward

\- and/or attaches to the GNU Screen

Voila, console and desktop access, with file transfer also available. The
"remote" part is a single script, based originally on this script for VNC-
through-SSH:
[http://so.piskvor.org/87443/vncssh.sh](http://so.piskvor.org/87443/vncssh.sh)

SSH provides _enough_ security (pubkeys), Autossh reestablishes the connection
if needed.

