28 June, 2015

h3x - upgrade part II

Upgrade-time! :) ...and this time h3x is undergoing a complete cabinet+gfx upgrade. From a rather minimalistic HTPC starter-cabinet, into a completely new 2-sectioned, airflow-designed multi-cabinet :)

Fractal Design Node 804 cabinet
Corsair CX600 PSU
3 x Corsair SP120 "Quiet Ed" fans
My new XFX Radeon R9 270X 2GB GDDR5:
1xHDMI - 2xDVI-D - 2xDP

Disassembly


Silverstone MILO (ML03) when first built (nov'2011)
Silverstone MILO (ML03) disassembled.
The above picture shows my old HTPC cabinet after being almost completely stripped. Only things still left inside are the system-SSD (Corsair ForceGT) and the 400W PSU (Silver Power).

I did not foresee how hard it would be to dismantle the MILO HTPC mATX-cabinet, everything was so close together that it made it near impossible to figure out where to start off.

After viewing it from different angles, and bringing in a fresh set of eyes; everything got pulled out eventually

Then, the time to re-mount everything again came around.

Re-assembly


  • First: the PSU.
Right side.
Back-right profile.
  • Then; motherboard + RAM + CPU.
Front-left profile.
Left side.
  • And to finish it off: graphics-accelerator + HDD + SSD.

Left side: Component-compartment.
Right side: Storage- / power-compartment.

I now have a overhauled gaming-rig / workstation / hypervisor with 3-4x more graphics-processing power than I previously had :P and it WILL get tested ;)

I opted to using the 3 Corsair SP120 fans in the front, to complement the total airflow going through the cabinet. So that's a total of 4 fans in the front for intake and 2 in the back for exhaust.



08 June, 2015

"Unix is not an acceptable Unix"

This article really grinds my gears. The author tries to discount the use of command line interfaces by saying it is an obsolete interface-technology (mostly reserved for developers and advanced system administrators).

Pontificating that modern Unices (like Mac OS X and Linux) suffer at exactly the same areas of complexity because of their Unix-heritage. Well, I call bullshit...

  • Linux does not have a Unix-heritage, because it does not contain any UNIX®-code.
  • Computer complexity is really a catch-22 scenario; every time you modify something low-level, something may break on a lower level. Keeping this complexity usable at varying levels is a master-class balancing-act, and not to be taken lightly.
Yes, the Unix-philosophy states that every program should: do one job, and: do it well. And to some extent, Linux has done just that. BUT, since we're operating in a so-called "open-source community", where everyone has the right to shout out concerns, fixes and feature-improvements, the so-called "bloating" of CLI-programs are a direct result of this fundamental right to speech, re-use and community involvement. Which in itself is beneficial to everyone using the software.

The reason why lower-level programs use much the same functionality as was used in the original UNIX®, is because the programming language in question (C) has few alternative methods of performing low-level calls to the hardware, and thus is forced to do certain things in specific ways. Having these low-level functions available at any time for whichever program needs them is fundamental to a POSIX-system. And re-using these functions to build / extend programs is the way it's always been done

I can agree with his point about re-creating and duplicating core-functions in a program if the program already facilitates the components needed to do a specific task, it's unnecessary. But I can see the other side of this matter as well, from a developer-viewpoint. If you spent a lot of time (multiple iterations) developing and extending an already-implemented function, (just) to get specific results presented in a specific manner, wouldn't you want to include it in the program so you wouldn't have to re-implement it further down the line if ever needed again? And does it really affect normal users what kind of extra filters and/or flags a program accepts from the command-line? Not really...

Back in the day (70s and 80s), this was the only way of specifying arguments to programs in a sequential fashion, and to some extent still is. Hardware works on the principals of sequential data-flow and execution, and unless we do something drastic to the hardware-platform we are all using, this is the way it will continue to be used in low-level terms (C+asm) until we do.

Until we see newer and better ideas concerning the data-bus / CPU inter-connection, we will not be able to implement any innovative interface-functionality on a low level.

My point is this: CLI is not meant for normal users. It is not intended to simplify computing, rather, it was intended for developmental and operational purposes, created by the very same type of people who use it on a daily basis.

If you want ease-of-use and simplicity, use Apple or Microsoft, and supplement that usage by providing user-feedback to them for new features / functions and fixes. Don't just crap on the alternative(s) because "it doesn't conform to my unique idea of what user-friendliness is". Linux was never made to be user-friendly. Derivatives were made to suit that scenario, so use them, instead of slagging on about the lacking user-friendliness and simplicity of the OS itself.

To quote one of the best sayings I have ever read:
"Unix is very simple, it just needs a genious to understand it's simplicity" --Dennis M. Ritchie