The sad state of sysadmin in the age of containers (2015) - <AUTHOR> https://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html <comment><USER2> _Ever tried to security update a container?_

The whole point of using a container is that you can destroy it and build a new one easily. The new one should be built using up-to-date packages with security patches applied (and tested, obvs). Using the 'pets versus cattle'[1] analogy, patching a container feels like you're treating it like a pet. You should just kill it and get a new one instead.

[1] [https://thenewstack.io/how-to-treat-your-kubernetes- clusters...](https://thenewstack.io/how-to-treat-your-kubernetes-clusters- like-cattle-not-pets/)

<comment><USER3> The whole point of having a distro with a good reputation is that you can incrementally outsource your trust to them, one package at a time. OpenSSL needs a fix? One package update per machine, and if you have lots of machines, you update that.

With VMs, you can use the same tools you use with any other machine.

With containers, you are responsible for figuring out which ones need which packages and how to re-build them. Your method is likely to be idiosyncratic, so you not only need to be your own security team, you need to be your own packaging maintainer and infrastructure maintainer.

The two extreme versions of this are the neglect model, in which you just don't care about anything, and the bleeding-edge model, where you automatically build with the latest versions of everything pulled from their origins. Both ways end up with unexpected security disasters.

<comment><USER4> The "one package at a time" model assumes you care about per-instance uptime and bandwidth costs. The "reset the world" model assumes rebuilds and reboots are cheap enough not to have to.

I don't think either is necessarily wrong; there's not a huge distance between `apt-get install unattended-upgrades` and a daily (weekly, whatever) container rebuild except that you need to cron the latter. Unless you're using a different OS between the two cases, they can use the same package database, the same tooling, and so on.

<comment><USER3> You need to make the decisions, keep track, and do the work. If you've got the tools made for you, excellent. Otherwise you also have to build and maintain the tools -- which is my point.

<comment><USER4> There are no more decisions to make one way or the other. If you're keeping a VM image updated with new packages, that's either a) automated with something like unattended-upgrades, or b) a manual scan of DSA's with decisions as to whether they're important enough to apply and to which boxes they need to be applied. It you're rebuilding a container image, that's either a) a 2am cron job to do a blind rebuild that captures the latest package versions anyway, or b) a manual scan of DSA's with decisions etc etc...

The 2am cron job, if you go that way, is, assuming you've got an automated build anyway, a one-line bit of config somewhere. It's not something I'd usually think the words "build and maintain" would apply to.

</comment></comment></comment></comment></comment><comment><USER5> > I'm not complaining about old-school sysadmins. They know how to keep > systems running, manage update and upgrade paths.

Sadly these ways of olde didn't scale. They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'.

> And since nobody is still able to compile things from scratch, everybody > just downloads precompiled binaries from random websites. Often without any > authentication or signature.

Right, that would have never happened back then, when packages were not signed and freshmeat.net was still a thing. For some reason compiling C code from some website (`wget;./configure;make;make install`) seems to be more secure than `go install`, maybe because nobody understands automake anymore.

<comment><USER6> > They could only do it for a handful of servers, change request took months > and the systems were not to be 'touched'.

Those old ways of doing things were indeed slower than they needed to be in many cases, and I'm glad that we sped them up. I don't believe that we needed to throw the baby away with the bathwater though.

The problem now is that we build systems which are unmanageable and unmanaged. 'Throw it in a container and let it run' is not scalable either: it scales neither security not maintainability. Instead of scaling, it just _punts_.

Enabling one to do something one shouldn't do (i.e., deploy insecure software into production) is not a virtue.

<comment><USER5> After a few decades it's no longer a baby ;)

Software is becoming more complex and moving faster than ever. 'Controlling your dependencies' was always an illusion and a trade-off at best. Often a trade-off against security, inheriting the folder of JAR files from your predecessor and such.

I think of containers and all these new tools as designs which are supposed to help us manage existing complexity. They don't create it, it's already there in the requirements and real-world deployments. The friction we feel, is that some of those tools are not very good (yet), but maybe better than the previous generation (sometimes). On the negative side, there is a lot of nostalgia ("ah, do you remember bare metal...") and unwillingness to change and learn.

<comment><USER7> I think a lot of folks who have been through a few tech cycles just see us building the same tools over and over again adding complexity to the overall system.

I think the main cause here is, ironically, the fact that businesses keep trying to remove sysadmin (as a discipline) from the IT value chain and replace it with subscription services. Sure, you _can_ do it, but at some point things will break and you need someone who understands what is happening at the lowest levels of abstraction.

</comment></comment></comment></comment><comment><USER8> You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been far more successful because they provide a much better user experience, and frankly I suspect this is if anything _because_ they're so thoroughly isolated from the platform package manager.

<comment><USER9> > jealous, insisting that every language has to conform to their way of doing > things

Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access?

Is jealousy the only explanation that comes up to you?

<comment><USER8> Reproducible builds were a non-goal for apt for most of its existence.

<comment><USER9> > Reproducible builds were a non-goal for apt for most of its existence.

Your comment sounds very disingenuous, as Debian was first released in 1993 (about 26 years ago) and has been pushing for reproducible builds since 2000.

