They have bbcode and html embed, with dynamic width and automatic linking back to the page with alt text, but nothing for markdown.
I can use HTML for my blog but my blog is written and marked down and I would rather just stick to markdown, plus many forums have switched to markdown and won't accept an HTML embed.
My current solution is to convert the following by hand from something like
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).
Author here. Glad this made its way to you. I've been chatting with Shay and don't have a ton of questions, but I'd just emphasize that even as Flickr continues to (rightfully!) modernize, please (a) don't drop the features that make it different than the closed social media platforms (e.g., RSS, open APIs, etc.) and (b) maintain and enhance the power features that make Flickr more than just a place to dump photos (e.g., would love to see a camera AND lens combination finder, search by EXIF, enhancements to the world map, etc.). Very much looking forward to more modern file types.
And while I think the site strikes the balance decently at the moment, Pro is too expensive for ads to get more intrusive (for the Pro user and for others looking at his/her photos).
But as I hope was clear, I'm a big supporter and would love to see the platform continue to thrive. If you're ever looking to bounce thoughts off a user, or anything else, I'm happy to help!
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!
I actually think we agree that the value proposition is currently there for pro, per what I laid out in the piece (though of course I look forward to things that will further increase its value). My comment was supposed to make clear that adding more ads to Pro could undermine that value—but it sounds like that's not the plan, which is great.
Is HEIC/HEIF support somewhere on the roadmap? I know people have been asking for years and you don‘t want to be a backup site, but display photos. But this whole conversion thing makes me uncomfortable anyway.
I think I asked Nathan B all of my important Flickr-post-your-aquistion questions at a 7CTOs event way back in 2019, but that was a lifetime ago. Do you make enough money off my Flickr Pro subscription to keep it going indefinitely? I'd rather pay you then funnel more cash to AWS or Google for cloud backups, but I'm not a professional photographer, so the actual SmugMug products aren't valuable for me and there's always the slight dread that you kill Flickr because it's a blip of a side hustle to the main business.
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. :)
I do a lot of event photography as a creative outlet. I want my friends to be able to download individual photos and photo albums easily. As an example, I just photographed a fundraiser for my rugby team last week, and I made all my shots available in a Google Photos album: https://photos.app.goo.gl/PfwHpEJejywBRiZp7
And while that works, I don’t necessarily love feeding all my creative content into the Google machine. I would rather support a diverse photography ecosystem.
Have you explored making downloading individual photos and albums a prominent feature? Mind you, I realize I am weird photographer who does this stuff for free, and I don’t care about attribution or watermarks. I just want my friends to be able to get their photos easily.
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.
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.
When an account is banned does support offer an export?
My experience with similar 'some things are okay, we know it when we see it' - is that support is extremely hostile if it responds (vimeo) .. non-existant if you are banned (google, meta / facebook)
and most often "sorry everything is deleted, your content, friends list, messages - all gone." (all of the above including tumblr)
So yeah, building content and friend's lists on other people's farmland is a thing of the past. with censorship that costs you friends and data people are better off self hosting and doing the fediverse thing, or going to places that explicitly allow almost all explicit things.
There was a time when flickr was very cool for sharing and making friends with people in niches that was to hard find in many places, same with tumblr and it was ruined in a similar way.
It's fine, and I completely understand, it's just not what it once was. Many things are not.
Hello. I just logged in for the first time in a while and it asked me to verify my age, despite the fact that my Flickr account is 22 years old. I've been paying for Flickr Pro as long as that has been possible, if I remember correctly, my Flickr user number was ~620. Surely, with an account that's 22 years old you don't need to hand my personal information to Peter Thiel?
To some degree I only still pay for it out of nostalgia for what it was. I stopped using it when it started trying to upload my entire camera roll every time I opened the mobile app - Flickr was never about storing all your photos on someone else's server, it was about curation and community. It somewhat lost that as phone photography got more popular, and instead of empowering users to do that directly on their phone, it presented itself as a mere backup utility. The app seems to be entirely non-functional now, no content loads at all for me. Flickr's failure to move with the rise mobile photography feels like its biggest misstep - age verification for an account that is 22 years old though might actually convince me to stop paying. I'm not using it, the mobile app is broken, and now it wants to hand my PII to a third party.
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.
Have you considered offering free storage for freely licensed (cc-by & cc-by-sa) works?
I want to share my photos under a free license, but the one thing that always put me off Flickr was that I would have to pay an indefinite subscription to contribute to the commons.
Hey, it's Saturday night and I'm on Hacker News woot woot.
I work on climate technology (sucking carbon dioxide out of the sky), and I have a side quest to create a "Freedom to Breathe" mural in Manhattan before the upcoming New York Climate Week. Might be up your alley knowing artists and photographers. How interested are you in working together on making a mural?
That particular section I have to Wikipedia article seems to have gone through a bunch of anonymous edits back and forth around the content of this citation
She was known as being _extremely talented_ at software development, particularly her knowledge of low level hardware and how to optimize around constraints.
I'm saying you can keep track of all the riders and drivers, matchmake, start/progress/complete trips, with a single server, for the entire world.
Billing, serving assets like map tiles, etc. not included.
Some key things to understand:
* The scale of Uber is not that high. A big city surely has < 10,000 drivers simultaneously, probably less than 1,000.
* The driver and rider phones participate in the state keeping. They send updates every 4 seconds, but they only have to be online to start a trip. Both mobiles cache a trip log that gets uploaded when network is available.
* Since driver/rider send updates every 4 seconds, and since you don't need to be online to continue or end a trip, you don't even need an active spare for the server. A hot spare can rebuild the world state in 4 seconds. State for a rider and driver is just a few bytes each for id, position and status.
* Since you'll have the rider and driver trip logs from their phones, you don't necessarily have to log the ride server side either. Its also OK to lose a little data on the server. You can use UDP.
Don't forget that in the olden times, all the taxis in a city like New York were dispatched by humans. All the police in the city were dispatched by humans. You can replace a building of dispatchers with a good server and mobile hardware working together.
You could envision a system that used one server per county and that’s 3k servers. Combine rural counties to get that down to 1000, and that’s probably less servers than uber runs.
What the internet will tell me is that uber has 4500 distinct services, which is more services than there are counties in the US.
The reality is that, no, that is not possible. If a single core can render and return a web page in 16ms, what do you do when you have a million requests/sec?
The reality is most of those requests (now) get mixed in with a firehose of traffic, and could be served much faster than 16ms if that is all that was going on. But it’s never all that is going on.
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?
Not the author but. Its a user side read through cache, so no need for pre-emptive cache coherence as such. But there will be a performance penalty for fetching data under write contention irrespective of whether you have single az/multiple AZ. The only way to mitigate the performance penalty here is to have accurate predictive fetching which works for usage patterns.
Assuming the "Designed for caching immutable blobs", I guess the approach is to indeed increase the cache size in each AZ or eat the cross-AZ networking costs.
Thank you for your comment and we love your take on this! Coming to what we think about John Carmack's arguments against building a custom XR OS at Meta,
It's kinda hard to have a single answer for this but we like to think that this project did not work out for META particularly. We believe that it was perhaps not the right project for someone like META who already had other on-going projects to deal with. Although a setback, it doesn't necessarily mean there's a fault in the idea itself. We'd like to address the problems that were mentioned with the development of a custom XROS -
1) Cost : We've managed to do everything up until this point at the cost of 0$. However, we're in initial stages and expect to incur costs in the next few months. But those costs are mostly associated with building the company and our own line of products, not in the actual development and engineering of the OS. We've managed to remain extremely cost efficient and intend to continue that practice.
2) Burden on third-party/new developers : We anticipated this problem right when we started building the OS. Over time, we've come up with plans to encounter it and are currently working on making sure that the barrier to enter and create applications and software on Xeneva remains as non-existent as possible. We intend on making the process easy, try to bring no learning curve whatsoever, thus allowing developers to port their existing software and applications to XenevaOS conveniently. Also create a beginner friendly environment so that new programmers are able to create an app on XenevaOS from scratch easily.
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.
reply