Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenDrop: An Open Source AirDrop Implementation

github.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: OpenDrop: An Open Source AirDrop Implementation

#161

Post by oefrha »

bborud wrote: post #142

God, I wish people would stop using Python for these sorts of things. It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos. Python is a nice langu…

Gosh, I wish people stop complaining about the language choice whenever cool project X happens to be written in a pet peeve of theirs.

Re: OpenDrop: An Open Source AirDrop Implementation

#162

Post by oefrha »

cyphar wrote: post #134
mxuribe wrote: post #81

It is 2019, and it is quite surprising - and disappointing - that we STILL haven't universally solved the means to easily, securely, and (yes, I'll use this term again) universally share files. I wish we could share files in a peer-to-peer fashion securely without hindrance of mobile platform, nor blockage of network MiTM, etc.

Have you taken a look at magic-wormhole[1]? I've started using it recently and it's insanely easy to use. It does have a centralised signalling server for key exchange between peers, but it does attempt to do peer-to-peer data transfer (only falling back to a TURN-style relay if both clients are behind NATs and aren't on the same local network). An explanation of the cryptography and design was given at PyCon 2016[2]…

I’m a happy user of magic-wormhole myself. It doesn’t solve the problem of sending files to phones, though.

Re: OpenDrop: An Open Source AirDrop Implementation

#163

Post by hultner »

bborud wrote: post #149
djsumdog wrote: post #144

Earlier quoted context omitted.

I honestly haven't run into this issue in a long time. `pip install --user` is one of your friends. Just using the official python:3 docker container is another. If you really want, you can even go back to virtualenvs. npm was also really bad about nothing building or working a few years back. It's improved, and there are alternatives like yarn. Rust/Cargo has this issue as well (whenever I attempted to pick up some…

Primarily any language that can produce executable binaries. Preferably statically linked binaries so that you can ship a unit that will not depend on the state of the system you try to run things on. (With disk and memory sizes, dynamically linked binaries aren't really as relevant anymore since the often trivial cost of size more than makes up for the nontrivial cost of having to fiddle around to make things actual…

It's possible to produce a self-contained executable with Python, there's multiple solutions for this it's just not a part of the core language.

I agree that the situation isn't perfect in the python world but it's actively being worked on and I think PyOxidizer looks like one of the most interesting recent developments in this space: https://pyoxidizer.readthedocs.io/en/latest/

Some other alternatives (depending on your use case, e.g. target platform) are PyInstaller, py2exe, py2app, cx_Freeze, Shiv, PEX (basically tooling for native .pyz), XAR, Nuitka (compiles Python into a native binary), pyninst (creates windows installer), PEP 441 style .pyz (executable python archive, can easily vendor in dependencies). Then there's tools like fpm if you want to create packages for deb, rpm, FreeBSD, macOS .pkg, paceman, tar-archives, etc.

I've used some of these in enterprise settings building rich GUI-applications being distributed to end users who have no idea of what Python is and to whom underlying technology choices are invisible.

Re: OpenDrop: An Open Source AirDrop Implementation

#165

Post by rektide »

dijit wrote: post #74
epixcz wrote: post #72

Xiaomi, Oppo And Vivo just introduced their own version of AirDrop. https://www.forbes.com/sites/bensin/2019/08/19/xiaomi-oppo-a...

Seems like theirs is not cross-compatible with airdrop. But OpenDrop is.

If there's a standard for this new thing, apple can stuff it.

Re: OpenDrop: An Open Source AirDrop Implementation

#166

Post by acomjean »

atombender wrote: post #145
bborud wrote: post #142

God, I wish people would stop using Python for these sorts of things. It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos. Python is a nice langu…

I don't use Python, but I've never had any issues with any distributed Python app. I have, however, had endless problems with C and C++ apps. The C way of referring to header files and libraries on the host system invariably leads to situations where the app wants to use a specific version that your system doesn't have. And we're not necessarily talking about system libs, either. Apparently authors thought the only w…

I deal with biology researchers trying to install various analysis programs. Python has caused me some pain recently. Its not easy, some use python 2.7 some packages use python 3.0. Many use different environments (pyenv/conda..). I ended up with a separate environment for each package..

To be fair java based software install isn't much better.

R is oddly a standout, in ease of installing packages. (Except the one time it didn't work, but in this case it wasn't much worse than anything else).

In general software distribution could be made much better.

Re: OpenDrop: An Open Source AirDrop Implementation

#167

Post by wadkar »

adestefan wrote: post #77
toxik wrote: post #60

Earlier quoted context omitted.

I can’t hep but think that these seemingly numerous security flaws are a product of proprietary software development. There is the old “many eyes” idea for software bugs, but even on a standards level. Did Apple not send out an RFC? Isn’t this type of architectural level screw up exactly what you want to avoid with an RFC? I’m glad Apple are taking the privacy issue to heart, but for every inch we’ve won in privacy,…

The “many eyes” hypothesis is routinely debunked when severe security bugs are found in things like the Linux kernel that have been there for years. The same is true for standards that end up being fundamentally broken at later dates. In the end software and hardware is so overly complicated that we cannot currently build secure systems.

I would like to read more about this many eyes hypothesis (and its falsification). Could you please share some links for the same?

Re: OpenDrop: An Open Source AirDrop Implementation

#168

Post by jtl999 »

bborud wrote: post #142

God, I wish people would stop using Python for these sorts of things. It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos. Python is a nice langu…

I do agree that's an issue, although I wouldn't put it as drastic as you did.

I was working on a Flask project many years ago and it didn't seem straightforward to "vendor" dependencies with the `pip install` paradigm. Guess I was wrong.

https://medium.com/underdog-io-engineering/vendoring-python-...

There's a reason why virtualenv and similar exist. Another interesting point. Gentoo Linux (which uses Python in the Portage package manager) doesn't support installing modules as system (by default) to presumably avoid breaking the system package manager.

Re: OpenDrop: An Open Source AirDrop Implementation

#169

Post by bborud »

hultner wrote: post #163
bborud wrote: post #149

Earlier quoted context omitted.

Primarily any language that can produce executable binaries. Preferably statically linked binaries so that you can ship a unit that will not depend on the state of the system you try to run things on. (With disk and memory sizes, dynamically linked binaries aren't really as relevant anymore since the often trivial cost of size more than makes up for the nontrivial cost of having to fiddle around to make things actual…

It's possible to produce a self-contained executable with Python, there's multiple solutions for this it's just not a part of the core language. I agree that the situation isn't perfect in the python world but it's actively being worked on and I think PyOxidizer looks like one of the most interesting recent developments in this space: https://pyoxidizer.readthedocs.io/en/latest/ Some other alternatives (depending on…

So with so many solutions to the same problem being made: which do you choose?

The thing is: for it to be useful people have to use it. And for people to use it nothing works better than one clear, idiomatic way.

If you have many solutions you often end up having no solution.

Re: OpenDrop: An Open Source AirDrop Implementation

#170

Post by Fnoord »

staticvoidmaine wrote: post #91
mxuribe wrote: post #81

It is 2019, and it is quite surprising - and disappointing - that we STILL haven't universally solved the means to easily, securely, and (yes, I'll use this term again) universally share files. I wish we could share files in a peer-to-peer fashion securely without hindrance of mobile platform, nor blockage of network MiTM, etc.

Rather than the google solution suggested by a sibling comment, I’d suggest a look at send.firefox.com.

Or magic-wormhole [1]. FOSS, x-platform, Python.

[1] https://github.com/warner/magic-wormhole

Post reply on HN