3 ms·

It's open source: if things don't get fixed, it's because no user cares enough to fix it. I'm certainty not wasting my time on that, nobody uses ext3 anymore!

It's open source: if things don't get fixed, it's because no user cares enough to fix it. I'm certainty not wasting my time on that, nobody uses ext3 anymore! You are as empowered to fix this as anybody else, if it presents a real problem for you.

bayindirh 3y ago
You can reliably change ext3 with ext4 in the GP's comment. It's not an extX problem, it's an BTRFS problem. If nobody cares that much, maybe deprecate the tool, then? Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality. Like everything, FOSS is 85% people, 15% code. > You are as empowered to fix this as anybody else, if it presents a real problem for you. I have reported many bugs in Open Source software. If I had the time to study code and author a fix, I'd submit the patch itself, which I was able to do, a couple of times.
- jcalvinowens 3y ago
  > If nobody cares that much, maybe deprecate the tool, then? If you think that's the right thing to do, you're as free as anybody else to send documentation patches. I doubt anybody would argue with you here, but who knows :) > Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality. Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO.
  - bayindirh 3y ago
    > If you think that's the right thing to do, you're as free as anybody else to send documentation patches :) That won't do anything. Instead I can start a small commotion by sending a small request (to the mailing lists) to deprecate the tool, which I don't want to do. Because I'm busy. :) Also, I don't like commotions, and prefer civilized discussions. > Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO. Of course. This is what I do. For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example.
    - jcalvinowens 3y ago
      > For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example Surely you were given some justification as to why they didn't want to merge it? I realize sometimes these things are intractable, but in my experience that's rare... usually things can iterate towards a mutually agreeable solution.
      - bayindirh 3y ago
        The sad part is they didn’t. GTK has (or had) a sliding infoline widget, which is used to show notifications. GDM used it for password related prompts. It actually relayed PAM messages to that widget. We were doing mass installations backed by an LDAP server which had password policies, including expiration enabled. That widget had a bug, prevented it displaying a new message when it was in the middle of an animation, which effectively ate messages related to LDAP (Your password will expire in X days, etc.). Also we needed a keyboard selector in that window, which was absent. I gave heads up to the GDM team, they sent a “go ahead” as a reply. I have written an elaborate patch, which they rejected and wanted a simpler one. I iterated the way they wanted, they said it passes the muster and will be merged. Further couple of mails never answered. I’m basically ghosted. But the merge never came, and I moved on.
        baq 3y ago
        This sort of thing happens all the time in big orgs which develop a single product internally with a closed source… there isn’t any fix for this part of human nature, apparently.
        deleted 3y ago
        [deleted]
- Zardoz84 3y ago
  for me it's a problem of the tool converting in place EXT to BTRFS. Not necessarily a problem of BTRFS.
  - bayindirh 3y ago
    I tried to say it’s a problem of BTRFS the project. Not BTRFS the file system.
