Saturday, October 20, 2012

Chromium

I like Google Chrome because it's fast, and it comes from my favorite Web search company. However, for whatever reason, the prebuilt packages from Google and Debian have rendering problems on my system. Maybe it's the amount of other messing around that I have done throughout the system which is somehow knocking the widget offsets out of whack. In any case, it looks awful, and is often unusable.

The solution to this is to download Chromium, the open-source version of Chrome, and build it. This ensures that the headers used to build the program correspond to the specific versions of software on my system, which helps to ensure compatibility. It works great now, but, as usual, there is always one obscure glitch which causes me to waste most of an entire day on an otherwise simple project.

As it turns out, Chromium has a stubbornly recurring bug which will probably crop up periodically forever because of the way Chrome's sandboxing is done under Linux. Basically, it immediately performs a system call which disables almost all further system calls from the sandbox process. This contributes to security by greatly limiting the sandbox process' acccess. However, every now and then, a forbidden call will somehow work its way in during development or building. In my case, this causes the browser to crash instantly on all pages, including all of the status and config pages.

The correct™ way to fix this would be to weed out the offending call. I'm way too lazy to do that, and prefer to simply disable that particular layer of the sandbox using "--disable-seccomp-filter-sandbox". Because it's a security-related thing, this probably explains why I had to go to so much trouble to find the answer. Really, though, since this feature isn't even available under Windows, I'm not going to worry about it.

Friday, October 19, 2012

Serious question

For everyone who reads my blog, which I know totals to roughly one person, counting myself. Is there something wrong with me if I have to compare Chief Miles O'Brien and Piers Morgan side by side in order to tell them apart? Even then, I have to rely mostly on age difference to tell them apart. Maybe the nose and chin are slightly different. Seriously, for the longest time, I thought that Colm Meaney had diversified his career into talkshow and reality TV hosting until I realized that they are two completely different people.

Wednesday, October 17, 2012

ALSA Sound System

Currently, ALSA is the standard Linux sound system. I'm not sure how I feel about it. On one hand, it works and it's highly configurable. On the other hand, its configuration system is a labyrinth of semidocumented hacks on top of hacks, which would probably have been better implemented using a real scripting language like Lua, or bash for that matter. It seems intuitive enough at first glance, such that you might mistake it for a list of assignments within a simple object-oriented property graph. But as soon as you try to use it, you will be instantly bewildered by all of the seemingly intuitive things that will simply not work, or which mean something other than what you think. Even after writing the configuration file for my system, I still don't fully understand exactly what the commands do. As far as I can tell, you are assigning strings to key values. Sometimes those strings are references, by name, to other configuration blocks. Sometimes those strings are themselves inlined configuration blocks. Sometimes one will work, but not the other. It's ridiculously confusing, and if it's going to be this difficult to use, then someone needs to write a configuration front-end, because this was like reverse-engineering a primitive programming language that I am probably only ever going to use once.

So, with the complaining out of the way, here is why I needed a custom configuration file. I have a Soundblaster X-Fi. The trouble is that the way this card is intended to be used, is via its six analog outputs, which are usually lauded by reviewers as an excellent value for consumer-grade D/A devices. Unfortunately, my Surround receiver doesn't have analog inputs, so I have to use SPDIF. SPDIF is digital two-channel sound and, as far as I know, the X-Fi does not do hardware encoding. This script, when dropped in /etc, configures ALSA to provide an "a52" device, which provides a filter stack which performs the requisite on-the-fly encoding. Applications see a stereo output but it is upmixed to 5.1 and then encoded into two channels, suitable for a Surround receiver to decode back to 5.1. When I get around to it, I will add another device that encodes 5.1 to SPDIF directly without upmixing. The configuration file is here.

More Desktop

Now I remember what I disliked about xfce. I had a problem saving (or restoring?) my session state between logins. I don't know what caused that, but this time around the problem is gone and I really like xfce. My only complaint is that there is no generalized drag-and-drop for menu and taskbar customization. Everything else is great.

Better yet, the xfce window manager can be switched out for Compiz. Compiz has a reputation for bloat, but I suspect that's only if you enable a bazillion useless bling plugins. With basic settings in place, I find that desktop response is even faster, because now the windows are being rendered in hardware, offloading work from the CPU. Dragging windows around the desktop is glassy-smooth, unlike in fluxbox, or some other 2D WM. I don't consider transparency a useless vanity item. I think it's really handy to be able to see through all of your non-focused windows because even though you might not be able to see them clearly, you can still see where they are relative to each other, and you can spot updates and changes in processes you might have running in the background.

There's probably some stuff in Compiz that looks neat but isn't strictly useful, and those things can be ok, so long as they are related to momentary things, like workspace switching and so on. If there's a feature that causes all of my windows to be continuously rendered as if they are on fire, or something, I can do without that.

