Sean's Technological Journeys

Re-blogging

http://www.combatpretzel.com/2008/11/cheap-dedicated-hosting/

Their hosting is even better and even cheaper than listed from 2008. Now they have Core i7 on all models! I can't believe the deal you get on a Core i7 965, 12GB RAM and 1.5TB of disk space, with 100MBPS uplink. It's in Germany so you'll get great speeds to Euro customers and probably decent enough to the US too. I'll keep blogging about how well mine performs when I get it

The title of this post is intentionally devoid of meaning and full of ambiguity. It seems that misunderstanding abounds when we talk about the various components of the sound architecture on the free desktop. In this post, I am going to cherry-pick on some comments posted to Aaron Seigo’s post regarding PulseAudio which seem to indicate severe misunderstanding of just what everything in the stack does.

This post is going to be as unbias as possible, and at no point will I recommend that you should use a particular configuration or set of programs/libraries/servers. My only goal here is to correct factual inaccuracies, but like any piece of writing, my own opinions will of course play into my selection of facts. And just in case you want to interpret me as pushing a particular agenda, think again; please consider that for the past 6 months I have almost exclusively used a DMIX-based sound setup on my laptop, and a PulseAudio-based sound setup on my desktop. Different hardware, different use cases, different programs. If someone really presses me, I might write a separate article expounding why I think particular solutions are good for my own particular use cases, but that’s not the focus of this article.

I will preface this article by asserting the following claim that may not be universally agreed upon, but it is so broadly-held that I am confident exposing it as a groundwork postulate:

(1) Hardware mixing solutions are very rare these days.
(2) In the absence of hardware mixing, the only way to play sound from two processes at once is to use software mixing.
(3) The mixing of sound from two processes at once is a desirable goal.
(4) Furthermore, the loss of mixing capability should be avoided at all times during the user’s experience. That is, the only process that should acquire the non-mixed “lock” on the raw sound hardware, is the facility that performs the software mixing.
(5) Therefore we must deploy some mechanism for software mixing as a de facto standard feature on all Linux desktops, much as we have accepted the de facto standard of having a mouse cursor associated with a graphical interface.

If you do not accept this argument, you may have difficulty seeing the soundness of any of my assertions below.

PLEASE NOTE: Nothing said in this post is intended to reflect upon the opinions of Aaron Seigo or his claims. I am leaving Aaron’s argument “as is” and focusing on some of the really problematic assertions made in the vast compendium of comments that followed.

First, Jeff says:

Now, what with it being new distro season and all, the first thing I do when I get a new distro up and running is tell Pulse to screw off. I use KDE4, and Phonon Just Works 95% of the time (the other five? Not sure if that’s Phonon or the app messing things up, but they’re minor issues at best)

Could there be an implicit assumption? Paraphrased: If I use KDE4 and Phonon, I’m not using PulseAudio.

In reality: PulseAudio is a perfectly valid backend to one of the Phonon backends; in other words, until you uninstall PulseAudio, you could very well have all of your applications use Phonon _and_ (at a lower level) PulseAudio as well. The two serve different purposes, and Phonon is really designed to “hand off” media to one of the media frameworks (GStreamer or Xine) which, in turn, hands off the decoded sound to PulseAudio.

Of course, Jeff could also be aware that Phonon has this capability, and he is simply remarking that, by not using PulseAudio but instead using some other software PCM mixing alternative, possibly dmix he is getting better results. This would be a coherent assertion.

My question in this case is, assuming that you accept my assertion that you need software mixing, what software mixing solution are you using? Certainly not Phonon, because Phonon doesn’t provide any software mixing solution! At least, not across processes. If you have software mixing at all (and this post assumes you need to), it’s coming from somewhere else. We should then weigh the perceived negatives of PulseAudio against this alternative’s own negatives.

Second, kriko remarked:

So pulseaudio was uninstalled from my machine very quickly.
Phonon + xine = win for me.

Implicit assumption: Using Phonon + xine is mutually exclusive with running PulseAudio.

In reality: Wrong. See above.

Third, saschpe remarked:

PulseAudio has just no use-case. Honestly, for whatever reason does we need this one? Back in history, one or two years ago, I installed it when everybody did because it was cool and TheNewThing ™. Now I still have it installed , this time because the (K)Ubuntu packagers force me to do so, for whatever reason there are dependencies on libpulse for OpenJDK and kdebase. Maybe I should file a bug on launchpad.net on it …

This is a juicy one with many deep misconceptions. Let me start with the easy one:

Implicit assumption #1: Any program that links against libpulse is somehow using PulseAudio.

In reality: This is simply false. libpulse is only the client side of the PulseAudio architecture; without the pulseaudio server (the package ‘pulseaudio’ on Debian and *buntu), this functionality is present but never used. It is conceivable that some packages link against libpulse as their only method of audio output; however, so far this is not true for anything except the native PulseAudio utilities. Even OpenJDK provides other (non-PulseAudio) alternatives for audio I/O. It’s just linkage – if you aren’t running a PulseAudio daemon, it isn’t doing anything.

Filing a bug like this would be like saying, I run an Ubuntu Server instance, and I never want to start an X.Org X Server instance for a graphical desktop. So maybe I should file a bug against the Java stack because its AWT library links against libX11? This sort of reasoning is complete nonsense.

Now for the harder one to tackle:

Implicit assumption #2: PulseAudio has just no use-case.

In reality: This is simply false. You could have stated more accurately that There are other facilities that perform the same functions as the subset of PulseAudio that I do need; as for the rest of it, I don’t want it.

There are two big problems with the assertion that PA has no use-case:

1. Just because you don’t want it, shouldn’t mean that distributions should abandon that feature altogether. As a concrete example, the in-flight stream swapping feature of PulseAudio is completely unmatched by any other software. Just point me to some other software that will switch your sound-playing streams from one sound card to another without interrupting the stream at all (AND without causing any hiccups or restarting the playback of the client). There are a few other features that PulseAudio pioneers that other users do have a use-case for. Whether or not you particularly have a use-case for them shouldn’t dictate what distributions are allowed to ship. If you want a distribution that includes all, and only all the features that you specifically have a use-case for, then start your own distribution!

