MeanEYE

I had ZNC set up for myself and few other people, but all of that is additional steps and additional things that require maintenance. But client with built-in things like these would be great. Ideally protocol should implement those, especially considering how easy it would be for server to do deduplication on messages for multiple users.

Yeah, I’d assume there would be a level of resistance to changes from big networks.

No problem. Like I said, everyone has different needs, but it’s better to have features and not use them than the other way around. When we used IRC, it was a real pain. I insisted we give it a shot for about a month and we couldn’t pull out a week. The moment I realized I had to explain to people where to click and what to expect that’s the moment we dropped it. Which is a shame, I really like the protocol. Not to mention ease of implementation with various scripts and git hooks.

I can understand people being use to unavailability of such features. When we were trying to figure out a solution for our development team which is mostly working form home, IRC was one of the options. We tried using IRC, Matrix, and bunch of others. While IRC was really fast and reliable its main issues were poor mobile support, where client would get disconnected when switching networks and multimedia support. Matrix and Tox supported these but there were so many problems with them at the time. So everyone pushed towards Slack. Luckily I had enough influence to not allow it and we finally settled with Signal, which is far from perfect, but it works for what we need it.

Sending files in this day and age shouldn’t be a question of having public IP and routed ports and messing around with settings.

IRCv3 doesn’t bring multimedia as far as I know. There are good changes to the protocol proposed, but they are moving too slow.

That’s great, although protocol level support would be preferable.

The need exists, and has been for a while now. Refusal to accept that fact is what’s leading to reduced use of IRC protocol. Sure, you might not see the need, but everyone is not you. Especially for work and development images can come handy.

There’s a “new” draft for version 3 being worked on but to be honest they are not addressing in my opinion the right features. Yay, we are going to get unicode nicknames? I think people are fine with what is there now. But not being able to paste code or images, now that’s a real hindrance.

IRC is sadly going away slowly. Which is a shame, it’s a great protocol that is easy to implement and simple to work with. Biggest problem I see is its inability to embed images and other multimedia. Had that been the case protocol would live on I feel. We just needed few more channel modes, some that ban or allow specific multimedia and inline image support and we are good.

Some people, if not most who use IRC, would claim otherwise, but there’s a reason why Slack became popular even though it’s shitty electron application.

Hardware is complex and mysterious enough without added complexity of an esoteric language.

Do people still think, after all this time and so many different languages, that there will be one language to rule them all? I mean technically you can drive nails with a rock, but you don’t see a carpenter using one. Right tool for the job. Always was, always will be.

Can be compressed very efficiently. I do dread the thought of writing a driver in brainfuck.

More to the point it refers to relation between elements and not the political correctness of the act. Just how the terminology is used in books, but reading one doesn’t imply you are a racist or condone slavery.

For a while, yes, you had to. Every new repo would be main while old ones remained master. Tools that default to a specific branch aside now you had to remember and check which branch you are merging into every time.

That’s like forcing people to have different color shoe laces and calling it good practice. In reality it changed nothing but forced a lot of people to work on solving issues with their scripts and automation tools for the sake of change instead of spending that time on writing actual code and fixing bugs.

This, sooo much this! People don’t realize that this change created a lot of unnecessary work to a lot of developers for no other reason than PR or to act smug about it. They solved slavery problem by renaming master to main equally well as they solved homophobia and transphobia by allowing people to specify pronouns on their profiles. Who the hell cares if you identify as tree sap. However many do care if your code sucks or doesn’t follow coding style.

I can’t wait for asshats to start calling for gender fluid connectors. What’s that, male 3.5mm connector, did you just assume my connectors identity?

How can you? I would understand if you have to, but Mercurial/Git approach is so much more flexible.

This is a huge pain in the ass for us as well. We have some automation with development environment and deployment of certain scripts. We had to redo a good chunk of them to first test whether there’s main or master. And it took us a long time to find stragglers that weren’t as frequently updated but would suddenly break deploymend after minor changes.

Had to refresh my memory, it’s been a while. They didn’t change branch on existing projects, but they did change it on new repos to main by default. Our tools indeed created repositories and configured everything for the developer automatically. However GitHub’s policy meant that you had to either change the tools to detect whether they are working with old repo or new, or go to every new project after automatic configuration fails, configure default branch and then rerun the tool. Same thing then happened to few of our tools that were used for CI.

All in all they made more work for us for no reason other than be smug about it and it changed exactly nothing.