I needed a new laptop and decided I wanted a system that was as guaranteed as possible to run out of the box with all hardware components working with zero configuration hassle.
I went with System76 and ordered their Gazelle Professional 15.6" laptop. Their website is simple, but intuitive, and configuration was a breeze. My requirements were simple:
- It Just Works in Linux.
- 16GB or more of RAM
- Ordered with 2 drives
- Core i7
- 1080p
- 15.6" or smaller
- $1000, +\- 10%
Their RAM upgrade on their website was a bit pricey, so I opted for the minimum, a single 4GB DIMM and a matched pair of after market 2x8GB. Replacing the RAM was a snap, and I notice its a socketed and (for a laptop) easily replaceable CPU. I got 2x500GB Seagate 7200 RPM drives, with the nifty hybrid 4GB SSD on drive cache. Linux aggressively caches as much as it can in RAM, so the "on subsequent loads" for commonly used apps isn't as apparent, especially with the entire OS loaded on a RAID1. Hey, its a laptop, they are spindles, and I want redundancy over write speed. But reads are nice and quick.
I rebooted the OS a bunch of times, and by the sixth time the boot time had dropped from ~12 seconds down to ~7 seconds, so perhaps that was a good idea.
I also have a keyboard that doesn't have a Windows logo on the meta key!! Too bad its a sticker, and too bad its off center by a millimeter! But I don't look at it that often, but its still a bit annoying - just not annoying enough to send it back.
System76 themselves have been great - they open a support case with you that gives you the current information and status of your order - once the order has been processed, you then get a message when its being built, then a shipping number and S/N(s) of your product(s). Its a social-networking sort of support system, with avatars and such. It makes you feel like there is a real person handling your expensive new gear.
They ship with Ubuntu, but as I used Fedora for work and don't like the context switch of yum/apt and other stuff like that, I reinstalled and had zero problems with any devices. The laptop is very fast, and indeed, everything works Out Of The Box. HDMI with audio passthrough worked with zero configuration, other than having to enable the HDMI profile in KDE (a GUI only feat, nice!)
Blue tooth had a weird setting in the BIOS and was disabled, but once that was enabled it worked just fine. All the OSD animations for volume and brightness and such work great. Standby works as well, and all wireless devices seem to resume their sessions on wakeup.
Things I don't like:
- limited accessories selection, lack of international power adapters, lack of 9 cell battery
- off-center Ubuntu logo
- The touchpad - Ok this is a a toss-up. It doesn't have any vertical physical presence indicators - its smooth and hard to know when you've reached the edge of the pad, but otherwise it works fine and I do like it visually.
- Heat under the left palm - its not too awful, and I have a laptop chiller.
- Lack of sensors (or lack of support in lmsensors) - haven't investigated too far, but I simply have CPU temperatures and no voltages/fans or anything else.
- lack of choice for illuminated keyboard - I'd pay extra for this as well!
- lack of choice for nvidia/ati discreet adaptors. I'm guessing this is either due to their suppliers lack of models, or the lack of good support for that switchable technology all the new chipsets use.
Hopefully the graphics situation will be remedied by the next time I purchase a laptop, I didn't want an Nvidia or ATI solution this time. An intel 4000 series graphics experience is enough for me. It played a 1080p movie beautifully and only showed some vertical slashing, and 99% of my time will be spent programming and office work, with movies and music sprinkled here and there.
But even these things negative aren't enough to stop me from really liking this laptop - its lightning fast, has a better display than even my last Macbook (early 2011), has no Windows Logo, has a support forums on the official Ubuntu Forums, is easily upgradeable and workable, and I'm supporting a company that doesn't seem to act like every other hardware vendor.
Tuesday, August 28, 2012
Monday, August 20, 2012
Cloud Management
I've been creating a cloud management and automation utility during the daylight hours the last couple of months. I'm using Mojolicious to manage the REST routes and UI, and some custom backend Perl apps and modules to manage the vcloud, spacewalk and other APIs.
I chose not to use any existing Vcloud perl modules as none of them were v1.5 compatible. I was seeing some slowness in the v1.0 compatibility calls, and I found that >50% of the API calls I wanted weren't coded up anyway and I was having to parse more XML than I wanted to with someone elses module that I didn't feel like modifying. VMWare, why did you stop making your SDKs for your new projects in perl? :(
I chose Mojolicious as the framework for the REST interface because the last time I did any web development in perl, CGI::Application was the tool of choice and I was automating system information gathering and IT-like functions, back in the early 00's. REST is all the rage these days and a long-polling API call with a 20 second wait in the browser without feedback just doesn't work anymore.
I looked at Dancer and Catalyst and both are similar in spirit, but Mojo just seemed more intuitive. I have a complete toolkit of everything webby that I need. I do wish some of the eccentricities were better documented, but they are easy enough to pick up, and many are just because I've never used a modern web framework before. I've had a couple of questions and the mailing list and bug tracking folk are friendly and quick to respond, another bonus.
I'm using various other tried-and-true CPAN modules for the Controller and Agent pieces, and MongoDB for the database. I had no choice in the cloud software or package management.
The REST framework authenticates a user and builds, loads, and configures apps, which consist of multiple machines running dozens of customized RPMs, each requiring dozens of steps to configure. Its a non trivial app, and the cloud management was the easy part.
Most modern Cloud Management Suites have similar designs for a reason:
- A Cloud, basically a virtual cluster with some sort of framework for creating/deleting/manipulating VMs and networks.
- A Package Manager - this could be "app libraries", or RPMs, or some other deployable code.
- A Controller, some sort of Master Planner that takes tasks and translates them into action. Some actions it will need to have might be:
- queries the APIs at certain intervals to populate a DB
- create vms with some network and some resources and put some pkg on them and configure with XML
- reset and reload a vm
- update a vm with the latest pkg
- A Database, something that can store the information about the various infrastructure and VM pieces.
- A Front end, where the end users can feed actions to the Controller
- An Agent, a Pub/Sub client commando which resides on your various VM/and maybe infrastructure pieces that collects running data and feeds back commands to the VM from the controller and logs its actions. (commands might be restart app, update app, etc)
To get off the ground quickly, I started with Mojolicious and built REST calls and used templates for GUI interaction and javascript for ajax fun to keep long page load times down on long polls to the various APIs. No database or agent, just straight queries against everything. This was a quick way to get everything off the ground quickly and define the process and I'm glad I did it this way. I'll followup with more posts on the rest of the design choices and its evolution from there.
I chose not to use any existing Vcloud perl modules as none of them were v1.5 compatible. I was seeing some slowness in the v1.0 compatibility calls, and I found that >50% of the API calls I wanted weren't coded up anyway and I was having to parse more XML than I wanted to with someone elses module that I didn't feel like modifying. VMWare, why did you stop making your SDKs for your new projects in perl? :(
I chose Mojolicious as the framework for the REST interface because the last time I did any web development in perl, CGI::Application was the tool of choice and I was automating system information gathering and IT-like functions, back in the early 00's. REST is all the rage these days and a long-polling API call with a 20 second wait in the browser without feedback just doesn't work anymore.
I looked at Dancer and Catalyst and both are similar in spirit, but Mojo just seemed more intuitive. I have a complete toolkit of everything webby that I need. I do wish some of the eccentricities were better documented, but they are easy enough to pick up, and many are just because I've never used a modern web framework before. I've had a couple of questions and the mailing list and bug tracking folk are friendly and quick to respond, another bonus.
I'm using various other tried-and-true CPAN modules for the Controller and Agent pieces, and MongoDB for the database. I had no choice in the cloud software or package management.
The REST framework authenticates a user and builds, loads, and configures apps, which consist of multiple machines running dozens of customized RPMs, each requiring dozens of steps to configure. Its a non trivial app, and the cloud management was the easy part.
Most modern Cloud Management Suites have similar designs for a reason:
- A Cloud, basically a virtual cluster with some sort of framework for creating/deleting/manipulating VMs and networks.
- A Package Manager - this could be "app libraries", or RPMs, or some other deployable code.
- A Controller, some sort of Master Planner that takes tasks and translates them into action. Some actions it will need to have might be:
- queries the APIs at certain intervals to populate a DB
- create vms with some network and some resources and put some pkg on them and configure with XML
- reset and reload a vm
- update a vm with the latest pkg
- A Database, something that can store the information about the various infrastructure and VM pieces.
- A Front end, where the end users can feed actions to the Controller
- An Agent, a Pub/Sub client commando which resides on your various VM/and maybe infrastructure pieces that collects running data and feeds back commands to the VM from the controller and logs its actions. (commands might be restart app, update app, etc)
To get off the ground quickly, I started with Mojolicious and built REST calls and used templates for GUI interaction and javascript for ajax fun to keep long page load times down on long polls to the various APIs. No database or agent, just straight queries against everything. This was a quick way to get everything off the ground quickly and define the process and I'm glad I did it this way. I'll followup with more posts on the rest of the design choices and its evolution from there.
Thursday, August 9, 2012
Why Doctor Who beats Back To The Future
If Doc Brown had gone back to 1885 and sent Marty a letter in 1955, and Mmarty had shown it to the young Doc Brown in 1955, then the old Doc Brown from 1985 that is living in 1885 would have remembered having sent Marty that letter and known that he got it, and if he had known that he got it, he could have then changed his choices so as to not be sitting in the stupid DeLorean when it got struck by lightning, or at least would have parked it, which would have allowed him to change the past and the present and the future at the same time.
As it is the doctor from 1885 is shocked that Marty shows up, when in reality he should remember Marty having received the letter in 1955 when Doc Brown was 30 years younger. He remembers to wear a silly bullet proof vest against the Libyans, why not that?
Of course, when the fuel line got hit they could have just siphoned the rest of the gas off the DeLorean that Doc Brown had shoved in a cave, and then he could have written a note that said "You'll need a new fuel line and some more gas, sorry".
But if I'm going there, then a half-dozen intergrated circuits that look like microcontrollers *could not* be replaced by a dozen vacuum tubes and some weird wires.
Also, if they had left the almanac in 1955 and Biff got rich, then as soon as they zapped into the future they both would have ceased to exist. His girlfriend Jennifer had "the world shift around her and she woke up in the morning in normal 1985 as if nothing had happened". What???
See in Doctor Who's land he would have known he was going to send himself the letter and done it anyway and all these things would suddenly fall into place and they'd have to get the girlfriend and take her in the time machine back to the real timeline or she would probably be in serious timey-wimey trouble.
Yes, these are the things I think about when waiting for a computer thing to finish.
As it is the doctor from 1885 is shocked that Marty shows up, when in reality he should remember Marty having received the letter in 1955 when Doc Brown was 30 years younger. He remembers to wear a silly bullet proof vest against the Libyans, why not that?
Of course, when the fuel line got hit they could have just siphoned the rest of the gas off the DeLorean that Doc Brown had shoved in a cave, and then he could have written a note that said "You'll need a new fuel line and some more gas, sorry".
But if I'm going there, then a half-dozen intergrated circuits that look like microcontrollers *could not* be replaced by a dozen vacuum tubes and some weird wires.
Also, if they had left the almanac in 1955 and Biff got rich, then as soon as they zapped into the future they both would have ceased to exist. His girlfriend Jennifer had "the world shift around her and she woke up in the morning in normal 1985 as if nothing had happened". What???
See in Doctor Who's land he would have known he was going to send himself the letter and done it anyway and all these things would suddenly fall into place and they'd have to get the girlfriend and take her in the time machine back to the real timeline or she would probably be in serious timey-wimey trouble.
Yes, these are the things I think about when waiting for a computer thing to finish.
Subscribe to:
Posts (Atom)