methodical

Every single post along these lines gets some comment about how it's acceptable/understandable because they've had such a massive influx of usage but I'm sorry at this point it's completely unacceptable for a service which acts as such a vital part of so many organization's workflows to have this level of downtime.

Given I've never worked at an organization at such scale, but there have been several other companies who have experienced large influxes of usage and been able to scale WAY more gracefully than github. It's not even like these outages are some delayed worker assignment due to higher supply than demand, it's just complete outages that make deployment impossible.

Simply unacceptable, hopefully this one doesn't take the NN hours it did last time to resolve.

Bloomberg's moat is the messaging service within it, not it's aggregation of data

Those are not LLMs

I'm unsure what SpaceX's weighting would be in QQQ but with Tesla being <3.54% weighting it would take both companies being 0s within a year to offset the cost in taxes from reweighting...

Candidly, while I understand the need for some amount of redundancy, I'm curious what this level of redundancy adds in terms of complexity to the system of a whole and whether or not that complexity-add almost outweighs the higher redundancy. I'm sure NASA has calculated the trade off, but I'd be curious to see the thoughts behind that.

I feel in a similar vein when learning of certain aircraft accidents over the years, where it feels like the redundancy of certain systems and the complexity it adds has been the indirect cause of accidents instead of preventing them. I suppose there's not really a way to quantify the accidents that it's prevent to be able to compare them directly.

To be fair, delineating between benevolent and malevolent pen-testing and cybersecurity purposes is practically impossible since the only difference is the user's intentions. I am entirely unsurprised (and would expect) that as models improve the amount to which widely available models will be prohibited from cybersecurity purposes will only increase.

Not to say I see this as the right approach, in theory the two forces would balance each other out as both white hats and black hats would have access to the same technology, but I can understand the hesitancy from Anthropic and others.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

While I fundamentally agree with the basis of compute getting cheaper by the year, I think a missed consideration here is the fact that these models are also requiring exponentially more compute with each iteration to train, in a way that arguably has outscaled the advances in compute.

Whether a generalized and broadly usable model will be able to trained within some N multiple of our current compute availability allowing the price to come down with iterative compute advances is yet to be seen. With the current race to the top in terms of SOTA models and increasingly iteratively smaller improvements on previous generations, I have a feeling the scaling need for compute will outpace the improvements in our hardware architecture, and that's if Moore's law even holds as we start to reach the bounds of physics and not engineering.

However as it stands today, essentially none of these providers are profitable so it's really a question of whether that disconnect will come within their current runway or not and they'll be required to increase their price point to stay alive and/or raise more capital. It's pure conjecture either way.

Circularly passing around tens to hundreds of billions of dollars for things which don't exist and may never exist to fund a technology that hasn't A. lived up to the hype they've marketed and B. proven any strategy to breakeven is fundamentally not that much different than the way in which Enron strategically boasted their revenue numbers by passing the money between shell corporations that their CFO created.

The main difference of course being that these are actual companies as opposed to just entities intently designed to inflate the apparent financials. While it seems like that difference means this situation is perfectly fine as compared with the fraudulent case of Enron, the net effect is still the same; these companies are posting crazy quarter over quarter revenue growth, sending their stock prices to crazy highs and P/E multiples, while the insiders are cashing out to the tunes of hundreds of millions of dollars.

