So you don't have to be a user to show appreciation ;)
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.
brew cask install sloth
> 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.
> audit — verifies installability of Casks
You can see where it pulls from if you provide the --download flag but as far as I can understand it does not do any other validation regarding that.
brew cask audit virtualbox --download
$ brew cask audit sloth
audit for sloth: passed
`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.
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.
As a Mac user, when I hear “Electron app” I think “company that was too lazy/cheap to make a real Mac app.”
It's a lazy, corner cutting way to build a cross platform app, and it shows.
I wouldn't mind if Slack had a native app but I'm not too bothered by it.
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.
The app has been around for years, is open source, and works really well.
Between 50Mb and 80Mb for the installer. Over 100Mb installed, depending on what is used.
What kind of security risk is this for me?
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.
So again - all up to you to decide.
But there is little stopping a signed app from becoming malicious, so from a security standpoint, being signed doesn't ALWAYS mean being "safe".
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.
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.
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.
Sloth exists only on OSX and is a GUI app.
I’d ask the opposite: Any reason anyone would anyone use Sloth over lsof?
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.
http://bhami.com/rosetta.html (ctrl-f lsof)
pony | lulee --pew | eels | cyan ..
> pony | lulee --pew | eels | cyan ..
I mean we kinda do, it's just that we're used to the bits.
ls | xargs cat | grep main >> /dev/nul 2>&1
Incidentally, powershell commands tend to be more "self-explanatory" in their naming, at least in theory.
MS did try to avoid explosion of idioms but at a tiny verbosity cost. I believe that map/reduce is a bit a good middle ground
Yep, is definitely a Mac :D
Curious what patterns you iOS developers out there do to avoid code like this? Personally I am a big fan of ReSwift.
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.