Storage for Photographers - <AUTHOR> http://paulstamatiou.com/storage-for-photographers <comment><USER3> Yes, PLEASE. We run a wedding photography business, and our numbers are something like this:

\- 40-60gigs shot in a weekend, need to offsite the RAWs as soon as possible. In six or seven years we've never needed offsite retrieval. Fine for it to be slow.

\- Only need around 100-200g of raws locally for jobs in progress

\- Once processed into final jpgs files are approx 8-10x smaller. Offsite these as well, and need access to last 1-2 yrs of jpgs randomly/sparsely w/in 1-2 days of a print order coming in

I definitely think some well thought out service that uses maybe a hybrid of glacier and S3 could be really awesome. Especially if the pain is taken out of getting the bolus 40-50g of photos "uploaded" in the first place.. We'd happily pay for a service that just sends us an external drive and a postage- paid box.. we drop it in the mail after a job and get another drive sent to us right away.

[EDIT: Occurs to me you might wonder what this looks like today. Today we get home, and immediately back up onto an 8-bay Drobo Pro ([http://bit.ly/1diZUHD](http://bit.ly/1diZUHD)). It's a fancy proprietary RAID-like system. I think ours has 7 1TB Drives in it currently, and it's at about 70% capacity. Then we back up the same jobs to an external hard drive which gets driven offsite (used to be my office, but now that I work at home it's the in-laws place) and copied to a hard drive for permanent offsite storage. Once that happens, the cards from the camera can be cleared. After processing, the final JPGs get copied to the drobo and make it into the sneakernet offsite process as well.]

<comment><USER4> > _Occurs to me you might wonder what this looks like today_

I finally hit a sweet spot of performance, archive accessibility, and offsite safety, by using internal SSD for latest import workspace, direct attached WD Velociraptor (Thunderbolt) for current projects (can reconnect between Mac Mini server and laptops as needed), and 2 direct attached LaCie 4big Quadras (daisy chained via FW800) for archived projects (up to 32 TB).

Interestingly, because these are all direct attached, BackBlaze will happily back them up offsite at ridiculously low cost if that's your thing. Initial backup of several terabytes will take several months, though.

For fast cheap offsite backups, partner with a colleague with similar storage needs who uses the same ISP via the same head end. Just backup to each other. You can enjoy near LAN latencies at maxed out link speeds. This trick will save you both time and headaches.

Finally consider a product like the CyberPower OR2220PFCRT2U (this one also blends nicely in an AV cabinet) to keep an Airport Extreme and Mac Mini along with all that storage running for about 80 minutes of power outage.

<comment><USER3> The idea of partnering w/ someone using the same ISP is interesting. It's really offsite that's the whole challenge. If it takes three days to get 60g uploaded (setting aside the nuisance of saturating our bandwidth for doing things like making Skype calls), then I effectively have close to no solution.. because during a busy season I have at least one job exposed for half of most weeks. House burns down, and I lose recent work.. which is the most important work since it hasn't been delivered.

Really, I need something that gets a copy of the images away from my home within a day to have something I'd be comfortable with.

<comment><USER5> Would it be feasible to simply dupe the drive and find a secure off-site place within driving distance to store it or a storage machine, and then mail drives to glacier (Amazon will import a HDD via mail for around 100USD) as the storage machine fills?

<comment><USER6> I worked at a wedding photography/videography place a few years ago and we did a lower tech version of this. The owner had a storage array at the office and at home, and he'd cart an external back and forth daily. This way there were two copies of all work, and three of the most recent: one at the office, one at his home, and the most recent work (that which hasn't been delivered) on the portable drive.

</comment></comment></comment></comment></comment><comment><USER7> We applied to YC with exactly this idea. We made it to the interview, but were turned down. I wrote about that experience: [http://tghw.com/blog/pull- hard](http://tghw.com/blog/pull-hard)

We pulled our bootstraps hard and tried to get it going, but soon realized that there's a pretty big flaw with the idea: most photographers have no idea that they should backup their photos. They know hard drives crash, but they never expect it to happen to them.

This meant that we'd essentially have to become insurance salesmen, convincing people that bad things will happen to them.

Eventually, we decided to shut it down, which I also wrote about: [http://tghw.com/blog/well-that-sucks-what-else-you- got](http://tghw.com/blog/well-that-sucks-what-else-you-got)

The old homepage is still up at [http://www.snaposit.com/](http://www.snaposit.com/).

<comment><USER8> Professional photographers know they need to backup their photos.

It looks like your product targeted consumers, but professionals seem like they'd be a better market. And it should have been priced way, way higher; the more it cost, the more secure it looks. I'd have a hard time trusting my money-making business assets to a $9/month service.

Of course, I'm not a professional photographer nor do I have your experience in trying to build this business, so who knows what my opinion is worth. :-)

<comment><USER7> Actually, once we started getting into the market, we found that most do not know they need to do regular, offsite backups.

Consider the some examples:

* An older photographer who grew up in the days of film who has just transitioned over to digital.

* A homemaker who is trying to add some much needed income for her family, with a passion but no formal training.

* A well-off software developer who moonlights as a photographer for fun and a little extra money.

Of those, only the third has been exposed, formally, to correct data backup procedures. The others are likely to keep their photos in folders on the desktop of their laptop.

Furthermore, photography is not a very lucrative profession for most photographers. That limits the amount you can charge. Our original pricing was much higher, but we realized that would be problematic, considering the average photographer brings in around $30k per year.

<comment><USER9> None of your examples contradict

"Professional photographers know they need to backup their photos."

A homemaker or techie moonlighting for extra income aren't really 'professional photographers'. They may take photographs that look professional, but it's not the same thing.

One might say that professional developers use version control, then have counter examples of "well, this web design student doesn't ever uer version control, but she's the only person working on the code, so it doesn't matter". This is not a professional developer, even if she is capable of producing results that look like they were done by a professional.

A professional, imo, is defined as much by their habits and practices as by the output.

<comment><USER6> > doesn't ever use version control, but she's the only person working on the > code, so it doesn't matter

As a web developer who works on a lot of solo projects, this sentence hurts me.

<comment><USER10> Do you use version control? If you do, that sentence doesn't even apply to you.

</comment></comment></comment></comment></comment></comment><comment><USER11> I really wish we as a developer community would better differentiate between "backup" and "preservation". They are both related to storage, but are fundamentally different problems. The article touches on the desire to have photos safe for decades, but doesn't really get into the strategy necessary to make that happen.

If we care about decades, storing the raw NEF or CR2 file is almost certainly the wrong approach. Those files could easily be as difficult to open in fifteen years as a ClarisWorks document is today (just to choose one example - proprietary formats for professional software from the late 90's are all pretty hard to open today). Also, important metadata is kept in the lrcat file. Unless we expect to always be able to open our copies of Lightroom, we need to migrate that data too.

We used to think of "archiving" as putting something on a shelf and forgetting about it, sometimes taking environmental factors like humidity into account. With our digital data, we need a plan for periodically checking it, both for fixity and to make sure at risk file formats are migrated to current best practices. This will require greater awareness for the complexities involved (and the need for open file formats) from everyone from creatives to storage and service providers.

By the way, every creative industry is struggling with this right now. Recording studios have session files created in ProTools 4. Designers have really old Quark files, even though they've been working in InDesign for the past five years. Composers have Finale files. A lot of these file formats depend on plugins to be able to display properly. I don't mean to sound discouraging, I think there's plenty of opportunities for viable businesses here. We just need to start using the right terms.

<comment><USER12> In a word, VMs. If you make sure you can open that NEF or CR2 file in a virtual machine, and the virtual machine image is in a standard, open format, you're set. You just have to worry about the image format becoming obsolete and not 10 or 20 different proprietary formats.

That said, I used to be a pretty prolific hobbyist musician and I haven't pulled this off myself. I have tons of old songs I can't open because they rely on a fiddly collection of old freeware plugins for freeware music apps from 11 years ago. I also have songs I can't open because they only play in a music tracker _I wrote_ , which is open-source, but only runs on OpenBSD.

It is a tricky problem and it seems hard to tackle because the market for professional software inherently favors closed-source, which has no incentive to adopt open, non-siloed formats.

</comment></comment><comment><USER13> I've been looking into Glacier, but the pricing in the case where I might want to retrieve a substantial portion of my data is quite complex. As far as I can tell, the headline $0.01/GB rate for overages they quote is misleading. They don't, as you might expect from that language, calculate ([GB retrieved] - [5% of GB stored]) x $0.01 and bill you that.

Rather, they charge you on a monthly basis, according to your highest hourly retrieval rate from any single hour _applied to the whole month_ (standardized at 720 hours). So if your peak hourly retrieval in a month was 10 GB/hr above your pro-rated free quota for that hour, you're charged for _7200 GB_ of retrieval overage, or $72, even if you retrieved nowhere near 7 TB of data. For companies with relatively constant retrieval this doesn't matter, but for small users, someone who has a large overage one day will be charged as if they were incurring the same overage continually all month.

To put it concretely, if you store 200GB of photos and then do a bulk retrieval, you aren't charged $1.90 ((200-10) x 0.01). Rather, the xfer is counted as 4 hours, so you have a peak transfer of 50 GB/hr. Your free daily retrieval is allocated to the hours in the day you retrieved data, so in this case 10/4 = 2.5 GB/hr free. So your overage is 47.5 GB/hr. Multiply by 720 and $0.01, and the fee for retrieving 200GB of photos is $342. Plus $22.88 in outgoing AWS bandwidth.

Or at least, I think that's what their pricing page says. Maybe someone else can better interpret this explanation: [http://aws.amazon.com/glacier/faqs/#How_will_I_be_charged_wh...](http://aws.amazon.com/glacier/faqs/#How_will_I_be_charged_when_retrieving_large_amounts_of_data_from_Amazon_Glacier)

<comment><USER14> Right, you definitely shouldn't request all 200GB at the same time, because it'd be expensive and also because you probably can't download all 200GB immediately either.

Arq (a backup app I wrote) takes a transfer rate from you (guesses your max transfer rate as a default) and then requests enough to be downloaded in 4 hours at that rate. 4 hours later, it requests another 4 hours' worth while it downloads the first 4 hours' worth, and so on. This mitigates the peak- transfer fee.

<comment><USER15> Does Arq fit the OP's use case of backing up files to AWS without keeping them on your local machine?

</comment></comment></comment><comment><USER16> Smugmug's SmugVault

"SmugVault is an added service to your SmugMug account that lets you store almost anything for next to nothing. Including files not normally supported by SmugMug."

[http://help.smugmug.com/customer/portal/articles/84562-more-...](http://help.smugmug.com/customer/portal/articles/84562-more- about-smugvault)

<comment><USER14> Although Smugmug is awesome, the issue I'd have with them is the lack of control. If my objects are in my AWS account, that feels more permanent long- term. It's just a gut feeling.

</comment></comment><comment><USER17> My company serves thousands of professional photographers (wedding, commercial, fashion, etc.). What you're describing is definitely an issue for photographers but I think getting them to use a tool like you've described would be an uphill battle.

Right now, most of them use Drobos or similar devices. You'd be asking them to add steps to their workflow which is always tough to do.

Also, I think your estimate of 18 mins to upload 6+GB is an order of magnitude off. We have tools that allow people to upload JPEGs and most customers claim it takes longer than that just for 100s of MBs.

My (wild) guess is that Adobe is going to get in this space too. It only makes sense to have your Lightroom catalog in the cloud. Maybe they wont offer an affordable solution for terabytes of data, but I'm not sure photogs want their images in two different "clouds".

I think the key is to do customer development from full-time photographers who aren't hackers. I'd be happy to send out a survey to some clients if you want do more research.

<comment><USER18> My Lightroom catalog is backed up to a folder in Dropbox, and this works really well.

You can't really have the current catalog in Dropbox because then each action and edit become really slow.

But if you set up Lightroom to do a backup every time you quit the program, and that backup is in Dropbox, you get the best of both worlds (strong backups + snappy edits).

Lightroom backups are really "backups", as they are named by date+time, so in Dropbox I have a history of everything I ever did in Lightroom, not just the current (last) version.

It's also fast because I suspect Dropbox is able to do some rsync magic and only re-upload new packets; my Lightroom catalog is around 150 MB and the upload to Dropbox is almost instantaneous (on a pretty lousy upstream bandwidth).

Of course this doesn't address the problem of backing up RAWs, but as far as Lightroom is concerned I feel pretty safe.

<comment><USER19> Just to be clear here... Your Lightroom catalog is very important but is not backing you your Photos. (which I know you said at the end. I am just emphasizing)

Your LR catalog contains your photo edits, metadata and history... but is not your original files. Backing it up is very important but is only part of the story. Putting your Lightroom catalog backups on Dropbox is a great and should be done by everyone. (Again just not your active catalog.)

</comment></comment></comment><comment><USER20> This idea is great, but it ignores on very real problem. Namely that you still have not addressed the issue of bandwidth. Take for example your 4th of july example. If I were to do that upload the way you describe, I would already be over my monthly bandwidth allotment with my ISP as would many hobbyists.

<comment><USER21> The US bandwidth situation is the elephant in the room.

There really is no good solution to automated offsite backup when it takes several days of uploading to handle a single day's worth of data capture. To make any internet-backup service work, you'd first have to pitch the photog on switching from their residential broadband package to something more expensive -- if that's even available short of their leasing office space somewhere.

I guess you could try to build out a reverse-CDN sort of network, with local relay nodes scattered across the various ISP networks, that might achieve faster uploads from the user (and maybe not get counted against bandwidth caps) which then use a fat pipe to send that data to larger regional storage nodes.

Neither seems particularly plausible at scale.

</comment></comment><comment><USER22> How about git-annex assistant with the glacier remote? [http://git- annex.branchable.com/special_remotes/glacier/](http://git- annex.branchable.com/special_remotes/glacier/). It will move files off your local once they have been transfered to the remote.

<comment><AUTHOR> The large part of this post for me is about the local thumbnail exports of the RAWs so I actually know what files are what without having to go just by album names, dates et cetera.

<comment><USER22> You could keep the thumbnails local and annex the raws. Based on the thumbnails, you could selectively git annex get from the remote glacier

<comment><AUTHOR> good point

</comment></comment></comment></comment><comment><USER23> I'm actually working on this idea right now!

[https://plover.co/](https://plover.co/)

We want to take backing up, sharing, and monetizing and make them very simple and enjoyable to do. We've started rolling out slowly already, our goal is to be open to the public within a month or so.

<comment><USER24> I hope your business model doesn't rely too heavily on the "monetizing" aspect. I know there are lots of photo hosting services with a "sell prints" option, but I get the impression not very many people actually use those in enough volume to cover the hosting costs. I'm imagining a non-pro track that's targeted at the enthusiast who just wants backup and sharing, but won't actually sell any prints. I'll be watching.

<comment><USER23> We don't make any money off of prints, only the photographers do. The business model is subscriptions.

<comment><USER24> This is good to hear. BTW, it might help if you had a _little_ more info on your landing page about the service. For example, I can't tell if this is going to be aimed at true pros who are willing to shell out a decent amount of money, or if I'm going to be able to afford it for my own pro-sumer needs. Having to sign up for a mailing list and wait in order to potentially find out that I'm nowhere near the target audience is frustrating.

<comment><USER23> Heh, it is unfortunate that there's very little info there. We put it up a while ago and have been so focused on actually building the app that updating the website seemed unimportant. :)

<comment><USER25> Look at it this way. Improving your website (which is already nice btw) means more people signing up to be notified when you are ready to launch.

</comment></comment></comment></comment></comment></comment><comment><USER26> I'm in a similar situation as the OP...an amateur but avid photographer with terabytes of RAW image files.

Currently, I have several multi-terabyte drives that I erratically back up to...I just got a 4TB drive that I'm going to try to backup everything I've ever shot in the last 3 years...

But I do want to move it to online storage...and I think this requires triage. For nearly every photoset, I've quickly gone through them with Lightroom and starred the ones that I kind of like, and then for maybe 1% of them, have taken the time to fully process, label, and upload them (in JPG form) to Flickr.

So for online storage, I think what I'll do is write a batch script that dumps all the _unstarred RAW files_ as JPGs, because they chances that I'll ever need these photos in RAW is very slim, and then upload them. For photos that I've given at least one star and/or taken the time to properly edit and categorize, I'll send up the RAW file along with the processed JPG.

If I have about 3TB of RAW files...and maybe 10% of those are RAW images that weren't disposable...that's 300GB right there. And then the remaining RAW "keep em just in case" files would end up being compressed from 24MB to about 2-3 MB (let's say 15% as an average)...so 400GB.

700GB is still quite a big footprint. However, the biggest problem will be...let's say I give up local storage all together and rely on the cloud...what's the best way to browse any photoset at any arbitrary time? When it's all local, it's trivial to pop open Lightroom and do some quick browsing and filtering. For online storage, I'll have to put a ton of work into proper folder-naming, at the very least

<comment><AUTHOR> Your last few sentences are exactly why I wrote this post. I want everything stored in the cloud but ALSO have a decent way of browsing them locally. The idea is to just store tiny jpegs (you can set how big they are, but something like 500-1000px wide likely, just for you to get a sense of which photo this is and allow you to remotely delete, retreive, etc)

<comment><USER27> This is basically what I need for Office Snapshots. I keep all of the original photos submitted so that I can use the full images in the future (if need be) and would love to store them somewhere other than my laptop.

If I could browse locally with smaller images (as you describe) like I currently do with Picasa (galleries, tags, etc) and then have the ability to download the original images when and if I need them, I'd be in heaven.

</comment></comment></comment><comment><USER28> I have a serious problem with the proposal offered in TFA and most variants in this thread: it encourages bad backup policy. Critical data needs three (or more) backups. In my experience, one cloud provider can only ever be considered as being one backup no matter their technical architecture.

For example, you can't (and in the broad "you", aren't even qualified to) audit the provider for data-loss or SLA-impacting SPOFs. You just have to assume that they're there. You also take on non-technical failure modes: the provider can go out of business, get bought by an uninterested owner (think Delicious), change focus (Google Reader), or experience myriad other problems.

FWIW, the best success I've had with helping others switch to good backup policy happened once it became economically feasible to buy a new laptop and two bus-powered external drives as big as the laptop's internal storage. The externals become bootable backups, one of which can be preiodically rotated to an offsite location. This has prevented severe dataloss events for myself and others far more times than I care to count now.

<comment><USER3> FWIW, I'm more technical than a typical user might be but I'd be _very_ intrigued by a provider that used multiple cloud service and gave me the keys to the underlying S3 buckets (or whatever) so I could independently verify. That's probly a more valuable idea to a company selling backup to nerds though, I guess.

</comment></comment><comment><USER29> I still prefer local storage and self-hosted storage, but what I'd like is a good plugin for Lightroom to manage cloud storage and multiple, versioned USB drives (or network locations) for images, from within the Lightroom interface.

(for local storage, once you go beyond individual USB drives, I'd go with a Synology 1813+ NAS ($999 chassis, 8-bay) or an Areca ARC-8050 thunderbolt raid ($1499, 8-bay).)

</comment><comment><USER30> I believe Photry (www.photry.com, currently in beta, I'm the founder) could be a possible solution in the long run. Since we started, a lot has changed on online photo storage market.

With that in mind we've started to look more on how photographers with larger photo volumes could benefit from our service. From the feedback from few photographers we've already included some features (RAW photos with smaller JPG thumbnails, workspaces and personal sharing for example) that will make the day to day workflow a bit easier. Currently our goal is to build something that would fit better for professional photographers (public for clients, ordering prints and possibly integrated payment flows, win/mac client + plugins for your favorite photo software).

Pricing wise we are currently not the cheapest but we have thoughts on how to make this better for high volume photographers. If you're one of them then please send me an email (martin at photry.com) and I would love to talk a bit further what we plan to do and if we would fit your storage needs.

</comment><comment><USER31> A service would be great ... but you might be able to "roll-your-own" with some basic scripts to handle the conversion (down-sizing) and backup sync - and something like Koken to handle the sharing with friends & family.

[http://koken.me/](http://koken.me/)

For back-ups - just buy a huge disk or set of disks, and keep 'em off-site wherever you have a trustable location (friend, family, work - if allowed and bandwidth isn't an issue) and use CrashPlan's free software to sync a copy to the secondary location. It's free after the initial expense of the drives and gives you encrypted, but physical access to the content in case of an emergency. You could find a friend with the same problem, and just agree to dedicate a certain amount of disk-space to each-other for this purpose.

</comment><comment><USER32> I'm the SO of a professional newborn photographer who generated somewhere in the neighborhood of 20-30TB of RAW photos, backups, LR xmp sidecars, etc in the last year. JPEGs don't even register. High end DSLR RAWs are gigantic!

I'm the technical support for overall workflow, storage & backup engineer, etc, etc. I wear many hats.

Right now I've got a backup on import to a FreeNAS (BSD) filer running on a HP Micro Server. Lightroom backups go to the same filer and are synced as well. My local server rsyncs the delta every night to an identical machine at a friends' house.

This isn't perfect. The one place that isn't 100% backed up is current projects in post-production. That's an acceptable trade off for now.

The most important thing to note is that there are two kinds of photographers: Those who never lost data, and those who care about backups. As mentioned elsewhere in this thread, converting members of Group A into Group B is a tough sell. Video testimonials might be a good option.

A storage service for photographers _MUST_ be invisible to their workflow. Make it as easy to use as an egg timer. At the _MOST_ , an addition of a single screen with sensible defaults (just click next) on photo import.

Ignoring error messages that get in their way is to be expected. Care more about their backups than they do. Send me (tech support guy) an email to notify if there haven't been backups added in X days, along with weekly reports of data usage per day -- how many photos, how large, what root folders, usage trends, etc.

An ideal installation would be automatic detection of what program they're using, what places files are stored (hint: It's not just on a local drive). Detect new file locations and back those up too.

An inexpensive (<$25) option of "only backup current projects I'm working on and anything I shot in the last month", that actually works... I'd sign up in a heartbeat.

</comment><comment><USER33> Seems like [http://www.loom.com/](http://www.loom.com/) would be great?

<comment><USER34> I've been on the waiting list of Loom for ages. Thought it was in the deadpool...

<comment><USER33> Nope, think they're just perfecting things!

</comment></comment></comment><comment><USER35> Backup is about having _several_ copies. If you delete files after you uploaded them to the cloud, you don't have a backup - with all the problems that come with it (say, if you delete a file by accident there will probably be no way to restore it).

If your files are important to you - you need a back up. If not - just get rid of them in the name of simplicity :)

PS. Also, uploading many gigabytes over a typical ADSL connection is just painfully slow... even local NAS is too slow over WiFi for my taste, and if I have to have a wire - I can just as well connect an external drive.

<comment><USER36> I wanted the benefit of Glacier plus backup functionality so I went with Arq. It encrypts everything and supports Glacier. Works really, really nicely.

<comment><USER37> I use Arq as well. Easily one of the best backup options for Macs.

</comment></comment></comment><comment><USER38> I wish I could trust the cloud because it would be a lot more convenient to not have to worry about storing photos, which involves a lot of effort once you advance beyond a casual hobby and you get into storing Terrabytes of large RAW files and maintaining adequate backups.

But the idea of storing any files in the cloud is very distasteful to me ever since the NSA Snowden story broke. Even something as innocent as a photographer taking pictures of a skyline or some beautiful architecture could land him in hot water if the government is looking at metadata and figuring out that he took lots of photos of a government building or a bridge or a power plant and randomly throwing him on some watch lists or no-fly lists. People have been hassled by the feds for a lot less.

My preference would be for all of these cloud storage providers like Google, Facebook, Apple, Dropbox, Amazon, etc to unambiguously and fiercely challenge the government on this and somehow unambiguously prove to people that they're respecting peoples' privacy and not complying with this stuff. Their denials so far have been obvious non-denials that are very carefully worded around "no direct access" when that's enough wiggle room to do just about anything.

Using some kind of cloud photo storage is a bad idea IMO until this gets sorted out.

<comment><USER39> FINALLY. I was going through every comment on this thread and I was wondering why no one was talking about security. This is one of the key features of the data warehousing business we have been contemplating.

</comment></comment><comment><USER40> Draft feature set:

\- Local daemon running that manages this process, on PC or Mac. It can't be done solely from the browser.

\- The software manages the import from the SD/CF cards, you put them all in, it sorts everything out and wipes the SD cards on the way out.

\- You then use Lightroom to do whatever you're going to do. The software would do well to have a Lightroom plugin that lets you select particular images to mark as "high priority" and "low priority."

\- Now the daemon uploads all of your RAWs, Lightroom metadata, and corrected JPGs to cloud storage.

\- Based on your settings, these RAWs get discarded after some set amount of time (maybe immediately, maybe never), and the highest-quality JPGs are also discarded after a longer amount of time for lower-quality JPGs just in case you need a emergency backup. After 6 months you lose the raws, 1 year the highest quality JPG, 2 years the medium quality JPG, etc. You are charged per gigabyte per month so you can decide how much you care about backup. Basically offload the cognitive effort of discarding old data that isn't worth its upkeep costs anymore.

\- The files are available via an API that you can use to build your own gallery/shopping cart site, with the ability to call a certain quality, PROOF watermarking, etc. on-the-fly. But the service offers a default site right there for you to do the same, that's stylable and can be implemented on your own domain.

\- You can get your entire catalog shipped to you on a hard drive at any time for a few hundred dollars.

</comment><comment><USER41> "I open the folder where Lightroom imports are stored and drag these shots to the RAWbox (fake name for this ideal photo app) desktop application."

You shouldn't be touching the directory structure. This tool should be either a plugin for Lightroom/Aperture/Photoshop or an entirely separate application.

I would lean towards separate application. It could be a background agent that detects when new files are added, would work for any known editor or user- defined directory.

</comment><comment><USER42> Over the past few years, I worked on a few versions of this as a side project. The last iteration didn't do the backup itself--it connected with your Dropbox, sync'd the raw images, and processed them at a preset +-2 EV, and 3 color temperatures. The image results were good, but honestly I never found it particularly compelling.

In any case, building this sort of thing is a pain. The most obvious problem is the size of the images. Glacier is an interesting backup solution, and had just come out around the time I decided to stop working on my app. A less obvious problem is raw conversion. All the best converters are proprietary, meaning that I had to piggy back off the Mac OS converter engines. Again, I never got to the point where I felt the product was worth the trouble of buying racking up a Mac Mini to run a little market test. Maybe I'm wrong.

I had a (frankly somewhat scattered) draft of a post mortem written, and since it seems like there's some interest in this subject, I posted it: [http://scraps.bigbento.com/2013/05/30/hiatus.html](http://scraps.bigbento.com/2013/05/30/hiatus.html)

</comment><comment><USER43> This is exactly what I was thinking about... I want cloud based storage which I am not locked into with a decent UI , way to browse and basic image management (something like ThisLife for the fronted)

I think it's possible to have a either S3 or GDrive based system that has a Angular.js (or some other JS MVC) that can operate without a backend for very simple browsing features and connecting to the S3 via apis.

I think it's doable ...

</comment><comment><USER44> If you want to avoid having any backup devices yourself, would you need to upload to two or more Glacier-like services?

I also trust Amazon to stay in business but mistakes can always happen (not just hardware but ID theft, card expiry while you're on a 6 month hike, etc) and unless you're prepared to say "losing these is OK" using one service would be risky.

<comment><AUTHOR> This is true, but what other Glacier-like services are there that have $0.01/GB/mon storage + retrieval?

<comment><USER45> Offsite tape backup can approach that price, but I don't know of any exact alternatives. It would certainly fulfill the requirement of having two different media types and providers.

[http://www.dpbestflow.org/backup/backup- overview](http://www.dpbestflow.org/backup/backup-overview)

</comment></comment></comment><comment><USER46> Highly recommend [http://www.mosaicarchive.com/](http://www.mosaicarchive.com/)

</comment><comment><USER47> Has anyone used Lightroom 5's new Smart Preview feature? It generates lossy DNGs from your full-sized files that you can still work with while your original sits on an external drive. Once you plug your external drive back in it, it syncs the non-destructive changes back to the RAW file.

</comment><comment><USER48> I did some on the side admin work for a Photographer once, a real big name. He was in the middle of making up exactly what this was, however he came up against the same issues everyone has. Firstly space costs money, Hardware costs alot too, not to mention bandwidth, this guy would easily do 100-200gb of photos in a couple shoots. all very high res shots (talking about for big company ads) his idea is to sell a server with a software suit that people can dump into a datacenter or at home and upload photos to it, personally I liked the idea but local storage and hardware failure + the ability to grow the storage was a real killer for his idea.. (not to mention that your playing with peoples businesses and lives if you lose those photos)

</comment><comment><USER49> I'll jump in here and share our current problem and how we are addressing it today. Hopefully it proves useful for whomever tackles this project!

So we are an ecommerce company and we do our own photography for products -- and we do a lot of it. We average about 2-3 photoshoots per month, and each photoshoot can be upwards of 40GB before any processing. We shoot raw images and are starting to experiment more and more with video. After we do the post- processing work and start the video editing we can push 70GB a shoot easily.

Our current workflow is like this:

Shoot tethered to a laptop each day (typically each shoot lasts two days). At the end of the day, we upload the files up to our local NAS (Netgear ReadyNAS, just shy of 3TB) which is redundant.

At the end of the shoot, we load a copy of the entire shoot on the local computers that will be editing so that they don't have to work directly from the NAS. Over the next few weeks while they edit the files, they will push the new files up to the NAS into specific folders.

(This is where it gets hairy) We also have an offsite NAS that is located in the business owner's house (about 6TB, but this one is not redundant). We used to attempt to upload files each night from the local NAS to an offsite NAS via rsync, but the pipe was just way too small. It would take days to upload a photoshoot, and everyone in the office suffered from slow internet while that happened. Now what we do is bring the offsite NAS _onsite_ every few weeks and do a manual sync! Locally the sync only takes a few hours and then that night it goes back home with the business owner.

Now since the local NAS is less than 3TB, we can't store all of our shoots on there forever. When we get close to full on the local NAS, we grab an external hard drive and archive old shoots (typically 2+ years old) to it, and then store that in our massive safe (on-site though). If we need access to just one or two files, we can retrieve them from the offsite NAS, but if we need access to quite a few of them, we can dig them out of the safe.

So that's our workflow. Probably not bullet proof, but it has been serving us well for the last few years. If someone came up with a better solution, we would be all over it!

<comment><USER50> Out of curiosity, how big is the pipe at the office? The one holding the local NAS?

<comment><USER49> I thought it was a 50/5, but the speed test I ran just showed 65/5.

</comment></comment></comment><comment><USER51> > I just need to know they are somewhere safe for decades to come.

The thing about Amazon Glacier... unless they are themselves making more than one copy, and taking hash fingerprints, and storing a couple copies of the hash fingerprints, and using it all to check for bit rot on a regular basis...

...and I don't think they're doing all (any?) of these things...

...then people are sadly going to find that their stuff _isn't_ neccesarily safe for decades to come. One copy on a single piece of media in an Amazon data center somewhere does not actually make for 'safe for decades to come'.

<comment><USER52> [https://aws.amazon.com/glacier/#highlights](https://aws.amazon.com/glacier/#highlights)

> Amazon Glacier is designed to provide average annual durability of > 99.999999999% for an archive. The service redundantly stores data in > multiple facilities and on multiple devices within each facility. To > increase durability, Amazon Glacier synchronously stores your data across > multiple facilities before returning SUCCESS on uploading archives. Unlike > traditional systems which can require laborious data verification and manual > repair, Glacier performs regular, systematic data integrity checks and is > built to be automatically self-healing.

</comment></comment><comment><USER53> I just came across the Plug Kickstarter, which I think might be the basis of a viable back-up storage for professional photographers.

[http://www.kickstarter.com/projects/cloud-guys/plug-the- brai...](http://www.kickstarter.com/projects/cloud-guys/plug-the-brain-of- your-devices)

Specifically, the $129 level, where you get two plugs, which they claim, "to replicate your data in 2 different places." Talk two of your friends in remote parts of the country into letting you Plug in to their home networks, and this might be viable.

</comment><comment><USER19> I am the CEO/Co-Founder of Mosaic. We are a company that helps serious photographers backup their photographers. I am happy to share what we have learned in the past 2 years. www.mosaicarchive.com

As a background, we now have thousands of users and customers. We also finished raising a series A in February. (Not that raising money proves anything) [http://www.boston.com/business/technology/innoeco/2013/02/mo...](http://www.boston.com/business/technology/innoeco/2013/02/mosaic_storage_systems_collect.html)

We are now growing at about 5%-7% a week. We recently peaked in the top 100 grossing US iPad Photo/Video Apps in iOS - although most of our revenue comes outside of iOS. (As they take a 30% cut.)

We target serious photographers (pro's and prosumers) who use Adobe Lightroom. For pure backup customers our sweet spot are those who have outgrown BackBlaze and Crashplan. (Both great services but geared at consumers.)

On the backup side, we help photographers manage their backups by using Adobe Lightroom metadata. Customers can choose to backup everything in Lightroom automatically. However, many photographers use metadata like stars or flags to designate their best photos. We allow users to automatically backup these "best" photos. This provides the automation of the best backup tools with more precision for larger customers.

We use Amazon Glacier behind the scenes to store the original photos. (Yes, WMF the restoration costs even out for us over all of our users.) (Sidebar - we actually ran our data center for months before switching to Glacier...very glad to have made the switch.)

However... we are not an online backup company. Online backup is a feature is our service... but not the entirety of it.

Once we have have photographers photos, we also want to help photographers better use, manage, share, and enjoy those photos. At one point I would have said we are a backup company, now I call us a workflow company.

We also offer a web and iOS App to privately view and share your Lightroom photos. (We take JPG snapshots of the RAW files so they load quickly and have the Lightroom edits. This part of the service runs in Amazon S3 not Glacier) This gives you access to your photos in the same way you are used to experiencing them in Lightroom. (Lightroom users try this for free - [https://itunes.apple.com/us/app/mosaic- archive/id627973694?l...](https://itunes.apple.com/us/app/mosaic- archive/id627973694?ls=1&mt=8))

The next step which we are working on now is adding two-way sync where you can manage your photos in the App and it populates back to your desktop files and Lightroom. We are also working on more collaborative features so photographers can share this culling and editing process with their clients or family members.

The bigger problem we are solving is that photographers have loads of large files... backing them up is painful yes... but managing them all is more painful. Sifting through 000s of images to find your best stuff frankly stinks. This problem is only getting bigger as we shoot more and more.

For those interested in this idea, please consider joining us. We are hiring a couple more software developers this year. [http://www.mosaicarchive.com/about-mosaic-photo- storage/care...](http://www.mosaicarchive.com/about-mosaic-photo- storage/careers/software-engineer/)

Thanks for the discussion and happy to answer all questions.

Best, Gerard www.mosaicarchive.com

<comment><AUTHOR> Thanks for replying Gerard. Do you ever see a version where I can store directly on my Amazon Glacier account?

Especially given "However... we are not an online backup company." I'd feel tremendously safer and more trusting of your service. I haven't used Mosaic so maybe you already do this, I'll take a closer look this week.

Also (in a nice way), your site could benefit from a redesign. Unfortunately I think quite a few consumers judge the trustworthiness and value of a brand by their site/landing design.

<comment><USER19> Hi PStamatiou,

We have certainly thought about giving direct access to customers Glacier accounts and behind the scenes each customer has their own glacier "vault" for potentially this reason. But for many customers they would prefer a set-it and forget it type of service. We didn't want a barrier of first create an glacier account then call us...

We also then didn't know what to do if a customer then changes their glacier files... if we are syncing with Lightroom and this gets out of whack... then it defeats the purpose of the automated sync with your local files. If it just "read only" access, we are already providing this with our App.

I think the difference in what we are providing in online backup is that we are not a pure cloud where we encourage you to delete your local file - <USER2> actually want to sync with your local files. Our philosophy on the workflow side is that changes that you make to your files on the App, should be reflected locally in your Lightroom catalog file. This way you always own your own data.

I agree with you on the site redesign... have had our head down on this. Good news is that the design is approved and being implemented as we speak (although won't be out for a couple weeks.)

Thanks again and happy to answer any other questions. Best, Gerard

</comment></comment></comment><comment><USER54> Great post. I appreciate the focus on minimalism and hobbyist photographers. I think it'd be an interesting project to take on. The technical side doesn't sound too difficult, plug into Amazon, lightroom/aperture.

While the post mentions avoiding externals I think a handy feature would be to push to both an external drive, glacier, and then remove the RAWs locally. That way you have two copies, so the data is actually backed up. Trusting all of your photography to amazon not losing data doesn't sound ideal.

</comment><comment><USER55> I only have a 128GB SSD on my MacBook Air, which is my primary computer. I used to run out of space until I read somewhere that you can use DropBox advanced settings to not keep specific directories on specific devices. So, I am not likely to have directories like, for example, videos2012, pictures2012 synced on my Air but they are on my old Linux and MacBook Pro laptops which have lots of disk space.

With high network speeds, I can quickly re sync directories, or just power on one of my old laptops.

</comment><comment><USER56> I'd use this. 100% for sure.

In fact, "a plugin for Aperture/Lightroom that backs up to Amazon Glacier" is on my idea list. Great minds think alike, fools seldom differ.

One thing I'd like to point out is that photographers are unlikely to be as cost conscious as other consumers. We put a lot of effort into taking these damn photos, and it'd be nice if I could be confident that they'd outlive me. I'm willing to pay a premium for that.

</comment><comment><USER57> Relying on only one storage provider is a little bit risky to me. I started a small desktop app for backing up my files with my family photos in mind, leveraging the properties of erasure coding and multiple dropbox/google drive services. Also adding a bit of crypto to follow the post-prism trend... Please, take a look at [http://yleprovost.bitbucket.org/](http://yleprovost.bitbucket.org/)

</comment><comment><USER58> It is important to be careful with how you try to use Glacier. I have been looking its pricing; It costs $0.01 per GB per month only if you want to upload your data.

Downloads add significant cost if you want to retrieve more than 0.17% of your data in a day.

Downloading 5% of your data increases your monthly rate to $0.097 per GB. 10% increases to $0.187 per GB 50% increases to $0.907 per GB 100% increases to $1.807 per GB

Downloads are also delayed by 4 hours after you make a request.

<comment><AUTHOR> if I have 2TB stored and only want to retrieve a single 10GB photo shoot one month (or even just a single photo), it would not be anywhere close to 5% (.5% in fact) of my total amount stored. The key point here is that we are dealing with TBs of photos that are there for safe-keeping and they have already been tinkered with and all photo JPGs needed have been exported and put elsewhere. This is just for RAWs and you likely won't need to access them again, definitely not 5%+ of them like this.

</comment></comment><comment><USER14> I think Filosync (www.filosync.com, currently in beta, I'm the founder) would work for this. You could have many projects in your cloud and only sync the one(s) you need to a given computer. We'd just need to add a feature that stores "previews" of the items in the folder so you could browse without downloading. But it uses S3 in your AWS account, so would be cost-prohibitive for a consumer storing terabytes.

</comment><comment><USER59> I'm helping build Photofeed, a platform that stores and organizes your private photos from your different devices in the cloud.

Photographers with the problem described in the article are within the target audience, even if we didn't implement some of the key features for them yet (e.g. storage of images in RAW format).

We'd love having some early feedback from you guys! (Didn't officially launch yet.)

</comment><comment><USER60> [http://www.snaposit.com/](http://www.snaposit.com/) tried but the market didn't pay.

</comment><comment><USER61> I've been developing a backup program for a few years now, HashBackup, that encrypts your files locally, with your own private key, and sends them to offsite storage you control: your own Glacier or S3 account, your offsite rsync server (rsync.net for example), your Gmail or other IMAP account, an ssh server, or ftp server. www.hashbackup.com

</comment><comment><USER62> My solution is to copy them all to Glacier, I also have local copies, Glacier is only for worst case scenario retrieval. I wrote about the little script I use here: [http://www.brianlane.com/automatic-backup-of-files- to-s3-and...](http://www.brianlane.com/automatic-backup-of-files-to-s3-and- glacier.html)

</comment><comment><USER63> And what happens if one glacier decides to close? Do you think you'll get any notice ahead of time? I wrote about these types of risks at [http://www.followsteph.com/2012/04/19/what-are-the-risks- of-...](http://www.followsteph.com/2012/04/19/what-are-the-risks-of-cloud- services/)

</comment><comment><USER14> I'm not convinced that retrieval time doesn't matter. If you decide you want several photos, wait 4 hours to retrieve them from Glacier, then realize you wanted a few more and have to wait an additional 4 hours, I think that would get old pretty quickly.

<comment><USER64> I was wondering something similar. Does Glacier have any way to see a preview of the images you are downloading? If I upload 100 images with serialized file names (001.jpg, 002.jpg) how do I know which images to download?

<comment><USER14> There's no preview. Actually there's no way to download or even list your archives through the AWS Console. You need to write (or find) an app that uses the Glacier API.

</comment></comment></comment><comment><USER65> Currently using Crashplan to backup my photos. I copied 200+ DVDs of photos to my hard drive in numbered directories... then deleted them after I had them uploaded (Crashplan keeps deleted files if you choose that option).

</comment><comment><USER66> I believe that [https://www.mediacloud.cc/](https://www.mediacloud.cc/) is trying to solve that right now. However, their website is sparse on details.

<comment><AUTHOR> Definitely quite a few companies are attempting something in this space. I think the one that will win will be the one that actually has photographers as founders and understand the need.

Unfortunately it is quite a niche and most photographers are gadget hounds and don't mind having 2-3 drobos (including an off-site one).

<comment><USER67> It appears that Loom is founded by photographers.

[http://www.loom.com/about](http://www.loom.com/about)

I'd love to hear more about this service from some users. I am bumping up against Dropbox limits with my photos as well.

</comment></comment></comment><comment><USER68> I've always wanted to work on this, but didn't want to work on the stereotypical nth photo sharing/management startup, especially with other projects taking up my time.

</comment><comment><USER69> We (cintrexav.com - a small video conversion service provider) are building something very much like this right now. Will post here when we get to MVP in a month or so!

</comment><comment><USER70> What about flickr and the insane free space they provide? you it's free now right?

searching is also a breeze there.

not sure how you'd go about downloading them all though...

<comment><USER71> no RAW support...

</comment></comment><comment><USER72> "I almost always shoot in small (5.5MP) or medium (11MP) on my 22.3MP Canon 5D Mark III3."

Sorry but what? I actually had to read that a couple of times.

</comment><comment><USER73> Wasn't that the idea behind "bitcasa" ?

-> [https://www.bitcasa.com/](https://www.bitcasa.com/)

</comment><comment><USER74> Covering video too would be great but maybe a second phase handling them separately is a hassle for users.

</comment><comment><USER60> snaposit : [http://www.snaposit.com/](http://www.snaposit.com/) tried but the market wasn't there. I'm going to send this post to the founder to see his take on it.

</comment><comment><USER75> Backblaze?

</comment><comment><USER76> "I almost always shoot in small (5.5MP) or medium (11MP) on my 22.3MP Canon 5D Mark III"

Kind of hard to take anything seriously after reading that. He buys a seriously expensive camera and shoots it in point and shoot size. That's just insane.

What's so hard with a simple home NAS. I replace the drive in my laptop every year for whatever is then biggest (sweet spot) and ue a NAS for backups. RAID5

<comment><USER77> Because cloud _this_ and cloud _that_! I feel like I'm the only person firmly against cloud storage. I'd constantly feel paranoid about my data randomly disappearing at the hands of a company I don't know run by people I don't know on hardware I don't trust.

I want everything local.

<comment><USER78> Local data can randomly disappear too - hard drives don't always fail in a predictable fashion.

Personally, I prefer to use both local _and_ cloud storage (encrypted, bien sûr).

<comment><USER79> I periodically mail a DVD of important stuff to my parents and ask them to toss it in the basement. You could do the same thing with backup tapes, or whatever.

Drives/tape/flash/dvd is pretty damn cheap and easy. These S3 type solutions would have to be much cheaper to be interesting.

<comment><USER78> A DVD holds 4.7GB. Box.net offers 5GB for free.

Besides, how do you verify that those backups can be restored when you need them, if they're offline in some remote location? That seems rather untrustworthy to me. I run checks against parity files regularly to verify their integrity.

<comment><USER80> 10 DVDS hold 47GB. How much does that cost on Box?

And can you download 47GB faster than your mom can mail you a DVD?

<comment><USER78> Storing 47GB would cost you 47 cents/month on Glacier.

 _And can you download 47GB faster than your mom can mail you a DVD?_

Probably, though I'm not quite sure about the speed of S3. I use a cheap VPS instead (much more expensive than Glacier, but also much, much more useful), from which I can easily get 3MB/s, so that would definitively be yes.</comment></comment></comment></comment></comment></comment></comment>


Functional Programming Exchange wrapup: scala, haskell, F# - <AUTHOR> http://www.mmakowski.com/wiki/tech:functional_programming_exchange_2011

<comment><USER2> One should note on the F# side that there are similar modules to Accelerate that let you calculate on the GPU.

Personally, I've found that the performance from the SSE4 units are faster than the GPU, but I have a feeling that this may be due to unaligned data structures.

<http://tomasp.net/blog/accelerator-life-game.aspx></comment>


Third Tesla crash in autopilot mode - <AUTHOR> http://electrek.co/2016/07/11/tesla-model-x-crash-montana-driver-blames-autopilot/ <comment><AUTHOR> "A Tesla Model X crashed in Montana Saturday night resulting in the SUV driving through a guardrail and going off the road. The driver blames the Autopilot but Tesla has yet to chime in. Based on the pictures of the aftermath, the vehicle appears to be totaled with the front passenger side being completely torn off, including the wheel, but fortunately, both occupants are reportedly OK."

"The car was in Autopilot at speed between 56-60 mph, the car drove off the road and hit the guard rail wood posts. I questioned him on how can Autopilot drove off the road by itself, he said he also want to find out."

The accident happened in Whitehall, Montana.</comment>


Zombie Operating Systems and ASP.NET MVC - <AUTHOR> http://blog.bitquabit.com/2009/06/12/zombie-operating-systems-and-aspnet-mvc/

<comment><USER2> Interesting write up, and a nice style.

The filename limitation isn't the only problem. There's also a limit of 260 characters in the URL.

[http://stackoverflow.com/questions/265251/asp-net-url- maxpat...](http://stackoverflow.com/questions/265251/asp-net-url-maxpath- limit)

Boo-sucks if you suddenly run into that without expecting it!

</comment><comment><USER3> > But ASP.NET MVC was based on ASP.NET. Which checks for the existence of a > file before running any scripts.

This is not correct. When you configure an ISAPI filter in IIS, such as ASP.NET or PHP, you can choose whether or not to verify the presence of files. You can also do this via configuration for .NET HTTP handlers. Parts of ASP.NET itself rely on this feature, such as the trace.axd handler and the web resource handlers.

I don't have the option to verify that you can't create those routes, but if you can't, it's not related to that particular feature.

<comment><USER4> You can create these routes via ISAPI, but not via ASP.NET (i.e., writing your own .asxd and observe the same borked behavior)--hence why I know the bug's somewhere in ASP.NET proper. You're correct that my post as-written is off, though. I initially thought ASP.NET was hitting files even though I'd told it not to. After more investigation, I think it's blocking those routes as a security feature to protect you in case you _at some point_ turn file routing back on.

<comment><USER3> Did you check the source? I have never heard of this feature, which certainly doesn't rule it out, but I try to keep abreast of issues like that and haven't heard anything about it.

</comment></comment></comment><comment><USER5> This article (and the comments on it here) is a pretty classic illustration of the "damned if you do, damned if you don't" situation Microsoft (and any other company that at least attempts to preserve backwards compatibility) inevitably ends up in.

</comment><comment><USER6> Reminded me of this Snopes piece about the width of space shuttle parts being determined by the size of a horse' butt. <http://www.snopes.com/history/american/gauge.asp>

Technology may not be immune from the stubbornness of standards that no one feels inclined to change.

</comment><comment><USER7> I couldn't believe the kludginess of Windows did run that deep - I had to check it out: [http://www.dieblinkenlights.com/blog_en/the-unbearable- kludg...](http://www.dieblinkenlights.com/blog_en/the-unbearable-kludginess- of-windows)

And what's the matter with the "all extensions" thing?

/me ducks and says goodbye to karma.

<comment><USER8> You say "goodbye to karma" because you say something bad about Windows on hacker news? That would be surprising.

And with regard to backwards compatibility, I believe, Goedel's incompleteness theorem holds. It's always either kludgy or incomplete ;-)

<comment><USER7> No. I am saying goodbye karma because I am saying something unfavorable to Windows. You have no idea how many people prefer to disagree by voting you down than by starting a legitimate discussion.

You have to see what happens when I say Mono is a bad idea...

<comment><USER8> Windows isn't exactly popular here to say the least. Anyway, I fully agree with you on that strange aversion to expressing disagreement with words.

<comment><USER7> I find this aversion quite disturbing.

And damaging to my karma ;-)

</comment></comment></comment></comment></comment><comment><USER9> Thank God for *nix based systems

<comment><USER6> for indeed they are free of all historical cruft, hallelujah!

<comment><USER10> Perhaps not, but they _do_ allow me to arbitrarily name URL routes! Hallelujah!

<comment><USER11> You /can/ use arbitrarily named URL routes in Windows; Rails runs fine on Windows, after all. It's ASP.NET that doesn't allow you to do it.

</comment></comment></comment></comment><comment><USER12> The legend continues.

</comment><comment><USER13> Honestly the fact that you couldn't user certain filenames in the URL wasn't as big a problem, it was the fact that you couldn't do URL rewriting unless you wrote your own httphandler that annoyed me the most. MVC does an awesome job with regex based URL routing. ASP.Net MVC is by far the best ASP.Net solution MS has provided to date.

</comment><comment><USER14> "In 2009, Microsoft released ASP.NET MVC, a thoroughly modern, orthogonal web framework supporting the most up-to-date understanding of how to architect well-factored, scalable web applications."

Astroturf should be left for the Jetson's dog to play on.

<comment><USER7> It's not astroturf unless the guy is being paid to do a campaign. I have seen things here and on Digg that can only be explained by active astroturf by the part of Microsoft - the active downmodding of comments, sometimes every comment in a given discussion or every comment in the downmoddable range, after posting something that paints Microsoft or its software in an unfavorable light.

It doesn't surprise me a bit.

(burn, karma, burn)</comment></comment>


Girls' Legos Are A Hit, But Why Do Girls Need Special Legos? - <AUTHOR> http://www.npr.org/blogs/monkeysee/2013/06/28/196605763/girls-legos-are-a-hit-but-why-do-girls-need-special-legos

<comment><USER2> > But critics wonder, would it be so hard for Lego to develop — even market — > toys for girls and boys to enjoy together?

The article cites that Lego itself has noticed, through empirical testing, that the two groups (statistically speaking), use the sets differently.

The critics, through virtue of their assumptions about how gender equality should work, seem to imply that this distinction isn't there and everyone should be happy with the same set.

So let me ask this: if there really is a difference in play styles (exterior versus interior focus on the set, for instance), why wouldn't you as a toy maker design two lines of sets - one with a focus on interior details and one with a focus on exterior ones?

If you try to combine it, for the price point, the toy is going to be slightly weaker for each segment of the population - effectively raising the price on both groups to have the toy they actually want by mandating we must have one toy in the name of "equality".

Seriously, can someone explain what's wrong with two lines of toys if Lego (through testing, no less) has found that there are two distinct groups of wants?

No one would suggest that if it were boys split in half in their interest of interior versus exterior, Lego would be remiss in offering two product lines, so it strikes me as incredibly... insecure about gender equality, to the point of pathologically insisting there be no differences, to say that we shouldn't have two lines because of the divide happening mostly along gender lines.

<comment><USER3> You make a good point.

The only problems I can see is that the two lines will very quickly become "pink or ponies for girls" and "dark or soldiers for boys". Whether that's actually a problem or not is for other people to decide.

There's another small problem with quality of testing - there's some possibility of confounding factors in the research.

Both of these come down to "do boys and girls actually prefer different toys, or do they get conditioned by society to like different toys?"

<comment><USER2> > The only problems I can see is that the two lines will very quickly become > "pink or ponies for girls" and "dark or soldiers for boys.

Just so I'm clear, I'm entirely against this.

What I /do/ support is one set of city-scape sets that focus on internal details and the characters involved, and a second that focuses on the building and external set details.

I think that this hits a legitimate play-style difference that happens to be mostly, but isn't entirely, along gender lines.

I'm against the knee-jerk reaction that we're absolutely equal, and everyone gets the same!

We accept, routinely, that there are behavioral differences that are statistically significant (because of genetics, exposure in the womb, hormones, etc) within a gender, but there seems to be a class of people who categorically insist that there is no such trend between genders.

This isn't to say every little girl wants to play the same way, but that there are statistical biases to the genders which might be intrinsic, not societal constructs.

"Equal before the law" and "equal member of society" does not mean "the same in every way", and trying to enforce the last of these can be harmful rather than helpful.

<comment><USER4> If you look at the products on LEGO site, it looks like it is coming to "pink or ponies for girls" and "dark or soldiers for boys," sadly. I agree that everyone shouldn't have to have the exact same thing, but they could cut out the part where they slather the girl products in pink and characters with small skirts, and include some normal girl characters in the otherwise boy- oriented sets.

EDIT: The more I think about this:

> "Equal before the law" and "equal member of society" does not mean "the same > in every way", and trying to enforce the last of these can be harmful rather > than helpful.

the more this frustrates me. No one is saying everyone should have to be the same. Did you even look at the LEGO products? What parents are reacting to is the reservation of action, space, science, adventure, technology, etc. for one gender and homemaking, baking, beauty, and animals for the other gender by putting very distinct gender-specific markings on them to make it clear which belongs to which. I'm extremely skeptical that girls just genetically prefer pink things and dresses. This is about forcing people into cultural categories which limit their options for individual expression, not some silly attempt to make everyone do the same things.

</comment></comment></comment></comment><comment><USER5> Why do girls need dolls? Why are there any marketing differences between men and women in general? Are we really so blind as to call this the result of gender stereotyping?

Men and women are different in far more ways than the genitalia. We have spend decades trying to convince ourselves that male and female roles are fabricated by society and have no basis in biology. And we have failed, because ideology does not change biology.

Have we really made so little progress that we _still_ cannot celebrate men and women for their differences and their unique contributions, and strengths? In other words, do men have to cease being men and women have to cease being women in order to consider themselves "equal"? Gender equality is becoming its own form of oppression. No, not equality itself (for men and women have the same human rights), but the wrong-headed attempts to suppress and eradicate the distinctions between genders.

</comment><comment><USER6> I had always assumed this was to encourage parents to buy different versions of the same toy, instead of having their kids share one.

</comment><comment><USER7> Legos used to be building blocks, now they are "Lego People" that can be collected, and the blocks themselves are the accessories.

</comment><comment><USER8> Ironically, they would come in for less criticism if they simply continued to not sell Legos to girls.

<comment><USER9> But this isn't a case of them being criticized when they try to make an /improvement/ in their behaviour. They would always sell Lego to any girl who can pay for them, the bad behaviour in in marketing specifically to boys and creating Lego sets that reinforce gender stereotypes.

They could simply stop doing that.</comment></comment>


Show HN: Talent vs. Luck – A recreation of the paper's model - <AUTHOR> http://joshuaballoch.github.io/recreating-talent-vs-luck/ <comment><USER3> When selecting a model to demonstrate some dynamic behaviour:

1\. First select the simplest model that captures some generic and essential.

2\. Vary the parameters and introduce additional variables to that model to see how sensitive it is to different parameters values and variations of the model. The general state phase under variation is what builds confidence to the model.

Some other results:

* Peter Norvig: Simple Economics Simulation: [https://github.com/norvig/pytudes/blob/master/ipynb/Economic...](https://github.com/norvig/pytudes/blob/master/ipynb/Economics.ipynb)

* Uri Wilensky even simpler version [http://www.decisionsciencenews.com/2017/06/19/counterintuiti...](http://www.decisionsciencenews.com/2017/06/19/counterintuitive-problem-everyone-room-keeps-giving-dollars-random-others-youll-never-guess-happens-next/)

* Bouchaud JP, Mézard M (2000) Wealth condensation in a simple model of economy. Physica A 282:536–545. [https://arxiv.org/abs/cond-mat/0002374](https://arxiv.org/abs/cond-mat/0002374)

* Colloquium: Statistical mechanics of money, wealth, and income Victor M. Yakovenko and J. Barkley Rosser, Jr. Rev. Mod. Phys. 81, 1703 – Published 2 December 2009 [https://link.aps.org/doi/10.1103/RevModPhys.81.1703](https://link.aps.org/doi/10.1103/RevModPhys.81.1703)

The general stable result that emerges from these simulations again and again is the effect of multiplicative randomness. There may be other factors, but it's usually the largest by far and you need to drill deeper if you want to quantify the effect from other factors.

</comment><comment><USER4> Having built models like this by programming before [1]. I think you can only "prove" things about the system _you_ construct. Meaning, in reality it has (or could have) little to no basis. That being said, I think building models that reflect something we _know_ can be valuable in providing insights - <USER2> ahouldnt be used as proof.

Also 0.62 is not near average depending on simulation count / size. That's a pretty significant margin (>20%) above average.

[1] [https://austingwalters.com/modeling-and-building-robotic- sea...](https://austingwalters.com/modeling-and-building-robotic-sea-slug/)

<comment><USER5> > I think you can only "prove" things about the system you construct. Meaning, > in reality it has (or could have) little to no basis.

I think the author is aware of that and the point is more that people generally assume that talent is guaranteed to lead to success, and they have no basis to make that assumption either. This model demonstrates that the intuition is fallible.

</comment></comment><comment><USER6> Why does this need to be a 2D simulation? I don't see how geometry comes into it at all. Also worth reading [http://bactra.org/weblog/491.html](http://bactra.org/weblog/491.html)

<comment><USER7> Why does it need to be a simulation at all? The model is essentially a geometric random walk with number of trials N and probability of success in each trial P, with P varying.

In an additive random walk, the distribution of positions after N time steps is Pascal's triangle with zeros injected every other column and with each row multiplied by one half [1], which is just a shifted binomial distribution (with zeros injected at odd distances on even time steps, and at even distances on odd time steps), with probability mass function of `arw_pmf(k, N, P) = (N choose k) * P^k * (1-P) ^ k - N/2`. For large N, the distribution approaches the normal distribution.

In a geometric random walk, the power of the scaling factor takes on the shifted binomial distribution. In this case, the scaling factor is 2, so the probability mass function is `grw_pmf(k, N, P) = 2^arw_pmf(k, N, P)`. Note that this is _not_ a power-law distribution, and therefor will _not_ exhibit a robust 80/20 rule. Even if you convolve this distribution with an input normal distribution over P, as they do in the paper, you would not get a power law distribution.

The effect of a change in P, which is used to model talent, is to shift the distribution, but not to greatly affect its shape. The shift is consistent with our expectations that greater "talent" results in higher probability of accumulating more capital, though there is of course an overlap in the distributions of two agents with differing talent.

All that being said, I suppose it's possible that the 2D discrete simulation introduces temporal correlations that could alter the population's final capital distribution into a power law distribution. If that's the case, then the power law distribution is due entirely to these temporal correlations, which suggests to me a different insight, namely that the source of inequality is these temporal correlations. In other words, if people who have recently been successful are more likely to continue to be successful, then you will have inequality. Since this seems to describe our world pretty well, perhaps inequality is inevitable?

[1]: [http://mathworld.wolfram.com/RandomWalk1-Dimensional.html](http://mathworld.wolfram.com/RandomWalk1-Dimensional.html)

</comment></comment><comment><USER8> OP, you should correct the first line

> I recently came across the paper titled Talent vs Luck: the role of > randomness in success and failure, by A. Pluchino. A. E. Biondo, A. > Rapisarda, _on Hacker News on Hackernews._

</comment><comment><USER9> Red flag:

> People start with the same allotment of capital, and are given a number > between 0 and 1 to represent their "talent". Talent is normally distributed.

Maybe the author meant "uniformly distributed"?

EDIT: Looks like talent is normally distributed with mean 0.6 and stddev 0.1, so it's quite likely between 0.3 and 0.9 (and most likely between 0 and 1, indeed).

</comment><comment><USER10> A key purpose of the original paper is to inform policy to improve public funding of research [1]. Thus, to a first-order approximation, it should reflect realities. However, ...

The number of lucky and unlucky events in the paper (figure 5, page 8) are _each_ around 5-7 events per agent on average, where 'lucky' is defined as doubling the capital (or success) _accumulated_ so far and 'unlucky' as halving it. In the real world, how many regular people/scientists have that many career-defining events? Most are quite risk-averse, especially later in their careers. Some entrepreneurs could be exceptions but they are a small minority (single-digit percentage or fewer) [2].

This parameter (no. of big lucky/unlucky events) diminishes the role of talent in the simulation. In real life, most talented people can avoid having 5-7 big 'unlucky' events in their career. This renders the simulations questionable.

\--> It's like saying talent doesn't matter much for blackjack players who regularly bet half of all their chips. Yes, if one gambles that much, then talent would probably matter relatively little. Do most people do something like that with their career? [3]

Research has shown that Log-Normal Distribution could fit data on real-world success as well as Power Law and sometimes better. [4] This suggests that multiple independent factors could play multiplicative roles in success. Talent, luck, grit, location of birth/childhood, educational opportunity, parental guidance, ambition, etc are some candidates. [5]

If several factors interacting multiplicatively influence success, the number of individuals who achieve success at a very high level would be quite small, as they need to 'score' high on several of them. This can be modeled quite well with Log-Normal Distribution.

[1] [https://arxiv.org/abs/1802.07068](https://arxiv.org/abs/1802.07068)

[2] As an entrepreneur myself, I would avoid betting half my capital unless the potential gain is far, far higher than doubling my capital. I believe most other entrepreneurs think similarly.

[3] Note that capital/success appears to be quite broadly defined in the paper, and can be interpreted to include expertise, reputation, and other resources as well as tangible capital.

[4] [https://arxiv.org/pdf/1304.0212.pdf](https://arxiv.org/pdf/1304.0212.pdf) "Moreover, even if the data do not rule out the power-law model usually the evidence in its favour is not conclusive – some rivals, most notably the log- normal and stretched exponential distributions, are also plausible fits to wealth data."

[5] Note that luck as defined in the paper does not reflect factors like location of birth, educational opportunity, or parental guidance.

<comment><USER9> > each around 5-7 events per agent on average [...] In the real world, how > many regular people/scientists have that many career-defining events?

A significant event every half decade or so does not seem unrealistically high to me.

> that Log-Normal Distribution could fit data on real-world success as well

Power laws (eg Pareto distribution) and log-normal are extremely different though in the tails. The log of a log-normally distributed RV is normally distributed, and thus effectively restricted to a fairly small support area (+/\- 5 std devs), as the tail falls off extremely fast (exponentially). The log of a Pareto distributed RV is exponentially distributed, and can get pretty high (the tail of the pdf decays only with some power, ie polynomially).

So, I'd expect the properties and conclusion to be quite different (more extreme wealth under power law/Pareto than under lognormal).

> Research has shown that Log-Normal Distribution could fit data on real-world > success as well as Power Law and sometimes better. [4]

This surprised me, and I don't think the paper [4] supports your claim. It examines _only_ the super rich (Forbes Billionaires), not the entire population. Log-normal might model a few hundred rich people reasonably well, but if you fit to the entire population, I'd think log-normal is basically ruled out by the rich (while I'd expect Pareto still to sort of work).</comment></comment>


Show HN: Instant click tests for visual interfaces - <AUTHOR> http://www.usaura.com/

<comment><AUTHOR> New project I'm working on. Wanted to make a site that's as simple as an image uploader or a code paster, but for click testing. You upload a screenshot of your interface and ask people to click somewhere. The app will generate a heatmap of the clicks, as well as show you how long they took.

Would love any feedback or suggestions. Also: would you find a tool like this useful? Would you pay for it given more functionality? Cheers.

<comment><USER2> I saw this on reddit yesterday. I love the simplicity, and I see you've been changing some parts of the UI today (which looks very nice). It's a very useful tool. We've been messing around with it at work throughout the day, and everyone's liked it so far.

My only question is how do you pronounce the name? Since I can't settle on a pronunciation, the name is not too memorable for me as of right now.

As for the pay options, it really depends on how much you plan to charge, and what features would be provided in the paid version. Overall, it is a really useful tool and my coworkers and I will definitely be using it for our projects.

<comment><AUTHOR> Thanks for the feedback! Glad you're finding it useful.

Name should be pronounced like "Use Aura" but without a gap. It's a play on the word Aura, combined with User, or Usability, as the heatmap is a bit like an aura.

There are a couple of angles I see for a paid version:

1) Beef up the features by adding more tests types (e.g. a preference test like: "Which do you like more: A or B?" -- like a poll but visual) and more customisation (e.g. ability to chain tests together, easy way to compare test performance for iterations, priority in the public test pool etc.).

2) Hook it up to Amazon's Mechanical Turk and basically get instant outsourced testers. Perhaps you can even do some demographic filtering here, although I don't have any experience with Amazon Turk yet. This option can probably tie in with 1) since the single page tests right now are probably too simple to pay for--you'll want to get more value out of each one, so getting a chain of tests with comments will make more sense.</comment></comment></comment>


NeXT vs. Sun (1991) [video] - <AUTHOR> https://www.youtube.com/watch?v=UGhfB-NICzg <comment><USER3> One of the things that really disappoints me about computing is how GUI development is such a horrid treadmill of constant reinvention and total reboots with no overall cumulative progress. The Web is just now reinventing things with React and components that were perfected in several different desktop systems at different times. Something about UI development makes long term reuse and depth building impossible.

I think one factor is that good UI and UX is nearly always proprietary, so these great platforms get built but then ultimately die when the market moves on.

<comment><USER4> There's nothing dead about this UI platform. It got a new theme in 2001 and is still going strong today. The colors have shifted over the years and the scroll bars switched sides and have mostly faded away, but it only takes a glance at the code to see that it's the same platform at heart.

<comment><USER5> Except that some elements _have_ changed massively.

You no longer have window-independent focus. You cannot bind hotkeys to windowing events. You cannot toggle through _all_ windows via alt-tab, you can't set focus-follows-mouse.

Source: I've been use WindowMaker (a NeXTstep clone) for 20 years.

<comment><USER4> I really don't see how some tweaks to window manager behavior to make it more accessible to Mac and Windows users are more fundamental and massive than the aforementioned change to scrollbar behavior to make it more accessible to Mac and Windows users. They were all _noticeable_ , for sure, but from a technological perspective they were all quite minor.

Plus, I'm not sure how many of the things you mention are even changes relative to genuine NeXTSTEP rather than just differences from WindowMaker's imperfect emulation of it. Focus-follows-mouse was an X11 thing WindowMaker shoehorned into its NeXT-like environment; genuine NeXTSTEP was click-to- focus, though it could be hacked to emulate focus-follows-mouse: [https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1994/_Mi...](https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1994/_Misc94-II.html)

</comment></comment></comment></comment><comment><USER6> 'interface builder' 1991 reminds me a lot of interface builder from xcode in 2016

<comment><USER7> Interface Builder remained nearly unchanged all the way up until Project Builder turned into Xcode and shortly after IB got blended in. Here's a screenshot from IB under OS X 10.2: [https://cl.ly/0J1g1p1m0T3C](https://cl.ly/0J1g1p1m0T3C)

I personally liked the two being separate applications. IB is still great today, but it (and Xcode) slowed down noticeably when the two combined.

<comment><USER8> I had almost forgotten about the horrendous horizontal pinstripes in early OS X. Looking back it's hard to understand why people drooled over the early OS X UI.

<comment><USER6> does this have something to do with rendering on CRTs? How they draw horizontal lines?

<comment><USER9> No, nothing.

</comment></comment></comment></comment></comment><comment><USER10> And the same year, 1991, Tim Berners-Lee had "world's first-ever web site and web server, running on a NeXT computer at CERN":

[https://en.wikipedia.org/wiki/Tim_Berners- Lee](https://en.wikipedia.org/wiki/Tim_Berners-Lee)

[https://en.wikipedia.org/wiki/Tim_Berners- Lee#/media/File:Fi...](https://en.wikipedia.org/wiki/Tim_Berners- Lee#/media/File:First_Web_Server.jpg)

<comment><USER11> Let's not forget the development of Doom on NeXT, which ironically went on to make PC/DOS cool in gaming:

[https://en.wikipedia.org/wiki/Development_of_Doom#Programmin...](https://en.wikipedia.org/wiki/Development_of_Doom#Programming)

<comment><USER10> It wasn't ironic, at these "earlier" times it was common to use significantly stronger computers to develop for the "smaller targets": in 1975 Altair Basic, the first product of (then called) Micro-Soft, which had to run on the 8080 computer with only 4 kilobytes of memory was developed on the PDP-10 computer owned by Harvard University:

[https://en.wikipedia.org/wiki/Altair_BASIC](https://en.wikipedia.org/wiki/Altair_BASIC)

Paul Allen wrote an emulator for the microprocessor which run on PDP-10. He was able to extend his previous version of emulator for that.

At the time Microsoft developed MS-DOS (actually modifying the program they have bought), around 1981, they owned their own DECSYSTEM-2060:

[https://en.wikipedia.org/wiki/DECSYSTEM-20](https://en.wikipedia.org/wiki/DECSYSTEM-20)

<comment><USER12> Also, the original Lucasfilm Commodore 64 games, such as Maniac Mansion, were cross-compiled on UNIX workstations, transferred over the network and uploaded to running C64s — way back in 1987! (Source: The Thimbleweed Park podcasts [0], which I highly recommend.)

[0]: [https://blog.thimbleweedpark.com](https://blog.thimbleweedpark.com)

<comment><USER10> Three years earlier, the development for the 1984 game "Match Point" for ZX Spectrum (the graphics in the video is original, the sound is fake by the youtube video producer):

[https://www.youtube.com/watch?v=eRO_nY-d94w&t=22s](https://www.youtube.com/watch?v=eRO_nY-d94w&t=22s)

was done by then-just-software company named Psion on their VAX computer:

[https://archive.org/stream/sinclair-user- magazine-036/Sincla...](https://archive.org/stream/sinclair-user- magazine-036/SinclairUser_036_Mar_1985_djvu.txt)

</comment></comment></comment></comment></comment><comment><USER13> For one of my summer jobs in college, this is around 2005, I had to port an old NeXTSTEP phone system to Mac OS X. I was amazed at how easy this was, considering it was just taking Carbon to Cocoa, and amazed at how ahead of its time NeXTStep's APIs were. Project Builder (XCode) and Interface Builder were created on these machines. Then bought by Steve@Apple.

<comment><USER14> Carbon was the name for the cleaned up, sanitized version of the old Classic Macintosh APIs that was compatible with OS X[1]: [https://en.wikipedia.org/wiki/Carbon_(API)](https://en.wikipedia.org/wiki/Carbon_\(API\))

Steve founded NeXT after getting fired from Apple, as is reflected in part by the name of the company. Apple acquired NeXT in 1996 for $429mm, which is how Steve Jobs came back to Apple: [https://en.wikipedia.org/wiki/NeXT#1996.E2.80.9397:_Apple_me...](https://en.wikipedia.org/wiki/NeXT#1996.E2.80.9397:_Apple_merger)

[1] Well, what was _then_ called OS X.

<comment><USER15> I've heard that purchase described as "Jobs buying Apple for $-429mm" :)

I still remember reading reviews of the NeXT OS as a child, wishing I had the hardware to run it (from memory I was still running a PC at the time - <USER2> original IBM PC, which was considered a dinosaur even then).

</comment></comment></comment><comment><USER16> Am I the only one who had the same development feelings but only on Windows with Borland Delphi?

You could do the same video with Delphi vs. Visual C++ playing in the 90s.

<comment><USER17> That's why Microsoft stole all of the key people from Delphi team.

<comment><USER18> How can they steal them? They were not slaves.

<comment><USER17> [http://www.wsj.com/articles/SB863034062733665000](http://www.wsj.com/articles/SB863034062733665000)

<comment><USER18> I don't have a account so I can't read the whole article but I can't see how someone could claim that the people was the property of Borland.

</comment></comment></comment></comment></comment><comment><USER19> I always feel like the Sun programmer, writing web apps today.

<comment><USER20> Have you tried some of the newer _magically-handles-everything_ frameworks like Meteor? Yes, it may not suit every project and I too use the more traditional tools for a lot of my work.

But when I do use Meteor for a project, I feel exactly like the NeXT developer in this video.

</comment></comment><comment><USER21> I wonder if the Sun programmer knew he would be portrayed as a patsy..

<comment><USER22> I mean he knew it was a video for NeXT, so I don't know what else he would have expected.

Though I would say I don't think he was portrayed badly in this video, the point was not that he was a problem, the point was that NeXT's application development environment is better.

<comment><USER23> What I found interesting, up until the Tiff issue, they were basically on par. The Sun programmer said his code would basically work with anything except tiff. The NeXT people probably knew this was a limitation of a specific library he was using and threw it in to make it less fair.

</comment></comment></comment><comment><USER24> @12:19: [https://youtu.be/UGhfB-NICzg?t=739](https://youtu.be/UGhfB- NICzg?t=739)

> At this point, we threw the programmers an unexpected but not unrealistic > curve.

> Like a typical user, we asked them to add a feature not in the original > spec. In this case, a button would recall all the trouble logs for a > particular customer.

> Using NeXT Step, the NeXT programmer completed the task in about 20 minutes.

> [NeXT progammer discussing some details]

> The sun programmer also estimated a time of 20 minutes, but it took about 45 > before he was ready to test his version.

This was about 20 hours in, which means that since they started on Wed, 30 October 1991 and assuming maximum 8-hour days, they have missed Halloween and would be at least halfway into Friday. The video states that the programmers finished on Sat, 2 November.

The video goes on to state that the NeXT system enabled the NeXT programmer to add a number of features such as system fonts and button icons "for free", which goes to show that the video's intended audience are managers and executives of software development teams who would of course want faster development, ad hoc requests, and cost-free features.

I personally would have been tempted to (╯°□°)╯︵ ┻━┻ once they announced a planned "unexpected" feature request because rather than train users and customers to frontload requirements in order to benefit from the design decisions that would be made as a result, the video encourages customers to believe their out-of-spec requests will be more quickly accommodated if only their programmers were using object-oriented NeXT Step.

25 years later, we know the truth about how easy it is to shoehorn in 11th- hour feature requests when using object-oriented code.

EDIT: link to specified timecode; formatting; additional detail about date code was written.

<comment><USER25> > they have missed Halloween

I don't understand this part. You said you're assuming 8-hour work days. AFAIK, it's not at all common to take Halloween off from work. So what's the point of mentioning that day?

<comment><USER24> Just that there are so few secular holidays in the US work context and Halloween is one of those non-holidays (like Cinco de Mayo in California) where people in the US will make an extra effort to spend time with friends and family.

</comment></comment></comment><comment><USER26> "Sun" was trimmed out of the title.

Still an enjoyable video.

<comment><AUTHOR> It was originally posted with the title:

 _NeXT vs Sun head-to-head programming competition (1991) [video]_

</comment></comment><comment><USER27> But ultimately most application developers wouldn't be using $15K workstations anyway.

<comment><USER28> Exactly. The important thing about this video in retrospect is that NeXT had completely misidentified a viable market (workstation hardware for customer service representatives) and the competition within that market (Sun).

Meanwhile, in another universe from this video, 1991 was the same year that Visual Basic was released. The rest is history there.

Ultimately, the plan of having NeXT's tools on dedicated hardware paid off.. but it took another 20 years for it to happen, and the target hardware was consumer hardware costing 1/50th of what's shown here.

<comment><USER29> I wonder where there is the VB version for web applications.

<comment><USER30> Isn't that ASP.net?

<comment><USER29> Kind of, but not really in regards to UI design versus the CSS/HTML/JavaScript mess.

<comment><USER31> Does Visual Basic pre-.NET/WinForms even support layout _at all_?

Edit: Doesn't look like it. [https://support.microsoft.com/en- us/kb/182070](https://support.microsoft.com/en-us/kb/182070)

<comment><USER29> GUI RAD tooling is much more than just layout, and at least it can center text and quite a few other things that require CSS tricks.

Yeah HTML does layout, what about everything else?

Where are the promised components, without frameworks faking them on top of a HTML, CSS, JavaScript?

Apparently each browser still implements just part of it.

Or a designer tooling to make use of such components in RAD way like VB.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> That was really fun to watch. I love old tech videos...thanks!

<comment><USER33> Here's one of a demo of Lucid's Emacs-based C++ IDE from around the same time: [https://www.youtube.com/watch?v=pQQTScuApWk](https://www.youtube.com/watch?v=pQQTScuApWk)

<comment><USER32> Nice. Thanks for that. Enjoyed it very much.

</comment></comment></comment><comment><USER25> Does anyone know what kind of database the NeXT version of the application probably used? Plain text files? .plist files? A relational database? Something else?

<comment><USER34> IIRC the NeXT workstations came with a contemporary version of Sybase (ancestor to SQL Server).

</comment></comment><comment><USER35> Man that control to put on the multiple buttons and give them spacing was really something. Kinda useless but really quite impressive.</comment>


The California Economy Isn't Just a U.S. Powerhouse - <AUTHOR> https://www.bloomberg.com/opinion/articles/2019-04-24/california-economy-soars-above-u-k-france-and-italy <comment><USER2> Interesting article. The article actually sparks another question: in the last 18 months or so, I've had maybe 3 different people tell me that California is actually a net economic drain on the USA, an example of failed liberal or neoliberal economic policies (I can't remember which).

What's up with that? Why bother to assert something (California's economy has failed) so counter-factual? I was unable to figure that out on-the-spot.</comment>