3 ms·

> Also, because there are so many IRC clients, and so many servers out there, one person's IRC experience can vastly differ from another's. How the fuck did pe

> Also, because there are so many IRC clients, and so many servers out there, one person's IRC experience can vastly differ from another's. How the fuck did people come to think of this as a negative? One of the stupidest things about "modern" IT services is that the public interface is a user interface instead of a machine readable iterface, so you can't build a user interface that fits your needs or preferences, you can't innovate features independently, and you can't use software to process the data, you have to interface everything with a human (or go to great length to scrape stuff 'n shit ... just the point of using information technology!).

briandear 7y ago
Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question? FOSS dogma seems to frequently get in the way of FOSS development. If you aren’t pure and blessed, somehow you are less worthy.
- kick 7y ago
  GNOME is an example of a free software project that is actively hostile to suggestions, critiques and code to improve it from outside.
- zAy0LfpBZLC8mAC 7y ago
  > Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question? Hu? Because they won't take my contribution that rips out all of the web interface and replaces it with EMACS? I mean, what does this even have to do with FOSS? Developing stuff as protocols instead of as user interfaces does not in any way prevent FOSS, very much to the contrary. There are FOSS IRC clients in all shapes and forms: Web interfaces, X GUIs, Windows GUIs, mobile clients, terminal UIs, EMACS modes, XMPP bridges, Matrix bridges ... how is any of that "reinventing the wheel", and how would we be better off if all those clients had to be part of one "IRC FOSS project" rather than independent projects with standards-based interoperability?
flukus 7y ago
Agreed. The worst thing about all these * as a service things it that you're locked in to a single client for that service and many of them have awful and annoying UI's. The netflix UI isn't great, the audible one is abominable, the google music one is very bare bones and they don't care because they have a monopoly on the content. There is no incentive to improve, they have to be just good enough. Having many IRC clients is a good thing because I can have the experience I want, not the experience someone else wants me to have.
tom_mellior 7y ago
> you can't innovate features independently That's also the case with open protocols like IRC. Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. You can only innovate by getting "everyone" to agree on a new standard, and that's hard.
- zAy0LfpBZLC8mAC 7y ago
  > That's also the case with open protocols like IRC. No, it's not. > Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. Then you are bad at protocol design. > You can only innovate by getting "everyone" to agree on a new standard, and that's hard. No, you innovate by being backwards compatible with established standards. Now, maybe IRC has reached the limits of its flexibility and should be replaced, I dunno, but the idea that it is somehow impossible to evolve protocols incrementally with partial adoption of new features is just bullshit.
  - tom_mellior 7y ago
    I think you read too much into my post. I didn't claim anything about protocols in general. You yourself admit that it might not be flexible enough to evolve. It has certainly had a lot of time to try.
    - zAy0LfpBZLC8mAC 7y ago
      > You yourself admit that it might not be flexible enough to evolve. I don't really think so, but I don't really know, I haven't every tried to do anything in that direction. > It has certainly had a lot of time to try. Except that people have to do it? As far as I am concerned, IRC is good enough, so I don't feel like putting any effort into "improving" anything, and it seems like a lot of people using IRC feel this way. Those who feel it's not good enough, though, seem to prefer building non-interoperable systems or just using proprietary lock-in vendors. Obviously, that's not gonna result in anything new in IRC.

briandear 7y ago

Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question? FOSS dogma seems to frequently get in the way of FOSS development. If you aren’t pure and blessed, somehow you are less worthy.

kick 7y ago
GNOME is an example of a free software project that is actively hostile to suggestions, critiques and code to improve it from outside.
zAy0LfpBZLC8mAC 7y ago
> Instead of re-inventing the wheel building your own interface, why not just spend that time working on the FOSS project in question? Hu? Because they won't take my contribution that rips out all of the web interface and replaces it with EMACS? I mean, what does this even have to do with FOSS? Developing stuff as protocols instead of as user interfaces does not in any way prevent FOSS, very much to the contrary. There are FOSS IRC clients in all shapes and forms: Web interfaces, X GUIs, Windows GUIs, mobile clients, terminal UIs, EMACS modes, XMPP bridges, Matrix bridges ... how is any of that "reinventing the wheel", and how would we be better off if all those clients had to be part of one "IRC FOSS project" rather than independent projects with standards-based interoperability?

flukus 7y ago

Agreed. The worst thing about all these * as a service things it that you're locked in to a single client for that service and many of them have awful and annoying UI's. The netflix UI isn't great, the audible one is abominable, the google music one is very bare bones and they don't care because they have a monopoly on the content. There is no incentive to improve, they have to be just good enough. Having many IRC clients is a good thing because I can have the experience I want, not the experience someone else wants me to have.

tom_mellior 7y ago

> you can't innovate features independently That's also the case with open protocols like IRC. Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. You can only innovate by getting "everyone" to agree on a new standard, and that's hard.

zAy0LfpBZLC8mAC 7y ago
> That's also the case with open protocols like IRC. No, it's not. > Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. Then you are bad at protocol design. > You can only innovate by getting "everyone" to agree on a new standard, and that's hard. No, you innovate by being backwards compatible with established standards. Now, maybe IRC has reached the limits of its flexibility and should be replaced, I dunno, but the idea that it is somehow impossible to evolve protocols incrementally with partial adoption of new features is just bullshit.
- tom_mellior 7y ago
  I think you read too much into my post. I didn't claim anything about protocols in general. You yourself admit that it might not be flexible enough to evolve. It has certainly had a lot of time to try.
  - zAy0LfpBZLC8mAC 7y ago
    > You yourself admit that it might not be flexible enough to evolve. I don't really think so, but I don't really know, I haven't every tried to do anything in that direction. > It has certainly had a lot of time to try. Except that people have to do it? As far as I am concerned, IRC is good enough, so I don't feel like putting any effort into "improving" anything, and it seems like a lot of people using IRC feel this way. Those who feel it's not good enough, though, seem to prefer building non-interoperable systems or just using proprietary lock-in vendors. Obviously, that's not gonna result in anything new in IRC.