2. You might be asserting that any features PulseAudio provides that you want, are overlapped by other programs. For example, if the only feature of PulseAudio you really want is the software mixing (and nothing else), you can use ALSA’s dmix. That’s a fine thing to say, but like in the previous point, that doesn’t mean no one else needs those features. And what’s more, just because another program does it equally well (or perhaps better if you have found some bugs in PA) doesn’t mean that there is no use-case for the features PA provides! What you are essentially claiming is that there is no use case for any of PulseAudio’s features, such as software mixing – which I have to completely disagree with; see above.

Implicit assumption #3: The (K)Ubuntu packagers force me [to install and use PulseAudio].

In reality: This, too, is simply false. Just ask Aaron Seigo, or one of the many other Linux users who are not “locked in” to PulseAudio any more than you, and they will tell you that you can have a perfectly functional desktop with software mixing but devoid of any PulseAudio daemons. The idea that somehow you are having things forced upon you is erroneous; it is a simple fact of the matter that distributions must choose some default configuration that they think will be good for the masses of the users, but this is simply a default configuration; it is by no means binding. If you really think that they are forcing PulseAudio on you, then you must also think they are forcing GNOME (or KDE) on you, as well as X.Org, and Firefox (or Konqueror), and HAL, and D-Bus, and the Linux kernel, etc. But this is absurd.

You are free to alter the system not to use PulseAudio, and that is actually a fairly easy task that does not even require you to remove any of your favorite programs. So there isn’t even a practical problem here, much less in principle.

Fourth, Samuel Mukoti remarked:

I believe it [PulseAudio] has the same design goals (to some extent) of what he developer of aRts had.

Yes and no. I like how you qualified your statement with “to some extent". In that sense, this isn’t really an erroneous assertion at all, so I’m not going to bring up that you have any misconceptions. I’ll just say that this was a fairly brief comparison of aRts and PulseAudio that hides some of their differences.

In reality, aRts tried to do lots of things PulseAudio doesn’t try (and won’t ever try) to do. For instance, aRts had the ability to decode non-PCM media (mp3, ogg, etc.) into PCM data. It would then do software mixing on it, similar to Esound or PulseAudio. So, while there is overlap between aRts and PulseAudio, I just wanted to make it clear that, unless hell freezes over or the core devs of PulseAudio (Lennart) have a major rework of their opinions, I don’t think PulseAudio will ever have this feature which (crucially) distinguishes aRts and PulseAudio.

Also, PulseAudio tries to do lots of things that aRts never tried to do. Since aRts is mostly dead, I can’t rule out that aRts would never try to do these things if it had been more successful; however, judging from the direction aRts was taking, it seems plausible to say that:

*aRts would never care to do hot swapping of streams from one card to another.
*aRts would never care to support bluetooth headsets.
*aRts would never care to support automatic discovery of sinks via HAL and Avahi.
*aRts would never care to support a vast number of interoperability libraries that help programs using other APIs to use aRts underneath. I never saw any work started on an aRts-ALSA plugin like we see with Pulse-ALSA.

Fifth, maninalift remarked:

I have had the same experience with openSUSE. Your blog post gave me hope that I could rip-out PulseAudio but apparently not

In reality, there is a very simple way to get rid of PulseAudio, while retaining software mixing through dmix and dsnoop:

Get to a root shell, or use the sudo command. I don’t care how you do it, but you need to run all of these commands as root:

Code:

You now have to deal with all of the associated problems of dmix; for example, if you plug in a USB headset, you have to edit this configuration file to get sound to play out of the headset. Oh, and if you want some sound to play out of the headset and other sound out of the internal soundcard, you’re really in a bind. There are some hacks you can do, but in the general case you’re hosed if that’s what you want. That’s one of the problems PulseAudio was designed to fix in the first place!

Sixth, behavedave remarked:

I thought PulseAudio was a sound server like AlSA but better. Now I find it’s somewhere around the Xine/Phonon level. What does it do then?

ALSA is not a sound server. There is a completely deprecated sound server still in the ALSA codebase last I checked, but it hasn’t been maintained for many, many years; every other part of ALSA (the stuff that actually works) is not a sound server.

The similarity between PulseAudio and ALSA can be summarized thus:

1. They both provide an API (Application Programming Interface) for developers to write programs that need to play sound.
2. They both provide an API that is a bit too complex for most sound-using programs, so in general you should use neither ALSA nor PulseAudio’s API, directly, unless you want to make bug-prone software. On the other hand, certain “special” requirements in the audio arena do require directly using these APIs. You can find more info on these special requirements by googling “realtime audio", “writing your own sound server", “not invented here", or “I AM an inventor and I want to do new exotic things with digital audio".
3. They both provide software mixing capability to an extent. The specific part of ALSA that provides software mixing is called dmix. dmix is neither required nor automatically used in most configurations; only a vanilla install of ALSA (unmodified by the distro) will activate dmix without any changes. PulseAudio, on the other hand, can not be used without the software mixing piece. In other words, I can write an ALSA application that breaks software mixing. I can not write a PulseAudio application that breaks software mixing.

Is it [PulseAudio] the reason why:

Audio just drops off on my PC? (reboot)

What do you mean by this? Does audio simply stop working altogether with no way to fix it other than reboot? If so, this could be PulseAudio. It could also be a failure inside of ALSA. Either possibility is likely. ALSA is not bug-free either!

I can no longer mirror front and rear audio in KMix?

Maybe, yes. But KMix is not aware of PulseAudio. There are ways to do this with PulseAudio that do not involve KMix.

The starting sound in KDE4 only plays half a second?

Another post addressed this issue.

behavedave continued as follows:

It does seem complex but it handles so much legacy compatibility it was always going to end up that way. It seems a mystery to me that all those differing systems worked harmoniously without pulse not despite of it.

The only curious thing is what or where is the native protocol for pulse surely it would provide its own control layer so that eventually that would become the standard bringing together all the other applications as they left their legacy interfaces.

In fact, all those disparate systems did not work harmoniously without PulseAudio! Admittedly, PulseAudio does not resolve the problem, as the problem itself is poses an almost insurmountable design challenge:

Give me an audio stack on which (assuming that I have enough hardware resources like RAM) I can install every audio-using Linux program, run them all at the same time, and not experience any dropouts or degradation of sound quality.

This is the challenge that software mixing solutions must ultimately face. This is the challenge that OSSv4, dmix, pulseaudio, aRts, and Esound all hope to eventually conquer. This is the challenge that we are so jealous of the proprietary operating systems about, because Mac has CoreAudio and Windows has DirectX; in 99.999% of the cases, these “other OSes” can meet the challenge above, given enough system resources. Windows never says “Device or resource busy.”

