johnm

No. Not even close. Did you bother to actually read the Common Clause FAQ? Here are the first 2 FAQ entries:

"What is Commons Clause? The Commons Clause is a license condition drafted by Heather Meeker that applies a narrow, minimal-form commercial restriction on top of an existing open source license to transition the project to a source-availability licensing scheme. The combined text replaces the existing license, allowing all permissions of the original license to remain except the ability to "Sell" the software as defined in the text.

This Clause is not intended to replace licenses of existing open source projects in general, but to be used by specific projects to satisfy urgent business or legal requirements without resorting to fully "closing source".

Is this “Open Source”? No.

“Open source”, has a specific definition that was written years ago and is stewarded by the Open Source Initiative, which approves Open Source licenses. Applying the Commons Clause to an open source project will mean the source code is available, and meets many of the elements of the Open Source Definition, such as free access to source code, freedom to modify, and freedom to re-distribute, but not all of them. So to avoid confusion, it is best not to call Commons Clause software “open source.” "

"Abstract Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner.

This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006–2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data.

In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism."

How are you going to deal with underlying "sources" where the content disappears or is changed out from under the fact checkers?

Indeed. And that's a sad testament about humanity.

Hahaha! You must be working with folks (pm, dev, qa) that do a lot more than just hack away. Or perhaps I've just been working too much lately with big enterprises. :-(

Commodore GEOS was created by the same company as PC/GEOS. I only worked on PC/GEOS.

Technologically, no. Business-wise, I don't recall.

There was a standalone version that was sold on disks as AOL. GEOS was completely hidden from the users. I.e., it was AOL's GUI.

We had some fun times playing heads up Tetris competitions in the office.

It was extra fun when one of the guys checked in a hacked version with some special keys to cheat that only he knew about. :-)

I doubt it. Ours was written in our homegrown x86 assembly language for our own OS kernel.

Actually, to be more clear... The original graphical AOL client for the PC was a PC/GEOS application. It booted GEOS and straight into the AOL GEOS application.

PC/GEOS didn't have virtual memory the way people think about it--it was a handles based approach so that memory could be moved when it wasn't being actively used.

Actually, v1.0 of PC/GEOS ran on an original IBM PC with 512K RAM. Later versions required 1MB and more.

It was similar to the Motif L&F but it was all implemented from scratch in the x86 assembly version.

We cross-developed. The host machines were Sun workstations where the dev tools and Swat debugger ran and talked to the PC target (remember that we started with PC/GEOS running on an original IBM PC with 512K of RAM).

Yeah, that's been my experience, too (on both counts).

Emacs ftw!

Have you tried LightTable yet?

For those who've tried cpap machines and struggled with the masks, try the so-called "nasal pillows". They are a lot easier to get a good, consistent seal; are much smaller and so don't trigger that "omfg their's an alien on my face" freak out in the middle of the night; and they allow for more variety of sleeping positions.

It's a definite help but no.

Get rid of the stupid "certifications".

Clarity. Expressivity. Simplicity.

Searching for security vulnerabilities is even more humorous. :-)

I had so much fun demo'ing that ability at a PHP conference one year.

Regular expressions are the wrong tool for this job.

For Krugle, we actually parsed the various languages so it actually knew the differences between e.g. definitions, invocations, comments, strings, etc. It affords the capabilities to do all sorts of cool queries and analyses.

We did that with Krugle awhile ago. It's still alive as an enterprise product... http://krugle.com/

Makes the choice of using them that much easier. :-)

Indeed and even more... The entire GEOS operating system, gui/windowing system, application suite, and the vast majority of the rest of the apps were written in 8086 assembly language and ran on an original IBM PC.

In terms of this point, the lack of closures forced one to NOT write that messy garbage of code that people complain that the newbs are doing in node. I.e. it forces one to separate out the behavior from the construction and so systems (rather than off-the-cuff demos) are cleaner and easier to read and maintain.

People generally have two high-quality stints in them per day. Putting in a sleep cycle (be that a power nap or up to a full cycle) between them works wonders for all sorts of benefits physiologically and creatively.

It depends on the person but it's true for me. I tend to do my really hard/deep thinking in the morning and queue up stuff that I can do the rest of the day. The creativity that tends to appear more often later in the day and in the evenings end up being the cool stuff that bubbles up.

Yes, in the morning it's so quiet that I find music distracting.

The one thing I've added is a nice room air filter and run it on low. The quiet white noise from the fan provides a smooth background.