ylere

Indeed, and that's through the API. If you use Claude Chat/Code and even if you then turn off web search, it still has access to some of its tools (for doing calculations, running small code snippets etc.) and that environment contains chardets code 4 times:

  /home/claude/.cache/uv/archive-v0/nZCy52fMCgTsNaLySn0xf/chardet
  /home/claude/.cache/uv/wheels-v6/pypi/chardet
  /usr/lib/python3/dist-packages/pip/_vendor/chardet
  /usr/local/lib/python3.12/dist-packages/chardet 

It's not surprising that they were able to create a new, working version of chardet this quickly. It seems the author just told Claude Code to "do a clean room implementation" and to make sure the code looks different from the original chardet (named several times in the prompt) without considering the training set and the tendency for LLMs to "cheat".

It also shows why this approach is questionable. Opus 4.6 without tool use or web access can provide chardets source code in full from memory/training data (ironically, including the licensing header): https://gist.github.com/yannleretaille/1ce99e1872e5f3b7b133e...

Correction (can't edit the post anymore): As another commenter pointed out, the rocket can carry 3.4M kg of fuel, not 34M kg.

Methane has 28% more energy per kg than kerosene and also produces slightly less CO2 (2.75kg CO2/kg burned vs 3.00 for kerosene) when burned [1]. SpaceX uses a 78:22 LOX to CH4 ratio, so for 34M kg of fuel burned, 20.57M kg of CO2 are produced (34×0.22×2.75).

[1] https://www.engineeringtoolbox.com/co2-emission-fuels-d_1085... [2] https://x.com/elonmusk/status/1298426245991063554?lang=en

> Anyways here's the example MAD folding picture from the exhibit when its folded -- https://www.google.com/url?sa=i&url=https%3A%2F%2Fbtwberkshi......

Working link to the page that contains the picture: https://btwberkshires.com/arts/visual-arts/mad-magazine-draw...

I think as long as "feature flag entitlements" are seen as distinctly different from what engineers usually use feature flags for (small incremental changes of individual components, testing, roll-outs, A/B testing) they can work well. An entitlement should have a clear link to a customer-facing feature, which are conceptually much larger blocks of functionality. One difficulty with this approach is that you still have to take into account a lot of billing-related aspects, e.g., handling customers in arrears, overage charges if they go over a certain limit, having different pricing models for the same feature, or resetting/carrying over usage counters on plan changes/upgrades - this can add a lot of complexity over time!

That's why we decided to offer separate feature entitlements that are tightly coupled to the billing chain and metering as part of Wingback (disclaimer: I'm the CTO). In the end, depending on your plan complexity and how much you have already invested in feature flags, I think both approaches can work well. Having some kind of feature gating in place for your customers will also make your life a lot easier for provisioning customer accounts and being able to offer custom packages.

My experience has been that there are typically two types of engineers: those who have worked on billing systems before and those who haven't.

I think a lot of the issues arise from the difference between payments and billing [0]. When just starting out and signing up your first customers, you primarily care about collecting a few (recurring) payments - and it's really easy to set that up with Stripe (or even just manually invoicing your first customers).

However, over time, more billing requirements gradually sneak in, such as more complex entitlements, multiple plans, grandfathering, and eventually enterprise/high touch sales customers (where the money is!) who need custom billing cycles, terms, and entitlement provisioning. Since billing is never a technical focus, numerous additions and small hacks accumulate over time, taking engineering resources away from the actual product. Eventually, this turns into an unmanageable mess that can significantly slow down the sales process or limit what you can sell.

The complexity of billing is riddled with hidden pitfalls and edge cases, and it has become even more complex now that most plans include many different limits and usage-based components and that most SaaS companies sell globally. Many later-stage companies have teams of 15+ engineers working solely on billing. I fully agree with the author that, unless it's at the core of your product, no organization should build a billing system themselves (Disclaimer: I'm the CTO of Wingback, a SaaS Billing Platform).

[0] https://www.wingback.com/blog/saas-payment-vs-saas-billing

Been using them on the paid plan for a 1yr+ and apart from working great and reliably I've been really appreciating how no-nonse and to the point their communication has been. Never realized it's also OSS, thank you for pointing that out!

Really easy to set up too, just make sure to also set up DKIM/SPF/DMARC to make sure the forwarded emails don't go to spam.

It seems to be a fork of VirtualBox under the same dual license as the original project.

I found a recording of it here (from IAA 2023): https://youtu.be/NORPeCcIXRQ

> If you know a site has a 4-words policy, the xkcd pw has very low entropy, but if you use this strategy on a "any pw goes" site, a bruteforcer would have to test all lengths upto 25 chars before finding yours (sort of).

How so? Iirc, the entropy calculations assume that the attacked is aware passphrases are used. The eff-long word list often used for xkcd-style passphrases has 7776 words. So on average it would take 7776^4/2 attempts to guess one (randomly generated) 4-word passphrase, comparable to a truly random 8-9 character password with special chars. As the comic points out, people tend to be pretty bad at remembering random sequences of characters and therefore often often use combinations of common words and apply non-random substitutions and patterns, resulting in much lower entropy for those passwords.

Of course, everyone should use a password manager in the first place, but for cases where people don't or they need to reliably remember it (master passwords and critical ones), xkcd-style passphrases are a good and secure option.

Have the guides been updates yet? I created my first one but it wasn't obvious whether things like pkgrel should be increased as part of the MR (I assumed not) and in what format to submit them/which information to include in general.

