So I voted for CGI. If it's just all one big movie then the cash to keep it going will go to nerds instead of genetically modified junkies.

sort-of. We have symbolic glyphs that make up most of what my 2D printer produces, and I arrange long combinations of these glyphs. This is done in a typically 1D fashion despite being 2D glyphs.

Assembly of pre-existing libraries in logical ways (like connect surface A.side to B.bottom at right angle rotation on clicked spot) sounds more likely to have mass appeal than complete freedom (MSPaint for 2D) .

Anything in that timeframe that's media-like (ebook, etc) has DRM trapping it, or else there are already more ways to make duplications of the original (Amazon MP3 vs torrented Amazon MP3).

But new art is made all the time that has identifiers showing that it was assembled and not printed.

Plenty, oh, and Plenty.

First it's a way to push more AIX mainframes (you need like 6 minimum to run it full out).
Think a couple TB of ram.

I asked Watson "what is the meaning of life?" and the answer:
        It's referent.

It makes sense for a referencing machine, but this was not a sarcastic pre-programmed answer. It provided the references it assembled for its decision. If it's right, it could do quite a lot.

Command-line interpreters help save time and have became my favorite way to jump into using those languages, but there's more than the shell.
Python is a great one.
Javascript in Chrome has a command-line where you can try out things.
Unsurprisingly, despite both of these languages having issues, they are highly popular.

I hear that there's a chrome with a Dash interpreter built-in. If it includes inline editing, then I'd bet it will do well.

I recommend any of the impressive tools that round-trips text nicely (Sublime, Notepad2, gedit). Just plain text with minor format annotations.
It's easy to lay out simple graphs which I use for financial summaries that I will be able to access for years.
Text is a massively-entrenched standard format with universal comprehension rules (unlike other standards like HTML). Just be sure your editor makes sense of either line ending. You can use many tools including those that can write directly to a RAID0 device, an FTP server, etc for safety.

Integration has some positive factors to consider:
  - Copy-paste of text into a calendar works great.
  - Filesystem tree layout is handy for archival purposes (and is also deeply entrenched).
  - Naming in year-month-day-subject.txt consistently will allow filesystem search to find the note you want, and dates are retained despite the copy tool used.

I can vouch for that. I got some algorithm questions in Seattle & developed a new best solution (It wasn't a known solution before). Did I get the job? Nope.

There's something like that for drive encryption (in-case someone gets your hard drive), but programs that are running are intentionally past that restriction.

Programs communicate with one another, with servers on the Internet. If it sends-out more data then it should, you can't do anything about it if it's from a closed-source client. If that server shares more than you'd like, you can't do anything about it either. The closed-source client (& client OS) prevents the verify stage of "trust, but verify".

No scientist trusts an experiment it can't verify (or isn't even given steps), so you can't trust the experiment of secure data if you're not given what steps are occurring.

Try propping it up, adding a bluetooth keyboard, and visiting something like Project Orion or Cloud9. It's close enough for web work.

On the web we have tens of languages on the server side communicating to browsers & crawlers. Crawlers are written in nearly every language.

How did we do it? A standard protocol.

So, stand up 2 programs, have a standard for message passing, and continue working. Forget library-like integration: you don't want some giant code in your process space anyway.

- Testing is simpler.
- Fractional deployment is equal to having DLLs, but simpler resource file management.
- Crashes are easier to debug, and far less insulation is necessary for a good overall experience.
- Scalability becomes simpler.
- The initiator of an internal issue can be hard to determine, but many solutions exist & it's often unnecessary to know.

Summary: Do one thing, do it well

I have 7 years of "Lotus Notes" experience. Now I was maintaining the Lotus Notes codebase, so I advertise that as C++, NoSQL (it is), Interpreter maintenance including Java, SSL implementation experience, RFC standards compliance, format conversion, etc.

Upsell the still-modern things you did with the obsolete software. Unless it's open-source, it's not like you're taking the specific code experience with you anyway, and they can change it to obsolete your experience anytime.

It's mostly Windows. If I bought that, it would be to sell a compatible Windows competitor.

Agreed, I'd much rather an autonomous car be driving us to the hospital/emergency-care while the would-be driver can be on the phone preparing the destination for their arrival.

Step 1: Ensure your whole toolchain (libraries, tech, etc) is either open or too commercially essential/purchasable to obsolete (Win32 libs).
    Proof: There are old PHP code that hasn't been touched in 10 years but can be improved easily.
    More proof: When the incompatible Python 3 came out, years went by where the other environment was maintained, and now for most code you run the converter and you're set. No commercial interest would have taken that much care.

Step 2: What is BIG? _Size-big_ On most resumes for the field big.
    Proof: Oracle's Java interpreter is so insecure that you can't use it in browsers anymore, yet it persists everywhere it can because the engineers know it.

Step 3: Don't put a lot of dependent code on-top of it
    Frameworks don't last, but neither does the product you're creating. If you don't have much code atop the framework, moving to another will be easy. If it will take a lot of code to make your tech work on a framework, it's better to fail fast. Keep your code atop the framework modular so you know where your integration points are.

Step 4: Be the integrator.
    If you rely on many small libraries (who doesn't), be sure you are-or-run the glue and not their compatibility. It's more code, but allows you to entirely replace a library that doesn't live up to your changing needs.

Step 5: Model Linux's ecosystem: standards win since they're multiply-implemented.
    As the most research-able long-lived full system, you see lots of libraries, fickle front-ends, separate long-running processes (daemons) to manage long-running and security-intensive operations. Large programs are broken into smaller programs which are each audit-able, replaceable, reusable, easier to divide labor, etc. Programs with the longest life depends on standard wrappers like the C libraries (which many libraries implement identically-enough) and not on the fickle kernel /proc sources of the C API wrappers source from.