"Bundler includes checksums in new lockfiles by default" is the thing I'm most excited about. You still need to enable them manually in existing ones though with "bundle lock --add-checksums"
What is interesting to me is the `Ractor.shareable_proc` changes that solved a bug for a use case I was having. And in general fixes for Ractors make them more appealing to use right now, even though they have not removed the `Experimental` flag from them. They are still missing a built-in concurrency primitive like channels or a lock free queue; I'm curious what they will settle on, Ractor::Port is nice but not enough.
OK, so based on this video, I've turned on EasyEffects, added an Equalizer, set the input source to "Easy Effects Source" in the system settings, started playing pink noise, then tried to adjust the dials until the input looked closer to a horizontal line (it's very chaotic so that is hard to do).
As some sections of the video highlight it ended up needing to dip the mids and boots the lows and highs. This is my end result (so far, I'm probably going to tweak this continuously):
Preamp: -1 db
Filter 1: ON PK Fc 27.782795 Hz Gain -3.36 dB Q 1.7848856
Filter 2: ON PK Fc 49.40557 Hz Gain 1.09 dB Q 1.7848856
Filter 3: ON PK Fc 87.85691 Hz Gain 5.04 dB Q 1.7848856
Filter 4: ON PK Fc 156.23413 Hz Gain 6.43 dB Q 1.7848856
Filter 5: ON PK Fc 277.82794 Hz Gain 3.76 dB Q 1.7848856
Filter 6: ON PK Fc 494.0557 Hz Gain -1.19 dB Q 1.7848856
Filter 7: ON PK Fc 878.5691 Hz Gain -5.54 dB Q 1.7848856
Filter 8: ON PK Fc 1562.3413 Hz Gain -3.96 dB Q 1.7848856
Filter 9: ON PK Fc 2778.2793 Hz Gain -2.97 dB Q 1.7848856
Filter 10: ON PK Fc 4940.557 Hz Gain 0.3 dB Q 1.7848856
Filter 11: ON PK Fc 8785.69 Hz Gain 4.35 dB Q 1.7848856
Filter 12: ON PK Fc 15623.413 Hz Gain 8.7 dB Q 1.7848856
There's also an Output amp of -2.5dB that does not appear in the export for some reason.
TUXEDO InfinityBook Pro 15 - Gen10 - AMD Laptop Speakers.
It does make a positive difference (why don't they teach us this in school? ;) ). Please note I am music illiterate.
EDIT: it looks like changing the input source has no actual effect, just need to make sure the internal microphone's volume is not muted, and have to keep system setting window open while doing this, maybe the microphone is no longer on when the window is closed?. Linux is weird sometimes.
But the reason this is not widely talked about is two fold:
First, because those measurements are heavily room dependent and they sound worse than treating a room. Because the room affects the sound in ways that EQ can’t really fix anyway.
Second, because the goal of mixing and mastering is making music sound good in a big variety of speakers and environments.
1. I've never felt the need to use anything else apart from ruby's Net::HTTP, while I see every project I've worked on in the past add in stuff like faraday or httparty for doing JSON REST calls. Apart for the convenience aspect of it in terms of lines of code, is there any advantage for me to use your gem in such cases? (for example performance?)
2. I'm confused as to why you would need to do something special for fibre aware scheduling. Is it the case that ruby considers anything traversing into C world as "CPU bound" even when it sits idle and you need to instruct it otherwise?
3. How does it behave with ractors? I mean does it work called inside a ractor or when I'm initialising a "client" object in the main body, then trying to pass it to many ractors for them to use it in parallel. Prior to ruby 3.4 I've had issues even trying to use `pp` inside a ractor so I'm not expecting miracles, just curious how things are progressing in that area.
Thanks it was a fun to dive back into the multiplexing loop logic and finally refresh that code with socket action from libcurl and new ruby APIs...
1. the C parser in libcurl is much faster then ruby's and libcurls support for HTTP/2 and multiplexing - even back in 2010 while at LivingSocial we used curb to improve site throughput (it's improved a lot these days) with the multi interface at my current company CTM we can push out millions of webhook requests with very little CPU burn.
2. Fiber support is needed because like a normal C extension would call a function to open a socket write some bytes, wait, write some more and then wait, and read some, wait and read some more again. All of this while basically the CPU is idle and we're just waiting there blocking a whole ruby thread or even worse process (typical ruby process running rails could be pretty big too so that's a lot of memory consumed just waiting around doing basically nothing). Ruby threading model really helped this and curb was one of the few libraries or only one i know of that played nice with the ruby global interperter lock so multi-thread web apps could do stuff on other threads while one thread was blocked waiting on IO. With this new curb update now a single thread can do multiple http requests with overlapping IO meaning while one fiber is waiting another fiber can do some busy work like queue up more http requests or read something from a db.
3. The key is we're rb_wait_for_single_fd so any reactor (if i'm understanding what a "reactor" really is correctly) can run and do busy work while we're waiting on a file descriptor. It should* work correctly now, if you run into issues i'd love to know about it and help get them fixed.
What I'm hoping for now for ruby is either puma implements a Fiber pool rails db adaptors fully add fiber support then we should as a ruby community have a really nice story around multiplexing I/O to be more competitive with node.js / golang for web socket and other I/O heavy workloads. By competitive here i mean we can use less memory since we'll be able to keep our CPU's busy while we wait for the network or even disk (maybe).
Ah - thanks for the link. Now I have maybe another thing to see if we can improve in curb to ensure Ractor is fully supported. (it might be i just have not tried)
So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).
> if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine
Won't `localhost:3000` and `localhost:3001` also both be secure contexts? Just starting a random vite project, which opens `locahost:3000`, `window.isSecureContext` returns true.
This is used for scenarios where you don't want to hardcode port numbers, like when running multiple projects on your machine at the same time.
Usually you'd have a reverse proxy running on port 80 that forwards traffic to the appropoiate service, and an entry in /etc/hosts for each domain, or a catch all in dnsmasq.
Example: a docker compose setup using traefik as a reverse proxy can have all internal services running on the same port (eg. 3000) but have a different domain. The reverse proxy will then forward traffic based on Host. As long as the host is set up properly, you could have any number of backends and frontends started like this, via docker compose scaling, or by starting the services of another project. Ports won't conflict with eachother as they're only exposed internally.
Now, wether you have a use for such a setup or not is up to you.
they are all aiming to implement the same html spec
2. there is no official standard
there literally is
> A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification
Secure contexts, not a part of the html spec, are described in the w3c candidate recommendation, which I can assume you are calling the official standard, which states:
>5.1. Incomplete Isolation > >The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.
>5.2. localhost > >Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances. > >Given that uncertainty, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).
>6. Privacy Considerations > >The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality. > >From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.
This does not qualify as the "this" in my original comment.
Notably, assuming conformance to this standard, a browser might still not treat localhost domains as trustworthy if it has reason to believe they can be resolved remotely. However, I'm not sure in what environments this is likely to be the case, especially with browsers implementing their own DNS over HTTPS.
1. I can't write an email from an alias. For example I can't send an email from something+yourservice@example.pro. This is possible from Thunderbird using their bridge, but not from their email app on Android. I can reply to an email and it will preserve the alias, but I can't write one from scratch.
2. Emails are not downloaded locally on Android so I can't access them when internet is not available.
These 2 have been consistent issues for me over the 3 years I've used them, and when I've contacted their customer support about it I was told they have no intention of fixing them.
I use Proton on Android and I can write a new email using one of my aliases. Maybe it was fixed recently.
Regarding n° 2, I think it will never be fixed, given the nature of the service itself, in which all emails are stored encrypted, and the encryption keys are in the server.
https://blog.rubygems.org/2025/12/03/upgrade-to-rubygems-bun...
"Bundler includes checksums in new lockfiles by default" is the thing I'm most excited about. You still need to enable them manually in existing ones though with "bundle lock --add-checksums"