I don't really see how exactly you're trying to make the argument that it may or may not be a bubble, it objectively meets the definition of a bubble in the traditional economic sense (when an asset's market price surges significantly above its intrinsic value, driven by speculative behavior rather than fundamental factors). These companies are massively overvalued on the speculative value of AI, despite AI having not yet shown much economic viability for actual profit (not just revenue).

Worse yet, it's not just one company with inflated numbers, it's pretty much the entire top end of the market. To compare it to the dot com bubble wouldn't be a stretch, it'd basically be apples to apples as far as I see it.

Watching along, will be interesting to hear how much they leave for the paper they seem to be releasing alongside this conference

Ditto. If anything, trying to add it into an existing codebase via JSDoc has only really been a detriment via being a massive time sink. It might have caught maybe 4-5 bugs in the code but none that presented a large enough issue to warrant the time investment. If you're starting from scratch with TS instead of JSDoc, it might be worth it, but even on the best of days trying to figure out typing oddities from library typings being wrong and such have only really added headache. As always YMMV

Ditto- I have a feeling the investors in his latest 2.3 quintillion dollar series Z round wouldn't be as happy if he'd have tweeted "there is a wall"

A company being unable to compete with another one on price will result in a drop in revenue, as consumers purchase the product with the cheaper price. Revenue going down is bad for a business. How exactly is any of what I've just stated wrong? How exactly is another company selling a similar product at a much lower price point good for the company? Perplexing position that somehow introducing a much cheaper product into the market from company B is good for company A.

Not when the domestic companies which manufacture the same product wither as a result. Don't get me wrong, I don't believe in defensive national economic policy as a blanket protection we should do to protect all industries, but in special circumstances such as this one where losing all of our electric vehicle production capability and specialization is at play, I think it certainly is in our strategic interest to avoid that from happening.

Help is an interesting word choice for what is essentially undercutting our entire domestic automotive manufacturers and ensuring, on a pure cost front, that the majority of Americans purchase and rely on maintenance for a product produced in China. Doing so would have major negative consequences for our own strategic interests, hence why there has been such a massive tariff on it for several years now. China isn't being altruistic when they're attempting to sell us their much more affordable EVs. It's not a uniquely US perspective on the threat of Chinese EVs either, as the EU also has lesser but still non-trivial tariffs on Chinese EV brands.

It may be a result of personal preference, but I struggle to see how talking through challenges encountered with a personal project are a poor indicator of competence. If you ask some boilerplate list of questions, sure, but few if any candidates could memorize all of the random in-the-weeds architecture questions one could ask while talking through someone's project. For a junior specifically, even a non-answer to these questions provides valuable insight into their humility and self-awareness. I also think that it'd be pretty easy to visually weed out personal projects created for the sake of saying one has personal projects, like a bootcamp may push to create, versus an actual passion project, and even easier to weed out during any actual discussion. I suppose YMMV, but in my experience, the body language and flow of discussion are vastly different when someone is passionate about a subject versus not.

I think the best test for a Junior is to ask them to submit some of their OSS or personal fun projects they've worked on. From my perspective, especially with Juniors who aren't expected to be extremely knowledgeable, displaying a sense of curiosity and a willingness to learn is much more important.

If, hypothetically, there's two candidates, one who is more knowledgeable but has no personal projects versus someone who has less knowledge but has worked on different side projects in various languages/domains, I'm always going to pick the latter candidate since they clearly have a passion, and that passion will drive them to pick up the knowledge more than someone who's just doing it for a paycheck and could care less about expanding their own knowledge.

To go one step forward, you can ask them to go into detail about their side project, interesting problems they faced, how they overcame them, etc. Even introverts who are generally worse at small talk are on a much more balanced playing field when talking about something they're passionate about.

You're dead sure? I wouldn't say anything definite about technology advancements. People seem to underestimate the last 20% of the problem and only focus on the massive 80% improvements up to this point.

Never really understood any company of any size that pushes for this type of workload. Do you really produce high-quality work on hour 100 of the workweek versus hours 0-40? For every startup that succeeds with this type of 996 dystopian work schedule, I'd argue more fail because of high employee churn, low worker motivation, and burnout even in a high-paid tech startup. In my opinion, even for those highly motivated, the human body simply can't do productive work in that type of environment. Some of the best startups I've seen are those with actual work-life balance. Not necessarily saying in and 9 and out at 5 on the dot, but certainly far from 996 or 997.

Ran into the same issue when I purchased a .ml domain (naively not looking into why .ml is such a cheap TLD to buy good names for, it has a super high spam risk). Purchased a different .com domain and haven't had any issues since. I didn't change content or anything, besides changing the domains in all of my links, and the same google ad campaigns and workspace for the new URL were able to be created without issue.

Fair point but I think the key point here is unnecessary complexity versus necessary complexity. Are zero-downtime deployments and load balancing unnecessary? Perhaps for a personal project, but for any company with a consistent userbase I'd argue these are a non-negotiable, or should be anyways. In a situation where this is the expectation, k8s seems like the simplest answer, or near enough to it.

In the same vein here.

Every time I see one of these posts and the ensuing comments I always get a little bit of inverse imposter syndrome. All of these people saying "Unless you're at 10k users+ scale you don't need k8s". If you're running a personal project with a single-digit user count, then sure, but only purely out of a cost-to-performance metric would I say k8s is unreasonable. Any scale larger, however, and I struggle to reconcile this position with the reality that anything with a consistent user base should have zero-downtime deployments, load balancing, etc. Maybe I'm just incredibly OOTL, but when did these simple features to implement and essentially free from a cost standpoint become optional? Perhaps I'm just misunderstanding the argument, and the argument is that you should use a Fly or Vercel-esque platform that provides some of these benefits without needing to configure k8s. Still, the problem with this mindset is that vendor lock-in is a lot harder to correct once a platform is in production and being used consistently without prolonged downtime.

Personally, I would do early builds with Fly and once I saw a consistent userbase I'd switch to k8s for scale, but this is purely due to the cost of a minimal k8s instance (especially on GKE or EKS). This, in essence, allows scaling from ~0 to ~1M+ with the only bottleneck being DB scaling (if you're using a single DB like CloudSQL).

