jsmith45

This is the spitting image of old pre-CRM thinking:

If I try to force the captain to go around, (or follow procedures or whatever), then i am exceeding my authority and will probably be fired. Some cultures have this sort of mentality a lot stronger than others, and it has zero place in the modern cockpit.

While a captain can pull rank, they really should only ever do it with respect to the first officer if: an inexperienced first officer is trying to insist on something dangerous or forbidden by law or policy, or if the captain fully understands an FO's concerns, is fully accounting for them, and as the person ultimately responsible for safety, has determined from experience and training that the current action is safer than alternatives, and would explain but cannot explain right now for workload/emergency status reasons.

That's it, the only two reasons.

Yeah, my bigger worry here is more about if somebody direct edits a file in their venv and uv was unable to make the venv with reflink/COW semantics and fell back to hardlinks.

This could happen with a user asking their editor to show definition, and then not realizing the result was in some other package, changing it, and saving it, but only if the editor's normal atomic replace mode is disabled. So perhaps that sounds farfetched. But if an AI agent wants to patch some package in a venv, I've seen them bypass the editor and use command line tools to make edits often enough to be concerned. Like corrupting the cache for one package version is already not ideal, and this could potentially affect multiple versions now?

I suppose is this happens the right fix is to nuke the cache completely?

You wouldn't.

But keep in mind that there are multiple kinds of exceptions.

Some exceptions, indicate scenarios the caller could reasonably have avoided. This include things like argument bound or null checks. A caller absolutely could avoid these exceptions by doing its own checks. This can be split between checks that the caller really should have done, like not passing null to a function that cannot take null, vs those where baking the relevant knowledge into the caller would be undesirable (perhaps because future versions of the library expect to accept more values).

There are exceptions that in theory a caller could avoid, but in practice it is impractical, like an exception thrown by a parser of some complex format if the provided input isn't legal. The only good way to avoid such an exception is to have a non-throwing parser that you can check with, but you probably don't want to parse twice. An alternative interface for the parser might be able to totally avoid the exception, returning either succeeded (with result tree) or fail with error message, but that would be a design choice of the implementor, not the caller.

There can be exceptions that indicate a logic bug in the impleentation (things like throwing if some invariant the implementation is in charge of is violated), but more often this is assertions instead.

Lastly, you have exceptions that there is no possible way the caller could always avoid. IO exceptions are among these. While you can sometimes do existence, space, or permission checks or similar to reduce the probability of getting certain exceptions, something else could race your app between the check and performing IO, and make them happen anyway.

The primary target for contracts are exceptions that callers both could and should have avoided, and the exception/assertion case that is trying to verify the implementation is working as expected.

The other categories of exceptions are more or less totally out of scope.

To be clear, they are billing for all the coded line items at the listed prices, it is just that the agreements with the insurance company will disallow many of the line items in favor of other ones. They bill everything, because they may accept some insurance that has not negotiated a day rate, and in that case, the day rate code would be disallowed and some of the other line items will be paid at relevant negotiated rates instead (with others still likely disallowed). It needs to be the same bill in both cases, so they need to include everything, and the list prices need to be greater than or equal to what any insurance would pay, or they might lose out on the difference.

This is one of the areas where more standardization would certainly help. If there were more standardization of which codes disallow which other ones (which can currently vary wildly by plan even with the same insurer, must less across insurers), then a lot of line items could actually get removed as truly redundant, vastly simplifying the bill.

I have successfully had am M1 MacBook open and in active use (albeit not with very heavy workload, mostly text editor and web), while plugged into a Nintendo Switch 1 charger (only thing I had handy at that moment), and was watching the battery percentage slowly increasing over time. So even laptops can sometimes charge slowly while in use with a rather underpowered type C charger (Albeit still slightly better than a cheapo 5V 3A Type-C phone charger).

The original design intention of this approach was that wallet apps were independant and interchangable, with any wallet app able to talk to any attestation provider, to get age attestation tokens, and any site/app able to talk to any wallet. The wallet's job was merely to securely hold a bunch of attestations tokens, and dispense them to other sites/apps on request.

So you could use an open source app, or government provided one, or one provided by your bank, whatever you trust the most to not be recording data about relying parties and sending it somewhere you don't want.

The version of the document currently on GitHub has heavily deviated from that original intention. This is very unfortunate.

Even so this version is supposed to still be incapable by design of sharing any data with a relying party other than "over 18" and was designed such that the only way for a relying party to determine your identity is to be colluding with the attestation provider, or by colluding with the wallet app.

