A disappointing journey in the laptop industry

update as if everything I've written and experienced wasn't already disappointing enough, this security hole caused by this nonsense software installed by Lenovo to "help us", should give you an indication of how badly are ingenuous Laptop customers treated these days. But please, find out even more problems in this blog-post!

---

When I've left all big, cuddling, lovely, companies that gave me a MacBook Air/Pro for the last 6 years, I couldn't believe how difficult would have been to replace such important part of my daily life.
This is the story of a "once technical assistant at the Computer Shop behind the corner" person that, 18 years later, miserably failed at persecuting his ideals trying to go full Open Source.

Why I wanted an Apple alternative!

The "just work" company disappointed me so much with Yosemite I didn't want to waste my money there. I have the latest Mac Mini with the latest software in, and I've bought it after my good older Mac Mini became utterly slow behind some free OS update.
Guess what, this latest Mac Mini with best CPU and max amount of RAM already works quite slow and I haven't even installed much software in it.
I use stock OSX iTunes, Safari, everything that was already installed and Spotify that does not even start automatically, and I have the feeling it's slow! When you spend some money for "the latest, the greatest", that's not exactly the feeling you'd expect, right?
I also don't like much iTunes or the Apple store, way too close systems that together with most of the rest of OSX does not give me the feeling I am helping, improving, using, or contributing, to what I love the most and do daily: Open Source!
Will I keep using the MacMini? Yes, when I need to test stuff on OSX or as entertainment "box" (it hurts me calling it like that, it could be much more), but it's not portable and it does not give me the freedom I am looking for with everything else.

Hence the problem(s) ...

The list of well known, and unexpected things, I've discovered last month of my life were unthinkable 18 years ago. Where is all this going and why?
You might think this post is about suggesting to boycott everything that is not Open Source, you'll actually realize that who's actually boycotting the Open Source community is the industry itself, with all its caveats, locks, and constrains, that the industry itself created: keep reading if you are still here!

They don't give you a Zero OS option

This is the very first problem I've encountered: there is no such option as let me buy this laptop without a pre-installed Operating System.
The result is that you have to pay Windows licenses, it's included in the price!
And when the price is that low, is not because the OS license got cheaper, the new hardware you choose is crappier than others, and you are paying $50 extra for that license anyway.
OK, to be fair, sometimes you have the option to give the license back and being refunded ... now how much pointless bureaucracy this procedure adds is not the problem; the problem is that the moment you sign-up for such option you basically give up any sort of warranty about your machine.
They are unable to provide assistance to non Windows OS, there's no Help Desk worth or specialized enough behind laptops, you are on your own ... with your problems, and I'll tell you all of them pretty soon!

Locked up BIOS

This was one of the biggest surprise from those days where building up your own Desktop PC was all about changing and upgrading your underlying system so that you didn't have to buy another PC from scratch, you could simply change a component and be good to go.
Not anymore ... let's see what happened here, shall we?

what's wrong in the laptop industry? Fu#$Ing locked bios so that Intel +Intel = no. I regret I've bought this Lenovo. pic.twitter.com/PIq8EEWW4z

— Andrea Giammarchi (@WebReflection) February 17, 2015

My Lenovo Yoga 3 Pro, the laptop I've mistakenly chosen as daily buddy for my work, is telling me that the Intel Dual Band Wireless AC 7265 card I've bought due problems with the bundled, closed-source, BROADCOM wi-fi Bluetooth module crap, is unauthorized.
Basically, Lenovo used a BIOS that locked its own component up so that I cannot upgrade for good. Unauthorized? What does it mean, not compatible or something?

[webreflection@Lenovo-Yoga-Pro ~]$ lspci
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 08)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 08)
00:04.0 Signal processing controller: Intel Corporation Broadwell-U Camarillo Device (rev 08)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP Thermal Management Controller (rev 03)
01:00.0 Network controller: Broadcom Corporation BCM4352 802.11ac Wireless Network Adapter (rev 03)

Above is the list of components my Open Source OS uses to work, these are all Intel but the last line: Broadcom
That Broadcom controller has no Open Source drivers, and when I've found myself (together with many others) few days ago unable to use my laptop, I've instantly bought the Intel wifi replacement.
It's natively supported by my kernel and OS but my laptop BIOS decided to not authorize it, whatever the f#£k that means!

Not only Lenovo