The division of the audio stack is the reason why we can’t claim the same. Incompatibility is our plague, and every additional piece to the puzzle increases the necessary complexity of any solution that wants to unify the free desktop audio architecture.

Now: As to your question of “where” the PulseAudio native protocol is? The answer is simple: libpulse is a client library that gives instructions to a PulseAudio server, such as “play this clip of PCM data". The PulseAudio native protocol is used whenever any application (except Esound applications) wants to play sound through PulseAudio. Keep in mind the number of indirections possible in the sound stack per the diagram; just because your end-user tools say that your program is using Phonon, that doesn’t mean Phonon isn’t using PulseAudio through gstreamer through libpulse in the backend. In fact, it probably is by default. PulseAudio is like the Xserver of audio, if you understand the graphics architecture any better.

Seventh, rf4nI5QRtMlfRg3rv00S9IGZVQNadQ– (what a name!) remarked:

Plus Fedora had to rewrite most of the PulseAudio-Core to stop it from randomly clipping(which is still happening btw.) which left me with a big WTF in my mouth. They need distributions to fix stuff that would be considered “basic” by 99% of all peole?

Just so you know:

Fedora is Red Hat’s officially sponsored test bed distribution. Fedora percolates ideas and new software to prepare it for inclusion in stable Red Hat releases. And yes, I’d bet money on the fact that Red Hat Enterprise Linux 6.0 will probably ship PulseAudio in some form or another.

Lennart Poettering does 90+% of the work on PulseAudio.

Lennart Poettering also works for Red Hat.

In order to prepare PulseAudio for inclusion in Red Hat, Lennart is also the maintainer for Fedora’s PulseAudio.

So it’s not a “distribution” fixing it; the guy who basically is the PulseAudio project is working on it, but he’s being paid by Red Hat to do it. What’s the difference? I don’t see any.

BTW, glitch-free (also known as time-based scheduling) is not designed to stop all glitches from ever occurring. Its true benefits are not to prevent glitches (it can’t do that on certain kernel/hardware configurations, no matter how hard it tries.) The benefit of glitch-free is to:

1. Reduce power consumption and CPU usage significantly.
2. Deliver sound with lower latency than before: what you need, when you need it. Nothing more, nothing less.

The primary growing pains of glitch-free (its much-maligned brokenness) are due to the following sort of development model:

1. Lennart happily hums a tune while developing large amounts of code based on his understanding of how ALSA-lib works. (His understanding is dependent on how well ALSA-lib is documented, among other things; ALSA-lib is almost completely undocumented.)
2. Lennart tries the new code on a few of his sound cards and runs into problems. Hmm, this is not good. Maybe he misunderstood some of the semantics of ALSA calls.
3. He finds a mixture of “that’s supposed to work that way, but it doesn’t… oops. File a bug and we’ll get back to it in a year.” and “Nah, you’re mistaken; it actually works this-a-way.”
4. He goes and fixes his code so that, with a combination of hacks and dependency on some upstream bugfixes, glitch-free seems to work on his reference hardware.
5. He releases PulseAudio versions with glitch-free enabled by default.
6. Users, who inherently have much more time and resources and variety of sound cards and kernel configurations, run into myriad problems because the code was not designed to work on these configurations, or there are bugs in these hardware drivers, and so forth.

And you can see how it gets ugly from there. That’s why glitch-free is currently, well, glitchy. No one’s to blame; it’s simply the state of flux of a software that’s still in development. If we have the requirement of having everything work 100%, I would agree with assessments that glitch-free is being shipped prematurely on production distributions. But it needed to get out there to get the wide testing that Lennart needs to fix it… hence, chicken-and-the-egg problem. Lennart simply can’t test all the hardware out there; there are too many different cards.

So that’s my summary of why glitch-free is currently a bit broken in some cases. But if you think about the situation with a clear mind, do you see anything that would permanently block glitch-free from being a plausible design in the long run?

1. Kernel maintainers for distros can configure the kernel in a way that makes glitch-free happy.
2. ALSA maintainers (and Lennart) can fix bugs in ALSA that makes glitch-free work better.
3. Lennart can tweak PulseAudio to accommodate some non-optimal situations in which the above two actions do not resolve the problem.
4. Distributors can tweak PulseAudio’s user-facing configuration to accommodate situations that are not addressed otherwise (Example: disabling time-based scheduling in some environments).

Summary
I’m tired of typing, so I hope some of this made a bit of sense. I’ve just cherry picked seven comments off of Aaron’s blog and made some responses to them. Some of it is more informative/factual in nature, while other parts are pure opinion. Take it as you will.

Comments are enabled but must be approved by me first, to prevent spam.

-Sean

A desirable goal for the Free Desktop is to have our own 3d games that we can play. Just because it takes special talents and tremendous amounts of effort to develop 3d games doesn't mean that we can not achieve this lofty goal.

Today there are only two types of hardware for which there are decent Free/Open Source drivers (and by "drivers" I mean 2D as well as OpenGL, and all that entails, such as an in-kernel graphics memory manager): oldish ATI Radeon cards, and all recent Intel integrated graphics chipsets.

I don't own any Radeons, but I've heard positive feedback on recent improvements there. However, by far the most advanced and featureful open source graphics stack is the one put together primarily by Tungsten Graphics (now a part of VMware), Intel, and Red Hat. This consists of a user-mode device driver that runs inside the X Server; the Mesa 3d OpenGL library, which communicates with the X server using DRI2 to make its rendered frames available for compositing and management; and the kernel and user-mode management routines consisting of the Direct Rendering Manager, a large component of which is the Graphics Execution Manager.

This set of components inter-operates to provide Radeon and Intel cards with the latest in open source display technology.

Today I built the entire stack above from source, checking out the latest components from git. The difference between the current "stable" stack (what Intel calls the Q4 2008 package) and today is primarily the new support for GLSL version 1.20. Version 1.10 has been standard for several releases.

The stack runs fairly stably, for a development version; I only noticed a few glitches. For the most part, things work as you would want them to, and you can set your expectations rather high. Unlike the past, today you can enable a composited desktop via AIGLX and continue to render 3d applications with a negligible performance impact. In fact, my tests indicated a qualitative performance decrease without a composited desktop.

