Hacker Newsnew | past | comments | ask | show | jobs | submit | newswangerd's commentslogin

Reminds me of the good ol' fail whale :)

One thing I'd like to learn is how to effectively meditate as someone with aphantasia. I took a course in college and all of the exercises involved some variation of tuning out your internal monologue going to your happy place in your minds eye. I'd love to get the benefits of meditation, but I can't visualize anything so none of the meditation tools that are taught in these kinds of courses work for me at all.

There are plenty of competent meditation approaches that don't really require visualization of any kind. Most Western "mindfulness" meditations don't require visualizations, nor does e.g. shi-ne / opening awareness, nor most forms of concentration meditations (e.g. transcendental where you focus on a sound like "ohm", meditations that have you focus on your breath, etc).

Read the book Mind Illuminated. Visualisation isn't really necessary for meditation

There's plenty of meditations that don't need it. You don't need to tune out your internal monologue, it's generally more about awareness, so you can be using your internal monologue or just be aware of your thoughts. It's about noticing distraction, which means you are aware.

This book is a great, easy to read, science-based explainer.

https://annas-archive.gd/md5/0e405c329f33fcb63b4647e386f0ad7...


One thing I’m starting to see more and more is that software is no longer as big of a moat as it once was. Netflix gets to cruise along with a tech like evaluation because it pioneered online video streaming software. They caught the incumbents off guard and now the incumbents are starting to chip away at their tech moat.

I think we’re going to start seeing this happen more broadly across the industry. AI will get to a point where it becomes easy to clone any app or service. At that point software is no longer your moat. Your moat is going to be content, community and branding. This kind of makes me wonder if open source get even more popular. If software is no longer a moat, then you may as well release it for free and cash in on the goodwill and community.


Not gonna happen software being cheaper simply moves the goalpost farther than before. Customers will expect and demand even greater capability and quality.

A team of highly skilled engineers at netflix are gonna beat you massively at their own game.

Acting like all code is flat and you just have to catchup to their level is false thinking. Netflix will be running 100x more AI than you with much better talent than you.


I don't think software in general is flat, but video streaming is a mature technology and it's pretty easy to get good enough video streaming that customers don't care about it as a differentiating factor.

If 8k TVs or VR suddenly take off, they might be able to take advantage of it, but right now it's only a minor advantage (in cost savings primarily). Customers choose based on content, not based on who's better at video streaming.


Mature is like saying CPUs are mature. Technically true but the entite world is actively trying and failing to be taiwan.

Video streaming is amoung the hardest technologies you can possibly make beyond a single cluster scale.

Youtube is my favorite engineering system to read about. And man... chatgpt has a LOOOONG way to be able to make that from scratch.

There is an argument though of "good enough" I don't think it logically holds since our entire ecobomy is built on that literally not being true but who knows.


I'm not saying it's not hard; I'm saying it's not a competitive moat.

There are hundreds if not thousands of companies that successfully run streaming services and I doubt that any of them are more worried about the technology than they are about the content.


True, but it's also pretty hard to tell the fuzzy edges of that. We are not privledged to info like "videos loading x% faster resulted in y% retention increase"

Obviously a big company can push a big project I thought you were in the camp of a vibe coder going up against netflix and winning.

Even before AI competition always caught up that really hasn't changed and basically is my point. AI doesn't change your competitive advantage against another company doing the same thing it's all down to operation excellence.


Netflix's moat is their CDN, which is fabulously expensive and complex hardware scattered across the entire planet.

AI isn't gonna help you magic a CDN into existence


How is that a moat?

All that matters is that the CDN is good enough to serve viewer traffic. If your CDN isn't up to snuff, the outcome is that the viewer can't play the video they want. AFAIK, no Netflix competitor is suffering from insufficient CDN resources.

Sure, some choices make the cost of CDN higher or lower, but it's not material enough of an impact on competitors to matter.

