Orphis

That has nothing to do with the compilation of your program. This is a specific option to use in a specific configuration and specific compilers.

So if you want a configuration with some flags like that, then you can have a separate file for it. Each compiler is different after all, some will need different options.

It is rather intuitive for someone knowing Make. Even then, which version of Make are you talking about? GNUmake? WHICH VERSION again? 3.82? 4.0? Some features in 4.0 aren't backward compatible of course, so you have to be precise about what you are exactly targeting.

If you are using anything advanced, then it will become unreadable for beginners too. Try to explain delayed and immediate variable interpolation to beginners, that their "VAR = foo" doesn't always work the way they think it does.

On the other hand, yes, the CMake sample above is self explanatory, works on all platforms (more than Make itself), all compilers without having you to write low level compiler invocations, supports IDE for easier debugging (sure, you can also tell your users they have to learn how to use GDB by hand, just... good luck). It will automatically rebuild the right files when their dependencies or command line changes, you don't have to code that by hand for each compiler (and probably have many subtle bugs in your implementation too).

Make has a place for simple things, not for build systems, we have way better ways to do them now, even if you refuse to use them.

"GNUmake is required, but you are running FreeBSD".

Not saying it's not available there, not all platforms have all software available right away or up to date.

Even then, upgrading CMake is the easiest thing ever: "pip install cmake". Or fetch it from the Github releases page quickly, it's always available as static binaries for all major platforms.

Sure, if you're running commands, but you're not building Java directly with it. That seems reasonable.

What's more simple than "add_executable(foo bar.cpp)"? It's concise, cross-platform and hides all the boilerplate for you.

Sure, everything in CMake is not super intuitive, but I've led workshops were people got the hang of it pretty quickly for simple to advanced cases (including multiple targets and some scripting). Keep it simple, most of the time, you don't need the advanced features at all!

Can't say the same for Make, apparently, people need to write about it still today! And most of the Makefiles are just plain wrong and won't make any reproducible and reliable builds. That's a big no in my book for a build system!

Makefiles, Best Practices: Don't write Makefiles, use a higher level language to describe your goal and some tool to execute it (either directly or through generating a Ninja file).

The Make language is the assembly language of build systems. Do you really enjoy writing assembly all the time?

As for the gigantic monolithic codebase, a proper build environment will know (to some degree) what tests could be impacted and only run those in CI.

And if you have segmented your tests in fast and slow, you can always invest in the proper infrastructure to only require fast tests to pass before CI and have some degree of automatic rollbacks (or supervised) when slow tests break.

Last time I checked, the free offering was 2 CI builds in parallel on AppVeyor, which is just too low and slow for feedback on my project.

Also, considering I make exactly $0 per month from it, it's either be patient or use another service that had more capacity and faster builders.

I believe that Travis-CI had a higher limit for parallel jobs, but your builds would most often end up queued because of a low capacity for a certain type of agents. Also, something quite noticeable was their lower limits on build time, which is why for some builds a cache was necessary. It got a bit hairy when you needed a full successful build to properly populate the cache but they would never finish in time. And of course, the biggest drawback from Travis-CI back then was the lack of Windows support.

As for Azure CI, I believe there's something like a 10 parallel builds limit. And I've got exactly 10 configurations!

I've migrated my Boost builds from Travis and Appveyor to your CI offering recently. It wasn't super smooth, but I got it to work quite fast and I like it a lot.

