Comments URL: https://news.ycombinator.com/item?id=46294537

Points: 2

# Comments: 0

Indeed, precise cost attribution is difficult or impossible due to how the nature of the language imposes structure on industrial computers. But that aside, you still end up easily with hundreds of megabytes of source to deal with in each translation unit. I have so many scars from dealing with that...

Years back I worked at a C++ shop with a big codebase (hundreds of millions of LOC when you included vendored dependencies). Compile times there were sometimes dominated by parsing speed! Now, I don't remember the exact breakdown of lexing vs parsing, but I did look at it under a profiler.

It's very easy in C++ projects to structure your code such that you inadvertently cause hundreds of megabytes of sources to be parsed by each single #include. In such a case, lexing and parsing costs can dominate build times. Precompiled headers help, but not enough...

Maybe a weak version of Turing's test?

Passing the stronger one (from Turing's paper "Computing Machinery and Intelligence") involves an "average interrogator" being unable to distinguish between human and computer after 5 minutes of questioning more than 70% of the time. I've not seen this result published with today's LLMs.

Though surely some AI systems do not use PDF image rendering first!

When looking at universities, when I saw a high sticker price, I ignored that university, even if in hindsight I had a good chance of being accepted.

I wish I had had someone when I was young who encouraged me to have broader horizons.

How did Nosey Parker Explorer come about? 2-3 years ago I was working on training ML models for tasks related to hardcoded secrets, such as TP/FP classification and detection. These are pretty specific tasks and there are no open-access datasets. So, I had to build my own dataset of several thousand labeled examples.

None of the existing tools for data labeling that I ran across was a good fit for the task. They were all either too general-purpose, too complicated to set up, or too slow. So I built my own proof-of-concept purpose-built terminal-based labeling app using the excellent Textual TUI framework [2] and DuckDB [3] to build fast faceted search. A couple weeks later I had Nosey Parker Explorer.

Nosey Parker Explorer proved very effective at the dataset construction task. My team of a few people used it to label about 15k examples collected from 2TB of input.

However, beyond dataset creation, Nosey Parker Explorer was a huge boon for security engineers on engagements. Once you are dealing with more than a few dozen possible findings, it is _hugely_ helpful to be able to interactively slice-and-dice the data. The largest-scale use of it that I'm aware of was an assumed-breach engagement where we had tens of thousands of potential findings from 20TB of scanned inputs.

Nosey Parker Explorer was far too useful to be left as a proof-of-concept or only used internally. A couple weeks ago I released it under the Apache 2 license.

If you want to try it, It's a Python application (not yet on PyPI). There are prebuilt zipapp releases, but you can also clone the repository and `pip install`. You will first need to use Nosey Parker to scan something. See the project's README for details.

Happy to answer questions.

[1] Nosey Parker: https://github.com/praetorian-inc/noseyparker

[2] Textual: https://textual.textualize.io

[3] DuckDB: https://duckdb.org

Comments URL: https://news.ycombinator.com/item?id=43090633

Points: 3

# Comments: 0

This was native desktop+server software, not a hosted SaaS thing.

Major releases were put out every few months.

Developers did run tests regularly with every change they would make, but it was infeasible to run all the tests in every configuration for each change. So they would try to choose tests to run that seemed most relevant to the code they had changed.

The entire test suite would run more or less constantly on shared machines, and every few days some new tricky failure would be detected. The tricky failures were almost always the result of some unanticipated interaction of features, frequently on the more obscure configurations (like IBM z/OS).

The problem was not that developers were not testing, but that the tests were infeasible to run every time. So instead, testing became an optimization problem.

This cycle time combined with occasional unexpected interactions between components meant that in every release cycle, there were dozens of complicated failing tests where it was not obvious which code change was responsible.

`bisect` here was extremely helpful: instead of having to pore over commit history and think very hard, I could bisect with a small wrapper script that would build and run the failing test in question. Builds still took hours, but I could usually autonatically pinpoint the responsible code change for one of the tests overnight.

(This was not using Git, but Perforce, for which I had to write `p4-bisect`. Alas, it's not open-source...)

Indeed! Utilization is a proxy for what you actually want (which is good use of available hardware). 100% GPU utilization doesn't actually indicate this.

On the other hand, if you aren't getting 100% GPU utilization, you aren't making good use of the hardware.

So indeed, not representative of the whole Internet.

> A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork.

[1] https://docs.github.com/en/pull-requests/collaborating-with-...

https://roaringbitmap.org/