chipx86

I love that! Thanks for sharing that with me :) It made my day. Looking forward to the second part! If you're on really any of the current social platforms, I'd love to connect. I'm chipx86 everywhere.

I still develop Review Board full-time with a small team :) The development world has changed a lot, and much of the world has converged on GitHub (it's a hard market to be in right now), so we still look for opportunities to build review capabilities that target problems people have that aren't being addressed elsewhere.

Just as an example, we launched PDF Review and diffing a while back, which we see companies use for things like industrial designs and schematics. It's neat, we actually diff two rendered PDFs without just converting them into text files first, like you usually see. Following that up with full Office Document Review soon.

Dark mode finally shipped earlier this year (I should write about that endeavor sometime). And there's a couple of super-neat code review capabilities we've come up with that nobody's doing, which I'm keeping under wraps for next year. I think they're going to be pretty awesome.

We first built interdiffs in Review Board [https://www.reviewboard.org] way back in 2006 (in fact I think I may have coined the term, or arrived at it independently). It's still my favorite part of the product and my process when doing code reviews. And it's one of the things we hear the most nostalgia for when people move to something like GitHub.

I've never felt that fix-it commits are really a proper alternative, since:

1) They don't tell you what upstream changes have been incorporated into a series of commits.

2) They tend to mess up the commit graph, even if temporarily, and make it more difficult to review. If you've been following along with a review, you may have already read the code being fixed in fix-it commits, but if you're coming in fresh, you may start off with a bad sense of what that code's trying to do or how it's structured.

3) Not everyone uses Git or other multi-commit-capable SCMs. Plenty of people are on Perforce (such as in gamedev) or on specialized SCMs like Keysight SOS (such as chip manufacturers). So fix-it commits aren't even an option there.

A proper interdiff-capable code review systems means one reviewer can start off from the first published review request and follow along with every update, seeing only what's changed, while another can jump in to the latest full change and not have to worry about the series of fix-its that led up to it. And it can do this regardless of the SCM.

If done right, it can also exist alongside multi-commit changes.

