mediagoblin-userops
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Userops] Why is it hard to move from one machine to another? An ana


From: Blaise Alleyne
Subject: Re: [Userops] Why is it hard to move from one machine to another? An analysis.
Date: Sat, 11 Apr 2015 00:49:25 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

On 09/04/15 04:59 PM, Christopher Allan Webber wrote:
> Hey Jessica, some strong points in here..
> 
> Jessica Tallon writes:
> 
>> Hey,
>>
>> Firstly, I agree moving from one server to another is difficult. Moving 
>> from workstation to workstation is also difficult though. You can just 
>> rsync your home directory if you've opened your firewall and know how 
>> to use rsync which for both of us and likely the rest of this ML is 
>> fine, but not for most people. There is also the problem of moving 
>> software which can be a huge problem, you seem not to find this an 
>> issue but for me I still find months later I'll be missing software I 
>> need. Then you have the problem that systems get very complex, you have 
>> postgres running on your workstation, you have several users, wifi 
>> network credentials, you probably have a bunch of different 
>> repositories enabled, python virtualenv's breaking.
>>
>> [...]
>>
> 
> You're right of course, I've simplified the "deploying between desktops
> stuff" and the "backing things up" story.  Things are easier *for me*
> because:
> 
>  - I know how to use rsync (not everyone does, and that's technical
>    privilege as a prerequisite... not exactly userops!)
>  - I've simplified my setup to only use mostly one workstation.  I used
>    to use multiple and sync tons of directories all the time between git
>    and git-annex, but it was a chore.
> 
> This is another reason, often overlooked, for the rise of "cloud" stuff:
> people have multiple machines, and keeping them in sync is hard.  Easier
> to have one server host those files in the first place and hope the
> company never shuts down, or use a virtual directory a-la dropbox (the
> free and much better alternative is probably git-annex, but that could
> be a bit easier to set up yourself... it's probably the easiest solution
> we currently have though... also, it can't scale up to millions of
> files, as I found out when looking into using git-annex for my maildir
> syncing to replace offlineimap, due to a limitations in git's indexing
> behavior... not git-annex's fault! :))
> 
> But anyway, yes, it's not actually easy for workstations.  I do think
> it's *comparatively* easier, if you tie down constraints to "knowing how
> rsync works" and "using just one machine".  That's a lot to ask though.
> 


Jessica's point made me think of two acquaintances of mine I spoke to in a
single day this past week, though both proprietary OS users.

One is a college student who said she bought a new computer because something
was broken on her old one and it was just easier to get a new machine than to
try to figure out how to fix it or whether it was fixable. I hear this a *lot*.

The other is a high-powered lawyer who brought his home desktop into the shop
after it could no longer connect to the internet after a power surge in his
house. Good guess that the power surge was the problem... but it was actually
the network switch in the basement that was fried. But the guy in the shop said
he found some sort of Windows malware, and seems like he did a total fresh
install and copied all of the users files to another hard drive or partition.
This user gets his computer back, and even after the network switch was
replaced, he couldn't use it because, for example, he didn't know why Outlook
wasn't set up (didn't know how to copy his data files back to the right location
-- or that there is even such a thing as an Outlook PST file -- and configure
his POP3/SMTP email account settings again). No one else in his family (wife and
5 kids in their teens and 20s) knew what to do either. He didn't even know how
to copy his files back from the D drive to the place he'd normally look for 
them.


I guess my point is: moving workstations is not only something that isn't easy
for the average user, but it's something than many people seek *professional*
help with, or at least seek the help of a knowledgeable friend or family member.
Even for stuff the people on this list would probably consider very simple, like
copying files from one machine or location to another, or configuring an email
client. Nevermind workstation backups, which in my experience are pretty much
non-existent or at best *very* infrequent for average users...

You can go to your local computer shop and buy a new machine or get them to
reinstall Windows (no matter what the problem actually is), but where would you
go for (affordable) help to move your home *server* software from one machine to
another? And how many friends or acquaintances for people who aren't on a list
like this would know how to help you move your home server?


But maybe that's not the point... maybe the target audience for userops is
*still* a bit more of a technically savvy audience? But the goal is to lower the
bar from "developer/sysadmin" to "somewhat technically savvy computer user"?

This changes my thinking (misconceptions?) about userops... from the
impossibility of making something that the average user could actually use,
towards maybe just significantly lowering the bar.

For me, recognizing that there are still many users for which a total dream
userops setup would *still* be too complex and inaccessible, it highlights for
me that userops efforts also still really need to be about "self-hosting" for
*other* people too...


Which suggests a final thought back to Chris' original post: one more thing
that's so hard about moving from one server to another is migrating *other*
users! e.g. when changes are required to client configuration, or when you're
moving someone else's data and you can't immediately tell on your own if things
are complete or normal...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]