Next up, I want to enable display management with fast session and user-switching, but I would rather do it without loading the entirety of the GNOME Desktop environment.

Desktop

Well, now that my disk storage fiasco has finally come to a close, I'm back to thinking about my desktop environment. I've decided against gnome because it's bloated and the file manager is possibly buggy. KDE is an extremely sharp-looking feature-rich environment, but it is insanely bloated, well beyond gnome. It leaves various Python instances running in the background, which take up tons of memory. Python is fine for transient processes such as configuration scripts, but not for something that is going to stay memory resident or run in the background.

fluxbox is lean, with a good feature set, but it's kind of annoying that all of the configuration is in text files. It occurs to me that I should probably be blogging more because I can't remember what I disliked about xfce, but I'm sure it was something. lxde, also, was alright. I want to dig around in fluxbox for a while and make sure I've given it a due chance because I like its simplicity. I want a setup that allows me to group like programs in the taskbar and maybe drag like windows into each other for tabbing. Eyecandy isn't a big factor with me, but I do like the idea of some practical transparency so that you can see through windows when positioning them.

Monday, October 8, 2012

Current events

The economy appears to be in dire straits indeed, as one of our senators has presented his initiative to exploit the nation's untapped livestock resources in his proposal to kill and eat Muppets. It's really not since the CDC's acknowledgement of the ongoing zombie threat that a government initiative has been so relevant. Politics are inherently surreal and disturbing, and it's good to see that someone is confronting the real issues head-on.

My only question is: who is going to regulate the production of muppet byproducts, and where is the USDA on this? In related news, I wanted to note my approval of the President's beer initiative. Nothing says "Everyone calm down and have a beer" like building a brewery in the White House basement. I hope that this is what they mean by "progressivism". I'm not in favor of more controls or more taxes, but the government certainly needs more beer.

Saturday, October 6, 2012

Sometimes...

I think I should find a nice girl and move out to the country. Or to another planet.

Friday, October 5, 2012

An open letter to hoteliers

If you wouldn't decorate your bathtub with seashells, then don't decorate your public pool with them either. If you would decorate your bathtub with seashells, then you're an idiot. With a lot of medical bills.

Thursday, October 4, 2012

Ok. It only gets worse. How in the world did we manage to land a rover on mars when we can't even write a correct manual for a desktop computer? I shouldn't have to take a scanning electron microscope to every piece of equipment I buy just to figure out how to use it. Nonetheless, look at this. If we go to Intel for specs on the X58 chipset, we get this. Ok. PCIE 2. Great! So, now let's click "Compare chipset components" for further details. "PCI Express Revision 1.1". What the hell, seriously? So, which one is it? More puzzlingly, how is it that the same group of people who built a machine that performs billions of mathematical calculations per second is unable to consistently distinguish between two two-digit numbers when it comes to writing the very literature on which the sale of their product depends? The dichotomy makes my head spin.

So, now let's click on the link for "product brief". Look! A block diagram. Those are usually quite illuminating. We see PCI V2.0 from the X58 and "500 MB/s each x1" for the ICH 10. 500MB/s/lane corresponds to 6Gb/s/lane, which requires PCIE V2.0 on the ICH10, so great! PCIE V2.0 all around! So, what do I have to do to enable it? The mystery continues.

Well, this is irritating. So, I ordered a RAID controller card for my SSD drive thinking that it would enable the full throughput of the drive because the on-board SATA controller on the Dell MT435 XPS is only SATA v2 at 3Gbps, or half of what I need. So, my RocketRaid 620 card promptly arrives, and I throw it in the machine, and I find that despite the SATA link being v3 at 6Gbps, my throughput has nonetheless dropped from roughly 0.25GB to 0.18GB. So, I try all manner of sensible things to get it to come up. I build and install the OEM drivers from HighPoint. No improvement. I flash my RAID controller BIOS, which disappointingly provides an enhanced config menu at the cost of AHCI support (what?). It seems like a downgrade, if anything. I install the RAID management program. I assign the SSD to a 1-disk "array", in case RAID-mode is faster. Still no improvement. So, I begin reading up on my system specifications to ensure that my system supports PCIE 2, which one would hope, since the machine was sold almost two years after the publication of the standard.

One would expect that the answer to such a basic hardware question would be readily available, and one would be completely wrong. Why? Because, once again, the marketing department's whims thoroughly triumph over common sense. Ride along with me on this completely fruitless and stupid journey. Our first stop is Dell's support site at support.dell.com. Typically, when we need specs on a piece of hardware, we look in the manual, where hardware specs belong. Let's see. We have 1 PCIEx16 slot, and 3 PCIx1 slots. Great. The multiplier tells us how many channels or "lanes" are provided by each slot, but we still need to know the PCIE version because our expansion board is x1 and I'm not going to swap out my x16 video card anyway. At any rate, we still don't know whether the slots are v1 or v2, and nowhere in any of the manuals does it specify.

