gecko

My favorite alt time is definitely the ancient way of doing things: there are twelve hours during the day, and twelve hours during the night. Yes, this means that the length of an hour at night is different from the length of an hour during the day (at least most of the year). This system is still used in some oddball places (like certain aspects of Jewish religious law, and possibly Islamic law as well for all I know), but, having written such a clock once, I did kind of like that you could get a feel for where you were in the year purely based on how fast the second hand was ticking during which half of the day.

I will say that a lot of that RAM is going to creature comforts that aren't about apps getting worse per se. For example, everything is running double buffered images and windows in HiDPI. The era you're talking about, applications were in charge of redrawing their window whenever you exposed their contents/tabbed back to them/etc. If they genuinely needed double buffering, they'd need to do it themselves, so apps rarely did. Plus side, less RAM, downside, you would get gray nondescript windows and redraw errors when moving and resizing windows. Nowadays, Windows/macOS/Linux instead keep double- (or even triple-) buffered copies of all that. Throw on all the HiDPI images and whatnot, and you've already used up more RAM just on that one thing than the old apps used to take. But you can tab between apps with full previews, and you don't get gray blobs and tearing when an app is overloaded. Other things, like 64-bit pointers, or static linking becoming a common way to deal with DLL hell (sigh), also add RAM, but are also solving real problems.

I'm not really defending all those decisions or anything, beyond that it's not simply a case of lazy devs or whatnot. We made trade-offs as a community that genuinely improved the user experience. I may not agree with all of them, but I get why they happened, and don't spend a lot of time wondering why we used to need fewer resources.

Uh, that title is...wrong...

I'm in PowerShell 7.4.2 and they're definitely absent. I hadn't thought to install directly from GitHub, given part of the whole shtick of winget is it's The One True Package Manager and bundled, but I can't say I'm surprised, either...

I was super excited to see this comment, but I don't seem to have those cmdlets, even though I'm on Windows 11, fully updated. Are you sure you didn't install something extra?

I mean, it is a country of laws. Just...some of those laws are pretty bad. For what it's worth, the Court in this case is narrowly focused on correcting a lower court's interpretation of the Copyright Act, not something in the Constitution or something fundamental, and on a first glance, I at least feel that their conclusion is highly justifiable. That doesn't mean the Copyright Act isn't fundamentally broken (it is, on my opinion), but that's trivially fixable by Congress if we get appropriately minded representatives.

I'm not sure you understand how WSL works: it's just the native `curl` binary for whatever Linux distro you're using in WSL. On both Ubuntu and OpenSuSE, which are the two I have installed, --cacerts works as expected, because of course it does.

Separately, Microsoft bundles curl.exe as part of Windows since somewhere in the later Windows 10 or early Windows 11 releases, I forget which. This also appears to be honoring --cacerts.

So no, this seems to very much be an Apple problem.

I love the concept of Fossil being in SQLite, but there's a reason that Mercurial invented revlogs and Git tries to keep related objects close to each other in packfiles. Sometimes, you really do need a dedicated file format optimized for specific use cases. I'm completely unsurprised OpenBSD wasn't able to pull this off.

(Kiln split the difference by storing metadata in SQL Server, but keeping all the actual source data in their native formats. This works great, but is only really viable if you can guarantee things never get out of sync, which is basically impossible for random local Git repos.)

Isn't that literally just slightly different colors? I don't remember meaningful differences between OS/2 1.3 and the Windows 3 line. I always thought that was part of why WinOS2 worked well: the Win32 apps looked like the old OS/2 apps, both giving them familiarity and emphasizing they were old.

It hasn't changed radically, but it has changed. Wikipedia actually has a nice write-up if you want the details, but support for symbolic links, transactions, and partition resizing are all things that have materially improved my life in the last ~5-10 years.

It'll reset the engine control unit (ECU), which will cause your car to run rough constantly as the computer has to relearn how to adjust the engine tuning from scratch every drive. You'd be better served using a trickle charger.

I'm happy to always have London, but I could do with forgetting most of Cambridge.

    As an aside, I do think that targeting Mono was the right thing to do for
    the universe, as it butterfly-effected tedu into writing weird and wonderful 
    technical blog posts for the next ten years :p

I've never figured out whether that work broke him or was simply his muse, but I also do confess to liking the result. So not a complete loss.

    (Since you're answering arbitrary Fog Creek questions) In retrospect, do you 
    think it was a mistake to make kiln hg-centric at first?

No; I think it was a mistake to not also support Subversion out-of-the-box.

Our customers were overwhelmingly Windows shops, and Git on Windows in 2007 was just unusably bad. It really would not have been a viable option. (I did look at Bazaar and Fossil, which were good players on both Windows and Unix, but neither seemed like a good fit for other reasons.) But Kiln's core value prop at the beginning was actually code review, and I think we could've found a cool way to bring in a Phabricator-like patch workflow that would've meshed just fine with Subversion and given our customers a much easier way to get access to Kiln's goodness. In that world, Mercurial would be a kind of bonus feature you could use, not the only way into Kiln. The resulting product would've been very different, mind, but I think it would've gone way better.

The other three technical mistakes we made, since you didn't ask me, were having FogBugz target .NET instead of Java (given the immaturity of Mono at the time only; I love .NET); having Wasabi compile to C# instead of IL (especially given the previous note); and having Copilot directly modifying VNC and its protocol instead of just jacketing it with a small wrapper app. These three decisions collectively slowed the company down a ton at a time when we shouldn't have let ourselves do that.

I enjoyed working with you, Alex. Glad to see you doing well!

Everything you're asking about happened after I left, so I have no idea. I didn't even know they'd discontinued FogBugz for Your Server.

[Edit: We did discontinue Kiln for Your Server while I was there. We nuked that because the support burden was monstrous, to the point we needed three extra SDETs/sales engineers purely to handle testing and on-prem bug fixes. It threatened Kiln's ability to be profitable. The FogBugz team may've made the same calculus a few years later.]