benoithamelin - Tumblr blog

[benoithamelin]

You will be newbie forever. Get good at the beginner mode, learning new programs, asking dumb questions, making stupid mistakes, soliciting help, and helping others with what you learn (the best way to learn yourself).

The Technium: Techno Life Skills

Everything I believe. Rediscovered in the Snarkmarket archives.

(via dianakimball)

[benoithamelin]

By the smart Casey Johnston.

What I didn’t say in the above article, but wanted to, is that Google and its new privacy policy that will let Google log and store data on everything you do with their services reminds me of the Spongebob Squarepants Movie. Stay with me.

In the movie, Plankton, the unquestionably evil character, gets ahold of the Krabby Patty’s cherished burger recipe, and starts selling those burgers at the Chum Bucket along with free souvenir buckets. People wear the buckets on their heads and it becomes a trend (I guess), until one day, Plankton flips a switch and the buckets clamp down on everyone’s heads, and surprise! The buckets are mind control devices. An unfair backhand slap of a plot turn, just like this privacy policy.

[benoithamelin]

To the people proposing this:

You dumb bastards. You know who this’ll hurt? Not big media. Not on any significant scale.

No, the people this will really fuck over are the EXACT same people SOPA and PIPA would fuck: Creative professionals; small publishers; independent businesses.

If you...

[benoithamelin]

Using Vim and Exuberant CTags for easy source navigation

I know many people who live and die with some of these shiny IDEs: nice fully-featured software to manage software projects. Design, code, compile, run, debug. Me, I distrust these great magnificient beasts. The good ones I've heard of work best when targetting certain platforms and languages, such as Xcode (for Mac and iOS software written mainly in Objective C), Eclipse (for Java software) and Microsoft Visual Studio (for C/C++/C# targetted at MS Windows). I've only worked with the latter, so bear with the gratuitous generality, but I've got the vibe that these IDEs feel cumbersome outside of their choice targets.

I've abandoned IDEs without looking back when I discovered the bash shell and Vim. I have been fascinated with the ease by which complex tasks could be easily solved by snapping together a couple of Unix tools. Being a keyboard-loving touch typist, I found that a few scripts and Makefiles replace beneficially the GUI used for compiling and running software from IDEs. For the coding part, I fell in love with the multiplatform Vim editor. Two things are still done more easily in IDEs, though: interface design, of which I really don't do much, and source navigation.

Now I have a nice trick for the latter.

Tags, ctags and Exuberant Ctags

My beloved Vim can natively navigate between so-called tags, which are named definitions of classes, functions, abstract types or what-have-you in some language of interest. These tags are read from a database generated by a tool called ctags. While many unices have a native implementation of this utility, it is worth replacing with Exuberant Ctags, by Darren Hiebert. Not only does this loquacious ctags find out about more tags than its terser brethren (such as BSD ctags), but it supports more languages, and can even be extended to support any language for which tags can be determined using regular expressions. For an example of this flexibility, check out VimLinkNotes, my implementation of a personal wiki using, you guessed it, Vim and Exuberant Ctags.

Running ctags

By default, ctags is run over a bunch of files, which it parses into a list of tags written to the tags file in the current directory. It is however more useful to specify a directory of the source that is to be navigated as a single project. Considering one would like to avoid parsing the source control metadata, one could then direct her shell to her project's directory and run

ctags -R --exclude='.git' .

where .git should be replaced with .svn or .hg or whatever is the name of the metadata file or directory.

When a project depends on libraries that should be browsable as easily as the project's own code, one can set up a list of source directories that should be parsed when running ctags. For instance, let us be working on project ~/Projects/Foo, which depends on two libraries, which have their source in ~/Projects/Bar and ~/OuterLibs/Baz, one could set up a file named ~/Projects/Foo/.srclist that could contain the following:

~/Projects/Foo ~/Projects/Bar ~/OuterLibs/Baz

Then, one runs

ctags -R --exclude=".git" -L .srclist

from the directory of project Foo.

Navigating the source in Vim

One issue of using ctags for source navigation is that Vim must be aware of where it can load the tag database. By default, Vim looks for a file named tags in the current directory, which is the default file for ctags. One must however be careful to run Vim only from the root directory of the project. To relax this constraint and restore the ability to cd to other directories within Vim, set the 'tags' option. This option supports all file searching cleverness of Vim, so a robust setting could be:

:set tags=./tags;~/Projects

