Docker really is the future - <AUTHOR> http://blog.circleci.com/it-really-is-the-future/ <comment><USER2> Docker does neat stuff, but if it's really the future then I am going to be disappointed. Using the Docker daemon as a high-level interface to clone(2) has been nice, but Dockerfiles are a weak format (why not use a general purpose programming language?), the pre-built binaries on DockerHub are just asking for exploitation, and unioning a bunch of disk images is a hack to deal with the imperative nature of how images are built. Projects like Nix and GNU Guix are what I want the future to be. With them I don't have to put trust into any single third party, I get nearly bit-for-bit reproducible builds, system-wide deduplication of packages, functional/declarative system configuration, atomic updates/rollback, quick setup of development environments (with or without a container), and more.

<comment><USER3> I would be extremely interested in an article contrasting the approaches of Docker and Nix/Guix. Is there anything like this available? A cursory search returned mostly information on using the two together...

<comment><USER4> It's hard to compare them, because it's really 2 different things. I understand what parent means, and I think it's fair, but comparing Docker and Guix is weird, because they aren't really competing technologies.

Docker is somewhat hacky solution for lightweight containers on Linux. It is something tagged by #virtualization, although it isn't really that. And, well, it comes with even more hacky solution to configure these containers.

Nix/Guix is a package manager for your Linux distro. It is solution for stuff, for which you use apt-get. More generally, it is "the right one" solution for system configuration, which makes configuration reproducible. So it's hard to say, what is the difference between Docker and Nix/Guix because they serve different purposes, but if you compare configuration language, "the approach" \- you don't have to think twice to decide which is better. Nix isn't hacky and Guix is even less so, as opposed to Docker.

<comment><USER2> I should point out that Nix has container support built-in, without Docker, using systemd-nspawn. So, you get to use the same tools to manage systems on "metal", virtual machines, and containers. Pretty cool stuff!

</comment></comment></comment></comment><comment><USER5> > Up until now we've been deploying machines (the ops part of DevOps) > separately from applications (the dev part). And we've even had two > different teams administering these parts of the application stack. Which is > ludicrous because the application relies on the machine and the OS as well > as the code, and thinking of them separately makes no sense. Containers > unify the OS and the app within the developer's toolkit.

False. VM Blue/Green Phoenix Deployments were essentially "build VM for each release to production; spin up new VM; spin down old VM" which is essentially what Docker enables, except in container form....which you could have done with OpenVZ or any other containerization solution that has existed to date, even on AWS.

> Up until now, we've been deploying heavy-weight virtualized servers in sizes > that AWS provides. We couldn't say "I want 0.1 of a CPU and 200MB of RAM". > We've been wasting both virtualization overhead as well as using more > resources than our applications need. Containers can be deployed with much > smaller requirements, and do a better job of sharing.

As someone who runs & leases 128MB RAM VMs for various purposes...wut?

You could have just as easily used OpenVZ to achieve this and literally everything else on your list:

[https://openvz.org/Main_Page](https://openvz.org/Main_Page)

Or any other container-based solution.

The only real thing you are saying with this article is:

"We like the Docker ecosystem and we feel its better than all other solutions."

Fair enough, but at least don't pretend Docker is the only way to solve these problems.

<comment><USER6> This is a good example of what I was talking about at the start. Nothing that Docker does is completely new, and people were doing all these things before Docker.

What Docker does is make them easier, pull them all into the same package, bring the ecosystem of tools around a single technology, and most of all: traction!

<comment> vezzy-fnord > Nothing that Docker does is completely new, and people were doing all these > things before Docker.

You're contradicting yourself, because in the same article you wrote:

 _Into that world drops Docker: a new way of doing almost everything. It throws away old rules about operating systems, and deployment, and ops, and packaging, and firewalls, and PaaSes, and everything else._

Then all the hype about the "future".

<comment><USER6> It's the same stuff, but it does it differently. So for example, instead of using AMIs to prebake images, it uses a weird AUFS layer. And it deploys using Dockerhub or by pushing images directly to hosts. And instead of using Mesos it has Swarm. And Kubernetes: that really is quite different to what we're doing, but not that different, conceptually, from what Heroku is.

<comment><USER5> Yeah, I took your post as vezzy-fnord did.

But honestly, you have a very AWS-centric perception and the traction you talk about is really "Silicon Valley" specific. As long as you understand you are looking at a very, very narrow slice of the world when you use terms like that, sure, I can agree to that.

For personal stuff, I use docker because its easy w/o all the tools I have at work. But that isn't the same thing as "unique and new".

</comment></comment></comment></comment></comment><comment><USER7> Your post is invalid at some point. Of course Docker is great, of course new technologies are great. BUT the first point isn't so much of a joke. Docker is not the future, at least not for everyone. Currently Docker will not change the way how apps will be built, Docker will change nothing, ... at the beginning.

To start out new development, people should and never forget this, don't care about microservices and docker and anything else. They should just build a fucking big Monolith. After they did that, and they are getting more people for development or more people at their page / service / whatsever they can still start to split everything.

Don't build a fucking Unicorn just to be accurate. Start out boring. Do this every time and don't listen to anybody that tells you how good microservices and docker is. Deploy your app manually (okai this step could be skipped), then use a tool LIKE ansible or puppet, then if you need more, look at the things that bigger companies use.

But never ever over architect your project / application / service.

<comment><USER8> As "the Docker guy" I don't want to enter the debate, I will simply try to explain how we approached this problem when designing Docker.

Docker was designed explicitly so you _don 't_ have to change the architecture or flow of your application on day one. Rather, we want to provide tools that make your life easier in small ways _now_ , and make it possible to improve your architecture and workflow gradually, and _on your terms_.

This was a hard-learned lesson from building our previous product (Dotcloud, a Heroku competitor), which _did_ require developers to change everything on day 1. As a result it was simply not possible for many developers to use it.

<comment><USER9> It's humorous that what you just said goes exactly opposite to the blog post, which talks about how docker is designed to do everything completely differently because current methods "don't scale".

Keep up the good work on docker though, it seems to be getting some good traction so far! I'm personally wondering if it's more fashion based traction though, and someone will be inventing the next "docker, but more buzzword" before long.

<comment><USER8> > _It 's humorous that what you just said goes exactly opposite to the blog > post, which talks about how docker is designed to do everything completely > differently because current methods "don't scale"._

I don't think it's contradictory. We _do_ want Docker to change, for the better, the way applications are built and run. And if you _do_ want to throw away your existing stack and build your next application in the most portable and scalable way possible, then Docker can definitely help. It's just that it doesn't _require_ you to, because most people don't upgrade everything at once: they improve their toolbox gradually.

For example, there is a meme that "if you run more than one process in Docker, you're doing it wrong". I actually disagree with that. I think if you want to transpose an existing VM into a container, and think of it as a mini-server that you ssh into, that is your prerogative and Docker should support that use case. Maybe later you will look into the benefits of breaking up your application into smaller, single purpose containers (for example, you can now the Docker API and ecosystem at a finer level of granularity). And when you do, Docker should support that use case too.

A small disgression: I think it's unfortunate that the tech community feels the need to coalesce around polarizing "you're doing it wrong" statements. I find it particularly unfortunate that _Docker_ , a tool I created partly to make the development world _less_ polarized, was chosen as a battleground for ideological battles that I find frankly boring... Everything doesn't have to be a battle.

> _Keep up the good work on docker though, it seems to be getting some good > traction so far! I 'm personally wondering if it's more fashion based > traction though, and someone will be inventing the next "docker, but more > buzzword" before long._

Thanks.

Obviously it will be hard for me to answer that in an unbiased way. I think the "fashion" aspect is a matter of perspective. From the point of view of heavy Hacker News and Twitter users, there is a lot of hype, both positive and negative. But the huge majority of Docker users don't hang out on Hacker News (if they even know what it is). They have a job to do, Docker helps them do that job, and they tell their friends and colleagues about it.

We've tried to invite as many real-world users of Docker at next week's Dockercon, to talk about their experiences, both good and bad. Maybe watch a few of their presentations and decide for yourself if it feels like "fashion" :)

<comment><USER7> I hope I will see some interesting talks about scaling out SQL Databases and running Docker behind a firewall or running containers on customer hardware.. Docker has still some rough edges especially in "non internet" environments. where stuff is not moving that fast. Also it's really hard to scale out while running on a single box without internet access and trying to add more.. I hope thats something that soon (tm) could docker also fix.

</comment></comment></comment></comment></comment><comment><USER10> One of the things that rankles the greybeards is when people think over-hyped tools like Docker are original creations and they don't acknowledge that containerization has been around for a long time. It's not really that anyone makes this claim per se, but just a general impression fostered by the cool kids' relative youth and ignorance.

We all wish that software could be judged on objective merits, but the sad truth is that now more than ever the software development world is so big that UX and marketing for dev tools actually matter a lot more. Of course over time we still gravitate towards better things as lessons are learned, but in order to figure out what the actual best tool is, huge investments need to be made to get it to work. Until millions of man hours are invested, it's impossible to say whether something like Docker will in fact be better than what came before, or whether it will peter out at another local maximum due to a fundamentally flawed philosophy. If you can't generate some initial hype then it's hard to get enough developer mindshare to even test the premise of something as complex as Docker.

<comment><USER11> What are the older examples of containers? Virtualization and chroot jails have been around forever, but LXC didn't exist until 2008 ([https://en.m.wikipedia.org/wiki/LXC](https://en.m.wikipedia.org/wiki/LXC)). My beard is red, not gray, but I did a lot of years of coding and devops before I ever heard about containers.

What am I missing?

<comment><USER12> Solaris Zones? OpenVZ?

<comment><USER11> Cool! Thanks for the references I had never heard of those. They don't seem to predate LXC by that much though. Solaris Zones was released in '04 and OpenVZ was started around '00 and open sourced in'06.

I guess I don't consider 10-15 years a "long time" that's just approximately the amount of time necessary to turn a fundamentally new architecture concept into something you want to work with every day.

</comment></comment></comment></comment><comment><USER13> So Docker is beautiful and wonderful thing, and it is the future, and anybody who doesn't like it has no credibility because they just don't like change, and they are Philistines.

