I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
"Stealing contacts" is not that hard to do, since your app can read the contacts (you don't need any hacking to do that).
But reading + sending them to your server will make the marketplace instantly reject the app. So i doubt there's a problem.
I also don't see how you can infect a windows phone, given that .Net and Secure Boot make it almost invulnerable to everything.
rob243 said:
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
Click to expand...
Click to collapse
Unless you unlock the device and install that software by yourself, i don't believe it ever gonna pass marketplace check before it get online.
Well I am interested to see how its done, apparently the guy will present the proof of concept on the 24th
There are ways to get past checks run in the Marketplace ingestion. This has been previously demonstrated with PoC malware on iOS, which has similar protections. Don't assume it's impossible, especially if native code use is permitted.
Please note that there is a difference between native and unmanaged code, don't mix them up.
Native code has always run on Windows Phone. Both C++ and C# produce native code. The first is un-managed, whereas the second is managed.
Visual C++, the one we use in Windows Phone is, just like C#, a managed native language. It achieves almost the same performance as the standard C++,due to the more optimized compiler. It is possible to run standard C++ on Windows Phone, but it is very difficult to do so because the marketplace knows which compiler you used to make your app (if visual studio is not there, no no). The marketplace also knows which API you use (no Windows Phone API for C++, again a big NO for the submission).
Now, the difference between native and non-native code...
Native code always ends up as 1 and 0. The very code you write in C# will, at some point, end up as 1s and 0s. Same goes for C++(managed or not). The difference between C# and C++ is that the compiler inserts some failsafes into the code (lots of ifs) to check for exceptions. This does not happen in C++.
So the path for C# is like this:
C# code -> MSIL->Native code which is run on your devices (compilation is either done at install time, or in the clouds).
the C++ code we use in Windows Phone has basically the same path! However, the more mature compiler and the "no-failsafe policy unless instructed to" that all C++ variations enforce make the code faster while less safer.
A non-native language will never, ever get the code a developer writes compiled to 1s and 0s.
Such an example are web programming languages, and Java.
For Java, the process is like this
Java code -> various stages of compilation>byte code -> JVM interprets bytecode and then sends 1s and 0s to the CPU to execute-> CPU sends 1s and 0s results back to JVM which displays the results.
As such, Java is somewhat safer than C#, but also a lot slower.
The advantage of using an interpreted language is that you know the hardware capabilities of the device beforehand, and optimizations can be made on the spot.
Microsoft, however, took the middle road with C#. They gave it all the advantages of an intepreted language (due to the MSIL step, the .Net always knows how hardware it runs on, so the MSIL will always target all the hardware capabilities for your CPU, GPU and RAM), while also running on native code, which makes it very fast. They also decided to push in the same failsafe checks Java inserts in its code. This resulted in a slightly slower code when compared to C++.
As a developer, I think the reason for dropping XNA development by Microsoft wasn't its speed. C# could easily run games, and the thousand XNA games we have on the marketplace bear testimony to that. They brought C++ on board because porting apps from one platform to another would be easier this way, especially for apps coming from android or iOS).
Anyway, having said that, the C++ we use on phones does not have the capabilities to access the hardware or the system the same way it has on desktop. It doesn't have more power than C# already did. It is just used there for other reasons. I don't think it will pose any threat to security. Desktop evolved in a different way. Microsoft learned the lesson of system protection a long time ago. They won't repeat the same mistakes now. It wouldn't surprise me if they actually had some sort of AV software built in, just to be sure.
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
GoodDayToDie said:
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
Click to expand...
Click to collapse
Well, I was just trying to get a "basic picture" of the thing, but thanks for going into much more details.
As I said, the C++ we use in Windows Phone, just like C# on Windows Phone, functions in a different way compared to Desktop or Tablet version(hell, with C# on desktop you can easily do the memory scan thing and find stuff in the OS, not only in your app, but that is generally not needed, since C# on desktop has a much boarder and less limited API) . Unlike the former two, you can't interact outside your application, because your application is sandboxed. Even if you did find the pointer to a system protected function, you wouldn't be able to do squat with it(the system protects itself). Which is why I said C++ can't do things C# already couldn't. In theory, yes you can do what you said, in fact, i expect it to be possible on rooted rooms, but for the average joe...well...it very unlikely to happen, unless he does something stupid.
As for the JIT story, well, yes, Java does use JIT. However, it does so because it doesn't know before hand on what hardware it will run. The same happens with C# and .Net on desktop, and this is due to hardware variations. Right now, for windows phone, the "JIT" occurs directly in the clouds, or at install time, as all Windows Phones (8) use snapdragon chips.
I didn't say there were no differences between the code C# and C++ create at run time. The abstraction layers inserted by the compiler fall under the "failsafes inserted in code that slow things down", which C++ doesn't have. Also the more mature compiler (C++has like 40 years of xp, C# barely made 10, and only 3 on Windows Phone), the "true native" (happy now?) code it generates (which is very close to assembler language) makes C++ faster than C#, but not fast enough nor safe enough to phase out C# entirely.
In fact, if we still have this board 10 years from now, we might C# eventually take down C++.
We should avoid getting into a technical talk in this thread. As you can see, there are non-developers coming by, and an answer such as yours will completely and utterly confuse them. What I attempted to provide was a very basic image they could understand, like JVM sending 1s and 0s to CPU is the same as JIT.
Let's wait and see what we will be presented with. Currently the only thing a WP8 Managed App can't do that was mentioned was reading the SMS-Storage. Everything else is part of the official APIs. It might be that similarily to several WP7 hacks OEM drivers are being used to gain access.
The only thing that would really worry me was if he was able to provide a way to install his Malware bypassing the Marketplace. It might be interesting though for the Jailbreak community, given that any jailbreak bascially means exploiting a security vulnerability to elevate the rights of the current process to allow for those unlocks.
Hey Guys,
Below is a list of the things that my HTC 8x does when it checks for Windows Updates. I am waiting for Microsoft's server to decide to give me a new firmware, so I decided to sniff out the TCP stream. Of note, I found the following:
1. Phone contacts http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
The Phone goes out and fetches this dll onto the system. It references the following certificates (which you can download):
root cert http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
production cert http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
time stamp PCA? http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
2. After that, it goes and fetches the following cab file: http://sds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab. This cab file contains a single xml file called wuredir.xml. It has two values: the clientServerURL and the ReportingServer URL.
3. After this, some https traffic occurs to the clientserver URL. I am guessing this is it checking for updates.
4. Then it posts to http://statsfe1.update.microsoft.com/ReportingWebService/ReportingWebService.asmx with a SOAP action of http://www.microsoft.com/SoftwareDistribution/ReportEventBatch with a whole bunch of info on the phone.
The User Agent being used for all of these communications is as follows: Windows-Mobile-Device-Update-Agent
If this dll it is fetching is unsigned, I wonder if we could have some fun....I am also wondering what happens if we develop and sign an xap with Microsoft's certificate if it will allow us to do more things within the OS.
Sign with Microsoft's private key? If you have access this then your about to become very popular
Sent from my Arc using xda app-developers app
Hmm, the 5_UssDetection seems to be a normal PE32 .dll. Not .NET compiled. I don't see any COM Imports/Exports for it so finding this out may be a little difficult. I haven't used any tools like IDA though, just a normal PE explorer program.
This is good information though. I wonder if GoodDayToDie may have some further input?
Nice find. I've been monitoring phone traffic myself but hadn't caught this exchange yet.
The fact that it checks external cert files is very interesting. Typically, I would expect this to be using "certificate pinning" where the public key of the signing cert is stored internally in the software, and no other signature is trusted (even if it chains to a CA that is installed on the phone and would normally be trusted). MS does use pinning in a number of places; for example, this is how the original ChevronWP7 Unlocker was broken, and is used when adding a Microsoft account to the phone or when that account is updating. However, I figure there's an excellent chance that pinning is *not* being used in at least one place where it really should be (this can be tested using tools like Fiddler or Burp, which have the ability to intercept SSL traffic using a cert that chains to a cert installed in the phone's trusted authorities store).
If pinning isn't being used, it may be possible to modify/create our own detection DLL, then create our own CA cert, install the public key on the phone, use the private key to sign an intermediate cert (that we also create, and have the private key for), and use the intermediate cert to sign our customized DLL. If necessary, we could even intercept the lookups that the phone performs and control what is returned (assuming the lookups are actually over HTTP, or at least unpinned HTTPS).
The probability that the file is unsigned isn't even worth considering; it's quite likely that Microsoft is using a mandatory signing level on WP8 for all executable code. Unfortunately, if they are doing that, it's also likely that it's set to require a cert which chains to the MS root cert (this is how Windows RT is by default), which is effectively a form of system-wide cert pinning. However, if you want to check, signtool in the Visual Studio Command Prompt can dump authenticode certs on a file.
Reverse engineering the detection DLL is quite possibly worthwhile even if we can't modify it, too; it'll provide insight into the update process, which is one of the best places to mess with a system. It runs with high privileges and explicitly is capable of modifying system code.
That sounds quite enticing! I wish I knew x86/ARM assembly :/. I'll see what the sign tool outputs in VS
It feels great to see that you're here GoodDayToDie You helped out a lot on WinPho 7 for HD2 (a device I'll soon repurchase).
Hopefully there'll be some advancements on the "jailbreaking" of Windows Phone 8
I would be surprised if WP8 wasn't using the same code signing requirements as Windows RT.
As far as hijacking that dll goes, unless we can find an immediate privileged code execution exploit in it all it's most likely to do would be to give us write abilities to the FS, and there's a huge 'if' attached to that. That would be a big step if possible, though.
Something that would be interesting to check is if an EXE compiled for Windows RT (cdb, for example) would be capable of running on WP8. If MS used the same signing certificates it may be possible to put enough of Windows RT's dependencies on WP8 to allow it to run a simple console application. Obviously we wouldn't have any console windows or the sort, but it should be possible to capture output if it worked.
We have a decrypted OS dump around somewhere, right? It should be simple to check if they use the same signatures.
Good call on checking the signatures. I'd also like to take a look at reverse engineering the OEM apps again; even if they don't give us a device-agnostic hack directly, they may reveal interesting things about the WP8 app model internals and also may give device-specific breaks which can be used to gain the knowledge we need for crafting device-agnostic ones.
Slightly off-topic:
The zipview exploit still (sort of) works. Hard to believe, but I bet MS just recompiled the program for NT's Win32 and didn't bother with it beyond that. Decent chance that the same holds for the XAP installer, though I haven't tried yet. However, A) the filesystem layout has changed, so write-only access is even more poking blind than it used to be, and B) zipview may be running with lower privileges than it used to. On a simple test ZIP (attached for your testing pleasure), I can open files and create directories up to three levels above the zip root, but no further. Trying to open a file in a folder directly higher than that gives a "cannot extract to a read-only location" error, and trying to open a file inside a subfolder above the third level up gives a generic error message (probably due to failing to create the folder).
Also, I got wired tethering working on my Ativ S today. I'll create a post about doing that if nobody else has done so yet (it was almost identical to the WP7 Samsung devices, the only hard part being finding the right 64-bit drivers). WindowBreak didn't work, though (the folder that it extracts at is above the permissions cutoff, which makes me suspect zipview can't write to the drive root) and I don't think the subcomponent of the Diagnostics app works the same, either (a lot of the diagnostics codes have changed; we should learn the new ones).I don't even know if WP8 understands provxml (it's historically a CE feature, not an NT one), although I found references in the Diag app to provxml being "ready".
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Great, thanks for that! Looks like provxml is definitely still here, and that's probably good. I'll bet they changed some things though, to make it more NT-ish (support for proper ACLs, for example). I should review those included provxml files for a look at how the phone is currently configured. Lots of potentially interesting .REG files too. I'll have to try some more things here!
No problem. All I did was pull out all text inside '<DevicePath>' tags inside one of the FFUs for the AT&T Lumia 920.
From looking at the FFU it appears to be a collection of CAB archives (or packages) encapsulated in some proprietary format. WP7.x tools don't work on them, sadly.
Edit: I'm blind sometimes, there is a tool to mount them and it does work.
More edit: Different signatures.
More more edit: Windows RT refuses to run the WP8 binaries without a jailbreak.
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
GoodDayToDie said:
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As far as running, some have given me console output, but I haven't gotten a single GUI one to start. I've been considering on looking to see how complex the UI is to see if I can write some sort of WP8->Win32 translation layer. There are just so few WP8 xaps floating around that it's not really worth looking into, though.
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
I haven't really found any to work, per se, I've just gotten console output, generally in the form of an error message or a help prompt. I can't recall which files exactly I had tried with, though. I mostly just poked through system32.
GoodDayToDie said:
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
Click to expand...
Click to collapse
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
netham45 said:
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Click to expand...
Click to collapse
In regards to the file "MMOS.wim", has anyone managed to extract it/analyze it?
I couldn't find anything about it online. I am able to mount the file to a virtual disk and view its contents, but I am not able to view/read/extract any of these files from the drive. Trying to copy any file from the drive gives a system error/exception message that I have never seen before.
Are the files inside of "MMOS.wim" even useful?
---------- Post added at 12:13 PM ---------- Previous post was at 11:22 AM ----------
mcosmin222 said:
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
Click to expand...
Click to collapse
Not difficult, more like impossible lol.
The entire native UI is very independent. It is best described as one single app that has multiple pages. The start menu is a page, settings app is a page, office 365 is a page, etc.
These different pages all cross-reference resources from each other and can modify each other. However, they are all compiled separately. Each "page" contains it's own resources and GUI markup in a dll, along with native code to interact with the markup. This native code can also call functions and access resources from other "page" dll's. There are no compiler dependencies between the "pages" when being created, only during actual runtime.
Things are very "coupled" by this model on purpose. Changing code/functionality in the startmenu.dll could potentially break everything. It is designed so that you cannot target and modify a specific element or feature without updating code in other areas of the system.
Basically, you need full access and understanding of the gui layouts/code to modify it.
The only reasonable possibility is the ability to modify the markup code (think XAML) to change layouts and visuals. But even that possibility is made difficult since the markup is compiled. However, no information is lost during the compilation, meaning that the markup can be decompiled back to its original form.
Windows 8/RT uses DUI (DirectUI), a similar framework, for all of it's native GUI elements.
Windows Phone 7/8 uses UIX/Splash.
Asking a former Microsoft employee about UIX/Splash is like asking a former U.S. government agent about Area 51. They seriously fear for their lives.
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
mcosmin222 said:
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
Click to expand...
Click to collapse
My GUI post was in regards to the native GUI. I didn't realize that you were talking about WP8 apps running on Windows RT. I thought you meant the other way around lol.
Couldn't this potentially be pointless? Microsoft Job posting was looking for developers interested on deploying .appx on Windows Phone I believe. So that means they are going to make .appx the universal model for all platforms and not .xap in the future. With that said, they might be stopping .xap development completely in the future.
Who would develop an .xap for Windows Phone when you can develop .appx and have it work on Windows Phone + Windows RT + Windows 8 + Xbox?
Just some thoughts. I think trying to get .XAP running on Windows RT is pointless to pursue right now, since the time researching would be better spent in other areas of development.
Im not sure how they are going to make appx run on WP8. The WinRT model is obviously tuned towards bigger screens. How would you use a charms bar on WP8? In fact, how would you use any of the W8 stuff on WP8?
I think a lot of people would like to run emulated WP8 apps on their tablets, since some apps have not been ported yet.
While I do agree this is kinda pointless, it's a nice way of learning new stuff.
Hello World , I am most definitely not the best person to be writing this but somebody's gotta.This will be my best attempt to create and maintain an ongoing description of different Linux Distributions, starting with the most popular and branching out from there. If you're new to Linux, or are interested in using it, practically the first thing you are expected to do is choose a Distro (shorthand for distribution) of GNU/Linux to use. Well if that's where you're at, or are looking to find out more about Linux distributions in general, I'm here to break down the pieces and start a tour of distros so you can find what beckons to you. This part can get a lot of people caught up thinking there's a right/wrong answer, really though, the joy of Linux is making it your own and once you know what you're doing, the make and breaks of a distribution will mostly be their software manager and it's repositories (database of applications). Unless otherwise noted, be aware that practically all distros are designed w/ daily use in mind and will likely come with or be easy to install a basic suite of software to meet those needs.
Spoiler: More About
Most beginner guides and resources for Linux are around Ubuntu and if you want things to be easy, just go download that and be gone, but what I've learned, and hope to share in these posts, is that Ubuntu isn't perfect for everyone, and much of the support for Ubuntu also works on other distros, maybe with a few different keywords. The out of the box experience of other distros may be more or less to your taste, and exploring what you do or don't like by jumping distributions is known as distro hopping. This thread may both be a resource for hopping as well as finding the single right distro for you right now.
I am not an authority on Linux nor would I consider myself an "expert," this isn't a complete guide to distibutions either. Anyone with more experience or knowledge than I is free to correct me or add info and I'll do my best to acknowledge and update. I'll also do my best to refrain from speaking too much on things I don't know about, and will denote when I'm unsure. Also stars will be placed like *Distro Names* to deote I know about but do not have firsthand experience with them. I'm writing this post as I have a slightly above average knowledge and understanding on the world of Linux and would like to share what I can for those just starting their journey, as well as take this experience to expand my own knowledge base. If you want more info on each and every distro, check out something like distrowatch.
1. A Dirty Introduction to Linux For those regular to the XDA forum, a good point of comparison for a Linux distro would be the custom ROM scene for Android, where we have the OEM stuff like OxygenOS, OneUI, but then we see the custom scene starting from AOSP, and derivative Lineage, AOKP, and more complex derivatives like crDroid and Dirty Unicorns (RIP ). But there is a distinct difference in practice between custom Android ROMs and Linux distros, which is binary (application) compatibility. Just because an application was written/compiled for one version of Linux doesn't mean it won't be compatible with others, but generally speaking, that is not the expectation with pre-compiled apps for Linux. All the major distributions simplify getting the right version of the app through the package manager, the Linux equivalent of the Play Store or F-Droid, unlike Android though, everything is typically free .
For one reason or another, you may find an application is not available, or maybe it's outdated/doesn't work. The good news is because most Linux software is open source, you can just compile the source code within your distribution to make it run. Whereas with Android, there is platform uniformity through unified app stores like the Play Store, Linux is a bit more fragmented, but not in a way that has to affect your usability. It is in part due to the variety in Linux distributions that we find them to be more secure than their closed source conterparts, malware written for Ubuntu for example would have to be re-written to work on or sometimes be completely ineffective against say Fedora- or Arch-based distros.
Spoiler: Overview
If you're interested in just seeing what some of the distros have to offer, jump to part 2, but this is where I'd like to break down the different pieces to a GNU/Linux system so you will have a better understanding what's actually going on between distributions hopefully. Unlike a platform like Windows where different functions in the system are all tied to one another in ways we can expect only Microsoft devs to truly understand, and Android where the majority of the what you the user interacts with is designed by Google while using proprietary drivers pre-baked into your handset, Linux can be (and often IS) built piece-by-piece. I'm sure there is better language to describe the difference in philosophy but the words escape me. But from here, we'll be breaking down the bigger pieces distributions will customize and include to make the full experiences we expect from them. Keep in mind this is my best to give an overview of these different parts, but is by no means all that can be said. Every section and subsection following here until part 2 is a deep enough topic to make it's own post, or several posts on, describing the pros and cons, gives and takes of each component choice, and the actual user experience some of these components provide are best experienced firsthand. Just know these are where you find many of the similarities and differences between distros.
1.1 Fixed vs Rolling If there's one difference between two distros you should be keenly aware of, it's gotta be distinguishing distributions by their release patterns. Many distros release on a fixed cycle. They'll push out individual and important updates on a regular basis, but will wait for major releases to make large changes. That's where we see things like new features and user interfaces updated on these, when they have a new version release. Compare that to a rolling distro where each component of the system is updated as soon as an update is ready, meaning you may have a major version change to a component months before someone on a fixed distro, but you may get a major change that changes your workflow with little to no warning when running system updates. They both have their gives and takes, but basic rule of thumb is Fixed distros for reliability, Rolling distros for cutting edge features. Standard individual apps, like Firefox, or LibreOffice will update on regular cycles with fixed distros still, maybe not as immediately as a rolling distro usually though, we're mainly talking about OS level updates being either fixed or immediate.
1.2 The Kernel (GNU, and the Bootloader too ) The heart and soul of Linux, the Kernel itself. Developed by Linus Torvalds, the Linux kernel is essential to the OS, and is what provides the most basic functionality of the computer past the BIOS and bootloader. You may have noticed people (including myself0 using Linux and GNU/Linux interchangeably, there's a very quotable meme here to summarize what this means:
Spoiler: CopyPasta
I'd just like to interject for moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!
Put briefly, the Linux kernel handles many system level functions, while user commands and most other basic system level functions are built into what's known as the GNU corelibs and shell utilities, open source projects initially developed separately but are now essential to using a Linux system on a PC. And this right here is what makes desktop Linux (GNU/Linux) different from Android, which is only Linux based and uses many fewer GNU tools. The GNU Project itself is massive (and we'll touch on more applications later) it, includes the essentials for not only GNU/Linux but for any operating system trying to get off the ground. Sure, you can develop your own functions, but if they achieve the same thing as a GNU tool, why not use the tested and trusted libraries/programs that already exist?
Leading us to the most essential GNU tool when starting up your PC, essential to getting an OS up and running, the Bootloader. Android users who root or do any customization will already know a little what this is, but like most things for Linux, is typically GNU and open-source on a PC. There are non-GNU alternatives, but the most common Linux bootloader is GRUB (the GNU GRand Unified Bootloader). So why am I mentioning this? Well coming from any recent Windows PC, the only part of a bootloader you've seen would be maybe a Windows icon or your motherboards OEM icon as Windows is getting ready, on older PCs, you might have gotten a couple lines of text after your BIOS completed post (first part of turning on a PC, sometimes adjustments need to be made to BIOS for new OS and bootloaders to install), but nothing like GRUB. Sure, you can have it only flash on the screen but upon turning on, you need something that tells the computer where an operating system is and loading the initial programs that will allow it to start running and take the reigns from there. GRUB is compatible with practically all operating systems and will be essential if you intend to dual-boot with Windows still installed or if you have multiple distros on your machine. It loads the Kernel, required drivers, and initial system services needed to make everything else work, and once past the bootloader, with a standard distro, you'll be put into userland, where you can sign in, start programs, , do your computing things. There's very little difference between versions of GRUB besides visual, though there are ways you can customize it.
The Kernel which the bootloader loads is where we see the first main thing that vaaries between the distros, as there are different optimizations, behaviors, or even drivers within the kernel itself that need the distribution writers to configure for the best experience possible. For the most part though, even though the Kernel including with a distro is tuned for it, most Linux kernels can be used across distros, or the one's included in a distro are based off of forks of the Kernel for specific things.
Common non-distribution specific versions/forks are: - Linux Stable (All the standard kernel stuffs, with maybe a couple tweaks applied by the distribution, typically loading modules [extra instructions needed for different use cases])
- Linux LTS (Long Term Support, may be missing newer edge features but will get essential updates for years to come, may be missing some security patches, but more stable, and less attack vectors afaik)
- Linux Hardened (making changes that may slow down or otherwise negatively impact performance, but overall make the system less susceptible to attacks)
- Linux Zen (focused on making the user experience the best possible with improvements to memory management and resource management as a whole)
Exactly which kernel options will be available to you out of the box will depend on your distribution, but most will install a standard or LTS kernel and then give official options in settings, with unofficial options able to be installed by other means, often the package manager.
1.3 Free vs NonFree Drivers (Not related to money) This section can be summarized with this: Do you have a Nvidia GPU you need/want to use? Do you intend to watch copy-protected media? Then you need proprietary drivers, written and maintained by organizations that don't support the open source agenda but know their products must work with open source software due to it's prevalence in certain industries and product types. At least for the Nvidia driver, there is an open source alternative, but do not expect it to do anything besides the barest of basics when it comes to visual effects and performance. AMD and Intel both have open source drivers that are on par with their closed source Windows counterparts to my understanding.
1.4 The Package Manager (and Daemons incl. systemd ) This is one of the more critical aspects of different distributions, how you get your applications, and how they are managed. Any component to a Linux system, whether it be a the settings menu or Firefox, is considered a package, and the package that handles other packages on a system level is the package manager. While many package managers exist, there tend to be the primary ones for a distribution base like Ubuntu/Debian has DPKG, Fedora has RPM, and Arch has Pacman. Some more universal package manager formats exist, like Snap, but they aren't ideal as they may lack the system integration expected of repository hosted packages.
A background application is typically denoted as a service, though in Linux a service specifically interacts to requests from other programs and the user, while a daemon typically handles only system level functions, which includes monitoring hardware and keeping services alive. The initialization of these daemons is done through the init system loaded at boot after the kernel. The most commonly used init system is systemd right now, but used to be sysv. The exact functions of these systems are too complex for me to go more in detail here, and would require I learn more than I already do, but what I can say is that systemd does much more than what sysv did and in doing so, has many more problems including reliability and security issues that other init systems do not have, though is used for the same reasons that it has problems: it's complex but handles a lot of functions you'd need more daemons, services, and packages to achieve otherwise.
1.5 The Desktop Environment (Including the Display Servers and Window Managers) Now we're in the territory of aesthetics and software suites, this is where we'll find both the most and least change between distributions,, at least from a beginner's perspective. Once you have a booted computer, you're typically greeted by a login screen, but even this is a variable your distribution chooses for you by default. Once your system initializes, it needs to communicate graphical information to you but that's not part of Linux or the GNU corelibs. Remember, when this stuff was developed originally, computers were more text than graphics, so a service was developed to display graphics, the Xorg server, evolving into modern X11, was the primary backbone of graphical UIs until a modern replacement known as Wayland began development. It's a server because it handles services, though is itself a type of service. Both have ongoing development though Wayland fixes many problems a 30+ year old program is bound to contain for compatibility. In creating a new standard though, Wayland has split development of the other key ingredient to a real graphical user interface. That said, as a user, typically it won't matter which you choose, but may find some oddities between the two in terms of display scaling and some display features working better in one or the other. I'd say though stick w/ what the distro recommends unless you have a specific issue, just trying to cover the differences.
Moving on, I said before Xorg (or Wayland) is the initial service so your computer knows hot to draw graphics, but it's a type of service known as a server waiting for other services to interact, so then loads a fully fleshed out library (either GTK or QT) to determine styling and such. Once the display server and library are designated and loaded comes the Display Manager, or in other words, login screen. From there one more major piece, the window manager, determines how you can actually manipulate the stylized applications. Other UI services will also be loaded such as system bars, docks, and universal menus. The combination of these things into more complete software suites is what's known as a desktop environment (or DE). All those details are picked out for you when you download a distribution, which will have a default flavor (the primary Desktop Environment they develop for and expect you to use) and flavors w/ other desktop environments that another internal team may maintain to assure compatibility and consistency between updates and versions. There's a lot of Desktop Environments and Window Managers, but they all do the same types of things and have some commonality between them between their QT or GTK origins and their reliance on Xorg or Wayland.
Some common desktop environments and window managers include: GNOME - (Premier GTK environment, many forks and derivatives exist, but is good for both touch and traditional mouse/keyboard, but doesn't function like most people expect at first. It can be used similarly to Windows or Mac, but isn't designed to and is best learned correctly before applying too many customization, otherwise why not pick a better fit?)
KDE - (Arguably the most advanced in terms of overall features and customizability, at least of complete DEs. Functions similarly to Windows, w/ some Mac like configuration options. More extensible than GNOME, but also less stable in my experience)
OpenBox - (A completely customizable window manager many other window managers are based on. Does not include all components of a DE, instead giving the bare basics for handling many windows, and leaving the DE experience down to additional packages and/or customization of OpenBox itself)
i3 Window Manager - (A favorite Tiling Window Manager. Always want to lock sections of your screens for specific apps, it may take time to get acquainted but this is for you)
1.6 Gaming (and Windows App Compatibility) Despite what many distributions claim, or how this information gets presented, you can expect nearly all distros to have similar compatibility save for the pre-configured programs to help with this. This is due to the same core component(s) across the board for this, Wine and Proton. These are compatibility layers, made to provide the necessary instructions to run binary applications with Windows specific instructions and using Linux/Unix/GNU functions instead. This is done by interpreting the DLLs or Dynamically Linked Libraries which are different app to app and may need different settings to work correctly. Using Wine (or gaming focused Proton), most programs will run without too much hassle but where distributions differ are in their included tools to simplify this such as WineTricks or PlayOnLinux.If you need Windows apps on the daily, and if those apps are reliant on peak performance as much as possible, Linux may not be right for that, not right now at least. But if you're willing to troubleshoot and compromise, you'll find that almost everything can be run in Linux with some tweaking. The worse case would be to look into Virtual Machines, or sandboxxed operating systems created, and with the right configuration and additional features, can be used in ways that make the apps run almost natively, though you are running Windows to maintain it so is only feasible on powerful enough computers, and will hamper battery life if used on a laptop in most scenarios. With this said, I don't recommend "gaming" distros of Linux unless there is something particularly special about gaming on it (there are a couple, but none meant for daily use). If a good distro has a seperate gaming version, I'll try to mention it, but keep in mind, most of the time you'll be installing bloat and you just need PlayOnLinux and WineTricks to get what you want out of it.
2. The Classics When getting into Linux, you'll likely find a few very commonly recommended or mentioned distributions, and nearly all other distros are based on these, or based off of the same base in Ubuntu's case. If you're new to Linux, you don't have to use these, but start here so the rest of the distro descriptions make sense.
Spoiler
2.1 Ubuntu
Spoiler
The tried, the true, you can't go wrong when going with Ubuntu. But what makes Ubuntu so ubiquitous in the Linux community? From their regular long-term support distributions and wide range of utilities included with it, Ubuntu is the go-to fixed distribution for anyone looking for ease of use in Linux. They offer both an LTS version for users not wishing for regular upgrades, with every other version being a standard release, updated for a little while, but phased out much more quickly for each new release. The default flavor of Ubuntu has for some time now come with the GNOME Desktop Environment, pretty much the standard for Linux desktops. Due to it's size and corporate backing, you'll find prorgrams are easier to find, download, and sometimes even use on Ubuntu. This has the downside of including many more nonfree proprietary pieces of software, as well as less care put in to user privacy. That said though, more things work out of the box, and you'll find it comes with a simple to use graphical package manager which allows you to find and install applications with ease though. If you're still afraid of touching a computer terminal, Ubuntu is a safe choice as you transition away from propietary computing.
As will be the case with many of these distributions, Ubuntu isn't entirely responsible for it's non-GNU/Linux pieces, particularly, it used the Deb package format through installed through DKPG (the Debian Package Manager) usually using APT (Advanced Package Tool). Or in simpler terms, it's based on another Linux distro, Debian Linux. We'll give some more info on that later, but what that means here is that Ubuntu is built on top of what's come before, and has integrated what has come after for a feature-rich experience w/ consistent theming. In addition to the Debian package base though, there are also Snaps which are sandboxed applications that can be updated directly without the need of Ubuntu pushing out an update, but are not popular among many of the users. My understanding is that this is due to it being sandboxed, thus may behave different or not fit in as thematically as apps maintained by the official repositories.
On top of it being a well-themed, reliable OS, it comes in both user and server oriented releases w/ many official and unofficial flavors existing including:
Kubuntu - Ubuntu w/ KDE, or the K Desktop Environment. More Windows like, but also more customizable than the default GNOME
Ubuntu Mate - Created when GNOMEwent from version 2.x to 3.x, Mate (pronounced mah-tay, like Yerba Mate) is a more traditional desktop that can look and feel like Windows or Mac, but is a continuation of what GNOME 2.x was, a good looking, performant desktop environment
Xubuntu - Ubuntu using Xfce, a well rounded, simple desktop manager that's always felt like a bit of Windows XP and 7 combined to me, leaning more on the XP side. Primarily used as a stable desktop environment that uses minimal resources while including the features expected, like window snapping, animated window resizing, and a navigation bar.
Ubuntu Budgie - Using the Budgie DE, this is often considered to be closer to a Mac-like experience, but besides the central dock, has a lot going for it distinctly un-Apple like. The programs menu and widgets it includes makes this DE feel like it's own thing
Plenty more flavors exist but these felt like the most critical to mention. As we'll get to later, many distinct Ubuntu-based distros exist too, but just because it is based on Ubuntu doesn't make it a flavor of Ubuntu, which I hope to illustrate when comparing to Linux Mint later on.
Examples of
App install
Code:
sudo dnf install xxx
App Update
Code:
sudo apt update
System Update
Code:
sudo apt dist-upgrade
2.2 RHEL/Fedora
Spoiler
Doing business w/ Linux? Well then this is probably the Linux distro most recommended for this. Red Hat Enterprise Linux (RHEL) is a commercial Linux distro aimed at the business market currently maintained by IBM. For those reasons, you'll find it's likely easier to get business oriented software on here as companies have come to trust Red Hat to make some of the most stable and secure software you can get out of the box with few compromises. Fedora is the open source free version of RHEL maintained by the community. You'll find more features and user centric programs with Fedora, but are binary compatible, or programs will work across the board. That said, even though RHEL is sold for real money, these distros are much stricter in regards to what's included being open-source and you won't be getting perfect hardware support out of the box if you have something like a Nvidia GPU or software needing proprietary drivers, and is probably the least recommended distro here for gaming on Linux. There's less customizations done than say Ubuntu as well, but you may find it more performant and reliable than Ubuntu partly due to this. These distros are released on a fixed cycle as well but unlike Ubuntu, there isn't a long-term support version, instead, to stay up-to-date, you must be willing to upgrade every 9 months or so. For this reason, Ubuntu server is much more popular for server situations.
Inside of RHEL/Fedora, you'll find the RPM package format with the DNF package manager to install. This is a package format incompatible with Ubuntu, Arch, and other distros not based off the same source code, but the visual package manager will appear quite similar between it and Ubuntu. If you're willing to download Fedora instead of Ubuntu, I'd hope you are a little more inclined to use the Terminal for package management as you'll find it's a lot easier to type a couple words than open a program, type, search, read description, click multiple times before finishing an install. One other interesting thing to note that's different between Ubuntu and most other distributions is that Fedora uses BTRFS by default for it's file system. This is in regards to how it stores and manages files, on Windows, everything is exFAT or NTFS usually, but in Linux, you'll find the most common is called ext4. Consensus seems to be that BTRFS is the best of these options, but ext4's limitations haven't been met and has been stable for longer, so we will not see BTRFS as the default all too often.
Examples of
App install
Code:
sudo apt install xxx
App Update
Code:
sudo dnf upgrade
System Update (multi-step via command line)
Code:
sudo dnf upgrade --refresh
##restart PC, REQUIRED STEP BEFORE ALL UPDATES##
Code:
sudo dnf system-upgrade download --releasever=xx ##WHERE xx IS THE VERSION NUMBER##
sudo dnf system-upgrade reboot
Similar to Ubuntu, there are flavors here, maintained directly by the main dev team instead of individual devs though, known as Fedora Spins. Similar to Ubuntu, you'll find both a KDE and Xfce spin, as well as many others. And like Ubuntu, there exists distros based on Fedora but distinctly different, though due to it's relative simplicity in presenting itself, there are far less of these. Because both Ubuntu and Fedora have a lot of money backing them, they are some of the best distributions for anyone new to Linux, but maybe you're not wanting some corporate entity in charge of maintaining your software. Maybe you're more inspired by the community co-creation aspect, or want to have more control over the fine details of how your PC works. If so then read on.
2.3 Arch
Spoiler
Got that DIY attitude with the time and patience to learn new skills? Well Arch might be right for you. It's not building Linux from the ground up (we'll get there) but it has usually required you (the user) to not only configure your hard drive and manually copy files and such, though there are automated tools to help, and as of recently, now includes one of these. It sticks to the principles of KISS (Keep It Simple Stupid), which is to say it has all the simplest necessities out of the box, unfortunately not the simplest to install. You get a terminal interface, a rolling linux system, some networking tools, and that's about it. If you want a GUI, you have to install the GUI, if the default config of the GUI doesn't work for you, you have to customize the GUI. While this may sound daunting, it's not as bad as you think, partly due to my favorite package manager here, PACMAN! As will be the case with basically all the package managers here, it will help you get all the dependencies required to install and run an applications correctly.
On top of having this standard package manager, Arch users have another goldmine of applications you don't get any where else, the AUR, or Arch User Repository. While AUR apps are not installable the same way through pacman as other apps, you'll find many apps here that otherwise claim to only work on Ubuntu or Fedora, as well as many gits for programs that wouldn't make it into standard repositories. The up to this is you can almost always get something working on Arch with little trouble, the downside to this is that the AUR needs to be maintained, and sometimes you may find an out-of-date AUR listing and not realize you'd be better off cloning and compiling the git yourself. Or in the worst case, they may be pre-compiled or need PGP keys that the maintainer has not maintained, making it uninstallable. Luckily, it's really only apps that aren't necessary where this happens, but it's still frustrating nonetheless.
Because of it's barebones nature but wide compatibility, you can use Arch however you please, but you have to know the different pieces to make it work how you want. For example, do you want it to be a file server? Well, if you know what apps would make it a non-graphical file server, you can do that. Want it to be a network logger? Download the right applications again, and let it do it's thing. Because there's so little extra, you are less likely than on most other Linux platforms to run into performance issues, and can have servers with extraordinarlily long runtimes. But you can also bring it all down a lot more easily if you don't know what you're doing and either have incompatible packages or configuring them in ways that crash your PC, so user beware.
Examples of
App install
Code:
sudo pacman -S xxx
Package Update (since this is a rolling release, this will update both user and system apps)
Code:
sudo pacman -Syu
Package Search
Code:
pacman -Q "xxx"
An AUR helper (not recommended by devs, though used by many, including most Arch based distros including these
Code:
sudo pacman -S yay
##Once installed##
yay "xxx"
##enter your sudo password to proceed)
2.4 * Gentoo (More info in Section 6) *
Spoiler
While Arch Linux is about keeping it simple while making you do a bit of the work, Gentoo is a distribution with an even more hardcore DIY philosophy having you make many more conscious decesions about your Linux. A big theme in the Gentoo community is building and compiling one's own software, this is not a beginner's OS by any means, and a solid, working knowledge of Linux and terminal navigation will be required. Due to this, details will be discussed much later on.
2.4.1 ChromeOS/ChromiumOS ChromeOS and ChromiumOS are linux distributions based off Gentoo designed for simplicity with the Chrome (or Chromium) browser taking center stage. If you're interested in Linux though, you'd be looking at ways to remove ChromeOS from your machine, not add it typically.
3. Debian-based? Debian based So none of the above caught your attention? Maybe you want the compatibility of Ubuntu but don't want as much proprietary software, or are not comfortable with a large company like Canonical creating and maintaining Ubuntu as they please. Well as stated earlier, Ubuntu is derived from Debian, which provides the base for packages and binary applications to run, meaning anything else based on Debian should have similar compatibility.
Spoiler
3.1 Debian (Buster)
Spoiler
Starting off strong is the og, Debian itself. Currently on Debian 10, codenamed Buster, it is fast and reliable, with a focus on LTS (long-term support) rather than bringing cutting edge features. Similar to Ubuntu, it is easy to use proprietary drivers as needed, and is also released on a fixed model. That said, we haven't seen a major release in years, but many new features do eventually get added through incremental updates and you can use Debian Testing if you'd like to get some of the newer features you might find in something like Ubuntu or Mint
3.2 Linux Mint
Spoiler
Based off Ubuntu (which is Debian-based, so is Debian-based in a sense), Mint is a popular choice amongst people distrusting of Canonical but wanting a stable OS with intercompatibility basically guaranteed. The default Desktop Environemnt is one of the devs own creation, being a modified version of GNOME 3.x known as Cinnamon. It has a glassy almost Win7 look to it, but has evolved it's own design language as it's matured. That said, Mint is a little more privacy focused, and do a good job maintaining their repository to avoid the use of the oft-maligned SNAP package format Ubuntu pushes.
While the DE Cinammon is GNOME based, it offers greater customizability than GNOME while taking less resources. It has many of the same elements as GNOME but presented in a way that desktop users will feel more at home such as the navigation bar at the bottom and the start menu being much closer to Windows than GNOME 3.x it's based off of.
3.2 Deepin (I'd urge you to look at alternatives, maybe ok if you live in China but still better alternatives)
Spoiler
You may find Deepin in your search for a Debian or Ubuntu OS that looks nicer, and by all means, Deepin is a beatiful system, originally based off Ubuntu and KDE, they moved to a Debian base and have developed their OS to so it's not just some souped up KDE on here, but it's own Desktop Environment. It has it's own dock, settings menu, terminal, text editor, etc. with KWin being the only part of the DE distinctly KDE. But even then, that's more in a technical sense than a usability sense as Deepin looks more like a Mac than anything we've discussed so far. That said, Deepin isn't completely open source though and was created and is most used in China. Due to the CCP, many are skeptical of this distro, though the main dealbreaker comes down to the repos being Chinese based so downloads are slow and unreliable.
The good news and why Deepin get's its own listing here is that it's DE is so striking, it's been brought to the other Linux distros including Ubuntu and Arch so you can get all the eye-candy with your favorite distro and none of the potential spying.
3.3 Raspberry Pi OS (NOT YOUR ONLY OPTION)
Spoiler
Based on Debian, this is the official OS that the Raspberry Pi team maintains and recommends. If you have a Pi 3 or 4, feel free to use this, but a none GUI OS will probably be better for performance and storage space. Basically Debian with some Pi tools built in
3.4 SteamOS (DEAD)
Spoiler
Valve's (1st) attempt at making a Linux OS for their licensed Steam Machines. SteamOS was available to download and install on other systems and was based on Debian as well, with Steam Big Picture taking control of the interface. It is not well maintained now and is not recommended, even with it's Steam integration. A new SteamOS could come up but the same thing could be achieved with any of these distributions w/ Steam installed.
3.5 * Kali Linux *
Spoiler
Many know this as the hacker's Linux. It is based on Debian and comes with tools designed for penetration testing as well as a lot of other cybersecuirty software. More could be said, but if that's what you're into, I don't think you need me to tell you more, do your own research how to use this OS, it is not recommended for new users.
3.6 * PopOS! *
Spoiler
An Ubuntu derivative gaining a lot of traction lately, PopOS! is created by System76, the largest Linux specific computer company targeted at individul consumers. It is another user-friendly OS to operate and install, but unlike Ubuntu, doesn't want your data, and is more privacy centric. In addition though, there are performance centric features pre-configured here like having the Vulkan GPU drivers installed out of the box, but not much you can't do w/ Ubuntu as well, though they claim to have many other under the hood improvements. User satisfaction w/ PopOS! seems to be higher from my experience. Same can be said of Linux Mint though.
4. Pacman? Waka-WakaSo a fixed release cycle isn't right for you. Maybe you want all the cutting edge features Linux can offer and you want it now. Or maybe you want the endless user repositories of the AUR without the trouble of setting it up from scratch. If that sounds like you but Arch is still a bit above your head to setup and maintain, well then an Arch-based distro might be for you
Spoiler
4.1 Manjaro
Spoiler
Based on Arch, but is much more like Ubuntu in terms of set goals and presentation. This is a highly recommended distro if you want the customizability of Arch, but aren't quite confident enough to format your own harddisks and initialize your bootloader/EFI partition.
4.2 Garuda KDE Dr460nized
Spoiler
Like Manjaro, but a greater emphasis on aesthetics and performance. Uses the Linux Zen Kernel and BTRFS for optimal performance. These features do not reflect well in vitual machines, as compared to running on real hardware. While I don't specify flavors too often, this is their customized KDE flavor that is potentially on it's way to being it's own DE. While it combines many open source programs not exclusive to this styling, it's custom configuration of the Latte Dock makes it look extremely Mac like, while it's custom KDE Sweet theme put's it in a style category that's hard to match out of the box with these other distros. And one of the best parts is it's ability to pre-configure and add apps from the repo of our next distro
4.3 BlackArch
Spoiler
Work in Progress, check back later
5. Grab Your Hats Stability and reliability is the cornerstone of the workstation orriented distributions based off the same base as RHEL and Fedora.
Spoiler
5.1 CentOS
Spoiler
Work in Progress, check back later
5.2 openSUSE
Spoiler
Work in Progress, check back later
5.3 * Rocky Linux *
Spoiler
This was created by one of the people behind CentOS, and my understanding is this will replace CentOS when that stops receiving updates (which is in the near future unfortunately)
6. I Don't Need You, I'll Do It MyselfIf you don't want anybody telling you what you can or can't do with your computer and you're not afraid of getting your hands dirty, check these projects out.
Spoiler
6.1 * Gentoo *
Spoiler
Work in Progress, check back later
6.2 * Linux from Scratch * A true DIY Linux project, requiring you to download, configure, and compile source code to build a Linux system from the ground up. Beyond just compiling a git, or choosing some of the package options, Linux from Scratch will guide you from beginning to end making your own one of a kind distro, though with enough uniformity as to be a proper guide and having compatibility with the greater Linux ecosystem.
7. Wait... This Isn't What I Signed Up ForOS Projects that are open source, potentially POSIX compliant, but aren't Linux. This is by no means complete and be aware many other interesting OS projects exist not listed here
Spoiler
7.1 * OpenBSD *
Spoiler
Not Linux, but still like-Unix, openBSD is the continuation of BSD, a unix derivative. It is POSIX compliant and has runs GNU corelibs as well, but has a kernel all it's own. If you're looking for something different but still getting decent support, look into openBSD.
7.2 Haiku
Spoiler
An open-source OS meant to be reminicent of BeOS, an OS developed through the 90s and was ahead of it's time. I'm unsure of the capabilities of a system like this in 2021 even if it were fully compatible on hardware, but an interesting project nonetheless. And if there are more practical applications of Haiku or BeOS, please tell me.
7.3 ReactOS
Spoiler
Meant to be binary compatible with Windows, it's a clean room project designed to reverse engineer Windows. Still has a long way to go before being a usable OS for daily use, but is able to run on real hardware and run many applications up to the XP-era of Windows
Final Note:
I'm new to this type of writing and as said a few times, this is a work in progress, so feedback is appreciated. That said, I know this post is a little barebones for now, I intend to flesh it out with pictures, a list of typical unique (or distinct) packages each distro contains, and more. Also be aware I may not be able to update daily as I'd like to, but will do my best to have this fleshed out completely within a couple weeks.
Suggestion: add MX Linux (Debian-based) and openSUSE (Tumbleweed and Leap)
Good post @thats_the_guy, this will surely be helpful to Linux newbies (if there are any...)
thats_the_guy said:
Hello World , I am most definitely not the best person to be writing this but somebody's gotta.This will be my best attempt to create and maintain an ongoing description of different Linux Distributions, starting with the most popular and branching out from there. If you're new to Linux, or are interested in using it, practically the first thing you are expected to do is choose a Distro (shorthand for distribution) of GNU/Linux to use. Well if that's where you're at, or are looking to find out more about Linux distributions in general, I'm here to break down the pieces and start a tour of distros so you can find what beckons to you. This part can get a lot of people caught up thinking there's a right/wrong answer, really though, the joy of Linux is making it your own and once you know what you're doing, the make and breaks of a distribution will mostly be their software manager and it's repositories (database of applications). Unless otherwise noted, be aware that practically all distros are designed w/ daily use in mind and will likely come with or be easy to install a basic suite of software to meet those needs.
Click to expand...
Click to collapse
Outstanding post!!!
Superb Post Bro !!
This help me alot to understand more of this "Realm"!
I think, you should add more explanations regardling of Apps inCompatibilites on several Distros----how & why ? or create a section about that.
Thanks!
can you make a list of distros that arent ubuntu based... All I see is some flavour of ubuntu kubuntu, lubuntu etc.
Dhairy said:
can you make a list of distros that arent ubuntu based... All I see is some flavour of ubuntu kubuntu, lubuntu etc.
Click to expand...
Click to collapse
He did touch on that a little bit but I'll list then for you
Debian based:
Debian
Ubuntu (and it's derivatives kubuntu, Lubuntu, etc.)
Mint
Pop!_os
MX Linux
Elementary
Zorin
RHEL based:
RHEL
fedora
CentOS
Arch based:
Arch
Manjaro
EndeavourOS
Then you've got independent ones that are close to the ones that are mentioned above like
OpenSUSE
Slackware
Alpine
Gentoo
A good place to see distributions and more specific information about them is https://distrowatch.com/
Hopefully that helps
This:
thats_the_guy said:
a lot of people caught up thinking there's a right/wrong answer, really though, the joy of Linux is making it your own
Click to expand...
Click to collapse
Exactly!
Try, break*, tinker, start again! Just do it!
* but do make backups!
SigmundDroid said:
Try, break*, tinker, start again! Just do it!
Click to expand...
Click to collapse
This is the way.
I use debian sid as my daily driver
Good post. I have used several dristo in the last few years and the only one I haven't tried is Fedora. Actually I run MX Linux, it's a compromise but it's good for me and it's good for my family.
Now i use Debian 11 bullseye btw
iamshubh69 said:
Debian 11 bullseye
Click to expand...
Click to collapse
What desktop do you use primarily?
SigmundDroid said:
What desktop do you use primarily?
Click to expand...
Click to collapse
You mean specs of my desktop or anything else?
iamshubh69 said:
You mean specs of my desktop or anything else?
Click to expand...
Click to collapse
Pretty sure he means Desktop Environment, like XFCE, etc
HipKat said:
Pretty sure he means Desktop Environment, like XFCE, etc
Click to expand...
Click to collapse
Then i use kde plasma
Yes, thanks for pointing it out @HipKat
Me, too
I just wonder what will be in 2023 with KDE and Debian 12 when no maintainer is found for QT6...
https://www.phoronix.com/scan.php?page=news_item&px=Debian-Needs-Qt6-Maintainers
...but then Plasma 6 doesn't seem a pressing mattter yet:
https://community.kde.org/Schedules/Plasma_6
SigmundDroid said:
Yes, thanks for pointing it out @HipKat
Me, too
I just wonder what will be in 2023 with KDE and Debian 12 when no maintainer is found for QT6...
https://www.phoronix.com/scan.php?page=news_item&px=Debian-Needs-Qt6-Maintainers
...but then Plasma 6 doesn't seem a pressing mattter yet:
https://community.kde.org/Schedules/Plasma_6
Click to expand...
Click to collapse
Lmao
iamshubh69 said:
Lmao
Click to expand...
Click to collapse
Better don't laugh your ass off so quickly... Srsly, am I overlooking something here? Wouldn't that pose a problem?
Eh, but you're probably right, why should we worry about the tomorrow-worries of other people Besides, unlike windows or mac, we can switch to anything and/or use things together...
SigmundDroid said:
Better don't laugh your ass off so quickly... Srsly, am I overlooking something here? Wouldn't that pose a problem?
Eh, but you're probably right, why should we worry about the tomorrow-worries of other people Besides, unlike windows or mac, we can switch to anything and/or use things together...
Click to expand...
Click to collapse
I've used XFCE for so long but I loved KDE-Plasma when I used it, too