Bear in mind that this is not Lenovo only, the MeegoPad T01 PC Stick, as example, has the worst from both worlds: you cannot easily put linux on it, due hybrid EFI 32bit boot VS 64bit system which has still many issues, and a preinstalled Windows you don't pay until it expires: it's sold unlicensed, meaning you are screwed when that evaluation time will go.
Avoid that product, if you want my advice, the MinnowBoard MAX is a way nicer device for all your experiments and it's not bound to any OS and its bios is upgradable via console (also EFI64 compatible!).

Locked Upgrades

This is the other screwed up part: if you don't have Windows, you cannot update your BIOS.

That, my dear reader, is a clear "you MUST use Windows or you cannot update what you bought" message, and I won't be able anymore in my life to update the bios of this piece of crap that does not let me install an Intel thing in a 99% Intel system.

Drivers

It does not matter if you even read an Open Hardware symbol in your dev board, that does not mean what you think it does.

Above symbol means that schematics of your boards and info/names about components it uses, are freely available. This does not mean Open Source drivers, which is usually the very first big mistake everyone does in the industry, this means that if you are a Chinese factory maybe you can reproduce such board, if you're allowed of doing so.
Drivers are the main problem in Open Source OS and development, these are most of the time clsoed source. Your Mali GPU in your Open Source phone is goddamn closed source, and your Raspberry PI has a VideoCore GPU driver that is half closed source too and my bloody Broadcom WiFi module also has a bloody hybrid driver that is half closed source!
I don't want to deal with any of this anymore because if Intel can have Open Source drivers for basically every-fucking-thing it produces out there, so could every other company in this world. What's the secret behind? Why we cannot have good reliablity and performance in OS world too?
Why is that, since most of these same companies develop their own stuff in Open Source environments? I don't understand!

So here a quick rule of tumb: is that an Intel thing? Full intel thing? Go for it!

Otherwise be sure you've spent weeks finding out if that little component in the entire Open Source system could be the bottleneck of whatever you want to do with your laptop, developer board, hardware whatsoever!
Do you have a granted problem-free ability to use the closed source within the Open Source env and you don't mind it? Go for it, but ask yourself why it has to be like that ... and please tell me once you find the answer!

Sustainability

This is the other big topic that everyone in this planet seems to ignore when it comes to electronics.
We all love the unfolding experience we have with modern devices, where most of the time the envelop is fully recyclable ... so adorable, isn't it?
Then there is a world behind chips we ignore, where Intel in pursuit of conflict free supply chains becomes also an etic must.
Lenovo, at that time, was the only one providing a laptop with 5th gen Intel CPUs, a generation born behind this Intel's Conflict Free initiative, the only CPU I felt comfortable, from the top of my privileged life, to buy.
I must be honest, I've no idea about other non-intel components inside this machine, but I've done what I could to be a responsible buyer.

Anyway, if Conflict Free Minerals are hard to understand, imagine everytime you buy chips (or Doritos), you gonna end up in the very same way with local people, instead of trees: Have I convinced you Intel is trying to do better than others in basically all fields?

Essential hints for an Open Source Laptop

This is what I'd do differently if I was aware already about all these tiny details that screwed my new laptop experience very badly:

• be sure all components are Intel or have Open Source drivers. AFAIK Samsung has some Laptop like this and they write all specs on the site.
• try to understand if you can get rid of the Windows OS or License without loosing your laptop warranty. I even have a Windows License/Nuber in my Yoga BIOS, that's just ridiculous, as example!
• try to understand if who's selling you the laptop provides at least BIOS upgrades for Linux. Most vendors do, Lenovo seemed to ignore Linux completely, at least for the Yoga line, but just one of them means they don't just care, period!
• last, but not least, try to understand if components are green, conflicts free, sustainable, and everything else you could do as responsible buyer to make this world a better place for everyone else, including yourself

Once you've done all this, give also archibold installer a try, before going with other mainstream distros: it's GNOME on ArchLinux and I can assure you it's a damn pleasant environment to be, more than good old snappy OS X if I might, very smooth, very complete, very nice!
And that's all folks

A future friendly, backward compatible, class utility

I've roughly talked about es-class during #FEDLondon, but I haven't mentioned it here even once.

yet another class utility?

