It's not that big of a deal. If you knew the libraries involved, his winning entry would take you 10 minutes to code. The advantage of the AI here is that it suggests which libraries to use, and how to connect them. Here is the code if you want to check it out.

Cheating worked for Tom Brady.

That's normal for PMs, minimal to no coding skills. That is not their job.

Here is his website. Nice, (but the top menu bar is among the most irritating I've ever seen).

Here is his code for the winning hackathon entry he made. It uses Gradio, which is a library I was unaware of, but looks interesting.

His linkedin has the following skills listed:

Are you quoting ChatGPT? Here is science: https://pmc.ncbi.nlm.nih.gov/a...

It depends on what kind of CS you are doing. Donald Knuth does a lot of programming as a computer scientist.

It's almost certainly because you didn't do enough programming in college.

Ideally an introduction course should be a course where you come in, sit down, and program all class period. For an entire semester. They can read the course material between classes (that is the new homework). By the end of the semester, the students will have written a lot of code, and have a decent introduction to programming.

What is a management trap?

In all OSes, privilege escalation exploits are endemic. Windows tries to solve the problem by adding more and more security (protection) rings. OpenBSD is only secure against remote exploits, not local. If someone gets access to run code on your system, they are going to be able to escalate to root.

It's kind of weird, tbh. Why wouldn't orcas attack humans? They don't have any problem attacking moose, or sharks.

I can't comment on where sudo itself lives on the spectrum from aggressively solid implementation to really-dodgy-smell-around-the-edges; but it seems like its purpose is a fundamentally tricky problem even if its execution were impeccable.

The basic "user is authorized for root; but we'd prefer he be thinking and logged when he uses that authorization" is reasonably cogent use case; but it's more of a reminder than a security barrier. Then you get into the actually-interesting attempts at limited delegation and determine that you'd basically need a different userland for a lot of purposes: aside from the modest number of things(often with setuid already in place) built specifically to carefully do a very particular delegated function on your behalf and provide you with nothing else if they can help it; very little aside from garbage kiosk UIs or web or database-backed applications with user and permission structures mostly orthogonal to those of the underlying OS actually tries to constrain the user's use of the application(within whatever context that user is operating; generally having a privilege escalation is considered bad).

Half of what you run considers having an embedded shell to be a design feature; so including any of that on the sudoers list essentially means being able to chain arbitrary commands from that sudoers entry; and the other half doesn't outright intend to include a shell but would require some really brutal pruning, likely of important features, to prevent being able to chain a couple of interactions into having the ability to run whatever. And that is assuming that sudo itself is working entirely correctly.

I guess to really get a good picture it would help to have a clear definition of what tech debt actually is. Certainly duplicated code qualifies.

Oh no, I carefully procured it from The Chat.

Seven out of 10 people find the world a very confusing place. cite

For people who don't understand statistics, the world is a very confusing place.