To attempt to address the first issue they have the unfortunately optional ZKP protocol. The original design assumed that users could find a wallet that they were certain would not collude with the RPs, and was considered a non-issue, but unfortunately it is a huge hole in the current version.

The PLC keys are normally intended to be held by your current PDS. Not a hard protocol requirement, but without it, certain things like migrating to a custom domain handle cannot be done cleanly though the app, and would need to be done manually. It might be a requirement of the bluesky hosted PDSes though, as those have some extra requirements beyond the reference self-hosted PDS.

The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.

If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process.

See https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.

Yeah, an agent should run with permissions no greater than that of the user on whose behalf it is executing, and ideally with less permissions. This is the scenario that is easier to fix, simply give the agent an API token with rights no greater than the user it is acting on behalf of. This could be a literal token for their account, or a limit-rights-to field or whatever, multiple possible approaches.

The harder problem is outside actors trying to prompt inject to get the agent to do something the user has rights to do but which the user doesn't want to happen. That is the hard scenario to fix, due to the nature of LLMs.

Yep.

Thrashing is a well known known issue that can occur with swap, but it can also happen from page cache or memory mapped files. Indeed not having swap enabled can make things worse, as private pages that haven't been used in a hours cannot be swapped out to keep the important files cached or memory mapped.

Realistically for measuring physical memory sufficiency, you care about memory/data of any type (even files) that will be used in use upcoming time period, and ensuring that a sufficient percentage of it can be held in physical memory to avoid thrashing.

This is hard! Technically impossible to know for the general case (halting problem), and all methods of trying to approximate it involves trade-offs.

In theory, sure, an identity verifier could issue you you a bunch of single use JWTs signed by them that contain `{"over18":"true", "nonce": 12748583..., "iss": "<issuerurl>"}`, signed by their key. A relying party just needs to know the public keys of all the issuers they trust, and can consume this JWT, verify it, and never learn anything about your IRL identity.

The important things are that they must issue a bunch at once. (Otherwise, correlating who you are becomes easy). They must keep no record tying nonce or the full JWT to an individual identity. Something user local or otherwise trustworthy (not keeping logs), needs to hold on to these, and send them out as needed, being very very careful never to reuse one (as that would enable cross site tracking). Lastly a relying party must be required to trust many issuers, not just those they are colluding with track users across sites with this.

The European Commission actually proposed pretty much exactly this system, also with a variation where instead of revealing the signed token, a ZSNARK proof (that you possess a validly signed token with the over18 attribute from a specific issuer) could be given to the relying party instead (to make it impossible for issuer and relying party to collude to release your identity). Many people here seemed to not like it.

I'd argue they are not commutive in regexes either, at least as implemented in practice. Implemented regexes favor the leftmost alternative even when both sides of the alternative match. This matters in cases like: capturing groups, and backtracking implementations. There absolutely are cases where one ordering of alternatives could yield catastrophic backtracking for some input, while the other will avoid it completely.

I personally don't like this at all. This means that regex engines that try to generate optimized matching code for an expression can end up generating suboptimal code if you don't want alternative order to matter, since the engine needs to keep that invariant, except in the case when it can prove that the alternatives won't overlap, and a later one can be checked in constant time. If both are true, it is legal to reorder them to do the constant time check before the big complicated wildcard-filled alternative.

But personally, I have never written a regex where I actively cared about the alternative evaluation order. I've used some other people made where order is important but never written one myself.

I'd love to be able to tell the engine "feel free to swap the evaluation order of my alternatives while optimizing", but few if any such engines offer that as a feature.

Now I get that PEGs have commutivity problems are that are different from regexes', which make the issue worse, but that doesn't mean regexes do things right either.

If the compiler can find any operation prior to the null check that would be UB if the value is null (even if it is something that in assembly would be harmless, like performing pointer arithmetic on it), the compiler is allowed to assume the pointer is not null, and thus omit the null check. This could then lead to something that will in practice cause problems like dereferencing the pointer.

Compilers keep taking more and more advantage of inferring that a values in variables cannot be `x`, because if it were than some previous usage would have been UB. When people file bugs to complain, the compiler authors point at the spec which allows them to assume that UB behavior never happens, so the compiler behavior is legal. The only counterargument is if the compiler has chosen to document some specific behavior for this UB (possibly only with specific flags enabled) in which case the compiler testing that scenario as proof of impossibility is indeed a bug (when the required flags are set).

A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.

The "custom os" part could also be done easilly enough with the correct approach.