Not only there are tons of library and used since 10 years ago, but I've also gone far enough with many attempts.
I asked myself if this wouldn't have been "just another one", but the answer was instead: no, this one is going to work!
The main difference between this class utility and others, either from me or other authors, is that this time the design reference is the ECMAScript specification itself. es-class aim is to be as close as possible to the future of classes in JavaScript and it will be updated accordingly.

Why not just transpiling from ES6 then?

The amount of mobile browsers and embedded computing devices out there without the ability to source map and debug is still very high. We are OK if we develop for a Desktop browser that supports them, but everywhere else it could be very problematic.
Using an ES3 compatible syntax in production, writing ES5 syntax in development, and transpiling, if we'd like to, only a handy subset of the next version, aka ES6, is a win in terms of readability, debugging, and development.
Strawberry on top, there won't be any automagically decreased performance with sugar we don't control, and also there will be some special feature borrowed from the next version of ECMAScript, ES7 or however that will be called.

Tomorrow vs Today

As shown in the FED talk, here how we will write classes in JavaScript:

class TestB extends TestA {
  method() {
    /** do something ... */
  }
  get value() {
    /** return something ... */
  }
}

and this is how we can write them already via es-class

var TestB = Class({ extends: TestA,
  method() {
    /** do something ... */
  },
  get value() {
    /** return something ... */
  }
});

In order to make object short method definition available in ES3, we can use only a subset of 6to5:

6to5 --whitelist=es6.properties.shorthand TestB.js

Generating the following ES5 compatible syntax:

var TestB = Class({ extends: TestA,
  method: function method() {
    /** do something ... */
  },
  get value() {
    /** return something ... */
  }
});

If we'll drop the getter, syntax available since about 10 years but not implemented in IE8 or lower, we can have compatibility down to IE6 and all good old ES3 based engines. Don't worry about reserved keywords, these will be normalized by any minifier out there you are already familiar with.

// minified class TestB example
var TestB=Class({"extends":TestA,method:function(){}});
//               ^  see? ^ this it's automatic once minified

Lightweight Traits included

In order to compose classes and reuse modules as much as possible, we can take advantage of the with property, another previously reserved keyword that will be wrapped once minified for older browsers too. This is probably not the keyword that will be used in ES7 to attach traits to classes, but being historically a reserved one and being the most semantic one available (with: anotherObjectPropertiesAndMethods), I took it to make composition deadly simple:

// a trait is just a plain object
var UniqueID = {
  // with an optional init method
  init: function () {
    this._uniqueId = '\x00uniqueid:' +
                     Date.now() +
                     Math.random();
  },
  // and optional properties or methods
  get uid() {
    return this._uniqueId;
  }
};

var Book = Class({
  // one or more optional traits
  // will be initialized automatically
  with: [UniqueID],
  // and **before** the constructor
  constructor: function (title, author) {
    this.title = title;
    this.author = author;
  }
});

var js = new Book('blabla JS bla', 'Some Body');
js.uid; // a unique id

And of course there is the possibility to add more traits:

// another trait/mixin
var Storable = {
  init: function () {
    this._storableData = Object.create(null);
  },
  saveStorableAs: function (name, what) {
    this._storableData[name] = what;
  },
  toJSON: function () {
    return this._storableData;
  }
};

var Book = Class({
  with: [
    UniqueID,
    Storable
  ],
  constructor: function (title, author) {
    this.title = title;
    this.author = author;
  },
  save: function () {
    // save data
    this.saveStorableAs(this.title, {
      author: this.author,
      uid: this.uid
    });
    // and store it permanently
    localStorage.setItem('book', JSON.stringify(this));
  }
});

var js = new Book('blabla JS bla', 'Some Body');
js.save();

More goodness

If a semantic extends with a smart super and a with keyboard to bring in traits and mixins isn't enough, you might consider interesting the usage of grouped static properties:

var LightBulb = Class({
  // grouped statics, one place to find them all
  static: {
    ON: 'lightbulb_on',
    OFF:'lightbulb_off'
  },
  constructor: function () {
    this.lightState = LightBulb.OFF;
  },
  switch: function (how) {
    if (how !== LightBulb.OFF && how !== LightBulb.ON) {
      throw new Error('no quantum light allowed');
    }
    this.lightState = how;
  }
});

var kitchenBulb = new LightBulb();
kitchenBulb.switch(LightBulb.ON);

In case you are wondering, statics are inherited too.

