lolinder

I would have used the word 'article' for any post in this format and I don't view that as giving it an elevated status. I didn't even notice it was Substack and certainly don't view Substack as any different than WordPress or Medium for reliability.

It's an article of writing the way that a shirt is an article of clothing.

That is actually unspecified in the license, undecided in court, and as you note very infrequently applied. I can see an argument that the license ought to be read that way, but the fact is that it very rarely is. The only reason why Ollama is being singled out here is because people have long-standing beef with them not doing the regular polite attribution that actually is normal in the community.

This may be true for a lot of people, but it's not universal and is readily avoidable. A few tips that have worked for me:

* Don't install any company apps or log in to any company accounts on your phone.

* Set your working hours in your calendar and stick to them.

* Set your Slack status to automatically show you as away and snoozed outside your working hours.

* When you're done with work, shut down your laptop and walk away.

I've never received any complaints from sticking to this pattern. When I'm in my working hours I'm consistently reachable and I do my job, when I'm not you can't get hold of me if you try. This is how it was in the office, I don't see why the expectation should be different in WFH.

I do think that a key thing that makes this work well for me is that I'm consistently online during (and only during) my specified hours, rather than mixing and matching my schedule on a day to day basis. I'm not always reachable, but I'm predictably unreachable.

The clause at issue is this one:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The copyright notice is the bit at the top that identifies who owns the copyright to the code. You can use MIT code alongside any license you'd like as long as you attribute the MIT portions properly.

That said, this is a requirement that almost no one follows in non-source distributions and almost no one makes a stink about, so I suspect that the main reason why this is being brought up specifically is because a lot of people have beef with Ollama for not even giving any kind of public credit to llama.cpp for being the beating heart of their system.

Had they been less weird about giving credit in the normal, just-being-polite way I don't think anyone would have noticed that technically the license requires them to give a particular kind of attribution.

This article's methodology leaves a lot to be desired. They throw out dozens of studies with a flippant, poorly justified dismissal and then proceed to take a cursory, high-level glance over a single other study that supported their desired conclusion. Having given that study a passing thought they proceed to wonder at "just how glaring this data is" from that single report and how it is that everyone else can't see it.

Ironically, the whole thing reads like someone did all the research and writing on a smartphone and didn't take the time to really construct an argument.

I don't disagree with the title—my assumption is also that parenting would have the largest impact—but the article does a very bad job justifying it and the conclusion that therefore technology isn't worth talking about is absurd. We do a lot of research that is aimed at helping out with marginal gains because marginal gains matter! The entire field of K-12 education exists to be a marginal improvement on top of what parents are already offering. Should we stop researching that field because there's evidence that parents are the single biggest factor in educational outcomes?

Most of our policy choices surrounding children are there explicitly to be a safety net for children whose parents can't provide the environment that they need.

Why, though? Completeness matters more than soundness in practice for this kind of language, which is a large part of what gave TypeScript its edge. The only people who complain about soundness seem to be those whose approach to TypeScript is one of theoretical interests rather than practical application.

TypeScript supports runtime type assertions, but it doesn't mandate them or write them for you.

I should have said your type system cannot be sound without runtime overhead. And I don't believe that choosing automatic runtime overhead is the right move.

Do you know what exactly the difference is with either of these projects adding multimodal support? Both have supported LLaVA for a long time. Did that require special casing that is no longer required?

I'd hoped to see this mentioned in TFA, but it kind of acts like multimodal is totally new to Ollama, which it isn't.

People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens:

* Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll.

* There will always be constructs that you can't type. See above.

* If your type system is going to usefully type enough of the ecosystem, it will be Turing complete.

All of these things are the trade-offs you make when you set out to layer types on a dynamic language, and they're well worth it to get 99% of the way to type safety in a language that otherwise couldn't scale. Theoretical purity is meaningless if the language isn't useful.

My passwords are bound to a domain and Bitwarden will refuse to autofill if the domain doesn't match. I can copy the password manually if I care to, but that's true in every passkey implementation that I've seen as well: they're never the only login option, you can always log in with a password too.

Whataboutism is bad, but there's a distinction between whataboutism and making comparisons to get a sense of the true scale of the problem. If you're not allowed to ever compare relative scales of things without being accused of whataboutism then we're paving the way to making every molehill a mountain.

