> I’m also not sure the ‘fuzzy’ aspects of Atuin quite match the heights of fzf/skim).

This. I've been using atuin for a few months and this is so horrible how much better it could be with a "real" fzf matching... I just tried skim shell integration ( https://github.com/skim-rs/skim/tree/master/shell ) and it's great. I kind of like the extra metadata atuin saves (cwd, session context), but I think I was just waiting to stumble into this to turn atuin back off...

You can have the best of both worlds - use atuin and fzf.

I use fish shell, so you'll have to forgive any fishisms.

First, when you start atuin, don't bind to ctrl-r, instead manually bind it to something else. I use ctrl-t. This brings up the "standard" atuin interface which you can use to get the more detailed history - in particular the command inspector can be super helpful as is the ability to limit scope of history searches.

Next, bind ctrl-r to something like this: `commandline -r (atuin history list --print0 -f "{time} | {command}" | fzf --read0 --delimiter="|" --accept-nth 2 | sed 's/^ *//')`

In fish-speak, that's saying replace the command line with a command that fzf selects from your atuin history (which has been pretty printed to show the time of the command, but that won't end up on the command line).

Probably 95% of the time I'm using my new ctrl-r which searches atuin history using fzf. The other 5% of the time I'm looking for a command that I know I've ran in a particular directory, or using the atuin history to remove problematic entries from my history.

I've considered this, but I'm running on a potato, and fetching the whole atuin history seems to take a while:

    $ time atuin history list --print0 -f "{time} | {command}" > /dev/null
    
    real 0m1.849s

(for some reason the built-in atuin search command doesn't take so long to show up? It might only fetch the last few entries from the db first... Eh, actually `atuin search` without argument which lists roughly the same thing run in less than half the time (0.85s), but -i is still another order of magnitude faster)

Anyway, thanks - I'll fiddle with all this :)

...i just use both atuin and fzf.fish [1] and bind them both to another key.

[1] https://github.com/PatrickF1/fzf.fish/

Unlocking the bootloader by itself is allowed apparently: https://www.daylighthacker.wiki/unlock

The problem is that in order to run linux you'll probably want a kernel with quite a few patches and their DTS, and I haven't found anything for this yet. Android is almost linux so with a bit of effort it's probably not unreachable, but I don't quite have the time for this yet... If someone does it then Linux with an external keyboard would probably work for me as well, there was someone who did it with the remarkable (it's already linux but they ran standard X11 on it), but the refresh rate was a bit too sluggish, something like the daylight computer would probably do nicely!

(not mine) was just checking what became of them and this review hit home

I have no use for an android tablet like this, but as soon as they make a PC screen (either laptop or desktop) I'm pretty sure I'd buy one fast! Keep it up folks!

While I was looking up such screens, these also seem to sell "quick refresh" PC screens: https://shop.dasung.com/

Just did a quick search on HN and while it did get posted recent ones didn't get many comments, not many users perhaps?

I'd be greedy and wish there was something in the middle (13 is tiny for desktop but there's no battery so it's not really laptop friendly; 25 is a bit too big for my desk), but perhaps...

The Dasung monitors are cool, but those are actual Eink, whereas the Daylight tablet is LCD, so you'll have a wildly different experience between the two.

There's a reflective lcd subreddit that discusses reflective lcd pc monitors, looks like at least one company is launching a commercial product soon.

Are you aware of any specific direct comparisons?

Video of same would be particularly illuminating, I think.

I really hope to Modos e-ink display works out - https://www.crowdsupply.com/modos-tech/modos-paper-monitor

They have their own FPGA based controller to enable much higher refresh rates and lower latency.

I turned my Daylight into a PC screen using this app, which worked like a charm: https://superdisplay.app/

That only works with Windows?

There seem to be equivalent for linux (not tested) https://www.tomshardware.com/how-to/use-tablet-or-phone-seco...

That's an interesting idea! I'm a bit wary of latency if this all goes over wifi, but probably worth a try.

There is https://eazeye.com/.

If it were some more reasonable spec than 24" 1920 x 1080 I would be far more interested.

It’s a hen and egg problem. There is little investment in the technology, because few people buy it.

That being said, Full HD at that size (and even at 27”) is still a fairly common resolution on the desktop.

It is still common, but there’s a reason that it only shows up on landfill-ready devices (unless you count high hz gaming monitors).

note reiserfs has been removed from 6.13, so you probably do not want to use that... https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13

(never used zig yet myself) For UB detection I've read zig had prime support for sanitizers, so you could run your tests with ubsan and catch UBs at this point... Assuming there are enough tests.

As far as I'm concerned (doing half C / half rust) I'm still watching from the sidelines but I'll definitely give zig a try at some point. This article was insightful, thank you!

(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...