dkulchenko

Have you tried comparing with 3.7 via the API with a large thinking budget yet (32k-64k perhaps?), to bring it closer to the amount of tokens that o1-pro would use?

I think claude.ai’s web app in thinking mode is likely defaulting to a much much smaller thinking budget than that.

Every time I read the story of Therac-25 I feel incredibly frustrated AECL never faced real consequences or (criminal) liability for it.

Maybe I'm retroactively imposing modern day safety culture, but reading the timeline and history, it feels like AECL was completely negligent in waving off the issue as more and more fatalities kept piling up.

Can't believe the devices weren't pulled offline to definitively solve the issue after the first death. Instead, they basically went "can't repro, oh well".

The T-Mobile experience has gone majorly downhill since the departure of Legere. Now they feel like just any other carrier.

This mirrors my experience. Not once did I have a Yellow LTL shipment arrive on time, and typical delays ranged from 2 days to 2 weeks or longer. Shipments would get lost in a terminal, down to staff insisting it never arrived on the trailer, and then spontaneously reappear after a loss claim was filed.

I would've loved to avoid them but vendors would often choose them due to their cost.

I had the same issue migrating an app off of Render (they also use Cloudflare for app routing).

Cloudflare would refuse to route to my new IP for hours on end. Incredibly frustrating and I almost pulled my DNS off of CF as a result.

I was able to work around it by disabling the orange cloud for the domain for a couple hours, then turning it back on, which must have reset some sort of cache on CF's end.

Ultimately, it's not a DNS issue, it's an internal CF routing issue - it only happens with CDN (orange cloud) on. It seems CF's just caching the orange cloud's original route (via the SaaS provider) way too long internally somewhere and it's not being cleared when the route is changed off of the SaaS.

Maybe a bit unorthodox, but I've been using SquashFS with xz for compression for long-term archival (I generally prefer zstd, but for long-term archival I don't mind waiting longer for better compression with xz).

SquashFS files have file-based deduplication, fast random access, and mountability, all of which are lacking from .tar.* archives without resorting to other indexing tools. And they're mountable on any Linux without installing anything.

Only downside is they're readonly (or more accurately append-only), but for my uses, that's totally fine.

MagSafe cable does indeed ship standard - see https://www.apple.com/macbook-pro-14-and-16/specs/.

Personally, I stick to Firefox because of multi-account containers, which Chrome doesn’t have (no, profiles don’t count). It’s a really sticky feature.

Agreed. Why is there no Tinder/online dating equivalent for making new friends locally?

Instead of dating-specific qualifiers, it'd ask for your interests, hobbies, values, age and other demos, then match you based on overlap.

Not Meetup - it's not quite solving the same problem, and so it solves things differently (focusing on shared interests and on discrete meetup events).

