It seems that now more than ever, testing is important. But LLMs love to cheat the tests and make them superficially pass. If you're never reading the code, how do you know changes are reasonable?
I do review, if only whatever I do was the norm for everyone :)
Do you see lots of posts about new compilers and languages and language features on HN in the last year? Maybe I just missed them. I'd love to read more posts like that and fewer about agent frameworks.
iOS generally lets you reject any permission an app asks for. This would certainly be "risky" enough that iOS would require explicit user permission, and you would be able to say no.
On top of that, the app is completely optional: if you aren't comfortable giving it those permissions, don't install it?
> you can actually learn a LOT by being given the answer, if you actually care to learn.
Even if you "actually care to learn", this is a huge mental shortcut and you're deceiving yourself if you think deep learning is happening from looking at the answer.
On top of that, the pressures to just finish the coursework and move on to your other homework due tomorrow seems pretty high. Your suggestion means we're no longer coddling/shielding students, but we also aren't actively helping them, are we?
Not from simply looking at the answer. From knowing the answer and reverse-engineering or understanding how to arrive at that answer in the first place. It's not always the best way of learning, but it definitely is a great way to learn if you care to actually understand why it is the answer and how you would have arrived at it.
> Your suggestion means we're no longer coddling/shielding students, but we also aren't actively helping them, are we?
My suggestion is just the former, it doesn't imply the latter.
- the way the wood looks and feels.
- it has been fairly tough. I managed to stain it with an overnight pen leak, but it's mostly easy to clean, and stands up to minor impacts from computers and cups. Also, no water marks so far.
I dislike:
- the curved front, which looked cute in the pictures but makes it a PITA to fit a keyboard tray. That was a mistake. I wish I'd gone for the straight edged desk.
SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.
Locking down a desktop OS to modern standards really requires what Apple did with macOS, which requires a degree of central coordination that's beyond the Linux community. It mandates huge changes in almost every area of the OS stack, and all apps have to be sandboxed by default out of the box.
Developers don't like mandatory sandboxing. It has to be forced on them. So you can see the difficulty of doing it in the open source community, which has for decades now had the worst security of any desktop OS platform (even Windows is better).
To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.
Apple have shown it can be done with macOS. Not only is every app sandboxed in a usefully robust way (even ones distributed outside the app store) but this has been done in a way smooth enough that users didn't revolt.
Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc.
Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
I don’t think that’s necessarily the case. Exposure and discovery aren’t that tightly correlated. Maybe there’s a small effect, but I think it is outweighed by the fact that blast radius and spread is reduced while buying time for discovery.
As a rule, I commit the input to the code generation tool, i.e., what the GPL refers to as "the preferred form of the work for making modifications to it", generate as part of the build process, and, where possible, try to avoid code generation tools designed around the assumption that its output will be maintained rather than regenerated from modified input.
As for LLM code assistants, I don't really view them as traditional code generation tools in the first place, as in practice they more resemble something in between autocomplete and delegating to a junior programmer.
As for attribution, I view it more or less the same way as "dictated but not read" in written correspondance, i.e., an disclaimer for errors in the code, which may be considered rude in some contexts, and a perfectly acceptable and useful annotation in others.
It seems that now more than ever, testing is important. But LLMs love to cheat the tests and make them superficially pass. If you're never reading the code, how do you know changes are reasonable?
reply