This is true, but I'm not sure if I trust users to preserve case in case-insensitive filenames when copying files around, possibly at some point passing through something like a web server that may apply case normalization. Sort of like timestamps on files, they're handy for things like synchronization, but I hesitate before relying on them as a primary source of truth for anything mission critical.
Practically? Quite a few codebases from *nix systems rely on the case sensitivity. To do a successful git clone you need a file system that handles both Makefile and makefile, or whatever.
I ran into it more than once back in the day when I used Mac OS X as my primary OS.
More generally -- case sensitivity is a conceptual nightmare in the Unicode era. Should Cyrillic or Greek be case-insensitive as well? Etc. Do you really want the full complexity of Unicode string handling in your file system?
I would suggest treating file names like raw bytes. On modern Linux, anything but NUL is valid.
Sometimes you download stuff that relies on case sensitivity. Anyone who's dealt with this probably has a sensitive RW DMG lying around for this reason. But macOS FSes default to case-insensitive, so random issues come up if you make your root sensitive (famously in Adobe software). Damned if you do or don't.
Another weird thing in macOS:
$ mkdir Cased
$ cd cased
$ pwd
/Users/me/Downloads/cased
$ cd ../Cased && pwd
/Users/me/Downloads/Cased
So yeah I wish the FS defaulted to sensitive, even though I never rely on that. Not its job to normalize names.
-L Display the logical current working directory.
-P Display the physical current working directory (all symbolic links resolved).
If no options are specified, the -L option is assumed.
In Bash and many modern POSIX shells, `pwd` is a builtin, not to mention an environment variable ${PWD}, but the POSIX system should also provide an external command, such as `/bin/pwd` that would operate on the filesystem, rather than semantically tracking your shell activity.
It can be nice to checkout some Git repositories that have this. It can also be nice to catch miscapitalizations of filename imports when those would fail on Linux, etc. One of my past workplaces actually had that problem, they mis-cased imports and the product failed to build on Linux. Nobody caught it because they all used macOS or Windows, I was the first to try WSL (this was before I switched back to Mac)
You would be asking for a world of hurt to put your root filesystem in a case-sensitive volume though. All sorts of software and applications have silently relied on case-insensitivity for decades. You can sometimes fix it on a case-by-case basis, but sometimes you can't, and it's also annoying for it to happen in the first place. Better to have a separate case-sensitive volume just for the stuff you want to be case-sensitive.
Mostly consistency in knowing that Foo will become foo. This is a problem when it comes to (for example) supporting devs on Windows working on a codebase with prod on Linux. The database dbCustomer would be renamed dbcustomer on Windows.
There are workarounds, and containerization is a better idea, but you asked why you might want this.
Yes, but you have to admit that the existence of these SLDs (like co.uk) is always going to be a point of confusion for anyone with a basic knowledge of how the domain hierarchy _usually_ works.
Needing to be familiar with all the special cases (like the VERY special case of x.y.name which I previously knew nothing about) kind of ruins everything and introduces yet more security risk.
> but you have to admit that the existence of these SLDs (like co.uk)
I'm sorry, what ? Admit ? Confusion ?
In the case of .co.uk it has been around since 1996. HN is a technical forum, most people here should be well aware it is a serious SLD. I honestly can't believe it even needs clarifying.
Hell, if you use AWS Route 53 you'll see they use co.uk as one of their nameserver suffixes[1].
I'm not referring to the HN audience; I mean the larger evergreen cohort of people in the world who are still building their mental model of how the web works. They will each eventually be doomed to the same misconceptions because it's a system full of inconsistencies and special cases.
> I think the non-profit has around 25% ownership of something that is around a trillion dollars of on-paper money.
But the purpose of a non profit is not to maximise profit in a for profit investment.
How well is non profit doing at furthering its goals? It formerly had the purpose of “safely” ensuring artificial intelligence benefits all of humanity. It looks like it gave up on that so its staff could be incredibly rich.
Do you not think money provides some ability to achieve goals? Fund raising is an integral part of most non-profits.
But you ignored the part about influence, would an OpenAI that did not scale up and had no world beating models have much of a say in how AI gets developed
This is not to say that I think they are doing everything right, but I see people bitter that they didn't take the path towards forgotten irrelivance.
What would you reccommend that they should have done that would still lead to them being relevant to the world development of AI?
Frankly the non-profit has failed. OpenAI is one of the least open of the AI companies (Anthropic is a bit worse). If it wasn't for the labs in China the dream of an actual open ai system would be dead.
I feel like people don’t give OpenAI enough credit for the early papers they did publish. Those are what showed the way that everyone else has built on.
With this being open sourced, and being the integration and creation of several fast components, this becomes an obvious recommendation for JS/TS. Similar to Cargo for Rust and uv for Python, yes?
The page summarises the license as “Basically… the MIT do-whatever-you-want license”. The MIT license is of course one of the most popular permissive open source licenses.
This is an incredibly misleading comparison. The subsequent clause is a complete contradiction, not a subtle clarification.
I wonder if the Paris city hall can do a rebate program of "Dear Paris residents, mail in your ticket stub and we'll give you a partial refund" - this is a first draft of an idea, it's flawed because it would lead to opportunistic Parisians asking tourists for their ticket stubs, and then telling the city hall that they visited the Louvre 30 times last month.
No, they can't, EU courts would strike that in a heartbeat.
Some time ago Germans tried to tax foreign drivers on their roads, so they introduced toll, nominally for all, but also lowered the same amount another car-related tax that was paid only by Germans. EU bodies saw through the scheme just fine and now they're on hook for returning the toll money to anyone still keeping the invoice/receipt.
Half yes, probably discarded, but the other half are in company books, because those were accounted as costs of operations. Even then, yes, probably worth it for the time.
There are only charging Germans right now. They wanted to extend that to foreigners, so if you wouldn't lower the tax that pays for this right now, you would charge Germans double.
Of course this is against the interest of other countries, which is why they prevented that, but it wasn't unfair or discrimination.
Often in these conversations we forget that editing is different from editorializing. Editing can make meaning clearer! (In this example, reactions are mixed as to whether it was successful).
Editorializing, on the other hand, is about adding clickbait or bias.
reply