How does text and calls work on a smartphone running linux?
Linux - MobileThis forum is for the discussion of all topics relating to Mobile Linux. This includes Android, Tizen, Sailfish OS, Replicant, Ubuntu Touch, webOS, and other similar projects and products.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How does text and calls work on a smartphone running linux?
I am new here and just started researching linux, and am wanting to root and install linux distribution onto my Samsung galaxy S5, in place of the bloated Android OS. Upon installing a Linux distribution, how are text and calls conducted? I know Ubuntu touch integrates this, but that particular OS is not for my phone. Is there something I am overlooking here? I do not want a custom android ROM, I want a Linux OS. Could my smartphone run a Linux OS and be able to successfully conduct calls and text? I have not been able to find much information about this topic. I appreciate any advice the forum has.
it is possible to install linuxes on devices with arm architecture; e.g. debian supports that.
that alone (installing it) will be a pretty effing hard task, but it still doesn't give you a usable phone.
next step: install a gui, touchscreen support...
i don't know what the status for app development is, but even supposing all the required apps (dialer, messaging, soft keyboard...) are available, it would be another major pita to install & set them up.
i guess in the end you would have some sort of half zombie device that is able to do calls about 50& of the time...
if there was some linux phone distro readily available, we would surely have heard about it. in other words, there isn't. except ubuntu phone. sorry.
Android is Linux. It uses a Linux kernel, with userspace optimized for a touchscreen. People have tried to install standard Linux on Android phones, but I'm not aware of any successes. The OS has to have complete touchscreen support, and standard Linux distros don't have that. Nor do they have the phone and SMS apps. It takes a lot of customization of Linux to run on the custom hardware. Android isn't all that bloated, but admittedly Samsung plus the carriers add a lot of crap. You can get by that by using something like CyanogenMod, which replaces all that with a barebone Android ROM, or as much extra as you want. CyanogenMod is easy to flash, standard Linux distros are not.
You can check with the Ubuntu distributions... I believe they have one that augments the Android on a phone (or at least some phones). It uses the Android kernel (thus all the drivers work), and the Android runtime is still present (thus still works as a phone), but it also has a the Ubuntu user space distribution available (as long as there is enough storage...)
i cant really understand why no one wants to make a linux phone
minimal interface, low overhead, being written in c hardware requirements will go down drastically
the ability to automate everything, standards compliant will allow infinite modding/flashing without breaking
open source drivers could allow lower performance but wider hardware support, one iso for many phones
tried and tested sane architecture, security would probably be better
add an e-ink display and you get a real gadget
i cant really understand why no one wants to make a linux phone
minimal interface, low overhead, being written in c hardware requirements will go down drastically
the ability to automate everything, standards compliant will allow infinite modding/flashing without breaking
open source drivers could allow lower performance but wider hardware support, one iso for many phones
tried and tested sane architecture, security would probably be better
add an e-ink display and you get a real gadget
They did. That is why there are so many Android phones...
Linux and C have little to do with each other. Applications on Linux are written in C, perl, ruby, python, and any other programming language. Just because that's what you think about, doesn't mean that's all there is. Android is the standard for phones, like it or not, and manufacturers make what sells. Linux phones don't sell, at least so far. I just read that Canonical still hasn't given up on the Ubuntu phone, so maybe you can buy one of those in a year or so. I don't expect them to take over the market, though.
Linux and C have little to do with each other. Applications on Linux are written in C, perl, ruby, python, and any other programming language. Just because that's what you think about, doesn't mean that's all there is. Android is the standard for phones, like it or not, and manufacturers make what sells. Linux phones don't sell, at least so far. I just read that Canonical still hasn't given up on the Ubuntu phone, so maybe you can buy one of those in a year or so. I don't expect them to take over the market, though.
You did know that most/many of those other languages are written in C. As is the runtime for Android...
c is the most efficient language in terms of resources
As you say "just because you think so, doesent really make it true " C is a compiled language so there will still be overheads in the resulting code. I'd argue that Assembly would be more resource efficient.
I am new here and just started researching linux, and am wanting to root and install linux distribution onto my Samsung galaxy S5, in place of the bloated Android OS.
Unlike PCs, the hardware of smartphones is now highly integrated with the relevant OS, Android, Blackberry, iOS, etc.
If you want something that's "minimalist" where you can write or extend the capabilities take a look at http://maemo.org/ and if you want to give Maemo a go I'll sell you my old Nokia N 900!
As you say "just because you think so, doesent really make it true " C is a compiled language so there will still be overheads in the resulting code. I'd argue that Assembly would be more resource efficient.
Not really. The difference is the quality of code generation. Compilers don't get tired, so the code generated is always of the same quality (depending on the programmer for the choice of optimization level). Some programmers may start out higher... but after an hour, they get mediocre - and the compiler can/will beat them. In nearly all cases, the compiler will beat them (try matching the inline function capability, and no - a macro will NOT be better, the code elimination by the compiler wins).
There are areas where assembly is better - handling architecture specific instructions/interfaces is the one I can think of. But these don't occur very often...
Depends on what your definition is of resource efficiency, if you're talking about people resources then I totally agree with you. I took "resource efficiency" in this case to mean the on-machine resources, in which case I stand by my claim that lower level programming can use less memory/space/instructions to achieve the same aim.
I guess my main point is that "C" isn't necessarily "The End Boss"
Assembly can THEORETICALLY be better- but hand written assembly never is in practice.
The problem is that the processors have gotten too complex, with too many instructions, and too many variations.
What works great on one CPU model... won't work well on the others, due to various other parts of the CPU being different.
I have seen systems where the last instruction on a code page HAD to be a NOOP instead of a branch instruction (otherwise it gave a segmentation fault) where on another version of the same CPU it worked fine. What was different? The lookahead branch code went farther... and invalidated the reference on the next page - thus the segfault.
Compilers for the different CPUs could recognize that - and add (or not add) the correct number of NOOPs. The programmer couldn't know ahead of time... thus added overhead.
The added complexities make it much much easier for errors to be added to assembler.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.