Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
vektor
wrote on the 31 Aug 10 at 13:53
|
|
|
|
I am afraid that most of the software Ubuntu uses expects the FS to be case sensitive, and that this would be a too big change.
|
|
Ssdg
wrote on the 31 Aug 10 at 14:32
|
|
|
|
And more, I find it usefull (what if you have a file to save quickly and the good name is already taken?)
|
|
|
This would make ubuntu completely incompatible with every other distribution in out there. Not only would convensions be different, but patching applications that expect a case-sensitive file system would be a *nightmare*.
OSX got away with it because they control *everything* on their platform and have the power to force application developers to fix their own problems.
|
|
dino
wrote on the 31 Aug 10 at 16:04
|
|
|
|
"File" and "FiLe" are not the same. One is a word the other a typo. Or maybe a name? Maybe a company called “Fire Lemonade”, short FiLe.
|
|
|
|
The file systems in osx and windows are both case sensitive. What isn't case sensitive are the tools built around them.
|
|
Auzy
wrote on the 31 Aug 10 at 20:57
|
|
|
*sigh*. No wonder Linux is going nowhere. You guys still can't see the usability issues, and ALL of you guys are wrong..
You guys realise that almost every GUI application in Linux uses the XULRunner file selection, GTK or QT file selection dialogs. So GUI is easy..
In console, barely any changes should be needed, only explicitly in the case of writing, when another file with different case but same name exists and an overwrite dialog is shown (that's why OSX probably didn't need to modify anything). The standard tools (ls, cat, less, more, pipe, etc) aren't affected actually, because they don't do this.. Autocompletion in bash might need patching, but Apple already has that code, and if syscalls are used, it might not be necessary.
You guys aren't interested in a flexible, productive or usable system. Clearly, you guys only seem to care only about the IDEA of Linux. This is useful to advanced users and newbies. And no, it isn't as big a change as you guys think.. Years ago, everyone was interested in usability, and changing things for the better. But honestly, Brainstorm ISN'T about how easy it is. Let the developers decide (because how should you guys know how hard it is). Vote on the idea itself!
I don't know a single technical user who wouldn't want mydoc1.doc and Myfinaldocument.doc shown when using m in bash..
|
|
|
@Auzy We are not saying that case insensitivity for open/save dialogs is bad (gtk and qt already allow you to do that by clicking on whitespace then typing).
If it's the command line (autocomplete) you want it for, IT'S DONE! http://www.cyberciti.biz/faq/bash-shell-setup-filename-tab-completion-case-inse nsitive/
Really, changing the entire filesystem and risking unknown numbers of driver, kernel, application and system bugs is not worth it when most of the tools are able to do it already.
|
|
|
I LIKE that Linux has a case-sensitive file system. It helps clarify. If is say:
rm Some.sh
and not:
rm some.sh
yes, the case-sensitivity can be a pain, but spaces in paths? Even worse.
Prioritize, please.
|
|
|
|
Adding quotes is harder than hitting the 'Shift' key. Case is not hard.
|
|
Auzy
wrote on the 1 Sep 10 at 05:59
|
|
|
Actually, I just realised, I am wrong, its MUCH easier to add than I thought, because almost everything uses fexists and syscalls. So its unlikely Applications (other than auto-complete apps like bash) will need modifications. Only a patch to the kernel probably, and a way of telling the filesystem the partition is case-insensitive.
And rockachu2. Can't you see how some people might get confused if they have 2x resume.doc's in the same directory, Resume and resume? Why the f*** would you want that?
I haven't actually seen any good reasons NOT to support this, and I sure as hell aint saying enable it by default. All I'm saying, is that this improves usability significantly, and we should have the option to do it.
Because another major issue with making the filesystem case-sensitive, is that if you zip up a directory with Resume and resume, when you decompress on a case-insensitive filesystem, they only get 1 file.. Yes, there are compatibility problems with the way it's done now too...
|
|
Akerbos
wrote on the 1 Sep 10 at 15:58
|
|
|
Somebody who has Resume.doc, resume.doc, ReSume.doc in one folder is stupid. E.g., too stupid to use real versioning.
Introducing simple conventions like "I do not use upper-case letters in my filenames" solves all your problems, Auzy. What Darwin S. gave you are even "real" solutions.
Really, all filesystems/OS should work like UNIX. It is just how computers work (well): one file, one name, one address. On Windows/Mac, one file has exponentially many names (in name length). This is clearly not a wanted thing -- if you think about it.
|
|
Akerbos
wrote on the 1 Sep 10 at 16:06
|
|
|
|
I value compatibility amongst UNIXs higher than compatibility with Windows.
|
|
|
if people what another windows they better be sticking with windows.
Rendering a file system's vital feature down is something i nor any one should support.
|
|
Auzy
wrote on the 2 Sep 10 at 06:59
|
|
|
@Akerbos.
1) Really? I've seen many decent users mixed up a few times in the past. Probably you have too, you just don't remember
2) PROVE, this breaks compatibility. Find me a single app at least which relies on case sensitivity to work
3) Case insensitivity is compatible with unix unless apps rely on it. I have never seen an app which relies on it.
@Anatshri. Vital feature? Great attitude. F*** anyone who doesn't approve of old Linux crap. I'm so sick of this elitist crap. Linux has TONS of usability issues, and you guys have your head full of elitist-unix-crap that you REFUSE to acknowledge that they exist (people like yourself are holding back developers, any increasing number which are starting to agree that stuff like the linux filesystem are horrible).
Clearly, we need a Linux distribution accommodating common sense, because the loudest Linux crowd only seems interested in only Unix compliance (despite the fact that they have no idea what that means). They aren't interested in options.
And NO, not all computers should use case-sensitivity. It might make a TINY bit of sense from the programming side of things, but that's not how humans work. Have you seriously been using computers so long you've started to overlook the obvious?
Bah, for a short time Brainstorm was starting to make sense again, but clearly, now I can see why I left it the first time. Once again, it's about making assumptions, and about coding what makes sense to computers, not to users.
|
|
|
Removing case sensitivity doesn't only cause problems for apps that require it (which is probably actually not that large). What I am *REALLY* worried about though are new developers targetting ubuntu and realizing that ubuntu is case-insensitive make their programs case-insensitive. This may work fine on ubuntu, but as soon as soon as they (or someone else) tries to get it to run on any OTHER distro, they will hit an unbelievable amount of bugs. I witnessed this myself when I ported and old PHP site from a windows XAMPP server to a LAMP stack. I did not (and still don't) blame linux, but my own laziness when I wrote it.
I usually don't bring this kind of thing up, but I have noticed that every brainstorm idea you don't agree with is followed up with very angry, frustrated and personal responses that are completely uncalled for in this kind of discussion. It's something you may want to work on.
|
|
Auzy
wrote on the 2 Sep 10 at 11:09
|
|
|
That's because many of the complaints about more extreme ideas (not just mine) are sometimes followed up with assumptions or at times, responses which weren't even properly considered. Not only mine...
All I'm asking is that people CONSIDER the possibility that this might be a better way.
The complaints are:
1) Because its a "standard", we need to be compliant with unix. This doesn't make any sense, because a standard isn't a law of physics. Standards change often. And this doesn't break standards (as it wouldn't be the default, just increase flexibility and options).
2) Wrongly assuming app breakage is enormous. It's true your app broke, but this is no different to other assumptions made by developers, clearly outlined in the developer guidelines. People on brainstorm shouldn't be disregarding ideas because of difficulty coding. I recall you and myself agreeing ages ago that ideas should not be voted by their difficulty, only by their quality.
3) The standard response to any response that mentions windows and OSX (if you want windows, use windows). ie. The elitist response
The reason I am frustrated, is because people aren't even considering the possibility anymore, and voting has become somewhat robotic at times. People should consider why they are voting for or against something, however, often seem to simply assume standards are correct.
|
|
|
@ Auzy: I commend your desire to make GNU/Linux more user friendly. But I condemn your attitude that changing standards is okay as long as it makes life eaiser for a small subset of the userbase.
Making GNU/Linux user friendly means making it easier for non-technical users to operate. And non-technical users shouldn't need to use the command line at all, case-sensitive or otherwise. So your argument that "most" new users would be confused and frustrated by the lack of such a feature is silly.
And any user that names one file "Resume.doc" and another "resume.doc" using the GUI might be confused for a second as to why they are not getting an error. But I defy you to find anyone who would exclaim "screw this Linux crap that lets me have two similarly named files!" and go back to Windows...
|
|
Auzy
wrote on the 3 Sep 10 at 11:08
|
|
|
@TwistedLincoln, What standards? Neither LSB 4,FHS nor POSIX/UNIX specs seem to mention filesystem case-sensitivity. Since OSX is fully UNIX compliant (SUSv3 and POSIX) yet uses HFS+ (set to case-insensitive) by default, I am guessing that you guys will have difficulty backing up the standards claim. But please do so, because I am genuinely interested about whether this is part of a common standard at all. It's also worth noting that not all deployments use a case insensitive filesystem, so...
If developers code doesn't work on case-insensitive filesystems or vice versa, it is already a problem, because you can't rely on distro's supporting it anyway (especially if you want to add cross platform compatibility later). One common example though is SMB (mainly on corporate networks/mixed environments), as SMB is apparently case-insensitive too. I've also seen issues in the past with SVN code which has seperate windows/OSX/Linux components, which seemed to be caused by compatibility issues between insensitivity and sensitivity. Personally, I would have preferred to use a case-sensitive filesystem to reduce the impact of this issue.
I never said "most users" either, and didn't even imply it. I said "some people". Some users also don't want to risk losing files when they zip them up into an archive and decompress them on Windows later (because they accidentally duplicated files with the same name but different case). Case-insensitive Filesystems are much more forward compatible. Users wont turn away only because of this. HOWEVER, Linux distro's seem to be accumulating a lot of serious usability issues which users here believe "are barely noticeable anyway". We might have gotten used to them because we are well trained for Linux. If you poke someone with a needle once, they will feel the pain for a short time, but it will stop. But, poke someone enough times, and they will be dead soon.
Forget everything you guys know about Linux. It's time we ask ourselves whether what we always knew is actually correct, because I STILL hear people say EXT2 doesn't fragment.
Also remember that anyone can write standards, and everywhere else, standards do change when they need to (it takes a strong leader though to do it globally). Most OS's have made major changes to their core since they were released, and if Ubuntu can improve the standards, to encompass more, they should do so! If all distro's agree to improve their standards to be more flexible, it isn't a problem, but how do you know they wont until you try?
|
|
|
|
Could you please give a firm example of a standard (preferably computer related) that has changed (Please don't bring up ooxml, that was never a true standard). From my personal experience, standards never really change, they have small amendments (usually for clarity) or are replaced altogether.
|
|
Auzy
wrote on the 3 Sep 10 at 16:28
|
|
|
Not really a relevant question, because nobody has yet to actually prove case-sensitivity is a part of any standard (and I believe I have adequately pointed out that developers CAN'T assume it doesn't exist).
For your question though, assuming you conveniently ignore programming API's (because then the Linux kernel fails), generally anywhere, where there is a design issue, a protocol gets changed. One such case is the IPV6 DOS vulnerability, where they depreciated a feature because it could be exploited by hackers.
In this case though, to the best of my knowledge, no standards are ACTUALLY being changed, because case-sensitivity was never defined as required (and there are 2 sides of the argument, which is why HFS+ can be formatted as either).
You are correct, they are normally amendments, but this would be too. Either way, there is plenty wrong with the Linux standards, and they do need heavy reworking. Remember, the linux filesystem layout was based on ancient unix systems which acted as mainframes or servers. It was probably never really intended for normal desktops, let alone expected to be used by the general population
|
|
puxkggn
wrote on the 8 Sep 10 at 16:24
|
|
|
Doesn't anyone sees the real problem here?
Changing the name from lower- to upper-case or the other way around is only a very narrow use case.
The real problem is that when a file changes it's name and/or path. The references in the list and programs don't change with it. Causes broken links.
This is a problem of recent item list and programs folder that doesn't change the name if the original file name is changed. Talking about case-sensitivity is the wrong thing. What if the path or name is changed to something different? (multiple letters deleted/added or other signs)
What should happen is (could be slightly different in execution) that Gnome or other Desktop environment that is currently used maintains a list of links to that file.
When the file is moved or renamed. It should look at that list and contact the other components involved. (Here the recent item list and menu program.) Those components should then rename their references to the new name and/or path.
Or when files are renamed and moved. The system checks if they are used in a few places. And sends the new name/path to those places.
These solutions actually solve the problem for real instead of making such a mess of things.
|
|
|
@puxkggn Your solution has nothing to do with the problem in question. We are talking about *users* getting confused about files having a different case than they expect or multiple files having the same name (with different case). Your solution is about *applications* not being able to find files.
If a user is moving/renaming (including case) files that and *application* needs, they are already WAY beyond their expertise.
The basic rule of thumb with moving/rename files is: If you didn't create the file yourself, or know *EXACTLY* what it for, *DO NOT TOUCH IT*. I'm pretty sure this applies to any and all operating systems.
|
|
Auzy
wrote on the 9 Sep 10 at 04:24
|
|
|
@Darwin. Well. It is related (read the problem), because as mentioned, application recent links break too if a user even changes the capitalisation of a file.
It is a small use-case, and I was mainly referring to simply recapitalising files. But, it fixes some problems, not others. Problem is, I think the recent file lists are handled by the application, and file watching on works when the app is running. However, granted, that use-case should be solved too.
#4 technically doesn't make sense, because casing would be handled at the kernel level (without a recompile of apps even), so only poorly designed apps would need to use that algorithm
|
|
alcatraz
wrote on the 14 Sep 10 at 09:58
|
|
|
I love the case-sensitivity of Linux.
But to be honest, I would like Ubuntu more, if ALL folder names would be non-capital. That would be much easier.
|
|
Auzy
wrote on the 14 Sep 10 at 10:38
|
|
|
|
It isn't changing it to be NON capital. Case-insensitivity means they are shown in a preset way, but can be accessed as /folder, /Folder, /FoLder or /FOLDER
|
|
|
@Auzy
I understand where you're coming from, and I personally would have like case-insensitivity. I agree that case-sensitivity is not end-user friendly.
Unfortunately, Linux and its filesystems are built *from the ground up* as case sensitive.
Changing this would be HUGE.
It would be quite easy, I imagine, for the GUI's to have front-end insensitivity to be built in. For example, the search function in Nautilus is case-insensitive.
But because Linux is case sensitive, the GUI's have no choice but to be aware of this and let users know about it.
This can only change if Linux *itself* and its file systems are rewritten. It wouldn't be a new disto. It would be a new operating system (albeit a fork from Linux), say, "Linuxi".
Linux and "Linuxi" would not be compatible with each other, and all programs written for Linux would have to be recompiled for "Linuxi" (and possibly debugged for the case-insensitivity).
You could go with Ubuntu (using Linux) or "Ubuntui" (using "Linuxi"). But Ubuntu couldn't run on "Linuxi".
So, while I agree with your sentiments, it's just not going to happen!
(Besides, with the idiotic patents being issued, you'll probably find that Windows has patented case-insensitive file names.)
|
|
Auzy
wrote on the 15 Sep 10 at 10:38
|
|
|
Actually, I believe that's incorrect... OSX already allows switching between case-insensitivity and sensitivity quite easily.
There should only been minor changes required.. Case insensitivity is actually a superset (and simply adding support to the kernel should make it almost work everywhere).
|
|
|
|
@Auzy Modifying the kernel (apart from installing modules) is pretty much the definition of "forking the linux kernel". Unless the linux kernel team decides to do this (0.00001% chance of that happening) then ubuntu would technically be running a forked version of the Linux kernel.
|
|
puxkggn
wrote on the 31 Aug 11 at 13:23
|
|
|
You could let the file manager put out warnings where there are files that from a case insensitive viewpoint look the same and offer to rename them.
Couldn't this solve the problem?
|
Post your comment
|