Specifically systemd has a less-known feature known as system extensions intended for basically exactly these sort of scenarios. These system-extensions are basically disk images containing files in /usr and/or /opt that can be dynamically overlaid on the existing filesystem (the intent is that these are purely additive). Systemd also intends that all os provided configuration live in /usr, with /etc existing only for machine specific or admin applied configuration. (And which should enabling overriding anything specified by the package or OS.)

System extensions when used default /opt and /usr to be read-only, but you can enable mutability if you having write routing directories or symlinks in the right spot.

So for userland this whole os profiles things could literally just be a set a of system-extensions, a distinct /etc folder, and distinct set of write redirect directories for each. An initramfs can simply bind mount the /etc directory, and add the correct write redirection symlnks before systemd starts. Rolling back a profile is simply wiping its write redirection and /etc folders. If you also want each to potentially have distinct device trees and/or customized kernels, that would need additional bootloader work on top, but nothing that feels too extreme.

Now in reality, since not everything support systemd style configuration, these OS profiles would probably need to construct an initial /etc by copying files from a base-os template, and then copying in anything included in the system extension images (which can have these as systemd will ignore such folders), but that is straightforward enough.

I must be missing something, since I'm not really sure that follows. Initially neither AV nor AR models knows anything about how activations map to explanations or how explanations map to activations.

As far as I can tell, the only reason that the explanations even resemble human speech is that AV and AR start off based on a trained language model. If we instead trained the same model architecture from scratch as AV and AR, they would eventually converge to some round trip format for activations, but it probably would be completely unintelligible and look only like human speech in so far as many of the tokenizer's tokens look like words or word fragments.

This whole process seems to rely on the fact that the text AR's output will still strongly favor output sentences that seem to make sense, rather than contradicting learned facts, etc. So it will favor mapping activations to plausible sounding text in ways where patterns can consistently hold across most of the training data. There absolutely is a risk that it will learn the wrong things for certain activation subpatterns like swapping concepts especially if none of the training data included a set of activation sub patterns that would help distinguish them the right way around.

Yeah, as far as I know, you need to define a customized theme to customize pie chart colors. You can prepend the chart with initialization logic like:

%%{init: {"theme": "base", "themeVariables": { "pie1": "#FF5733", "pie2": "#33FF57", "pie3": "#3357FF", "pieStrokeColor": "#000000", "pieStrokeWidth": 3, "pieOpacity": 0.8 }}}%%

This looks like it works on this site too.

> I think many people already mentioned it, but I also don't feel to good about non-boxed unions not being the default. I'd personally like the path of least resistance to lead to not boxing. Having to opt-in like the current preview shows it looks like a PITA that I'd quickly become tired of.

The problem is that the only safe way for the compiler to generate non-boxed unions would require non-overlapping fields for most value types.

