So you mean you could take your FreeBSD Jails configuration, upload it on a well known public website like dockerhub, then get someone on Windows or Mac transparently install the image and run it with a few cmdlines ?
Because docker container are called container for this reason. That comes from the boat container analogy.
Many years before Linux containers, FreeBSD jails were easily packaged up via tar, deployed via scp, and started with minimal script. There wasn't much hype, it just worked. It was an excellent software packaging and distribution tool.
There wasn't a hub that I recall, nor was there tooling to use VMs so they could run on Windows/Mac. However, the main challenge, being able to distribute an "image" without requiring VM overhead, was solved elegantly. It just wasn't Linux, so it didn't make news.
Running Docker on non-Linux platforms requires a Linux VM to run in the background. It's not as cross platform as people make out. The other container technologies can be managed via code too, that code can be shared to public sites. And you can run those containers in a VM too, if you'd want.
What's more, with ZFS you could not only ship the container as code, but even the container as a binary snapshot, very much like Docker's push/pull but predating Docker. Even on Linux, for a long time before Docker, you could ship container snapshots as tarballs.
Also worth mentioning is that early versions of Proxmox even had (and likely still does) a friendly GUI to select which image you wanted to download, thus making even the task of image selection user friendly. This was more than 10 years ago, long before Docker's first release and something Docker Desktop still doesn't even have to this day.
> Because docker container are called container for this reason. That comes from the boat container analogy.
The term computer "container" predates Docker by a great many years. Containers were in widespread use on other UNIXes with Linux being late to the game. It was one of the reasons I preferred to run FreeBSD or Solaris on production in the 00s despite Linux being my desktop OS of choice. Even when Linux finally caught with containerisation, Docker was still a latecomer to Linux.
Furthermore, for a long time Docker wasn't even containers (still isn't strictly that now but it at least offers more in the way of process segregation than the original implementations did). Albeit this was a limitation of the mainline Linux kernel so I don't blame Docker for that. Whereas FreeBSD Jails and Solaris Zones offered much more separation, even at a network level.
If we are being picky about the term "container" (not something I normally like to do) then Docker is the least "container"-like of all containerisation technologies available. But honestly, I don't like to get hung up on jargon because it helps no-one. I only raise this because you credited the term to Docker.
---
Now to be clear, I don't hate Docker. It may have it's flaws but there are aspects of it I do also really like; and thus I do use it regularly on my Linux hosts these days despite my original reluctance to move away from Jails (Jails is still much nicer if you need to do anything complicated with networking, but Docker is "good enough" for most cases). However what I really dislike is this rewriting of history where people seem to think Docker stood out as a better designed technology - either from a UX or engineering perspective.
I personally think what made Docker successful was being in the right place at the right time. Linux was already a popular platform, containers were beginning to become widely known outside of the sysadmin circles but Linux (at that time) still sucked for containerisation. So it got enough hype early on to generate the snowball effect that saw it become dominant. But lets also not forget just how unstable it was, for a long time it was frequently plagued with regression bugs from one release to another. Which caused a great many sysadmins to groan whenever a new release landed.
(sorry for the edits, the original post was a flow of thoughts without much consideration to readability. Hopefully I've tidied it up)
If anything this is testament to the failure of previous solutions to popularize it.
Docker invented absolutely zero on the OS side and reused what LXC did but the invention here is not "putting things in containers" but "making it easy to put things in containers" and "making it easy to run those containers. Every solution before that required a bunch more knowledge.
> Running Docker on non-Linux platforms requires a Linux VM to run in the background. It's not as cross platform as people make out.
Which people ? I never seen anyone saying Docker makes it easy to run cross platform stuff, and it was always one of it's pain points.
> If anything this is testament to the failure of previous solutions to popularize it.
Maybe. But I'd rather not argue about popularity in a conversation about technical merit. The two aren't mutually inclusive and popularity is a subjective quality. Nothing good ever comes from conversations about popularity and preference.
> Every solution before that required a bunch more knowledge.
I'm not sure I fully agree with that. Docker has a lot of bespoke knowledge whereas the previous solutions built on top of existing knowledge. Where they differed was that Docker was an easier learning curve for people with previously zero existing systems knowledge. Which is something I didn't really appreciate until reading these responses because (possibly because I'm an old timer developer. I want to understand how my code works at a systems level so made it my job to understand the OS and even hardware too - though that's gotten harder as tech has progressed. But that was expected of developers when I started out).
> Which people ? I never seen anyone saying Docker makes it easy to run cross platform stuff, and it was always one of it's pain points.
The comment I replied to said: "get someone on Windows or Mac transparently install the image and run it with a few cmdlines"
>> If anything this is testament to the failure of previous solutions to popularize it.
>Maybe. But I'd rather not argue about popularity in a conversation about technical merit. The two aren't mutually inclusive and popularity is a subjective quality. Nothing good ever comes from conversations about popularity and preference.
The popularity is directly related to technical merit of it being very easy to start, both to run and to create containers. It isn't "just" popular, it got popular because it was solution to the problem that near-zero infrastructure skill developer could apply. We have countless example of solutions winning almost purely on having low barrier to entry, and docker was just that for containers.
The previous solutions ignored that, and assumed the target audience is mildly competent sysadmin, not a developer that has no idea what UID is, let alone the rest of ops stuff.
And it got buy in on the other side of the fence too, as now sysadmin instead of installing a spider's net of PHP or Ruby deps just had to install docker and deploy a container.
>> Every solution before that required a bunch more knowledge.
> I'm not sure I fully agree with that. Docker has a lot of bespoke knowledge whereas the previous solutions built on top of existing knowledge. Where they differed was that Docker was an easier learning curve for people with previously zero existing systems knowledge.
Well, you got the point. At the point where you need that knowledge (and I'd argue debugging docker container is in every way harder than just having a process in system) you already bought into the ecosystem. There is no initial hurdle to go thru like there was with previous systems trying to do same thing, even if you end up with harder to debug end result.
Just like with other things, PHP got popular because it was easier than anything CGI related, "just write code inside your HTML", Ruby got popular off Rails and 15 minute blog engine demo, Python being just all around easy to learn.
> The previous solutions ignored that, and assumed the target audience is mildly competent sysadmin, not a developer that has no idea what UID is, let alone the rest of ops stuff.
But that doesn't mean that the previous solutions weren't popular for others outside of the developer community. The comments here are heavily developer orientated but that's only part of the story in terms of the wider container ecosystem.
> Just like with other things, PHP got popular because it was easier than anything CGI related, "just write code inside your HTML", Ruby got popular off Rails and 15 minute blog engine demo, Python being just all around easy to learn.
The point I was making wasn't that "Docker doesn't deserve popularity" nor any confusion as to why it's popular. It was saying that the stuff that came before it was also easy.
Your example about languages here is a apt because PHP is an easier language for people from a zero coding background. But if your background is in C then PHP is going to be much harder to use compared to learning Nim, Zig or Rust.
Saying the containerisation solutions that came before were garbage, as people have done, isn't accurate. I'm not being critical of Docker; I'm defending the elegance of Jails. It's just that elegance is exposed in a different way and for a different audience to who Docker targets.
i think a lot of previous solutions focused on the "5x" engineer that was willing to comb through manpages and dig through the source (or at least the Makefile) if something unexpected happened.
many, many, MANY engineers are not like that.
many just want to build and push their features, and that's fine.
Docker knew that LXC was onto something and focused on the latter audience; that combined with their VC funding after they hit a critical mass is why they are heralded as having "invented" containers (even though they didn't).
and what I really dislike is dissing a technology because piece of it had existed in other forms before.
yes, zones on solaris offered a lot of the modern SDN networking stuff. was it popular? no.
yes, with zfs, in theory, you could ship a binary file and the other side can load it nicely (if you're thinking send/recv). was it popular to ship things like that in the open, public, in an easy to use fashion? no.
just admit docker popularized a lot of these and let's move along. while the tech might have existed, the previous ecosystems sucked and docker changed this for good.
> and what I really dislike is dissing a technology because piece of it had existed in other forms before.
How am I "dissing" Docker here? The comments before me are saying other technologies weren't easy or as feature rich. I'm saying they were. That's not a criticism of Docker. It's just a fact about other technologies.
> yes, zones on solaris offered a lot of the modern SDN networking stuff. was it popular? no.
Popularity means jack shit about the quality of a product. Reddit, Twitter and Facebook are popular but the UX is appalling on each of them. Just as plenty of really well built technologies never gain traction.
I suspect the reason Zones wasn't popular was because Solaris wasn't popular. Had Zones or Jails existed in the Linux mainline kernel at the same time as they had in Solaris/FreeBSD then we might not have seen a need for Docker. Or maybe it might still be around and popular...who knows? It's pointless to speculate over why something is popular because it's unscientific and unprovable. But we can discuss the UX and capabilities.
> yes, with zfs, in theory, you could ship a binary file and the other side can load it nicely (if you're thinking send/recv). was it popular to ship things like that in the open, public, in an easy to use fashion? no.
I can't speak for others did or did not, but I certainly did. (also see my comment above regarding popularity).
> just admit docker popularized a lot of these and let's move along.
I wasn't arguing that Docker didn't popularise these things. I was arguing against the point that the other tools were sub-par.
> while the tech might have existed, the previous ecosystems sucked and docker changed this for good.
And here's the crux of problem: you're conflating popularity with technical excellence. They're two unrelated metrics.
Just for clarification, because zoltan isn't making very compelling arguments.
Docker made containers easy and effective. Solaris zones were not as good as Docker is, BSD jails are/were not as good or easy to use as Docker is. Popularity has nothing to do with it, except that the popularity is an indication of the fact that Docker was revolutionary in the way it made these technologies accessible to a very large professional audience.
Docker was not created in isolation, it was inspired by jails and zones and all the fancy new features that were added to the linux kernel at the time.
Using just the words FROM, ADD and CMD, you can make a container definition that effectively isolates a runtime for just about any application in a 3 lines. Beyond the couple simple keywords all you need to have is absolutely basic linux knowledge, the level you can teach any developer in an afternoon.
There's no need to pollute that developers mind with any other system administration garbage. Nothing about networking, policies, filesystems, whatever. Just basic bash and a couple keywords.
Then when you want to go to production, you just hand the shit your developers wrote over to a professional system administrator and they'll make it run perfect at any scale. It's magic. Before Docker the world was darkness and bullshit, and after Docker the world was drenched in light and all that is good.
The fact that it's 2022 and there's still people that are going "hur-dur Solaris zones, BSD jails amiright" as if any of those technologies have any relevance is ridiculous.
> The fact that it's 2022 and there's still people that are going "hur-dur Solaris zones, BSD jails amiright" as if any of those technologies have any relevance is ridiculous.
Having diversity in the computing ecosystem is a good thing, not bad.
I'll take your point that Docker brought containers to the developers (frankly, I made that point myself) but that doesn't mean that Jails doesn't solve some problems that Docker (currently) struggles with. Nor does Docker's success mean that a little competition isn't healthy for the wider industry.
Dismissing the stuff that went before it as "systems administration garbage" because it was targeted at a different audience to yourself is a really poor attitude in my opinion. Especially when there are countless examples of when audiences different from developers also need to make use of software. Frankly, I thought by now we were past the sysadmin vs developer flamewars. But clearly not.
Aside from that minor rant, I do want to thank for your post. It was an informative read.
My apologies, I meant relevance to the problem that Docker solves, which is enabling developers to neatly specify and package their dependencies. I am not trying to diminish jails and zones usefulness to system administrators. I'm just saying if you put Docker in a comparison list to other technologies, jails and zones wouldn't even be in that list.
The annoyance comes from system administrators looking at the set of technologies inside Docker and saying "we already have that", and then just assuming Docker must be some sort of marketing scheme. I deployed docker in my organisation within a week of its first (beta?) release, when all of its "marketing" was a single blog post.
Docker solved an enormous real problem in the software industry, even if from a system administrators perspective it's just a new way of packaging applications, as there have been many in the past and probably will be many in the future.
Oh I never meant any of my comments to undermine Docker. While I do have some specific frustrations with Docker, the same is true with any technology stack: Jails and Zones included.
I'd never describe Docker as being a marketing gimmick. It was definitely a "right time, right place" tool. But that speaks more about how the market (and particularly Linux) was yearning for something better.
Docker is the best because it did something its predecessors could not: made it accessible, easy to run and easy to share. On Linux. Now the technology has industry standardization and so much inertia it’s surviving the monetization drive by docker (the company). The existing software out there was sysadmin stuff because it was mostly DIY. Or required learning to administer and build tooling for another OS.
It's worth noting that Docker was primarily a godsend for people working in scripting languages like Ruby or Python, where they have very messy packaging systems, depend on tons of native Linux libraries and so on.
For people working on the JVM the world was in some sense already 'drenched in light'. You could just send the sysadmin a fat jar you developed on Windows or macOS and tell them to deploy it, done. Or maybe you'd use an app server, so you'd send a less fat jar and they'd deploy it via a GUI and it already gets high level services like db connections, backups, message queues etc.
Also, Docker doesn't really solve the common case of an app that depends on a DB, maybe email etc. Those are services that need administration, you can't just start up a random server and expect things to go well. At least you need backups, proper access control and so on.
So deployment difficulty was very much dependent on what ecosystem you were in.
That's certainly true and describes my circumstances at the time. But it's also good to note that it is great for C/C++ dependencies as well, our GIS applications require PROJ, and our machine learning projects various Nvidia cuda things.
Also, just last week I needed new smbd features, and the only way to deploy a recent smbd version whilst retaining sanity seems on Ubuntu seems to be to just use docker. Normally there's a PPA but there wasn't in this case for some reason.
popularity has won every single time in history over technical excellence. I know this is HN and a techbro echo chamber, but technical excellence is not even in the top 3 that people care about.
> Running Docker on non-Linux platforms requires a Linux VM to run in the background. It's not as cross platform as people make out. The other container technologies can be managed via code too, that code can be shared to public sites. And you can run those containers in a VM too, if you'd want.
right, and this is something else that Docker made incredibly easy to do as well. It's almost transparent now; so much so, that you need to use nsenter to connect to the underlying VM on Mac and Windows.
And yet, most people don't know google own Waze, Youtube, Gmail, Android, Chrome, Chromecast and so on.
They also don't realize most sites use Google Analytics, meaning your activity on a site completely unrelated to google is still recorded.
They don't realize that Meta own not just Facebook, but also Instagram, WhatsApp or Oculus.
They also don't realize all sites that use "share with facebook" send date to facebook, meaning your activity on a site completely unrelated to FB is still recorded.
We know that on HN, but ask somebody in the street, they barely know what a URL is, how would they understand a monopoly?
Anecdotal, but the non-techies on my personal circle are, on average, more critical of Google and Facebook than techies are. And they understand that those are monopolies on a very visceral level - because it's so hard to escape from them as a casual user.
Agreed, but the part where we discourage similar act is very related to the prison time she will do. Anything else will not discourage other people to scam, because worst case scenario you just loose reputation and money, but best case scenario you are a billionaire.
Given how bad those scams are for society, it's the discouraging is very important, and a strong message should be sent.
How many people do you think harsher sentences would make a deterrent difference for?
The number of tech CEOs is small. Of those, what percent do you think would be ok With fraud if it were only 18 months years in prison? What is the change if it were >18 months?
Are any choices being changed at all?
I think it is basic misunderstanding of the human mind.
One mistake a lot of people make while writing code, slides, essays and so on, is trying to structure the ideas too soon in the process.
Throwing ideas on a paper in no particular order and in a few words will exercise the least possible the part of you that expresses idea, and keep the one that generate ideas in focus. Then after you have exhausted the muse, you can start ordering them, chaining them, then putting full sentences, sections, or code blocks, functions and classes.
So the other should be, generate as many ideas as possible, then express them, structure them, put them in shape. Then generate ideas again. Then structure again. But not at the same time.
Because expressing things needs a structure, while creativity thrive without it.
This drove me nuts when I was writing my master thesis. Professor handling it insisted on writing the outline first and then, in order (!), each of the chapters.
I found that approach problematic, at least for me. How was I supposed to know from the get-go what problems I'll stumble upon, what the conclusions will be, what pivots I'll make. So I just ignored that and started out in the middle, wrote what I knew when I knew it, and then progressed outward to more general, summary chapters. Turned out ok and I think with a lot less rewriting had I listened to her advice.
Because Python has a long experience with REPL, the experience ends up being awesome.
If you try iPython + a PYTHONSTARTUP script, it will be very hard to use anything else.
And ipdb is a very good example of using a debugger that fully benefit from that.
So it is entirely possible to have an exceptionnally good experience in a Python REPL, despite the significant whitespaces, but it does depend of the implementation.
Creating the giga factories and making space x a success were as much a technical success as a human success. At this scale in the game, everything is.
We can be critical of his actions, but at this point, assuming incompetence is foolish.
No, it's not. Essentializing incompetence, implying that he's incompetent at everything, that's foolish. But the supposition that he's incapable of being incompetent at Twitter because of his successes elsewhere has already been disproven.
It's possibly not that foolish depending on how hard you believe the Peter Principle applies to billionaires. Musk didn't start Tesla, he swooped in and meddled exactly like Twitter, because he had extra money and wanted to swing it around. Is picking a good bet, one that survives your meddling, a skill or just luck? It's possible to believe the Peter Principle applies and it was entirely luck.
He came in years before the first car was shipped and, like, 15? years before they got to sustained profitability with their third-gen cars.
I'm not trying to dickride the guy, obviously a lot of people contributed, but this literally just happened and we all saw it. How are people rewriting it successfully?
Most of Tesla's current profitability is still in carbon credits trading with other manufacturers. Their own manufacturing is still not stably profitable. Where it is profitable it in part relies on continuing sales of a feature that has yet to be delivered (and may not be ever delivered).
Tesla has done a great job to shake up a complacent status quo of car manufacturers, and to especially lead the curve of EV adoption in the US. That's not nothing, yes, and is absolutely a team effort. It's also not the best run business model and there's a lot of questions still about the long-term sustainability in their cost cutting and their over-reliance on credits and promised but not delivered features. If we want to credit Elon as the sole "business guru" and the company is relying on business models that are less than stellar, it's fair to criticize Elon's role in Tesla with respect to their ongoing business model issues.
There have been times where Tesla's stock, to generate additional liquidity, has had SEC violations alleged against it and most of those were directly "great business man" Elon Musk posting SEC violations directly to social media and pretending they were honest mistakes (and having enough reasonable doubt to not get the "Martha Stewart treatment").
I don't think there's "rewriting". There's 15 years of questionable business practices that was criticized at the time, yet seem easy to sweep under the rug now that Tesla looks popular and is a darling of certain investors.
I don't care how instrumental he was to Tesla, because it doesn't have anything to do with how successful he'll be with his stated plans for Twitter, a company he desperately tried to avoid acquiring but was forced by his own mistakes.
The "gigafactory" in Nevada—built, owned, and operated by Panasonic—is similar in size to other Panasonic battery factories in Japan and around the world.
I disagree. I think that the assumption of incompetence makes sense if you're also assuming that a tech company like twitter is different enough from a tech company (hardware focused) like tesla or space x, that the same operating principles apply.
Intelligence comes in a lot of ways - clearly Elon Musk is incredibly intelligent, but only in some ways and not in every way.
Trying to play devils advocate here, I don't fully believe that Musk will be incompetent in handling Twitter, but I definitely think given the current evidence it's possible his understanding of how to operate Twitter is less comprehensive than how to operate a hardware driven tech company.
You made the right choice, rst is not user friendly, even for tech savvy people.
I'll take the opportunity to do a shameless plug for the amazing "Markedly Structured Text", or MyST, a markdown flavor that is both easy to write like markdown, and expressive like rst.
Basically, if you know markdown, you can write decent MyST already. In fact, any markdown is valid MyST and .md is a valid file extension for MyST.
Once you want more, the syntax offers richer construct, but still easy enough to use.
I wanted to love asciidoc because the format rocks, but it never took off and the tooling is still lacking. MyST piggy back on markdown ecosystem, this is less of a problem.
Also, the devs behind it also have a very good track record at creating a good FOSS ecosystem.
The “one more backtick” syntax is a very early Markdown feature explicitly mentioned by John Gruber (originally only for inline code, of course). It might even be in the original “spec”, I don’t remember, but it dates way back and is implemented by virtually all half-decent Markdown parsers. It’s one of the least utilised feature, however, so huge kudos for MyST to clearly explain it and raise awareness.
