dkulchenko

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

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".

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

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.

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.

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).

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.

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

  $ 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
  >>>

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.

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.

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.

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.

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

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.

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.

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.

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.

  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

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

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).

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.