tomphoolery
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.)
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 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!
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.
https://github.com/workarea-commerce/workarea/blob/master/co...
Some context:
- The 5th Element is a cool movie
- My sister's dog was named Leeloo Dallas Multipass and she was like my favorite dog of all time
- I was the original developer of the `ProductMultipass` search query feature
- Turns out, funny comments make other developers like your product more
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.
hmm i wonder why... https://wordpress.com/wordpress-hosting/
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!
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.
Unfortunately, I believe for "custom jobs" like this you'd need to explicitly state that you don't want it to occur because it won't happen by default, unlike some other stuff that's more standard in the browser.
The issue is that they keep enacting laws that have good intentions, but are written poorly and without any sort of experience in the technical realm. This results in the laws' implementation being filled with weird loopholes that you can use to get around the extra work while still maintaining the legality, but completely missing the intention of the law in the first place. It just seems like a massive waste of time to me.
Their attitude of not communicating anything and basically inventing stuff the R1 can do without actually having the engineering to back it up is what is "scamming" to me. Over-promising and under-delivering is one thing, but lying about what something can do and then going back to the engineering team to "just make it happen" is what I am reading between the lines here.
For those who don't want to install a custom status bar, this seems like it would solve similar problems of the status bar getting way too big with all these programs running in the background.
However, the biggest problem with depending on packages in Go back then was that it was difficult to communicate to other people on your project the exact version of the dependency that you wanted them to install. For projects in which you were the only developer, this wasn't an issue...but as soon as you started to use Go in a team setting, it became a real blocker toward getting your work done. Go developers needed _some_ way to communicate what version of each package they wanted to install, and a bunch of solutions popped up to help with that. But they were all still bound by the `$GOPATH` constraint and such.
Although it took a lot longer than many predicted, I'm still pretty happy with how Go approached dependency management at the end of the day. Generally, all I have to do is import a dependency from a known URL and my editor/Go modules will take care of the installation work. This is way better than the JS world, in which if I want to just sketch something out I have to actually install the dependencies I need otherwise TypeScript will yell at me. With Go, it all seems to happen automatically.
ajksbdnfjasdnflaksdfbnfHP: "no u"
(j/k of course...i actually rather like their enterprise blade offering if you're making your own cloud)
> That’s why one of the goals in Chimera is to implement the actual useful systemd functionality, but independently and in our own way, without the shortcomings.
I question whether it would be possible for SystemD to be portable to other software stacks? Seems like it would be useful enough to attempt that port rather than literally rewrite SystemD, and you get to satisfy _both_ the SystemD stans and the haters at the same time! But who knows, it might lead to some kind of future innovation to have competing products doing the same thing...
Kinda depends on whether the "sound chip" is emulated. For example, the MOS6581 doesn't seem to be emulated here. You could emulate the UI and controls of an Elektron SIDStation, but you wouldn't be able to get the sounds to play unless you had a real SID chip in there. So in that sense, just running the UI and controls would be fine for an emulator if there was a real MOS chip somewhere to take in audio.