> However, in this situation it may make more sense to disable biometric authentication.
In Face ID, there's a setting that requires direct eye contact in order to open your phone. Highly recommend enabling this when feeling insecure about someone forcing you to open your phone (if it's not already on by default) because it means somebody forcing you to open your phone with Face ID can be easily defeated by simply closing your eyes. I tried this a number of times during the BLM protests, and I/nobody else could get my phone to unlock unless my eyes were open and looking right at it. So with Face ID, I think it's actually way more secure to have biometric authentication turned on, using this setting. The thumbprint stuff might be a good idea to avoid though.
(WARNING: This will make your phone pretty much impossible to unlock with your face if you're inebriated on anything. Ask me how I know. xD You should probably disable it after the protest.)
While this is good info, it should also be known that in the USA, a judge (maybe and police officer?) can legally command you to unlock your phone via biometrics, but they cannot legally command you to unlock via password or passphrase.
“Legally command” = command you to do something with the force of law, and legally punish you if you resist
IANAL, but I think the distinction is that "give us the password that unlocks this" is forcing you to testify against yourself, producing something from your own memory and forcing you to admit ownership/control of the object. (Which might not even be yours.)
In contrast, "the device opened in response to the same fingerprint/face that the suspect has" is a form of world-evidence which doesn't infringe on your mind, much like "the key found in your pocket unlocked the safe."
The reasoning behind this is that your fingerprints and face etc. are public knowledge. Whereas you can retain your right to remain silent (about your password/PIN), failing to provide these aspects of your person can be viewed as not cooperating.
>The reasoning behind this is that your fingerprints and face etc. are public knowledge.
Not really. You can be compelled to give blood sample for alcohol testing, but your blood is hardly "public knowledge". Same thing with strip searches.
That is usually due to 'implied consent' laws. Most states have it written into what you sign to get your license that you must submit to DUI testing. Generally, you can refuse, but the penalty for refusal is worse than the DUI penalty.
This has failed me. I was mugged while black out drunk, and they succesfully unlocked my phone, unlocked my banking app, etc, despite me having the eye contact feature enabled.
Most people who make a living as a musician these days do so by being a "renaissance man" of sorts, where they make their money doing a multitude of different things. This includes playing live, but some other examples live sound, stage tech, lighting, promoting/booking events, instrument trade shows, and composing music. You can think of this as being "T-Shaped" in the software industry, except the difference is in the music industry, you need to be "T-Shaped" just to survive, not simply to excel. The "long part of the T" is what you generally want to do most of the time, and it's usually how people identify their job when asked. But really, most of us do a combination of many different things to get by, almost none of these jobs pay enough or are regular enough to do it on their own.
This was, and still is, a HUGE shift in the way I live my life after moving careers from software development into music composition...
Even as a film scorer, who has jobs that last for a long time and include many personal conversations with the film makers, you're not guaranteed to get back-to-back gigs, so when you're done with one score, what's next? It's not like there's always someone handing you jobs if you're doing this by yourself. But that's my preferred angle, because the jobs do last longer and there's a more regular (and higher) payout. It just takes a lot of back and forth with the people making the film, in order to get the vibes just right.
> SWC was one of the earlier Rust builders, which then became absorbed into Vercel and turned into Turbopack (is my understanding)
SWC and Turbopack aren't related in the sense that one is the "successor" of the other. They both do different things, and compliment each other. SWC is more lower-level, it's a compiler for JS (and other web tools) that converts your syntax into something any browser can understand. Turbopack is a bundler, it takes that compiled code and minifies/concatenates it together in various ways so it can be distributed to a browser efficiently. I believe Turbopack does in fact use SWC (if you're using Next that is) to do the "dirty" work of compiling TypeScript code into JavaScript quickly, but its main feature is the use of the Turbo engine to cache function calls at a very low level. From what I read, Turbopack's potential to make building JS apps incredibly efficient should be a really neat thing to work with in the future!
Ah gotcha, yeah I was always a bit confused about the whole thing but that makes sense. I've only used SWC directly as a WASM bundle to do in-browser realtime compilation and analysis of .tsx files, which works great, but that was pre-Vercel times when only 강동윤 was working on it.
> I was also similarly disappointed with the quality of Supabase’s auth offering considering all the praise I consistently see for Supabase on HN.
Around the time you were trying it out, there were some issues with Supabase clients not authenticating properly in SSR environments like Next.js or Remix. I think those have been solved with the introduction of the `@supabase/ssr` library, and continuing to use a middleware for refreshing the session upon each request. This latter option was always available, but wasn't in the example, so I think a lot of folks didn't implement the auth middleware and thus didn't ever refresh their stored access token.
I had a comment in this file for a very long time but the project lead was something of a Professional so he removed it. The comment was "# MULTIPASS!"
I handed a project over to a new developer once before leaving the company. I returned about 18 months later, and he'd stripped out the one Easter egg I'd put in. No sense of humor that chap. Good coder though.
> The fact that those boundaries are crossed means that anyone who is in competition with Automattic might have any and all ecosystems that Matt has any control over leveraged against them if they upset Matt or Automattic in any way.
There was never a boundary in the first place if it's the same guy doing both things. WordPress has always had this veneer of "community-driven", which is what they hide behind when people get their sites exploited, but Automattic really holds all the keys here. Just because Matt replies with an `@wordpress.org` email vs. an `@wordpress.com` email doesn't mean he's a different person all of a sudden.
If that’s the case, I’d like to hear from Matt about this. I’ve known him for years, and I don’t think he is unaware of conflicts like these. In fact I’ve seen him be deeply thoughtful about complex problems in the past. He’s not perfect (who is?), but he really does try.
Given that he has been pretty reasonable about stuff like this in the past, I don’t find myself inclined to ascribe bad intent until I hear from him personally.
Seems like the kind of situation where only one person can answer.
> Given that he has been pretty reasonable about stuff like this in the past, I don’t find myself inclined to ascribe bad intent until I hear from him personally.
there is a level of actions that are so bad that intent doesnt actually matter anymore. i would say matt has crossed that line here.
ThePrimeagen just did an interview with him, the video is also available on youtube now too.
Not the best interview IMO since prime didn't have much time to prepare questions / topics, and so he is very much "firing from the hip" but you'll get to hear matt go into detail about this topic.
You could also draw parallels from Drupal's death spiral that kicked off when (at the behest of corporate clients) Aquia decided to pivot to "large core" architecture and tossed the bulk of the community overboard in the process.
This went from "hey you guys shouldn't use WP Engine because it's not Real WordPress" to "WP Engine is violating trademarks and isn't welcome in the WordPress community anymore" really f'in quick!
Just as an FYI: this is a really really bad look from the outside. Your CEO's comments and the new trademark policy sound borderline deranged, and this step of banning them dangerously destabilizes the ecosystem.
WP Engine may be just as bad as you say, but if so they just successfully baited you into making yourselves look like the bad guys.
Yes - I don’t use WP and have no experience with either of those companies but everything I’ve heard about this has been people looking into alternatives because this raises the question of whether it’s motivated by a desire to boost revenue and merely the first step in the process.
OK. But do you really think this public bullying abuse of power from your increasingly unstable-sounding CEO is going to play out well? Good luck I guess.
always great to see devs sh1t on other devs under the premise of "this isn't right!!!" when in reality it's just affecting their bottom line. money makes the world go round!
Did you read the post? They have no problem with other Wordpress hosts and are calling out WP Engine specifically. They even suggest switching to literally any other WP host that isn't WP Engine.
As someone who's made a few Electron apps in the past, I can say that it has a lot more to do with what you're putting into the app itself than the runtime shell you're working with. It's not impossible to make an Electron app that's very efficient, to the point where people probably wouldn't realize it uses Electron unless they opened the app itself and poked through the source code. That said, due to Electron being a layer above the actual application stuff that's doing the "real" work, it's a lot harder to sniff out performance problems and especially to reproduce them on all platforms. So I wouldn't call this "bad application logic", I would say that it probably has more to do with using older (and deprecated) APIs to handle certain things like resizing the window, which could be replaced with better ones if the devs at Slack were able to easily see that this was causing problems for people. Unfortunately, Electron does make that a bit harder to do.
Basically...I'd say this has more to do with the fact that Slack's development team doesn't get enough control over their applications in order to make things like this happen faster.
Yeah - people use Electron because web-style UI toolkits are what they know and work cross platform, but those toolkits make it easy to write very un-performant applications that do block/repaint/block/repaint cycles which feel awful.
Everyone knows the electron apps even if they perform well - they’re the ones that don’t integrate properly with basic system services and don’t use native controls.
Ah yeah, common examples include Premiere Pro, Blender, Photoshop, Fusion 360 and a host of other Electron applications because there is no integration + they don't use native controls.
The Adobe apps integrate fine (on macOS at least). I don't know about any of the others, but would assume that a cross-platform UI solution leads to a bad experience.
Are the Adobe applications using the native toolkits on macOS? Because on Windows they certainly not, and I'm having a hard time imaging macOS has completely different UIs than the Windows versions.
Not the same runtime, but iirc parsing,etc is done at an earlier stage in Hermes/RN so some parts of the initialization process is already done in that way if I'm not mistaken.
In Face ID, there's a setting that requires direct eye contact in order to open your phone. Highly recommend enabling this when feeling insecure about someone forcing you to open your phone (if it's not already on by default) because it means somebody forcing you to open your phone with Face ID can be easily defeated by simply closing your eyes. I tried this a number of times during the BLM protests, and I/nobody else could get my phone to unlock unless my eyes were open and looking right at it. So with Face ID, I think it's actually way more secure to have biometric authentication turned on, using this setting. The thumbprint stuff might be a good idea to avoid though.
(WARNING: This will make your phone pretty much impossible to unlock with your face if you're inebriated on anything. Ask me how I know. xD You should probably disable it after the protest.)