Just to clarify my ultimate point, being able to draw does not require a resistive screen. A capacitive screen with an active digitizer is plenty to get the job done.
Yes, and? You either have dementia or you weren't around back then because the AC shitposting is a tiny fraction of what it used to be in the early days of Slashdot. I suggest you go back through the story archives to refresh your memory just a bit.
Will your followup also be about how you don't own a television and you shake your fists at clouds while reminiscing about wearing onions on your belt?
But this article and the original comment are about the ZenFone 2, which is specifically running Lollipop. So it has the ART runtime, and JIT is not happening on it, and the OP was asking about things being compiled for this non-ARM architecture.
Which is why I stated multiple times that the vast majority apps are not compiled for ARM at all. They are just pure Java. So whether or not they go through Dalvik's JIT or ART's AOT makes no difference.
Except he has reality on his side. Microsoft already tried pushing "full Windows" tablets more than a decade ago. They were abysmal failures.
Yes if your talking the latest installment of Windows perhaps.
Nope, XP tablets were pretty horrendous to use.
But Legacy applications from Windows XP and even earlier days have a footprint a fraction of the size of 'current' apps while doing the exact same job.
This is hilarious considering everyone complained about how XP and its applications were "bloated" when it was the latest Windows release. Everyone was then pining for the "lightweight" Windows 2000.
And, yes, I did fail to mention that Lollipop's ART changes when things are compiled, but the end result is the same. Most apps do not use any native code so the architecture change won't have any effect.
Okay, but Lollipop is only on a small minority of phones. Either way, my point still stands. Most apps are written in Java and are architecture-independent and are compiled locally so the change from ARM to x86 won't effect most apps.
You must not have been around in the early days if you think AC shitposting is a new thing. The current level is far less than it used to be in the early days of constant GNAA and Goatse ASCII posts.
Most apps aren't geared towards any processor. Most of them are just written in plain Java and are JIT-compiled when run. So for those apps this will work perfectly fine. I believe Intel had some sort of binary translation to handle things like games where there is native code being used.
I think if they deliver on the promise, this will change the way people view their mobile devices. Motherboard replacements and case replacements will gain traction just like in the assemble your own PC era.
It will have quite a hard doing what you claim when only a fraction of a fraction of 1% of phone buyers will ever hear of its existence.
Because there are a ton of bugs. Trying to claim there is only 19 bugs out of 100s of issues is complete silliness.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1
Never claimed smart pointers solve all problems because that would be ridiculous. If you have cases that a smart pointer doesn't solve then clearly you would need to use the correct solution. But for the vast majority of cases that people use raw pointers for, they can be substituted with something safer and remove a whole host of potential bugs from their code.
In addition, references in Rust are guaranteed to be non-null.
As they are in C++. They are also compile-time checked to make sure they have been initialized. It's one of the whole reasons that references exist in C++ and should be used in place of pointers whenever possible.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1
Why you wouldn't want those standards enforced by the compiler I have no idea.
This reeks of strawman. GP never said or implied any such thing.
No, people have been able to use Rust as an alpha-quality language for pet projects for going on 3 years now. Just because you only heard of it today doesn't mean the rest of us did.
Slashdot Mirror
All of that is easy to accomplish when you can simply exclude huge swaths of kids.
Slashdot is about whatever the owners/editors think it's about.
Then I stand corrected. :)
The screen is going to work just like the N900 did. So, yes, there is touch but not multitouch.
Just to clarify my ultimate point, being able to draw does not require a resistive screen. A capacitive screen with an active digitizer is plenty to get the job done.
It doesn't. It has a Wacom stylus -- something older than even resistive screens.
Umm, yes it does. Just because the screen had a Wacom digitizer layer doesn't change the fact that the screen itself is capacitive.
Yes, and? You either have dementia or you weren't around back then because the AC shitposting is a tiny fraction of what it used to be in the early days of Slashdot. I suggest you go back through the story archives to refresh your memory just a bit.
Try to do that with a normal capacitive screen - it's like trying to draw in boxing gloves.
Never heard of this thing called a "Surface Pro". It has a capacitive screen and people draw stuff on it all the time.
They are only making a couple hundred. So it would be impossible for it to take any significant market share regardless of the fit and finish.
Will your followup also be about how you don't own a television and you shake your fists at clouds while reminiscing about wearing onions on your belt?
But this article and the original comment are about the ZenFone 2, which is specifically running Lollipop. So it has the ART runtime, and JIT is not happening on it, and the OP was asking about things being compiled for this non-ARM architecture.
Which is why I stated multiple times that the vast majority apps are not compiled for ARM at all. They are just pure Java. So whether or not they go through Dalvik's JIT or ART's AOT makes no difference.
I don't think you could be more wrong.
Except he has reality on his side. Microsoft already tried pushing "full Windows" tablets more than a decade ago. They were abysmal failures.
Yes if your talking the latest installment of Windows perhaps.
Nope, XP tablets were pretty horrendous to use.
But Legacy applications from Windows XP and even earlier days have a footprint a fraction of the size of 'current' apps while doing the exact same job.
This is hilarious considering everyone complained about how XP and its applications were "bloated" when it was the latest Windows release. Everyone was then pining for the "lightweight" Windows 2000.
And, yes, I did fail to mention that Lollipop's ART changes when things are compiled, but the end result is the same. Most apps do not use any native code so the architecture change won't have any effect.
Okay, but Lollipop is only on a small minority of phones. Either way, my point still stands. Most apps are written in Java and are architecture-independent and are compiled locally so the change from ARM to x86 won't effect most apps.
You must not have been around in the early days if you think AC shitposting is a new thing. The current level is far less than it used to be in the early days of constant GNAA and Goatse ASCII posts.
Most apps aren't geared towards any processor. Most of them are just written in plain Java and are JIT-compiled when run. So for those apps this will work perfectly fine. I believe Intel had some sort of binary translation to handle things like games where there is native code being used.
No, most of the apps are JIT compiled in the VM when run.
And yet you claim above that people are going to buy this over the countless number of cheaper phones? Care to share what your smoking?
I think if they deliver on the promise, this will change the way people view their mobile devices. Motherboard replacements and case replacements will gain traction just like in the assemble your own PC era.
It will have quite a hard doing what you claim when only a fraction of a fraction of 1% of phone buyers will ever hear of its existence.
Oh and to add, it's quite interesting that you ignored the "ICE" label that reports over 200 issues reporting internal compiler errors.
Because there are a ton of bugs. Trying to claim there is only 19 bugs out of 100s of issues is complete silliness.
Never claimed smart pointers solve all problems because that would be ridiculous. If you have cases that a smart pointer doesn't solve then clearly you would need to use the correct solution. But for the vast majority of cases that people use raw pointers for, they can be substituted with something safer and remove a whole host of potential bugs from their code.
In addition, references in Rust are guaranteed to be non-null.
As they are in C++. They are also compile-time checked to make sure they have been initialized. It's one of the whole reasons that references exist in C++ and should be used in place of pointers whenever possible.
Why you wouldn't want those standards enforced by the compiler I have no idea.
This reeks of strawman. GP never said or implied any such thing.
No, people have been able to use Rust as an alpha-quality language for pet projects for going on 3 years now. Just because you only heard of it today doesn't mean the rest of us did.