DevOps from Scratch, Part 1: Vagrant and Ansible - <AUTHOR> https://www.kevinlondon.com/2016/09/19/devops-from-scratch-pt-1.html <comment><USER2> Ansible seems to be the best of the bunch, at least for my use-case which is just a handful VMs (Chef seemed to require more infrastructure than what it would be managing).

So let me rant about it for a bit:

\- Whatever that language is, it's not something invented on earth. I've given up on learning when to use quotes or how it wants its indentations and just copy&paste&destroy everything&restart when it doesn't work after 15 minutes.

\- There are a few thousands tests in their test suite, which makes it quite a feat to introduce a bug that breaks what amounts to "passing variables to a subroutine": [https://github.com/ansible/ansible/issues/17356](https://github.com/ansible/ansible/issues/17356). (2 hours today I won't get back). I seriously don't know any other software where I spend most of my time reading through github issues.

\- It's a tool to manage hosts. Which would make me think that "reboot" shouldn't be a dirty word. But there's actually no function to do (a) ```/bin/sh reboot```, (b) wait for it to come back. First request I found is four years old: [https://github.com/ansible/ansible/issues/513](https://github.com/ansible/ansible/issues/513). The current request has a nice summary of the cottage industry of "blog articles that explain how to reboot & wait": [https://github.com/ansible/ansible/issues/16186](https://github.com/ansible/ansible/issues/16186)

\- Projects are structured in a quite "sparse" folder structure. A small project usually has 25 files in 20 folders and 18 of them are "main.yml" which is probably a conspiracy to annoy me. The main feature an editor plugin for ansible needs is not syntax highlighting but "use second-to-last folder name instead of filename on tabs".

-

<comment><USER3> \- Ansible lacks proper error handling

\- YAML is not a proper programming language

\- It's not easy to create reusable "functions". You can include tasks but it can be painful to manage variables, you can depend on roles but everything ends up in separate folders and files.

In retrospect I would prefer to just use Fabric, or use Ansible modules through Python.

<comment><USER4> YAML is a config language, not a programming language (Yet Another Markup Language).

If you want to configure your hosts using a programming language, just use shell scripts.

\--

edit: the acronym has been changed to 'YAML Ain't Markup Language', to separate it from documentation languages

</comment></comment></comment><comment><USER5> How much more flapping there needs to be? Chef, Puppet, Ansible, Salt, Vagrant, Docker, CoreOS, runC, Kubernetes, OpenStack, the list goes on and on and on. People are going way, waaayyy out of their way just so they wouldn't learn shell programmimg and how to build all this automation with OS packages. Is learning N amounts of discrete orchestration really easier and simpler than writing shell scripts and encapsulating them in OS packaging? Seriously?!?

Enough with the flapping and discrete solutions already!!!

<comment><USER6> I'm not sure what you mean by "flapping," but the technologies in your list do not all address the same problem space. You might as well ask why we need both Solaris and C++. Only the first four (Chef, Puppet, Ansible, and Salt) are configuration management tools, which take the place of "writing shell scripts and encapsulating them in OS packaging." If you're well-versed in one, there's no need (short of a job change) to learn the others.

Vagrant allows you to create reproducible development environments _using shell scripts_ (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you!

Back to "writing shell scripts and encapsulating them in OS packaging": have you _tried_ a configuration management tool? I used to be old school like you; specifically, maintaining a fleet of AIX instances using a healthy mix of Perl, ksh, and RPM. I too was resistant to the tide of new, quickly-evolving technologies. I started using Ansible about a year ago and it's changed my life. Don't be so quick to pooh pooh the idea that there just might be a better way to do things.

<comment><USER5> _I 'm not sure what you mean by "flapping,"_

Flapping, you know, when a person who cannot swim is drowning and just flailing and flapping their body, most notably arms, all over the place in an attempt to stay above water so that they do not drown.

 _but the technologies in your list do not all address the same problem space._

I don't know about you, but for me to get a fully configured, ready-to-serve system, I need both provisioning and configuration management. With that being the case, provisioning and configuration management fall under the same problem domain.

 _Vagrant allows you to create reproducible development environments using shell scripts (by default), so it should be right up your ally. Docker is used to containerize applications. runC is the container runtime used by Docker. Kubernetes orchestrates containerized applications across a fleet of CoreOS (a minimal "Docker host" Linux) machines. OpenStack orchestrates your data center. They are discrete solutions because they do different things. Each piece of the puzzle does one thing and (hopefully) does it well. That philosophy should sound familiar to you!_

I'm familiar with all of those technologies, and yes it does indeed sound familiar to me!

But, what is unclear to me is, why I would use a discrete provisioning solution like Kubernetes instead of using, say, imgadm(1M) and vmadm(1M) through parallel SSH?

Why would I use a discrete, proprietary solution like Vagrant when I wrote my own, simple variable expansion function which uses eval(1), and that's all that's really needed for configuration management? I'm far, far better off with a simple shell function then using Salt or Ansible. Simplicity, the core of the UNIX principle. eval(1) is much simpler and easier to understand than an entire provisioning and/or configuration management engine! Or do you disagree?

Other than templated configuration excerpts and self-assembly, both easily implemented with a few simple lines of shell code in a small shell library which OS packages can source, what more do I need to configure systems? Why make things unnecessarily complex? In fact, that exact same approach is what Chef uses, conceptually, when one specifies the configuration management policy, except that with my solution, the system administrator need not learn a proprietary Ruby dialect and need not employ a client-server architecture; they can just dive in and leverage their existing shell programming knowledge, with a zero learning curve. And because it's all just shell and AWK, the system administrator has infinite possibilities to configure the systems and do anything they need to do, without being limited by the framework of whichever technology they are using (like YAML or Chef recipes).

So why bother??? Why flap?

Why would I need runC and Docker to provision systems, if I can just install OS packages which configure the system, and then make a ZFS image?

Or, in terms of Linux: why do I need say Docker and Kubernetes, if I have everything in OS packages, and I just use KickStart to PXE boot, automatically install and configure the target node with OS packages?

 _have you tried a configuration management tool?_

You bet your ass I did! But that's not the point, the point is, why should I learn a discrete, proprietary systems, when I can just write a simple shell library which leverages the eval(1) command to do variable expansion, and BAM!!! I instantenously have a template expansion engine so all my configuration, even code, can be parametrized using the same varaible evaluation and expansion technology which the shell uses, and which the configuration packages can call?

With that:

\- I don't have to use proprietary, discrete systems;

\- I can leverage technology already built into the operating system;

\- I don't need a client-server architecture like Chef or Puppet, ever (ssh- sshd is just fine, thank you!)

Why would _anyone_ waste their time?

<comment><USER6> Your strategy of calling everything a provisioning system and then decrying the surfeit and complexity of provisioning systems is deeply flawed. Kubernetes is not a provisioning system. Docker and runC are not used to provision systems. Vagrant is not "an entire provisioning and/or configuration management engine," and its functionality cannot be trivially implemented with a "simple variable expansion function." You say you are familiar with these technologies, but your familiarity is insufficient. Your comparison of Docker and Kubernetes to OS packages, Kickstart, and PXE is outright laughable. You clearly do not understand the various purposes of these tools.

You point to imgadm and vmadm as superior solutions, but these appear to be "proprietary" (to use your own word) to SmartOS. Why not add SmartOS to your list of unnecessarily technologies and apply the same critical thinking? Triton appears to occupy the same space as OpenStack (Triton DataCenter), Kubernetes (Triton ContainerPilot), CoreOS (Triton SmartOS), and possibly other components, and it appears to use the same kernel-level containerization facilities as Docker and runC. You're using a competitor's vertically- integrated solution, so no, you don't need another stack. If you weren't using Triton you would be researching these alternatives. Your argument is akin to saying you don't need a car because you have a Buick, people who drive cars are using an unnecessary, proprietary mode of transport, and they should all just drive Buicks instead.

That brings us back to configuration management tools. You keep calling them proprietary, but the cores of all these products are open source! And while I agree with you that the client/server model used by Puppet, Chef, and SaltStack is unnecessary—although it does have benefits at scale—it's worth noting that Chef Zero and Ansible _just use ssh-sshd_. These tools are making the same system calls as your shell scripts, they're just doing them from Ruby or Python instead. So just to recap:

 _> I don't have to use proprietary, discrete systems;_

They're not proprietary, they're open source, and you only need one of the four.

 _> I can leverage technology already built into the operating system;_

They do: Ruby or Python and system calls.

 _> I don't need a client-server architecture like Chef or Puppet, ever (ssh- sshd is just fine, thank you!)_

Okay, so use Chef Zero or Ansible.

Finally, your other main argument, against abstraction, does not hold water. Everything we do is an abstraction. Shell scripts are an abstraction. Why aren't you writing your configuration management in C? (Wait, why are you writing it in C instead of assembler?) On one hand, you have a portable, open source tool with a domain-specific language. On the other hand, you have each company creating their own proprietary (this is the correct use of "proprietary," by the way) tooling, and an engineer has to learn it from scratch every time they change jobs. You may think any engineer can walk in off the street and instantly grok your homegrown shell- and AWK-based big ball of mud, but you are probably wrong. If your solution is as good as you think it is—if it's portable, extensible, and easy to maintain—you should release it and we can add it to the list of available CM tools. If it's not, why are you reinventing the wheel?

<comment><USER5> _Kubernetes is not a provisioning system._

Really? What is it then? Let's see...

 _Kubernetes (commonly referred to as "k8s") is an open source container cluster manager originally designed by Google and donated to the Cloud Native Computing Foundation. It aims to provide a "platform for automating deployment, scaling, and operations of application containers across clusters of hosts"_[1]

Automating deployment? I guess _deployment_ has nothing to do with _provisioning_ a resource... really, if you are going to argue for these tools, you should understand the concepts which they are trying to solve. Or are you one of the developers of one or some of these tools, and this is just rubbing you the wrong way, because it means that your tool isn't required? If so, just state that upfront, so everybody knows where you stand, and we don't have to discuss this any further.

[1] [http://kubernetes.io/docs/whatisk8s/](http://kubernetes.io/docs/whatisk8s/)

Moving right along...

 _your comparison of Docker and Kubernetes to OS packages, Kickstart, and PXE is outright laughable. You clearly do not understand the various purposes of these tools._

Okay, then you explain to me _why_ I need Docker to do what I can do with PXE, KickStart, and OS packaging? This ought to be really good...

 _Why not add SmartOS to your list of unnecessarily technologies and apply the same critical thinking?_

Because SmartOS uses zones, which give one fully isolated, true UNIX servers running at the speed of bare metal, and because it uses ZFS, fault management architecture (fmadm(1M), svcs(1), and svcadm(1M)), performance and post mortem analysis tools, and because it has everything required for massive datacenter and cloud deployments, built right into the operating system from the beginning, and not as an afterthought, knee-jerk "oh shit, we have to scale Linux to massive deployments now" reaction. By professional system and kernel engineers with formal education in those problem domains. imgadm(1M) and vmadm(1M) in SmartOS are the functional equivalents of JumpStart (or KickStart, in redhat's jargon, and AutoYaST in SLES one). That's _why_.

 _They 're not proprietary, they're open source, and you only need one of the four._

 _Proprietary_ means that someone owns it, or that it is _specific_ to something or someone, _not_ that it is closed source.

A product can be both proprietary and open source, and _freeware_ all at the same time if the _proprietor_ is providing the source code and giving the product away for free.

 _They do: Ruby or Python and system calls._

Neither of those _programming languages_ are part of the operating system _consolidation_ on a proper UNIX, and on Linux, they are provided in various versions by various people who are volunteers. And anything which is not part of the _OS /Networking consolidation_ on a _real_ UNIX is a third party and unbundled _application_. That's the only distinction we have ever needed, and the only distinction we have ever made.

This mistake was already made once on UNIX, when Perl was hip just like Ruby and Python are now: we are still coping with the fallout of ripping out, and replacing all the Perl garbage which has since been integrated into the OS/Networking consolidation. You haven't yet been busted by that on Linux, but you will be, because Linux keeps repeating the same mistakes which UNIX made. Except we learned from that, and on Linux it just causes more flapping.

Between Ruby, Python and shell and AWK, I will always pick shell and AWK (and not even bash, but traditional Bourne shell), because they are stable, the interfaces won't change, the syntax will stay the same forever, they are well understood, easy to learn, and they are small and fast, very fast.

I have regularly beaten Python with AWK both in code density and speed (latest: 487 lines of Python code in 183 lines of AWK, and no kernel hooks required like with the Python code). So if you're implying that Ruby and Python are ideal for massive deployments and configuration management just because they're _hip_ right now, that's insane, and I'm not buying it.

 _Okay, so use Chef Zero or Ansible._

Why? What does the Ruby dialect of Chef offer me, that I couldn't do in %pre, %post, %preun and %postun in a RPM package? Policy? Policy is best solved with a throughly thought through _change management process_. Capability Maturity Model and all that, you know?

 _Why aren 't you writing your configuration management in C?_

And just what do you think svcadm(1M) is written in?

 _(Wait, why are you writing it in C instead of assembler?)_

Who says I'm not? Use the right tool for the job. The problem here is, none of these Chefs, Puppets, Ansibles, Salts, Dockers or Kubernetes are the right tools for the job. Even Linux as the substrate for all of this is not the right tool for the job! But then again, judging by the other comments here, people are starting to realize that, and that's a good thing.

</comment></comment></comment></comment></comment><comment><USER7> Just a note that Upstart is Ubuntu-only and it's actually going to be replaced by systemd.

<comment><USER6> It already has been replaced by systemd as of 15.04 (and 16.04 LTS).

</comment></comment><comment><USER8> I like the premise of this, but can someone link a more modern guide that deals with Docker, ECS, etc?

<comment><AUTHOR> Looks like this is a little closer to what you're looking for I think: [https://medium.com/aws-activate-startup-blog/running- service...](https://medium.com/aws-activate-startup-blog/running-services- using-docker-and-amazon-ec2-container-service-bde16b099cb9#.fhj8j5rj9)

<comment><USER8> Thanks. For anyone interested: the above linked medium post doesn't mention config management, but I see that Ansible has some form of ECS support.

</comment></comment></comment><comment><USER9> Why go through all this for a simple flask app (or even a more complicated one)? What do you gain over just using Elastic Beanstalk (which handles the monitoring/autoscaling etc.)

<comment><USER10> I feel it's pretty clear that the purpose of this article is to illustrate this general methodology using these tools and is not "how to deploy a Flask app." The nature of the app itself is largely inconsequential to what is being illustrated.

<comment><USER9> I guess my question was "why use vagrant/ansible over a more simple AWS setup like Elastic Beanstalk"?

I agree it being Flask is largely irrelevant.</comment></comment></comment>


Etsy's experiment with immutable documentation - <AUTHOR> https://codeascraft.com/2018/10/10/etsys-experiment-with-immutable-documentation/ <comment><USER2> At Firebase (and at Google) I have done a _ton_ of work at making our "how docs" consistently correct with limited maintenance time.

Consider a page like this: [https://firebase.google.com/docs/firestore/manage- data/add-d...](https://firebase.google.com/docs/firestore/manage-data/add- data)

It has 12 "how" sections of code snippets, each with 12 language options. That means 144 code snippets need to be correct for this page to be 100% correct! And we don't auto-generate any of these snippets, since auto-generating idiomatic code is a rabbit hole that's consumed many a good developer.

So we, like Etsy, have come up with a separation of concerns between How and Why that works for us. The text on the page is maintained by a tech writer. The code on the page is a series of blocks that look like this:

{% includecode snippet="android_firestore_write_doc" %}

We have a system that resolves these, at publish time, to match snippets on GitHub. For example: [https://github.com/firebase/snippets- android/blob/5f94890d7b...](https://github.com/firebase/snippets- android/blob/5f94890d7ba329a8a4c25f0ec8b42d4b9d781bc0/firestore/app/src/main/java/com/google/example/firestore/DocSnippets.java#L318-L336)

These snippets can be maintained with all the wonderful tools that exist in the world for maintaining code! We don't need to think of them as just docs. So that "snippets-android" repo has continuous build, a robot that updates dependencies, PRs/Issues for third-party contributions, etc.

What we've found is that this system allows us to maintain many thousands of code snippets with only a handful of people watching over them.

<comment><USER3> I noticed the same system in the Google Cloud python samples repository. It's actually quite useful to have the full code available and to easily see which parts are displayed in docs.

Feature request, though: include a url in the source code that takes you to the snippet's usages in documentation. Something like // [START [https://codesamples.google/firebase/set_document](https://codesamples.google/firebase/set_document) ] or just the url as a separate comment.

<comment><USER2> We're working on making the system smart enough to work backwards, but I agree that's a great idea!

</comment></comment></comment><comment><USER4> I think the part about this that is truly successful, is the use of slack significantly lowers the transaction cost of adding the documentation. In a wiki, where there is a certain level of quality expected, you might make the decision to just move on with your life once you find the answer you need, as you've already wasted enough time. With this, however, it's so cheap to leave a breadcrumb it's just polite to do so.

<comment><USER5> > the use of slack significantly lowers the transaction cost of adding the > documentation. In a wiki, where there is a certain level of quality expected > ...

The wikis I've used also have slow editing interfaces because they have separate read and edit modes. Does anyone know of a modeless wiki, which probably means one that allows you to edit-in-place?

The problem with modes is that to edit something on a sizeable page you must,

1\. Load the page in read mode

2\. Read/search to locate the spot on the page where your edit goes, read the context around it, and plan the edit.

3\. Load the page in edit mode

4\. Read/search to locate the spot on the page where your edit goes

5\. Type your edit

6\. Reload the page in preview mode (a form of read mode)

7\. Read/search to locate your edit and verify it

8-?. Repeat steps 5-7 until your edit is correct.

N. Reload the page in read mode.

Compare to a modeless wiki:

1\. Load the page in read mode

2\. Read/search to locate the spot on the page where your edit goes, read the context around it, and plan the edit.

3\. Edit until satisfied

<comment><USER6> Google Docs. Has comments, too.

<comment><USER5> How easy and efficient are other wiki functions, such as creating hyperlinks between documents, creating new documents, and a simple, structured style system? Last time I looked at it for these purposes, Google Docs failed in those areas.

</comment></comment></comment></comment><comment><USER7> Why isn't the how-docs tested? I don't work in ops or anything like that, but it seems to me that it'd be the best way to ensure everything stays up to date.

In Rust (and many other languages), when you document a function, you usually add a code snippet that explains how to use this function. That code snippet will be treated as a unit test and ran when testing the functionality. In this way, documentation is always up to date (assuming the tests are ran).

Why can't tool documentation be the same? The tool documentation usually contains a sample tool invocation. All we need to do is run the tool in a controlled environment, and ensure that the invocation runs successfully. When a tool gets updated, run the "documentation tests" to ensure all the commands in the docs still run successfully. If they don't, then update the docs. Surely, there are tools out there that already do this? Does anyone know?

<comment><USER8> This is kind of what I have been doing with this testing framework: [https://github.com/hitchdev/hitchstory](https://github.com/hitchdev/hitchstory)

It's designed so that you can write tests that _are_ the basis of the "how to" documentation - with a small script and some jinja2 you can generate readable documentation in the form of markdown from the test:

Original test (behavioral example) : [https://github.com/crdoconnor/strictyaml/blob/master/hitch/s...](https://github.com/crdoconnor/strictyaml/blob/master/hitch/story/email- url.story)

Example docs generated from that test : [https://hitchdev.com/strictyaml/using/alpha/scalar/email- and...](https://hitchdev.com/strictyaml/using/alpha/scalar/email-and-url/)

It's also designed so that the testing framework can be programmed to rewrite the test automatically for simple code changes (e.g. changing the wording of that exception).

This makes building tests _much_ quicker and much, _much_ less tedious and perfectly in sync docs _almost_ becomes a side effect.

Essentially "how to" documentation and example driven behavioral tests _are_ the same thing for all projects. It's just that most people don't realize and don't treat them as such.

</comment></comment><comment><USER9> In the specific example given here of "dbconnect", I'd consider a different approach: incorporating the "how" knowledge into the CLI itself. For example, running the command without any arguments could trigger an interactive guide that asks the user questions.

"What do you want to do?"

o Get a list of databases

o Connect to a database

"Do you want to connect to dev or prod?"

o dev

o prod

o I don't know (this option could link the user to documentation on the different environments; maybe the user is a student on his or her first internship and has never even heard of the concept)

"What's the shard number?"

"Which side?"

The CLI could output the equivalent, non-interactive command before performing the requested action, making it a teaching opportunity as well. Maybe the "I don't know" option or this approach in general is overkill, but I generally think tools should be smarter. You don't need as much documentation if your tools are inherently capable of guiding you to the right answer.

<comment><USER10> That's quite a bit more work than adding a reacmoji to 100 chars which were typed into Slack anyway. We all want better tools with fantastically helpful interfaces, but we also want functioning MVPs yesterday. I like the Etsy approach because it fits into our existing JIT dev/doc workflow.

<comment><USER9> 1\. I'd use a library or framework that handles the interactive parts, which should make it fast to implement. We have tools to help make other tools.

2\. A tool's popularity/usage could be a way to judge when it's worth the effort to add this sort of system.

3\. With the Etsy approach, I would also be wary of the cost of interruptions. Getting constant Slack notifications is not conducive to getting work done. You could silence them, but then what if someone can't move forward without getting an answer to their question?

4\. There is a nice balance to be found between wasting time documenting everything possible upfront and not documenting anything until someone asks a question.

5\. Personally, when I find documentation that needs to be updated, it's usually as simple as editing a wiki or editing Markdown and making a pull request in GitHub's interface. To me, that's not much effort.

</comment></comment></comment><comment><USER11> This feels incredibly broken to me. The 'how' should not change often, because it enforces rapid change on anything which depends upon it.

Any system inevitably acquires dependencies. Maybe it's fine to break those dependencies if you're building some public website where you can always have the latest version of the code running, but if you've got customers who depend on having a stable build which was initially branched three years ago and you still need to build, run and test that, you damn well better have a consistent and stable mechanism for dealing with that codebase which spans multiple years. Your ops and QA people will hate you otherwise.

Our own approach has been to pull out the coarse-grained operations and have an 'environment' script which examines the version it's working with in order to spit out relevant details. The 'porcelain' scripts are never allowed to change their API in any breaking fashion, and their behaviour is adapted based on the environment's output.

<comment><USER12> DDD: Documentation-driven development. With apologies to Fred Brooks, write documentation first, then write tests for the functionality and syntax described in the documentation, then the code. I would speculate that doing straight docs instead of something like Cucumber would be more productive.

</comment></comment><comment><USER13> Cool!

One of the big picture value propositions of technical writers IMO is that we're shepherds of organizational knowledge. For example, if someone sends an email to me asking how to get a particular task done in Chrome DevTools (which I write the docs for), I will ask their question on Stack Overflow, provide an answer for it, and then send the link back to the asker. It's a similar amount of work, but I'm making the knowledge public, rather than one-off.

What's really innovative about Etsy's idea IMO is that they have found a way to make tribal knowledge shared on an ephemeral platform like Slack more permanent. My big issue with real-time chat up to this point has been that all the beautiful knowledge that you share on the platform isn't recorded in a permanent way. I acknowledge that a lot of people prefer the real-time messaging format, so it's really cool that Etsy has figured out a way to get the best of both worlds.

</comment><comment><USER14> This is a really interesting idea and I feel like it has the potential to make the common usages much easier to ramp up on, but I'm skeptical because I run into _conceptual completeness_ problems of the "how do I think about this?" sort much more than "how do I do this?" problems.

Blog posts like this are always optimistic and celebratory. Sometimes it's warranted, sometimes it isn't. I'd love to hear how people on the ground at Etsy actually feel about it.

<comment><USER15> I personally feel that the problem with most documentation is that it always focuses on the how/what. That will always decay and be wrong. The code is the only truth in the end.

The thing I suggest here is that if you are going to document the function, it should only be the _WHY_. The how can change and the documentation doesn't really decay. If you are making a new function you have to start with the _why_ and if you can't then you shouldn't be adding a new interface. This also helps build a better picture of how the pieces interface together.

<comment><USER16> This is my most common feedback when I review docs that people have written.

The other is when someone write "if you need to do X" with no information about how you'd know if you need to do X

</comment></comment></comment><comment><USER17> I'm surprised no one has yet mentioned how well automated functional tests can document the how. I constantly go back to my automated tests to understand how to do something I've since forgotten but that the code supports.

</comment><comment><USER18> or alternately, treat the documentation as code and don't accept code changes which are not properly documented..

<comment><USER19> This is it.

I would barely consider random snips about a thing/keyword, scattered over time, to be documentation.

Certainly, a problem was likely solved with this FYI system... but it wasn't a documentation problem.

<comment><USER20> Discoverability is often a major documentation shortcoming. They solved task- oriented discovery of 'how' snippets. Someone can search based on what they want to do, and not based on a specific command.

I also prefer the 'documentation is code' approach, but it doesn't solve the same problem.

</comment></comment></comment><comment><USER21> The article is both a why-doc and a how-doc.

I do agree that this is a useful distinction.

I'd have called how-docs and FYIs "howto", as I think that term would be recognised more clearly, but that's a quibble.

<comment><USER22> Internal documentation has a handful of patterns. There's the cookbook patern, which corresponds to a "how-to." There's the "readme" pattern, which is meant to conceptually get you started on a project. There's the "architecture" pattern, which is a conceptual design and talks about the rejected alternatives - this is not used everywhere but is a key deliverable in both outsourced and waterfall applications. There is the "small chunk of information that is hard to organize" pattern that has multiple solutions, be it FAQs or Etsy's bot.

Immutable documentation, at its essence, isn't new. Wikis are in many ways immutable documentation due to the diff. The interesting thing here is trying to organize the "small bits of hard to organize" information around slack. More often, however, the real problem is that we need to properly organize this documentation at the point the organization becomes more evident.

For a tool, that should be obvious: --help should be obvious. It's not true in all cases.

<comment><USER23> > Internal documentation has a handful of patterns.

This is a great way to articulate something I've been trying to talk to people about for a while - is this something you've thought of for yourself, or do you know of anywhere that talks about these patterns?

<comment><USER24> I've noticed the concept of _information architecture_ is being used in technical communication more frequently these days, borrowed from graphic design. Which covers a bit more ground then patterns, including topics like search, labeling, and taxonomy.

Sure, getting everyone to maintain docs with their features is useful. But given enough time, you'll end up with so many "close but not really close" concepts in documents it's very hard to stay on top of without someone putting some organization into play.

<comment><USER22> Old school tech departments used to have librarians for documentation. I still think it would be valuable for departments, but it's one of those positions for which it is hard to quantify until you get much larger as an organization.

</comment></comment></comment></comment></comment><comment><USER25> It took me a while to work out why this doesn't feel like a full solution.

I can imagine it working for simple one-line commands and their switches.

I can also imagine it failing to work for any application that requires multi- line code blocks and/or more detailed how-to examples.

For example - as a hypothetical, imagine you change your API from Oauth to Oauth2, and you have to provide examples of new standard code, perhaps in different languages.

That's very much a how-doc and not a why-doc problem, so supposedly it doesn't belong in the Wiki.

But I really can't see the changes being explainable in a fyi.

Of course you can say "The new code is in repository X instead of X-1." But if there are other questions and fyi's around Oauth2 - and there will be - there's no guarantee that important fact is going to be at the top of the read list.

For complex breaking changes that read list is going to get very long.

Simpler changes are going to have the same issues on a smaller scale.

So this isn't really immutable documentation - it's more of a database-hosted command cheat sheet.

That's a useful thing in itself, but I don't think it's a complete solution for documentation.

</comment><comment><USER26> You should never break interface. You should expand interface.

If you do that.. then..

You never edit docs. You only add to docs.

<comment><USER27> Works _great_ for a year or two ;-)

Never refactoring your interfaces means that you can never improve the design as you gain new information. It means you can never change to something more appropriate if the underlying use cases change. It means that you can't easily consolidate common functionality in a different place as new similar interfaces are constructed. In other words, you are locking yourself in to a brittle system that will degrade into a mess of spaghetti that nobody can understand.

There are, of course, also downsides to refactoring. No simplistic rule of thumb will tell you your best approach.

<comment><USER28> You can have the best of both worlds by versioning your endpoints

<comment><USER29> Supporting and maintaining old endpoint versions is expensive. Especially if the old endpoint shares a back end data store with the new endpoint. You can get locked into a bad data model and unable to move forward.

If you can do it then great, but it's just not always technically feasible or cost effective.

<comment><USER27> Yeah, you can sometimes build an adaptor to expose the old API on top of your new API, but other times you have to actually maintain 2 parallel implementations. It's always a hard choice. Or at least it should be if you are thinking it through all the way :-)

A lot of times I find that developers lack experience of how legacy applications get the way they do. Either they have only ever worked on green field applications before (a surprisingly large contingent!) or they assume that the crappy legacy code was created because the previous developers were stupid. The reality is that most legacy systems were made with very reasonable decisions at the time, but that the world shifted under them. The mistake was locking themselves into their original decision and making it very expensive to change. The decision to never deprecate old APIs is one of those decisions that makes change expensive. Such decisions should always be made looking at the trade offs in cost. How expensive would it be if we changed this API? How expensive would it be if we _don 't_ change this API? Usually the second is _far_ more expensive in the long run, but you have to take it on a case by case basis.

</comment></comment></comment></comment></comment><comment><USER30> Maybe the docs are binary and code aware, so the doc system can pull up the binary's code in source control and find all the possible doc strings. Developers can't add/change flags without also updating these.

Maybe the docs are history/execution aware so they can list the top N ways the binary is executed.

Maybe the docs are also team aware so they list the top N ways the binaries have been executed by your team.

So you say, "Here at CoolTechCompany, we built a tool to help control our widgets. Please see the `cli widget` command. And everything kinda works automatically.

</comment><comment><USER31> Reminded me of Infobot and the countless knowledgebase bots it inspired.

[https://en.wikipedia.org/wiki/Infobot](https://en.wikipedia.org/wiki/Infobot)

</comment><comment><USER32> I feel like searching for the solution may become time-consuming because you have to search the right set of keywords to find the answer, which may or may not be an intuitive set

</comment><comment><USER33> There is also Stack Overflow for Enterprise: [https://stackoverflow.com/enterprise](https://stackoverflow.com/enterprise)

<comment><USER34> This kind of falls into the same problem as wikis though. It requires people to A. remember it's there and B. be actively monitoring it for questions. We have one at my location and I constantly forget it's a thing.

With something like this tool it puts it right in a primary communication tool.

</comment></comment><comment><USER35> This doesn't seem like a solution to me but rather a symptom of a much deeper problem in the way that we write and document code.

</comment><comment><USER36> Why not just add a comment system to the doc page?</comment>


Lawyers: To Save Newspapers, Let's Destroy Pretty Much Everything Else Good - <AUTHOR> http://techdirt.com/articles/20090517/0236594905.shtml <comment><USER2> Does anyone else think this scene from "Other People's Money" applies to Newspapers?

<http://www.youtube.com/watch?v=MfL7STmWZ1c>

</comment><comment><USER3> _That would be a massive reinterpretation of copyright law, and would effectively destroy much of what makes the internet useful._

Non-lawyer lectures lawyers about what constitutes massive reinterpretation of a particular law. Why did I read this?</comment>


Vim - Putting arrows to use - <AUTHOR> http://codingfearlessly.com/2012/08/21/vim-putting-arrows-to-use/ <comment><USER2> I believe many VIM users overestimate the importance of using h,j,k,l in comparison to numeric modifiers. Holding down j to scroll down the page is no more "right" than holding down the down arrow, in my opinion.

The following made me considerably faster:

* Relative Line numbering (For Vim 7.3). G/gg stop being convenient for frequent line movement once your file goes beyond 100 lines. Doing math in your head to figure out if line 589 is 16 lines from 605 takes way too much effort. Append this[0] to your ~/.vimrc, and then CTRL-l will toggle relative/absolute line numbering. So in relative mode, you see a line is 20 up from your cursor, and 20k takes you there with no guessing or holding down keys.

[0]: <https://gist.github.com/3418841>

* Learn the following: f,F,t,T. Combine them with c and d.

* zz => make current line appear in middle of the screen.

* H,L,M

* w,W,b,B. Combine with numeric modifiers (5dW)

* CTRL-u, CTRL-d, CTRL-f, CTRL-b

* % for block highlighting. Works well with curly braces by default, you may need to pick up extra plugins for ruby/python.

* g; will cycle back to the last places you were in insert mode. g, will cycle forward.

<comment><USER3> Even better, just learn to use EasyMotion, it's one of the most efficient ways of navigating around a file:

<https://github.com/Lokaltog/vim-easymotion>

<comment><USER4> I've tried it and didn't like it at all.

The main problem is how it replaces the letter I'm searching with another unrelated one, making all the matches practically unreadable. To me, at least.

        set incsearch

and

        /foo
        ?bar

are more than enough for my needs.

<comment><USER3> Basically what dedward said before me.

EasyMotion is not for searching, it's for moving the cursor deliberately to a place onscreen where you need to make an edit.

<comment><USER4> Yes, I know.

Searching is how I move to where I want.

It's a lot less confusing to me than EasyMotion's logic, it's consistent whether the word I want to jump to is visible or not and it's a native feature.

Well, I was curious when it was released so I've used it for a couple of weeks and found it horrible and confusing. Obviously many people like it so let's say it's a matter of taste.

</comment></comment></comment></comment></comment><comment><USER5> I use my up/down keys to move between visible lines (rather than real lines, which is what they and j/k do by default). This can be helpful occasionally when you have lines wrapped for something that's text rather than code.

        " up/down move between visual lines
        " instead of actual lines when wrapped
        imap <silent> <Down> <C-o>gj
        imap <silent> <Up> <C-o>gk
        nmap <silent> <Down> gj
        nmap <silent> <Up> gk

(You could also map j/k to just do this if it's something you use often, but I prefer not to.)

</comment><comment><USER6> I don't remember where I found it but the best remapping I ever did was to map the sequence 'kj' to esc.

kj is rarely used in a word, and when it is it isn't a big deal.

inoremap kj <Esc>

<comment><AUTHOR> That's useful indeed - I have both kj and jk mapped to Esc in my vimrc.

<https://github.com/mmozuras/vimfiles/blob/master/vimrc#L75>

<comment><USER7> Interesting, I always did jj, but kj or jk feels speedier. Thanks for the tip!

</comment></comment></comment><comment><USER8> I use arrow keys for movement all the time. Not always, but I found no value in forcing myself otherwise.

<comment><AUTHOR> Interesting. How long have you been using Vim?

<comment><USER9> you did not ask me, but: when i'm busy thinking about the code, when i'm not typing for a long time, i lay back and browse the sourcecode with arrows and (up and down or pg-up and pg-down). not that fast, sure. but can be done with one hand, the other is scratching my head or what helps me think.

<comment><USER10> Page up and page down are part of my must-learn-asap shortcuts when learning a new editor - once you have hjkl and ctrl+f/ctrl+b ingrained, browsing code while keeping your hands mostly over the home row becomes a lot easier and you don't have to move your hands back and forth. I've found that if I want to browse my code with one hand, the scrollwheel on my mouse does the trick :)

<comment><USER9> ah yes. mouses. i knew there was another input controller...

(not to be misunderstood, i use mostly hjkl and ctrl-d and ctrl-u (half-screen up and down). and i find the mouse uncomfortable.)

</comment></comment></comment></comment></comment><comment><USER11> My issue has always been one of muscle memory.

The hjkl keys are fine to use when in Vim, but the majority of other products (browsers, word processors, spreadsheets, etc) don't support them for movement. So I have a constant context-switch in my muscle memory when moving between these different applications.

On a Mac keyboard, I find arrow-key navigation with my pinky finger very efficient… only requiring the rest of my fingers to move from the home row when pressing right.

I'm not sure this would work for everyone… but for me, one set of muscle memory is superior to convincing my nervous system to context-switch.

</comment><comment><USER12> Not to be too cranky, but the rationale for avoiding the arrow keys is to keep your hands on the home row. So anything useful you find to do with them, if you do it often, will be inefficient.

<comment><AUTHOR> Good point and something I should've written in the post. Text moving is not something needed very often, but I find using arrows in this case more pleasant than <gv or [egv. In normal mode, I'll usually use <<, because I'm already used to it.

</comment></comment><comment><USER13> It's a nice idea, but I don't buy it. What I like most about vim is how few unnecesary moves I make with my hands - in particular my wrists stay in the same place all the time; reaching for arrows would require moving the whole forearm, which I don't like and which breaks my flow.

Also I'm curious about this quote from OP:

      I just might remap hjkl to split navigation,
      because I use hjkl less and less, favoring
      navigating in other ways. Sounds crazy, I know ;)

Can you elaborate on your habits that cause it?

<comment><AUTHOR> I got used to better ways to navigate in Vim - RegEx pointed out quite a few of them - <http://news.ycombinator.com/item?id=4414502>. I would especially emphasize f,F,t,T and w,W,b,B,e,E.

</comment></comment><comment><USER14> I'm a rather advanced Vim user (10 years, vimrc with custom vimscript, use many shortcuts for movement), but I find it unproductive to NOT use arrows in insert mode. Example: inserting 'x' two characters before current position.

With arrows: <LEFT><LEFT>x<RIGHT>

Without arrows: <ESC>hix<ESC>lli

It also much depends on a keyboard design, the laptop-like often have arrows under ENTER and using them doesn't require hand movement.

<comment> qu4z-2 In that situation I'd likely as not just backspace to the offending location and continue typing. Although I have been known to map caps+hjkl to the arrow keys.

(I'm assuming your situation is a typo while you're inserting a short string, rather than just defaulting to insert mode)

</comment></comment><comment><USER15> Cool idea. I read an article here a couple months ago about vim autocomplete and I mapped my tab key to autocomplete, but that was super annoying for, you know, adding indentation.

Now I've got my arrow keys mapped to Nop in all modes except I mapped my right key to autocomplete in insert mode, which has worked pretty well for the last 10 minutes. I'd really like to start using autocomplete more, so for me it's handier than text moving.

<comment><USER2> Check this[0] out. Autocomplete when typing words, indentation otherwise.

[0]: <https://gist.github.com/3418565>

<comment><USER15> thanks, that's a way better solution.

</comment></comment></comment><comment><USER16> A very small corner case here, but on certain keyboard layouts, hjkl is actually harder to use than the arrow keys. To be more specific, I use an alphagrip keyboard most of the time where left,right,up,down are all under the left thumb and a trackball is under the right thumb. The way I interact with vim is thus very different from most folks, I imagine.

</comment><comment><USER17> I prefer to map left and right arrow to navigate :bprev and :bnext. Paired with buftabs, I find it rather handy <http://www.vim.org/scripts/script.php?script_id=1664>

</comment><comment><USER18> From my funny looking vimrc: navigating between splits with Alt+HJKL

        nnoremap ¬ <C-w>l
        nnoremap ˙ <C-w>h
        nnoremap ˚ <C-w>k
        nnoremap ∆ <C-w>j

(Mac :P)

</comment><comment><USER19> I map left/right to next/previous tab, and up/down to next/previous buffer, since if I switch files my hand is often coming from the mouse and the arrows are along the way.</comment>


Why Google was correct in Chrome dropping H.264 - <AUTHOR> http://www.arpitonline.com/blog/2011/01/11/why-google-was-correct-in-chrome-dropping-of-h-264/

<comment><USER2> Google as a business is well within it's rights to do whatever it wants to further it's business interests, and/or tick off it's competition. Let's just not keep saying it's all for the user.

</comment><comment><USER3> The real question is will Google follow through and remove all support for H.264 from YouTube. That will be the telling sign that they're serious.

<comment><USER4> Just because you're not a suicide bomber doesn't mean that you're not a serious Muslim.

<comment><USER5> Just because you're not a double negative doesn't mean that you're not a confusing sentence.

<comment><USER4> Haha good point. How would you have put it, though?

</comment></comment></comment></comment><comment><USER6> Chrome ships with Flash. Flash plays H.264. Thus, Chrome still supports H.264, now it just has to go through Flash.

There are Android phones with H.264 hardware support. There are no Android phones with WebM hardware support (software support, yes).

So... there is no point to converting YouTube videos to WebM: it doesn't benefit Android, it doesn't benefit Chrome. It would be a pointless waste of space.

<comment><USER7> Flash will support WebM in a future version. Additionally, Google could update the iOS YouTube app to support WebM in a future iOS version.

Once both reach sufficient market saturation YouTube will be able to completely switch from h264 to WebM.

<comment><USER6> No point in updating the iOS app unless there's going to be hardware support.

<comment><USER7> Two possibilities.

First, Google could go software only for older hardware. It will suck for them. But by the time YouTube phases out h264 there will be few of these and the latest hardware will accelerate both WebM and h264.

Second, there could be a way to utilize the h264 hardware decoder to work with WebM through a wrapper. The ffmpeg decoder for WebM is basically a wrapper around the existing ffmpeg h264 decoder already. I've never worked with decoders myself, but this at least seems plausible.

Regardless, I think bundling WebM software decoding along side h264 decoding in the YouTube iOS app is a no-brainer even if YouTube doesn't take advantage of it right away.

</comment></comment></comment></comment><comment><USER7> HTML5 video is DOA and Google might as well lay the groundwork for the next round. Major content providers don't support HTML5 video. Netflix, Hulu, and anyone else with intellectual property to protect want nothing to do with it. So we're going to need to keep our proprietary plugins and our proprietary apps through the HTML5 era. Even YouTube needs to stay proprietary.

So if HTML5 video is DOA, why support h264? Why be democratic when people are going to use Flash and Silverlight anyway? At least this way there might be a real push for the standard HTML5 video codec to be free and open source.

<comment><USER8> _WebM video is DOA and Google might as well lay the groundwork for the next round. Major content providers don't support WebM video. Netflix, Hulu, and anyone else with intellectual property to protect want nothing to do with it. So we're going to need to keep our proprietary plugins and our proprietary apps through the WebM era. Even YouTube needs to stay proprietary._

Your argument goes both ways.

<comment><USER7> Actually they are equivalent. HTML5 video tag is codec agnostic. In this instance HTML5 includes to both WebM and h264 video over HTML5. Both are DOA.

So why support h264, which is scary and patent encumbered, when Google can give a little boost to its own WebM standard at no risk to Chrome's viability in the browser market?</comment></comment></comment>


Keeping your family safer with Windows 8 - <AUTHOR> http://blogs.msdn.com/b/b8/archive/2012/05/14/keeping-your-family-safer-with-windows-8.aspx <comment><USER2> What the parents didn't know was that little Timmy is a young hacker, the report says he keep reading wikipedia all day long while in reality he is playing diablo, watching porn and reading their parents' emails.</comment>


Please share your JavaScript webapp.  - <AUTHOR>

<comment><USER2> I wrote a lot of the code for [https://www.airbrite.io/](https://www.airbrite.io/), which we are quietly launching on hackernews today.

The dashboard is all backbone, the backend is all node.js.

We wanted to build something that could become a core toolset for all developers. Hopefully it'll help frontend developers with e-commerce sites, but I'm excited to get to use it myself.

<comment><USER3> What does the site do? Once my order is stored, then what?

</comment></comment><comment><USER3> [https://findalakethatlookslikeadog.com](https://findalakethatlookslikeadog.com)

Started as a joke among my dev team and we've now sold a few shirts and plan on developing the idea.

Javascript: Just jQuery.

</comment><comment><USER4> [http://www.wiwitness.com](http://www.wiwitness.com) Backbone.js + Zurb Foundation + jQuery + require.js. Of course there's some plain java script as well.

The backend is Java on Google App Engine. Restful.

</comment><comment><USER5> [http://www.featuremap.co](http://www.featuremap.co) (although it's actually written in TypeScript :))

We make extensive use of Knockout and Backbone; the backend is ASP.NET MVC4/WebAPI.

</comment><comment><USER6> [http://play.basketball-gm.com/](http://play.basketball-gm.com/)

Completely 100% client-side JavaScript. Possibly makes heavier use (abuse?) of IndexedDB than any other website.

</comment><comment><USER7> My website / blog is a single page app :)

[http://mkeas.org/](http://mkeas.org/)

<comment><USER8> I have two suggestions. 1\. Use a good font on your site, e.g. Helvetica Neue, Open Sans, Proxima Nova 2\. Make more padding in-between the top of background images and their text content

</comment></comment><comment><USER9> [https://github.com/amirouche/hivi.mx](https://github.com/amirouche/hivi.mx)

</comment><comment><USER10> [http://imageswaps.tk](http://imageswaps.tk)

<comment><USER4> Very interesting. How many visitors have you got? How many people are using it?

I liked the UI. Clean and simple.

Adding a line or two about what the site does may help.

Best wishes.</comment></comment>


Ubuntu AppStore: Like Apple AppStore, but with less Suck - <AUTHOR> http://swizec.com/blog/ubuntu-better-for-app-management-than-apple/swizec/1672

<comment><USER2> Sigh... I wish Linux (and Ubuntu in this case) were better at UI/UX. But still, it's so clearly designed by programmers (not always a bad thing, but sadly more often than not).

So what's called out here as being good? Well. Subcategories. Average users don't respond well to taxonomy, generally. People are also not good at classifying. So in that example shown, what's the difference between "Arcade" and "Sports"? I've played football games in Arcades. Where should users look?

More: "Some items can be bought, others just downloaded" Cool, where can I filter so I only see free apps? Because it's nowhere in the screen shots, and I will bet money that it's the first thing a sizeable percentage of users want to do. Which would be known, had any user testing been done. I hope it was, but I'm guessing not.

I could be nit-picky - "Get Software" vs. "Installed Software" - they're not even the same tense. Imperative tense is commonly interpreted by users as causing an action to happen, not a categorisation. I could go on too, merrily burning karma as I go, but all I see when I look at this is how far it has to go, not how great it is. Don't get me wrong, the Apple version is by no means perfect, but I bet it performs better in tests with actual users.

Someone needs to get a real UX team together and actually sit down for a real project - not "someone and their favourite futuristic GUI idea for the next version". I would hope that Ubuntu, Red Hat, etc. have the budget to do that, but I see little sign of it.

<comment><USER3> Canonical (the commercial company behind Ubuntu) has hired a number of full- time UX and Mark Shuttleworth, the founder, recently stepped down as CEO to focus full time on leading product design and development. [http://www.zdnet.com/blog/open-source/mark-shuttleworth- to-s...](http://www.zdnet.com/blog/open-source/mark-shuttleworth-to-step-down- as-canonical-ceo-in-march/5491)

I think this is evidence that there's a "real UX team" at work.

<comment><USER4> "Mark Shuttleworth, the founder, recently stepped down as CEO to focus full time on leading product design and development."

And this is where the high degree of "programmers design" is coming from.

</comment></comment></comment><comment><USER5> 1) I don't think Ubuntu's UI is any better than Apples UI. If anything it's the same bad copy of the Windows 98/2000/XP/7 lineage of program management tools in control panel that linux has beed copying all the way back to RedHat's RPM package management GUI in the early 2000's.

2) The title of the article is "Ubuntu's app management better than Apple's" not "Like Apple AppStore, but with less Suck."

<comment><AUTHOR> at 2) I couldn't decide on a good title, hence some disparity. The URL itself contains a third version.

at 1) Actually GNOME has since forever been an Apple copy, the newest Unity thing even moreso, but I really really like the Launcher. I feel like it's just innovative enough while being sufficiently familiar not to throw me off completely.

<comment><USER6> GNOME an Apple copy? Unity's not developed by the GNOME devs but by Canonical. Since Lucid, the behavior of Ubuntu has shifted somewhat to match that of Mac OS X. Traditionally, buttons defaulted to the right hand corner of the window rather than the left and multi-touch tapping has been remapped to match OS X's style (two finger right click, three finger middle). Compiz has the window picker plugin similar to Exposé along with a cover flow-like window switcher. Now you've got he Unity Launcher with Spotlight/Quicksilver/Gnome-Do functionality. The Add/Remove Applications tool has been around since Breezy in 2005, predating even the iPhone App Store, and provided the same functions as the Software Center and the Mac App Store.

GNOME can be tweaked to look like OS X or Windows or whatever you want, but it's because you can mix and match things like themes and window managers. If you just used vanilla GNOME 2.x with Metacity, I don't think you'd find much of a similarity.

You could say that Ubuntu or GNOME3 borrows functions or aesthetics from other contemporary desktop environments, but GNOME "forever been an Apple Copy?"

<comment><USER7> Calling GNOME an Apple copy is a bit much, but 2.0 was strongly influenced by Apple/NeXT design principals, or at least it seemed that way when it was happening.

</comment></comment></comment></comment><comment><USER8> What I get from this article is a) apt-get is awesome and b) there's subcategories in the launcher. I completely agree that apt-get is great, and subcategories aren't bad either. However, this has nothing to do with "app stores." apt-get has been around way before the ubuntu software center, and if anything it goes way deeper than just "apps." If anything, this article is just bringing up the point that software management on linux (for the more technically inclined) is better than on mac, something that isn't quite exciting or new.

I think articles like these are just looking for trouble. It immediately stands as being biased, and screenshots completely skew things in Ubuntu's favor. Seriously, "pushiness?" It's a bad thing now to be showing users applications on the home page of a store? Maybe it might get cluttered, but I definitely don't prefer Ubuntu's "Nice clean and unassuming" main page with just a category listing. "The listing is pretty simple?" Now you're just looking for things to say; I'm going to end my comment here before I make the same mistake.

</comment><comment><USER9> Is it just me, or does the Ubuntu App Store resemble something one would find in Windows? Not sure where the "less suck" comes from.

</comment><comment><USER10> What about the Apps from the App Store? How many of them have good design?

</comment><comment><USER11> I love this kind of articles for the fact that they are all ignoring all the background work you have to do in Linux in order to bring your system at a state in which you can work and get what it has to offer. The story is pretty straight yet a lot of people ignore it: Non tech savvy people just wouldn't be able to work with Linux.

</comment><comment><USER12> Cmd+Space works as a pretty decent app launcher, functioning pretty much exactly the same way as Natty's new Super key which acts a lot like Vista/7's search/start menu.

I still don't see why Ubuntu's is better. It's cool how it slightly blurs the line between installed applications and available applications, but that's it.

</comment><comment><USER13> Mature title...

</comment><comment><USER7> "Ubuntu AppStore"?

<comment><AUTHOR> Purchasable apps -> app store.

<comment><USER7> Are we pretending anyone actually calls it that?</comment></comment></comment>


The End of the Road for the actual American pastime…TV - <AUTHOR> http://technovisions.wordpress.com/ The Grim Future for our Favorite Pastime
by Evan C
Television. For most, it seems like the most basic of technologies, something people have been living with their entire lives. However, discussing the future of such an important and (dare I say) essential technology is no easy task, for you and I both know that change is not something people are always open to. My purpose for writing this is to not only inform people of the revolution at our doorstep, but to also encourage others to seek alternative viewing methods and explore the existing technology that is already out there.
Now, the things I am about to explain may seem obvious at some points and entirely unrealistic at others, but you must remember to think outside the box and understand that the future is not always simple to explain. For example, think about trying to explain e-mail (or e-mail on your iPhone) to somebody from 1988. To them it would seem impossible, but little did they know that only a decade later, AOL would have over 30 million users and "You've Got Mail" was not only a catchphrase, but also the title of a Hollywood movie.
To bring me back to my point, my ideas may seem like theory, but they are far more than that. I have spent years studying the industry, analyzing viewing habits in relation to their medium in hopes of gathering a greater understanding of what lies ahead. I've seen the world of palm pilots, turn into a world of blackberrys, and then turn into a world of iphones. The technology ecosystem is brutal, and technological cannibalism occurs in months now, not years.
Television is no different. In the late 90's tube televisions were just beginning to be phased out after nearly four decades ofdominance. In the following 10 years, we experienced three dramatic shifts in television hardware. Tube TVs became flat screens, which became HD flat screens, which have now become 3D TVs. These changes are happening so rapidly, nobody can really keep up. Large companies are struggling to adapt to these rapid shifts in the industry, which is why small start-ups have been able to become game changers in the last few years. Their smaller operations make adaptation easier to the fast paced changes of these industries.
But while changes in technology have drastically shifted the hardware side of the industry, has that really changed the overall experience of these mediums? I mean sure, the operational differences between a flip phone and iPhone are drastic, but in the end, you're still making a phone call right?
WRONG. While it may seem like these experiences are the same, they are actually entirely different. While the hardware changes may define the physical transitions in this movement, it's actually the advancements in software that have truly altered the way people approach and engage with these mediums.
Interaction between users and mediums used to be a passive experience. You would turn on the TV and watch. You would sit down and read the newspaper. Today, technology has changed the way individuals interact with these mediums. We now expect interaction rather than passivity. Media no longer is sent from channel to user, but instead it's two-way street where information is sent in both directions. People want to engage themselves in this technology, because it offers them more choice and control.
Where this urge for engagement is most prevalent is in web-based media. The Internet has created a portal of endless media that is right at our fingertips, and content creators are flocking to to the web like gold miners to the Rockies. There isn't a content maker out there that doesn't have a web presence, and companies are becoming smarter when it comes to opening their content to the Internet.
The big networks have already taken to the web as a way to extend their programming to further audiences. NBC, ABC, and Fox all have a major stake in Hulu, which allows them to rake in the ad revenue on programming they own syndication rights to. For them it's a win-win, because site maintenance/hosting costs are low, and they still can collect ad revenue without lifting a finger. HBO and Showtime offer their programming online as well. Netflix distributes Starz content, Yahoo has a joint venture with Discovery, and most other networks stream their original content on their websites.
Viewers win also, because we get that "choice and control" that we covenet so much. Watching TV online on-demand brings all of the flexibility of web to the most basic of mediums. We watch what we want, when we want, where we want. No restrictions, no time schedules, we can pause and restart as we please. Since everybody already has a computer (and perhaps now a smartphone), access is as easy as ever. It's the perfect relationship, because we still get our content and networks still get their money.
But wait a second…something is missing. What about the content producers? The actors? The people behind the scenes creating all this content? Where's their cut? Do they really just sit back and watch the networks extend their revenue streams while their content flies around the Internet?
Here's where things get really interesting, because we have a reached a crossroad where shit really is starting to happen. But to understand how we got here, we have to take a quick history lesson to understand why things are like they are today…
Back in the day (mid 20th century) when television was a new technology, cable networks didn't exist, and all broadcasting was handled through the airwaves. Well if you know anything about broadcast technology, you know that these airwaves represent frequencies in which information can travel from one point to another. These frequencies run on a spectrum that is quite finite, and in order to make TV technology as functional as possible, this spectrum needed to be regulated. Without regulation, it would be nearly impossible to have functional channels because every frequency would be jammed with too much information (Think static radio).
So the FCC began issuing spectrum licenses to those they thought would control the airwaves for the "greater good" of the public. These "clear channels" would end up being ABC, NBC, CBS, and the other major local networks that you tend to find in the beginningof your TV guide.
While these networks provided important "greater good" services such as newscasts, sporting coverage, and other entertainment programming, it's important to note that they were given a natural monopoly by our government. With exclusive access to our nations TV spectrum, they were free to operate as they pleased with little to no competition.
Now let's say you're a creative person, and want to develop something for TV. Well, back then, there were only a few ways to do that. You could try to create the program yourself and sell it to the network, or work with the network and try to create the program as a joint-venture. Obviously the latter option was far more common, because nobody back then really had the financial capability to produce a show on their own.
What could you do? When networks control the airwaves, it's a one-lane road to broadcast.
In the 1980's when cable technology became popular, the situation for content producers was very similar. The only difference was instead of networks gaining broadcast licenses from the government, they purchased them from cable providers. In order to have your content on the air, you had to go through some sort of monopolized cable provider; and this was not cheap.
Now in case you're unaware of how television production works, most television productions are contracted out to other production companies that actually do most of the production work. So in essence, production companies develop and create shows for networks to purchase for air. This may be described as a joint venture, but in reality the situation is more like this…
1) Production Company develops show idea
2) Network green-lights show idea, provides financing for pilot or short season
3) Production Company produces show with network money (scripting, shooting, research, deliverables, pretty much all the hard work that goes into making a show)
4) Production company delivers network completed show
5) Network pays production company for completed work
6) Network airs show on monopolized airwaves, makes back lots of money in ad revenue, sponsorships, syndication rights, etc
7) Production company gets renewed contract should ratings be high.
After reading this, does it really seem like TV production is an equal joint-venture? Of course not! But what choices to production companies really have? Without the networks, there is no show. There are thousands of production companies out there trying to create, but only a handful of networks that have the ability to broadcast.
What's important to take away from all of this, is that these networks only exist due to their monopolies over broadcast rights. They are the connection between the camera and the cable box, and without that connection, the there is no TV.
But what if you didn't need a cable or network channel to broadcast your content? What if there was an entirely new medium that allowed viewers to watch premium content without having to subscribe or tune-in to TV networks? Something like say…THE INTERNET!!!
Yes! We have made it back to our crossroad, and the fun has finally arrived. Like Moses, the Internet is here to free content producers from the slave whips of network executives. The freedom and accessibility of the Internet has created a renaissance in creative video production, as anyone with a camera (or camera-phone) can create and upload original content for the world to see.
There's one other thing to note in regards to this renaissance in original content, and that is the rapidly declining costs of production. The transition into digital filming has drastically dropped the costs of filming, allowing so many more people to enter the market. With the drop in camera costs, the rise in new editing platforms, and the increased performance of personal computers, people can now produce high quality content at just basic costs.
So now we have more content, but where does it go? Sites such as Youtube, DailyMotion, Facebook, and Vimeo are providing easy access to some of the best online content available, but they are cluttered. There's no way to distinguish John's home-video from Jane's HD film trailer. There's no way to sift through the junk video blogs and lip syncing teenagers to find the good quality news stories and music videos.
These hosting sites provide a launching starting point for the webvideo movement, but they are clearly flawed in two major aspects. One being the lack of quality control, and two being the revenue sharing systems. With no upload restrictions, YouTube has become the craigslist of video sharing, with anyone and everyone posting their content without restriction. At first this provided an amazing service, because it put all of the best video content in one place. But as it's popularity grew, so did its clout and clutter, drawing all sorts of junk videos that have just tarnished the service.
Think about it like this, if you were watchmaker Rolex, would you want to be sold at the same place someone could buy a Timex? Hell no! You're product doesn't even deserve to be in the same room, let alone same store. Video content is the same way. Premium content providers don't want to put themselves on the same level as Nancy the travel blogger. They pour their heart and soul into their work, and deserve a little more respect.
This is the flaw with major hosting sites such as YouTube and DailyMotion. They have no separation between armature and professional, and it will cost them in the future.
The other flaw in their service is revenue sharing. Some sites including YouTube do offer "partnerships" with proven content producers, which include ad revenue sharing, but I still believe this to be a far cry from what is deserved. Why should YouTube get a substantial cut of something they had no hand in producing. Just because they have a site that hosts video? Hell, I can start my own website and host my content just as easily, while still taking in 100% of the profits.
This is the issue that I think has stalled the online revolution so far. Producers still haven't figured out how to financially capitalize on their online content. The big providers are either locked to major networks, or cluttered with junk and bad revenue-sharing systems.
Now is the part where you have to use your imagination, because the future is about to come.
Premium content producers need to start distributing their own content online. The top of the market has already made the jump, with Pay-per-view (PPV) services such as HBO and Showtime offering all of their content collections online. They realized early that it made no sense for them to make deals with cable networks when they could directly sell their content to users. Of course, they don't work with a ad revenue business model, but that's beside the point. They noticed early that the Internet grants them the freedom to become their own network.
They can directly sell their programming to customers, bypassing the hoops and deals from cable providers. Today hundreds ofthousands of PPV subscribers access their content via the Internet; do you know why? Because it provides them more choice, and more control.
But what about majority of TV, which is non-PPV? Can the Internet free them also? Yes, of course! Over the next three years, over 90% of televisions will either be directly connected, or connected through a box, to the Internet. Companies like Apple, Microsoft, and Google are already creating software platforms that will allow content producers to broadcast directly onto televisions through the web.
The Xbox, with over 40 million members, already provides HBO, Netflix, and an array of other premium content directly to televisions via the Internet. Sony's Playstation does the same! AppleTV, Roku, and Boxee all offer boxtop solutions that directly link TV sets to the web. And major TV companies such as Samsung, LG, and Sony have partnered with Google to directly integrate GoogleTV software into their sets.
Apple is even slated to announce a new Apple Television set (iTV) that will fully integrate Apple's mobile application store withtelevision sets. Think of the TV being one giant iPad, with the functionality to watch live TV, play games, and stream movies. It only took Apple two years to destroy the tablet market, think about what they can do in the TV world.
The revolution is here folks, and it's just a matter of time before content producers jump on the bandwagon. Why would big players like Dick Wolf and Jerry Bruckhiemer jump through hoops for major networks when they can distribute their content directly to consumers. They have millions of dollars in the bank to finance their projects, and by selling their content directly to viewers online, they can reel in 100% of the advertising profits. Did you hear me? 100% ad revenue!!!
Simon Fuller, creator/producer of American Idol, has the ability to make $7.1 million dollars an episode in ad revenue if he were to directly sell is show to consumers. American Idol broadcasts roughly 40 episodes a season, which would net him nearly $284 million a season. Now assuming that production costs are maybe $5 million a year, he would stand to be making almost $280 million dollars a season.
But in reality, Simon Fuller sold his entertainment company, Entertainment 19, for a total of $200 million dollars. His company not only owned American Idol, but all of the international licensing rights for the shows concept, which generates millions around the world. And he sold it for less than the ad revenue he would make in one season if he directly distributed online.
Now these numbers are all estimates, but you get the picture. There's a lot of money left on the table, and that's because he has to deal with the network. Take that away, and he's in complete control.
Steve Jobs realized this years ago, when he stopped distributing core Apple products at other retailers. He didn't see why he was spending so much time and money developing and producing amazing products while companies like Best Buy and Target made money on the sale. It's why he developed the Apple Store concept, which has become a staple in the company image. If you create a great product, you should sell it, don't let others take advantage of you.
TV producers need to think the same way. You make the content, you should distribute it. No more middle men, no more jumping through hoops. This is the time to take control, while the Internet is young and untamed. You can take back what is yours, and eliminate the monopolies that have controlled the industry for decades.
The time is now, so make your move. <comment><USER2> I get that television is, compared to most other art forms, a pretty new industry -- and that it's one with which many people are dissatisfied.

Stuff like this is dumb, in my opinion. Television's a medium and its here to stay for quite a long time. I'm not saying cable is -- I'm not saying network television is -- but audiovisual vignettes, the process of producing something for it to be watched, are going to be here for a while.

"We now expect interaction rather than passivity."

This, in my opinion, is silly. The engagement of interaction and the engagement of presentation are two different experiences.

I think the author makes a good point with regards to the barrier to entry decreasing; as a result, we're seeing more 'auteur' television, both on networks and on YouTube. Think back to the Renaissance, the shift from poets and great writers seeking patronage to the development of mass publishing -- we are seeing this within the video industry as well.

"Why would big players like Dick Wolf and Jerry Bruckhiemer jump through hoops for major networks when they can distribute their content directly to consumers."

Marketing, and the fact that the last Jerry Bruckheimer-produced film (On Stranger Tides) had a budget of $200 million.</comment>


Anonymous Browser Fingerprinting in Practice - <AUTHOR> http://valve.github.io/blog/2013/07/14/anonymous-browser-fingerprinting/

<comment><USER2> When these things come up on HN I pipe up a bit.

I wrote several implementations of passive device fingerprinting for fraud/security firms and they are implemented across a broad range of industries and companies. I know quite a bit about the shortcomings of these and the challenges faced, in case someone is interested.

Also, just FYI, the big use these days is actually NOT in security or fraud, though most of the companies selling these still say that is the case. The use is in advertising. Most of the companies selling these still call themselves "security" or "fraud" companies, but the revenues from advertising are far outpacing the former categories.

<comment><USER3> Have the fraud and security markets shrunk, or has the advertising market expanded?

<comment><USER2> I think is has to do more with the role of security/fraud in companies vs advertising.

For instance, security doesn't get much attention and people view it as a necessary evil. Fraud is about loss prevention in most cases, so the way you show your value is how much you save the company in loses. Your revenue is typically a fraction of those savings.

Most companies using tracking in advertising are still operating at a loss or have fuzzier ideas of "revenue". TBH, advertising is weird. People spend money like water without really knowing what they are getting in return. This obviously won't last, but there is money to be made in the meantime. At least that is my experience.

</comment></comment></comment><comment><USER4> And for anyone who hasn't tried it yet, here's EFF's site for testing how unique your browser's fingerprint is:

[https://panopticlick.eff.org](https://panopticlick.eff.org)

</comment><comment><USER5> Just a side note, I was momentarily confused regarding the author of this article. I had thought that it was Valve Software's github account. It took visiting [https://github.com/Valve/](https://github.com/Valve/) to realize that it was a private account.

</comment><comment><USER6> > Very few users have a staggering amount of fingerprints, for example 20-25. > I don't know if they have a lot of devices, use different browsers or > something else.

They probably use mostly public / school computers to access the website.

<comment><USER7> Or maybe they are just changing their browser windows size by hand, which would lead to a lot of different resolutions.

<comment><USER8> He's hopefully using screen width (window.screen.availHeight) rather than browser width (window.screen.height)

</comment></comment></comment><comment><USER9> I've been thinking about developing a browser plugin that would spoof fingerprints. Based on the URL in the address bar it would keep a discreet cookie-store and fuzzed version of the variables that fingerprinting looks at.

For example - if you are on espn.com then espn.com and all the trackers referenced from their pages would see a set of cookies and variables specific to espn.com. Browse over to icanhascheezeburger.com and even if the lolcats use the same trackers as espn.com does they would see a different set of cookies and a slightly different set of values - like browserid incremented by a .1 or a couple of non-essential plugins missing from the list of installed plugins.

I welcome any _technical_ feedback on the idea.

</comment><comment><USER10> The operational problem with these things is how do you deal with time? Over time folks upgrade plugins/browsers etc, making it not match the previous fingerprint. Therefore you won't be able to stitch two sessions together as belong to one person (who did the upgrade in between). Sounds to me directly opposing the core idea behind these techniques. (E.g. bringing it from unique identifier to persistent unique identifier)

<comment><USER11> If you read the actual paper referenced [0] you'll see that they explicitly mention this. Since they assumed that users were interactively trying to change their foot print, the looked at uses who had changed their settings within 1-2 hours:

"We ran our algorithm over the set of users whose cookies indicated that they were returning to the site 1-2 hours or more after their first visit, and who now had a different fingerprint. Excluding users whose fingerprints changed because they disabled javascript (a common case in response to visiting panopticlick.eff.org, but perhaps not so common in the real world), our heuristic made a correct guess in 65% of cases, an incorrect guess in 0.56% of cases, and no guess in 35% of cases. 99.1% of guesses were correct, while the false positive rate was 0.86%. Our algorithm was clearly very crude, and no doubt could be significantly improved with effort." (any typos here are likely the result of copy/pasting from the pdf)

0\. [https://panopticlick.eff.org/browser- uniqueness.pdf](https://panopticlick.eff.org/browser-uniqueness.pdf)

<comment><USER10> Missed that, but basically confirms the point (not being able to track ~35% of the cases is quite a big gap)

</comment></comment></comment><comment><USER12> One way to counter browser fingerprinting could be to add a plugin that simply report random data when queried. This would invalidate the hashing.

Of course, if the plugin is well known, it could be removed by the fingerprinting code, unless it can disguise itself as something else -more or less random- when it is installed.

<comment><USER2> I just have a couple of personal plugins that will change my reported UA slightly, my fonts collection slightly and some other random bits. Just screws it up enough so I know I'm not tracked.

<comment><USER13> Would you consider releasing these, or are you concerned if they were more common they would become less effective?

</comment></comment></comment><comment><USER14> I'm curious as to how many fingerprints match multiple users, which could be used to detect users logging into multiple accounts. This could be useful for detecting compromised accounts, or for banning all of the accounts belonging to a user trying to evade bans.

<comment><USER15> Wouldn't all default install browser installations on the same model of fresh- from-the-box laptops be identical? They quoted a 10-15% false match rate (excluding mobile phones which have a much higher false match rate due to lower configurability).

<comment><USER16> The first thing I do when I get a new laptop is wipe the hdd and install my preferred OS, which entails also installing my favorite browsers. (My OS choice doesn't come with a browser, or much else it's all up to the end user)

As for mobile devices, here too I always install my preferred software, so I don't see how mobile devices have lower configurability. That said, there exists databases with which one may at least identify the mobile device in order to serve up content appropriate for that device.

Alas, my tendencies make my devices uniquely identifiable!

(From Panopticlick) Your browser fingerprint appears to be unique among the 3,140,429 tested so far.

Currently, we estimate that your browser has a fingerprint that conveys at least 21.58 bits of identifying information.

That's for FreeBSD running Xombrero.

<comment><USER15> Sure, but average computer users probably have a much more default configuration, and thus the probability of unique match goes down.

That being said, people who tend to be worried about security also tend to have more unique computing configurations and thus would be more identifiable. Interesting.

</comment></comment></comment></comment><comment><USER17> I don't feel like this could accurately identify a return user as browsers such as Google Chrome have an auto updater that goes so often. The version number could likely be different when returning a few days later. Does anyone have thoughts about this?

</comment><comment><USER18> Security firms that sell this kind of service tout its accuracy, like it's going to prevent fraud by uniquely identifying everyone. Interesting that the author notes they stopped using it because of poor results.

</comment><comment><USER19> Related project matching against a database of >3Mio. fingerprints: [https://panopticlick.eff.org/](https://panopticlick.eff.org/)

<comment><USER20> Did you even read the article? They link that in the first sentence.

</comment></comment><comment><USER21> NoScript to the rescue, again.

<comment><USER2> In practice this is not effective, for as someone else noted, tracking can and is done at server level as well.

Most implementations, though, make the assumption that if they get JS info, that info is good. Better to give them wrong/inaccurate/changing JS info than no info.

So, I leave JS on, use some personal plugins to change variables and give them bad data on each request. They won't know and will just get bad fingerprints that are not seen again.

See this comment: [https://news.ycombinator.com/item?id=6046810](https://news.ycombinator.com/item?id=6046810)

<comment><USER22> Would it be possible have the source of those plugins open?</comment></comment></comment>


Twitter will remove inactive accounts and free up usernames in December - <AUTHOR> https://www.theverge.com/2019/11/26/20984328/twitter-removing-inactive-accounts-usernames-available-date <comment><USER2> I have, for the past few days, been trying to login to one of my older accounts to reactivate it and prevent it from being deleted or reassigned. However, every time I try to login it throws me to a "consentflow" URL and gives me a message saying "Something went wrong, try again later."

I've tried two different browsers, incognito and non-incognito, deleting cookies, resetting my password, and nothing seems to work.

I have no idea what to try next.

How I hate Twitter.</comment>


CDC recommends sweeping changes to American offices - <AUTHOR> https://www.cdc.gov/coronavirus/2019-ncov/community/office-buildings.html <comment><USER3> The advantage of being colocated in an office is collaboration--being able to work together in close proximity--and community--adhoc gatherings in communal areas. Take out these things to make the workplace safer and I can't see many advantages of being in the office at all.

I know that there's a lot of people who can't work effectively at home for many reasons, especially city dwellers with tiny apartments, but I wonder if there's a market for small private offices for them. A open office where you sit in a cubicle surrounded by perspex walls seems the worst of all worlds.

</comment><comment><USER4> > Modify or adjust seats, furniture, and workstations to maintain social > distancing of 6 feet between employees.

> Install transparent shields or other physical barriers where possible to > separate employees and visitors where social distancing is not an option.

> Replace high-touch communal items, such as coffee pots, water coolers, and > bulk snacks, with alternatives such as pre-packaged, single-serving items.

Hopefully this will help inject some sanity into open offices designs, or better yet, kill the idea entirely.

</comment><comment><USER5> I hate this "new normal". Whatever evidence you see for or against these policies, they are incredibly depressing to me. I don't want to spend the rest of my life 6 feet away from everyone afraid that they might infect me.

<comment><USER6> I think you're interpreting the "new normal" too literally. My understanding of it is that this is just until we get to a place where people can contract the virus without overwhelming hospital capacity. i.e. we have established better treatment options, perhaps achieved some level of herd immunity or immunization, and improved hospital triage plans.

<comment><USER7> More than that - there's a population at-risk of death. At 3-5X the ordinary disease rate. They'll be isolated until a vaccine becomes available - <USER2> or years.

</comment></comment></comment><comment><USER8> Per HN Guidelines, the title should be changed to "COVID-19 Employer Information for Office Buildings". There was no reason for the submitter to editorialize the original title.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment><comment><USER9> Elevators, stairwells and bathrooms are going to be problematic in a work environment. And will fire drills be cancelled until COVID-19 has been defeated?

<comment><USER10> Elevators are a huge problem: a friend of mine told me her employer calculated it would take 24 hours for all employees to arrive at their desks if they follow social distancing rules.

</comment></comment><comment><USER11> OUT OF THE CUBICLES AND...gosh almost anything else. Offices, even if it's just the size of a cubicle, would be really appreciated.

<comment><USER4> > OUT OF THE CUBICLES AND...gosh almost anything else.

Even cubicles would be an improvement on many "modern" office designs.

</comment></comment><comment><USER12> The actual title is "Employer Information for Office Buildings."

It's not as catchy as "CDC recommends sweeping changes..." but per HN rules shouldn't the original title be used?

<comment><USER13> @dang, can we get this altered?

</comment></comment><comment><AUTHOR> >C.D.C. Recommends Sweeping Changes to American Offices

[https://www.nytimes.com/2020/05/28/health/cdc-coronavirus- of...](https://www.nytimes.com/2020/05/28/health/cdc-coronavirus-offices.html)

</comment><comment><USER14> I'm glad to see them talk about HVAC systems and air filtration. Not enough conversations around reopening discuss this despite studies showing that HVAC systems can cause outbreaks and render all other efforts moot.

</comment><comment><USER15> Doesn't mention removing hot air dryers that blow droplets all over the place and replacing them with hand towels and changing taps to no touch ones.

<comment><USER11> Also the Dyson air blades: [https://arstechnica.com/science/2016/04/dyson- dryers-hurl-60...](https://arstechnica.com/science/2016/04/dyson-dryers- hurl-60x-more-viruses-most-at-kid-face-height-than-other-dryers/)

Note: Published in 2016

</comment></comment><comment><USER16> Not really understanding the editorializing in the headline here. The CDC isn't characterizing these recommendations as "sweeping changes", certainly. And at a first read they all seem quite sensible to me, and in line with general scientific consensus.

Some of them might be expensive, sure. It's a global pandemic, is it the government's job to make it magically free, somehow?

<comment><USER5> I hate the meme of a "scientific consensus" especially with this current topic. It really goes against the core of what science is. There is no "consensus" at this time about coronavirus, even if there are certain large groups that agree - that's not consensus. Perpetuating this idea that there is "scientific consensus" means that implicitly there are certain scientists that should be excluded because of their work or perspective in order to create this consensus (exclude those who disagree so that all agree).

Science, in the strict and true sense, denotes knowledge. Because knowledge is boundless, a scientist is an eternal revisionist; his overarching goal is to falsify his existing understanding, either by making new, contradictory observations, or by proposing better theories.

<comment><USER16> I'm sorry, can you be specific? What recommendations in this CDC document reflect science on which you feel there is significant uncertainty or disagreement?

This is almost all just straightforward isolation requirements. Social isolation as a disease prevention strategy has been practiced and studied for literally millenia. Yes, it's very much "scientific consensus".

Sure, there are questions unanswered, and there always will be. I don't see how that's relevant to "keep your workers from getting too close and keep your air from circulating unfiltered among them".

<comment><USER5> Sorry for the confusion, I'm referring to the parent poster's mention of "scientific consensus", not directly related to the CDC guidelines. There is a strong meme of talking about "what the science says" as if there is only one unified Science (TM) and people (scientists, even) who have differing views are either not real scientists or crazy</comment></comment></comment></comment>