Two average American's beef consumption for training GPT-3 would place the cost in water of training GPT-3 at 1/150000000 of the US beef industry's average water consumption. That means it's a rounding error relative to all the other uses we place on water, and pointing that out is not whataboutism, it's putting the problem in its proper scale.

But how much more convenient is it really? Filling out the login form with Bitwarden is a single hotkey: Ctrl+Alt+L. That's such a light burden that I'm having a hard time seeing the value proposition for users who are already on a password manager.

I can totally see the value for companies who serve users that don't use password managers—if you can get those people onto passkeys that's a clear security win.

What do passkeys synced over Bitwarden get you that a username + random password does not?

The mission critical problem cuts both ways.

I've weighed the risks and decided that I'm more comfortable relying on Bitwarden for the most critical service than I am hosting in on my own hardware and counting on my own skills to keep it available. I self host plenty of other things, but having `rm -rf /`'d my hard drive before I don't trust myself more than I trust the folks at Bitwarden.

Source [0]. The examples look pretty clearly like they stuck it in the context window, not trained it in. It consistently seems to structure the replies as though the user they're replying to is the one who brought up white genocide in South Africa, and it responds the way that LLMs often respond to such topics: saying that it's controversial and giving both perspectives. That's not behavior I would expect if they had done the Golden Gate Claude method, which inserted the Golden Gate Bridge a bit more fluidly into the conversation rather than seeming to address a phantom sentence that the user supposedly said.

Also, let's be honest, in a Musk company they're going to have taking the shortest possible route to accomplishing what he wanted them to.

[0] https://www.cnn.com/2025/05/14/business/grok-ai-chatbot-repl...

What kind of partnership with hotels could they have made that would have set them apart from the dozen options I already have for booking hotels?

Yeah, probably true.

Most humans don't feel that way most of the time. Barring extreme cases of trauma we tend to be moderately happy regardless of circumstances. If you find yourself unable to be consistently at least neutral in a first world country that tends to be a mental health issue worth addressing.

I think there's some truth to what you're saying here, but there is room for some nuance.