So sure, I'm missing caching that I've had on Travis. But honestly, it builds reliably fast anyway. On Travis, I always needed to wait a LONG time to get macOS agents, on Appveyor, we were limited to 2 parallel builds. Here, everything starts all at once, completes under 10 minutes (there's quite a lot to build and test).

If I could, I would love to have an sccache ( https://github.com/mozilla/sccache ) compatible distributed free caching solution for my C++ projects. That'd be a killer feature!

The major issue I see regarding a cash-free society (which I am part of by living in Sweden) is that it puts a big burden on tourists who have to pay a huge amount of fees when using their own cards in a different currency.

It is also a bit similar for expats who, under certain conditions, can't apply for a Swedish person number (think SSN) and thus get a fully activated bank account. No bank account? Good luck doing anything!

gold is sure fast compared to bfd.ld, but then you should try lld from the LLVM project which is much faster in general.

Not that many really.

Since the mobile apps and desktop app share a lot of code, you could if you wanted profile the desktop app in similar scenarios to guesstimate usage patterns. As long as you remember that the desktop app will also load more data (bigger screen, so more data to handle), it should be fine.

Somehow, you could compare it to a browser usage pattern. There's some index, some various files that are cached... My guess in your case is bad quality SD card or bad SD drivers / reader.

There is a WebRTC over QUIC experiment, the standard document can be found here: https://w3c.github.io/webrtc-quic/ It is currently not a work item of the W3C WebRTC WG, but we hear about it every time we meet.

The current focus right now is to deliver WebRTC 1.0, when this is done, we may reconsider it.

Make is a much of a build system as C++ as you can call stat() and system() from it.

A modern build system by default should be able to provide utilities to make sure your build is correct and reproducible. Those features need to be coded into your Makefile and aren't available easily or by default.

If you need to code those rules, then you don't have a build system, just a way to run commands and possibly add some (usually poor) logic around them.

A typical example that most handcrafted Makefiles will fail is that changing a build flag should only rebuild the files affected. Most will either require a full clean (aka ignoring the flag change) or rebuild everything.

You don't pay to develop, just publish. So hobby developers are fine.

Also, my take on this is that you should probably not mix WebRTC and ORTC APIs. Those are quite different (even if there are similarities).

If you want to implement ORTC, fine, but you should probably do it in another package and make sure you don't expose fields in WebRTC that aren't part of the standard. Some fields (like the SSRC field) is not exposed for good reasons.

Anything related to RTCRtpSendParameters (previously RTCRtpEncodingParameters) really.

For example, RTCRtpSender.getParameters is missing and the setParameters seems to be missing (unless that's the send function). And as far as I can tell, you are not supposed to call setParameters without getParameters first, so that's not spec compliant ;)

And of course, the sendEncodings property of the init parameters in addTransceiver is missing. It is required to setup simulcast (and later SVC when we standardize it).

Nice work! As a WebRTC implementer (both native and in Chrome), I applaud the work!

But I can only notice quite a bit of mismatch between your APIs and the current spec. Do you plan on updating your implementation to match it?

Above the previous average. With the increase they all have, it may raise the average income in the area too, and they could still be below it.

They say they have done it for performance. I am wondering if they wanted to optimize for the client performance or the SFU's.

There are Java Android and ObjC iOS bindings available in the repository. Not sure how those would work in a regular JRE or ObjC macOS environment, but it should be alright (but then, you might as well use the C++ API directly on macOS, just saying).

If you need to request more APIs, you should try to talk about your usecase to the WebRTC working group using the users mailing list ( https://groups.google.com/forum/#!forum/discuss-webrtc ). Depending on the question, you may also ask on the spec Github project ( https://github.com/w3c/webrtc-pc ).

Source: Google employee, in the WebRTC WG.

At large scale, you still need to have proper API boundaries, even with a monorepo. Otherwise, even with the best tooling, you will never be able to change anything.

The APIs are there to ensure the behavior won't change and break anything. In a monorepo, that is easier to check by running all the tests that are affected by your code changes. The actual programming "syntax" is a detail though, and that can be changed (atomically everywhere) anytime with proper tooling.

It's only in the old traditional split model that APIs are supposed to be a guarantee for syntax + behavior (+ sometimes ABI).

I was sitting on row 13 last week in 2 planes. Really depends on the company.

You know what let's me access the Steam store (and many others)? Any VNC client to my other computer.

Or just the regular Steam app. Check the screenshot page on the AppStore and you'll see the store with prices and all.

About 20 years ago, I did a one week internship as a teenager in some lab that worked exactly on this. They were trying to grow and select enzymes that could process different types of oil that frequently occurred in spills.

The tricky part was to make sure they only targeted what was in the ocean. You didn't want them to start propagating into the oil tanks in boats, or start processing all the random plastics that make up boats or various infrastructure.

I remember on my last day, they had some really good results with some samples that processed some oil really well and were quite excited. I then left, and have no idea if they managed to reproduce the results or not.

No, I meant it would give more money than it does now. Smaller artists are REALLY small compared to any others. The main problem that small artists have is exposure and bad contracts anyway, and none of those can be fixed by changing the payment system.

Don't blame the service for missing tracks but the artist's label for not putting them there.

I once complained to Sufjan Stevens' label about his albums missing in Spotify. They basically told me the deal with their distributor in Europe expired and they didn't look for a new one yet. "woops". It took them many months to get the tracks back.

What kind of phone do people have in emerging countries? Certainly not an Apple one.

I wouldn't worry about Apple too much, the market will become saturated in some countries after some years where they are popular. But in other countries, where they only use Android, who do you think will win the market?

But no one actually does that, and if you really did, you don't need Spotify, just buy their album directly. Such a payout seems appealing in theory, but in practice will just give more money to the very popular bands since they dominate the market and leave a much smaller share for the others.