bhenc

I'll leave this here: https://www.slideshare.net/iammutex/what-every-data-programm... https://www.safaribooksonline.com/library/view/the-data-sess...

TL;DR Disk IO is pretty much a black box in virtualized environments. All the cool stuff you can do with disks (and memory, and tmpfs) to improve performance seems worth hosting your own hardware.

Personally I'd just read everything Ted Dziuba wrote and rethink how much "Ops" is dying. http://widgetsandshit.com/teddziuba/archives.html

Maybe it's just being replaced by a bunch of code to fix problems caused by "cloud" hosting performance bottlenecks. I'm not saying this is necessarily bad, but you should be aware that you're probably trading time managing and picking hardware that suits your needs for additional coding time.

I think it is unfair to attack the grsecurity guys like this. They've been providing their patches free of charge for years only to have their work abused.

I mean, this whole situation seems a lot like the one described in the following articles, and afaik RedHat is still not facing any lawsuits: https://lwn.net/Articles/432012/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracl...

Now RedHat has the benefit that they claim they're "upstream first", but afaik ASLR originated with the grsecurity guys, so there is grsecurity stuff in the vanilla kernel. Is ASLR snake oil?

I don't see how the situation is different between how grsecurity did things and RedHat. Between going out of business and working on the boundary of the GPL, they chose to stay in business.

More importantly, how would you deal with publishing under the GPL and making money off of it? This whole discussion reminds me of this article: http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-e...

The way things are going, the best direction to take if you want to produce GPL code is to have another job unrelated to programming to earn enough to code in your free time. It's really sad if you think of the megacorps that are making billions off of FOSS.

I'll end up with a quote by Steve Jobs: By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations? http://widgetsandshit.com/teddziuba/2010/05/the-future-of-ap...

Okay.

The equivalents to steps 1-11 were done by the Wormhole authors when they created the rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have to trust the rendezvous server.

Operating scp with a working ssh server is as simple as working with wormhole:

To push:

scp foobar.txt tmp@www.example.com: #equivalent to wormhole send

To pull:

scp tmp@www.example.com:foobar.txt . #equivalent to wormhole receive

To revoke access, you simply change the password, instead of deleting the user account. In fact, the steps you mention are what I already have by default on most of my machines, so there's 0% extra effort. I got rssh working in five minutes.

Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.

Compare explaining the above two commands to explaining virtualenv and pip. On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also preinstalled on their system.

So yes, I do rejoice in the simplicity.

I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.

That is a good use case.

Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account?~

Assuming that you have openssh and rssh installed, you bootstrap like this: useradd -m -g users -s /usr/bin/rssh tmp passwd tmp edit /etc/rssh.conf and uncomment allowscp Share the password with the party you want to exchange data with. Make sure your ports are open.

See: https://serverfault.com/questions/197545/can-non-login-accou...

The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.

You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted, and extends to cover other use cases much more easily (rsync, VNC, etc.).