_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Cursed Knowledge
physicles wrote 1 hour 26 min ago:
Back in 2011, I wasted an entire afternoon on some string handling code
that was behaving very strangely (I donât remember exactly what the
code was).
It wasnât until I loaded the content into a hex editor that I learned
about U+00A0, the non-breaking space. Looks like a space, but isnât.
hiAndrewQuinn wrote 1 hour 53 min ago:
>The bcrypt implementation only uses the first 72 bytes of a string.
Any characters after that are ignored.
Is there any good reason for this one in particular?
stogot wrote 2 hours 16 min ago:
This is the best thing Iâve read on hacker news all year
burnt-resistor wrote 3 hours 19 min ago:
Install an SP3 or TR4 socketed CPU in a dusty, dirty room without ESD
precautions and crank the torque on the top plate and heat sink like
truck lug nuts until creaking and cracking noises of the PCB
delaminating are noticeable. Also be sure to sneeze on the socket's
chip contacts and clean it violently with an oily and dusty microfiber
cloth to bend every pin.
c. 2004 and random crap on eBay: DL380 G3 standard NICs plus Cisco
switches with auto speed negotiation on both sides have built-in chaos
monkey duplex flapping.
Google's/Nest mesh Wi-Fi gear really, really enjoys being close
together so much that it offers slower speeds than simply 1 device. Not
even half speed, like dial-up before 56K on random devices randomly.
Havoc wrote 3 hours 55 min ago:
One can really sense the pain just reading the headings
Also a crypto library that limits passwords to 72 bytes? Thatâs wild
AstralStorm wrote 3 hours 1 min ago:
It's written with constant memory allocation in mind. Silly of them
to use such a small buffer though, make it a configuration option.
nothrabannosir wrote 11 min ago:
I assumed all hashes are in O(1) space? Is there any thatâs not?
Ygg2 wrote 4 hours 11 min ago:
Why is the YAML part cursed? They serialize to same string, no? Both
[1] and [2] serialize to identical strings. This seems like the ancient
YAML 1.1 parser curse strikes again. [1]
[2]
URI [1]: https://play.yaml.io/main/parser?input=ICAgICAgdGVzdDogPi0KICA...
URI [2]: https://play.yaml.io/main/parser?input=ICAgICAgdGVzdDogPi0KICA...
qbane wrote 4 hours 27 min ago:
Love to see this concept condensed! This kind of knowledge will only
emerge only after you dive in your project and surprisingly find things
do not work as thought (inevitable if the project is niche enough).
Will keep a list like that for every future project.
egruy wrote 5 hours 43 min ago:
Reminds me a lot of phenomenal Hadoop and Kerberos: Madness beyond the
gates[1], which coincidentally saved me many times from madness. Thanks
Steve, I can't fathom what you had to go through to get the cursed
knowledge!
1 -
URI [1]: https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/
maxbond wrote 6 hours 33 min ago:
> Fetch requests in Cloudflare Workers use http by default, even if you
explicitly specify https, which can often cause redirect loops.
This is whack as hell but doesn't seem to be the default? This issue
was caused by the "Flexible" mode, but the docs say "Automatic" is the
default? (Maybe it was the default at the time?)
> Automatic SSL/TLS (default)
URI [1]: https://developers.cloudflare.com/ssl/origin-configuration/ssl...
bo0tzz wrote 2 hours 18 min ago:
It was indeed the default at the time.
motorest wrote 6 hours 22 min ago:
> This is whack as hell but doesn't seem to be the default?
I don't think so. If you read about what Flexible SSL means, you are
getting exactly what you are asking for. [1] Here is a direct quote
of the recommendation on how this feature was designed to be used:
> Choose this option when you cannot set up an SSL certificate on
your origin or your origin does not support SSL/TLS.
Furthermore, Cloudflare's page on encryption modes provides this
description of their flexible mode.
> Flexible : Traffic from browsers to Cloudflare can be encrypted via
HTTPS, but traffic from Cloudflare to the origin server is not. This
mode is common for origins that do not support TLS, though upgrading
the origin configuration is recommended whenever possible.
So, people go out of their way to set an encryption mode that was
designed to forward requests to origin servers that do not or cannot
support HTTPS connections, and then are surprised those outbound
connections to their origin servers are not HTTPS.
URI [1]: https://developers.cloudflare.com/ssl/origin-configuration/s...
maxbond wrote 6 hours 12 min ago:
I get that it's a compatibility workaround (I did look at the docs
before posting) but it's a.) super dangerous and b.) apparently was
surprising to the authors of this post. I'm gunnuh keep describing
"communicate with your backend in plain text and get caught in
infinite redirect loops mode" whack but reasonable people may
disagree.
I would like to know how this setting got enabled, however. And I
don't think the document should describe it as a "default" if it
isn't one.
motorest wrote 5 hours 39 min ago:
> I get that it's a compatibility workaround (...) but it's a.)
super dangerous (...)
It's a custom mode where you explicitly configure your own
requests to your own origin server to be HTTP instead of HTTPS.
Even Cloudflare discourages the use of this mode, and you need to
go way out of your way to explicitly enable it.
> (...) apparently was surprising to the authors of this post.
The post is quite old, and perhaps Cloudflare's documentation was
stale back then. However, it is practically impossible to set
flexible mode being aware of what it means and what it does.
> I would like to know how this setting got enabled, however.
Cloudflare's docs state this is a custom encryption mode that is
not set by default and you need to purposely go to the custom
encryption mode config panel to pick this option among half a
dozen other options.
Perhaps this was not how things were done back then, but as it
stands this is hardly surprising or a gotcha. You need to go way
out of your way to configure Cloudflare to do what amounts to TLS
termination at the edge, and to do so you need to skip a bunch of
options that enforce https.
maxbond wrote 1 hour 57 min ago:
It seems like you think I'm operating under a misunderstanding
as a result of not having looked at the docs. I looked at them
before commenting, and described them accurately if tersely in
my original comment. We just disagree.
I didn't mean "I would like to know" in some sort of
conspiratorial way, I just thought there was a story to be told
there.
tonyhart7 wrote 6 hours 42 min ago:
ok but this one is not cursed tho ( [1] )
its valid privacy and security on how mobile OS handle permission
URI [1]: https://github.com/immich-app/immich/discussions/11268
csours wrote 8 hours 57 min ago:
You can load Java Classes into Oracle DB and run them natively inside
the server.
Those classes can call stored procedures or functions.
Those classes can be called BY stored procedures or functions.
You can call stored procedures and functions from server-side Java
code.
So you can have a java app call a stored proc call a java class call a
stored proc ...
Yes. Yes, this is why they call it Legacy.
binary132 wrote 9 hours 42 min ago:
This would be a fun github repo. Kind of like Awesome X, but Cursed.
joshdavham wrote 9 hours 56 min ago:
This is awesome! Does anyone else wanna share some of the cursed
knowledge they've picked up?
For me, MacOS file names are cursed:
1. Filenames in MacOS are case-INsensitive, meaning file.txt and
FILE.txt are equivalent
2. Filenames in MacOS, when saved in NFC, may be converted to NFD
burnt-resistor wrote 3 hours 36 min ago:
Yep. Create a case-sensitive APFS or HFS+ volume for system or data,
and it guarantees problems.
nothrabannosir wrote 13 min ago:
Iâve done this with my main drive for the last ten or so years
and run into not a single problem. I recommend it.
qingcharles wrote 4 hours 20 min ago:
I created one of the first CDDBs in 1995 when Windows 95 was in beta.
It came with a file, IIRC, cdplayer.ini, that contained all the track
names you'd typed in from your CDs.
I put out requests across the Net, mostly Usenet at the time, and
people sent me their track listings and I would put out a new file
every day with the new additions.
Until I hit 64KB which is the max size of an .ini file under Windows,
I guess. And that was the end of that project.
mdaniel wrote 9 hours 6 min ago:
1 is only true by default, both HFS and APFS have case sensitive
options . NTFS also behaves like you described, and I believe the
distinction is that the filesystems are case-retentive, so this will
work fine:
$ echo yup > README.txt
$ cat ReAdMe.TXT
yup
$ ls
README.txt
Maybe the cursed version of the filesystem story is that goddamn
Steam refuses to install on the case sensitive version of the
filesystem, although Steam has a Linux version. Asshats
qdw wrote 9 hours 58 min ago:
One of their line items complains about being unable to bind 65k
PostgreSQL placeholders (the linked post calls them "parameters") in a
single query. This is a cursed idea to begin with, so I can't fully
blame PostgreSQL.
From the linked GitHub issue comments, it looks like they adopted the
sensible approach of refactoring their ORM so that it splits the big
query into several smaller queries. Anecdotally, I've found 3,000 to
5,000 rows per write query to be a good ratio.
Someone else suggested first loading the data into a temp table and
then joining against that, which would have further improved
performance, especially if they wrote it as a COPY ⦠FROM. But the
idea was scrapped (also sensibly) for requiring too many app code
changes.
Overall, this was quite an illuminating tome of cursed knowledge, all
good warnings to have. Nicely done!
Aeolun wrote 28 min ago:
I donât think that makes intuitive sense. Whether I send 50k rows
or 10x5k rows should make no difference to the database. But somehow
it does. Itâs especially annoying with PG, where you just cannot
commit a whole lot of small values fast due to this weird limit.
motorest wrote 2 hours 57 min ago:
> This is a cursed idea to begin with, so I can't fully blame
PostgreSQL.
After going through the list, I was left with the impression that the
"cursed" list doesn't really refers to gotchas per se but to lessons
learned by the developers who committed them. Clearly a couple of
lessons are incomplete or still in progress, though. This doesn't
take away from their value of significance, but it helps frame the
"curses" as persona observations in an engineering log instead of
statements of fact.
burnt-resistor wrote 3 hours 12 min ago:
Or people who try to send every filename on a system through xargs in
a single command process invocation as arguments (argv) without
NUL-terminated strings. Just hope there are no odd or corrupt
filenames, and plenty of memory. Oopsie. find -print0 with parallel
-0/xargs -0 are usually your friends.
Also, sed and grep without LC_ALL=C can result in the fun "invalid
multibyte sequence".
Terr_ wrote 3 hours 29 min ago:
> One of their line items complains about being unable to bind 65k
PostgreSQL placeholders (the linked post calls them "parameters") in
a single query.
I've actually encountered this one, it involved an ORM upserting lots
of records, and how some tables had SQL array-of-T types, where each
item being inserted consumes one bind placeholder.
That made it an intermittent/unreliable error, since even though two
runs might try to touch the same number of rows and columns, you the
number of bind-variables needed for the array stuff fluctuated.
fdr wrote 8 hours 32 min ago:
that also popped out at me: binding that many parameters is cursed.
You really gotta use COPY (in most cases).
I'll give you a real cursed Postgres one: prepared statement names
are silently truncated to NAMEDATALEN-1. NAMEDATALEN is 64. This goes
back to 2001...or rather, that's when NAMEDATALEN was increased in
size from 32. The truncation behavior itself is older still. It's
something ORMs need to know about it -- few humans are preparing
statement names of sixty-plus characters.
antonvs wrote 4 hours 19 min ago:
> few humans are preparing statement names of sixty-plus
characters.
Java developers: hold my beer
eadmund wrote 3 hours 5 min ago:
Hey, if I donât name this class
AbstractBeanFactoryVisitorCommandPatternImplementorFactoryFactory
FactorySlapObserver how would you know what it does?
e1g wrote 8 hours 45 min ago:
Another strategy is to pass your values as an array param (e.g.,
text[] or int[] etc) - PG is perfectly happy to handle those. Using
ANY() is marginally slower than IN(), but you have a single param
with many IDs inside it. Maybe their ORM didnât support that.
godelski wrote 10 hours 13 min ago:
Looks like they're missing one. I'm pretty sure the discussion goes
further back[0,1] but this one has been on going for years and seems to
be the main one[2]
05/26/23(?) Datetimes in EXIF metadata are cursed
[0] [1] [2]
URI [1]: https://github.com/immich-app/immich/discussions/2581
URI [2]: https://github.com/immich-app/immich/issues/6623
URI [3]: https://github.com/immich-app/immich/discussions/12292
a96 wrote 6 hours 47 min ago:
Datetimes in general have have a tendency to be cursed. Even when
they work, something adjacent is going to blow up sooner or later.
Especially if it relies on timezones or DST being in the value.
burnt-resistor wrote 11 hours 8 min ago:
- Windows' NTFS Alternate Data Streams (ADS) allows hiding an unlimited
number of files in already existing files
- macOS data forks, xattrs, and Spotlight (md) indexing every single
removable volume by default adds tons of hidden files and junk to files
on said removable volumes. Solution: mdutil -X /Volumes/path/to/vol
- Everything with opt-out telemetry: go, yarn, meilisearch, homebrew,
vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk,
OpenShift, Firefox, Chrome, flutter, and zillions of other corporate
abominations
TheBicPen wrote 4 hours 2 min ago:
Opt-out telemetry is the only useful kind of telemetry
matheusmoreira wrote 1 min ago:
Its usefulness is completely irrelevant. We do not want it to
happen under any circumstances.
salawat wrote 1 hour 40 min ago:
Forces me to fork your shit and remove privacy invasive parts.
Consider my computer my home, and your telemetry a camera or
microphone you're adding to my place.
If you don't ask me for permission first I have no reason to trust
you will maintain any semblance of integrity in the long run.
burnt-resistor wrote 3 hours 43 min ago:
Not useful to me or most users. See, other people besides you have
different values like privacy and consent.
kirici wrote 8 hours 36 min ago:
>opt-out telemetry: go
By default, telemetry data is kept only on the local computer, but
users may opt in to uploading an approved subset of telemetry data to
[1] .
To opt in to uploading telemetry data to the Go team, run:
go telemetry on
To completely disable telemetry, including local collection, run:
go telemetry off
URI [1]: https://telemetry.go.dev
URI [2]: https://go.dev/doc/telemetry
burnt-resistor wrote 3 hours 44 min ago:
Yep, but you're techsplaining to someone who already know this. But
still, it's not opt-in. It's always on by default and litters stuff
without asking. All that does is create a file but that doesn't
remove the traces of all the tracking it leaves behind without
asking. This fixes it in a oneliner:
# mac, bsd, linux, and wsl only
(d="${XDG_CONFIG_HOME:-$HOME/.config}/go/telemetry";rm -rf
"$d";mkdir -p "$d"&&echo off>"$d/mode")
thorum wrote 11 hours 24 min ago:
> npm scripts make a http call to the npm registry each time they run,
which means they are a terrible way to execute a health check.
Is this true? I couldnât find another source discussing it. That
would be insane behavior for a package manager.
skacekamen wrote 4 hours 58 min ago:
probably an update check? It definitely sometimes shows an update
banner
dgoldstein0 wrote 6 hours 25 min ago:
It might be referring to the check if whether npm is up to date so it
can prompt you to update if it isn't?
simpaticoder wrote 11 hours 33 min ago:
I loved this the moment I saw it. After looking at an example
commit[1], I love it even more. The cursed knowledge entry is committed
alongside the fix needed to address it. My first instinct is that every
project should have a similar facility. The log is not just cathartic,
but turns each frustrating speedbump into a positive learning
experience. By making it public, it becomes both a tool for both
commiseration and prevention.
1 -
URI [1]: https://github.com/savely-krasovsky/immich/commit/aeb5368602db...
delusional wrote 3 hours 22 min ago:
I agree, I usually put this sort of information in the commit message
itself. That way it's right there if anybody ever comes across the
line and wonders "why did he write this terrible code, can't you just
___".
motorest wrote 3 hours 1 min ago:
As a side note, it's becoming increasingly important to write down
this info in places where LLMs can access it with the right
context. Unfortunately commit history is not one of those spots.
pushedx wrote 56 min ago:
There's no reason that an LLM couldn't (or isn't) being trained
on commit messages.
No difference between a git index and any other binary data (like
video).
motorest wrote 17 min ago:
> There's no reason that an LLM couldn't (or isn't) being
trained on commit messages.
You are arguing that it could. Hypotheticals.
But getting back to reality, today no coding assistant supports
building system prompts from commit history. This means it
doesn't. This is a statement of fact, not an hypothetical.
If you post context in commit messages, it is not used. If you
dump a markdown file in the repo, it is used automaticaly.
What part are you having a hard time understanding?
mejutoco wrote 11 min ago:
There are MCP Servers that give access to git repo
information to any LLM supporting MCP Servers.
For example:
>The GitHub MCP Server connects AI tools directly to GitHub's
platform. This gives AI agents, assistants, and chatbots the
ability to read repositories and code files, manage issues
and PRs, analyze code, and automate workflows. All through
natural language interactions.
source:
URI [1]: https://github.com/github/github-mcp-server
rf15 wrote 2 hours 5 min ago:
You are sadly completely missing the point of ever-self-improving
automation. Just also use the commit history. Better yet: don't
be a bot slave that is controlled and limited by their tools.
motorest wrote 24 min ago:
> You are sadly completely missing the point of
ever-self-improving automation. Just also use the commit
history.
I don't think you understand the issue you're commenting on.
It's irrelevant whether you can inject commit history in a
prompt.
The whole point is that today's support for coding assistants
does not support this source of data, whereas comments in
source files and even README.md and markdown files in ./docs
are supported out of the box.
If you rely on commit history to provide context to your team
members, once they start using LLMs this context is completely
ignored and omitted from any output. This means you've been
providing context that's useles and doesn't have any impact on
future changes.
If you actually want to help the project, you need to pay
attention on whether your contributions are impactful. Dumping
comments into what amounts to /dev/null has no impact
whatsoever. Requiring your team to go way out of their way to
include in each prompt extra context from a weird source that
may or may not be relevant is a sure way to ensure no one uses
it.
LeoPanthera wrote 12 hours 4 min ago:
"Some phones will silently strip GPS data from images when apps without
location permission try to access them."
Uh... good?
a96 wrote 6 hours 45 min ago:
Kind of. But that means any file that goes through that mechanism may
be silently modified. Which is evil.
steve_adams_86 wrote 11 hours 59 min ago:
I'm torn. Maybe a better approach would be a prompt saying "you're
giving access to images with embedded location data. Do you want to
keep the location data in the images, or strip the location data in
this application?"
I might not want an application to know my current, active location.
But it might be useful for it to get location data from images I give
it access to.
I do think if we have to choose between stripping nothing or always
stripping if there's no location access, this is the correct and safe
solution.
Aurornis wrote 10 hours 23 min ago:
> saying "you're giving access to images with embedded location
data. Do you want to keep the location data in the images, or strip
the location data in this application?"
This is a good example of a complex setting that makes sense to the
1% of users who understand the nuances of EXIF embedded location
data but confuses the 99% of users who use a product.
It would also become a nightmare to manage settings a per-image
basis.
fc417fc802 wrote 8 hours 51 min ago:
Not per-image, it would be per-app. The first time it happened it
would ask you. There are already quite a few per-app toggles for
things like this so it wouldn't be anything new or particularly
surprising.
That said, an alternative to bugging the user might be that when
the app makes the call to open the file that call should fail
unless the app explicitly passes a flag to strip the location
data. That way you protect users without causing needless
confusion for developers when things that ought to "just work" go
inexplicably wrong for them.
worik wrote 12 hours 16 min ago:
dd/mm/yyyy date formats are cursed....
Perhaps it is mm/dd/yyyy (really?!?) that is cursed....
javcasas wrote 1 hour 22 min ago:
mm/dd/yyyy is cursed. You parse it naively with momentjs, and some
times it parses (wrong), other times it doesn't parse.
It's the reason our codebase is filled with momentAmerican,
parseDateAmerican and parseDatetimeAmerican.
armchairhacker wrote 11 hours 51 min ago:
dd/mm/yyyy is most common worldwide (particularly Europe, India,
Australia) followed by yyyy/mm/dd (particularly China, Japan, South
Korea). [1] IMO the best format is yyyy/mm/dd because itâs
unambiguous (EDIT: almost) everywhere.
URI [1]: https://wikipedia.org/wiki/Date_and_time_representation_by_c...
Izkata wrote 11 hours 43 min ago:
For a really cursed one that breaks your last comment, check out
Kazakhstan on the list by country: [1] > Short format: (yyyy.dd.mm)
in Kazakh[95][obsolete source]
URI [1]: https://en.wikipedia.org/wiki/List_of_date_formats_by_coun...
o11c wrote 9 hours 46 min ago:
Even ISO has used the cursed date format.
ISO-IR-26 was registered on 1976/25/03.
accrual wrote 11 hours 44 min ago:
I like CCYY-MM-DD because it's also a valid file name on most
systems, and using "CCYY" (century + year) instead of "YYYY" feels
fancy.
Fwirt wrote 8 hours 15 min ago:
Except this could get confusing because the year 1976 (for
example) is actually in the 20th century.
fastball wrote 11 hours 48 min ago:
Not only is YYYY/MM/DD unambiguous, but it also sorts correctly by
date when you perform a naive alphabetical sort.
LoganDark wrote 9 hours 47 min ago:
I believe YYYY-MM-DD is even less ambiguous than YYYY/MM/DD.
a96 wrote 6 hours 44 min ago:
Correct. Slashes mean it's a yank date and going to be
backwards. Dashes hint that it's going to be (close to) ISO
standard.
tom_ wrote 2 hours 19 min ago:
Slashes are used for dd/mm/yyyy as well. Dashes are indeed
better if you want a separator. or use the separator-free ISO
8601 syntax.
_Algernon_ wrote 5 hours 14 min ago:
And it doesn't use a path-separator character for the date.
hollerith wrote 12 hours 10 min ago:
mm.dd.yyyy is cursed, too. The not-cursed options are dd.mm.yyyy and
mm/dd/yyyy
dmd wrote 11 hours 55 min ago:
in what world could mm/dd/yyyy not be cursed!? that makes no sense
whatsoever.
Izkata wrote 11 hours 49 min ago:
It's the US short form, matching the word-month order we always
use for regular dates: "August 7, 2025".
Note the slashes are important, we don't use dots or dashes with
this order. That's what GP was getting at.
chrismorgan wrote 7 hours 34 min ago:
> It's the US short form, matching the word-month order we
always use for regular dates: "August 7, 2025".
Counterexample: US Independence Day is called the âFourth of
Julyâ.
I would agree that, for dates with named months, the US mostly
writes âAugust 8, 2025â and says âAugust eighth, 2025â
(or sometimes âAugust eight, 2025â, I think?), and other
countries mostly write â8 August 2025â and say âthe
eighth of August, 2025â; but neither is absolute.
FridgeSeal wrote 9 hours 20 min ago:
The short form doesnât match the word form though.
If you wanted a short form to match the word form, you go with
something like:
âmmmm/dd/yyyyâ
Where mmmm is either letters, or a 2-character prefix. The word
form âAugust 7thâ¦â is packing more info that the short
form.
dmd wrote 11 hours 29 min ago:
And it makes absolutely no sense. I've lived with it all my
life (I'm an American!) and it has never made any sense to me.
hollerith wrote 8 hours 59 min ago:
Can you explain why on a traffic light, red means stop and
green means go? Why not the other way around?
a96 wrote 6 hours 42 min ago:
Red is an aggravating colour psychologically. It's pretty
universally used as a warning. Red lights in cars also mean
"not ready to drive". Brake lights are also red for similar
reason. "Seeing red."
fc417fc802 wrote 8 hours 46 min ago:
Because it's arbitrary. Unlike a date format where the
components have relative meaning to one another, can be
sorted based on various criteria, and should smoothly
integrate with other things.
As a US native let me clearly state that the US convention
for writing dates is utterly cursed. Our usage of it makes
even less sense than our continued refusal to adopt the
metric system.
kstrauser wrote 11 hours 6 min ago:
First, I use ISO8601 for everything. This is not me arguing
against it.
But, I think the American-style formatting is logical for
everyday use. When you're discussing a date, and you're not a
historian, the most common reason is that you're making plans
with someone else or talking about an upcoming event. That
means most dates you discuss on a daily basis will be in the
next 12 months. So starting with the month says approximately
when in the next year you're talking about, giving the day
next says when in that month, and then tacking on the year
confirms the common case that you mean the next occurrence of
it.
When's Thanksgiving? November (what part of the year?) 27
(toward the end of that November), 2025 (this year).
It's like answering how many minutes are in a day: 1
thousand, 4 hundred, and 40. You could say 40, 400, and 1000,
which is still correct, but everyone's going to look at you
weirdly. Answer "2025 (yeah, obviously), the 27th (of this
month?) of November (why didn't you start with that?)" is
also correct, but it sounds odd.
So 11/27/2025 starts with the most useful information and
works its way to the least, for the most common ways people
discuss dates with others. I get it. It makes since.
But I'll still use ISO8601.
out_of_protocol wrote 3 hours 17 min ago:
> So 11/27/2025 starts with the most useful information
Most useful information would be to not confuse it. E.g.
you see a event date 9/8/2025 and it's either tomorrow or a
month from now. Perfect 50/50% chance to miss it or make a
useless trip
g8oz wrote 12 hours 21 min ago:
This is awesome. Disappointing to hear about the Cloudflare fetch
issue.
motorest wrote 5 hours 34 min ago:
> Disappointing to hear about the Cloudflare fetch issue.
You mean the one where explicitly configuring Cloudflare to forward
requests to origin servers as HTTP will actually send requests as
HTTP? That is not what I would describe as disappointing.
g8oz wrote 1 hour 54 min ago:
The behavior seems likely to mislead a lot of people even if it
doesn't confuse you.
motorest wrote 20 min ago:
> The behavior seems likely to mislead a lot of people even if it
doesn't confuse you.
You need to go way out of your way to toggle a switch to enable
this feature.
The toggle says very prominently "Cloudflare allows HTTPS
connections between your visitor and Cloudflare, but all
connections between Cloudflare and your origin are made through
HTTP."
You proceed to enable this feature.
Does it confuse you that
Cloudflare's requests to your origin servers are HTTP?
doctorpangloss wrote 8 hours 59 min ago:
The infallibility of Cloudflare is sacrosanct!
bigyabai wrote 12 hours 31 min ago:
> Some phones will silently strip GPS data from images when apps
without location permission try to access them.
That's no curse, it's a protection hex!
8organicbits wrote 10 hours 32 min ago:
I think this is written unclearly. Looking at the linked issues, the
root cause seems to be related to a "all file access" permission, not
just fine grained location access.
It seems great that an app without location access cannot check
location via EXIF, but I'm surprised that "all file access" also
gates access to the metadata, perhaps one selected using the picker.
URI [1]: https://gitlab.com/CalyxOS/platform_packages_providers_Media...
nulld3v wrote 11 hours 8 min ago:
On the other hand, one particular app completely refuses to allow
users to remove location information from their photos:
URI [1]: https://support.google.com/photos/answer/6153599?hl=en&co=GE...
mynegation wrote 11 hours 12 min ago:
I have no idea what that means but to me it looks like it works as
designed.
Muromec wrote 12 hours 18 min ago:
A ward even
DIR <- back to front page