7 ms·

There are 2 types of crotchety old men: 1) This one yells "get off my lawn!". 2) This one yells "get off my lawn!" and proceeds to explain why he doesn't like

There are 2 types of crotchety old men: 1) This one yells "get off my lawn!". 2) This one yells "get off my lawn!" and proceeds to explain why he doesn't like kids walking through his grass, and gives the complete history of him yelling at kids and then goes into detail why staying off his lawn is best for everybody. The author of curl is the latter. It would take much less time and effort to just write something fun into it, AND document it. Good grief, life is short, software development should be fun, even while remaining professional.

pavel_lishin 5y ago
But it's not a lawn. It's a critical tool. Do you want your car's brake system to have easter eggs? What about your smoke detectors?
- jjoonathan 5y ago
  Yeah, next time I'm on the highway and go into my foot-brake's "About" menu and click on the word "2020" twenty times I might be in serious danger of crashing my car!
  - Arainach 5y ago
    When the API that enables the effect has a buffer overflow that no one noticed because the feature was snuck in and attackers exploit it to take over your brakes (and from there the CAN bus because how could the brakes possibly have any vulnerabilities?), you'll care.
    - jjoonathan 5y ago
      My brakes don't have an about menu, they don't have a monitor, and they don't have a mouse. Everyone agrees they are safety critical. My point was to demonstrate through a nonsensical example that different environments have different ambient expectations for reliability. If a problem in a low-reliability environment propagates to a high-reliability environment, the root cause is the failure of isolation, not the bug or exploit in the low-reliability environment. Now, I would never actually ship an easter egg, but that's because I have no faith in the corporate blame game to correctly assign blame, not because I place the slightest stock in the idea that safety and security are a genuine reason why it shouldn't be done. This is why we can't have nice things.
      - pavel_lishin 5y ago
        I would argue that curl is safety critical. And it's a very nice thing, and we have it.
        jjoonathan 5y ago
        > I would argue that curl is safety critical. O.O That opinion scares me. Genuinely. Have you seen its protocol list grow in recent years? It has taken on a hundred thousand easter eggs worth of overhead to add 26 protocols, of which you probably use 2, but you consider it safety critical?
  - l-p 5y ago
    Yes because it'll load an image from a domain that expired and is now controlled by a nefarious third-party. The image is now a payload targeting the out of date image loading lib used by the onboard entertainment system that has seen no updates for 5 years. This entertainment system is connected to the actual driving electronics of the car that will now brake at full force the next time it reaches 130 km/h. This scenario is fictional, but possible. cf. the works of Charlie Miller and Chris Valasek. https://outline.com/k6U6P6 https://outline.com/k6U6P6 https://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ https://www.forbes.com/sites/andygreenberg/2013/07/24/hacker... https://www.youtube.com/watch?v=OobLb1McxnI https://www.youtube.com/watch?v=OobLb1McxnI
    - jjoonathan 5y ago
      > This entertainment system is connected to the actual driving electronics That's the actual problem in your scenario. You can try to blame the kids for having fun all you like -- you might even be able to make it stick -- but it doesn't make you right.
      - deleted 5y ago
        [deleted]
      - samhw 5y ago
        I really dislike this ubiquitous attitude: > My X broke while doing Y. > Well, you shouldn't be doing Y with X. That's the real problem. What does it matter? If people are doing Y with X, and you as the author of X can improve that path, then you should do that. Normative ideas about what people should be doing don't make a difference. (You can see this a lot with the Go community. "Go doesn't support [language feature in common use for longer than Keith Richards has been alive]" "Well, you shouldn't be using [language feature in common use for longer than Keith Richards has been alive]" etc etc.)
        jjoonathan 5y ago
        Sure, do you want me to fix every other bug in the shitty Android 7 headunit it's running on while I'm at it? If you don't pick your battles, you'll be doomed to fight for bad causes. Like this one.
  - pavel_lishin 5y ago
    Sure, assuming that's the only way to trigger that code path.
  - CuriousCosmic 5y ago
    The problem with this rationale is that it's how you end up with stuff like this: https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030 https://unix.stackexchange.com/questions/405783/why-does-man... Easter eggs can get invoked in unintuitive ways and as a result can cause serious issues. Sure you can make easter eggs that are "safe" but the mental overhead to doing so just is absolutely not worth it for anything that could potentially end up in a security critical or automated path. It's easier to just take a hard line stance and say "I don't want my projects to ever run the risk of losing someone millions of dollars or worse get somebody injured/killed because we decided to add an unnecessary joke".
    - jjoonathan 5y ago
      That's the best example you can come up with? A bug in an easter egg broke a test related to manuals? See, I think security and reliability are good arguments for minimalism and that minimalism is a reason to get rid of easter eggs -- I just think that in most applications nobody gives one genuine whit about minimalism, except as a universal argument of last resort to kill an otherwise completely unobjectionable feature that they don't like. The typical product has a very long tail of dead code and useless features that nobody will ever derive utility or joy from. Easter eggs typically bring a bit of joy, and this actually places them rather far up on the tail. In a land of zeros, a small number stands tall. I fully agree that the overall size of the tail is a problem, but actual attempts to make the tail smaller generally start with lower hanging fruit and still are widely considered a waste of time. Cleanup work is universally valued at close to nothing. Ditto dependency analysis. Nobody thinks twice about roping in heavy dependencies, even in applications that like to think of themselves as important. From the perspective of minimalism, these are all much heavier sins than easter eggs, yet these titanic-sized ships sail silently through the night while one tiny little unobtrusive easter egg that has not in fact caused any trouble will call forth a roiling army of soulless corporate drones, pouring over desks and cubicle walls to wring their wrists, clutch their pearls, and wag their fingers about the possibility that the easter egg may contain a bug.
      - CuriousCosmic 5y ago
