Would you keep cooking if a Star Trek style replicator existed that could more or less cook anything in a minute? What if all of your friends and family were satisfied with the replicator food and weren’t willing to wait for you to cook anymore?
It's like ordering food from outside versus cooking food yourself. Yes, you could order it and it might be appreciated but cooking something for others will, if they're good people, have them definitely appreciate your effort. And there's a difference between cooking for sustenance daily, in which case I too would use the replicator just to save myself the effort, and cooking for fun and special occasions.
This is analogous to coding as a profession versus for fun. For work I'd use all the tools at my disposal to get the job done because that's what matters in a corporate environment. And for home, well, I'll code some things and vibe code others, depending on how I feel about a certain project. I think OSS maintainers lean too hard in setting themselves and others too high of expectations such that they burn out like this, many such cases, when in reality they shouldn't take it so seriously. Work on your code when you want to and leave it alone when you don't, the license literally says "as-is," so follow that philosophy.
> If AI can do what we deem creative work, say implementing a chunk of a Ruby gem, should we still consider such work creative in the first place?
Assuming that it can, and it can also do a great number of things that we previously considered creative work, what’s left?
I recently played some music for a friend by an artist I really like (mitch murder), and his comment was that Suno AI could generate plenty more songs along the same lines. Now, I’m not so sure it actually can; I think the human behind the music is bringing something special to it, but this nuance is lost on my friend. Suno AI is good enough for him.
I think the situation with these ruby gems is similar. I, personally, would rather use the human crafted gems, but there are plenty of people like my friend who think there’s either no difference or no important difference between what the creative human made and what the machine can make.
Linux isn’t a good analogy to Chromium due to the differences in history, licensing, and project governance.
Linux is GPLv2, it has many outside contributors, it was built from scratch, and it has Linus as a neutral party as the final decider in terms of the direction of the project and what gets included.
Chromium is a mix of LGPL, BSD, and other licenses depending on the component. Chromium was originally forked from WebKit; it isn’t a from scratch project. Google decides what changes get merged to Chromium.
I think the author’s use of a 500Hz display covers up or minimizes a lot of issues. It’s really easy to look at this data and say 8ms click to flash is fabulous even though he has an config that does 4ms.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.
At one point you could have said the same thing about Blizzard, that everything they did was gold. It’s hard to pinpoint where they went wrong, but it’s not clear to me that it was business model or game format related. Like, WoW was a fabulous success from day 1 and it was a live service game.
No, this scenario works fine. Car audio (and UI) can interleave with CarPlay. I can put podcasts on my center screen, my car manufacturer's navigation in the driver's screen, and the navigation prompts will duck the podcast and interrupt as appropriate. This isn't hypothetical or hard, my car does exactly this today.
Right, this is why video parse / decode ought to be sandboxed. Writing secure code for these formats, especially in C, is really hard. I just sort of glanced at the bug in the repo, but it sounds plausible. It certainly wouldn’t be the first of its kind.
I’m not sure what the bug is, but this is a terrible fix. What this is doing is forcing the WindowServer to composite the cursor rather than treat it as a hardware overlay. I suppose the issue must be pretty bad for OP if this helps, but … ugh.
Reminds me of a fix I wrote a decade ago. My Laptop would sometimes start emitting a high frequency whine when on battery. I figured out it only happened when the CPU went into performance states lower than P2 for power saving.
So I wrote a bash script that auto-started on battery mode and then calculated a hash every few seconds. Boom, whine solved. Terrible fix, but I never measured how much battery it cost me, so it was... fine.
Terrible fix but it's a fix that's minimally-invasive and addresses a bug that causes a disproportionate annoyance to the fix. I can imagine your cursor lagging is something that is extremely annoying over time.
I've also had computers with nvidia, amd (even back when it was still ATI) and intel gpu's, at least since 2006, and can't remember ever having an issue like this.
Not saying it's not an issue, but there is such an incredible amount of hardware configurations that linux supports, so it's a bit weird to say that "linux" in general has suffered a bug like this.
There was a time when it was quite bad, especially if using Wayland and under heavy CPU or I/O loads. I think this has mostly been solved now, but I do recall getting frustrated with the switch to Wayland because of it.
My latest and greatest ThinkPad T14s Gen 6 likes to do it sometimes on cachyos, I can't nail it down from a KDE or hardware issue as it never does it while docked or a external mouse
not necessarily ubiquitous, but you can encounter some issues with "lagging cursor" even today, if you use standard raspbian for example
> usbhid.mousepoll=0
> to /boot/cmdline.txt
> This option was implemented to enforce a mouse polling rate of 62.5Hz which dramatically reduced the XWindow event system update rate in certain circumstances (oddball or "performance" mice can have update rates of 1000Hz, which is silly).
The number is as low as 2. Hell, it may even be 1! I have had a subscription for years, I do not share it, and I read on 2 devices, and they've been hassling me with this nonsense for the past week or so. I'm holding out hope it's just a bug and they'll stop, but if it goes on much longer I will cancel too.
As a long time DF reader I can assure you that John does not use Chrome to browse the world wide web.
You are almost certainly correct in saying he is using it to illustrate his point because Chrome is engineered to be part of the internet advertising complex that commits so many of these crimes against design.
reply