The actual moat for streamers has been, and always will be, the breadth and popularity of their exclusive content. Netflix will die if they don't continue to produce exclusive content that audiences will subscribe for.


Everything about a cdn is cost per MB, and Netflix has that priced at I don't know, I imagine almost zero, and maybe negative because they host with ISPs, which other cdns can't do. Which means their competitors must spend infinitely more money until they hit a scale where they can start to follow in Netflix's parh. Also, I imagine that buying hardware now, especially DRAM is four or more times as expensive as it was when Netflix paid for a lot of their hardware, so yeah, that.


Do you seriously believe Apple and Disney are going to lose to Netflix over CDN costs? If so, let's place counterwagers.


That is not what I said. I am challenging your dismissal of the cost of bandwidth is material to the success of a cdn

> All that matters is that the CDN is good enough to serve viewer traffic. If your CDN isn't up to snuff, the outcome is that the viewer can't play the video they want. AFAIK, no Netflix competitor is suffering from insufficient CDN resources

My personal experience is that e.g. if your cdn can serve ads, but not video, then you lose subscribers.

Extrapolating from that, if you lose money on every video a subscriber plays because of DTO costs, then you can't stay in business. Netflix and Amazon can afford their cdn. Maybe Disney can stay in business because they have the scale to get to the right COGS to meet their forecast, but for sure in the past they are accused of misleading investors as to their costs and revenue and their future revenue forecasts[1]. Since that's still underway, we may even know what part of their break-even calculations CDN costs are in the future.

1. https://www.ktmc.com/new-cases/the-walt-disney-company/?hl=e...


> we may even know what part of their break-even calculations CDN costs are in the future.

That's unlikely to come out publicly as a result of this suit. Courts routinely grant motions to seal records that contain trade secrets.


You are probably right that it's not the most likely outcome, but it is more likely with net revenue and projections of future revenue being the actual crux of the case isn't it?


> My personal experience is that e.g. if your cdn can serve ads, but not video, then you lose subscribers.

Of course. But none of the major providers is suffering from that problem on a regular basis.

> if you lose money on every video a subscriber plays because of DTO costs, then you can't stay in business

These are public companies, and they have to report material risks (as CDN costs would be, if your claim is accurate) on their SEC filings by law. They're not reporting these as a material risk. They could be lying, I guess, but that seems rather unlikely as they'd be at risk of shareholder lawsuits and government prosecution.

Speaking of which, the Disney suit you referenced doesn't mention CDN costs at all. It mentions the "staggering" cost of content creation, which makes sense to me; content production easily dwarfs CDN costs. (https://storage.courtlistener.com/recap/gov.uscourts.cacd.88...)

(Also, as a side note, no large customer like these is paying retail DTO costs. Large or strategic customers get significant discounts on public pricing.)


All your points are valid, but they all assume a fait accompli of all cdns have already built out to Netflix scale with similar contracts for bandwidth at the edge. If they have done so, then that is not a moat or even a difference at all. However these things take time, and amortize over years, and I don't think the big.playets are all there yet, and so it's a moving target.

Also you are saying that the lawsuit speaks to context cost, which is the headline, but that is unlikely to be the full story at the end of the day since it is a fishing expedition at the moment.


> that is unlikely to be the full story at the end of the day since it is a fishing expedition at the moment.

This suit, assuming it's like most shareholder derivative "failure to disclose material information which led to a stock price drop" suits, was filed to wet lawyers' beaks and get the company to settle by compensating shareholders. It's not really intended to get at the whole story, and neither party has any interest in disclosing CDN costs to the public.


I have an old iPhone SE and I want to give you kudos that the animations run buttery smooth on this page. There are a lot of websites where just the ads will cause my phone to completely freeze.


This is one of the killer Firefox features. I'm so happy to see it's getting added by default!


I went through this process when I was designing the sync server for Digital Carrot.

