pxc

> MacOS doesn’t claim to work on other hardware, Linux does.

"Linux" isn't even an operating system. There is no entity in the world who claims "bring any Linux distro at all to any random assortment of hardware you happen to already own, it'll be great and we'll commercially support it!".

Huh? I never claimed they made a breakthrough. My point is that if they really have an alignment or interpretability breakthrough, they won't have to tell us by virtue signaling about how safe it is. Users will just be able to tell because it will eliminate or drastically reduce problems like #3 in the OP. The outcomes of prompt changes remaining unpredictable tells us it's still a black box.

GitLab annoys me in tons of ways, but I feel it's generally better than GitHub in lots of ways.

This is the problem for me with the cloud:

> Finally, clouds have painful APIs. This is where projects like K8S come in, papering over the pain so engineers suffer a bit less from using the cloud. But VMs are hard with Kubernetes because the cloud makes you do it all yourself with lumpy nested virtualization. Disk is hard because back when they were designing K8S Google didn’t really even do usable remote block devices, and even if you can find a common pattern among clouds today to paper over, it will be slow. Networking is hard because if it were easy you would private link in a few systems from a neighboring open DC and drop a zero from your cloud spend. It is tempting to dismiss Kubernetes as a scam, artificial make work designed to avoid doing real product work, but the truth is worse: it is a product attempting to solve an impossible problem: make clouds portable and usable. It cannot be done.

Please learn from Unix's mistakes. Learn from Nix. Support create-before-destroy patterns everywhere. Forego all global namespaces you can. Support rollbacks everywhere.

If any cloud provider can do that, cloud IaC will finally stop feeling so fake/empty compared to a sane system like NixOS.

Labor-saving devices don't save labor at work. They increase productivity rather than reducing hours, and the extra value is captured by the employer.

That's the difference between your home dishwasher and the means of production.

It's also probably a big part of what worries Gen Z about when it comes to AI. They're thinking about their own employment and employment prospects, where most people probably understand they have little to gain from it long-term.

Maybe that's true. But I think part of the issue is that for a lot of things developers want to do with them now— certainly for most of the things I want to do with them— they're either barely good enough, or not consistently good enough. And the value difference across that quality threshold is immense, even if the quality difference itself isn't.

One of Anthropic's ostensive ethical goals is to produce AI that is "understandable" as well as exceptionally "well-aligned". It's striking that some of the same properties that make AI risky also just make it hard to consistently deliver a good product. It occurs to me that if Anthropic really makes some breakthroughs in those areas, everyone will feel it in terms of product quality whether they're worried about grandiose/catastrophic predictions or not.

But right now it seems like, in the case of (3), these systems are really sensitive and unpredictable. I'd characterize that as an alignment problem, too.

The approach you outline is totally compatible with an additional one or two day time gate for the artifact mirrors that back prod builds. Deploy in locked-down non-prod environments with strong monitoring after the scans pass, wait a few days for prod, and publicly report whatever you find, and you're now "doing your part" in real-time while still accounting for the fallibility of your automated tools.

There's risk there of a monoculture categorically missing some threats if everyone is using the same scanners. But I still think that approach is basically pro-social even if it involves a "cooldown".

Install tools using a package manager that performs builds as an unprivileged user account other than your own, sandboxes builds in a way that restricts network and filesystem access, and doesn't run let packages run arbitrary pre/post-install hooks by default.

Avoid software that tries to manage its own native (external, outside the language ecosystem) dependencies or otherwise needs pre/post-install hooks to build.

If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history.

Learn how your tools actually build. Build your own containers.

Learn how your tools actually run. Write your own CI templates.

My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks.

Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can:

  - write and distribute CI templates
  - run caches, proxies, and artifact repositories which might create room to
    - pull through packages on a delay
    - run automated scans on updates and flag packages for risks?
    - maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration
  - set up shared infrastructure for CI runners that
    - use such caches/repos/proxies by default
    - sandbox the network for build$
    - help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal
  - provide docs
    - on build sandboxing tools/standards/guidelines
    - on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards)
  - promote packaging tools for development environments and artifact builds, e.g.,
    - promote deterministic tools like Nix
    - run build servers that push to internal artifact caches to address trust assumptions in community software distributions
    - figure out when/whether/how to delegate to vendors who do these things

I think there's a lot of things to do here. The hardest parts are probably organizational and social; coordination is hard and network effects are strong. But I also think that there are some basics that help a lot. And developers who serve other developers, whether they are formally security professionals or not, are generally well-positioned to make it easier to do the right thing than the sloppy thing over time.

How is ortholinear supposed to be better? I've never used a full-size ortholinear keyboard but every time I've had one on a portable keyboard or mobile device it has driven me nuts (and staggered keyboards of the same sizes have not).

I agree that offering more user choice here could be a unique and standout feature, though. One of the small things I love about their keyboard offerings is that they offer all blank key cap options.

