Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

141–150 of 152 posts

Re: From Markdown to remote code execution in Atom

#141
post #102

Earlier quoted context omitted.

My argument is that it takes a few hours to make a look and feel for swing that mimics the appearance of modern electron apps. Also that Qt has plenty of styling power. Blizzard's app is a "really bad app" just because you have a personal problem against it. It works pretty well on my PC (0.5% CPU and 130Mb ram) and I think it looks pretty nice.

Lots of people dislike the Blizzard app but if you like the Blizzard app or spent 5 hours beating a single Swing frame into looking like a web app with questionable typography, we probably have very different (subjective) notions of what a decent-looking app is. What you did say is that Qt or Swing apps looking bad cannot be further from the truth. If that were the case, you should be able to rattle off dozens of bel…

> questionable typography

To be fair, I did change it a bit later to use Open Sans .

Re: From Markdown to remote code execution in Atom

#142
post #136
post #102

Earlier quoted context omitted.

Lots of people dislike the Blizzard app but if you like the Blizzard app or spent 5 hours beating a single Swing frame into looking like a web app with questionable typography, we probably have very different (subjective) notions of what a decent-looking app is. What you did say is that Qt or Swing apps looking bad cannot be further from the truth. If that were the case, you should be able to rattle off dozens of bel…

It looks like you're wasting your time arguing with a person who has not developed an appreciation for native, consistent, desktop applications.

Consistent? Where? Windows changes its style with each version. Macs may be more consistent, but they're the exception and I never owned a mac. Linux is a rainbow of diversity.

Unless someone puts in the extra effort to style the application, nothing will look consistent cross platform.

And if you want "native, consistent, desktop applications" (for the current platform), Qt has that out of the box and Swing had a native look and feel that looked pretty consistent on Windows 7 at least.

Re: From Markdown to remote code execution in Atom

#143
post #53

Earlier quoted context omitted.

Office, Photoshop.

Two very mature and high revenue products.

Sure, but once upon a time developed from scratch, always supported PC, Mac and some UNIX variations, and the Web wasn't even a thing.

Re: From Markdown to remote code execution in Atom

#144
post #114
post #7

Whilst it's very hard to write a secure C application because writing C is hard, it seems it's very hard to write a secure application in javascript because javascript is too easy. Maybe we should stop blaming language complexity and start blaming the complexity (or lack thereof) of the designs that fail us?

C isn't hard. C is easy, in fact. This is the main impetus behind its popularity: people liked it, in part because it was easy. Security is hard in c, in part because c tries to make things easy for the developer at the detriment if security. Javascript is in the exact same posistion. Why is javascript popular? Because its easy. Why is javascript easy? Because none of its features are focused on security.

C is not easy, it looks easy, that is the trap or a plain siren song.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

https://blog.regehr.org/archives/1393

Re: From Markdown to remote code execution in Atom

#145
post #116
post #83

Earlier quoted context omitted.

There are many viable compile-to-js languages out there to pick from: * clojurescript * f# via fable * c# via different means(even an MSIL compiler) * Golang * etc I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bi…

f# is the future

As clearly evidenced by how hard MS has been working to bring C# up to par these last few years :)

Naturally there are limits to how well you can retrofit something into a language compared to having that feature there from the start...

Re: From Markdown to remote code execution in Atom

#146
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…

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.

Re: From Markdown to remote code execution in Atom

#147

Earlier quoted context omitted.

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.

...or it's saying you have limited resources and want to maximize what you do with them.

The UI of your app is the one highly visible point where 99,999% of the interaction with your customers takes place. If you can't be bothered to have a good UI, how shit is the stuff I can't see as a user ?

A bad UI is a huge smell. In my experience there is a 1:1 relationship between the quality of the UI and the quality of the software as a whole.

Re: From Markdown to remote code execution in Atom

#148
post #36

Earlier quoted context omitted.

No, you create a proper abstraction layer that maps to native plaform elements. For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on. Yes, it takes some initial effort, but it only needs to be done once.

That's easy to say for a file picker on desktop OSs, but what happens when you need to layout a page on all 3 desktop plus Android and iOS? Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc... Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept…

Desktop and laptop systems tend to be in portrait orientation; phones and tablets tend to be in portrait. So you already have to either make two layout styles or accept a mediocre general solution.

Cursors and styluses are accurate, but fingers are not. So, if you make buttons sized for fingers, they feel awkwardly large (takes large hand movements to change between UI components, and the spacing means more scrolling or pages of UI), but if you size them for cursors/styluses, they are frustratingly small targets for touchscreens.

You can probably assume that most devices in portrait orientation are that way so they can be held in one hand leaving the other free to work a touchscreen, so you only need to handle three of the four combinations for a comfortable user experience in those regards.

However, there's more to it than that. Desktop users often run apps windowed, while phones tend to omit that option entirely. Mac puts the menu bar at the screen edge regardless of the window size/position, but other desktop/laptop OSs usually put the menu bar within the window border. You can remove the menu bar entirely and draw a hamburger button into your UI, but desktop users have the expectation of a menu bar and the change in convention will make the app feel like an outsider.

A desktop/laptop user will never try a long press and don't have a menu button, both of which have been used to hide extra functionality on phones, but they often do have a keyboard, and there is a massive list of keyboard shortcuts that they will automatically use. Desktop UIs have a logical tab order and that selection can be moved with the arrow keys. Cut, copy, and paste function as expected. On windows, F2 almost always means "rename selected item", F1 for help, alt-enter to toggle full screen, and so on. What about the multitude of multi-finger phone/tablet gestures? You have two very different modes on input, and users' muscle memory expects your app to fully support whichever one they are using. As an anecdote, I tried writing something in an Electron app's text box, then went for ctrl-left to jump back a word, but instead it caused a page navigation and lost the entire message I was typing. That was a frustrating "this app is an outsider on desktop" experience to me.

Your decision is effectively mediocre everywhere or customized to fit the conventions for each platform.

Re: From Markdown to remote code execution in Atom

#149

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

Would something along the lines of "React QT" be possible? React Native for desktop!

Re: From Markdown to remote code execution in Atom

#150
post #110
post #12

Earlier quoted context omitted.

I understand the sentiment and dislike laggy UIs, but browsers have been running millions of apps securely on billions of computers for ages. No browser exploit has led to worldwide data compromise. In fact, being able to run untrusted code at this scale represents the pinnacle of security engineering feats. There have also been plenty of exploits in applications written entirely with native code.

Browsers can barely open a simple web page without getting owned. They're probably the number one infection vector nowadays... This has lead to some pretty bad hacks. I'm not sure what more you could want really, a vulnerability where people can be punched in the face over the internet?

> a vulnerability where people can be punched in the face over the internet?

That sounds like a mild form of swatting, which is already a thing.

Post reply on HN