In the end, I decided to just go with the simplest solution possible. In my case it's just a barebones Go gRPC service that uses an in memory channel to send notifications between connected clients.

The reality is that this simple Go server will scale up to about 1000 simultaneously connected customers on about 2gb of RAM. I don't expect to have more than that many paying customers, and if I do I can always just throw a bigger VM at the problem.

Engineers love to over complicate things in the name of infinite scalability, when in reality you can save a lot of time and effort by just understanding the scope of the actual problem you're trying to solve. Fingers crossed that this will become an issue for me some day, but until then most of us just don't need to worry about it!


I had a similar setup, scaled pretty well with some GOGC tuning. I had a small, simple "router" using channels https://github.com/urjitbhatia/gopipe and except for the per connection 16ish kb network overhead per socket, you can get away with a lot of performance with a small hand rolled service.


1000 connections is a fairly low number by modern standards, c10k “challenges” are like twenty years old by now.

The real questions are:

- how many messages per second are you processing on that 2gb machine (and using how many cpus)?

- does your message processing involve transaction handling, including saving data ti disk durably?

No offense but it really seems you’re comparing apples and oranges, with your use case being much much simpler than the one described.


These are all very conservative back of the napkin calculations. Also, this isn't 1000 connections. It's 1000 customers, each of which can consume dozens of connections.

My point here is that it is important to match the tech stack to the challenge you're facing. When I started thinking about how to solve this problem my first reaction was to design an overly complicated distributed message queue using PG Notify, Redis, Kafka or something along those lines. The key takeaway here is that I realized that I probably wouldn't end up with more than 1000 customers, so I just needed to design a system that could comfortably handle that level of traffic without much effort. If, by some miracle, my business goes crazy viral, I know that my cloud provider can probably handle up to 200,000 customers by just updating a slider in my dashboard, which is way more business than I want anyway.

Engineers love to fantasize about Google levels of scale, but that's just not realistic for a lot of services.


Engineers also love to reinvent the wheel.

What you wrote is essentially technical debt.


I had to double check that today isn’t April 1st


I know right? And the obnoxious music in the video like something so wonderful and worthy of celebration what the actual fuck


Buf is well established and maintains a lot of protobuf packages for many languages, including the YAML implementation for go.


Going strong since 2019! It's a wonderful company entirely dedicated to making google's miserable protobuf "somewhat" useable.


This is incredible news! I’ve used protobuf in Python, Go, Kotlin and Dart and the Python implementation is totally unusable. I don’t know what black magic Google uses for the Python implementation, but the classes it generates are totally opaque and impossible to inspect. I’ve been waiting for a proper python implementation for years now!


> I don’t know what black magic Google uses for the Python implementation, but the classes it generates are totally opaque and impossible to inspect.

TFA seems to say that they’re just thin proxies over the underlying C++ APIs, which would more than do it, and does not surprise me (the re2 Python bindings are similar, not as bad since they don’t generate Python code but they’re really c++-y — in Google’s flavour too — and uncomfortable).


I did not know this before... Google protobuf is not one thing, it is three! Same import, but:

* old C++ extension

* upb

* pure Python

upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?

This one helped me to dig deeper - https://vectree.io/c/how-python-protobuf-runtimes-work-pure-...


> upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?

That is pretty unlikely. TFA's version is in Rust and just barely edges out upb.


rust code tends to be incredibly slow unless you spend a ton of time optimizing (compared to other compiled languages, and contrary to popular belief).


When I was a novice in protobuf I felt tempted to inspect the generated code, but soon I learned that the documentation is good enough that I don’t need to read the generated code.


Using AI to inform architecture doesn’t seem so different from googling architecture in this case. Architectural patterns are mostly well understood and well documented these days and are something that you could piece together via Google search pre AI. The thing that AI brings to the table that wasn’t google able in the past is code generation. Previously you had to understand the architecture patterns to implement them yourself, but now the AI can just do it for you.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: