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

Minbox - a faster workflow for sending files

minbox.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Minbox - a faster workflow for sending files

#31

Post by voltagex_ »

disbelief wrote: post #8
fxtentacle wrote: post #5

Yay! thanks :) That looks like the Dropbox replacement I was hoping for to use at work. Some questions: 1. How about transparent GZIP-ing files. For example, I ofter have to send large CSV files, but my recipients are not always skilled enough to unzip them 2. Is there a way for end-to-end encryption, if my recipient also uses your tool? Urls including a ?key=ABCDFGHJKL part come to mind... For example, you could ran…

Thanks for the feedback! (Minbox developer here) > 1. How about transparent GZIP-ing files. This is an interesting idea! We've been mostly focused on receiving zipped files and extracting their contents, but I could see a "auto-zip" feature at some point. > 2. Is there a way for end-to-end encryption We use SSL on all uploaded data, enforce SSL-only on our download links and gallery pages. That said, this is email we…

Actually, if you've got your webserver configured correctly, it's not even "auto-zip" - your server sends gzip and the browser unpacks it transparently.

Re: Minbox - a faster workflow for sending files

#32

Post by hpagey »

EvanAnderson wrote: post #27
Osiris wrote: post #11

I had an idea a while back to make an SMTP server that would automatically strip out attachments, dump them on a web server, and re-write the email with a link to the attachments. I would still love to see something that does this type of thing automatically (such as through an Outlook plugin or SMTP relay) so you can use don't have to change your workflow to get the benefit.

This has been something that I've looked at a few times over the years. There have been a number of FLOSS and commercial projects that have tried to do this (and all that I'm aware of have sputtered out). A defunct product called "Mailonator" ( http://web.archive.org/web/20080611060558/http://www.mailona... ) did exactly what you're talking about.

We did this at my previous workplace. We stripped emails, encrypted them, and sent an email with the link to the files. Only an approved app was then able to open such files.

Re: Minbox - a faster workflow for sending files

#33

Post by vonskippy »

Seriously, they need to work on a decent elevator pitch. The video is annoying and too long, and their webpage goes on and on and on without clearly stating why they are better then all the rest. Should I try them - who knows? Will it make my work flow better/faster/easier - who knows? Ironically they dis dropbox, but everyone knows what dropbox is and does.

Re: Minbox - a faster workflow for sending files

#34

Post by rogerbinns »

fyrabanks wrote: post #20
rogerbinns wrote: post #12

I misread the title as faster sending, rather than faster workflow. For dropbox we just use shared folders which work no matter what else is going on (network connectivity, machines sleeping, reboots etc). I'd be overjoyed if someone could figure out faster sending. My DSL maxes out at 100 kbytes/sec upstream. Sending someone something like a mongodb dump involves a long wait while I locally compress it, and an even…

Perhaps you should have a look at pigz, a multi-threaded implementation of gzip. It uses the same flags as gzip, so -# specifies speed (-1 runs the fastest with the least compression ... -9 runs the slowest with the best compression), and by default it spawns as many processes as you have processors. I've never done any formal benchmarks, so I'm not qualified to speak as to its efficiency, however. Based on your late…

I usually use pbzip2 which is multi-threaded bzip2. As for efficiency, gzip -9 uses a 32kb window while bzip2 -9 uses a 900kb window. This plus other improvements is why bzip2 beats gzip.

> I'd say the more time you spend on compression, the less overall time you're looking at.

That turns out not to be the case. For example xz (-9 uses a 65MB window) does indeed result in better compression. However it isn't multi-threaded and uses considerably more cpu time. The extra time taken is beaten by using pbzip2 which can start the upload sooner. 7z does allow multi-threading if you can navigate it's command line options.

BTW here is a quick test. I have a json file that is 8.1GB.

    442MB  3m12s  single threaded gzip -9
    309MB  23m    single threaded bzip2 -9
    326MB  25m    single threaded xz -9

Re: Minbox - a faster workflow for sending files

#35

Post by [deleted] »

daniel-cussen wrote: post #26
meritt wrote: post #16

Earlier quoted context omitted.

While I understand it technically I feel like the video is incredibly misleading. It's demonstrating time-to-share a link which (at some point) will contain a file. It's not demonstrating time-to-upload a file like the video suggests by comparing directly against dropbox.

Incredibly misleading? Obviously it doesn't give you 8Gbit internet, it just saves your precious time. You don't have to spend five minutes on a task. It's not like Bruce was going to download that file as soon as he got the message, and that's assuming it sent right away, which it could avoid by delaying the email by those same 5 minutes. In terms of workflow, it's a huge improvement.

[deleted]

Re: Minbox - a faster workflow for sending files

#36

Post by aihunter »

apendleton wrote: post #25

What if you actually want to send someone RAW files, or big videos? Can they access them, or do they only get compressed/resized ones? Seems like a shame to go to all this effort to make a fast service, then force users to obfuscate their stuff by putting it in a tarball or something.

Option is yours!

Re: Minbox - a faster workflow for sending files

#37

Post by rogerbinns »

rogerbinns wrote: post #34
fyrabanks wrote: post #20

Earlier quoted context omitted.

Perhaps you should have a look at pigz, a multi-threaded implementation of gzip. It uses the same flags as gzip, so -# specifies speed (-1 runs the fastest with the least compression ... -9 runs the slowest with the best compression), and by default it spawns as many processes as you have processors. I've never done any formal benchmarks, so I'm not qualified to speak as to its efficiency, however. Based on your late…

I usually use pbzip2 which is multi-threaded bzip2. As for efficiency, gzip -9 uses a 32kb window while bzip2 -9 uses a 900kb window. This plus other improvements is why bzip2 beats gzip. > I'd say the more time you spend on compression, the less overall time you're looking at. That turns out not to be the case. For example xz (-9 uses a 65MB window) does indeed result in better compression. However it isn't multi-th…

As a followup, the most effective way to minimize upload time would be to start from the front of the file with gzip or something similarly quick, and simultaneously start the heavyweight compressions from the end of the file. When the two meet the more compressed content gets sent for the remainder of the file.

Re: Minbox - a faster workflow for sending files

#38

Post by M4v3R »

daniel-cussen wrote: post #26
meritt wrote: post #16

Earlier quoted context omitted.

While I understand it technically I feel like the video is incredibly misleading. It's demonstrating time-to-share a link which (at some point) will contain a file. It's not demonstrating time-to-upload a file like the video suggests by comparing directly against dropbox.

Incredibly misleading? Obviously it doesn't give you 8Gbit internet, it just saves your precious time. You don't have to spend five minutes on a task. It's not like Bruce was going to download that file as soon as he got the message, and that's assuming it sent right away, which it could avoid by delaying the email by those same 5 minutes. In terms of workflow, it's a huge improvement.

If you drop a file into your Dropbox Public folder you can share it instantly though.

Re: Minbox - a faster workflow for sending files

#39

Post by aihunter »

M4v3R wrote: post #38
daniel-cussen wrote: post #26

Earlier quoted context omitted.

Incredibly misleading? Obviously it doesn't give you 8Gbit internet, it just saves your precious time. You don't have to spend five minutes on a task. It's not like Bruce was going to download that file as soon as he got the message, and that's assuming it sent right away, which it could avoid by delaying the email by those same 5 minutes. In terms of workflow, it's a huge improvement.

If you drop a file into your Dropbox Public folder you can share it instantly though.

Not anymore! They deprecated that feature, only exists for old users.
Post reply on HN