And for mobile phones - without internet is similar, unnecessarily hard. The other day I was hiking with friends, and wanted to share a .gpx file with the route, at some spot with no cell coverage. I thought: "I 'member, bluetooth can send files". Well, we spent good 15 minutes trying and miserably failed, that's no longer possible in the name of "security". So I had to wait for cell signal to come back and send the file via whatsapp. To someone standing right in front of me.
Otherwise ironical that all of this behaves like the 90s PalmOS which could not store a file unless a program would accept it.
Available since Android 6 (c.2015)
I've had it be horribly slow, wickedly fast, and also absolutely fail to work at all.
The wickedly fast method seems to involve the two devices forming an ad-hoc WiFi network -- just for themselves. 802.11ac/ax is pretty darned fast when there's no competition, on a network with exactly two nodes, and when those two nodes are separated by only a couple of feet.
IIRC, this is not the default mode of operation.
I have a fairly expensive meter at my disposal to use for planning things like this, which analyzes different cellular carriers by frequency, and can output (messy, and with unescaped commas for notes, but eventually-fucking-usable) CSV files of the results -- with GPS coordinates of the measurement location.
This sounds amazing for a person like me in this line of work. But it is not amazing for a person like me in this line of work.
(As a preface for the rest of this, remember: This meter is a tool that is meant to be used in areas of limited or zero cellular coverage -- places where outside RF is problematic for whatever reason.)
1. The meter has a Bluetooth interface that connects to an app on a pocket computer. (This part works fine, usually, except the app often doesn't background properly and silently dies if the user uses their pocket computer to do some other task, which might be fine if the problem was ever reported. [Haha!])
2. The meter expects the pocket computer to have an Internet connection, so it can use that to upload its findings to The Clown. (This part often cannot work, because the whole fucking reason any of this is happening is because cellular coverage is shit inside of a random building.)
3. The meter expects that the pocket computer will provide GPS coordinates, even though it is intended to be able to be used indoors -- without network connectivity, or perhaps even in a Faraday cage. And while modern pocket computers are very good at providing some location data by various means as long as there is internet connectivity or GPS-esque data, all of them fail at this when there is neither Internet nor GPS available. It produces an error [Haha!] when there is no location information available.
4. It does not provide useful errors. It provides errors, but they aren't specific at all and do not promote productive troubleshooting or workflow. ("Oh, there was a problem with your measurement! [Haha!]" is the singular error.)
5. Sometimes, it will even produce an error [Haha!] but record the measurement anyway -- and without recording the error.
6. It stores nothing locally. When an error happens [Haha! Good luck!], it is impossible to quickly see if anything was stored at all, so the only clear path is to repeat measurements that result in an error [Haha!]. This often results in redundant measurements being actually-recorded, but who would know that at the time of measurement. (These measurements often take about 4 minutes each, so these errors [Haha!] and repeated measurements can consume significant portions of an expensive workday.)
7. (Your main point): Exporting a CSV file of [whatever-the-hell was collected] is possible, as long as I want to send it to Google Drive or some other Clown-based service. The CSV is only a few tiny kilobytes at very most, but it won't let me copy the CSV to my pocket-computer's clipboard, or send it in an email, or save it locally on the pocket computer, or send it with Bluetooth to my laptop. It has to be exported to a Clown-based service, and then it can be read from that Clown-based service by some other device. There are no other options presented, unlike in so many other apps in my pocket computer.
8. Continued: While the maker of this meter device has their own Clown, and this Clown is clearly extent on the Internet, this Clown is completely inaccessible outside of their pocket-computer app. I cannot bypass Step 7 by any official means no matter how deep my desktop computing prowess may be.
It is completely shit, and it appears to be the best thing available on the market in this space. (And it isn't even Chinese shit: The company that produces this meter is in Utah.)
Bluetooth can work, but it is slow as hell, and Apple doesn't support it.
Cloud services are convenient, but you not only you need some signal, but you also uses up your data plan.
If you have USB OTG support, you can simply use a thumb drive, like with your PC, but it is cumbersome and you need the hardware.
There are some somewhat proprietary systems like QuickShare and AirDrop, which are supposed are great when you have support which is not always the case.
Other options include having one phone act as a WiFi AP and host a local HTTP server, there are apps for that (ex: MiXplorer). A bit uncommon, but the advantage is that only one phone needs to do weird stuff, for the other, it is just downloading from a URL.
There are also apps like SyncThing based on P2P networks.
Generally, phones are pretty terrible at dealing with files. Their OS is designed around apps controlling their data rather than around interchangeable files like traditional desktop OSes. The way they want you to work is not by exchanging .gpx files but instead by using some built-in "share" feature of your hiking app. It may be .gpx under the hood, but they don't want the end user to see a file.
But localsend has worked well for me. Yes, it requires an app but if we could get vendors to bundle that rather than a boatload of bloatware.
I know that it would be to optimistic to hope for Google.
Spread the word.
That's a clearcut case of absolutely willful trademark infringement, and it will not go well for the authors when (not if) Apple happens to cast their gaze in that direction.
Wait, seriously? iPhones still don't support Bluetooth file transfers? I knew this was the case with the first iPhone but I just accepted that's a limitation from the OS being still an early release of a brand new product with limited functionality, I wouldn't have expect this to be the case after 15 years.
Anyway, I'm still baffled we never got a standardized Wi-Fi file transfer protocol, like with Bluetooth but at wi-fi speeds.
Oh right, nevermind, Apple wouldn't have supported anyway versus their own proprietary one that only works on Apple devices.
(If you're talking iphone to Android, nvm)
It's pretty shocking that we don't have a dead-simple cross-platform "send a file to someone over the Internet" solution that doesn't involve cloud servers and accounts and downloading apps.
Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces.
>ftp is too big a technical hurdle for the guy
Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. I'm not sure what happened between then and now, but these days people just say "I'm non-technical" and refuse to learn anything that doesn't involve a GUI. FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:
1. ftp [ip address] 2. type username 3. type password 4. cd dir-to-drop-files 5. put filename 6. quit
These days, we'd use sftp anyway, but you could also use scp in a single command line which they could simply copy-and-paste from an email, after you have their temporary account set up.
Back then there were far fewer non-technical people using email anyway. In my experience people like office admins wouldn't do anything with split archives they would get the local computer person to do it for them (and the same would happen at the receiving end). They were generally aware of zip files, but might get a local tech to compress things for them even if a split archive wasn't needed.
Or they would just send a floppy in the post if the file would fit on there but the email limit at one end or both was less than 1440K. On one occasion because no one was free to help otherwise I remember a secretary driving a floppy between campusesses to deliver updated slides for a talk because she couldn't get it pushed through email (I forget if the biggest blocker was at the sending or receiving end).
Things changed quite a lot when decent GUI zip tools became common, and again when shell-integrated ones arrived in the Win95 era.
Flipping back through time to now, there are two problems that we didn't have back then:
1. Phones don't have particularly good+friendly archivers, and even if one is found security protections might mean said archiver can't access the data it needs from the app that generated it. As well as talking someone through the archiving process you might need to try work out how to open the relevant permissions and describe that to the remote non-technical user too.
2. Often desktop environments are locked down too, and Windows for instance doesn't come out of the box with an archiver, neither CLI nor GUI, that supports multi-volume archives or encryption worth bothering with.
> Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done.
Some would do that, but I wouldn't say they were the majority by quite a margin in my experience. And not just secretaries: higher paid managers & such too. In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).
> FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:
The issue with that was (still is) that they will need telling each time. It isn't their job to do these technical things so if they don't have an active interest they aren't going to spend time learning it, so they can work out the exact sequence for next time unless it happens often enough that they learn by repetition. It isn't hard, but it isn't natural or familiar to many. It is only natural to you and I because we do that sort of thing regularly (or have done it enough in the past that it has become wired in).
No, the managers were lazy and insisted on having secretaries print everything out for them, and refused to touch a keyboard.
>In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).
In my experience in a college, the secretaries could handle their computer-based duties by themselves just fine. They only called for help when they ran into a problem they hadn't encountered yet. But doing basic file management at the MS-DOS command line (this was before Windows) was within their ability.
>The issue with that was (still is) that they will need telling each time.
Yeah, so what? ryandrake above said "I recently had to have a non-technical person send me a very large file, and encountered this", so that's why I countered with this in response to his claim that "ftp is too big a technical hurdle for the guy". It doesn't matter if it isn't natural or familiar; all you have to do is cut-and-paste some simple commands. If you can't do that, you're hopelessly stupid I think. You don't even have to understand the commands! That's my whole point with the utility of a command-line interface in situations like this: you can give someone some explicit commands, and they should be able to follow them exactly, simply by cutting-and-pasting or typing them in. It's not like a GUI interface where you have to try to tell them (perhaps over the phone) exactly where to click, which isn't reliable since you may not be able to exactly duplicate their environment or they might be using a different program or even OS. If you're somehow smart enough to use a computer with a GUI for years (and likely multiple computers: smartphone + PC), but you're too stupid to open a terminal window and cut-and-paste a one-line command, this sounds to me like "willful ignorance".
Anyway, the point is that this is fine for a rare occurrence like this. It doesn't sound like ryandrake has to deal with this problem with this same person on a daily basis.
https://developer.android.com/training/secure-file-sharing/s...
This one is there, and that's exactly how I was handing over the file between osmand and BT/WA.
I beg to differ. In the 2000s and part of 2010s everyone had optical media readers at home or in the office. In my EU country, radiology offices still use DVDs to share or hand you over your X-ray/CT/MRI images that you can then share with your dentist/GP/specialist for diagnosis.
Yeah, a national cloud system for radiology image storing and sharing part of the national healthcare system the would be much better, but computers and on-line services are still a new confusing thing to the government, so this is what we got now. So every medical practice still has functioning optical readers.
I could have used it, too, but I could not think of anything I wanted to do with it by that time in 2017 -- seven years ago -- despite my proclivity for making backups of films.
BD on a PC has never been common in my world of computing, and by 2017 optical drives in general were becoming very uncommon in everyone's world.
It never broadly caught on.
And even those are mostly download now.
But is your program actually P2P? (If it were, then: The sender would know when the recipient has completed the download, because the sender was finished sending it and the recipient has stated that they are done receiving it. And there would be no need for gymnastics.)
The only thing is writing to a CD/DVD can be a PITA. To me diskettes were very easy when it came to read and write to physical media.
>Sure, I can attempt to lend another person a thumb drive, but that's a much more complicated thing than giving them a throwaway DVD-R was
This I agree with, I have a tough time giving flash drives away for some reason. If one could buy a pack of 10 1gig flash drives for the same price as a box of Diskettes, it would be easier. Right now you can only buy flash drives 1 at a time.
Smaller flash drives are available online, in bulk, of course, but they're not much cheaper. I guess the cost of flash becomes a negligible part of the total price at the single-digit GB range these days.
But I can't seem to find any big packs of cheap small sticks either...
A USB key can be anything, or even complex combinations of things. It can be a storage device and an HID keyboard input and an optical drive that autoruns software on the PC it is connected to, with all of this being intentionally supported by the host operating system.
No back door is required: This can happen right at the front door, as the operating system does what it is intended to do when it detects new hardware.
And as a parting shot: It can even deliberately physically destroy the host computer's hardware. (Try that with a crafty ZIP file.)
And even this might not be enough. Is your OS's partition table code robust against malicious input? I don't think there's any way to disable reading the partition table in Linux when a new block device is detected. In this case even copying a single file to/from the raw device with dd might not be secure.
You can get a ten pack of 16gb drives for $25, which after inflation is in the ballpark of what I remember floppies costing 30 years ago.
https://github.com/magic-wormhole/magic-wormhole
There's also various webapps that work similarly: set up the connection then have you transfer data directly to the peer.
And for a while, I enjoyed handing people CD-Rs or DVD-Rs full of data, and the disks were also cheap enough (eventually) to not care much about. (And disk quotas and attachment sizes have never caught up with either CD-R or DVD-R capacity, although transfer rates have.)
But BD-R never really caught on for a lot of reasons: So even if it is cheap-enough, it isn't universal-enough.
And I'm somewhat loathe to hand someone a thumb drive. They're universal these days and can be cheap enough to not care about, but they can also be expensive and they just don't feel as forgettable as pulling another blank disc out of the box/off of the spindle, writing some data to it, and just letting them keep it was.
Sure, I can attempt to lend another person a thumb drive, but that's a much more complicated thing than giving them a throwaway DVD-R was. (Also, it's an active computer device -- there's very real concerns about trusting a foreign thumb drive that never existed with previously-used iterations of removable media.)
So now, to give someone some meaningful amount of data: I get to upload it to The Clown (with Dropbox or Google Drive or Discord or something). With the most-common methods, I also get to hope that I remember to delete it later (and also hope that they remember to save their own copy before I do delete it).
Which is great, I guess: I can send a mountain of data to anyone in the world this way and we never have to be in the same room.
But it also sucks: I can't simply copy off some data and actually hand that data to anyone else like I did do with a CD-R. There's always a third party involved. (It's like mailing a letter through a transciptionist service might have been, if that was ever a thing that was, instead of addressing it to the end recipient directly.)
As a final lament: What in the fuck ever happened to easily sending data, over the Internet, to a fellow peer? Transferring files with DCC on IRC seems like it was miles ahead of where we are today, and that was 25 or 30 fucking years ago.
(No, I'm not bitter. I'm just old, I guess.)