[https://wiki.debian.org/ReproducibleBuilds/History](https://wiki.debian.org/ReproducibleBuilds/History)

<comment><USER8> Your own comment is extremely disingenuous. Your own link states that there was very little enthusiasm for reproducible builds when mentioned in 2000 and 2007, and the first serious effort towards reproducible builds started in 2013.

</comment></comment></comment></comment></comment><comment><USER10> This all boils down to trust.

`curl | sudo bash` is no different than .\install.exe. The question is about trusting the SOURCE and trusting the DISTRIBUTION channel (that HTTP download from scala-lang.org violates this).

Where did you get it? from [https://microsoft.com/..](https://microsoft.com/..). or from [https://micro.soft.com/...](https://micro.soft.com/...)? Whom you trust more? The same with pre-built VM image or whatever... do you trust the party that made this image/container available?

<comment><USER11> `curl | sudo bash` should never have become a thing in the first place. To me, it's the most "WTF?" mode of installing anything. __Especially __when the source is HTTP.

In what world is that secure?

Pity Qubes is so heavy, otherwise I'd be using it

<comment><USER12> would you feel better if your Makefile looks like this:

        install:
            [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh

it goes back to what jve said - it's a matter of trust. how often do you blindly run 'sudo make install' w/o reading the entirety of the build script? all the time I bet - it's because you trust the source

<comment><USER11> No.

I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software.

And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.

<comment><USER13> What difference does it make if you run `make install` or `curl | bash`? In both cases, you are running code you have not audited yourself. Or are you the kind who inspects every Makefile and installer script before installing? If not, why is one better than the other?

<comment><USER14> Because at least with make install you can have some trust in the delivery method, ie encrypted git or whatever. If you use just plain http....

<comment><USER13> So wget [https://example.com/installer.tar.gz;](https://example.com/installer.tar.gz;) tar -xvzf installer.tar.gz; cd installer; make install is okay for you?

But curl [https://example.com/installer.sh](https://example.com/installer.sh) | bash is not? Why?

<comment><USER14> I'm fine with the second too as long as the host is trustworthy and it's always https. Most of the time it isn't.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The holy grail of sysadmin has always been deployment of immutable images, instead of host system pollution, source code mutation during deployment ...

It was doable with things like Packer, KVM or OpenStack, now it's become easier with containers. You can still orchestrate your stuff with ansible or bash scripts.

I most certainly remember how I was doing isolated deployments 10 years ago: [https://github.com/jpic/bashworks/tree/master/vps](https://github.com/jpic/bashworks/tree/master/vps) HINT: it's much cleaner and much more automated with containers: with GitLab- CI it's trivial to host a private container bulding infrastructure with a registry and other automation ...

</comment><comment><USER16> Talking from a developer's point of view, I've thought about this for a while and I think it has something to do with what I refer to as "anti-imposter syndrome" \- the notion that anyone can make software. You see, over the past 10 years or so, self-proclaimed "educational" services/websites/institutions have been shoving down everyone's throat the idea that anyone will be able to create the next FAANG from scratch after just 3 months of training. Which is the same as claiming that I can become an F1 driver in 3 months. Where do I sign up?!?!?! The thing is, F1 results are a lot more visible since you have a point of reference - the top dogs. Chances of scoring a fastest lap or coming even close to them - little to none. Software - not so much - you have a shiny interface and what it does underneath is always a mystery to the end user. And people who have gone through those magical 3 months of training are often lead to believe that the way they are doing things is what everyone is doing and that is how it should be done. Often people who have signed up for those courses are people who have just a smudge above average technical knowledge - they have no idea how OS'es work, what should be considered safe or even why. Don't hate me for saying it, but essentially Windows users. And this is the software they end up building and distributing. 10 years down the line, thousands have picked up random scraps of knowledge from here and there and tried to mash something together. Don't get me wrong, I think technologies like Docker are astonishing and an incredible tools in the hands of people with knowledge and experience. However way too many people have picked up some scraps from there and created the unholy mess the author is talking about.

</comment><comment><USER17> I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed.

It seems the concept was entirely alien to programmers younger than me.

<comment><USER18> > _without relying on any third-party servers being available and without > pulling in dependencies that might have changed._

There are two different issues here:

1\. Not pulling in changed dependencies. This is what "lock files" are for: To limit builds to known version of every dependency. npm was terrible about this for a long time. Most other language package managers are better.

2\. Not relying on third party servers to be available. Personally, I've mostly worked with Ruby's bundler and Rust's cargo, and in over 10 years, I've lost maybe two days of work because of package server outages. That's less than I've lost due to S3 outages, less than I've lost due to broken backup systems, and less than I've lost due to complex RAID failures. For the clients and employers in question, this was acceptable downtime.

In the rare cases where one day of noticeable build downtime every 5 years is unacceptable, then it's usually possible to just "vendor" the dependencies, usually by running a one-line command.

For many small to midsize businesses (and many growing startups), a small risk of brief outages is an acceptable engineering trade-off.

<comment><USER19> > npm was terrible about this for a long time.

That's putting it lightly. To me "terrible" would mean they just didn't support it, "batshit insane" means they supported lock files but ignored them every time you ran npm install.

My favorite comment from this stackoverflow post: [https://stackoverflow.com/questions/45022048/why-does-npm- in...](https://stackoverflow.com/questions/45022048/why-does-npm-install- rewrite-package-lock-json)

"Why would you expect something called package lock to lock the packages? Package lock is analogous to how, when you put any key into a door lock, the lock reshapes itself to match whatever key was put in, then opens the door. Now if you'll excuse me, I'm late for a tea party with a rabbit."

<comment><USER20> I think one of the scenes with Humpty Dumpty could be an appropriate allusion as well.

</comment></comment></comment></comment><comment><USER21> The maven/gradle ecosystem actually does use signatures. That's one of the things they got right. Maven central has no unsigned artifacts. Also, the signatures are actually checked on download. Other maven servers may be a bit more sloppy of course. In any case, if you are running that on a production system, you are doing it wrong. You run that as part of CI. The output of CI is containers which you start on a production machine.

The point about containers is that they should be immutable. Running chef/puppet in kubernetes is not a thing (I hope, probably somebody went there). Updating a container means replacing it with a new one, that hopefully you or somebody else built in a responsible way.

That last part is indeed a problem that we have moved instead of solved. 20 year ago, people were just sticking whatever they downloaded on hardware they bought at the store and banged on it until it worked (very literally sometimes). So, I guess this is progress but indeed hardly ideal. I remember using puppet. Can't say that that is with any level of fondness. I vastly prefer Dockerfile and having CI systems produce containers from those.

Installing things on a filesystem is no longer that common at deploy time unless that filesystem is that of the container you are building using a Dockerfile or you are self hosting kubernetes (aka. reinventing a lot of wheels at great cost). Puppet/chef etc. are still of use if you are doing that but otherwise it has a limited role in IAAS type architectures. The closest thing is perhaps pre-baking AMI images using packer and some tool like ansible, which is nice if you want to avoid having a lot of startup overhead.

Hadoop is complicated, which is why companies exist that host that for you or will help you hosting it on premise in a responsible way. If you want to DYI, you indeed have to do a lot of things and do them properly. Kubernetes has moved that space forward in recent years; so it's easier but this is not for everyone. If on the other hand you are messing with puppet to get this stuff done, maybe reflect on the wisdom of not standing on the shoulders of giants rather than blaming the internet for your self inflicted pain.

</comment><comment><USER22> Discussed at the time (443 comments): [https://news.ycombinator.com/item?id=9419188](https://news.ycombinator.com/item?id=9419188)

And again in 2018 (426 comments): [https://news.ycombinator.com/item?id=17083436](https://news.ycombinator.com/item?id=17083436)

<comment><USER23> But unfortunately, it's relevant to this day.

<comment><USER22> More than ever.

</comment></comment></comment><comment><USER24> Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison.

"Ever tried to security update a container?"

Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

<comment><USER25> The article focuses on Hadoop, but the generalization to containers is spot on.

Containers have become the first stop method to hide overly complicated build processes. When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip.

It seems to me that containers are useful for deploying final setups, but should be a no go for packaging tools.

<comment><USER26> >When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip.

On the other side of the coin, putting stuff in boxes is the essence of architecture. CPU opcodes? Boxes. Compiling readable code into bytecode? Boxes. Objects? Boxes. Functions? Boxes.

Sure, it can be abused. There might be spaghetti in those boxes. The spaghetti should be chopped into digestible chunks (smaller boxes!). But putting it in a box makes that an implementation detail. Putting stuff in boxes is still progress.

<comment><USER27> All problems in programming can be solved by adding another layer of abstraction (ie a box) - except too many layers of abstraction.

Good architecture is not about putting things into boxes, but about figuring out what boxes you need and which you do not. Sometimes a box is good, sometimes a box is bad. It isn't the fault of the box that it does't contain the right thing.

</comment></comment></comment></comment><comment><USER28> Standard Makefiles are really under appreciated today. They are simple and can be used with most any language, version controlled and have been around for decades.

<comment><USER29> They don't solve any dependency management problems.

<comment><USER30> Most ports like systems actually use makefiles to solve cross-package dependency management. (Whether that is good approach and whether writing what is essentially package manager as hairy ball of makefiles is good idea are another questions)

</comment></comment></comment><comment><USER31> ha +1 for the build tool mess. its like everyone goes "duuude this stuff is so complex lets build something on top to abstract it all away" and you end up with another level of complex stuff that builds the stuff that builds the that wraps the stuff that you originally wanted to use...

</comment><comment><USER32> I agree the last decade has been really tough for sysadmins, but the payoff is developers have had a great time and I dont have to rely on those guys any more.

<comment><USER33> Flash bulletin from the engine room: you're still relying on "these guys" (and gals), you're just cost-sharing our salaries across whatever pile-o-garbage SaaS you convinced your architect to engage, including my own large cloud provider. Hint: it'd be more effective (and cheaper) to employ us directly, but you do you.

That said, at the end of the day, I'm still sitting in my Aeron and your "great time" just means concentrating an entire discipline of professionals into cloud companies and ISPs. In this dream scenario (for who?), you get to sit around waiting for ticket updates while your revenue craters instead of picking up the phone or using that hole on your face to communicate with a peer. I get to focus on systems at scale and on monitoring and metrics instead of an annoying developer who escalates to their SVP and makes an inter-org ruckus when their TLS certificate expires and they can't find the error in their voluminous Javascript "logs". To be clear: I'm having a great time. There's a suspicious TAM in between me and you now, and you don't have my extension. I prayed for this day across many developer escalations and _still_ can't believe it's here.

Seriously, people who are likely replaceable with Microsoft Access and a few Thoughtworks clones shouldn't throw stones at the professions completely supporting their Blue Bottle habit.

Oh yeah, the Internet keeps on quietly working, too. Tip jar is to your left.

<comment><USER34> All the claims that cloud computing is some boon to developers makes me suspect they might just work at a terribly organized company.

If you make developers pull double duty as sysadmins, then outsourcing surely makes things better for development. But it's still more work than handing the infrastructure and administration over to people that specialize in that. A well managed service is a ticket away, not getting someone who "knows docker pretty good" to have another background responsibility to neglect until it sets on fire.

Throughout the cloud boom I've worked at a company with a great IT department, not just a glorified helpdesk. The division makes sure that we provide a sane deliverable that doesn't need constant handholding and 10 hotfixes a day, and they give us the peace of mind that it's not going to go sideways. They sweat the details so much that the rare issues that have escalated to the head of IT and myself at the same computer investigating something were still relatively minor in the grand scheme of things.

</comment></comment></comment><comment><USER35> And it seems to be getting worse lately with everyone talking about their cloud-y build "pipeline". Which invariably seems to involve stringing together a bunch of different service offerings from startups that might not be here tomorrow.

It's hard to imagine something more fragile

</comment><comment><USER36> I don't agree.

Systems are more complicated to build with a lot of dependencies that's true, but this is mitigated by shipping pre-built binaries and containers which have the dependencies bundled. Yes, those binaries can be from untrusted sources but if you use those you're taking a risk - the same as if you use code from an untrusted source (just because it's not compiled doesn't make it safe, when was the last time your organisation audited anything), ultimately a business should be using banaries from businesses they trust.

Containers actually increase security in the following ways: 1\. They run isolated from the host system and if you set things up properly they should be non root. 2\. They're immutable and cannot be tampered with. 3\. Because they work on layers you can change them without affecting the underlying container, to upgrade you can just replace the layer that you inherit from, simplifying the upgrade path (and being immutable, stateless, and versioned there's no risk to upgrading, you can very easily rollback). 4\. In the example listed above like Haddoop you can install the outdated version of Java that it depends on without compromising the host or other workloads on that server.

Of course, this all breaks down if you don't use containers from trusted sources and if you don't have processes in place.

It works in a modern environment with pipelines and automation, it doesn't work as well in a more traditional environment with sysadmins hand wrangling deployments.

Of course the most secure way to do things is to have deterministic builds of a codebase which creates a hash which you can compare with a canonical source, but this is tricky and not all build toolchains support this properly so you'll end up with mixed results. For a streamlined business the best compromise is to get applications from trusted vendors and rely on static analysis and the ability to quickly upgrade if a vulnerability is discovered.

Ultimately, the one of the best ways to secure a system is to establish an unbroken, audited, and automated trust chain and remove the ability for human intervention.

</comment><comment><USER37> Things will break and I will need to be able to debug them.

New versions will be released and I will need to be able to upgrade to them.

Bugs will be found and I may need to know if I or my users are experiencing them.

Security holes will be found and I will need to either upgrade, or mitigate them in some other fashion.

All of the above realities mean I want well defined and understandable software. The less well defined and understandable a deployment is, the less I am interested in deploying it. Complexity is a cost, and this cost cannot be waived by simply chucking everying into a container.

Simplicity means cheap. It means time not wasted and it means fewer headaches.

</comment><comment><USER38> The only part of this article that I really disagree with is the title. The main issue here is release engineering, or rather, the lack of it. Software development and system administration have well developed traditions, but release engineering doesn't seem to get much attention in comparison. Given that supply chain attacks are now all the rage in the black hat community, maybe release engineering will start to get the attention that it deserves.

</comment><comment><USER39> Amen. I avoid any container-based or blindly 'curl |sudo' install (the latter only after manual inspection of such a script).

Apps which only offer containers are untrustworthy black boxes. And it indicates devs who are too ignorant and/or lazy to make even basic efforts at distribution-neutral or portable code.

Gentoo and Funtoo keep devs honest to some extent, as packages must be built, not just slurped down in whatever alien form the project decided to use.

<comment> james-mcelwain I'm not sure about other container solutions, but Docker isn't a black box at all. It's fully introspectable -- I often dump a container's file system to see what's actually included.

</comment></comment><comment><USER40> I saw this comment now from 4 years ago on reddit:

Software packaging and building seems to be becoming more complicated and more disconnected-- particularly as more specific tools continue to be developed. It seems every little corner has their own dependency management and build management solution.

The Docker comments seem a little backhanded. If one looks at a Dockerfile, there's not much to complain about. It downloads a key, it adds a repository, installs a package, and some very simple docker-specific tweaks.

If you distrust Docker's signed image, building your own is as simple as doing a git clone ..; cd docker-nginx; docker build. Docker encourages disposable containers, separating data, and making your own images. There's still a lot of work for Docker to do regarding signed images, but I'd argue running isolated images with documented changesets and simple build files is far different from blindly running 'curl | sudo bash'

[https://old.reddit.com/r/programming/comments/33ktc9/the_sad...](https://old.reddit.com/r/programming/comments/33ktc9/the_sad_state_of_sysadmin_in_the_age_of_containers/cqlxne5/)

</comment><comment><USER41> So nearly 5 years later, is any of this any better? Also, why haven't Linux vendors standardized on a single package manager that is the default for ALL Linux distros? This seems like the equivalent hell that npm gives to NodeJS.

<comment><USER42> _> why haven't Linux vendors standardized on a single package manager that is the default for ALL Linux distros?_

The two distro package managers that "matter" (apt and rpm) are similar enough that this isn't a problem in practice. You can have fpm spit out a deb or rpm or arch pkg with just one flag change, and host it on your own website.

The real differences aren't just mechanical packaging differences, but more a question of philosophies, there are a lot of differences in upstream distro packaging policies themselves. Debian isn't going to let you upload it directly unless it is a good citizen on their distro, stays up-to-date with their versions of all dependencies (so that you only end up with one python, libjpeg etc on your system) and is certifiably free software down to the bones. Whereas Arch will take literally anything in the AUR, and the fast way into CentOS is to be employed by RH (paraphrasing).

(I tried to package a certain app in RPM, but it turns out that OpenSuSE and CentOS have different names for the tzdata package, and until very recently rpm didn't even have a system for specifying alternate dependencies.)

</comment></comment><comment><USER43> I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use where applicable and hope for better days.

<comment><USER44> I don't think you should put security at any case in tradeoff, by your argument one can save passwords in plaintext because its easy and comfortable, but its just not acceptable and this would effect not only your app but every app that your users use.

<comment><USER45> I see the value when running e.g. home instrastructure on some old laptops or other non-critical stuff. Most people have NAT at home and thus whatever services they pull and listen in their local network aren't exposed to the outside world, and they can enjoy mopidy/NextCloud/whatever without going through a lot of hassle setting it up.

Of course once we come to enterprise environments the opaque build/deployment process is atrocious.

<comment><USER46> 30% of the Internet already uses IPv6. NAT is obsolete and was never supposed to be used for security anyway...

</comment></comment></comment></comment><comment><USER47> So you dont want to run (insert software here, like your IDE) in the cloud, and you dont want to run it yourself because you dont trust it (its open source). Then how do you want it delivered? Snaps? Docker? KVM image?

<comment><USER48> In an InstallShield package, with a 7-step license activation process.

Let's face it, security is an asymptote. I just want someone I can call and scream at when we eventually get pwned and I'm ready to pay for that privilege.

</comment></comment><comment><USER49> This post reminded me of an old article: [https://blog.codinghorror.com/vampires-programmers-versus- we...](https://blog.codinghorror.com/vampires-programmers-versus-werewolves- sysadmins/)

The big win for 'containers' is that they separate the concerns of sysadmins from developers. The days of the sysadmin administering the tomcat and apache installs are shortly coming to an end. For my part, i think this is a good thing because devs and sysadmins have different concerns that don't overlap all the time.

</comment><comment> kube-system Using stuff blindly from Docker Hub is a bit sketch, but it's not a hard problem to fix. Read the dockerfile before using it, adjust if you don't like it, and build and push to your own repo. Then run your vulnerability scans of choice on them nightly.

</comment><comment><USER50> "Consider for example Hadoop. Nobody seems to know how to build Hadoop from scratch. It's an incredible mess of dependencies, version requirements and build tools." And that's exactly what's wrong with a half of the software industry. Some people even take pride in thinking that having dependency hell is a good thing. A lot of build tools look like they are created by aliens to aliens with little thought of how the end user would use it. And if someone dares to say how crappy the whole thing is, they get dismissed for not being smart enough or simply lack dedication to spend unlimited hours trying to build some 500 line code.

</comment><comment><USER51> I'm looking at this from a relatively neutral newbie POV. I've tipped my toes in both administering machines the "classic" way and with tools like Docker and Docker Compose. To me both have their benefits and drawbacks but Docker looks a bit better overall. Here's why:

1) The idea of immutable systems rocks. It feels like the logical next step from containers.

2) This is maybe just because of me but I have the feeling services that can easily be (automatically) updated (like with Docker) are gonna be more up-to- date on average than when I have to build every new version myself. (Although that could be automated probably.)

</comment><comment><USER52> [http://kmkeen.com/maintainers-matter/](http://kmkeen.com/maintainers-matter/)

</comment><comment><USER53> Uh... I've built Hadoop from source, it is not that bad.

<comment><USER54> I've also built it from source, admittedly back in 2012. It wasn't that bad, either! My concerns were building an AMI image, not "packaging" it in a more traditional sense.

<comment><USER53> I think most of the conventional image building tools are stupid. (e.g. they take something that could be done in 10 minutes and make it take an hour, are prone to failure because of too many round trips, ...)

I made rather complex images that included a large database (e.g. 30 GB) and Java apps, and found the easy way to do it was write a program that analyzes the problem, writes a shell script that builds a bastion and builds the software, then put that in the cloud-init... The machine "phones home" via SQS to tell the controlling server to shut it down and image it.

</comment></comment></comment><comment><USER55> [https://xkcd.com/1988/](https://xkcd.com/1988/)

</comment><comment><USER56> Looked at the Debian wiki the OP linked to:

>Debian currently does not include Hadoop packages. There are a number of reasons for this; in particular the Hadoop build process will load various dependencies via Maven instead of using distribution-supplied packages. Java projects like this are unfortunately not easy to package because of interdependencies; and unfortunately the Hadoop stack is full of odd dependencies (including Apache Forrest, which for a long time only worked with Java = 1.5).

>If you want to build Debian packages, the most complete efforts can be found at the Apache Bigtop project [http://bigtop.apache.org/](http://bigtop.apache.org/) . __Unfortunately, the build process for these packages is currently of a disastrous quality, and should only be attempted within disposable virtual machines, as it requires root permissions and will install non-packaged software. __

> These will allow building Hadoop packages on a recent Debian system. > __However, the resulting packages do not live up to Debian quality > standards. In particular, they include copies of .jar files from other > packages, and will thus not benefit from security updates done to these > packages. __

> If you are interested in getting Hadoop packages into Debian,

        Coordinate with the Java packaging team
        Coordinate with upstream Apache Bigtop

>to avoid duplicate efforts. Thank you.

[https://wiki.debian.org/Hadoop](https://wiki.debian.org/Hadoop)

Jesus Christ.

<comment><USER57> Who still uses Hadoop anyway?

[https://spark.apache.org/](https://spark.apache.org/) [https://www.iguazio.com/data-science-post- hadoop/](https://www.iguazio.com/data-science-post-hadoop/)

<comment><USER56> Spark is worse because you need Scala as well as regular Java.

I've tried building it for my day job, I would rather have a colonoscopy without sedation.

It's more pleasant and dignified.

<comment><USER58> And then add PySpark on top of that. Couldn't leave my last job fast enough when they decided to use Hadoop/PySpark when the largest incoming files we received were at most a few GBs.

<comment><USER59> I once had a consulting gig where the customer desperately wanted to build a Spark/Scala ML pipeline, for a dataset that was 10 MB. We spent 3 months hammering it together for a flat Python process that would've taken us 2 weeks.

<comment><USER60> > This find xargs mawk pipeline gets us down to a runtime of about 12 seconds, > or about 270MB/sec, which is around 235 times faster than the Hadoop > implementation.

[https://adamdrake.com/command-line-tools-can- be-235x-faster-...](https://adamdrake.com/command-line-tools-can- be-235x-faster-than-your-hadoop-cluster.html)

</comment></comment></comment></comment></comment></comment><comment><USER61> Before containers, I had sysadmins who ran our AIX cluster. Three nodes, not a single one configured like the other. There was zero consistency where it counted and these jokers would go on a terminal and manually configure Websphere and other components and screw it up constantly. We even tried to give them a terminal tool where you could type in one window and it would mirror on other boxes, but they refused to use it.

Puppet, Chef, Ansible, all led the way to something better. Docker and Kubernetes feel so far advanced from what we had in 2012.

</comment><comment><USER62> Yes, it's worse than that on a couple of fronts. Cloudera, Amazon and others benefit financially from situations of over-complicated messiness, while average SWEs, SAs and others are left with wasted time, money and lack of trust. And worse, lax engineering and operations practices introduce attack surfaces to fraudsters, thieves, organized crime and state-level actors to backdoor, destroy, steal, extort and monetize infrastructure of organizations large and small.

</comment><comment><USER63> Give me rsync and a sysadmin any day over a circle jerking dev ops team.

<comment><USER64> Amazon and some other FAANGs build and deploy OS packages, and by choice.

Sad to see how anything that is not container gets downvoted here.

</comment></comment><comment><USER65> The same applies today for nodejs and go, but the same was happening with python, ruby and perl libraries in the past.

However, this only shows that standard distro packaging approach is broken or was broken all the time. First, if you want to distribute you application (or library) via distro packages, you'd either have to build them and publish on your site or have to go through long mailing process to satisfy distro specific packaging guidelines and hope that your package will end up in standard (or extended) distribution. Debian is also notorious for "reviewing" and modifying source code, without contacting authors (remember Debian SSH fiasco).

I had, not once, unpleasant experience with this process.

Today, things are much easier - pack your whatever and put on dockerhub, maven or github. No middleman and no headaches just to reach your users. Sure, there are drawbacks (like mentioned in article), but we'd have to leverage things like GPG and proper package signing. Now, that is totally different story, because cryptography, even the basic one, is PITA for most developers and users. You can't have both :D</comment>


ClojureScript Year in Review - <AUTHOR> http://swannodette.github.io/2015/12/23/year-in-review/ <comment><USER2> Clojurescript has made me excited about frontend again.

</comment><comment><USER3> I think that cljs-devtools [1] also deserves honorable mention. Not only does this improve console output, but it improves inspection while doing interactive debugging (e.g., pause on exception) in Chrome.

[1] [https://github.com/binaryage/cljs- devtools](https://github.com/binaryage/cljs-devtools)

<comment><USER4> Thanks for the plug. I'm glad you find it useful.

I've been working on Dirac - a Chrome DevTools fork for ClojureScript developers. That will be a complementary tool to cljs-devtools: [https://github.com/binaryage/dirac](https://github.com/binaryage/dirac)

</comment></comment><comment><USER5> For devcards, you can see the full strangeloop talk about the tool here: [https://www.youtube.com/watch?v=G7Z_g2fnEDg](https://www.youtube.com/watch?v=G7Z_g2fnEDg)

<comment><USER6> I meant to link to that one actually. Thanks for the catch, post updated.

</comment></comment><comment><USER7> Really intresting clojure and clojurescript seems to be wonderfully designed and with the advancements that's going to take place in jvm I hope it can be as good at performance as java or Go.

<comment><USER8> I don't know about Go, but it certainly is as fast as Java. And it can definitely be faster than your average Java program, because you will have a really easy time doing concurrency. That is why it is a neat language, worth investigating.

It is by default slower than Java and Go because the default data structures are immutable. When execution speed is more important than statelessness you can make your data structures mutable.

Read more about that here [http://clojure.org/transients](http://clojure.org/transients)

Happy holidays :)

</comment></comment><comment><USER9> Parinfer is the craziest lisp exponent ever. I highly recommend any curious and / or skeptical dev to download Atom, install it, and give it a shot. This book also helps: [http://funcool.github.io/clojurescript- unraveled](http://funcool.github.io/clojurescript-unraveled)

From straight up confusion to basic productivity in just a week, it has also completely removed the learning fear. Highest regards to this beautiful tool that will hopefully bring lisp to the masses.

<comment><USER10> Thank you for the kind comment :) I'm glad you like atom-parinfer!

</comment></comment><comment><USER11> ClojureScript will enrich your mind but at some point you might get tempted, as I have, to switch to ES6/7 via the Babel route and enjoy the benefits of a much more diverse ecosystem, with your ClojureScript-enhanced perspective. Same with Elm and Haskell and prefty much any language wortg learning. In fact, learning a new language esp one drom a different world will always expand your horizon and I can't over recommend ClojureScript as one of those enlightenment languages.

<comment><USER12> I switched to using ClojureScript in prod last year and couldn't be happier. The Js interop is great, ClojureScript is fast, and the runtime is pretty small. I simply can imagine any reason to bother with ES6/7 at this point as they will offer nothing that's not already available in ClojureScript right now.

You also get a clean and well designed language as opposed to a mountain of kludges that is current state of Js [https://twitter.com/capotej/status/677926991513780225](https://twitter.com/capotej/status/677926991513780225)

</comment></comment><comment><USER13> I'm exploring ClojureScript via the re-frame SPA pattern and it got me really excited about UI development again. What's the best way to sync data with a REST server backend?

<comment><USER14> I recommend the following: 1) read up on how Om.Next handles remote calls. Not that it's the only way to do it, but it de-couples the async functionality of a remote call from the rendering loop. 2) Just code against something like Google Closure's XHR libraries, making a HTTP call isn't complicated, just wrap basic functions to suit your needs.

But over all, no matter what you use, core.async, or callbacks or whatever, limit the async bits to the edges of your code. Done correctly (Om.Next is a great example) you shouldn't need a whole lot of async bits to get a nice clean app. If you have core.async "go" blocks littered all through your codebase, you're doing something wrong.

</comment></comment><comment><USER15> Diving into clj/s 4 months ago was such a wonderful, arbitrary decision. The #clojure community on Freenode is friendly and wildly clever. They are delighted to answer your Clojure questions. The language itself is great. It's a terrific language for a CS Sophomore to pick up after learning Scheme and Java.

My one complaint with cljs has been the difficulty of configuring Ring HTTP beyond the trivial SPA defaults: getting it to respond to other URL requests, other types of HTTP requests. I spent close to 3 hours trying to configure it to accept a POST action before finally giving up, frustrated by the opaque stack traces that went >1000 frames deep. 20 minutes later, I had an Apache server up and running. So it wasn't really a big deal, but I can't remember the last time I felt so baffled by a problem that I simply had to throw in the towel.

<comment><USER12> I put together the Luminus micro-framework [http://www.luminusweb.net/](http://www.luminusweb.net/) to help with this kind of stuff. The docs provide lots of examples on how to get stuff done. For example, here's the section on doing Ajax with ClojureSCript [http://www.luminusweb.net/docs/clojurescript.md#ajax](http://www.luminusweb.net/docs/clojurescript.md#ajax)

<comment><USER15> Thanks for putting this together. This looks like a fantastic tool, and really well-documented. I noticed from a quick perusal of the docs that Luminus still requires a handler function to map URLs to a named page asset (about-page, home-page, etc.) using defroutes -- requiring too, of course, definitions for each of those pages. Could you explain in a few words why that is? Is it a Node requirement? Isn't that a lot of complexity to have to deal with? If so, how do people manage it?

I'm just curious because my only exposure to the HTTP layer so far has been via Apache. Apache is... for lack of a better word, a bro. It's up for just about anything. It seems like the default mode of Apache is to do whatever the HTML recommends. Apache is happy to serve an arbitrary "/about.html" URL, provided it exists, and asynchronously execute any server-side scripts to which it injects a dependency. I don't know if this strictly requires the use of jQuery, but it certainly seems easier to do it that way. Is it even possible to serve a cljs app this way? In light of the fact that jQuery is not compatible with the Google Closure compiler?

</comment></comment></comment><comment><USER16> Very cool to see such a robust community.

As far as self-compilation, I haven't seen anything on how to compile a ClojureScript project without Java, is there an article somewhere on how to do so?

<comment><USER14> One of the reasons that ClojureScript is so fast and efficient is that it leans heavily on the Google Closure optimizing compiler. This compiler goes beyond normal "minimzation" and goes into dead code removal, function inlining and a ton of other stuff. That compiler is written in Java. So it's highly unlikely that JVM is removed as a dev-time requirement anytime in the near future.

On the other hand, I have never really seen a need to remove it. Once the CLJS compiler is up and running, incremental compilations on huge codebases (~300 files) takes a fraction of a second. So in the end...I'd rather have the JVM as a requirement if it allows that fast of a dev cycle.

<comment><USER17> Another reason is that is doesn't do all the things that standard Clojure does, which are the actual cause for slowness, it is not the JVM.

[http://blog.ndk.io/2014/02/11/jvm-slow- startup.html](http://blog.ndk.io/2014/02/11/jvm-slow-startup.html)

</comment></comment></comment><comment><USER18> They do seem to be doing really nice things. And from time to time I try to keep up, watching videos on new tools and things.

But I guess I always get hung up on the idea that you should just write in the language that you're targeting, and I wonder about the cost of the (admittedly pretty nice) developer experience of cljs. When you have a bug in production you're stuck debugging the generated JS. This was also my problem with CoffeeScript.

<comment><USER12> I've been using ClojureScript in production for about a year now. The runtime is very fast, and in some cases it actually outperforms native Js. For example, both Om and Reagent are actually faster than React.js itself ([http://www.youtube.com/watch?v=VSdnJDO- xdg&t=9m36s](http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s)).

Debugging story is very good. You pretty much never have to see the generated JavaScript. ClojureScript uses source maps, so any errors in the compiled Js will map back to the original ClojureScript source that caused them. Chrome dev tools even do syntax highlighting for ClojureScript now.

Having a live dev environment with Figwheel and a REPL goes a long way here as well. You can inspect a lot of things at runtime very easily.

Using immutable data structures by default avoids a lot of the debugging pain as well. You practically never have to trace through a bunch of function calls to find the problem. In most cases the problem is exactly on the line where the error occurred.

<comment><USER18> What if your thing crashes in IE?

<comment><USER12> IE 11 supports source maps, so that's helpful. The other nice thing is that you rarely end up dealing with browser specific quirks since all popular ClojureScript libraries piggie back on React.js and the Google Closure library.

These do a great job of handling the platform specific quirks for you. The first app I developed with Reagent actually had to run on IE8, and to my shock and surprised worked without any issues after I added the standard IE shims.

So, overall my experience is that you're better off dealing with IE than with most Js frameworks.

</comment></comment></comment></comment><comment><USER19> I highly recommend devs (especially JS devs) try out a Clojure/script project. The tooling has improved immensely, and Cursive is one hell of an IDE. JS devs will really appreciate how clearly you can express these seemingly new frontend paradigms (immutability, one way data flow, single source of state) in Clojure.

Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: [https://github.com/danielsz/holygrail](https://github.com/danielsz/holygrail)

I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?

<comment><USER20> I have nothing to say on Lein vs Boot, but I'm a long-term emacers with > 10 years and I can't endorse Cursive strongly enough. I've got easily at least 1k hours in my .emacs.d. Suffice it to say, it takes a lot to take away from Emacs/SLIME. Never bought into the Textmate hype during the Ruby days, or the SublimeText hype subsequently because Emacs already had all that functionality if not out of the box, there certainly was someone with an .el I could borrow. It takes _a lot_ for me to leave Emacs, _especially_ for a LISP.

Here's my 2 cents - _Cursive is worth it_. (Hey Ideogram folks, if you want an endorsement, feel free to use that paragraph in exchange for a lifetime license ;)). For one-off-scripts, for back-end solutions, and what tipped me over the edge, it's CLJS script integration goes beyond acceptable -- it's actually _fun_ to work in-- Cursive is my go-to. Om and Figwheel (optionally with Prismatic Schema if you like type guarantees) makes web development's feedback loop a lot tighter.

Rich Hickey assembled a team of just _insanely_ talented and charismatic(1) developers who not only are a) remarkably intelligent but b) know when to steal ideas and integrate them [none of that too-proud-NIH-syndrome there], and c) know how to interact in a way to that is community-feedback-positive(2) so people contribute. Watch this talk by David Nolen [https://www.youtube.com/watch?v=ByNs9TG30E8](https://www.youtube.com/watch?v=ByNs9TG30E8) (CLJS lead). [Sidebar - He even mentions how that whole immutable, one way data flow, datomic-ish single state idea existed in other languages, but read (2) on that].

Anyways, Cursive + Lein + ClojureScript + Om is the holy grail for me right now. On the other hand, that nREPL/cider/boot setup is what I'd be using as a long-time emacs'er were I to give up Cursive.

(1) Having someone like Hickey or Nolen to shepherd ideas is actually really important in garnering traction. Developers go to conferences and when everyones talking about that 4PM Thursday talk that someone gave, it really resonates within the community for quite a while. I like Perl 6's ideas but if you've ever seen Larry Wall talk, well, yeah. (2) Some communities _cough Haskell_ have great ideas, Lenses, FRP, applying (pun not intended) monoids -> functors -> applicative functors -> monads was genius. But for some reason the barrier to entry is so high (even for me with a fairly advanced math background) that concepts remain isolated within the community. LINQ is a monad (though few know it) and it took Brian Beckman (or Anders, or Bart de Smet, or whomever) to take it into C# to make the concept widely used by the Joe-the-programmer (again, pun not intended).

<comment> eric-hu I've been a vim user for a number of years and have fiddled with building in Clojure support at different times with repl support, syntax highlighting and other basics. My success was varying and incomplete. Tooling has been a barrier for me learning Clojure. Half the time I want to learn or practice Clojure, I remember gaps in my tooling. Subsequently, I spend a few hours yak- shaving to improve it.

I've contemplated learning Emacs because of the general praise for its workflow in the Clojure community. I even know some basic emacs from bash scripting. Switching just seemed like it would add another learning block to an already long list of tools to learn. Cursive, on the other hand, is based on IntelliJ, which is familiar to me through RubyMine.

Thanks for taking the time to write up about Cursive. You just convinced me to finally install it and give it a shot.

<comment><USER21> As a fellow vim user and full time clojure dev, I should point out that spacemacs is pretty great for getting the best of vim and emacs in one editor.

But to get up and running and try things out? Use Cursive until you are comfortable, don't get distracted by tooling problems (which there _will_ be).

</comment></comment></comment></comment><comment><USER22> Since the GSoC project mentioned still seems to be incomplete, can anyone suggest a way to use npm/es2015 modules with cljs applications for the browser?

I build the first version of my app with cljs, and it was the cleanest/simplest code I ever wrote. Just the lack of npm interoperability makes in non-viable for me.

Anyone tried systemjs with cljs?

<comment><USER23> The simplest approach that works for this at the moment is to have something like webpack build a UMD bundle and then add that bundle as a foreign lib.</comment></comment>


Infinite Anonymous and Secure Flash Drive - <AUTHOR> https://flash.so/ <comment><USER2> > In case of Flashsafe the device will be blocked and you will get a new one.

How does it know when to brick the device?</comment>


Ask HN: Follow up for feedback a second time? - <AUTHOR> Hey HN,
I have been applying to jobs all over NYC. I've completed a few interviews. I ask for feedback immediately from all of them. Often, I don't get a response.
Question: Would it be unwise to send a second response asking again?
I understand people are busy, but you would think if they were making an informed decision on multiple candidates they would have shared feedback about the candidates at some point? As long as the feedback isn't "sorry, you didn't have what it takes" it's probably valuable feedback. Just be honest. <comment><USER2> To me, the right way to follow up is personally with one of the individuals you met during the interview process...i.e. in the context of professional networking rather than a job search. Networking provides value to the other party because networking is a two way street. "Give me feedback" is one way, all about you, and work for the other person. It is also risk because the reason companies in the US don't provide feedback is to limit the risk of being sued.

To put it in context, be ok with not getting hired this time (yeah I know it sucks). But the long term is about relationships. Asking for feedback for a position creates a context in which someone is unlikely to say, "I know this other company that's hiring and <important person at other company> is a friend/customer/acquaintance of mine. Here is their contact information."

I'd put it this way, if someone gave you the impression that it is a good idea to ask for feedback following an interview in the US, that is an impression to remove from your mind. It raises the concern that you might want to argue over the feedback. If a company interviews six people for a position, most or all of them won't get hired.

One way to work the networking side is simply to try to connect on Linkedin the next day as follow up. It's low effort on the other person's part to open the door to future interaction while allowing them to signal that they are not interested in a passive, non-confrontational way or carefully consider their response.

Good luck.</comment>


Chat with the 17 year old hacker who hacked my blog  - <AUTHOR> http://thenextweb.com/2009/11/28/chat-hacker-hacked-blog/

<comment><USER2> It doesnt take a 'skilled hacker' much effort to use the tools others have released. I cant imagine the author's blog being hacked as anything more than mere button pushing. A 'script kiddy' really.

<comment><AUTHOR> I agree. But still interesting why he does it.

<comment><USER3> I think that the 'why' looses it intrigue when you consider that there is little done to convey their purpose to anyone other than 1)the pissed off blog owner and 2)their competing frienemies and script kiddies...

"... we do this to protest against somethings, for example the last month I think there was a genocide agains the Uygurs in the west of China and we just hacked around one thousand websites of the chinesse government. Our web page is: www.ayyildiz.org..."

It seems more is said in this short interview about their supposed 'moral motivations' and logic for these attacks than the attacks themselves actually conveyed.

To make a real stance against something, wouldn't it prove far more beneficial to compose a multi language (Translate) well thought out argument instead of posting a few Turkish sentences and a flag Gif as a protest? A few lines of CSS and javascript to actually provide usable reference and material to viewers about what it is you feel strongly enough about to actually hack another's property over?

I feel like this type of hack is more of a <i>"I'm a rebel (because I am a kid) and am going to tag this bridge because I have a can of paint and no one is there to catch me doing it - I'm a protester because I tagged it 'Pigs suck!'"</i>

But again, in my day when 16 year olds where 'acting out against society' with netbus and BackOrifice on my school pcs

<comment><AUTHOR> For me its another example for how the term "hacker" is being wrongly generalized and how easy its to claim to be one.

</comment></comment></comment></comment><comment><USER4> The guy who got "hacked" (see colbyolson's post) couldn't keep his bias out of the conversation, ruined it for me. That and the guy comparing changing the page of a blog to stealing.

There could have been a lot more interesting questions asked.

<comment><USER5> Considering the situation, a crime victim interviewing the perp, I thought he was quite effective at eliciting feedback. I suppose it's not surprising this 17 year old has the ethics of a sociopath. When I read he wants to become a broker, LOL.

<comment><USER4> Yeah, sorry, this isn't a rape victim or someone who was mugged. A few lines of code got changed in a website that didn't (easily) update their plugins.

The 17 year old was being a 17 year old.

</comment></comment></comment><comment><USER6> The defacing/rooting hackers are always the young and bright ones it seems. It's fun to watch how the trend continues over the years, and has spread to all corners of the world.

</comment><comment><USER7> Would have been a lot more interesting if he had actually gained root and explained how he pulled that off.

</comment><comment><USER8> What's interesting is all the comments on that blog, saying how someone who can download an automatic deface script "can make money with websites". I thought the general public had a better understanding of the Internet these days :)</comment>


Heuristics, Biases & Rationality - <AUTHOR> http://www.vimeo.com/2648376 The study of reproducible errors of human reasoning, and what these errors reveal about underlying mental processes, is known as the heuristics and biases program in cognitive psychology. This program has made discoveries highly relevant to assessors of global catastrophic risks. Eliezer Yudkowsky, who writes on the subject of cognitive biases at Overcoming Bias, presented at the Global Catastrophic Risks conference in Mountain View was on the subject of cognitive biases in the assessment of risk. <comment><USER2> something that particularly jumped out at me was the mention of biases in relation to the jury trial. Since we know that people are prone to making these types of errors consistently lawyers can take advantage of it. Is there any reason to think that professional rationalists wouldn't make better jurors than "a jury of peers"?

<comment><USER3> A problem with rationalists is that to make oneself truly rational they have to somewhat kill their instinctive, spirited side. But, the instinctive, spirit side is based on millions of years of evolution. So, the rationalist is missing out on a massive chunk of life.

A good combo is Kirk/Spock, Hamlet/Horatio.

<comment><USER4> Rationality also doesn't provide you with goals, only means to achieve goals.</comment></comment></comment>


Fanboy to Facebook: I Don't Know How to Quit You. - <AUTHOR> http://500hats.typepad.com/500blogs/2007/10/fanboy-to-faceb.html <comment><USER2> I know this is supposed to be a humorous article, but to me there's something profoundly sad here.</comment>


Colleges Weighing 3-Year Degrees to Save Undergrads Time, Money - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2009/05/22/AR2009052203681.html?wprss=rss_print <comment><USER2> So implying that current degrees are a waste of time and money?</comment>


What do colors mean to your users - <AUTHOR> http://www.joehallock.com/edu/COM498/associations.html

<comment><USER2> The rest of our site is brown/gold but we chose blue for our payment page for exactly this reason.

<http://i.imgur.com/2WcOF.jpg> (You have to be logged in to see the payment page so I took a screen shot)

The pattern at the bottom is also designed to invoke the feeling of banking. It's kind of like the patterns you see on cheques or credit cards.

</comment><comment><USER3> I think that these perceptions can be influenced.

For example, if Ferrari runs ads with only its yellow models for the next 10 years, more people might start associating Yellow with Speed, instead of an overwhelming vote for red

<comment><USER4> color association is an evolutionary development and wasn't invented by Ferrari. look at the world of nature for evidence.

the first Ferrari was yellow anyway, their first racing cars used the Italian national racing color which is "Rosso Corsa".

</comment></comment><comment><USER5> These 3D pie charts are the worst. <http://www.stevefenton.co.uk/Content/Pie- Charts-Are-Bad/>

</comment><comment><USER6> does that mean the denver broncos football team is then fun, high quality, we trust you to win, but we hate the colors?

thats what i get when i translate the blue and orange team colors against those pie charts.

<http://www.denverbroncos.com/>

the translation also works for GE (blue and white)

</comment><comment><USER7> So, according to this, your startup dominant color should be Blue?

<comment><USER8> It seems so.. it might be the reason why Zuck chose blue and still sticks to it, although some people argue it's terrible and childish.

</comment></comment><comment><USER8> I have observed myself that men tend to hate purple as a UI background color, while women like it. I have not seen that many high-quality sites with a deep purple backbround, but when I did, the designer was female. These numbers got something.

</comment><comment><USER9> As always with aesthetics.

Different cultures have different ways of interpreting it.

</comment><comment><USER10> Maybe this is simply personal opinion, but I generally find it difficult to take aesthetic advice from a website with a relatively uninspired or outdated design like this. Perhaps I just have bad taste

<comment><USER11> Judging by the credits ( <http://www.joehallock.com/edu/COM498/credits.html> ) I think this was created in 2003.

</comment></comment><comment><USER12> Ow. That site is unreadable.</comment>


Show HN: Eslisp – Minimal JavaScript S-expression syntax and macro system - <AUTHOR> https://github.com/anko/eslisp <comment><USER2> To my taste, Lisp's hierarchical list notation is by far the most natural, intuitive way to represent HTML. I exploited this Lisp feature to create a web server using Scheme and C (a 5-year project).

While my server still works well, it's obvious Node and JS have become predominant tools in the space. I used these tools for my most recent project and while not too difficult to get up to speed, it lacked the elegance and simplicity I preferred.

Eslisp looks promising, surprisingly close to Lisp/Scheme I'm familiar with. I'm thinking that a few changes might make it even closer. For example, one could use "define" instead of "=" to declare bindings, or "begin" instead of "block".

The "this" syntax in macros is reminiscent of the arguments to ER syntax transformers which can be used to operate on elements in macros. Is it possible to simplify it further? Something like (this/evaluate) instead of (. this evaluate)?

Just ideas that pop into mind...

I agree that using s-expr syntax to create macros makes is much better than the elaborate syntax of other JS macro systems. I'm looking forward to learning more and trying it out.

Eslisp looks like it will be excellent.

<comment><AUTHOR> Many thanks for your thoughts.

> Lisp's hierarchical list notation is by far the most natural, intuitive way > to represent HTML.

HTML-representation is also important to me, and it's how I got started on eslisp actually. I wrote an XML templater [https://github.com/anko/whatxml](https://github.com/anko/whatxml) for LiveScript that abused the ".." cascaded-function-call feature to create XML hierarchies. It took me a while to realise it was basically an S-expression in disguise!

I'm working on an "eslisp-html"-macro that compiles to an HTML-templating function. Here's the gist of it so far [https://gist.github.com/anko/f8ecc66a99a8ec656b49](https://gist.github.com/anko/f8ecc66a99a8ec656b49) No implementation yet, just an early-ideas readme with an example. What do you think?

> For example, one could use "define" instead of "=" to declare bindings, or > "begin" instead of "block".

If you want to use different names for the built-in macros, you are welcome to. Aliasing them is just a matter of "(macro define =)", then "define" does the same as "=".

> The "this" syntax in macros is reminiscent of the arguments to ER syntax > transformers which can be used to operate on elements in macros. Is it > possible to simplify it further? Something like (this/evaluate) instead of > (. this evaluate)?

Property access can be sugared to "this.evaluate" with the eslisp-propertify macro [https://github.com/anko/eslisp- propertify](https://github.com/anko/eslisp-propertify) It's quite convenient if you use it as a transform macro [https://github.com/anko/eslisp/blob/master/doc/how-macros- wo...](https://github.com/anko/eslisp/blob/master/doc/how-macros- work.markdown#transform-macros) from the command line, like this [https://github.com/anko/eslisp-fancy- function/blob/master/ma...](https://github.com/anko/eslisp-fancy- function/blob/master/makefile#L6) Is that what you mean?

<comment><USER2> > ...an "eslisp-html"-macro that compiles to an HTML-templating function... > Here's the gist of it so far ... What do you think?

Interesting! Similar to Scheme templates:

        (let* ((admintype (...))
               ...
               (htm (htdoc
                  `(html
                     (head
                       (meta (@ title "My site")))
                     (body
                       (div (@ class "banner")
                         (img (@ class "logo" src "logo.gif"
                                 title ,(get-curr-url))) ...

Basically it just sets up variables for use in the let* scope, and calling the htdoc procedure that parses the quasiquoted list, returning the prepared html as a string (written to the client-connected socket).

The htdoc proc is surprisingly simple, and I've implemented it in other Lispy languages without much trouble. I'd be real interested to try it in Eslisp once I'm familiar enough with it.

> Property access can be sugared to "this.evaluate" with the eslisp-propertify > macro ... Is that what you mean?

Possibly. I need to learn it more thoroughly.

Of course I realize the "(. id1 id2 ...)" form expands to object notation. My comment just reflected that to me the leading dot expression looks "noisy", a bit distracting.

In Scheme, identifiers can contain punctuation like ".", so "this.evaluate" could name a procedure, macro, etc. To my eyes, "(this.evaluate)" is visually easier to parse. In my head, the string "this.evaluate" looks like an atom that expands to the operator this.evaluate(), which I think is what it means.

I'm sure I'll get used to the notation as it is, this is just my immediate impression. However, mildly "sugaring" the representation might make it more accessible, especially to people not already enlightened by and in awe of the magic of s-expr.

Edit: getting the code section to look like code...

</comment></comment></comment><comment><USER3> Listen to an old man that has gotten his feet wet with Allegro Common Lisp back in the day:

Avoid macros if at all possible. Use functions if you can.

Special forms that don't follow the standard evaluation rules are putting additional mental load on the readers of your code. If you go overboard with macro use, good luck having other people understand your code.

If you are a lone coder, feel free to go happy-crazy with macros. If you are a team, just stay with standard lisp as long as you can.

<comment><USER4> You do not understand macros at all. One should _always_ prefer macros to anything else. Macros must be used to implement hierarchies of composable eDSLs - by far the most powerful and advanced way to handle abstraction. Functions are not a match to this.

Heavily DLSed code is much more readable and maintainable than your mess of functions.

</comment></comment><comment><USER5> Fun :) Back in my Racket days (back then it was known as PLT Scheme and dinosaurs roamed the web) I did a similar thing:

[http://planet.racket-lang.org/package- source/dherman/javascr...](http://planet.racket-lang.org/package- source/dherman/javascript.plt/9/2/planet-docs/javascript/pjs.html)

The Javadot notation was really convenient -- might be worth checking out:

[http://jscheme.sourceforge.net/jscheme/doc/javadot.html](http://jscheme.sourceforge.net/jscheme/doc/javadot.html)

<comment><AUTHOR> Wow, many thanks for sharing!

PJS is very neat and its documentation very clear. I'm surprised how little JavaScript has changed in 16 years…

I've got a Javadot-like thing [https://github.com/anko/eslisp- propertify](https://github.com/anko/eslisp-propertify) for converting a.b.c → (. a b c). Eslisp uses "." for property access, like PJS' "field". It hasn't got a next-line (.property args) thing though, which seems useful. I'll be trying that.

</comment></comment><comment><USER6> How does its macrology stack up against sweetjs? [http://sweetjs.org](http://sweetjs.org)

<comment><AUTHOR> Eslisp macros are compile-time functions that operate on code consisting of lists.

Sweet.js macros are special-case separate structures that have to introduce special syntax, pattern-matching rules and a whole lot of other cruft, mainly to deal with JavaScript not being homoiconic.

tldr eslisp macros are prettier, otherwise quite similar.

</comment></comment><comment><USER7> Looks great. At the very least it needs a built-in function shortcut; people are already used to ES6/Coffeescript shortcuts. Yes, I understand I can probably macro it myself, but that doesn't mean it's not needed in core. Anyway, looks like a great piece of work!

<comment><AUTHOR> If you mean shortcuts like argument-splats and implicit return-statements, [https://github.com/anko/eslisp-fancy- function](https://github.com/anko/eslisp-fancy-function) is on npm.

All you need is to npm install it and do

        (macro function (require "eslisp-fancy-function"))

If you want it in all files, it's safe to cat that onto the start of each as a build step.

I do see your point though—it's a very common thing for people to want to use. I'm adhering strictly to UNIX design priciples for now because I'm afraid of featuritis, but perhaps that will change as the project matures.

I'm playing with the idea of having a separate convenience "getting started" package called "eslisp-coffee" or something, which acts like the core eslisp compiler but with a certain set of macros attached by default. What do you think?

<comment><USER7> eslisp-fancy-function looks great. One standard package with a lot of sensible defaults - based on learnings from ES6, Coffeescript etc - sounds like a great idea. Again, great work!

</comment></comment></comment><comment><USER8> This reminds me of wisp:

[https://github.com/Gozala/wisp](https://github.com/Gozala/wisp)

<comment><AUTHOR> wisp was indeed an inspiration! A pretty fundamental difference is that eslisp macros are ordinary JavaScript functions, which you can put on npm, and write in any language. In wisp, macros are magic compiler-internal things.

Here's a brief comparison to a few other JS-lisps too: [https://github.com/anko/eslisp/blob/master/doc/comparison- to...](https://github.com/anko/eslisp/blob/master/doc/comparison-to-other-js- lisps.markdown)

<comment><USER9> > (The non-JVM self-hosted implementation does not yet support macros at the > time of writing.)

Fixed, you can remove this line :)

</comment></comment></comment><comment><USER10> Neat. Why would I use this over ClojureScript or Parenscript?

<comment><AUTHOR> ClojureScript tries to be Clojure, and Parenscript tries to be Common Lisp. Eslisp tries to be JavaScript; it's intended to just be an obvious one-to-one syntax replacement.

I wrote a brief comparison in the docs: [https://github.com/anko/eslisp/blob/master/doc/comparison- to...](https://github.com/anko/eslisp/blob/master/doc/comparison-to-other-js- lisps.markdown)

<comment><USER11> Really only macros are in common lisp for Parenscript. Parenscript very strongly tries to be close to JavaScript.

<comment><AUTHOR> That's very true. For anyone with an existing Common Lisp stack who wants to use CL macros to write JS, Parenscript is great.

I wanted to write JS macros in JS, hence eslisp.</comment></comment></comment></comment>


Ask HN: f & t logos are everywhere, but for how long? - <AUTHOR>

The ubiquitous Facebook & Twitter "app icon" logos.  Every website, every TV commercial, every magazine, every poster, even on radio... "Like us, follow us!"
Companies are spending millions of dollars promoting a website because it's "in", cool, trendy.  How long can it last?  Most of them just have the f & t logo with no explanation as to why they are there.  Just f & t.  What does that do to benefit them?
You can't click a TV, magazine, poster or radio.  How many of you actually watch a commercial or read a magazine, see the f & t logo and think to yourself "I'm gonna go Like or Follow a laundry detergent company."
Obviously f & t are proven and effective ways to connect with consumers, but how effective is it for companies to promote them on their own ads without any incentive?
Seems that the "hype" is dying down for f & t and that it's become common place.  I wonder how long it will take for people to become numb and uninterested in them and move on to the next latest and greatest thing.
I'm interested in learning what other hackers think about this.  Please add on.  Thanks. <comment><USER2> How long? When the next big thing comes along they will move to that. Remember everything use to promote their myspace page? Myspace is still around, it's just not popular with, I guess, most people these brands are targeting.

<comment><AUTHOR> Yeah, but f & t are deeply engrained into everyday life of people and businesses.

<comment><USER3> So was MySpace. So will be the next big thing and the one after that.</comment></comment></comment>


The Scallop Sees with Hundreds of Eyes - <AUTHOR> https://www.nytimes.com/2017/11/30/science/scallops-eyes.html <comment><USER2> The hero image doesn't do it justice.

I recommend image-searching "scallop eyes": [https://www.google.com.mx/search?q=scallop+eyes&tbm=isch](https://www.google.com.mx/search?q=scallop+eyes&tbm=isch)

A beautiful beast.

I also enjoyed the morbidity of the article pointing out how much we have to learn from these creatures yet also how we sear them in butter.

<comment><USER3> If you can get them live, you need neither butter or searing. Just a quick cut with a scallop knife. :)

When diving for them, they definitely see me and will close tight. But unlike as the article mentions, I've never seen them propel themselves away. I have however seen trails in the sand of where they've come from. The impression I have is they move slowly to better position themselves to capture food.

</comment></comment><comment><USER4> Here's another article, containing a cryo-electron microscope image of the square tiles:

[https://www.sciencenews.org/article/scallops-amazing-eyes- us...](https://www.sciencenews.org/article/scallops-amazing-eyes-use-millions- tiny-square-crystals-see)

</comment><comment><USER5> Inspiring. Just as our brains combine signals from two eyes, scallop brains must be able to combine the signals from all of their eyes, but what would this conception of the world even be like?

It'd be fun to build a headset rig that tries to imagine scallop vision. With present tech, I imagine this would require some preprocessing to combine the various eyeball streams into something human eyes could understand. Anyone done something similar yet?

<comment><USER6> You already know exactly what their conception of the world is like. When you look at the world you don't see two images, you just perceive the presence of things.

The thing that would make scallop reality different than yours is not the many eyes, it's the different body. Because you have fingers and lips you will perceive a fish differently than a creature with tentacles and gills would perceive it. We can only perceive that which we can relate to our own bodily experience.

(Although as humans our layering of cultural references on those bodily sensations can sometimes lead to the illusion that our perceptions are abstract.)

<comment><USER5> I'm not so sure. Just as language influences how we think and how understand the world, don't our senses mediate our understanding of reality?

Say there were a hyper-intelligent, speaking scallop. I agree that we could build a shared language with the scallop for properties as "presence" or "absence", but the scallop's internal conception of presence and what presence looks like may be completely incomprehensible to us. Could that scallop then ever teach a human what presence is without showing it to them? (similar idea to knowledge argument)

More practically, two points I find interesting about scallop vision:

\- 360 vision from multiple small eyes. How are these inputs combined in the scallop's brain?

\- Scallop eyes seem to be optimized for seeing contrast and detecting motion. What would seeing using an array of low resolution, light/darkness sensors be like?</comment></comment></comment>


Microsoft Surface vs. iPad and Linode - <AUTHOR> http://yieldthought.com/post/60180703528/microsoft-surface-vs-ipad-linode <comment><USER2> _I can do more with the Surface, but it is not beautiful, nor do I enjoy using it - or being seen using it._

You come across as someone that went into the Surface not wanting to like it and you found a bunch of reasons from reasonable to erroneous not to like it. Does it seriously bother you what other people think about the devices you use?

 _Word doesn't save your work unless you click on a 3.5" disk icon regularly._

This is an example of one of your contrived reasons. Word auto-saves at a user-definable interval. It also creates AutoRecover files at a regular interval. I've had situations like power outages hard shutdown my computer and AutoRecover restores them up to the second.

[http://office.microsoft.com/en-us/word-help/help-protect- you...](http://office.microsoft.com/en-us/word-help/help-protect-your-files- in-case-of-a-crash-HP010354296.aspx)

[http://support.microsoft.com/kb/107686](http://support.microsoft.com/kb/107686)

 _Some things are saved on SkyDrive, some on the local disk, which isn't automatically backed up either. So now I am forced to be aware of this leaky abstraction, to manage the remote and local state and at this point I might as well just have a MacBook Air and be done with it._

Just buy a MacBook Air because that's obviously what you want. This is another contrived reason. Backing up the local and remote (Skydrive) data on your Surface RT is pretty darned easy to set it and forget it:

[http://www.microsoft.com/surface/en-us/support/music- photos-...](http://www.microsoft.com/surface/en-us/support/music-photos-and- video/back-up-photos-documents-and-more)

[http://windows.microsoft.com/en-US/windows-8/set-drive- file-...](http://windows.microsoft.com/en-US/windows-8/set-drive-file-history)

<comment><AUTHOR> It's not about fashion-conscious style. Pulling out the Surface in a nice cafe to work in feels... awkward. Out of place. It's clearly a business device for office work, and doing office work in a cafe feels like an imposition. This is not true in Starbucks, but is in the more provincial cafes around here.

Word autosave isn't good enough. Here's what happens regularly: I leave Word open without manually saving for days in the background without realizing. Eventually the Surface decides to reboot itself for an update or runs out of power. The next time I open a Word document from an email attachment during a conference call some stupid side bar pops up with a number of revisions of documents that I instincively ignore. Cancel, go away! I'm busy! Oh, now I've lost that work.

I've retrained myself always to save the 'recovered' copies now, and then manually check whether it's newer or older than the last 'saved' copy. I shouldn't have to do that.

I really, really wanted to like the Surface. Just check my previous posts and tweets about it. I still use it, but I am also disappointed.

<comment><USER3> | It's not about fashion-conscious style. Pulling out the Surface in a nice cafe to work in feels... awkward. Out of place.

This is your own hangup and has nothing to do with the tablet.

<comment><USER4> _> This is your own hangup and has nothing to do with the tablet._

A few things.

First, that's rude, especially to someone who's taken the time to express an honest view.

Second, he never claimed to be speaking on behalf of some objective viewpoint. This is clearly an opinion piece, and it's redundant to say, "Well, that's your opinion." Of course it is!

Third, and this bears repeating: his opinion is valid and useful in-and-of itself. It doesn't need to be "correct", and you don't need to agree with it for that to be so. What you did there was attempt to _invalidate_ his viewpoint, his reaction. It is a form of control, of bullying, and you should be ashamed of yourself for trying it.

<comment><USER5> What on earth are you ranting about ?

It IS his own hangup if he feels uncomfortable using a laptop in a cafe. Millions of people do it every single day and see no issue.

</comment></comment></comment></comment></comment><comment><USER6> The Surface sums up for me why Microsoft is a disappointment (to me at least), it's an area of boundless potential that's besmirched by poorly thought out execution. Microsoft has the potential to really nail these things, but instead they deliver a product that works and you get no joy out of it at best, and actively dislike it at worst. It's 2013, don't expect a user to remember to click save, and especially don't on a tablet as they've already become accustomed to data persistence, don't force updates every 2 weeks unless it's something critical (zero day critical), really nail transitions and animations and encourage developers to build applications that take advantage of the form factor.

But they didn't, and here we are. It's like having a set of drawers where the third one down needs to have the second draw pulled open half way and the bottom all the way in to work properly. It's totally liveable, but you'll always resent it.

<comment><USER7> _The Surface sums up for me why Microsoft is a disappointment_

Completely agree. Microsoft can't win for losing. They have some great products and the cash to really make a dent, then they completely flub the opportunity. I feel like they're trying to cast too wide of a net and in doing so miss the important details.

They have almost the polar opposite approach of Apple, who will happily give up features in order to have other features work solidly (in my opinion). A former boss of mine once said that users will forgive a lack of features, but not a lack of stability/usability. I agree with that. I'd rather have a limited set of features that WORK than a larger set of features that "sort of" work. I don't know if this comes from Microsoft's background of working with corporate partners (and delivery dates are important to fulfill a contract, bugs or not) or what.

</comment></comment><comment><USER8> On the one hand, I love that MS made an Arm OS that embraces the file-system instead of hiding me from it. Android often suffers from making me think about the files (like my downloads) while trying to pretend there is no filesystem... Win8RT accepts the burden of files and goes to work trying to make them pleasant to handle.

But yeah, the save thing, the lack of automatic cloud support... that seems anachronistic. The disconnected, versionless way people still handle their documents is incredibly haphazard and it's staggering that we've allowed it to persist like this so long. You can't really blame MS for this - everybody has a blind spot with office documents, even people who try to compete with MS - It's not like LibreOffice avoids these problems.

<comment><USER9> Unfortunately, Open-/LibreOffice has never been more than a free and open- source two-versions-ago copy of MSOffice. Thanks to the network economies that MSOffice enjoys, LibreOffice is under enormous pressure to aim for compatibility, not superiority.

</comment></comment><comment><AUTHOR> Author here. Before spending so much time with the Surface I'd have been really enthusiastic about the idea of a Microsoft Phone following the Nokia purchase. Now, I just can't see them getting all the little details right.

It's a real shame, there's so much potential here. I know people with Windows Phones love them; do they also do things like screw up the screen rotation, force a reboot with 15 minutes warning and update every few days? I'm guessing not; if only the Surface division had made the same choices.

I feel as if a tablet really needs to be a magic slate first, a general purpose PC second (if at all).

<comment><USER10> There's some weird stuff in your linked article that makes me wonder if Surface RT is some parallel nightmare universe version of normal Windows 8 beyond the typical 'ARM only' bit. Don't consider this nitpicking; just some questions that came to mind, since your experience is so different from mine using win8 on a tablet.

Word doesn't have autosave anymore? It's had it since like Office 95!

Did the machine really power itself off, losing your work, every week even if you had it in hibernate or sleep mode? That would really surprise me, I haven't seen my tablet do that. Windows Update is a troublemaker, for sure, though...

Why is the keyboard behavior you describe such a problem? For me, I consider the Windows 8 behavior the only optimal choice: Windows software in general is designed on the assumption that screen geometry will not change constantly every time you tap. The android/iOS behavior of keyboards popping up at random as the focus moves around can be a real pain when trying to precision target objects, scroll around, or highlight content. There are certainly cases where it's unambiguous and the keyboard could just be popped up, but at most I found that a minor nitpick when interacting with W8 on a daily basis - and you've got a Surface, where you can just attach a keyboard and start typing. Is it just something that really annoyed you, from a friction perspective, even though it doesn't have a big workflow impact?

<comment><USER11> > Word doesn't have autosave anymore? It's had it since like Office 95!

The last Microsoft Word version with Autosave is 97[1], from 2000 onwards it was changed to Autorecover (from crash)[2].

[1] [http://support.microsoft.com/kb/77535](http://support.microsoft.com/kb/77535) [2] [http://support.microsoft.com/kb/107686](http://support.microsoft.com/kb/107686)

</comment></comment></comment><comment><USER12> "I can do more with the Surface, but it is not beautiful, nor do I enjoy using it - or being seen using it."

But mom what if the cool kids see me using it?

</comment><comment><USER13> I bought a Nexus 10 with the hope of using it for dev. At first, I tried just using terminal emulators. This was quickly ruled out after finding most of them had screwy key bindings when used with a keyboard.

Then I thought I would try using splashtop to remote into my home desktop. I thought this was perfect; I could use the power of my home machine and the portability of the Nexus. Worked great on my home network. After going to a conference, I found that it just could not hold the connection. I'm only using vim on a terminal. It just would not work.

Now here I am eyeing an 11 Macbook Air. Great portability and battery life, but the price is just hard to swallow.

<comment><USER14> I'm curious if the problem here is splashtop--does it work when you go to cafes with spotty wifi? For example, running vim from an ec2 instance might give you better connectivity.

<comment><USER13> I would tend to agree. The problem would then come back to the terminal emulators. I would miss out on keys like tab complete, home, end, del, and others. Not essential for vim, but definitely for CLI.

</comment></comment></comment><comment><USER15> I have been using an iPad + ssh to connect to my linux desktop for a while, similar to the way the author did in the linked article. I found it to be an excellent way to work, using a bluetooth keyboard on the iPad. I did this for about 6 months before I, too, switched to a Surface about 3 weeks ago. I found that I no SSH client worked consistently enough on the iPad + bluetooth keyboard for me to get things done.

Here are my (hopefully) brief thoughts on the Surface (Pro). I agree with the author's take that it's clunky as a tablet. I noticed the same sort of rotation issues with windows resizing oddly. I find the lack of automatic auto-correct to be frustrating, since typing on the screen keyboard is hard (although in some ways I do like the Surface's screen keyboard better than the iPad's, mainly because it has a fuller range of keys, like a programmer typically expects, and I like having the number pad since you're having to switch the keyboard to get to the numbers anyway).

I also found that scrolling windows in the browser (a common task on a tablet) works considerably less well on the Surface. It seems to be best in IE, but in Firefox and Chrome sometimes my finger will scroll the window with a touch, but sometimes it just seems to select text. Window management is the same old problem as on every windowed device, but now more difficult when trying to hit the small window border with your finger. Of course, full screen is still an option.

I considered buying a MacBook Air, and in some ways wish I had (battery life comes to mind) but I like that the Surface is a real PC as well as an OK tablet, and I really wanted the Wacom pen (something I have a particular fondness for). While I wouldn't recommend the Surface generally to people, it fit my usage pattern well. I can still connect to my desktop, SSH works as expected, but I can also work locally if I want to install stuff. For me, it beats the iPad + ssh pattern, but really only in the way any ultra-portable laptop would.

<comment><AUTHOR> Jailbreak it and use PuTTY as your SSH terminal, it does a stellar job.

</comment></comment><comment><USER16> At some point just buying a MacBook Air makes more sense than either. Just have 2 gadgets and deal with it.

</comment><comment><USER17> Well anytime you see yourself missing a real laptop, remember you could have always gotten the Surface Pro. Its a complete laptop and more.</comment>


Implementation of EMNLP paper about which the hype "FB shuts down AI" surfaced - <AUTHOR> https://github.com/karandesai-96/lang-emerge-parlai <comment><AUTHOR> PS: I am not the owner, saw it on facebook AIDL - [https://www.facebook.com/groups/DeepNetGroup/permalink/52515...](https://www.facebook.com/groups/DeepNetGroup/permalink/525154117877475/)</comment>