Specifically the CLR has a hard rule that it must know with certainty where all managed pointers are at all times, so that the GC can update them if it moves the referenced object. This means you can only overlap value types if the locations of all managed pointers line up perfectly. So sure, you can safely overlap "unmanaged" structs (those that recursively don't contain any managed pointers), but even for those, you need to know the size of the largest one.

The big problem with the compiler doing any attempt to overlap value types is that if the value types as defined at compile time may not match the definitions at runtime, especially for types defined in another assembly. A new library version can add more fields. This may mean one unmanaged struct has become too big to fit in the field, or that two types that were previously overlap compatible are not anymore.

Making the C# compiler jump though a bunch of hoops to try to determine if overlapping is safe and even then leaving room for an updated library at runtime to crash the whole things means that the compiler will probably never even try. I guess the primitive numeric types could be special cased, as their size is known and will never change.

Cost tracking is used if you connect claude code with an api key instead of a subscription. It powers the /cost command.

It is tricky to meaningfully expose a dollar cost equivlent value for subscribers in a way that won't confuse users into thinking that they will get a bill that includes that amount. This is especially true if you have overages enabled, since in a session that used overages it was likely partially covered by the plan (and thus zero-rated) with the rest at api prices, and the client can't really know the breakdown.

Right. Claude models seem to have had very limited prohibitions in this area baked in via RLHF. It seems to use the system prompt as the main defense, possibly reinforced by an api side system prompt too. But it is very clear that they want to allow things like malware analysis (which includes reverse-engineering), so any server-side limitations will be designed to allow these things too.

The relevant client side system prompt is:

IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases.

----

There is also this system reminder that shows upon using the read tool:

<system-reminder> Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior. </system-reminder>

The file locking approach is one used by centralized version control systems, and are mostly used in the everybody commits directly to trunk style of development. In those environments merging isn't much of a thing. (Of course this style also comes with other challenges, especially around code review, as it means either people are constantly commit unreviewed code, or you develop some other system to pre-review code, which can slow down the speed of checking things in.)

This approach is actually fairly desirable for assets types that cannot be easily merged, like images, sounds, videos, etc. You seldom actually want multiple people working on any one file of those at the same time, as one or the other of their work will either be wasted or have to be re-done.

Sure but the real concern of the article that if passed "gid://moneymaker/Invoice/22ecb3fd-5e25-462c-ad2b-cafed9435d16" the global id locator will effectively locate "gid://moneymaker/Invoice/22". Which is to say, that what is supposed to be a system-generated id which has no need for de-slugification, uses the same lookup method as is normally used for URLs which attempts to de-slugify.

Obviously, this means that first gid was bogus anyway, as it was trying to look up via the wrong key, but the fact that it doesn't fail, and will instead return the record with primary key "22" can certainly be surprising.

Chrome desktop has just landed enabled by default native HLS support for the video element within the last month. (There may be a few issues still to be worked out, and I don't know what the rollout status is, but certainly by year end it will just work). Presumably most downstream chromium derivatives will pick this support up soon.

My understanding is that Chrome for Android has supported it for some time by way of delegating to android's native media support which included HLS.

Desktop and mobile Safari has had it enabled for a long time, and thus so has Chrome for iOS.

So this should eventually help things.

Chrome has finally just landed enabled by default native HLS playback support within the past month. See http://crrev.com/c/7047405

I'm not sure what the rollout status actually is at the moment.

> COM is just 3 predefined calls in the virtual table.

COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc.

I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class.

This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.

BBFC's rulings have legal impact, and they can refuse classification making the film illegal show or sell in the UK.

over in the US, getting an MPAA rating is completely voluntary. MPAA rules do not allow it to refuse to rate a motion picture, and even if they did, the consequences would be the same as choosing not to get a rating.

If you don't get a rating in the US, some theatres and retailers may decline to show/sell your film, but you can always do direct sales, and/or set up private showings.

Yeah, proving correct is not a panacea. If you have C code that has been proven correct with respect to what the C Standard mandates (and some specific values of implementation defined limits), that is all well and good.

But where is the proof that your compiler will compile the code correctly with respect to the C standard and your target instruction set specification? How about the proof of correctness of your C library with respect to both of those, and the documented requirements of your kernel? Where is the proof that the kernel handles all programs that meet it documented requirements correctly?

Not to point too fine a point on it, but: where is the proof that your processor actually implements the ISA correctly (either as documented, or as intended, given that typos in the ISA documentation are that THAT rare)? This is very serious question! There have been a bunch of times that processors have failed to implement the ISA spec is very bad and noticeable ways. RDRAND has been found to be badly broken many times now. There was the Intel Skylake/Kaby Lake Hyper-Threading Bug that needed microcode fixes. And these are just some of the issues that got publicized well enough that I noticed them. Probably many others that I never even heard about.

I'm confused by your perspective.

The simplest (and arguably best) usage for a devcontainer is simply to set up a working development environment (i.e. to have the correct version of the compiler, linter, formatters, headers, static libraries, etc installed). Yes, you can do this via non-integrated container builds, but then you usually need to have your editor connect to such a container, so the language server can access all of that, plus when doing this manually you need to handle mapping in your source code.

Now, you probably want to have your main Dockerfile set up most of the same stuff for its build stage, although normally you want the output stage to only have the runtime stuff. For interpreted languages the output stage is usually similar to the "build" stage, but out to omit linters or other pure development time tooling.

If you want to avoid the overlap between your devcontainer and your main Dockerfile's build stage? Good idea! Just specify a stage in your main Dockerfile where you have all development time tooling installed, but which comes before you copy your code in. Then in your .devcontainer.json file, set the `build.dockerfile` property to point at your Dockerfile, and the `build.target` to specify that target stage. (If you need some customizations only for dev container, your docker file can have a tiny otherwise unused stage that derives from the previous one, with just those changes.)

Under this approach, the devcontainer is supposed to be suitable for basic development tasks (e.g. compiling, linting, running automated tests that don't need external services.), and any other non-containerized testing you would otherwise do. For your containerized testing, you want the `ghcr.io/devcontainers/features/docker-outside-of-docker:1` feature added, at which point you can just use just run `docker compose` from the editor terminal, exactly like you would if not using dev containers at all.

Might be worth checking out Tidal's Mondo Notation, which while not quite Haskell syntax is far closer to it, being a proper functional style notion, that unifies with mini notation, so no need for wrapping many things in strings.

Looks like this:

    mondo`
    $ note (c2 # euclid <3 6 3> <8 16>) # *2 
    # s "sine" # add (note [0 <12 24>]*2)
    # dec(sine # range .2 2) 
    # room .5
    # lpf (sine/3 # range 120 400)
    # lpenv (rand # range .5 4)
    # lpq (perlin # range 5 12 # \* 2)
    # dist 1 # fm 4 # fmh 5.01 # fmdecay <.1 .2>
    # postgain .6 # delay .1 # clip 5

    $ s [bd bd bd bd] # bank tr909 # clip .5
    # ply <1 [1 [2 4]]>

    $ s oh*4 # press # bank tr909 # speed.8
    # dec (<.02 .05>*2 # add (saw/8 # range 0 1)) # color "red"
    `

If actual tidal notation is important, that has been worked on, and would look like:

    await initTidal()
    tidal`
    d1 
    $ sub (note "12 0")
    $ sometimes (|+ note "12")
    $ jux rev $ voicing $ n "<0 5 4 2 3(3,8)/2>*8"
    # chord "<Dm Dm7 Dm9 Dm11>"
    # dec 0.5 # delay 0.5 # room 0.5 # vib "4:.25"
    # crush 8 # s "sawtooth" # lpf 800 # lpd 0.1
    # dist 1

    d2 
    $ s "RolandTR909_bd*4, hh(10,16), oh(-10,16)"
    # clip (range 0.1 0.9 $ fast 5 $ saw)
    # release 0.04 # room 0.5
    `

Only the actually implemented functions, and implemented custom operators are available even when that works, so not all tidal code can necessarily be imported.

But it is currently broken on the REPL site because of https://codeberg.org/uzu/strudel/pulls/1510 and https://codeberg.org/uzu/strudel/issues/1335

Phonics based reading is all about sounding out unknown words. The idea is that the student would understand if somebody else read the text out loud, so if we can teach the kids how to convert the written words into sounds, they can understand many new words they first come across. The core idea is to teach the kids that certain letters or groups of letters map to certain sounds (phonemes) at a start, and then gradually introduce more and more rules of English phonetics, allowing students to successfully learn to sound out even more complicated words.

The hope is that students will gradually learn to just recognize words by sight, which the overwhelming majority do eventually learn to do, and just need to sound out unfamiliar words. The fact that some students have struggled to learn to recognize words and need to sound most out is part of why people try to create alternatives, but those largely don't work well.

Of course, English does have some tricky phonetics. We have some words with multiple different pronunciations. We have some words with the same phonemes but different meanings that differ solely based on syllable stress. There are even some words whose pronunciation simply must be memorized, as there is no coherent rule to get from the word to the pronunciation (see for example Colonel).

My view, which I suspect even Toub would agree with is that if being allocation free or even just extremely low allocation is critical to you, then go ahead and use structure and stackalloc, etc that guarentee no allocations.

It is far more guarenteed that that will work in all circumstances than these JIT optimizations, which could have some edge cases where they won't function as expected. If stopwatch allocations were a major concern (as opposed to just feeling like a possible perf bottleneck) then a modern ValueStopwatch struct that consists of two longs (accumulatedDuration, and startTimestamp, which if non-zero means the watch is running) plus calling into the stopwatch static methods is still simple and unambiguous.

But in cases where being low/no allocation is less critical, but your are still concerned about the impacts of the allocations, then these sort of optimizations certainly do help. Plus they even help when you don't really care about allocations, just raw perf, since the optimizations improve raw performance too.

I can get by with a weakly typed language for a small program I maintain myself, but if I am making something like a library, lack of type checking can be a huge problem.

In something like JavaScript, I might write a function or class or whatever with the full expectation that some parameter is a string. However, if I don't check the runtime type, and throw if it is unexpected, then it is very easy for me to write this function in a way where it currently technically might work with some other datatype. Publish this, and some random user will likely notice this and that using that function with an unintended datatype.

Later on I make some change that relies on the parameter being a string (which is how I always imagined it), and publish, and boom, I broke a user of the software, and my intended bugfix or minor point release was really a semver breaking change, and I should have incremented the major version.

I'd bet big money that many JavaScript libraries that are not fanatical about runtime checking all parameters end up making accidental breaking changes like that, but with something like typescript, this simply won't happen, as passing parameters incompatible with my declared types, although technically possible, is obviously unsupported, and may break at any time.