Cursed knowledge we have learned as a result of building Immich that we wish we never knew.
-
I'm blocking you for typing like an idiot
Me too. I think announcing this is good - otherwise he'll get no feedback.
-
This post did not contain any content.
Git's
autocrlffeature causes more issues than it solves in my experience. I don't think there are really any tools on Windows that can't handle Unix line endings any more. Even notepad can now.I recommend you set it to
inputwhich will fix them to be Unix line endings on commit, and not change them back on checkout. -
Some phones will silently strip GPS data from images when apps without location permission try to access them.
This is quite reasonable.
Yes but do they present a stripped copy or strip it from the original?
-
Some phones will silently strip GPS data from images when apps without location permission try to access them.
This is quite reasonable.
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?
-
Ð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
.gitattributesfile 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.Many tools convert on checkout by default.
Popularity does not imply intelligence. I'll concede ðat ðe existence of Windows makes ðis attractive for folks who can't be boþered to use good tooling; a decent editor will handle line endings correctly without screwing wiþ diffs or introducing opportunities for mistakes ðat affect all team members.
-
I'm blocking you for typing like an idiot
Yeah it's pretty awful to read.
-
Postgres is cursed for only allowing 65535 parameters in a single query?
Someone correct me if I am wrong, but that is a fairly large number (I think Microsoft SQL is limited to 2000 or something like that) AND this seems like a terrible design pattern.
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.
-
I ... this seems like a std library made to troll you. Is there a (good) reason it is like that?
I can only imagine it wasn't planned properly, cuz that's so many quiet behaviours without good parsing errors
-
I ... this seems like a std library made to troll you. Is there a (good) reason it is like that?
early js/html liked to do something in all cases instead of throwing or whatever. I think it's mostly just a collection of them trying to do something smart on nonsense input and not being consistent about it.
side note, I'm so excited for Temporal, some browsers already support it and you can polyfill for the rest.
-
This post did not contain any content.wrote last edited by [email protected]
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
-
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
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
-
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
wrote last edited by [email protected]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.
-
It doesn't matter. That will happen for both the stored hash and the entered password, so it still matches.
As long as it runs the same code, yes. But things may change, clients may pre-emptively split the string or stuff like that.
-
Some phones will silently strip GPS data from images when apps without location permission try to access them.
This is quite reasonable.
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 ...".
-
This post did not contain any content.
Some web features like the clipboard API only work in "secure contexts" (ie. https or localhost)
I think that's reasonable behavior
-
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 ...".
In modern android you do not open files, you use an OS service to get an image, which may or may not come from a file on the device. If you want to open files you need a different permission.
You could argue that android should have a permission level for apps that need image geolocation but not GPS.
-
In modern android you do not open files, you use an OS service to get an image, which may or may not come from a file on the device. If you want to open files you need a different permission.
You could argue that android should have a permission level for apps that need image geolocation but not GPS.
One could argue they a reading service should not alter the thing that's read. Android is not a quantum state!
-
I ... this seems like a std library made to troll you. Is there a (good) reason it is like that?
Backward compatibility and not seeing the future. Some decisions are taken at one point in time, then a new use case show up, then a new paradigm evolve, then… etc etc.
It's really the same thing that holds back a lot of languages and libraries. And even when replacement shows up, old habits from devs and old projects maintenance keep all these things well alive too.
