mark242

16 thousand Cybertrucks sold in Q3.

To compare, 3.9 million cars sold in Q3.

That is fundamentally wrong. Pushing content moderation onto every person who posts a message on social media is a chilling effect on people posting. Pushing content moderation onto every person who reads a message on social media is a chilling effect on people reading.

Because the alternative is pretty provably worse for you, and for them.

* You have to save your (hopefully unique!) email/password in a password manager which is effectively contradictory to your "I won't use a cloud service" argument.

* The company needs to build out a whole email/password authentication flow, including forgetting your password, resetting your password, hints, rate limiting, etc etc, all things that Google/Apple have entire dedicated engineering teams tackling; alternatively, there are solid drop-in OAuth libraries for every major language out there.

* Most people do not want to manage passwords and so take the absolute lazy route of reusing their passwords across all kinds of services. This winds up with breached accounts because Joe Smith decided to use his LinkedIn email/password on Midjourney.

* People have multiple email addresses and as a result wind up forgetting which email address/password they used for a given site.

Auth is the number one customer service problem on almost any service out there. When you look at the sheer number of tickets, auth failures and handholding always dominate time spent helping customers, and it isn't close. If Midjourney alienates 1 potential customer out of 100, but the other 99 have an easier sign-in experience and don't have to worry about any of the above, that is an absolute win.

Here's what I would like from a Kubernetes-like system.

I have a collection of machines.

I have a very simple file that defines A) what I want to run, B) how the pieces communicate to each other, and C) how I want it to scale.

Make that work without me having to think about any of the underlying infrastructure. (If this sounds suspiciously similar to Heroku, there you go)

One node_modules directory?

I'll bet you didn't know that many times, those are getting repaired.

https://www.dailymail.co.uk/news/article-8838159/amp/The-Who...

Because of the connection that the players have with the instruments.

Could you do that with an iPad?

The thing I love the most about Sentry/Bugsnag/Honeycomb/etc is that it is essentially automated observability. That is, I don't need to do a huge amount of integration to have, basically, a prioritized list of bugs along with severity and overall application health.

I like the idea of the browser extension being able to offer these kinds of tools where you wouldn't need to install a heavy Javascript snippet -- but I do think that taking the manual steps out of debugging wherever you can is the most efficient. With Bugsnag et al, I don't need to wait for a user to contact me. I shouldn't have to wait for someone to submit a Jam report in order to see how healthy my app is.

If you had ever put the time and effort (and blood!) into learning how to play the guitar, you too would have a visceral reaction to seeing a guitar getting destroyed for nothing. It's not the objects themselves that are the problem, it is our connection to those objects, and our innate feelings about those objects, that Apple has smashed in that video. That's a marketing 101 mistake and how this ad ever got greenlit is beyond me.

Do you think it's possible to get the placement of the towel correct if you've gotten your finger chopped off by your Cybertruck?

Yes, I read the article. 90 percent of their signups are within 130 days. That's not a great funnel.

I'd be curious to see the breakdown of SaaS vs self-hosted customers.

Again, imagine what the funnel would look like if the page simply said, "First 100 license keys are free forever. Then pay $0.005 per license key issued."

That's a very, very easy opex cost for a developer (and a finance department!) to understand.

Right now you can get 50 "ALU"s for free per month but the page doesn't say that at all on first glance; you have to move your slider to the left in order to get that offer. Instead there's so much complexity on that page. API requests per day. Number of licenses. "Number of policies" (whatever that means?!?). Number of products.

Devs, please please please simplify.

On the contrary - any trial you offer is incorrect.

"People won't know the value of my service if they can't use it!" means that you either aren't doing a good enough job showing them the value of your service up front, or you have an incorrect pricing model.

Let's take Stripe as an example. It is absolutely free for you to create an account, browse the dashboard, read their API documentation, etc etc etc, but they take their cut of every single financial transaction you do on their platform. There's no trial - either you find value in Stripe's services, or you don't.

Notion has a free tier for single user seats because that's their marketing plan. The moment you want to use Notion for what it's built for, team use, you're paying per user - again, there's no trial period there. Same for companies like Atlassian or IFTTT or Zapier or on and on and on.

"You get our full service for X days for free, then you have to start paying" is incorrect for _all_ values of X. Either, "you have to pay to be a user of myproduct.com" or "you can be a free user of myproduct.com but once you get to a level where you're serious about using the product, you have to pay" is the correct strategy.

It's mind-boggling to me that Google didn't create a spec to work with special partners whereby they could get syndicated data in a format that was easy to ingest, and easy for their partners to produce. Lighting dollars on fire just to serve up pages to Googlebot, when you could just periodically dump a journal of updates to Google, is just crazy imo.

