Well if I can cancel my HBO Max it will probably be a zero-sum thing (all the crappy "discovery" content they tacked on was just annoying and I have little interest in their "sports" offerings)
The unfortunate reality is that HBO may have less content but there's also less garbage. I'm constantly blown away by how mediocre everything on Netflix is. I only have it because it's bundled into myobile bill at a legacy discount which makes it only a few dollars a month. I wouldn't pay full price for Netflix now and I will likely remove it altogether if they do another price hike that adds a few more dollars beyond my current discount (~70%).
> HBO may have less content but there's also less garbage
If you leave the featured areas and venture into any of the categories, you will see that HBO is also full of junk. HBO -> Browse by Genre -> A-Z -> any of them are full of junk.
The Netflix featured pages are more geared to showing you stuff you haven't seen yet, while HBO is geared toward showing you popular stuff, even if you have watched it on HBO.
The problem is the arbitrary way the funding is allocated, find something interesting to companies du jour with a clear path to funding and you're golden.
If whatever OSS is too obscure to be noticed by non-techies but still fundamental (think OpenSSL, libxz,etc) it's more likely to lead to burnout far before anyone wants to put in any sane money (curl is one of few counter-examples but that hasn't had a straight journey).
It was competitive before ChatGPT existed, and IMHO that gives them a special insight that people miss to consider in this context.
They know what revenue streams existed and how damn hard it was to sell it, considering IBM Watson probably had the option of 100% on-prem services for healthcare, if they failed to sell that will a privacy violation system like ChatGPT,etc have a chance to penetrate the field?
Because however good ChatGPT, Claude,etc are, the _insane_ amounts of money they're given to play with implies that they will then emerge as winners in a future with revenue streams to match the spending that has been happening.
Salespeople are often non-tech despite working for tech-firms, non-tech people are the ones who usually create messes by workarounds since they often quickly give up instead of reporting.
If the non-reporting is a problem of the non-techs or techs at a company is an open question, but it's often a shared problem connected to non-techs coming with stupid things at one point and fundamentally important stuff at other times.
Anyhow, they usually should know how to get proper escalation to get shit done when hounded enough.
I let them know that if this isn't solved by COB tomorrow, I'll be pushing the client to switch to a new vendor. Then I received the email for the support ticket and see that they set it at the lowest priority.
I've already started playing with AWS to see how hard it is to spin up VMs there.
There's also digital ocean and hertzner cloud if you don't want to enter the AWS money pit. Though if you're looking to become a forensic accountant, AWS billing is great training
So to fully close the loop, I convinced the client to go to AWS after this week's debacle. I showed them how simple it was to spin up a new box on AWS, and everything just worked. Then, I showed them how DIRECTLY within the AI help interface, as SOON as you say you "need to speak to a human" it gives you the SUPPORT TICKET INTERFACE to fill out RIGHT there. No "you must have a support contract to ask about a billing question" horseshit. DIRECT access to the support ticket system.
The customer has agreed that we should pivot to AWS. Microsoft has officially lost a $10M, 10 year contract, and it's going to their primary competitor.
I wonder how often this really happens, just so they can save a few bucks on tech support?
Machine code yes (along with Spidermonkey, JSC and Nashorn), the timeframe around 2005-2010 saw the introduction of JIT'ed JS runtimes. Back then however JS was firmly single-threaded, it was only with the introduction of SharedArrayBuffer that JS really started to receive multithreading features (outside of SharedArrayBuffer and other shareable/sendable types, a runtime could opt to run stuff like WebWorkers/WebAudioWorkers in separate processes).
Early Node f.ex. had a multi-process setup built in, Node initially was about pushing the async-IO model together with a fast JS runtime.
Why Bun (and partially Deno) exists is because TypeScript helps so damn much once projects gets a tad larger, but usage with Node hot-reloading was kinda slow, multiple seconds from saving a file until your application reloads. Even mainline node nowadays has direct .ts file loading and type erasing to quicken the workflow.
The article mentions blocking phones with stolen IMEI's, but iirc that's mostly up to telecom network providers to block rather than some "app". Also doesn't Apple have their own locking technology?
I'd be much more interested in bare metal ARM64 vs X64 workloads on modern hardware, remember the article that compared Hetzner VPN + Bare metal to Amazon workloads a while back?
Amazon was so ridiculously gimped and expensive that it was almost unfair, thus comparing ARM and X64 on Amazon thus runs into whatever arbitrary "savings" AWS does.
Think of it this way, the global timer resolution of the system is minOf(allProcessesTimerResolution). If no process needs higher accuracy timing then there is nothing hindering the system from sleeping longer periods to save power and/or have less interrupt overhead (An feature I'd say).
These API's are from the 90s, in the beginning of the 90s where these API's are from having an global system interrupt firing 1000 times per second could very well have taken a percent or two or more from overall CPU performance (people already complained about the "overhead" of having a "real OS").
On the other hand writing audio-players on DOS you had the luxury of receiving your own interrupt within a few samples worth of audio, this meant that you could have very tight audio-buffers with less latency and quicker response to user triggers.
Not having that possibility to get that timing fidelity would have made Windows a no-go platform for audio-software, thus giving developers the freedom to enable it when needed was needed. Removing it in the next 10 years would probably have risked bad regressions.
Like a sibling comment noted, they finally removed it during Windows 10's lifespan and with modern CPU's _AND_ multicore they probably felt safe enough with performance margins to separate high accuracy threads/processes to separate cores and let other cores sleep more and actually win more battery life out of it.
It might not be "perfect engineering", but considering the number of schedulers written for Linux over the years to address desktop(audio) vs server loads it was a fairly practical and usable design.
DOS was basically bare-metal programming with a few hardware and software calls thrown in. With 50 cent ARM processors these days having the power of an 80's mainframe Bare-metal on $5 dev-board is still my preferred way to go for simple projects that boot instantly and never need updates. I'm currently listening to music on a DOS MP3 player on a throwaway industrial x86 motherboard I built into an amplifier case 23 years ago.
>In order to maximize user security, we would prefer third-party providers to use the Signal Protocol. Since this has to work for everyone however, we will allow third-party providers to use a compatible protocol if they are able to demonstrate it offers the same security guarantees as Signal.
>To send messages, the third-party providers have to construct message protobuf structures which are then encrypted using the Signal Protocol and then packaged into message stanzas in eXtensible Markup Language (XML).
>Meta servers push messages to connected clients over a persistent connection. Third-party servers are responsible for hosting any media files their client applications send to Meta clients (such as image or video files). After receiving a media message, Meta clients will subsequently download the encrypted media from the third-party messaging servers using a Meta proxy service.
You also have to connect over XMPP and through a proprietary "Enlistment API", etc.
reply