In the US context, you should refrain from blaming specific people and if you possibly can you should explicitly leave open the possibility that everyone involved was trying to do their best (even if you really don't think this is true). Project an assumption of good faith even if it's not deserved.

But that said, you are looking for a new job and no one is going to be surprised to hear that there were things you don't like. More importantly, it's valuable to surface those things because you want to know if the things you didn't like are commonplace in the place you're interviewing.

I have never had a work environment ruined by toxic positivity—the normal healthy human reaction to that kind of environment is gallows humor, which hits the sweet spot between acknowledging the problem and showing a willingness to be there with your team.

I'm sure there are people out there who do have a toxic positivity problem, but my own anecdotal experience leads me to prefer to err on the side of rejecting unnecessarily grumpy people, because they tend to more frequently be a problem.

This part was particularly interesting to me:

> The Open Source Project agrees not to (nor to authorize any third party to): (a) use the GitLab Software and GitLab for Open Source Program materials except for the purpose expressly provided in Section 2.1; (b) modify or create any derivative works of the GitLab Software and the GitLab for Open Source Program materials; (c) take any action that would subject the GitLab Software and the GitLab for Open Source Program materials to any third party terms; (d) copy, distribute, sell, sublicense, rent or lease the GitLab Software and GitLab for Open Source Program materials, including any access key provided by GitLab, or use such items for hosting, service provider, or similar purposes;

If I'm reading this right, in order to participate in the GitLab for Open Source Program (which is the only way to get a decent-sized project for free on GitLab.com any more) you have to renounce your right to several key freedoms with regard to the FOSS version of GitLab.

With GitLab specifically as an alternative: GitLab made it very clear a few years ago that they weren't particularly interested in hosting large-scale free projects when they introduced the Open Source Program as the only path to using GitLab for FOSS. I've heard over and over again that this process is painful and not worth the effort, and it has a bunch of extra requirements that would likely be dealbreakers for Mozilla [0]:

* "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;"

* "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software"

That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab.

So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on.

[0] https://handbook.gitlab.com/handbook/legal/opensource-agreem...

You can't really use the word "certainly" when speaking about "strongly typed" because the entire concept is fuzzy and subjective. From the article you linked:

> > However, there is no precise technical definition of what the terms mean and different authors disagree about the implied meaning of the terms and the relative rankings of the "strength" of the type systems of mainstream programming languages. For this reason, writers who wish to write unambiguously about type systems often eschew the terms "strong typing" and "weak typing" in favor of specific expressions such as "type safety".

I personally think the whole concept of "strongly typed", which is usually used as a prop to make dynamic languages count as part of the cool kids typed-languages club, should be ditched as a point of argument. The supposed "weakly typed" languages people are usually comparing to (like C) aren't actually framed as viable alternative for problems dynamic languages are suited for, so they're something of a straw man. I'd like to see advocates for dynamically typed languages ditch the obsession with having types like the cool kids and instead focus on showing why dynamism is valuable.

There are plenty of great cases to make for dynamism without having to argue on rhetorical ground that the static languages defined and dominate.

Where is the WordPress fork?

There is none because forking the code doesn't automatically bring the community along with you, and so no one wants to risk the instability that would inevitably come from forking. When a project needs a fork it usually much more closely resembles a civil war than it does a succession, and the whole system becomes weaker because of it.

Why would we start with a model that we know will permanently weaken our community when we inevitably need to trigger a succession?

I think that the open source community is too quick to make "just fork it later" the answer to all our governance woes.

Look at the state of WordPress: the (B?)DFL actively bans people from the community for critiquing his self-described "nuclear war" waged against his biggest competitor in the hosting space, which "nuclear war" has caught thousands of members of the community in the crossfire. And yet we see no fork. Why? Because forking is hard and fragments the community, so people would rather put up with a tyrant than deal with the risk of instability. This is no different than tyrants in any other environment.

If a project has good governance established from the beginning, including a reasonably democratic process for contributors to elect the executive function, then the community can be reasonably sure that they won't feel the need to fork in the future because they have recourse if things go sour.

I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.

I'm not trying to be pretentious, but wrangling an HN thread is hard and I don't have time to get into an argument about a bunch of different implementation details. Rather than just ignore your post I decided to respond explaining why I couldn't answer.

The only valid short answer is what I said: that it really depends on the details and how they all work together. I truly can't give you features in isolation that won't be questionable, because the decision hinges on the whole combination of factors. Had I said "x and y" someone would have come along and argued that X and Y didn't call for a framework because Z. Me identifying the two points would have accomplished nothing and would actually have undermined my primary point of "it depends".

Edit: btw, I just corrected the downvote on your original post with an upvote. Whoever did that probably assumed you were being belligerent, but that's not fair.

Forks introduce chaos and are sometimes impossible. If WordPress had a different government structure from the beginning Matt would not be in power anymore, but because it's a dictator for life he's still there and the community has decided to put up with him rather than risk the chaos of a fork.

No one is happy about it, but collective action is hard when it's not baked into the system.

I'm increasingly disaffected by the idea of BDFL-run projects.

The concept is appealing—it's essentially Plato's philosopher king. The BDFL can unstick decision making and ensure the project moves forward without having to litigate every decision in committee, they maintain context and vision throughout the life of the project, and because they're not accountable to anyone they can make the right call for the project rather than having to make complicated political trade-offs. It's all the perks of a monarchy.

Unfortunately, we've seen over and over again that the BDFL model also has all the problems of monarchy. If you get a good one it's the most effective form of government, but people are fickle things. Frequently we see things like this, where the BDFL turns out to have been malevolent after all or decided that they are the project and are entitled to the sole profit from it. WordPress comes to mind.

A good BDFL is worth keeping, but I think we'll find that drawing inspiration for our community structures from real-world democracies/republics will be more stable and reliable in the long term and more generalizable across new projects. Democracies aren't perfect, but by design they smooth out the variance of the individual humans in the community, giving you much more predictable results over time than monarchies do.

I'd have agreed with you a year ago, but the WordPress debacle shows that the BDFL concept really hangs on the "benevolent" part of the job description. If your BDFL goes rancid your only option is to fork, and hostile forks are very difficult to pull off because it almost invariably forks the community.

The BDFL archetype is basically Plato's philosopher king. It's a nice and appealing idea in theory, and works well if you get a good one (Matz for Ruby, by all accounts). But it's risky, and it's hard to be sure yours is actually benevolent and will stay benevolent.