var FlashBulb = Class({
  extends: LightBulb,
  switch: function (how) {
    // do whatever a lightbulb does
    this.super(how);
    // check that if it's on
    if (how === FlashBulb.ON && !this._flashBulbTimer) {
      // should go off in 50 ms
      this._flashBulbTimer = setTimeout(
        this.switch.bind(this, FlashBulb.OFF),
        50
      );
    } else {
      // clean up the timer once OFF again
      clearTimeout(this._flashBulbTimer);
      this._flashBulbTimer = null;
    }
  }
});

Interfaces too

This time inspired by TypeScript interfaces, es-class uses implements keyword to do, at definition time and only once, a check against possible interfaces expected to be found in the class itself.

// es-class interface example
var IGreetable = {
  /** Used to welcome someone */
  greet: function (message) {}
};

var Person = Class({
  // one or more interface to implement
  implements: IGreetable,
  greet: function (message) {
    console.log(message);
  }
});

If we try to remove the method from Person, we'll see a simple console warning, where available, like: "greet is not implemented"

As summary

In my 15+ years career I've been working with both classical and prototypal inheritance programming languages, actually avoiding in the past the simulated "classical to JS" approach as much as I could.
However, this classical pattern is now part of the fresh new baked specification and honestly, I think classical inheritance has been useful in large (huge!) code bases too, where classes ended up being the only clean or sane way to move forward.
Composing their behavior thought, is also something extremely handy and powerful and reusable, if done the right way.
With es-class we can code what we expect from the present and the future today, using eventually some partial transpiler to write faster and use handy features, without necessarily dropping performance on older browsers or needing full ES5 capabilities. Some little polyfill like es5-shim and dom4 or others, in order to enjoy without fearing missing source-maps and with a syntax ready to be refactored once our target engines will be ready.
Write today what you can use tomorrow in a fully backward compatible way, and have fun with es-class

JavaScript and the living ECMAScript Standard

.@rauschma note cover of most recent draft. We hope the year-based branding will catch on in prep for annual updates pic.twitter.com/stWqa6ArTl

— Allen Wirfs-Brock (@awbjs) January 22, 2015

ECMAScript 2015, aka ES6

For those who don't know yet, ECMAScript, also known as ES, is the specification that defines semantics, syntax, and behaviour of the JavaScript programming language.
The versioning of such specification has historically been represented by edition numbers: ES3, or 3rd edition, is the most used and compatible ECMAScript specification ever, making JavaScript virtually the most deployed programming language in the world, compatible and often mandatory on the Web, embedded or translated in IoT devices and developer boards, available on the server through various implementations and engines since 1999.
It has also been decided, when the current standard went out, that one of the prime-goals of the ES specification is to not break the Web, meaning being enriched in a backward compatibility way.

We are virtually in 2011 2009 under ES5.1 umbrella

The current "running" version of JavaScript is based on a modification of the original ES5 specification, called ES5.1.
ES 5.1 is dated 2011 but it's just a typo/fixing version of ES5 dated 2009.
It's the first specification that has been officially adopted in IE ditching the historically slightly different JScript engine used in IE8 and lower.

Despite it's been 6 years since it has been officially published, and considering that it took long time to be finalized since it came out after a "never made it" ES4 version, there are still few quirks in modern engines as you can see in this table. We are almost fully compatible cross platform with such specification dated 2009.
To give yourself a better idea on how long it takes to fully match a specification, regardless it's almost complete and out, just have a look at version 6 of the same table.

A confusing last minute naming change ... for good

As some sort of curse, the JavaScript name and everything around it has been confusing since the beginning of the time:

from The World's Most Misunderstood Programming Language by Douglas Crockford

JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript, is one of the world's most popular programming languages. ...

The Name
The Java- prefix suggests that JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language.

JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for.

JavaScript was not developed at Sun Microsystems, the home of Java. JavaScript was developed at Netscape. It was originally called LiveScript, but that name wasn't confusing enough.

The -Script suffix suggests that it is not a real programming language, that a scripting language is less than a programming language. But it is really a matter of specialization. Compared to C, JavaScript trades performance for expressive power and dynamism.

Now ... think about it ...
Once finally clarified for some, but not for everyone, what JavaScript is, It took years of community effort to explain what ECMAScript is about, and how to reference a specific version of it so that in 3 letters we can describe the past, ES3, the present, ES5, and the future, ES6.
People keep posting ES6 related things on the web!

