Comment by Osiris | Hacker News Reader

Comment by Osiris | Hacker News Reader

As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suited to today's much more complicated GUI applications.

Mac OS X, I think, has done a decent job of structuring the file system to be more user friendly despite the -nix background.

Modern use cases typically revolve around either installation and use of specific applications, often with dozens or hundreds of files needed, and data storage. In Windows/Mac, applications (for the most part) are installed into their own individual application folder and a GUI (as opposed to the PATH) is used to provide easy access to the application. This makes it easy to 1) know where to put a program you're installing, 2) know how to locate a program after install, and 3) keeps all the application components in a single place for easy move or removal.

In my somewhat limited experience with Linux, I find that the complicated nature of the file system makes package management systems necessary to simply keep track of where all the files are: executable in /usr/local/share/bin, configuration files in /etc, libraries in /usr/lib, and I'm not sure where non-binary resources of an application get stored.

I once installed my favorite browser (Opera) in Ubuntu. It didn't make a desktop or Applcation menu icon for some reason, so I figured I'd just go make a icon to point to it. It took quite a while to just figure out where the executable was at.

This could very well be one of the reasons that many people find Linux on the desktop difficult to use. They don't understand where anything goes.

I hope that one day one Linux distribution will at least step up and consider restructuring the file system to be more friendly and straight forward and to take advantage of the availability of long file names.

I come from a DOS / Windows background, but now use Cygwin as my primary interface on Windows, and also regularly use Nexenta (Debian-flavoured Solaris) and Linux. I find the Unix way more understandable, particularly when things break.

Only the most simple of Windows applications get away with putting everything into a single folder under $PROGRAM_FILES. More usually, lots of stuff is in $COMMON_FILES, and may or may not be shared. And these common files are tied in to the program files via a giant complicated global variable, the registry; the program looks up ProgIDs and CLSIDs to instantiate COM objects, so the registry becomes a very sensitive source of failure, particularly when you have different versions of $COMMON_FILES that break the various linkages.

Furthermore, these days Windows Installer is often used to manage the Windows equivalent of packages. These too are sensitive to corruption; if you end up missing the MSI files from c:\windows\installer for one reason or another, you can easily get into a situation where you can't even reinstall an application cleanly, because the installer notices that you already have it installed, and tries to uninstall it first, but fails (usually quietly, in the middle of the installation, where the progress bar goes into reverse and at the end you get a cryptic and unhelpful error message). To fix this, you must venture forth once more into the registry, find out the cryptic (hex) name for the relevant package, and surgically excise it. Not even the MSI/MSP/etc. files have meaningful names. It's tortuous.

All that said, I by far prefer working in Windows to any other OS. If it had a faster performing yet fully POSIX compliant layer as well integrated as Cygwin (i.e. not off in its own parallel little world like SFU/SUA), it would be even better.

"and a GUI is used to provide easy access to the application" How do you think the GUI finds the application? There is a PATH. Open up a cmd and type the name of any installed program.

1) Programs put themselves in various directories on my windows 7 machine, some are under \Program Files, some are under \Program filees (x86), some are \Programs and so on, variations and variations.

2) to locate a program you need to know its corporation, which people often dont know. There are setup.exe start.exe fireup.exe and run.exe and variations, which one should the user use to start the program?

3) all the applications components are not in a single place but are spread out over \Program-Files, \Windows\system, \windows\xx\xx and the registry at the least. Then they put stuff in \users\application data\ and \users\xx\applications or whatever.

You and many people dont understand where anything goes because unlike for Windows, GNU/Linux systems actually make sense and actually have a structure (that is different from windows) which you need to learn to operate the system, just as you learned to navigate the mess of windows.

I thought the many of the shortcuts used fullpaths in windows I'm pretty sure not all of them can be accessed with name in cmd. Looking at the .desktop files under /usr/share/applications (ubuntu) most execute by name but some especially games(both third party and some gnome games) use fullpaths.

In Windows from a cmd.exe prompt you rely on the contents of %PATH% to access programs. This is a holdover. In Windows proper there are other methods; from cmd.exe you can use the 'start' program to invoke executables in a Windowsy way. The most convenient/reliable way to set up an easy to use/remember way to launch an executable in Windows is to go to the registry and locate hklm/software/microsoft/windows/currentversion/app paths/, inside of which are a series of keys. Each key is the name of an alias and its default reg_sz value is the path to the executable to invoke when the alias is passed to 'start' (or entered into the run prompt, or what have you). You will find a number of these already in existence on any Windows box, most notably iexplore.exe.

While the system is, indeed, complicated, there is a reason changing it has not been Ubunutu's highest priority: almost all installation is done via the package manager. I haven't used Ubunut much, but at least on Fedora 95% of what I use is in the repositories and the rest is available as an rpm file which installs itself. I have never had to worry about where to put executable files.

Of course, I have installed things manually from source. But when I do, I only install them locally in my home directory.

So the complexity is there, I just haven't had to deal with it.

Also, I think that GUI-centrism is short-sighted, but that's another matter altogether. In short: command-line tools are just as "modern" as GUI tools; they're just harder to learn but tend to be more powerful.

As a user, this may well be tolerable. As soon as you start developing for Ubuntu (or any other OS), these kinds of things will make you suffer.

I learned Linux pretty well before I learned Windows (I was an early adopter) and I felt equally baffled by Windows at a time. I felt nothing made sense. :)

I don't think either make any sense. I guess you could give Windows the nod for not really even making any pretense of making sense (my favorite detail is how 64-bit system files go in "System32" and 32-bit system files go in "SysWOW64"). OTOH while I never got the /bin /sbin /usr/bin /usr/sbin thing, I always vaguely assumed there was some deep reason behind it that I just didn't understand.

For future reference, you can list all of the files associated with a package using this:

    dpkg-query --listfiles package-name

Or use Synaptic's 'Installed Files' tab in the package detail dialog.

Or:

    dpkg -L package-name

I often find myself looking for the opposite mapping; to which package does /usr/share/foo/bar.blob belong?

   $ dpkg --search /etc/apt/
   debconf, apt: /etc/apt

I prefer "apt-file search" which is much faster than "dpkg -S" at the cost of some disk space and having to periodically do "apt-file update".

apt-file search is [also] for uninstalled packages. If all you care about are packages actually installed use dlocate

Reply on news.ycombinator.com