MurrayHill1980

I learned more from YouTube videos on database normal forms and useful problems they solve than I did in grad school.

If I recall correctly, log structured file systems and in general, making file systems more robust was a real breakthrough. Before that, fsck after a crash seemed a little too exciting. I can't recall the details, but didn't Microsoft go through a similar evolution in the early days of win32 where they recruited a prominent LSFS academic researcher to help them with this problem. The article mentions this but it seemed much more important at the time.

Because deep down, it's not what they do. They are optics and camera hardware companies. In the race between physics and software, they are on the physics side. This is evident in the entire user experience. They keep missing the boat with the way people actually use photography today, and don't even seem to care much. There's not much evidence they have the kind of research expertise that Apple, Google or Adobe built in signal processing and image processing, either.

See also https://www.dslrbodies.com/newsviews/news-archives/nikon-201... and https://www.dslrbodies.com/newsviews/news-archives/nikon-201...

Because the Intel 8080 instruction set was octal, right?

This is cool: https://dercuano.github.io/notes/8080-opcode-map.html

There are probably several definitions of "giant" in play here.

Why should it matter that much whether people search for "app" or "software"? There are different types of programs. There are big desktop programs. There are useful mobile device programs of all sizes and shapes. There are games that run on various devices.

The market shows that people like free stuff and cheap little programs ('exercise workout timer on your iphone') but will pay for a zillion features (AutoCAD, Lightroom, Tableau, the AWS ecosystem are examples).

Even the variants of Unix tools with a lot of features seem to have won in the marketplace of ideas.

Yes, in my experience this can get to considerable scale (hundreds of thousands and beyond) but at a price. You need to do all your own management for things DOM/SVG were doing (e.g. hit detection, styling). You still need to send the data to the client and probably store it locally (customers will enjoy learning how to start Chrome from the command line with flags like --args --js-flags="--max_old_space_size=8192"). The client environment still doesn't have much support for data management or processing unless you bring in some other JS libraries. I'm a big fan of JS development but the criticism is on target.

The RCloud project covered some of this ground https://cscheid.net/2015/08/17/collaborative-visual-analysis... It takes the view that everything should be saved and versioned. In hindsight it seems obvious that this can overwhelm people with dead ends and scratch work and in general the flat workbook space doesn't provide enough help with organizing results. There are some other ideas mentioned in the conclusion of the RCloud paper.

It would help if gitlab's web interface could make it possible to renew letsencrypt security certificates more easily than running local commands and cutting and pasting the certbot handshake string, then the SSL public and private keys. I have to do this every 3 months for the website for an open source project. Or if gitlab could sell ssh access to a VM host (for this purpose, not to use do any other significant computing) at reasonable cost.

About 12 years ago, some colleagues (Yehuda Koren and Chris Volinsky) and I proposed a technique for measuring proximity in quasi-random (social) networks, that can handle out-of-memory databases, and more than two query nodes, also finds a visualizable subgraph that represents as much of the relationship as possible using dynamic programming. It is described here (includes some figures): http://web2.research.att.com/export/sites/att_labs/groups/in... The proposed heuristic approximates the "cycle-free effective [electrical] conductance" between the query nodes. In this paper, we were able to use anonymized phone calls to confirm 6 degrees of separation.

There used to be a live demo on an AT&T Labs website but it is not available now. There are published algorithms for all the phases of the proposed heuristic, but my recollection is that Yehuda found an efficient, robust implementation of k-disjoint-shortest-paths was not easy.

This is an interesting problem, thank you for making your work available. (I do agree the HTML form placeholders that change rapidly but are ignored when you press the GO button are a little confusing; it took me a minute or two to figure out what was going on.)

Some important tools were written after 1993 (stress majorization around 2004 https://graphviz.gitlab.io/_pages/Documentation/GKN04.pdf ; sfdp around 2007-08 when Yifan Hu joined AT&T Research, edge bundling in mingle and orthogonal routing were done in the last few years) but, yes, basically right.

Thank you all for the comments and suggestions. Most of the criticisms are quite fair: graph language improvements, modernization including default styles that aren't from 1980, bring Javascript interfaces like viz.js into the code base, coding multithreaded solvers, etc. Emden Gansner and I left AT&T a few years ago (in my case, it was AT&T's idea not mine) and we have not put a lot of work into the code lately. Emden's done a lot to move the website to gitlab.com that is about ready to go (instead of hosting the site in a VM on a 1.1Ghz Pentium or whatever we left in the rednet closet in AT&T.) We have a small backlog of algorithmic improvements. For instance, Emden implemented Ulrik Brandes' "untangling hairballs" algorithm but it's not in the code base. I realize this is a standard open source refrain, but "if anyone knows how we could support ourselves by working on this, let us know."

