pkage
pkage on Hacker News
I used this to build my personal site:
https://ka.ge . It's a pixel-perfect (and functional) recreation of the windows 98 desktop environment in under a MB.
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.
https://ka.geLockdown project during early COVID, I tried to be as close as possible to the original windows 98 functionality.
Does not appear to work under Firefox, getting a bunch of CORS-related errors (header ‘user-agent’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response) on the /graphql endpoint.
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.
There's native ad blocking on iOS and has been for a while—I've found that to significantly enhance the usability of the device. I use Wipr[0], other options are available.
[0]: https://kaylees.site/wipr2.html
The DC Metro system operates similarly.
Not OP, but common solutions in this space represent the state as conflict-free replicated data types (CRDTs). Some popular browser-based libraries for that are Y.js[0] and Automerge[1].
[0]: https://yjs.dev/
[1]: https://automerge.org/
I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being.
[0] https://beej.us/guide/bgnet/
[1] https://beej.us/guide/bggit/
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.
If you're willing to hold your nose a little bit, Plaid[0] might be worth looking into. They have (had?) a testing tier which is more than enough for personal uses (100 linked accounts).
[0]: https://plaid.com/
I mean, it's entirely possible the boy has two mothers. This seems like a perfectly reasonable answer from the model, no?
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.
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