Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel.
Android is a Linux distribution just like any other Linux distribution which can include different userland, desktop environment and application toolkits (which can be - but are not limited to - Java), applications can - but do not have to - use these provided toolkits and may or may not directly interact with the kernel.
Java is not merely an application toolkit. For all practical purposes Java is its own operating system and environment. Its virtual machine (VM) can merely be hosted on Linux or various other platforms, Java apps don't know or care what is hosting the VM. Android is built upon Java and therefore shares this structure. Android apps run on the Dalvik VM, whether this VM is hosted by Linux or something else is irrelevant to Android.
Android also comes with a set of support libraries implemented in C and wrapped with the Java Native Interface (JNI) letting an Android app call these libraries. When you use the NDK to wrap your own C code, which may interact with the kernel, in a JNI compatible library you are creating an application specific extension to Android. Its just a library next to libc, OpenGL, SQlite, etc. This does not somehow turn Android into a Linux distribution.
Unlike desktop Linux UI's where the apps may interact with the kernel.
You just said If you think this is a UI argument you are mistaken and then compared applications running on Android to applications running on desktop Linux UI's. Are you quite sure you understand what you're trying to say? Because you are directly contradicting yourself, or perhaps just confusing terms.
Look at the post that I am responding to, that post made the claim that its just UI differences. I am responding to that claim.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Bollocks, if I write a desktop app in Java (Eclipse for example...) all I see is Java API, but that doesn't mean Eclipse is not running on Linux.
The Java app is not running on Linux, it is running on a Java virtual machine. That is one of the benefits of Java, it isolates you from the host operating system so that your app is portable. What that Java virtual machine is running on is irrelevant to your app. Would you claim that a Windows app is Linux based because MS Windows is running on a virtual machine hosted on a Linux box?
I'm sorry to say it that way but you are wrong. Google has documentation and sample on writing Android activities without any Java code involved. Take a look at samples/native-activity in the NDK.
Note how Google's sample native code begins with "#include "
You seem to be confusing you having to write additional Java or glue with there not being any. It is there, Google has merely provided it. The main process for your app is Java running in the Dalvik VM. Your native code is a C library effectively extending the Android run-time, it is running at the JNI stubbed library level of the Android Software Hierarchy.
Well, and how does it change the nature of Android that you can write apps entirely in C without a single line of Java anywhere? Google even ships demos that do just that.
Stock Android does not expose the kernel. The developer has to **customize** the Android run-time to get to the kernel. Google merely provides a mechanism for an app to do so, the Java Native Interface (JNI). The developer puts all the C/C++ code in a library with a JNI wrapper. Starting from a Google example that has all the necessary Java, JNI, makefiles, etc pre-made is not the same as having no Java anywhere. Having a C library that implements nearly all of your app does not change the Java nature of Android nor the fact that stock non-customized Android provides not access to the Linux kernel.
That said, even if your app is basically written in C/C++ you are probably accessing and making calls to Java via the JNI. Its the only way to access the Android API and its resources.
Very few apps use it? Everything that is ported from other platforms is using the NDK, Or do you think that apps like Firefox, Chrome or Opera have been rewritten in Java? And then there's all the cross-platform games.
Those are just high profile exceptions. The vast majority of apps on Google Play are pure java.
The fact that there is an infrequently used mechanism that allows one to add a custom C library to the java run-time environment does not change Android's java nature.
So? With gnome or qt stuff that developers almost never get near the kernel either.
I'm not commenting on gnome or qt, I'm commenting on Android. Android is a java based environment, java byte codes running on the Dalvik virtual machine. Its no more a Linux environment than Windows XP running in a virtual machine hosted on a Linux box.
You are wrong. Android has a C interface that is very POSIX conformant. It is there for applications to use. Google offers all the tools you need to make use of that.
That is the NDK and very few Android apps use it. It break portability across architectures. It is an optional add-on to the standard Android SDK. Google cautions developers not to use it unless absolutely necessary. The standard Android SDK is Java and does not expose posix nor the kernel.
"The Franklin stove is a metal-lined fireplace named after its inventor, Benjamin Franklin. It was invented in 1741. It had a hollow baffle near the rear (to transfer more heat from the fire to a room's air) and relied on an "inverted siphon" to draw the fire's hot fumes around the baffle. It was intended to produce more heat and less smoke than an ordinary open fireplace." http://en.wikipedia.org/wiki/Franklin_stove
You got that wrong. YOU can't change the fact that Android runs on a Linux kernel and that's pissing you off so hard that you wanna deny that Linux is there at all.
Sorry, but you guessed wrong. I also develop for Linux. I've been using Linux (not exclusively) since Yggdrasil Linux in the early 90s. I am not religious about my platforms. I've used Linux, MS Windows, or Mac OS for decades, whichever was best for the task at hand.
Android is a Java environment. Java apps don't see the kernel. That is quite different than apps/utils running on the desktop where the kernel is right there in the headers and fully available.
No one is denying that Linux is currently on the device, many layers distant from the app, below the virtual machine that the java byte code is running on. The argument is that Linux is irrelevant to the java app. That Android is no more of a Linux environment than MS Windows running in a virtual machine hosted on a Linux box.
Most of his argument is that the UI is different. It's like saying that if you don't have a Gnome/KDE/Unity UI, you're not running Linux.
If you think this is a UI argument you are mistaken. Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel. Unlike desktop Linux UI's where the apps may interact with the kernel.
Same is true for Debian: Linux kernel, FreeBSD kernel, same userland. Hence GNU/Linux GNU/hurd GNU/whatever...
The key distinction is that Android is a Java environment not a *nix environment. An app's byte codes see a virtual machine, the kernel is far below that, far more removed from an android app than a *nix app.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Android is very much Linux. It's just not GNU/Linux. All the GNU utilities that give Linux the functionality and feel of Unix have been stripped out and replaced by running Dalvik on top of the Kernal.
A Linux developer sees a C API that includes the Linux kernel. An Android developer sees a Java API that does not include the Linux kernel. Dalvik is somewhat like a virtual CPU that the Java byte code runs on. Linux is pretty far removed under Android, a hidden implementation detail.
So? Most of the time you could say the same thing about a Desktop Linux distro.
Note that I was referring to both the user and the **developer** perspective. Android is a Java based environment, not a Linux based environment, not even a posix based environment.
While on the topic about fragmentation... Android is another type of linux.
No, its not.
Yes it bloody well is.
Android is a Java based environment not a Linux based environment. Having a hidden Linux kernel several software layers down does not change this fact.
End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice.
That's true of desktop linux as well. If you used gnome on FreeBSD you would not notice.
You are mistaken. On the desktop Linux users are not restricted to the GUI, there is also the console. Linux and BSD are a bit different when you get to the console.
While on the topic about fragmentation... Android is another type of linux.
No, its not. End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific.
You don't need to adjust any dollars to make it cheaper - the Commodore 64 was listed as $595 at the time of arrival, and I don't think that it ever went below $200 in the stores, not even in the early nineties, ten years after its introduction.
I recall paying about $175 for a C-64 circa 1983/84. The price drops from that initial $5xx price tag was incredible. I expect that few C-64 owners bought their machines at the high end of the price range.
That's basically the socratic method (still beloved in law schools)... I wonder how this works for, say, history.
It works well in business school too, at least for micro and macro economics and some strategy classes.
As a computer science undergraduate who was also a history geek taking a history class every quarter for fun I would speculate that it would work well in history as well. The book and lectures can go into the facts and provide some background to the environment that events took place in. The lectures could focus on discussions as to why the various players made the decisions that they did, what influenced them,... Those were the sort of discussion I really loved.
Back in the early 1990s, I had a high school math teacher who would assign the homework *before* she taught the lesson. You were expected to read the chapter, try to do the homework, and then she'd answer any questions that you might have the next day in class. You then had another night to correct whatever you needed before the homework was due. (and then start your reading for the next day's class).
My second year calculus professor did something similar, except that the homework on a topic was collected before his lecture, no turn ins once the lecture begins. We had to read appropriate sections, figure it out on our own well enough to do the homework, do the homework and then in the professor's opinion we were "qualified" to hear his lecture. Needless to say when this was announced on day 1 half the class dropped. I stuck with it, my job made this my only open time slot.
As difficult as it was I have to admit that the professor's method worked. I took the rest of the series of classes with this professor. I learned more in 2nd year with him than in 1st year with more traditional professors.
Issue is, time is finite. You're effectively doubling the time spend per each course...
No. I've had two graduate level economics classes (micro and macro) that used this format. My classmates and I soon learned that watching at 1.5x speed works really well if you are getting the material, less likely to get bored and nod off. If not getting a particular difficult concept, rewind, slow down, repeat as necessary - which is also an improvement offered by video.
Also issue is the time needed to prepare, classes would need to be staggered to allow at minimum the three (or however long is needed) hours between them.
No, my classmates and I generally watched the videos the night before the class.
The point is that this isn't really a win. It's just enforcing the best practices.
No it can be a win if done right, see below. I had two graduate level economics classes (micro and macro) that followed this model. The stock lectures were videotaped and made available for download. We watched them outside of class at our convenience and usually at 1.5x speed. If you are understanding the material 1.0x and 1.5x are effectively equivalent, if not there is rewind. Sometimes a tricky concept took a couple of rewinds.This was a win but not the biggest win.
These videos were not simply a recording of a past class lecture. The professors did a lecture specifically for the video and made sure any charts, graphs and writing on the whiteboard was recognizable on video. The videos had companion slideshows with key points, charts, etc and plenty of whitespace to take notes on if you printed them out.
The biggest win was having 100% of class time for questions, discussion and debate. Not just with the professor but between students as well. The professor instigating, steering and refereeing the debate at times.
When my various classmates and I talked amongst ourselves we recognized that we had some additional work to do outside of class, mitigated by 1.5x speed, but that we got so much more out of lectures we thought the new class format was an big improvement. YMMV. If the videos were simply a recording of a previous live class lecture the new format probably would have sucked. A purpose made video with accompanying material probably makes it work.
Programming hasn't changed very much in 50 or so years.
So you're still feeding punched cards to your computer?
I still use punch cards... as book marks. In my intro to programming class (1980s) the professor had us do our first programming assignment on punch cards. He told us they were obsolete but having used them once we would better understand why some things are the way they are. He then mentioned we would have bookmarks for life so the deck of cards we had to buy wasn't completely useless.
As I typed the above I realized that I am old not only because I had used punch cards but because I was referring to reading paper books. The punch cards don't help so much when using my paperwhite.:-)
The whole point of these things appears to be to provide a modern day version of a Commodore-64, and get people interested in programming, and get them engaged, by having an environment where it's easy to do small hacks.
Get a $200 Chromebook, install a full Linux distro on it. In adjusted dollars that is cheaper than a C-64 alone, not including tape, disc or monitor.
Slashdot Mirror
Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel.
Android is a Linux distribution just like any other Linux distribution which can include different userland, desktop environment and application toolkits (which can be - but are not limited to - Java), applications can - but do not have to - use these provided toolkits and may or may not directly interact with the kernel.
Java is not merely an application toolkit. For all practical purposes Java is its own operating system and environment. Its virtual machine (VM) can merely be hosted on Linux or various other platforms, Java apps don't know or care what is hosting the VM. Android is built upon Java and therefore shares this structure. Android apps run on the Dalvik VM, whether this VM is hosted by Linux or something else is irrelevant to Android.
Android also comes with a set of support libraries implemented in C and wrapped with the Java Native Interface (JNI) letting an Android app call these libraries. When you use the NDK to wrap your own C code, which may interact with the kernel, in a JNI compatible library you are creating an application specific extension to Android. Its just a library next to libc, OpenGL, SQlite, etc. This does not somehow turn Android into a Linux distribution.
Unlike desktop Linux UI's where the apps may interact with the kernel.
You just said If you think this is a UI argument you are mistaken and then compared applications running on Android to applications running on desktop Linux UI's. Are you quite sure you understand what you're trying to say? Because you are directly contradicting yourself, or perhaps just confusing terms.
Look at the post that I am responding to, that post made the claim that its just UI differences. I am responding to that claim.
Linux is the kernel. Other stuff is other stuff.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Bollocks, if I write a desktop app in Java (Eclipse for example...) all I see is Java API, but that doesn't mean Eclipse is not running on Linux.
The Java app is not running on Linux, it is running on a Java virtual machine. That is one of the benefits of Java, it isolates you from the host operating system so that your app is portable. What that Java virtual machine is running on is irrelevant to your app. Would you claim that a Windows app is Linux based because MS Windows is running on a virtual machine hosted on a Linux box?
Oops, should have been: Note how Google's sample native code begins with "#include "
I'm sorry to say it that way but you are wrong. Google has documentation and sample on writing Android activities without any Java code involved. Take a look at samples/native-activity in the NDK.
Note how Google's sample native code begins with "#include "
You seem to be confusing you having to write additional Java or glue with there not being any. It is there, Google has merely provided it. The main process for your app is Java running in the Dalvik VM. Your native code is a C library effectively extending the Android run-time, it is running at the JNI stubbed library level of the Android Software Hierarchy.
Well, and how does it change the nature of Android that you can write apps entirely in C without a single line of Java anywhere? Google even ships demos that do just that.
Stock Android does not expose the kernel. The developer has to **customize** the Android run-time to get to the kernel. Google merely provides a mechanism for an app to do so, the Java Native Interface (JNI). The developer puts all the C/C++ code in a library with a JNI wrapper. Starting from a Google example that has all the necessary Java, JNI, makefiles, etc pre-made is not the same as having no Java anywhere. Having a C library that implements nearly all of your app does not change the Java nature of Android nor the fact that stock non-customized Android provides not access to the Linux kernel.
That said, even if your app is basically written in C/C++ you are probably accessing and making calls to Java via the JNI. Its the only way to access the Android API and its resources.
Very few apps use it? Everything that is ported from other platforms is using the NDK, Or do you think that apps like Firefox, Chrome or Opera have been rewritten in Java? And then there's all the cross-platform games.
Those are just high profile exceptions. The vast majority of apps on Google Play are pure java.
The fact that there is an infrequently used mechanism that allows one to add a custom C library to the java run-time environment does not change Android's java nature.
So? With gnome or qt stuff that developers almost never get near the kernel either.
I'm not commenting on gnome or qt, I'm commenting on Android. Android is a java based environment, java byte codes running on the Dalvik virtual machine. Its no more a Linux environment than Windows XP running in a virtual machine hosted on a Linux box.
You are wrong. Android has a C interface that is very POSIX conformant. It is there for applications to use. Google offers all the tools you need to make use of that.
That is the NDK and very few Android apps use it. It break portability across architectures. It is an optional add-on to the standard Android SDK. Google cautions developers not to use it unless absolutely necessary. The standard Android SDK is Java and does not expose posix nor the kernel.
Didnt Philips do this 5 to 10 years ago????/
Didn't Ben Franklin do this 250 years ago?
"The Franklin stove is a metal-lined fireplace named after its inventor, Benjamin Franklin. It was invented in 1741. It had a hollow baffle near the rear (to transfer more heat from the fire to a room's air) and relied on an "inverted siphon" to draw the fire's hot fumes around the baffle. It was intended to produce more heat and less smoke than an ordinary open fireplace."
http://en.wikipedia.org/wiki/Franklin_stove
You got that wrong. YOU can't change the fact that Android runs on a Linux kernel and that's pissing you off so hard that you wanna deny that Linux is there at all.
Sorry, but you guessed wrong. I also develop for Linux. I've been using Linux (not exclusively) since Yggdrasil Linux in the early 90s. I am not religious about my platforms. I've used Linux, MS Windows, or Mac OS for decades, whichever was best for the task at hand.
Android is a Java environment. Java apps don't see the kernel. That is quite different than apps/utils running on the desktop where the kernel is right there in the headers and fully available.
No one is denying that Linux is currently on the device, many layers distant from the app, below the virtual machine that the java byte code is running on. The argument is that Linux is irrelevant to the java app. That Android is no more of a Linux environment than MS Windows running in a virtual machine hosted on a Linux box.
Most of his argument is that the UI is different. It's like saying that if you don't have a Gnome/KDE/Unity UI, you're not running Linux.
If you think this is a UI argument you are mistaken. Android is a Java environment not a Linux environment. Nearly all apps are pure byte code executing on a VM, they never see the Linux kernel. Unlike desktop Linux UI's where the apps may interact with the kernel.
Same is true for Debian: Linux kernel, FreeBSD kernel, same userland. Hence GNU/Linux GNU/hurd GNU/whatever...
The key distinction is that Android is a Java environment not a *nix environment. An app's byte codes see a virtual machine, the kernel is far below that, far more removed from an android app than a *nix app.
Linux is the kernel. Other stuff is other stuff.
The point is that in desktop/server/embedded Linux environment the developers sees the kernel API. Under Android they do not. Android is a Java environment not a *nix environment.
Android is very much Linux. It's just not GNU/Linux. All the GNU utilities that give Linux the functionality and feel of Unix have been stripped out and replaced by running Dalvik on top of the Kernal.
A Linux developer sees a C API that includes the Linux kernel. An Android developer sees a Java API that does not include the Linux kernel. Dalvik is somewhat like a virtual CPU that the Java byte code runs on. Linux is pretty far removed under Android, a hidden implementation detail.
So? Most of the time you could say the same thing about a Desktop Linux distro.
Note that I was referring to both the user and the **developer** perspective. Android is a Java based environment, not a Linux based environment, not even a posix based environment.
While on the topic about fragmentation... Android is another type of linux.
No, its not.
Yes it bloody well is.
Android is a Java based environment not a Linux based environment. Having a hidden Linux kernel several software layers down does not change this fact.
End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice.
That's true of desktop linux as well. If you used gnome on FreeBSD you would not notice.
You are mistaken. On the desktop Linux users are not restricted to the GUI, there is also the console. Linux and BSD are a bit different when you get to the console.
Budweiser makes the best beer ...
Which Budweiser, made in the USA or Czech Republic? :-)
While on the topic about fragmentation... Android is another type of linux.
No, its not. End users and nearly all **developers** don't see it. The Linux kernel could probably be swapped out with a BSD kernel and few would notice. Even for those using the NDK and writing some C code they are probably making POSIX calls not calls to anything Linux specific.
You don't need to adjust any dollars to make it cheaper - the Commodore 64 was listed as $595 at the time of arrival, and I don't think that it ever went below $200 in the stores, not even in the early nineties, ten years after its introduction.
I recall paying about $175 for a C-64 circa 1983/84. The price drops from that initial $5xx price tag was incredible. I expect that few C-64 owners bought their machines at the high end of the price range.
That's basically the socratic method (still beloved in law schools) ... I wonder how this works for, say, history.
It works well in business school too, at least for micro and macro economics and some strategy classes.
... Those were the sort of discussion I really loved.
As a computer science undergraduate who was also a history geek taking a history class every quarter for fun I would speculate that it would work well in history as well. The book and lectures can go into the facts and provide some background to the environment that events took place in. The lectures could focus on discussions as to why the various players made the decisions that they did, what influenced them,
Back in the early 1990s, I had a high school math teacher who would assign the homework *before* she taught the lesson. You were expected to read the chapter, try to do the homework, and then she'd answer any questions that you might have the next day in class. You then had another night to correct whatever you needed before the homework was due. (and then start your reading for the next day's class).
My second year calculus professor did something similar, except that the homework on a topic was collected before his lecture, no turn ins once the lecture begins. We had to read appropriate sections, figure it out on our own well enough to do the homework, do the homework and then in the professor's opinion we were "qualified" to hear his lecture. Needless to say when this was announced on day 1 half the class dropped. I stuck with it, my job made this my only open time slot.
As difficult as it was I have to admit that the professor's method worked. I took the rest of the series of classes with this professor. I learned more in 2nd year with him than in 1st year with more traditional professors.
Issue is, time is finite. You're effectively doubling the time spend per each course ...
No. I've had two graduate level economics classes (micro and macro) that used this format. My classmates and I soon learned that watching at 1.5x speed works really well if you are getting the material, less likely to get bored and nod off. If not getting a particular difficult concept, rewind, slow down, repeat as necessary - which is also an improvement offered by video.
Also issue is the time needed to prepare, classes would need to be staggered to allow at minimum the three (or however long is needed) hours between them.
No, my classmates and I generally watched the videos the night before the class.
The point is that this isn't really a win. It's just enforcing the best practices.
No it can be a win if done right, see below. I had two graduate level economics classes (micro and macro) that followed this model. The stock lectures were videotaped and made available for download. We watched them outside of class at our convenience and usually at 1.5x speed. If you are understanding the material 1.0x and 1.5x are effectively equivalent, if not there is rewind. Sometimes a tricky concept took a couple of rewinds.This was a win but not the biggest win.
These videos were not simply a recording of a past class lecture. The professors did a lecture specifically for the video and made sure any charts, graphs and writing on the whiteboard was recognizable on video. The videos had companion slideshows with key points, charts, etc and plenty of whitespace to take notes on if you printed them out.
The biggest win was having 100% of class time for questions, discussion and debate. Not just with the professor but between students as well. The professor instigating, steering and refereeing the debate at times.
When my various classmates and I talked amongst ourselves we recognized that we had some additional work to do outside of class, mitigated by 1.5x speed, but that we got so much more out of lectures we thought the new class format was an big improvement. YMMV. If the videos were simply a recording of a previous live class lecture the new format probably would have sucked. A purpose made video with accompanying material probably makes it work.
So you're still feeding punched cards to your computer?
I still use punch cards ... as book marks. In my intro to programming class (1980s) the professor had us do our first programming assignment on punch cards. He told us they were obsolete but having used them once we would better understand why some things are the way they are. He then mentioned we would have bookmarks for life so the deck of cards we had to buy wasn't completely useless.
:-)
As I typed the above I realized that I am old not only because I had used punch cards but because I was referring to reading paper books. The punch cards don't help so much when using my paperwhite.
The whole point of these things appears to be to provide a modern day version of a Commodore-64, and get people interested in programming, and get them engaged, by having an environment where it's easy to do small hacks.
Get a $200 Chromebook, install a full Linux distro on it. In adjusted dollars that is cheaper than a C-64 alone, not including tape, disc or monitor.