noncoml 3y ago
> You are as empowered to fix this as anybody else, if it presents a real problem for you. I’m getting sick and tired of this argument. It’s very user unfriendly Do you work in software? If yes, do you own a component? Have you tried using this argument with your colleagues that have no idea about your component? Of course they theoretically are empowered to fix the bug, but that doesn’t make it easier. They may have no idea about how filesystem internal. Or they may be just users and have no programming background at all
- jcalvinowens 3y ago
  It's not unfriendly, it's just how it is. The fact you're comparing it to industry shows you don't get it. Open source doesn't work for you. You can't demand that it do things you want: you have to push and justify them yourself, and hopefully you find other people along the way who want the same things and can help you. I taught myself to program as a teenager trying to fix bugs in Linux. If I could do it, anybody can. That's what makes it empowering.
  - mardifoufs 3y ago
    Well I think you're completely right, in a way. But I also don't see the problem with people telling other people to not use the software or to complain about it. They are totally in their right to complain about stuff. Now obviously if the complaining involves requiring people to work for some feature you want, that's entitled and wack. Same goes for throwing a fit because maintainers went for systemd instead of your own favorite init system. But being open source doesn't mean people shouldn't or can't just say "this is bad" or "don't use x" or even "this X feature doesn't work when using Y" (now If what they are saying isn't true, sure we should call them out) It's normal and in fact I think it should be encouraged, as not everyone can be aware of potential problems they could have with a piece of OSS that is already known in some obscure dev mailing list. The more people are informed and aware of potential issues, the less they will be surprised and complain about it when they start using it. (Fwiw I love btrfs, and I think it's very reliable)
  - noncoml 3y ago
    Read the thread again. No one asked anyone to work for free. Please don’t put words in other peoples mouth.
romanows 3y ago
I think the parent comment's fix is to not use btrfs and warn others about how risky they estimate it is.

bayindirh 3y ago

You can reliably change ext3 with ext4 in the GP's comment. It's not an extX problem, it's an BTRFS problem. If nobody cares that much, maybe deprecate the tool, then? Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality. Like everything, FOSS is 85% people, 15% code. > You are as empowered to fix this as anybody else, if it presents a real problem for you. I have reported many bugs in Open Source software. If I had the time to study code and author a fix, I'd submit the patch itself, which I was able to do, a couple of times.

jcalvinowens 3y ago
> If nobody cares that much, maybe deprecate the tool, then? If you think that's the right thing to do, you're as free as anybody else to send documentation patches. I doubt anybody would argue with you here, but who knows :) > Also, just because it's Open Source (TM) doesn't mean developers will accept any patch regardless of its quality. Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO.
- bayindirh 3y ago
  > If you think that's the right thing to do, you're as free as anybody else to send documentation patches :) That won't do anything. Instead I can start a small commotion by sending a small request (to the mailing lists) to deprecate the tool, which I don't want to do. Because I'm busy. :) Also, I don't like commotions, and prefer civilized discussions. > Of course not. If you want to make a difference, you have to put in the work. It's worth it IMHO. Of course. This is what I do. For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example.
  - jcalvinowens 3y ago
    > For example, I have a one liner in Debian Installer. I had a big patch in GDM, but after coordinating with the developers, they decided to not merge the fix + new feature, for example Surely you were given some justification as to why they didn't want to merge it? I realize sometimes these things are intractable, but in my experience that's rare... usually things can iterate towards a mutually agreeable solution.
    - bayindirh 3y ago
      The sad part is they didn’t. GTK has (or had) a sliding infoline widget, which is used to show notifications. GDM used it for password related prompts. It actually relayed PAM messages to that widget. We were doing mass installations backed by an LDAP server which had password policies, including expiration enabled. That widget had a bug, prevented it displaying a new message when it was in the middle of an animation, which effectively ate messages related to LDAP (Your password will expire in X days, etc.). Also we needed a keyboard selector in that window, which was absent. I gave heads up to the GDM team, they sent a “go ahead” as a reply. I have written an elaborate patch, which they rejected and wanted a simpler one. I iterated the way they wanted, they said it passes the muster and will be merged. Further couple of mails never answered. I’m basically ghosted. But the merge never came, and I moved on.
      - baq 3y ago
        This sort of thing happens all the time in big orgs which develop a single product internally with a closed source… there isn’t any fix for this part of human nature, apparently.
        deleted 3y ago
        [deleted]
Zardoz84 3y ago
for me it's a problem of the tool converting in place EXT to BTRFS. Not necessarily a problem of BTRFS.
- bayindirh 3y ago
  I tried to say it’s a problem of BTRFS the project. Not BTRFS the file system.

noncoml 3y ago

> You are as empowered to fix this as anybody else, if it presents a real problem for you. I’m getting sick and tired of this argument. It’s very user unfriendly Do you work in software? If yes, do you own a component? Have you tried using this argument with your colleagues that have no idea about your component? Of course they theoretically are empowered to fix the bug, but that doesn’t make it easier. They may have no idea about how filesystem internal. Or they may be just users and have no programming background at all

jcalvinowens 3y ago
It's not unfriendly, it's just how it is. The fact you're comparing it to industry shows you don't get it. Open source doesn't work for you. You can't demand that it do things you want: you have to push and justify them yourself, and hopefully you find other people along the way who want the same things and can help you. I taught myself to program as a teenager trying to fix bugs in Linux. If I could do it, anybody can. That's what makes it empowering.
- mardifoufs 3y ago
  Well I think you're completely right, in a way. But I also don't see the problem with people telling other people to not use the software or to complain about it. They are totally in their right to complain about stuff. Now obviously if the complaining involves requiring people to work for some feature you want, that's entitled and wack. Same goes for throwing a fit because maintainers went for systemd instead of your own favorite init system. But being open source doesn't mean people shouldn't or can't just say "this is bad" or "don't use x" or even "this X feature doesn't work when using Y" (now If what they are saying isn't true, sure we should call them out) It's normal and in fact I think it should be encouraged, as not everyone can be aware of potential problems they could have with a piece of OSS that is already known in some obscure dev mailing list. The more people are informed and aware of potential issues, the less they will be surprised and complain about it when they start using it. (Fwiw I love btrfs, and I think it's very reliable)
- noncoml 3y ago
  Read the thread again. No one asked anyone to work for free. Please don’t put words in other peoples mouth.

romanows 3y ago

I think the parent comment's fix is to not use btrfs and warn others about how risky they estimate it is.