Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

21–30 of 152 posts

Re: From Markdown to remote code execution in Atom

#21

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.

Re: From Markdown to remote code execution in Atom

#22
post #13
post #10

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 be…

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…

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.

Re: From Markdown to remote code execution in Atom

#23

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

Why? Qt/swing/gtk apps tend to look like shit and are horrible to try and code

Re: From Markdown to remote code execution in Atom

#24
post #21

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.

Cross-platform GUI development in general is a dumb idea. The user chose a specific platform and expect applications to follow that platforms UX guidelines. Building a cross-platform app is basically saying you don't give a fuck about your customers. It's an insult to your users.

Re: From Markdown to remote code execution in Atom

#25
post #13
post #10

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 be…

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…

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

Re: From Markdown to remote code execution in Atom

#26
post #21

Earlier quoted context omitted.

Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.

Cross-platform GUI development in general is a dumb idea. The user chose a specific platform and expect applications to follow that platforms UX guidelines. Building a cross-platform app is basically saying you don't give a fuck about your customers. It's an insult to your users.

So you're saying software OEMs need to pick one of Windows or MacOS and not support any other platforms?

Re: From Markdown to remote code execution in Atom

#27

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

Why? Qt/swing/gtk apps tend to look like shit and are horrible to try and code

> Qt/swing/gtk apps tend to look like shit

You couldn't be further from the truth. Have you seen the Blizzard app (Qt) [0]? The JetBrains Toolbox app(Qt) [1]?

Also, here's a small app I wrote in kotlin and swing for my GF who wanted to download music from youtube without installing crapware downloaders [2]. You'll notice it has a custom window frame, support for drag and drop, and fully customized table and buttons. I spent about 5 hours styling the UI, and half a weekend writing the entire app.

Yes, I agree, dowloading music from youtube is immoral and illegal, but I'm showcasing the UI so please ignore the underlying purpose of the app.

[0] http://l3.yimg.com/ny/api/res/1.2/v.xvnI7eUsLskyHopY6Kkg--/Y...

[1] https://www.jetbrains.com/help/img/idea/2017.2/rm_py_toolbox...

[2] https://imgur.com/J29HJJk

Re: From Markdown to remote code execution in Atom

#29
post #22
post #13

Earlier quoted context omitted.

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…

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…

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.

Re: From Markdown to remote code execution in Atom

#30
post #25
post #13

Earlier quoted context omitted.

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…

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

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.
Post reply on HN