Do I Need Kubernetes? - <AUTHOR> https://mbird.biz/writing/do-i-need-kubernetes.html <comment><USER2> > Run your applications in Docker from day 1 (with docker-compose it's as > valuable for dev as it is for production) and think carefully before letting > your applications store local state.

I think this is the key take away for many startups. Get it so you:

        1. Have a single-command way to bring up your entire backend
        2. That command can run on your dev machine
        3. You document all of the settings for your containers and deps

Once you have that in a docker-compose.yml file migrating to something like kube when you need health checks, autoscaling, etc is easy.

The only thing you must be critical of is bashing people over the head to make everything you run in your company run in this environment you've created. No special deployments. Establish 1 method with 1 tool and go from there.

Every company I've worked at I've brought a single command `docker-compose up -d` workflow and people were amazed by the productivity gains. No more remembering ports (container_name.local.company.com), no more chasing down configuration files and examples, no more talking to shared DBs, etc.

<comment><USER3> Can I ask people who _don't_ use Kubernetes and maybe have architectures built on proprietary cloud services: how do you manage this?

<comment><USER4> Ask every enterprise that existed prior to 2018? Even for small and mid-size enterprises, manual deploys aren't that huge of a deal. Automation with some bash scripts can get you pretty far. Especially if you're only managing a monolith or two. I've worked in some platforms that absolutely defied automation due to their proprietary nature. It just meant that we'd need a few people to spend 1-2 hours every two weeks to run a deployment. That cost added up over even a year or two is probably less than paying for a redesign and replatform.

I've also done deploys just using managed services like ECS/Fargate or Heroku where we just build an artifact and push it to the host with a script. A stack that's a load balancer, stateless app server then a DB and/or file store can be provisioned manually once then not really worried about for a long time.

<comment><USER3> To be clear, I was more asking how people achieve the sort of fast bootstrapped dev environments the parent comment describes using k8s, especially where you're not necessarily talking about simple topologies like a monolith plus a database.

<comment><USER5> Option 1: Everyone develops on the CI/CD platform.

Ops gives devs "disposable environments" to do their testing in. Basically, GitHub + Jenkins + Terraform + AWS. I've used this to stand up real infrastructure every time a PR is opened, and pipelines run against the infra. Code and infra match each other because they both exist in the same branch/repo (monorepo; you can of course do multi-repo, just takes more coordination). It's all destroyed as soon as the PR is closed, but you can also keep it up to do dev work against. You can also keep one copy of the latest master branch up at all times (the "dev" or "cert" or "test" infrastructure) as a shared test environment. Downside: you have to have access to the network (which is in AWS, so that's not so difficult). Upside: the dev environment always mimics production, devs don't need to do anything to stand it up.

Option 2: A bunch of mocks, and scripts to stand up stuff in Docker, using docker-compose or something else. This becomes a bit of a problem to manage with lots of devs, though, and docker-compose is not a good model for production deployments.

<comment><USER3> Thank you for describing option 1, which is really what I was picturing but seemed ambitious enough that maybe nobody tried it.

</comment></comment></comment></comment></comment></comment><comment><USER6> I think one of the underrated parts of using something like Kubernetes early (or even w/ simpler orchestrators like swarm or rancher), is that it encourages (and sometimes enforces) architecture best practices from the start. IE, you won't be storing state locally, you'll be able to handle servers being randomly killed, you'll already have horizontal scaling, etc. In my experience the hard part of migrating to containers in a legacy app is when they break those constraints, especially around local state and special servers. It's easier to do these things sooner rather than later, and the constraints kubernetes places on you aren't that hard to work around if you design it in from the start.

I good reason _not_ to use kubernetes though is if you know your app is probably never going to scale, or if it's the kind of thing that can scale very well on a single machine, or if it's not primarily based on http communication. (I wouldn't write a real time game server in kubernetes, for instance, because I doubt it'd really help with a primarily UDP workload that is likely going to be attached to one server)

<comment><USER7> I'm not avidly opposed to k8s by any means, but you can get these same properties from any of a variety of easier-to-use schedulers such as Fargate, Heroku, or even EC2 autoscaling groups. Of course, there are probably Kubernetes distributions that lower the threshold of using Kubernetes (and if there aren't, there really should be) by providing solutions for logging, monitoring, certificate management, Functions (a la AWS Lambda), load balancing / ingress, state management (databases as a service), etc preconfigured out of the box (similar to what you get with AWS or Heroku).

<comment><USER8> The problem with your approach is that you're firmly locked in to the vendor.

And in the case of Fargate, Heroku etc you're paying significantly more than if you had made use of Spot instances or shopped around for a cheaper vendor.

<comment><USER7> Vendor lock-in concerns are overblown. Unless there's a real chance you'll need to pick up and move, don't worry about it. Your savings by not building/operating everything yourself will dwarf other costs (unless your business has huge scale _and_ you have a world class internal cloud capability which you probably don't and if you do, you can probably just negotiate a better deal from a cloud provider a la Netflix and Amazon). To that end, you only "save money" by managing everything yourself if you write off the cost of engineering time and talent, which is to say you lose money by doing it yourself because you don't have the scale or talent to compete with Amazon even with their markup (certainly not when you account for opportunity cost).

<comment><USER8> Nobody is saying you have to build everything yourself.

But you can just use cloud providers for their hardware and not needlessly tie yourself to their software. For example you can use a managed K8s solution like EKS but then have all of your monitoring, logging, databases etc all be self-hosted.

And it's not just about cost but also about being able to take advantage of other cloud provider's unique strengths or being truly resilient to outages.

<comment><USER7> The same arguments apply to hardware and software. Cloud providers' core competency is cloud infrastructure and services and they have the scale to economize their offerings. Your business very likely can't compete with them, so _to the extent that you're owning things that cloud providers could sell you, you're throwing away money_ and that figure very likely dwarfs the _risk adjusted_ cost of maybe having to migrate to another provider one day. (Of course, there are services that are overpriced here and there, but the general principle holds).

</comment></comment></comment></comment></comment></comment><comment><USER9> I've always seen the story like this:

It all started with Ruby. Ruby's syntactic sugar inspired the "syntactic sugar" of tooling, primarily Bundler and Rspec. Tooling, for what felt like the first time, became a first class citizen. Ruby's tooling made Heroku possible: ie, reproducible builds across; dev, testing, staging and production environments. Heroku's success was based on the primitives of the Twelve- Factor App[1]. The 12 factors (and therefore Heroku) were fundamentally designed around the already-old lightweight virtualisation technology of LXC. The success of Heroku paved the way for Docker. The success of Docker created the world in which Kubernetes makes sense.

To be blunt: if you don't understand the relevance of Kubernetes, or whether it's relevant to you, you don't understand the benefits of the 12 factors in their broadest sense. The 12 factors are much, much more than just "How To Deploy On Heroku".

Copypasting the 12 factors:

        I. Codebase
        One codebase tracked in revision control, many deploys
        II. Dependencies
        Explicitly declare and isolate dependencies
        III. Config
        Store config in the environment
        IV. Backing services
        Treat backing services as attached resources
        V. Build, release, run
        Strictly separate build and run stages
        VI. Processes
        Execute the app as one or more stateless processes
        VII. Port binding
        Export services via port binding
        VIII. Concurrency
        Scale out via the process model
        IX. Disposability
        Maximize robustness with fast startup and graceful shutdown
        X. Dev/prod parity
        Keep development, staging, and production as similar as possible
        XI. Logs
        Treat logs as event streams
        XII. Admin processes
        Run admin/management tasks as one-off processes

1\. [https://12factor.net/](https://12factor.net/)

<comment><USER10> Reading this, I doubt it can be taken as gospel.

> Store config in the environment

How do you pass hierarchical config? In JSON, YAML, TOML, etc., it's easy to group env vars, but how do you do that with env vars? LOGGING__HANDLER__FORMAT, LOGGING__HANDLER__ARGS__ARG1, LOGGING__HANDLER__ARGS__ARG2 ? If so, that looks positively awful. If the solution is passing a YAML or JSON string in the env variable, that sounds even worse than having a config file that the app reads.

>> it's easy to mistakenly check in a config file to the repo

Add it to the ignore file. Someone would really have to force commit it to get into version control. Plus, even if it's stored in env vars, you're going to commit the values somewhere be it your Ansible secrets, SaltStack yml, Chef or Puppet repo, whatever.

To be fair, that's the only point I contend with. The rest is very reasonable.

<comment><USER11> > How do you pass hierarchical config? In JSON, YAML, TOML, etc., it's easy to > group env vars, but how do you do that with env vars?

Spring Boot approaches that problem via `SPRING_APPLICATION_JSON` (and likely `SPRING_APPLICATION_YAML` but I haven't personally tried it)

        containers:
        - name: web
          image: whatever
          env:
          - name: SPRING_APPLICATION_JSON
            # language=json
            value: |
              {"spring": {"logging": {"level": "debug"}}}

<comment><USER10> Goodness gracious. That's dreadful and exactly what I feared the effect of that rule would be were it followed strictly. It looks like a hacky workaround to an unnecessary problem.

</comment></comment></comment></comment><comment><USER12> Honestly nobody _needs_ k8s, but nobody really needs anything. If you know it and you know it suits your needs, then sure! Go for it! Have fun.

If you don't know it, then learn it first. Then you can properly evaluate whether it suits your requirements or not.

There's huge value in choosing something that your team already knows + is familiar with

I'd totally advocate for learning something new, but solving a business problem probably isn't the best time for this :)

I think the article gave a great overview though, and is perhaps a good way to decide what to learn next

</comment><comment><USER13> Remember Greenspun's 10th rule?

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Well, there's a kubernetes version, which is that any sufficiently advanced deployment system will ultimately be half assed version of kubernetes.

<comment><USER14> Including Kubernetes itself!

<comment><USER15> To be fair, there was a ring of truth to this

...back in 2015 ;)

