HN user

tstack

300 karma

https://lnav.org

Posts5
Comments127
View on HN

what can be fast

I think this doesn't get talked about enough. If your input is a big run of data that is being checked/transformed in one shot, it works well. But, if you're likely to have to make a decision on several bytes of the input, SIMD will be the same or slower than the scalar method. It's not a magic "go fast" button.

Looks like Mr. Kelly agrees with you. From the zen of zig:

... what? No one is going to argue against those vague statements. He obviously does not agree with people that put more weight on making things compile errors instead of runtime errors. Which is fine, but saying he is in agreement is nonsense.

Considering every memory safe language that I’m aware of panics on index out of bounds, there’s spectrum here.

Many of those languages go to great lengths to avoid raw indexing: rich iterators, arenas with branded indexes, checked gets, and so on... But, sure, if you ignore all that and do `get(i).unwrap()`. Then, yes, things are exactly the "same".

I have no problem with people choosing the set of tradeoffs that works for their context. I have a problem with people acting like those tradeoffs don't exist.

You are leaving out other trade-offs, like the program crashing when something memory-unsafe is done. It is not simply a performance trade-off. Many folks would rather have the language catch this at compile-time instead of hoping that the test suite exercises all the code in just the right way to tickle the bug.

Another key pro to capabilities is that you can actually have a memory safe interface without having to leak lifetime and other info across boundaries.

One of the benefits of having lifetimes in the type system is thread-safety. Again, there is a lot of focus here on just memory-management: use-after-free, double-free, etc... But, being confident in the code running in a threaded environment is important as well.

With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect.

You have no idea whatsoever how many iterations were done before the initial commit. The VCS log is not representative of anything that happened before the first public release. Even before LLMs, people would grind away on stuff until they were happy and then put it in a VCS for public consumption.

there were still people chiding the project for not using Rust

Please provide a link to this comment.

Someone asked an honest question and got reasonable responses that were informative. At no point did anyone chide the project for not using Rust.

Rust might be a fine language but it has the most toxic evangelist culture, bar none.

Nah, people complaining about the supposed toxic community are noisier than the supposed toxic community.

re: man page - It looks like there is no support for man pages from the snap infrastructure. So, there's not much I can do.

The "stable" version of the snap is really old (circa 2023) at this point because I have been shy about bumping it. The candidate and edge versions are more recent and should be more usable.

Thanks for your time.

Kinda neat but I had trouble using it. Not sure what it is doing or what it is even showing me.

Can you elaborate a little more? lnav behaves like a pager with the conventional hotkeys for basic stuff. I'm not sure what else you are expecting.

Also a nitpick but the colors are quite garish

I enjoy colors, so there's a lot going on by default. There are several themes builtin. You can configure the "grayscale" theme by running:

    :config /ui/theme grayscale

Oof, sorry you had such a bad experience.

but there is no obvious way to exit. I tried Q,q

It's not very responsive during initial indexing, which is something I need to improve. Pressing `q` should work to exit in general, though. Pressing CTRL-C three times in quick succession will force quit it.

It would help to know which version you tried. Things have gotten better over the years.

I tried `man lnav` in separate terminal - but no man page is provided.

A man page exists, but only contains basic information. The builtin help text is much more extensive and can be viewed by running:

    lnav -H
There is also the documentation website: https://docs.lnav.org/

`ps` shows 3 processes which would not die with SIGTERM, have to `kill -9`.

Older versions of lnav would use readline for the prompt and had to run it in a separate process because of "reasons". More recent versions have a custom prompt and don't require the extra processes.

At that time lnav basically just kept everything in memory.

lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.

The memory consumption has never been a problem for me. So, it's not something I've ever focused on.

Speaking as the author, I too wish it was written in Rust. But, I started it in 2007 when I needed to get practice with C++ for work. At this point, there's so much code in lnav, rewriting would be a long process. There are some sub-components[1] that are written in Rust though.

A new project called logana[2] is written in Rust and is headed in a good direction. Use/contribute to that if you're really interested.

[1] https://github.com/tstack/lnav/tree/master/src/third-party/l...

[2] https://github.com/pauloremoli/logana/

