“We Are Morons” – A quick look at the Win2k source (2004)
atdt.freeshell.org
atdt.freeshell.org
But in fact what you did was rational in its own way. You enjoyed blogs in the beginning, as long as they were easily accessible by an aggregator. When the user friendly aggregator went away, you decided the blogs didn't offer enough good content to justify the increased management and use of your time.
I loved Google Reader. But now Inoreader is better than Google Reader ever was.
Link to the last time I posted this comment:
https://news.ycombinator.com/item?id=16285449
(Seriously - if you liked RSS try Inoreader)
Also, I have no connection with Inoreader whatsoever. I wish I did. Great product.
Advantages: It's neither a web service that will disappaer tomorrow, nor a browser extension that ties you to a specific browser.
Off-Topic: As with most websites, I had to visit an "About" sub page to get to the description what it does. Why?! Shouldn't this information be the first you read when you open the main site? It's almost the same nonsense as with so-called "landing pages". If a company's main site doesn't qualify as landing page, why do they create a separate sub page instead of just improving their main site? And some websites don't have any newcomer-friendly sub page at all - then there's Wikipedia to the rescue.
I’ve personally settled with feedly now but even now after all these years, it’s not up to par with google reader.
> Note: I actually don't know who ordered first. I just made up that part of the story to make it funnier. (Note that I make up parts of other stories, too. I'm not a historian. I'm a storyteller.)
It really made me rethink the value everyone places in the accuracy (or lack thereof) of storytelling.
[1] https://blogs.msdn.microsoft.com/oldnewthing/20130205-00/?p=...
And especially the FAQ about it: https://www.ibiblio.org/harris/500milemail-faq.html
> "You waited a few DAYS?" I interrupted, a tremor tinging my voice. "And you couldn't send email this whole time?"
> "We could send email. Just not more than--"
> "--500 miles, yes," I finished for him, "I got that. But why didn't you call earlier?"
> "Well, we hadn't collected enough data to be sure of what was going on until just now." Right. This is the chairman of statistics.
I hadn't read the FAQ before though! Thanks for posting these. This guy definitely has a lot of patience for putting up with all those FAQs about inconsistencies in his story...
I've been in the "movie industry" for decades and it still astounds me that people come out of the theater thinking what they saw, in most cases, is reality--even when the disclaimer "based on" is clearly shown ahead of time.
I can't exactly fault them as "based on" seems to be more of a marketing gimmick used to imply some form of authenticity rather than an actual disclaimer. For the longest time I fell for the fallacy that "based on" implied some semblance of factual accuracy.
Something that is inspired by something is also based on that thing.
This seems false? If iPhone was inspired by Blackberry (no idea if it was) that doesn't imply iPhone was based on Blackberry.
Inspire -- give rise to -- stimulate, motivate, spawn, engender.
Based on -- rooted in -- built upon, be founded on/upon, be anchored in something, rooted in.
-
A hamburger inspired the design of the Millenium Falcon, the ship is not based on hamburgers. A comic book inspired the movie 300, which is only loosely based on the comic and historical fact.
A story that is based on specific events it must build upon those events. A story that is inspired by something has no presumption of content, only that some facet of it motivated the storyteller somehow.
So while, yes there is nuance, they still broadly mean the same thing: you actually just gave two examples agreeing with me.
And directly conflicting definitions are not "nuance". You are missing a qualifier in order to make the point you think you're making (ie "the design of X is rooted in..."). You've also wilfully read past both examples in order to stretch this point.
Inspiration can not be understood as "rooted in". That is not how words or sentences work. The millenium falcon is not rooted in Hamburgers. "Imagine" is not rooted in Yoko Ono.
You know, just because someone uses swear words doesn't mean they're racist or homophobic...
Also, I don't find those comments terrible. If anything, maybe a bit childish.
The list included the obvious "dirty" words, and milder words like "idiot" and "moron". Surprising inclusions were references to the DOJ, the Microsoft consent decree with the DOJ, and Janet Reno.
Oh, and be careful of your messages in debug/trace statements, should your client decide to have a look at those ever-growing files.
Then someone shared the source code in question with Sharp (as sample code or something), and they found the comment.
Many, many apologies later, $mike was able to laugh about it, though I don't believe he ever felt unjustified. This may have been the time that he decided that his unofficial job title in Newton was Official Scapegoat. "Feel free to blame me for anything that goes wrong. I won't do anything about it, but at least you can blame someone."
Teams cranking 80+ hours a week on a project for a year or two are just gonna vent. It's perfectly healthy.
The new owners shared a look between themselves...
This is one of the easiest ways I have found to distinguish mature coders and immature coders (green, rookies, whatever): read their test data entry.
New coders write all kinds of cute things, little data entry stories (test1, test2, test3whyisnothingworking), and frequently put in jokes or witty things... Longbeards have all, at one point or another, had a customer/management see something inappropriate and know it's a bad idea. More importantly, they've worked on too many systems to spend time thinking up cute ways to manually test if their CRUD operations are working.
I think it indicates that the people writing them felt comfortable enough with their environment team that they could talk freely.
Stuff like:
"if this alert fires you should start an incident and page teams X Y and Z before you page $alert_author."
"if this alert fires and we're not switching between active and standby data-centers then you should update your resume and begin the process of failing over to the standby datacenter"
"this is a terrible hack because this is a terrible legacy system and the worse it is the more incentive the remaining (internal) customers have to move to the new system and the author's time is better spend building good code for the current system"
"this process is specifically designed to be a massive pain in the ass in order to encourage you to do $stuff ahead of time and not rush it through in the last minute"
There's talking freely and there's writing childish or unprofessional comments in the source code. It doesn't take much to keep code comments clean and you can still vent to your coworkers in other ways.
The example comments you wrote all seem ok to me though, except the second one, which just comes across childish or dickish. You can say the same thing and be blunt about it without suggesting someone should be fired for doing what you don't want them to do.
But hey, that's just my opinion on the matter.
Where does it ever imply that? It says racist and homophobic slurs, not just swears like "fuck" or whatever. And yes, if one uses bigoted slurs, then one is a bigot.
> there are limits to how far the programmers go
I read it as - "I suspect they think of what I'm mentioning next, but limit themselves in what they'll actually type."
btw, Microsoft's original reaction to the leak:
https://news.microsoft.com/2004/02/12/statement-from-microso...
Why should Microsoft produce a hack for an IBM antivirus product? That IBM software might be used by a few tens of thousands of people for a few years, whereas Win2k impacted billions of people and will continue to do so.
At some point it is likely the programmer, PM, and maybe even the bug tracker behind this code may have moved on, and a newer generation of contributors will have to waste time understanding the bug, and deciding to support it or not. Possibly without ever knowing if IBM has fixed their own bug, or still uses that antivirus software or not.
Windows is still one of the most backwards-compatible systems you're ever likely to encounter. Sure, not everything works anymore, but you can still install a lot of software written for Windows 95 and expect it to still function. That's hugely impressive, given that we're not even running the same kernel anymore.
Unless you're doing shenanigans with ioctls to devices or direct access to kernel functions, the kernel does not really matter - everything goes through user32 and friends anyway, so as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much.
The problem is that you have to keep them stable to a much higher degree than you might think at first. Obviously you have to maintain the functionality as described in the API documentation but that is far from enough. If the implementation has a bug, you can not simply fix it because there might be software either relying on the wrong behavior or having implemented workarounds that you might break with the fix. And no matter how often the API documentation states that this or that is not supported or undefined behavior there will be software doing it anyway or relying on what ever undefined behavior meant in the version they developed against. You return a list of something and say nothing about the ordering in the documentation but as an implementation detail it happens to be in some specific order, if you wait just long enough there will be a program critically depending on the ordering you choose. This is an endless nightmare especially if your APIs have as many different consumers as the Windows APIs.
Backwards compatibility used to be the norm for most stuff, didn't it? In the 80s/90s. You didn't need to get a new computer every few years. Now if there's a problem, the solution is easy - "Buy a new computer/phone/iPad."
I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility.
The king of backward compatibility is probably IBM. AFAIK, their mainframe operating systems can run unchanged software from before MS-DOS was born.
Seeing as most of IBM's largest customers are banks and other places that have no interest in rewriting battle tested software, it's probably the reason that their mainframe department is still alive.
Here's Bob Dole's 1996 campaign site: http://www.dolekemp96.org/main.htm
Browsers are on every platform, and for the most part different platforms require no different code for your web application to work. Mobile vs Desktop, Android vs Windows, you get it all.
Since we're talking about the lengths Microsoft goes towards backwards compatibility: https://msdn.microsoft.com/en-us/library/aa384143(VS.85).asp...
"For older applications that use a 16-bit stub to launch a 32-bit installation engine, 64-bit Windows recognizes specific 16-bit installer programs and substitutes a ported 32-bit version."
(However, this is not always enough: https://davidcmoisan.wordpress.com/2010/02/18/16-bit-install...)
Right, I have one 1997 videogame that uses InstallShield 3.0.95.
Microsoft actually has a reasonably close relationship with large companies that develop on their platform. eg, their plug fests for devs to come put their stuff onto the same machine and see how they all inter operate on new versions of Windows. I used to work semi-closely with someone doing Windows driver work. He knew a lot of quirks in the platform and even could escalate to the point of getting help from kernel engineers.
This may answer your query. Microsoft takes (took?) user-friendliness as the most sacrosanct thing. Breaking a user's apps is the biggest anti-user thing to do. In hindsight, it has maybe turned out that taken to extremes this approach is not sustainable. But I agree with the basic logic.
glibc and a handful other libraries are also careful not to break binary compatibility, providing versioned symbols for old binaries.
Beyond that it tends to suck, with some libraries not even bothering with sonames.
If they had not then the forced timed restarts of Win 10 (30 minutes and kiss your work goodbye), along with forced updates would not be a thing.
If a user upgrades their OS and something breaks they blame the OS upgrade.
However, if someone claims to write self documenting code, and by that think it's enough to have long variable names and skip comments, then I can understand the sentiment above coming into existance.
In "identifiers are comments" paradigm the goal isn't only to just skip comments, but also to structure the code in a way so that it's as clear as possible what it does and why. This helps much more than a long comment block hidden somewhere in a big ball of spaghetti code.
Comments aren't a panacea either, as they take effort to write in a helpful way, often only occurs once (so you'd have to find the place where the purpose of x is defined) and of course, often are some level of wrong/outdated in relation to the purpose/function of the code.
Sometimes, it's not possible to write the code in a way that is clear, this could be for compatibility reasons or performance reasons. That is when comments really come into their light.
http://webcache.googleusercontent.com/search?q=cache:EhC7uFJ...
Hyrum's law states: "With a sufficient number of users of an API, it does not matter what you promise in the contract, all observable behaviors of your system will be depended on by somebody."
This is going to be awesome.
Lots of cool stuff in both; the NT 4 leak had a lot more of the cool kernel stuff, like a DEC Alpha HAL.
I don’t recall the links and won’t share them. I also notified Microsoft about them when I found them, so they may have been taken down already. But it’s the internet so realistically they’re still up somewhere.
You can also find the Windows Research Kernel, which is slightly sanitized and leaves out NTFS, HAL, PnP, and power management, but is slightly newer coming from the win 2k3 era.
Or is this not feasible due to factors that we non-programmers wouldn't understand?
Also, hindsight is a wonderful thing.
> Despite the above, the quality of the code is generally excellent