Ah but you see, the challenge is to get a 3-split PBP on an M2 pro on a monitor with a native res of 7680x2160, each one scaled down 33%, working at 120hz with HDR, all hidpi like so:
┌─┐┌────┐┌─┐
│ ││ ││ │
└─┘└────┘└─┘
It creates some wonky math and requires plenty of dock and cable shenanigans and unlocking resolutions above 8k via BD. It's the third "monitor" where it gets tricky with the M2 pro especially at these resolutions.
I hate spending any unnecessary clicks or keyboard shortcuts on getting whats out of my head into the computer. I used yabai before primarily, now using aerospace. Since the monitor is super ultra-wide (57 inches with a very high DPI) the native resolution makes everything ultra small to my eyes. It's the same height as my 34-inch Samsung G5s which are 1440 pixels tall natively, but since this one is 2160, it would have to be 1.5 times larger physically to look decent at native res especially on macOS. The only other option is to scale the UI 1.5x which is where all the problems begin.
I like the three-column separate monitor layout because I have hotkeys, primarily driven by my mouse but also usable keyboard-only where I can easily switch between monitors with `⌘+`` which moves my cursor between them. I can select whichever monitor I want and put my mouse to it, and I can switch to any workspace on any monitor quickly. I also have hotkeys that sync three workspace numbers across monitors, so switching between them switches all AeroSpace workspaces on all three monitors simultaneously. If I have five projects going, I'd have the terminal on the left, Linear and other communication tools on the right in accordion mode with AeroSpace, and I can use my mouse or keyboard exclusively to find exactly what I'm looking for almost as fast as I think of it. I spend zero time on window management or organization now so it makes it thoughtless to use.
If I'm just using the monitor's native resolution there's no real way to do portals — having two apps open as sticky and only switching a portion of the monitor space to a different app while keeping the other sticky. There are hacks you can do with AeroSpace, especially since AeroSpace doesn't use native macOS Spaces, but the three-monitor layout is a much more robust approach in my opinion just a bit of a nightmare to setup. Theres a million little mac annoyances you have to fix.
...And then there is the near-infinite trickle down of apps that rely on apps that rely on arcane configs and so on. This is truly the OS from hell. At least with Windows you know it's going to be garbage so when anything works on any level you are maximally impressed. But I have to spend my weekends isolating window shadow disabling functionality from yabai into it's own binary because I switched to aerospace which requires 'displays have separate spaces' to off, which just so happens to be exactly what yabai requires to be on, to remove window shadows, which is the only use I have left for it.
Just like the excel world championship I would find a macos ricing/window tiling competition equally enthralling. You read articles like the OP and at some point all you can do is laugh because lord (Cook) knows you've cried.
This tool is invaluable, I love it so much. I have 2 workspaces and I love just running the command (via Alfred) when I plug into my dock at either place that fixes all my monitors. I could script it so that as soon as my computer recognizes a monitor UUID it fires off the correct displayplacer command but I don't switch often enough to care (the 2 desks are 3.5+ hours apart).
When I was commuting daily displayplacer was even more indispensable but even for just unplugging my mac and using the internal screen vs my monitors I get a ton of value out of this tool.
Yes. Postgres stores the checkpoint on the source database replication slot. You can configure Debezium Engine to send checkpoints to the file /dev/null to disable the default external system checkpoint behavior.
Debezium relies on Kafka Connect's `OffsetBackingStore` contract [1] for persisting and restoring offset positions (that's subject to abstraction from Connect's SPIs at some point). While acknowledged LSNs are committed to the source DB in case of Postgres indeed, the offset store is still needed in most cases, e.g. for persisting other information, e.g. the fact whether or not an initial snapshot has happened yet.
> I don’t want to manage that in data producers anymore.
Could you elaborate a bit? The outbox pattern typically _is_ implemented in source applications, so I'm curious what alternative you have in mind? Stream processing e.g. with Flink actually can be an alternative, creating external data representations after the fact, though challenges arise e.g. in terms of transactional consistency.
Our current many outbox patterns are implemented by producers using two phase commit. Rather than writing code for that, I want move the outbox to another component, but we don't want to use stream, we want to use a queue. Essentially, listen to WAL, any relevant data gets written to a queue for down stream consumers. Kafka/Kinesis is not in our stack right now, so I want to use standalone Debezium server on a AWS Fargate/ECS service and write to FIFO-SNS.
The latest code on the master branch of displayplacer supports this. Run `displayplacer "id:34686E82-0CED-DF86-AFC7-AA1A8EB5CFC0 enabled:false"` with your screen ID and it will set the screen to all black plus remove the screen from the view of the OS. I'll cut the next release version after I add native Apple silicon support.
The latest code on the master branch of displayplacer supports this. Clone the repo and run `make` to build it. Run `displayplacer "id:34686E82-0CED-DF86-AFC7-AA1A8EB5CFC0 res:1440x2560 enabled:false"` with your screen ID and it will set the screen to all black plus remove the screen from the view of the OS.
I've seen a few comments mention the description now. Thank you for the feedback. I wrote displayplacer because all the other tools were GUIs and I needed something scriptable. Consider using SwitchResX for a multi-display profile GUI tool.
As far as I understand, there is a low level race condition here. The order that the monitors come alive and initialize with the OS is non deterministic. This can cause the left monitor and the right monitor, for example, to swap IDs.
reply