1,496 karma · joined April 15, 2020
It would be more like a low level manager telling new employees what he would do if he ever catches them stealing office supplies.
The university has a policy on how to handle cheating. The professor doesn’t need to imagine potential scenarios in the syllabus
Anecdotal but not in my experience. The professor can inform students, collect evidence, etc without detailing each scenario in the syllabus.
Every CS class I’ve been a TA for had the same generic university provided statement on cheating.
The professors did not want to spend time thinking about or dealing with people cheating.
Every time MOSS flagged assignments they basically sat with me and the student and said “You are likely cheating. Please don’t do it again.”. No one ever admitted to cheating and no one ever got flagged twice.
> If we find reason to believe that a student or team has cheated on any assignment, we may inform the student or team promptly, or we may decide to silently accumulate evidence against the student or team on later assignments.
Why role play what you may or may not do if you encounter cheating.
The university has rules about how academic integrity is handled independent of the syllabus.
Including this line in the syllabus, and again at the top of the blog post is weird
Chrome and Safari can’t be trusted because the profit model of the parent company is at odds with building a user first browser.
Firefox cannot be trusted because they work on too many unrelated projects.
Open source alternatives cannot be trusted because they don’t try to profit off of users.
Brave is good though, despite having a profit model directly at odds with a privacy first browser and working on many unrelated projects (multiple browser versions, a search engine, and a VPN, a cryptocurrency) even though they are smaller than Mozilla.
The fact that you can pay for a version that doesn’t sell your habits to advertisers goes against the point you are trying to make. Other than Google, every other browser does that by default for free, and even Google offers chromium for free.
I think this is exactly backwards, they are a business first and all other messaging is marketing to support that end. I recognize there is likely nothing that can be said to change your opinion if you have faith Brave is putting your interests above their own.
If you do compare to the firefox privacy policy, the most notable difference is how specific Mozilla is about what data is collected and how it is used.
In contrast, try to find any detail about the specific information collected by the brave browser and how it is used to serve ads.
Isn't Brave's main source of revenue serving you ads based on information collected about you from while using their browser?
I've switched fully to Meta's Muse for all of my research going forward.
Its the same difference between "I was arrested for having liquid in my car while driving" and "I was arrested for holding an open bottle of whiskey while driving"
Why build codex if AGI will replace SWEs?
Why build excel integrations if AGI will replace spreadsheets?
> Phishing through the standard login flow is eliminated by passkeys, but it creates a false sense of security. An account’s security is still dictated by the weakest recovery method: SMS, email links, security questions, and so on.
Passkeys are too strong and may cause account loss.
Passkeys are too weak and can be bypassed by account recovery.
To me, it’s essentially implementing the same code twice in two languages and checking the behavior matches.
If the same person implements both, what are the odds they implement the same bug in both?
Only verification annotations are generally even harder to read and write than the code itself, making it even more difficult to tell if you implemented the proof according to the spec, or just mirrored what the function actually does.
My point is that this is the hard part, and writing annotations does nothing to help with this problem.
Programmer intends to write code that does Y, but writes code that does X. Then they make the same mistake again and write an annotation that verifies the function does X.
Verification passes, but the code does the wrong thing.
Sorry if I wasn’t clear.
My point is that the annotations are manual and inherently prone to error.
If humans could correctly write annotations according to a spec, we wouldn’t need verifiers at all. We could just write correct code directly.
There is an argument to be made that the annotations are a smaller surface than full blown code and therefore easier for humans to reason about.
However, in practice formal verification tools and annotations are far more obscure than regular code.
Thousands of people write and review code both professionally and as a hobby. But most people writing verifier annotations have a PhD in some field adjacent to formal verification.
Hopefully they find some kind of carve out for OSS projects while still blocking the egregious offenders.
Browsing open issues or reviewing a few PRs will easily use more than one request per minute.
The limits are based on the average user but I wonder if the most common interaction is to view a readme and bounce.
I don’t know that putting a paywall up to learn from or even consider contributing to public projects is a good thing.
The guidance given seems to hurt open source projects, not help.
> Make the project private if the traffic is not coming from the audience you built it for, which stops anonymous callers reaching it at all. Or upgrade to Premium or Ultimate for much higher limits.
But maybe this changes in the age of LLMs. A deterministic check to let LLMs verify the correctness of an API could improve the success rate of large scale refactors or performance optimizations.
Exciting!
If you want to keep a secret, you must also hide it from yourself.
How can you tell?
It’s also popular enough that there is an abundance of high quality learning resources for beginners.
No other language threads that needle as well as C.
This is exactly what makes it great for teaching. Students don’t need to know actual arch or hardware details. They just need to grasp the core concepts of what is happening on the hardware.
For that purpose the ideal teaching language is lower level than python, javascript, Ocaml, etc without diving into nitty gritty arch specifics.
C is the undisputed champion in that domain.
Lifetimes are a compiler safety abstraction and mostly unrelated with how the computer runs your program.
Learning a language like C helps to understand why lifetime annotations are needed and how the compiler uses them.
Those that don’t need low level details can spend their professional career in languages like python and JavaScript while still have a sense of what lies beneath the abstraction.
For those that do want or need to go deeper, C is an excellent jumping off point into ASM and arch specifics.
Most modern languages have ways to automate parts of memory management, and rightfully so. But you should at least be somewhat aware of what is going on under the hood.
It’s still an abstraction, but at least being aware of memory management, copying vs referencing, etc are hugely important concepts that ML languages can hide.
Does the same hold for going from 5 days to 7 days or 8 hours to 16 hours?
A reasonable person should agree at some point adding more time will make people less productive due to lack of breaks, rest, etc.
Is it obvious where the line is? if so, where?