+1 Can confirm that thanks to gromit I got my account in under 10 minutes a few days ago!

Are you using Cloudfare DNS (1.1.1.1)?

https://news.ycombinator.com/item?id=36970702

It's probably challenging to get good data on actual search engine market share in China. A bit surprising that this is not properly taken into account for the global stats.

There were 4.9b internet users in 2021 [0]. Assuming a search market share of 90%, that's $5.9 per user and year - which seems a lot of considering it includes the developing world, but then of course Google's total ad revenue in 2021 was $209b ($47.3/user/yr) [1] globally and $61.2b in the US alone ($198.6/user/yr!!!) [0,2].

No other player has the ad revenue and market power to even attempt competing with Google:

* Microsoft's search ads + LinkedIn revenue was only $18.7b [3] in 2021 (9% of Googles) and they are the only big global (i.e. not Chinese) player with ad revenues over $10b and a competing search engine.

* Meta is the company one that comes closer in terms of ad revenue at $112b in 2021 (53% of Google) [4], but it's hard to imagine how they would fit search into their ecosystem.

* Apple has the cash already controls the valuable (=mostly iOS users) Safari market, but even for them, they would have to forego $18b/year (as per the article) in pure profits from their deal with Google and manage to actually create a competing product and advertise it heavily, which would costs them 10s of billions a year more. It makes sense that they'd rather keep taking the cash.

This also makes you realize just how valuable dominating the browser market with Google Chrome and having significant influence on the mobile market with Android must be for Google (and also why Apple doesn't allow third party browser engines on their platform).

[0] https://www.itu.int/itu-d/reports/statistics/facts-figures-2... [1] https://www.statista.com/statistics/266249/advertising-reven... [2] https://www.statista.com/statistics/469821/google-annual-ad-... [3] https://www.microsoft.com/investor/reports/ar21/index.html [4] https://www.statista.com/statistics/271258/facebooks-adverti...

While I agree that Stripe is great for payments, Stripe Subscriptions and Stripe Billing were never really built specifically for SaaS. The problem seems easy at first when you have just one plan at $100/month, you'll quickly have many more plans, all kind of discounts and special deals, custom "enterprise" plans for your larger customers and design partners, while having to grandfather your existing customer base and also allow easy upgrades/downgrades etc. A lot of SaaS pricing these days is built around tiers with certain usage limits on individual features, so you'll need to built that as well. And if you are working on an application with a fixed underlying cost for certain features (like genai tokens), you'll also have to implement metering. None of this is really part of your core product and yet most SaaS startups spent a lot of time building and maintaining (billing is hard!) the same functionality over and over again.

There are a few new modern players (disclaimer - I'm the CTO of one of them [0]) in the SaaS subscription mamagement and adjacent usage billing space now and I would highly recommend using such a solution while still relying on Stripe for just the payment processing part. It will save you a lot of technical headaches down the road and even should allow you to get started quicker (for example, we provide you with embedded pricing pages, quoting and sign up links, feature entitlements per customer, full metering support and much more out of the box) and iterate over your pricing faster as you grow.

[0] https://wingback.com

According to an update posted to the newspapers website [0], the owners mother just died. The police had raided both the newspapers office and their home. In the interview they had mentioned she'd been very stressed out by the raid.

[0] http://marionrecord.com/direct/updated_illegal_raids_contrib...?

Porkbun has been excellent for a long time and over the years I moved all my domains to them. They also provide a lot of built-in functionality at no additional cost.

The only issue I have is that they moved their DNS offering to Cloudfare instead of running it themselves, which is understandable to some degree as running DNS for a large numbers of domains for "free" must've been a lot of work for them and I'm sure Cloudfare made them a great offer, but I fundamentally disagree with. It also caused a few domains from certain TLDs to stop working after the transition and I later had yet another issue with url https forwarding due to DNS verified SSL certs not being issued. I expect from my domain provider that included services are solid and that they never break any aspect of my domains that they're are responsible for.

Nonetheless, apart from this one incident their offerings and support have been outstanding and I would still recommend them.

£10 GBP a month for a AS with an IPv4+IPv6 subnet + worldwide POPs that allow you to advertise your subnets over BGP? How did you pull that off? I've researched this a while ago and just the IPv4 subnet alone was at least 10x that amount if you are OK with leasing it from less reputable sources.

Works for me, maybe an be an issue with your DNS or routing? They're using Cloudfares Reverse Proxy.

   dig +short dwdraju.medium.com
   162.159.152.4
   162.159.153.4

Hmm, that could be. It happens with different prompts when the number of input tokens is over a certain length.

Fascinating how hard these kind of issues are to debug.

Fixing the missing links in the billing chain is what we have been working on at Wingback (https://wingback.com). Agree that the actual metering part is not that hard to get (and having a standard here would be great!), but using it to correctly enforce entitlements in your product and accurately bill your customers who might be on all kind of different plans, models prices and discounts over a large number of metered (and umetered) features is.

HDR is less about the colors and more about achieving a wider range of brightness levels (hence increasing the total dynamic range). It's typically encoded using 10 or 12-bit color depth, and metadata is added to the media on how to map the colors' luminance/brightness values (e.g., what darkest and brightest values of a image/video should be). This is then used to transform HDR content into appropriate color and luminance values for your specific monitor (e.g., the reference monitor used for grading might have a peak brightness of 1000 nits, but yours might be different, or have a different luminance-response curve or support a different color space).

Same, I'd love to buy them a beer (or coffee)!