To elaborate on this, lnav (https://lnav.org) is always polling files to check for new data and will load it in automatically. It does not require the user to do anything.

As far as following the tail of the file: if the focused line is at the end of the file, the display will scroll automatically; otherwise, the display will stick to the current position. Also, if there is a search active, matches in the new data will be found and highlighted.

It’s a bit odd to use

I would say it's a bad UX and not just odd. I can't see any benefit to making it modal. It should just load new data as it becomes available without making the user do anything.

There's also a new "https boot", which is supposed to be a PXE replacement, but TLS certs have time validity windows, and some clients may not have an RTC, or might have a dead CMOS battery, and those might not boot if the date is wrong.

I think the lack of entropy right after boot can also be a problem for the RNG. But, maybe that has been solved in more modern hardware.

... push it into overload ...

Oh, oh, I get to talk about my favorite bug!

I was working on network-booting servers with iPXE and we got a bug saying that things were working fine until the cluster size went over 4/5 machines. In a larger cluster, machines would not come up from a reboot. I thought QA was just being silly, why would the size of the cluster matter? I took a closer look and, sure enough, was able to reproduce the bug. Basically, the machine would sit there stuck trying to download the boot image over TCP from the server.

After some investigation, it turned out to be related to the heartbeats sent between machines (they were ICMP pings). Since iPXE is a very nice and fancy bootloader, it will happily respond to ICMP pings. Note that, in order to do this, it would do an ARP to find address to send the response to. Unfortunately, the size of the ARP cache was pretty small since this was "embedded" software (take a guess how big the cache was...). Essentially, while iPXE was downloading the image, the address of the image server would get pushed out of the ARP cache by all these heartbeats. Thus, the download would suffer since it had to constantly pause to redo the ARP request. So, things would work with a smaller cluster size since the ARP cache was big enough to keep track of the download server and the peers in the cluster.

I think I "fixed" it by responding to the ICMP using the source MAC address (making sure it wasn't broadcast) rather than doing an ARP.

We just don't want your sexuality shoved in our faces.

The flag simply acknowledges that certain people have the right to exist. Extrapolating anything else out of that is you being weird.

I've been hearing claims of the necessity of doing so for over a decade.

It seems to be necessary because you want to "turn the power of the state against you". All because of a rainbow?

We won the last election.

Did the whole of humanity have an election that I missed? Just because an election at one time and in one place went one way or the other doesn't mean much to something that is global. If you're speaking of the US Election, a certain person didn't even get 50% of the vote. So, I don't see how you act like this is some mandate that means you get to silence other people.

We can and will, with sadness but determination power, turn the power of the state against you and make you leave us the hell alone.

You don't seem sad about this at all.

My small site now sports a flag because it is clear it is needed. Are you going to come after me too?

The PRQL[1] syntax is built around pipelines and works pretty well.

I added a similar "get results as you type" feature to the SQLite integration in the Logfile Navigator (lnav)[2]. When entering PRQL queries, the preview will show the results for the current and previous stages of the pipeline. When you move the cursor around, the previews update accordingly. I was waiting years for something like PRQL to implement this since doing it with regular SQL requires more knowledge of the syntax and I didn't want to go down that path.

[1] https://prql-lang.org [2] - https://lnav.org/2024/03/29/prql-support.html

Solarpunk 1 year ago

the Wayfarers series starting with “The Long Way to a Small, Angry Planet” is maybe the best collection of before-bed reading I’ve ever found.

I agree wholeheartedly and do, in fact, read them in bed. I transitioned to the Wayfarers after souring on The Expanse (I enjoyed most parts of those books, but the black ooze is not for me). The low-stakes, slice-of-life content is more up my alley.

- regex101 support for quickly defining custom formats is just awesome. Versioning support is slightly broken however, probably because regex101 changed something, so there's no easy way to update the format once you've initially imported it.

There is a `pull` sub-command and it looks like it still works. Running the following will generate a patch file with the updated regex:

    lnav -m format <format-name> regex std regex101 pull
It creates a patch file since the original file might've been modified.

- There are lots of different filtering capabilities, but there is no unified treatment of them. For example, `:hide-lines-before` and `:filter-out` are at their core the same type of operation: filtering. I should be able to pull up a list of all filters that are currently active and easily add new ones and toggle or delete existing ones.

Adding the time filters to the "Filters" panel sounds like a reasonable request. I've added https://github.com/tstack/lnav/issues/1275 to track.

- I would expect to be able to create a new view of the data using SQL `SELECT`. A select statement is fundamentally about filtering out some rows (log lines), which feels like a filter, and selecting some particular columns (log fields) and hiding others. The latter point seems like it could be something that should be handled when https://github.com/tstack/lnav/issues/1274 is resolved.

There is the `:filter-expr` command (https://docs.lnav.org/en/v0.12.2/commands.html#filter-expr-e...), have you tried that?