Why is it so hard to find a file in Ubuntu? (2011)
superuser.com
superuser.com
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.
Dotfiles are hidden because some people decided that configuration files ought to be hidden from the user during normal activities and so they took advantage of the originally-a-bug-feature of hidden files. This became the standard practice because at the time there was no agreed-upon location for user-local configuration (as existed for system-level config in the form of /etc), so the most logical thing to do was to just put config files inside $HOME. This clutters up the home directory, and so hiding these configuration files made sense.
Even my kids go into their .minecraft directory to install mods.
Of course that's entirely anecdotal but the point is that there are a lot of reasons people are drawn to Linux, and it's not just because of the ability and knowledge to do more. I'm happy your kids are modding minecraft, just like I thought it was cool when my cousin did the same. But, in my cousin's case at least, it wasn't because he's the type to really mess with things, but because he wanted mods and was told how to do it. I still think it's good of him, but it doesn't really mean he has any more interest in really understanding computers than he did before the mods.
I believe "%appdata%" is symlinked to the AppData folder on every version of Windows Minecraft runs on.
I knew what symlinks were but never knew Windows had them. I only learned about %appdata% from a youtube video made by a 11-13 year old kid about how to install a mod for Minecraft. They don't need to know what a symlink is or where their .appdata folder is to know how to navigate to "%appdata%".
The young ones are a bit more tech savvy than adults are giving them credit for. Are they pandered a bit without having to know as much about the internals and how things work? Sure. But they're able to navigate and follow instructions because they've literally been doing it their entire lives.
Many laptops don't have a dedicated function row ("F\d" not FN) keys. So "F8" might serve to confuse some people who have had the privilege of only ever owning a laptop (I know a few of these teens myself!)
My point was more about not knowing what those are rather than the keyboards that lack them or have alternative inputs.
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.
You can simply make SELinux / Apparmor profiles that default-restrict applications to ~/.config/<appname> and ~/.local/share/<appname> with quotas. Applications that need exceptions would be shipped with apparmor or selinux profile files to amend that.
Its also how you can make desktop Linux a lot more sophisticated in permissions management for applications. I know Apparmor at least supports the idea of network, peripheral, and display access in the same way it controls directory access. It would be a huge usability and security boon to the Linux desktop to have notifications of requests to access resources when an application does so - I think Android 6 is absolutely going in the right direction on application control, and adopting those ideas would be valuable.
What's MAC,, in the context I wrote about? Googled a bit, being a common acronym as well as abbreviation for Macintosh makes it difficult to find the right links.
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.
When I was a teenager I would lurk around there a lot to "hack" stuff.
[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.
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?
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.
for everything else, use mlocate
sudo updatedb
locate <name>
I don't see how that's hard at all.
or the even easier to remember 'whereis <name>'
find /. | grep [string]
updatedb is usually run daily by cron(8) to update the default database.
Also:
To create a private mlocate database as an user other than root, run
updatedb -l 0 -o db_file -U source_directory
Again, this about the only thing that systemd, fdo, etc. and I agree on.
thats taking a very "desktop" view on things.
Many more systems run as headless installs in some rack somewhere.
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.
For less serious searches: du -a | grep -in filename # usually works
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.
Of course, it presumes the user has the necessary technical bent.
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!
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.
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.
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.
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.
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!
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.
... 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
from a big picture perspective. 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
which <executable>
dpkg -L <package>
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 : )