(add this to your .vimrc). This makes Vim look for a file named tags first in its current directory, then in its parent directory, and so on recursively up to containing directory ~/Projects.

All tag databases so found are merged into one, with all tags resolving in a list of possible source locations. Here's a brief list of commands and keystrokes to navigate between tags.

CTRL+]

Navigate to tag under cursor. (Update: the keystroke was initially CTRL+[, an error of mine. Thanks to joelb!)

:tag <tag name>

Navigate to named tag.

:pop

Tag jumps are saved on a stack; this command pops the top of the stack and returns to the previous cursor position.

:tnext

For tags that resolve to multiple source locations, jumps to the next such location.

:tprev

Idem, but jumps to previous such location.

Check out Vim documentation for a more exhaustive overview. As for me, this navigation interface satisfies most of my needs.

Updating tags as code changes

In a project under development, code shuffles around. For instance, adding a new method in the middle of a class definition moves down methods previously written underneath. Therefore, the tag database must be frequently updated. For the sake of convenience, this should be done from Vim itself. However, this is not as simple as just invoking ctags from within Vim: if one is vimming in another directory than the root of the project, the project's tags file will not be the one updated and generated. Instead, only the source subtree under the current directory would be processed, and the tags file would be written in the root of this subtree.

The problem is thus to find out which of the current directory stack is the root of the project, so we can run ctags from there. For this, one should use a marker path, a file or directory that can only live in the project's root. I use the .gitignore file: the tags file only exists after initial tag generation, so its use as a marker is flawed. The following recursive script does the job of finding out the root and running ctags appropriately:

#!/bin/bash if [ -f ".gitignore" ]; then if [ -f ".srclist" ]; then ctags -R --exclude='.git' -L .srclist else ctags -R --exclude='.git' . fi else HERE=$PWD cd .. if [ "$PWD" = "$HERE" ]; then echo "Got to /, have not found your project root, abort!" exit 1 fi exec "$0" fi # EOF

This script could be copy-pasted to a file named ctags-proj.sh, for instance, which could be put in a directory in one's PATH. It can then be invoked from any subdirectory of a project to update the project's tag database. For convenience, this actions should be scripted from Vim, using a keystroke or a custom command. I favor a keystroke, adding to my .vimrc the command

:noremap <Leader>t :!ctags-proj.sh<CR>

Do you have Vim-Ctags tricks of your own? Do you use other navigation commands with you tag databases? You're welcome to share them in the comments.

Oh, and I wish to you, my peers, a year 2012 of peace and fulfillment.

[benoithamelin]

Having just fallen in love with literate programming, I stumble on this hilarious piece. Not so sobering as just a reminder that not every problem is a nail. As I said earlier, literate programming is a tool to manage the complexity of a problem solved in software. However, when the solution is expressed concisely in a certain language or toolkit, it is thus a simple problem in this perspective. Therefore, there is no complexity to manage in its solution, hence no need for tools such as literate programming.

Also, good programmers are writers in disguise. Training to be a programmer? Take a good course or two in nonfiction writing. Thank me later when you have an edge in organizing discourse.

[benoithamelin]

I will look like a complete Philistine, but this piece is my first serious exposition to literate programming. The times I had heard about this approach to software development, it had been derided as academical, unpragmatic and impractical -- something that was of interest only to its pioneer, Donald Knuth. That that I can see it for myself, I think the ideas behind literate programming are utterly exciting.

Not that I think that the piece above got it completely right. Actually, its takeaway should be "do as I say, not as I do." The author hits his mark when saying that the text segments between the code fragments should explain the why of the code, not the what. Explaining the what is repeating oneself, as the code is the what. Still, the author goes off and writes about the what of his code and not they why, so his whole program is a bit hard to read, in spite of being simple and fully documented.

The what is the code. The why lives as a second, third, nth degree within the code. What the text between the code should say is why some variable is made global. Why some functionality is spread between these three processes, these five functions. Why these things are coupled, when we know coupling is bad. Real-life code gets ugly, as programming is like packing one's car trunk: you make decisions above decisions you've made previously from less information. It's NP-hard!

Literate programming done in increments, supported by unit tests, should then document the decisions as they are taken. This documentation can drive future debugging and refactoring, avoiding contradiction and easing new developers trying to wrap their head around the growing code base. I feel that literate programming is a complementary way to manage the complexity bloom of software projects.

Its now a cliché that programs are parsed by computers, but read by people. I'll add that if compilers have a right to complain that a program is unfit to be read, so should people. Programmers must communicate their ideas to people. They thus must be good writers. These days, we see many people embracing the functional programming languages and approaches that I had seen my coeds deride when we learned them in undergrad CS. FP is the old idea that's become a good, fashionable idea. I feel that the next such concept to resurface will be literate programming.

Unsatisfied with what the author of the paper above has come up with, I have been checking out modern literate programming weavers-tanglers. Being a LaTeX afficionado, and wanting to experiment with multiple target languages, I've settled on nuweb for my initial experiments. Feel free to share your own experience with LP in the comments.

[benoithamelin]

VimLinkNotes: a personal wiki using Vim and ctags

I have hacked together a simple personal wiki implementation in Vim, with the help of Exuberant ctags. I think the full implementation holds in less than 50 lines of configuration and Vim script code. Feel free to take a look at the project page. For the impatient, I might as well point to the GitHub page.

[benoithamelin]

I am a member of the Vim cult. We hold no meetings, we don't always know each other, we don't all mock Emacs (at least I don't), we just share an unlikely love for this lean and efficient text editor. Vim is like a good dog, it follows you everywhere you code, your faithful companion.

However, like a good dog, Vim requires some taming, some domestication (actually, Vim tames you -- even out of soviet Russia). It has been said to have a steep learning curve, which I cannot deny. However, putting its commands at one's fingers yields rewards of unexpected magnitude. Its bimodal approach to editing has been derided, but one does get used to it, and it then feels natural: now I'm reading, now I'm writing, and so on.

The steep learning curve, however, is best overcome in small steps. This is the main point of this great lesson in text editing by Vim's original author and actual maintainer, Bram Moolenaar. Learn the basics, then learn the advanced features that allow you to be efficient in your own work. Practice until these new features have become second nature. Repeat as needed. As Vim only requires keyboard interaction and few chords, it enters easily in one's muscle memory.

I've used Vim for more than ten years now. The next feature on my learning list: text objects. What's yours?

[benoithamelin]

Very honest piece. As a software developer of any walk or flavor, you work a market, so you have to sell something, to offer some value to someone. Making yourself hireable entails making this value explicit. So shine away.

Here's a good quote out of the article that has prompted some bitter responses:

You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.

I get the bitterness, but I totally agree with the author. How do you think have computers become so important in this economy? They were born to run complicated and tedious calculations. However, they have taken so much market space because of automation: doing stuff that people use to do more reliably and more cheaply. Hence, putting people out of jobs.

I write some programs for my own uses. What for? Automating tedious tasks such as backups and data processing chains. I put myself out of these tedious jobs -- good for me! But you know, ATMs were programmed by people like you and me, and because of these, you don't get to speak to nice ladies when you withdraw a bit of the money you made doing so. Wherever we stand as software pros, be it developers, but also writers, teachers, executives of software companies or whatever, we all stand in favor of automation, some way or other, directly or indirectly, happily or sadly or blindly. What Patrick McKenzie says is that this shirt is mandatory dress code: if the collar chafes, you have got to change.

[benoithamelin]

Ergonomics for programmers: the importance of a good font

Scotch tape fetish

Back when I was working for my Ph.D., there was this post-doc in our lab who had this funny habit. He had this big roll of scotch tape by his computer screen. Every morning, as he sat down for work, he tore off a good length of that tape to bind his left-hand ring and pinky fingers together.

"Is this some kind of fetish?", I asked on a slow day. "No, it's because of the pain." He went on to explain that he used to mouse with his right hand, but then he developed severe carpal tunnel syndrome. When the pain became chronic, he switched to mousing with his left hand, but then the carpal tunnel started flaring up on this side as well. "That's when I realized that I had this unconscious habit of stretching my pinky away just so when I held the mouse. Now, my right hand is busted for mousing, but I can still get by with the left by forcing my pinky in this relaxed position."

Does your work involve repetitive gestures, such as mousing or typing at a keyboard all day? Well, then you have to care for your work ergonomics. This means a lot of things, but as a rule of thumb, you must be careful about avoiding any sort of excessive fatigue.

Eyestrain 10pt, bold

I am a lucky man not to have had to endure the torment of carpal tunnel, but I also have my pet peeve as a full-time software developer. Hard days get me headaches. Not migraines, thank god, but headaches sufficient to ask my kids not to be so noisy while I fix dinner. Dull, tired, sad headaches. I hold myself to some standard as a dad, so I need to have some control over these headaches.

I have remarked that the worst skullbores happen on days where I'm under pressure and I squint at the screen. I surprise myself peering confounded at the glass, shoulders tense, neck craned forward, back stooped, eyebrows furled. I put myself into this crow-like position unconsciously when I get nervous about some code or bug or negotiation or change of plan or what-have-you.

I figure headaches come from the physical fatigue of the crow stance, so this can be tackled as an ergonomics problem. How can I avoid squinting? The first thing that comes to mind is to reduce eyestrain any way I can. For reading text and documentation in my web browser, just increasing font size has worked wonders. I also ditched the old bright-characters-on-dark-background color scheme that I found so 'leet when I was a college student. I now use lower-contrast black-on-lightgray color schemes, in which the characters do not become blurry as the day progresses. Figuring out colors for syntax highlighting that contrast sufficiently against gray backgrounds was a small hurdle.

However, it did not fully fix the dreadful headaches that come from difficult coding and debugging, activities I do in editors and terminals. These are the domain of monospace fonts, the readability of which does not seem to be directly enhanced by simple enlargement. Also, bigger monospace fonts yield work windows with less rows and columns, or that become so big that the editor and shell windows cannot fit side-by-side on the screen. In short, I needed a cleaner, more readable font that would get me to squint less.

The $220,000 font

I recently discovered the excellent font work of Fabrizio Schiavi (@fabrizioschiavi). He designed PragmataPro, a monospace font that is highly readable and comfortable even in small sizes. It is condensed in both width and height, but somehow still manages to breath on the screen. It is a real labor of love, as all the characters appear crisp and clear even for large font sizes.

The problem is that this font is sold at 170 euros. I know, "what's a headache worth to you" and all of this, but I just do not have this kind of petty money on hand. However, Schiavi has a plan to make the font free, if he can somehow recoup the resources he spent designing it. The amount he is trying to raise gives pause, and his budget breakdown made me glad I live under Canada's tax burden. Still, if he fails to reach his financing goal, Schiavi has pledged to offer the font to all contributors for a more affordable 20 euros.

This offer was quite palatable to me, and maybe it's because my wife is a graphic designer too, but I contributed enough to be offered the ancestor font of PragmataPro, named Pragmata. This thing is my new sliced bread. Like PragmataPro, it is a horizontally condensed font design, but with a largish interline space. On my 1680x1050 screens, the font size that I find most comfortable still yields more than 40 lines of text, which, while less than Inconsolata's yield, fits my need. I am surprised at how I like this interline space: it breathes and feels like the old electric typewriter I used when I was a kid.

Here's a screenshot to show the font in action. On the left is a 25-lines iTerm2 window with a Gambit Scheme session. On the right is a 41-lines MacVim window with a bit of Markdown code. In both cases, I appreciate the equilibrium of the characters, more than twice as tall as they are wide. I also love the large space between the characters, which help them breath. It is this space that makes the medium-weight characters so crisp and easy to read. There is neither bloat nor blurriness to this font, even after reading page after page of terminal output.

Fond of your font?

We software developers have access to many free high-quality tools. There are also those tools that we paid for, sometimes dearly. I've seen people advocating passionately for the likes of TextMate, Mac OS X, optimizing C compilers, Matlab, Visual Studio… We see how one can get by without these tools we love, but we would not. I feel this way about the Pragmata font, and I expect as much from PragmataPro.

If editors, terminals and other monospace text hubs are crucial for software developers, then so are monospace fonts. Squinting is for moles. If we are to care, no, to obsess about window placement and color schemes, I think we should put as much care into choosing a readable and comfortable font. There are good free fonts out there. It is part of the ergonomics of software development, as much as a good typing position and mousing habits. Don't wait until you have to tape your fingers together.

[benoithamelin]

Sorry for the long hiatus, dear reader, the last many days have been crazy at the job.

These are notes for a presentation by Perl guru Mark Jason Dominus, the author of Higher-Order Perl, among other things. From these many wisdom nuggets, here's a few ideas I retain.

As said Vonnegut, "God damn it, you've got to be kind." Really, it's not so hard, even I am up to it. Writing to someone you know but in reputation, to ask or comment about code or ideas? Introduce yourself briefly, give some context to your question or remark. Do not confound curtness and concision: the latter is appreciated, the former is unsettling. Hellos, pleases and thankyous are not fluff, they're air: the air that fills the tires your car/bike rolls on. Want a smooth ride?

The other side of the coin of kindness is the fish discussion. I've taught many classes at the undergrad level, and I've seen the results of a having a positive stance towards questions. I've always given prompt, helpful answers to students who cared to state their question clearly enough for me to understand (not always the case). Those students who pried direct answers for homework problems were seldom interested with the course material in the first place, and often performed in the lower and middle tiers of the group. However, for people interested in the course matter, a few helpful answers would get them on track to complete their projects and solve the most difficults problems on their own, making them happy and proud of themselves, and getting them to perform in the higher tier of the group. There was no sucking-up, nor any sort of favoritism or nepotism going on. What have I got out of this all? Many of these then-interested students have become good professional contacts, with whom I share a common appreciation of our respective competences. In other words, if I'm seeking work, I can call some numbers. Giving a bit of your knowledge freely nets you karma, grasshopper.

OH: apparently, Lisp communities are not friendly with newcomers. HA! opportunity, here we go. I love Lisp dialects, though I've only dabbled lightly. Let's talk some Lisp; let's start a Lisp community that takes heed to my idea #1 above. To be honest, Montreal's Clojure user group, named Bonjure, is a very nice bunch. Let's copy their kindness without mercy, while we talk some Lisp problems.

Dominus raises a very good point about pragmatism of code solutions. This is the one snag I always trip in while doing test-driven development: after writing a few tests, I get smartypants. I start writing a clever complex solution. It takes time. In the end, it's useful as-is only as often as it's not, which I figure as I get to later parts of the task. So much time lost! 

So, brain, hear this: from now on, when going for the first implementation that gets a test to run, you go for simple. Keep the smart stuff for when simple is not enough anymore. Don't look over this moment's shoulder, don't try to take into account what's coming after these tests, just do simple. Does it look dumb? Whatever. Does it look inefficient? It's only looks. Do you think we'll have to scrap it before lunch? We'll see. Ok? That's a good brain.

Software is like any human project: sometimes, it's, you know, finished. That it receives no further update or new feature does not mean it's abandoned. It's just right as it is.

A good example of this is TeX, Donald Knuth's famous document preparation software. It has not had a single new features since the '80s. Is it abandoned? No, it's finished! Besides having received a few bugfixes throughout the 30 years since being feature-complete, it's used both by itself and within many other document preparation systems, notably LaTeX. Many mathematicians, physicists, engineers, scientists and writers can use //nothing else// to typeset their stuff. So, before pronouncing the death of software that's not receiving updates, wonder whether it just solves your problem already.

Reading is hard. Sure, one can follow the text, maybe even retain some of the material. In all honesty, while writing this post, I am referring again and again to Dominus' notes: "What was he saying again?" It's just about four pages long and I have trouble remembering what's in there. So what's in that big 500-page book you've read last week?

Reading actively is difficult, I'm often drawn too much towards what comes next to really pay attention. I prefer Andy Hunt's advice in Pragmatic Thinking and Learning: read once through the whole document, to get an overview of the material. Then, take the time to re-read slowly, taking notes in margins or in a notebook. I must say, while I love e-books for learning, since they're lightweight and inexpensive, there is just not a single good way to annotate them. I mean, the whole bezel area of my Kindle is covered with annotation graffiti after reading through Hunt's book. I've tried sticky notes, but they fall off the device after a while.

Feel free to share similar wisdom articles from devs or gurus you respect in the comments.

[benoithamelin]

I've been a Vim user for almost 15 years, now. Vim is my one true companion while programming: it has taken me through undergrad CS and grade school, home projects, school projects, research projects, article writing, thesis writing, desperate attempts at system administration and so, so much random noodling. With Vim, I have succeeded and I have failed. In spite of my Ph.D. advisors best intents, I have converted my best research colleague to Vim, which tightened our friendship. Vim is now an extension of my mind and typing hands, and is the first tool I make sure is installed everytime I lay hands on a new system.

Thank you Bram Moolenaar, for how you guided the development of this great editor, improving over Bill Joy's vi in so many critical ways. Also, thank you for making Vim the only charityware effort I now of, thus making sure that Vim litterally makes the world a better place.

[benoithamelin]

Sorry for the thematic disruption, but this is important. Also, sorry about the exclusivity of this rant. Abuse online is disgusting in any and all cases. However, I am personnally moved to action about issues of woman equality and feminism. What is at stake here is not disagreement or dissension to points, ideas or even personalities in online discussion: these can be dealt with, even when they get emotional or personal. No, I am infuriated to tears here about the hatred on exhibit.

I am a naive, idealistic man. Living in Québec, Canada, surrounded with so many examples of women succeding and making their place in what was a man's world 40 years ago, getting respect and equal opportunity in many aspects of their lives, folding all of this goddamned laundry all by myself (please laugh along), I thought ah! we're there. My generation is the first to have women and men stand on equal footing. I even started pleading for less feminism in discussion of gender issues, and try to redirect our efforts towards equity and equality.

In the name of all that is holy and sacred to me, I was so biased. So wrong!

I take it all back. Feminist --- hear this, not equalitarian --- activism is as important today as it was in the time of suffragettes. It might be even more, because the big visible victories have been won, so the revolutions's flag is waving over parliament hill, while the reactionaries have fallen back to waging a guerilla war. Affronts at womens' freedom of speech are marginalized and neglected in the greater public discourse, so as discussed in the linked article, writing in public as a woman requires much more courage that I've ever had to muster.

To conclude, I would like to call upon two groups of people. I have nothing to say to haters, so my first point addresses the indifferent. The fight for basic women rights, such as arguing opinions in public, is not over. Are men threatened of rape or assault every time they take the soap box? No. If it were the case, the outrage would make such a racket that I could not go to sleep at night, which would shake some politics into action. These sorts of threats are happening for women writing in public today. And no, I won't accept that the hating commenters are young temporary imbeciles, so that the problem will go away once the Internet crowd grows up. Young haters grow into old haters. Hate left to itself festers, ferments and blows up in your face the day you lift the lid. Haters must be identified, accused and condemned. Be warned or be sorry.

My second call is to women of all ages. Do you participate to mixed-gender communities where opinions are exchanged? Do you do it while identifying as women? I offer you my sincere admiration. As a man, I pledge to always consider the point before the author's gender, to never make point validity a question of gender and to make any effort of empathy when the argumentation goes beyond the limits of my male experience of life. I hope this can be made better.

[benoithamelin]

I wrote a typing tester in Turbo Pascal when I was a kid! Lovely memories of learning the mysteries of pointers. And linked lists. I'll just fire up my qbasic to wipe off the nostalgia. (No I won't, it's bedtime. I'm not 16 anymore.)

[benoithamelin]

Way back when in undergrad CS, I had been fascinated with functional programming. The teacher was reviled by everyone but me, because each lesson would put many more questions into your head than it did answer. I am not a very intelligent guy: I get by on sheer perseverance and putting in the work, and although I have good memory and a knack for explaining things, I get few good ideas. In the past five years, all good ideas I've got were about functional languages and programming, which might explain why I did not do so good as an imaging researcher (always dreaming about FP).

Anyway, this paper outlines clearly and concisely some of the best ideas of FP, high-order functions and lazy evaluation, and especially why they are such good ideas that software devs must take notice of them, have them lurk in their minds' background. Learning some FP, using any language that can support at least some sort of lazy evaluation, is an experience I highly recommend.

[benoithamelin]

(via Instapaper)

This is not Fred Brooks' seminal book, but it riffs along similar lines.

The highlight of this insider view of a Google engineer is his perspective on the effects of team size. "People need small wins to thrive, and large teams are poisonous to small wins." Indeed, working in a small team has brought me a great sequence of small wins, gems of professional happiness that I would work hard for, and get.

[benoithamelin]

(via Instapaper)

I have been using virtualization since starting up on the job with Arcadia, and I am not going back. I love that machine state can be saved for archiving, reuse or packaged as a product.

The piece I link to here presents a virtualization implementation that makes the virtual machine run in a stealthy fashion with respect to the host machine and other VMs. The tech is introduced as a way to run sensitive computations in a securized environment, which is nice. My take is that it can also be used for nefarious purposes: such a stealthy VM can be implanted from malware and then used as a fully-featured backdoor for snooping, illegal file storage and running payloads.

In addition, if the stealthy VM runs on a dedicated CPU core with a dedicated memory block, it can likely be detected by attempting to run a program that would make use of the full capabilities of the host system. In other words, the VM itself is not dedicated, but its resource usage cannot go unnoticed in all situations.