Let's say I have a small project I've broken up into multiple commits to help with the review process (say, an API handler, front-end UI, and documentation), and have decided this is suitable for posting as one review request (since the commits are largely interrelated and having these as one change helps lend context to the reviewers — if they aren't, multiple review requests in a dependency chain are probably ideal).

Based on review feedback, I may end up making a series of changes to one or all of those commits. When people go to review my updates, it's nice to be able to see how each piece evolved, without trying to do the mental arithmetic of mapping fix-it commits and their changes to their corresponding changes.

So yes, interdiffs are fantastic! More people should use them, whether they're working with lots of small commits or large commits, single-commit review requests or multi-commit.

This was a hard-learned lesson for young me.

Early in my career — and in my teens — I was doing web design for local businesses. It was the late 90s/early 2000s, and the Internet was taking off, and people wanted websites. I have plenty of stories from this era, but today, I'd like to talk about Demmer.

(That's not his name, as I want to preserve anonymity, but it's close.)

Demmer was an old man, retired, and excited by what the Internet could do for him and his organization. They were, he told me, building a state-of-the-art retirement center. And what a retirement center it was. It offered every luxury. Five-star food. Movie theater. Staff tending to your every needs. A better living environment than you'd ever have had pre-retirement. They had Dot Com billionaires investing. It was HUGE!

(Best I could tell, this never existed in any form, sadly. Demmer was the sole representative, and I began to suspect this was more wishful thinking than anything.)

Demmer's ask was simple: Take a document he wrote and put it up on a website. Easy. Shouldn't take long. I billed him up-front for the full cost — a couple of hours of work.

A couple hours that took a month. To send a document. With daily, angry voicemails.

I began to call this lovely interaction the "Daily Demmer."

He'd send an e-mail with the document, and the e-mail would be blank. I'd reply, and he'd respond via voicemail explaining I must have done something wrong. I'd respond with a voicemail of my own, asking what he tried, and that I'd help. He'd get defensive, say he knows how to e-mail! He e-mails all the time!

His voicemails graduated to long, expletive-laden rants within a week.

Finally, I got him to walk me through his attachment process.

Step 1: Open the document. Step 2: Compose an e-mail to me. Step 3: Place the document on one side of the screen, the e-mail on the other. Step 4: Hit send.

"Ah-ha. Well, I'm sure it made sense to him. I can set him straight," I stupidly thought.

I walked him through attaching the document. Find this button, click it. Find your file. Click Attach. He nods along over the phone. "Uh huh. Okay. Got it." Good, good, this is working. "I'm hitting Send."

I received an empty e-mail.

Turns out, he had dug in his heels. He knew e-mail! He sent plenty of e-mails with documents to all the investors. And he did so with the same steps: Place both on the screen, hit Send. I'm just a kid, what do I know?

Rinse and repeat for weeks.

Eventually he drove to town and just angrily handed me a printout.

I got the website up within a couple hours.

He canceled his hosting within a month. I never heard from him again.

Very cool! Which client did you write?

I had forgotten they tried to standardize the protocol!

Yeah, it was surprisingly easy. Connect to the switchboard server, set up sessions from there, and then it's all MIME. We even implemented avatars for Gaim by chunking Base64-encoded images over MIME messages (they had a max length), which MSN would ignore but Gaim would use.

We never had any trouble from the MSN team. Rumor had it at the time that at least one dev on the team was secretly a Gaim user, and they just looked the other way.

I used to work on Gaim/Pidgin (and in fact created libgaim/libpurple) back in my college days.

It was easier for us to build and maintain back then. We had push-back from some of the companies (Yahoo being notoriously aggressive about it, to the point of actively banning our developers' accounts and inventing new obfuscated auth schemes all the time), but from a technical standpoint:

1. Most of these were communicating over plain text channels (making it easy to sniff traffic from official clients)

2. The protocols were generally understandable (MSN for a long time was largely all MIME-based messages, and could be understood by watching a traffic stream)

3. Used simple usernames/passwords for authentication (just fewer hoops to jump through)

It's a different world nowadays, with more focus on keeping you in the chat environment and offering additional features as part of that experience. Harder to abstract a lot of that out.

That said, Gary Kramlich's been working on this diligently. (If interested, he also regularly streams development over at https://www.twitch.tv/rw_grim).

Alma in midtown, and it was pretty noticeable here. I'm on the second floor and for the first time in ages, I didn't think it was just Caltrain.

I'm using the fork here: https://github.com/magnusviri/stable-diffusion.git (apple-silicon-mps-support branch).

Pretty easy to set up, though I had to take all the Homebrew stuff out of my environment before setting up the Conda environment (can also just export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 GRPC_PYTHON_BUILD_SYSTEM_ZLIB=1, at least in my case).

Otherwise, I followed the normal steps to set things up, and I'm now here generating 1 image every 30 seconds at default settings. This is on a M1 Max MacBook Pro at 64GB RAM.

Hi! Yep, I think you're right :) That sparks a memory.

Indeed. Originally it was "GAIM" (due to the original purpose being a GTK+ AOL Instant Messenger client), which AOL wasn't thrilled about. We changed it to "Gaim", which I think they had less of a problem with, or at least we had hoped they would.

Internally at least, we called it "Gaim's An Instant Messenger". I'm not sure if we formalized that or not. It's been too long.

And then to fully move away from that branding situation, it was renamed to Pidgin. This was mid-2000s, after I moved away from the project, so I don't have any insight into the name change beyond the history.

Good times for sure!

This was a problem even back when Gaim (now Pidgin) was at peak popularity.

I used to be a dev on the team, and we had our accounts banned all the time. Some of the IM services didn't mind us being there (MSN seemed more than fine with it, and we reportedly had fans within the team there, though future protocol versions made it harder for us to figure out).

Yahoo wanted us off and did everything they could to keep us from connecting. Changing auth schemes to increasingly-elaborate obfuscated methods, at one point throwing pages of what looked like equations at us.

AIM would have been fine with us if we had used TOC (their open source protocol), but OSCAR is where all the features were at. They didn't outright ban clients, but my understanding is that their lawyers were involved at one point (though I think mainly due to the name "GAIM").

But you're right, they are removing third-party clients more. And fewer protocols are unencrypted plain text, which makes it harder as well. Still, work continues.

The source code, along with all other assets, were sold to Symantec in the late 90s. My uncle doesn’t have any copies of it, and so much time has passed that there aren’t any contacts at Symantec to ask (if Symantec even preserved the source to begin with — they didn’t buy the company for DESQview).

Early in my career, I did work with a former employee of my uncle’s, who worked on DESQview/X back in the day, and we spoke a lot about that time. If he had the source stashed away someplace, he never admitted it.

I wish I could offer more hope than that. I want it too :/

Thanks for understanding :)

It's on my task list for the holidays.

That's a shame :/

Looks like I commented on that thread way back then. And I think my comment there was at least mostly correct. I was always under the impression that much of the core of the product, the interesting bits, was done in assembly, or a layer on top of assembly (they used something called SYMPL in the DESQ and DESQview eras, but I'm not sure about DESQview/X). This would have been for performance and memory constraints.

I'll have to call and get clarification on all that. I might be mistaken.

In the later years, Quarterdeck transitioned to building DOS and Windows applications like CleanSweep. That was the era when Symantec bought them. I always got the impression that DESQview wasn't really an interest of theirs. It would be interesting to know what they would have done with the source in that era.

I plan to, but I want to run it by my family before I commit to a permanent record on archive.org. They're fine with sharing when it comes up, but, you know, due diligence.

There are no strings to pull.

The company was sold to Symantec back in the late 90s, I believe, and he retired (for the most part). At that point, he no longer had the source code. Symantec eventually closed it down. Given the state of things like version control back then, I would be surprised if anybody has that source.

If I thought I could get it, I'd have asked for it loooong ago :)

This was a wonderful surprise. DESQview (and anything early Quarterdeck) holds a special place in my heart.

My uncle, Gary Pope, co-founded the company. I grew up with DESQview and QEMM as two of our primary pieces of software running on our computers.

I moved onto Linux many years later, and used to have a Linux box as my primary machine, but with a DOS computer sitting next to it, DESQview/X loaded up, and would use DESQview/X as a makeshift second monitor by using it as an X11 display server.

DESQview/X was based on X11R5, I believe, rather than X11R6, so I was a bit limited in terms of which software worked, but terminals were just fine.

Anyway...

A while back, I assembled all the DESQview/Quarterdeck material I had sitting around and put it up for others to look at. There's some stuff in here that you won't find anywhere else:

https://www.dropbox.com/sh/htvf2edf3mrx0be/AABllqVhf0BzOytup...

There's a README with some background, screenshots, marketing material, photos, product reviews, and even a paper that my mom wrote up about DESQ (the precursor to DESQview and DESQview/X), with a little bit of background on its development, back in 1984.

Hope it proves interesting! :)

When I was first learning about network programming, I used to pour over your guide (hosted locally on a Chico State account at the time, if I remember correctly), absorbing every detail I could fit into my young mind. That was... more years ago than I want to think about, but I'm glad to see the guide continuing to get updates!

And I'm also glad for the opportunity to directly thank you for the work you've put into this over the years :)

That's correct, and I've verified it with modern versions of pip for Python 2.7 and 3.x. `pip2.7 install -U pip` just grabs pip 20.3.4 and installs it, ignoring pip 21.0.

pip and the legacy easy_install both access the "simple" list for a package when determining download options. This is a basic HTML page with links to all public versions of a package. Here's pip's: https://pypi.org/simple/pip/

These links contain Python version specifier information, which pip can use to select an appropriate version. For pip 21.0, that specifier is ">=3.6", so any modern pip will know it can't be used on a Python prior to 3.6. It will therefore fall back to the nearest version that provides a compatible specifier.

Looks like this was implemented starting in Pip 9.0 (at the end of 2016). From experience (my product is written in Python), there are plenty of enterprise installs that still use much older versions of pip than this. Those will grab pip 21.0 or newer (I just confirmed with a copy of pip 8).

I know for us, that'll be important to document. We still support Python 2.7 in part due to slow-moving enterprise installs, and I'm sure we're not alone in that. So geofft's example for forcing installs to <21 is exactly what a not-insignificant number of people will ultimately need to do.

This typo-laden response brought to you by Very Little Sleep.

If it wasn't obvious, libgaim became libpurple, not the other way around. Too late to edit the parent comment, but felt I should clear that up.

So, aside from Jabber, IRC, and the AIM TOC protocol (which was the weaker version — we used OSCAR, which was not open), we had to reverse-engineer most of the protocols, and keep up-to-date with changes. Often these services actively tried to block us, and we would spend weeks or months working around their changes. Yahoo was notorious for this.

It's not entirely different than the current situation, in that regard, but there was also less security baked in on the older services, and much of the protocols were in plain text.

It's funny. I was just reminiscing about all this a few days ago on Twitter. https://twitter.com/chipx86/status/1352371276464050181

While I'm out of the IM game (gaim?) these days, I'd be very interested in any modern attempts to reverse-engineer these modern services, and whether the pushback from companies would be any different.

It was.

I worked on Pidgin (Gaim, at the time), and was the original author of libpurple (now libgaim). Adium was a sister project that was originally completely different, but utilized some of our Protocol Plugins (aka prpls — basis for the name "libpurple"). It later utilized libgaim when it reached a certain level of maturity.

I don't know whether Adium eventually moved fully onto libgaim. I seem to recall it only used it selectively, but I stopped working on those projects years ago.

Been very happy to Pidgin's maintenance resume. Gary Kramlich's been doing a fantastic job reviving it, and I'm hoping the same will be done for Adium in time. We really need a modern multi-chat/IM client for the modern era.

I build Review Board (https://www.reviewboard.org/, https://github.com/reviewboard/reviewboard), an open source code review tool built on top of Django. It used to be a side project to fill what was at that time a gap in code review offerings (not even GitHub was around at this time), but these days it's a full-time job.

Like @encoderer and Cronitor.io, we also stuck with Django 1.6 for several years! YAY! Turns out the jump from 1.6 to 1.7 was a painful experience, but we're finally on the modern.... 1.11. Yeah, we're not getting rid of our Python 2.7 customers for some time (still trying to get some off of Python 2.6). Enterprise software development is a different sort of beast.

Our https://rbcommons.com service is Review Board as a SaaS, and uses Stripe. Curious to hear what you're doing with Stripe integration on your end! We've been making heavy use of it ourselves.

We've also done some crazy, fairly-complex, maybe-niche stuff in Django, and built these out into some libraries you might find interesting to browse through:

1) Djblets (https://github.com/djblets/djblets) — A big ol' utility library for Django that provides:

* Foundations for loadable extensions (just like browser extensions) for Django projects

* Support for defining flexible integrations for third-party services (Slack, etc.)

* Avatar support (gravatars, file uploads, URL-based avatars, and custom backends)

* Datagrids (with user column customization)

* A foundation for REST APIs

* Dynamic site settings

* Stuff to make privacy/PII/consent a first-class citizen in codebases

* And just a ton of other things that we found useful in Review Board and wanted to make more widely-available.

2) Django Evolution (https://github.com/beanbaginc/django-evolution) — A precursor to Django's migrations support (and the reason we were on Django 1.6 for so long — the in-development version cooperates with migrations now). We inherited and maintain this project. It provides an alternate way to specify database schema changes, and has the benefit of just being far faster to apply migrations, through a built-in optimizer. This significantly reduces upgrade times for large installs (super important for many of our Review Board customers).

All open source, and might be interesting to look at, who knows. We've built a lot up over the years (we started by writing code against Django pre-1.0 SVN checkouts), and I still recommend it.

This is awesome. ZZT was huge for me when I was young. I had already been toying with making games and desktop programs in VisualBasic by the time I found ZZT, but the ability to just throw together little worlds and play with the basic primitives the game gave us, share them with friends, was such an experience for the time.

I wonder how kids today would see ZZT. I think they'd have a lot of fun with it once they got into it, but being an older DOS-based game, ASCII art and all, might be particularly strange to some. A lot of modern games, Minecraft being one that immediately comes to mind, invoke the creativity and that ZZT did in my generation. Still, I'd love to see what people would make in ZZT today.

Tangent: I can't believe it was this long ago now, but about 10 years ago I started working on reverse-engineering ZZT with the goal of putting together a web-based implementation that was compatible. That spiraled out of control into a brand new project I called MWorlds (https://mworlds.wordpress.com/).

Haven't toyed with this in ages, but the idea morphed into an open platform for making web-based games, including all assets (sprites, music, script packs, monsters, weapons, etc.), that any kid or adult could build and share and use in their own games. I really should just open source this someday. Or start hacking on it again.

Thanks!

I'm very glad to hear that :)

Took your suggestion and updated the webpage!

I've updated the website and GitHub to point to GtkInspector as the successor. Hopefully that helps!

Ah yes, I remember this. We did see it and looked into it at the time (and I've just gone over it again). It's really a different problem than it seems. Not a security issue, but I can see where it'd look like it. Kind of a terrible quirk with the unreliability of diffs.

We discussed it internally, but those discussions never moved to the bug. I'll follow up on there, give you an overview of why you saw the behavior you did and our rationale.

Thanks for the poke!

Hah, well, wouldn't have expected to see this on Hacker News all these years later.

This got folded up into GTK+ years back as the GTK Inspector, so we dropped further development on it. They could do more with this being part of GTK+ than we could as a loadable module.

I also don't really work on GTK-based applications anymore, so it didn't make sense to continue development when I no longer had a vested interest in building new features for it. Instead, I build Review Board (https://www.reviewboard.org -- code review product) full-time now. Takes about 156% of my time.

The little Parasite bug lives on, though, as the mascot for Splat, a bug tracker we maintain for our needs (and might turn into a product someday). See https://hellosplat.com/tour/ for more drawings of the little guy.