mihaelm

Same, I associate Hoka & Salomon with running, never would have thought someone would wear them as everyday sneakers.

Good points, the second is very "dual-licensing" in nature. BUSL is certainly the more "mature" option and there's a higher likelihood people came across it in the wild.

You might also be interested in the O'Saasy license (https://osaasy.dev/) which is in the similar vein, but simpler.

HashiCorp switched to BUSL license for their products/tools when they already had substantial market share, and they still faced MPL-licensed forks (Terraform -> OpenTofu, Vault -> OpenBao). It will be interesting to see in a few years if those tools notably cut into their share.

I'm not sure a new tool with a BUSL license will get adoption as easily.

I think it definitely hurts adoption. No hobbyist or experimenter wants to delve into legalities head first by first having to understand the licensing terms of software, whereas permissive licenses like MIT and Apache 2.0 are easily-understood and familiar.

The solution is probably to be more selective what you're open sourcing if you're planning to build a business. And what you open source, you do it under a permissive license so people don't feel limited should they wish to play around with it.

A more restrictive license might be more apt if you don't really want to open source, but you must for regulatory reasons.

The verbosity takes a bit to get used too, but it sure beats the anything-goes feeling - messy as you put it - of pandas.

Maybe because it's like a swiss army knife for data work, regardless of whether you need it for OLTP or OLAP workloads. Having different SQL dialects is a bit annoying, but the base is the same more or less, so switching doesn't come at too big of a cost.

Lets see what they do with Opus first. I didn't find Fable 5.0 prose that bad to read, but improvement is always welcome. It's Opus 5.0 that's atrocious.

I like the software side on my Series X, so if they can bring that over to PC as an OS, that'd be great. I agree the Xbox on PC experience hasn't been stellar so far and I hope they ditch that app with the next generation, for the sake of current userbase. It was serviceable at best in my Windows 10 days.

For anything not gaming related, I have Linux or MacOS.

I'm pulling for Microsoft to create an XboxOS for PC you can just freely install on any machine, as that's about the only thing I care about regarding Windows. Then I could see myself dualbooting that when I want to play my Xbox collection. And it'd be nice to build a beefy machine to max them out on, once the PC component prices settle a bit.

They're playing with that with the Xbox Full Screen Experience on ROG Xbox Ally, but it's still running Windows 11 underneath. I just want the Xbox.

You can also just turn off attribution in Claude Code settings if it bothers you: https://code.claude.com/docs/en/settings-reference#attributi...

"To hide all attribution, set commit and pr to empty strings and sessionUrl to false."

Yeah, the cost of running the test suite every time an agent generates code JIT would be the killer for running it at scale. I didn't even get into practicality of that approach too much because the gist of it for me was the question of agents writing code JIT having security benefits (?) - the verification thing is a sidetrack.

Certainly, adding agentic JIT code invites more complexity to properly do it, so what are the benefits that call for introducing it.

Again, I answered that in the earlier reply:

> Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.

I wouldn't consider feeding the JIT-ed code to a JIT-ed verifier code proper verification.

Even ignoring the verification bit, I don't see the security benefits of having agents write JIT code, hence the original question. Because there might be some edge cases I don't know about, but I can't see this applying generally.

Where did I say you can't do that? I answered you why I assumed the original comment was leaning towards JIT for everything.

Proper verification would be deterministic rules the JIT-ed code would be checked against, so it would have to be non-JIT. Since the comment is talking about using more & more JIT for security reasons, I assumed it extended to verification too.

I don't get why you'd generally switch to JIT for security reasons.

What's there to gain security-wise? Nondeterministic generation & then execution of that code without proper verification seems to be the opposite of a good security posture.

We did that with Comic Sans MS

The landing strip was not load-bearing enough for the translation to land clean. Another attempt is warranted — if you please.

We've known Anthropic has filed for an IPO since early June.

Yes, you should've clarified all the things you don't want :D

I actually tried to switch Claude's `output-style` to ASD-STE100 Simplified Technical English for the prose it writes (code comments, commit messages), but it didn't seem to help. Figured I'll just use GPT 5.6 Sol for implementation instead of trying to "socialize" Opus 5. Anthropic will have to address it sooner or later if they want people to keep using it.

Cause that, along with some other Claudisms, just gives off a vibe of a highschooler trying to hit the word count on an essay.

To combat it, I decided to only use Opus 5 if I'm actually talking to Fable 5 that's orchestrating it. :D Opus 5 experience is really abysmal, hopefully they can get it back on track.

The actual blog post on open-sourcing: https://www.modular.com/blog/mojo-open-source

I remember being really interested a few years ago when it was billed as a superset of Python. I know they pivoted away from that, but I might play with it now that the compiler is also open source.

I think the compiler not being open-source hurt with getting people to check it out. Today, people are accustomed to most of it regarding PL development being out in the open, and Mojo was an outlier here.

I guess it helps with emphasizing their Swedish identity, which is one of their goals with naming. Doesn't gel too well with "feels good to say" for a non-native speaker, but I see their point.

The bare R experience is not that great, to put it mildly, but it's a whole other story if you add tidyverse on top of it. The data work becomes really easy then, but I still prefer Python because of familiarity and a better experience & ecosystem when you want to do anything beyond data wrangling & analysis.

I found `polars` to be a better experience than `pandas` even though I'd say it leaks some "Rustisms" in its Python APIs. But LLMs alleviate those pains and it's easy enough to review. I'd say it's even easier when there's less of a chance of implicit behavior.

> have some kind of weird pattern baked into their text to act as a watermark.

public abstract class BaseAnimalBeanFactoryGeneratedFromClaudeFactory

lol, you're right, the brainfart completely changes the meaning.

I corrected it.

I'm sooo happy I pulled the trigger on upgrading and getting a new laptop (with 64 GB RAM) last summer. Feels like it was just in time before the exponential price jumps.

You just need to work out the threat model for what you're working on. For trusted containerized workloads, where the attack surface is minimal, just containerization is fine. However, agents can do just about anything on your computer if you allow it and people aren't really shying away from `--dangerously-skip-permissions`, so better hardening (VMs, microVMs) is desirable.