throw10920 5y ago
The linked article is only a few hundred words long. It probably took Daniel half an hour to write. It would take far longer to write, integrate, test, document, and maintain even a simple easter egg to the same quality standards as the rest of the curl project. That last bit is key - to the same quality standards. curl is a really well-done, carefully-built-and-tested project. If we were talking about most other pieces of software - yes, a small easter egg wouldn't have taken much effort. Not in this case. If someone else had volunteered to take on all of the effort of maintaining the easter egg, Daniel might let it in - but that would still be more work on his part to rope them in to test their thing after every change to code adjacent to the feature. Conversely, nobody prevents you from forking curl and adding the easter egg in yourself. Why don't you?
- deleted 5y ago
  [deleted]
oh_sigh 5y ago
There's no need to gate-keep software development. People do it for all different purposes.

pavel_lishin 5y ago

But it's not a lawn. It's a critical tool. Do you want your car's brake system to have easter eggs? What about your smoke detectors?

jjoonathan 5y ago
Yeah, next time I'm on the highway and go into my foot-brake's "About" menu and click on the word "2020" twenty times I might be in serious danger of crashing my car!
- Arainach 5y ago
  When the API that enables the effect has a buffer overflow that no one noticed because the feature was snuck in and attackers exploit it to take over your brakes (and from there the CAN bus because how could the brakes possibly have any vulnerabilities?), you'll care.
  - jjoonathan 5y ago
    My brakes don't have an about menu, they don't have a monitor, and they don't have a mouse. Everyone agrees they are safety critical. My point was to demonstrate through a nonsensical example that different environments have different ambient expectations for reliability. If a problem in a low-reliability environment propagates to a high-reliability environment, the root cause is the failure of isolation, not the bug or exploit in the low-reliability environment. Now, I would never actually ship an easter egg, but that's because I have no faith in the corporate blame game to correctly assign blame, not because I place the slightest stock in the idea that safety and security are a genuine reason why it shouldn't be done. This is why we can't have nice things.
    - pavel_lishin 5y ago
      I would argue that curl is safety critical. And it's a very nice thing, and we have it.
      - jjoonathan 5y ago
        > I would argue that curl is safety critical. O.O That opinion scares me. Genuinely. Have you seen its protocol list grow in recent years? It has taken on a hundred thousand easter eggs worth of overhead to add 26 protocols, of which you probably use 2, but you consider it safety critical?
