Between the App Store and the Adobe Creative Cloud, I freely delete large apps when they're not in daily use. For example, I use Adobe After Effects about once every three or four months. It's a 1.8 GB app, and my SSD is pretty small. So I install it when I need to use it and delete it when I'm done with that project.
It's pretty handy—I definitely wouldn't have done that in the old days of slow CD-ROM installers and serial number stickers.
You're damned if you do, you're damned if you don't. If you request access to the camera because you might need it in the future, you risk turning off a group of users who may rightly ask why their calendar app wants the camera.
I agree—in the past, I deleted apps that update very frequently, especially if I hadn't used them since the last update. But recently iOS has switched to automatic updates, and now I don't think about it.
I wonder if OS X will switch to auto updates. It's one thing to have a 10 MB Tweetbot update happen in the background, but something like Final Cut Pro might come with a 1GB update.
Well, I have four debit cards from the same bank (my account, joint account with my wife, and cards for two businesses), and they all look identical (the CC lettering is emboss-only). So Coin would be an improvement in a half-drunk scenario.:)
Sadly, none of my cards have chips, which is a bit of a hassle when traveling to Europe.
I doubt they would send the CC#s to the server, since it's not needed for the Coin to function. You swipe a card, it stores it locally, then sends it to the Coin via Bluetooth. Why would you need the internet for that?
And that is why they should have sold to FB and walked away. Let FB take the flak for adding ads to Snapchat. Now they're basically screwed. They either have to sell themselves for more than $3B to someone (who?), or take the company public.
Going public will be a nightmare for them, because investors and the board will demand that they have a hard plan for monetization. They'll need to immediately start running ads. When that doesn't work (it won't), they'll have to awkwardly insinuate themselves into other markets. It hasn't worked for Groupon.
Oh, I didn't realize you were the author of jor1k! It's amazing. Congratulations! I also didn't realize it was completely hand-written, rather than cross-compiled to asm.js. That is impressive.
It definitely seems like you've gained a lot of speed by hand-coding the emulator. Have you seen jsbochs? I'd be curious to test it against the Virtual x86 you linked to.
I just looked up what exact model my MBP was. It was a MC226LL/A, running a Intel Core 2 Duo T9600 at 2.8 GHz. That particular model averages about 2800, but there are scores in the 2500s, and there were lower end MBP 17s released that year.
So yes, the new iPhone does match a 2009 MBP 17. In any case, we agree that this is a fast phone (not to discount the new Nexus or other top-of-the-line Androids, which as fast or faster).
I think the thing with desktops / laptops is that we reached "way, way fast enough" a while back. The most processor-intensive thing most people will do is play 1080p content via YouTube or Netflix, which is a pretty low bar to clear. Couple that with declining computer sales at the same time as increasing smartphone sales, and it's definitely easy to see why the gap is narrowing. That's why I think it's inevitable that we'll get an ARM-based MacBook at some point.
Ugh, exactly—except Java runs in more browsers. I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js.
It's possible to compile bochs to Javascript using Emscripten, so it's only a matter of time. If you do get Crisis running, let us know what kind of framerate you're getting.:)
I was mistaken—I misremembered the baseline. The Geekbench 3 baseline is 2500 for the single core score of a 2011 Mac Mini.
But my MacBook Pro 17 was a top of the line machine 4 years ago, not five. It's still pretty impressive that the 5s (and yes, top-end Android phones) can match it.
Oh, you're right—I had remembered the Geekbench 3 baseline (2500) as a 2011 Mac Mini multi-core, but the baseline is the single-core score.
In any case, 2500 is very impressive for a phone. I did a lot of 3D rendering and video editing on that old 17" MacBook Pro, and this phone is just as fast.
Yes, the 5s is incredibly fast. With a Geekbench score of 2523, it's faster than a 2011 Mac Mini (which were not slow machines by any means). It matches my last workhorse, a 17" MacBook Pro, which clocked in at 2524.
Incidentally, it doesn't take a weatherman to know which way the wind blows. Intel recently started up ARM production for the first time ever, and Apple has been referring to the A7 as "desktop class." It's only a matter of time before they ship the first ARM MacBook.
All of this is relevant to JavaScript, because as developers look to bridge the ARM/i386 and Mobile/Desktop worlds, web apps will look more and more attractive. This Linux emulator is a good proof of concept that you can basically do anything as a web app now. The floodgates are open.
Gmail uses a highly non-standard implementation of IMAP, which never worked quite right in the previous versions of Mail.app. Mail is expecting a more or less standards-compliant IMAP server. Well, people complained, so Apple modified Mail.app to special case Gmail. Unfortunately the fix looks a bit buggy at the moment.
I suppose that may be true, but I have to refer to this canonical xkcd. Every change will break some niche workflow. The real question is: To what degree will it impact the company in particular and the ecosystem in general?
Many elevators and ATMs still run Windows XP—a truly frightening thought. If Windows Vista, 7 or 8 breaks some obscure elevator software, it doesn't really impact Microsoft, even if it costs them thousands of licenses per year. Commercial apps are forced to keep up so they can keep making sales, but for a niche or in-house app, it will probably end up running on old hardware, old software, or a VM. The fact that you may still be able to run an applet from the 1990s is a testament to the resiliency of Java, but in my opinion, it doesn't have any bearing on the state of browsers today.
I think you're right about the importance of individual players, but the overall trend is unstoppable. Google, Apple, Microsoft, Yahoo and Mozilla all want JS to take over for different reasons. In contrast, none of those companies care about client-side Java, and some actively hate it.
I do think it's a bummer for groups with a lot of legacy Java. I wonder if it's possible to go from Java -> LLVM -> JS, using VMKit and Emscripten as starting points. Obviously it would be quite a process, but it could be less work than scrapping millions of lines of code.
For example, I have a Java applet which downloads, decompresses and processes data from a bug tracking system. How should I implement this in HTML5?
I would argue that you shouldn't do this, period. If you need to download data, just provide a link to the data in HTML. The user can open the file however they want, which gets you around the horrendous security implications of what you're doing now.
Losing my moderation on this thread to respond. I've been on the web since 1994, and when Netscape 2.0 came out, I eagerly tried out the new features, which included JavaScript, Java and background images. In my experience, the performance of Java was never good. In 1995 it was terrible, but as the VM improved, it advanced to merely "slow."
To this day, all of the end-user Java applications I've encountered are noticeably sluggish. I use Cyberduck and Vuze regularly, and the UI is not as responsive as it should be. The JVM may be extremely optimized for hardcore math, but for end users, Java is still slow. I'll go ahead and preemptively duck as I mention the long battle with "lag" in Android.
There was a technology introduced in Netscape 2.0 that ended up fulfilling the dream of cross platform development, but ironically, it wasn't Java. It was that goofy joke Javascript, which I abused to make ASCII animations in the title bar. JS had no Sun Microsystems pedigree. It had no stated goal of uniting platforms. But in the past 18 years, it gradually became incredibly fast and capable. The DOM is extremely optimized and even GPU accelerated on some platforms. Media queries mean you can reconfigure the UI without any code. And whatever you think of Apple, Java doesn't run on the hundreds of millions of iOS devices out there.
The result is that a web app written in JavaScript is actually faster, more portable and more flexible than the same app written in Java. If you had told me that in 1995, I never would have stopped laughing. But I have to agree that developing an applet in 2013 is, in a word "stupid." Java is only necessary if you're doing something exceptionally un-web-like with the web, like requiring a USB signature dingus, but that's just stupid in a different sense.
Slashdot Mirror
Between the App Store and the Adobe Creative Cloud, I freely delete large apps when they're not in daily use. For example, I use Adobe After Effects about once every three or four months. It's a 1.8 GB app, and my SSD is pretty small. So I install it when I need to use it and delete it when I'm done with that project.
It's pretty handy—I definitely wouldn't have done that in the old days of slow CD-ROM installers and serial number stickers.
You're damned if you do, you're damned if you don't. If you request access to the camera because you might need it in the future, you risk turning off a group of users who may rightly ask why their calendar app wants the camera.
I agree—in the past, I deleted apps that update very frequently, especially if I hadn't used them since the last update. But recently iOS has switched to automatic updates, and now I don't think about it.
I wonder if OS X will switch to auto updates. It's one thing to have a 10 MB Tweetbot update happen in the background, but something like Final Cut Pro might come with a 1GB update.
Well, I have four debit cards from the same bank (my account, joint account with my wife, and cards for two businesses), and they all look identical (the CC lettering is emboss-only). So Coin would be an improvement in a half-drunk scenario. :)
Sadly, none of my cards have chips, which is a bit of a hassle when traveling to Europe.
I doubt they would send the CC#s to the server, since it's not needed for the Coin to function. You swipe a card, it stores it locally, then sends it to the Coin via Bluetooth. Why would you need the internet for that?
People who have separate business and personal debit cards, to start.
And that is why they should have sold to FB and walked away. Let FB take the flak for adding ads to Snapchat. Now they're basically screwed. They either have to sell themselves for more than $3B to someone (who?), or take the company public.
Going public will be a nightmare for them, because investors and the board will demand that they have a hard plan for monetization. They'll need to immediately start running ads. When that doesn't work (it won't), they'll have to awkwardly insinuate themselves into other markets. It hasn't worked for Groupon.
Oh, I didn't realize you were the author of jor1k! It's amazing. Congratulations! I also didn't realize it was completely hand-written, rather than cross-compiled to asm.js. That is impressive.
It definitely seems like you've gained a lot of speed by hand-coding the emulator. Have you seen jsbochs? I'd be curious to test it against the Virtual x86 you linked to.
I just looked up what exact model my MBP was. It was a MC226LL/A, running a Intel Core 2 Duo T9600 at 2.8 GHz. That particular model averages about 2800, but there are scores in the 2500s, and there were lower end MBP 17s released that year.
So yes, the new iPhone does match a 2009 MBP 17. In any case, we agree that this is a fast phone (not to discount the new Nexus or other top-of-the-line Androids, which as fast or faster).
I think the thing with desktops / laptops is that we reached "way, way fast enough" a while back. The most processor-intensive thing most people will do is play 1080p content via YouTube or Netflix, which is a pretty low bar to clear. Couple that with declining computer sales at the same time as increasing smartphone sales, and it's definitely easy to see why the gap is narrowing. That's why I think it's inevitable that we'll get an ARM-based MacBook at some point.
Ugh, exactly—except Java runs in more browsers. I honestly don't know who NaCl is for, or what problem it's trying to solve that can't be addressed with asm.js.
It's possible to compile bochs to Javascript using Emscripten, so it's only a matter of time. If you do get Crisis running, let us know what kind of framerate you're getting. :)
I was mistaken—I misremembered the baseline. The Geekbench 3 baseline is 2500 for the single core score of a 2011 Mac Mini.
But my MacBook Pro 17 was a top of the line machine 4 years ago, not five. It's still pretty impressive that the 5s (and yes, top-end Android phones) can match it.
Not necessarily. Just start with an x86 emulator instead of an OpenRISC emulator.
Really, with Emscripten you can do just about anything. There was a classic Mac emulator posted about a month ago.
No need—it has already been done.
Oh, you're right—I had remembered the Geekbench 3 baseline (2500) as a 2011 Mac Mini multi-core, but the baseline is the single-core score.
In any case, 2500 is very impressive for a phone. I did a lot of 3D rendering and video editing on that old 17" MacBook Pro, and this phone is just as fast.
Oh right, I forgot about XScale. Well in any case, it's an interesting move on Intel's part.
Yes, the 5s is incredibly fast. With a Geekbench score of 2523, it's faster than a 2011 Mac Mini (which were not slow machines by any means). It matches my last workhorse, a 17" MacBook Pro, which clocked in at 2524.
Incidentally, it doesn't take a weatherman to know which way the wind blows. Intel recently started up ARM production for the first time ever, and Apple has been referring to the A7 as "desktop class." It's only a matter of time before they ship the first ARM MacBook.
All of this is relevant to JavaScript, because as developers look to bridge the ARM/i386 and Mobile/Desktop worlds, web apps will look more and more attractive. This Linux emulator is a good proof of concept that you can basically do anything as a web app now. The floodgates are open.
With the introduction of Web Workers, JavaScript is no longer single threaded. It's pretty nice!
Gmail uses a highly non-standard implementation of IMAP, which never worked quite right in the previous versions of Mail.app. Mail is expecting a more or less standards-compliant IMAP server. Well, people complained, so Apple modified Mail.app to special case Gmail. Unfortunately the fix looks a bit buggy at the moment.
I suppose that may be true, but I have to refer to this canonical xkcd. Every change will break some niche workflow. The real question is: To what degree will it impact the company in particular and the ecosystem in general?
Many elevators and ATMs still run Windows XP—a truly frightening thought. If Windows Vista, 7 or 8 breaks some obscure elevator software, it doesn't really impact Microsoft, even if it costs them thousands of licenses per year. Commercial apps are forced to keep up so they can keep making sales, but for a niche or in-house app, it will probably end up running on old hardware, old software, or a VM. The fact that you may still be able to run an applet from the 1990s is a testament to the resiliency of Java, but in my opinion, it doesn't have any bearing on the state of browsers today.
I think you're right about the importance of individual players, but the overall trend is unstoppable. Google, Apple, Microsoft, Yahoo and Mozilla all want JS to take over for different reasons. In contrast, none of those companies care about client-side Java, and some actively hate it.
I do think it's a bummer for groups with a lot of legacy Java. I wonder if it's possible to go from Java -> LLVM -> JS, using VMKit and Emscripten as starting points. Obviously it would be quite a process, but it could be less work than scrapping millions of lines of code.
I would argue that you shouldn't do this, period. If you need to download data, just provide a link to the data in HTML. The user can open the file however they want, which gets you around the horrendous security implications of what you're doing now.
Exactly. When the CEO can't access the site from his wife's iPad, it all moves to JavaScript pretty quickly.
Yes: don't use the web.
Losing my moderation on this thread to respond. I've been on the web since 1994, and when Netscape 2.0 came out, I eagerly tried out the new features, which included JavaScript, Java and background images. In my experience, the performance of Java was never good. In 1995 it was terrible, but as the VM improved, it advanced to merely "slow."
To this day, all of the end-user Java applications I've encountered are noticeably sluggish. I use Cyberduck and Vuze regularly, and the UI is not as responsive as it should be. The JVM may be extremely optimized for hardcore math, but for end users, Java is still slow. I'll go ahead and preemptively duck as I mention the long battle with "lag" in Android.
There was a technology introduced in Netscape 2.0 that ended up fulfilling the dream of cross platform development, but ironically, it wasn't Java. It was that goofy joke Javascript, which I abused to make ASCII animations in the title bar. JS had no Sun Microsystems pedigree. It had no stated goal of uniting platforms. But in the past 18 years, it gradually became incredibly fast and capable. The DOM is extremely optimized and even GPU accelerated on some platforms. Media queries mean you can reconfigure the UI without any code. And whatever you think of Apple, Java doesn't run on the hundreds of millions of iOS devices out there.
The result is that a web app written in JavaScript is actually faster, more portable and more flexible than the same app written in Java. If you had told me that in 1995, I never would have stopped laughing. But I have to agree that developing an applet in 2013 is, in a word "stupid." Java is only necessary if you're doing something exceptionally un-web-like with the web, like requiring a USB signature dingus, but that's just stupid in a different sense.