~] ls -l /System/Index/lib
libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
~] cat /etc/ld.so.conf
/System/Index/lib
Personally I think it would have been interesting to version the system index itself, like /System/Index/Current|1.0|myappenv|etc/lib|bin|etc, and each app is chrooted into their own system index by default.
The question is, when 2 packages, pkgA & pkgB bring in the same library, call it "thelib.so" into the system, logically, only 1 of them can be refered to by the symlink in System/Index/lib.
So we have both
/Programs/pkgA/1.0/lib/thelib.so
/Programs/pkgB/1.0/lib/thelib.so
/System/Index/lib/thelib.so -> /Programs/pkgA/1.0/lib/thelib.so
My question is: how is the pkg management system resolving this?
/System/Index/lib/thelib.so -> /Programs/thelib/1.0/thelib.so
https://github.com/gobolinux/Documentation/wiki/Removing-pro...
https://github.com/gobolinux/Documentation/wiki/Understandin...
But Gobolinux can actually handle this scenario better than most distros since package-specific libraries don't need to go into the global index in the first place. So neither pkgA nor pkgB's 'thelib.so' would end up in the index, it'd just be local to the package.
So it would be better if either there were no `/sbin` or if it was always in the PATH.
[1] https://github.com/blueman-project/blueman/blob/fcef83a01c80...
My favourite one is how people try to come up with reasons for the /usr dir and why /bin and /usr/bin both exist. The original reason was that one of the original Unix devs ran out of space on their hard drive and needed a second bin folder for the new drive.
Or probe for its location Rather than hardcore one or the other
Everyone happy
Hrdcoded paths for things a program doesn't bring with itself, should be avoided in general. There is a reason $PATH exists and is easily extended. It is the users/admins responsibility to make sure envvars are set correctly, and it's the programs responsibility to give a useful error message when it cannot locate the programs it expects in $PATH
Other projects need to sit still so one project doesn’t have to change one line of code?
Nonsense. Keep up or get forked (that’s not a euphemism for vulgarity). It’s not esoteric magic like it used to be.
The historical difference is that in /sbin there are binaries meant to be executed by root, and thus they were not be put in the path of non root users (Debian still do that), so you don't get binaries that you can't run in your path (these days it's stupid since you may want to use sudo and thus have them in path only for the shell autocomplete to work properly).
By the way I prefer how things are nowadays, otherwise you get the same confusion that I have every time I use Windows or macOS that you either have an infinite PATH variable or have to specify the full path every time.
Yes, the package manager can make symlinks, but at that point what is the difference?
Also having everything in /usr/bin has the good side effect of avoiding that by mistakes someone creates a program that has the same name of one of the thousands of programs that are in the repository of a distribution, to avoid confusion to the user that can launch a program or another depending on who comes first in the path.
EDIT: didn't realize you were talking about Gobo specifically; not sure how they deal with this, but theoretically a similar strategy seems like it could work
Shared libraries actually being shared is the exception and not the rule
For all the hate of npm and node_modules it’s wonderful to have this isolation
But since there can be only ne symlink to the library (because the lib is searched by name in the index) the question remains: How is the package manager handling this for Gobolinux?
Looks like you could use
find /System/Index | RemoveBroken
In a way this is inside-out from what Nix and Guix do, where their equivalent of the System Index (the Nix/Guix store) is the build target, and everything all symlinks point to that. That makes this kind of thing a little easier to deal with, at some other costs.
From the answers There is no package comes with a dependency, there is a pkg depends on a well dependency
Either you are asking a deeper question or comes with a dependency is an unusual terminology
Take journals in systemd for example, they are better than plaintext log files in some cases, but now you are stuck with a format that needs to be interpreted and parsed before it is useful.
That doesn't mean improvements shouldn't be done, but every step that is a big change often also makes it impossible to do some basic things that used to be possible for decades. This is similar to analog radio (i.e. only requiring a diode, tunable capacitor and a coil to receive audio! - no power supply needed!) vs. DAB. DAB has a lot of improvements over the base feature, as well as a whole lot of new features. But it is no longer possible to simply receive the radio waves and get audio.
In a way you lose simplicity to gain sophistication. Sometimes we get sophisticated simplicity where a complex problem was solved in a very neat and elegant way that can be reasoned about with ease, but most times it isn't the case and that makes me (and a whole lot of other people it seems) wonder how we can get the improvement without losing the simplicity.
For the very simple "the filesystem is the database" concept, this might actually be possible, all we really get is a well-known structure and versioning with symlinks, similar to the alternatives system used in Debian. But then we get /Programs which is capitalised which looks nice but mixed capitalisation seems too much of a "they are doing it, thus so are we" thing, while on a filesystem level there isn't any gain. Same with spaces in names or dashes. For visual representation that is nice, but everything else it sucks.
I would take out the capitalisation and add some sort of unionfs/aufs/overlayfs hooking (symlink into a bundled filesystem would be one way) so from the system's perspective it's still a single filesystem tree but you add the option to get all those newfangled distribution methods in there as well. The problem we still haven't solved is versioning, but since it is arbitrary at this point /programs (or just call it /apps) could just contain <shortname>/<versionstring> for the application name and then version of the application. If you then dump in a version that comes from a docker image, flatpak, some weird weine-dxvk-steam construction or something else you symlink it in as a <versionstring> and then it's no longer the problem of the distro.
There is still the issue of partitioning off parts of the system you don't want to be touched or want to have safe; a RO-snapshot plus user-overrides could work, but you might end up with a huge RO-snapshot that needs to be entirely replaced, and then a billion override mounts on top of that...
As simple as Gobolinux presents it, this only seems to be useful for a single distro with a single distribution point, which is no longer where we are. Even FreeBSD is past that and that's not even Linux.
Remember that some systems may have multiple users (some may even have multiple simultaneous users) who use different locales. Or a single user might run different programs using different locales, e.g. if a program has a bad translation in their native language, they may prefer to run it with a different language that they also speak.
A lot of computer systems only got rid of the problem of storing filenames in locale-specific character encodings (e.g. ISO-8859-*) relatively recently, by switching to a locale-neutral encoding (UTF-*/UCS-*). It would be nice if they could not repeat some of those problems with locale-specific filename matching rules.
You could remove the problem of "requiring you to type the name with exact case" by having shells' autocomplete feature fix case issues. So you could type "vi foo<TAB>" and the autocomplete change that to "vi Foo.txt". That could have the advantage of also fixing combining character normalisation issues. And the question of "which locale's rules get used?" is easy - the locale of the shell doing the autocomplete.
Apple's APFS will create the folder as "Programs" if you use "mkdir Programs", and will give you an error when you try to create "programs". You can navigate with any case combination, but it just plays along like the capitalization you entered is present. It feels like a hack tbh.
Another thing I noticed that I never notice that I'm pressing shift while capitalizing. It's not a deal-breaker issue for me (while this might sound like "it works for me", I'm sure that I'm not alone in that).
Case insensitive systems created a lot of problems down the road. Esp. due to popularity of Windows. Program porting is a pain, using macOS with real case-sensitive mode is again a pain for some scenarios. It also encourages sloppy programming practices and "I don't case as long as it works" ism.
What is this? It's not capitalised so it can't be an acronym or initialism. And your username doesn't start with a capital like a Proper Noun, so it's unreadable. This is my problem with case-sensitivity, it's not how humans use writing, think about writing, design fonts, etc. 'a' and 'A' are the same letter, they're the same letter in the alphabet, they are pronounced the same, they make the same word "apple" or "Apple" which is also pronounced the same and means the same, they could be rendered the same in a given font without making words unreadable or confusing (e.g. small caps fonts).
If the computer isn't letting me use "apple" or "Apple" interchangably as I (the user, supposed to be in control here) wish, that isn't helping me, it's nitpickingly hindering me and making me implicitly care about character encoding values I can't even see. This is dreadful UX.
Domain names aren't case sensitive, email addresses could be but generally aren't, usernames could be but generally aren't, phone numbers aren't, Twitter handles aren't, my bank cards have my name in ALL CAPS but it's still me, you wouldn't join an IRC channel and think it okay to use a nick which matches someone else's but for capitalisation differences, you know which book I mean when I say "the martian" and so does Google search and my email search, PostgreSQL table and column names aren't case sensitive.
It's nice, convenient, helpful when identifiers aren't case sensitive.
They are case-sensitive. The thing is however that is that PostgreSQL will automatically lowercase names that aren't explicitly double quoted.
It's a case insensitive "to be honest". Non capitalizing it wasn't intentional, but it has shown to be a prime example how case also conveys meaning.
> And your username doesn't start with a capital like a Proper Noun, so it's unreadable.
No, it's a combination of my name and surname, and a play on C/C++ header convention, more specifically "bayindir.h", which is based on a joke one of my university friends. See? Again case conveys meaning. In this case, my username is case sensitive and has a meaning when it's all lowercase. Bayindirh won't do in this case.
> it's not how humans use writing, think...
Case carries information, conveys meaning. "apple" and Apple are not the same word, doesn't point to the same "thing". Computer is the ultimate data storage and manipulation device we have, and I don't want ambiguity in any parts of it.
If humans didn't use cases, and this is not how we use writing, i can just write will all lowercase letters and make distinctions between apple the fruit and apple the company, or turkey the animal and turkey the country some other, more convoluted way. Cases matter. They carry information. Try to tell a mathematician or any scientist that their formulas are moot because X and x are the same variable.
> If the computer isn't letting me use "apple" or "Apple" interchangably as I (the user, supposed to be in control here) wish, that isn't helping me, it's nitpickingly hindering me and making me implicitly care about character encoding values I can't even see. This is dreadful UX.
I'm the opposite. I consider apple being equal to Apple "Dreadful UX", so it's subjective. IMHO, every user have preferences and a computer can adapt to that. Given the choice I'll prefer case sensitive, you'll prefer case insensitive. That's OK. What's not OK is pointing a finger to a property and calling "This is useless!"
On the technicalities side, there are some capitalization rules which make case insensitive systems shiver and break. For you probably i and I are same. For me it's not. We have i, İ, ı, I. How to make this case insensitive? A lot of programs break because of this. This is fun. This is called Turkish.
So, no. Neither a and A, nor i and I are the same letters. They don't have to sound the same either.
> Domain names aren't case sensitive, email addresses could be but generally aren't, usernames...
Case insensitive passwords and usernames are big security nightmares, including the technicalities I've described above. Names on credit cards are built upon the assumption that capitalization works the same everywhere (it isn't). Just because Google wants to match something case-insensitive doesn't make it right.
Some things are designed to be case insensitive against the norms. In normal human language case conveys meaning. Some conventions decide to ditch that meaning. Many programming languages are case sensitive. Are they wrong? No they're not. SQL statements use cases to denote keywords, even if they're case insensitive.
Case conveys meaning. Ditching is a choice.
> It's nice, convenient, helpful when identifiers aren't case sensitive.
In some cases yes, in most cases no. Try to lower() this comment, and try to read it. It may not be nice, convenient and helpful.
I have occasionally complained that I find math notation frustrating to read because of the use of the same letter with a tiny variation, maybe an unpronouncable one. Mathematicians are not particularly interested in what outsiders find difficult (why would they be?).
I have occasionally enthused about PowerShell, a shell/scripting language where string comparison is case insensitive (by default, sensitive if you want it), where variable names, method names, object properties, function names, are all case insensitive, and how wonderfully convenient, liberating, easing and brilliant I think that is for an interactive shell experience. And about other simplified systems such as APL and Dr Iverson's work to simplify math precedence rules and how its builtins try to work the same over scalars, vectors, and multidimensional arrays. About Simplified Music Notation and their work to reduce cognitive load by in-lining sharp and flat information into the shape of the note instead of having to remember it from the beginning of the bar; the Esperanto language and the 'clockwork-morphology' where all the patterns about past/present/future apply to every verb with no exceptions for strong verbs or loan-words, and how much easier that makes it to learn.
Humans use case flexibly, it adds meaning but it can be overridden. News headline "Apple Announces New Computer" means something different from "Fruit Grower Announces New Apple". Humans now have to deal with more and more different systems, the fewer nitpicking rules humans have to learn for each one to be able to do that, the more the systems adapt to humans, the better.
> "Computer is the ultimate data storage and manipulation device we have, and I don't want ambiguity in any parts of it."
I don't want ambiguity, mapping "a = A" for information retrieval isn't ambiguous, it's completely specified. I don't know what it would do in Turkish, but your own example tells me you can see those four things as variants of 'i' differing in capitalisation and you don't confuse any of them with K or Z. If you can, computers should be able to. I would expect datetime and number formatting to be different in Turkey, and capitalisation too. If i, İ, ı, I are different, then they are different and need to be carefully specified each time, that Turkish case shouldn't mean English a-z and A-Z must be considered different.
> "I'm the opposite. I consider apple being equal to Apple "Dreadful UX", so it's subjective."
You consider it "a dreadful experience" that someone searching Google for 'apple computer' gets results instead of nothing? That "December 2021" and "december 2021" are considered the same month? Someone who doesn't remember the correct capitalisation for XF86Config, what should they search for to find it in your world? All possible case variants? One way they could find out is to list a directory which contains it and read the listing, and the only reason that works is because their brain can recognise 'the same thing' without knowing the case(!). Humans do it, machines should do it (unless explicitly overridden).
> "Case insensitive passwords and usernames are big security nightmares"
Passwords yes. Usernames, no. Case sensitive names are a security nightmare, they lead to problems like phishing. It's bad enough getting an email from @bankofamerlca.com but if the official one was bankofamerica.com and BankofAmerica.com was a scam domain, what chance would anyone have?
Like, apple and APPLE are the same company name in the UK! Search for 'apple' on this government site https://find-and-update.company-information.service.gov.uk/c... - and it says "The company name "APPLE" is considered to be the 'same as' the existing names shown below: APPLE.COM LTD". If that's ambiguous, a computer system should represent the ambiguity of real life.
> "In normal human language case conveys meaning."
But the case difference is not pronouncable, not memorable. I don't have to learn apple and Apple as two different words, I change the case on-the-fly as I need it. Same way I would not want to condiser apple and apple as different words where I have to get the italics correct before the computer will find them, or underlines, or bolding, or colour, I don't want to have to specify the way the news headline was written before I can find it - not font size or emphasis or capitalization. "README.TXT" is still at the core saying "read me" not anything fundamentally different.
> "Try to lower() this comment, and try to read it. It may not be nice, convenient and helpful."
Try to transcribe a talk and write the case they are speaking. They aren't speaking cases, you have to guess from your knowledge of language and work out from context which things are names and where sentences begin. Case isn't present in speech but it still carries meaning.
Also imagine having two files in the same directory which differ only by case. What would be the benefit of being able to have two or more such files?
Are there any use-cases for which case-sensitive file-system is better than case-insensitive one?
Actually, not having the exact file may not provide a utility for you, or most of us, but searching for a file in a case sensitive manner, and getting ENOTFOUND just because it doesn't present in the way I searched is valuable from my point of view.
Also, having a case-sensitive system is simpler from technical point of view, and prone to less bugs. This is especially true after UTF-8 become ubiquitous. Searching for an exact byte stream is much more simpler than a country dependent, exceptions filled search/match algorithm.
If you shouldn't have to care, if there should be a layer of Unicode normalization happening, why is that okay but case normalisation is not okay? If you do have to care, then you no longer "know exactly what you get".
You do know you get exactly what you put in, whether that is é (U+00E9) or é (U+0065 U+0301). When you reference files created by yourself, this is not a problem as realistically speaking, your input method will only have a convenient way of forming one of these, and it will consistently generate the same one every time. When you reference files created by someone else, this may be a problem but no more than e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i): from the user's perspective, the problem is pretty much avoided by selecting the file using tab completion, TUIs, GUIs, whatever you use.
Just want to remind a little but extremely important thing: There's absolutely no guarantees that upper("i") is I. There's at least one language breaks that convention, and you won't believe how a big headache is that.
Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.
I don't override the font, either HN or FireFox or Windows is picking a serif font. I assume you didn't explicitly choose a font where different things look the same, but if it rendered 'a' and 'Z' the same glyph, you wouldn't say that was a problem with the English alphabet or with case sensitivity, or anything other than bad font design, right?
Most shells can be configured to behave that way, and Fish works that way by default.
You install ProgA and the lib is symlinked into the index You install ProgB and the index's symlink to ProgA's lib gets some information added to it along the lines of "if the symlink to ProgA/lib is broken, try ProgB/lib"
Then when you uninstall ProbA the fallback symlink is activated.
At some point you would want to clean up the dangling primary link but maybe the best time to do it is immedately. i.e. the first time the primary fails you make the backup the new primary and now there's no backup, i.e. it looks the way it would look if you had only ever installed ProgB.
A lot of the directory structure of POSIX systems is completely obsolete in the 21st century. The difference between sbin and bin? Historical, for the most part, and irrelevant in the age of rescue systems.
One question that is nagging at my mind with this: What if two programs require the same lib, how is this resolved?
Because, when I install progA, the lib is symlinked into the index, so when I now install progB, the lib is installed again if I understood correctly. Storage is irrelevant, the pkg manager sees there is a symlink, so it stays in place, all is well.
But now I remove progA, so what happens? progB is still present, still requires the lib, it is also still installed, but now the symlink, which refered to /Programs/progA/libs/thelib.so is broken. How is this situation handled?