paulirwin

Seat-based pricing just includes a certain amount of token usage at a discount for buying in "bulk" (and risking not using all your usage). You can still pay the API token-based rates if you really want to; they won't stop you from doing that.

It is different. I do nearly 100% of my .NET development on macOS, only dropping into Windows to support .NET Framework users of open-source projects I work on, and we deploy exclusively now on Linux containers. The apps I maintain haven't touched a Windows server in years. My colleagues (and OSS co-maintainers) use a mix of macOS, Windows, and Linux. I use Rider instead of Visual Studio.

The only time I've been forced into a "culture of Windows and creaky Lenovos and Dells" recently was on a Java project. (Anecdotally, of course. Java has a similarly cross-platform culture as a whole.)

My two-year-old son had started saying "turn around" in a sing-song kind of way several months back, and thus my wife and I, both babies of the 80s, had to start singing the song whenever he would do it. It became a fun thing that my son enjoys more than we do. That turned into regularly playing this song (and its covers) in the living room. We just did this again a few nights ago because he loves the song so much and requests it now.

RIP Bonnie.

And what about containers/VMs, or booting software bare metal?

Does my laptop have to pass my age verification to a Docker container?

Am I at risk of government censorship (or worse) if I create a hobby smart home app that boots bare metal on a Raspberry Pi?

Or even the shell apps that I run daily. Does curl (which can access any web url) have to validate my age? What about AI models/ollama?

One thing that MCP solves well, that neither CLI apps (like the `gh` CLI for example) nor letting your LLM call arbitrary APIs via CURL does, is setting granular permissions per tool.

Most agent frontends I've used like Claude Code only give you one level deep of CLI commands to authorize, which works fine for allowing commands like `docker build:*`. But for complex CLIs like GitHub, Azure, etc. it just doesn't scale well. It is absurd to grant Claude Code permission to `az vm:*` when that includes everything from `az vm show` to `az vm delete`. Likewise, the argument that says that you should just let your LLM call APIs directly via curl or whatever, does not hold up well when Claude Code just wants raw access to all of `curl:*`.

Meanwhile, MCP tools are (currently, at least in CC) managed at the individual tool level, which is very convenient for managing granular permissions.

Perhaps there could be some "CTCP" (CLI tool context protocol; the CCP acronym does not work well) where CLI apps could expose their available tools to the LLM, and it could then be dynamically loaded and managed at a granular level. But until then, I'm going to keep using MCP.

As a vegetarian of 20 years, I like being able to go to restaurants and have something that is on par with what my friends and family are eating (although I do prefer Impossible to Beyond, by far). Even without friends and family, there's a social (and distinctively American) aspect to being able to have a realistic burger and beer at my local sports bar/grill and not just have a salad or some Sysco frozen black bean burger.

Avalonia is FOSS (MIT licensed). You only need Avalonia XPF if you are migrating legacy stuff.

Moq is largely unnecessary today with LLMs being able to easily generate mock classes. I personally prefer to hand-roll my mocks, but if you prefer the Moq-like approach, there's NSubstitute (3-BSD).

Automapper and MediatR are both libraries I avoided prior to the license change anyways, because I don't like runtime "magic" and not being able to trace dependency calls through my code. But, there is Mapster and Wolverine to fill those needs (both MIT). Wolverine can also replace much of MassTransit.

Telerik stuff - there are many good FOSS alternatives to these UI components; too many to list since it depends on which stack you're using.

PDF is indeed a sore spot. PdfPig is good, but limited in capability. I've started offloading PDF processing to a separate Python container with a simple, stateless Flask API with PyMuPdf.

> we have a problem with opensource being asymmetrically underfunded and if people going commercial is the cost perhaps we've failed.

Completely agree with this, though. My company and myself personally contribute a lot of time back to OSS, and I feel like that is part of the social contract of OSS. To have these libraries rug-pulled feels like a slap in the face as a OSS contributor and maintainer.

Yeah, agreed. Anker, if you're reading this - please open source the printer hardware/parts and software if you're truly pulling out of the market!

It seems like everyone is dog-piling on Anker over this, so I'd like to put forward a bit more positive of a take.

I have a M5 that I got through the original Kickstarter campaign. I love this printer. I use it casually, but I rarely have a failed print that I can't attribute to i.e. poorly chosen supports. Almost all of the parts on it are still original and working well, apart from the hot end that I've had to replace a few times due to accidentally breaking the screws when changing nozzles. (It was a poor design of the original hot end where the very thin, long screws did not have the shear strength in aluminum to not break when accidentally torquing the nozzle head. This was fixed with the all-metal hot end, which is not ideal for all filaments.)

Despite my issue with the hot end (which I believe could easily be fixed with an updated design), and the nearly useless "AI" feature, I feel like this printer was a great value at the time. It's very well built, looks great, and very reliable. I really enjoy every opportunity I have to use it and do not regret my purchase decision at all.

I'm saddened that they seem to be pulling out of the market, even though it makes sense compared to the competition. It really seemed like they had a promising start. If this is truly the end, then RIP with positive sentiments from me.

Azure SQL Database for a long while has been the most cost-effective way of running SQL Server as a PaaS database, and still is if you choose the DTU-based modes, making it a very attractive option. Combined with the rich feature set and maturity and reliability of SQL Server, it is hardly legacy; in fact it's very capable and continues to get new updates like vector operations.

I've helped create apps that support millions to hundreds of millions of revenue on Azure SQL Databases that cost at most a few hundred dollars per month. And you can get started with a S0 database for $15/mo which is absolutely suitable for production use for simple apps.

Unfortunately, I think Microsoft realized how good of a value the DTU-based model was, and has started pushing everyone to the vCore model, which dramatically increases the barrier to entry for Azure SQL Database, making PostgreSQL a much more attractive option. If Microsoft ever kills off the DTU purchasing model of Azure SQL Database, I likely won't be recommending or choosing Azure SQL Database at all going forward. It'll 100% be PostgreSQL.

Can someone check my understanding: does this mean they have eight logical qubits on the chip? It appears that way from the graphic where it zooms into each logical qubit, although it only shows two there.

If that is true, it sounds like having a plan to scale to millions of logical qubits on a chip is even more impressive.

These are the first few sentences of the article:

> Cadmium is bad news. Lead and mercury get all the press, but cadmium is just as foul, even if far fewer people encounter it. Never in my career have I had any occasion to use any, and I like it that way.

It seems clear that he doesn’t want to work with cadmium, regardless of the compound.

Congrats on the launch! This looks great.

I see you plan on making money by charging for the hosted service. Given that, and given recent history in the industry with companies starting out with this model only to rug-pull it from users later and move to a more restrictive license, can you publicly commit to keeping the code MIT/AGPLv3-licensed into the future?

They now refer to the former as Windows PowerShell, and the latter as PowerShell. The Core part was dropped.