</comment></comment></comment><comment><USER16> I was a huge proponent of not hosting monolithic applications on kubernetes, that was until the company I worked for acquired another same size company and I had to learn their hand rolled puppet2/shell script based infrastructure management/deployment logic all over again(we had our own hand rolled puppet3/shell script based infrastructure logic too, so that's two stacks with their own quirks.)

Now I'm completely in favor of hosting anything you can cram into kubernetes in kubernetes, even though kubernetes is more complex than most other infra tools, most of the time there is only one way to do things(configmaps for config, PV allocations for storage etc..) So if you understand kubernetes, it's easier to get the larger picture about the infrastructure even if you know nothing about the application stack.

</comment><comment><USER17> I think what isn't fully appreciated about k8s yet, but we will look back on is how it creates an open standard platform for apps to be deployed. It is one thing to port your own apps to run within a k8s cluster, it is another to have and operate a k8s cluster that you can use to deploy services built by others. I hope we see more of this soon

</comment><comment><USER18> Not a single mention of elastic beanstalk or App Engine? The best middle ground for small teams who just want one reliable website with minimal scaling (and who can't just choose a nom-aws service).

<comment><USER19> Do you have any examples of non-proprietary solutions?

<comment><USER20> Knative + buildpacks is one. CloudFoundry is open source too (although CF now runs on Kubernetes I think)

<comment><USER21> Cloud foundry offers their old(er) architecture as well as 2 ways to get the "cf push" experience over Kubernetes. Check out KubeCF and cf-for-k8s. Both of these are open source projects that you can deploy to a Kubernetes infrastructure of choice.

[1] [https://github.com/cloudfoundry- incubator/kubecf](https://github.com/cloudfoundry-incubator/kubecf) [2] [https://github.com/cloudfoundry/cf- for-k8s](https://github.com/cloudfoundry/cf-for-k8s)

</comment></comment></comment></comment><comment><USER22> I only have one tiny detail: Bursty traffic means that your cluster needs to be able to deal with the peaks. If you running an on prem Kubernetes cluster, then there is no savings, unless you can use the capacity for something else during non peak periods.

The scaling, and potential savings is a cloud feature, not a feature of Kubernetes.

<comment><USER23> It also enables you to achieve app density. Many of the companies I've been working with lately have large batch processes on nightly / weekly / monthly basis. For some reason, each job previously was setup on on-prem hardware dedicated per workload. Using Kubernetes and scheduling jobs to manage capacity has enabled us to reduce the number of on-prem servers substantially as part of the migration plan for the cloud.

<comment><USER24> Precisely.

In my experience hosting services in VMs on-prem I was able to achieve roughly 30% efficiency across 3k instances and hundreds of nodes. In my experience hosting microservices on k8s, I was able to achieve 80% efficiency across hundreds of nodes.

Both were the result of a great deal of work to optimize efficiency. In this case, I use the word "efficiency" to refer to a blend of CPU and memory utilization.

</comment></comment></comment><comment><USER25> My assessment is that if you have a large, complex micro service environment with several applications, docker may be a good route to take as an interim to cloud native.

If you have a relatively simple deployment structure (one big application with 10-20 services), maybe you don't need to add the docker skill to what you're already doing.

If you're in the process of rebuilding your applications and you've decided cloud native is the way to go, then containers are pointless.

I'd argue if you don't have the skills and you don't want to pay someone to do this work full-time, you might put your developers in a position to fail.

Based on my 30+ years of building software, I see containers as a dead end. It may help you out in the short term, prove to your CTO that you're using "well- known" technology, but in the end, cloud native is going to replace everything. And before you say "but we can't be in the cloud," then you should know that cloud-native development like Lambdas can be done on-prem as well.

I'm positive this post will get negative votes. That's fine. I like tilting at windmills.

<comment><USER26> Containers are a good tool for scaling resources?

<comment><USER25> It depends on the app. If it's an existing app, a container is fine. If you're building a new app and you don't care about the infrastructure, Serverless is better.

My problem is that eventually all apps will be rewritten...and it's probable they will be in some kind of Serverless manner.

Containers still have some separation of concerns issues as well as maintaining state or sharing data.

My default would be Serverless with a plan B for Containers and a plan C for VM's.

</comment></comment></comment><comment><USER27> > To make a cluster useful for the average workload a menagerie of add-ons > will be required. Some of them almost everyone uses, others are somewhat > niche.

This is the concern I have with k8s. All this complexity introduces operational and security concerns, while adding more work to do before you can just deploy business value (compared to launching on standard auto-scaling cloud instances)

<comment><USER2> If you are using a managed kubernetes cluster from a cloud provider you mostly don't need to worry about these sorts of things. If you're not, and deploying to bare metal, the main things you need to worry about are: load balancers, storage & monitoring. If you're large enough that you can effectively run kube on bare metal you probably have enterprise solutions for load balacing [0], storage [1] & monitoring your applications that you've already validated as being secure/stable.

If you want to go all out you can also grab an operator to manage rolling out databases for you (postgres [2], mongo, etc).

A lot of the complexity people bump into with kube is really poorly planned out tools like Istio that have way too many features, a very overly complex mode of operation (out of the box it breaks CronJobs!!!), and very sub- standard community documentation. If you avoid Istio, or anything that injects sidecars and initcontainers, you'll find the experience enjoyable.

[0] - [https://clouddocs.f5.com/containers/v2/kubernetes/](https://clouddocs.f5.com/containers/v2/kubernetes/)

[1] - [https://www.netapp.com/us/kubernetes- storage.aspx](https://www.netapp.com/us/kubernetes-storage.aspx)

[2] - [https://github.com/CrunchyData/postgres- operator](https://github.com/CrunchyData/postgres-operator)

</comment></comment><comment><USER28> This sounds like people try to compare K8s with what was before and sure, that all holds true.

You get all of this with serverless (be it with managed services or FaaS), with reduced (albeit not zero) complexity compared to K8s.

<comment><USER8> And with serverless you get significant lock-in, are overpaying for resources, have less ability to debug when things go wrong, have basically zero flexibility and it's very difficult to have a local setup mirror your production one.

It's fine for certain use cases but you get the benefits of both worlds by just using a managed K8s service like AWS EKS.

<comment><USER28> I'll dive into K8s this week, after a few years of serverless. I'm intrigued to see what it has to offer, that serverless lacks.

</comment></comment></comment><comment><USER5> Here's a quick reference:

1) Are you on AWS? Then you don't need Kubernetes. Use Fargate.

2) Are you on Google Cloud? Then you don't need Kubernetes. Use Cloud Run.

3) Are you on Azure? Then you don't need Kubernetes. Use Azure Container Instances.

4) Are you on a PaaS like Heroku? Then you don't need Kubernetes.

5) Are you on a random VPC provider / bare metal machines? You could probably still do without Kubernetes using Docker Swarm (apparently it's not dead!), Nomad, Mesos DC/OS, or a standard Linux box and systemd (or some other process or cluster scheduler).

6) Do you need to solve the bin-packing problem? Do you need to self-host a service mesh of microservices in multiple colocated regions? Do you need a fully automated redundant fault-tolerant network of disposable nodes to constantly reschedule different versions of applications with stringent RBACs, scheduled tasks, dynamic resource allocation, and do you have about a million dollars to spend on building and maintaining it all? Then you need Kubernetes.

<comment><USER24> > do you have about a million dollars to spend on building and maintaining it > all? Then you need Kubernetes.

I think you're overstating the investment necessary to overcome the initial complication of Kubernetes and also understating the benefit of being on a platform with a massive and thriving community behind it.

As an example, in a prior role, there were a set of data engineers that would receive data in the form of MS SQL server backups from which these engineers would need to query and transform data on an exploratory rather than production basis. Certainly one could use an "undifferentiated" service from a cloud provider, but it was also a roughly 5-minute process for me to use the rather high quality helm chart and docker image commonly available to stand up a new service for the benefit of each engineer that had the need.

The process of creating that automation necessary to deploy the helm chart and restore the backups took approximately one hour and could be repeated ad nauseum in the aforementioned 5-minute time period.

There are many, many other examples of this. Want a data-science platform complete out of the box with no vendor lock-in, how about data8.org? The list goes on.

<comment><USER5> What happens when your car's A/C stops working? Most people think, I'll just get a little can of R134a, fill up the system, and it'll be good as new. Somebody said they did that once and it worked just fine, so it should work for you too, right? I mean, it says so right on the can, and there's YouTube videos of it and everything.

The trouble is, A/C is a complex system. There are moving pieces with specialized oils that oxidize and break down over time. There's a sealed system of pressurized gas. There's a pump, clutch, coils, fans, filter, thermostat, drain, belt, and electronics, Any of those parts could fail in a number of ways. Just to inspect it you need a custom gauge set, a tank of R134a, and a vacuum pump.

 _Etcd_ is about as complex as an A/C system. That is one of a dozen components of a Kubernetes system, before we get into custom integrations, which you will need about another dozen of.

The million dollars is to pay for everything needed to set up and maintain all of that, create the custom integrations that do not come turn-key from the community, create the custom integrations the community doesn't even have, integrate it with your development and deployment systems, business requirements, application-specific needs, and so on.

A million is an average. You can get away with less, just like you can get away with pumping a pre-pressurized A/C system with extra coolant: if you're lucky it won't break. When it does, I hope you have either a lot of time, or a lot of money to pay a consultant.

<comment><USER29> I would strongly disagree. Etcd, for what it does, is extremely simple. What is so complex about it? The configuration?

<comment><USER5> It's a distributed decentralized database using self-signed certs. Just by itself it requires maintenance: upgrading the software, upgrading the host it runs on, rotating keys, networking, access control, key space maintenance, backup, etc. Here are the docs you need to know to run it: [https://etcd.io/docs/v3.4.0/op-guide/](https://etcd.io/docs/v3.4.0/op-guide/) And there's another dozen docs not written there that the admin just sort of finds out over time.

But it's part of other systems too, making the overall thing a system of systems. Interactions between systems of systems are complex and cause unexpected behavior. At some point you will run into an error in K8s that you can't resolve that will require you to debug Etcd. And "Bob" help you if the database gets corrupt or overwritten, or incompatible versions of software screw up what's in the database, etc. (My original analogy was inaccurate... Etcd is more like the engine than just A/C, because if it stops working, everything stops working)

Do you know what happens if an Etcd certificate's SAN field does not include domain names but only IP addresses? The client requests HelloInfo with an empty ServerName so it doesn't trigger a TLS reload on handshake, making it more difficult to replace expired certs. That is a single random quirk in a single component of this software which underpins all of Kubernetes. I cannot sit here and explain every single reason why Etcd is complex; it must suffice to say that the software just _is_ complex, and that this reality means that while it may sometimes be simple for some people to operate, it will definitely not always be simple to operate, and there will come a time that the true cost will emerge.

Now, most people don't _need_ to pay for that high cost of complexity. They can use a SaaS/PaaS product like AWS ECS/Fargate or others, where somebody at some other company is dealing with the cost of complexity for you. All you have to do at that point is run some API calls and everything just works. Not only is it easier, it's immensely cheaper, less time-consuming, and more reliable.

...But you might not even need ECS! There's a lot of work just to get a simple PoC up on Fargate with an NLB, ACM cert, RDS instance, security groups, VPCs, cluster, service, task, etc. Compare that to just spinning up a micro instance and running MariaDB and a Python on it, and the latter you can have done in 20 minutes. If you can avoid complexity and still meet your SLOs, do that.

</comment></comment></comment></comment></comment><comment><USER30> To me the question is more: Is there an extremely valid reason to _not_ use K8s.

As a freelancer I visit quite a number of enterprise companies, think: Banks, Insurance, Airports, and they are all making the switch or are full-on invested in living in K8s by default. If it does not run in or was not made with K8s in mind: It will not be used/bought.

Another thing I'm noticing with smaller companies: If you start fresh, you choose k8s. Which mens all other stuff is already slowly dying by virtue of not beeing chosen.

Developers want/expect it, sysadmins see the benefits from day one, and companies see the potential gains of using less cloud resources and a platform that could potentially run in multiple clouds for the first time ever.

K8s, openebs, prometheus/grafana, loki, kustomize, github actions. This is truly where "it's at" at the moment.

</comment><comment><USER31> I work for a startup whose product is small (half a dozen servers, if relatively beefy ones) clusters that will be run on-prem by customers, at least sometimes in a low-to-no-touch capacity. Most of our application components are micro-ish services that are run on all hosts in the cluster for either extra capacity or fault tolerance.

We currently run everything on mesos/marathon, but are looking to switch away from it. K8s is kinda the "default" option, and is potentially appealing to some potential acquirers and investors.

But I never really see k8s being talked about in that context of "physical hardware that's on prem, but not on MY prem." Is there a reason for that? If we go with k8s is it going to bite us? Does anyone have experience with something like that they could share?

<comment><USER32> I did an on-prem k8s deployment at my last place. It is definitely challenging compared to EKS and GKE, but the difficultly is not in base k8s.

Following the kubeadm getting started guide on the kubernetes.io site can get you an 'ha', 'production ready' going in a couple hours. Most of it is pretty mechanical, and only needs a couple key decisions, mainly your networking plugin. Generally the most popular ones have instructions as part of the getting started guide, making the process straight forward.

Where it quickly becomes difficult is after this step. You have a cluster ready to serve workloads, but it has no storage, no ingress/external load balancer.

Storage can be as simple as NFS volumes (you don't even need a provider for this, but you should use one anyway). Rook/Ceph will work, but now you've just taken on two complex technologies instead of one.

Without an external load balancer of some sort, you will have trouble getting traffic into your cluster, and it likely won't be actually HA. You can use MetalLB for this, or appliances. If you're just starting out though, you can totally get away with setting up CNAME aliases in DNS to your nodes in a round robin type fashion. It won't be HA, but it will work, and is simple and straight forward.

Ingress is pretty easy to setup for the most part. Usually just applying an available manifest with a tweak or two. If you go the CNAME route, you will need an ingress setup so you can serve http/https on standard ports without too many issues.

If you do all these things, then you have a real deal cluster. Things like ingresses are recommended even if you're running in the cloud, so you may find that you're not all that far off from what you might find there.

Overall, the biggest trouble is all the choices you need to make. If you're starting out, maybe read up on two or three of the most popular choices for each step, and then just pick one. Anything that exists entirely within the cluster can usually be expressed purely as source controlled manifests, and kubeadm deployments can be simple shell scripts if you don't make them do everything (i.e. only support one container driver, not all of them).

One major caveat; If you screw up your network layer, you basically have to start over. This isn't strictly true, but it's the one where you are often better off starting over when you need to make fundamental changes to your network setup (like podCIDR and serviceCIDR or your network plugin). Pretty much everything else can be made to work with multiple setups at once, or you just need to delete and redeploy that component.

<comment><USER29> Kube-vip is another good alternative to metallb.

</comment></comment></comment><comment><USER33> I would say if you have the question "Do I need Kubernetes?", you don't need it because the benefits are not immediately crystal clear to you. Also, the author starts the evaluation from the wrong point of view, because the decision should be not so technical, but like everything else should be based on BUSINESS REQUIREMENTS. Evaluating Kubernetes is no different:

\- Do you have such high traffic that you need a distributed system?

\- Will a unified framework solve all your distribution problems?

\- Do you really need high availability?

\- Can you swallow the cost of high availability?

\- Can you handle the insane complexity of Kubernetes at a reasonable cost?

You should not start asking questions about "Pods, Ingress" or anything Kubernetes specific, those are just implementation details.

<comment><USER26> > Can you handle the insane complexity of Kubernetes at a reasonable cost?

For me, this point is akin to asking "Can you handle the insane complexity of Linux at a reasonable cost?"

And what I mean by that is: If noone exists on your company who can administer it, then you shouldn't do it.

</comment></comment><comment><USER34> Vendor lock-in aside, I've found ECS to be a great alternative.

<comment><USER35> Yes if you are on AWS. Significantly speeds up the engineering workflow.

Not sure if it is a vendor lock-in. If a customer wanted to move from ECS to kubernetes, they will need to migrate the manifests, roles/rolebinding etc. That is a small effort as long as they do not have to rewrite the code.

</comment></comment><comment><USER36> The article outlines a very nuanced detailing of how to answer that question, but I have a more blunt first consideration: If you need kubernetes, you don't need to ask whether you need it.

Basically, I think that a team/product _knows_ when the time has come in which the infrastructure has grown in complexity so much for it to need something like kubernetes to orchestrate it. If there are doubts, then whatever current setup is in place* is probably still enough and kubernetes is beyond what the team requires.

I am very proud of the one time I managed to convince both my then tech lead and project manager, in one of my past jobs, to move away from kubernetes into a simpler architecture leveraging docker, compose and PaaS.

* Hopefully one using docker and compose or similar, as mentioned in the article.

</comment><comment><USER37> For small apps and projects that continuous delivery is not required I would start with lxd. I think it's the easiest way to containerize an app.

Once that feels too little, I would start looking at docker, and only when docker feels again too little, to kubernetes.

So in essence, for 95% of the apps/people, the answer is no.

<comment><USER38> Can you elaborate on why you think that lxd is easier to use than Docker? I've always found docker build && docker push to be a simple interface to understand. What makes "start[ing] with lxd" more approachable or easier than creating a Dockerfile, given the abundance of Docker-101 tutorials, advice, and expertise available?

</comment></comment><comment><USER26> I've sprinkled some comments in this thread, but as someone who is working more or less full time with k8s infrastructure, architecture and maintenance (and I do love k8s!), my take is that if you have to ask this question then the answer is invariably: NO.

</comment><comment><USER39> I need Kubernetes since we're outgrowing Docker Swarm. Docker Swarm has a lot of issues we deal with on a constant basis so it's becoming quite painful.

Can anyone suggest a good migration guide from Docker Swarm -> Kubernetes?

<comment><USER15> My gentle suggestion is to avoid phrases like "a lot of issues" and instead to list some of the top ones. This could give some people a chance to share how they have overcome some of those specific challenges.

At a recent employer, we moved cold turkey from Swarm to Kubernetes (K8s in the rest of this reply). But we did this one microservice at a time. We didn't want our resulting K8s solution to be compromised by a misguided attempt to foist Swarm concept into the K8s way. Probably the biggest decision to make is whether to manage the cluster from scratch (not recommended), by using kops to deploy on a cloud platform, or use a cloud-native solution like EKS on AWS. After that -- here's a good guide to help with the differences in configuring the services[1]

[1] [https://kubernetes.io/docs/tasks/configure-pod- container/tra...](https://kubernetes.io/docs/tasks/configure-pod- container/translate-compose-kubernetes/)

</comment></comment><comment><USER40> Would have been much funnier, if this would have been just a page with a single word on it: NO.

See also: [http://dowebsitesneedtolookexactlythesameineverybrowser.com/](http://dowebsitesneedtolookexactlythesameineverybrowser.com/)

</comment><comment><USER41> Probably not.

</comment><comment><USER42> No.

</comment><comment><USER43> When a newspaper headline or blog post title ends in a question mark, the answer is almost always 'no'.

<comment><USER44> [https://news.ycombinator.com/item?id=24179969](https://news.ycombinator.com/item?id=24179969)

</comment></comment><comment><USER45> No

<comment><USER46> Exactly!

Betteridge's law of headlines:

Any headline that ends in a question mark can be answered by the word no.

⌘ [https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

<comment><USER47> I get it, but it's not really doing the author justice, who's trying to give a quite nuanced overview of where kubernetes is a good fit, and where it isn't.

As somebody who's pretty skeptical about onboarding the big lump of complexity that is k8s, I really appreciated the information in the article.

<comment><USER45> You see, any pile of junk(Kubernetes being one of them) can have a use case if you searched hard enough. Do not learn/work with Kubernetes unless your livelihood depends on it.

</comment></comment></comment></comment><comment><USER48> > Kubernetes isn't just a 2018-era buzzword.

And then he goes on to throw buzzwords. Yet another poorly written article as is now the norm for Kubetnetes.

<comment><USER26> Agreed, except the point about "the norm".

</comment></comment><comment><USER49> Probably not. Why not utilise ECS/ Fargate and attach managed services, rather then tending a whole now flock of things?

<comment><USER50> I find ECS/Fargate and managed Kubernetes not a bit easier to manage than Kubernetes itself. On the other hand, the inflexibility or vendor-specificity of these requires as much learning as you'd use FOSS tools. Also those skills are not transferable to an other cloud vendor, which might happened to be required if your primary cloud provider does not cover markets you supposed to operate in.</comment></comment>


Clojure vs Java, pt. 1 - <AUTHOR> http://tech.puredanger.com/2011/04/18/clojure-vs-java/ <comment><USER2> Clojure Protocols are really a great way to extend types. I think it's a nice fit with both the functional and dynamic nature of Clojure, and it is carefully designed to allow "open" types while completely avoiding monkey- patching. It just seems like the perfect balance, even if it's hard to understand at first. I think it might even lead to "better" OOP in Clojure than in Java.

I would love to have this in Ruby, so that classes could be extended but not in surprising ways.

<comment><USER3> _Clojure Protocols are really a great way to extend types. I think it's a nice fit with both the functional and dynamic nature of Clojure, and it is carefully designed to allow "open" types while completely avoiding monkey- patching. It just seems like the perfect balance, even if it's hard to understand at first. I think it might even lead to "better" OOP in Clojure than in Java._

Exactly. Funny thing. Better OOP in a functional language than in a OOP- language.

But i don't think it's hard to understand. I've seen a lot of good explanations in presentations and articles. Also the concept is really easy.

</comment></comment><comment><USER4> I keep hearing that current JVM implementation prevents tail call optimizations [1]. Is it still the case nowadays? Kind of curious on that since there seem to be lots of folks on HN use Clojure in production systems.

[1] [http://stackoverflow.com/questions/105834/does-the-jvm- preve...](http://stackoverflow.com/questions/105834/does-the-jvm-prevent-tail- call-optimizations)

<comment><USER5> You use recur in clojure for tail optimization. Don't think the jvm has tail optimization support currently.

<comment><USER4> Is recur kind of workaround? Any performance penalty?

Please bear with me as I'm not familiar with Lisp family languages. I'm interested in ML languages. There is a project to port OCaml to JVM, but I don't see any sign of progress, so I thought it may be something on JVM to hold them back.

<comment><USER2> I actually like the 'recur' better than implicit tail-call optimization. It does what it says on the tin. If you don't use recur, you get unoptimized recursion, and more importantly: where you _can't_ make a function tail- recursive, you _can't_ use 'recur', because it is a compiler error.

</comment></comment></comment></comment><comment><USER6> Is it possible to implement the same protocol for a particular type in multiple ways?

<comment><USER7> No, as a reimplementation will effectively replace the prior implementation. But I think you should ask whether that question makes sense.

If you're dispatching based on something other than just type (some information that would allow you to choose one of multiple implementations) than you should probably either a) put that logic inside the protocol implementation for that type or b) use multimethods which let you use an arbitrary dispatch function that can take both type and other information into account. If you choose a), you could actually layer another protocol or other dispatch mechanism under the initial call if you need to.

<comment><USER6> Imagine I have a JSONfiable protocol and I have a generic function to traverse a structure that uses the protocol to make a JSON document. It would be nice if the caller had a way to change the format.

<comment><USER7> You can _change_ the implementation of the protocol, but then it's changed (in that it replaces the prior version). When you see something of type X, the protocol says what to do when you encounter a function on X. If you want more than one kind of thing to happen, then you shouldn't use a protocol.

For instance, it would be perfectly feasible to use a multimethod that dispatches on both type and output format. Or a protocol that dispatches on type, then dispatches a different function on format.</comment></comment></comment></comment>


The Tcl War (1994) - <AUTHOR> http://vanderburg.org/old_pages/Tcl/war <comment><USER3> 1994? How about 2016 and I'm still living in a nightmare - my company uses tcl ("legacy" scripts). No matter how many times I tried to approach the language with an open mind there is no other language that grinds me down as much. If you think passing a variable name in a string to a function and then using upvar to access it is an acceptable way of returning values then have I got good news for you - we have languages with a sane way of doing it today (heck we've had them for longer than tcl has been around for)! I die every time I have to look up which order arguments come in because of how inconsistent it is, and oh, is it append or lappend or some other crazy keyword? People at the office had this for decades and they still have to use a cheat sheet. Why... There's perl, python, bash, anything god, please, make it stop.

<comment><USER4> [Warning: Personal anecdote... somewhat off topic.]

Around 2003 I was getting very heavily into what we used to call "Dynamic HTML", which of course required programming in JavaScript. At the time JavaScript was looked down upon by most professional programmers as a toy. A toy that had buggy implementations in various browsers, that lacked the strict typing of C++ or Java, that didn't have classical inheritance, that had no good IDE, and, worst of all, that you could create some terribly confusing bugs with.

At the time I'd moved to Fort Worth which let me attend the monthly Pragmatic Programmers meetings/dinners at Spring Creek Barbeque in Addison, TX. This was a meeting with a lot of polyglot programmers and "old timers", and there was a prevailing attitude that programming languages were just tools, and a good programmer learned to use many tools well.

Anyway, there I was one night ranting about JavaScript to someone I only remember as Chris. I probably chewed his ear off for a long time about how terrible JavaScript was. After what I'm sure was many minutes, I paused to let Chris tell me how much he agreed that JavaScript was terrible. Instead, he simply said: "You need to learn about prototypical inheritance."

This caught me off guard. I don't remember if it shut me up, but I hope it did.

Fortunately I actually took Chris' advice. While I'd understood that JavaScript had prototypical inheritance, I'd never really taken the time to understand how it really worked. I'd also never really grokked how scopes worked. As I properly learned these features, I started to gain a new respect for the power of the language, and it quickly became my favorite.

So, now when I have a strong negative reaction to a new language or tool, I ask myself if I'm reacting because of a fault in the language or if I just don't like that feeling of being less productive because I haven't _learned_ the language yet. Usually it's the latter, which means I need to grit my teeth and bend my brain and learn.

(P.S. Chris, if you're reading this: Thank you! I owe you a millions lines of code in grattitude!)

<comment><USER5> I'm pretty sure that was Chris Morris. (He and I were both regulars at that group.)

<comment><USER4> Hi Glenn :-)

I could have sworn it was a _different_ Chris. I remember someone with black hair. He may not have frequented the meeting as much, because I don't remember seeing him again after that.

(P.S. I've updated my profile.)

<comment><USER5> Ah, OK. (And yes, I remember you. You ran the FW JUG for a while?)

<comment><USER4> Yes, that was me.

</comment></comment></comment></comment></comment></comment><comment><USER6> I have used Lisp, Scheme, Prolog (and multiple dialects of each) for extended periods in large projects. Each was a pleasure to work with. They all have their own advantages. I am not sure if there is value in arguing over x feature of one language vs. y of another. As a matter of fact, it was fun to write Prolog interpreters in Lisp, and Lisp interpreters in Prolog, for example. (Many courses / textbooks (used to) present these as side projects to do and the task is simpler than it sounds.) One could say Tcl is really an extension of Lisp or Prolog in its core concepts of syntax, data and program equality, style of interpretation, etc.

I agree wholeheartedly with the last paragraph of Mr. Ousterhout's reply here - and I must say, a smart, classy and almost Tcl-ish way of a jab at its distractors:

[http://vanderburg.org/old_pages/Tcl/war/0009.html](http://vanderburg.org/old_pages/Tcl/war/0009.html)

I came across Tcl/Tk while doing Motif in a large C-based project. I simply couldn't believe how powerful, simple and succint Tk was compared to Motif (or anything else since). And it ran on Windows, Unix, Linux and Mac OS, to boot. It was too late for that project to switch, but all my other projects have used Tk if they ever needed a UI.

Similarly with Tcl. I still think the best introduction is Mr. Ousterhout's original Tcl/Tk book. It stands as one of the best language books on my shelf. Combined with Tk, one can put together a working application prototype in no time.

Of course, this was eons ago. Nowadays, Tcl offers one of the best environments with a complete set of packages ranging from web servers to image and sound processing. Plus, you can distirbute your program and all of its media and support files easily as well.

I believe Tcl has been mischaracterized and has suffered in terms of open popularity. But for insiders, it remains as one of those secret indispensable Ninja tools that is used over and over again for competitive advantage.

<comment><USER7> A bit off topic: did you really use Prolog for something else than just research? That is, did you write software that was used in production? I have learned it many years ago but always had a nagging feeling that it is better to use a "normal" language with AI libraries if you need the program to actually do something... Did I miss anything?

<comment><USER6> Most of my Prolog experience was in academics - for my own research as well as for maintaining some existing packages. But I did get to use it outside as well. There are many cases where a controlled language is needed or comes in handy and solves a lot of issues. This is where Prolog shines - plus you get to use a lot of the previous stuff you developed as well.

When it comes to an "AI" language vs. typical language with an "AI" library, I will just repeat a phrase that is often used in the field: what you thinnk of as an AI problem today will no longer be considered AI tomorrow, since it will then be well-understood and implemented in many places. People used to say that in response to the (seeming lack of) progress AI had made to date. A good example of that is Siri or Amazon Echo. Not many people consider it an AI problem anymore, or so it seems.

</comment></comment></comment><comment><USER8> See also "Tcl the Misunderstood" [1]

An interesting discussion here: [2]

[1] [http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

[2] [http://lambda-the-ultimate.org/node/3891](http://lambda-the- ultimate.org/node/3891)

</comment><comment><USER9> Note that RMS almost certainly did not write the inciting post [1][2].

[1] [http://lambda-the-ultimate.org/node/3891#comment-58302](http://lambda- the-ultimate.org/node/3891#comment-58302)

[2] [https://web.archive.org/web/20110102015130/http://basiscraft...](https://web.archive.org/web/20110102015130/http://basiscraft.com/0800-0100-the- tcl-war.html)

<comment><USER10> Dunno if I'm dense, but reading that second post, I can't figure out if he's saying Lord's name was attached to RMS's post, vice versa, or some third party attached both of their names.

I'm guessing you mean it's the second possibility, but I can't figure out how you get to there from reading it.

<comment><USER5> Two things about it make me think that RMS actually wrote it (probably after consultation with Lord). The first is this sentence in that post by Lord: "Who cares if a post occurs under my name that I didn't post so long as I more or less agree with it -- this isn't about ego."

The second is writing style. The Tcl War post is classic RMS. Compare it to this reminiscence from Lord and it's hard to imagine they were written by the same person.

<comment><USER9> When I wrote my comment above I skimmed through Thomas Lord's essay, found that the parts I remembered being there were all in their place, pasted the link and pressed "submit". In particular, I remembered the paragraph from which you quote as written in a ironic manner, suggesting with a wink at the reader that Lord actually wrote the post. Now that I've reread the essay, I don't see that at all. I think in that paragraph he probably says what he means. That, and you are right about the style.

In short, I retract my claim. Sorry to whoever I misled! My confidence was completely misplaced.

<comment><USER11> I should be wary of the account anyhow. For calibration: it's just false to say egcs was due to "friends of Cygnus" and "hostile"; it was friends of GCC with the intention it should turn out as it did, happily.

I can't find anything archived to check but, as I recall, Lord later posted a bizarre sort of semi-retraction in rms' name, and rms fired him soon afterwards, possibly as a result. Perhaps that's partly a source of rms- didn't-write-it ideas? I don't remember the suggestion at the time.

</comment></comment></comment></comment></comment><comment><USER12> Having spent the past few weeks debugging a Gtk application, Gtk is such a step _backwards_ from Tk. It's so difficult to predictably lay out a Gtk application in code, things which Tk solved with the beautifully elegant pack and later grid models.

The Tcl language OTOH .. awful once you tried to do anything mildly complicated.

<comment><USER13> Depends on what you mean by "complicated". My habit is to lay things out in event cross state and for that, it's pretty even. IMO, FSM are awfully good at reducing/decomposing complexity. An FSM in Tcl may look like:

array set FSM {

init {

        ...

        set state two

} two {

        ...

} }

...

set state init

...

eval $FSM($state)

I have just put together too many things that would have been severely daunting in any other way in this manner to agree with you.

</comment></comment><comment><USER14> I both like to use Tcl and Lisp. Tcl and Tk I use for smaller tools and Lisp for larger application programming. While the Tcl syntax indeed is a big rough, its also very simple - I can strongly recommend to read Ousterhouts Tcl book for insights. It is also remarkable, that Tcl is one of the few languages that like Lisp allow the user to define arbitrary syntax elements (e.g. you could rebuild if, for, ...) in the language itself. This is a very powerful feature which allows you to create new abstractions the original language designer did not build in.

Beyond that, Tcl comes with a rather complete runtime, and using tclkit, you can very easily create standalone and small (<2M) installation-free packages out of your program. This is very valuable, especially if you have to distribute to Windows. This is where Tcl easily pulls ahead of a lot of languages.

And often I use Tk for the user interface of my Lisp programs via Ltk, which brings both together.

</comment><comment><USER5> Heh. In a recent overhaul of my site, I considered taking these pages down. But they do still get a reasonable amount of traffic, and I hate broken links.

Thanks to amelius for the "Tcl the Misunderstood" link. I agree with that, for the most part. I haven't written Tcl in many years, but I don't think it deserves the reputation that it has.

</comment><comment><USER15> To my mind, there's a tremendous irony in the 1994 flame war. A user of Tcl since the 1990's I'd read, and been amused by, the hyperbole contained in those long-ago comments a number of times. Not that flaming doesn't still happen, such emotion isn't hard to find, though the subjects in dispute vary, the form of battle remains the same.

Goes without saying that there's a nub of truth in those ancient rants. Tcl can be kind of hard to catch on to, but then again, the Gnu "replacement", the Guile implementation of Scheme, is also hardly a mainstream favorite. Plenty of hate is expressed toward Lisp-derived fully parenthesized languages, Scheme included.

The not-so-dirty secret in the "language war" is that Tcl is itself very much a Lisp-like language, and over the years has increasingly adopted many features that make it even closer to languages like Scheme.

Having become reasonably fluent in both Tcl and Scheme I see similarities that outweigh syntactic differences. Not identical of course, but translating programs across them is fairly straightforward compared to C-like code, e.g., Javascript.

Maybe Lisp derivatives are an acquired taste, or maybe there some inborn twisted brain thing that entices some and repels others. At any rate, I'm convinced Tcl and Scheme are very capable languages, admittedly different in approach vs. more commonly used systems. Looking back it is ever so obvious that the old war was fought between two sects of the same tribe, and isn't that often the source of the fiercest rivalries.

</comment><comment><USER16> Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil:

"In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."

[http://www.lua.org/doc/hopl.pdf](http://www.lua.org/doc/hopl.pdf)

</comment><comment><USER17> The Guile vaporware was the first time I really lost respect for Stallman and the FSF. It's incredibly damaging to say "don't use TCL use Guile instead" and then never actually produce a useful Guile product. A similar pattern happened in the same timeframe with the Hurd kernel.

I have an enormous amount of respect for the FSF. But it has been most effective when it has working code, like gcc or emacs. The political pronouncements not backed up by working code were actively harmful.

<comment><USER18> IIRC, GnuCash and LilyPond use Guile. The project itself now has some good maintainers, and has been making strides since its 2.0 release. Some parts of the (small) Scheme community have taken notice, and new projects are popping up; like GNU Artanis[0].

Oh ah, and there's Guix[1].

0: [http://web-artanis.com/](http://web-artanis.com/)

1: [https://www.gnu.org/software/guix/](https://www.gnu.org/software/guix/)

<comment><USER19> For a long time -- until Andy Wingo took over development -- Guile was kind of a joke of a Scheme. It was horrendously slow and buggy, and it was updated very infrequently. Since Andy took over, it's quickly become one of the better choices for Scheme. Guile 2.0 is solid and reasonably fast. The 2.2 release is shaping up to be even better and even faster. Andy has done a great job with it, and he keeps his blog[0] updated with a lot of interesting posts about Guile internals and development.

[0]: [http://wingolog.org/](http://wingolog.org/)

<comment><USER17> I appreciate the irony that TCL is basically a dead end but Guile development continues. Thanks for giving context for why!

</comment></comment></comment></comment><comment><USER20> tl;dr: John Ousterhout's reasonable reply: [http://vanderburg.org/old_pages/Tcl/war/0009.html](http://vanderburg.org/old_pages/Tcl/war/0009.html) , done

(Submitted page looks like an Usenet Who's Who index ;-)

<comment><USER21> yes, he is good. this is my favourite part:

"I didn't design Tcl for building huge programs with 10's or 100's of thousands of lines of Tcl, and I've been pretty surprised that people have used it for huge programs."

lots of Tcl criticism stems from the fact that people started using Tcl not in the way it was intended.

<comment><USER13> I have trouble finding things that require more than 10kloc of Tcl but Tcl has been extended since Osterhout sorta faded on it.

It has features like namespaces and package management since at least 8.x . Language comparison is always challenging. I've had less trouble with Tcl than with just about any other language. But it rather requires thinking about the problem in certain ways. The main thing it requires is adherence to an event driven model.

</comment></comment></comment><comment><USER22> Posting on a newsgroup for X that X sucks is the _very definition_ of trolling. Since long before it came to mean "anyone who disagrees with me for any reason".

</comment><comment><USER23> Dived into tcl wiki after writing a program with tkinter (tk python bindings), it's amazing to see a community speak about other paradigms. Reading how they approached FP idioms for instance. I felt this way with perl too. These are two old languages that are mostly ignored nowadays (except for the perl6 has shipped) but they have very interesting ways.

<comment> david-given If you're interested in Tcl, you might also like to look at TH1:

[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md](https://www.fossil- scm.org/xfer/doc/trunk/www/th1.md)

It's a tiny Tcl subset, implemented in only a few kloc. It's used by Fossil as a HTML templating engine but it's easily adaptable for other things. It's small enough to be understood and does an excellent job of demonstrating the core principles of how string-processing languages think.

<comment><USER24> @david-given probably knows this, but that TH1 is Tcl-ish is no surprise, given fossils founder/principle author is drh (Richard Hipp).

drh is a former Tcl Core Team member[0], and probably most famous as the author of Sqlite, originally a Tcl extension that "escaped into the wild"[1]. Sqlite also has a comprehensive test-suite written in Tcl[2].

[edit: footnotes]

[0] [http://wiki.tcl.tk/977](http://wiki.tcl.tk/977)

[1] [http://www.sqlite.org/src/doc/trunk/README.md](http://www.sqlite.org/src/doc/trunk/README.md)

[2] [http://www.sqlite.org/testing.html](http://www.sqlite.org/testing.html)

<comment><USER23> How fun is history sometimes, would never have thought sqlite wasn't a "standalone" first project.

</comment></comment></comment></comment><comment><USER25> It so happens that the 14th annual European Tcl/Tk users conference just took place [1]. Quick perusal of the event site shows the breadth of uses Tcl is still being put to (enthusiastically, by programmers who choose to use it):

* nuclear power plant operations

* high-performance visualization and analysis of microscopic images.

* design analysis of high-resolution camera light sensors.

* embedded programming of Cortex-M3 ARM v7-Microcontroller.

* satellite control systems.

* multi-platform/compiler automated C++ library compilation.

* customization of the Fossil VCS.

* scripting and visual programming on Android.

* communicating sequential process programming.

* Linux D-Bus scripting.

Slag Tcl all you want, but it's still being used every day by brilliant programmers to ship real products, in environments where reliability is crucial. How does Guile stack up to that? Or any other unfashionable programming language for that matter?

Maybe more effort should be put into understanding what these programmers see in Tcl that the critics can't.

[1] [http://www.eurotcl.tcl3d.org/index.html](http://www.eurotcl.tcl3d.org/index.html)

</comment><comment><USER26> Coming in from the harsh fronts of YouTube, Reddit and 4Chan, this is an awfully tame flame war.

In any case, a lot of good points are raised by both sides. As an Emacs user, I appreciate Stallman's points, but he does make a fatal mistake, in that he doesn't include popular extensions like itcl in his evaluation. That's like evaluating lisp without considering popular macros, or the potential of macros. While that doesn't alleviate the problems Stallman has with tcl's lack of datastructures, those are not insurmountable with a couple of well-written C-extensions, assuming that tcl's C interop is any good at all.

Also, tcl is a pretty terrible lisp, as although they have a lot on common, the differences are substantial enough for fans of one to have some degree of distaste for the other.

The most entertaining part is that Stallman criticises tcl for lacking common datastructures, being slow, and having bizarre syntax that appeals to hackers alone. ESR (and, I believe, Stallman, although I am unsure), goes on to note the common use of dynamic scope, confusing quoting mechanism, and the horrors of upvar and upvalue.

Gee. DOES THAT. SOUND. FAMILIAR?

If it does, it's because most of those problems also appeared in MacLisp, the direct predecessor to Common Lisp. Many of them also appear in other lisps:

Linked lists, an unusual datastructure, are one of the few well supported by Lisp. Lisp used to be quite slow, and many implementations still are. Dynamic scope is still the default in elisp, and macros just barely hold the system together when you're writing lots of code, a cicumstance that Stallman claims elisp is actually better in than tcl. As for confusing quoting, `(there ,(is 'quite) ,@(a lot) of that in lisp). And upvar and upvalue are in some ways less dangerous than macros.

Actually, lisp used to have its own version of upvar and upvalue, coupled with a mechanism called the fexpr that let you get rid of a lot of the quotes. These were not implemented in most later lisps, due to the fact that they are nearly impossible to optimize well.

At the end of the day, whether you love or hate tcl and lisp, there are people out there that are stuck using far worse extension languages. Like these poor sods: [https://gitlab.com/xonotic/xonotic/wikis/QuakeC/Introduction...](https://gitlab.com/xonotic/xonotic/wikis/QuakeC/Introduction_to_QuakeC).

</comment><comment><USER27> Inferno, the Bell-Labs system, uses a Tk implementation to lay out the UI.

[http://doc.cat-v.org/inferno/4th_edition/limbotk/](http://doc.cat-v.org/inferno/4th_edition/limbotk/)

</comment><comment><USER28> There was an interesting article by Ousterhout (Tcl creator) about scripting languages versus system programming languages some years ago. I think I read it in one of the print computer magazines that existed at the time - <USER2> Development Magazine, Unix Review, Dr. Dobb's Journal, C User's Journal, or some such. I wonder whether he was inspired to write that article after this post (mentioned elsewhere in this thread):

[http://vanderburg.org/old_pages/Tcl/war/0009.html](http://vanderburg.org/old_pages/Tcl/war/0009.html)

<comment><USER24> Are you referring to this: [http://www.tcl.tk/doc/scripting.html](http://www.tcl.tk/doc/scripting.html) ?

<comment><USER28> Just took a quick look at it. Need to read more, which I will, but pretty sure it is that one. I doubt he would write more than one article on that topic, also it is slightly long (about 24 PgDn keystrokes on my PC :), which I remember from before.

Excellent. I thought of googling for relevant keywords to check if the article was online (after posting my previous comment here), but you saved me the trouble. Thanks!

</comment></comment></comment><comment><USER29> The guile history also mentions the TCL war from their point of view: [https://wingolog.org/archives/2009/01/07/a-brief-history- of-...](https://wingolog.org/archives/2009/01/07/a-brief-history-of-guile) although it misses the important technical details. Stallman was right with his criticism, but could of course convince nobody to add the missing features. Some of them came with 8.5 eventually but support for lexicals (upvar) is still horrible.

</comment><comment><USER30> >> It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.

Did I miss the rebuttal to this?

<comment><USER5> There was a semi-rebuttal … I think in a post from Brent Welch. Tcl does have things called "arrays", and you use them much as you'd expect. Tom Lord confirmed later that what he and RMS meant by this was that it didn't have "true arrays" that are laid out contiguously in memory, to be much more efficient. That's a valid criticism: Tcl's arrays are basically dual-use hash tables, much the same as JavaScript's arrays.

The other two things are totally valid. Tcl has no references, so you can't build your own linked list. And all values are (at least semantically) strings, so numeric operations are slow.

But of course, a lot can be done to optimize those things in the implementation, and over time at least some of that optimization was done.

<comment><USER13> Lists are a first-class object in Tcl, so it's not clear to me how much of a deficiency not having linked lists is.

I've had cases where opening a 'C' program as a pipe and doing heavy number crunching in the 'C' program outperformed native Tcl.

<comment><USER31> > _Lists are a first-class object in Tcl_

Was that the case in 1994, or are you writing about the current state of Tcl?

<comment><USER13> I believe it's been true since the language first saw light.

I didn't get to it until around v7.x around 1995 and lists feature prominently in Osterhout's book.

</comment></comment></comment></comment></comment><comment><USER32> I love how RMS always begin is war on language with "it does not have a LISP/scheme syntax".

University coders and their obsession of purity of syntax (map/purity) superior to actually dealing with the true problem of the hardware is looking (territory/practicality) is looking for me like an Aristolecian argument of superiority of the style over the «getting things done».

Well, as spotted in the answers, expect is a nice non university bred innovation (is it?) that is still a de facto standard in handling interactive session (stateful) with a simple syntax that helps getting things done with maintainable code.

It is ported in Perl, python ... and I think this is probably a point for what Tcl is worthy : getting things done.

Practicality beats purity.

And as of today it is still the most portable way to write embeddable graphical user interface that have good FFI.

<comment><USER23> Lisp is close to syntaxless. What "lisp syntax" means is principled to the bones systems, including syntax. The fact that everything in lisp was in recursively defined lists meant you could reuse recursive thinking everywhere. An `infinite` tower of reuse. You get genericity, pattern matching, combinatorial generation for very low cost. It's not practical for people crunching data or opening files .. but whenever you need to attack something a little more complex the 'practicality' argument shift sides.

<comment><USER33> Well, if he meant "it doesn't have S-expressions", he should have said that. That's not an unreasonable expectation for a guy who is otherwise a pedant in almost all other areas of his life.

<comment><USER23> Fair point, and to be honest, it's a common problem in many places. People enjoying a property often fail to communicate it clearly with those who never did. Math, and I believe Lisp has many times more inherited math genes than other languages, is especially guilty of this. It's often a lethal cultural shock.

<comment><USER34> S-Expressions are fun. When I first learned a Lisp, Scheme in my case, I found them weird but could see the appeal.

When I learned Haskell afterwards, it was the opposite: I thought I'd miss S-Expressions, but I learned to like its more baroque syntax.

S-Expressions have the chief virtue of making even the most crude macro look no different from the most over-engineered builtin to the language from the user's point of view.

And they clearly separate the syntactical space in the language, so that new features (whether as macro or built-in) can always find a space. Compare to the cracks of C they had to fit C++ into.

Haskell might be even worse. The chief obstacle to adding OCaml or-patterns to Haskell ([https://stackoverflow.com/questions/24700762/or-patterns- in-...](https://stackoverflow.com/questions/24700762/or-patterns-in-haskell)) seem to be finding a syntax that's both pleasant and fits between the strands of the fine web in ascii space of already valid Haskell programs.

<comment><USER26> ...And I never grew to like Haskell. The syntax makes all of your programs look very elegant, but there are no clear delimiters. The syntax for how functions are delimited isn't clearly explained by most sources. And I don't want to type my code and just hope that the magical compiler fairies deduce my meaning. That kind of programming attracts bugs like a man covered in honey.

<comment><USER11> I don't know what that means, but if the objection is to layout ("the off-side rule"), that's just an alternative to the braces and semi-colons that you'd typically use if it was machine-generated, for instance.

<comment><USER26> The objection isn't so much to the layout, as it is to the fact that I can't find any documentation as to what the layout is and how the compiler interprets it.

<comment><USER34> Interesting. I've never bothered to look up the formal specs, but it was never a problem that lead to an ambiguous interpretation of my programs. (I sometimes write programs that the compiler doesn't like. But seldom once that the compiler interprets different from me.)

I usually give types for my top level functions. It's good documentation, and also prevents most of these kind of issues. (For a similar example, human mistakes with operator precedence usually lead to compile-time type errors in Haskell, seldom to runtime problems like in C or C++.)

<comment><USER26> It's not a huge problem, but lack of understanding of how the compiler delineates blocks of code makes the code hard to reason about. I like to know what the compiler will do with my code, and what is and isn't valid through something other than trial and error. Scheme's perfect regularity makes that easy. Haskell... doesn't.

I am aware that the information exists somewhere, and I think I got a link a bit back, so I'll have to go track that down. But it is absolutely baffling that people don't discuss it more. Would you be able to write Python if nobody told you about the indentation rules? Of course not.

I'll have to find that link...</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Decentralized Reputation in OpenBazaar - <AUTHOR> https://blog.openbazaar.org/decentralized-reputation-in-openbazaar/ <comment><USER2> It was always sad to see the distributed currency Bitcoin be used in a centralized manner (e.g. SilkRoad & MtGox). Satoshi Nakamoto said, "Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own". But using these centralized exchanges prevents a fully p2p ecosystem.

Bitcoin provided trusted p2p money and money transactions. But needs to be complimented with trusted p2p reputation and transactions of goods/services.

Such a distributed marketplace was talked about in the early days of the bitcoin forum, and I remember OpenBazaar comming about after the seizure of silkroad. I'm glad their github repo is active.

Sorry I don't have any conversation to contribute specifically to this article, as I haven't fully grooked the details of this yet, but thought I would write the first comment here.</comment>


Python-ftfy: Given Unicode text, make its representation possibly less broken - <AUTHOR> https://github.com/LuminosoInsight/python-ftfy <comment><USER2> It even successfully un-mangles the shipping label from Ode to a Shipping Label: [https://www.facebook.com/cmb/posts/619241744770551:0](https://www.facebook.com/cmb/posts/619241744770551:0)

        >>> ftfy.fix_text('L&amp;Atilde;&amp;sup3;pez')
        'López'

Bravo!

</comment><comment><USER3> Very common problem in web scraping, for example forum site might contain a mix of MacRoman, Windows codepage and various european codepages in a single page (yes, even in 2014!). Seems like a more advanced version of UnicodeDammit module ( [http://www.crummy.com/software/BeautifulSoup/bs4/doc/#unicod...](http://www.crummy.com/software/BeautifulSoup/bs4/doc/#unicode- dammit) ).

Note: this module, like UnicodeDammit, is very US/English-centric, and is _practically useless_ for worldwide web scraping. For non-english pages, it is necessary to statistically estimate the codepage and language of each page segment, and then try to normalize each segment to unicode.

<comment><USER4> The way I understand it from their examples, it's rather latin-written- languages-centric, no? Could you give an example where it doesn't work with a romanized language? If not, then I'd hardly call that English-centric and practically useless worldwide.

<comment><USER3> from __init__.guess_bytes(): "This is not a magic bullet. If the bytes are coming from some MySQL database with the "character set" set to ISO Elbonian, this won't figure it out. Perhaps more relevantly, this currently doesn't try East Asian encodings."

The world is a very large place, there are many codepages in use besides latin-1 and "ISO Elbonian". All central european contries use latin-2 (1250), or cyrillic codepage (1251). Since they are all single-byte codepages, they cannot be detected by try: convert() catch: try_another_codepage() and must be distinguished statistically. LTR/RTL language and asian encoding detection is even worse. [https://en.wikipedia.org/wiki/Code_page](https://en.wikipedia.org/wiki/Code_page) [https://en.wikipedia.org/wiki/Windows_code_pages](https://en.wikipedia.org/wiki/Windows_code_pages)

Another python Unicode conversion module which is slightly less US/English- centric: [https://github.com/buriy/python- readability](https://github.com/buriy/python-readability)

<comment><AUTHOR> I would like to emphasize that "guess_bytes" is not what ftfy is about. It's there for convenience, and because the command-line version can't work without it. But the main "fix_text" function isn't about guessing the encodings of bytes.

Not all text arrives in the form of unmarked bytes. HTTP gives you bytes marked with an encoding. JSON straight up gives you Unicode. Once you have that Unicode, you might notice problems with it like mojibake, and ftfy is designed for fixing that.

Like you say, encoding detection has to be done statistically. That's a great goal for another project (man, I wish chardet could do it), but once statistics get in there, it would be completely impossible to get a false positive rate as low as ftfy has.

</comment></comment></comment></comment><comment><USER5> Had a dataset where this was the case.. old devs used Windows, I'm not sure what the DB encoding was set as when they did imports, etc. I've been putting off fixing it because it's just a PITA to deal with.

But I built a sanitizer in a couple hours with this lib, and it seems to work pretty well.

The only unexpected thing is that it converts the ordinal indicator º to o in addresses. Luckily there are only a handful I need to fix.

<comment><USER6> This is an impact of the default Unicode normalization, which is set to NFKC. This normalization is lossy for things like the ordinal indicator and trademark symbol; if you'd like to keep the ordinal indicator unchanged, use NFC normalization:

      >>> print ftfy.fix_text(u'ordinal indicator º to o in addresses.')
      ordinal indicator o to o in addresses.

      >>> print ftfy.fix_text(u'ordinal indicator º to o in addresses.',normalization='NFC')
      ordinal indicator º to o in addresses.

</comment></comment><comment><USER7> I can't help but think that this merely gives people the excuse they need for not understanding this "Things-that-are-not-ASCII" problem. Using this library is a desperate attempt to have a _just-fix-it_ function, but it can never cover all cases, and will inevitably corrupt data. To use this library is to remain an ASCII neanderthal, ignorant of the modern world and the difference of text, bytes and encodings.

Let me explain in some detail why this library is not a good thing:

In an ideal world, you would _know_ what encoding bytes are in and could therefore decode them explicitly using the known correct encoding, and this library would be redundant.

If instead, as is often the case in the real world, the coding is _unknown_ , there exists the question of how to resolve the _numerous ambiguities_ which result. A library such as this would have to _guess_ what encoding to use in each specific instance, and the choices it ideally should make are _extremely_ dependent on the circumstances and even the immediate context. As it is, the library is hard-coded with some specific algorithms to choose some encodings over others, and if those assumptions does not match your use case _exactly_ , the library will corrupt your data.

A much better solution would perhaps involve a machine learning solution to the problem, and having the library be trained to deduce the probable encodings from a large set of example data from each user's _individual_ use case. Even these will occasionally be wrong, but at least it would be the best we could do with unknown encodings without resorting to manual processing.

However, a _one-size-fits-all_ "solution" such as this is merely giving people a further excuse to keep not caring about encodings, to pretend that encodings can be "detected", and that there exists such a thing as "plain text".

<comment><AUTHOR> I think you're criticizing the wrong library. ftfy isn't about encoding detection. Should I take guess_bytes out of the documentation to stop giving that impression?

It's the library you use when the data you get has _already_ been decoded incorrectly. The user of ftfy cares about encodings, but gets data from sources that don't.

And in no practical sense does it corrupt your data. I don't know where you got that idea from. It leaves good data alone.

I will not say that false positives are _nonexistent_ , but they are vanishingly rare -- see [http://ftfy.readthedocs.org/en/latest/#accuracy](http://ftfy.readthedocs.org/en/latest/#accuracy) \-- and they don't occur in "serious" data, they occur when people are screwing around with bizarre emoticons and stuff.

<comment><USER8> Well, teddyh might have a point here, nonetheless: By now, I understand that ftfy is about fixing mixed up encodings between UTF8, latin-1, CP437, CP125[12] and MacRoman (only). But by claiming you are fixing "Unicode" in general as the first thing on the GitHub page, you might be misleading first- time visitors. Maybe you should try to place the "warning" about the encodings your library does handle right at the start somewhere? And make it clear that "moji-un-baking" is the library's central and main use-case, not just an "interesting thing" it can do. Despite being quite aware of Unicode and string encoding, I had exactly the same thoughts as teddyh as I read the first few paragraphs ("Oh, now we will see those encoding illiterates converting all those beautiful bytes in some highly informative character encoding to all- too-boring-ASCII.")

Which leads me to my other concern: Why do you use NFKC compatibility as the default normalization? Given you are a text mining company, you of all guys should know you loose valuable information - particularly about numbers, super- and subscript characters - with this normalization strategy. Doing NFKC on stuff like all kinds of articles, books, patents, etc. would lead to potentially disastrous results (e.g., NFKC "decomposes" the string 'O\u2082\u00B9' to 'O21' instead of 'O_2^1' \- "oxygen, reference 1"). In general, I think NFC is what Python and many other libraries do, while I believe NFKC should only be used when you know what you are doing (and why you need it). Maybe it is useful for some strange, geeky tweets, but I would argue that its the corner case, not the default.

<comment><AUTHOR> I wonder if I could change the default to NFC in the next version without breaking people's expectations. It is a safer default.

When it comes to text analytics, the underlying tagger and stuff won't know what O21 is any more than it knows what O_2^1 is anyway. And NFKC is useful for mixed Latin and Japanese text, which I wouldn't entirely dismiss as strange and geeky. But it's true that the default could be more conservative.

</comment></comment></comment></comment><comment><USER9> This is a great project because a lot of work has been put into finding solutions to many different edge cases, and it "just works".

</comment><comment><USER10> The last testimonial in the README gave me a good laugh :)

</comment><comment><USER11> This will mangle text discussing mojibake.

</comment><comment><USER12> Dude, i'll pay you a beer if you want, this project is fucking awsome!

</comment><comment><USER13> Wow, recruiting pitch at the top of the README. Someone make Adblock for Github.

<comment><USER14> I think the least we can give in return to companies that open-source useful stuff like this is look the other way when they self-promote a little bit.</comment></comment>


Hooked – Why Netflix and Amazon want your kids - <AUTHOR> https://stories.californiasunday.com/2015-07-05/why-amazon-and-netflix-want-your-kids/

<comment><USER2> _According to the American Academy of Pediatrics, the average 8-year-old spends eight hours a day — 56 hours per week — using electronic media such as laptops, tablets, and smartphones._

Wow!

<comment><USER3> 7-8 tv

8-4 school

4-11 tv

<comment><USER4> Aside from the TV usage, going to sleep at 11 PM for an 8 year old is not healthy. This 8 hour sleep bullshit is nonsense, children require substantially more sleep.

<comment><USER5> 8 hours is okay - for adults. infants need ~11 hours sleep to stay/grow healthy.

<comment><USER4> Infants need closer to 16. Children need about 11. Adults range from 7 to 10.

Averages are useful for some things, but are unbelievably misleading with others.</comment></comment></comment></comment></comment>


Eliza, the Rogerian Therapist (1999) - <AUTHOR> http://psych.fullerton.edu/mbirnbaum/psych101/Eliza.htm <comment><USER2> Go read ELIZA's author, Joseph Weizenbaum's book, "Computer and Human Reason"; well at least the first 2 chapters. Let me justify it, (I'm typing it out from a hard copy so excuse my brevity)

Page 4:

"DOCTOR...soon became famous...mainly because it was an easy program to demonstrate. Most other programs could not vividly demonstrate the information-processing power of a computer to visitors who did not already have some specialized knowledge"

As in, the mid-1960s, this was (one of) the first non-technical computer programs. No commands, no manual, no conceptual overview needed - just sit down and start typing.

Page 6:

"I suggested I might rig the system so that I could examine all conversations anyone had had with it, say, overnight. I was promptly bombarded with accusations that what I proposed amounted to spying on people's most intimate thoughts; clear evidence that people were conversing with the computer as if it were a person who could be appropriately and usefully addressed in intimate terms ... what I had not realized is that extremely short exposure to a relatively simple computer program could induce powerful delusional thinking in quite normal people."

Page 38:

"Like highways and automobiles, they [new forms of media] enable the society to articulate entirely new forms of social action, but at the same time they irreversibly disable formerly available modes of social behavior."

... that's a pretty deep insight about social media, especially from 1976.

Pages 115-130 he writes quite critically of "hacker culture", characterizing the participants as "compulsive programmers" and comparing them to gamblers. I'm not making any judgment on his claims in those pages, but his arguments are fairly unique and I had not seen them before.

<comment><USER3> The bit about "delusional thinking" is incredibly condescending.

<comment><USER2> Although you can certainly read it that way, I don't think that was his intention. From the broader context, I believe he was trying to use it clinically and not as a derisive insult. He was trying to understand the mechanisms which made people have emotional connections with a computer program.

"Maybe it's because people saw it as a tool and people become emotionally attached to tools" you may think. Coincidentally his chapter following that is entitled "On Tools" where he goes into psychological literature on human-tool interaction.

\---

Also there's an unspoken context here that he gets a step away from a few times without hitting it:

Non-technical people understood computers from their popular depictions; perfect electronic brains; profoundly superior-to-human machines.

Some people likely assumed there was an infallibility to the interaction, as if someone, say unfamiliar with stage magic, saw a magic trick and assumed it was sorcery. People employ whatever mental model they're familiar with that fits best.

The idea it was _merely_ just rearranging your words and feeding it back at you likely seemed just outrageously galling to be the thing a multi-million dollar machine that takes up an entire room and coming from the MIT Artificial Intelligence Lab is doing. No. It must be real...

Almost as outrageous as someone suggesting your sorcerer simply put the item in his pocket while he was distracting you.

Eliza, in 1965 was a computer version of Uri Geller.

\---

Another idea relating to Milgram, he never pointed out whether people trusted that a machine would have had safety precautions built in. Of all his variations I'm not familiar with any where he made the machine "malfunction".

Would subjects then trust the proctor but distrust the machine and back off more or perhaps, even more interesting, would there be no difference at all?

<comment><USER3> People can have strong emotional/sentimental connections with anything. It doesn't make them delusional, even in the clinical sense. For example, a diary.

But I take your point that people at the time may have misunderstood the program, possibly believing it was _actually_ sentient. That's a mistake belief, not a delusion.

<comment><USER2> He does point that out in a part I omitted. I wish the work was online so I could just link you but please, don't take my selective quoting as a faithful representation, it probably isn't, I'm just some internet rando.

Go get your hands on a copy, you can probably find one for under $7 on eBay

</comment></comment></comment></comment></comment><comment><USER4> So many great Eliza submissions in the past:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=comments%3E0%20Eliza&sort=byDate&type=story&storyText=none)

But not really any fundamental discussions, probably because it was already so well known as a thing.

</comment><comment><USER5> For anyone interested in learning more I recommend the 99% Invisible episode on it: [https://99percentinvisible.org/episode/the-eliza- effect/](https://99percentinvisible.org/episode/the-eliza-effect/)

</comment><comment><USER6> Eliza was great value for as long as you could stay within its limitations. Eliza was a true friend.

Imagine Eliza GPT 2020, speech enabled friend in pocket.

Who's going to implement it?

</comment><comment><USER7> I've got one for my 404 page. Quite fun.</comment>


Ask HN: Do you ever use an online whiteboard? - <AUTHOR> I'm a developer that's studying product management.
I have a product idea for an online whiteboard.
I know there are already some out there and I'm investigating if there's room for a new product that fills a need not met.
I'd love to hear from the community about your experience using one.
Otherwise, if you'd care to respond anonymously, I've got an online survey
https://www.surveymonkey.com/r/SHVWYRV <comment><USER2> I dont. I love whiteboards if i have a stylus. But I seldom do

<comment><USER3> Seconded.

I do have a stylus in my Note 4 phone. It gets considerable use because it's there.

The mouse doesn't work well for this use case. A track pad can... but marginally.

Google Sheets actually works fairly well for some list or discussion oriented WB tasks.

<comment><USER4> You can use a Wacom graphics tablet, which generally works very well.

<comment><USER3> With the exception being I will probably never be where said tablet actually is.

Right now, it's laptop and phone. Not gonna carry anything else. The next "laptop" may well be one of these "can be tablet" devices. No way I would need a Wacom, though they are fantastic. I've used 'em in the past.

<comment><USER4> The latest Surface laptops look interesting. It will be interesting to see if Apple comes out with a touchscreen laptop in the future.

<comment><USER3> The user experience on the Surface machines is pretty good right now. I would be very interested to see how Apple would end up doing it too.</comment></comment></comment></comment></comment></comment>


Incoming space junk a scientific opportunity - <AUTHOR> http://www.nature.com/news/incoming-space-junk-a-scientific-opportunity-1.18642 <comment><USER2> It could be a cosmonaut! [https://en.wikipedia.org/wiki/Lost_Cosmonauts#Andrei_Mikoyan](https://en.wikipedia.org/wiki/Lost_Cosmonauts#Andrei_Mikoyan)

<comment><USER3> Well, that's in the Confirmed Hoaxes section of that page. :)

The N1 rocket (USSR's workhorse for their Lunar space program in the '60s) never worked well. Chief Engineer Korolev (the Russian counterpart to Wernher von Braun) dying in the mid-60s certainly didn't help. The project suffered from "financial malnutrition" for a long time, due to political infighting within the top levels of the Communist Party.

The N1 test launches were all rushed, improvised affairs that failed, sometimes spectacularly. [https://en.wikipedia.org/wiki/Largest_artificial_non- nuclear...](https://en.wikipedia.org/wiki/Largest_artificial_non- nuclear_explosions#Rank_order_of_largest_conventional_explosions.2Fdetonations_by_magnitude)

The way the project operated was, basically, "we don't have enough money to run horizontal burn tests properly, so we'll do it live, with a full-scale vertical launch". The results were what you would expect.

Main point is, the Russians didn't have a properly working vehicle in the '60s to reach Moon orbit. They were starting to figure out the issues with the N1 towards the end of the decade, but then Armstrong set foot on Luna and the rest is history. The N1 was cancelled quietly in the mid-70s.

</comment></comment><comment><USER4> So is this man-made space junk or what?

<comment><USER5> Almost certainly one of the various artificial object we discarded in orbit around the sun. For a complete list of candidate objects: [https://en.wikipedia.org/wiki/List_of_artificial_objects_in_...](https://en.wikipedia.org/wiki/List_of_artificial_objects_in_heliocentric_orbit)

Because their orbits are so close to the Earth (essentially they're artificial near-Earth asteroids), they're periodically recaptured into quasi stable orbits around Earth. Example: [https://upload.wikimedia.org/wikipedia/commons/3/39/J002e3f_...](https://upload.wikimedia.org/wikipedia/commons/3/39/J002e3f_orbit.gif)

> _The object is only 1 to 2 metres in size, and its trajectory shows that it > has a low density, and is perhaps hollow. That suggests an artificial > object, "a lost piece of space history that's come back to haunt us", says > Jonathan McDowell, an astrophysicist at the Harvard–Smithsonian Center for > Astrophysics in Cambridge, Massachusetts. It could be a spent rocket stage > or paneling shed by a recent Moon mission. It is also possible that the > debris dates back decades, perhaps even to the Apollo era. An object seen > orbiting Earth in 2002 was eventually identified as a discarded segment of > the Saturn V rocket that launched the second mission to land men on the > Moon._

Ahh yes, the curious case of J002E3, aka the S-IVB stage of Apollo 12. The example orbit animation above is J002E3, actually! [https://en.wikipedia.org/wiki/J002E3](https://en.wikipedia.org/wiki/J002E3)</comment></comment>