Hacker Newsnew | comments | show | ask | jobs | submit | highwind's comments login

I think they just inject iframe into the actual DOM. It's not an UI element that's part of the browser.

-----


alright thanks! The consensus seems to be injecting a sidebar div into the current page.

-----


Actually they link to the Diagnostic page for the malicious site.

-----


Then again, one cannot expect all of any website's client devices to have a correctly calibrated displays. Unless you have control over entire stack (from your service hardware all the way to client displays), you have to start your design (graphical or otherwise) with the assumption that there will be differences in how your product is perceived by your clients.

-----


Ugh... just scrolling through that page adds TON of baggage in the browser history. So much for the back button.

If I didn't click a link or a button, don't add things to history. Please.

-----


Back buttons? Where ello is going we don't need back buttons.

-----


My favourite comment ever on HN :)

-----


The part where Cosmos, the player, manipulates the memory to execute arbitrary code starts around 8:06 mark.

-----


Know More is a pre-Bezos product. Bezos took over on 10/1 and know more was launched on 10/7. Meaning planning and development on Know More must've started before Bezos' control.

-----


I'm not sure if I like introducing computer science with a physical "computer". A physical "computer" is an application of computer science. I rather start with an abstract idea of computation, but my view point is very skewed towards academia. I'd love to hear what others have to say about this approach.

-----


Why is the password limited to 16 characters long? I don't understand this limitation on any of the sites.

-----


The password length should be limited to something. 16 characters is rather short, though. (Still better than my old webmail, at exactly 6 characters, only uppercase and numbers)

-----


I don't see any reason to ever limit passwords to less than 100 characters.

-----


Agreed.

-----


Then, I'd argue that writing iOS app in Objective C is not native because there are several layers between Obj-C and the Apple A7 cpu.

There might be more layers on Firefox OS than iOS, but I'd take more abstraction layer than write speedy "native" code any day.

-----


Speed definitely still matters for everyday apps on mobile devices, because their processors are so much slower than actively-cooled desktops and laptops, and because touchscreens demand a more responsive UI. JIT runtimes have gotten faster, but statically compiling to machine code (especially when link-time optimization is used) cannot be beat for things like application launch performance. And the machine code that Objective-C compiles down to is definitely more native than bytecode for a JIT VM.

-----


Could we start to come to an agreement that maybe "Native" might be a bit of a marketing term? For example a browser rendering HTML and CSS is probably native under the current term. It is not until you get to JavaScript that things need the JIT VM.

-----


There's still objective meaning to the term, even if opinions may differ on what threshold to use for "native". HTML and CSS aren't used to do computation, bytecode and machine code are. So it doesn't make sense to talk about whether HTML and CSS are native or not, only whether the rendering engine is. JITs produce native code, but a lower quality in almost all cases when compared with ahead-of-time optimization, so there's still good reason to make a distinction.

-----


"Native" is not a marketing term, and we shouldn't pretend that it is.

It has a very specific definition in this context, and this definition requires that the application be represented in a form that's directly executable on whatever CPU is being used by the computer executing the application.

Anything that doesn't match that very simple criteria is obviously not a "native" app.

Maybe a new term is needed for describing this type of situation involving Firefox OS. I don't know what that would be, but I do know that we shouldn't go ruining an existing technical term.

-----


Would that make Android development that uses XML layouts and the Dalvik JIT VM "obviously not a native app"?

-----


Right. If there's bytecode of any sort that needs to be converted to machine code on the fly, then we aren't dealing with a native app.

We wouldn't consider a Java app running on HotSpot on a desktop or server Linux system to be considered a "native app". Thus we shouldn't consider a Java app running on Dalvik on a mobile Linux system to be considered a "native app" either.

Maybe that will change in the Android case if ART and its AOT compilation approach is more widely adopted. But that'll still be some time in the future, if ever at all.

-----


You can actual write in assembler on iOS and use that (sparingly) in your programs, which means there are optionally no layers between you and the CPU.

For almost all apps, that's unnecessary, but it's there as an option if you really need it.

-----


You see a bit of this in game development. At my old job, our engine was written in C++, however we had two copies of our matrix library: one written in C for desktop etc. and one written in ARM NEON asm, for building on iOS or with the Android NDK.

-----


That argument would have more weight if you iPhone apps were distributed as Objective C source code.

They're distributed as ARM binaries. I think the standard definition of "native" is "binary". I would argue that Firefox OS apps are not native, and neither are Android's Java based apps.

That said, I don't think the distinction necessarily matters in practice. I'm excited by Firefox OS--Mozilla tends to do cool stuff.

-----


This is usually how you codify a dynamic programming algorithm. Good to know that there's a name.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: