A really neat feature is that you can also trigger a job by just submitting a yaml file (with the web interface, the API or the cli) without needing to push a commit for each job. This is neat for infrequent tasks, or for testing CI manifests before committing them.
I tried using Tauri a few weeks back, and the build system is an absolute nightmare.
I gave up after a few hours. The last issue I encountered was it trying to link udev and libinput. libinput is a library for writing compositors, and their website literally state "libinput is not used directly by applications". I've no idea why Tauri was trying to link this (and some rough ideas of why it wasn't working due to the absence of udev on that host), but at this point, I didn't care any more.
AppImages are supposed to be able to handle all of that and I have used a number of them that do. In the case of Tauri though it seems nobody on the framework team knows Linux well enough to fix the build process to not constantly break as libraries update on the GitHub Ubuntu VMs or to make all the required dynamically linked libraries get included in the AppImage. And finally most of the downstream app developers have never written an app for Linux and chose the framework expecting it to solve the problems it clearly isn't.
I think Typst looks really interesting for some scenarios, but inadequate for others.
I like RST a lot for Python documentation, because of all the directives for types, admonitions, and lots of domain-specific stuff. I wouldn't use RST if I'm writing a book, or a research paper.
In the same way, Typst looks like a great candidate for those last examples, but is likely unsuitable for documenting a library written in Python.
> eventually we'll be back to normal carrier-based carrier message
Why would you want to go into this closed model, where you’ll likely be charged per-account? How is this any better than XMPP, email, or any other IM protocol out there?
> generally included in the plan you pay anyway for data access.
Er, what? The main reason why most of the world moved from SMS to internet-based messaging is because SMS was far more expensive.
> having it for emergencies is nice
In what kind of emergency could SMS be useful?
> just to bootstrap an alternative, secure channel.
But you need to exchange SMS numbers to do that. You might just as well exchange emails, XMPP, or whatever other protocol your going to use later and skip SMS entirely.
Because SMS is horribly limited. 140 chars per message* (less if chars are not plain vanilla ASCII), no support for attachments, group messages, reliable delivery receipts, emoji reactions, etc etc.
* There's a terrible hack called concatenated SMS that strings together multiple messages to build one longer message under the hood, but if any of those parts go missing along the way, the whole thing gets dropped on the floor.
For the proposed use case, you don't need those things, except maybe the 140 character thing, but I've never found that limiting, since phones stitch them together nowadays (and have for the past 15 years?).
Sure, RCS has those functions, but half of them are broken 60% of the time, and you don't need those anyway for bootstraping into wherever you actually want to talk, and for short messaging.
RCS brings nothing to the table if all you need is to tell mum she needs to come pick you up. On the contrary, it might fail you because it tried and failed to send that message over a 4G connection you barely have, rather than sending it as an SMS and then actually arriving. And you're never going to use it for group messages, attachments or with emojis unless its an actual service you intend to use for serious purposes, which is exactly what the comment I was responding to said you weren't going to use RCS for anyway.
I disabled RCS (and iMessage back when I had an iPhone) for exactly these reasons, but still use SMS as a fallback with people I don't actually know and never intend to talk to again, and see no reason to upgrade to RCS even if it wasn't broken, since for my use cases, the extra feature set isn't needed. If I need more fancy features, its for use with people I actually know, and thus people I can get in touch with on not-SMS.
Mostly because my understanding is that RCS is meant to be a drop-in replacement for SMS and if you’re on a device that supports it (or your carrier-specific configuration of RCS) you don’t actually have a choice and your “SMS” is actually RCS and you must use it and hope it works.
Given that there's a 'Disable RCS' toggle (and a 'Resend as SMS' toggle for that matter) that seems to re-enable SMS and eliminate the RCS weirdness, this doesn't really seem to be true. I guess it could be in the future when carriers disable whatever path SMSes are currently going through, leaving you only with RCS that might still be borked.
I'm not entirely sure what you're claiming here, but broadly speaking no, this is not correct.
RCS is, by spec and in practice, intended to fall back to sms/mms if it doesn't work for some reason (e.g. you're roaming and not connected to your carrier. or have opted out. or they're having an outage. or...).
And there's an opt-out (partly because it kinda requires syncing your contacts to the RCS servers... technically only for "online presence" and for any individual you contact to check their RCS status (which is completely reasonable) but do you know where that presence toggle is in Google Messages? I don't).
The fallback is not really automatic or anything, RCS's feature-set is gigantic and allows senders to have far more control over the message's presentation (https://developers.google.com/business-communications/rcs-bu... currently has visual examples of this). It's rather clearly a "built for businesses" system, at least in part. But "RCS might not be available" is very much a core expectation for the stacks as a whole - the world is a big place, and there are many old phones and out of date apps, even if every carrier gets on board. (this is very likely one of the reasons why everyone's just piling into Google's stuff)
If they ever get things working, they might try to force it everywhere, but that's probably like a decade or three away at a minimum. Accurately predicting industry and legal trends on that kind of horizon is basically impossible. They might be planning on it (I have no evidence either way), but achieving is an entirely different matter.
GitLab is slow and its pages are heavy. I often have to work on slow/unreliable internet and GitLab pages simply can’t finish loading. Most of them need to load megabytes of JavaScript before they even fetch the data to be shown. The data being usually under 1kB of text.
The conditional here only makes it stop when it reaches 100. The solution can be adapted to use a while loop if you’re okay with it running indefinitely.
Other would be to use goto (though Python doesn't have it) & introduce something that will panic/throw exception, like creating variable with value 1/(max-i).
Looks like this is just a clone of pre-commit, with the same general design.
> pre-commit is a framework to run hooks written in many languages, and it manages the language toolchain and dependencies for running the hooks
The “and” here are the main annoyances with pre-commit. It does too many things, which would each be best served by a separate tool.
As a developer working on a project, I already have mechanisms to set up a development environment. Having pre-commit install another copy of the dev environment is redundant, and typically necessitates duplicating dependency declarations too.
I’d much rather see a tool that focuses on running commit hooks, while leaving dependency management to another tool. Most projects already have something in place anyway, since dependencies are necessary for development beyond the scope of pre-commit hooks.
The really useful part of pre-commit is that it: (1) only runs hooks based on file that changed and (2) stashes all unstaged changes and untracked files.
The latter is possibly just a Git feature that should come into existence (it's annoying to have to make sure your hook is robust against this). But I think "being a package manager" is what they think the main point is.
probably not relevant to you, since it is yet another tool for managing your development environment, but maybe have a look at devenv (https://devenv.sh). it's main purpose is managing the development environment, but it has integration for pre-commit (or even prek iirc) that let's pre-commit do it's thing, but takes over the dependency management.
Indeed, “Software Transactional Memory” sounds like a magic black box. It feels a bit like reading “just use an sql database and transactions”. It’s not really telling me how the problem is solved, just to use someone else’s solution without understating how it’s implemented.
A really neat feature is that you can also trigger a job by just submitting a yaml file (with the web interface, the API or the cli) without needing to push a commit for each job. This is neat for infrequent tasks, or for testing CI manifests before committing them.