Hacker News .hnnew | past | comments | ask | show | jobs | submit | sockaddr's commentslogin

In fact, duplicates with different approaches over time and different ways of being asked is REALLY good for LLMs

And they made it easy by linking duplicates together

Any company that uses that type of background image definitely churns out AI slop

I'm a huge AI advocate but even I can't get on board with this.

Feel free to fork the kernel and maintain your own vibe-coded disaster.


I'm confused by your answer, the previous post doesn't seem to be about vibe-coding at all.

It seems to be more about:

1. auto grouping duplicate security reports

2. auto validating if they are likely viable or likely nonsense

3. auto checking if they have recently been patched

4. auto assessing if they likely "invalide" for other reasons (e.g. they are for a very old long time no longer maintained Linux version, out of tree drivers, etc.)

I mean practically all of that isn't trivial to get working in a way appropriate for the Linux security mailing list and comes with many not so obvious complications. But also non of that is vibe coding and in most cases this is is more about AI doing a per-assemsment of send security issues to speed up the review of them, then it is about the AI doing the final decision.


Exactly.

At the end of the day, we would rather have a more stable and bug-free kernel than not.

It's not that much work for me anymore to report and even fix that obscure monitor driver bug that sometimes causes my machine to bootloop, unless I boot without graphics and start the XOrg server manually.

I often find myself surprised at how easily frontier models are able to find bugs across abstraction layers, that only original authors can comprehend. We need more positivity around these contributions as well.


AI slop causes additional noise on the mailing list. Your suggestion is to use more AI to filter the noise?

How about we just reduce the noise?


I'm going to law school there next semester.


So basically you've built a mechanism for a model to de-compress itself.


Not for a lack of trying! Had to enforce tool building through code as models tend to just execute arbitrary code when allowed.


To add to this, as long as the diff representing the removal of the driver is kept in the git history it would be trivial for someone in the far future to say to an AI agent:

"Please take this linux source and patch the Bus mouse driver back in but match the new driver interface".

With code preserved in git history it's never actually "removed". It's just, disconnected.


Sorry but I think this should be left up to the user to decide how it works and how they want to burn their tokens. Also a countdown timer is better than all of these other options you mention.


Yeah this is actually quite shocking. In my earlier uses of CC I might noodle on a problem for a while, come back and update the plan, go shower, think, give CC a new piece of advice, etc. Basically treating it like a coworker. And I thought that it was a static conversation (at least on the order of a day or so). An hour is absurd IMO and makes me want to rethink whether I want to keep my anthropic plan.


> Also a lot of bullet points are bad

> Slides should have maybe a sentence of text at most

Proceeds to have slides with many bullet points and more than several sentences of text per.

I don't find issue with the slides as they are but if you're going to make arbitrary rules why not follow them yourself?


I haven't seen the associated talk, but (a) I would imagine the author chuckled while reading this, because it's sort of a joke among scholars, and (b) the point is likely focused much more on the context of presenting research (e.g., at conferences) rather than a blanket ironclad rule for all presentations you ever make ever.

While I think there's some validity to your point that the author's presentation suffers excess verbosity, I'm not too worried about it because the linked slides seem more meant to act as a reference document than an example of a good presentation, and the level of text is just fine for that purpose.


Yeah I’m the author, this was a joke. I also wanted to convey to the students in the room that this was not a high quality presentation, more so text just converted into presentation form.


Seemed pretty clear to me, for what it's worth, but perhaps it is less obvious to those not steeped in similar traditions of academia.

Thanks for this, by the way! It's a lovely resource!


There are presentations that you actually present to an audience, to which this point is valid.

But lots of presentations, including this one I think, are merely used as a means of conveying information (yeah, not my favorite way of doing so, but being a contrarian doesn't do anybody's career any good), and those are indeed intended to be read and need to have explicitly all the information that you otherwise would be speaking and addressing.


My guess is probably there is a difference between slides used for presentation and slides used for reading myself alone


I always thought this was funny. We were taught this in grad school, but hardly anybody followed this guideline. "If there's too much text on the slide, the audience will be busy reading the slide, and not paying attention to you". I try to have just the main point on the slide, then I can talk around it. The details should be in the slide notes, if you need reminders.


Your family is starving and your dog died of radiation poisoning from the fallout but at least your local LLM can browse this and recommend a good software stack for your automated booby traps.


Not really, AI slop flood is also some kind of end of World. It gets harder and harder to hoard pre-2020 content.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: