This is not joking matter! Next up on the agenda is Oxygen sequestration, a noxious, highly reactive, corrosive gas that instantly kills most cells it comes into contact with and, in high enough concentrations, can set just about anything on fire!

And don't even get us started on dihydrogen monoxide!

Depends on whose code I'm editing.

If it's my own, then emacs.

If it's someone else's, then usually vi since I'm probably in a hurry.

IDEs I play with every once in a while, but invariably I hit some silly brick wall where it's better/faster/dareIsayeasier to bring it up in emacs.

I have been using notepad++ on Windows a lot lately, and just wondering what the closest thing to that there is on Linux. It's the only thing I've seen that combines the feature set of emacs with the snappiness of vi while still having a pretty consistent GUI. I have to admint I learned a lot about what emacs can do by discovering features and plugins in notepad++ and Googling how to do that in emacs :-P (speedbar, whitespace-mode)

Sublime Text editor was a lot of fun to play with if only for the multi cursor mode, but there's a great howto on doing the same thing in emacs.

Have you tried gvim?

(ducks before he gets yelled at for making people launch that abomination in X)

Eh, all good points.

I think the mistake was just in making it a heavy-handed ban. Bringing out the ban hammer just turned it into a joke.

I'm sure they will successfully reintroduce the behavior-modification measure by creating a higher sales tax on large drinks. Which will probably have an as good or better impact as a silly ban that people would gladly find ways to circumvent just to "stick it to the man".

We have these luxury taxes on alcohol that corresponds to the proof (one tax bracket for wine and beer, another for hard liquor). It could certainly work like that, and not come across as freedom-limiting nanny-statism.

>Stop allowing the perpetrators to hide behind the corporate veil.

Then what's the point of a corporation!? (See my sig. below.)

He'll be schmoozing with the various copyright cartel lobbyists, who'll be blowing smoke up his arse and whispering sweet little lies in his ears.

Recompense will come in the "you scratch our backs, we'll scratch yours" format at some point in the future. That's the way it usually worls: 'favours' for 'favours'.

Finally someone (of note) says what everyone has been thinking (and saying).

Without the ability to challenge, it amounts to totalitarianism.

Yes. We really need to take a hard look at network transparent displays in the context of what we can really do today as well as the future.

When I did this, 10T networks were common, and just a little slow for something like CAD. 100T networks were growing in popularity, and then we sort of jumped to 1000T.

Also during that time, I started on dialup, moved to DSL, and then more came.

Know what? The fiber connection I have in my home is fast enough to run X with few worries today.

And it's going to improve more. My 4G cell phone can run X too. Amazing!

Honestly, I miss the vision our early innovators had. In a way, the field was more open and people could build without so many legacy ties. The need to incorporate those into the next step is holding people back. Legacy "screen scrapers" should get attention. They are useful, and they do have advantages for application developers.

Network transparent, multi-user, concurrent multi-processor, networked computing is the bar to cross, and if we don't maximize it, we risk losing out on a lot of the potental.

Sad really.

All I know, is I won arguments back then, and I did it on UNIX when the dominant move was to Windows and the PC, and all that distributed software bullshit we face today. Won solid. No fucking contest.

The difference was really understanding how things worked and applying that instead of following the cookie cutter stuff we see being done so often today.

With X, one can distribute or centralize as needed!

Fonts on one machine, window manager on another, application on another, storage on yet another, graphics server on yet another, or even better, how about a few displays, each capable of serving a user?

Or, pile it all on one box somebody can carry with them!

Doesn't matter with X. It's all trade-offs, and this leaves people to structure things how it makes best sense to them. For some, having very strong local compute / storage / graphics / I/O is best. For others, centralizing that pays off the best.

Only X does this. Nothing else does, or has.

The screen scrapers are impressive, but they really aren't multi-user in the sense that X is, and that requires a lot of kludges, system resources, etc... to manage things.

I remember the day I read about X in BYTE. It changed how I viewed computing, and when I got my chance, I went for it whole hog and it paid off very well.

Also IMHO, part of this vision really should be to provide developers with dead simple tools to get things done. It is true that building an efficient network aware application takes some work. SGI, BTW, did educate people. If you developed on IRIX, you got the tools to make it all happen, and you get the education and consulting of a vendor who knew their shit cold.

Today, we don't have that surrounding X, and it's hurting development pretty big.

Back in the 90's, I was doing video conferencing, running things all over the place on lots of machines, melding Linux, IRIX, Windows, etc... together in powerful ways, often using machines secured from a dumpster. No joke.

We've managed to cobble that together again, but it's a far cry from what could have been, and could still be with people thinking this stuff through like it was the first time.

IMHO, the other real problem is as I've stated. We have a whole generation of people doing this stuff now who basically have no clue! They were never introduced to multi-user computing properly, never got to experience X as intended, etc...

When I explain some of this to people, they make comments like, "sounds like Star Trek" and "amazing", "wish I were there..."

Yeah. I was. Many of us here were.