6 ms·

This is why I don't run any Electron apps on my computers at all, ever. That means I'm stuck with the web browser version of Slack, Skype, Signal (going away),

by zx2c4 9y ago

This is why I don't run any Electron apps on my computers at all, ever. That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron. I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's been around for ages and continually sees updates. Usually people who see the Qt light are pretty satisfied. It can also be used from a wide variety of languages, in case you're not into writing C++. I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers who otherwise wouldn't have had any clue how to make desktop/native applications. However, do I really want to be running unsandboxed xss==>rce code written by clueless devs? No, no I do not. So, in the end, refusing to run Electron apps turns out to be a somewhat reasonable security posture.

gcb0 9y ago
welcome to the history loop! it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs. I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries. then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images! good luck with that
- styfle 9y ago
  As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL. The solution, is to bump the version in the dockerfile, rebuild, and deploy. This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines. Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs. Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.
  - gcb0 9y ago
    when it works for containers, it would have worked just the same for shared lib, but with one less step. containers: update the lib, rebuild. sane software: update the lib. now, to the complicated case which containers claim to solve, when the lib update breaks compatibility. container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways. sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.
    - AluminiumPoint 9y ago
      Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers. I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good
      - gcb0 9y ago
        with shared libraries containers are an option just fine
  - xorcist 9y ago
    Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.
- frou_dh 9y ago
  > it is a very known fact for all unix grey beards ... It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.
  - gcb0 9y ago
    Go packaging philosophy goes against that. but go is also released in a good enough state and things are being done right on the fly.
- ryanplant-au 9y ago
  > a very known fact for all unix grey beards The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.
  - neoeldex 9y ago
    It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code... Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.
    - xfer 9y ago
      And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).
  - pjmlp 9y ago
    The same Rob Pike also stated that UNIX is past its due date.
qudat 9y ago
All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary would need to offer more than a cross platform desktop app.
- DandyDev 9y ago
  It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.
  - tcd 9y ago
    Sure, you can hate a programming language. It changes absolutely nothing, except your potential revenue streams. It's like saying "I loathe Linux!!" and knowing nothing about it; sure, but in this industry, you're going to have a tough time :)
    - rootlocus 9y ago
      To be fair, JavaScript hardly deserves being compared to Linux. People don't loathe JavaScript for no reason. The language itself is pretty rough around the edges.
      - zghst 9y ago
        Not just the edges!
  - NMDaniel 9y ago
    And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI? Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.
scrollaway 9y ago
Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes. But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS. I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen. I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment. There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app? You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core. Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.
- pjmlp 9y ago
  The thing is, with the desktop Web in the end what we get is ChromeOS, a browser window manager that makes the actual kernel completely irrelevant. The adoration of Electron apps among Linux users will be the final nail on the year of desktop Linux.
- chrisweekly 9y ago
  > “really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies” did you mean /s/start/stop/ above?
Tehnix 9y ago
> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible". Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.
- josephg 9y ago
  I'm really surprised we haven't seen the functional style of elm, react and friends backported into modern gui frameworks. A react-like framework for native apps written entirely in swift would be killer - swift is a much better language than JS, and the resulting apps would be much smaller and snappier than what we get with electron or react native. C#/F# would be a great candidate for this kind of thing too.
- blub 9y ago
  Qt QML is JS with a declarative UI language and C++ when you need it. On the other hand you have JS with a document markup language combined with style sheets. And the first one is embarassing you say. And declaring UIs in HTML and CSS is easier than in QML. Why do you even post this. I mean... it's trivial to disprove it. Do you subscribe to the idea that if one makes enough noise their arguments will win out?
- orodley 9y ago
  >the ease of CSS/HTML Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.
ec109685 9y ago
On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.

by zx2c4 9y ago

gcb0 9y ago

welcome to the history loop! it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs. I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries. then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images! good luck with that

styfle 9y ago
As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL. The solution, is to bump the version in the dockerfile, rebuild, and deploy. This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines. Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs. Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.
- gcb0 9y ago
  when it works for containers, it would have worked just the same for shared lib, but with one less step. containers: update the lib, rebuild. sane software: update the lib. now, to the complicated case which containers claim to solve, when the lib update breaks compatibility. container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways. sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.
  - AluminiumPoint 9y ago
    Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers. I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good
    - gcb0 9y ago
      with shared libraries containers are an option just fine
- xorcist 9y ago
  Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.
frou_dh 9y ago
> it is a very known fact for all unix grey beards ... It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.
- gcb0 9y ago
  Go packaging philosophy goes against that. but go is also released in a good enough state and things are being done right on the fly.
ryanplant-au 9y ago
> a very known fact for all unix grey beards The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.
- neoeldex 9y ago
  It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code... Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.
  - xfer 9y ago
    And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).
- pjmlp 9y ago
  The same Rob Pike also stated that UNIX is past its due date.

qudat 9y ago

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary would need to offer more than a cross platform desktop app.

DandyDev 9y ago
It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.
- tcd 9y ago
  Sure, you can hate a programming language. It changes absolutely nothing, except your potential revenue streams. It's like saying "I loathe Linux!!" and knowing nothing about it; sure, but in this industry, you're going to have a tough time :)
  - rootlocus 9y ago
    To be fair, JavaScript hardly deserves being compared to Linux. People don't loathe JavaScript for no reason. The language itself is pretty rough around the edges.
    - zghst 9y ago
      Not just the edges!
- NMDaniel 9y ago
  And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI? Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

scrollaway 9y ago

Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes. But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS. I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen. I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment. There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app? You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core. Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.

pjmlp 9y ago
The thing is, with the desktop Web in the end what we get is ChromeOS, a browser window manager that makes the actual kernel completely irrelevant. The adoration of Electron apps among Linux users will be the final nail on the year of desktop Linux.
chrisweekly 9y ago
> “really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies” did you mean /s/start/stop/ above?

Tehnix 9y ago

> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible". Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.

josephg 9y ago
I'm really surprised we haven't seen the functional style of elm, react and friends backported into modern gui frameworks. A react-like framework for native apps written entirely in swift would be killer - swift is a much better language than JS, and the resulting apps would be much smaller and snappier than what we get with electron or react native. C#/F# would be a great candidate for this kind of thing too.
blub 9y ago
Qt QML is JS with a declarative UI language and C++ when you need it. On the other hand you have JS with a document markup language combined with style sheets. And the first one is embarassing you say. And declaring UIs in HTML and CSS is easier than in QML. Why do you even post this. I mean... it's trivial to disprove it. Do you subscribe to the idea that if one makes enough noise their arguments will win out?
orodley 9y ago
>the ease of CSS/HTML Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.

ec109685 9y ago

On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.