Orphis

> Do you have the right to prioritize your personal activities over your employers protection of its' data?

It is absolutely fine in many countries to use a work computer for light and occasional personal use or on breaks. And no, employers don't always have the right to monitor all traffic that isn't relevant to the business, or even files on your machine marked as personal. Really depends on the local laws though.

You don't, you run them in parallel to HTTP/3 and it shouldn't add any cost for you. The work is done in the browser (or any client) to fallback to whatever works.

Then, in a few years, when you notice that most of the traffic is done over QUIC, you still won't do anything as it has no significant cost anyway and helps the few % of people who haven't upgraded their network. And customers who can use it won't notice much as your website still works anyway, but your latency metrics should be better for those users.

Duo is targeted to the general public and has E2E encryption though, so cloud denoising is not a possibility.

It's not a problem on Android at all and just a limitation of the Apple platforms.

When I try to use a "share" action for example, I get my contacts from the phone and Whatsapp at the same level. My list of contacts actually has a merged view of all my contacts stored on my phone, Whatsapp and other services. Contacts on multiple services are merged appropriately.

It works just fine.

Alternatively, you can instrument the code with checks for UB using a sanitizer. It won't be the compiler screaming at you but your CI running all your tests with this instrumented version of your software.

Not perfect, but should work for most sane people running CI before merging changes.

It's NOT about the codec. It's about all the post-processing happening to do noise cancellation, echo removal or auto gain.

Those features are usually configurable in major video conferencing apps.

FYI, I saw some artist play on Zoom not so long ago, and the music was muted by their client. And they didn't know it happened or how to fix it. No software is immune from misconfiguration.

10 years ago, barely anyone had a smartphone. Spotify then was about Desktop usage.

I used that for build machines. Had a btrfs filesystem on a loopback device I could just download as needed to seed the agents and then make a subvolume to work in. When all was done, I could just drop it. A lot of was automated with "schroot" and definitely faster than spawning a new instance of a VM every time!

Some are graph based, some aren't. ALttP was a giant pile of if/else last time I checked the logic, which makes adding new modes a bit complex.

Same for Netflix app on Samsung TVs, I can see when I'm streaming 4k directly.

Though, WebRTC tracking is becoming severely limited with the current mDNS initiative that hides all the local IP addresses and other measures to hide available devices.

Speaking as a member of one of the many W3C working groups, I would say that it isn't desirable. When designing a standard, we want to have multiple competing implementations of the standard to ensure it is well defined and understood by users.

Should there be one implementation, we wouldn't be able to say with confidence that we have succeeded for that goal.

I was on that core team and that's not quite what I recall regarding the core library.

We had some hard requirements on that library because of protocols used by the backend and other reasons. And when you mention features "mostly related to playback", well, it was 95% of the library from its conception (the rest being login and communication with backend). Most of it is quite complex code and not anything you want to rewrite for each platform (mainly offline storage, remote control, playback).

The issues we had were caused by growing pain from having the library initially mixed in the desktop code (back when mobile wasn't a thing). It needed to be extracted, productified and a whole lot of tooling and testing written for it. Once we got there, the quality of the code was much nicer and the integration in the various clients easy and automated (which it couldn't be at first). It certainly took sometime, but it wasn't a problem caused by it being cross platform, only that we needed a better infra. We were there when I left the company about the same time as you for quite a while already.

The integration with various clients got later easier once we removed the need to reach into that library for just fetching simple server side data. But that wasn't a cross-platform library issue, it was mainly a backend issue.

You can always have both in parallel. The first one to test changes and deploy to production and the second one to try to upgrade your dependencies. Should all the test pass on the second one, you can then commit the new requirements.txt and other updated package versions.

You can then run the second continuously and warn when it fails and handle whatever happened manually, without having a broken prod.

Bingo, that's one of the tuning you can use for real-time communication. There's a lot of ways to tune an encoder, and getting optimal setting for each use case is always tricky.

So you just build your app and pushes the "binary" output on Github Pages? It would be better to push the output dir to another branch folder and force push it when you update.

Unless you're a library vendor, the outcome of multiple repos is most likely a single final application. Or a few applications.

CMake is doing more than generating a build file, it's also a configuration tool (detecting compiler, finding dependencies, etc).

The point was more about general APIs like threading or file access, anything covered by POSIX.

It is already expected to have to rewrite your GFX backend anyway using the specialized API for the platform, but people don't expect the same for general use APIs too.

As for programmatic plays, there's Discovery Weekly, that eclectic and weekly. And you also have the Daily Mixes which are clustered by artist and genres.

They easy enough to find on Android, all are in "Library > Made for you"

> No OpenGL support. I guess this is where world is moving > No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers

Well, tell that to game developers working for consoles. They don't have access to the same APIs and they made it work just fine. Most of the time, you don't make your own engine and rely on some other engine to support your platform, so it just works.

I've done enough Wii, PSP, PS3 or PS4 development and having different APIs was never a problem.

You don't necessarily need it. You could have some math focused code you want to call from JS.

In the civilized internet world, we don't have any data caps though.

This is like saying that car sharing services like Uber are DOA because there are people who like to have racing cars or are professional pilots.

It's a niche market overall, and each is a different segment you can target independently.

If you need really small functions, yes. emscripten is providing all the libc functions, WASM loading code and binding generators. You will probably need some of that when porting existing libraries or applications to the web!

It can be fine as well if it can legally be downloaded. For example, it's possible to get the official firmware directly from Sony or play some homebrew software.

And I'm sure it's possible to find some game demos as well.

Are you really free to do something if it comes with highly unfavorable conditions then?

It's not free to build a platform, but I believe the cost has already been paid by the users when they buy their device.

No reason to have users pay twice, when they buy their device and when they try to use services on the device they already have.

Don't forget that it is a symbiotic environment. Spotify needs to be on the Apple ecosystem as it is massive and Apple needs to have Spotify in its ecosystem because that's what the users want.

As for payments, they all follow the same scheme more or less and redistribute about 70% of the revenue to the rightholders. If the services are priced the same, it's exactly the same for artists.

The big difference is that Spotify has a permanent free tier, which admittedly makes less money short term, but it is driving acquisition of premium users faster than any other methods. The alternative being no revenue, it's just fine. Apple on the same topic doesn't care about razor thin margins on this product, or even losses. They are a hardware vendor, so as long as they still sell their devices, they will be fine.

It's a lot more nuanced than that.

The payout per play is basically different between free and premium users as they add more to the revenue shared by all the artists.

If you look at revenue for premium users, then it's probably much higher than that, but when you add free users, it will lower the average.

A solution you might think would be to remove the free-tier. But that will only do one thing: cut a (admittedly smaller) revenue stream for artists, cut a promotional stream for artists and less possibilities to upsale premium accounts to free users.

Someone who isn't even a free user will either not listen to music or pirate it. Is that preferable?

A lot of artists admit that Spotify pay-out per stream is certainly lower, but it's still dominating all the other streaming revenues, as long as you are actually an artist who has the potential to make any. Some unknown artist selling 1 CD for $10 on bandcamp with no listen on streaming services will probably think differently.