My texting is scattered. I’d prefer it to be all XMPP, but I engage with Signal, & Mattermost, IRC, & Matrix on a regular basis… & largely this is a result of me just quitting the other chat platforms that most are using here (LINE, Facebook Messenger) which has made communications more difficult for others. I could run gateway to puppet all those accounts which is a lot closer than Pidgin was at unifying it all, but I’ve been a bit lazy to set it all up (& if the common gateway tool wasn’t Python I’d be more thrilled to touch it).
Choosing between charging or audio shouldn’t have to be a choose when you consider it’s common courtesy to not spew your noise pollution into your public surroundings. Dongles big enough for passthru charging are too bulky to fit in a pocket comfortably. Now you also have another wire/hub you have to go out and buy & might easily lose or misplace, for what exactly? It sure ain’t to waterproofing or a significant cost-cutting measure. It can let a device be ever so much thinner but does being < 3.5 mm really benefit the user. I bet the manufactures love the revenue of the discount bundled wireless earbuds tho—whose audio is usually not good but labeled under subjective to all but the nerds looking at frequency-response graphs. And when those irrepairable buds can no longer hold a charge after a couple of months, I bet they like banking on users coming back to purchase that same ewaste again from them.
Slow down pal. How am I supposed to have SSG and hydration and hook with such a simple setup!? I need my system to be webscale™, not maintainable with minimal moving parts.
Since those services all died off my memory is a bit foggy, but I recall stacking contacts in one with Adium & being able to prioritize in that meta contact which service they provided. But I really only ever used it for two-person conversations so I had no experience with the group situation. Even still, a multi-chat app was a vastly better user experience than running several independent applications (with the cost of missing ‘advanced’ features & occasional outages as protocols needed to be reverse engineered & the proprietary providers had no incentive for backwards compatibility).
> Google particularly abandoned it for really no reason
What most annoying is seeing Big Tech now trying to write a new standard to comply with the EU instead of using the existing standard they abandoned that already has all the mileage & scaling looked at. Instead all the same hurdles will have to be overcome yet again, just like the current growing pains of Matrix meanwhile XMPP is still quietly holding strong for massive chat/presence systems.
True. But developers should push in that direction anyhow since it still means interop for those in that camp already… and considering how well those large systems have scaled, it’s a good idea.
We had universal chat applications & standards and interoperability in the 2000s. Pidgin (et al.) + libpurple allowed users to use a singular application for chat--even the proprietary protocols. We also had (& still have) XMPP from that era which many of the big boys like Google jumped on, killed, then jumped off (EEE?). Are we just repeating history (https://ploum.net/2023-06-23-how-to-kill-decentralised-netwo...)? There’s an XKCD about inventing yet a new standard despite us having good ones for decades…
I don’t know I agree with this perspective. The internet is in many ways an unsafe space & surfing it with JavaScript in allowlist mode (e.g. blocking by default) should be in the bag of tricks users can use to mitigate some potential issues. One may also want to automate scraping these docs to put in another tool or in a new, independent search engine whose MVP isn’t including a whole JavaScript runtime (and can be trick to read from the source code if using a tool that generates docs from comments instead of a generic file so the output HTML is easier to consume).
Setting a good example & being a good steward of the net is something docs like these could/should provide; that is to say, the author could make the static parts static & offer a <noscript> with a brief description of the interactivity the user might be missing. The docs are likely coming from dog-fooding the library, but came at the cost of making static content maximally available & providing a noscript message.
This isn’t a demos page--they are just static docs where the only interactive part is some JS to make it quicker to copy/paste. Right now these docs aren’t accessible to many reading options or search indexers since there is nothing on the page.
Blank page without scripts enabled by default or in a TUI browser. Seems these docs are just static content so I’m not sure why JavaScript is in the way of reading them.
I dislike them too, but they can be disabled. This makes them ‘good’ for remote pair with something like upterm so two users that disagree on the subject can have it their way. Inappropriate usage is rampant making presentations & in-person pairing way more difficult/unclear (luckily userStyles can be used to prevent it in the browser). What we need is languages to stop clinging to US keyboards as a limiter where => doesn’t need to be misunderstood as ⇒ or ≥.
How should a developer who learned on & is happy with Pijul or Mercurial … or Codeberg, or whatever feel otherwise? There’s an implicit bias in supporting a much narrow band of tools, especially a proprietary one, that gets codified when not starting at something more generic. And if your projects aims to be long-lived it’d be equally myopic to assume Git will remain the most popular tool til the end of time. As noted in a sibling comment, had the project accepted a tarball, then almost any platform—past, preset, & future (assuming filesystems with files & folders are still used)—would be supported. A good example of this is what happens in Nix where the base is a tarball, and all shorthands merely a convenience DSLs that map down to the tarball.
…Or use something generic like a tarball? Almost all DVCS have the ability to export an archive. Don’t build on lock-in; build on the generic thing… and then provide an ‘enhanced’ experience for something specific like Git or a specific forge.
> To add a package, first create a GitHub repository for your package. While Inko's package manager supports the use of any Git repository (e.g. one hosted on GitLab), the above list is populated using GitHub repositories only.
So another community that wants to lock itself into Microsoft products as well as Git in general. Why should a user’s choice for DVCS & forge make them feel less supported or inferior?
Yes. I couldn’t get comfortable with Guile for Guix, but having touch PureScript, Haskell, OCaml, Nix feels at home (other than the need for dymanic types).
Sounds like Microsoft… you get Microsoft npm releases signed if you use Microsoft GitHub Actions. Deployed to Microsoft Azure, built with Microsoft GitHub Codespaces enhanced with Microsoft GitHub Copilot, all from your Microsoft Windows machine.
Folks shouldn’t be forced to use proprietary software from US-based, publicly-traded megacorporotations just to build & sign their libre software.
Signal has massive usability issues: requires a phone number, requires a primary Android or iOS devices, can’t register multiple Android or iOS devices, requires Google Play services for notifications unless you get the APK which drains your battery (a fork, Molly, no supports UnifiedPush tho).
A lot of clients have OMEMO on by default now. You can’t enforce it for all clients & across the entire network tho as XMPP is a ‘simple’ protocol without a let of bells & whistles meant to be eXtended like OMEMO/OTR/PGP built atop it. With the newer compliance suites tho, to be considered ‘modern’ OMEMO & other e2ee options are expected to be supported. Gajim makes the UI easy, & Conversations isn’t bad. Profanity is a bit more obtuse to use since you need to trust your own keys manually too & they’re not autocompleted, but all the tools are there even for a TUI client.
Like when Biden said COVID vaccines for all Americans & then the health minister or whatever had to walk it back clarifying that that doesn’t apply to those taxpayers living abroad.
Almost none of the “free” or affordable options work the minute you put in an international address. Uncle Sam is one of the rare cases of taxing its citizens abroad, but everything about getting taxed abroad is more complicated.
Often, I like getting the context & history of a recipe. When researching foreign dishes these things help me understand a lot about what might be acceptable ingredient substitutes.