- l-p 5y ago
  Yes because it'll load an image from a domain that expired and is now controlled by a nefarious third-party. The image is now a payload targeting the out of date image loading lib used by the onboard entertainment system that has seen no updates for 5 years. This entertainment system is connected to the actual driving electronics of the car that will now brake at full force the next time it reaches 130 km/h. This scenario is fictional, but possible. cf. the works of Charlie Miller and Chris Valasek. https://outline.com/k6U6P6 https://outline.com/k6U6P6 https://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ https://www.forbes.com/sites/andygreenberg/2013/07/24/hacker... https://www.youtube.com/watch?v=OobLb1McxnI https://www.youtube.com/watch?v=OobLb1McxnI
  - jjoonathan 5y ago
    > This entertainment system is connected to the actual driving electronics That's the actual problem in your scenario. You can try to blame the kids for having fun all you like -- you might even be able to make it stick -- but it doesn't make you right.
    - deleted 5y ago
      [deleted]
    - samhw 5y ago
      I really dislike this ubiquitous attitude: > My X broke while doing Y. > Well, you shouldn't be doing Y with X. That's the real problem. What does it matter? If people are doing Y with X, and you as the author of X can improve that path, then you should do that. Normative ideas about what people should be doing don't make a difference. (You can see this a lot with the Go community. "Go doesn't support [language feature in common use for longer than Keith Richards has been alive]" "Well, you shouldn't be using [language feature in common use for longer than Keith Richards has been alive]" etc etc.)
      - jjoonathan 5y ago
        Sure, do you want me to fix every other bug in the shitty Android 7 headunit it's running on while I'm at it? If you don't pick your battles, you'll be doomed to fight for bad causes. Like this one.
- pavel_lishin 5y ago
  Sure, assuming that's the only way to trigger that code path.
- CuriousCosmic 5y ago
  The problem with this rationale is that it's how you end up with stuff like this: https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030 https://unix.stackexchange.com/questions/405783/why-does-man... Easter eggs can get invoked in unintuitive ways and as a result can cause serious issues. Sure you can make easter eggs that are "safe" but the mental overhead to doing so just is absolutely not worth it for anything that could potentially end up in a security critical or automated path. It's easier to just take a hard line stance and say "I don't want my projects to ever run the risk of losing someone millions of dollars or worse get somebody injured/killed because we decided to add an unnecessary joke".
  - jjoonathan 5y ago
    That's the best example you can come up with? A bug in an easter egg broke a test related to manuals? See, I think security and reliability are good arguments for minimalism and that minimalism is a reason to get rid of easter eggs -- I just think that in most applications nobody gives one genuine whit about minimalism, except as a universal argument of last resort to kill an otherwise completely unobjectionable feature that they don't like. The typical product has a very long tail of dead code and useless features that nobody will ever derive utility or joy from. Easter eggs typically bring a bit of joy, and this actually places them rather far up on the tail. In a land of zeros, a small number stands tall. I fully agree that the overall size of the tail is a problem, but actual attempts to make the tail smaller generally start with lower hanging fruit and still are widely considered a waste of time. Cleanup work is universally valued at close to nothing. Ditto dependency analysis. Nobody thinks twice about roping in heavy dependencies, even in applications that like to think of themselves as important. From the perspective of minimalism, these are all much heavier sins than easter eggs, yet these titanic-sized ships sail silently through the night while one tiny little unobtrusive easter egg that has not in fact caused any trouble will call forth a roiling army of soulless corporate drones, pouring over desks and cubicle walls to wring their wrists, clutch their pearls, and wag their fingers about the possibility that the easter egg may contain a bug.
    - CuriousCosmic 5y ago

throw10920 5y ago

The linked article is only a few hundred words long. It probably took Daniel half an hour to write. It would take far longer to write, integrate, test, document, and maintain even a simple easter egg to the same quality standards as the rest of the curl project. That last bit is key - to the same quality standards. curl is a really well-done, carefully-built-and-tested project. If we were talking about most other pieces of software - yes, a small easter egg wouldn't have taken much effort. Not in this case. If someone else had volunteered to take on all of the effort of maintaining the easter egg, Daniel might let it in - but that would still be more work on his part to rope them in to test their thing after every change to code adjacent to the feature. Conversely, nobody prevents you from forking curl and adding the easter egg in yourself. Why don't you?

deleted 5y ago
[deleted]

oh_sigh 5y ago

There's no need to gate-keep software development. People do it for all different purposes.