HackerTrans
トップ新着トレンドコメント過去質問紹介求人

robenkleene

no profile record

投稿

Order of the Sinking Star demo now available for download

orderofthesinkingstar.com
9 ポイント·投稿者 robenkleene·26 日前·1 コメント

SwiftUI Only Makes It Easy to Develop Bad Apps

daringfireball.net
9 ポイント·投稿者 robenkleene·先月·0 コメント

Designing a Better Podcast Editor

adamsolove.com
2 ポイント·投稿者 robenkleene·先月·0 コメント

Monome at Twenty

monome.org
4 ポイント·投稿者 robenkleene·先月·0 コメント

Monome at 20: memories of the grid, in pictures

cdm.link
2 ポイント·投稿者 robenkleene·先月·0 コメント

Order of the Sinking Star Overview Trailer [video]

youtube.com
2 ポイント·投稿者 robenkleene·2 か月前·0 コメント

The Navigator Trackpad is here

newsletters.feedbinusercontent.com
3 ポイント·投稿者 robenkleene·2 か月前·0 コメント

InMusic will acquire Native Instruments, as NI joins brands from Akai to Moog

cdm.link
2 ポイント·投稿者 robenkleene·2 か月前·0 コメント

Photoshop's challenges with focus, pt. 2

unsung.aresluna.org
2 ポイント·投稿者 robenkleene·2 か月前·0 コメント

Little Snitch for Linux

obdev.at
17 ポイント·投稿者 robenkleene·3 か月前·2 コメント

Death of the IDE?

addyo.substack.com
2 ポイント·投稿者 robenkleene·3 か月前·0 コメント

Liquid Glass Is Permanent

mjtsai.com
7 ポイント·投稿者 robenkleene·4 か月前·3 コメント

AI Layoffs

mjtsai.com
6 ポイント·投稿者 robenkleene·4 か月前·0 コメント

'Grief and the AI Split'

daringfireball.net
2 ポイント·投稿者 robenkleene·4 か月前·0 コメント

GIMP: The Movie (2026) – Official Trailer [video]

youtube.com
5 ポイント·投稿者 robenkleene·4 か月前·0 コメント

The evolution of Mac app window corners

lapcatsoftware.com
2 ポイント·投稿者 robenkleene·4 か月前·0 コメント

If computers are the future, why are computer users permanently illiterate?

lapcatsoftware.com
15 ポイント·投稿者 robenkleene·4 か月前·1 コメント

macOS Tahoe windows have different corner radiuses

lapcatsoftware.com
320 ポイント·投稿者 robenkleene·4 か月前·227 コメント

Lobsters Interview with Steveklabnik

lobste.rs
4 ポイント·投稿者 robenkleene·5 か月前·0 コメント

The Unlikely Success of an Alabama Bookstore

newyorker.com
3 ポイント·投稿者 robenkleene·5 か月前·0 コメント

コメント

robenkleene
·8 か月前·議論
> Notarization Review Guidelines (a subset of the App Review Guidelines).

