Hacker News Reader

Comment by sjmulder | Hacker News Reader

This looks like such a nice app! Proper Mac UI too. I'm going to try it out as soon as I get home.

Proper Mac UI, and it's 0.6MB! :)

For me it looks like the binary is 1.4MB (which is still fantastic)

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.

It’d be like building a factory around a music box.

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.

I'm not sure that I would call something with about 40 screens of man pages "lightweight".

The size of the program’s man page doesn’t impact the performance characteristics of the program, does it?

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.

What are better starting points? QT?

Yes

> 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.

That's right.

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.

The app is older than Electron. The people who this tool were written for would probably dislike a big, slow Electron app anyway

And why Electron? Why not QT, or Java swing, or some other language with GTK?

> 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.”

I can vouch that they're terrible on Linux, too.

It's a lazy, corner cutting way to build a cross platform app, and it shows.

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.

If you want to build a simple UI on top of a script for Mac, I recommend Platypus: https://sveinbjorn.org/platypus

The app has been around for years, is open source, and works really well.

Thanks! This sounds like it might be exactly what I'm looking for, just need to find time to dig into it.

And by the same author as Sloth!

GNUStep also exists in Linux. Maybe the Linux version is just a compile away.

I wonder if it was possible to port the App to Linux using GnuStep or the Cocotron.

Except how big is the Electron app going to be?

Well, there's that ;)

Between 50Mb and 80Mb for the installer. Over 100Mb installed, depending on what is used.

It's not proper in that it is not properly signed. Gatekeeper complains that it cannot be opened because it is from an unidentified developer.

What kind of security risk is this for me?

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.

Good for you, man. That was one of the reasons I stopped using OS X.

Keep up the good work, I agree with you on that. I can’t see any reason why Apple don’t give free developer certificates to serious developers

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.

So again - all up to you to decide.

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".

Reply on news.ycombinator.com