gdxhyrd

Considering UE4 and Unity both support OpenGL, yes, a lot if not the majority of games.

WebGL and OpenGL ES are pretty much OpenGL. Formally they are different standards, but they are based all in OpenGL: if you know one, you know the others pretty well, which is what is important for developers as you agree in the second paragraph.

Thanks!

AMD has always lacked tools and has never produced much on the software side.

That is not news, and that has nothing to do with the state of OpenGL.

Please, stop spreading misinformation about OpenGL.

OpenGL does not stop being cross-platform just because it does not work natively in 1 platform.

In any case, abstraction layers for macOS already exist.

And, going by your definition, if Apple only allows Metal, then no API will be cross-platform ever anyway.

That profiler is meant for low-level debugging as its own description says. That is why it does not support DX11 either.

You are conflating language/build issues with VCS issues.

Everything you discuss also applies to multirepo, but worse, because there no one enforces consistency across all the project and you will end up with a broken interdependency.

A lot of games and apps are being released using OpenGL today.

Then there is WebGL and OpenGL ES, widely used everywhere too.

So, no, it is not going anywhere. In fact, Khronos themselves have said so.

Apple is not Khronos.

They haven't supported OpenGL for years anyway, so the fact they deprecate it now is irrelevant.

In almost no situations you want to have software, pixel-based access.

Are we really going back 30 years?

Where is this all being discussed and developed?

POSIX, SDL and the usual suspects are pretty much cross-platform and run everywhere.

Eh, no. Vendors everywhere will package things for your architecture and give you binaries.

That is how it has always been done and is still done.

Yes, you can do it differently with an IL, but that isn't new either (Java, .NET, etc.).

No, OpenGL is not "on the way out". Please back up your claims.

You are right, I was thinking of CVS.

In any case, with SVN you usually do not want to give write perms to everyone in all the tree, so you end up with effectively partitioned spaces, or you make several repos instead, or you put another layer on top. With Git, anyone can easily develop global commits.

> Plus, one have to draw a line somewhere on what to include (a Python interpreter? A Go version? awk and grep?), and third party vs in-house is a fairly robust one imo.

If your code/project/company uses the dependency in any way in production and it is not a part of the base system (which should be reproducibly installed), you include it; either in source or binary form.

Why is the size a problem? Developers should only be checking out once. If your repo hits the many-GiB mark, then you can apply more complex solutions (LFS, sparse, etc.) if it is a burden.

> This is what confuses me about monorepos. Their design requires an array of confusing processes and complex software to make the process of merging, testing, and releasing code manageable at scale (and "scale" can even be 6 developers working on 2 separate features each across 10 services, in one repo).

False. It is having multiple repos what creates those problems and a huge graph of versions and dependencies.

What "processes" are you talking about?

What? I don't understand what that means.

A monorepo is just 1 repo. There is nothing more straightforward than that.

> IME, most consternation comes from people adopting a mono repo without adopting a build/dependency graph tool (like Bazel, buck or pants).

That seems like a build problem, not a Git problem.

> An additional source of strain is from people abusing the repo (checking in large binaries, third party dependencies, etc).

That is not necessarily abuse. In fact, it is a good practice in many cases!

> A third is when people try to do branch-based feature development, instead of the “correct” practice of only deploying master (or weekly cuts of master).

I am not sure what you mean by branch-based development, but I don't see why that would be a specific problem of monorepos.

It depends on what you are trying to do.

Most of these benchmarks are not done to predict performance in a target machine, but to find out which is faster.

You are speaking as a stats person. :)

While there are dozens of things that can go south in benchmarking, how to solve them is not about applying advanced stats, but about understanding and eliminating the sources of noise.

Most benchmarks in CS can be done quite easily as long as one understands all the technology stack.

> Please don't do that: they won't necessarily be the outliers in the dataset and your model will converge to the wrong thing.

They are the outliers. These experiments are typically measuring something that is effectively constant with almost zero noise, rather than some complex physical phenomena.

If you don't get an almost perfect fit, there is something going on that invalidates what you are doing (e.g. cache effects, clock effects, etc.).

In fact, if there are any outliers, I would not trust the benchmark at all. So removing them seems like trying to fix a bad benchmark with statistics.

> Statistics is hard. Like, really really hard. Stuff goes wrong all the time. Please leave it to the experts.

That is unnecessary gatekeeping. Benchmarking in CS is hard not because the maths/stats that are needed are hard, but because setting up the right experiment is hard and most people don't know all the pitfalls.

Therefore, if anything, you should leave benchmarks to CS/SE experts, rather than a statistician!

Not really, because commits don't go across the entire SVN, which is what makes monorepos so powerful.

What problems did you encounter with just a few services?

Monorepos should be straightforward unless you are managing the code of >1k engineers.

No, ML works fine with large output spaces too.

The problem is that the solution space grows super exponentially, and if you need to find an exact one, then the number of samples too.

Thanks a lot for this.

I never understand why Mozilla doesn't allow to enable this in the settings.

Wait, what?

So you think a kernel is large and has to be counted in the total, even if a browser also requires a kernel.

Yet you think web apps don't need libraries, so you are not even counting the browser and its dozens of libraries?

How is React or hooks "full FP"?

I think we have wildy different definitions of FP.

Apple should not have that kind of power, though. They have been wrong before.

Instead, the scrutiny and investigations should be public so that the developer can defend themselves.

> few site reliability engineers are looking to add extra ways for the site to be taken offline

If your company has anything close to "reliability engineers", then you already have legal and finance teams too that can sort terms out.

The discussion is about companies that do not even have departments to begin with.

Kind of, yes.

Nowadays (for almost 20 years actually), Windows supports and encourages programs to deploy their dependencies in their own folder.

It is trivial to do for developers and works perfectly for users.

Some people claim security updates are a problem, but many apps do not deal with untrusted input for starters. For those that do, like browsers, servers or your office suite, you really should be using one that is supported and updated automatically.