On edit: if only there were some way to do some kind of really simple syndication of your data.

I would be okay if they gave it the Peripheral treatment, which is to say it doesn't need to be 100% like the book. It would be better if Case's ono-sendai rig was something a little more modern than the original vision of essentially an Atari ST. It would be hilarious as hell if Wintermute started hallucinating like a GPT. The vision of Chiba City has been done a million times over; what if, instead of trying to just remake the street scenes of Blade Runner, we got something completely different? I'd be okay with that.

It got cancelled after season 1 -- we never actually got to the end of the book.

This is how we all know you never read the book.

> I don't want content aggregated by 3rd parties and drip-fed to me telling me what I should believe, what is important, and what I should focus on.

> I want my AIs to give me a morning newspaper of content from across the internet (...)

Please make this make sense.

[Insert the "now you have 16 standards" joke here]

This is great -- all the way up to the point where you have to hold and drag. The usability on a laptop goes out the window as you realize you can't accelerate past the edge of your touchpad. Getting to the top item in the menu -- maybe even the most important item -- is extremely hard. You rapidly become limited to the number of items you can have in this menu.

Tap-or-swipe-to-open, and tap-or-swipe-to-close have rapidly engrained themselves as the easiest to understand for users. I'd love to see this demo with that in mind.

Someone reading the headline of this might think "oh, they're using Cockroach, or Fauna, or Planetscale" -- nope, this is about next-gen hardware powering their single-write (with a number of read replicas) MariaDB instance.

imho there are a lot of steps you can take to make your day-to-day feel better, even if it doesn't give a radical "oh I just turned everything around one day" kind of feeling.

By default, don't have any notifications show on your lock screen unless they're from close family or friends (or you're a SRE whose job it is to deal with problems at 2am, but that's another story). Any app that isn't specifically human-to-human-communication-based probably doesn't need to be sending you notifications at all, ever. Keep track of your weekly screen time notifications from your operating system, and be mindful of having that trend upward.

Set specific times in the day when you're going to look at random communications/email, and stick to those times -- if it helps, set a calendar time for that. The more you can get into that timed routine, the easier it is to reduce the total amount of time spent on distracting things and the more you'll be able to budget your time for deep work.

Social media, it can be really tempting to feel fomo with friends/coworkers/family/etc. You'll feel like you're missing out at first, but that feeling does get smaller and smaller over time. You don't need to cut it out 100%; but what you need to do is eg stop that quick 2-minute refresh of the Gram when it's 10:30am and you really should be more productive.

It isn't a magical self improvement routine, there isn't a promise of happiness, but eg reducing doomscrolling and reading shit comment responses and shit bird app threads and seeing shit clock app videos, it will give you a lot more mental energy.

Anything that an IP address can be attached to is already accumulating a charge, just by existing and running. EC2, NAT gateway, ELB, etc. What's "actually unused" then? Minimum amount of traffic? I don't think it's in Amazon's purview to make those judgement calls.

Addresses were already being charged if they weren't attached to an interface. Increase that charge if you're looking to churn unused IP addresses.

A fun project for someone would be to run this through Midjourney to get an un-pixelated, huge animation.

To be fair, it wasn't the lack of search data revenue that wound up bankrupting the company -- that whole data mining industry didn't really exist outside of a couple of players and the USG. What did Netscape in was the browser revenue stream evaporating because of IE getting shipped with Windows, and the huge amount of time and people put into the Enterprise Server project that effectively got destroyed by the birth of Apache, and then double-destroyed by the birth of PHP.

Somewhere, there's an alternate universe where Jim Clark is able to do a licensing deal or acquisition with Microsoft; that halts the development of both IE and IIS, and nodejs is never born because server-side-Javascript already exists in the form of Livewire living on. That alternate reality probably also kills off server-side-Java faster just because of how good Livewire really was.

I think you'd get people wanting to do that for the novelty, maybe once. Your departure "port" would wind up being Marina del Rey. Even if you lived down the street in Santa Monica, the time to get to the "port", board, etc, it's just a diminishing return of time investment. If you're okay with getting to Santa Barbara in 2 hours, you just make the drive. If you want to go faster, you're taking a helicopter. If you want the relaxing scenery for a longer duration without driving, you take the Surfliner.

The holy grail for this thing is SF-to-Marina del Rey, at a decent passenger load, without stopping. If it can pull that off, some enterprising company will buy 50 of these things and run a shuttle that competes with the San Jose to LAX commuter routes.

> Could it make the Catalinas from California coastline?