I tested out four open source 3d games, and two proprietary 3d games. All of them have fairly demanding hardware requirements. My hardware is a ThinkPad X61T 7764-CTO. This laptop has a Core 2 Duo L7700 clocked at 1.8GHz, with 4MB of cache; 4GB of RAM; SATA-2 7200RPM 200GB disk; the Intel "Santa Rosa" mobile chipset; and an Intel Crestline GM965 integrated graphics controller with 128MB of reserved VRAM. An interesting tidbit is that the Intel guys have tuned their driver to actually claim 256MB of VRAM, which is the maximum amount of system memory that the controller is allowed to claim. I'm not sure why Lenovo advertises it as having half of that. When I look at my 'free' system memory, it is indeed 256MB lower than the advertised 4GB, because 256MB is reserved for graphics.

Here are the results when testing these games:

1. Second Life. It runs perfectly and smoothly at 10 - 20 fps. You will notice a performance hit if you start other processes that are heavy on the CPU, because both the rendering and the Second Life engine are rather CPU-intensive. To keep the frame rate up, you should give SL lots of available RAM and CPU. Note that performance in Second Life has traditionally been low, and on many driver builds I've tested, Second Life also tends to crash a lot. The resolution has been to simply wait for Intel to finish their work on the Graphics Execution Manager, as well as some welcome improvements to the Mesa 3d renderer.

2. Vegastrike. It runs very smoothly, but requires some settings tweaking. Vegastrike attempts to guess your video card model from a list that is extremely outdated, as it stops at the GeForce 3. If you have none of the cards it recognizes, then it defaults certain settings to ridiculous levels: high-quality fonts are disabled, which means that you can hardly read any in-game text, and Vertex Buffer Objects (VBO), a feature that is well-supported by now on the Mesa stack, is also disabled, reducing performance. After enabling these features, performance is excellent, and in-game text is readable again. My main gripe here is that there is one rendering glitch: as you change position relative to objects in your camera view, the old position of the objects will remain on the screen every few seconds. It feels like the graphics stack operates as an "inch worm"; it periodically goes behind itself and cleans up old garbage, and then it has a few seconds of correctly-rendered frames, and then it again starts rendering "trails" of the frames that came before the current one. To see this effect in action on any hardware, download a game based on the Quake 3 engine, turn on the "no clipping" feature, and walk into a wall or off the map.

3. Chromium B.S.U.: This one runs perfectly, both performance and correctness-wise, with default settings and graphics detail set to high. The requirements here aren't very demanding, but it's good to know that it is still supported.

4. Planeshift: The game starts, and the basic GUI elements show up; however, all rendered world objects (such as characters during character selection, and the entire 3d world once you enter the game) do not render at all; they are completely black.

And now, the proprietary games.

5. Savage 2: Crashes to desktop. The crash is caused by a function call in the Mesa library (libGL). I'd be happy to provide the info to Mesa developers to improve their stack, because according to the developers of Savage 2, they don't support Intel graphics cards at all. Considering this decision, any fix would have to be on Mesa's side, not Savage 2's. Note that this game is a proprietary native 64-bit Linux application, so there is no emulation.

6. Audiosurf, running through Wine: Freezes the entire X server, or crashes gently to the desktop, depending on whether you have compositing enabled or not. The issue here could be any number of places, but if it's with Wine, Mesa, or the Wine-Mesa interfacing, then there's hope that open source developers can work on it. If the issue is inherent in Audiosurf, though, it would be very difficult to work around it in the Wine code, and unlikely.

All things considered, it's not too bad. Savage 2 is extremely demanding of the hardware, and Audiosurf is running under Wine emulation, which slows it down considerably. Also, the proprietary nature of these games means that if your card isn't officially supported, there is little you can do to convince the developers to get it working with your hardware.

Here we can clearly conclude that open source games run much better with the open source graphics stack than proprietary games. I plan to test additional games later, as well as any future versions of the Intel Linux graphics stack.

The website for Intel's Linux Graphics effort is http://www.intellinuxgraphics.org.

Dear Jim,

First, thanks for your thoughtful trackback. I am glad that my blog garnered some attention from Sun employees; I wasn't really expecting that! For those of you who haven't been following the discussion, the original post on my blog is here, and Jim's reply on his blog is here.

