They depend on the Play Service and Play Store, that's for sure. But I'm pretty sure they know it's a risk already.
Don't get me wrong: they are locked-in, that's a fact. And to be fair they benefit from all the work of Google on the OS. But that's not a reason to desire to go further and lose even more control.
Framework is a not a huge organisation. This sponsorship consists of a few laptops and committing to a $250 monthly donation. There’s no contradiction here. CachyOS is also not a huge project.
I don't think that carries the weight it used to carry, if it even used to carry any weight. Measuring things by popularity tends to give poor results anyways, you want to sponsor and contribute to good things, regardless of their popularity.
Even if Framework were to dismiss or overlook the controversy surrounding Omarchys creator, which is ultimately their call, surely there are better ways to allocate OSS funding than sponsoring a multi-millionaire executives pet project. He can afford to bankroll it himself.
But it's anathema to the cosmopolitan multiculturalism we practice and appreciate in most of the anglosphere and parts of western Europe. Of which much of the tech world / HN posters are part of.
I'm a European immigrant to Canada, in a suburb of Vancouver which is plurality Chinese with Europeans at about 30% and its totally cool and normal.
But I'm also typing this from vacation in Japan where they famously don't welcome immigration much. But people don't seem as upset by Asian nativism compared to European. And I don't have a diplomatic way of explaining the difference - it's the "bigotry of low expectations."
This naturally ends up being controversial, especially in tech, when some of our brightest minds are from other cultures. It doesn't help his case that he's not even from the places he complains about, so he's another outsider complaining about outsiders, which always looks bad.
dhh always been "controversial", initially it was mostly about strongly held opinions about software, engineering and such, presented in a very vocal way that got a lot of attention at the time. Then at one point Basecamp had some drama about employees calling customers names, which spiraled into a debate about racism and company culture, and ultimately leading to Basecamp banning "discussions about society and politics" or similar. More recently he started sharing opinions about London having too many foreigners, immigrant communities having gangs of groomers or something, and a bunch of Ruby community members have written publicly about what they think about him.
The air around dhh always been dramatic for various reasons, not sure that particular theme is new. But I think is new is that currently people are re-evaluating if they want a prominent community leader to have views that could be seen as "against" members of the community they're supposedly leaders over.
Ghostty feels a lot less native than foot on Wayland. Example: it doesn't respect Fontconfig preferences, so it doesn't use your configured monospace font. In general, Ghostty feels quite alien for me.
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.
They already do; Google's flavour of Android adds plenty of proprietary components on top of AOSP.
reply