Show HN: Terrastruct – A Diagramming Tool for Systems - <AUTHOR> https://terrastruct.com/ <comment><USER3> Can I nitpick two things about the website? I don't mean to be an asshole about it or anything, I just hope it can help in some way:

\- I think the mobile detection thing uses nothing but window size to determine if this is on a mobile browser or a desktop, so it mistakes my (definitely desktop) browser window for a mobile one. I know from my friends who do frontend stuff that reliably detecting a mobile browser isn't very straightforward (or even possible?) but perhaps a "my device was not correctly detected, request desktop site" button would help? Or at least a hint about resizing the browser window for technical users who are, nonetheless, not very web-inclined?

\- The plural of "scenario" is "scenarios", without an apostrophe. Also frames, not frame's. Sorry if it seems overly pedantic but I see a lot of people (including native speakers) do this and it's driving me nuts.

Other than that I think like the idea! Me and web interfaces don't really get along so I can't say I've done too much test driving but I realize that's a personal preference of mine, and quite possibly something that puts me outside your target audience. I don't suppose there's yet a good web equivalent of Visio, and I'm fairly sure that the ones I've tried don't have the hierarchical/structured approach to diagramming that Terrastruct has. Best of luck with it -- I hope ten years from now I can tell my friends I went all grammar nazi on alixanderwang, world-renowned billionaire and the founder of Terrastruct!