Yes -- but there is probably no business case where that makes sense. Presumably your launch points are San Pedro/Long Beach, Dana Point, or maybe Redondo. In all three cases, if you want to get to Avalon within 15 minutes, you're paying for the helicopter service. If you're okay with taking an hour, you're paying for the existing boat shuttles, which take a whole lot more than 12 people at a pop and you're able to experience the environment -- it is not uncommon to run into pods of dolphins, whales, etc, on the trip over to Avalon.

In theory, you could open up a shuttle service to Avalon from San Diego, or Santa Barbara. Maybe there's enough demand there, but again the 12 person limit makes it probably a money loser. You'd have to charge so much that people would just make the 90-minute drive to Long Beach and shuttle over from there.

I don't know if this is the correct tactical implementation, relies upon having a cloud-based account that never goes away or gets disrupted in any fashion etc etc etc etc.

However! If you have built any product which has gotten traction, you know just how much of a pain auth still is in 2023. It will always be your number one customer service pain point -- either unable to remember the email address your users signed up with so they can't initiate a reset password flow, or not getting an OOB email to start said flow, and so on. Auth in its current state is a complete drain on company time, resources, and money. Extrapolating out, I really wonder what a raw cost of the world's total GDP is taken up by dealing with auth issues.

Any kind of breakthrough here would be such a net benefit to the human race as a whole. Even the half step of OAuth, even with all of its complexity and "did I use Google or Facebook or Apple to sign into this site?", even that reduced friction enough to be such a material benefit to customer service. If we can make signing into a service as easy as unlocking your phone, there would be a huge productivity jump.

The short answer is "yes" but the questions that you should be asking are: A) How long am I willing to block the queue for additional consumers, B) How committed am I to getting close to exactly-once processing, and C) how tolerant of consumer failure should I be? Depending on the answer to those three questions is what drives your queue architecture. Note that this has nothing to do with time spent processing messages or "long running jobs".

Assume that your producers will be able to spike and generate messages faster than your consumers can process them. This is normal! This is why you have a queue in the first place! If your jobs take 5 seconds or 5 hours, your strategy is influenced by the answers to those three questions. For example -- if you're willing to drop a message if a consumer gets power-cycled, then yeah, you'd immediately ack the request and put it back onto a dead letter queue if your consumer runs into an exception. Alternatively, if you're unwilling to block and you want to be very tolerant of consumer failure, you'd fan out your queues and have your consumers checking multiple queues in parallel. Etc etc etc, you get the drift.

Keep in mind also that this isn't specific to RabbitMQ! You'd want to answer the same questions if you were using SQS, or if you were using Kafka, or if you were using 0mq, or if you were using Redis queues, or if you were using pg queues.

In summary -- their RabbitMQ consumer library and config is broken in that their consumers are fetching additional messages when they shouldn't. I've never seen this in years of dealing with RabbitMQ. This caused a cascading failure in that consumers were unable to grab messages, rightfully, when only one of the messages was manually ack'ed. Fixing this one fetch issue with their consumer would have fixed the entire problem. Switching to pg probably caused them to rewrite their message fetching code, which probably fixed the underlying issue.

It ultimately doesn't matter because of the low volume they're dealing with, but gang, "just slap a queue on it" gets you the same results as "just slap a cache on it" if you don't understand the tool you're working with. If they knew that some jobs would take hours and some jobs would take seconds, why would you not immediately spin up four queues. Two for the short jobs (one acting as a DLQ), and two for the long jobs (again, one acting as a DLQ). Your DLQ queues have a low TTL, and on expiration those messages get placed back onto the tail of the original queues. Any failure by your consumer, and that message gets dropped onto the DLQ and your overall throughput is determined by the number * velocity of your consumers, and not on your queue architecture.

This pg queue will last a very long time for them. Great! They're willing to give up the easy fanout architecture for simplicity, which again at their volume, sure, that's a valid trade. At higher volumes, they should go back to the drawing board.

> The best possible experience starts with not being spied on, especially against my consent. No feature is worth that.

This kind of knee-jerk reaction says that there is no comment in the universe that would make you entertain a different perspective. That's fine, that's not what this comment is going to be.

Instead, I'll say this: the default assumption of ie "collecting crash data equates to invading my personal privacy" is just wildly off-base. I will freely admit that there are plenty of companies who have abused the concept of the always-on-network connection and are doing hardcore data-mining almost at the keylogger level. That's bad, 100%.

But there is a large majority of data-driven companies who are actively trying to make your experience with their software better, with the small team that they have. To say "well f them, they can try to divine how I, Power Linux User, would even use their software" is reductive and puts an engineering team at a distinct disadvantage and slows their overall output. This is not what you, as a user of their software, want, and it is ultimately a self-defeating argument.

"Create great solutions" does not happen in the year of our lord 2023 without data. That data needs to come from somewhere, and "make it easy to report bugs" isn't it.