5 ms·

Re. keybindings: you can change your default GTK bindings to Emacs-style if you want to. Whether the super/Windows/Command key should be used for window managem

by snazz 8y ago

Re. keybindings: you can change your default GTK bindings to Emacs-style if you want to. Whether the super/Windows/Command key should be used for window management or application controls is still up for debate; it always bothers me whenever I have to use a Mac that some browser bindings are already taken by the WM/OS because Cmd is shared between apps and the OS. There are very few bindings that you can’t change on Linux or another non-Mac Unix-like. Re. file history: use real version control or a filesystem with this functionality (I imagine that ZFS would). Better to just use Git. Re. Cmd-?: no alternative exists that I know of. However, menu bars are usually less prevalent on software written for traditional Unix than on a Mac. Re. Finding files: GNOME does this with the search bar OOTB it appears. Otherwise, use search in Nautilus like you would in Finder. Re. Memory presssure: search “swappiness Linux” into a search engine. Do you prefer maximum available memory or responsiveness? Linux gives you the choice here. Recency, contents and type can all be sorted with Nautilus on GNOME. I’m not aware of a way to find very specific files that meet your search query quite like you mentioned (although I’m sure they exist). I would pipe file into grep personally, but that’s probably too rudimentary for what you want.

patrec 8y ago
> Better to just use Git. How would this help with my example? Git is terrible for managing non-text files and has zero support for browsing such files interactively. It also doesn't work at the file level and is pretty much unusable for anyone who isn't a developer. > Re. keybindings: you can change your default GTK bindings to Emacs-style if you want to. Yeah, but that doesn't really work, it just makes the whole mess even worse (oops, no longer can select everything with a shortcut, webapps, other toolkits don't care etc). > Do you prefer maximum available memory or responsiveness? Linux gives you the choice here. It doesn't. I want responsiveness, but I can't have it. Turning off overcommit (and swap) does improve responsiveness but is not a viable option for a desktop system, apps will just break if you turn off overcommit completely. > Recency, contents and type can all be sorted with Nautilus on GNOME. For me this works neither reliably nor with acceptable performance (unsurprising since a proper version needs FS integration).
- laumars 8y ago
  > Turning off overcommit (and swap) does improve responsiveness but is not a viable option for a desktop system Back when I got my first SSD I ran Linux without a swap file/partition. I did this partly because it was only a 60GB SSD so I wanted to conserve space. I also did it because I didn't want to shorten the life of the SSD with (this was back when such a thing was a concern) and I ran that set up for years on a pretty modest 8GB RAM with KDE installed (ie not just a lightweight tiling WM). > unsurprising since a proper version needs FS integration It really doesn't and apfs (your file system in OSX) doesn't even do this. In fact it's probably better that your meta-data indexer isn't embedded into your file system driver because you're just going to slow down file system operations - which matters a lot on UNIX-based platforms because they do lots of file system operations. A far better approach is to have your indexer run as a separate process that monitors file writes (you can still have a kernel hook for that if you wish) thus you can then catalogue your files without interrupting your normal file system operations. You can also add more granularity like separate database per home directory (which would be much harder to do securely if you were embedding that code into the fs driver without then going down the route of having multiple tanks ala ZFS). It also makes it much easier to optimize your meta-data db since you can now dump everything into a RDBMS rather than attached to the space constrained inodes. For what it's worth, this is another area I have first hand experience with because I've written a few hobby file systems over the years. Nothing serious nor performant; just myself messing around with a few ideas. But it's still earned me a greater appreciation for the design decisions behind the file systems we do commonly use.
  - patrec 8y ago
    > Back when I got my first SSD I ran Linux without a swap file/partition You can turn off swap if you don't need hibernate, and from memory even turning off overcommit used to be OK-ish (of course most software written for linux doesn't try to deal with failing malloc requests gracefully, because there's no point since it never happens in the default configuration). You end up with a noticeably snappier system. However, this no longer seems to work in practice. Try turning off overcommit completely and see how long it takes Chrome to crash even if you have a lot of available memory. > A far better approach is to have your indexer run as a separate process that monitors file writes (you can still have a kernel hook for that if you wish) This is how spotlight works though, no? It's a separate process gets notified by the kernel on file system changes and then indexes them (that's what I meant with FS integration). I agree that you don't want to synchronously update all indexing meta info on FS operations because everything will grind to a halt if you do that. But you still want OS support such as reliable notification and extended FS attributes to store things like "this was downloaded from here" or tagging. I don't think there is anything particularly magical about this (spotlight is 15 years old tech and linux has had xattr support in all major file systems for ages) but in practice xattrs end up pretty much useless in linux because next to nothing uses them (baloo probably does) and as far as I'm aware there is no robust file system change notification API (you can use inotify for some stuff, but it's limited in various ways). I'd love to be wrong about this though. I think the situation is better on macOS, but it might just be that spotlight is more polished and there is no fundamental difficulty in writing the same for linux these days.

by snazz 8y ago

patrec 8y ago

> Better to just use Git. How would this help with my example? Git is terrible for managing non-text files and has zero support for browsing such files interactively. It also doesn't work at the file level and is pretty much unusable for anyone who isn't a developer. > Re. keybindings: you can change your default GTK bindings to Emacs-style if you want to. Yeah, but that doesn't really work, it just makes the whole mess even worse (oops, no longer can select everything with a shortcut, webapps, other toolkits don't care etc). > Do you prefer maximum available memory or responsiveness? Linux gives you the choice here. It doesn't. I want responsiveness, but I can't have it. Turning off overcommit (and swap) does improve responsiveness but is not a viable option for a desktop system, apps will just break if you turn off overcommit completely. > Recency, contents and type can all be sorted with Nautilus on GNOME. For me this works neither reliably nor with acceptable performance (unsurprising since a proper version needs FS integration).

laumars 8y ago
> Turning off overcommit (and swap) does improve responsiveness but is not a viable option for a desktop system Back when I got my first SSD I ran Linux without a swap file/partition. I did this partly because it was only a 60GB SSD so I wanted to conserve space. I also did it because I didn't want to shorten the life of the SSD with (this was back when such a thing was a concern) and I ran that set up for years on a pretty modest 8GB RAM with KDE installed (ie not just a lightweight tiling WM). > unsurprising since a proper version needs FS integration It really doesn't and apfs (your file system in OSX) doesn't even do this. In fact it's probably better that your meta-data indexer isn't embedded into your file system driver because you're just going to slow down file system operations - which matters a lot on UNIX-based platforms because they do lots of file system operations. A far better approach is to have your indexer run as a separate process that monitors file writes (you can still have a kernel hook for that if you wish) thus you can then catalogue your files without interrupting your normal file system operations. You can also add more granularity like separate database per home directory (which would be much harder to do securely if you were embedding that code into the fs driver without then going down the route of having multiple tanks ala ZFS). It also makes it much easier to optimize your meta-data db since you can now dump everything into a RDBMS rather than attached to the space constrained inodes. For what it's worth, this is another area I have first hand experience with because I've written a few hobby file systems over the years. Nothing serious nor performant; just myself messing around with a few ideas. But it's still earned me a greater appreciation for the design decisions behind the file systems we do commonly use.
- patrec 8y ago
  > Back when I got my first SSD I ran Linux without a swap file/partition You can turn off swap if you don't need hibernate, and from memory even turning off overcommit used to be OK-ish (of course most software written for linux doesn't try to deal with failing malloc requests gracefully, because there's no point since it never happens in the default configuration). You end up with a noticeably snappier system. However, this no longer seems to work in practice. Try turning off overcommit completely and see how long it takes Chrome to crash even if you have a lot of available memory. > A far better approach is to have your indexer run as a separate process that monitors file writes (you can still have a kernel hook for that if you wish) This is how spotlight works though, no? It's a separate process gets notified by the kernel on file system changes and then indexes them (that's what I meant with FS integration). I agree that you don't want to synchronously update all indexing meta info on FS operations because everything will grind to a halt if you do that. But you still want OS support such as reliable notification and extended FS attributes to store things like "this was downloaded from here" or tagging. I don't think there is anything particularly magical about this (spotlight is 15 years old tech and linux has had xattr support in all major file systems for ages) but in practice xattrs end up pretty much useless in linux because next to nothing uses them (baloo probably does) and as far as I'm aware there is no robust file system change notification API (you can use inotify for some stuff, but it's limited in various ways). I'd love to be wrong about this though. I think the situation is better on macOS, but it might just be that spotlight is more polished and there is no fundamental difficulty in writing the same for linux these days.