onethumb

Thanks! We think so. :)

I want this, too. SmugMug (our other platform) supports them. So we already have the tech done (for a long time). I hope we add support on Flickr.

We’re allergic to ads. If I knew how to make Flickr work at its scale without ads even on free accounts, I’d do it.

Since I can’t figure it out (yet?), free accounts have ads and Pro don’t. As long as I’m running the show, that will remain true.

I'm too big of a nerd to let the RSS feeds, open APIs, etc go. :)

Alas, Flickr wouldn't even be alive if we hadn't increased the price ($$) and value (features) of Pro relative to things like intrusive ads on free accounts, etc. The very reason it's alive is because we have intrusive ads on free accounts, but no ads on Pro accounts, including for viewers. I don't expect that to change anytime soon.

We have some great plans to further increase Pro's value, but we disagree that Pro is too expensive. Relative to our peers, it's a bargain for unlimited storage, advertising free, etc etc.

Love to bounce future ideas off of you, and thanks for the article!

We have a lot of mobile usage and the app works fine, so I'd love to know more about what you're experiencing with it. Can you contact our Support Heroes so we can assist? https://www.flickrhelp.com/

You make a fair point about the age verification thing. I'll look into it. It's probably based on a legal requirement that we have to deal with, even if the solution is silly. Sorry about that.

As far as I know, we haven't considered that, but it's a good idea. I'll noodle on it. Thanks!

We rely on self- and community-moderation. As long as content is flagged appropriately, we allow and embrace content that's often banned on other platforms, such as artistic nudes.

Not everything is allowed, though - here's the list: https://www.flickrhelp.com/hc/en-us/articles/20529310987796-...

We do have real, human, in-house customer support. It's good and fast.

Thanks! I get asked to write again frequently, but finding the time is tough. I'll see what I can do. :)

Thanks for the feedback and feature request. I don't hear this request often for Flickr, but it's a core and beloved feature on our other platform, SmugMug, which you might want to check out if you haven't.

Doesn't sound like us. When was this?

Can you elaborate on the markdown embed request? In which contexts would you want that?

Yes. Flickr was losing a ton of money (>$50M/year) when we bought it, and it's now cash flow positive and profitable. Not by a lot, alas, but the difference between $1 and $0 or less is the difference between life and death. Flickr is alive!

As I think the article captured pretty well, we could make a lot more money if we went the algorithmic-privacy-violating route, but we don't want to. So we aren't.

Since we never raised a round of funding, as long as the bills are getting paid, we can do what we want - build a company for the long-term based on a great photography community. So that's what we're doing. :)

Just finished reading. Glad they captured what we're doing - photography & community - and what we're not - algorithmic feeds & privacy violations.

We have lots of work to do, and I think most of the criticisms are fair and on our road map. Small team, working hard, listening to customers. Like we've been doing for 24 years. (We're bootstrapped and privately owned, never taken VC).

AMA.

Hey, owner & CEO here. Reading this now, but AMA.

Probably needs a (2010) label. Great article, though.

Is that true? This comment suggests otherwise, with citations. https://news.ycombinator.com/item?id=46351511

She was known as being _extremely talented_ at software development, particularly her knowledge of low level hardware and how to optimize around constraints.

Uber could not run the complete global rider/driver flow from a single server.

This looks super interesting for single-AZ systems (which are useful, and have their place).

But I can't find anything to support the use case for highly available (multi-AZ), scalable, production infrastructure. Specifically, a unified and consistent cache across geos (AZs in the AWS case, since this seems to be targeted at S3).

Without it, you're increasing costs somewhere in your organization - cross-AZ networking costs, increased cache sizes in each AZ to be available, increased compute and cache coherency costs across AZs to ensure the caches are always in sync, etc etc.

Any insight from the authors on how they handle these issue on their production systems at scale?

A lot of great companies have come out of "bad for business, good for hobbyists" ideas... :)

Related discussion:

John Carmack's arguments against building a custom XR OS at Meta

https://news.ycombinator.com/item?id=45066395 (11 days ago; 527+ points; 646+ comments)

Love to hear whether you agree or not and how your project is different?

The whole point is for it to cost less (ie, smaller size) for the sender and cost more (ie, larger size) for the receiver.

The compression ratio is the whole point... if you can send something small for next to no $$ which causes the receiver to crash due to RAM, storage, compute, etc constraints, you win.

Yep, I love Apple, follow them closely, own a Mac Studio with an M3 Ultra and a MacBook Pro with an M4 Max, and it's still confusing. :)

I mean, surely a Mac Studio with an M4 Max must be the best, right? It's an entire CPU generation ahead and it's maximum! Of course, it's not... the M3 Ultra is the best.

Naming things is hard.

If Apple's so great at naming things, tell me (without looking) which is bigger/better/faster for their CPUs: Max or Ultra?

I'm not "engineering" anything - I'm just stopping a service. I close the account, or disable billing, or whatever that step requires. I don't even read the data back out or anything - just cancel. Doesn't really require "engineering".

Not useful for me at environment setup time because I never want any of my data deleted. The only time is if I decide to abandon that cloud provider.

Most cloud providers do this now. Encryption operations like this are relatively easy to detect.

Certainly some of this simply comes down to "how valuable is my data?".

Currently, given the extremely low (and dropping YoY) cost of storing cold data at rest, the essentially free cost of ingest, and the high cost of retrieving cold data which I almost never have to do, the ROI is wildly positive. For me.

And since all of these things (how many providers, which providers, which storage classes, how long to retain the data, etc) are all fine-tunable, you can basically do your own ROI math, then pick the parameters which work for you.

Only if you allow permissions to set a lifecycle rule...

No delete credentials present a cost issue when moving from a provider... I've accidentally left data behind after I thought I'd deleted it. Worth the risk, and learned my lesson.