That featur is opt-in: someone had to check a checkbox somewhere to enable it.
And yeah, that how the businesses work: you opt-in to feature, then you start paying for it. Sometimes the latter part is delayed, in which case it's a good style to send heads-up email about it. Nothing unusual or scammy about it.
> GitHub Code Quality is available for organization-owned repositories on GitHub Team and GitHub Enterprise Cloud plans.
Both of those are paid plans, so the billing information available. As the message says, this email is not for individual user, but rather for github org admin. I guess someone made the poster an admin, they are receiving admin-only messages and are freaking out now?
> A hash of all files is checked against known hashes on sum.golang.org to prevent tags from being replaced, and it uses a proxy to prevent repos from being left-pad’d.
there is no need for 3rd party hosts to stay online. It's the best combination of de-centralized and centralized approaches.
Re pre-buiild packages: Python makes a difference between source and binary wheels. This approach is obviously for source wheels only.
LoRa is 3-4 kilobytes/second, slower than a dial-up modem. And there are duty cycle limits too. This is ideal for text messages and occasional telemetry. But 'full-on SSH session'? or even worse, 'Git history, issue tracking, release distribution'? That sounds like a really bad fit.
A single person pulling a single git repo may easily occupy multiple LoRa channels for hours. That sounds like a horrible idea. Some things simply should not be unified. The low-bandwidth world and high-bandwidth worlds have completely separate protocols and do not belong together.
I am currently work on embedded / low-level / devtools and there are tons of novel things to do. Perhaps the "programming" skills are not needed as much, but demand for "engineering" is as high as ever.
Maybe it's the case in web dev? TFA shows that the number of "web developers" is decreasing strongly.
Not really, bluetooth/wifi detectors are absolutely a thing, and emissions from camera in glasses are easily detectable by the right equipment.
This equipment is not very common today, but if the smart glasses become popular, then universities (or proctoring centers) will get it.
And if they don't become common, then some fraction of cheating is acceptable, as long it's not too high. After all, one could do micro-camera + earbuds even before AI, with human conspirator.
> Turkstra said he’ll still use the AI detection tool going forward.
That's crazy! AI detection tools are notably unreliable, and even if they had only 1% false positive rate (I am sure it's actually much higher) that'd still be multiple innocent people failing the class for no reason.
Imagine enrolling in the class, and the professor says: "oh, and btw I am going to randomly pick three students and accuse them of cheating". Would you want to stay in this class
I think the future is going to be proctored exams on paper or on locked-down devices. If there will be projects, they should be accompanied by secondary evidence, like interviews about them.
Interacting with durable data storage is actually pretty common.
Perl is modern (-ish? Definitely modern compared to MUMPS) and had "tie" for database access forever [0]
Python's dbm interface also looks like a regular dict [1]. I am sure there are many others, I know we had one "magic dict" in one of my work projects.
It's just that transparent access has some limitations, like lack of transactions, unexpected latency, lack of strong types, inability to only change a single value.
I had some "reverse classroom" classes back in college, and it was the best kind of class for me. Read the papers on your own time before class, and spend class discussing and in tests.
It did, however, absolutely require everyone to prepare for every class. Some people complained a lot about this, which might be why this was not as popular as more common lectures.
The key word is "web", and all associated ecosystem - the place where local devices are transient, and everything is in the cloud.
I personally have multiple regular PCs, sync the files around, do encrypted backups, and so on. I still have my files from 20 years ago, and I manage my personal keys.
But when I talk to other people, most people aren't like that! They don't do regular backups, they lose files all the time (phone broke -> files are gone), and when they transfer files, they do it via 3rd party, by emailing, dropboxing or uploading to Google Drive.
So how would they handle "private key"?
Most of then will never download the app, and will only use the website. I guess you can use browser web storage to store the key, but next time they run out of space and clear internet files, it would be gone. Or if their phone breaks. Or if the computer starts to behave strangely, so they wipe it all (not exaggerating, I've seen people do that). So keeping the key only in the browser is a terrible idea.
You can force them to download private key, but then what? Most people will simply forget it (after all, "I am just trying out this thing, no need to both with all the complex backups"), and the key will sit in Download folder until the PC/phone breaks. If you got lucky, they'll upload this to Google Drive/iCloud, so that megacrop will have a private key.
But the worst of all, even if you somehow magically get them to preserve the private key, it's useless. Remember, we are talking rogue operator here, and those are very likely the same people who are serving you the webpage and javascript blob that will obtain the key from local storage and decrypt. They will do the same thing hushmail did, which is to modify the webpage so it exfiltrates the private key.
(And yes, all of this can be worked around if you don't use web, and run the stuff locally. But this severely restricts users, and will kill the adoption)
Yes, I am familiar with multiple solution that want to replace the web. They can solve all sorts of interesting problems, except one: how to get adoption.
I have nothing against people exploring alternative networking systems, but let's be clear: the only reason to run GNUnet (or Nostr, or SSB) is if you are interested in GNUnet/Nostr/SSB itself, or if you want to add exclusivity and wall your garden away from random visitors.
But many people have the opposite goal - they want their content to be accessible, and they want everyone to be able to participate, even if they are a high school student with 10 year old iPhone. And this means web.
So let's talk about how we can actually reach people, and this means figuring out how to get this web thing to work.
Is author new at the whole web thing? Yes, people trust remote web servers. Yes, if you link multiple apps to an identity server (be it atproto, google, or self-hosted OpenID server), and your identity server is compromised, attacker will be able to impersonate you or lock you out.
This is just how the web works, and there is no easy around it without losing features people care about. Sure, you can do client-side encryption and pretend serve can't see the plaintext, but it's just a theatre, see Hushmail incident for example.
And having people export uber-key by default is pretty terrible idea. Sure, allow advanced users (like post author) to do it. But for the common person, the exported key is just another way to get account compromised, via malware or backup provider hacking. Or if they are not backing up stuff, then the key will get lost next time they upgrade.
Perhaps read the text? Literally the first paragraph:
> They show students how to use tools known as humanizers and autotypers, which make it easier than ever to cheat.
and later:
> Autotypers slowly drip words and sentences into documents, making it appear as if papers were typed at a human pace when in fact, they were produced by A.I. They even fabricate typos, deletions and revisions.