whimblepop

Almost never do software companies even attempt to design secure systems. I'm not sure this requires new fundamental research so much as slightly giving a shit.

Bullshitting is how LLMs work. It doesn't require active encouragement. All it takes is a machine without consciousness or physical access to the world and an actually-lived life. A training set that contains lots of confident answers and few to no refusals doesn't help either.

When Apple Sherlocks something, aren't their implementations usually worse? Typically the thing being Sherlock'd is very mature and featureful, and Apple's implementation is much less capable and has undergone much less user testing, at least at the outset.

To be clear, this does technically meet the very minimal commitment[1] they gave when announcing the acquisition:

In the coming weeks, we will relicense all of our source-available tools, including Tart, Vetu and Orchard under a more permissive license. (HN discussion: https://news.ycombinator.com/item?id=47730194)

In this case they moved from one source-available license (Fair Source License v0.9 with seat restrictions) to another (Fair Source License 1.1-ALv2 without seat restrictions), with the same sort of restrictions on field-of-endeavor as before.

Why they've chosen this isn't super clear, as (1) there are already open-source alternatives that use the same storage formats as Tart, like Lume[2]; and (2) Tart is certainly already in the training sets of all of OpenAI's "direct competitors", who are practically held back little or not at all by the restrictions of the FSL. The only entities this really restricts are F/OSS distributions which might otherwise include Tart as a first-class package in their distros. :-\

--

1: https://web.archive.org/web/20260412071019/https://cirruslab...

2: https://github.com/trycua/cua/tree/main/libs/lume

Writing better exams, even if they're more expensive to grade, and removing homework from grading as far as possible addresses this problem well wherever it's applicable. Senior-level math courses at many universities are already like this: homework is ungraded, or counts for little, and it's possible for students to "cheat" on the homework by copying another student instead of struggling through the exercises. But the students who do that don't learn much, if at all, and predictably fail the exams. Professors warn students at the beginning of the class and tell them how this will work, something like:

You can always ask me for feedback on your homework and I will mark up every part of it, but you won't receive a grade for homework. However, if you don't do the homework and take your time with it, you will fail the class. My office hours are in the syllabus and you're strongly encouraged to use them. There will be an early exam to give you a chance to know whether you are likely to fail this class before you lose your chance to drop it.

Correctness is harder to adjudicate in some humanities disciplines but the format of these exams is actually not super different from essay tests (when a math professor grades a proof, they're inspecting specialized prose for validity, coherence, persuasion in a way that also reveals knowledge).

When you don't rely on homework for determining whether or not a student passes the class, you make cheating on the homework into the student's problem instead of the professor's or the university's. Students have the right incentives to solve problems for which they are the ones responsible, and they figure it out after one failed (or ideally, dropped) class at worst.

Whether things like "intelligence", "cognitive ability", and "aptitude" (some of which may be synonyms depending on your view) are innate vs. learned or fixed vs. variable over time are orthogonal to each other. And for each of those pairs, the answer may not be as simple as a binary division or even a gradient (it may decompose into something weirder, being causally determined by multiple factors where some of those factors are fixed and others aren't).

Moreover, both of those questions are separate from questions that get at what IQ measures (does it measure aptitude, does it measure factual knowledge, does it measure social knowledge or acculturation within a specific context, etc.).

Lots of things are easy to identify as both substantially genetically determined and variable over time and mediated by environmental factors, e.g., height. Lots of things are likewise easy to identify as significantly environmentally determined but also largely stable over time if not altogether fixed (e.g., personality, attachment styles).

It's also at least possible for all of the following to be true at the same time:

  - IQ tests correlate with socioeconomic status
  - IQ test scores vary over time and can be increased
  - some IQ score increases, or some part of a given IQ score increase, reflects a genuine aptitude increase
  - IQ tests are somewhat gameable in that training for IQ tests can increase scores so that some of the measured increase does not measure improved cognitive ability

IQ is about aptitude and credentials on specific topics are about knowledge and skills. It's the wrong thing to optimize for.

Besides, high-IQ students can still underperform for many of the same reasons that average-IQ students often do (e.g., under-preparation, lack of discipline, disorganization, mental illness, financial distress, unstable living situation). We should be better addressing those things before students get to a university no matter what their IQ is.

Beyond that, if you have good competency tests on both ends (i.e., the credentials before a four-year degree are accurate signals, and university degrees effectively prove a high degree of competency), who cares if someone manages to get those credentials by working harder while being dumber? I like working with clever people. I also like working with people who know their shit because they take their time to study and consider things. (When I'm lucky, I get to work with people who are both!)

You can't make people more knowledgeable by not attempting to measure their knowledge. You can maybe try to improve things for subsequent generations. But issuing a false credential won't solve the problem.

https://www.scienceopen.com/hosted-document?doi=10.14293%2FS...

The average university attendee's IQ is virtually indistinguishable from the average person's IQ.

People don't go to college because they're smart. They predominantly go so they can earn more money and/or work more enjoyable jobs when they graduate. Being smart isn't the main reason that adults encourage teenagers to pursue college either. It's mostly a matter of class reproduction; it's the "default" for anyone whose parents are college graduates.

And failing out once you get to the university isn't generally an IQ issue, either. Mediocre and slightly stupid people graduate from universities with degrees they've earned fair and square every year. You don't have to be smart to finish a degree. You do have to be reasonably prepared, and that's the primary issue.

I love the Asahi project and I'll probably keep my oldest M-series Mac around to continue to play with Asahi. But even for the oldest Macs it supports, the feature list is not quite complete. The way Apple does a lot of things is bespoke and involves a different division of labor between firmware and operating system than conventional UEFI systems. It's hard to support. I don't want to be required to wait years for features like full support for Thunderbolt docks, and I also want to give my money to a company that proactively supports Linux (e.g., sending hardware to kernel developers, FreeDesktop graphics driver developers, DE maintainers, and distro maintainers in advance of the release of new products) rather than always buying used or giving my money to a company that merely tolerates Linux support.

Again, I love the ambition of the Asahi project and what they've done. They're impressive hackers, and thousands of people will doubtless get years of happy Linux life out of their work— maybe including me! I have no complaints for them, and no wishlist I want to bring to them. In fact, I think maybe I should send them a donation or a kind email or both upon their next release.

But I want to give the bulk of my financial support to a computer vendor who offers me first-class, day-1 support for software environments that make me feel happy and respected. The Asahi team can't turn Apple into that by themselves.

I was seduced by Apple Silicon after experiencing the exceptional battery life and performance. Those things are great, as are the screens and the speakers.

But I'm still excited about the Framework 12 because I don't love macOS. I don't need an alternative to beat Apple on every line of the spec sheet. I just need them to align with my values, support Linux well, and cross a certain "good enough" threshold. The latest laptops from Framework meet all of those requirements, and I'm excited to buy one after I've saved up enough money. I've missed Plasma for a long time. At the same time, I wouldn't even consider a MacBook Neo.

Thanks! Love the game as a whole :)

I got "overblocked" for this one:

  rm -rf node_modules && npm install

Anyway you should generally run `npm ci` except when you're deliberately updating your actual dependencies. I'd only permit an `npm install` if I was adding or updating a dependency, or I'd just reviewed an `npm ci` failure.

It surprises me because I'm often asked why I knew X or Y odd perhaps esoteric fact or design pattern. Usually it's because I came across it in a book interested in something else.

It was like this in the days when the primary shortcut was StackOverflow as well. People who are allergic to RTFM treat things that are covered in the docs as "esoteric" knowledge because they never read anything except as a shortcut to solving their immediate problem.

I think the stats are clear that reading is in decline in general, though. I'm sure LLMs will add to this much like YouTube has.

When I wrote the comment you replied to here, I of course had Sabayon in mind.

Sabayon had some loveliness beyond that surface level, too. If the distro still existed (MocaccinoOS is a thing nowadays, but it's a completely different base), I'd probably spin it up out of nostalgia.

That's great! Thanks for informing me. :D

Kinda surprising that this doesn't support Linux.

Podman can transparently start microVMs instead of local containers via libkrun as well, which does support Linux: https://josecastillolema.github.io/podman-wasm-libkrun/

SARIF is kinda nice for security-oriented linters imo, since lots of tools know how to speak it. It avoids lock-in that way, which is otherwise/previously pretty common, with every scanning tool using its own bespoke format.

That's exactly the kind of flashy, gaming-forward distro I was drawn to as a teenager. Good times :)

I think internal organizations of employees of various shapes (unions, affinity groups, "employee resource groups") can be useful for diversity and inclusion issues. But you also need budgets and power and integration with other departments. HR needs to care about non-discriminatory hiring practices in a first-class way. Legal needs to see ensuring good-faith legal compliance with the requirements of the ADA before anyone brings a lawsuit as part of their mandate.

Anonymous, third-party outlets for complaints like Blind can also likely be useful. Even at companies that never punish anyone for criticizing the company, participation rates in internal surveys are typically atrociously low, and people stop speaking up even informally if it's clear to them that nobody actually acts on employee feedback. Most companies probably perceive such channels of communication as threats, though.

Idk about audits. I worry that it's easy for them to become their own circus and overhead without materially improving things. But you may be right.

The FSF's purpose in writing the GPL is the protection of end-user freedom, including the freedom to inspect and modify the code (or paying someone else to do so) of whatever software people use.

Linus' purpose in adopting the GPLv2 was something like "to avoid free-riders on his kernel code; if you make improvements upon the Linux kernel for some product, you have to share them with the users of your product".

The GPLv3 addressed a gap in the protections GPLv2 guarantees to end-users, namely that if a vendor locks down other parts of the stack (in the case of the Linux kernel and TiVo-ization, at least the bootloader), inspecting the and modifying the software can be useless for them in terms of the real freedom it grants those users— the device can just refuse to run the modified software.

For Linus, moving to GPLv3 would extend the domain of the GPL beyond the code of his project to the broader context in which it is used, namely the situation of the user. He sees this as inappropriate, in a way. He doesn't care about the broader context in which Linux is deployed or if some devices only allow you to run vendor-approved kernels. He sees the GPLv3 as changing what "GPL" means in a way that offends him.

For the FSF, the point has always been to use licensing as a mechanism to protect and promote the freedom of people using computers. The FSF's primary concern has never been the rights or conveniences of maintainers at all. It's not about "no freeriders with downstream forks who hide their patches", though that was an incidental effect of the GPLv2. The purpose is to use copyright licensing as a mechanism to inch towards a world where users who do computing— on their laptop, on their mobile phone, or on their TV's set-top box— can transparently inspect and modify all of the devices they compute on. For them, the GPLv2 had a vulnerability that made its function of protecting user freedom easily bypassable, and they patched it in the GPLv3.

But the question of whether linking against the kernel's public interfaces constitutes a derivative work is outside the scope of GPLv2 vs GPLv3 and not yet fully tested/settled by the courts.

Hopefully this context does make clearer, at least, the spirit of the license of the software Bambu inherited when they forked it from others. It's very much about letting users actually modify/replace the software running on their devices without restriction.

IANAL

Someone reverse engineered the plug-in and put it into orca slicer and then claimed that the plugin should have been GPLed to begin with which I find dubious. I don't really see it being much different than downloading closed drivers on Ubuntu but I'm also not a open source lawyer.

The GPLv3 specifically was written to address a problem called "TiVo-ization", which is when a hardware vendor uses some trick (DRM, proprietary blobs, whatever) to prevent users from actually running modified versions of the software.

The AGPL, the license of this particular software, extends the GPLv3 with protections for users of network services:

Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program. In both licenses, sections four through six provide the terms that give users the right to receive the source code of a program.

https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t...

And on TiVo-ization: https://en.wikipedia.org/wiki/Tivoization

The Linux and proprietary drivers situation is more complicated, but proprietary drivers on Linux are generally restricted to interfaces that Linux chooses to expose to them for that purpose. But the Linux kernel seems to take a narrower view of what constitutes a derivative work than was likely intended by the FSF in writing the GPL. Under a "traditional" reading of the GPL, those proprietary drivers are meant to be illegal. Whether some or all of the linking done by proprietary drivers in the Linux kernel is really allowed by the GPL or not is somewhat untested, I think.

GitLab isn't open-source. It's "open-core". Third parties hosting GitLab instances don't have access to the same range of features that GitLab-the-company does.

You can end up with a lot of people talking about it a lot, lots of meetings and initiatives rather than doing actual work. And usually those don't go anywhere because the people doing it don't have any power to actually change things.

Someone I'm close to is going through this right now. They work at a place that officially highly values "inclusion", and their employer's website is dripping with virtue-signaling language related to it. But that someone is disabled, and in fact there's nobody at the organization who owns accessibility issues. Disability accommodations are haphazard, and often not timely. Why? Because no one owns them. They just get punted to an internal employee affinity group of disabled people who don't have a real chain of command, a real budget, or even a real prerogative to do accessibility work, let alone meaningful power— many of its members are routinely chastised by their bosses whenever they dedicate any time to solving access problems within the company. "That's not what we pay your for", "that's not your job", "I need you on this other thing", etc.

Meanwhile the organization receives public accolades from meaningless business press organization as a "great place to work" or even "great place to work for people with disabilities".

I think it's fine for companies to value diversity, and to value it publicly. A little virtue signaling is fine, as a treat; it may actually repel nasty people, encourage good behavior, or make employees feel more welcome sometimes. That stuff is good.

But there's also a real possibility that a company making diversity an explicit value results in lots of energy going into activities that let that company's executives pat themselves on the back about how good they are without actually doing much for inclusion. I wouldn't take any sizeable company's stated values too seriously, including that one.

GitLab's old values are for now still listed in their handbook:

GitLab’s six core values are Collaboration, Results for Customers, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency, and together they spell the CREDIT we give each other by assuming good intent. We react to them with values emoji and they are made actionable below.

Since those terms don't speak for themselves individually, it's worth seeing what they're supposed to mean to get a sense of what GitLab is forsaking now. Each section is actually pretty lengthy, so you should go look and skim for yourself.

Here's the page: https://handbook.gitlab.com/handbook/values/

And here's an archive from yesterday, for when that changes: https://web.archive.org/web/20260510150031/https://handbook....

One morning in 1976, the Princeton mathematician Edward Nelson (opens a new tab) woke up and experienced a crisis of faith. “I felt the momentary overwhelming presence of one who convicted me of arrogance for my belief in the real existence of an infinite world of numbers,” he reflected decades later (opens a new tab), “leaving me like an infant in my crib reduced to counting on my fingers.”

Friends don't let friends do Platonism.

For real, if you're a formalist you can ask these foundational questions without fear of this kind of dread; they become methodological rather than some kind of metaphysical mess.

In practice, it was seldom done, and here we have LLMs actually doing it, and we're realising the drawbacks.

I spent some time dealing with this today. The real issue for me, though, was that the refactors the agent did were bad. I only wanted it to stop making those changes so I could give it more explicit changes on what to fix and how.

There are many reasons why others might not find what you wrote sufficient to understand it. You boss ran it through AI for a reason and that reason was most likely because it the document was not understandable or perhaps confusing.

It could also be because their manager is less technical. It's not unusual in my life for a PM to try to "rephrase" or restate things I've written in order to make them "easier to understand" in a way that in fact falsifies them or makes them more difficult to understand for the people who will actually have to work on/with it.

My own approach to simplicity generally means "hide complexity behind a simple interface" rather than pushing for simple implementations because I feel that too much emphasis on simplicity of implementations often means sacrificing correctness.

This particular example is a useful one for me to think about, because it's a version of hiding complexity in order to present a simple interface that I actually hate. (WYSIWYG editors is another one, for similar reasons: it always ends up being buggy and unpredictable.)

The whole "just sync everything, and if you can't seek everything, pretend to sync everything with fake files and then download the real ones ad-hoc" model of storage feels a bit ill-conceived to me. It tries to present a simple facade but I'm not sure it actually simplifies things. It always results in nasty user surprises and sometimes data loss. I've seen Microsoft OneDrive do the same thing to people at work.