fweimer

The TUI version of Claude Code just isn't very good, though. The default keybindings do not work in the majority of terminals (because they generate the same byte sequences for key sequences assigned to different commands). Editing large prompts is rather painful because there doesn't seem to be in-prompt search commands. There is no source code browser, so source code references cannot checked by the users without a separate tool. Diffs cannot be copied directly because they are indented by spaces (even though some tools strip indentation from patches, it's still ugly). Switching between conversations is somewhat discouraged by the interface, which makes it harder to keep the context clean.

I think it's possible to have a better TUI, with something that isn't modeled after a shell prompt. Apparently, recent updates move in that direction. The GUI version of Claude Code seems to be coming to Linux, too.

These builtins of course exist, it's how compilers keep track of the behavior of these functions.

For GCC, there is -minline-all-stringops:

https://gcc.gnu.org/onlinedocs/gcc-16.2.0/gcc/x86-Options.ht...

It does what it says, but the results may not be what you expect.

Cases are infrequent, but not extremely unlikely. There's even a term for it, airport malaria:

https://www.eurosurveillance.org/content/10.2807/1560-7917.E...

Are you sure this is actually makes a difference in your build?

Mine doesn't have the SB-INTERPRETER package, so I doubt binding the variable has an effect.

Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.

But 2 isn't a list, and the argument to unqoute-splicing must be a list:

> If an (unquote-splicing <expression> ...) form appears inside a <qq template>, then the <expression>s must evaluate to lists; the opening and closing parentheses of the lists are then “stripped away” and the elements of the lists are inserted in place of the unquote-splicing form.

Isn't at least one of them undefined? `(1 ,@2)

It's always surprising to me how many things Scheme leaves undefined. Other examples are evaluation order (in some rather surprising places) or the value of: (make-bytevector 4)

I wonder what the intent is behind releasing the weights under a CC-BY-NC license. Is it about restricting any commercial use of the weights, including for inference?

Not in typical builds of SBCL: all code is compiled before evaluation.

I think we'd need something different to make that a reality today. It's likely that decentralized compute eventually wins out here as well. It usually does. But without architectural changes, it will take a couple of years before the current single-conversation flow is truly usable on consumer-grade hardware.

Centralized inference can easily increase batch size, leading to huge efficiency gains in the usual scenario where most users have just one or very few session. Using local resources efficiently requires some way to increase the batch size. I'm not sure if we are there yet.

This is the relevant law: https://www.buzer.de/8_TDDDG.htm (It used to be §90 TKG.)

It's specifically about bug-like devices which transmit the recording. A typical consumer camera does not provide simultaneous uploading, I think. A device that is just recording for storage is not regulated this way.

The law has been applied to baby monitors disguised as toys, which makes some sense to me. Smart watches and phones where the microphone can be controlled remotely, with that capability being marketed specifically for monitoring purposes, have also been targeted.

There are far more cases. Some ABIs use callee-saved registers for parameter-passing under certain circumstances, for example. Usually, there are compatibility restrictions on the signatures of the current and tail-called functions beyond the return type, too.

This is different from Scheme or the MLs (there as a quality-of-implementation feature) where tail calls into arbitrary functions are expected not to lead to space leaks.

It's not really about a monorepo, but how many changes you can have in flight in parallel. Desirability of merge-and-rebase-and-check depends on more factors: the rate of change, the number of developers, the time the pre-merge checks take and the reliability of those checks, and how often pre-merge checks fail (legitimately or otherwise). How conflict-prone queue changes are matters, too.

I would like to have something like this for one of the repositories I work on, which is pretty far away from being a monorepo (it's mainly producing two tightly interlinked binary objects). Fortunately, I believe Gitlab offers something like it, at least as a preview feature (under the namemerge-and-rebase or something like that).

> interfaces still can’t declare type-parameterized methods

What would an implementation look like? Wouldn't it be quite different from the existing one because it has to rely heavily on indirection because (limited) monomorphimization is not possible?

I can see it happening if people start depending AI-generated proof libraries for the work they are interested in. Not because the libraries are proprietary, but because they are impenetrable. AI usage wouldn't result in this directly, but it could be a consequence of formal verification as a substitute for canonicalization in some cases.

(Disclaimer: I had quite a bit of formal training in mathematics at one point, but have worked in software for more than two decades now. I wasn't on the applied side, but I recall that MATLAB evoked similar concerns back in the day.)

I remember enhancing the F-PC visual editor to display the checksum for the current line because I did not have access to whatever method the magazine recommended (maybe OCR with Logitech Scanman?).

Recent glibc uses the correctly rounded tanh from CORE-MATH, so it returns different values than what's quoted in the article. It's unclear today if it's possible to achieve reasonable performance for other transcendental functions with correct rounding, so other functions have their own unique fingerprints.

There's Naïve Bayes (although it's sometimes labeled in more explicit terms).

The problem with “unconventional” is that these works are anything but. As far as I can tell, the most of the paintings presented on the site follows a particular style. I don't think someone who is inspired to paint after watching the Joy of Painting would necessarily end up with something like this, so it's not just about being amateurish. It's also quite likely that some of the painters are anything but self-taught and have chosen to paint in this particular way.

It's still bad for emergency services if everyone does it on the same day.

We have plenty of functions that convert one byte array to another byte array. Both arrays have specified bounds. The functions are total (an error return indicates if the input or output arrays are incomplete). Most of them do not even have state that is preserved between calls. Complete source code is available in the same build for all the functions they call.

In theory, this should be very straightforward to prove correct with many of the current tools. In practice, no one has shown us how to do it. We could even rewrite the code from a macro/#include maze to proper function calls if that's a prerequisite for analysis. At this point, I would even take a one-off analysis.

I still have to see a single glibc bug that truly matters. I don't have illusions about our code quality, so there must be something to find.

We got many high-quality bug reports, some of them with a security aspect to them. Several of them received CVSSv3.1 scores of around 9.8 from the rating agencies, but these high numbers are misleading. (Vulnerability scoring is hard, and it's pretty much impossible for a library without reference to an application that uses the library.) Looking beyond the numbers, everything reported this year (and late in last year) was pretty harmless so far.

Does this mean LLMs are making a difference? For upstream developers, definitely. For end users? Not that much yet.

Maybe the picture changes once the organizations sitting on the good findings figure out how to disclose them to the relevant upstream projects. When I read the announcement of Project Glasswing, I immediately thought that this was going to be the hardest part.

I think it's rather this:

3. People were already sitting on vulnerability reports from their own tools and threw them over the wall.

They were worried about getting scooped. They had to consider Mythos' alleged capabilities as a tool, and Project Glasswing potentially establishing a well-run disclosure and remediation process. Both could devalue preexisting results.

I think the decode phase of inference typically uses local compute resources poorly due to the very small batch size. If you can run many inference tasks in parallel, this will make local inference more competitive to centralized inference, not less.

I think you got it backwards. Wouldn't it be way worse if they used your likeness for advertising to your friends? Compared to random people who don't know you?

Everything we need is already upstream. I think the changes were:

    commit 0690dc39644d15fc89813419ffcdf9754b098260
    Author: Mark Wielaard <mark@klomp.org>
    Date:   Sun Sep 22 23:24:34 2024 +0200
    
        Implement /proc/self/exe readlink[at] fallback in POST handler
        
        Calling the readlink[at] syscall directly from the PRE handler defeats
        the FUSE_COMPATIBLE_MAY_BLOCK (SfMayBlock) flag. Add a POST handler
        that only explicitly calls the readlink[at] handler for the
        /proc/self/exe fallback (this should be fine unless /proc is also
        implemented as fuse in this process).
        
        Adjust readlink[at] GENX_ and LINX_ syswrap macros to GENXY and LINXY.
        
        https://bugs.kde.org/show_bug.cgi?id=493507
    
    commit ddf397c024c80382f7a2f3a0d46d58fb839eef96
    Author: Mark Wielaard <mark@klomp.org>
    Date:   Sat Sep 21 22:27:24 2024 +0200
    
        Add missing FUSE_COMPATIBLE_MAY_BLOCKs
        
        Various syscalls (in particular "at" variants) PRE handlers were
        missing a FUSE_COMPATIBLE_MAY_BLOCK statement.
        
        Add it to the generic PRE handlers of access and statfs64. And the
        linux PRE handlers of mknodat, fchownat, futimesat, utimensat,
        utimensat_time64, renameat, renameat2, readlinkat, fchmodat,
        fchmodat2, faccessat and faccessat2.
        
        https://bugs.kde.org/show_bug.cgi?id=493454

There's an older effort called Typed Assembly Language (TAL) by Greg Morrisett et al. It was a rather ambitious in some ways because it tried to model inter-procedural control flow, including exceptions. They eventually had a solution for array bounds checking, but I haven't seen anything for array initialization (that doesn't depend on a memory allocator that zeros everything or multi-instruction macros with semantics defined by fiat).

Using __builtin_unreachable in this way makes the switch version unsafe, too.

I'm not convinced this is true. Otherwise, it does not bode well for Rust code because any type safety glitch will be considered a vulnerability. This would be really challenging for Rust developers because it goes beyond unsafe Rust code. You can easily have unexpected panics because your types do not enforce invariants as you expect. If a library has such a bug, is this a denial-of-service vulnerability in the library? Rather than dealing in absolutes, I would say that it's impossible to tell in isolation. If applications do not misuse the library in ways that triggers the panic, probably not, and treating this as a vulnerability just results in pointless noise.

Determining the impact of library bugs can be really hard. For example, some functionality might be so broken that it's simply impossible to use correctly, so a buffer overflow on top does not make a difference. Or a buffer overflow vulnerability triggers consistently during system boot, so that you never get to the login prompt. These can hardly be considered vulnerabilities. On the other hand, we have clear buffer management bugs, where we must expect that there is application code out there which specifies tight buffer bounds and requires that the library stays within that buffer. (Rust should help here, at least out-of-bounds accesses should turn into panics.) But most bugs are unfortunately somewhere in the middle. Tools like Debian Code Search can provide some evidence. But in the end, it's more subjective than I'd like it to be.

On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.

I really think we need some corrective factor (such as potential implication impact) when determining whether toolchain bugs are vulnerabilities.

The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, for a test that exercises the O_CREAT|O_EXCL failure path. Like the Rust fuser crate, it uses the kernel API directly. The tests are slightly brittle because sometimes we encounter a new LSM that triggers unexpected file system operations, but it's not too bad overall.

What I found funny when I discovered it is that you can create a thread in the same process that provides the FUSE file system implementation for this very process. It makes it much easier to write certain tests, especially debugging. We had to teach valgrind that more system calls effectively perform callbacks into the same process, but fortunately valgrind already had a FUSE_COMPATIBLE_MAY_BLOCK mechanism for that.