> I never thought about battery life while the lid is closed until my Framework.

In the days of S3, I never thought about it either. Ironically it's on my Mac that I have to remember to hibernate if I won't use my laptop for a week or whatever, because it'll die if I don't. It just happens to be that it was on a Mac on which I first tried "modern standby" features.

Anyway I feel you. This big battery life improvement is what has convinced me my next laptop can be a Framework.

Wow. For as long as I can remember it was usually the opposite for me. Even after configuring TLP and looking for things to tune manually with powertop, I usually didn't get battery usage quite as low as I wanted. I thought it was still typical for Windows to be better.

Are you running a DE or just a lightweight WM?

HP Envy does have OLED screen options. I'd assume it's what they have, if they thought dark mode was relevant.

Is Framework open to an OLED panel option in the future? I have an eye disease that makes extremely high contrast and extremely deep blacks very helpful to me, since it means I can get good contrast with less total light. I can still read LCD displays well enough, but as my eyes worsen, that may not be true.

Since Framework has a great track record with display upgradability, just an indication that there is serious interest in OLED options in the future would be enough to sell me.

So if anyone at Framework is reading this: is there any opposition inside framework to OLED? Any fundamental constraints that make OLED panels unlikely for the next several years?

Me, neither! I just had someone suggest to me yesterday that I was "holding it wrong" for preferring a real click mechanism on my trackpads.

I doubt they had one. Context.ai got acquihired by OpenAI when it was still a very small company. I think they were winding down the original business, so it's unlikely that it grew after that.

Some of these are consequences of what makes them feel "premium" or even "solid". Aluminum is a terrible material for bumps and drops because it dents, and that often damages the internal components.

Systems that have trackpoints have physical mouse buttons, so you can just do real right clicks. Scrolling typically has its own input combo: hold the middle mouse button plus push the trackpoint to scroll in whatever direction you're pushing.

If there's a trackpad as well (usually there is), you can still do all the multi-finger gestures on it unless you choose to disable the trackpad altogether.

Fwiw, I don't find the trackpoint faster or more precise than the giant MacBook trackpads. Its main advantages are being closer to your index fingers' likely resting position on the keyboard, physical mouse buttons, and requiring less vertical space than a giant trackpad.

Sure, I can tell you one thing that's different right now: I use third-party software to get a three-finger middle click. If Apple's operating system weren't missing basic features like the ability to middle click via the trackpad, I wouldn't have to do that and maybe wouldn't have this problem.

Amarok was way better than iTunes in that era. Massively better UI, separation of playback queue from collection browsing, plugin ecosystem, better metadata fetching including lyrics support... And its dynamic playlists were way more capable too.

I had an iPod in those days and Apple's firmware updates that periodically broke third-party sync (while bringing no improvements) is the reason that to this day I've never bought Apple hardware for myself from Apple since that time. Used hardware only.

Every time I had to use iTunes was regrettable. The app was an insanely massive download for the time. It tried to install fucking Safari on Windows for no reason. The UI was somehow simultaneously a sprawling mess and feature-deprived.

Maybe there was a brief period where iTunes was genuinely an interesting app, but even by the mid-aughts, it had been totally surpassed by a number of open-source music players.

But Amarok at that time was only available on Linux. I assume most iTunes fans of the time never got to try it.

It's also annoying that macOS doesn't already have at least basic per-app volume mixing.

So much pain in macOS is in areas like this, trying to hack basic features back into the anemic OS.

Apple's "OS" updates typically focus on end-user applications that I don't use and never intend to. Meanwhile the core of the OS, and even the desktop environment, feels stagnant compared to many Linux distros.

> I don't know about Thinkpads, but the utterly pleasant glass trackpad is still one of the things I cannot find on most non-Mac laptops, despite every manufacturer being able to copy it for years.

I was never a trackpad person until I finally got a Mac at work maybe 10 years ago. But since the trackpads stopped really clicking in favor of haptics, they're a lot worse than they used to be. I get false/double clicks and inconsistent feedback.

ThinkPads have nicer keyboards, but they stopped doing the more traditional IBM layout several years ago, which is really unfortunate. I'd be willing to pay for a more traditional keyboard layout with a slightly smaller trackpad and/or a sizeable bottom bezel (which is actually preferable for me because of my posture when I use a laptop most of the time).

A fun little adventure either way! I'm sure you won't regret having learned a little more about these writing systems. :)

> UX problem, blame the engineer. [...] Documentation problem, blame the engineer.

I see UX and usable documentation as among my responsibilities as a developer. It's not that I "blame" myself if the documentation is confusing for a user, it's that I say "oh, that's a documentation bug". And it's my job to fix bugs.

There are manners of speaking (and whole languages) that are more explicit and manners of speaking that are more implicit/contextual. There's a tradeoff between doing disambiguation work in expression vs. in interpretation, and people's communication preferences often determine this distribution of cognitive effort. (And for many people, one half of that exchange is easier than the other.)

