Archive for January 5, 2023

Thursday, January 5, 2023

Dell UltraSharp 32 6K

Scharon Harding (via Hacker News):

Dell announced a beefed-up monitor to expand the limited options available to creative professionals who want more pixels. With 6144×3456 resolution, the Dell UltraSharp 32 6K Monitor (U3224KB) places itself firmly in the professional category, right alongside the likes of Apple’s 6K Pro Display XDR.

[…]

The U3224KB has a pixel density of 223.79 ppi, to be precise, making it noticeably more pixel-dense than a 31.5-inch, 4K (3840×2160) monitor like the Dell UltraSharp U3223QZ (139.87 ppi). The Dell monitor also gets you more pixels per inch than a 27-inch, 5K (5120×2880) monitor like Apple’s Studio Display (217.57 ppi), and even the Pro Display XDR monitor. Apple’s display is a hair bigger, at 32 inches, with a slightly lower resolution of 6016×3384, giving you 215.7 ppi.

[…]

IPS Black differs from standard IPS LCDs by claiming 35 percent deeper black levels. As such, the U3224KB is supposed to have twice the contrast of an average IPS monitor, at 2,000:1. It also claims a typical max brightness of 450 nits with SDR content.

[…]

Running at up to 4K at 30 frames per second, the integrated webcam on the U3223QZ made the image, particularly the background, look distinctly sharp, giving us hope for the U3224KB camera’s image quality.

Dell has not announced the price, but it sounds like the display will include a stand and even a power button.

Previously:

Update (2023-05-15): Dell (via Paul Haddad):

32-inch monitor built for productivity. Featuring a 6k monitor with IPS Black panel technology for exceptional color, contrast and detail across a wide viewing angle.

The 6K version is $3,199.99 with stand and camera. There’s also an 8K version for $4,023.99.

Shopify Migrating to React Native

Farhan Thawar (in January 2020):

After years of native mobile development, we’ve decided to go full steam ahead building all of our new mobile apps using React Native.

[…]

At Shopify, the idea had its skeptics at the time (and still does), but many saw its promise. At the company’s next Hackdays the entire company spent time on React Native. While the early team saw many benefits, they decided that we couldn’t ship an app we’d be proud of using React Native in 2015. For the most part, this had to do with performance and the absence of first-class Android support. What we did learn was that we liked the Reactive programming model and GraphQL. Also, we built and open-sourced a functional renderer for iOS after working with React Native. We adopted these technologies in 2015 for our native mobile stack, but not React Native for mobile development en masse. The Globe and Mail documented our aspirations in a comprehensive story about the first version of our mobile apps.

[…]

we learned from our acquisition of Tictail (a mobile first company that focused 100% on React Native) in 2018 how far React Native has come and made 3 deep product investments in 2019

[…]

in rewriting the Arrive app in React Native, the team felt that they were twice as productive than using native development—even just on one mobile platform

[…]

As an aside, even though we’re making the decision to build all new apps using React Native, that doesn’t mean we’ll automatically start rewriting our old apps in React Native.

Mauricio de Meirelles (via Ben Sandofsky):

After a thorough evaluation, it became clear that we couldn’t fix these issues [with Shopify Point of Sale] with incremental changes. Hence, we decided to do a full rewrite, which has been a big hit with our merchants.

[…]

Having all mobile teams use a single tech stack and tooling across the company gives you an incredible amount of leverage. We didn’t want Shopify Mobile to miss out on all the shared libraries, components, and tooling that other apps were benefiting from. So, we decided to gradually start adopting React Native in the app instead of doing a full rewrite.

[…]

After evaluating several options, we decided to go with an approach we like to call “Iterative Porting”. In this approach we started building all new features in React Native and migrating existing features in parallel.

[…]

Now that our root screens are ported and most of the necessary infrastructure is in place, I’m noticing that the ports are picking up speed! Most of our developers didn’t know React Native before this project, so each day they learn more, which further contributes to the fast pace.

Geoff Foster:

I’m one of the original iOS developers on that app. Left about 6 months after the move to RN announcement having fought against that for years and no longer able to stop it from happening.

We started with about 8 people doing the GraphQL backend, design, native iOS and Android and shipped good stuff fast. Scaled everything well over the years with a solid tech stack.

I open the app now and again and can instantly tell where the RN screens are because of the weird glitches and bugs

Miguel de Icaza:

Rewrites never go as planned.

Xamarin.Forms turning into Maui was supposed to be a quick change, fueled by hopium so strong it defied gravity.

Instead, at best, it set it back 2-3 years.

Previously:

Limiting Swift Concurrency’s Cooperative Pool

Alejandro Martinez:

In Swift Concurrency all your async code runs in a cooperative thread pool, unless you are using Actors (or in the future custom Executors, but that’s a topic for another day). The beauty of the cooperative pool abstraction is that it allows us to not care about thread exhaustion, or even about our code running “on the background”, something I still see many developers get wrong.

[…]

In fact this cooperative pool is such a specific implementation detail that it could work totally different in other operative systems or more constrained enviornments.

[…]

And you can test how your code would behave in such a constrained system thanks to an environment variable that limits the cooperative pool.

Set LIBDISPATCH_COOPERATIVE_POOL_STRICT=1 and see how the runtime will only create 1 thread on the pool.

Mastodon and Federation

Ben Klemens:

Lemmer-Webber drew a direct line from problems on other social networks to the development of a network where local controls are built in. “Queer people built the Fediverse,” she said, adding that four of the five authors of the ActivityPub standard identify as queer. As a result, protections against undesired interaction are built into ActivityPub and the various front ends. Systems for blocking entire instances with a culture of trolling can save users the exhausting process of blocking one troll at a time. If a post includes a “summary” field, Mastodon uses that summary as a content warning.

Other governance questions are more subtle, because features for greater privacy, almost by definition, limit the discovery and exploration we also look for in a social network. For example, the question of whether Mastodon should allow instance-only posts that do not go out to the Fediverse at large has been especially contentious. The final decision leaned toward discoverability, so Kazemi forked Mastodon to create Hometown, which includes this more-limited sharing option and various improvements.

[…]

Fediverse.party lists around a hundred ActivityPub-based systems, many going well beyond the traditional social network. There’s Pixelfed, which provides a Fediverse instance with an images-forward front end (“It’s like Instagram, but…”). You can share video with PeerTube or federate your music via a Funkwhale instance, write collaboratively on Write freely or dokieli, review books and form your book club on BookWyrm, or plan events using Kazemi’s gath.io.

Kazemi is optimistic about coming full circle and using ActivityPub as the next RSS.

Mastodon (via Bud Gibson):

If you hide boosts from someone, you won’t see their boosts in your home feed.

I’m probably going to start doing this because boosts seem a lot more intrusive and repetitive than retweets on Twitter.

Previously:

Update (2023-01-06): Adam Chandler:

I’m going to put my money where my mouth is and run my own Mastodon instance. I like that people can follow me (like they do the RSS feed I publish here) but owning your IP also means owning your box on the internet.

The realization that my Mastodon posts can’t move with me between servers is even more scary. Why would I devote years of my life posting to someone’s instance and lose all of my posts when that instance closes down since I can’t migrate posts out? That’s a serious flaw and flies in the face of data portability efforts many advocates have been working for.