December 27, 2016

"How To Learn Programming"

Filed under: philosophy, programming, software development — Benjamin Vulpes @ 8:28 a.m.

Don't worry, I'm not going to give you any useful pointers. As a matter of fact, if you read this and walk away completely deflated and as though I've torn the inspiration to make a career change from your hands, we'll both be better off. I'll have fewer kids working for starvation wages and reinventing all of JavaScript every year and a half saturating my marketplace, and you'll be spared all sorts of personal tribulations and the crippling insanity that comes of intimacy with modern computing1. You shouldn't learn Python, you shouldn't learn Ruby (let's be real, you were just going to use Rails anyways), you definitely shouldn't learn JavaScript, and if you value the power of independent thought, also avoid products of the cube farm like Java and Swift/Objective-C2.

That said, since you're here and reading this nonsense, I'm going to go out on a limb and assume that you're not of the brain-dead crab-pot postulators of such pap as "there's no such thing as wide variance in human ability at a broad spectrum of tasks, all competence can be traced to genetic predisposition to competence at the task in question", are in fact a smart cookie willing to work your ass off for meagre dopaminergic rewards in the short term, and have a passing interest and some amount of learned skills that make you, as the numbskull linked above might say, "good at computers". Perhaps someone even told you that you might eke great piles of loot food credits from Capital's demand for more Labor to turn its ever-multiplying cranks of complexity. None of that will be enough: you'll need tenacity, a solid dose of ability to pretend that some things are true while pretending some other completely contradictory things are also true, a healthy disregard for public opinion (if you want to preserve your sanity), and a historical bent so that you may at least work to build the leg up on the rest of the market that is grokking the historical reasons behind why Android sucks so fucking bad. Moreover, you'll need practical reasons to soldier through the nonsense, like a fearless leader or the promise of untold wealth. Pure fun or "joy of it" will get you precisely nowhere, when it wears off and the slog proper begins.

"Programming", as the touchscreen-using public knows it, consists nearly entirely of building soi-disant "apps". This domain decomposes into an enumerable set of subdomains: browser user-interface development ("webapps", "javascript apps", "single-page applications", "mobile-first websites", and more recently "React", "Elm", "Vapor" and other friends. Same old show, new cast of characters.), server-side development ("microservices", "Django", "Docker", "Rails", "Node.js"), and (generously) "operations" ("DevOps", "NoOps", "ContainerOps"), and "native" development ("React Native", "Atom", "Balompagus", "Objective-C", "Swift", "Java")3. In-browser UI development reduces to "some JavaScript that draws shit on the page and talks to backend services", "backend services" reduces to "a thin layer of glue code that handles HTTP requests, retrieves data from a data store (typically SQL4, although there are very fun mistakes to make in this domain as well), and then transmutes that data into a response to the original HTTP request". "Native development" reduces to "figuring out how the fuck to imitate AirBnB's latest nightmare of complexity with the fewest lines of code and most adherence to how Apple or Google want you to build that kind of "experience" (gag) on their respective platforms.

Building "experiences" (barf)5 in the browser is an unmitigated disaster. You can't really understand how miserably fucked up building "apps" (as the public call anything with buttons on a screen at which they can paw with their grease-coated sausages6) in the browser is, you must understand where browsers came from and how they evolved into the shitshow you haul around in your pocket every day. In the beginning, there was plain text. Then, some people structured that text, wrapping paragraphs in <p> (known as "markup") to indicate that they should be styled as paragraphs, using other markup for eg lists, and so on and so forth7.

So take a step back and think about what your browser is trying to do under the hood: take some text, marked up with various tags, apply some visual rules to it with CSS, and then execute COMPLETELY ARBITRARY CODE to oh you know maybe rearrange the ordering of lists, or replace your cursor with a spinning dick blowing loads whenever it draws over the character V or T, or oh I know pre-validate that you put a credit card number into that form input so that we can save ourselves a round trip to our servers from the user's browser. That's totally a good reason to shoehorn an impossibly bad programming language into the browser, mhm.

Fast-forward a decade. Web sites are passé, and people want at the very least "responsive" websites, and ideally "mobile first experiences" (drink). This means that the website that once needed to render nicely and quickly at 600x800 and maybe a few larger monitors now needs to look good on the 15" Macbook Pro Retina monitor (a monster of pixels, owned by everyone involved in "experience design", that no actual customer owns and yet whose pixel-count drives ~all design considerations in the industry), the Nexus Pucksell with its trapezoidal screen, the iPhone 7XXL with nearly the same number of pixels as the 15" Macbook Pro Retina but that uses an entirely different user interface built around poking at buttons drawn on a screen rather than pointing and clicking with a mouse and typing with a keyboard, and miscellaneous 4-year old Android phones that the User Experience expert in question has around from his last job but doesn't use any more except when he wants to make his devs lives miserable. On small budget projects.

It gets worse: because everyone involved in web dev was fathered by the kinds of neutered not-thinkers that women in America must settle for and the women aren't smart enough to have the children sired by actual quality sperm that didn't come from their meal ticket out of some perverse adherence to the local traditions of Beer, Monogamy, and Sports, your website won't even feel slow to the average cell phone user until you serve over a dozen megabytes (That's rather a lot of bytes. The last time I checked, the CH homepage clocked in at a trivial sub-30 kilobytes [kilo, mega, do recall the SI names for orders of magnitude from your elementary education, don't you?]) of uncompressed JS and CSS that you probably aren't even serving to clients anyways. This means that there is zero pressure for people to build lightweight websites anymore, which pretty much guarantees that nobody building websites is even going to think about the repercussions (either performance or security!) of pulling in a library to trim whitespace off the beginning of strings. For example.

So that's "the frontend". A soul-killing hodgepodge of 3 "programming languages" (HTML for the text and its structure, CSS for an approximation of what it should look like, and JS for responding to user input like clicks and taps), executed all together by "The Browser" and differently by each browser. Obviously (or perhaps not obviously, I have no idea how much you know about how your apps work), these things running in the browser have to get their data from somewhere. That somewhere are your "backend services".

"Backend services" are, well, Wordpress in other languages. All systems evolve until they can send mail, and all programming languages evolve until they reproduce a Wordpress-like Content Management System (CMS). They're of variously (I hesitate to say "great", but maybe) "less heinous than the alternatives" (will suffice) quality, where "the alternatives" are the poor Drupal framework. Which you don't want to use, unless you have some amount of cause to use it and Jesus fuck surely there's a programming language you like more than PHP, right? Anyways, all that WP does is respond to requests for web pages with data from its database wrapped up in HTML. Maybe with some CSS. JS if you hired someone to make a modal or a carousel or some other Web 3.14 inanity happen to your website (which, don't. It'll break in a year and you'll be out another 3k. Plus they always look horrible). Funny story, I recently heard tell of a Wordpress plugin that pulled in an entire JavaScript framework to render a modal. Does it serve that JS on all pages or just the ones where its modal is active? Was the JS compressed? GOOD QUESTIONS, KIDDO.

I digress. Backend services respond to HTTP requests with data from the database. Sometimes they write data to the database. Sometimes they poke other backend systems. Generally, though, they're "the pure function of the server: glorious, stateless, and without any user-interface cruft", to paraphrase a man who taught me much. Backend systems, eschewing as they do the complexities of managing user interface state are far simpler systems to build and maintain that clicky-pointy-tappy UI's. Every language used in serious force for web development (some languages are not, believe what you may) features one of these mega frameworks in which other web devs have encoded their knowledge and best practices around building web applications. In Python one has Django, and in Ruby one has Rails. PHP has Yii, and I hear that PHP is an entirely adequate(ly) object-oriented programming language these days, so who knows maybe that's a thing the budding webdev might consider using, except for how don't.

Finally, there is the wasteland of "native application development". Once upon a time this was just "software development" after the phrase was bastardized to mean "software running on consumer desktops" and not "missile control systems", but the poor notion's been degraded even further to now signify any drawing of buttons on a screen by any old monkey anywhere. It's not like she cares about the degradation, she's just happy to be with someone who can pay for dinner and maybe a kid. "You're a software developer too! Don't listen to what those mean guys on the internet say, I love you and that's all that matters." Not that any of us could afford to educate a kid in this America, but fuck I digress again.

"Native App Dev" is a glorious term for reading through Apple and Google's documentation for how to build list views and swiping image carousels on iOS and Android and then copying code from Stack Overflow that you can sorta-kinda beat into doing what the designer on staff has demanded, all naïve of the actual engineering constraints in play. Building UIs in this fashion is mostly configuration, if you can keep your designers on a tight leash and force them to design things that fit into the (admittedly inane) touch paradigms of the two platforms.

Building apps in the browser sucks, but at least a million people are out there sorta willing to lend the five brain cells they have left after playing in rock bands through their forties in resolving your problems with JavaScript and `undefined'. Plus it's sorta this weak Lisp Machine knockoff where you can kinda look at ("inspect") the web page and Chrome or Firefox will make a cursory attempt to tell you why the p tag doesn't have the spacing you might want it to have. Moreover, once your "browser apps" grow in complexity to the point where you're maintaining user state and redrawing things based on what you want to show them...well, at first you'll want to use a framework like React to get you 90% of the boilerplate you don't know that you need yet but the odds are solid that in two or three years you'll look back at whatever you built and curse fluently at the time you wasted using bloated toolkits. Nevermind that the only reason you built "apps" of the scale you did on your first dabblings is because all of the hard stuff was handled for you. Granted, you'll have a better notion of how badly those libraries handled it and with opinions and assholes in hand you'll set out to begin another cycle of the Great JavaScript Circle of Life where someone who's only ever built UI's in the browser with JS finally gets fed up with it all and decides to write the One True Frontend Framework to Solve All Everything That Sucks About Building UIs In The Browser. Hopefully you read this first and realize that contributing to the Circle of JS/Life is not actually a worthy use of your time.

Building apps for iOS and Android is no better; you're stuck in the hell that is Other People's IDEs (Integrated Development Environment, handling compilation and code browsing and documentation and autocompletion and all the civilized niceties that Emacs provides poorly and only after extreme customization). Java has the advantage of a compiler over JavaScript8, but it's pretty easily tricked and moreover Java the language is pretty repulsive to the aesthetically-inclined. Objective-C has over Java has a C-like syntax? And is tangentially related to the Legacy of Steve Jobs? I suppose there's the hot new jam of Swift, and if you bite off that mountain of lurking WTF let me know what you find; all I learned in building Swift apps is that Apple apparently can't ship a compiler/IDE toolchain that doesn't require regular restarts9.

Backend systems are the refuge of those inadequate for the task of building end-user interfaces, and of people who recoil from the notion of building user interfaces (due to aforementioned insanity in technology choices). "Nope", one guy demonstratedly capable of building iOS and Android systems told me one time, "I simply will not build mobile applications." One wonders "why" for approximately five minutes, and then realizes that a high-performing backend dev in the SV-driven market pulls down just about as much as your typical high-performing frontend dev -- and without all of the insanity of user interface development (the "technology" choices are bad enough, but have you ever met a self-styled user-experience visionary?). This odd confluence of the derpiest and some of the sharper knives (in the sense that they have a stiff internal resistance to dumb shit, and a nose for finding it) breeds such monstrosities as Rails (grasshopper, explaining the ways in which Rails development wears on my will to live is beyond the scope of this piece, but let it suffice to say that I recently saw the following line of code and recoiled in horror: `authenticates-with-sorcery!'). Most appealingly, you get to work with sane-ish linuxes, and your systems remain stable while the suckers working in the browser and on iOS and Android chase every single operating system release with if not actual slavering excitement then full-bore Stockholm syndrome.

However, despair not. There are other "kinds" of "programming"! You could configure SharePoint websites for any of a million small/medium business with SharePoint websites. This will also make you a Microsoft stoolie, and unfit for civilized company. Also you'll be stuck with the same problems. SalesForce idem, although I don't think you have to buy the Microsoft party line to hack on their shit. You could get a plain-Jane analyst job, and then apply your not-insignificant thinker to solving business problems with technology, and nobody would tell you which languages you had to use. Shit, I know options houses with Excel spreadsheets that take an hour to run, and that's after hand-optimization.

Or you could move into the "embedded" space, and compile programs in whatever language to run on tiny devices in the "Internet of Things". Making software to run on smaller and smaller chips is an excellent career bet for the next decade, as corporate focus moves from the "one person, one device, one chip" model to a rat-king of devices infiltrating every aspect of American life.

If you're really ambitious, you could even shoot for an actual auto-didact's "Computer Science" degree. Just keep in mind that if you do this correctly, you'll not "learn programming" nearly as much as you'll learn about theories of computation. Two litmus tests: if you write a single line of code in your first semester, you got scammed; and if you don't know the lambda calculus and its combinators by the end of the third semester, idem.

The point that I apparently need at least one more glass of wine to get out is that you'll need to pick a project to "learn programming" in the context of. If you know statistics, pick up a book on what's called "Machine Learning", but is really just applied statistics, and start working through the exercises. If you've already got the hang of physics and the related mathematics, consider writing a simple physics simulator. If you want to see the results of your work, consider building a simulation of agents controlling physical objects in a simulator someone else built, like in the game development program Unity.

If you have utterly no fucking idea where to start, consider buying a Raspberry Pi and beating it into a robotic cat feeder. You might not ever finish the project, but you'll either learn how to learn how to work with the linux shitshow or you'll flunk out of computer-related auto-didactery 101.

The point is that one cannot "learn programming" quite so simply as asking "how do I learn programming". Rather, you must have a place you're trying to get to, whether that's making more money than you otherwise might or solving problems that are just too tedious to solve properly in Excel.

In any case, you really shouldn't "learn programming". The world doesn't need more programmers, and you don't need to wreck your head on the shoals of Von Neumann and his band of merry mongols. If you insist, though, I'll be here. Don't expect me to help, though, this ain't Stack Overflow.

  1. You either go batshit nuts and move to a cave, hook up with crypto-terrorists like The Bitcoin Foundation, or retreat into the soft embrace of Dunning-Krugerism telling yourself that "this is fine, man", surrounding yourself with other middling schmucks all the while merrily self-deluding yourselves into the kind of complacency that makes crushing a six pack in front of The Game so damned seductive for the typical American male. []
  2. The joke's on you if you think you're "just going to learn Swift...". There are a few decades of internal Apple API's that'll need rewriting before you don't accidentally absorb some Objective-C on your way to Swift "mastery". The joke's on me if you write your app in Objective-C and then come crying for help. []
  3. Pop quiz: which of this paragraphs parenthetical appellations did I make up? []
  4. Another of those hoary old languages that refuse to die because they're just so miserably adequate for the tasks to which humans put them. []
  5. The degree and earnestness with which people lie to themselves about their work ("user experience visionary", "Full-stack JavaScript engineer", "Rails guru"), is a strong proxy for the quality of the work they produce, its utility to the market, and in precisely which market they hawk their goods and services. []
  6. True story: the extremely large iPhones exist to capture the bariatric market. []
  7. There was a whole pile of crazy around documents referring to other documents, semantically organizing the world's knowledge, it got as full-bore tin-woman as you might expect with very bad results). Eventually, some well-intentioned asshole (funny how it always goes the same exact way. Every. Single. Time. ) in search of a solution to some specific problems but not smart enough to evaluate the implication of his design on the world then applied a healthy dose of Cascading Style Sheets (henceforth CSS) to the Hypertext Markup Language (henceforth HTML) and turned browsers, which until that point had not done a whole lot to style the web pages shown to users into a so-bad-it-came-out-the-other-side-into-amusingly shitty knockoff of InDesign (This is unfair to CSS. Inline styling was a thing, and picking the right resolution of technical accuracy for a good read is hard.). To compound all of the above, someone decreed (this would have been at the height of the Browser Wars) that their company needed something other than the Java applets that were a) in use and b) causing all sorts of havoc at the time (It may sound crazy to someone "learning programming" in the dusk of 2016, but people loaded and executed Java code into their browsers "once upon a time". That you don't find this a laughably bad idea on its face should start to give you an idea of the yawning chasm of crazy you'll have to eat if you want to "learn programming".) . Thus was born JavaScript, a crime for which many are liable and will likely only discharge their debts by providing entertaining deaths []
  8. Now that you mention it there are comtranspilers for JavaScript that turn a sane-ish language into valid JavaScript. There's PureScript, TypeScript, ParenScript, and ClojureScript JUST TO NAME A FEW. One could in theory compare the different $LANG_THAT_TRANSPILES_TO_JS but by the time you got through the top three entries on your list the JavaScript "community" would have moved onto another one and showstopper bugs would emerge in the three you tested and do you begin to understand why I think that opening your wrists might be a better use of time than "learning programming"? []
  9. It's so bad that I actually got into the habit of preemptively quitting Xcode because its auto-completion backend would crash and never notify me. The easy and humiliating solution was simply to restart Xcode whenever it failed to complete symbols I was typing. And yes, before you ask, I'd quit Xcode regularly expecting the autocompletion framework to work again on reboot only to discover that I'd mistyped the symbol prelude. Such is the cost of shitty tooling. []


  1. Framedragger says:

    I enjoyed this article, and will have the pleasure of pointing people (including my past self? swig) towards it.

    Only a couple of opinionated notes:

    1. It still is quite possible to work at a place which develops desktop software that is nontrivial (in the sense of having a degree of (justified) complexity; e.g.: software for CAD/architects, with interesting problems such as "content-sensitive revision control and merging" (have two architects be able to work on some drawing area; lock a specific component when one is working on it; be smart not to lock too much when not actually necessary; etc.)). It doesn't have to fall under the umbrella of "actual computer science" - it's software engineering, but not of the worst kind!

    2. Things such as a language being "pretty repulsive to the aesthetically-inclined" may not always be really important. While the barf of FactoryFactoryMakerFactory's is not exactly pleasant, or justified half the time, IMHO sometimes Java's "let's overdo OOP" does map to business logic pretty efficiently, and there are good Java engineers [citation needed] which can mentor one into a better developer; they refactor code, do quality control and keep things (relatively) sane. Not that this is a strong point or anything.

  2. Whatever profit you make from having put yourself in a position to write this piece, cannot possibly make up for the radiation damage that racks up from being in said position. It was physically painful to read.

    I recommend to get out while you still can, lest you begin to think such things as that there could be a "good Java program", or a "good Java engineer" who writes such programs, or that the entire ecosystem crawling with Djangos and Balompagi is something other than an advanced case of technogenic mental ebola.

  3. And countdown to "Balompagus" coming to actually exist! complete with Code of Conduct!

  4. Benjamin Vulpes says:


    While it may be possible, it is uncommon enough that I'm not even going to bother with the topic today. There's a thread that needs pulling here on the topic of how the market for ever-cheaper touchscreen web browsers destroyed the market for professional computing.

  5. Benjamin Vulpes says:


    I can but hope that the pain of reading the drivel of a man driven off the deep end by wwwtronics will discourage starry-eyed youths from repeating my mistakes.


  6. Or you could ignore all of this stupid shit and buy a Masamune for 410USD plus the price of the hardware (x220 thinkpad, tablet or no), learn CL and forget the rest of the above nonsense. Between the sane graphics (CLIM) and math libraries: MJRCALC, MAXIMA, MGL (new!) and Femlisp you will have years worth of engineering entertainment + newly implementable business models.

    Email me for details/to order. As it stands I can only ship within the USSA.

    gabrielvalethladdel at gmail dot com

    NOTE TO READERS PAST 1/2/2017: I will be deleting this email address with a ~year. Can also be found on freenode in #trilema

  7. Benjamin Vulpes says:


    Please quote a price for the full package, including shipping to 97229.


  8. Ben,

    If you were not impressed with the video, Masamune is not ready for you yet.

    • Benjamin Vulpes says:

      I rather liked it, which is why I offered to host it for you. The cryptic theatrics are downright bothersome, but perhaps I'll eventually grow enough interest to pester you into delivering that quote omfg.

  9. Quote,

    -----BEGIN PGP MESSAGE-----
    Version: GnuPG v1

    -----END PGP MESSAGE-----
    • Benjamin Vulpes says:


      The utility of a laptop-snowflake with Masamune on it is vanishingly small to me, for any number of reasons you can probably guess at.

      So: can you install this on a server?


  10. So: can you install this on a server?

    Yes, but it is a complete PITA at the moment.[0] There is not, and will never be support for any of the abstractions AWS/Cloudflare/Digital Ocean employ. You'd had better _physically_ own those servers.

    I've not yet had a chance to sit down and work on this, but one model of deploying CLIM 'in the wild' is use Xforwarding (+ Xquartz) to send CLIM programs to OSX/Ubuntu users. All they have to know is that you can create GUIs 10x faster than the competition - no one need mention lisp.

    asciilifeform: ftr i grunted through gabriel_laddel's www material and cringed, he quotes massive chunks from my www but shows no symptoms of having learned anything there about, e.g., impedance mismatches in a comp system, or the failure of massive abstraction towers, or any of what i consider to be the basic observations
    ben_vulpes: give up, write everything in cpp and python, right?

    Oh oh, I know, let's do it in ADA.

    trinque: I think he would've been wiser to say "I wish to replace emacs with a CL environment" than "this is a step towards sane computing" or somesuch
    asciilifeform: if d00d worked on, e.g., climacs, and ditched the pretense of 'os design', he could theoretically come up with something worthwhile imho
    trinque: aha
    trinque: agree 100%
    trinque: I emphatically do not want anyone telling me how to run gentoo when I've been doing so myself almost as long as it has existed.
    asciilifeform: ^
    asciilifeform: gentoo could theoretically be improved -- but not by bolting a hacked-together cl layer ON TOP OF pythonic emerge
    trinque: the presence of e.g. network manager in the thing shows the lack of an eye for what constitutes cruft in gentooland
    trinque: that said the various CLIM explorers of the lisp system were ~rad~, integrated debugger etc, rad
    trinque: can certainly be more sanely framed as "finishing climacs"
    mircea_popescu: there's an impedance mismatch between description and labeling though. i expect my wine bottle to say "wine bottle" rather than the more accurate "dubious suspension of tanic acid salts in water"
    ben_vulpes: yeah, emerge, network managers, gui wrappers around os stuff is very uninteresting (but i suppose useful in the case of eg fs browser 'dired' and climacsy presentations).


    This is a step towards sane computing.

    Distro design, not OS design. And forget "theoretically". Gentoo can PRACTICALLY be improved by slowly & surely eliminating it from Masamune. There are plenty of people who can, and have written lisp bootloaders. The only problem with this (and all related projects) is that they're incomplete, due to lacking a working lisp environment one can integrate with. People write code using the _stable_ abstractions at hand.

    The ability for arbitrary ALGOL code to call into the lisp process (and for lisp to "wrap around" it) will be immensely useful in selling to those who cannot make the leap to CL all at once (businesses that have seen 100s of platforms come and go over the years come to mind).

    Until I can buy a lisp nic, I'll be networkmanagering it up thank you very much.

    asciilifeform: i gotta say that i am entirely uninterested in theatrical/hollywood imitations of lispm
    asciilifeform: which is to say, any and all attempts at 'it OUTWARDLY worx!1111' without correspondingly aligned internals


    Lisp is forwards-compatible, thus "outwardly working" programs will be able to run on the correspondingly aligned internals of the future with minimum fanangling. What, I'm supposed to belive that the ternery, dataflow, optical, loper machine is not going to have 2d/3d output? Gtfo.*Lisp#Implementation

    Please let me know if you have the sources of Zmacs/S-GRAPHICS/etc lying around.

    trinque: I dunno it's accurate to say the guy just grabbed something he found, but it's at the present impossible for me to evaluate how much code is g_l and how much found.


    A large amount of Masamune's value is in all the stuff I found, and then discarded. The 'weight' of the final codebase is irrelevent. You do not have to dig through quicklisp for interesting stuff - it's all in there. At one point in time I reviewed ALL CL codebases.[1] Everything interesting is either already included or on its way to inclusion. Furthermore, how much code is "mine" is irrelevent. The most useful patches (in terms of my working from within the environment): a non-crashing climacs & debugger are ~20 loc each, yet you would never know what 20 lines to write until you'd been Climacs _every single day_.

    trinque: the way you jump around, man.


    Eh, he spent ~decade at war. Mild PSTD is reasonable.

    [0] I've tried _many_ times to create a complete Masamune LiveUSB for this purpose, but presently my code can only generate an incomplete LiveUSB.

    [1] ~2 years ago I reviewed all of Cliki, each and every quicklisp project + did some google searches for lisp code and poked at github/bitbucket CL repos. Am happy to state on no uncertain terms that I know of every single even remotely interesting CL project to be found on the net.

    • Benjamin Vulpes says:

      Yes, but it is a complete PITA at the moment.

      Fix this. Repeatable builds are table stakes. I understand that you have a huge amount of sunk cost in the bootloader/distro pile, but not being able to fart a lisp image or collection of files onto a server for a demo is hurting you here.

      any of the abstractions AWS/Cloudflare/Digital Ocean employ

      Dedis are trivial enough to obtain, but for my education, what abstractions do the virtualizers require use of that you don't support?

      X Forwarding (sic)

      Great, you get it.

      We can't carry on like this. You're doing high-touch sales on my fucking blog, buddy. Take Framedragger up on his offer of a VPS for a bouncer and join civilization, wouldja?

RSS feed for comments on this post. TrackBack URL


« How to (Actually) Process Bitcoin Transactions --- A Pox Upon Your House! »