Not really true. If you want to do something "native", you can use JNI and put anything you like behind that. You also have the usual options of launching a script or another process and using sockets or another protocol communicate to system services.
JNI isn't as easy as (say).NET native calls but that could be seen as a blessing because it encourages developers to be platform independent to avoid the pain of JNI. By contrast.NET apps can and often are peppered with native calls to DLLs and Win32 which bind them to the Win32 platform and this bleeds into other bad practices such as hardcoded assumptions about directory structure, file behaviours etc.
Java is horribly verbose at times. Not Cobol bad, but insistent on needlessly complicating code with anonymous inner classes, decorations and so on. IDEs take most of the sting out of this but there are still some obvious improvements that could have been lifted from contemporary languages like C#, Groovy etc which would have made life easier and code a lot more readable - mixins, auto types, lambda, embedded dsls and so forth.
Still, the platform itself is enormously powerful and well supported in software and hardware which is why it is so popular in the enterprise. It's stable, it's scalable and it's portable.
So, in other words, most people are screwed, because most of the manufacturers pretty much never really do updates.
"Most people" get their apps from Google Play store where presumably apps that use the exploit can be screened and killed on sight. So the vast majority of people are perfectly safe by default and moreso when firmware updates explicitly address the exploit in the installer.
It's only those idiots who get apps from warez sites who are risk and frankly what difference does it make in that situation? Anyway the exploit itself is easy to detect (the apk has 2 or more files that point to the same path) so it would be simple enough to obtain an app from a trusted source that scans an apk to see if it was affected or not before installing it. That would be a sensible precaution at the best of times.
C is the lowest common denominator and bindings including C++ can be and have been written that sit on top of it. So if you want C++ with GTK, use gtkmm.
QT bindings also exist though I suspect it would be far more difficult to write and maintain them and present them in a language-sane way due to the class hierarchy the bindings must sit over.
I think a better strategy would have been to offer GNOME 2 like functionality in GNOME 3. They sort of had this from the beginning in the fallback mode, and now have a proper "classic" desktop. Personally I think the default experience is extremely usable, certainly by people who see a desktop as a thing on which they do stuff rather than something to endlessly tinker with.
If I were a scammer I'd be seeking out people who have a higher concentration of gullible people within their ranks than the general population - churchgoers, libertarians etc. I think bitcoin users represent easy pickings and more so because the distributed and unregulated nature of bitcoins makes it easier to collect "investments" and easier to disappear afterwards.
I think GNOME went too far by cutting configurability. The inability to choose fonts and some other basic settings is greatly annoying. It doesn't mean it has to offer a kitchen sink of options (which IMO is even worse), but as a rule of thumb if OS X offers an option then GNOME 3 probably could too without compromising usability. But fundamentally I don't believe the design is broken or unsound. It's a very slick, attractive and usable user interface and for once Linux has a desktop which actually holds its own vs Apple and Microsoft.
It's also entirely customisable so there is no reason that people who don't like some of the things it does have to put up with it, e.g. use the "classic" mode or MINT extensions and it resembles GNOME 2 while still benefiting from a fast compositing desktop.
GNOME 3 got right things that Microsoft got wrong. For example Microsoft are bring back the start button (not menu) because jamming the mouse into the corner is non-obvious. GNOME 3 always allowed you to click Activities and discover the corner behaviour later. Metro doesn't bother to show you any visual context when you're in metro of what is happening on the desktop whereas GNOME puts the windows into its launcher so you can rapidly see them. Microsoft heavily relies on swipes and gestures to bring up overlays which don't work on the desktop whereas GNOME relies on conventional menus and a control panel.
In fact I don't see why people say GNOME 3 is a tablet interface at all. It's certainly a better place to produce a tablet interface from (larger buttons, scope for gestures etc.) but it's still a desktop window manager. Conversely Microsoft very clearly redesigned Windows so that it tablet friendly.
You whine about GNOME 3 being like a tablet (though it is clearly nothing of the sort) and then hold out for GNUStep offering an OS X like experience. When GNOME 3 and OS X are very clearly aiming for the exact same space in terms of user experience, usability etc.
Printing on Android is truly execrable. Some of the better apps have a "Print to PDF" which at least produces a file which can be previewed and printed from somewhere else. The remainder have nothing at all except a "Send to" option which a Cloud print app hooks into. Then the Cloud print app will do its half assed best to rerender the file format and send it to a cloud print device. And to cloud print you either have to be running a PC with Chrome as a proxy to the printer or have a special cloud print enabled printer already registered.
It's just so nasty that it's an embarrassment. Android really, really needs a set of rendering APIs that apps can use to render content to a canvas and some dialogs for previewing, printing, page setup and spooling documents to a printer via a CUPS-like API. I'm sure it doesn't even need a new API level - the printer server could be a an app, the APIs for rendering could be drawing primitives with some convenient methods for snapshotting screens for lazy apps. It could be backported like other things have been like fragments to encourage wide adoption. But it does need them.
Windows 8 works extremely well on a tablet. You have the metro UI for touch and the desktop when you're docked. The desktop means as soon as you park the tablet or connect a USB mouse / keyboard you have a full desktop. Otherwise you get an adequate touch UI. So I can fire up Eclipse for development while still having something which works while casually browsing on a train.
I think it was the high price (esp the keyboard), the lacklustre performance and the gimped OS. A change in any one of those things and it might have stood a chance. Now, it's just dead tech. I think a genuine Windows running an x86 processor in a tablet is a compelling experience but RT is just a bad idea.
I suppose if you were a professional gamer then the slight % boost might give you the edge you need. In the top rankings it might make a difference. But really any pro competition should require entrants to use regulation mice, keyboards, computers, drivers and settings to eliminate any advantage.
I would not be surprised if a lot of so-called gaming keyboards / mice and assorted other gaming junk (gloves, mats, chairs, screens) are the equivalent of Monster cables and their ilk - just an excuse to slap a large markup on something because it looks fancy, not because it objectively delivers a measurable advantage.
Almost all GPU and GPGPU programming is around a C-like language. There is some Fortran support too for CUDA and a smattering in OpenCL. I expect most developers would be using C though.
My point Einstein, is that C is the language that CUDA, Cell, OpenCL and OpenGL SL are derived from. So it's a rather useful property of MagicNewLanguage if it is similar to what people are accustomed to already, preferably allowing them to express the same concepts in a terser but similar form. Assuming that is, that the person who created MagicNewLanguage stands any hope of persuading people to use it.
Lisp code is practically unreadable thanks to all the parentheses without good formatting and even then looks totally foreign to people brought up on C or Java. For example all the computations are completely backasswards thanks to polish notation.
A better language for GPU programming would be one which at least retains the essence of C and provides convention based techniques and inference to relieve some of the effort of writing out OpenCL kernels.
Technically they could come from either but in practice? If I buy a popular game for 99c on Play which is free on a p2p site, which is most likely to be the malware?
And most likely Google and AV vendors are very active in policing the store, putting apps through their paces in virtualized devices looking for suspicious behaviour, weeding out malware attempts, remote killing any installs of said malware. Whereas if some guy who installs an apk they got from a torrent site gets none of that and probably stands a larger chance of infection to go with it.
A "gun" could be constructed from tape, a tube (plastic or metal), a rubber band and a push pin, nail or some other hard piece of metal. It only has to work well enough to reliably fire a bullet in the general direction the weapon is pointed. The components could be smuggled through (or can be sourced beyond) virtually any security checkpoint in the world and assembled. Smuggling the bullet would be another matter but I assume that a small.22 calibre could be gotten in disguised as a pen or something.
Slashdot Mirror
JNI isn't as easy as (say) .NET native calls but that could be seen as a blessing because it encourages developers to be platform independent to avoid the pain of JNI. By contrast .NET apps can and often are peppered with native calls to DLLs and Win32 which bind them to the Win32 platform and this bleeds into other bad practices such as hardcoded assumptions about directory structure, file behaviours etc.
Still, the platform itself is enormously powerful and well supported in software and hardware which is why it is so popular in the enterprise. It's stable, it's scalable and it's portable.
Well Ireland did have a summer for once this year although it's pissing it down at this moment.
So, in other words, most people are screwed, because most of the manufacturers pretty much never really do updates.
"Most people" get their apps from Google Play store where presumably apps that use the exploit can be screened and killed on sight. So the vast majority of people are perfectly safe by default and moreso when firmware updates explicitly address the exploit in the installer.
It's only those idiots who get apps from warez sites who are risk and frankly what difference does it make in that situation? Anyway the exploit itself is easy to detect (the apk has 2 or more files that point to the same path) so it would be simple enough to obtain an app from a trusted source that scans an apk to see if it was affected or not before installing it. That would be a sensible precaution at the best of times.
QT bindings also exist though I suspect it would be far more difficult to write and maintain them and present them in a language-sane way due to the class hierarchy the bindings must sit over.
I think a better strategy would have been to offer GNOME 2 like functionality in GNOME 3. They sort of had this from the beginning in the fallback mode, and now have a proper "classic" desktop. Personally I think the default experience is extremely usable, certainly by people who see a desktop as a thing on which they do stuff rather than something to endlessly tinker with.
If I were a scammer I'd be seeking out people who have a higher concentration of gullible people within their ranks than the general population - churchgoers, libertarians etc. I think bitcoin users represent easy pickings and more so because the distributed and unregulated nature of bitcoins makes it easier to collect "investments" and easier to disappear afterwards.
It's also entirely customisable so there is no reason that people who don't like some of the things it does have to put up with it, e.g. use the "classic" mode or MINT extensions and it resembles GNOME 2 while still benefiting from a fast compositing desktop.
GNOME 3 got right things that Microsoft got wrong. For example Microsoft are bring back the start button (not menu) because jamming the mouse into the corner is non-obvious. GNOME 3 always allowed you to click Activities and discover the corner behaviour later. Metro doesn't bother to show you any visual context when you're in metro of what is happening on the desktop whereas GNOME puts the windows into its launcher so you can rapidly see them. Microsoft heavily relies on swipes and gestures to bring up overlays which don't work on the desktop whereas GNOME relies on conventional menus and a control panel.
In fact I don't see why people say GNOME 3 is a tablet interface at all. It's certainly a better place to produce a tablet interface from (larger buttons, scope for gestures etc.) but it's still a desktop window manager. Conversely Microsoft very clearly redesigned Windows so that it tablet friendly.
You whine about GNOME 3 being like a tablet (though it is clearly nothing of the sort) and then hold out for GNUStep offering an OS X like experience. When GNOME 3 and OS X are very clearly aiming for the exact same space in terms of user experience, usability etc.
It's just so nasty that it's an embarrassment. Android really, really needs a set of rendering APIs that apps can use to render content to a canvas and some dialogs for previewing, printing, page setup and spooling documents to a printer via a CUPS-like API. I'm sure it doesn't even need a new API level - the printer server could be a an app, the APIs for rendering could be drawing primitives with some convenient methods for snapshotting screens for lazy apps. It could be backported like other things have been like fragments to encourage wide adoption. But it does need them.
So regain users it should be less "Do you want Firefox to be the default browser?" and more like "What is the riddle of steel?"
I don't care about that at all. A 64GB or 128GB tablet with a storage slot should be acceptable for the form factor.
Windows 8 works extremely well on a tablet. You have the metro UI for touch and the desktop when you're docked. The desktop means as soon as you park the tablet or connect a USB mouse / keyboard you have a full desktop. Otherwise you get an adequate touch UI. So I can fire up Eclipse for development while still having something which works while casually browsing on a train.
I think it was the high price (esp the keyboard), the lacklustre performance and the gimped OS. A change in any one of those things and it might have stood a chance. Now, it's just dead tech. I think a genuine Windows running an x86 processor in a tablet is a compelling experience but RT is just a bad idea.
Developers can be total whores when it comes to snagging some free shit.
I would not be surprised if a lot of so-called gaming keyboards / mice and assorted other gaming junk (gloves, mats, chairs, screens) are the equivalent of Monster cables and their ilk - just an excuse to slap a large markup on something because it looks fancy, not because it objectively delivers a measurable advantage.
Almost all GPU and GPGPU programming is around a C-like language. There is some Fortran support too for CUDA and a smattering in OpenCL. I expect most developers would be using C though.
Oh and add HLSL and Renderscript for good measure.
My point Einstein, is that C is the language that CUDA, Cell, OpenCL and OpenGL SL are derived from. So it's a rather useful property of MagicNewLanguage if it is similar to what people are accustomed to already, preferably allowing them to express the same concepts in a terser but similar form. Assuming that is, that the person who created MagicNewLanguage stands any hope of persuading people to use it.
Lisp code is practically unreadable thanks to all the parentheses without good formatting and even then looks totally foreign to people brought up on C or Java. For example all the computations are completely backasswards thanks to polish notation. A better language for GPU programming would be one which at least retains the essence of C and provides convention based techniques and inference to relieve some of the effort of writing out OpenCL kernels.
An malicious app author's chances of being in the top 30 without cause to be there are about zero.
And most likely Google and AV vendors are very active in policing the store, putting apps through their paces in virtualized devices looking for suspicious behaviour, weeding out malware attempts, remote killing any installs of said malware. Whereas if some guy who installs an apk they got from a torrent site gets none of that and probably stands a larger chance of infection to go with it.
A "gun" could be constructed from tape, a tube (plastic or metal), a rubber band and a push pin, nail or some other hard piece of metal. It only has to work well enough to reliably fire a bullet in the general direction the weapon is pointed. The components could be smuggled through (or can be sourced beyond) virtually any security checkpoint in the world and assembled. Smuggling the bullet would be another matter but I assume that a small .22 calibre could be gotten in disguised as a pen or something.
I wonder how many of those infections occurred from apps in the Play store versus those acquired through other means, e.g. warez sites.