Another (not too obvious) FOSS freedom coming true
|
| Author | Content |
|---|---|
| theBeez Nov 16, 2011 4:55 AM EDT |
Having worked with Linux on several different processors, it is obvious that FOSS due to its very nature offers more than one freedom for the user. If I want to switch to another processor all I have to do is to compile the applications I want for this platform. True, there are a few that may be tied to a specific processor, but again, there are only few. Most of the time, such a distribution will have a repository of packages, so I can click my way around and have my working environment copied on a new processor - which is not too different from a reinstall on the same platform. But for those applications that are not in that repository, a recompile is all that is needed. Another freedom is formed by development platforms like Python. No matter how much I dislike the language itself, the freedom of having a load of useful functionality once the language itself is available is wonderful. The only drawback is that those platforms seem to be unable to "stabilize", so that the version of the language itself becomes an issue. On the other hand, maintaining a compiler myself, I can understand you have to move on in order to offer new functionality and "fix" errors one made before. All in all, I don't think the scenario of having ARM desktops and servers is unthinkable, the more since Windows8 can have a significant effect on the PC platform and the usability of that platform for Linux. |
| tmx Nov 20, 2011 6:47 PM EDT |
Because of ARM, in a couple years people are going to replace their laptop desktop with a dockable phone. Next year already we'll see nVidia Tegra 3 with 1.4ghz quadcore and Qualcomm S4 with 2.5Ghz quadcore that HTC wants to put on their phone. But consumer is still losing because moving to these device there are even less standards and user inputs/modification, more hardware DRM. |
| Grishnakh Nov 20, 2011 7:50 PM EDT |
@theBeez: there are precisely zero applications which are tied to a specific processor (open-source ones, anyway), unless they're very poorly written so that they're not 64-bit compatible. There's no reason at all you shouldn't be able to recompile any application to work on any CPU. The only exception to this might be low-level utility or diagnostic software, but for any normal application, there's absolutely no reason it shouldn't compile on any CPU. |
| dinotrac Nov 21, 2011 2:15 PM EDT |
@Grishnakh -- Are you sure about that? It may no longer be the case, but I'm pretty sure that, over the years, I've seen applications that included bits of assembly language in some bits, and those are likely architecture dependent. |
| gus3 Nov 21, 2011 2:41 PM EDT |
@dino, do you remember what those programs were? I'm skeptical that anything above a low-level library (on the same level as glibc) in a desktop application needs to be coded in assembly language. Real-time can be a different story, but the only RT app in an Android environment would be the one that makes phone calls. (Disclaimer: I'm blowing smoke. Anyone and everyone can feel free to call out my ignorance.) |
| skelband Nov 21, 2011 2:57 PM EDT |
It is possible that some games may use assembler, but to be honest, I would be very wary of any application level code that contains assembler these days. The two examples that I have seen in recent times were 1) CPU detection (of which there are much more reliable and portable methods of doing this) and 2) Implementation of a compare and swap function in a portability library. |
| gus3 Nov 21, 2011 3:10 PM EDT |
Ah yes, games. Not being a gamer of any consequence, that possibility never occurred to me. I would question games being desktop programs, but the point is taken. |
| Grishnakh Nov 21, 2011 6:00 PM EDT |
I'm with skelband and gus3; there really shouldn't be any applications using assembly any more. It's even questionable with games; these days, most games are GPU-bound, not CPU-bound, as all the heavy lifting occurs in the GPU now. Just look at the Linux kernel; it's all in C, except for a few bits of assembly needed for very low-level machine-specific routines like handling interrupts. Those kinds of things aren't going to be done by applications. |
| JaseP Nov 21, 2011 10:17 PM EDT |
I do not believe that Intel will allow the X86 platform to fall into complete M$ dominance, they have a love/hate relationship. Intel & M$ are in a perpetual chess match, with one vying to break their reliance on the other. Then, there is a reconciliation of sorts, where they find themselves in common agreement on something... Then, there is an event that disrupts their love-fest... We need to count on that,... And continue to support Linux ad multi-platform... |
| krisum Nov 21, 2011 11:35 PM EDT |
Media players like vlc, mplayer too have processor specific optimizations so those won't work for a new processor. |
| JaseP Nov 22, 2011 11:58 AM EDT |
I have VLC working on Android, as an alpha. It's fine... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!