Simplicity of IRC
151–160 of 250 posts
Re: Simplicity of IRC
#152Earlier quoted context omitted.
I couldn't disagree more, I think bash is a horrifically bad programming language. Honestly I'm incredibly surprised anyone could compare PowerShell and bash and think that PowerShell is the arcane one.
The problem is that you think bash is a programming language.
Re: Simplicity of IRC
#153I have the skills. Just let me automate my own machine without making me have to fight you tooth and nail!
Re: Simplicity of IRC
#154A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there. In the old shop, we eventually had all kinds of…
In my experience, Teams has been a terrible alternative to most every option out there, including IRC. The entire UI/UX seems like an afterthought at best.
To think people build their businesses on this is mind boggling.
Re: Simplicity of IRC
#155In the beginning was the command line. Then work of bright people of Xerox PARC was used to hide from users the reality that underneath their beloved GUI, computers are just passing around strings of text. Now we yearn for a time when you were just one INT and several MOV away from putting a pixel on a screen, instead of downloading multi-GB IDE to fiddle for a weekend before you can show a simple window.
Re: Simplicity of IRC
#156I love IRC, unfortunately it doesn't work properly with smartphones because they have a "loose" connectivity (4G towers data etc). I'm not sure IRC apps can deal with this already. It would be nice to have some update to the IRC RFC. If it was well supported for smartphones, I'm still wondering if it would cause some bandwidth costs to servers. EDIT: I know about bouncers, but I would prefer to do without.
Re: Simplicity of IRC
#157Earlier quoted context omitted.
What's more "under control of the enterprise" than a self-hosted IRC server?
It doesn't prevent clients from logging communications in that server. I know the same is possible in slack or teams, but they don't consider that from a legal perspective.
And consider this also: "hey we're quite sure pur homegrown system is as leak proof as it can be, trust us or fire up an audit team for 5 sprints to asses compliance" vs "Slack has the box checked already"
The fact that folks can e.g technically fire up a headless browser and programmatically interact with the app via capybara or whatever to rebuild a makeshift API, or just take pictures with their phones because the compliant system is inconveniencing them daily is immaterial.
Re: Simplicity of IRC
#158Earlier quoted context omitted.
> That is, unless the enterprise has policies to abide by disallowing API calls ...What?
Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend. [1] https://docs.microsoft.com/en-us…
Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.
Re: Simplicity of IRC
#159The simplicity also comes with problems, such as nickname registration in practice being implemented with bots that have administrative rights, which can lead to social engineering exploits and poor standardization of their interfaces, or the fact that the protocol does not seem to support sending an encoding so it relies on the gentleman's agreement that everyone use UTF-8, which works until that one user using lati…
For example a server can tell the client that it only accepts UTF-8: https://ircv3.net/specs/extensions/utf8-only
Re: Simplicity of IRC
#160In the beginning was the command line. Then work of bright people of Xerox PARC was used to hide from users the reality that underneath their beloved GUI, computers are just passing around strings of text. Now we yearn for a time when you were just one INT and several MOV away from putting a pixel on a screen, instead of downloading multi-GB IDE to fiddle for a weekend before you can show a simple window.
You don't understand what happened at Xerox PARC or what their "GUI" was. Smalltalk wasn't a language, it wasn't a GUI, it was an _environment_, and its whole point was that it didn't hide anything! It was a completely different paradigm to how computers and their programs are architected today. A Smalltalk system was always meant to be so simple that one could understand, and change, everything about it.