My understanding is the GPL based on copyright - and that copyright only protects a specific expression, not a general idea or concept. To suggest that if something is copyrighted, humans cannot learn from it and generate thier own material seems to be absurd.
PullRequest actually reviews the reviewers (I actually became a better reviewer via this).
'LGTM' is considered a bad practise, and I've been pulled up on this several times. Instead, we're trained to take more time, go deeper, and be very clear about what the changes do, and how well they are written even on relatively trivial changes.
I've gotten pushback on best practises, especially from more junior developers or developers on a tight deadline.
I do C# and one common, yet trivial example is poor naming conventions.
As a reviewer we have certain tools we can use to encourage change:
* We can make comments low priority, so the advice is there, but it's skippable.
* We can make summary comments, that are opinionated but don't expect any immediate or direct resolution (great for architectural thoughts).
* We can include example code snippets in our comments. This reduces the burden for the developer to adopt a certain change. I've even gone to the extent of writing small programs to validate a refactor or prove an error exists.
* Sometimes it's not an error, but how that company wants X done. We take note of these for future reviewers.
Overall, this is a diplomacy game, the only power we have is soft power. I find it good practise, as I'm typically a direct kinda guy.
Results?
I've seen a lot of developers, after being introduced to new ways of working, implement that on later PR's. Sometimes immediately, sometimes after it arises a few times. Examples include improved naming, better code structure, usage of newer language features, more clarity in the code, or better SQL injection protection!
I'm a reviewer on PullRequest, and thought I'd share some perspective. Happy to answer any questions in comments.
Background - I've built and led engineering teams at multiple fast-growing startups. In doing so I've seen the incredible value PR's can provide, but also the huge cost of them on small teams. I review on PullRequest part-time as I work full-time building a startup.
Many of the critics here are right. The PullRequest service won't catch every bug. As reviewers on this service, we lack context* to fully understand the impact of every code change.
However, this can be a blessing in disguise. As an outsider, I bring an entirely different set of context to the project. I can see errors or improvements that teams have become blind to, I don't have the pressure of shipping for X release, and I've often been not only where these teams are, but where these teams want to be in X months.
This is all done without using any man-hours on the client team - which is often a critically short resource.
Ultimately the proof is in the pudding, I raise comments on almost every single review I do, raising from best practice to architectural to security vulnerability, and the majority of the time teams take that feedback onboard.
Other QA:
Where are you located? I'm located in San Francisco.
Who approves PR's? I tend to consider my role to advise and sometimes mentor. I will give opinions, but it ultimately the client's job to approve/reject PR's.
My code is great, I don’t need this! Have you tried it? As an outsider, I catch peoples blind-spots. That said, PR is always looking for great reviewers to join the team!
* It's worth noting, that between seeing the code, optionally having access to the full code base, and asking questions of developers - I develop a decent mental model of most projects.
> Perf/watt isn’t the same thing as task energy, it sounds like you’re the one confused here.
How do you calculate Perf/watt if not Task/Task Energy?
> As I said, task energy (which is what’s measured in the OP) heavily favors “getting it done quicker”
Which x86 can do.
> It’s basically a “race to sleep”
Oh no, it gets the task done faster!
> I’m not the one claiming anything, if you disagree with Anandtech’s numbers go take it up with them.
I have no issue with Anandtech, since they made no such claim. I read the article, you're badly misquoting it.
> And again, that’s with it running at half the clock and half the threads of its laptop peers, so IPC is something like 8x higher in those scenarios.
None of which is ultimately important.
> That is not the kind of gap you close up with a node shrink or tightening pitches a bit. Hackernews experts know best though.
Look at the results again. For example for SPEC2017 ST the Apple M1 MAX is essentially tied with the 5950x.
Sure the M1 Max might be more energy efficent (though by how much you'd need to measure) - but remember it's a massively larger chip, a whole year newer, and on a newer node.
For MT we see the M1 max bearely beat a 5800X for int, and do significantly better for floating point - which shows different priorities of design.
Again, take a 5800X, shrink it down, add another FPU, and it beats a M1 max hands down.
> Next year Zen4 and A16 will be on the same node, and then it’ll be another excuse for why x86 is still getting dumpstered.
Except x86 isn't getting dumpstered.
You're just cherry picking specific comparisons that make M1 look great, and then ignoring all contrary information.
I mean, I could the the Borderlands 3 1080p benchmark, and say that the M1 got 21.1FPS to the GE76's 100, and therefore x86 is ~8 times faster.
It wouldn't be honest (I'm deliberately chosing the worst M1 chip, and picking a workload that really favors x86) - but I could do it.
But I don't, because it's not honest nor is it helpful.
The 3990x is not designed for energy efficiency, on an older node, and on an older architecture... uses 3kWh vs Apples 2kWh (using a very flawed methodology).
An yet you're claiming Apple has a 3-6x power efficiency advantage.