The article’s understanding of Java’s Virtual Threads is incorrect. Virtual threads have a preemptive concurrency model, not a co-operative one, so suspension points are not only at calls to things like Future.get()
I really hope Fastmail implements the JMAP spec for calendars and contacts soon. They’ve had the mail part of the spec implemented for a while, but it still requires CardDAV/CalDAV for contacts and calendar access.
We're working on it. We still use an unholy set of earlier versions of JMAP internally for our contacts and calendars; in particular the caldav_sync code is gnarly - I wrote it over 10 years ago when I knew less about calendars than I do now! It's still using an earlier branch of what became the perl Net::CalDAVTalk library interally, even though our frontend API is an almost-up-to-date version of what will become the JMAP Calendars spec eventually.
The downsides of developing and testing this stuff as we were writing it up!
We've finished rewriting the objectid generation to give smaller sized and more sortable IDs (they're an inverse of nanosecond internaldates now, plus some extra magic on the low bits for IMAP appends to avoid clashes)... which we wanted to speed up and reduce disk usage for the offline mode.
Next up is indeed updating to the latest spec on calendars and contacts. Files might take a bit longer, I really want to do some desktop clients for the files system, we have a really nice files backend at Fastmail which is only accessible via our interface or WebDAV right now.
Off-Topic: Thank you for not only providing a stellar service with Fastmail, but also for contributing back to the OSS ecosystem and the specifications/RFC work. This takes a lot of time and we all benefit from this work. It helps many people/small IT shops to run a system outside of the "big ones". Again, thank you.
The next, next big thing would be the Chatmail relays[1] supporting JMAP based servers (right now it's Dovecot) and this new targeted push extension for faster notifications without battery drain on mobile. I can see how the Fastmail mobile client will benefit from this RFC as well (it's already incredibly battery efficient, thanks to the team).
What good is a protocol like JMAP as long as common clients like Thunderbird, K-9 Mail, the iPhone email client and others don't support it? Without some concerted effort it will never take off. Then there is the question of what problem it solves that isn't already solved by existing solutions.
I think Thunderbird will implement JMAP at some point, because as I understand it their upcoming hosted mail service, Thunderbird Pro will offer it.
I looked into adding JMAP support to Thunderbird but the client is so tied around the ideas and principles of IMAP, it needs surgical refactoring of many parts of it and I don’t love C++.
So instead in my spare time I am developing a JMAP only gnome email client, using many Stalwart libraries. Think Geary but Rust instead of Vala, GTK4 instead of GTK3 and JMAP instead of IMAP. It’s been mostly an excuse to play with Rust and gtk-rs and Relm4 (beautiful Elm inspired rust bindings for GTK4). Someday, it will be released.
Client support for a new protocol is never that quick, but I believe adoption will happen, at least outside of the big providers, who will never support it.
> We have been experimenting with this for a while now and are using Stalwart as the software stack we are building upon. We have been working with the Stalwart maintainer to improve its capabilities (for instance, we have pushed hard on calendar and contacts being a core piece of the stack).
However, unfortunately I am unsure whether this is a good source or official page.
The lack of support for JMAP in common mail clients has been my concern for years. And recently Fastmail went ahead with releasing its own Electron-based desktop app that uses JMAP for its mail service. Mozilla Thunderbird could do with some support (financial and/or people wise) to get JMAP implemented. I don’t know if Fastmail the company has done much on this aspect, but hope they do.
I control my Mitsubishi mini-splits with an esp32. I’d never done any soldering or worked with a microcontroller before, but I was able to install this into 4 units in a single day.
This esphome project has great integration with home-assistant and Apple Home and I’d highly recommend this approach over the Mitsubishi app if your unit is supported and you’re willing to do a little work.
It doesn't look like this is available just yet. I can't wait to see more details when it comes out.
I have a JetKVM (https://jetkvm.com/) and it's been absolutely fantastic. I'm still waiting on the ATX expansion board, but the core unit is used to monitor my homeserver.
Can a single JetKVM control multiple computers? I have several AI training machines that occasionally got stuck and need a power cycle. Most of the time this happened when I’m out of town so it has been annoying.
It can only control one set of monitor/hid but through the extension port you could wire up something for multiple computers power buttons (the ATX module mentioned by GP uses a rp2040, which has plenty of GPIOs).
I think it would be simpler to buy a network PDU (or iot plugs) for your use case, assuming the computers can be set to power-on automatically.
Wait. My theory was that they were so popular making a solution like this, that they were overwhelmed with orders. Kinda like how Framework have a 3-6 month wait from order to delivery.
I'm guessing they're getting through the kickstarter batch and then they're going to launch a store, particularly once they get all the bugs worked out of the manufacturing process.
I kinda would like to see a DP over USB-C version so keyboard, mouse, video, and power all go over one cable.
This looks pretty great. The UI looked fantastic, and the post mentioned that it was open source. However what's open source appears to be the DuckDB extension, which forwards the requests to a remote URL. I've not been able to find the code for the actual UI.
Is the actual UI open source, or is that something MotherDuck is allowing to be used by this while remaining proprietary? Right now it doesn't appear like this would work without an internet connection.
Yeah, this is really concerning. The handwaving around "keeping the ui up to date" by hosting it on ui.duckdb.org instead of embedding it doesn't taste great to me.
At least it's hosted on duckdb.org and not mother duck, but I really would expect to see that source somewhere. Disappointing unless I've missed it.
It’s quite funny the docs also say this about the configurable url:
> Be sure you trust any URL you configure, as the application can access the data you load into DuckDB.
That’s certainly not what I would expect if someone gave me a “local UI” for some database.
I’ve only just once toyed with duckdb, was planning to look more at it - looks like will need to have my guard and see what actually is “local” and doesn’t ship my data to a remote url.
I'm a co-author of the blog post. I agree that the wording was confusing – apologies for the confusion. I added a note at the end:
> The repository does not contain the source code for the frontend, which is currently not available as open-source. Releasing it as open-source is under consideration.
(Someone could write an actually open source UI extension for duckdb, but that would require a lot of investment that so far only motherduck has been able to provide.)
I've looked at quite a few options, and this one (the product of a single person) is a great base, and MIT licensed:
https://github.com/caioricciuti/duck-ui
I’ll never understand how any UI projects don’t include an actual screenshot of their project as the first thing on their landing page. It seems so obvious.
I find the SqlLab in apache superset to be very good, and I have duckdb as a data source (anything that supports SqlAlchemy works). It works very well. To be honest, when I first saw the screenshot, I thought it was SqlLab. I haven't actually tried the duckdb ui, though.
That is really interesting. I am thinking of toying with same combination for my small project. Can you share a bit on your use case? Would love to know more.
Honestly I hope they keep some things proprietary. Just making everything FOSS is not a sustainable business model, and I would quite like DuckDB to continue to exist.
I have similar concerns for Astral. Frankly they're single-handedly unshitifying Python, and it would be a tragedy if they run out of money and we're back to dealing with Pip.
it works with flutter. we many active flutter developers in our discord too that will flame us if we introduce any bugs for them. its good because then we can fix this asap.
Relational databases are not the preferred storage mechanism at Amazon. If a team wants to use an OLTP relational database it’s possible that it will be a decision they will need to defend at any kind of design review.
Of course there are relational databases running OLTP workloads, but it’s far away from the norm. There was a program a while ago to shift many RDBMS systems onto something else.
It can but it's usually more obvious what's happening with code and how to fix it. Amazon wants you to think about the scaling issues while building as they don't want to lose the area under the customer curve on the far right.
The theory is that with rdbms you have a magical box that scales vertically until it doesn't. And when it doesn't all you can do is scale back the customers until you fix it with sharding or a re-architecture. Basically you tend to hang yourself with indexes and transactions. Also generally when an RDBMS fails it fails down to like 30% throughput.
I recently finished a contract at a company who has gone full on dynamo with the idea that if we have slow queries and dynamo is good for Amazon, then it's good for us too. I've ran some explain on the queries causing issues and of course those queries didn't leverage indexes like they thought ....
I ran explain on the original mysql implementation. The basis of the migration project to dynamo was mysql couldn't cope with our scale but that was bullshit
reply