mildred593

Very nice. Unfortunately with tunes with notes that are identical but with different sylabes, it's not separated clearly, but I believe this is unavoidable unless there is a speech recognition too. Very nice tool.

That's why I never accepted the app from my bank. It still work most of the time but it's cumbersome for some uses (like adding a new recipient for wire transfers, it takes two days).

A Linux distribution that uses well the CPUs de have now and do not waste resources would be godsent. Zero copy networking is needed as well. Avoid wasting resources in all sort of ways, I can only dream.

This is really a great manifesto, but I fear that it might go a bit too far to be realistic. Perhaps rethinking the filesystem and databases is not the top priority.

I can run this on an AMD Framework laptop. A Ryzen 7 (I dont have Ryzen AI, just Ryzen 7 7840U) with 32+48 GB DDR. The Ryzen unified memory is enough, I get 26GB of VRAM at least.

Fedora 43 and LM Studio with Vulkan llama.cpp

Never trust a LLM for anything you care about.

Can't wait to have it in my language!

I also improved an existing custom component for this : https://amc.melanie-de-la-salette.fr/polyfill.js

HTML imports could not include markup within the body, it could only be used to reference template elements for custom elements

I remember just using PHP sessions back then on a XHTML document produced parse errors. Because PHP added the session to the query strings of links and used the raw & character instead of & for separating params in the query string. Thus causing a XML parse error.

There was a push to prevent browsers to be too lenient with the syntax in order to avoid the problem that sloppy HTML produced (inconsistent rendering across browsers)

Would that help with Wine?

Started with a large shell script, the next itération was written in go and less specific. I still think for some things, k8s is just too much

https://github.com/mildred/conductor.go/

I wouldn't even know how to prompt the complex queries I have in mind. For simple queries that an ORM could write, I see, but for something complex that generates actual data from the tables, I don't see it coming.

For my work I use SQL pretty extensively, the PostGreSQL flavor, and it's really powerful. I wonder how it is possible to do without except for very simple queries where the ORM might kind of work.

There is however a weakness of SQL is that it's purely declarative and it's difficult to make sure it does the right thing. I often find myself in front of queries that are badly optimized and I'd welcome a language that would be less declarative where you could tell the database engine which index you want to use and how explicitly. The optimizer has table metrics but with the domain specific knowledge the programmer has generally better insights.

I'm not surprised at the powers of htmx. I have been doing single page apps (or close to) using Rails + Hotwire (Stimulus/Turbo) and it works really well.

The only thing I remember is that I would never install SP2 because of EULA. I don't remember the specifics though. Around that time I started mostly using Linux anyway.

Do you think that at some point in the future, browsers could bundle in htmx or something similar, and that we could imagine web pages that have javascript disabled but with great interactivity due to htmx? This could perhaps be used as a security feature.

Web people are actually insane. Making security depend on etld+1 is just complete madness.

The proposal in the video is actually not bad (domain at the start followed by actual URL) if they can put back tge http(s):// prefix in the URL part.

The article says "Unfortunately, Jamstack tools require an initial setup and an initial (and continuous) learning" but with the bare minimum, static website generators are nothing more than glorified template engines.

I'm using Hugo and for my purposes, I always start without any theme. Basically, I start to write a markdown file for each page, and an HTML template, then if I need more complexity I have the power available underneath.

Static website generators are not necessarily complex to use, and they generally stay compatible from version to version so you only need to learn the new features and only if you want to use them.

The issue with moderation is that not everyone agrees. Moderation should be plug-in and multilayer. Everyone should be able to choose which moderation they trust or distrust.

Full p2p is technically complicated and does not work well for small devices not always connected, we should keep servers to host the discussions.

The servers should be able to subscribe to a moderation. You don't want to host a discussion illegal in your country gor example. Users should also be able to move servers painlessly. If the users trust their servers with their identity, it does not need to use crypto for user identity. On your profile page on a server you can link other servers identity and that's enough and simpler.

If a discussion group is private, it should only be hosted in servers of their members and not elsewhere.

I started working on such a system https://github.com/mildred/disputatio.nim but beyond the technical stuff I have no idea how this could gain adoption.

OAuth can already work without a backend...

JMAP really solves many problems and allows you to do many things that are just not possible with IMAP. Also, IMAP has many ways to (badly) perform the same task, not all supported by all servers or all clients. MIME parsing is not easy to do and there is not always quality libraries available for your language... JMAP solves all of this.

The problem with the proxy is that to be efficient, I believe the proxy will need to store all IMAP messages in an indexed form on the proxy-side.

The problem with IMAP is that some requests are not possible efficiently, and the real breakthrough of JMAP is that those requests are now possible and clients are now allowed to be fast. For that though, the server-side JMAP needs to access the indexed mail store directly.

SQLite have a bunch of features that would allow limiting what you can do in a request, and if you limit the access to a database by the user that puts e-mails in that database this is easily doable.

I started looking at implementing that

Offline is just a matter stable identifiers on the server. It's the client that is responsible for caching the e-mail content on the device.

Also, the fact that JMAP makes it convenient to only download part of a message, and let the server do all of the message parsing does not encourage the client developer to do much processing client-side and keep e-mails blob in cache to be processed offline.

blood clots, anyone ?

JMAP is great but is not nearly enough. it would still need some improvements... on the protocols and on the available servers. I experienced slowdowns with Cyrus (which is the most advanced implementation I believe) on complex requests.

Also, the great idea behind JMAP is to chain requests so a series of tasks is performed on the server and the client then get the end result. This works great for the majority of cases but the replacement syntax (to replace results from a previous request in a following request) is not powerful enough in some cases (when trying to reuse complex responses in follow-up requests)

The other issue is that there is no way to easily groups e-mails from a given contact. There are JMAP extensions for CardDAV and CalDAV that can be of some use but it's difficult to bridge them with the Email spec and get all e-mails from a given contact for instance.

Last, it lacks editing features like appending a custom header to existing e-mails. The fact that JMAP abstract away all of the MIME format is great, but makes it difficult to just add a single header to an email.

What would be the benefit to using JMAP in thunderbird?

JMAP main benefit is that it allows a mail client to to things efficiently in JMAP that are extremely difficult to do in IMAP or take a long time to do. Merely adding JMAP support in Thunderbird will not add any benefit.

The benefit will come if Thunderbird is refactored internally to make use of the nice properties of JMAP, but then there will be a problem with IMAP compatibility which must be kept.

JMAP is nice for new mail clients that can move away from a folder-centric paradigm, but if you already managed to use IMAP then it's less useful.

What about including the true cost of remediating lithium pollution?

I had a really similar idea I'm working on and this can be solved by federation, and allowing users to move freely between servers. A gicen server could have its own moderation list. If you want to bypass it you'll need to connect to a server in another juridiction.

typo commits might be really useful, especially if you can bisect a bug from one of those commits. it happened to me.