mpixel

Ultimately, I think we disagree on the essence of the issue and many consider the 'almost enough' option to be worse than 'enough' which is the crust of this issue.

That said, I respect your opinion -- I've seen your comments on the thread and I see where you are coming from.

The thing is, information leaks. You can go and read the Windows source code, if you want to, you just would get busted if you actually use it to build your own Windows or something.

Likewise source code is a shared a lot in my experience, i.e. the important software that's closed but has the important customer, the important customer gets the access when they ask for it. This depends on who you are and what you sell, of course.

So in practice, the difference isn't that huge.

That said, you are right too, THERE IS a difference. And it's better than entirely closed source.

So I will prefer the source-available over completely-closed-source, but I'm not going to be grateful about it.

And then there's realities, if I'm writing business critical software that my life depends on, I'll make it closed source in all likelihood. I'm not Stallman.

So I don't blame anyone for caring about their interests, it's entirely fair.

The tradeoff is that the app runs faster, looks better, works better -- in quite the indirect way.

Now that the developers on the core part don't need to spend time on compatibility -- or, just dont want have to make the base choice of being a runtime dependency -- they can spend time on other things instead.

This seems like a net negative at a glance, on the surface it means the apps are less compatible, so the second level is forced onto the older iterations, in practice, since each iteration has to worry about a lot less, the older iterations are _also_ a lot better instead.

It is of no surprise to me these Apple or Apple-like systems tend to be better overall, as opposed to the other philosophy of Android.

It leaks into all the levels. In the Java app, it is usual to see a deprecated warning that keeps working and it is maintained, and someone pays for that. The negative side is that there's no reason to get rid of the said dependency, either.

My point is that lowering the maintenance cost of _any_ app or systems in general, leaves room for improvement in all the other areas, as long as you don't fall behind -- if you are allowed to fall behind, you can afford to, if not, the end result is better given enough time.

Ultimately -- the thing is, if anyone is both capable and willing, they can, and sometimes do, fix it.

Granted, this combination is rather rare. Most people aren't capable. Of those who are, they have better things to do and they probably have very well paying jobs they could be focusing on instead.

With that being said, Linux is _still_ more efficient than Windows.

I don't want to say Linux is free, in practice it's not, those who are running the big powerful machines are using RHEL and paying hefty licenses.

Which are still better than any other alternative.

As a supporting point, right now people have decent GPUs but as people get a taste of the streaming approach on a laptop for example, and with the GPU prices increasing, they might not want to spend a whole lot of money on it. A small subset.

And then the AAA-studio will see the hyper-paced style of game would be a bad experience and reduce the revenue, being more likely to prefer the styles that are more comfortable with the latency.

This in turn will make the approach itself more viable let alone the improvements in the area, and when the most popular games ensure they are viable on these platforms, you won't need to buy a 4XXX card.

People I know are looking into 3XXX and 4XXX cards at the moment when they are building a PC or buying a pre-built, 4XXX for the latter scenario, not necessarily 4090 or anything, really just the ones closer to the entry point, and honestly they aren't great value.

I don't like this situation but the writing is kind of on the wall, for the laptops I already see the streaming becoming common.

And if you tell 2 experts to build something with W3Schools as the resource against better documentation, I'm sure the results will be the opposite.

That's not the point though, I'm not going to say different strokes for different folks.

Instead I'd say, if that beginner uses the 'slower' path instead, that will pay dividends in time -- they are better of learning to use the docs than getting paid peanuts for delivering that project which depends on the juniors faster.

Bitwise operators only work on the first 32-bits, so it isn't as easy as `instead of doing the Math.floor operations, check for edge cases and just the same operation as ~~`

They don't spend 30 million per year, they spend 30 million over what they generate.

I don't think they'd generate peanuts so as to not even cover hardware costs.

It's almost as if a site for tech has bias for tech commonly enjoyed by the readers of the said site.

I'm shocked, truly.

> I'd wish it not be repeated, because we both know you don't really believe it.

I'm reasonably confident most people here understand the semantic behind the meme, rather than taking it at the face value as if it's a statement in a program.

I agree with all your points and also agree that honestly, these scenarios aren't far off from real world tasks.

I get the main issue, which is you could adjust the workload by 10% and achieve a 50% performance loss when you do this at the point where we cross the cache threshold and whatnot.

However I see CPUs unique in that I rank them _for_ these scenarios. A particular might be ranked unfairly, but as long as the test is equal, the better one is infact better, just not by the 50% the test might show but it's still going to be 5% better. I expect my GPU to be idle when it isn't training AI or rendering frames, but for the CPU, it's general purpose in real life, and anything goes.

It had multiple angles it could succeed on really.

It had two major issues.

The first one was if you went beyond using it yourself or a very limited collab, it would desync, which was a major deal breaker for something like this. Nothing google with their vast amount of resources couldn't fix though.

The second one was it really was usable for multiple niches. This made it confusing for the general public, and the main audience doesn't even bias towards IT when you are at the scale google operates at.

You could use it as a note taking app yourself that you think might warrant sharing or collaborating later on.

You could use it as a spreadsheet, like how google sheets currently function.

You could use it to replace what we use Slack for these days.

And I really think that a niche or a community would find it useful for one of these and it would become a major tool they'd depend on if google just let it sit around for a while.

There also other cloud companies to depend on that have been more sane. I doubt that in practice this will cause huge insurmountable challenges, but it's a headache and not a ton of fun.

I'm not a C++ programmer, could you explain why this is a bad idea?

> People just don’t want to deal with the reality that the Taylor swift tickets that start at $40 or whatever were never real to begin with

This.

Here's a much more optimal semi-auction style solution. Tickets go on sale for 20 days, each day, all the seats and spots are worth the same price, you can buy anything, the price is always the same.

Day 1, the price is $2000. Day 20, the price is $10. So you'd only pay $60 at most for a ticket? Sure, just check in on day 16.

Since we start the price at the higher-than-scalp price, there's no scalping opportunity if you are paying the 'real market price'.