5 ms·

EDIT: Comments from the maintainers have painted a completely different picture while I wrote this so none of this applies here but I'm leaving it up as a gener

EDIT: Comments from the maintainers have painted a completely different picture while I wrote this so none of this applies here but I'm leaving it up as a general view on maintainership. Very strange, makes me want to avoid i3 altogether. It's not like it requires a lot of code to support configurable, optional gaps. Probably the rationale is something asinine like "I don't like gaps, gaps are dumb" or "buhu I don't like the completely negligible overhead" I actively avoid projects whose maintainers are MDFLs rather than BDFLs.

bee_rider 4y ago
I think it is generally best to not assume people have asinine motivations.
the-grump 4y ago
The beauty of free software is that nobody will coerce you to use it, and nobody cares if you use it. I'm incredibly thankful to the maintainers for doing the thankless job of keeping i3 stable and for doing it so well.
Airblader 4y ago
I see your point (in general terms). But I think people tend to overlook the hidden costs of optional features in terms of maintenance and complexity (in code, documentation, and for users). In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. It's easy to add a feature, difficult to maintain it, and impossible to remove it.
- secure 4y ago
  Yup! We even have an FAQ entry on the reasons for not merging features without careful consideration: https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/index.html%3Fanswer=779.html https://faq.i3wm.org/question/778/why-is-patch-not-merged-an... Also, saying “it’s not that many lines of code” comparing the before and after state is too simplistic: it doesn’t include the cost of changing the existing code into the desired state, which can be a significant effort, even if the number of lines doesn’t differ much before and after. See https://github.com/i3/i3/pulls?q=is%3Apr+author%3Astapelberg+gaps https://github.com/i3/i3/pulls?q=is%3Apr+author%3Astapelberg... to get an impression of how much work it was to merge gaps.
- mtlmtlmtlmtl 4y ago
  I'm impressed with your complete lack of snark in response to my asininely snarky comment, edit or no. I went from thinking you're a bad maintainer to thinking you're one of the more level headed ones I've interacted with. I feel like there's some kind of lesson here about Bayes' Law. I never used i3 much beyond trialing it for embed stuff(went with dwm). I'm too much of a Lisp nerd not to use StumpWM. I like the fact that your stumpwmrc is essentially just a live patch for your WM. You can redefine arbitrary functions, classes, variables, define commands with arbitrary code in them. And you can patch the WM while running via Emacs. How is i3 support for more obscure unices like OpenBSD, Illumos etc? StumpWM is kind of a pain to get working after they dropped support for all compilers except sbcl... And I agree completely general in about the tradeoffs of adding features. It's tough to do, though my philosophy in this specific case is also that customization is a core feature of any good tiling WM and should be priorited almost above all, except performance and minimalism.
  - secure 4y ago
    OpenBSD packages i3: https://openports.se/x11/i3 https://openports.se/x11/i3 I briefly (for about a year or so) developed i3 on NetBSD. I have no knowledge of other more obscure variants, though.
  - Airblader 4y ago
    I can promise you that in a decade of doing this, I've made my fair share of mistakes as a maintainer. There's a learning curve to everything, and maintainer burnout is a real thing, too. i3 should definitely work on BSD, there are a few awesome folk that regularly send patches when we broke something. I don't have experience with it myself though.
    - mtlmtlmtlmtl 4y ago
      Naturally, the best maintainers are those that are humble enough to learn from their mistakes. And maintainership is just hard, way harder than writing code IMO. You have to have and defend a vision for the project, and yet not be so staunch as to scare off the many users and contributors you depend on. You can't be everybody's best friend; sometimes you really do have to give a list of 18 different bugs in a 10 LOC PR, and yet somehow try to do it without completely disheartening someone who means well and wants to learn. And then on top of all that diplomacy you still have to dig down and figure everything out when a particularly nasty regression slips through the cracks. I know I couldn't do it worth a damn, just thinking about it gives me an ulcer. One other maintainer who I admire is Greg KH, maintainer of the Linux stable branch. 15 years ago I sent him this absolutely useless patch cleaning up the code style of a driver that was marked to be deleted and rewritten from scratch. 15 year old wannabe kernel hacker just finished his first read of K&R and wants to go straight for the damn linux kernel next. In his reply he not only thanked me for what was basically a waste of his time, explained why there was no point taking the patch, then he went and reviewed the patch anyway! This was at least a couple kloc, and he voluntarily wasted even more of his no doubt precious time to teach me a few more things. He even responded to a follow up email asking for reading material. I'm not sure how he does it. My main hypothesis is Greg KH is secretly the identical triplets Greg, Karl and Harold and they're somehow all kernel maintainers. That interaction, while just one in hundreds he engages in on any given day, to me was oddly enough life-changing. It let me know I was overreaching to an absurd degree, yet also inspired me to keep learning(big deal for a 15yo). And I did end up becoming a capable low level C programmer, doing some of the best work of my career in embed stuff during the brief windows my health has allowed me to be productive. It also helped me accept that I'm just not cut out for hacking on the kernel, which is fine, almost no one is.
- sophacles 4y ago
  > In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. Thank goodness for this. I would say you've succeeded at those goals - sometimes I go deep into tinkering and other times I am focused on something else. i3 is on the short list of software that I can tweak to my liking and then ignore for years without concern that my environment will mysteriously break from an update. I really, really appreciate that, kudos.
Oxidation 4y ago
The discussion[1] over "maximise" leaned towards "that's dumb, only dumb people want that" for a very long time, and it's still the one thing in i3 I find jarring. To maximise a window temporarily but keep your status bar or avoid your program going into "full screen mode" and hiding UI from you, you have to move it to some empty desktop and just deal with the fact that when you put it back on the original desktop it might not end up where it came from. [1]: https://github.com/i3/i3/issues/2107 https://github.com/i3/i3/issues/2107
- Airblader 4y ago
  I think that's an unfair and fundamentally false representation of the discussion on that issue. But I won't further comment on it here.
