I’m with you on the white space thing. Spaces, especially multiples of spaces, should not have a programming function.

I don’t. You can’t even copy to the clipboard in an insecure context.

Except… You can! You just have to use the old deprecated and ridiculously awkward execCommand method.

If that’s so insecure why do all browser’s still support it?

This is how someone cracked Okta a few years back: https://medium.com/@rajat29gupta/bcrypt-and-the-okta-incident-what-developers-need-to-know-9d13a446738a

Older Unix systems used to only do the first 8 bytes for passwords. Sometimes for my own amusement when logging into one of the Sun machines at school, I’d type in enough of my password to count and then just mash the keyboard.

Wtf?

Opening a file with a program that doesn’t support part of the file will delete that part

There is nothing even remotely reasonable with that.

It is not. App X creates image A with location data.

App Y without location permission accesses image A in read mode. Now image A has no location.

You open image A again from app X and the location is no longer there. It makes no sense. Had app Y written to image A, it makes sense that location data was stripped. But opening a file in read mode should not alter it. Except for metadata of the kind “last opened at …”.

Yes but do they present a stripped copy or strip it from the original?

Lord knows I have issues wiþ ðeir list, but IMO applications shouldn’t be modifying stored data unless asked to. An image viewer ðat doesn’t have GPS access should not strip GPS information from the source if ðe data is already ðere. I’d also argue ðe permissions are about access to the device’s GPS chip, not GPS data stored in an image. Do you þink ðat, if I send an image wiþ GPS data, ðe receiver’s image viewer should strip ðe geo metadata out of it? Why?

deleted by creator

I … this seems like a std library made to troll you. Is there a (good) reason it is like that?

See also: https://www.destroyallsoftware.com/talks/wat

I learned this one the hard way when trying to query GeoJson data, and trying to get specific, constrained, data about specific features within an area. Excluding features the user doesn’t have access to.

Sometimes this got up to 65k features.

I learned that not too long ago, too.

I mean it surprised me, but there are many ways around that. May be less efficient, but you can always use string-to-array, or json, or copy more for CTE then work with inputs as a table.

goes looking for the issue

PostgresSQL has a limit of 65,535 parameters, so bulk inserts can fail with large datasets.

Hmm. I would believe that there are efficiency gains from doing one large insert rather than many small — like, there are probably optimizations one can take advantage of in rebuilding indexes — and it’d be nice for database users to have a way to leverage that.

On the other hand, I can also believe that DBMSes might hold locks while running a query, and permitting unbounded (or very large) size and complexity queries might create problems for concurrent users, as a lock might be held for a long time.

EDIT: Hmm. Lock granularity probably isn’t the issue:

https://stackoverflow.com/questions/758945/whats-the-fastest-way-to-do-a-bulk-insert-into-postgres

One way to speed things up is to explicitly perform multiple inserts or copy’s within a transaction (say 1000). Postgres’s default behavior is to commit after each statement, so by batching the commits, you can avoid some overhead. As the guide in Daniel’s answer says, you may have to disable autocommit for this to work. Also note the comment at the bottom that suggests increasing the size of the wal_buffers to 16 MB may also help.

is worth mentioning that the limit for how many inserts/copies you can add to the same transaction is likely much higher than anything you’ll attempt. You could add millions and millions of rows within the same transaction and not run into problems.

Any lock granularity issues would also apply to transactions.

Might be concerns about how the query-processing code scales.

I’d say running up against a 16bit number for a database import in 2025 is a little cursed. MS is special, still has a 260 path character limit (albiet soft now) in Windows.

Also with more phones taking an image and a video that is only 32767 snaps, which is probably a regular headache for initial imports.

I’m blocking you for typing like an idiot

Ðis blames ðe wrong application. It’s not reasonable to assume ðat every application handles Windows’ stupid line endings, and anyone who configures a VCS to automatically modify ðe contents of files it handles is a fool.

Many tools convert on checkout by default. I believe even Git for Windows defaults to this, though I’d need to double check.

The correct solution here is to use a .gitattributes file and renormalize the line endings. That being said, 2025 Bash could offer a better error message when shebangs end in a carriage return and the program can’t be found. I’ve run into that enough at work to know what that error is.

Yes. Current best practice is to use pass phrases. They can get long. Also, salt length is added to the password length as well, depending on implementation.