this is how the community eventually learned what's going on behind JS pic.twitter.com/ySGBQmXfdL

— Andrea Giammarchi (@WebReflection) January 23, 2015

There are websites named after ES6, there are talks on YouTube, and in Dr. Axel Rauschmayer case, as well as other authors, there are books titles that would like to be as accurate as possible for credibility sake of the author, at least, and for converging within the community about a single name to specify a list of expected features.

This is not just me being a drama queen as someone might think or even laugh reading that Axel's question in es-discuss related thread, this is also a concern for libraries shelves or articles and blog posts that will be considered outdated before vendors will even be fully compatible with the mentioned year.

@WebReflection ok never going to publish my (serious) JS book then - because by the time it's out the "covers ES 20xx" will look old :/

— an·gus (@angustweets) January 23, 2015

It will take years indeed before the ES6 table will become as green as the ES5 one, and it will take years to explain that to look at what the web called ES6 for 2 years has been renamed into ECMAScript 2015.

Apparently toward a year-based label naming convention anyway

So the reason behind this renaming is not to convince the rest of the world that in es-discuss they sell good stuff to smoke, rather to promote a faster rolling release cycles which is actually good since browsers implement whatever they want in the order they want anyway.
Chromium has already a presumably "ES7" Object.observe but still no bloody Proxy in its engine, so saying Chrome is targeting ES6 is basically telling a lie.
Going to a year-based naming convention might be more confusing for developers, they have to master features detections more and more moving forward with engines fragmentation based on rolling specifications anyway, but it could be good to define matching point for vendors and their engines.

What's the bummer

ES5 was the first attempt to improve JavaScript since 1999. 10 years later it came out nice, non breaking, and with tons of good new features most books and blog posts still don't fully know. ES6 race, together with the already widely discussed ES7 or however it will be called, is being a bit more anarchic.
JavaScript is probably the closest programming language to the utopia "write once, run everywhere". The amount of fragmentation that tripled with the Mobile Web era has never played a "fun to deal with" role for developers. They are sick of inconsistencies across platforms, they also are sick of engines stack in the past, as the io.js effort already demonstrated.
The community knows what it wants, and we are all thankful for the incredible effort TC39 and es-discuss ML is putting to keep developers updated, part of the specification, and informed of what's going on, but deciding that specs MUST roll out no matter what each year does not give me any more confidence I can actually use anything cross platform anymore.
Numeric edition of the specifications were probably not perfect, but as main milestones, as main deadline, these have done a pretty good job in describing expectations and set of features ... a year ? What a year would tell you, every year is just another year ... no milestone achieved, no idea how to measure compatibility, and not feeling like the following way to talk about features would be better than what we have now.

... I actually imagined this and somehow didn't feel right ... pic.twitter.com/rdQfwRo5LT

— Andrea Giammarchi (@WebReflection) January 23, 2015

Well, put in this way, at least now there will be less surprise whenever we'll find out that people started talking about ECMAScript in YYYY units.h3

... and the ISO Standard ...

As Allen pointed out in his comment there is also a document representing the third submission of the ECMAScript as ISO/IEC 16262 standard, marking the current standard known as 16262:2011 which is about ES 5.1.
For those thinking that it would then be that simple and fair to name JS same as C++

@paul_irish @WebReflection actually c++11 is the submitted standard at 2011 to ISO, same as c++15, 2015, JS15 seems fair…

— Juan Felipe Alvarez (@nebiros) January 23, 2015

not only the current JS should be called JS11, just to create some extra branding confusion, but there are already versions of JS called js17 and js24, these are SpiderMonkey implementation of the JS engine, often used as utilities in Linux.
If ES6 will be proposed as ISO standard it will be known as the fourth submission for ECMA-262-6 document as standard ISO/IEC 16262 in 2015.
So what's the other problem with year-based release? Mostly this:

@WebReflection don't know, seems impractical

— Allen Wirfs-Brock (@awbjs) January 23, 2015

And at this point, if ES7 or 7.1 will be submitted in 2017 then we'll already have confusion with JS17 as mentioned before but the good news is that at least, the official ISO standard could play the milestone role I'd like to refer when I am talking about features.
In that sense, in that case, I personally wouldn't mind calling it ES15, ES17, ES20, referring to the ISO standard.