Fifteen years of maintenance and updates (by one developer) for a free and open source tool, and just asking for donations if the user finds it useful! I'm impressed! If I were a user, I would certainly donate.
I like to think that when I see such really nice behaviour, I should supply positive reinforcement since I know how much such things can matter to people. Eg I had a really nice commuter bus ride, when about to go off, I went to the driver and said thanks, I enjoyed the ride, it was very smooth etc. I could tell this person took pride and enjoyment in doing it. I also called his employer and gave praise (using the bus number), hopefully this is reflected professionally for him too.
So you don't have to be a user to show appreciation ;)
After our meal of takeout BBQ last week I called the joint, which was brand new, and thanked them for how good everything was. As a shy telephone-allergic introvert I’d never done that before, but I’m glad I did!
edit: and re-reading my comment I feel it can come across like a manipulative sociopath comment, but I can assure you all that's not what I am. Though, that's exactly what a manipulative sociopath would say.
Activity Monitor makes it reasonably easy to check which files a process has open, but does not reasonably handle the inverse case of checking which processes have a specific file open.
I know Homebrew is vetted, but I personally like to always check where this is pulling in its installer file - and it appears to match the domain as is in the Github repo.
You might already know this but you can do that by command line with 'brew cask audit sloth' to see where it's pulling from...I'm paranoid enough too :O
> Check formula for Homebrew coding style violations. This should be run before submitting a new formula. Will exit with a non-zero status if any errors are found, which can be useful for implementing pre-commit hooks. If no formula are provided, all of them are checked.
Binary is ~200KB. The rest is mostly images, icons and whatnot, and the auto-update framework (Sparkle). Version 1.0 was 40KB zipped, back in 2004. O tempora, O bloat.
This is interesting to me because it's an example of the other side of the "Electron" argument.
`lsof` exists in Linux. At least, my Ubuntu 16.04 has it. So if this were an Electron UI, would we instantly have a Linux version as well? Or is it not that simple?
I do really enjoy the look and feel of this mac version, though.
Taking something as lightweight as an lsof command line tool and putting an entire web browser and node.js instance on top seems like we are moving in the wrong direction. It’s like we are going to need a terabyte of RAM and a Tesla battery to run basic apps of the future with even half of the performance we got out of our systems 2 decades previously.
I feel like this argument is the software engineer's version of "smaller government" political ideology. Yes, we want small, fast processes. Yes, we want efficiency. But we want efficiency _for the sake of usability_. For the Linux user, Sloth is (nearly) useless. Electron would have provided great value (at the cost of and under the burden of larger hardware, etc.) Complexity and resource usage creep isn't going away, although I applaud efforts to reduce complexity and use resources parsimoniously.
No, but "lightweight" doesn't necessarily mean performant. The size of the program's man page might be the thing that makes people want a different, more discoverable interface to the program.
> if this were an Electron UI, would we instantly have a Linux version as well?
Many Electron apps are only written in JS without any (or no neccessary) platform specific code, but some also interface with the platform. In this case, if it just calls lsof through the shell and the versions are the same, it might actually just work. If it ships with its own binary it'd need to be switched out.
Once you've got the equivalent commands for each platform, it should be possible to build and package for all of them (Mac/Win/Linux).
I've just done a tri-platform Electron app which handles quite a few platform-specific commands. (For drive listing, SD-card formatting, file decryption (in custom C apps), etc.)
It does take a lot more work (and lots of time-consuming testing). But it can be done.
> And why Electron? Why not QT, or Java swing, or some other language with GTK?
In this specific case, the app was targeted for MacOS and OS X earlier. Java really isn't a good solve on that platform. Which also makes it not a good solve for anything on the Mac platform.
I have been wanting to build a UI tool for non-techies to be a front end to a collection of shell scripts that I have been using for day-to-day tasks. I have written the scripts to be a friendly as I can make them with drag-n-drop folders as inputs rather than requiring arguments to be provided. This looks like a good example for me to use as research.
Electron apps are also horrible on the Mac (and probably everywhere else too). Buggy, bloated resource hogs with nonstandard and limited UI and incredibly high input latency for simple actions.
As a Mac user, when I hear “Electron app” I think “company that was too lazy/cheap to make a real Mac app.”
Hmm, I don't know about this. VS Code is an Electron app and I'm not sure if it would benefit that much from being a "real" Mac app. I much prefer that is it consistent across platforms. I do prefer Terminal.app to Hyper though.
I wouldn't mind if Slack had a native app but I'm not too bothered by it.
The VS code team has spent an inordinate amount of time optimizing their Electron usage to achieve some semblance of performance. VS Code is nice but it is still slower than Sublime, let alone Notepad++, Textmate, or Pluma/GTKedit
Also, if Electron apps are just a packaged up webpage, could they even do things like run shell scripts locally? I'm also wanting to allow the user to browse for a file and have the full path intact instead of just the name of the file a browser would return.
Not only that, but they have pervasive cross-site scripting vulnerabilities that are now exposing the user to remote code execution!
Also, they tend to have out of date dependencies, and are vulnerable to traditional code execution exploits that were fixed in upstream chrome long prior.
Author of Sloth here. I develop free software in my spare time and I'm not willing to pay Apple USD 100 per year for the "privilege" of developing for their platform. It's a sad state of affairs when independent developers like me have to shell out hard cash in order to give software away for free. True, USD 100 isn't much, but I'm opposed, on principle, to paying money to an enormously wealthy megacorporation just to make software for their platform. Not so very long ago, macOS had a vibrant independent developer community. It's now slowly being choked to death with this horrid App Store stuff.
I think that $100 is less of a cash grab and more of a gate to nefarious actors - they can’t trivially cycle through certificates for their malware without spending $100 every time, but $100 is likely not so much that it will hurt an independent developer. I see your perspective though. I have mixed feelings about it as well.
That is for you to assess. macOS gives you the opportunity to either override the security popup by right-clicking the app and launching it anyway, or not.
Also, the "security risk" doesn't get a whole lot smaller when the app is signed. Only widely known malware apps will get their certificates revoked in time.
The new "notarization" is slightly more thorough but the risk is still up to you and the app permissions for non-appstore non-sandboxed apps are indeed quite open. Malicious or not, an app that is not sandboxed can steal or damage your data anywhere in the filesystem.
All that an Apple signature proves is that the developer is paying Apple for the privilege. And, theoretically, apple has vetted the app to some minimal extent.
But there is little stopping a signed app from becoming malicious, so from a security standpoint, being signed doesn't ALWAYS mean being "safe".
For standard Unix tools? Not really, since they're often used in scripts and everything breaks if the formatting changes. Generally any new feature is hidden behind new flags on the command line to avoid breaking anything. There are exceptions of course but I doubt the output of lsof will change any time soon.
Meanwhile kernel ABIs can and do change between versions (the API less so, but it still means that you have to rebuild your code).
What can happen however is that a tool of the same name might have a different output or behavior on different operating systems (most notably between the GNU and BSD variants). But in this case the kernel API is probably different as well, so you'll have to implement an abstraction layer anyway.
In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itself; the interaction with userspace is where backwards compat is held as the highest guiding principle (see Linus's remarks about breaking userspace).
By contrast, lsof can change output at any time. I've not done enough parsing of lsof to be familar with past changes, but have seen meaningful changes in the default output of lsblk, df, and other core CLI tools that wrap system information.
If anyone's curious: Traditionally, lsof on BSD would just open /dev/kmem and read the info directly out of the kernel's data structures! It still does that on FreeBSD, and used to do it on macOS prior to 2006, when Apple added the more sensible (and stable) libproc.h API in one of the Tiger software updates.
Sloth dates back to 2004, at which point parsing lsof's output would definitely have been a more sensible choice than replicating the kmem parsing code. On the other hand, if I were writing something like Sloth today, though, I'd use libproc, because I think it'd be easier overall, and it would also make it more feasible to improve the core functionality (like adding a progress bar or lazy querying).
However, lsof does have a flag (-F) to specify how to format its output, explicitly documented in the man page as being intended for other programs that want to parse its output, implying that it will remain stable. And Sloth uses this flag. Thus, even from a modern perspective, its approach is perfectly reasonable.
I have Bash scripts that still run (all of them). Meanwhile I’ve had PHP deprecate functions I was using, I’ve had Python rewrite the requests library and break working 3.X scripts after an apt-get update, and node.js seems to change so fast and require so many dependencies that it’s much less likely to be maintainance-free. Bash is still my favorite scripting and automation language.
lsof is pretty common, but I don't think it is actually standard in any way, for example it is not part of POSIX or SUS which arguably are the two most influential UNIX related standards.
In addition to Sysinternal's Process Explorer, there is also a built-in application "Resource Monitor" (resmon.exe) linked on the Performance tab of the regular Task Manager.
Wardle has his own style for these apps. I’m personally not a big fan if it, since it looks out of place, but I guess it is a “branding” thing for him.
This is a nice little tool. The more I find myself running a full stack application local (when not in Docker), lsof is quite useful. Will try this out for sure!
My comment was too negative. Looks very useful. I just have trouble remembering names like this.
I don't think this is a name/sound that clicks for me.
I get the feeling too. I was just wondering about that this morning. Some times you want a name that is clearly descriptive like lock_and_clean_journal but when you have a new tool that does a lot and in a different way.. a cute name is a good symbol to indicate 'completely new context'. Otherwise we'd get meaningless glue code like
Not sure why you're getting downvoted but I can relate. There is sort of a fashion to naming projects that I think many people don't understand. To me "cute" tech project names were fashionable in 2000 - 2010 (Shoes gui toolkit for ruby comes to mind) but like any trend, it was overdone and became lame.
I too hate this phenomenon, but this one has version history going back to 2004, so it's not exactly your generic JS framework-of-the-week with nondescript cutesy name.
yeah, I don't want to be overly negative but I think this must target a very niche, possibly non-existent set of users: people who need to see all open files and sockets for whom lsof+grep is too complicated. Personally I have "sudo lsof -i | grep <port>" burned into my muscle memory and this tool just seems slower
Author of Sloth here. The controller didn't start out quite so fat, the whole thing was quite slim, 400-500 lines, when I first put Sloth together some 15 years ago. It grew as various additional features piled on over the years. However, your point is well taken. I should refactor things at some point.
This[1] video with Andy Matuschak helps with refactoring these “Mega” controllers. This[2] article also is good when it comes to breaking down controllers into smaller pieces.
I will admit it’s a hard problem for me. Putting everything into one view controller is so easy and makes certain problems go away. e.g. Storyboards are a lot easier to deal with when their outlets are in the massive view controller. Custom UIviews with storyboards are a huge pain to get working with interface builder.