It's true that misunderstandings can arise between people who both tend to communicate very explicitly, but they're just different from the kinds of misunderstandings that occur with people who tend to leave more disambiguation work to the interpreter. I'm feeling lazy atm so idk what to say about that except that you'd know it if you saw it.

It's true that the details are messy, but in practice it's not that difficult to recover basic concepts related to such differences in personality like "more literal" vs. "less literal" in a way that's useful.

> I’m sure if I spoke to your counterparts in the scenario you described they’d say different words which also ultimately amounted to something like “it’s difficult to interpret what they’re saying.”

Yes and no. Lots of people who speak in a way that relies more heavily on (real or presumed) shared context react to precise turns of phrase from their counterparts who prefer explicitness like "Wow! You're so good and finding the right words for things.". When they do misunderstand, they're typically less likely to notice. You only usually get the "you're difficult to interpret" realization from them if you are discussing a specific misunderstanding and you come upon a logical or grammatical distinction they just can't see.

I'm not a linguist or communications scholar and idk if any work has been done to see whether related traits really form identifiable profiles or personality types or whatever, but at least some individual traits and behaviors that I associate with these personality differences are pretty easy to measure. For example: the "intuitive" speakers/listeners tend to make more use of anaphora as well as more difficult (more distance in the conversation from the referent) and more complex (the referent may not be the most recent grammatically compatible named thing/person) use of anaphora. They also tend to see more ambiguous use of quantifiers as grammatical (little sensitivity to "surface scope/logical form isomorphism").

Idk what to tell ya but there's a real spectrum here. If you fall in the middle of it, it might be easy to miss. But for people at opposite ends of it, the kinds of communication they encounter with one another are pretty unmistakable.

Relatedly, there's a single load-bearing word in GP's comment that you seem to have missed or given inadequate emphasis:

> Many people I find speak in what I would describe as tone poems.

It's that first word I've emphasized above, "many". They're not running into this kind of communication problem with everyone. That should increase the curiosity you hint at in the beginning of your comment, because it suggests that this is not the simple problem of one person assuming everyone can/should automatically understand them as well as they understand their own statements. Their experience and their self-report of it describes a structured and selective clash in communication (down to their admission/suggestion that they may be on the autism spectrum) which your reply seems to miss.

OpenAI owns Contexts.ai, doesn't it?

Absent any distinctive Japanese scripts or other Japanese writing in context, it probably makes more sense to call those Chinese characters, since those characters for numbers were taken directly from Chinese and still retain the same/original meanings in both languages

> One thing I immediately like more than Claude is that Codex seems much more transparent about what it’s thinking and what it wants to do next. I find it much easier to interrupt or jump in the middle if things are going to wrong direction.

I've finally started experimenting recently with Claude's --dangerously-skip-permissions and Codex's --dangerously-bypass-approvals-and-sandbox through external sandboxing tools. (For now just nono¹, which I really like so far, and soon via containerization or virtual machines.)

When I am using Claude or Codex without external sandboxing tools and just using the TUI, I spend a lot of time approving individual commands. When I was working that way, I found Codex's tendency to stop and ask me whether/how it should proceed extremely annoying. I found myself shouting at my monitor, "Yes, duh, go do the thing!".

But when I run these tools without having them ask me for permission for individual commands or edits, I sometimes find Claude has run away from me a little and made the wrong changes or tried to debug something in a bone-headed way that I would have redirected with an interruption if it has stopped to ask me for permissions. I think maybe Codex's tendency to stop and check in may be more valuable if you're relying on sandboxing (external or built-in) so that you can avoid individual permissions prompts.

--

1: https://nono.sh/

That's true, but the leakage component is characteristic of many kinds of breaches and not specific to ransomware. Likewise its defenses are not ransomware-specific.

> If you have a limited budget of tokens as a defender, maybe the best thing to spend them on is not red teaming, but formalizing proofs of your code's security.

You can only do this if you have a very clear sense of what your code should be doing. In most codebases I've ever worked with, frankly, no one has any idea.

Red teaming as an approach always has value, but one important characteristic it has is that you can apply red teaming without demanding any changes at all to your code standards, or engineering culture (and maybe even your development processes).

Most companies are working with a horrific sprawl of code, much of it legacy with little ownership. Red teaming, like buying tools and pushing for high coverage, is an attractive strategy to business leaders because it doesn't require them to tackle the hardest problems (development priorities, expertise, institutional knowledge, talent, retention) that factor into application security.

Formal verification is unfortunately hard in the ways that companies who want to think of security as a simple resource allocation problem most likely can't really manage.

I would love to work on projects/with teams that see formal verification as part of their overall correctness and security strategy. And maybe doing things right can be cheaper in the long run, including in terms of token burn. But I'm not sure this strategy will be applicable all that generally; some teams will never get there.