I recently modeled churn for my subscription box calmbox (https://thecalmbox.com) by using an actuarial table (http://www.lifeexpectancy.org/lifetable.shtml, formulas at the bottom) which I found to be a lot more informative than the standard churn formula.

Subscriptions still active at month x are represented as `l(x)` and subscriptions that "die" (cancel/expire) in a given month are represented as `d(x)`.

This gives you a "life expectancy" and a "mortality rate" (so, churn) for any given number of months that a customer has been subscribed. So I can project how long someone will stay subscribed when they're brand new (at month 0) and how long they likely still have when they're at month 8 (longer than at month 0, funnily enough).

With those subscriptions where the month-specific churn will largely decrease the longer someone's subscribed (after passing the initial high-churn first months), this allows measuring/projecting churn on a much more granular level.

Notably used (and developed) by the SQLite authors. They explain their rationale here: https://sqlite.org/whynotgit.html

Wow, this is substantial.

All my mail sync is down, Analytics isn't loading, Sheets and Docs are all stuck in "Reconnecting". I wonder what could cause this.

Yeah, shockingly enough despite the economic situation. Business-wise, it's been the best quarter yet, outpacing even holiday gifting peaks.

That's not unique to JS.

  $ irb
  irb(main):001:0> 0.1 + 0.2
  => 0.30000000000000004
  irb(main):002:0>


  $ iex
  Erlang/OTP 22 [erts-10.6.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe]

  Interactive Elixir (1.10.2) - press Ctrl+C to exit (type h() ENTER for help)
  iex(1)> 0.1 + 0.2
  0.30000000000000004
  iex(2)>

  $ python
  Python 2.7.17 (default, Dec  2 2019, 13:23:33)
  [GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.12)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 0.1 + 0.2
  0.30000000000000004
  >>>

I used Cratejoy to handle the e-commerce backend, so the extent of it was some minor HTML/CSS work. There's existing solutions for Shopify that do the same as well, so no programming needed.

Later on (still running 5 years later), when I got back into coding again, I got rid of Cratejoy and wrote the backend from scratch in Ruby.

For me, I took 2 years off of programming entirely and did something completely unrelated (started a monthly subscription box, so mostly marketing/sales/procurement).

I was completely burned out and couldn't stand to code even side projects when I started the hiatus. When I was ready and got back into it again, the passion was 100% back. Still going strong 3 years since.

I love the way Elixir/Erlang handles this, personally.

If the error is expected/should be handled, just add the error to your pattern match and handle it right there (or bubble it up, if appropriate).

Truly exceptional situations where something "should never happen" won't be pattern matched against, BEAM will crash the process, and your supervisor will get you back to a good state.

Feels so much cleaner than either exceptions everywhere or easy-to-ignore error values.

All the backend code for my current startup is in Elixir (switched from Ruby, my previous love).

Elixir/Phoenix/Ecto are an absolute joy.

It took a bit to get used to immutability and FP but it feels so "cozy", for lack of a better word, to know exactly what my code is doing and to not be bit by obscured mutability and magic anymore.

How does this compare to TimescaleDB?

Are they solving the same problem in different ways or are they complementary projects? If it's the latter, what would that look like?

I didn't mean it didn't make sense grammatically, just that it's not really something people use in the way they do here in the U.S.

Anecdotal, but growing up surrounded by Russians and consuming Russian media daily, "я тебя люблю" as a phrase is something I've heard uttered by others maybe a dozen times, ever, compared to American culture where it's omnipresent and not uncommon to use many times a day.

Movies and books do talk about love, of course, Russian poetry especially expresses love in a truly amazing way. But the article is referring to the frequent conversational use and Western importance of "I love you", and in that sense, there's a major cultural difference. Didn't know about the historical context behind it - that's an interesting point.

Russian is the same way.

You can translate "I love you" linguistically, but it doesn't really make sense to say - people express it through actions rather than words. It's definitely an interesting (and rather significant) difference in Western culture that grants the 3 words such importance.

Switching from Ruby, I used the Fiber pattern (await-defer) heavily in Node via node-fibers & synchronize.js which alleviated a lot of the pain.

To me, "written in Go" is essentially shorthand for zero-dep, statically linked, single binary deployment.

This is a pretty big selling point for command-line utilities like rtop, as opposed to utilities written in Java/Python/Ruby/Node/etc. which require their respective runtime to be installed.

I do disagree about Yosemite's installation time, coincidentally I just updated my wife's 2011 MBA last night and it took around 40 mins.

He's referring to the infamous bug for Homebrew users or just anyone with a lot of files in /usr/local on which the OS X install chokes hard, copying each file individually, taking many hours to complete the install.

Here's what I got in response to my invite request:

  Delivery to the following recipient failed permanently:

     inbox@inbox.gmrservice.ext.google.com

  Technical details of permanent failure:  
  Google tried to deliver your message, but it was rejected by the relay gmr-smtp-in.l.google.com by gmr-smtp-in.l.google.com. [2607:f8b0:400e:c04::e].

  We recommend contacting the other email provider at postmaster@gmr-smtp-in.l.google.com for further information about the cause of this error.

  The error that the other server returned was:
  550-5.2.1 The user you are trying to contact is receiving mail at a rate that 
  550-5.2.1 prevents additional messages from being delivered. For more 
  550-5.2.1 information, please visit 
  550 5.2.1 http://support.google.com/mail/bin/answer.py?answer=6592 j1si1502294pdb.1 - gsmtp

Here's some more background: http://www.reddit.com/r/SubredditDrama/comments/1buh8c/the_c...

And more still: http://terry.davis.usesthis.com/

The Automobile Association - Britain's equivalent to AAA in the US.

But what's really interesting to me is that Apple has clearly put a lot more thought into how interactions on a device like this should work than anybody else.

I strongly disagree.

I think that Apple actually took the easy way out here - they seemed to have approached the problem as "how can we make iOS usable on a smaller screen" and came up with interfaces like the crown and the (albeit pretty) circle-based homescreen UI to access apps to tackle those issues. Which is interesting, because they started off their presentation explicitly saying they didn't want to just scale down iOS.

Google, on the other hand, approached the problem of "how can we make wearables useful as a platform" rather than "how can we scale down Android" and created the intuitive cards interface (which, as a Moto 360 user, is remarkably convenient) and Google Now-based contextual awareness of info you need when you need it. Android Wear doesn't even have an app selector easily accessible, because they don't want you to use the watch that way - it's hard to hunt for apps on a tiny screen, so instead they push contextual information at you as you need it in an easy-to-use way.

I have high hopes for both platforms in the years to come, but I don't find Apple's watch design to be smarter or better thought-out as it is right now (and I'm typing this on a Macbook Air, so I have an appreciation for Apple).

I have tiny wrists and own a Moto 360. It's not huge at all. Try one on at a BB once they're in stores and see for yourself.

Actual Moto 360 owner here to dispel the two most common complains because I'm tired of hearing them parroted online. You'll find that you only hear them from people who've never actually used/seen the watch in person.

1. Battery life. The initial reviews complaining about battery life are simply inaccurate. I have ambient mode on (always-on screen) which is supposed to kill battery, and am easily getting a day out of this watch (ending 16 hour days with 20-30% remaining). I'm using the watch all the time to read emails, respond to messages, etc. If you don't believe me, check /r/moto360, you'll find a bunch of people who actually have the watch corroborating that the battery life is perfectly fine.

2. Size. I have tiny wrists and it looks great on my arm. Not too thick or too big at all, and very much on par with typical men's watches. The fact that it's very light helps too.

It's a fantastic device and I'm really enjoying it.