I would like to hear a bit more explanation on the title of your post, "No Coup Needed". I'd like to hear your side of the story. My blog post was intended to demonstrate how, with a little work, OpenSolaris can really meet peoples' demands of a desktop OS. I was simultaneously trying to cheer on the community to make the amount of work (on the user's behalf) less and less, while trying to point out where it currently falls short, in the hopes of getting OpenSolaris contributors to focus on making those issues more seamless. If all of these goals were fully realized, therefore, OpenSolaris would be in position to peacefully convert Linux users to OpenSolaris, thereby causing a "coup" of sorts (but without armies and assassinations and so on). My title, though, was really asking a question to Sun, and to the OpenSolaris community at large.

What I'd like to know is, why does Sun expend man hours on OpenSolaris features which directly benefit desktop end-users, but not servers and the like? I have always been curious about this, because it seems that OpenSolaris reaps the most revenue for Sun by being deployed on large servers (and those servers might also conveniently run Sun hardware). I may not be seeing the entire picture of how trying to catch up to Linux usability on the desktop is directly benefiting Sun.

On the other hand, of course, I recognize that there *is* an OpenSolaris community out there, which consists of non-Sun employees who have their own agendas; and they may be contributing stuff that benefits desktop users. This is a nice way to go, since Sun only has to accept their contributions, which doesn't take nearly as many man hours.

If by "No Coup Needed" you meant that Sun just doesn't need to _try_ to overtake Linux, but it will do so eventually in time, I think that's also a distinct possibility. At this point, it's a simple matter of calculus: if the rate of change measuring the growth of the Linux community is faster than the growth of the OpenSolaris community, then OpenSolaris will likely have fewer features, fewer testers, fewer contributors, and fewer well-integrated FOSS packages than Linux distributions. If, on the other hand, velocity is in OpenSolaris' favor, then we need only keep doing what we are currently doing, and in time, OpenSolaris will have more desktop adoption than Linux distributions.

Of course, it's also nice to recognize that in the Free Software world, there is no need for aggressive competition in the sense of attempting to extinguish a competitor, or reduce them to obsolescence. Instead, simply trying to make your community as strong as possible, while coexisting peacefully with competitors, seems to be the common theme. Linux _is_ a competitor because the kernel is inextricably different between OpenSolaris and Linux; furthermore, any user of a Free Software operating system must choose between Linux and Solaris. So in that sense, since Linux and Solaris serve the same function as being the core of the OS, one might argue that it is important to seek out and retain new community members, even at the expense of converting them away from the other alternatives. But the GNU userland, I believe, is a potential powerful ally, if properly adopted into OpenSolaris.

At this point in time, I think I will remain neutral and sit on the fence. I really don't know which interpretation of the future of Linux and OpenSolaris is the most likely. I run both Linux and OpenSolaris, and I will not disregard either community as being obsolete, inferior, or defunct in any way. I have tried OpenSolaris distributions in the past, and I did not consider it to be a viable alternative for a desktop OS; however, since I tried 2008.11, I have revised that opinion. We will see what happens in the future. I hope that we will soon have choice for every aspect of the Free Software stack: until OpenSolaris, there is an alternative for every component except for the kernel. Now there are no single-source components of the system, and the alternative -- OpenSolaris -- is shaping up quickly.

Thanks,

Sean

I’ve been thinking for a while about my development experiences, and why I will often go out of my way to do something like access my development environment (Eclipse on Linux) through an NX server – and happily suffer through the slow screen refreshes – just so I can have a better time coding.

My ThinkPad X61T is an acceptably fast Santa Rosa-based laptop, with 4GB of RAM, a Core 2 Duo, and a 7200rpm HDD. Those specs make it pretty well-suited to building software. But it suffers from one limitation and one annoyance.

The limitation is that the screen resolution is only 1024x768. Development environments often have a great number of different panes, popup windows, scrollbars, and so on – these certainly contribute to making the UI more usable and productive. Many of these features are very desirable and I can’t live without them.

I’m looking for a much higher screen resolution in the purchase of my next laptop. But I also want to keep it fairly small. Anything over 14″, I would consider too large. I guess I’ll have to accept a higher DPI on my next laptop purchase, because that way I can get more resolution with less space. But then everything is smaller and harder to read, unless it’s sufficiently bright

When I’m developing with a good display resolution, things are smoother. Eclipse is very flexible about hiding stuff so you can read code that goes above 80 columns per line, but it takes time to have to minimize the overhead of the other panels so you can actually _see_ 80 columns on 1024x768. It’s much nicer to leave everything open all the time, so you can just click what you need, when you need it.

I think I’ll hold out until Nehelem-based laptops are available and not way overpriced. Then I’ll look at one with a tablet and decent battery life. Then I’ll tack on the best screen resolution I can find. If anyone has suggestions, I’m listening

This isn’t such a useful post, upon reflection - I’m basically just saying that I am better at programming when I have a high screen resolution, so I’m gonna look for a better screen resolution for my next laptop purchase Not as meaningful as other posts in this blog, eh?

Since I am an operating system connoisseur, and especially because I can hardly pass up Free Software operating systems, I downloaded OpenSolaris 2008.11 today, out of curiosity. I started out with somewhat low expectations, so when my favorite Linux and cross-platform software started popping up left and right, I was very surprised. It would seem that even some of the big, non-Sun vendors – Nvidia and Adobe – are backing OpenSolaris by supporting the platform.

Here is a summary of what I have experienced:
1. Virtually all of the most popular FOSS desktop applications are available. They may not come on the installation disk, but you can install them with a click in the package manager – after a sizable download, of course.

2. Due to the availability of the vast majority of important FOSS software, your OpenSolaris desktop will quickly start to look and feel like a Solaris-stylized Linux distro. Those already used to a GNOME-based Linux desktop will not see a dramatic difference in the end-user applications.

3. The breadth of hardware support, particularly for laptops, is not on par with Linux. However, if you get lucky and OpenSolaris supports your hardware, getting the basics will be very easy for you.

4. You can find precompiled binaries of all sorts of things floating around the net. With a bit of creative googling, you can go well beyond the offerings of the package manager, and have Firefox with Adobe Flash 10, Adobe Reader, Java 6, and even Gstreamer-based movie playing with Totem.

5. There is plenty of Linux-specific software that has yet to be ported to OpenSolaris. Sometimes it may be just a few lines of code where a library call needs to be tweaked; other times a significant rewrite is needed. However, the number of Linux-specific packages that recently support OpenSolaris is rapidly increasing.

6. One major advantage of OpenSolaris is the genius that is the ZFS filesystem. Even on relatively modest disk hardware, ZFS has noticeable performance gains over the popular Linux alternatives, ext3 and reiserfs. This is directly observable to an end-user when doing things like file copies or installing software. You can read more about the performance of ZFS with Michael Larabel’s independent review of operating system performance, between FreeBSD, Linux and OpenSolaris, here.

7. There’s no way that anyone not already an experienced Linux or Solaris user will find this operating system workable, especially compared to Mac or Win32. You need to be conversant in F/OSS technology, and fight a sometimes uphill battle, to get OpenSolaris to the point where it has feature parity with a common Linux distro such as Ubuntu. Most of the problems, oversights, and incompatibilities of OpenSolaris are not with the front-end applications, but under the hood; these compatibilities, while more concealed from the user, are not less significant due to their nature. In fact, certain problems like filesystem support may be a primary deterrent to end-user adoption until more of these features are brought into the out-of-box experience.

Now, here are some of the gory details of my experiences so far:

• NTFS support: Very Difficult. Involves tweaks to PATH, downloading of SUNWonbld, install of Sun Studio 12 Express (with the package manager), more tweaks to PATH, compiling FUSE (kernel and library) from source, compiling pkg-config from source, then figuring out which disk devices correspond to the NTFS volumes you want to mount. Final Status: Takes a fair bit of patience and expertise, but works. Read support appears very stable; I’m afraid to try write support due to the early status of FUSE on OpenSolaris. I have seen reports of the write support causing lockups, but this may have been fixed recently. Under active development. Helpful link (with a chance for free tech support from a Sun employee!): OpenSolaris FUSE forums.
• Marvell Yukon PCI-Express GB Ethernet Driver: Doable, but inconvenient. A benefactor in the community, Masayuki Murayama, has released and actively updates device drivers for several ethernet chipsets that Solaris does not support out of the box. When these will be integrated into the out of the box experience remains unknown. Fortunately, the install process for these, once the files were transferred to the OpenSolaris machine using a FAT32 external hard drive, was very, very easy. Note that if your ethernet hardware is supported out of the box, then you are better off than I was.
• Skype: Likely unavailable for now. There is no native build of Skype for any Solaris; your alternatives are to tar up a Linux distro install and run it in a BrandZ container; or, attempt to run the Windows version of Skype using Wine. Since the latter is much simpler, I chose to download the Solaris builds of wine that are linked to from WineHQ: Wine for Solaris is here. The app starts, and the GUI appears correct. Chat works. But, as expected, sound doesn’t work. Also, after about 5 minutes of running idle, the app crashes. I think the built-in Sun audio system is the problem; it is likely unsupported under Wine. I should probably try to build the CDDL’ed version of OSS v4.1 RC for OpenSolaris and see if that works any better.
• Flash 10: Easy to install, easy to find, works flawlessly. Newbies might puzzle for a moment on where they need to place the plugin, but Adobe Labs has made available a Flash 10 beta for Solaris. Works great with Firefox 3.0.4, shipped with OSOL 2008.11. Compared to the above issues, this is cake. Youtube within 10 minutes of post-install is a nice feature.
• Adobe Reader 8: Available through emulation of the Adobe 8 for SPARC package. Earlier this year, Codeweavers ported Google Chrome to Linux using Wine, with a bundled custom version of Wine that runs it fairly well. Transitive, a cross-platform virtualization company, has now jumped on the Look What I Can Do bandwagon and now gives us an alternative to the preinstalled GNOME Evince PDF reader. This proprietary alternative may be capable of reading certain complex PDFs that are not rendered properly with Evince, though I have yet to find a PDF that doesn’t look great with Evince. Still, this is an interesting use of developer energy directed towards OpenSolaris x86 users.
• Wine: See above info for Skype. Installs and runs, but I have yet to get sound working on a Wine app; furthermore, installing the package maintainer’s strange .lzma archive requires compiling the open source LZMA extractor, just to get at the raw .pkg file beneath it.
• EXT2/EXT3 filesystem support: Available through ext2fuse, a package similar to ntfs-3g. The trials and tribulations of getting a working FUSE kernel/lib install far outweigh the difficulty of compiling this small package. If you have any ext2 volumes, this should suffice once you get it working.
• Linux Old Hand Learning Curve: Moderate to high. Much is familiar, and much is unfamiliar, if you’re coming to OpenSolaris with experience hacking on Linux. Informational tools are often named differently; even tools of the same program name have different options and behavior. The Sun CLI userland feels antiquated and very rudimentary compared to the well-documented and flexible GNU userland. Certain things behave as expected, such as directory navigation; some things have reasonably simple analogues that you can adapt to, such as disk device enumeration in /dev/dsk; some things are wildly different, such as the Sun package manager(s).
• 3d Graphics: Nvidia’s binary drivers are really the only semblance of modern OpenGL support. The Nvidia drivers have feature parity with the Linux equivalent, supporting OpenGL 2.1.2 and GLSL. Some work has been done to get the Mesa stack working in Solaris world, but so far I would say that you need to have an Nvidia graphics card, and you need to be willing to use the binary-only drivers; otherwise, prospects of 3d acceleration on OpenSolaris are very poor indeed.
• Multimedia: The situation is bad. Out of the box support for free formats is provided, via the gstreamer packages. However, any of the patent-encumbered formats, such as mp3 and aac, are not shipped. You can attempt to download these non-free codecs from Blastwave, but they are so old that they either do not work with your current gstreamer core, or they work but they’re intolerably slow. Seriously – some of that blastwave stuff is from 2003. It doesn’t seem to fit very well with some of the more recently-updated packages. Your only alternative is to re-build the entire multimedia stack from source, including external decoder libraries (of which there are about a dozen), and then rebuild gstreamer from scratch. This can be done with some minor workarounds and thorough knowledge of the software in question, but that’s well beyond a newbie’s capability. A newbie’s only hope might be to run a simple, well-integrated media player app under wine, after they get sound to work under wine. Either that, or only use free formats like theora and vorbis.
• Office: On par with Linux. OpenOffice runs flawlessly (of course) on the Solaris platform. You could even say that it’s fast - spiffy - a little bit more spit and polish than most Linux builds of OpenOffice.

In conclusion, OpenSolaris has many problems out of the box for the end-user, that can be fairly easily solved with some more attention by the distro maintainers. In general, free software packages out in the wild are either programmed with OpenSolaris quirks in mind; or, OpenSolaris’ userland is running out of quirks, so more and more Linux-targeted code can run unmodified. Either way, you can almost always grab a GNU tarball of the latest stable off of a GNU FTP mirror, and have few problems building it, except to meet dependency version requirements.

Should end-users jump on the OpenSolaris bandwagon today? No.

Should F/OSS supporters, enthusiasts and evangelists jump on the OpenSolaris bandwagon today? I think so. Try it. Realize that there’s a free alternative to Linux. If the corporate types manage to corrupt the spirit of Linux someday, we’ll need a backup to continue the F/OSS movement.

Should system hackers, curious UNIX heads, and sysadmins looking for a performance boost jump on the OpenSolaris bandwagon today? Absolutely. Not only will the OS be easy to use (or even fun to learn!) for this sort of person, but its features will be of great importance.

Good luck,

Sean

UPDATE: I tried to compile the latest OSS4/CDDL drivers, a 4.1 release candidate, for OpenSolaris. The compile succeeded, but loading the modules (oss_haudio in particular) causes a kernel panic. This is not entirely unexpected, however, because I get the same behavior when loading oss_hdaudio on a Linux kernel. I think in this case that OpenSolaris is not to blame, but rather, my Intel ICH10 based integrated sound card, which is quite new. I’m using the new Intel X58 motherboard chipset.

I might invest some spare time in trying the OSS4/CDDL release candidate again when it’s updated, but for now I am back to using GNU/Linux (Fedora 10, to be precise) with ALSA underneath. It supports my HD Audio very well.

Current vs. High-end. In short, this is a distinction between technology that is chronologically new to market – and thus supports the latest software facilities that programs rely on – and technology that is very capable compared to other hardware available at the time of its release.

So the degree to which hardware is “current” is only based on time. And the degree to which hardware is “high-end” is only based on how relatively powerful that hardware was when it first shipped.

These two axes are independent of one another because their basis is completely different. You can have old, high-end hardware, or you can have new, low-end hardware, and so on. I am going to apply these concepts to the arduous task of shopping for a new video card. I’m not doing this for myself, but as a guide to others who might be in the market for a new video card.

When shopping for a new video card, you have to answer one question along each of the axes. And you absolutely must go into this with a budget in mind, no matter how large or small it may be. Otherwise you can’t weigh reality against your needs.

First, ask how new are the games I want to play? When were they published? If you don’t game, but use other 3d applications, then the same question applies to those apps too. Almost without exception, new games will require many of the newest features of video cards. That means, to play new games, you need a current video card.

In general, you will need a video card that – at the time of the software’s release – was either the first, second, or third most-recent generation of video card from the vendor. The third generation cards are sometimes not supported, either, so choose wisely. For the sake of future-proofing your investment, I would never recommend that anyone buy a new video card older than the current second-generation, unless the price is extremely marked-down.

The second question to ask is, how high-end are the graphics being used in the game or app I want to use? Games these days are released with a broad spectrum of hardware expectations in terms of sheer texture fill rate. Texture fill rate is a general measure of how much complex scenery a video card can handle. Due to the natural evolution of technology, there is significant gain in fill rate on more current hardware, even the low-end stuff. But if the software you want to run is expecting the kind of fill rate you’d find on a $600 enthusiast video card, you can’t expect to buy a low-end video card that will play it with acceptable speed.

Similarly, there are some games that require only a small fill rate, but they require current hardware to support the game’s request for modern graphics APIs such as DirectX 10. Now for the tricky part. You have a vague idea of whether you need a low, mid or high-end card, and you know how current it needs to be. But now you have to size up your budget against the cost of a card to determine whether you can satisfy your needs under your current budget. If you can’t, you may find yourself going bargain hunting. But the financial optimization of purchases is a much more complex topic than I can cover here.

Now I will break into an overview of the top four graphics card manufacturers’ strengths and weaknesses, along with a “snapshot” of what their high-end, mid-grade and low-end video cards are today. This information should help you evaluate which vendor can best suit your requirements, as gathered above if you followed my post so far. The contenders are Nvidia, ATi (now a division of AMD), Intel, and S3. Other vendors out there might claim to manufacture 3d graphics cards, but I deliberately exclude them for their lack of competitiveness in the market.

But first, some terminology for the uninitiated:
Integrated: Often contrasted with discrete. Integrated means that the video “card” (i.e. the Graphics Processing Unit, GPU) is hard-wired to the motherboard, and can not be removed from it, nor upgraded. These are popular on laptops to save space and energy.
IGP: Integrated Graphics Processor. This is just an abbreviation for an integrated GPU.
Discrete: As opposed to integrated. A discrete graphics card is one that plugs into a slot on the motherboard. If you have discrete graphics, you can upgrade your video card later to a more powerful one (or run multiple video cards at once if your motherboard supports it). When upgrading, pay careful attention to the slots available on your motherboard, versus what slot is required for the card.
Texture memory: Very fast memory that is used to store graphics during 3d rendering. On some setups (IGPs), texture memory can be a piece of your main system memory that has been set aside for this purpose. All discrete cards have texture memory on the video card itself.
GDDR#: Graphics Double Data Rate RAM. The number after GDDR roughly translates to how quickly the GDDR can send and receive data. Higher numbers are much faster than lower numbers. GDDR is the modern terminology used to describe how fast and how much texture memory you have.
OpenGL, DirectX: Two different 3d graphics programming interfaces that software uses to interface with the GPU. These are always evolving to new versions that support more complex graphical operations; however, older hardware may be unable to support these newer revisions. That’s why maintaining a current GPU is important if you want to play 3d games.
Future-Proofing Guarantee (FPG): A term of my own invention that represents how long I think the specific video card in question will continue to work with newly released software. I always give a range for the FPG; the low number is the amount of time you can continue to use this card with the very latest high-end games; the high number is the amount of time this card will continue to work with new casual games.

Nvidia: The Evil Empire. Extreme performance, at all costs (even your paycheck).

• Market leader for mid-grade and high-end gaming. Trend-setter and forerunner.
• Both integrated and discrete GPUs using all the latest PCI-Express 2.0 technology.
• Gold-standard Windows drivers with comprehensive compatibility.
• Gold-standard Linux drivers with comprehensive OpenGL support, although their drivers are proprietary.
• They release each “generation” of video card as low-end, mid-grade, high-end, and enthusiast models for discrete GPUs. Less variety in the IGP product line, which targets casual gamers, composited desktops, and multimedia.
• All discrete chips have dedicated texture memory; currently ATi’s high-end cards have a slight edge in terms of memory bandwidth and capacity. Integrated chips may have dedicated memory or share system RAM, or both.
• All chips scale appreciably well to complex games; the low-end cards can run high-end games with detail settings turned down a bit.
• Decent value at the low end; rapidly decreasing value at the high-end. Their best cards cost way too much – a good $100 to $200 above the most expensive ATi.
• Power schmower! Ask your congressman to build you a new power plant; you’ll need it to run a discrete Nvidia GPU! Their integrated GPUs are among the most inefficient on the market, too, but recently they’ve started to compete in that regard.
• Nvidia makes motherboards, too, and it’s always a good idea to run an Nvidia GPU with either an Nvidia or Intel motherboard.
• No sane 3d application developer – games, high end computing, whatever – would dare release a product without extensive testing on the three most recent Nvidia series of GPUs. They’re the gold standard, after all.

For high-end gamers and enthusiasts, the GeForce 200 series is recommended. Unfortunately, Nvidia has yet to develop this generation into lower-end hardware. FPG is 2 - 4 years.

For gamers playing older 3d games or casual games, the GeForce 9 series is recommended. There is a lot of variety in this series of cards, so go with your price point. FPG is 1.5 - 3 years for the value cards; 2 - 4 years for the 9800 GX2.

If you don’t need all the latest features at all the latest expense, there are some affordable GeForce 8 series cards providing great gaming speeds. FPG is 0.5 - 1.5 years.

If you just want to run a game from 2004-2005 or earlier, and have no plans to play newer games, go with the GeForce 7 series. FPG is already expired; i.e., only future-proof for the next 6 months at most.

ATI/AMD: The New Republic. Good value all around, with competitive performance.

• In terms of market share, they’re a close second place for mid-grade and high-end gaming. Occasionally beats Nvidia to market with bragging-rights features (e.g., GDDR5, 1 TFlop.)
• Both integrated and discrete GPUs using all the latest PCI-Express 2.0 technology.
• Near-perfect Windows drivers with comprehensive compatibility for the latest DirectX.
• Quite good Linux drivers with comprehensive OpenGL support, although their drivers are proprietary. They have difficulty updating their drivers fast enough to keep up with the evolution of the Linux kernel and X server.
• They release each “generation” of video card as low-end, mid-grade, high-end, and enthusiast models for discrete GPUs; less variety in the IGP product line, which targets casual gamers, composited desktops, and multimedia.
• All discrete chips have dedicated texture memory; currently they have the best dedicated texture memory solutions available. Integrated chips may have dedicated memory or share system RAM, or both.
• All chips scale appreciably well to complex games; the low-end cards can run high-end games with detail settings turned down a bit.
• Very good value at the low end; decreasing value at the high-end. Their best cards are expensive, but cheaper than Nvidia.
• Power usage isn’t a big focus for ATi, because they are trying to keep up with Nvidia performance-wise, and power efficiencies often equate to performance drops.
• AMD makes motherboards and CPUs, too, and it’s always a good idea to run an ATi GPU with either an AMD or VIA motherboard.
• No sane 3d application developer – games, high end computing, whatever – would dare release software without extensive testing on recent ATi products, for risk of alienating many customers. The ATi user base is big enough that support for these GPUs is almost never neglected.

Cards with an “HD” in the model number came around the 2007-2008 timeframe. HD4x cards are pretty recent, and largely composed of enthusiast boards, with an FPG of 2 - 4 years. Luckily, the price of a current ATi video card can be very affordable compared to the price of a similar Nvidia card. You should be able to find an HD model GPU that is within your price range. This is one advantage ATi has over Nvidia: customers benefit from the innovation of their latest builds because ATi is more agile at paring down their enthusiast cards to the low-end range. Of course, FPG is negatively impacted by a low-end card, even if it’s current.

Intel: Just starting to realize that they’re in the graphics business.

• A modest market share overall; massive success at business-class integrated graphics.
• Current chips are only integrated (with discrete graphics planned for next year).
• Well-supported Windows drivers and good DirectX 9 compatibility, with some chips now supporting DirectX 10.
• Enthusiasts, Red Hat employees, and Intel employees make a coordinated effort at rapidly evolving the Linux graphics stack by developing open source drivers for Intel cards, while evolving the DRI framework at large. Their work benefits S3 and ATi customers too.
• No real sense of low-end or high-end within the Intel product line. Newer is better; only desktop and notebook variants of their GPUs exist. However, on the market at large, Intel chipsets appear at the entry level (low-end).
• These IGPs use system memory as texture memory, reducing available RAM for programs. However, the amount of RAM used can afford lots of texture memory to the IGP.
• GPU design does not scale well, as texture fill rates are modest.
• Intel IGPs sport outstanding value because the IGP is included with a motherboard or laptop purchase.
• Power usage of Intel IGPs is much lower than a comparable Nvidia or ATi product.
• Intel motherboards integrate Intel GPUs, opening the possibility for great optimizations.
• These cards are on the radar for most game developers, but moreso for casual games than high-end games. ATi and Nvidia are the market leaders, so no game developer would dare release a title incompatible with one of those; but they might also work in Intel support as an afterthought.

Go with the X3100 or, preferably, the X4500. Prior to that the cards weren’t really a contender at all for 3d gaming. FPG of 0 - 2 years.

S3 Graphics: The Unknown, the Unusual, the Underdog.

• Very small market share overall; niche market success at the ultra low-end.
• Current chips are either integrated, or discrete cards that need a modern PCI-Express x16 slot.
• Well-supported Windows drivers and outstanding DirectX 10 compatibility.
• A rapidly-growing community of enthusiasts on the Linux/Open Source front are making modern S3 chipsets usable on Linux for 3d.
• Cheapest chipsets target the ultra low-end market; slightly more expensive are the entry-level chips that actually compete with current low-end ATi/Nvidia products.
• Outstanding texture memory value for the price.
• GPU design does not scale well to extremely complex rendering environments, such as the Valve Source engine, or the Gamebryo engine (that’d be Half-Life 2, Oblivion, and Fallout 3, notably.))
• $49.99 price tag on the Chrome 530 GT undercuts ATi and Nvidia’s entry-level chips by a long shot.
• S3 claims to excel at power management. Less watts = lower electricity bill!
• Joint venture with VIA, an experienced motherboard manufacturer, leads to possible performance wins for S3/VIA combo.
• Barely, if at all, on the radar of game developers for QA/testing. Any hardware-dependent problems will probably go unanswered.

