HN user

pkage

709 karma

https://ka.ge/

[ my public key: https://keybase.io/pkage; my proof: https://keybase.io/pkage/sigs/H5CBCtp_dXAcg78KYbrbG1uqmBaPgylN1Bfm166k1UY ]

meet.hn/city/us-Atlanta

Posts3
Comments145
View on HN

As with all text-only AI detection schemes, I am concerned about the accuracy of the detection. I'm skeptical of the methodology, specifically the final join of the three detector scores---how can you be sure that that final step does not introduce any biases? There's no source available, so it's difficult to tell exactly how this works or reproduce the research.

I've also uploaded text samples from my own (unreleased) research from pre-LLM era, and it's seemingly scoring pretty high on the LLM-detection scores. On other papers, nearly every sentence is highlighted as red "machine-leaning," but that does not impact the score? Additionally, there are dramatic differences between the scores for identical text with and without LaTeX formatting, despite the fact that it should not matter.

The takeaway from this should be "it is difficult to detect generated text and we should be careful about accepting results simply because they confirm a hypothesis."

--

Relatedly, the text above scores as highly machine-written, despite the fact that I just wrote it with my human hands, I promise :)

The filter doesn't appear to be perfect, one of the top posts right now is "My Agent Skill for Test-Driven Development"

I switched from iTerm2 because at the time (possibly still), iTerm2 had a performance bug where large amounts of underlined text would cause the terminal to slow down noticeably. Wezterm works perfectly, and I appreciate the .lua configuration over iTerm2's mess of menus.

In addition to the other responses, it's also worth noting that wasm itself is useful outside of the web itself; e.g. in containerized applications.

Yes, that's an http connection to the Docker Engine api on localhost failing due to the same issue—the docker engine cam't negotiate with the Docker Hub to get the new image and is passing the error back through the local api to your updater process.

For me, that's manual—I make sure everything I've cited is in the .bib file, and move papers into another collection if they end up not being relevant for a particular paper.

This is probably an automatable task, but it's generally not too much of a burden to do manually. I add a 'needs-review' tag to papers I've identified in a literature review, and categorize it when I get around to reading it.

Same here, except that I gather all the bibliography entries into a Zotero collection organized by paper and only export that to the latex workspace rather than using JabRef. Works a treat and keeps the size of the .bib file small.

There is no concrete concern past "models that can simulate thinking are scary." The risk has always been connecting models to systems which are safety critical, but for some reason the discourse around this issue has been more influenced by Terminator than OSHA.

As a researcher in the field, I believe there's no risk beyond overconfident automation---and we already have analogous legislation for automations, for example in what criteria are allowable and not allowable when deciding whether an individual is eligible for a loan.

LIME and other post-hoc explanatory techniques (deepshap, etc.) only give an explanation for a singular inference, but aren't helpful for the model as a whole. In other words, you can make a reasonable guess as to why a specific prediction was made but you have no idea how the model will behave in the general case, even on similar inputs.

Micrograd.jl 2 years ago

Same here. I started my PhD with the full intention of doing most of my research with Julia (via Flux[0]), and while things worked well enough there were a few things which made it challenging:

- Lack of multi-GPU support,

- some other weird bugs related to autograd which i never fully figured out,

- and the killer one: none of my coauthors used Julia, so I decided to just go with PyTorch.

PyTorch has been just fine, and it's nice to not have to reinvent to wheel for every new model architecture.

[0] https://fluxml.ai/

I like this! I feel like I've written a half-version of this a dozen times, it's nice to see a version which is fully fleshed out.

One feature request: you could likely fully remove the need for an NPM package by accepting POST requests from forms, and staple the API key in with either the URL or an <input type="hidden" value="key"/>—is that in the roadmap?

I agree, the `dev` extra group should be used for development dependencies. The arguments against it are pretty weak, especially the "i don't want dev dependencies listed as dependencies of the package on pip" line; imo if a package is required to interact with the dev environment it is a de facto dependency regardless of whether it gets installed in a normal installation.

A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.

This is a fairly common way to install tools on Linux. Tailscale, Homebrew, Pi-hole and many others offer installations in this way.

ML researcher perspective: Conda is... dog slow, even for relatively simple tasks (clone and run a project). The recommendation nowadays is to use Mamba (iirc), but in my experience (a few years old now) it's been unstable and unable to find package solves which worked on my system / our cluster.

I've settled on just using Poetry for most things, and then using pip in a venv to install the pyproject.toml file from Poetry either in a Dockerfile or directly on a cluster. That's worked fairly well so far, even with torch/cuda (and the mess of CUDA versioning) and from macOS to Linux.

I think uv/rye is a good next step, Poetry can be a bit slow as well at times.

Claiming that emissions surged 50% due exclusively to AI (as in the headline) is unsupported by the Google report, which is the article's singular source.

Again, looking at the graph of emissions at Google on pg 31, it's clear that the increase is linear after a dip 2019-2020 and the report identifies supply chain issues as a major source of emissions in addition to datacenter electricity costs—again, notably not specifically calling out their AI training/inference costs as a reason for their increase. The report does identify AI as a challenge going forwards, however that's not the same as saying it's exclusively responsible for the last 5 years of emissions.

Additionally, the only sea covered in its entirety is the Mediterranean. Generally, constellations don't do captures over open ocean as researchers/customers tend to be much more interested in events on land; this makes it difficult to do long-term analyses of marine events as the data just simply isn't captured.

Source: work in the industry

I think the problem comes down to fingerprinting. For example, resources used to be cached in the browser regardless of site exactly as you described, but then ad companies figured out you can track a user's browsing history by timing the cache accesses to see if a user had loaded a bundle from another site. To remove that vector, browsers split up caches per domain.