8 ms·

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.

MrBuddyCasino 3y ago
People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.
- jsnell 3y ago
  That's actually a hilarious example (in the "hilariously wrong" sense), because Jeffrey Snover had to accept a demotion to make PowerShell. He was told it was a useless project, not fit for someone at his level to work on, and bumped down a level when he persisted.
  - pi-e-sigma 3y ago
    But then he got a promotion. So it was a calculated bet that paid off.
  - MrBuddyCasino 3y ago
    Interesting, because a Windows kernel hacker told it differently [0]: These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. (That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.) [0] https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
    - jsnell 3y ago
      Here's a source for my claim: https://news.ycombinator.com/item?id=31302174 https://news.ycombinator.com/item?id=31302174 (I'd heard the story in person from Snover years before that, so it definitely wasn't just sour grapes from somebody about to leave the company.) I can totally believe that MS had a culture where making improvements to cmd.exe was impossible to justify, but that doesn't actually mean that a greenfield project in the same space would be considered promo-worthy either. It seems more likely that everything in that space was viewed as career suicide and you needed to be working on Internet stuff, just like at today's bigco anything except AI will have the same problem.
- aetimmes 3y ago
  cmd.exe is a terminal emulator and PowerShell is a fully-formed scripting language (that Windows desperately needed). This analogy doesn't work the way you think it does.
  - dragonwriter 3y ago
    > cmd.exe is a terminal emulator Isn't Windows Console the (old) terminal emulator, with cmd.exe being just the command-line interpreter.
    - jkrejcha 3y ago
      Yeah, conhost.exe is the old terminal emulator effectively (cmd.exe being a shell). Before that, csrss.exe handled terminal emulation (which is why console windows weren't themable[1]). [1]: https://devblogs.microsoft.com/oldnewthing/20071231-00/?p=23983 https://devblogs.microsoft.com/oldnewthing/20071231-00/?p=23...
  - pi-e-sigma 3y ago
    cmd.exe can be used with shitload command line utilities and is a full blown scripting language just less powerful than Unix bash. The analogy works just fine.
  - waych 3y ago
    This is mixing up cmd.exe which is the dos-like (but not dos) scripting interpreter, and conhost.exe which is the actual old terminal emulator/console that the kernel would spin up whenever you ran cmd.exe.
- afavour 3y ago
  Wouldn't it be more likely that maintaining backwards compatibility (an important Windows trait, after all) while also implementing all of Powershell would be a considerably more difficult task than just making a new scripting environment?
  - pi-e-sigma 3y ago
    yes, too much to ask for a multi-trillion company, especially that this company was until recently well known for maintaining crazy level of backward compatibility
    - afavour 3y ago
      But… this is backwards compatibility. The command prompt is backwards compatible. Sometimes the best way to ensure that is to preserve in amber and replace.
pi-e-sigma 3y ago
[flagged]
- jsnell 3y ago
  Here's a third option: the five month old anonymous HN account claiming to know what the H2 designers were thinking of is wrong. How would you compare the likelihood of that to your two options? The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think, and that was already the case during the original SPDY design window. End-user networks had mostly been set up to buffer rather than drop. (I know this for an absolute fact, because I spent that same time window building and deploying TCP optimization middleboxes to mobile networks. And we had to pivot hard on the technical direction due to how rare packet loss turned out to be on the typical mobile network). The real problem with networks of the time was high and variable latency, which was a major problem for H1 (due to no pipelining) even with the typical use of six concurrent connections to the same site. Second, what you're missing is that even a marginal improvement would have been worth massive amounts of money to the company doing the protocol design and implementation. (Google knows exactly how much revenue every millisecond of extra search latency costs). So your "marginally better" cut isn't anywhere near as incisive as you think. It also cuts the other way: if SPDY really had been making those metrics worse like one would expect from your initial claims about H2 performing worse than H1, it would not have launched. It would not have mattered one bit whether the team designing the protocol wanted it deployed for selfish reasons, they would not have gotten launch approval for something costing tens or hundreds of millions in lost revenue due to worse service. Third, you're only concerned with the downside of H2. In particular HPACK compression of requests was a really big deal given the asymmetrically slow uplink connections of the time, and fundamentally depends on multiplexing all the requests over the same connection. So then it's a tradeoff: when deciding whether to multiplex all the traffic over a single connection, is the higher level of vulnerability to packet loss (in terms of head of line blocking, impact on the TCP congestion window) worth the benefits (HPACK, only needing to do one TLS handshake)?
  - pi-e-sigma 3y ago
    So again, why HTTP3 is pushed when HTTP2 was meant to be the holy grail? Seems that even Google doesn't consider HTTP2 to be so great.
KaiserPro 3y ago
> It’s not an error in thinking to assume a good faith basis Its nothing about faith here. I was looking at the evidence. The problem was that a lot of people I was working with had faith that SPDY was something that it wasn't. They either interpreted what I was saying as either an excuse to not change infra (the change was minimal), "old think" because I was not a hot young fullstack node engineer, or that they thought I was trying to be more clever than google.

MrBuddyCasino 3y ago

People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.

jsnell 3y ago
That's actually a hilarious example (in the "hilariously wrong" sense), because Jeffrey Snover had to accept a demotion to make PowerShell. He was told it was a useless project, not fit for someone at his level to work on, and bumped down a level when he persisted.
- pi-e-sigma 3y ago
  But then he got a promotion. So it was a calculated bet that paid off.
- MrBuddyCasino 3y ago
  Interesting, because a Windows kernel hacker told it differently [0]: These junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. (That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.) [0] https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/ https://blog.zorinaq.com/i-contribute-to-the-windows-kernel-...
  - jsnell 3y ago
    Here's a source for my claim: https://news.ycombinator.com/item?id=31302174 https://news.ycombinator.com/item?id=31302174 (I'd heard the story in person from Snover years before that, so it definitely wasn't just sour grapes from somebody about to leave the company.) I can totally believe that MS had a culture where making improvements to cmd.exe was impossible to justify, but that doesn't actually mean that a greenfield project in the same space would be considered promo-worthy either. It seems more likely that everything in that space was viewed as career suicide and you needed to be working on Internet stuff, just like at today's bigco anything except AI will have the same problem.
aetimmes 3y ago
cmd.exe is a terminal emulator and PowerShell is a fully-formed scripting language (that Windows desperately needed). This analogy doesn't work the way you think it does.
- dragonwriter 3y ago
  > cmd.exe is a terminal emulator Isn't Windows Console the (old) terminal emulator, with cmd.exe being just the command-line interpreter.
  - jkrejcha 3y ago
    Yeah, conhost.exe is the old terminal emulator effectively (cmd.exe being a shell). Before that, csrss.exe handled terminal emulation (which is why console windows weren't themable[1]). [1]: https://devblogs.microsoft.com/oldnewthing/20071231-00/?p=23983 https://devblogs.microsoft.com/oldnewthing/20071231-00/?p=23...
- pi-e-sigma 3y ago
  cmd.exe can be used with shitload command line utilities and is a full blown scripting language just less powerful than Unix bash. The analogy works just fine.
- waych 3y ago
  This is mixing up cmd.exe which is the dos-like (but not dos) scripting interpreter, and conhost.exe which is the actual old terminal emulator/console that the kernel would spin up whenever you ran cmd.exe.
afavour 3y ago
Wouldn't it be more likely that maintaining backwards compatibility (an important Windows trait, after all) while also implementing all of Powershell would be a considerably more difficult task than just making a new scripting environment?
- pi-e-sigma 3y ago
  yes, too much to ask for a multi-trillion company, especially that this company was until recently well known for maintaining crazy level of backward compatibility
  - afavour 3y ago
    But… this is backwards compatibility. The command prompt is backwards compatible. Sometimes the best way to ensure that is to preserve in amber and replace.

pi-e-sigma 3y ago

[flagged]

jsnell 3y ago
Here's a third option: the five month old anonymous HN account claiming to know what the H2 designers were thinking of is wrong. How would you compare the likelihood of that to your two options? The main problem you're talking of is head of line blocking due to packet loss. But packet loss as a congestion signal is nowhere near as common as people think, and that was already the case during the original SPDY design window. End-user networks had mostly been set up to buffer rather than drop. (I know this for an absolute fact, because I spent that same time window building and deploying TCP optimization middleboxes to mobile networks. And we had to pivot hard on the technical direction due to how rare packet loss turned out to be on the typical mobile network). The real problem with networks of the time was high and variable latency, which was a major problem for H1 (due to no pipelining) even with the typical use of six concurrent connections to the same site. Second, what you're missing is that even a marginal improvement would have been worth massive amounts of money to the company doing the protocol design and implementation. (Google knows exactly how much revenue every millisecond of extra search latency costs). So your "marginally better" cut isn't anywhere near as incisive as you think. It also cuts the other way: if SPDY really had been making those metrics worse like one would expect from your initial claims about H2 performing worse than H1, it would not have launched. It would not have mattered one bit whether the team designing the protocol wanted it deployed for selfish reasons, they would not have gotten launch approval for something costing tens or hundreds of millions in lost revenue due to worse service. Third, you're only concerned with the downside of H2. In particular HPACK compression of requests was a really big deal given the asymmetrically slow uplink connections of the time, and fundamentally depends on multiplexing all the requests over the same connection. So then it's a tradeoff: when deciding whether to multiplex all the traffic over a single connection, is the higher level of vulnerability to packet loss (in terms of head of line blocking, impact on the TCP congestion window) worth the benefits (HPACK, only needing to do one TLS handshake)?
- pi-e-sigma 3y ago
  So again, why HTTP3 is pushed when HTTP2 was meant to be the holy grail? Seems that even Google doesn't consider HTTP2 to be so great.

KaiserPro 3y ago

> It’s not an error in thinking to assume a good faith basis Its nothing about faith here. I was looking at the evidence. The problem was that a lot of people I was working with had faith that SPDY was something that it wasn't. They either interpreted what I was saying as either an excuse to not change infra (the change was minimal), "old think" because I was not a hot young fullstack node engineer, or that they thought I was trying to be more clever than google.