Furilabs was just in the news here because they discontinued their device models from a few years ago, and released a new device for a big price bump with _significantly worse_ hardware.
I know I would love to give them a try, but a 720 screen is an absolute non starter for me. It would be hard for anyone to sell me on just a FullHD (1080) screen in the era of QHD (2K) being industry standard.
Additionally, I believe their FAQ even admits that their already low power devices only get a few hours of battery life.
Small company that deals with what hardware they can get their hands on. They're shipping a device when others are not. It's a pretty straightforward equation right now; people who want to advance the ecosystem should consider it if they want a device they can drive and build for.
Otherwise there's no real reason to not just run Graphene.
It was discussed here when it was announced. I believe it was determined the hardware is an ultra-low-budget Aliexpress design that normally retails for ~$100 that they had custom built with a mic cutoff switch added to it (probably the cause of a large portion of the hardware price increase). I dont remember the specifics, but even thr most optimistic were pretty sure it won't get hardware vendor support for even a full year based on the specific processor it contains.
Replying to myself:
Apparently I was mixing up the new Furilabs FLX1s and new Jolla phone. The FLX1s that's a major downgrade from the prior FLX1 and some people were reporting are based on a design that's really cheap on Aliexpress and using very old hardware but with a custom spin to add some physical switches to it.
The new Jolla actually does look really good compared to all the other avaiaobale Linix phone hardware options.
WARNING: This is a Kickstarter device still, and needed funding to even create a proof of concept device last time it was discussed (extensively). It's a Flagship phone device and price, but with only the oldest of pans on how it's actually going to deliver some on of the promises.
Doubling down on this, get a Reader that let's you filter, and do so judiciously.
I have some feeds where I only allow thru items with specific categories. Others I have dozens of filters for "spam". And some I just had to give up on because they enshittified their feed to inhibit differentiation of junk/sponsored/spam content from real content.
Personally I just self-hosted a personal FreshRSS instance, but you can also get a lot of similar features from a paid Inoreader account.
You should talk to some people with kids then. I can't find the source, but I think the US national average is something like $1500/month for <40 hour/wk daycare. That doesn't account for child-to-sitter ratio differences, or cost of living differences either.
A few different friends around the country, not in big cities, have cited >$5K/month as the cheapest they can find for full time daycare.
It's significant enough that families with multiple children are often cited as being unable to have both parents with careers, because the cost of childcare far exceeds what one of them can make in their career.
To be fair, this makes some sense, you're effectively paying for a portion of a child care professionals career, plus the shared overhead for facilities and supplies. If you have a decent (<8 children per professional) ratio and have 2-3 kids needing daycare, you're paying for 25-30% of someone's direct salary, plus overhead. Very few people make so much more than a trained professional that they could afford to shell out that much.
To be clear, this plugin is only a keymap, and just extends the built in Emacs-style keymap option of VSCode. If you did much/any mapping of any keys in Emacs, or are looking to expose more Emacs-like features, you're SOL. VWCode is simply unable to support most Emacs editing features without a significant engine expansion, and that's beyond the ability of plugins to add.
I did exactly the same, though I wasn't an Evil mode user. I quickly found VSCod(e|ium) lacks the internals to even do many of the basic useful things of Emacs.
BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
Similar story here. I used vscode for about 3 months for all my editing needs without even having Emacs installed, but returned to Emacs because of how hard it was to learn how to modify vscode (I'm not a web dev) compared to modifying Emacs and because of a vague impression that vscode is slower in responding to my inputs.
It's definitely slower when doing any intensive background activities that Emacs would normally offload. But I've found VSCode has features readily available as one-click installs that are very difficult and convoluted to setup in Emacs. For some of those you end up either settling for less-ideal tools in Emacs, or because you're not an expert in the specifics of the tool being integrated, you end up with a much less optimized integration. And in either case you can actually end up with a net-worse performance in Emacs, even though the VSCode core is in a far less performant language than Emacs.
> It's definitely slower when doing any intensive background activities that Emacs would normally offload.
Emacs is single threaded and can't offload any elisp code. Even the stuff it can offload as background OS processes report in to the main loop and share time with editing, so a chatty background process can and does frequently lock up Emacs. So I'm surprised that VSCode, whose runtime is better suited to async jobs, ever feels slower than Emacs.
I actually agree with that. I should have added a qualifier to my previous comment (grandparent), namely, I use Emacs mainly for things other than programming, and if I ever start programming full-time in a language other than Lisp, then, yeah, (for the reasons you give) I'd probably use vscode instead of Emacs to do that.
I use Emacs for managing files (with Dired) running shell commands, bookkeeping, keeping notes and chatting with LLM services.
It's more like how to put a modern day car dash over an F16 fighter jet. One has modern expectations and standards everyone is already familiar with but far less power and features, while the other existed before usability was even an idea but has more power and features than even most experts can handle. And in this case (and analogy), you can always slowly remove parts of the interface that hide the more powerful features.
I say this as a 10 year Emacs user who left for VSCode and Zed because I decided I'd rather discover new modern features when they became useful (VSCode/Zed) rather than having to hunt them down when I became too fed up with the status quo and then have to spend weeks figuring out how to get them working (Emacs).
That said, I keep itching to go back for some of the power features. If only it weren't a full time job just maintaining a basic emacs config.
> It's more like how to put a modern day car dash over an F16 fighter jet.
Yeah, that's probably a better analogy.
> If only it weren't a full time job just maintaining a basic emacs config.
I've heard that before, and I don't get it. I might spend 20 minutes a month updating my config, but it's really a set it and forget it thing for me. What are people doing that requires so much work?
> What are people doing that requires so much work?
15 years ago I was in the same boat as you.I just had a set it and forget it config. But about 6 years ago I had to start adding addition languages support to my config, and started having to switch machines at work every year or so.
Emacs package manager has always been abysmal at reusing an existing config on a different machine, and always required significant updates to the config for the latest versions of the packages (which frequently have/had breaking changes every coupe years). So it became a config update every year or so, that would take a couple days at minimum.
Then the language support had to be addressed. With the couple days of updating every year or so, I start eying what other solutions are providing, especially since I was delving into new areas and toolsets.
A few years ago simple dumb syntax and identifier fuzzy completion stopped being sufficient and table stakes became intelligent context-aware autocomomplete. Emacs setup for that was incredibly bad and has been extremely poor for years up until very recently. Only in the last year-ish has actual working LSP support finally been added and isn't bolted into a system that can barely cope. That means there was literally a gap of a few years where Emacs at best failed to meet the minimim to even be considered as a primary editor. Even still, the setup is very manual to get even the most basic integration.
A similar rush of features is now pretty normal in editors, and Emacs is simply not keeping up. It's now a question of trade offs: how much do I want those crazy editing features of Emacs, and how many one-click support and integration features that are standard across almost all competitors am I willing to go without or spend hours every couple weeks setting up?
That said, I see some of those "legitimate business purposes" as things the CCPA was explicitly intending to redefine as illegitimate. In particular, while it says it would still limit third-party data collection for marketing, it would no longer limit when the company itself (e.g. Facebook) does that data collection for itself. Additionally the "analytics services" is standard speak for "all data that can be hoovered up for cross-site tracking", and is specifically exempted as well.
On the face there is certainly clarification that' needed, and some of the exemptions are needed (E.g. security features), but the current bill clearly includes extras that effectively completely revoke everything the CCPA tries to do.
