In theory, packagers could put these docs somewhere. I'm not sure what the best way is to make it convenient to use.
Also, I'm not sure about jj v0.25, but in the upcoming (probably tomorrow) 0.26, you can get a lot of docs by doing e.g. `jj help -k config`. Ironically, this fact is currently somewhat under-documented. `jj help` just says at the end:
`'jj help --help' lists available keywords. Use 'jj help -k' to show help for one of these keywords.`
Yeah I made it as far as planning out a change to the `jj config --help` output to at least link to the documentation and then realized that my copy didn't have the documentation. Oops. And then I got occupied by some other FOSS bug and forgot to circle back.
Unfortunately there was a gap between installing it and trying it for the clever merge resolution use case I had in mind, and I've forgotten how I installed it, so I need to reverse engineer that to figure out how I got here.
After trying various solutions - including DeskPad - I came up with a custom cross-platform (I'm on macOS, but assume it'll work elsewhere) solution that worked incredibly well on my 40" ultrawide monitor: OBS[1].
Having never used OBS before but knowing it was popular among streamers, I wondered if I could use it to (1) only share the specific applications I wanted to share and (2) share them at a resolution that people could actually read, without constantly being asked to zoom in.
I first tried setting up a virtual camera and sharing via my video stream, but it was laggy and the quality was so poor that people couldn't read what I was sharing. I quickly gave up on that approach.
Then I discovered Projectors[2]. By right-clicking on the main view in OBS and selecting "Windowed Projector (Preview)", it launches a separate window, which I can then share directly via Zoom, Teams, Meet, etc.
Whatever I drag into the OBS view is displayed in the Windowed Projector (similar to DeskPad), with the added bonus that I can choose to blur certain applications that might be dragged in. For example, if I open Slack or my password manager, the entire window blurs until I focus back on my terminal or browser.
It took a bunch of tweaking to perfect, but I'm very pleased with how well it works now.
When I'm teaching a class, I will share the screen that has the projector fully screened on it (which is normally the screen for my teleprompter (so I'm looking into the eyes of my students)). I have a bunch of scenes set up, so I can quickly change the scenes using my Stream Deck. You can make really smooth transitions, so I have a scene for:
- Full camera
- Full camera shifted ~60% to the right with a small desktop screen (where I'm showing my slideshow or code) on top
- Full desktop with face in upper right or lower right (another Stream Deck button to toggle face position)
- Full desktop, no face
I also have countdown timers that I can set from the command line when we are taking a break or waiting for the class to start.
OBS is awesome.
However, I also record many courses and must do them in HD res. Sadly, my MBP has a notch and won't natively do HD. OBS doesn't help with this (easily). My current solution (which I'm curious to try DeskPad to see if it is better) is to use the BetterDisplay app and create a "virtual screen" with HD dimensions. BD lets me "mirror" the virtual HD screen to my Mac monitor, and it magically resizes the dimensions correctly to HD.
It's a painful workaround (especially because every time my Mac or other monitors sleep, all of the orientations of the monitors and the mirroring of the virtual screen are forgotten).
I would love a way to tell my MBP screen to go HD, but to my knowledge, that doesn't appear possible.
My main work machine is also a Mac and I found the accessibility zoom a really useful and quick feature. I simply share my entire screen or a window in whatever meeting/share app and then use a 3-finger gesture and Cmd+ or Cmd- to zoom in and out. That zoom level is fully passed on by the screen share.
Obviously this feature has to be enabled and wasn’t intended for this purpose but it works perfectly!
Application-independent zoom is such a nice feature. I've been keeping a zombie version of compiz (formerly beryl) on linux working for years, mainly because I love my wobbly windows and desktop cube, but it's long had two features great for screen sharing purposes too: the zooming like you mention (have it bound to meta+scroll wheel) and drawing annotations (alt+meta+left click for free drawing, there's also eraser, erase all, straight lines, and filled rects/ellipses).
Thanks for sharing this! My main issue with the windowed projectors is that you can't force them to have the proper size for the resolution of the OBS canvas which causes the result to be scaled and it has window borders. I've worked around this by having a virtual display (in my case BetterDisplay [1], but DeskPad should work as well) and use the full-screen projector instead, as an added benefit there is no additional window floating around. The resolutions are all aligned, so no scaling.
Blacklisting falls into badness enumeration territory. It's good that you can blacklist sensitive windows, but it would be more useful to have a whitelist feature. If I want to share my browser tab and a game I'm playing, I could simply tell it that, and not have to worry about whatever other sensitive information may pop up randomly at any given time.
Not OP, but OBS is cross platform and you can set up custom scenes. So you can basically show whatever you want on it, and save those so that it automatically works like that every time. It also can act as a virtual camera, and you can record.
But how is Conduit better than the combined products? Doing two things poorly is worse than doing one thing well. (I'm not suggesting that Conduit does anything poorly, but it's not clear how it's superior in any way to any competing implementation.)
What they are presumably going for is ease of use, Istio uses a pluggable service mesh with Envoy being the most common one, and Linkerd being one of the alternatives.
I'm guessing they think Conduit can bring value by being an intergated solution out of the box, and I'm excited to see if they can deliver on that.
It's far easier to grasp when you consider that Monty opening one of the other 2 doors makes no difference to his offer (since he'll always open a door with a goat behind it anyway), i.e. he could also say "Do you want to stick with your door, or switch to both these other 2 doors?" without the unnecessary misdirection of opening the goat door beforehand.
Interesting. I wonder if this indirectly expedited the price hike? Encryption would make it (practically) impossible for Amazon to deduplicate people's data and store it more cost efficiently.
A word of warning to those considering using this. While I completely understand why people might want to encrypt/decrypt files within their public Git repositories, doing so doesn't come for free.
As Junio C Hamano explains more eloquently and in greater depth here[1], one thing to bear in mind with this (and similar) tools is that they store the managed files as binary blobs, regardless of their original format, meaning that a change to the source file of even a single bit will result in an entirely different uncompressed blob being stored, rather than a compressible textual delta.
While technically true, the type of data this extension is meant for (small configuration snippets containing sensitive credentials) are both small and rarely-changing. A couple extra bytes in the index won't be a very big deal.
Aha, I remember now. I was puzzled by what this comment meant at first. This isn't the first time I've come across this site!
I recall being annoyed by this, too. Fortunately, uBlock Origin[1][2] came to my rescue back then. It's a great adblocker which requires minimal configuration out-of-the-box, but also offers a bunch of Power User options for the more discerning Internet user. One such option is a point-and-click tool[3] that allows you to block arbitrary elements loading on a given site, which I promptly used to obliterate this image on first sight. :-)
I'm particularly curious about the "[...] serious vulnerabilities in an encryption protocol that I, and probably most of you, use regularly." ‒ does anyone know what this in reference to?
> Apple iMessage, as implemented in versions of iOS prior to 9.3 and Mac OS X prior to 10.11.4, contains serious flaws in the encryption mechanism that could allow an attacker -- who obtains iMessage ciphertexts -- to decrypt the payload of certain attachment messages via a slow but remote and silent attack, provided that one sender or recipient device is online. While capturing encrypted messages is difficult in practice on recent iOS devices, thanks to certificate pinning, it could still be conducted by a nation state attacker or a hacker with access to Apple's servers. You should probably patch now.
