exyi

You know that prompt injection is a thing, right? Giving opencode access to bash and malicious input is not very far from piping it right into bash.

Exactly. Although if you do >> 8 while working with uint8, it will be the fastest :)

It's 3 cycles for float multiplication (and 1 for shift right):

https://uops.info/table.html?search=mulss&cb_lat=on&cb_tp=on...

https://uops.info/table.html?search=shr&cb_lat=on&cb_tp=on&c...

In throughput it's even less of a difference: 2 per cycle vs 3 per cycle.

Then you also have to auto-update the containers, if it's a public facing service. Either you'll have to build containers yourself or hope the developer pushes a new update whenever the base image has relevant security fixes.

VSCode extensions often contain binary blobs, so it won't catch basically anything. It would also be a bit expensive.

At least my password won't leak as often with yubikey, but the attacker can still hack my shell to execute fake sudo. Even if I type /bin/sudo explicitly, there is ptrace, LD_PRELOAD or just replacing the entire bash binary.

In practice yubikey sudo keeps you much safer today, as almost nobody uses it and malware won't be prepared for it

Ok, so the malware runs a keylogger / clipboard logger, gets the password and runs sudo on it's own. Or replaces your shell by putting exec ~/hackedbash into your bashrc

Password on sudo is only useful if you detect the infection before you run sudo

Whitelisting also quite likely doesn't work ("of course I will allow my agent to run find, that can do no harm")

Same tool is very handy if you hypothetically wanted to control spread of anything else, like anti ice apps for instance.

Also hash matching is so easily bypassed you can be sure they really want to add some "AI" detector as well

and cross-platform UI

Do you know if there is override this specifically when I want to install a security patch? UV just claims that package doesn't exist if I ask for new version

Except that LiteLLM probably got pwned because they used Trivy in CI. If Trivy ran in a proper sandbox, the compromised job could not publish a compromised package.

(Yes, they should better configure which CI job has which permissions, but this should be the default or it won't always happen)

If you change this you break a common optimization:

https://github.com/python/cpython/blob/3.14/Lib/json/encoder...

Default value is evaluated once, and accessing parameter is much cheaper than global

Every sane approach to security relies on checking you are doing permitted actions on the server, not locking down the client.

Python does not need that, as it has built-in type annotation support. The annotation is any expression, so you can in theory express anything a custom type-only language would allow you (although you could make it less verbose and easier to read).

However, the it IMHO just works much worse than TS because: * many libraries still lack decent annotations * other libraries are impossible to type because of too much dynamic stuff * Python semantics are multiple orders of magnitude more complex than JavaScript. Even just the simplest question: Is `1` allowed in parameter typed `float`? What about numpy float64?

... or they teached GPT to use em-dashes, because of their love for em-dashes :)

Ok, run the same prompt on a legitimate bug report. The LLM will pretty much always agree with you

Local would imply the date is in the current machine timezone, while PlainDateTime is zoneless. It may be in the server timezone, or anything else. The main difference is that it does not make sense to convert it to Instant or ZonedDateTime without specifying the timezone or offset

Only until you work with a type array (Int32Array, Float64Array, etc), then it becomes 10x slower: https://jsperf.app/doyeka/11

Usually yes, but it's still a neat trick to be aware of. For interpreted scripting languages, parsing can actually be a significant slowdown. Even more so when we start going into text-based network protocols, which also need a parser (is CSS a programming language or a network protocol? :) )

The point is that a good library usually exists for some language, which is not necessarily the one you are currently using.

IMHO, we don't lack good libraries in XY, we are lacking good interop. Going through REST or stdio is quite painful just to render PDF (or export spreadsheet, ...)

C# portable SIMD is very nice indeed, but it's also not usable without unsafety. On the other hand, Rust compiler (LLVM) has a fairly competent autovectorizer, so you may be able to simply write loops the right way instead of the fancy API.

The protocol must support it somehow already, as some bridges can send custom emojis from other platforms

Everyone I know of will try to click "reject all unnecessary cookies", and you don't need the dialog for the necessary ones. You can therefore simply remove the dialog and the tracking, simplifying your code and improving your users' experience. Can tracking the fraction which misclicks even give some useful data?

I know about netcoredbg, but I did not have much success using it. If we count this as the C# debugger, then the tooling quality is not comparable to other mainstream languages like Scala, D or Julia.

JetBrains have their own closed debugger, which doesn't really help.

Since Rust is native code, you can use pretty much any debugger for it, there is definitely not a single implementation. Yes, Rust has a single compiler, but does C# have any other compiler than Microsoft's Roslyn? (I don't think this is a problem, though)

Kotlin did not have open LSP, C# still does not have an open debugger.

The C# VSCode extension works in Microsoft's build of VSCode, not when someone else forks it and builds it themselves.

Then you are back to what the article discusses. Each integer is in a separate box, those boxes are allocated in one order, sorting the array by value will shuffle it by address and it will be much slower. I tested this as well, see the other comment.

I guess it depends on how deep you want to go, I think the real predictors are based on publicly known algorithms such as TAGE. This seems to be nice overview: https://comparch.net/2013/06/30/why-tage-is-the-best/ (it's 2013, so definitely not SOTA, but advanced enough for my taste :) )

I don't know how large are those boxes, but normal CPU L1 cache has 32 or 48KB which should be plenty for this. Python opcodes for this program are going to be tiny, and the interpreter itself uses the instruction-L1 cache (which is another 32-48KB). I hope the sequential scan of the big array won't flush the L1 cache (there should be 12-way associativity with LRU, so I don't see how it could).

Anyway, there is no need to have 256 integers, just 2 is enough. When I try that, the results are similar: 17.5 ms (unsorted) / 12.5 ms (sorted)

It corresponds to a way more than one branch at instruction level. The branch prediction AFAIK does not care based on what are you branching, it just assumes branches will go in similar sequences as they did last time. If the Python 'if' is never taken, the instruction-level predictor will learn that after the comparison operation, there is an 'if' operation and then another array access operation. If the Python 'if' is unpredictable unpredictable, CPU predictor can't be sure which opcode are we processing after 'if', so there will be penalty.