My point exactly. Since it's the ODBC Data Source selection dialog, I think the actual users of it would be old enough to work with Win3.x/WinNT 3.x back when it was new, so maybe it counts both as penny-saving and a fan service for the greybeards?
On the other hand, how many kinds of first-party file copy dialogs and file open dialogs do you need? :-)
Agreed ! Plus, the ability submit a bunch of tasks, and to block until _one_ task completed (akin to `epoll_wait` of tokio's `select`) makes it quite useful.
I don't know of a use case or `mutiprocessing.Pool` which is not covered by `concurrent.futures.ProcessPoolExecutor`; so I wonder why both exist
In general, the Executor or even Queue abstractions are much better and safer ways of doing multithreading and multiprocessing. These days, I rarely ever directly create threads. It's fine for situations when you must but parallelizing work can usually be done better, safer, and easier with executors.
Coincidence: I literally read that doc-page and wrote some ThreadPoolExecutor code 5 minutes ago to workaround the lack of a specific async operation in asyncio.
>To make the transition seamless for you and your organization, there are no changes to any Azure AD capabilities, APIs, login URLs, PowerShell cmdlets, Microsoft authentication library (MSAL), developer experiences, or tooling.
So we will still be calling it Azure AD in most situations where someone interacts with it
On a fresh install I first setup WSL1, duplicated it and then converted the other one to WSL2. I don't really use the WSL1 one much, but it's nice whenever I need touch files "in Windows".
The idea (pre-aquisition, afaik Meta deprioritized that) was letting companies pay to push their gifs. Since companies can't directly buy ads in your private conversations, giphy could offer them the exciting opportunity to push people to send ads in meme-format to their friends! (I wish I was joking, but that was their framing)
Analytics tracking pixels normally ARE GIFs, specifically a 43 byte transparent 1x1 GIF.
But most “GIFs” are not GIFs but rather Mp4, mov, or webm or some other compressed file format. Actual GIFs are extremely wasteful of bandwidth and not hardware optimized. The name lives on though.
Are you asking why a GIF is used, or why the 43 bytes are needed?
I think a GIF is likely the smallest wide-supported resources format (force the browser request a URL to load a specific resource). The 43 bytes is the minimum size for a valid GIF, so the browser won't log an error loading the image and go through all load events.