Just noting I was wrong, Notarization Review Guidelines are referenced here https://developer.apple.com/help/app-store-connect/managing-...
robenkleene
·8 か月前·議論
I think notarization is just a more automated way to do this approach, e.g., otherwise Apple has to hunt down all the permutations of the binary themselves. It seems like it just simplifies the process? (It makes it a white list not a black list, so it's certainly more aggressive.)
robenkleene
·8 か月前·議論
> Notarization is the same for macOS and iOS AFAIK.

Assuming the basic facts are straight, the the linked story explicitly proves this is false:

> UTM says Apple refused to notarize the app because of the violation of rule 4.7, as that is included in Notarization Review Guidelines. However, the App Review Guidelines page disagrees. It does not annotate rule 4.7 as being part of the Notarization Review Guidelines. Indeed, if you select the “Show Notarization Review Guidelines Only” toggle, rule 4.7 is greyed out as not being applicable.

Rule 4.7 is App Review Guidelines for iOS, so this would be a case of failing notarization for iOS App Review Guidelines, which means the policies (and implementation) are different between platforms.

(Of course there's no such thing as "Notarization Review Guidelines" so maybe this whole story is suspect, but rule 4.7 is the App Review Guidelines rule that prohibits emulators.)
robenkleene
·8 か月前·議論
Yeah, don't disagree with any of that, but I'm looking for explicit evidence that that is true (right now it sounds like it's just an assumption)? E.g., either examples of apps failing notarization due to API calls, or Apple explicitly saying that they analyze API calls. Without that it sounds like we're just guessing?
robenkleene
·8 か月前·議論
> In practice though they use it to turn the screws on various API compliance topics

Do you have an example of this on macOS?
robenkleene
·8 か月前·議論
> doesn’t seem to have been offering any extra protection.

How would this be measured?

Since no one has pointed it out here, it seems obvious to me that the purpose of the notarization system is mainly to have the code signatures of software so that Apple can remotely disable any malware from running. (Kind of unsavory to some, but probably important in today's world, e.g., with Apple's reach with non-technical users especially?)

Not sure how anyone external to Apple would measure the effectiveness of the system (i.e., without knowing what has been disabled and why).

There's a lot of unsubstantiated rumors in this comment thread, e.g., that notarization on macOS has been deliberately used to block software that isn't malware on macOS. I haven't seen a concrete example of that though?
robenkleene
·8 か月前·議論
Note this is an iPhone app (noting because this thread seems to mainly be about macOS).
robenkleene
·8 か月前·議論
I went through the comment there, all of those look like the most likely explanation is just bugs in the notarization system.
robenkleene
·8 か月前·議論
> detects use of unsanctioned API calls

Is there a concrete example of this? We know this isn't blanket policy, because of a recent story (https://news.ycombinator.com/item?id=45376977) that contradicts it. I can't find a reference to any macOS app failing notarization due to API calls.
robenkleene
·8 か月前·議論
> My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it).

This comparison of the mouse and keyboard seems to have programmer tunnel vision. Anything involving layout, graphs, media editing (audio, video, image), 3D modeling, and drawing I think we can all agree are better served by the mouse (in tandem with the keyboard). It's really the mouse and keyboard together that's made the computer such a successful creative medium. Programming seems to me like a bit of anomaly in that it's one of the few creative tasks that doesn't benefit greatly from a mouse.
robenkleene
·8 か月前·議論
There's a ton of comments here saying the keyboard is more ergonomic than the mouse, I've never heard that before and it feels wrong on its face (it's called repetitive strain injury, using multiple forms of input should helpful).

But generally, please if you believe this provide some kind of source.
robenkleene
·8 か月前·議論
I think this is a bit of an oversimplification, I see art and technology as more like a dance where it's unclear who's leading who.

E.g., quick high-level examples: Photograph invented led to Impressionism, Andy Warhol's entire oeuvre. Today one of the most talked about artists is Beeple (technology-forward in distribution medium, tooling, and even practice techniques [e.g., "dailies"]).

Music is probably where this is the most profound, take the trajectories of Miles Davis and the Beatles, both started their career with a fledgling recording industry, ended it record in sophisticated studios using instruments and studio techniques that didn't exist a mere 5-10 years earlier.

In electronic music this is even more pronounced, e.g., Native Instrument's Massive synth facilitating dubstep is a nice clean example, but if you've followed electronic music overall the connection is obvious. E.g., what dates most pre-2000s era music is that today musicians use DAWs whereas before it was less powerful hardware devices that had a more specific sound (and other arrangement and composition limitations).

This actually feeds into one of the points you made: Being successful at art (or anything really) has a lot to do with how excited and motivated you are to pursue it. It's easier to be excited if you feel like you're exploring new territory, ripe with untapped potential, and that's historically often been unlocked by technology. Whereas if you keep comparing your solos to John Coltrane when you're learning the saxophone, that's going to be demoralizing and you'll feel like you'll never get there so why bother trying. There's also diminishing returns, e.g., that music territory has been so thoroughly explored now, so the ROI on developing that specific skill (playing jazz at that level) has been reduced, because so much of that artistic space has already been explored.

If you tie that all back to the art itself, I'd assume today that we already have saxophone soloist who are more technically skilled than John Coltrane, e.g., the music theory is better understood, and we've had decades of iteration to improve practice techniques (there are tons of books and studies on this subject now). But you can't replicate the sheer excitement that those musicians must have felt as they unlocked new music possibilities by iterating on music theory (a form of technology), and recording as a new medium to share and learn from.

To be clear, most of what you've said I'd agree with, but I'd add more nuance like: Leverage technology to make the act of creation as exciting for you as possible, but the main goal of the excitement is to keep yourself practicing and improving. And also look for untapped potential (e.g., a specific example that's relevant today, I think GPU-based rendering is still under-explored today Beeple has been able to leverage this in his art, but I think the big barrier of entry [probably ~$10,000+ for hardware/software over the course of a career] means there's untapped potential there.

E.g., Daft Punk on well-tread territory due to the accessibility of technology https://pitchfork.com/features/lists-and-guides/9277-the-yea...:

> Technology has made music accessible in a philosophically interesting way, which is great. But on the other hand, when everybody has the ability to make magic, it's like there's no more magic—if the audience can just do it themselves, why are they going to bother?
robenkleene
·8 か月前·議論
> Notably; the engineers I respect the most, and the ones making things that I enjoy using, none of them use vscode.

Curious what they use?
robenkleene
·8 か月前·議論
> Or is your point that the previously desktop-only software suites now have web-based counterparts, and the latter aren’t catering to power users anymore?

Yes this. More specifically collaborative software (e.g., with features like live-collaborative editing) tend to be less capable than non-collaborative software.

These are not 1-for-1 comparisons though (Figma vs. Canva), I didn't mean to imply they were. E.g., Canva isn't emphasizing collaboration. But office suite software does also have a lower barrier of entry than creative software, which I think Canva's strategy should probably capitalize on. E.g., the market has already been split for pro vs prosumer/casual, I think Canva strategy will probably be to emphasize this split short term, which would mean focusing on ease of use at the expense of complex features (and then consider the more technically complicated led shift to collaborative web-based versions later, leveraging what they've learned so far).
robenkleene
·8 か月前·議論
Do you mind getting more specific about what you disagree with around the comparison / characterization of "office suite software"? I can't tell what you're disagreeing with. E.g., it sounds like you're saying I don't think office suite software is powerful, which I don't think I said? (And I don't believe, e.g., I think Excel is one of the most powerful applications there is). I do think the most popular web-based office suite software (e.g., the Google suite) is less powerful than the more desktop-orientated competitors (there's an obvious reason for this, web-based software facilitates collaboration, and complex features hinder collaboration, so they're in natural opposition).

But I definitely struggle with the comparison between power users and casual users. Like I wouldn't characterize designers that use Figma as casual users, it's that the needs of software designers have changed so much, and those changes mean treating design software more like office suite software make sense.

I guess the comparison of casual users and power users is more apt when comparing the Adobe suite and Affinity suite. And, e.g., Final Cut Pro X and CapCut are evidence of a wider industry trend towards serving that market. I wouldn't necessarily say that's to the detriment of power users though, it seems like there's software to serve both markets now?
robenkleene
·8 か月前·議論
I'm not sure what part of this you think I'd disagree with, if just looking at the microcosm of Sketch to Figma. In other words, the ease of sharing and collaborating via a URL I think is the underlying reason office suite software has become successful.

But I suspect you're arguing against the wider arch of the point I'm making (that design no longer requiring as sophisticated features helped facilitate the transition to the web-based software). If I have that right, I suggest making sure that your hypothesis about motivations behind the market transitions also incorporates the transition from Photoshop to Sketch. Because that transition (which preceded the transition to Figma) made every problem you're describing worse. Which means for example that you can't attribute the transition from Photoshop to Sketch to Figma just to the URL.
robenkleene
·8 か月前·議論
This is analysis is spot on.

I made the same argument about Figma (that what made Figma successful is that design software had started to be used more like office suite software) in my overview of the historical transitions in creative software https://blog.robenkleene.com/2023/06/19/software-transitions...:

> In the section on Photoshop to Sketch, we discussed an underappreciated factor in Sketch’s, and by extension, Figma’s, success: That flat design shifted the category of design software from professional creative software to something more akin to an office suite app (presentation software, like Google Slides, being the closest sibling). By the time work was starting on Figma in 2012, office suite software had already been long available and popular on the web, Google Docs was first released in 2006. This explains why no other application has been able to follow in Figma’s footsteps by bringing creative software to the web: Figma didn’t blaze a trail for other professional creative software to move to the web, instead Sketch blazed a trail for design software to become office suite software, a category that was already successful on the web.

Regarding this, I'm curious how big this market is really. E.g., for me, working on software, I almost never see design work from folks that aren't professional designers (and if I do, they use Figma already, not the Creative Suite). But I'd be curious to hear other folks impressions, even just anecdotally:

> To explain what I mean: Let’s say you’re a company that subscribes to Adobe Creative Cloud. You might buy it for one department—like your video team, or your web team, or your print team. But there are a lot of other people in your office, and they need design too. They need to build social posts and presentations and email signatures and graphical work that your $150,000-per-year senior designer doesn’t have the time for.
robenkleene
·8 か月前·議論
For this example:

> we have somebody who has somehow obtained a "weird" video file

Why are you arriving at the conclusion that this requires complex software, rather than just a simple UI that says "Drop video file here" and "Fix It" below? E.g., instead of your conclusion "stick to your walled-garden-padded-room reality where somebody else gives you a video file that works", another possibility is the simple UI I described? That seemed to me the point of the post.
robenkleene
·8 か月前·議論
> Taking the case of Photoshop vs. Gimp - I don't think the problem is complexity, lol. It's having to relearn everything once you're used to photoshop. (Conversely, I've never shelled out for Adobe products, and now don't want to have to relearn how to edit images in photoshop or illustrator)

I don't think this comparison is really accurate, Adobe's suite is designed for professionals that are working in the program for hours daily (e.g., ~1000 hours annually for a creative professional). There are probably some power users of The GIMP that hit similar numbers, but Creative Cloud has ~35-40 million subscribers, these are entirely different programs for entirely different classes of users.
robenkleene
·9 か月前·議論
burnstsushi provides the canonic answer here of course.

But as a quick thought shortcut, I think of `ripgrep` as a search that gives similar semantics to project-wide search in a code editor or IDE. E.g., most editors will inspect a project and already ignore files that usually should be ignored (e.g., third-party dependencies, build artifacts, source control metadata like `.git/`).

Those semantics are also almost always what I want when performing a search from the command line, so `ripgrep` is what I use most of the time.