• 0 Posts
  • 264 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle


  • The C example is the wonderful happy path scenario that only manifests in dreams.

    Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.

    Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.

    And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.

    All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.


  • Is there anything in the LLMs code preventing it from emitting copyrighted code? Nobody outside LLM companies know, but I’m willing to bet there isn’t.

    Therefore, LLMs DO emit copyrighted code. Due to them being trained on copyrighted code and the statistical nature of LLMs.

    Does the LLM tell its users that the code it outputted has copyright? I’m not aware of any instance of that happening. In fact, LLMs are probably programmed to not put a copyright header at the start of files, even if the code it “learnt” from had them. So in the literal sense, it is stripping the code of copyright notices.

    Does the justice system prosecute LLMs for outputting copyrighted code? No it doesn’t.

    I don’t know what definition you use for “strip X of copyright” but I’d say if you can copy something openly and nobody does anything against it, you are stripping it’s copyright.




  • Generally agree. Except:

    Logs that are a “debug diary” are not useless. Their purpose is to debug. That’s why there’s log levels. If you are not interested in that, filter by log levels above debug.

    Also, the different formats for fields I see as a necessary evil. Generally, more logs (of verbose log levels) = more good. Which means that there should be as frictionless to write as possible. Forcing a specific format just means that there will be less logs being written.

    The json (or any other consistent format) logs seem to be a good idea, but I would keep it to a single debug level (maybe info+error?). So if you want to get wide events, you filter by these log levels to get the full compact picture. But if you are following a debug log chain, it seems a pain to have to search for the “message” field on a potentially order-independent format instead of just reading the log.

    TL;DR

    Log levels have different purposes, and so they should have different requirements.



  • One of the techniques I’ve seen it’s like a “password”. So for example if you write a lot the phrase “aunt bridge sold the orangutan potatoes” and then a bunch of nonsense after that, then you’re likely the only source of that phrase. So it learns that after that phrase, it has to write nonsense.

    I don’t see how this would be very useful, since then it wouldn’t say the phrase in the first place, so the poison wouldn’t be triggered.

    EDIT: maybe it could be like a building process. You have to also put “aunt bridge” together many times, then “bridge sold” and so on, so every time it writes “aunt”, it has a chance to fall into the next trap, untill it reaches absolute nonsense.









  • My comment explicitly avoids the “standard” problem.

    A user could have many "theming system"s installed at once, while only having 1 DE. The user ideally would configure only one, and some program should try to translate that system into the other ones.

    Then each app will fetch the list of theming systems the user has installed, and choose whichever the app prefers. And if there’s no match, fall back to a default hard coded theme.


  • I see you ignored my entire comment.

    I don’t know what is more explicit about expect. Unwrap is as explicit as it gets without directly calling panic!, it’s only 1 abstraction level away. It’s literally the same as expect, but without a string argument. It’s probably top 10 functions most commonly used in rust, every rust programmer knows what unwrap does.

    Any code reviewer should be able to see that unwrap and flag it as a potential issue. It’s not a weird function with an obscure panic side effect. It can only do 2 things: panic or not panic, it can be implemented in a single line. 3 lines if the panic! Is on a different line to the if statement.


  • An unhanded error will always result on a panic (or a halt I guess). You cannot continue the execution of the program without handling an error (remember, just ignoring it is a form of handling). You either handle the error and continue execution, or you don’t and stop execution.

    A panic is very far from a segfault. In apparent result, it is the same. However, a panic is a controlled stopping of the program’s execution. A segfault is a forced execution stop by the OS.

    But the OS can only know that it has to segfault if a program accesses memory outside its control.

    If the program accesses memory that it’s under it’s control, but is outside bounds, then the program will not stop the execution, and this is way worse.

    EDIT: As you said, it’s also an important difference that a panic will just stop the thread, not the entire process.