Well now you've changed the requirements. Your original statement only mentioned serving from a NAS not specifically about serving from a NAS via SMB. Serving from NAS over HTTP or Plex works fine for me.

SMB on the NAS is also a, "remote agent off of the player unit", if you want to get technical about it. Turning on HTTP on the NAS (at least for the one I am using) was no easier or harder than turning on SMB. There is no server piece to Roxsbox as there is for Plex except a simple httpd.

But yeah, there is no built in client for either SMB or HTTP. Adding one for HTTP isn't rocket science but evidently it bothers you more than it bothers me. To each his own.

Those are nice, but the problem I have with all Android based solutions is that there is no free Hulu. If it's free on my laptop it should be free on my tablet and STB.

So much for that... This one is broken now too....

This solution bypasses Google's Chromecast SDK entirely.

Plex can run on several brands of NAS.

Either that or use Roxsbox on Roku and serve it from your NAS using http.

My NAS can do both and I stream local content on Roku all the time.

percentages of abuse amongst priests is disturbingly high compared to other professions

Source? Studies? Numbers?

It's actually lower from what I've read. Kids are much more likely to be abused by family members or teachers.

I was tempted to go that route but the lack of free Hulu on Android was a deal breaker. H+ just isn't worth it IMHO.

To me this kind of crap (limiting / charging for things that are unlimited / free on my desktop just because it's a phone or tablet) is the biggest problem for using Android as a desktop OS. That and all the apps trying to spy on you with unnecessary permissions are making Android privacy hostile, which I don't want in any OS.

Exactly what I was thinking. If it, "never touches the disk", how does it reload if you turn the machine off and turn it back on? Saving itself to the BIOS?

All your children are belong to us! Slavery for the 21st century...

I have an ancient version of this book (same author) from back in the 1980s when it was called A Practical Guide to Unix System V from and it's still pretty useful...

I hear what you're saying (ie. your opinion). I just don't buy it.

I am consistently the top performer on my team and I work from home. Go figure... Been doing it this way for almost 20 years on market leading commercial products. Go figure...

Low latency? We are all on a multiperson Skype conversation all day long. Type and be heard by the whole team. Hit a different button for a conf call. Hit another button for a video call. Neither I nor my employer are seeing the negatives of which you speak. I don't spend any time fighting it. It just works.

No matter how much technology you throw at the problem (IM, video, holograms), the reality is you throw away practically all the possible gains when team members are remote.

We do Scrum with remotes. It's not a problem if you set up a good electronic communication infrastructure and have the right culture.

This sounds more like a process problem. When I first started my VP wanted daily reports, which I provided. No different than what I would report at a daily scrum. For me, it was an opportunity to show the higher ups what I could do. After a while they just dropped the requirement because they could see I was getting a lot done and they were no longer worried about me. I think my performance made them reconsider their telecommuting prejudices.

My manager meets with each of his direct reports individually for 30 minutes each week at a regularly scheduled meeting time. If you're in the office, he meets with you in his office. If you're remote you meet on a video call. Even people in the office typically only come in 3 days a week to get more uninterrupted time. In addition the team has a group conversation on Skype that never closes. It works well for us. Everyone, in the office or not, also has to submit a weekly status to their manager and the VP.

Managing remotely might be harder. I would not know.

I do agree with the folks here though that have said that if your employees like what they are doing, you don't have to worry about them goofing off. If they are professional, same thing. Not everyone has self discipline and self control.

Yes, all this is theoretically possible via IM, (even the sketching, with special equipment)

There are lots of shared white board web sites and methods for remote desktop sharing. You really have to use pen on board rather than draw it on the computer? I guess it just depends on what you are comfortable with but it's quite common.

the instant, high-speed collaboration just isn't possible remotely.

Maybe try multi-person remote screen sharing (eg. join.me) combined with a multi-person IM audio call or a free webinar type service? I do this kind of thing all the time to help people fix problems in their code and watch their code in their debugger. Very possible.

I can talk much faster than I type

Because everyone knows that there is no much thing as IM with video / audio call capability... Are you living in 1990 or something?

there isn't any concept of "overhearing" a colleague discuss something if you are on other sides of the country.

We use a team wide Skype conversation that is always open. If you're having a problem and can't find a similar issue in the bug database, ask the team. If no one responds, ask your manager. Hopefully they have some idea of the problems their people have solved. I know it's not 100% the same as random overhearing people, but it works for us.

Yup. We do the same thing except with groups on Skype. The team conversation is never closed. Multi-person audio call is just one button click away.

Been trying to get them to try Google Hangouts for the 6 way video but everyone is already on Skype.

Skype screen sharing sucks (image quality is bad), but join.me is clearer and good enough for us at the moment.

All free as in beer.

All devs are using Mac OS X. I seem to recall the last time I tried Skype on Linux that it was not as nice as the Win / Mac clients. So maybe not great for a Linux shop.

Honestly though, we had the same kinds of problems in the big multinational company I used to work for, even without telecommuters. I had people on my team in NY, DC, Bangalore, UK, and Charlotte that all needed to work together.