- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Is Windows 10's Privacy Issue Reason Enough to Move to Linux?
|
|
|
Comments (32)
12 earlier comments in the full thread.
I like to differentiate operating systems by naming both their user space and their kernels, so we have:
Gnu/Linux
Android/Linux
Chrome/Linux
and then we also have:
Windows/WinNT
iOS/freeBSD
What have I missed?
Gnu/Linux
Android/Linux
Chrome/Linux
and then we also have:
Windows/WinNT
iOS/freeBSD
What have I missed?
> Well, the users who complained in Munich wanted to be able to install software, which is what they were apparently used to with their old Windows laptops
Of course the software they want to install probably isn't available for Linux in any case.
Of course the software they want to install probably isn't available for Linux in any case.
> Like it or not, notbob, Android IS Linux.
But for most users, that's only true in roughly the same way as it would be for a Windows VM on a Linux host.
I have an Android tablet, myself, and I do like it much better than a Windows or iOS device -- but it often feels not much more free and open and flexible than the iOS or Windows devices. There's a lot of unnecessary hassle -- it's not nearly as bad as those others, but I still find myself having to fight or evade the OS for control over my experience and my data. And after all... isn't that the larger part of why FDroid, CyanogenMod and similar projects even exist?
But for most users, that's only true in roughly the same way as it would be for a Windows VM on a Linux host.
I have an Android tablet, myself, and I do like it much better than a Windows or iOS device -- but it often feels not much more free and open and flexible than the iOS or Windows devices. There's a lot of unnecessary hassle -- it's not nearly as bad as those others, but I still find myself having to fight or evade the OS for control over my experience and my data. And after all... isn't that the larger part of why FDroid, CyanogenMod and similar projects even exist?
> Well, the users who complained in Munich wanted to be able to install software, which is what they were apparently used to with their old Windows laptops.
I get the impression that it's actually about fostering a political issue to stir up public opinion against the majority party, than about any supposed problems with the technology.
I get the impression that it's actually about fostering a political issue to stir up public opinion against the majority party, than about any supposed problems with the technology.
I'm happy to stand corrected on my understandings of Limux and certainly I now have two good alternative opinions. Thankyou both BernardSwiss and CFWhitman. Something similar is here in so far as all Federal and State software has been developed so that it ONLY runs on Windows.....Vendor lock-in with a vengeance. I'd also tend to agree very firmly with your last statement directly above BernardSwiss.....I haven't run across that aspect myself, but it is just the sort of puerile behaviour politicians get up to based on what I see here in Australia.
I'd also be happy to agree with you on Android BernardSwiss, and that's without ever touching the OS. The article I quoted above in Wikipedia says two things: sure, it's Linux at the kernel level, but it's Google developed and developed especially for mobiles - and while I am happy to use the Chrome browser, I'd be a little cautious over just what restrictions Google has placed in the Android overlay. Whatever, Android by all accounts does not resemble what I see each time I use my laptop and reach KDE....but what the heck......Android's still Linux at its core, not Windows.....and that thought remains very satisfying every time I see a smartphone in use. Our Telstra shops often don't stock Winphones, there is so little call for them - or that was certainly frequently the situation earlier this year. I suspect Penguinist has nailed the best way of dealing with all these different OS's and their kernels.
I'd also be happy to agree with you on Android BernardSwiss, and that's without ever touching the OS. The article I quoted above in Wikipedia says two things: sure, it's Linux at the kernel level, but it's Google developed and developed especially for mobiles - and while I am happy to use the Chrome browser, I'd be a little cautious over just what restrictions Google has placed in the Android overlay. Whatever, Android by all accounts does not resemble what I see each time I use my laptop and reach KDE....but what the heck......Android's still Linux at its core, not Windows.....and that thought remains very satisfying every time I see a smartphone in use. Our Telstra shops often don't stock Winphones, there is so little call for them - or that was certainly frequently the situation earlier this year. I suspect Penguinist has nailed the best way of dealing with all these different OS's and their kernels.
Linux is user-friendly. It's just choosy about its friends.
Unlike the social disease that is Windows.
Unlike the social disease that is Windows.
gus3 .......that's a CLASSIC......can I have permission to use it ? If I can type it without laughing ?
The first part is quoted by ESR in "The Art of Unix Programming." The second part just... well... made sense as a follow-on.
You may repeat it to your heart's content.
You may repeat it to your heart's content.
Often when people say "Linux" they are talking about the operating system that some have suggested be called GNU/Linux. In that sense, Android is not Linux. Android is another Linux based operating system, but what really makes it different than GNU/Linux is that it uses an incompatible C library. That is, you can either run a GNU system on top of a Linux kernel or an Android system, but you can't run both in the same root directory. You need to have separate root directories to run both. Basically, everything above the kernel is different and incompatible.
> That is, you can either run a GNU system on top of a Linux kernel or an Android system, but you can't run both in the same root directory.
So you could, in theory, chroot an Android system within a working Linux system. That would be an interesting exercise. Way too much work though.
So you could, in theory, chroot an Android system within a working Linux system. That would be an interesting exercise. Way too much work though.
>Way too much work though.
Not really. Try 'Linux Deploy' from Play Store, together with a VNC Android app. I use this combo at work, just awesome. Started that after a hint from CFWhitman some 2 or 3 years ago, many thanks.
Not really. Try 'Linux Deploy' from Play Store, together with a VNC Android app. I use this combo at work, just awesome. Started that after a hint from CFWhitman some 2 or 3 years ago, many thanks.
Okay, I'll bite.
Android executables are just like Java bytecode executables are just like Perl executables are just like Python executables are just like LLVM executables are just like Scheme executables are just like ELF executables. The system knows which loader/linker/interpreter to invoke from the image itself (99 times out of 100, anyway).
Why couldn't the Dalvik interpreter sit side-by-side with /lib/ld-linux.so, and be invoked by the system automatically when an Android executable is invoked?
Android executables are just like Java bytecode executables are just like Perl executables are just like Python executables are just like LLVM executables are just like Scheme executables are just like ELF executables. The system knows which loader/linker/interpreter to invoke from the image itself (99 times out of 100, anyway).
Why couldn't the Dalvik interpreter sit side-by-side with /lib/ld-linux.so, and be invoked by the system automatically when an Android executable is invoked?
gus3: you make good points with your suggestion. I think maybe the difficult part would be to get the non-android half of that combination to recognize and use the android windowing environment.
Having said that, perhaps what you propose is realizable. There are basically two parts to the problem,
invokation: and as you point out that should be a matter of running the elf executable
user interaction: and that part seems a bit more of a challenge. Maybe someone else has a clear idea on that part.
Having said that, perhaps what you propose is realizable. There are basically two parts to the problem,
invokation: and as you point out that should be a matter of running the elf executable
user interaction: and that part seems a bit more of a challenge. Maybe someone else has a clear idea on that part.
gus3
In theory, there is no reason you couldn't have a Dalvik or Art virtual machine run on top of a conventional Linux system. However, you would have to port Dalvik or Art to GNU/Linux to do this (in theory, you could port Dalvik or Art to Windows or another operating system as well).
Perl and Python interpreters have been ported to Linux and several different other operating systems (these languages in practice function more like Java than pure scripting languages). Similarly, the Java VM has been ported to many operating systems. LLVM is a compiler, and executables from it are operating system specific, though of course it exists for Linux and can compile programs for Linux. Scheme is an interpreted language, and has a Linux interpreter. ELF is a binary file format, which is a bit different. It's more about knowing how to read the files than knowing how to run them.
So Perl, Python, Java, and Scheme all have some sort of interpreter that has been compiled for the GNU/Linux C library, and LLVM compiled executables have been compiled for the GNU/Linux C library. The normal Dalvik or Art interpreter has been compiled for the Android C library.
Basically, if the kernel is the operating system engine, the C library is the transmission, and you can't have two transmissions hooked up at the same time (in the same root directory). So you would need Dalvik or Art compiled to run with the GNU/Linux C library to run it in the same root directory as GNU/Linux.
In practice, some apps have parts that run at lower levels than the VM for performance reasons. Of course, Android exists for x86 and MIPS, so apps like those won't run on those systems without some emulation going on (which Android x86 definitely does).
In fact, there is a proprietary port of Dalvik to GNU/Linux which is used by Jolla. Now if there would only be an open source one, we could run Android apps in our Linux systems.
As penguinist refers to, there might be some logistical issues, but I think they would be minor. The big issue is having the virtual machine ported.
In theory, there is no reason you couldn't have a Dalvik or Art virtual machine run on top of a conventional Linux system. However, you would have to port Dalvik or Art to GNU/Linux to do this (in theory, you could port Dalvik or Art to Windows or another operating system as well).
Perl and Python interpreters have been ported to Linux and several different other operating systems (these languages in practice function more like Java than pure scripting languages). Similarly, the Java VM has been ported to many operating systems. LLVM is a compiler, and executables from it are operating system specific, though of course it exists for Linux and can compile programs for Linux. Scheme is an interpreted language, and has a Linux interpreter. ELF is a binary file format, which is a bit different. It's more about knowing how to read the files than knowing how to run them.
So Perl, Python, Java, and Scheme all have some sort of interpreter that has been compiled for the GNU/Linux C library, and LLVM compiled executables have been compiled for the GNU/Linux C library. The normal Dalvik or Art interpreter has been compiled for the Android C library.
Basically, if the kernel is the operating system engine, the C library is the transmission, and you can't have two transmissions hooked up at the same time (in the same root directory). So you would need Dalvik or Art compiled to run with the GNU/Linux C library to run it in the same root directory as GNU/Linux.
In practice, some apps have parts that run at lower levels than the VM for performance reasons. Of course, Android exists for x86 and MIPS, so apps like those won't run on those systems without some emulation going on (which Android x86 definitely does).
In fact, there is a proprietary port of Dalvik to GNU/Linux which is used by Jolla. Now if there would only be an open source one, we could run Android apps in our Linux systems.
As penguinist refers to, there might be some logistical issues, but I think they would be minor. The big issue is having the virtual machine ported.
Quoting: As penguinist refers to, there might be some logistical issues, but I think they would be minor. The big issue is having the virtual machine ported.
It's a little more complicated than that, I'm afraid... The Davlik VM makes certain assumptions about the underlying Linux architecture. The Android API is written against that kernel (and is changing all the time). This is part of the reason that the Google ARC Welder app for Chome browsers can't run all Android apps.
You're talking about issues such as I was referring to in this paragraph:
"In practice, some apps have parts that run at lower levels than the VM for performance reasons. Of course, Android exists for x86 and MIPS, so apps like those won't run on those systems without some emulation going on (which Android x86 definitely does)."
When I said what you quoted I was talking about issues like whether apps would run inside windows or full screen, how the mouse would work, etc.
"In practice, some apps have parts that run at lower levels than the VM for performance reasons. Of course, Android exists for x86 and MIPS, so apps like those won't run on those systems without some emulation going on (which Android x86 definitely does)."
When I said what you quoted I was talking about issues like whether apps would run inside windows or full screen, how the mouse would work, etc.
@ CFWhitman:
Until you have coded for Android (as I have), you really don't grasp the difference that Android has from a standard Linux environment. Android is to Linux as iOS is to BSD. They have abstracted so much of what the OS does that it really is a different system. It's more pronounced than the differences between GTK and QT. In a modern GNU/Linux, you can run GTK and QT stuff side-by-side. That wasn't the case 15 years ago, when I started using Linux. Back then, if you wanted to run a GTK app versus a QT app, you had to switch from Gnome to KDE (log out and log back in, in the other environment). Android is much like that. They abstract so much of what the OS does (like talk to hardware), that it would take an effort similar to what RedHat did to integrate the environments.
I'm not saying that you're wrong. What I'm saying is that it would be a monumental effort to do it. It IS worth doing, by the way,... Just as it is worth bringing Chrome/Chromium into the fold the same way. I would be particularly interested in adapting Chrome's graphical system, so that you could run a Chrome/Android/GTK/QT compatible environment. That way, a GNU/Linux system would be virtually unlimited in what it could run,... Android Apps, Chrome Apps, GTK (Gnome, XFCE, Etc.) Apps, QT (KDE, et al.) Apps, Windows Apps (via Wine), Containers, VMs,... The barriers would come down in much the way that was intended with Java, originally...
Until you have coded for Android (as I have), you really don't grasp the difference that Android has from a standard Linux environment. Android is to Linux as iOS is to BSD. They have abstracted so much of what the OS does that it really is a different system. It's more pronounced than the differences between GTK and QT. In a modern GNU/Linux, you can run GTK and QT stuff side-by-side. That wasn't the case 15 years ago, when I started using Linux. Back then, if you wanted to run a GTK app versus a QT app, you had to switch from Gnome to KDE (log out and log back in, in the other environment). Android is much like that. They abstract so much of what the OS does (like talk to hardware), that it would take an effort similar to what RedHat did to integrate the environments.
I'm not saying that you're wrong. What I'm saying is that it would be a monumental effort to do it. It IS worth doing, by the way,... Just as it is worth bringing Chrome/Chromium into the fold the same way. I would be particularly interested in adapting Chrome's graphical system, so that you could run a Chrome/Android/GTK/QT compatible environment. That way, a GNU/Linux system would be virtually unlimited in what it could run,... Android Apps, Chrome Apps, GTK (Gnome, XFCE, Etc.) Apps, QT (KDE, et al.) Apps, Windows Apps (via Wine), Containers, VMs,... The barriers would come down in much the way that was intended with Java, originally...
: Shashlik - Android Applications on Real Linux, there is a video there.
This might be of interest
Original Request
News about it
Discussions 1
Discussions 2
This might be of interest
Original Request
News about it
Discussions 1
Discussions 2
Replying to Ridcully's
I'm always amazed
Quote _ Oh yes......obliquely he refers to Munich. From what I have seen, the problems are not that Linux is hard to use, but rather there is a core of dedicated Windows users that are refusing to work with any other OS or even trying to learn how to use it......One is almost tempted to ask whether or not they ever purchase a new car and have to learn new locations for some of the controls ? Same difference to me.
The latest news is >>>> Munich now a major contributor to open source The city of Munich is a major contributor to free and open source projects, sending bugfixes to upstream developers, making available software solutions and sharing best practices and technical information. In August, Munich IT staff members shared the city’s accomplishments with the community of Debian developers, one of the main free software distributions. Source from https://joinup.ec.europa.eu/node/145626
The latest news is >>>> Munich now a major contributor to open source The city of Munich is a major contributor to free and open source projects, sending bugfixes to upstream developers, making available software solutions and sharing best practices and technical information. In August, Munich IT staff members shared the city’s accomplishments with the community of Debian developers, one of the main free software distributions. Source from https://joinup.ec.europa.eu/node/145626
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
https://en.wikipedia.org/wiki/Android_(operating_system)
I will accept that Android is meant for mobiles, but seem to recall from my recent reading that there are Android PCs around now as well. And if the kernel is Linux, then Android IS Linux. I don't use a smartphone, so I haven't been exposed to Android in any way. But I remain unshakeable in the belief that if you use Android, you are using a Linux OS. It may not be the same interface as found in a PC running Redhat, Fedora, openSUSE, Ubuntu, etc. etc., but it is very firmly a Linus OS !