Well, since we aren't getting any help from the manufacturer at the product level, we can "drill down", as they say in the corporate world, to the component level and look for assistance there. So, I look up the parts list for my machine, in search of the motherboard model number, and I get gibberish like this:


N575K      QTY 0         SERVICE CHARGE..., HYPERTEXT MARKUP LANGUAGE...,
                         INTEL..., LAN ON MOTHERBOARD..., 435MT

I interpret this to mean that I was assessed a service fee for a zero-quantity of part number N575 which consisted of HTML, an Intel something-or-other, and integrated ethernet. That makes perfect sense, or whatever is the complete opposite. Nevertheless, by searching for all occurrences of the word "motherboard", I was able to find the one line item which actually does refer to the motherboard, and I determined that the part number is R843J. This is great! Maybe now I can finally get some support. Not to make a long story even longer, this is the "specs" page for the motherboard in question. It does not help. At all.

So, having completely struck out on support from the manufacturer at both the product and component levels, we can begin digging after subcomponents in the hopes of answering the timeless riddle of what type of PCIE support I have. Cursory Googling does not provide any direct answer, but it does reveal that the system board uses the X58 and ICH10R chipsets, which are roughly analogous to a north and south bridge on older machines. We can go to Intel for specs on these and behold, wonder of wonders, a manufacturer who actually bothers to document their products. This is expected, since Intel is perhaps the lead developer of the PC architecture, and they would not maintain that status if nobody could locate or make sense of their documentation.

Homestretch? No way. As it turns out, in a strange twist, both chipsets suport PCI Express. The X58 does v2, and the ICH10R does v1.1. So the question becomes: to which chipset is each slot connected? That would have been a question for the motherboard manufacturer, whom I would at this point describe as having achieved a depth of inefficacy so deeply nested as to constitute a fractal of pure fail.

Now I'm convinced that not even Dell knows which slots on the XPS 435MT support PCIE 2.0. So, let's ask Linux. We can do lspci -t, which gives:

...
 \-[0000:00]-+-00.0
             +-01.0-[07]--
             +-03.0-[06]--
             +-07.0-[05]--+-00.0
             |            \-00.1
             +-14.0
             +-14.1
             +-14.2
             +-14.3
             +-19.0
             +-1a.0
             +-1a.1
             +-1a.2
             +-1a.7
             +-1c.0-[04]--
             +-1c.3-[03]--+-00.0
             |            \-00.1
             +-1c.4-[02]----00.0
             +-1d.0
             +-1d.1
             +-1d.2
             +-1d.7
             +-1e.0-[01]--
             +-1f.0
             +-1f.2
             \-1f.3

Using the ouput of lspci -vvv for further reference, we know that [03] is the RAID controller, and it is connected to function 3 of slot 1c, the info of which looks like this:
0000:00:1c.3 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 4 (prog-if 00 [Normal decode])
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
 I/O behind bridge: 0000c000-0000dfff
 Memory behind bridge: fbd00000-fbdfffff
 Prefetchable memory behind bridge: 00000000c0400000-00000000c05fffff
 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
 BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
 Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
   ExtTag- RBE+ FLReset-
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
   MaxPayload 128 bytes, MaxReadReq 128 bytes
  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
  LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
   ClockPM- Surprise- LLActRep+ BwNot-
  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
   Slot #0, PowerLimit 10.000W; Interlock- NoCompl-
  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
   Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
   Changed: MRL- PresDet+ LinkState+
  RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
  RootCap: CRSVisible-
  RootSta: PME ReqID 0000, PMEStatus- PMEPending-
 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
  Address: feeff00c  Data: 4171
 Capabilities: [90] Subsystem: Dell Device 02c9
 Capabilities: [a0] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [100 v1] Virtual Channel
  Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
  Arb: Fixed+ WRR32- WRR64- WRR128-
  Ctrl: ArbSelect=Fixed
  Status: InProgress-
  VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
   Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
   Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
   Status: NegoPending- InProgress-
 Capabilities: [180 v1] Root Complex Link
  Desc: PortNumber=04 ComponentID=00 EltType=Config
  Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
   Addr: 00000000fed1c000
 Kernel driver in use: pcieport
Right away, we can see that this makes much more sense than a Dell parts list. We have a PCIE v1.0 slot which is capped at 2.5Gbps. Well, this sucks. However, I'm still not done. Because when we go back and look at the bus tree, we see that bus 5 is connected to bus 7, and I happen to know that 5 is my PCI v2x16 video card which does operate at 5Gbps/lane. It has neighbors in the tree which are empty, so maybe there is still some slim chance that the drive controller's slot can be routed to the X58 interface, though it seems unlikely. It seems similarly unlikely that someone would have routed PCI slots around an available fast interface to a slow one, but I've yet to figure out if that's what has actually happened, but I think the primary takeaway from this, as the business school kids say, is that crappy documentation wastes time.