Some of the main lessons from this software, which can be applied by other projects:

- For certain applications, people need rich types of diagrams, not just dots and lines. Many automatic tools including ours often still do not reach the quality of the best handmade diagrams.

- We can benefit from using more general systems of constraints, and this area of research deserves further study and exploration.

- Interaction, complex APIs, embedding your software in bigger, more elaborate systems is great, but presents some users with a lot of complication that is too costly to surmount.

- Documenting your work in a way that makes it accessible is as important as the work itself. We did fall short there.

We're grateful we had a good run with graphviz.

Best regards, Stephen North north from graphviz.org

uucp?

People usually respond to how they are measured and rewarded. This applies to software written by graduate students. (Most professors code in English using students.)

"Before the Internet existed?" You make that sound like such a long time ago!! Meanwhile I see there's another Ycombinator news item in which someone discovered the "HERE IS" key on Teletype ASR-33s (which I believe one pressed to automatically read the already-punched papertape with the code to identify your "Station".) Again from pre-Internet days when mighty dinosaurs still roamed the earth writing games on Teletypes on IMSAI-8080 computers and pirated copies of Microsoft 8K Basic.

Graphistry is impressive, but not free, and needs their server and an API key. You probably already know about graphviz sfdp (not interactive). There's been interesting recent work on distributed maxent optimization https://arxiv.org/pdf/1506.04383.pdf and sparse stress models https://arxiv.org/abs/1608.08909 (see its references as well, for example, Khoury's MARS is still available at https://github.com/marckhoury/mars). This problem requires a ton of algorithm engineering, a lot of messy user interface engineering, and integration into an HPC environment is a big issue, so progress in open source has not been that rapid.

What task is made easier by this visualization?

This is a very good point. In the early days of Graphviz we put a lot of effort into making very readable diagrams of fairly small graphs, mainly in drawing directed graphs (dot). We aimed at graphs with under a hundred objects. We agree with the viewpoint that it is better to apply some sort of analysis to reduce a larger graph to a smaller one that can be read and understood. People still want to draw much larger networks. In fact it is valid to want an overview of all the data, it's just not clear how to do this with many thousands of random connections. Graphviz sfdp (based on Yifan Hu's earlier work) and recent work on Maxent (which has a decent theoretical justification) and from Ulrik Brandes group are good examples. One reason graphviz neato does not make such great layouts of large graphs out of the box is that it is straight statistical multidimensional scaling, and we just drop shapes on top of the points, so they can overlap badly. We felt since people are relying on it for data visualization we did not want to post process the MDS layouts by default in a way that could be misleading. But you can turn on overlap removal (neato or sfdp -Goverlap=false). We really should document all this in one place that is easier to find and understand.

About the external shape loader issue - this code is somewhat centralized in graphviz/lib/gvc/gvusershape.c and in gvrender.c which calls it, and I thought it could be disabled at compile time (because we did address the security concerns at one point) and there's a lot of other machinery to control compile time features. Maybe John Ellson can comment here. Kudos to John for recognizing the problems with the shape loader as soon as I proposed it but apparently that didn't stop us at the time. Stephen North

Exactly. Where's Photoshop or Excel for Linux?

No, but I have respect for their work. I'm in the graphviz project. You might take a look at Tim Dwyer's WebCola, http://marvl.infotech.monash.edu/webcola/ which is not quite what you want, but seems closer and may be a plugin replacement for D3 force layout.

You are asking for too much, but you could join our project and help. The inference of "intuitive" geometric constraints from operations in a graphical interface is an interesting problem. Realtime interactive edge routing is interesting, too. Have you looked at Tom Sawyer Software?

It is totally totally impressive that a hardware version of a software simulation of the actual 6502 was built.

What about an 8080 or 6800? Or Z-80.

Zapple V1.1 >g200

HIGHEST MEMORY?

52926 BYTES FREE

Welcome to BASIC, Ver. 1.3 <TDL Z-80 8-K VERSION>

>READY

Soon: how to win at Lunar Lander.

Javascript clock? You can get an entire animated 6502 CPU. Maybe it could be used to run a browser, to render the clock :-) http://www.visual6502.org/JSSim/ Stephen North