Still, I wish I could reconcile my personal disconnect with the majority of people here who regard k8s as overly complicated and unnecessary. Are there really that many shops out there who consider the advantages of k8s above them or are they just achieving the same result in a different manner?

One could certainly learn enough k8s in a weekend to deploy a simple cluster. Now I'm not recommending this for someone's company's production instance, due to the foot guns if improperly configured, but the argument of k8s being too complicated to learn seems unfounded.

/rant

The irony is palpable. Stating your position and then never providing any supporting proof is not a "valid and sound" argument.

You really need to learn about the burden of proof, since you'd (hopefully) be able to figure out that in this case, the burden of proof is on you to prove what you're saying is accurate. HN isn't a place for hand waving arguments where your only supporting proof is "logic".

While I mostly agree with your point of Apple being rather aggressive with forced upgrading, I don't think the device requirements for these features were based solely on the desire to push out people with older devices, but rather due to the hardware requirements for a lot of the ML/AI features being based on the Apple Silicon, at least for the Mac side of things. As to why they drew the line at the iPhone 15, perhaps it's a similar reason regarding performance requirements. While obviously, I'm not intimately knowledgeable of their basis for the device requirements, I'd wait a few more years to see how the device requirements for these new features cascade. If they continue requiring newer and newer devices, only supporting the trailing generation or so, then I'd agree wholeheartedly with your sentiment.

If a would-be founder doesn't want to start a company because of their salary, then it's probably for the better. An early-stage startup isn't a vehicle to funnel VC money into your account at the rate that multi-trillion dollar companies give it out.

Wholeheartedly agreed.

Moreover, one thing NIH syndrome handwavers miss is that developing a custom situation-specific solution allows you to expand your knowledge in that discipline, create a more tailored solution, and avoid supply chain vulnerabilities that can come with using third-party packages. In my experience a handbuilt solution to a problem is going to be much more efficient in most cases than OSS out there, except in spot instances where the scale of the task is not able to be achieved in a small amount of code (e.g. a versatile graphing library), although these are /very/ few and far between.

At least where I live (Texas, United States) from what I saw it's allowed to have legal counsel, although it may be uncommon. I'll have to look into the process more and see if there's anything I can pursue.

As much as I'd love to stick it to them, I haven't looked into it at all, assuming I'd have to pay more for legal counsel than the tickets were worth.

They most definitely have some BS in the fine print about how they're not responsible for their awful system, as CYA for things like this. Truly scum of the earth.