But… the 3.6 -> 4.0 release was just such a pain. We spent more than a year trying to cram too many features in v4.
Clearly feature-based releases were just not cutting it, especially as Chrome was shipping new versions fast.
For the longest time people were saying it was the wrong move, but really - that was absolutely necessary, and proved out to be the right thing to do. The Stable / Beta / Alpha ("aurora", was that the name?) channels massively improved our yield :)
>For the longest time people were saying it was the wrong move,
I detested Firefox from v4 onwards and finally got off the crazytrain at 12.
Other than the version numbering becoming vapid, the browser itself became vapid. No longer was Firefox about the users, it was about Mozilla.
That has remained the case to this day, and I have not bought a ticket to this day. I'm not counting the first ticket as a purchase since it was forced on me.
I'm hopping between the Pale Moon space station and (begrudgingly) the Chromium train now depending on what I'm doing.
Atuin has encrypted sync, that'll be a big difference.
I've used mcfly for years and I appreciate the hard work cantino has put into it, but mcfly is currently looking for a maintainer while the maintainer of Atuin has recently committed to doing so full time (https://ellie.wtf/posts/i-quit-my-job-to-work-full-time-on-m...). That may make a difference to some people considering which one to pick.
Both are implemented in Rust and use SQLite as storage, so both should be equally performant in terms of startup latency and storage capacity.
The ctrl+R UI of each is different but that comes down to personal taste.
I just tried to use atuin... I have to login, but I don't want to :( I tried to run a search locally... but I have to run a PostgreSQL server??? Why isn't it just allowing embedded DB like mcfly? I know this isn't the place for support, but I give up trying to get it to work :(
I'll also plug my project [0] as another alternative that supports syncing (similar to Autumn) and also has a number of powerful customization features (e.g. custom columns to collect arbitrary metadata with each command, like the git remote) and an AI shell command generator.
> The key feature of McFly is smart command prioritization powered by a small neural network that runs in real time. The goal is for the command you want to run to always be one of the top suggestions.
I need Signal… so it had to be an Android phone. I also need a good map app, and Spotify.
I tried many of these phones, and they all had 2 main problems: poor build quality (random shutdown, compass failing, random android bugs), and bad bluetooth, making it impossible to use headphones (I even tried to use wired headphones, but then, there's no wired earbuds with active noise cancelling).
The only phones that were "good enough" were the 4" Unihertz Pocket and the 3" Jelly.
But the bluetooth situation was unbearable (cracking noises, sync issues), and some hardware problems just made me anxious (couldn't rely on the phone to wake up, or going on a hike).
I just ended up getting a Zenfone 8, which is a massive phone, but considered the smallest. It's way too big for me, and does way too many things. But… there's no other options sadly.
I use lineage supported lte tablets with sd cards, rooted without google play (10 inch) that are usually around 50-100$ used so you don't even care if they get lost.
You don't use those on the go to distract yourself, because it's in your pack. I stopped drunken texting and calling people alltogether as well.
Ebook-Reader, LUKS with termux, VPN, WebDAV makes this essentially your digital home on the go without the hassle to open/boot a laptop.
I agree; I've really tried to find a phone that isn't "modern" but has the features I need and want..has to be able to make phone calls, encrypted messaging of some form, GPS and NFC payments while not being beholden to G/A/M. I've yet to find that so I still look. Currently use Graphene on an older pixel but it lacks NFC payment ability.
K-Meleon used the Gecko rendering engine but with a native chrome and no SpiderMonkey. It also powers Thunderbird and the SeaMonkey browser. I'm sure it turned up elsewhere before it was too 'baked in' to Firefox.
In the case of Thunderbird and seamonkey, Gecko was not embedded, but was the "embedder".
For a short time, there was some attempts (native cocoa and gtk widget) to embed gecko, but it was really not meant to be, it was really hacky and never matured.
"There was never a proper embeddable gecko" is both (a) a strong claim which with some difficulty we might be able adjudicate, but not especially important whether we do or not because, crucially, it is (b) not the same thing as saying/proving that "Gecko was not originally conceived to be embeddable" (or proving that its negation is untrue).
Gecko was not, at the time that Servo was conceived, supposed to be easy to embed. Gecko had, by the time that Servo was conceived, undergone refactoring that knowingly made it more difficult to embed. It would be accurate to say that, at the time that Servo was conceived, embeddability of Gecko was an explicit non-goal.
This is exactly why I raised the issue of the logical throughline of the other comment—what is the point of mentioning Gecko's embeddability in this discussion? All right, Gecko is "notoriously unembeddable". So what? It's a complete nonsequitur, and it risks catching anyone off guard if they're not playing close enough attention and they mistake it for a salient retort of... something not actually stated or argued here
I respect you and your contributions to Mozilla and the Web, but you're wrong. These two sentences aren't even logically consistent:
> I'm just saying gecko was not embeddable and was never designed to be so. There has been some efforts, and all failed.
Aside from that, sorry, but I have a huge distaste for the XKCD-style just-make-a-claim-on-the-internet-and-wait-for-someone-to-correct-you strategy of factfinding. It's reckless and annoying.
Anyone who's curious about this subject has more than enough information from this thread alone to turn up the relevant details on their own by now. I'm not going to do any archeology at this point in the discussion, because my patience and the amount of resources I'm willing to put into this topic have by now been exhausted. The only thing I'll say is that the Components.classes[`@mozilla.org/embedding/${...}`] namespace didn't exist for no reason.
Alright, you don't have to engage. I thought maybe I missed something before my time.
For others and historians :) … some efforts were made I think around 2008 (by Brad L. and/or Mark F. … I don't remember so well). A shortlived GTK widget was attempted at some point.
But this lead to nowhere because… well, it's hard to bend Gecko that way, because, again, Gecko was not designed to be embedded. And also because leadership was not pushing into that direction.
About the "not designed that way", what I mean is this:
We had many abstractions for sure to make it multi-platform (and that was amazing achievement, really) but embedding requires mechanisms to hook the event loop and the rendering pipeline into the embedder, in an agnostic way. Which is the part that was missing in Gecko.
Webkit had a proper, well designed, embedding story.
But… the 3.6 -> 4.0 release was just such a pain. We spent more than a year trying to cram too many features in v4.
Clearly feature-based releases were just not cutting it, especially as Chrome was shipping new versions fast.
For the longest time people were saying it was the wrong move, but really - that was absolutely necessary, and proved out to be the right thing to do. The Stable / Beta / Alpha ("aurora", was that the name?) channels massively improved our yield :)