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.
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.
You sure? At Google, network storage has been faster and more reliable than local disks, for years. See bradfitz' talks about the dl.google.com rewrite.
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.
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.
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.
> 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.
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.).
Instead you get to pip install. But pip isn't installed. easy-install pip? What's easy-install - it's not there? (brew|yum|apt-get) disttools. Forget this... download get_pip.py, run python get_pip.py... Some error about libsodium now? Where do I get gcc for Windows 10 again?
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
sysadmin here in MAD world using homebrew since Lion. First thing I did when I got in this morning was to pull out my personal MBP and install magic-wormhole.
So... 'brew install rssh' is bad and kludgy, but 'brew install magic-wormhole' is easy and light? And hey, if you're not on a mac, you have to also install a bunch of other deps too.
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
Honestly, even if I have both rssh and magic-wormhole installed already, just creating a new user that can read (some of) the filesystem is already orders of magnitudes more hassle.
I'm not gonna argue against that. Using pip-install certainly limits our current audience to people who are comfortable with python packaging tools, which basically means python developers.
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
A stand alone static binary that does not depend on system libraries.
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
This is true but not completely. You will only get pip when you install the binary downloaded from python.org. On osx, people use brew, on Debian, they use apt. It is most likely only Windows people will download those binaries but actually they use Anaconda, WinPython instead
I'm actually getting tired of package managers reinventing the wheel (literally) every time they want to install something.
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
if only to address the dependency issue, one can rewrite the magic wormhole in go, then do cross-platform compilation and distribute the standalone binaries
UPnP could have helped with the router bits and dynamic DNS could help with the internal/external bits. https://upnp-portmapper.sourceforge.io is fun but UPnP isn't enabled everywhere reliably, and explaining how to do that + ensure it's working is probably only going to work for someone who would know what homebrew is.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
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.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.
That doesn't make sense. The client needs the passcode to read the file, and that passcode is sent out of band. The Relay server can't simply "play the role of the client" and steal the file.
When both parties are in a corp network (eg across companies) you would need a server anyway. Many either offer a FTP server or have switched to Accellion (which is kinda cr.p, and full of security holes)... so this is a nice, fast and secure alternative.
When both parties are in a corporate network their IT policy would forbid using magic wormhole. They'd have to use the file-transfer program managed by their IT department.
Surprised no-one has mentioned socat ('netcat on steroids') in this context, which is what I use to quickly transfer files, especially in closed network contexts.
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.