15 ms·
Why is it so hard to find a file in Ubuntu? (2011)
- AdmiralAsshat 11y agoComing from a Windows background, I can understand the initial learning curve in getting used to the Linux filesystem. I still don't quite grasp it all myself. With that said, who the hell goes looking for stuff in C:\Program Files? The exe's live there, but most Windows programs create shortcuts on the Desktop/Start Menu, so you're rarely going to go into the program's directory itself unless you need to modify a .INI file.
- jsvaughan 11y agoI suspect that the question is just poorly worded - I think he meant to ask "why are programs in linux so hard to find" (if you look at his other questions they are not mega technical but they are also not questions that a novice would be posting)
- the_af 11y agoI suspect this too. Still, who goes to Program Files to find programs in Windows? I've seldom seen this. Most Windows users I know start programs either from desktop shortcuts or from the start menu, and wouldn't know their way around Program Files (note: I'm talking about Windows XP, 7, etc. No idea how the newer Windowses work).
- wodenokoto 11y agoI don't think he is looking to execute the programs. He is looking to inspect the program files. This could be anything from looking for assets, to manually editing config files or adding a cracked DLL to make photoshop run. When I was a teenager I would lurk around there a lot to "hack" stuff.
- TeMPOraL 11y agoIndeed. Also, assuming you're installing programs to their default locations, Program Files used to be[0] the single location where you could get an accurate overview of installed applications. Both the Start Menu and Add/Remove Programs lists are way too cluttered by various Windows additions and/or third-party bullshit. [0] - I don't know how's the situation with Windows 10, but on Windows 8 I've noticed some stuff tends to install to %APPDATA% instad.
- Avshalom 11y agoA lot of programs didn't/don't put a shortcut to the uninstall utility in the start menu was usually my excuse that and installing various downloaded addons/level packs/extensions. Copying/modifying config or save files that the application decided to keep with itself instead of putting in a user specific location. Part of the curse of backwards compatibility is that best practices have been invented and changed quite a bit over the last 20 years. I've been using linux full time for the last 3 years or so and before that it was old XP installs mostly but still I found myself in Program Files at least once a week?
- cpplinuxdude 11y agoInteresting. I think the posts contains a lot of useful information, however I believe this kind of response is detrimental toward user acquisition. It's very much akin to the tech guy walking into a sale's person's office, to fix their immediate need. The tech guy is thinking all he has to do is teach the person to think for themselves, problem solved. All the sales guy is thinking is is "oh god, please don't teach me anything". Personally I find locate and slocate very useful in linux to find the files I am after. Going over these might be more useful. That or whatever third party tools are available, with a UI and good UX, to achieve a similar goal.
- henesy 11y agoIn the same grain I find which and where is very useful. Additionally, find itself is a command that does its job pretty well. For less serious searches: du -a | grep -in filename # usually works
- fruzz 11y agoThe response is also abrasive bordering on condescending. The tone is very much along the lines of "what are you, stupid?" Even though they answer the question in quite some detail, that's really not the kind of thing that makes others be willing to open up about what they don't know and get better. The Filesystem Hierarchy Standard is a very different approach to storing applications on the filesystem than to how MS-DOS/Windows does it. There's a learning curve for Windows users and they do get confused. They conceive of all files for an application residing in a single directory dedicated to that application, whereas the FHS thinks of distributing files for an application according to purpose. I agree - I find locate to be very useful, and failing that grep/find.
- vram22 11y agoA modest amount of time spent learning how to use the main features of find, with options like -o, prune, -exec, {}, along with xargs, grep, can repay itself many times over in a short period. Of course, it presumes the user has the necessary technical bent.
- agumonkey 11y agoIt wasn't easier under Windows. Either the badly configured indexed search or the hard to find, slow tree walk. It's gotten usable by win10 I think.
- BuckRogers 11y agoUsually I install packages wherever they go by default but if installing by hand I put it in the home folder and run it from there. Most programs are under /usr though, but it's true you never know. I had to give up on Linux as a daily driver due to my fairly complex (multimouse, multimonitor) desktop setup. I suspect that some of the X11 code hasn't been touched in 20 years. This is why OSX and Windows make sense. For the user in the OP, the $100 or so dollars may be money well spent if that works for him. After much hacking I figured it's not equipped to handle my setup but I use it as my development platform and server both servers via SSH.
- pvaldes 11y agoIs just that you are not using your OS correctly. Learn a few commands of bash and you'll never look back. ... Or just create a link in your desktop pointing to the desired file or dir. Is ironic to say that files are hard to find in the first SO that allowed you to have as many soft and hard links to a file in your desktop as you want. ... Or browse the files in your file manager. In many cases you can even have thumbnails to help you finding the photos or videos that you want. ... Or just open firefox, write "file:///home/my-user-name" and browse your files. when "my-user-name" is the real name of your user ... Or use the main menu in your desktop ... Or use emacs dired and tumme
- zanny 11y agoThe only criticism I could have of Linux filesystems is that user mounted devices show up in /run?/media/<user>/<device> rather than ~/media/<device>. Otherwise everything a user does or makes is showing up under ~ somewhere, and the superuser's stuff resides in a mix of /etc, /root, and /usr. Well, I'll take that back, the fact the config folder is hidden by default is also kind of sucky, and the habit of some software putting configuration data in ~/.local/share and some applications putting non-config data in ~/.config is extremely annoying but should be solved on a per-application basis. Just a few offenders on my desktop in config: * Chrome/ium stores extensions in .config rather than share. Those take up 600MB each in my config folder on my system. * Qupzilla has a profile network cache of 32MB in config. * Brackets has 14MB of cache data in config. * Clementine puts its indexing databases in config. * Spideroak puts everything in config - its index database and snapshots. I'm not as familiar with offenders putting configurations into share, but I know at least KDE's kscreen puts monitor layouts in share/kscreen when they belong in config/kscreen. I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there, akin to localstorage's limit and the intent to use it as a config store rather than persistent data store which is what indexdb / share are. Also, .config should just be config. No dot. Users need to configure their stuff, they should be able to see it.
- vram22 11y ago>I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there Potentially useful idea, in general. There used to be a quota feature on some Unix versions (SVR3 etc, IIRC), with commands to both set and get quotas, though I never really used it. Update: Just googled for "Linux disk quota", and some links show that there seems to be some support. But it is per file system, not per directory. though per-user limits seem to be supported too. But even if a per-directory limit could be enforced, how would you get around the fact that the program could create files in other dirs than the controlled ones, under your overall home dir (as long as they had write permission)? I supposed some kind of script-based monitoring could be improvised, but it might be a kludge ... and even if you could detect it in near real time, it wouldn't be a good idea to kill the process responsible. Interested to know if there are any other methods or approaches. Restricting write permissions could be the basis for one approach.
- melted 11y agoThe "problem" is much more prevalent than people think. Switchers come from Windows to Mac and expect it to function exactly like Windows. When it turns out Mac has its own ways of doing things, they're disappointed. It doesn't matter that quite often the "Mac" way of doing things is actually better or at least more consistent, they just expect it to be exactly like Windows. Well, guess what, folks, you can "drill with a saw and saw with a drill", but you shouldn't expect a good user experience unless you use the tools the way they are meant to be used.
- asdf13 11y agoRead the first chapter based on linux in 'Counter Hack reloaded' by Ed Skoudis. yes the book is focused on security however after reading it I found the file system in linux makes far more logical sense to me than windows. from a big picture perspective. http://www.ubuntugeek.com/linux-or-ubuntu-directory-structure.html http://www.ubuntugeek.com/linux-or-ubuntu-directory-structur... (taken from the article) on a side note I added links from that page that are useful my own .02 cents is: >updatedb >locate xyz.xyz
- jrcii 11y agoI would pose a more general question, why is it so hard to find a file in Linux? Across all distributions I've found in difficult to predict where a particular binary or configuration file will be, and this is one of the reasons I prefer BSD (NetBSD in my case) -- the file system feels much more organized and the locations are predictable.
- Mikeb85 11y agoDunno, I personally think Linux has a much more organized and common-sense file structure than Windows. The home folder keeps most user data in a nice, organized place, and generally programs installed from the repos are in a consistent place. Sometimes 'installers' put programs in strange places, but that's the price of freedom I guess...
- _yosefk 11y agoThat programs and libraries get installed in a consistent place is nice in some ways I guess, but for me it's always been terrible, since it's more often than not really hard to install multiple versions of the same program or library (and therefore two programs using different versions of the same library. The hairier programs can't even be built from sources on "the wrong OS version" by most mortals, not to mention installing binaries; try building KDevelop 3 on an OS where only KDevelop 4 is made available by default.) Another maddening thing is how Linux distributions can't agree on where any bloody thing is - even env, which in large part serves a workaround for the inability to count on absolute paths, is at /usr/bin/env on some distros and /bin/env on other distros. So is something as basic as tcsh. How to write a portable tcsh script in these conditions I don't know. (And "you should use bash" misses the point, and also brings fond memories of #!/bin/sh script breakage when it turned out that sh is bash on some systems but dash on others.) Bill Gates said in the 80s that there are many different Unixes and this will remain a problem for a long while. Damn, did that man make a good prediction! As to Linux - Richard Stallman said that it's a kernel, not an operating system. Damn, did the various distributions go out of their way to prove him right, creating many different, not Unixes, but Linuxes!
- chriswarbo 11y agoThe major difference between Program Files and, say, /usr, is that the former is split up according to "which program it belongs to" and the latter according to "what kind of file it is". Each scheme has its merits, and both are quite fuzzy ("is this helper a part of my program, or standalone?" "should this asset go in 'share' or 'lib'?"). Interestingly, the /nix/store directory on NixOS is split according to package, so acts rather like Program Files. However, I try to keep my browsing of /nix/store to a minimum, since it currently contains ~25000 top-level directories. Search (eg. wildcard paths) is still necessary, even with this level of categorisation!
- draw_down 11y agoThe answers to this are condescending and terrible.
- justinsaccount 11y agoIs the question any better?
- draw_down 11y agoI'm not interested in that, personally. But this strikes me as the Linux version of "You're holding it wrong." ( http://www.engadget.com/2010/06/24/apple-responds-over-iphone-4-reception-issues-youre-holding-th/ http://www.engadget.com/2010/06/24/apple-responds-over-iphon... )
- qwertyuiop924 11y agoUbuntu actually does make it hard to find files. Is it in /usr/bin? /usr/local/bin? /bin? /sbin? /etc/bin? /opt? /god-knows-what-directory? Honestly, on linux, there should be /usr/local/bin, which is never touched by system management, for source installations, /sbin for emergency recovery tools, and /usr/bin for EVERYTHING ELSE. This is pretty much the only thing that fdo got right.
- SteveNuts 11y agofor executables, use which <name> for everything else, use mlocate sudo updatedb locate <name> I don't see how that's hard at all.
- pvaldes 11y ago> use wich <name> or the even easier to remember 'whereis <name>'
- ryfm 11y agoI recently started playing with lisp in ubuntu and decided to go with slime for it. So i installed slime through ubuntu software manager, couldn't find it, couldn't start it (i'm totally new to emacs and slime). After that I read some manuals, made changes to .emacs config and eventually installed slime using emacs and its package manager. Now i'm wondering if i have 2 versions of slime where are they located, which one is being actually used etc.
- Avshalom 11y agoWhy should anyone need to have admin privileges to find a file?
- fnordfnordfnord 11y agoBecause updatedb needs to look at your system's private parts. Try find /. | grep [string] which will look everywhere for [string]
- adrusi 11y ago
- imh 11y agoI wish I'd seen something like this when I first started using ubuntu. As with most things linux, it's very sensible if you know what to look for (which is the hard part).
- angdis 11y agoI think the underlying problem here is the expectation that you, the user, should be able to find stuff by looking "in" particular places. This is perfectly reasonable if you're dealing with a fairly limited set of files or executables, but that era has been slipping away for the last 5 years or more. It is no surprise that the question comes from 2011. I believe that was near when Unity came out and Ubuntu did away with mouse menus to find "Programs" in favor of just searching for what you have. A lot of folks did not like it at first but I think its no longer an issue.
- drzaiusapelord 11y ago>A lot of folks did not like it at first but I think its no longer an issue. The sudden popularity of Mint and ElementaryOS at the time of Unity tells me its still an issue. Those who care just left. Personally, I couldn't use Unity on a daily basis for this and other reasons.
- angdis 11y agoOK, but even now Windows folks have largely given up on pressing <windows>/<All Programs> and looking for what they want. There's simply too much stuff on a typical computer these days for a user to pick out what they want from a dropdown, yes, even if nested. It is the same problem that Yahoo once had back in the day when it tried to "Categorize" the internet. At some point such attempts at categorization break down and you gotta look at more sophisticated strategies for search.
- csydas 11y agoWell, I think this is sort of where Spotlight on OS X came from. Spotlight was pushed pretty hard when it came out as the new way to interact with your files, and for the most part it has lived up to its claims, allowing you to search concepts or text within a file and get nigh instant results, and it has only gotten better with SSDs now being default in so many Macs. Of the users I've worked with over the last 10 years, many older users still hang on to rigid folder hierarchies, but I have noticed some users who are used to Spotlight and the faster Windows searches doing away with these strict hierarchies in favor of just a really well indexed search.
- auvrw 11y agowhich <executable> dpkg -L <package> will find anything that's in program files. i think this is a really good post, though, b/c it demonstrates something that happens when we use engineered things on all levels: "different" is (perhaps falsely) equated with "difficult." i suppose it would be possible to make a package that uses FUSE or something to provide a /prog_files with a similar directory structure to what a windows user would expect, but... nah : )
- fnordfnordfnord 11y agoI don't agree that it is so much easier to find a file on Windows, but yeah searching for files on Linux could be a lot more user (or new user) friendly.