Neat! I recently bought a Sony NW-A306. I wish the battery lasted longer. Also, Android is slow and janky. On the other hand, it's Android so it runs Spotify.
But it is 2023. Things like GTK on Wayland should support fractional scaling. In fact it is already supported by Wayland and is in GTK project's pipeline, but open source software obviously have limited resources. So I think it is fair that people would complain this does not work, but I also understand why it does not.
Framework delivering a HiDPI display makes it more future proof. HiDPI displays aren't just a gimmick. HiDPI displays is super helpful when you are short sighted for example as the increased font clarity from a HiDPI display will help you read small text better.
The HiDPI display on MacOS and the excellent support for fractional scaling is one of my favourite features of a MacBook and why I wouldn't consider purchasing a "Linux laptop" (e.g. Lenovo or whatever else) before they support this.
Just from my understanding from having read the linked website: yes, you do.
"Applying the migration" doesn't actually do anything to the table, it just creates a new schema containing views over the old one, where the view for the table whose column you deleted hides the column. You can then try if your app still works when using accessing this schema instead of the old one. If you're happy, you can "complete" the migration, at which point only the table structure actually gets altered in a non-reversible way.
Any pgroll operations[0] that require a change to an existing column, such as adding a constraint, will create a new copy of the column and backfill it using 'up' SQL defined in the migration and apply the change to that new column.
There are no operations that will modify the data of an existing column in-place, as this would violate the invariant that the old schema must remain usable alongside the new one.
Maybe this is explained somewhere in the docs but I'm lazy: how does it cope with possible performance issue in highly trafficked tables? Can you somehow control the backfill speed if it's taking up too much I/O?
Backfills are done in fixed size batches to avoid taking long-lived row locks on many rows but there is nothing in place to control the overall rate of backfilling.
This would certainly be a nice feature to add soon though.
The bloat incurred by the extra column is certainly present while the migration is in progress (ie after it's been started with `pgroll start` but before running `pgroll complete`).
Once the migration is completed any extra columns are dropped.
I'm currently paying for Kagi. It's nice. But, so far I feel like it may only be like 2% better than Google, probably not enough to keep me long term.
A lot of times the results are better on Kagi than Google, but not by much. It makes sense they're similar since Kagi uses Google's index (among others).
True, but a bit of a moot point if both search engines will indiscriminately route you to those websites anyways. It's not like I'm opting-out of that issue by using DuckDuckGo right now.
Yeah, I'm strictly talking about search results. That's the main thing I care about. No ads is nice, but if I can't find information I need then that's not very useful to me.
Being able to block domains (without an extension) makes Kagi at least 30% better on its own. Maybe more. It's absolutely a killer feature and one that Google themselves used to have.
The outrage comes from having to carry both the wired headphones AND the dongle. The dongle is small and easy to lose. It's much harder to lose your headphones.
A lot of us don't have trouble understanding 1,000 millimeters equals 1 meter.
Same here: 1,000 millidays equals 1 day.