For S3 chip selection, just pick whatever their latest model is – their cards retail around $50 and have been pretty consistent in staying that way.

In Conclusion, here is how I sum up the current state of the market for these graphics card vendors:

Value (bang for buck): S3 and Intel are close on this one, but I’d have to call it in favor of S3, because their discrete graphics are more capable than Intel’s best IGPs, yet still extremely cheap. AMD is slightly more value-driven than Nvidia for those needing performance.

Performance: In general, Nvidia. AMD does have its moments where its offerings leapfrog Nvidia on some key performance metrics, but the “safe” bet is on Nvidia. Intel’s recent offerings pull ahead of S3 in terms of performance, but not by much.

Compatibility: Best bets are on Nvidia and ATi, a dead tie. Depending on the software APIs used, and the generation of video card, S3 and Intel may be better or worse in terms of compatibility. S3 compatibility may suffer due to S3’s low market share.

Market Share: S3, Intel, ATi, Nvidia – least to greatest. Not much else to say about that.

Power Consumption: Nvidia and ATi love to chew up power; Intel and S3 are more miserly about it.

Well-Testedness/QA Factor: Nvidia gets preferential treatment. ATi is a first-class citizen, but in line behind Nvidia. Intel and S3 are often ignored during development, and if they work, it’s by sheer luck.

Future-Proofness: Nvidia. Cards as old as the GeForce 6 Series – launched in 2004 – can still run the latest games. ATi cards do not fare quite as well, and older value-priced cards from Intel and S3 have no hope whatsoever after 2+ years of product age.

Stability: Dead tie. These are all professionally manufactured, high-reliability parts. Graphics cards have no moving parts, so their lifespan of stable use is quite long (10+ years). As long as you maintain a healthy software environment, there’s no reason that graphics hardware should cause any instability for you, unless you physically damage it.

If you are in the market for a video card, I would suggest that you choose among the above factors your most important item, and start from there. For example, if you value power consumption the most, you would want to look at an Intel or S3 chip.

I hope this has been helpful. Even if it’s not, I at least got to record a braindump of my thoughts on this matter for future reference