(probably, I was also looking for that)

Japanese flick input is closer to thumb-key ( https://github.com/dessalines/thumb-key I just discovered in another comment), and even that's a bit different as you get to input a consonant+vowel pair at a time (e.g. ka-ki-ku-ke-ko on a key)

I switch between Japanese input and hacker keyboard all the time for termux and it's much faster to type Japanese; this thread made me want to try both thumb-key and unexpected keyboard but I think I'll try thumb-key first.

https://github.com/not-an-aardvark/lucky-commit and others have shown up to engineer (read: brute-force) these early hash digits

> --I ran ctags across the linux kernel source code, pulled out all the signatures and then reference the signature when compiling the query, so you don't have to do a bunch of casts in the query.

note you don't need the casts if you use kfuncs instead, which also let you reference arguments by name (from https://github.com/bpftrace/bpftrace/blob/master/man/adoc/bp... ):

    kfunc:tcp_connect {
        if (args->sk->__sk_common.skc_daddr == (uint32)pton("127.0.0.1"))
            ...
    }

With that said, kfuncs don't work (yet?) on aarch64, so this is great for me -- I'll definitely give it a try next time I need it.

(EDIT: formatting)

oh sick! thank you for letting me know. I will look into using this more for sure. I am curious, do you know if there is a way to access the arguments for kfuncs ahead of time? does the kernel provide this information somehow at runtime, or is it all still implicit?

Also, you might also enjoy https://github.com/zmaril/hancock which is some of the code I've been using to run ctags across the versions of the kernel.

(edit: I checked bpftrace -l and saw that it does have the arguments and type structs ahead of time, which is absolutely perfect, thank you very much! Super helpful.)

Try this:

    bpftrace -lv kfunc:*

(or any specific function instead of wildcard) will get you all kfuncs and their respective arguments.

output snippet:

    kfunc:vmlinux:tcp_conn_request
        struct request_sock_ops * rsk_ops
        const struct tcp_request_sock_ops * af_ops
        struct sock * sk
        struct sk_buff * skb
        int retval
    kfunc:vmlinux:tcp_connect
        struct sock * sk
        int retval
    kfunc:vmlinux:tcp_create_openreq_child
        const struct sock * sk
        struct request_sock * req
        struct sk_buff * skb
        struct sock * retval

I'm not sure how to get this info without bpftrace itself - bpftool might have the info available somehow?

That’s awesome! Very helpful, thank you. I had been holding off on parsing that output and combining it with vmlinux.h, but that just jumped up way higher priority. Thanks again!

infinitely easier to read with https://threadreaderapp.com/thread/1825472703223992323

I don't know what that scrolly thing is, but it's horrible for this kind of messages.

It'd be even better if it didn't start on X in the first place, but at this point it's a lost battle...

I'm really surprised ijl got angry that his mail was quoted, it looks innocent enough to me.

For reference it's been edited out here: https://github.com/pydantic/pydantic/issues/589

But github shows edits, so the edit is meaningless for privacy. Here's the original mail (yes, I'm blatantly ignoring his request to not publish this, I'm just this evil.)

    I've looked into replacing ujson in pydantic with orjson
    (https://github.com/ijl/orjson). In this implementation, the same JSON
    library is used for everything, and JSON outputs bytes without
    whitespace (as it's faster and JSON is a serialization format). If
    orjson is installed, it won't affect pydantic's benchmark for
    validation, but can be expected to improve whole-program performance.

    It's a large change with breaking changes to JSON methods, however, so
    rather than opening a pull request now, could you take a look and see if
    that's consistent and acceptable to the project?

    https://github.com/ijl/pydantic/commit/7c08f41edd340614d7c58888f025665dbc71d0e3

    That passes tests, but that's all. I'll clean it up or modify if the
    idea's acceptable.

    Thanks.

I've had people get angry at me for "quoting emails", even when it's small quotes from completely innocent non-private stuff like this. I guess it's a matter of principle for some shrug

took me some time to find where it's described, but "LibertOS" is yet another degoogled android: https://unplugged.com/blogs/news/the-unplugged-phone-inside-...

Doesn't say what it's based on (lineage or AOSP or something else)

> how do we actually know that that pull request has gone through all the checks

gerrit flags all reviews and checks into git notes, which can be downloaded and displayed with a little bit of configuration: https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo...

This doesn't prevent an admin from cheating and editing the notes manually, but it's a good audit trail if you trust the "forge".

> This doesn't prevent an admin from cheating and editing the notes manually, but it's a good audit trail if you trust the "forge".

If one of the values of Git as a DVCS is that you don't need to trust the forge, this seems like it removes one of the core features of git to me.

People trust the forge all the time; if someone wants to mess with github (say, feed a different repo for everyone except developers using whatever it is they usually interact with the git with (ssh or their IP or whatever), it'd take a while to notice -- if they do that for existing releases archives distros might notice but for a new tag? I'll bet no-one sees it)

From a pure git perspective, notes are normal objects so if everyone fetches the notes regularly they'll notice if they're tempered with just like regular commits iirc. I think you can add notes after the fact but not modify what's there?