I stopped reading after that.

<comment><USER14> I agree with this summary assessment of the article.

I like docker and I believe it's potential is huge, but I don't like this article. At all. It's based on a false dichotomy and it's intentionally divisive. Trying to get a rankle out of people who disagree with you by trying to pin them as irrational "haters" is not discourse, it's propaganda.

"At the same time, most of the software industry makes its decisions like a high school teenager: they obsessively check for what's cool in their clique, maybe look around at what's on Instagram and Facebook, and then follow blindly where they are led"

I think my reaction to this is... this is definitely true, but how do I know you're not yet another lemming like the rest of us?

<comment><USER6> > how do I know you're not yet another lemming like the rest of us?

I'm pretty sure I am!

</comment></comment></comment><comment><USER15> > We are always faced with a choice between staying still with the > technologies we know, or taking a bit of a leap and trying the new thing, > learning the lessons and adapting and iterating and improving the industry > around us.

I think they forgot the third popular choice -- taking a bit of a leap, trying the new thing, and finding that it doesn't involve really adapting, iterating, or improving, it's pretty much just a reinvented wheel.

This might explain why the author apparently has trouble drawing a picture of the motivations behind curmudgeons who hate anything new.

If your tool _really_ _genuinely_ solves problems _without_ creating a new layer of complexity, it's not going to have very many haters.

<comment><USER6> > If your tool really genuinely solves problems without creating a new layer > of complexity, it's not going to have very many haters.

OP here. A thing I wanted to touch on, but left out. I don't think it's possible to solve problems without adding some complexity. For example, golang genuinely solves problems but you have to learn go and the new toolchain, etc. Once you learn them though (and the same is true for Docker here), you get to remove some of the complexity that existed with your previous tools.

So for example, in Docker, we'll be able to remove the host OS and move it into the hypervisor, and the complexity will drop to lower than it was before the start. Or we'll start to use the Google Cloud Platform (which is Kubernetes) and we won't think about anything other than our container image and the exact resources it needs.

<comment><USER15> > I don't think it's possible to solve problems without adding some > complexity.

Sounds like you're with the curmudgeons, apparently. ;)

> you have to learn go and the new toolchain, etc. Once you learn them though > (and the same is true for Docker here)

That's fine -- the overhead of learning something new isn't (inherently) "complexity" at all. This isn't to trivialize that overhead (or our frequent failure to minimize it), but complexity is more in whether the abstractions offered for dealing with a problem demand as little attention as possible.

Good tools/abstractions categorically reduce the number of details users have to pay attention to, and correctly pick the prominent ones most relevant to the problems they're trying to solve. Details beneath the abstraction _very_ rarely bubble up from beneath to break things or otherwise demand attention, and nobody even pretends that when they do that it's anything other than a problem. The end result is less complexity.

The curmudgeon invoked in the article is probably just someone who's seen that a lot of what we produce doesn't live up to this standard. It's not _impossible_ to produce these things. jQuery is one of my go-to examples: it did a great job of insulating developers from browser API differences and blew native APIs so far away in terms of convenience that people could mistake it for an application framework (or even a language). But that's relatively rare. Most abstractions are leakier and/or don't spare you from the details that are really bogging you down.

I'm not qualified to talk about which category Docker is in. I might be more qualified to talk about it if more of pieces like this focused on the specific problems rather than speculative theories about haters and curmudgeons. :)

I do like that this piece did at least spend _some_ time on a high-level overview of the kinds of problem-orientation it wants Docker users to take and by extension a very fuzzy introduction of how Docker can help.

</comment></comment></comment><comment><USER16> Both this and the previous tongue-in-cheek rant are correct. It depends on who you are.

The fact is that not everyone is going to need to scale to Google-like sizes, and not every app is going to need to scale _in the same way_.

For many developers trying to build products, getting bogged down in all this emerging Docker-centric complexity is a case of premature optimization. Build your thing, polish it, get users, get customers, etc., and if you manage to get so many that scaling becomes a problem then you now have a "good problem to have."

... and the problem with the Docker ecosystem is _not_ that it is new. I love new stuff. The problem is that it's a lot like the web framework ecosystem, which is an example of the CADT development model:

[http://www.jwz.org/doc/cadt.html](http://www.jwz.org/doc/cadt.html)

To a certain extent that's an artifact of all this Docker stuff being new and very much in its experimentation phase. I expect that the web will settle down a little someday, and this stuff will too, but for now it's a crazy wild west of people implementing Yet Another Everything. There's also a bit of a funding wave going through this area, which is causing a lot of me-too Docker startups to pop up and do the same things over and over.

</comment><comment><USER17> I'd agree that containers will be huge in the future. But it might not be with Docker, that's all.

</comment><comment><USER11> The same thing happened with "the cloud" and "nosql" etc etc. 2% of people crow "this changes everything!" and 2% yell back "this changes nothing you morons!" and both groups of people are wrong, and the other 94% of us just keep working and are grateful for all of the cool new tools that help us get to our goals faster.

10 years ago you couldn't build a Heroku unless you were a genius. Now you can build a Heroku clone in a month. That's progress.

Also, it's still just computers. Can we move on?

</comment><comment><USER18> Previous Blog post[1] is Gold!

[1] [http://blog.circleci.com/its-the-future/](http://blog.circleci.com/its- the-future/)

</comment><comment><USER19> The only potential use I see for Docker's potential is to distribute applications with data as combined appliances: so if you want a PostGIS server preloaded with maps, you can do `docker fetch some_postgis_server` and end up with something you can query. But then when you try to build such an appliance (containing a lot of data), and push it to Docker Hub, it ends up failing with a mysterious error code overnight, and you open a ticket, and nobody follows up on that ticket. Docker has to get better at that kind of thing before I can consider using it again.

<comment><USER20> I'm looking forward to using Docker (or another container format) for reproducible computational work. Now, it's still somewhat difficult to keep versions of programs in sync on clusters (even using environment modules). It will be really nice when we can store the application environment as a container and be able to pull that configuration off the shelf to repeat an experiment/analysis.

Unfortunately, that use-case usually happens on multi-tenant HPC clusters, where we can't use Docker yet until the security issues are figured out (or we can get a solid and standard micro VM for running containers). Job scheduling is also a non-trivial issue.

</comment></comment><comment><USER21> I think the future is something like prefabricated / disposable / immutable(ish) infrastructure. Stop managing servers, start managing your service.

Containers are a big part of that - they made the idea more palatable and usable. But if you're doing this BECAUSE of Docker and containers and PaaS being cool, rather than the benefits of disposability and prefabrication in enabling stable / predictable scale out , availability, and change management of your bits, you've probably already lost.

Netflix arguably started this cloud-native wave. They still use VMs.

</comment><comment><USER22> Docker seems interesting. But it seems like there is room for something even better.

I imagine a Docker-like product where you can write a Dockerfile for your checkin test suite as easily as you can write .travis.yml right now. And then you can run a command to easily submit this "job" to AWS, Google Compute, or whatever other cloud provider you want.

Maybe I'm thinking about this right now because my Travis build has been stuck waiting to be scheduled for over 24 hours for no apparent reason. I'm at the mercy of the Travis people to take a look at this. What I imagine is a world where cloud execution is so commoditized that I can say "sorry Travis, too slow, you lose my business today." I can hit CTRL+C, change my command-line to --submit-to=aws.amazon.com, and run exactly the same test suite there instead.

Oh, to dream...

</comment><comment><USER23> He made some good points, but there's a really good chance I'll never need to scale at a level that requires Docker. Hopefully I'm wrong, but Azure/AWS/Heroku are probably going to be good enough or overkill for my needs.

</comment><comment><USER24> Docker is an opinionated way to use containers. You don't need to adopt that to get the benefits of containers. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion.

By eschewing plain containers in favour of Docker you are embracing some complexity and it would help to have more discussions on the tradeoff and benefits of every approach, rather than just conflating containers to Docker.

The LXC project in development since 2009 on which Docker was based and now Systemd-nspawn give you pretty advanced containers with mature management tools, multiple container OSs, full stack linux networking, storage options, cloning, snapshotting etc. [1]

LXC and soon Systemd-nspawn (version 220) support unprivileged containers [2] that let's non root users run containers. That's a pretty big step forward for container security.

There is lot of innovation happening outside the hype of Docker. But these projects are not opinionated and stop at giving you container technology as lightweight VMs like KVM, Xen, Vmware stop at giving you virtualization.

Docker takes that as a base and restricts the container OS template to a single app, builds the container as layers using aufs, btrfs, device mapper, and enforces storage separation. This is not rocket science, you can do this yourself with overlayfs, aufs, btrfs, build single app containers etc [3]

By adopting the Docker way you are immediately taking away seamless migration of VM workloads and embracing some complexity. There are both upsides and downsides to this. For a lot of use cases the Docker approach may help, in others it may add unnecessary complexity. We have an indepth [4] look at the differences between LXC and Docker here for those who are interested.

Disclosure I run flockport.com that provides an app store for servers based on Linux containers.

[1] [https://flockport.com/guides](https://flockport.com/guides)

[2] [https://www.flockport.com/lxc-using-unprivileged- containers/](https://www.flockport.com/lxc-using-unprivileged-containers/)

[3] [https://www.flockport.com/experimenting-with- overlayfs](https://www.flockport.com/experimenting-with-overlayfs)

[4] [https://www.flockport.com/lxc-vs-docker](https://www.flockport.com/lxc- vs-docker)

</comment><comment><USER25> I'd say my problem with the whole massive containerization hype circus is less that I'm a curmudgeon who hates anything new, and more of a practicioner who hates marketing and social hype promoting a half solution to a narrow problem as a full solution to all problems.

Containerization isn't new. It just has a brand name now, and the "all the way" solution to this problem is unikernels.

</comment><comment><USER26> Docker is a broken package manager with no checksumming or version, leveraging layered filesystems to introduce more bugs with a chroot post install hook

</comment><comment> vezzy-fnord This whole article seems completely confused with its definitions and train of thought, which I suppose is delightfully ironic.

Some quarrels:

 _Into that world drops Docker: a new way of doing almost everything. It throws away old rules about operating systems, and deployment, and ops, and packaging, and firewalls, and PaaSes, and everything else._

That's a dramatic overstatement if I ever saw one. The rules haven't been thrown away. They're there, just the subsystems partitioned into multiple namespaces under a single host.

 _But then something interesting happened. Web applications got large enough that they started to need to scale._

The whole portion of the essay about web applications and distributed systems operates under a broken causal chain and continuity. That assumptions break down and new use cases arise with scale is obvious, though here it's presented like some recently attained enlightenment, and moreover that every J. Random Hacker should be thinking about distribution and high scalability right from the conception of their CRUD app. Not the case. Dumb setups work for the commons.

 _Instead of dealing with simple things like web frameworks, databases, and operating systems, we are now presented with tools like Swarm and Weave and Kubernetes and etcd, tools that don't pretend that everything is simple, and that actually require us to step up our game to not only solve problems, but to understand deeply the problems that we are solving._

This paragraph makes no sense. The author is listing completely orthogonal tools.

\</comment><comment>

On to the allegedly solved problems:

 _Which is ludicrous because the application relies on the machine and the OS as well as the code, and thinking of them separately makes no sense. Containers unify the OS and the app within the developer's toolkit._

Depends on your domain. Plenty of applications are built to be self-contained. The unikernel/libOS approach is one that treats the OS as an implementation detail, ironically taking us straight back to the 1950s where all code had to independently initialize the machine, though in a good and reusable way.

 _Up until now, we've been running our service-oriented architectures on AWS and Heroku and other IaaSes and PaaSes that lack any real tools for managing service-oriented architectures. Kubernetes and Swarm manage and orchestrate these services._

Those are all different deployment strategies and application environments you're mixing up here. It may not be that you've lacked tools so much as you've had no need for them in your use case.

 _Up until now, we have used entire operating systems to deploy our applications, with all of the security footprint that they entail, rather than the absolute minimal thing which we could deploy. Containers allow you to expose a very minimal application, with only the ports you need, which can even be as small as a single static binary._

And it does so by cloning the various subsystems of the host OS into their own namespaces. You don't get around using the whole OS, you just work around it because your host OS can't handle multi-tenant properly and the dynamic linking quagmire has become a maintenance burden.

 _Up until now, we have been using languages and frameworks that are largely designed for single applications on a single machine. The equivalent of Rails' routes for service-oriented architectures hasn't really existed before. Now Kubernetes and Compose allow you to specify topologies that cross services._

This hasn't changed. You still need to bolt on lots of heterogenous components. Seamless multi-node distribution is beyond the scope of nearly all language runtimes, or frameworks, though then again nor is there any obligation to support this. At sufficient scale, you will be doing lots of homegrown integration work.

 _We couldn't say "I want 0.1 of a CPU and 200MB of RAM"._

Pretty sure you could. I'm assume you're referring to the likes of Mesos, in which case I can name at least HTCondor, which is a cluster manager and scheduler not unlike Mesos, intended for HPC. It's been around since 1989. Then there's the much smaller scale things you could always do to limit resource utilization. It's not like this was discovered yesterday.

 _Up until now, we've been deploying applications and services using multi- tenant operating systems. Unix was built to have dozens of users running on it simultaneously, sharing binaries and databases and filesystems and services._

Author confuses multi-user with multi-tenant. Unix is the former.

 _As an example, how many protocols had to die before we got REST? ... Yet, we still haven't got the same level of tooling for REST-based APIs that we had for SOAP a decade ago, and SOAP in particular has yet to fully die._

REST isn't even a clear protocol suite like SOAP or CORBA. It's more of a design philosophy than a formal definition.

 _And the same thing has been going on with programming languages since we escaped Java a decade ago._

We did?

 _If you're looking for me, I'll be in the future._

Damn, it looks an awful lot like the past.

<comment><USER27> > REST isn't even a clear protocol suite like SOAP or CORBA. It's more of a > design philosophy than a formal definition.

It's also one of the most misunderstood architectural styles I have seen. If you see any read-write API that calls itself "RESTful", chances are it violates at least one compulsory constraint of REST (very often Uniform Interface), in effect meaning "HTTP-Based API that is not SOAP".

</comment></comment><comment><USER28> Docker is the present - given we don't have jails on linux.

Docker COULD be the future, but I frankly hope it's not. Despite the idea being good, there are better designed alternatives.

Like rkt.

</comment><comment><USER29> TLDR; A frank retraction of the sentiment expressed sarcastically in the previous post is summarized under _Real problems solved_. However, each of these points is dubious...

1\. _Up until now, we've been running our service-oriented architectures on AWS and Heroku and other IaaSes and PaaSes that lack any real tools for managing service-oriented architectures. Kubernetes and Swarm manage and orchestrate these services._

While some options for managing large groups of services running on one type of infrastructure do indeed now exist, and this is one step further in automation and therefore a good-thing(tm), it is by no means the end-game and in fact at this stage may not even be desirable as it is in effect simply shifting the basic scope of service-oriented infrastructure comprehension and management from a single service to a group of services, and likewise the units of deployment and management of infrastructure a cluster rather than a host, while making certain (and not safely universal) assumptions about how the service(s) will need to be managed in future.

2\. _Up until now, we have used entire operating systems to deploy our applications, with all of the security footprint that they entail, rather than the absolute minimal thing which we could deploy. Containers allow you to expose a very minimal application, with only the ports you need, which can even be as small as a single static binary._

Yes but this rarely happens in practice. It's like saying "now we use Linux, we get the benefits of NSA SEL". No, you don't. You have to put a lot of effort in to get that far, and it's highly unlikely to be used. So this is basically a moot point right now.

3\. _Up until now, we have been fiddling with machines after they went live, either using "configuration management" tools or by redeploying an application to the same machine multiple times. Since containers are scaled up and down by orchestration frameworks, only immutable images are started, and running machines are never reused, removing potential points of failure._

Yes, immutable infrastructure is good, but we have 100 ways to do this without docker. Docker is like an overpriced gardener who comes to your door, knocks around the garden for half an hour, flashes a thousand dollar smile - ie. put a cute process convention over the top of what's there already - and tell you all smells sweet in the rose garden (PS. here's your fat invoice). Never trust a workman with an invoice, and never trust abstraction to solve a fundamental problem.

4\. _Up until now, we have been using languages and frameworks that are largely designed for single applications on a single machine. The equivalent of Rails' routes for service-oriented architectures hasn't really existed before. Now Kubernetes and Compose allow you to specify topologies that cross services._

Well that's cute, but actually bullshit. We've had TCP/IP and DNS for decades. To "specify topologies that cross services" you just go _host_ : _port_. What's more, the standard approach and protocols actually have deployment, documentation, and are known to work pretty well on real world infrastructure. Their drawbacks are known. Now, I'm not saying there's zero improvement to be made, but the way this is phrased is ridiculous.

5\. _Up until now, we've been deploying heavy-weight virtualized servers in sizes that AWS provides. We couldn't say "I want 0.1 of a CPU and 200MB of RAM". We've been wasting both virtualization overhead as well as using more resources than our applications need. Containers can be deployed with much smaller requirements, and do a better job of sharing._

Sure, we've known that container-based virtualization was far more efficient than paravirtualization for decades. Docker has not actually provided either, nor made it measurably easier to mix and match them as required, so this claim seems bogus.

6\. _Up until now, we've been deploying applications and services using multi- user operating systems. Unix was built to have dozens of users running on it simultaneously, sharing binaries and databases and filesystems and services. This is a complete mismatch for what we do when we build web services. Again, containers can hold just simple binaries instead of entire OSes, which results in a lot less to think about in your application or service._

What kool-aid is this? The implication is that unix and its security model are going to go away as a basis for service deployment because... docker. What? Frankly, I would assert that many application programmers can barely _chmod_ their _htdocs /_ if pushed, let alone understand a process security model including socket properties, process state, threads, resource limits and so forth. Basically, the current system exists because _it is simple enough to mostly work most of the time_. While it may not be perfect, it's a whole lot better than throwing the baby out with the bathwater and attempting to rewrite every goddamn tool to use a new security model. The mystical single binary services that docker enthusiasts seem to hold up as their _raison d 'être_ are likely therefore to either tend to be huge, complex, existing processes allowing almost anything (like scripting language interpreter VMs) or nonexistant. By contrast, the 'previous' unix model of multi-process services with disparate per-process UIDs/GIDs, filesystem and resource limitations seems positively elegant.

All in all, this post's argument doesn't hold that much water in my view. However, I applaud CircleCI for working on workflow processes ... I think ultimately these are the bigger picture, and docker is merely one step in that direction.

</comment><comment><USER30> Excellent article.

</comment><comment><USER31> I want to like Docker. I just don't have the time to learn the tooling and keep up with all the changes. Maybe in a year or two when things stabilize.

<comment><USER32> Software has become like Matryoshka dolls - layer after layer of packaging. Even Python and Javascript programs now need "building". (I saw a makefile for a Python program last week. All it did was "test: python app.py test", but there was a makefile.)

It's sometimes easier just to make a static executable in Go or Rust.</comment></comment>


My implementation of simple ruby Binary Reverse puzzle from Spotify - <AUTHOR> https://gist.github.com/rajahafify/5663654

<comment><AUTHOR> I stumbled upon Spotify puzzle page while checking out their jobs page. I love Spotify and working for them would be cool. But they only want submision based on Python, C++ or Java.

I wrote one in ruby still. Not much of an implementation but I did it as proper as I could.

Any comment on how I can improve the code is appreciate.

P/S: I don't know the etiquette here at Hacker News. Especially with regards to posting submission like this. Tell me if I violate any kind of code of conduct or anything.</comment>


The rise of context-aware computing - <AUTHOR> http://kent.io/post/68239366153/context-aware-computing-is-the-next-big-thing <comment><USER2> I find concept videos like this often grossly over-simplify the problem of contextual computing, or even personalization for the matter.

I think today we already have plenty of context -- A paypass-equipped credit card can already provide context. And NFC-equipped phone, or even your wifi or bluetooth fingerprint. All of these things are already capable of providing the same level of uniqueness describing your person (Or at least arranging the transfer of enough uniqueness to qualify you).

I think the biggest problem that every entrepreneur always misses is: "How do we define context?"

"How do we organize it?" "How do we make sure that your personal information is open, tailored to you, and not limited in so much as Microsoft, Apple, or Facebook is willing to sell you that expression of identity which you will be LIMITED to being, as they see fit."

I think it comes down to a much more broad question that I don't think the industry has yet to answer at all.

What is the GRAMMAR of this context -- that will make it so fluid that everybody can integrate with it, seamlessly?

This is not something the industry has tried to answer, because we're still arguing over Apache's "Web of Things" vs a Json "Web of Things". We haven't even prescribed machine-understandable meaning to these free structured Apis yet -- let alone write a system that can automatically understand what a trunk is, how it works, and the entire context and meaning of a car.

This is not a move to context -- it's a limited gesture, and one that isn't based in the realm of context any more than a key understands a door.

<comment><USER3> If there only was some way of reading one's mind. You could create a device that holds your hand and hums your favourite tune as you cross the street, tell you when it's time to go pee-pee and tells you a cute story when you go to bed.

I hate the future where you can't drive a car because the cars drive themselves, you can't create a campfire (or even bbq) because the drones put it out and call the cops, can't flip the bird at anyone because the picture of that is instantly posted to your profile for your employer and clients to see, can't watch the games on the couch with a crate of beer because the tv watches you and forwards the data to your doctor, etc.

Wait a minute, we're nearly there already. Better book a trip to Bouvet...

<comment><USER4> It is easy to focus on what inevitable restrictions are more easily "enforced" with the technology (but those restrictions by and large already exist). I think it is far more interesting to focus on what they enable.

</comment></comment></comment><comment><USER5> Ah yes, the semantic web. Remember when that was going to change everything? All it required was for everyone on the web to meticulously format their data into carefully structured databases. I can't imagine why it never gained much traction.

As an interesting side note, part of the reason of the success of google is that through the page rank algorithm they were able to extract highly important _implicit_ data on the relative popularity, authoritativeness, and context of links rather than being forced to rely only on explicit data.

I will make the claim that in the future devices and systems which work on implicit context and metadata are going to be more successful at these sorts of high level pseudo-cognitive capabilities than anything which is dependent on people changing the way they do everything.

</comment><comment><USER6> I started working on a project with a friend to use NFC in phones to start on this problem.

We where working on using NFC to auto lock and unlock your PC when you phone was on your desk hear a receiver. The idea originated from using the NFC to by pass the RFID door scanner so we didn't need our toggles to get into the office. Deciding we could get in troupe pissing around trying to bypass the security system we ended up working backwards to something easier... being the lock/unlock thing.

Unfortunately we stopped working on it when my friend went broke and his priorities changed (i.e. silly hobby projects don't pay the bills).

Would love to pick it up again some time in the future, we had lots of awesome discussions and ideas with this field. We where just investigating a braclet RFID to add to the system as a two factor authentication, so you needed more than just the phone do it. But thats roughly where we got up to.

</comment><comment><USER7> This is so true, and it's such a hard problem.

AFAIK, only Google (with Google Now) is tackling it seriously. The Sixth Sense demo[1] showed where we should be going.

(The linked Nymi tool isn't particularly interesting IMHO. It's certainly not much more capable than things like the FitBit, or the much more capable sports oriented Garmin devices)

[1] [http://www.ted.com/talks/pranav_mistry_the_thrilling_potenti...](http://www.ted.com/talks/pranav_mistry_the_thrilling_potential_of_sixthsense_technology.html)

</comment><comment><USER8> I get a feeling that this is what Apple might be trying to accomplish with their rumoured iWatch. They've been hiring experts in heart rate measurement and other biometrics. There have also been rumours that the iWatch would integrate with home automation systems.

[http://www.macrumors.com/2013/07/18/apple-taps-new-hires- in-...](http://www.macrumors.com/2013/07/18/apple-taps-new-hires-in-health- sensors-broad-array-of-internal-experts-for-iwatch-team/)</comment>


ffind: a sane replacement for command line file search - <AUTHOR> http://wrongsideofmemphis.com/2012/11/19/ffind-a-sane-replacement-for-command-line-file-search/

<comment><USER2> I wrote a similar tool to this in C, ff ([https://github.com/silentbicycle/ff](https://github.com/silentbicycle/ff)).

The main difference is that, where `ffind foo` appears to be comparable to

        find . -name "*foo*"

, ff is closer to

        find . -name ".*f.*o.*o.*"

In other words, you don't need an exact match, just the characters given in order. (This is inspired by Lisp-y toolchains where e.g. c-w-c-c would search and expand to call-with-current-continuation.)

There are some other features (e.g. '=' toggles literal match, it has smart handling for '/' and directory name grouping), but it's pretty straightforward to use. It also doesn't depend on python.

</comment><comment><USER3> Similarly, I have a little shell function loaded by .zshrc that covers 90% of my use cases:

       findit() {
           find . -name \* -exec grep -iH $1 {} \;
       }

<comment><USER4> Why not just run a recursive grep? That would save having to invoke grep on every single file found.

        findit() {
            grep -iHR $1 .
        }

Alternately, you could use the '+' variant of -exec in order to batch files together to be processed together.

<comment><USER3> Cool, I wasn't aware of a -R flag in grep for some reason. I need to go back and re-read the man pages...

</comment></comment></comment><comment><USER5> Many of the commenters here have missed an essential line of ffind's description from the article, emphasis mine:

> find in this directory and all the subdirectories a file that contains > some_text _in its filename_

This is NOT a find+grep/ack/ag -alike. It's used for rapid search on filenames, not file contents. Think of it as TextMate's Cmd-T for the command- line.

</comment><comment><USER6> I find myself doing this a lot when sifting through huge codebases:

find . -type f -print0 | xargs -0 grep -Hin <identifier>

The -print0/xargs thing is to get around spaces in filenames or directories. I don't think spaces belong in source files (or directory trees containing source code) for a gazillion different reasons, but I still stumble across it every once in a great while. There are also platforms where system directories have spaces in them, so if you're scrounging through a deep subdirectory tree trying to find something, you may have to deal with the spaces thing. I've been bitten by it enough times that I just always do this rather than have to think about whether or not I might need to do it every time I use find.

Depending on what I'm looking for, I might select files with -type, or a -name glob, or whatever. I use '-type f' most commonly because the source code I deal with has a fair number of interesting things defined outside of files with the standard source/header extensions in their names.

There's usually a couple pipe stages after this filled with 'grep -v <stuff I don't care about>', or more greps to narrow down the result set. Sometimes this all goes in shell scripts or sometimes I just type it all out.

<comment><USER7> How about

      grep -irn <identifier> .

?

-r recurses and since it is multiple files implies -H.

<comment><USER6> Yep, that's much nicer. :) I always forget about recursive grep.

</comment></comment></comment><comment><USER8> Alternatively, you may just install _locate_. It won't examine file contents, but it works in the common cases. It's also blazingly fast because it's indexed.

<comment><USER9> Its problem that you always have to update the index, which can be problematic in fast changing systems (and quite slow in some cases). The greatest disadvantage is that you need root rights to update the index.

<comment><USER10> You can have arbitrary indices being created by arbitrary users. The database(s) that is(are) used by the locate command can be specified by command-line option or by an environment variable.

</comment></comment></comment><comment><USER11> If you just want a shortcut to invoke find in this common way, put this in your shell's profile:

      function ffind {
          if [ $# -eq 1 ]; then
              search_path='.'
              expression=$1
          elif [ $# -eq 2 ]; then
              search_path=$1
              expression=$2
          else
              echo "ffind [path] expression"
              return 1
          fi
          find $search_path -name $expression
    }

</comment><comment><USER9> I looked into his python implementation, I thought he would just translate the parameters and call find, but he instead did go to implement the search algorithm. Wouldn't that make it a bit slower than the original find?

<comment><USER12> File system traversal can be quite slow on traditional hard disk drive, it requires a lot of random disk access which has much higher latency than sequential access (think about the moving parts in the disk drive). So I guess that being written in Python is hardly the bottleneck if the disk reads have not been cached by the kernel.

</comment></comment><comment><USER13> What are the advantages of this over

        mdfind -onlyin . <str>

<comment><USER14> It searches the contents of files, not just the names of files.

<comment><USER13> So does mdfind.

<comment><USER14> I stand corrected.

(I tested before I posted, but forgot MD indexing was turned off.)

</comment></comment></comment></comment><comment><USER15> Yeah thats ok but holy cow, thanks for letting me find out about ack! ack is awesome!

<comment><USER16> If you like ack (and who doesn't???), you might like more or less `ag`: [https://github.com/ggreer/the_silver_searcher](https://github.com/ggreer/the_silver_searcher)

<comment><USER15> I did notice ack is pretty slow and i may try ag but speed isnt a problem here for me i think

btw, heres what ive been using up until now:

        alias gerp='grep -riHnT . -e'

and more recently:

        alias gerp="find . -type f | perl -lne 'print if -T;' | xargs egrep -riHnT"

</comment></comment></comment><comment><USER17> This ffind isn't this ffind: [https://github.com/sjl/friendly- find](https://github.com/sjl/friendly-find) ?

</comment><comment><USER18> In zsh:

        print -l **/*myfile

</comment><comment><USER19> From reading this, I'm not entirely sure what makes this better than grep. I get why it is cool to have written it.

<comment><USER20> It's not a replacement for grep, it's a replacement for find

<comment><USER19> That works by searching the contents of files. So, it is just a grep -l -R . 'search terms', right?

Edit: Actually, now that I am revisiting this thread. The top post hit my misunderstanding on the head.

</comment></comment></comment><comment><USER21> It is a remarkable shame the author did not read the ack manpage to discover the '-g' option.

</comment><comment><USER22> why not just find|grep <pattern>

</comment><comment><USER23> find | grep foo</comment>


Ask HN: Good Morn. - What's The Quickest Way To A Million Dollars In 1-2 Years? - <AUTHOR>

<comment><USER2> Startups are overrated. Start a service-based business. Start alone. For the first 3 - 6 months, focus on building a portfolio of good work and references. For the next 6 - 12 months, focus on steadily increasing your rates/prices and bring on-board one or two technical people to help you on a freelance basis. You must continue to do sales and ask for referrals. The next 12 - 24 months, focus on scaling your services and capacity. I know it's easier said than done - but this is what worked for me.

Background: 25 years old this year, software development firm made $500k in revenue so far in 2013.

Caveat: 1 million dollars revenue != 1 million dollars profit. Huge difference.

<comment><AUTHOR> \- Okay thank you very much for this info penguin_gab.

</comment></comment><comment><USER3> Find a niche that you can offer something that people will want or better yet, pay for. It's better to start small or find a way to enter a market that you can easily differentiate yourself and go from there. Also, you shouldn't try to hide your idea, most ideas aren't unique, it's how you execute them off that can make or break them. So don't be afraid to tell friends and acquaintances and have them give you feedback. There is no easy way to a million but with the internet there are now more ways then ever.

<comment><AUTHOR> \- Okay thanks for the wisdom ksaville00. I appreciate it.

</comment></comment><comment><USER4> Start with a $100 mil. 1 Put $$$ in savings account with at least 2% interest 2 Wait ... 4 Profit!

<comment><USER5> Borrow $2 million from your parents. Wait until they die.

<comment><AUTHOR> \- Very funny VikingCoder, but my parents are not that rich.

</comment></comment></comment><comment><USER6> The most realistic way for you to get there is this:

1\. Have the tech skills to launch a complete web application or project that can either easily be acquired or generate revenue. If the former, aim for something viral and exciting. Think Threewords.me, which supposedly sold for 6 figures days after Mark Bao launched it. If the latter, price high and build a product for businesses or high-net-worth individuals. Assuming 30k of yearly living expenses, and not factoring in taxes (too complicated to calculate this right now), you'll need about 1,060,000 dollars. 1000 customers each paying 49 each per month over 2 years is $1,176,000.

2\. Get paid at a salaried job / freelancing using said skills. Assuming you've got enough experience to do (1), you should be able to pull at least 100k. Live frugally and you can save 50k-100k from this job alone after two years.

3\. Work on various iterations of (1) in your off-time from (2). Don't be afraid to sell a site on Flippa for a middling price if it doesn't seem to be growing huge. 10 sites at 5k each is still 50k.

<comment><AUTHOR> \- Keiferski, thank you for giving me 3 options. I really appreciate it.

</comment></comment><comment><USER7> Acquire 10.15 Bitcoins and hope that the 2013 Wedbush Report [1] will be correct.

[1] $98,500 per BTC [http://www.scribd.com/doc/188644617/Bitcoin-Intrinsic- Value-...](http://www.scribd.com/doc/188644617/Bitcoin-Intrinsic-Value- Wedbush-Report-December-2013)

<comment> marco-fiset The problem with Bitcoins is that you must be able to sell them afterwards. And this would surely be a huge leap of faith.

<comment><AUTHOR> \- Okay, I will put that into consideration next time marco-fiset.

</comment></comment></comment><comment><USER8> Borrow 500k go to the casino and bet on red twice. 25% chance of a million dollars 50% chance of +- 0.

<comment><USER9> Funnily enough, this would probably be the answer that requires both the least amount of work, and has the best odds of actually succeeding :P

</comment></comment><comment><USER10> Start a company get 5 million dollar valuation and investment by making people think your in it for the long haul. Retain 20% that can't be diluted and has no strings attached. Get fired. sell said precentage once new CEO takes over.

<comment><USER11> What would the contract language that prevents a share from being diluted say?

</comment></comment><comment><USER12> Take 100k and invest 20k in five early stage startups for five to ten percent of equity.. pray for the next two years that one of them gets acquired for a billion

<comment><AUTHOR> \- Very very smart imahboob. I first need to get the money to acquire the 100k first.

</comment></comment><comment><USER13> <serious> Start a new silkroad </serious>

<comment><AUTHOR> \- Okay thank you hardwaresofton.

</comment></comment><comment><USER14> You can start with five and work from there. ;-)

<comment><AUTHOR> \- lol. Nice. Thanks rbanffy.

</comment></comment><comment><USER15> Forex. Stock market. Niche web/mobile app.

<comment><AUTHOR> \- Okay I'll definitely get into those joeldidit. Thank you.

</comment></comment><comment><USER16> Finance - if you can get a job in finance.

<comment><AUTHOR> \- Okay padseeker, thank you for the knowledge.

</comment></comment><comment><USER17> Organ traffic.

<comment><AUTHOR> \- Okay thank you rrzar.

</comment></comment><comment><USER18> Make a good SaaS.

<comment><AUTHOR> \- Okay thank you meerita.

</comment></comment><comment><USER19> Drugs.

<comment><USER5> [https://lh3.googleusercontent.com/-9nZQu7k930Q/TW5Negr-u5I/A...](https://lh3.googleusercontent.com/-9nZQu7k930Q/TW5Negr-u5I/AAAAAAAABnU/QYxWH0-GKOU/s1600/charlie_sheen_ferris_Bueller.jpg)

<comment><AUTHOR> \- lol, nice one.

</comment></comment></comment><comment><AUTHOR> \- I totally forgot that I had ask this question but I will like to thank everyone for their response. Thank you so much. I appreciate it.</comment>


640k Really Is Enough for Anyone - <AUTHOR> https://blog.sourcerer.io/640k-really-is-enough-for-anyone-314f393ca5b8 <comment><USER2> Bill Gates never said "640k ought to be enough for anybody."

[https://www.computerworld.com/article/2534312/operating- syst...](https://www.computerworld.com/article/2534312/operating-systems/the-- 640k--quote-won-t-go-away----but-did-gates-really-say-it-.html)

<comment><USER3> Why does this myth keep getting pushed - by tech people no less? Bill Gates emphatically denied ever saying it and no one has ever come forward with a scrap of evidence he actually said it.

<comment><USER4> Guess: it _was_ perpetuated because lots of tech people hated him and what he did to the industry and to computing progress in general.

He has since gotten way, way better PR handling though. Just look at the way Reddit absolutely adores him nowadays (he's done lots of very carefully managed AMAs). Heck, even on HN there's enough young people who have no idea how much this one individual repressed computing progress over 1-2 decades through market abuse.

Here's one example of many of how the pro billg PR is done:

[https://www.reddit.com/r/secretsanta/comments/5iphpa/i_won_s...](https://www.reddit.com/r/secretsanta/comments/5iphpa/i_won_secret_santabill_gates_was_my_santa_link_to/)

<comment><USER5> > (he's done lots of very carefully managed AMAs)

You seem to have a pretty prominent chip on your shoulder regarding Bill Gates.

Gates has donated billions of dollars of his fortune to charity and he's largely credited for having eradicated malaria through these efforts in multiple countries.

It's hard to find a good reason to dislike someone like that.

<comment><USER4> How old are you? Let me just guess; not old enough to have experienced living/working in tech while Bill was doing his thing.

Did you ever pause to consider how much humanity would have progressed without him stopping so much progress in the first place?

(I deleted a section on the malaria stuff; I misread your comment slightly at first.)

<comment><USER6> I never liked Bill Gates when I was a power user in the nineties and early 2000s but it really is amazing that one could offset his contribution to disease eradication and his philanthropy generally with some aggravation about his business' tactics and nebulous what-ifs about what might have happened if he had not been on the scene or had behaved differently. (Moore's Law would did it's thing anyway, whether he was there or not, and even with him there, Microsoft's stranglehold on the desktop market relented anyway.) Do you really think the annoyance of a free browser warrants indicting his post-business career?

<comment><USER4> Just noting that this comment first only talked about the browser bundling antitrust thing, and then, after I commented, completely morphed into something else.

<comment><USER6> I'm not really sure what you are referring to because I have not edited any of my comments, but this one probably closely resembles another one I made further up and therefore might give you the impression that there had been some 'morphing' involved.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As for the alleged Bill Gates quote, I read somewhere (Deep C Secrets by Peer van der Linden, I think, but I am too lazy to look it up), that "640k ought to be enough for anyone" did not mean that it was enough for anyone for all times. I am not a fan of Bill Gates, but he is not stupid. And at the time he - allegedly - said it, 640k of RAM _was_ (for a single user!) was indeed a lot! Compare that to the 64k of the C64. It is idiotic to think that he meant that 640k would be sufficient 30 years in the future.

That being said, I actually did install MS-DOS 6.22 on three computers over the last couple of years, because the company I work at does - among other things - industrial automation, and (at least) one of our customers has a plant built with automation technology that can apparently only be programmed and configured with a program running on DOS. And it must do some rather funky things, because the software will reliably fail to talk to the PLC if it is running in a virtual machine or on FreeDOS. And of course the company that has written this software has gone out of business a long time ago, so there won't be any updates, either. ;-) If I didn't have more important things to do, figuring out why it does not work on FreeDOS could have been a lot of fun, but just installing MS DOS was the faster solution.

Still, installing DOS these days is an interesting experience. The whole system comes on three floppy disks, the installation procedure takes about 15 minutes, and the freshly installed system boots up in about 30 seconds, _including_ the BIOS doing its thing. Admittedly, you cannot do very much with it without additional software.

Three floppy disks - that is about 4.5 Megabyte, Ladies and Gentlemen. Today's high end CPUs have as much L2 cache, or more.

And primitive as it is, there are situations where DOS is a reasonable choice.

I'm still glad, though, that I never had to deal with segmented memory. That sounds horrible.

<comment><USER8> What I don't get is, if this multi-decade-old software is valuable enough to be used today, why isn't it valuable enough for someone to have written a replacement in the intervening decades?

Surely every plant like this would pay _something_ for the ability to run on modern OSes, and presumably there are enough plants using this kind of software to recoup the cost of development?

<comment><USER9> This isn't software that you can just install and use. This type of software is tightly integrated with the hardware in the factory or distribution center. So, even if there were free software which did the same thing, it would cost a lot of time and money to replace the old, already-working system.

Moreover, for software that was put in place 20 years ago, it's likely that some of the functionality is unknown, i.e. the whole system works together, but exactly what is being done by each piece of software isn't fully understood by anyone still at the company. So it would require a bunch of work to even spec a replacement.

So it's totally rational to keep the existing, working system, even if you need a dedicated PC to administer it.

(Source: I was in a similar situation ~20 years ago.)

</comment></comment></comment><comment><USER10> I love the idea that there's still an active community developing for old hardware. Specially on videogames since many times they apply modern design ideas in very old hardware.

As a dumb example I saw a platformer for the ZX spectrum not long ago, where the falling speed was not linear but accelerated, which may seem trivial now but back then was something really unusual and I didn't realized how big was the difference after watching it. Then you have stuff way more complex such as the RTS for the Commodore mentioned by the author.

About the quote. Bill Gates said once in an interview:

> I've said some stupid things and some wrong things, but not that. No one > involved in computers would ever say that a certain amount of memory is > enough for all time.

<comment><USER11> There are new games coming out for the Atari 2600 just about every three months.

And a guy in Texas recently released a very interesting looking Ultima IV- style game for the Commodore 64.

<comment><USER12> There is an ARM based 2600 cart to make games for the 2600 better.

[http://www.atari-forum.com/viewtopic.php?t=28171](http://www.atari- forum.com/viewtopic.php?t=28171)

I think they can buy the ROM and put it on the Harmony cart Sdcard and it will play.

There seems to be new games that can't afford to burn a ROM and ship a cartridge so they use this cart instead to download ROM images to it.

</comment></comment></comment><comment><USER13> DOS is only "real time" if you don't do disk I/O. Disk I/O is synchronous.

There's something to be said for using FreeDOS simply as a loader for a real- time control program. It's not doing anything in the background. There's no networking stack. There's no way to attack it without physical access.

<comment><USER14> Disk I/O being synchronous doesn't disqualify it from being real time. Disk I/O not having a bounded execution time would make it not real time.

<comment><USER15> Filesystem IO through DOS APIs does not have bounded execution time by design (it can even cause user interaction, ie. the infamous "Abort, Retry, Ignore?"). On the other hand the timing is pretty consistent in non-error situations.

Also synchronous (and also often non-preemptible) disk/FS IO was for the long time the only way it was done. For example the reason that on Linux process that got stuck accessing NFS or removable drive that got removed was unkillable (in 'D' state) was to preserve illusion of such semantics to user processes (ie. that IO to filesystem and block devices will never fail with EINTR). And I would not be surprised if many deeply-embedded RTOSes do the same to this day.

</comment></comment></comment><comment><USER16> Amusingly, loading that page takes up 897kB.

<comment><USER17> Medium? More like Extra Large, am I right? Eh? Eh?

</comment></comment><comment><USER18> Great article about using FreeDOS. However, the title is misleading because the article is not really addressing that specific claim.

<comment><USER19> Sure - but I think the title is referencing the fact that 640K is the minimum required for a basic DOS system to run. Using that system you can write code for fun that would by definition fit in 640K.

<comment><USER20> Probably not this. 640k was actually the maximum amount of memory available for a user's DOS applications on an IBM PC or clone. There were many PC's sold that had only 64k of use-accessible RAM. It was only in later years, as memory got cheaper (and apps "ballooned") that machines maxed out at the 640k limit. With the 16-bit system the actual CPU-addressable limit was 1024kb (or 1MB), but the difference was reserved for use by the system for things like the ROM BIOS, graphic adapter bios, etc.

My memory is vague on this, but I believe the core DOS commands (e.g., copy) were part of the ROM BIOS (or maybe they were just always loaded into non- user-accessible RAM as part of boot). So they were always present and did not affect available user RAM. The non-core DOS commands (e.g., xcopy) had to be loaded into user RAM to run. What's more, if you had a diskette-based system (i.e., no hard drive), you would have to load the floppy diskette that had the particular extended DOS command you wanted to run, before you could run it (because it had to be read off the diskette).

<comment><USER15> 640k is not maximum available to applications, but the maximum amount of RAM that would fit into PC, restof the 1MB address space was reserved for ROMs and memory mapped IO.

No dos commands were normally part of ROM. In fact even command.com was designed such that large part of it could be thrown away if additional memory was required and then reloaded from disk when user program terminated (this was implemented by relocating the "transient" part onto the end of usable address space and detecting whether it was overwritten by user programs). Larger DOS file managers usually use similar approach, but simpler: the UI is implemented by separate binary that simply records what the user wants to run somewhere and then exits passing control to small stubbinary that starts requested program and restarts the UI when the program ends.

Edit: MS-DOS 2.0's command.com detects that the transient part was overwritten by means of single byte checksum. The reason why it is done in this somewhat hackish way is that DOS allocates all of the available memory for most MZ EXE programs regardless of how many they actually use (MZ header specifies minimum and maximum amount of unitialized memory needed, with no maximum being the default).

</comment></comment></comment></comment><comment><USER21> The actual 1989 quote by Bill Gates is this:

"I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time. Well, it didn't – it took about only 6 years before people started to see that as a real problem."

</comment><comment><USER11> I recently saw a video of Steve Jobs and Bill Gates at d5, and Gates talked about how you could run Word on the original Mac in a 14K OS. Jobs interjected that MacOS was more like 22K, but the point was made.

Can you imagine an entire OS in 20-something being built today? BIOSes are larger than that.

<comment><USER22> The 4k demoscene people could do a lot with that, but there's few places that really need it. IOT devices, perhaps.

</comment></comment><comment><USER23> If you are looking for a truly minimalist OS for your PC, DOS is for you. I have a warm feeling when I try to imagine an HPC compute node running DOS instead of a fat OS with all the overhead that comes with it. I know, it sounds like a pipe dream, but wouldn't it be nice if there was something like DOS that is natively 64-bit and also supports multiprocessing and multithreading - basically, something that turns a machine into a modern high- performance "calculator", without any unnecessary overhead? I wonder how close one could get to such "ideal" by using Linux or a BSD.

<comment><USER24> One problem in these days is drivers.

There was a glorious period of the DOS days, when:

* all sound cards had a mode compatible with SoundBlaster or at least AdLib cards;

* all Ethernet cards had a mode compatible with NE2000 cards;

* all video cards had EGA/VGA/VESA compatibles modes.

So that defined an informal standard for PC/DOS. Your programs just needed to support these and you could get a working system (even if you didn't have specific driver to use the full power of the specific card).

Nowadays, if you try installing DOS on a current machine, you won't be able to get your games to play sound, nor to connect to your LAN. Video cards still seem to honour VESA standards (however only old ones, with old resolution, there was no VESA update to support modern resolutions), but for how long?

I hit that reality when I tried to install DOS on two machines a few months ago. Then you fetch old Ethernet or sound cards from dusty boxes in the attic and... there is no ISA (or even PCI) slot on your motherboard, damned!

And modern chips have ditched the compatibility layer with older chips :-(

And of course, it has been a while since manufacturer stopped providing DOS drivers for their specific chips.

<comment><USER25> Anyone know how FreeDOS deal with this, if at all?

</comment></comment></comment><comment><USER26> "It's largely attributed to him, though, so he might as well have said it."

This is such a reckless statement, IMO. Sort of like the opposite of "If a tree falls..."

<comment><USER11> It's like politics. If you tell a lie often enough it becomes the truth.

</comment></comment><comment><USER26> Believe Josh Levine's The Island ECN (one of the first trading networks) ran on DOS. He released the source code years ago:

[http://www.josh.com/notes/island-ecn-10th- birthday/](http://www.josh.com/notes/island-ecn-10th-birthday/)

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

</comment><comment><USER27> I'm really surprised that this article is flagged. Yes the title is clickbaity, but the topic itself is interesting and has created some interesting, relevant discussion.

<comment><USER28> When you come across a post you believe is flagged in error, you can contact the mods via the Contact link to have them look into it. On occasion, they remove flags.

</comment></comment><comment><USER29> What a bait and switch. I came to read about the origin of that expression, only to have the author go balls-deep into running FreeDOS, never referencing the original lede.

</comment><comment><USER30> Anyone remember Wing Commander game that required exactly 640K of conventional RAM?

<comment><USER31> I Never played wing commander but I don't think it is possible. With dos 6.22 using DOS=HIGH,UMB and loading everything possible in high memory and removing all the non essential stuff gave you 622k free memory if I remember correctly. I managed to get more only "cheating" using a boot disk from the dos version bundled with windows 95, but even in that case you couldn't get more than 635k of free conventional memory.

<comment><USER32> That's certainly one thing I don't miss about old DOS gaming, having specific boot disks around with the proper config.sys/autoexec.bat magic to make ornery games work -- base RAM, HMA, EMS, XMS etc.. I had to play some game without the mouse, as that cost precious kilobytes…

But yeah, even when you moved drivers to the higher memory areas, there had to be the actual memory manager loaded to do that, so the full 640k wasn't really possible. And despite Origin games like Wing Commander and Ultima basically needing the next generation of PCs not released yet, they didn't really demand the impossible.

<comment><USER24> > _That 's certainly one thing I don't miss about old DOS gaming, having > specific boot disks around with the proper config.sys/autoexec.bat magic to > make ornery games work -- base RAM, HMA, EMS, XMS etc.._

You could make menus items in the config.sys to chose between different options, you did not need several boot disks. I don't remember in which MS DOS version it was introduced (perhaps 5.0?), but that was the normal way to go after that.

<comment><USER31> DOS 6. In dos 5 you could only selectively load stuff in the autoexec.bat, not in the config.sys</comment></comment></comment></comment></comment>


Amazon Is Coaching Cops on How to Obtain Surveillance Footage Without a Warrant - <AUTHOR> https://www.vice.com/en_us/article/43kga3/amazon-is-coaching-cops-on-how-to-obtain-surveillance-footage-without-a-warrant <comment><USER2> Coming from the same company that also listens to your conversations in your house via Alexa? Why do people still trust Amazon? Stop using Ring, and get another non-cloud device. Issue resolved.

<comment><AUTHOR> No, this does not resolve the issue at all. The problem is not that police are accessing Ring footage against the will of the owners, the problem is that Ring users are complicit in constructing a surveillance panopticon that affects _everyone else_ and has no mechanisms for preventing abuse.

Personally forgoing Amazon devices isn't the solution. There must be political action.</comment></comment>


San Francisco Open Source Voting System – Feasability Assessment Report - <AUTHOR> http://sfgov.org/electionscommission/sites/default/files/Documents/meetings/2018/2018-03-21-commission/CCSF%20-%20Open%20Source%20Voting%20System%20-%20Feasibility%20Assessment%20vFINAL.PDF <comment><AUTHOR> See: [https://news.ycombinator.com/item?id=17012000](https://news.ycombinator.com/item?id=17012000)</comment>


Comic Book Heroes Drawn From Real Life - <AUTHOR> http://www.nytimes.com/2010/07/29/fashion/29comics.html?hp <comment><USER2> Surprisingly not about Greg Land.</comment>


Vacation Rental Site Raises $250 Million - <AUTHOR> http://bits.blogs.nytimes.com/2008/11/11/vacation-rental-site-raises-250-million-in-venture-funds/ <comment><AUTHOR> Here on Cape Cod vacation rentals are big money, I wonder how many locals use this service as it's the first I've heard of it. CyberRentals tends to dominate the local market (besides local rental sites)</comment>


Trail of Tears - <AUTHOR> https://www.history.com/topics/native-american-history/trail-of-tears <comment><USER2> and the current people in America often says 'go back foreigners' .. whereas they themselves were the outsiders..leaving the past as mistake the current generation of America should allow talent (who can contribute to society in anyway and not try to create havoc) and should not create rules to restrict based on religion or belief system.</comment>


Mistakes Web Developers Should Avoid When Using JWTs for Authentication - <AUTHOR> https://www.ducktypelabs.com/5-mistakes-web-developers-should-avoid-when-using-jwts-for-authentication/ <comment><AUTHOR> [https://www.reddit.com/r/javascript/comments/fwm8wc/5_mistak...](https://www.reddit.com/r/javascript/comments/fwm8wc/5_mistakes_web_developers_should_avoid_when_using/)</comment>


Learnable Programming by Bret Victor - <AUTHOR> http://worrydream.com/#!/LearnableProgramming <comment><AUTHOR> Previous Discussions:

[https://hn.algolia.com/?query=learnable%20programming&sort=b...](https://hn.algolia.com/?query=learnable%20programming&sort=byPopularity&prefix&page=0&dateRange=all&type=story)</comment>


A hypercane is a hypothetical class of extreme tropical cyclone - <AUTHOR> https://en.wikipedia.org/wiki/Hypercane <comment><USER2> Hypercanes are thought to have played a role in the biggest mass extinction ever, the end-Permian.[1] Back then all the continents had converged into the massive Pangea supercontinent, which was surrounded by an equally massive global ocean. Bear in mind that today's most intense tropical cyclones are the ones in the Pacific, the world's largest ocean. Back during the Permian, the global super ocean would've been an even richer feeding ground for cyclones.

From the article cited below, "there might have turbocharged 'hypercanes' of almost unbelievable intensity assaulting the supercontinent Pangaea—the result of runaway global warming." Also bear in mind that the supercontinent Pangea was assumed to be habitable almost exclusively along its coasts, with an immense desert covering most of its non-coastal land. So if life was mostly concentrated along the coasts and the coasts are constantly getting slammed by hypercanes... yeah, not good.

Certainly lots of things contributed to the Permian extinction. Some have referred to it as the "Murder on the Orient Express" extinction: everything caused it. Pangea, an asteroid impact or two, volcanoes, methane releases from the ocean floor, maybe even a gamma ray burst hit the Earth too. The sheer scale of death seems to imply multiple causes. But regardless of what the primary causes were, the hypercanes part of it always fascinated me.

[1] [https://www.theatlantic.com/science/archive/2017/07/a-road-t...](https://www.theatlantic.com/science/archive/2017/07/a-road- trip-to-the-end-of-the-world/532914/)

<comment><USER3> I thought supermonsoon was much more likely.

Hyercane sounds like sci fi.

<comment><USER4> Hypersharkicane

</comment></comment></comment><comment><USER5> ... As the area of sub-700mb atmospheric pressure slid over the Tetons and down into the Yellowstone Caldera, an enormous weight was lifted. Like a curious bear pushing aside the stone on the lid of a bottomless box swarming with a quadrillion angry bees, a trillion tons of ash exploded into the stratosphere. Within hours, half of humanity lay sprawled under a smothering blanket of doom ...

</comment><comment><USER6> If any of the events required for this incredibly speculative thing to happen occurred we'd probably have bigger things to worry about.

I hypothesize that hypertornados would go along with it, and since we're speculating about things that could be triggered by large asteroid impacts, I imagine there will be hyperquakes, too. We could call the long, cold period after hyperwinter.

This link is stupid.

<comment><USER7> The link is pretty bizarre to me. It can only occur if an enormous region of an ocean is tremendously heated. Short of a Chicxulub-style event in which down falling ejecta massively heats a large region, I don't see how you get there.

Even then, the link requires that the troposphere remains at a relatively normal temperature, which rules out ejecta heating. I just don't see a mechanism.

</comment></comment><comment><USER8> That would be especially nasty. Even if you survive the winds and don't drown in the storm surge, there would be a threat that ordinary hurricanes do not pose: burns.

The ocean temperature necessary to support a hypercane is high enough to cause third degree burns in around 10 minutes and second degree burns in around 20 minutes.

<comment><USER9> I think you misread 120 degrees Fahrenheit as 120 degrees centigrade.

<comment><USER10> Nope, 120F is just under 50C, which is plenty hot. A blissfully hot scalding shower is 110F/43C, and most people can't take a hot tub/spa temperature of more than about 104F/40C.

Anything greater than 98.6F/37C will cause body temperature to rise, and you can't expect to cool off by sweating when the neighborhood is underwater.

</comment></comment></comment><comment><USER11> Curious if a thermonuclear explosion in the sea could kick off something like this. Y'know, because nukes aren't scary enough as they are. How long would the sea temperature need to be at 50C for, and what volume of water? And presumably if you're dropping an h bomb in the sea there's going to be a tsunami as well.

<comment><USER12> You don't have to wonder.

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

<comment><USER11> So the thermonuclear devices detonated near the sea surface were in the ballpark of 10Mt. At least half of the yield (probably more due to reflection) went up into the atmosphere. I'm curious if a more powerful weapon (Russia's Tsar Bomba had a yield of 50Mt, with a theoretical limit of 100Mt), detonated below the sea (so that all/most of the energy heats up water) could achieve a hypercane, or if it's just a drop in the water (pun intended)

</comment></comment></comment><comment><USER13> Hypercanes would be pretty intense; wind speeds of 500 mph would destroy most buildings, and almost all skyscrapers (which are not built to withstand such lateral loads).

<comment><USER14> Almost all skyscrapers? Are there skyscrapers out there that _wouldn 't_ be leveled by a 500mph wind!?

<comment><USER15> 300 mph tornados tear up everything except some roadways, foundations and deeply-driven steel pilings. 500 mph would just make a messier mess. If that were multiplied over continental size, that would definitely extinct some species.</comment></comment></comment>


Apple's operating systems mistreat or harm the user - <AUTHOR> https://www.gnu.org/proprietary/malware-apple.html <comment><USER2> It's a bit weird to me that an org that's been around for as long as GNU has such a black-and-white view of the software security/privacy/ownership landscape, when real life is a fair bit more nuanced.

Yeah, Apple and their ecosystem aren't saints, and their position on right-to- repair policies is reprehensible, but neither is Android, which runs on a Linux kernel, and from a privacy perspective, reasonable people could argue that Apple's doing a better job than Google is with Android.

GNU unfortunately doesn't see the other dimension here -- usability. There's basically nothing that's come out of GNU in recent memory that's been competitive in terms of usability and mass-market appeal (discounting coreutils, which are the de-facto usability standard for loads of command-line UIs, but their mass market are developers, sysadmins, and power users).

As long as GNU keeps preaching this kind of absolutist position where the downsides of corporate-owned software ecosystems exist in a vacuum, they'll come off as doomsayers to many observers.

Having said all that, DRM does suck and I believe their position there is fully justified.

<comment><USER3> > ...but neither is Android, which runs on a Linux kernel

The same goes for Ubuntu which runs Amazon Ads and sends usage statistics by default.

> As long as GNU keeps preaching this kind of absolutist position where the > downsides of corporate-owned software ecosystems exist in a vacuum, they'll > come off as doomsayers to many observers.

The FSF was absolutely spot on of raising privacy issues and that has forced a privacy overhaul throughout the entire tech industry. However it is still a shame at how they still cannot convince users to stop using non-free OSes or applications since they don't understand that most end users aren't willing to put the effort into migrating to another platform or to sacrifice convenience over freedom.

The only audience that seems to get the message are software engineers but not the average Joe or Jenny.

<comment><USER2> I've been developing software for the better part of a decade (granted, not the most senior developer around, but still) -- their message comes off as unreasonable to me, if only because it revolves around heavily criticising the state of the industry without offering a clear alternative for anyone.

I say this as a former full-time user of a pretty huge chunk of their software offering, from emacs, to GCC, to screen -- over the years, I realised that many of their APIs or feature sets aren't modern, and better alternatives exist.

<comment> compiler-guy The "clear alternative" that they offer is unusable for the masses, arcane even for the tech-literate, and almost completely unresourced for improvement, with no viable plan to make it so.

I love FSF's products, contribute to them frequently, and use them every day for my job. But it is laughable to even dream that the alternative they present would be better for the average user, for almost any definition of "better" other than the most restricted FSF definition regarding no-compromise of any sort of "better freedom".

Would I love it if there were more free, "better" alternatives to Apple, Microsoft and Google? You betcha. But there isn't one, and there is no viable path to one, and hasn't been since Stallman first rode out of the desert.

</comment></comment></comment></comment><comment><USER4> It's from the FSF, so I expect my eyeballs to start rolling involuntarily. They do have a few good points that are consistent with their principles, but they dilute their message with disprovable claims. Like this one:

> In MacOS and iOS, the procedure for converting images from the Photos format > to a free format is so tedious and time-consuming that users just give up if > they have a lot of them.

First, there is no "Photos" format. The Photos apps are just catalog viewers. On macOS, the original files are easily accessible on disk organized inside the .photoslibrary file.

There are a few proprietary aspects:

\- As of iOS 11, iPhones will store photos using the patent-encumbered HEVC codec. This can be disabled.

\- Live Photos are undocumented but nothing special: a still frame bundled with a short video. (The video likely uses proprietary codecs.)

\- Adjustments to images are nondestructive and stored separately from the file, in an opaque way.

Exporting a photo to a free format is trivial. The system usually does it automatically whenever you share the photo. Otherwise, it's literally just File > Export or even dragging to another app.

\---

This is also rich, coming from the FSF:

> "Dark patterns" are user interfaces designed to mislead users, or make > option settings hard to find. This allows a company such as Apple to say, > "We allow users to turn this off" while ensuring that few will understand > how to actually turn it off.

Yes, because open source software is widely celebrated for the ease with which the everyday user can figure out how to change settings or modify source code.

(I agree Apple buried the ad tracking setting in a counter-intuitive place. But it's now in the top-level Privacy settings, where it belongs.)

<comment><USER5> I think this isn't meant to be about ease of use but about controls that are actually misleading. E.g. the thing that turning off the WiFi in the control center in recent version of iOS does not really turn off the WiFi, it just disconnects it (because users might forget to turn it back on).

</comment></comment><comment><USER6> The second sentence is "This does not include accidental errors" but then an accidental error and a bunch of third-party program are cited as primary examples. Things are cited multiple times - the recent "battery DRM" news, App Store censorship, and remote wiping. How is it Apple's fault if someone writes and distributes malware for their system outside the App Store?

I agree with the premise, but this article is a little bit of a mess. Things like this don't help convince people. Were it shorter and more cleaned up, and devoid of things like "cr...app store" it might actually help people realize the importance of Free Software.

<comment><USER7> I'm pretty much 100% on board with GNU, FSF, etc, but I absolutely despise the "crapp store" stuff. Once in a while, fine, but almost every talk, article and software title has some kind of jab like that. "GNU" itself is an example. It's very childish and I think it's RMSs fault for setting the precedence from the beginning and doing it so much since. I wish he'd stop doing it and start actively discouraging it.

</comment></comment><comment><USER8> I really hate this list. Not because I hate GNU (I don't), per se, but because it's childish, mostly misleading, and at times outright dishonest or factually incorrect. I'm not in the mood to go through this one, but if I've done a line-by-line comparison of a similar list: [https://news.ycombinator.com/item?id=18515395](https://news.ycombinator.com/item?id=18515395). The GNU should be ashamed to have this on their website and replace it with a coherent argument against Apple, which is really not that hard to write if you put a little bit of effort into it.

</comment><comment><USER9> After nearly two decades of FOSS advocacy I've come to the conclusion that most consumers (a) already know about their gardens' walls, and (b) actually _prefer_ it that way.

The view that freedom is always preferable over, say, the sense of security that folks get from having an avuncular corporation ensure that the tools in their lives have a limited range of use -- that someone is literally managing the possibilities of their personal devices, pruning them of (supposedly) dangerous apps and ensuring that they are within certain expectations, is a great comfort to people who are already used to their lives being managed in precisely this way by any number of powerful actors.

Stuff like this from the FSF makes me think they just don't understand the user. The user is typically is not an engineer. The customer is not interested in the responsibility that comes with that kind of power, and would pay good money to trade it off for predictability. And the success of nerfed, general- computing-incapable devices is market validation of this hypothesis.

I'm uncomfortable with this facet of human nature too, and it runs contrary to the prevailing narrative of our industry and even of the Enlightenment itself, but until we accept that many folks just want to be taken care of, we will keep being surprised.

Customer obsession means appreciating all the data, not just the data that is comfortable to behold.

</comment><comment><USER10> Unfortunately, most non-techie users _like_ having their freedom taken away in exchange for [security, ease of use, etc.].

There are a few things on the list universally hated, though, such as pervasive DRM (even non-techies hate lack of repairability and lack of compatibility with non-Apple branded peripherals).

At any rate, I hated the feeling of being locked into a walled ecosystem that was hard to escape from, so I never bought another Apple product after the iPhone 4S.

<comment><USER11> I'm not a developer, but am pretty technical. I've written some code, some scripts, etc. I use apple stuff specifically because I want the tradeoff of usability instead of pure openness. To me, computers are just like any tool - sure, I can build a bench grinder with off the shelf parts and make only the tradeoffs I want to make, or I can go to home depot and buy a complete engineered package for 1/10 the cost, and take they tradeoffs that delta wanted to make. same with any machine. If you want to buy the tools and build software yourself, you sure can. but it has always been mysterious why software should somehow obey totally different laws. its all just tools.

<comment><USER10> Well in this case it would be like if you went to home depot and bought a new saw.

But the saw needs to be connected to the internet all the time for it to work, and ToolCorp can remotely disable your saw if they detect you are using it to cut something other than wood, and ToolCorp will only let you buy ToolCorp brand blades, even though CompetitorCorp makes high quality cheaper blades that have the same shape. Furthermore, your new saw has a computer that can be used to program it to cut different patterns, but all patterns must be approved by ToolCorp and indeed they can remotely go in and delete unauthorized patterns if they want to (remember, your saw needs to be connected to the internet all the time). Also, you'll probably need a "ToolCorp Hardwood Premium" monthly subscription if you want to use hardwood cutting features.

The complaint here isn't that Apple is making tools. It's that they are making tools that act in the interests of its creators more than in the interests of its users.

You wouldn't buy a hammer from home depot that failed to work if your interests didn't align with HammerCorp's interests, would you?

</comment></comment></comment><comment><USER12> Editorial title much? "Apple's Operating Systems Are Malware" is the actual (click-bait BS) title. Very similar to the other BS GNU article: "Google's Software is Malware" [0]. Interesting OP only submitted the Apple one with a different title...

[0] [https://www.gnu.org/proprietary/malware- google.html](https://www.gnu.org/proprietary/malware-google.html)

</comment><comment><USER4> See also Steve Job's essay on iTunes DRM from 2007, "Thoughts on Music":

[https://web.archive.org/web/20080107121341/http://www.apple....](https://web.archive.org/web/20080107121341/http://www.apple.com/hotnews/thoughtsonmusic/)

<comment><USER8> FWIW, iTunes now sells DRM free music. It seems like the third option that Jobs suggested prevailed.

</comment></comment><comment><USER13> > In MacOS and iOS, the procedure for converting images from the Photos format > to a free format is so tedious and time-consuming that users just give up if > they have a lot of them.

I select one or more photos in the Photos application on my Mac, and drag them to a folder window in Finder. That exports them as JPEGs.

</comment><comment><USER14> > MacOS High Sierra forcibly reformats SSD boot drives, and changes the file > system from HFS+ to APFS, which cannot be accessed from GNU/Linux, Windows > or even older versions of MacOS.

It is important to be accurate.

You can access APFS from Windows or Linux at at least Paragon APFS for Windows, and Paragon APFS for Linux. There is also an experimental AFFS FUSE driver.

This can actually be important in case of forensics.

[1] [https://www.paragon-software.com/home/apfs- windows/#](https://www.paragon-software.com/home/apfs-windows/#)

<comment><USER15> Worth noting the hfsplus driver in Linux can only mount as read-only, unless you manually mount it with the flag to force it to ignore the journal... which is a silly idea when journaling is what makes modern filesystems so resilient. apfs-fuse is actually in a more promising position than hfsplus, as it supports mounting any volume in the APFS partition, FileVault encrypted volumes, and Fusion Drive volumes. Granted no distro is shipping apfs-fuse that I know of. They probably could at this point as it is read-only.

[https://github.com/sgan81/apfs-fuse](https://github.com/sgan81/apfs-fuse)

<comment><USER14> Paragon also sell a proprietary HFS+ driver for Linux which AFAIK r/w. For forensics, r/o is enough though.

</comment></comment></comment><comment><USER16> Following the same thinking we can say that browsers are malware as well due the DRM. The user has no idea what data is shared with the DRM vendor nor any control to filter it out.

</comment><comment><USER17> What's next? Android is spyware?

<comment><USER18> Indeed:

[https://www.gnu.org/proprietary/malware- google.html](https://www.gnu.org/proprietary/malware-google.html)

</comment></comment><comment><USER19> Why is Apple being dinged as writing Malware for something Dropbox wrote?

<comment><USER20> Dropbox exploited mechanisms Apple created for accessibility, so would it be fair to say GNU is failing Apple for making their operating system accessible? That seems to be what GNU is doing by including this bullet, but I think they might object to that characterization.

</comment></comment><comment><USER21> When was this published? Bit behind the times since we're on IOS 12 with 13 coming out soon.

Not saying they're wrong exactly, but the argument would be stronger if they kept up with the times.

</comment><comment><USER18> I fear the inflammatory headline is going to put most people on the defensive instead of listening to the very valid points that most of these lists are.

<comment><USER2> Fully agree. They're valid points, but the editorial/tabloid writing style makes it sound less like a constructive, educated discussion and more like name calling à la Westboro Baptist Church (at the risk of sounding reductionist).

</comment></comment><comment><USER22> GNU's Not Unbiased

<comment><USER8> I don't think they've ever claimed to be. They're clearly biased towards systems build using free software.

</comment></comment><comment><USER23> Click bait: Why not just say "we don't approve of proprietary operating systems" and leave it at that?

<comment><USER24> Wouldn't that followed by a "Why?"

</comment></comment><comment><USER25> This was flagged for a while. How strange.

<comment><USER8> As it should have been, I'd argue. This is a low-quality flamebait submission that I feel has no place on Hacker News.

</comment></comment><comment><USER26> _TL;DR_ basically any software not from the GNU project is malware, in case you haven't heard already.

<comment><USER27> Replicant is endorsed by the FSF. It has no GNU software in it whatsoever and almost all code comes from google. Try again.

<comment><USER26> The point is that the original text was such an over-the-top and just plain logically off-base rant so as to not be worth reading past a line or two.

So whether it's about software coming from GNU or FSF (or something endorsed by Google) doesn't really matter, in this context.

</comment></comment></comment><comment><USER28> Strange, I never feel more abused than when I have to use GNU.</comment>