rawoke083600 4y ago
I actively avoid programmers that use "MDFLs" and "BDFLs" in their sentences...

bee_rider 4y ago

I think it is generally best to not assume people have asinine motivations.

the-grump 4y ago

The beauty of free software is that nobody will coerce you to use it, and nobody cares if you use it. I'm incredibly thankful to the maintainers for doing the thankless job of keeping i3 stable and for doing it so well.

Airblader 4y ago

I see your point (in general terms). But I think people tend to overlook the hidden costs of optional features in terms of maintenance and complexity (in code, documentation, and for users). In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. It's easy to add a feature, difficult to maintain it, and impossible to remove it.

secure 4y ago
Yup! We even have an FAQ entry on the reasons for not merging features without careful consideration: https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/index.html%3Fanswer=779.html https://faq.i3wm.org/question/778/why-is-patch-not-merged-an... Also, saying “it’s not that many lines of code” comparing the before and after state is too simplistic: it doesn’t include the cost of changing the existing code into the desired state, which can be a significant effort, even if the number of lines doesn’t differ much before and after. See https://github.com/i3/i3/pulls?q=is%3Apr+author%3Astapelberg+gaps https://github.com/i3/i3/pulls?q=is%3Apr+author%3Astapelberg... to get an impression of how much work it was to merge gaps.
mtlmtlmtlmtl 4y ago
I'm impressed with your complete lack of snark in response to my asininely snarky comment, edit or no. I went from thinking you're a bad maintainer to thinking you're one of the more level headed ones I've interacted with. I feel like there's some kind of lesson here about Bayes' Law. I never used i3 much beyond trialing it for embed stuff(went with dwm). I'm too much of a Lisp nerd not to use StumpWM. I like the fact that your stumpwmrc is essentially just a live patch for your WM. You can redefine arbitrary functions, classes, variables, define commands with arbitrary code in them. And you can patch the WM while running via Emacs. How is i3 support for more obscure unices like OpenBSD, Illumos etc? StumpWM is kind of a pain to get working after they dropped support for all compilers except sbcl... And I agree completely general in about the tradeoffs of adding features. It's tough to do, though my philosophy in this specific case is also that customization is a core feature of any good tiling WM and should be priorited almost above all, except performance and minimalism.
- secure 4y ago
  OpenBSD packages i3: https://openports.se/x11/i3 https://openports.se/x11/i3 I briefly (for about a year or so) developed i3 on NetBSD. I have no knowledge of other more obscure variants, though.
- Airblader 4y ago
  I can promise you that in a decade of doing this, I've made my fair share of mistakes as a maintainer. There's a learning curve to everything, and maintainer burnout is a real thing, too. i3 should definitely work on BSD, there are a few awesome folk that regularly send patches when we broke something. I don't have experience with it myself though.
  - mtlmtlmtlmtl 4y ago
    Naturally, the best maintainers are those that are humble enough to learn from their mistakes. And maintainership is just hard, way harder than writing code IMO. You have to have and defend a vision for the project, and yet not be so staunch as to scare off the many users and contributors you depend on. You can't be everybody's best friend; sometimes you really do have to give a list of 18 different bugs in a 10 LOC PR, and yet somehow try to do it without completely disheartening someone who means well and wants to learn. And then on top of all that diplomacy you still have to dig down and figure everything out when a particularly nasty regression slips through the cracks. I know I couldn't do it worth a damn, just thinking about it gives me an ulcer. One other maintainer who I admire is Greg KH, maintainer of the Linux stable branch. 15 years ago I sent him this absolutely useless patch cleaning up the code style of a driver that was marked to be deleted and rewritten from scratch. 15 year old wannabe kernel hacker just finished his first read of K&R and wants to go straight for the damn linux kernel next. In his reply he not only thanked me for what was basically a waste of his time, explained why there was no point taking the patch, then he went and reviewed the patch anyway! This was at least a couple kloc, and he voluntarily wasted even more of his no doubt precious time to teach me a few more things. He even responded to a follow up email asking for reading material. I'm not sure how he does it. My main hypothesis is Greg KH is secretly the identical triplets Greg, Karl and Harold and they're somehow all kernel maintainers. That interaction, while just one in hundreds he engages in on any given day, to me was oddly enough life-changing. It let me know I was overreaching to an absurd degree, yet also inspired me to keep learning(big deal for a 15yo). And I did end up becoming a capable low level C programmer, doing some of the best work of my career in embed stuff during the brief windows my health has allowed me to be productive. It also helped me accept that I'm just not cut out for hacking on the kernel, which is fine, almost no one is.
sophacles 4y ago
> In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. Thank goodness for this. I would say you've succeeded at those goals - sometimes I go deep into tinkering and other times I am focused on something else. i3 is on the short list of software that I can tweak to my liking and then ignore for years without concern that my environment will mysteriously break from an update. I really, really appreciate that, kudos.

Oxidation 4y ago

The discussion[1] over "maximise" leaned towards "that's dumb, only dumb people want that" for a very long time, and it's still the one thing in i3 I find jarring. To maximise a window temporarily but keep your status bar or avoid your program going into "full screen mode" and hiding UI from you, you have to move it to some empty desktop and just deal with the fact that when you put it back on the original desktop it might not end up where it came from. [1]: https://github.com/i3/i3/issues/2107 https://github.com/i3/i3/issues/2107

Airblader 4y ago
I think that's an unfair and fundamentally false representation of the discussion on that issue. But I won't further comment on it here.

rawoke083600 4y ago

I actively avoid programmers that use "MDFLs" and "BDFLs" in their sentences...