This sounds like a classic case of "35% of statistics are made up"

Over 50% of people have a below average understanding of statistics.

That's funny. In my study it was 70%. Nah, make that 85%.

Aren't there licesing issues with porting a proprietary implementation into an open-source one that could open up the project to legal issues with the proprietary vendor?

The Plasticity guy seems to be threading that needle.

That might seem to be the case, right up until he gets taken to court over it.

Never presume that a thing is legal (or will not later be punished) on the basis that someone is already doing it.

You can't stop it. This is just progress.

All software that isn't delivered over client/server to thin clients is now subject to being trivially cloned.

That was never in question, even before AI. It just took more monkeys at typewriters.

How do I opt out of this for my own private repos? I don't see anything related to this as I've got a ton of settings for Copilot itself (I have access to Copilot through my work org)

https://github.com/settings/copilot/features, it's near the bottom "Allow GitHub to use my data for AI model training"

I believe it is under:

Settings->Copilot->Features->Privacy=>[ Allow GitHub to use my data for AI model training

Allow GitHub to collect and use my Inputs, Outputs, and associated context to train and improve AI models. Read more in the Privacy Statement. ]

Under privacy.

> Allow GitHub to use my data for AI model training

I don't see this. Might be a regional/geofenced thing with the EU, not sure. Or because I have a corporate Copilot license through my day job org.

Strange, looks like I don't have that option at all

https://postimg.cc/LJD5w1rv

I don't see it there, but I do see it in screenshots online. Maybe it was removed or moved.

Still at https://github.com/settings/copilot/features#copilot-telemet... for me.

It's not a new setting, fwiw. I opted out years(??) ago.

Huh, there must be some reason it shows up for some people but not others. Weird.

> I guess the equivalent would be if I could ask you to send a PDF to my specific IPv6 address, and you could peer-to-peer shoot it directly to me.

That's not exactly complicated if either party owns a web server. Which - last I checked - the government has.

Just give the person who needs to send the sensitive documents a short link like uploaddocuments.gov, have that page ask for some basic identifying info, and have a box for the user to drag and drop a file. At which point the browser will p2p upload that file over HTTPS.

That’s kinda true, but adds a few steps over cmd-P “print to fax”, paste in a phone number, done. And when done, the fax workflow has been tested and approved in courts. It’s a known entity.

I don’t love faxes. This isn’t me saying we should keep them forever. We shouldn’t. Still, there are reasons they’re still widely used for medical stuff today. If CMS or HHS rolled out a new method and told doctor’s offices to start using it if they want to get paid, the industry would switch in a heartbeat. Short of that, any other alternative will take approximately forever.

We still deal with doctors who handwrite their progress notes. Fax will be around for a very, very long time.

Well, that too.

In addition to this article, I've recently read this one [1], where the reported received numerous violence and death threats from people who wanted him to change the a story he published to match what they bet on Polymarket.

[1] https://www.timesofisrael.com/gamblers-trying-to-win-a-bet-o...

Yeah this is a much more likely outcome of unregulated gambling... I expect to hear a LOT more of this. Also plan for a swift, complete erosion of trust in sports officiating.

Fedora also wants to reboot to install (dnf) updates offline, as I understand it's to prevent potential instability from running processes getting confused when their files get swapped out under their feet.

It's also good since you can't swap out the kernel without rebooting.

I assume Microsoft took the same approach, just replace everything offline then reboot into a fully up-to-date system without any chance of things in RAM still being outdated.

> It's also good since you can't swap out the kernel without rebooting.

Yeah you can. Ksplice.com We got bought by Oracle so it's in their ecosystem but the technology exists.

The point isn't "run the Linux kernel on a phone", the point is "run an non-big-tech OS that respects the user's privacy and choices". See also Google's recent announcement regarding locking down Android app installation to "protect users"

That's not what was said here, though - and also not something that's going to become a viable major platform.

The folks who care about privacy can't agree on the definition of a privacy respecting phone, so whatever you make some of them will be unhappy. 99.9% users care way more about price, availability of apps, and hardware, in that order. App developers will only write apps for the platform once it has sufficient users, and users will only switch if the platform has sufficient apps.

Yeah I got 7284 as well on the first try. My second session got 7384.

Not for local password authentication.

https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...

Yes, for local password authentication.

The code you linked to isn't the code for a wrong password. It's a check to make sure you're using a TTY. That code isn't to prevent brute force. The delay there is 10 seconds.

The 2 second delay is in support.c at https://github.com/pibara/pam_unix/blob/5727103caa9404f03ef0...

It only runs if "nodelay" is not set. But you might have another pam module setting its own delay. I have pam_faildelay.so set in /etc/pam.d/login

Change both the config files and you can remove the delay if you want.

> Yes, for local password authentication.

It's really really not. By default PAM has a difficult-to-disable 2ish second minimum delay for all authentication methods. However this is completely pointless for local password authentication because PAM checks password using unix_chkpwd, which has no delay. The comment I linked to is explaining that unix_chkpwd has a silly security theatre delay if you try to run it in a tty, but that's trivial to avoid.

If you want to brute force local password authentication you can just run unix_chkpwd as fast as you like. You don't need to involve PAM at all, so its 2 seconds delay achieves nothing.

It maybe does more for remote connections but I'm not sure about that either - if you want to check 10k ssh passwords per second what stops you making 10k separate connections every second? I don't think the 2 second delay helps there at all.

> Change both the config files and you can remove the delay if you want.

This is extremely complicated. See the comments in the issue for details.

No, it's very simple. Do what I said in my comment. Add nodelay to the options for pam_unix.so and set pam_faildelay.so delay=0

That's it. You didn't link to any issue and the weird mistakes and justifications you're making feels like arguing with an LLM.

You obviously can't run unix_chkpwd against a local account without root.

> You obviously can't run unix_chkpwd against a local account without root.

Wrong. At least check before you say something is obvious.

> No, it's very simple.

Even more wrong: https://github.com/linux-pam/linux-pam/issues/778#issuecomme...

> feels like arguing with an LLM

I could say the same about you, repeatedly and confidently asserting falsehoods.

No, I'm right. You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash. If you think you can, explain how. Otherwise you have to use the setuid version which won't let you run it directly.

And I just removed the delay using my method. Perhaps try checking something yourself?

I don't understand how you can be so confidently wrong about something so easily checked. :D

> You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash.

unix_chkpwd can access /etc/shadow because it is suid.

> Otherwise you have to use the setuid version which won't let you run it directly.

Haha you mean this?

  $ unix_chkpwd
  This binary is not designed for running in this way
  -- the system administrator has been informed

Take a look at the source code I linked about 6 comments ago!

> Perhaps try checking something yourself?

I have. You haven't.

  printf 'hunter2\0' | unix_chkpwd yourusername nullok; echo $?

How large are a couple of 1080p PNG screenshots? 0.5MiB?