<comment><AUTHOR> I'm curious, do you (or anyone else) even have an interest in creating diagrams on mobile? It's never crossed my mind as a conducive platform for creating diagram because of the small screen size. I've thought about viewing diagrams in mobile, but again I'm unsure of the desire from other people to do so. (It isn't too hard to get this working as a viewing platform for mobile)

<comment><USER4> I experimented with it on my iPad, and came away frustrated. I definitely like to use my iPad when practical.

<comment><USER5> Same and diagramming seems like something that a tablet touch interface should be good at. I just use the omnigraffle app though so it's unlikely I'd bother with a webapp tool.

</comment></comment></comment></comment><comment><AUTHOR> Hi HN, I made a diagramming tool specifically for explaining systems. It's something that I felt like I could've needed at my previous engineering jobs when I was explaining some software architecture or concept that were complex and I had trouble expressing on a single image diagram. Would love to hear HN's thoughts and feedback!

<comment><USER6> I've often needed something like this, but, sadly, once again, this isn't it.

No discredit to you; this is great work, but for me, personally: The world does not need more diagram editors.

Diagrams are fundamentally not the right tool for the problem I have.

The problem I have is that I have a technical system, for example, a network diagram, or an architecture diagram of a system or set of systems; and I need the _data_ that represents that system, to be _visualised_ in multiple diagrams, in such a way that you can have multiple _views_ of the _same data_.

This means that when you make a change to the _data_ , _all of the diagrams_ are updated to reflect that change.

As an analogy to explain what I mean, consider a 3D model:

If you have a 3D model, you want to save it as a 3D model.

What you don't want, is to manually draw the way that model looks from 5 different perspectives; because if you alter the model, to say, add a new cube, or change the color of a face; you have to redraw _every single diagram_.

What would be actually novel, would be to allow you tag / label / whatever the components of your diagrams in some way, and they apply filters to the diagram to generate different views of the data, while maintaining one single master diagram.

I know, this is a hard problem, because layouts are fundamentally hard (if you've ever worked on layout engines you'll know exactly what I mean), and you end up looking like graphviz as soon as you try to use constraint solving to layout the elements in a diagram... I guess.

...but, at least it would be genuinely novel to try.

I don't really see much here that would, eg. get to use it over the many other indistinguishable diagram editors out there.

<comment><USER7> I don't have any personal experience from it aside from viewing an existing architecture once, but from what I could tell, the ArchiMate language supports this, possibly via a concept called "viewpoints" ([https://en.wikipedia.org/wiki/ArchiMate#Viewpoints](https://en.wikipedia.org/wiki/ArchiMate#Viewpoints)). There is a free and open-source tool for it: [https://www.archimatetool.com/](https://www.archimatetool.com/) .

<comment><USER8> Does a common Structure Element 'sub-type' naming repository (Lexicon) exists for Archimate?

like [https://nominatim.openstreetmap.org/](https://nominatim.openstreetmap.org/) but for IT technologies.

[https://architecture-center.com/blog/125-archimate- metamodel...](https://architecture-center.com/blog/125-archimate-metamodel- tips-to-understand-it-better-part-1.html)

</comment></comment></comment></comment><comment> d--b The thing I've been wanting is to have a diagramming tool that can serve as a live health dashboard with links to logs.

Infrastructure diagrams always get out of date, unless they're looked at frequently. By hooking the diagrams with live status and logs, it becomes a tool that's used daily. It would make logs easier to navigate and diagrams kept up to date.

<comment><USER9> If you just want links to logs then you can use draw.io and export an svg: [https://svgshare.com/i/H7g.svg](https://svgshare.com/i/H7g.svg)

If you want dynamically updating diagrams you can maybe consider some of the diagram creation generation tools listed here: [https://asciidoctor.org/docs/asciidoctor- diagram/#creating-a...](https://asciidoctor.org/docs/asciidoctor- diagram/#creating-a-diagram)

</comment></comment><comment><USER10> I've been using draw.io for this in the past... will play with your tool, just made an account, but wondering if you could clarify what the differences are (the landing page didn't make it immediately obvious to me).

EDIT: I like the concept of Scenarios a lot! Will be using this more regularly... if you can do a PDF export, would be killer for me :)

<comment><AUTHOR> That's what I use as well! And it works perfectly when what I'm diagramming is pretty simple. It's just that when I'm trying to diagram anything nontrivial, I can't map it out on a one dimensional diagram without it turning into a mess. That's why I created this!

<comment><USER11> Hmm. Can you expand further? I also use draw.io and a quick look at your landing page did not enlighten me.

<comment><AUTHOR> So for example, I'd often want to add some sequences to diagrams, and the only way to do so is by numbering the connections, which in my experience becomes too messy/confusing after the single digits.

Another example is if I'm diagramming an API, the paths that a request takes differs under different conditions/scenarios. So a canonical diagram for a system in a company design doc ends up only illuminating the happy path of a successful request, missing so many detail because it couldn't fit nicely into one diagram.

Another is my issue with scattered diagrams detailing different subsystems. Eg a high level overview contains many microservices each diagrammed by their own teams. I wanted to be able to hop layers, easily going up and down a subsystem to see how they behave when handling something. And in my experience, decentralized diagrams within an org ends up becoming a guessing game of which one is most up to date and which ones haven't been deprecated.

<comment><USER12> Now I understand. Feedback: landing page should probably focus on communicating this: like draw.io, but gracefully handling paths, cases, alternatives, and scenarios. Good job!

<comment><AUTHOR> Yeah I've gotten more draw.io comments than I expected haha. I didn't know it was mainstream enough to say "like X for Y", but I'll add something to mention it. Thanks for the feedback!

</comment></comment></comment></comment></comment></comment><comment><USER13> Hey!

I got things i could see that could improve this greatly:

\- have a dot format (graphviz) importer (and maybe exporter), something simple to allow people to programmatically import/update their existing architecture.

\- alternatively have a json format, same thing (versioning, hand update, generation etc)

\- allow with a shortcut (alt key, whatever) to draw links between objects directly. Creating links is tedious right now.

I will post more as i'm working with your tool to represent our system :)

<comment><AUTHOR> Thanks for those suggestions! Agreed with all of them, especially having quicker ways to do common actions like add links, will be working on that next.

</comment></comment><comment><USER14> The sign-up requirement is a big onboarding hiccup.

Like yo, I don't even know what it really does yet, why are you asking me to create an account? Do you really expect your users to capture your value prop based on just screenshots alone?

<comment><AUTHOR> Thanks for that feedback. I'm working on that, I'll let users be able to play around with editing the demo with no save functionality without creating an account.

</comment></comment><comment><USER15> The layers are fun, but without some form of linking between elements and layers, it becomes hard to figure out what relationship there is between them.

I'd also enjoy a slightly easier way to link things. Having to drag an arrow from the sidebar to the field, then manually link the two points is quite slow. Normally these systems have a sort of handle when you've selected something that allows you to make a new arrow to another item.

<comment><AUTHOR> I'm working on both those things right now. Thank you for the feedback!

In general I wanted to see if people were receptive to this format of diagram before sinking more time into features, because there's just no stopping point to diagramming features. Now that the concept has gotten some validation, the diagramming tool itself is going to be getting _a lot_ better real soon. I'll post updates here: [https://twitter.com/terrastruct](https://twitter.com/terrastruct)

<comment><USER15> Thanks, I've subscribed, not that I look at Twitter that often :)

</comment></comment></comment><comment><USER16> After playing with it for a few minutes, this looks like it could be a really handy tool. Often times I'd find myself creating enormous diagrams trying to capture everything your tool handles more gracefully.

Is there some way to export data (SVG ideally) so I can use the diagrams in other apps? Also, I noticed that saving a diagram doesn't retain labels I give a block.

<comment><USER17> I had the same label-saving problem in Firefox. Chrome seemed fine.

It would be nice if there was an obvious way to report issues through the interface.

<comment><AUTHOR> There is a send feedback feature, it's in the drop down under your username top left. Thanks so much for reporting that, because I had only tested it extensively in Chrome and hadn't seen that.

Edit: I've fixed it. (apparently you can't use innerText in Firefox, has to be textContent)

</comment></comment></comment><comment><USER18> Kudos on the elegant execution of an interface to explain architecture and system behavior with layers and sequences!

Suggestions for v2: How to show v2 of system has changed since v1, and handling requests from your users to version control their diagrams. Nice problems to have!

</comment><comment><USER8> alt: [https://www.archimatetool.com/](https://www.archimatetool.com/) [https://plantuml.com/archimate-diagram](https://plantuml.com/archimate- diagram)

[https://c4model.com/](https://c4model.com/) [https://news.ycombinator.com/item?id=21032805](https://news.ycombinator.com/item?id=21032805)

<comment><USER19> [https://sparxsystems.com/products/ea/](https://sparxsystems.com/products/ea/)

</comment></comment><comment><USER20> I've been using MindNode for this.

I've found it very good at letting me quickly transfer my system ideas to paper. It gets out of the way and works with quick keystrokes.

But it breaks down when trying to use it for presentation. It is too difficult to show and hide different states of the system when presenting to others. It's slow changing between each state by showing and hiding different nodes.

I'm looking forward to trying your tool for this reason. I just wish it was a local program.

</comment><comment><USER21> You should consider adding a premium paid version, in addition to your enterprise version. This could add a lot of revenue to your bottom line.

</comment><comment><USER22> I would prefer to use local programs to make such things. Is there such a open source software that uses Xaw or just plain X window, preferably where the file format is a sequence of PostScript tokens (to make it easy to write a parser for the file format in PostScript (I also wrote a JSON parser in PostScript, so JSON would also work))?

<comment><USER23> Mermaid.js may be what you are looking for. Draw. Io is also open source and has desktop client

</comment></comment><comment><USER24> I like it, but just browsing the site quickly I'm not seeing something I've grown accustom to: sequence diagrams. My auth system for an embedded product to hit AWS is three players and fairly complex to explain. Makes sense to me as a sequence diagram, does anyone know if this option exists?

<comment><AUTHOR> This is designed for sequences! You have to create a scenario (name of your sequence, eg "auth request"), and then you create frames for it. Frames are steps of a sequence.

I used to use websequencediagrams.com for this btw, in case that fits your needs too!

<comment><USER25> I use a similar tool: sequencediagram.org

Seems to have very similar features, and can export to svg for free (in websequencediagrams.com it's a premium feature)

</comment></comment></comment><comment><USER26> Nice! I was just looking to convey entity diagrams to a client - and thought of doing them through something like Omnigraffle - this looks like it could do the job.

However - it doesn't seem to export itself well (the Print doesn't work - <USER2> something like a read only link would be enough)

<comment><AUTHOR> There is a read only link, that's what the demo is. Under the drop down for the diagram (hovering the diagram name in the top center), you can find a Presentation Mode. Then just share that link.

Thanks for the feedback!

</comment></comment><comment><USER27> I highly recommend [https://draw.io](https://draw.io)

<comment><AUTHOR> Same. It's for different purposes, but I 100% recommend using draw.io for simple one-image diagrams. This tool is specialized for complex systems that you can't fit in a single image.

</comment></comment><comment><USER28> Nice tool, I can see myself using it.

I was intuitively clicking on the boxes expecting to go to the details of that component. It would be nice to move deeper into sub-layers dynamically, instead of relying on the side tree menu.

<comment><AUTHOR> Yeah I thought about this as well and is something I originally imagined as a cool feature.

The problem, though, is that not everyone will create a sub-layer for every component. It'd be a bad user experience for the viewer to have to just try clicking components to see which ones work, and I don't want to modify the look of the diagram, from what the author intended, to add some visual indicator that it's clickable.

<comment><USER18> Please do reconsider adding a visual indicator. Direct manipulation is a powerful UI technique and helps retain user focus. It could be something as simple as the mouse pointer changing when hovering over a component that can be drilled down into.

<comment><USER29> Hovering the navigation on the left could also highlight all linked components as well, giving a better sense of what you can drill into (without having to discover for yourself by moving your mouse all over the diagram).

<comment><AUTHOR> This is an excellent suggestion, I might just do that. Thanks!

</comment></comment></comment></comment></comment><comment><USER30> Any thoughts on support for textual representation of the diagrams?

<comment><AUTHOR> What do you mean by textual? Like ascii art?

In general I'd love to be able to export this to some non-web format, but I just don't know any that fit given that there's 3 dimensions (layers of the diagram, scenarios for each layer, and frames for each scenario). All the formats only support linear traversal (eg pdf pages, gif frames). Exporting as a directory of files viewed as a tree hierarchy is the closest I can think of.

<comment><USER31> He means using a _language_ to generate diagrams. (I use a personal tool that has a LISP-like language to generate simple block diagrams in JavaFX for myself).

<comment><AUTHOR> Ah. Yeah if this is something people use and I can support myself with it, I would love to work on adding that.

<comment><USER32> Every couple years I go through the exercise of trying to find the right solution like d3.js, mermaid, or dot and graphviz to automatically generate diagrams like you're creating here. Every couple years I continue to be disappointed.

</comment></comment></comment></comment></comment><comment><USER33> Would be nice to have examples, so after login user can use them, to check how tool is working, what are layers and scenarios.

<comment><AUTHOR> Yeah you're right, I should allow users to load examples. Thanks!

</comment></comment><comment><USER34> How is this different from draw.io?

<comment><AUTHOR> See the thread above (currently), I responded there on this question.

</comment></comment><comment><USER35> FYI the logo looks a lot like the kubernetes logo to me, in case that's unintentional

<comment><AUTHOR> Any similarity is unintentional

</comment></comment><comment><USER36> Curious, what JS libs are you using for the drawing? Or is it a pure "from scratch" thing?

<comment><AUTHOR> I'm using this low level SVG library: [https://svgjs.com/docs/3.0/](https://svgjs.com/docs/3.0/)

<comment><USER36> Ah that's cool. Any reason you picked that over a canvas implementation?

<comment><AUTHOR> TBH, I saw that's what another popular diagramming tool was using.

</comment></comment></comment></comment><comment><USER37> Does it support collaboration mode? As in can I design diagrams with my colleagues?

</comment><comment><USER38> Any relationship to terraform?

<comment><AUTHOR> Nope

</comment></comment><comment><USER39> Definitely an advancement over draw.io however isnt this just mermaid diagrams?

<comment><AUTHOR> Thanks! Are you referring to this? [https://mermaid- js.github.io/mermaid/#/](https://mermaid-js.github.io/mermaid/#/)

If so, that looks like the output is still single-image diagrams. The differentiation of Terrastruct is having an elegant way to aggregate what would've been many diagrams, to express something complex, into one.

</comment></comment><comment><USER40> How is this related to SysML?

</comment><comment><USER41> > This is an iFrame of a diagram [...]

Why do I give a shit as a potential user that this is an iFrame?

<comment><USER39> because that indicates that this product has iFrame capabilities just for the graphs therefore you can easily add it to for example Confluence..

Just because you dont understand it doesnt mean you need to be rude.</comment></comment>


Roslyn ships v1.0-rc2 with "Go-Live" license - <AUTHOR> http://blogs.msdn.com/b/vbteam/archive/2015/05/01/roslyn-ships-v1.0-rc2-with-go-live-license.aspx

<comment><USER2> Like edit-and-continue I bet the code-aware library concept will be scoffed at by some, but provide a huge productivity boost to those who adopt it.

You can design the API as nicely as possible but there is just some information that can't be communicated that way. Now the library can ship with some compile-time code (instead of run-time code) that can analyze your usage of the library and provide feedback.

I'm also curious if C# begins to evolve some meta-programming constructs, letting you write "macros" or syntax extensions in C#. Everyone hates on the C preprocessor (as do I and for good reason) but few compiled languages provide a truly suitable replacement. Back when I was doing C# on a daily basis I would use reflection to generate DynamicMethod instances and emit the IL instructions in 2.0; later being able to convert Expressions to machine code was a step up for the cases where its needed and the T4 template engine works ok for other scenarios.

Now that I'm doing iOS full time that's my one major complaint - complete lack of any meta-programming facility. (That and they took away __conversion)

<comment><USER3> I think being able to do syntax extensions (a la LINQ) as a language feature would be great. Although I don't do much of it now, when VB.Net introduced XML literals I craved it in C#... other nice to haves would be regexp literal notations (or even expressions like perl), or template string handling like ES6.

It's a really nice time to be working as a programmer, although the proliferation of options has gotten to be nearly too much to keep up with even the fraction that I try to.

</comment></comment><comment><USER4> Interesting to note .NET and Go have both gone to some effort to make their internals more accessible to regular coders that build on them. Roslyn has a C# compiler in C# and has APIs you can use to build things like static checks. Go tip is in Go (converted from Plan 9 C) and has stdlib packages with APIs you can use to build things like static checks. Plenty of differences, of course, but sort of a surprising parallel between two very different ecosystems.

</comment><comment><USER5> This was the first time I had heard of code aware libraries. I can see them being very beneficial.

With resharper, I love going through all the little warnings and fix suggestions on old code that people that had written. I think I can have some fun with the analyzers while improving the quality of code.</comment>


BlockPRISM.org Facebook Encryption for Everybody - <AUTHOR> http://www.blockprism.org

<comment><USER2> I've seen at least 3 other such services promising encryption for Facebook chats, but none of them talked about how they're doing it. So how does it work? What is it using? OTR?

<comment><USER3> Based on the beta version of the Chrome Extension, they use [https://github.com/wwwtyro/cryptico](https://github.com/wwwtyro/cryptico) to create a RSA keypair based on a user-provided keyphrase. The private part is stored in the LocalStorage of the extension and the public part seems to be submitted to the server. Actual message encryption then happens using AES, but I'm not sure about the details. They delegate all actual crypto to the cryptico lib, so the description on GitHub is probably accurate for BlockPRISM's encryption too.</comment></comment>


Ask HN: Are programmers wages too low? - <AUTHOR> I looked at highest paid programming jobs and what skills are required. I also looked at lowest paid programming jobs and what skills are required. And then I looked at middle level jobs.
I concluded that employers are "milking" all of them.
I'm not saying that being a business person and selling, besides being a programmers is easy. Actually we are on HN and that is encouraged. And I'm not implying that jobs should be as easy as they were during the dot com boom.
Wages are determined by demand and supply to some degree but also by people's behavior or policies. Maybe I lack the experience of being employed as a programmer, but when I read job descriptions including words such as "fast paced" it reminds me of those junk food shops. And when I read a dozen of technologies being required at Master level, it reminds me about those article about the Myth of the Full Stack Developer. And then there are those middlemen who inflate the number of jobs posted, making it seem like there is a huge demand.
At the existing wage levels, I think the companies should put the effort to hunt programmers, not the other way around, I've only applied for 2 programming jobs in my life;  I want to hear your experience, especially if you work or have worked longer than 1 year as a programmer. <comment> a-saleh Worked 3 years at the same company, begun with 20k pre tax, currently at 24k a year, pre tax. I tried to apply to another company in neighbouring country and they offered me 24k as well.

The thing is, median annual pre tax income is ~10k and my yearly rent with utilities for 50 sq meter flat is ~5k.

So, on one hand I keep thinking "Wow, my yearly rent would cover maybe a month in SanFran" on the other, "I know that there is someone in my company making 5 times as much for the same amount of work just because he lives someplace expensive."

So, I kinda find myself underpaid in comparison, but I have been on the other side of the hiring table as well, and I even I wanted to have as good colleague as possible, that wouldn't break our hiring budget at the same time

<comment><USER2> Where exactly are you from? Are you in Eastern Europe by any chance?

</comment></comment><comment><USER3> There certainly are a lot of people who do not earn how much they should earn as a developer. A part of that is the whole master vs management discussion that occurs on HN a lot - not many companies have the maturity, foresight or need to pay a developer $300k+.

There are a lot of developers who do not know all the technologies. Sure you do need to know A LOT to be able to operate in a startup, but if you are a .NET engineer at big co generally the job description will be to know 3 or 4 technologies. For example my last role was Python, SQL and basic front end development.

I've found that jobs aren't fair, I feel that tech guys build this resentment a lot towards analysts or coordinators who they feel don't pull the weight.

If you want to maximize your income (given you are a high performer), banking/law would be the best career choice over programming.

</comment><comment><USER4> Be really awesome at whatever you specialty is (provided it's not something that has no business value at all) - and be able to prove it (through open source, books/talks, demoscene, robotics projects - whatever is appropriate in your field). That should easily enough put you in the $250k+ bracket.

Granted, I think that level of expertise may be achievable only by the gited, while the rest of us ordinary folks may have to accept our ordinariness and the meh salary and positions that come with it. Or, alternatively, go to an industry like finance, which pays a lot for just domain knowledge without neccessarily having to be an exceptional programmer.

</comment><comment><USER5> The supply of professionals is influenced by corporations and, well, capitalists so much, that it's almost impossible to have very well paid jobs lasting a long time.

</comment><comment><USER6> Definitely, relative to the skill requirements and value created vs other professions.</comment>


Where Tcl and Tk Went Wrong - <AUTHOR> http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ <comment><USER2> There is some interesting stuff here, but if you want a one-sentence explanation of why Tcl has declined I'd suggest: It doesn't have a hook.

What does Tcl offer? Half this article is about Tk, but Tk is (a) a generic GUI toolkit, and therefore competing directly against everything from Java Swing to Flash to (the big winner) HTML/JS/CSS. And (b) not Tcl-specific, right? Didn't I see Perl bindings for Tk go by?

As an embeddable language Tcl somehow got eclipsed in the branding battle by Lua (don't ask me why; not my field, all I can do is repeat glib rumors) and in web-app land it got crushed by PHP just like Perl did. If you want to toy with extensible syntax in your language you can use Ruby DSLs; if you want the real thing you go to a Lisp. Tcl's a lousy language for mathematics and I can't imagine replacing a shell script with it (I think I vaguely remember a Tcl shell, but maybe I dreamed that, because it has no mindshare). It doesn't run in the browser. So what is Tcl for? Just tell me in a sentence. And, no, "being a nice average general-purpose language" is not a brand worth anything.

<comment><USER3> I think you should get an afternoon and learn Tcl, because it is clear from your post that you don't know it enough. A few remarks:

1) Ruby DSL, really? After you understand Tcl you'll discover how Ruby is not really a language suited for DSLs compared to TCL, even if Ruby is quite suited for this use case indeed. Tcl is not just much more DSL-ish as a syntax and structure, but also has some kind of "run time lisp macros" (uplevel) that let you do everything in your DSL.

2) Tcl built-in event loop provided a way to write very fast evented I/O apps easily. Something node.js is providing now was, in a different form, available since 10 years, and nobody noticed. However it is still very interesting, now with support for coroutines Tcl is very suited to take the state between firing of events.

3) Tcl as alternative of shell script is great, for a number of reasons: from the [glob] command to an [exec] command that is able to mimic a lot of what a shell can do. See the Redis unit test for an example of scripting stuff with Tcl.

4) Tcl vs Lua: Lua IMHO wins in the implementation, Tcl has not an ANSI target, and is a much larger implementation. But actually it is possible to write a large subset of Tcl in a very small space. I tried it in the past with <http://jim.tcl.tk>, and indeed now this implementation is in use in the embedded world.

Tcl lost at this point, but programmers willing to understand it will do a great thing, it is like to be exposed to a different new world. It's like learning Scheme or FORTH: mind changing.

<comment><USER2> Actually, I was technically a professional Tcl programmer in 1999, and I remember "uplevel" very well, because I got to watch as the MIT Scheme wizards put it through all its paces. Oh, the things those folks could do with Tcl. I really can't overstate how much fun it was to read their new libraries as they came out.

I admit I've forgotten most of my Tcl, though. Because I haven't had a compelling need to use it in ten years, so I haven't. See above.

Tcl is indeed "a different new world, like learning Scheme" (though Scheme has SICP, and Tcl has... what?) but this essay is not about "why Tcl makes a great academic paper" or "why Tcl is a great way to spend a Saturday night" but rather "why Tcl is not popular as a mainstream programming language". Being "mind-blowing" is not only not a path to mainstream popularity, but it's also a field with a lot of stiff competition: Scheme, Forth, Factor, Erlang, Io, Common Lisp, Haskell... several of these are on my personal todo list ahead of revisiting Tcl.

<comment><USER4> TCL has the TCLers wiki (<http://wiki.tcl.tk/>), which isn't the same as SICP, but is a great place to see awesome things TCL can (and can't) do.

</comment></comment></comment></comment><comment><USER5> From a language design standpoint, Tcl is simple and beautiful. You can read its entire semantics in its rather short man page. It's got the homoiconicity of Lisp (with strings instead of lists) which enables very flexible syntax extension. Its simplicity also allows it to be embedded rather easily.

Unfortunately, it's _too_ simple, in one fundamental way which makes the language very flawed: it does not have closures. Callbacks (which are fundamental to I/O or GUI work) are executed from a scope which has access to nothing but global variables. As a result, users of the language must either stash everything in globals, or else perform awkward explicit variable substitution, taking care to distinguish between variables to be evaluated in the present context and variables to be evaluated in the callback context and escape them appropriately (like writing a Lisp macro, but this is in every callback.)

And if you want to implement any higher-order functions, say filter by predicate, you have a problem because you want to pass an argument to the predicate, but you also want the predicate to have access to variables in the scope where it was defined. The predicate is not a first-class function: it's a block of code that you can eval. In fact, you can eval it anywhere on the call stack. That's right: Tcl gets the job done using functions which evaluate blocks of code in their caller's context. If that sounds scary, good, it is.

<comment><USER6> It certainly has warts. But it's not bad for something from the late 80ies (my guess is that Tcl is older than a small but significant number of this site's users), and I don't think language design is a key component in being popular / having a healthy community.

Exhibits A and B: PHP and Java.

<comment><USER5> I think Tcl is beautiful example of a certain point in the design space and extremely useful pedagogically. It's not that it has unnecessary deformities (warts) the way that PHP does. Someone could make a much better PHP than PHP by just cleaning up a bunch of nonsense that's only there because its designer didn't know what he was doing. I don't think that's the case with Tcl (or Java, for the most part.)

It's just that solving a complex problem with a simple tool can often be more complex than solving it with a complex tool, even if the complex tool requires a bit more up-front learning.

Working with Tcl makes it very clear that spending some of your complexity budget on closures pays off big.

As far as what makes for a popular language, clearly corporate support is the key factor in some cases, good libraries in others, but I can't really explain the rise of Python except by its design.

</comment></comment></comment><comment><USER7> I've dabbled in Tcl a few times, and I really like it.

The author talks about the ease with which the language's syntax can be extended. For me, this gives me the same feeling I get when I'm using Lisp. I'm aware of the large differences between the languages, but the feeling of freedom they both provide makes using them flat-out fun.

<comment><USER8> Both Lisp and Tcl are "everything is a-" languages. In Lisp, everything is a list. In Tcl, everything is a string. (For some values of "everything").

I guess that's really the key to allowing easy syntax extensions; it means that programs are represented in the very core data type, and you have lots of tool to manipulate it.

</comment></comment><comment><USER9> How about almost being Javascript? In 1994 I gave a talk and demo at the Second WWW Conference with TCL integrated into Mosaic. It performed the same functions as Javascript later did, and was a very good match also being string based. (ie it was embedded in the page and could control page display and actions.) Even got massive applause from the crowd.

Although it was embedded in our browser (IXI Mosaic) as standard, Netscape was formed at the same time, got huge market share and did their own thing. But TCL could have been a contender ...

I personally switched from TCL to Python in 2000. The lack of a standard way of keeping data and the methods that operate on it together ("object orientation") made larger projects too clumsy.

</comment><comment><USER10> The best description of Tcl state is that its creator John Ousterhout now teaches students how to write web apps in Rails.

It's like Larry Wall would write a book about Django.

</comment><comment><USER11> Back in the era this is talking about, I ported the Tk text widget over to GTK+ which became GTK's still-used text widget (GtkTextView).

I think the author is right that it was a mistake to ignore Linux. It didn't have the desktop user marketshare, but it did have the developers that were doing a lot of the work on open source code.

Even at that time (just before GTK+ 2.0, around 2001), expected toolkit features had jumped ahead of Tk quite a bit; in porting the widget I think I added model-view separation, pixel-based (vs. line-based) scrolling, international text layout, input methods, accessibility, lots of optimizations, support for non-XPM images... likely more I can't remember.

Tk lacked all that stuff, and various GTK-related companies and Troll Tech (Qt) were investing in building all of it for GTK and Qt. That led to a situation where only those two toolkits, that had been modernized, were acceptable to lots of decision-makers who were deciding what to ship with Linux distributions or GNOME or KDE. Nobody could afford to go modernize Tk also, it was easier to just get all the apps on one or two toolkits. The modernization work was being funded or volunteered-for with Linux in mind, nobody cared to do it for open source toolkits on Windows or Mac. Swing was probably the only cross-platform toolkit that had the same modernization work done. (Ignoring "wrapper" toolkits like wxWindows or SWT that have whatever modernization is found in the toolkit they wrap.)

The Tk text widget was a solid piece of work, I mean, it's an accomplishment to write code good enough that it makes sense to port it to another toolkit. The core btree data structure from Tk is in GTK to this day with extensions but no real major overhaul: <http://git.gnome.org/browse/gtk+/tree/gtk/gtktextbtree.c> I think Ousterhout may have written it.

It's an interesting data structure if you like that sort of thing. The older GTK text widget had various operations that were O(n), and so people kept writing O(n^2) or worse code accidentally; with the new one, one of the goals was to try to keep everything below O(n) so it was harder for developers to hose themselves. The core of this was the btree from Tk. One place we declared defeat was in very long lines; some stuff is still O(n) where n is the line length, and that's hard to fix without massive overhaul. The btree is about storing lines and related metadata so that things aren't O(n) in number of lines. There's also a useful trick in <http://git.gnome.org/browse/gtk+/tree/gtk/gtktextiter.c> where an incrementing "change stamp" is used to keep an iterator valid even though the iterator caches some pointers that can become invalid as the btree changes.

Sorry for the "used to walk both ways in the snow"-flavored post ;-)

<comment><USER12> _"One place we declared defeat was in very long lines"_

This still haunts me today. IDLE, the IDE-like editor that comes with Python, struggles with long lines. Execute something like this:

        print list(range(10000))

...and your whole Python Shell window (which is essentially a Tk text control) becomes so slow and unresponsive that it's better to close it, and/or restart IDLE.

<comment><USER11> Yeah, it sucks. It's pretty hard to fix though, one of those bugs where the multi-week or even multi-month effort to fix it probably isn't ever going to make sense to anybody. (Say IDLE in particular is bothering you; you could probably spend a very short time just hacking it to truncate that string before putting it in the widget, vs. the likely gigantic task of fixing the widget. Everyone is making that same calculation whenever they get annoyed by this.)

</comment></comment></comment><comment><USER13> Every time I'm reminded of Tcl's history through Sun I wonder how much would have had to have been different for Tcl to have ascended instead of Java.

Was it the decision of one man who just liked Java better? Was it for more technical reasons (like the lack of a standard OO system)... etc?

I don't know Tcl well, but I still feel like a different present in which Tcl had arisen to be one of the most popular languages may have been better than the actual Java-dominated present.

<comment><USER14> For a long time I thought that way, but Java has a killer feature that everything else is missing: it's really hard to write java extensions in C/C++, and thus it's near-impossible to crash your runtime. I think that combined with its C-like syntax was always going to ensure Java's success in the enterprise.

The other thing that makes it good for large systems is that Java was designed from the ground up for running untrusted code. I know the python module that attempted to offer the same functionality has been abandoned as basically unworkable. (Though interestingly this is one of the things that Tcl did well - safe Tcl actually worked, afaik).

</comment></comment><comment><USER15> My absolute favorite thing about Tcl is its simplicity. Just do "man Tcl" (it's built in to Mac OS X). That one man page describes the entire language and it's only 12 paragraphs long. There's a wonderful simplicity and symmetry that comes from the core "everything is a string" tenet.

That said, I haven't used it for a new project in over 10 years. I still kind of miss it though...

</comment><comment><USER16> For me, the crufty nature of Tk's Motif-style appearance was the major factor.

I used Tcl/Tk heavily in my 3D graphics class back in 1998, and while I enjoyed its light weight and ease of use, I felt that the GUI output was definitely old-school compared to Gtk and Qt, and had no desire to continue using Tcl/Tk after the class ended. It felt like the past.

</comment><comment><USER17> I'm a long time Tcl/Tk user - it's still the defacto standard in the electronic design automation industry.

My own tl;dr for this comment: David makes good points and his experience mirrors some of my own. I think the biggest mistake was not going with a "batteries included" strategy for Tcl releases.

1) Tk got left behind by Qt, GNOME, etc.

I whole-heartedly agree with this. We spent a very long time making our Tk apps fit in on user's Linux based desk tops - tweaking color schemes, widget dimensions, and even adding new widgets that Qt and and GNOME had that Tk didn't (trees, tables, buttons that could show images and labels, for example). Tk has since made this a lot easier but at the time it was frustratingly time consuming.

The author's other point that there were too many ugly Tk apps. Maybe. You definitely could spot a Tk app a mile away. But there are plenty of ugly X apps where X is any GUI framework so I don't buy in to that theory as much.

2) The debate between making Tcl batteries included or not.

In think this is the #1 issue. I love Tcl for quickly stitching together a few apps or processing files. Tcl makes working with the system really easy and it's "everything can be a string" roots can be tremendously useful. But... if you want to do something that's not in the core language - you had to build it yourself. There were quite a few useful external packages but they were often incompatible or tied to specific versions of Tcl etc, etc. Comparing that to the first time I built something in python and needed to process a gzipped file. Just import zlib. Wow!

Every big Tcl project I'm aware of had to devote a lot of energy adding support for some fairly basic - in comparison to other scripting languages - features. Tcl's philosophy was very much like the C language. Keep the core small - let the users work out the rest.

3\. Missing default support for object orient programming.

Sure. Maybe. That kind of goes with point 2 above. It wasn't ever so much of an issue for me or any of the projects I worked on.

4\. Missing support for some modern conveniences (no PNG, no readline based shell)

Sure. It goes with the batteries included or not theme. It was (and still is in some cases) a sign that tcl was falling behind.

5.Everything must be representable as a string

I spent a lot of time dealing with this. It's incredibly convenient when writing Tcl scripts. It's incredibly difficult when writing C extensions. The Tcl_Obj structure is actually really clever but managing the life cycle of objects is frustratingly complicated.

This is advanced enough of a feature that I don't think it impacts that many people. That said, fixing this flaw might have allowed for more interesting extensions.

6\. (I'll add one of my own.) Multi-threaded tcl is not built in. You have to make the choice at compile time. Compiling in support for threads slows down tcl enough to be noticeable for the kinds of people that are interested enough to do multi-threaded programming with Tcl. :-)

<comment><USER10> 'it's still the defacto standard in the electronic design automation industry.'

Can you elaborate on that? I know nothing about that industry but I still have some nostalgia for Tcl despite of using Ruby now.

In the past I was a solid Tcl user (couple years ago even did a small custom Linux distro where bash was replaced with Tcl & installater was written in Tcl/Tk. It was fun!)

My thoughts on its ~ 0 popularity are:

* No Rails equivalent.

* No gems equivalent. In modern world it is a disaster. (One could notice how quickly nodejs got its npm.)

* 8.6 and OO system are in aplha/beta stage for 6 (?) years. Many of us just gave up waiting.

I still remember '2007 would be a great year for Tcl.' What a joke.

<comment><USER17> Tcl is used quite heavily as a command line shell EDA tools. Google "pt_shell tcl" or "ncsim tcl" for examples.

Cadence and Mentor Graphic's digital simulation GUIs were built with Tk. Probably a lot more. The big win for Tk in GUIs in the late 90's was it's cross platform support. For all of its limitations - Tk was a huge improvement over Motif!

Tcl is also used as a data file format for describing desing rules. Synopsys' SDC (standard design constraints) and Cadence's CPF (common power format) are both just design specific variations of Tcl. Writing a parser for these formats just requires writing command implementations. Tcl takes care of the rest.

<comment><USER10> Thank you for the answer.

Never realized that Tcl empire was so broad.

</comment></comment></comment></comment><comment><USER18> I was a long-time Tcl user and loved it. [incr Tcl], incidentally, is not a play on "+=1", but "++"; i.e., [incr Tcl] is to Tcl as C++ is to C. Speaking of event loops, before Tcl had its own event loop, I wrote a select()-based event loop extension to Tcl that was similar to the Xt event loop. For that, I was (or still am for all I know) listed as an extension contributor in the Tcl/Tk FAQs.

[incr Tcl] was a great OO framework for writing GUIs. Perhaps not the greatest framework since it was trying to mimic C++.

As antirez said, "It's like learning Scheme or FORTH: mind changing."

</comment><comment><USER19> I always felt that the syntax was painful to work with - it reminded me of scripting with csh way too much. That's not to say Tcl/Tk didn't have areas where it would shine brightly back in the day. Those would be Expect and Tk. When you needed to 'automate' accessing hosts or devices via telnet, Expect could do that and then some. And Tk was probably the easiest way to create a GUI on the fly for unix and linux. I know that most of the management and configuration apps for UnixWare 2 and 7 were written in visual tcl, a curses enhanced version of tcl, which made dealing with UnixWare less painful.

Unfortunately, there aren't really any big killer apps written with tcl, and I haven't seen any major new books (a 2nd edition of Ousterhout's book and one or two others). I suppose it's better than the situation that Eiffel is in, though.

</comment><comment><USER20> I used Tcl a lot at my former job, it's a fun language. The architect of the project I was on picked it, and I got see a dozen or so people's introduction to the language. These may seem like nit picks, but for newbies, these appeared to be the biggest issues:

1) People hated pronouncing it "tickle", and would almost always initially call it T-C-L. This seems minor, but people have egos and if the name is silly, it's going to hurt in adoption.

2) Comments (#) are actually commands, and you can't simply comment out blocks of code.

3) There was no buzz or heat around the language, nothing exciting seemed to be happening with it. This led a lot of people to thinking it a waste of time to learn.

<comment><USER6> Comments are not actually commands, but... yes, you can't just do something like

        # if { $foo } { ...

Because the open brace will cause problems.

</comment></comment><comment><USER21> I tried to use Tcl a couple of times and resigned very quickly, for a similar reason I don't like bash for non-trivial scripts. It's the strange quoting rules that can cause some text to become an expression which is executed. It's just an accident waiting to happen and I kept running into that many times. 'expr' seems like an eval that you can't get rid of.

I'm a bit surprised how language feature like this became the standard way of doing basic things. How is parsing "code strings" at runtime ever better than building an ast and handling variables as variables?

</comment><comment><USER22> I worked with expect (tcl based automation tool) for a while back in the 90's and while I really liked expect for what it could accomplish, tcl itself annoyed me. I can't really articulate why (perhaps just the overwhelming prevalence of {} characters?) I also found pass by name semantics sort of weird, but on the other hand, I was much less mature then than I am now, so I can't really trust my own impressions.

Expect is still pretty neat:

<http://expect.sourceforge.net/>

</comment><comment><USER23> What's replaced Tk for an easily scriptable, cross-platform GUI language? What I see the most in practice is PyGTK, but it's pretty hard to love. Javascript+HTML is probably the most capable alternative but the lack of a simple container for native-feeling apps is really limiting. I was surprised to learn Lua has quite a robust series of GUI options, but I've never seen it actually used.

<comment><USER24> What really happened was that the core functionality of Tk was ported to other languages (for python, check out Tkinter), so you can leverage the power of Tk elsewhere. As a result, you have to look at Tcl in comparison to Python and other languages. At the end of the day, Tcl fell out of vogue.

<comment><USER25> Python accesses Tk by shipping a Tcl interpreter.

(which doesn't really change your point, but Tcl is directly involved there)

<comment><USER26> If memory serves me correctly, Tkinter even exposes you to Tcl sometimes if you want to do more advanced things, though I can't remember now why I needed it.

</comment></comment></comment></comment><comment><USER27> Author is right. Right or wrong Tk' least common denominator old ass, crusty, motif look kept me away. Little I saw back then, 90's, "advertised" any use of tcl outside ok Tk. In fact it was almost always called tcl/Tk.

Languages need mindshare and to get mindshare you need marketing and tcl suck[ed|s] at marketing. Unlike python, ruby, lua.

<comment><USER28> Is it really that much worse than Lua's marketing? I figured Lua just took off because it's niche is much more clear cut and there's less competition.

<comment><USER6> I'm talking about marketing more in the sense of "finding out what people are doing with your stuff, and moving your product in a direction that helps them" than "SELL! SELL! SELL!", which you really can't do with open source in any case.

The embedded vs batteries included example is a pretty good example of that: Tcl is neither small and limited/self-contained like Lua, nor does it ship with a bunch of stuff out of the box. So it satisfies no one.

</comment></comment></comment><comment><USER29> What a memory flashback...

I made the decision to focus on low level C++ / Windows right around the time tcl/aolserver was cutting edge.

I think my career advice for younger programmers is to stay away from whatever technologies I'm using.

<comment><USER30> Just curious, why? I personnally have almost 0 interest in web programming. What would you recommend for younger programmers that hate web stuff?

</comment></comment><comment><USER31> one thing tk got very right was a superb vector canvas. it blew my mind when i realised how easy it was to draw shapes on the canvas and have them respond individually to mouse clicks.

</comment><comment><USER32> (looks at watch) pretty soon we'll see the "whatever happened to FORTH?" post troll by. It's Groundhog Day all over again.

</comment><comment><USER33> tl;dr: Rails is the killer app for Ruby. Your open source project needs a killer app.

I spent several years as a TK/TCL programmer. I believe where Tcl "went wrong" is that it never got attached to a very high profile use case or project.

It is not enough that the language was open source-- it needed to be used in a major open source product (or a major product period, the way flash is major, and thus ensured a life for lingo/actionscript, etc.) There was no Rails for Tcl like there was for Ruby. There was no Django like there was for python. There was no iPhone like there is for iOS, or massive number of open popular open source products like there is for Java.

I can barely remember anything of Tcl. It didn't make a big impression on me, even though I wrote it full time for a couple years at a job back in the day.

This is not true of other languages- Every language I've had to use full time has become my favorite language. At one point it was Java, then I discovered Objective-C and that became my favorite language, then I got into erlang, and now _that_ is my favorite language (though it shares a spot with Obj-C because I use them for different things.) Tcl never made a big impression- it never gave me the big epiphany of a better way to do something that the other languages have (message passing in Objective-C makes it the best OO language in my opinion, and erlang's concurrency is unmatched, in my experience, though I don't claim to be an expert.)

Finally, the big claim to fame that Tcl had, was TK. Tcl programmers talk about TK a lot- notice how this article does. Unfortunately, the problem TK is trying to solve is essentially unsolvable in a good way. Sure, you can make a cross platform GUI toolkit, many have, but you then have to decide if you make your program look the same on each platform (and thus not like that platform) or if you try to make it look like the platform, in which case you run into all kinds of issues (because each GUI platform is based on seriously different design choices and thus having one bit of code support contradictory design choices on the different platforms is difficult. You can abstract a lot of it, but not all of it.) In the end, these cross platform apps never quite look right. Perfectly fine for Enterprise software (part of the reason Java found such success there) but never really delivering for the commercial shrink- wrapped market, which needed each platform app to look just right for that platform.

The two big lessons I take away from this for any open source project is- 1\. Have a clear compelling feature that you absolutely nail. Be the go-to place for that feature (as TK tried to be.)

2\. Do everything you can to make sure there's some high visibility adoptions of your project in other projects or products.

<comment><USER34> tcl (as embedded interpreter) had its killer apps. tk was IMHO for quite a long time the only reasonable way to provide a cross-plattform GUI. It simply lost traction (due to the developments described in that article but IIRC also due to the opposition of Ousterhout towards integrating some OO framework) and python and ruby took over.

</comment></comment><comment><USER35> Otra vez!

</comment><comment><USER36> I'm usually a patient man, but after reading several paragraphs of that article and it still going nowhere, I gave up. I think that if the author managed to summarize what he was trying to say in one or two paragraphs, it might be easier for me to decide if the verbiage is actually worth my time.

I read about half of the article before my annoyance surpassed my curiosity. Come ON!

This is constructive feedback.

<comment><USER6> > This is constructive feedback.

Not really. Some stories, such as those involving hundreds of people over the years, many companies, countless person-hours of work, and lots of money, are long and complex with many details and cannot be summed up in one or two paragraphs. I mean, you could say about my article that the key point is "marketing is important", but you'd be missing out on many details.

Lord help us if you're ever confronted with something like...shudder... a book! Some contain thousands upon thousands of twisty paragraphs, not at all alike.

Or, as a mediocre man once said, in the future, "There was a time when reading wasn't just for fags. And neither was writing. People wrote books and movies. Movies with stories, that made you care about whose ass it was and why it was farting. And I believe that time can come again! "

<comment><USER36> I strongly disagree. Being brief and to the point is difficult and requires hard work, and it is impolite to assume that what you have to say is so important that other people should be expected to read the whole thing before being able to decide if it is relevant to them.

The article in question would benefit greatly from a summary that allows the reader to decide if reading the whole thing is worth the effort. In scientific publishing an abstract is part of good form. In journalism the structures are usually less formal, but a good journalist will sell you a lengthly article without requiring you to read the whole thing.

I have been criticized for writing at length and being bad at summarizing myself. I know it is hard. And of course I find it annoying when people point out how bad I am at writing. But you know what: it is extremely constructive criticism.

<comment><USER6> I was brief and to the point, though. There's a lot of material to cover and I did so fairly quickly.

I figured the title was enough to give away the general gist of the article: it's about a programming language and the problems it had. If that's a subject that interests you, perhaps the article is worth a read. I wrote the article to talk about a subject I know well, for people interested in that subject.

tl;dr: not everything can be dumbed down to TV-style sound bytes.

<comment><USER36> If you were to submit a paper to a conference or a journal and they asked you to provide an abstract -- would you be offended? Why not? When you read ACM or IEEE journals, do you see the abstracts as "dumbing down to TV-style sound bytes"?

<comment><USER6> Let's put it this way: if you can't figure it out from the title of the article, it's just not for you.

The article was not meant for people with a casual interest in the subject, but those who wanted to know about the details.

If that's not you, so be it. I would note, however, that at this point you've surely spent more time complaining here than it would have taken you to read the _entire_ article.</comment></comment></comment></comment></comment></comment>


The Pirate Bay Tracker Shuts Down for Good - <AUTHOR> http://torrentfreak.com/the-pirate-bay-tracker-shuts-down-for-good-091117/ <comment><USER2> <http://news.ycombinator.com/item?id=946367>

</comment><comment><USER3> Doesn't this mean that the technology is basically the same as eMule or Kazaa now?</comment>


Warranty void if removed stickers are illegal - <AUTHOR> https://motherboard.vice.com/read/warranty-void-if-removed-stickers-are-illegal <comment><USER2> Hooray, this is finally starting to get some attention!

It really grinds my gears how "voiding your warranty" has become coined as a tinkerer badge of honor, even though one is doing no such thing. In the case of something with GPL components like Android, some modification is even expressly granted!

Having said that, the stickers themselves aren't illegal. They fall under a backwards legal principle that adversaries can purposely mislead you without consequence.

<comment><USER3> > Having said that, the stickers themselves aren't illegal. They fall under a > backwards legal principle that adversaries can purposely mislead you without > consequence.

Except, as the article (and the FTC official quoted therein) states, the law in question (the Magnusson-Moss Warranty Act) actually does prohibits various deceptive implications which the stickers can reasonably be viewed as conveying.

<comment><USER2> I do now see the relevant clauses of the Act, and see how they _could_ imply as such (although said sticker isn't actually referencing any _brand_ ). But obviously lawyers from most major electronics companies seem to disagree, at least in expected value terms.

</comment></comment></comment><comment><USER4> What is a manufacturer to do when someone opens a device that functions as advertised, zaps it through a careless electrostatic discharge, puts it back together and gets free warranty service?

Well, that manufacturer has to raise prices (or invest in even more involved ways of detecting damage, or in hardening the electronics against ESD, all of which cost more). This harms those that don't want to mess with their devices.

There is no such thing as a free lunch...

<comment><USER2> That "free lunch" is the inherent difficulty of performing diagnostics on a failed device. I'd say the manufacturer is in the better position to test their devices and make their devices conducive to such testing, rather than putting the onus onto the consumer to prove the contrary.

Furthermore, the situation you describe is going to be such a small fraction of cases that manufacturers are likely not going to even worry about it.

<comment><USER4> _Furthermore, the situation you describe is going to be such a small fraction of cases that manufacturers are likely not going to even worry about it._

I hate to leave it at disagreeing on facts, but at this juncture, I have to. This is not a rare case at all!

<comment><USER5> Are you suggesting that there's some underground scene of consumers intentionally zapping their electronic devices and then demanding warranty service all the while twirling their moustaches in the manner of a Snidely Whiplash.

</comment></comment></comment></comment><comment><USER4> Maybe that is what the law happens to say now, but it isn't necessarily what the law should be.

Ideally, manufacturers have a right to sell what they want, under terms that they want. Buyers have a right to choose among the best available options on the market, or to not buy at all. Maybe this wouldn't lead to outcomes that the author wants, but then again, he's free to show that all of the other companies are doing it wrong by starting his own company!

So let's allow other people vote with their dollars, rather trying to suppose what customers want and then forcing everyone to comply.

<comment><USER6> The concept of "voting with one's dollars" or "letting the market decide" is predicated on all parties having perfect information, i.e. everyone understands all laws, including this one. Naturally, this is rarely true in practice, hence the need for consumer protection laws.

<comment><USER4> We're not living in the early 1970s anymore. Nowadays, if you want to dig into something, you're just a search away from deep knowledge about whatever you want.

Learning is an inherently individual process, and it requires time and effort on the part of the learner. Just think back to when you were in school - we'll never all be equal in terms of what we know.

(I shouldn't have to say this, but yes, it should be illegal to do things like sell a cake with an actual bomb inside it or something. Doing that is just plain murder, which is an entirely different phenomenon from what we're talking about here, which is whether or not a company has to honor a warranty for a device which the customer has tampered with in violation of contract.)

Why should the range of options for those that avail themselves of information be limited for the benefit of those that do not?

<comment><USER6> It is not a reasonable expectation that consumers be aware of every law that may be applicable to a purchase. If we had to do that, we'd either have time for nothing else, or be lawyers.</comment></comment></comment></comment>


Ask HN: nodejs, express and jade - worth it? - <AUTHOR>

Hi all,
A few weekends ago I wrote a simple web traffic analyzer. Very simple website. I told a few people about it, and also told them about the sites that I was basically mimicking (for my own personal education). I didn't make any updates to the site after that single weekend of working on it. Well, I found out today that 2 of those people actually enjoy using it. One of them made a few feature requests today.
Now, this site is very minimal. It's not pleasing at all to look at. It doesn't even use any custom CSS - only Yahoo's base CSS file. So, I'm thinking about making it better. As I mentioned, I wrote this site several weekends ago and since then I've been playing around with nodejs, expressjs (web framework) and am about to try out the jade template engine. Jade itself is entirely new to me, and at first glance I laughed at the thought of using it. It has been sitting in the back of my mind though since I laughed at it, making me wonder if I could force myself to perhaps try it to see what it's all about.
Anyways, I'm thinking about re-writing this site using nodejs, express and jade. It perhaps won't be better, because I'm a nodejs beginner, but it may be a good learning experience.
Does anyone out there actually use nodejs to power their entire website? Is it even recommended for that? It seems very low level and I am not sure how productive I'll ever be with it. This Jade template engine is pretty much a foreign language to me. I've mostly always used engines similar to Jinja2, where it's still entirely HTML.
I just wanted to see some thoughts on nodejs as the choice backend engine for a complete website! <comment><USER2> Although I have never built a "complete website" on the node.js stack, the time that I have spent developing on the platform has been very enjoyable and I've put a decent amount of effort in. There are many articles as well as github repositories that can teach you what you need to know to get up and running. I recommend <https://github.com/ry/node/wiki> and <http://expressjs.com/> for reading on the subject. Good Luck!

</comment><comment><USER3> There are many product websites including companies using just express.js, see <http://expressjs.com/applications.html>

node.js is bound to have even more.

About it being worth it, it is worth trying. At the end, you would know about Event servers, mini frameworks & more.

It is a newer area, so expect some hiccups.

A tip: There are some express.js screencast links in the github readme, <https://github.com/visionmedia/express#readme>

</comment><comment><USER4> I'm not a pro or anything but this is probably of interest to you:

<http://howtonode.org/> is built with node and <https://github.com/creationix/wheat> is the blogging engine it was built on

Hope it helps.</comment>


New in Cloudera Labs: Google Cloud Dataflow on Apache Spark - <AUTHOR> http://blog.cloudera.com/blog/2015/01/new-in-cloudera-labs-google-cloud-dataflow-on-apache-spark/

<comment><AUTHOR> Google's blog post: [http://googlecloudplatform.blogspot.com/2015/01/easily- run-d...](http://googlecloudplatform.blogspot.com/2015/01/easily-run-dataflow- big-data-pipelines-anywhere-thanks-to-cloudera.html)</comment>


The PDA returns to CES, because everything old is new again - <AUTHOR> https://techcrunch.com/2018/01/07/the-pda-returns-to-ces-because-everything-old-is-new-again/ <comment><USER2> > Back before "PDA" was merely shorthand for kissing someone a crowded > commuter train, we carried personal digital assistants. It was a dark age, > when our mobile devices still sported physical keyboards.

Except for the fact that the most popular PDA of the 90's, the Palm Pilot, most commonly had no keyboard.

<comment><USER3> A derivative, the Treo had a keyboard.

Bluetooth keyboards and docking station keyboards were available for the palm pilot.

Hp iPaqs also had keyboards available.

Sharp also had a Zaurus device.

Nokia had the N800 communicator device too.

<comment><USER2> Of course, in the same sense that there have been Android phones that had keyboards, and Blackberry devices with keyboards were still in wide circulation only a few years ago.

</comment></comment></comment><comment><USER4> I'm _very_ happy that devices such as this, and my current favourite - the GPD Pocket - are making a return to the market. Having a full-fledged Linux workstation with multitouch, 'retina'-class display, and still fit in my pocket .. this is truly awesome. And if it weren't for the massive (>$1000) investment in software on my iPads, I'd just ditch iOS completely and move 100% to the GPD Pocket for all my touch-interface needs.

This represents an opportunity - iPad-class devices, without any of the walled garden. I'm far more excited about writing apps for Linux now that those apps can take advantage of hardware features such as the GPD Pocket .. now if only there were more competition with the same physical qualities.

</comment><comment><USER5> Waiting for this one [1].

[1] [https://www.indiegogo.com/projects/keyboard-mod-a- physical-k...](https://www.indiegogo.com/projects/keyboard-mod-a-physical- keyboard-for-the-moto-z#/)

</comment><comment><USER3> If there was an honest external keyboard case for a pixel or iPhone... Might not be too far off.

<comment><USER6> Except for the price point. And the "boot into Linux" part. The latter alone might compel me to purchase this device, if it means that the drivers are all (or at least mostly) upstream.

<comment><USER7> My prediction is: you get the same driver quality as you get with bottom-of- the barrel Android. Based on the fact that the device is mostly built from those parts.

</comment></comment></comment><comment><USER8> In German, PDA also is a common abbreviation for [https://en.wikipedia.org/wiki/Epidural_administration#Epidur...](https://en.wikipedia.org/wiki/Epidural_administration#Epidural_analgesia_during_childbirth) — which with the current state of IT/tech. might also be a good idea ;)</comment>


Help Reform Computer Crime Laws - <AUTHOR> https://hackerone.com/news/legally-blind-and-deaf <comment><USER2> > The hackers with the skills to break into software and networks, who choose > to come forward with their knowledge and share their findings, should be > legally exempt from criminal prosecution under laws designed to punish > crime.

I know this is an unpopular opinion here, but I personally think that you shouldn't mess with people's shit unless they invite you to (e.g. by having a bounty, research partnership program, etc.). Yes, some organizations will be less secure because of it. Similarly, some houses are less secure because the locks are low quality. It isn't up to you to decide how thoroughly said locks should be checked.

<comment><USER3> The stance you take is harmful when said organizations are responsible for the stewardship of the data of others, and being "less secure" places the general public at risk. The true impact of a breach is rarely limited to a single organization.

It is even further harmful when the laws are aggressively applied to prevent research into personal property, especially when your personal safety may depend upon it. For example, your car: [https://twitter.com/0xcharlie/status/600729130355666944](https://twitter.com/0xcharlie/status/600729130355666944)

<comment><USER2> > The stance you take is harmful when said organizations are responsible for > the stewardship of the data of others

Do you make a habit of visiting banks uninvited to test their vaults?

<comment><USER3> I don't make a habit of storing assets in banks that fail to insure me against a total loss of those assets. That insurance just happens to require extensive third-party verification of security practices that may be publicly audited upon request.

The analogy doesn't hold when applied to the digital services we all depend upon as such assurances are impossible.

<comment><USER4> > The analogy doesn't hold when applied to the digital services we all depend > upon as such assurances are impossible.

Rather than allowing anyone to try to crack a server as long as they claim to be a white hat, I'd much rather require corporations to go through a standard, "extensive third-party verification of security practices that may be publicly audited upon request" and default cracking attempts to "illegal."

I may be misunderstanding something in what you're saying, though -- if I am, could you clarify that for me?

</comment></comment></comment></comment></comment><comment><USER5> IMO, security researchers have the legal and moral obligation to contact their research target before conducting research. If said target refuses their request, the security researcher should have the legal right and moral obligation to publicly disclose that their request to conduct research was refused. And that's it.

</comment><comment><USER6> Not so easy to do. As usual, there is a risk that such legislation will be abused to let people who are trying to break in to a system for malicious reasons, claim later it was research. A decent law would require researchers to register with police/whatever before they start researching. Which then excludes researching government/police systems (because they would know up front). etc. Not so easy!

<comment><USER7> Let's imagine a decent law that would require people to register what kinds of information they are protecting, from what kinds of use.

One kind of security researcher we would want to protect is the one who finds out they can get information, but doesn't get everything, or doesn't keep what they get, or doesn't get anything really sensitive. Or who establishes that they can modify a system, but doesn't change anything important.

If someone gets my credit card number, and doesn't use it, and points out the problem, __I want to thank them __.

We make the analogy of breaking into houses, but bad information security is more like someone putting up a post-it note that says "This is a lock."

Sometimes just looking past the lock violates the letter of the law.</comment></comment>


In Silicon Valley, Hypocrisy is the new normal - <AUTHOR> https://om.co/2019/11/10/in-silicon-valley-hypocrisy-is-the-new-normal/ <comment><USER2> Plus ca change!</comment>


Show HN: Trump to Text (Natural Language Generation) - <AUTHOR> http://trumptotext.com/ <comment><USER2> " Dude where is my car. What do you need it for? Where are the employees? This is a man who's got a wife and a beautiful home. And he's going to be president. OK. He's going to be president "

</comment><comment><AUTHOR> Hey HN!

As a side project, I used the GPT-2 OpenAI NLG model and trained it on Donald Trump speeches. You can type a sentence and it will generate a few paragraphs that sound like Trump completing the thought.

I used [https://github.com/minimaxir/gpt-2-simple](https://github.com/minimaxir/gpt-2-simple) and some other stuff to re-train, with Starlette being the python web server. I'll write up a blog post later on what I learned and issues I faced.

The text generation is pretty slow right now (~20 secs), but I didn't optimize anything since this was just a fun side project. Would love thoughts/feedbacks/funny texts :-)

<comment><USER3> Hey thx for sharing this. Would you mind sharing some details about deployment and cost? Would be very helpful?

<comment><USER4> See the gpt-2-cloud-run repo: [https://github.com/minimaxir/gpt-2-cloud- run](https://github.com/minimaxir/gpt-2-cloud-run)

</comment></comment></comment><comment><USER5> "I am a crossbreed of an Oompa Loompa and a potato."

</comment><comment><USER5> "When will our song and dance of life reach a beautiful crescendo?"</comment>


Triton: Docker and the "best of all worlds" - <AUTHOR> https://www.joyent.com/blog/triton-docker-and-the-best-of-all-worlds <comment><USER2> I find these to be pretty weasel words: _Is Triton open source?

Yes. Triton Elastic Container Infrastructure is the commercial offering built on the top of the open-source SmartDataCenter cloud infrastructure management platform. In addition to the open source components, Triton includes support, a DevOps portal, and intellectual property indemnification only available to commercial customers._

In more plain English, "Yes. Triton is open source just like Mac OS X"

[https://www.joyent.com/developers/triton- faq#os](https://www.joyent.com/developers/triton-faq#os)

<comment><USER3> That's a good thing to clarify. It's not an open core system like Mac OS X. SmartDataCenter is open source and Triton is our product branding. [https://github.com/joyent/sdc](https://github.com/joyent/sdc)

There is work in progress to clean up and open source the self-serve portal and its dependencies.

The propriety bits are not ours: "The Joyent SDC USB images offered to our customers contain certain firmware binaries for use with Joyent-branded hardware. We cannot make that software generally available in the open source builds; however, it is available to all who have purchased Joyent-branded hardware and is of no use without that hardware." [https://docs.joyent.com/sdc7/obtaining- software](https://docs.joyent.com/sdc7/obtaining-software)

<comment><USER2> But what you're branding Triton in fact appears to be a PaaS GUI on top of SDC? i.e. the way people manage their containers/hw in Triton the service, is not available in SDC which seems to be all CLI tools?

<comment><USER3> As the Docker Engine for SDC is being developed to the Docker API and CLI, Triton can be used through any Docker ux. [https://github.com/joyent/sdc- docker/blob/master/docs/diverg...](https://github.com/joyent/sdc- docker/blob/master/docs/divergence.md)

The interesting bits are not the self-serve portal. The portal is good for introducing the stack and supplementing the experience, but few use a portal for infrastructure management -- they require more automation, specific to their business.

We're working hard on getting the self-server portal code architecture and hygiene up to open sourcing it. From there we can get these portal plugins open as well. Our on-prem customers are hungry for this, as many of them have a mandate for OSS.

</comment></comment></comment></comment><comment><USER4> Tldr.

Triton lets you run your docker containers in the cloud without worrying about virtual machines or setting up your own paas.

Signup here: [https://www.joyent.com/lp/preview](https://www.joyent.com/lp/preview)

<comment><USER5> So how is this different from the container service from google?

<comment><USER6> One interesting bit from the article: "Does this mean that I'll be able to DTrace my Linux apps in a Docker container?" (yes)

Technically you can run dtrace on various platforms, and I don't know enough to tell you specific reasons why you would rather use dtrace on smartos than linux. I got the impression a few years ago the ports weren't as good. (perhaps relating to the linux port not yet being a kernel module?)

<comment><USER3> Debugging LX branded zones on SmartOS

[https://www.youtube.com/watch?v=6oIBiWdh41c](https://www.youtube.com/watch?v=6oIBiWdh41c)

"A gritty how-to on debugging LX branded zones on SmartOS presented internally at Joyent on 1/30/15\. While given to an internal audience, there is quite a bit of information here that may be interesting to the broader community"

</comment></comment></comment></comment><comment><USER7> Uh, so I've never really heard of SmartOS or Joyent's SDC before now...

This stuff looks pretty fucking unreal. What's the catch? It looks like it solves so many problems with clustered container deployment. Exposing a whole datacenter as a single Docker host seems like the end-game to me.

Am I missing something? I'm a little low on sleep today.

edit: To answer my own question a little: I guess the docker-sdc isn't quite fully baked yet. That's not really a huge issue since it's still a preview, I think?

<comment><USER8> Nope, SmartOS is pretty neat.

<comment><USER9> Ditto. We were early adopters at work. KVM + ZFS and practically no setup is ace.

</comment></comment></comment><comment><USER10> Can someone explain this in words that a time traveller from 2010 would understand?

<comment><USER11> Love the question. This should be the new ELI5. I think a lot of articles on here would benefit from answering that question.

<comment><USER12> The Explain it like i have been in a coma for 5 years... Elihbiacf5y or just 5 years in coma, explain! 5YICE....

Or ETTT5YA or ET5... explain to time traveler from 5 years ago

</comment></comment></comment><comment><USER13> Joyent has solved some really hard problems to make this work. I was lucky enough to get the chance to sit down with Bryan last week and talk with him about what this took. It's essentially reimplementing Linux on top of Illumnos, which is no tiny feat.

There are still messy hurdles to running Docker in production, but it's clear that Joyent has really tried to make something awesome here.

As someone who works deeply in the future-container space, I applaud folks who are taking us deeper down the rabbit hole. I think it's clear that this whole 'back-to-the-future' isolation technology is really cool stuff. Jails/zones/containers have been around forever and I think it's great that we're finally taking advantage of this technology.

Edit: at Terminal.com, we want people to push Linux forward, and this is a great example of taking Linux to new and intriguing heights. I did not think we would have Linux on Illumnos in quite this way in 2015 and it's delightful to see. We are all standing on the shoulders of giants and it's great to reach new vistas.

<comment><USER14> Isn't it an example of taking Solaris to new and intriguing heights? There is no actual Linux code in the implementation.

<comment><USER13> That's a great point, but I think the point of what Bryan has been doing is to make Linux work with Zones (and dtrace).

That's a primitive that Joyent has wanted to upstream into the Linux kernel for a long time and has never been able to get the necessary consensus around it (similar to OpenVZ's troubles getting their work upstreamed).

In short, this is sort of a hack to give you zones on Linux without needing to get zones into the upstream. Yes, there's no linux code, but there is a lot of required understanding of Linux code to make something like this work.

It's kinda amazing that they got 64-bit linux to run on top of Illumnos, right? I did not see that coming and maybe that's because I'm ignorant in some capacity, but it's been a pleasant surprise.

<comment><USER14> Emulations have been a Unix feature for a long time actually. NetBSD has had 64 bit Linux emulation for ages, for example, but its not very complete because no one has cared enough to implement more. For example Illumos is AFAIK the first system to emulate epoll. The Linux API is huge and historically the process has been just fixing stuff for a binary someone wants to run. It is very tedious work...

I dont really see it as zones in linux. More a gateway drug for non-Linux.

<comment><USER15> Hey Justin -- do you have insight into how hard any _particular_ remapping (ie: epoll) is to perform ? I was talking to @bcantrill about their effort at a Docker meetup and mentioned the NetBSD emulation (he said "Oh! Of course!"), but whats interesting (in retrospect) is that they (Joyent) just tried running stuff and played whack-a-mole w/ unimplemented APIs... how tough would it be for "us" (NetBSD) to occasionally implement pieces ?

edit: parens

<comment><USER16> Speaking without familiarity with NetBSD, I think it depends on what kernel facilities the system happens to have; speaking for SmartOS/illumos, in many cases we were able to slightly rephrase Linux facilities as extant facilities -- saving a considerable amount of time and effort. For example, the big realization with epoll was just how naive it is -- so much so, in fact, that it actually looks very similar to a pre-port mechanism (/dev/poll) that we developed nearly 20 years ago (!!) and later deprecated in favor of ports. epoll would have been much nastier without /dev/poll -- which is likely the greatest service that /dev/poll has ever provided anyone...

<comment><USER15> Hi Bryan -- I'm also aware that epoll may have been a bad example on my part, because isn't it subject to some nasty fork/share bugs wrt handling the (well) handle, and what file it's _actually_ associated with the handle -- so a parent can get notifications on a handle it doesn't have, or worse, notifications for a socket that it _does_ have that is not _really_ the same handle that's issuing the event.

In cases like that, did you end up trying to be bug-compatible, or make a design decision to clear up the trouble ?

[edit -- spell "Bryan" correctly]

<comment><USER16> Funny you should mention that one in particular -- from our (SmartOS's) epoll(5) man page:

           While  a  best effort has been made to mimic the Linux semantics, there
           are some semantics that are too  peculiar  or  ill-conceived  to  merit
           accommodation.   In  particular,  the  Linux  epoll facility will -- by
           design -- continue to  generate  events  for  closed  file  descriptors
           where/when  the underlying file description remains open.  For example,
           if one were to fork(2) and subsequently close an actively epoll'd  file
           descriptor  in  the  parent,  any  events generated in the child on the
           implicitly duplicated file descriptor will continue to be delivered  to
           the parent -- despite the fact that the parent itself no longer has any
           notion of the file description!  This epoll facility refuses  to  honor
           these  semantics;  closing  the  EPOLL_CTL_ADD'd  file  descriptor will
           always result in no further  events  being  generated  for  that  event
           description.

So while we do aspire to be bug-compatible, we're not about to compromise our principles over it. More details (or some of them, anyway) can be found in the talk on LX-branded zones that I gave at illumos Day at Surge 2014.[1][2]

[1] [http://www.slideshare.net/bcantrill/illumos- lx](http://www.slideshare.net/bcantrill/illumos-lx)

[2] [https://www.youtube.com/watch?v=TrfD3pC0VSs](https://www.youtube.com/watch?v=TrfD3pC0VSs)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Here's the signup link for Joyent's hosted container service: [https://www.joyent.com/lp/preview](https://www.joyent.com/lp/preview).

We're seeing the initial explosion of the microservices ecosystem right now. I've been spending most of my time over the last few years thinking about trusted decentralized infrastructure and have decided that microservices, including hosted ones, could be one possible solution for instantiating trust as a proper 'knob' of the cloud. This Intracloud, if I'm allowed to use a new buzz term, will be smeared across 100s (1000s?) of datacenters world-wide. Have a high-trust use-case? Run it in a German or Dutch datacenter. Have a high-efficiency use case? Run it on a friend's cluster for free.

I believe in this idea of the 'trust knob' enough that I sought out a job with the folks at [https://giantswarm.io/](https://giantswarm.io/), where I am now a dev evangelist. We are a German hosted microservices stack which provides a Docker platform. Alpha signup is here: [https://giantswarm.io/request- invite/](https://giantswarm.io/request-invite/). Demo of it in action here: [https://github.com/kordless/swarm-ngrok#ngrokn-giant- swarm](https://github.com/kordless/swarm-ngrok#ngrokn-giant-swarm)

I also hacked together a SF Microservices meetup last Friday: [http://www.meetup.com/SF-Microservices/](http://www.meetup.com/SF- Microservices/). 139 people have already joined. Would like some feedback for content! Planning on mid-April for the first event.

I'm excited to see what happens with this market in the next 6 months!

</comment><comment><USER18>
        > When Docker first rocketed

I thought this was an interesting way to start off the post.

</comment><comment><USER19> "You can run your Docker containers across entire data centers without ever creating a "cluster" as other IaaS providers would have you do."

This is a little unclear. I get that you don't have to create a "cluster" because you're going to use the API to launch containers on existing dedicated hardware, but how is that a WIN for your finance team? I guess I'm missing something.. but wouldn't you have to already have systems online that you're paying for that these containers can be launched on?

From: [https://www.joyent.com/blog/docker-bake-off-aws-vs- joyent](https://www.joyent.com/blog/docker-bake-off-aws-vs-joyent)

<comment><USER4> The difference for the operator is: Baremetal -> smartos -> container vs Baremetal -> hypervisor -> virtual machine -> container.

Theres root safety in the smartos implementation of docker. So they can do multi-tenancy.

For the customer, you dont have to provision entire virtual machines to run docker containers.

<comment><USER19> Is it multi-tenancy of various Joyent customers on the same hardware? So you get containers placed somewhere in their data center on shared hardware with other customers? Or do you already need to have dedicated hardware provisioned at Joyent to launch containers on? I'm still unclear on that point, which makes me question how it's saving the end user money.

<comment><USER20> Yes, you are running on shared hardware, securely, but with no hypervisor.

The biggest money-saver is in performance. IO-heavy applications can see anywhere from 5-10x performance improvements[1] by switching from hardware- to OS-virtualization.

[1]: [http://dtrace.org/blogs/brendan/2013/01/11/virtualization- pe...](http://dtrace.org/blogs/brendan/2013/01/11/virtualization-performance- zones-kvm-xen/)

</comment></comment></comment></comment><comment><USER21> Very cool. Is the next step integration with Manta so you can specify an environment of Linux executables to map over your data?

<comment><USER22> Yes, that's definitely the direction that we're headed.

Manta allows users to spin up large numbers of transient containers around their data (i.e., without moving data around) in order to do map-reduce operations, and without having to think about the container management. Today, these compute tasks are specified as scripts that run inside a well-stocked SmartOS container, plus some optional assets to download (for custom binaries or other data). The obvious next step would be to let people specify they want to run an LX zone (rather than a SmartOS zone) so that they can run GNU/Linux binaries. Then we can consider whether it makes sense to phrase the task as a Docker image. That might well be a more natural way to incorporate a larger bunch of binaries and other shared data. Architecturally, all of this should be relatively straightforward (famous last words!).

</comment></comment><comment><USER2> Didn't see the actual repo linked: [https://github.com/joyent/sdc- docker](https://github.com/joyent/sdc-docker)

"A Docker Engine for SmartDataCenter, where the whole DC is exposed as a single docker host. The Docker remote API is served from a 'docker' core SDC zone (built from this repo). ... Disclaimer: This is still very much alpha. Use at your own risk!"

<comment><USER23> To me it seems like Triton is about shoehorning Linux into Solaris/SmartOS containers. While this seems great for accelerating adoption, why not just use SmartOS-specific Dockerfiles/repos in conjunction with sdc-docker (Not directly addressing the parent, more of a general question)? Imagine all of the crazy bugs and edge cases that will arise when trying to run Linux binaries on UNIX.

I'm surely making some assumptions, but the primary languages/developers that something like this targets are probably like Java, Javascript/Node.js, Ruby, Python, C...which are probably all portable enough to run on SmartOS without much/any modification.

<comment><USER24> Docker multiarch support isn't finished yet, and getting all the world's Dockerfiles rebuilt on SmartOS is a big task.

There are also different philosophies about whether container images should be distributed as source (Dockerfiles) or as binaries. It looks like Joyent decided to run Linux/x86-64 binaries to be on the safe side.

</comment></comment></comment><comment><USER25> Is there any pricing information for Triton yet?

<comment><USER26> Pricing here: [https://www.joyent.com/blog/expanded-container-service- previ...](https://www.joyent.com/blog/expanded-container-service-preview)

<comment><USER25> Thanks for finding that link. That is a very attractive pricing model. I am currently running about 10 VPS running about 25 containers. The costs of the VPS hosting is affordable, but managing those VPS hosts, deployment, balancing, discovery, and scaling are the hard parts. I'm looking forward to learning more about Triton.

</comment></comment></comment><comment><USER27> Is there any further work going on to support AMD in the KVM driver? I remember the codebase having sat idle for a few years last time I checked...

<comment><USER28> While sadly not merged upstream yet, it works very well. I've been running custom SmartOS "eait" builds from [http://imgapi.uqcloud.net/builds](http://imgapi.uqcloud.net/builds) (which include AMD support) for some time now without any issues. The source can be found at [https://github.com/arekinath/smartos- live](https://github.com/arekinath/smartos-live)

</comment></comment><comment><USER29> This looks like a very nice way to deploy containers. I see the per hour prices ([https://www.joyent.com/blog/expanded-container-service- previ...](https://www.joyent.com/blog/expanded-container-service-preview)) but is there any pricing on bandwidth? I imagine there will be eventually, right?

<comment><USER30> I'd suggest looking at this page as an indicator ([https://www.joyent.com/public-cloud/pricing](https://www.joyent.com/public- cloud/pricing) \-- Bandwidth tab): all inbound traffic free, outbound is 12 cents/GB after the first GB, cheaper at higher tiers.

</comment></comment><comment><USER31> I feel like perhaps I'm the only one concerned about this: (Somehow, "SmartOS + LX-branded zones + SmartDataCenter + sdc-portolan + sdc-docker" was a bit of a mouthful.)

Not only is it a mouthful, it means there is a much wider space for things to go wrong.

<comment><USER32> Compared to say "hypervisor + Linux + kubernetes + weave + etcd + lxc-docker" ...? Not to mention all the pieces that work together for lxc-docker.

</comment></comment><comment><USER33> Excited to see this. Congrats to the team on the release!

</comment><comment><USER34> Nice!

</comment><comment><USER35> I saw the name and my desire to read it plummeted. The same person wrote [http://www.joyent.com/blog/the-power-of-a- pronoun](http://www.joyent.com/blog/the-power-of-a-pronoun) which led to one of the most talented developers of node core and libuv leaving the project for a while.

<comment><USER36> That "most talented developers of node core and libuv" took time out of his day to revert a commit to take a gender neutral pronoun and make it back into a male one. Talented people can be shitbirds also you know.

</comment></comment><comment><USER37> This is running Linux binaries on Oracle Solaris (which they call SmartOS), and not the real thing that Oracle is still developing, but a fork from 2010 that is maintained by 1/10th of the developers it once had. [https://www.openhub.net/p/illumos](https://www.openhub.net/p/illumos).

This would have been pretty rad 10 years ago, when the world still cared about Solaris.

On a minor note: the post doesn't credit Oracle or Solaris, from where more than 90% of their SmartOS code comes from, until Oracle closed their code in 2010.

<comment><USER38> This is cool RIGHT NOW because WHO THE HELL CARES WHAT THE UNDERLYING OS IS? For a user trying to bring something to market, here's what matters:

1) it's cheaper (theoretically, due to performance savings from not dealing with hardware virtualization), and 2) it looks like a docker host

I honestly expected Docker Hub to expand into this kind of operation before anyone else, but Joyent, from out of nowhere, has done it instead. Why should anybody care that they're doing it with a Solaris-based kernel, Linux, on NetBSD, as MAME machines, VIC-20 cartridges, or with 1402 machine images and druidic spells?

To the user, it's just a magical world where your Docker host always expands to whatever size you need it to (and you of course get a bill for the usage).

The real test will be whether or not this is cost-competitive to deploying Docker swarms on other public cloud providers. If the performance and tenancy claims are as they claim (or even the same order of magnitude, which seems reasonable), and they're not insanely greedy with pricing, this could be the biggest tech since Linux itself.

<comment><USER39> I was wondering how this would compete with docker swarm. Is my understanding right that docker swarm basically lets you run an agent on individual docker hosts whereas triton will let you run a single virtual docker host?

<comment><USER38> Docker swarm basically lets you say "I want to deploy this image somewhere, you choose from the available actual machines" based on constraints that you've set up. You also had to actually set up the machines themselves (though docker-machine is intended to take some of the pain out of this).

sdc-docker (the tech behind this, Triton) basically lets you just keep deploying containers without any regard for the actual underlying machines (or EC2 instances, DO droplets, Linodes) that you are actually deploying to. It's like docker-machine + docker-swarm but all automatic and managed by guys on the other side of the curtain, so you can just write the checks and keep the Docker goodness flowing.

<comment><USER40> > _sdc-docker (the tech behind this, Triton) basically lets you just keep > deploying containers without any regard for the actual underlying machines > (or EC2 instances, DO droplets, Linodes) that you are actually deploying to. > It 's like docker-machine + docker-swarm but all automatic and managed by > guys on the other side of the curtain, so you can just write the checks and > keep the Docker goodness flowing._

Not sure I get this - Is this any different from mesos/kubernetes? If I am running this software and deploying my own datacenter _someone_ stills need to provision the machines.

<comment><USER39> I'm still fuzzy on this also, but it sounded like it would fill a very similar role as kubernetes except that they are claiming superior performance.

<comment><USER3> You've got it. This is a complete stack (sdc + lx-brand, sdc-docker, vxlan/portolan) fully benefiting from Illumos's architected OS virtualization.</comment></comment></comment></comment></comment></comment></comment>