Agreed.

I don't care what shape / size the bulb is, particularly. In some cases I'd rather not have it try to emulate a traditional bulb.

Just plug in, and put out light, for most circumstances.

That said, most modern light fittings are LED or halogen and those can be tiny little things and hide among the ornamentation of the lamps.

I'm not sure about non-replaceable but they certainly don't need to be easily-replaceable nowadays. I'd be quite happy with having to take down the light-fitting in order to change the bulb, to be honest, if it really lasts as long as it should.

The last light fitting I bought is exactly that with an LED uplighter in it. It's some stylistic thing that my girlfriend liked and will be a pain to change when the time comes but, who cares? So long as I don't have to do it every month.

But, to be honest, short of the "old" light fittings I've inherited from previous owners, I can't remember the last time I changed a bulb. I have an outside light with a CFL on a timer to light the driveway every evening, and that's been out in the extremes of weather for two years and not needed a replacement.

Hell, even the shed runs off some LED clip-on lights that were about £10 each. It's cheaper to just buy new lights.

Over 500 draw calls per frame. I've only ever tinkered in basic OpenGL stuff, but does that seem like an awful lot to anyone else? I was always told to reduce draw calls and to use the newer OpenGL features as they were able to batch commands on thousands of vectors, etc. (or are we talking about different types of draw calls?)

Especially as a lot of the work is done in shaders and shared between passes according to the article?

Wonder what kind of texture etc. bandwidth that's pushing.

What makes you think you're able to programmatically determine that and return it to the BIOS?

For those interested, the show I'm talking about, with the man himself:

https://www.youtube.com/watch?...

He appeared on a TV show in the UK basically arguing just that. When the time came, he wanted to be able to press a button or whatever and choose himself, and it was long after he started down the road to Alzheimer's that he appeared and argued that.

Actually he barely said a word. He was too far gone down the Alzheimer's route by then, and Tony Robinson (Baldrick) had to say the actual words he'd prepared for him, if I remember correctly.

At least Death should be kind to him.

He made Death more human - and humane - than almost any author before him.

Terry, Sir, just make sure you don't end up cleaning Albert's boots.

Well, if copyright extension laws keep... extending... then it's only going to become a bigger and bigger problem as estates of former artists just keep suing and suing forever.

As far as I'm concerned, this is a problem of the industry's making anyway. Which is exactly why, some 70 years after some songs were released, their copyright is STILL not available in the public domain.

"Handed me a vegemite sandwich"

That's all I have to say.

How many of those multiple people have done what was requested in one of the very first replies - test under nouveau, where they stand a chance of debugging? None. How many tested not on Fedora, as suggested? None.

An offer to debug is only useful if people have a tiny clue what's going on. In this case, we know exactly what the problem is - there's an unshared pixmap trying to be used as a shared one.

And, as someone points out in the thread, there is NO instance of an unshared pixmap being created in the code and passed to those functions. So either there's a patch being applied somewhere, or the nVidia driver is talking nonsense or breaking itself.

How to debug? Ask nVidia to provide a debugging version of their MASSIVE driver so someone can get a clue about where the original pixmap it has a problem with came from.

More likely, there's an interaction at play here - a distro combination with the XR+R options with a particular version of the nVidia binary and maybe even some memory corruption (where something not a pixmap at all is being passed to the shared pixmap functions!).

But without a line number, a clue, an origin, a pointer, etc. then it's impossible to debug.

Like all things - you need a reproducible, and bisectable, bug in order to be able to get close to a reason in any significant amount of code. You can't break into or debug the nVidia binary AT ALL unless you're nVidia. The XOrg stuff doesn't look like it ever creates an unshared pixmap in or around these functions. Nobody has worked out if it's a Fedora specific, nVidia-driver-specific, or even card-specific bug.

And it affects precisely, what... 2/3 people on that thread.

If you want help in fixing bugs, you have to do most of the legwork, ESPECIALLY in open-source projects. Because likely you're the only one it affects and until a common ground can be found, nobody can reproduce it.

Like my entire day's work every day in IT:

If I can't reproduce it, I CANNOT fix it.

If it always works when I try, even as your user, even on your computer, even doing exactly what you said you did, whether that's a printer not working, or a driver crash, or an obscure bug, I can't do much about it. If I can't make it happen in front of me, I can only stab in the dark as to the cause until I get lucky.

Try it on Nouveau.
Try it on Ubuntu, say.
Try it on the previous nVidia driver and the latest (if it isn't already).

When you get the bug in TWO places, someone can start drawing conclusions about the cause. If it works on Nouveau, it's probably not a hardware bug. If it works on Ubuntu, it's probably not a Fedora-specific bug. If it works on other nVidia versions, it's ALMOST CERTAINLY an nVidia bug.

About 20%. There are about 5000 games on Steam.

Probably not a lot. The hardware surveys don't bother to include Linux for most things because it's such a tiny portion.

But the old arguments of "We can't make games for Linux because of X..." doesn't hold true - it's just as capable as the other two major OS. It still may not be economical to make Linux ports for everything, but that's another question entirely.

And, again, the Steam purpose-built machines may change all of the above dramatically. Or not.

Anecdotally, about 1/3rd of my 900 Steam games are on Linux. More than are on Mac. I could happily get by with just the Linux games, Linux office suites and Linux base OS for my daily and work lives. The only change there is that Steam has made the first viable whereas before it was a lot of faffing and installing Wine and all sorts.

A long-term user of Wine, Crossover Office, Steam (day-one signup), WON before that, and someone who's lived and worked an IT job for many years with ONLY Linux laptops for my own use.

The problem is that the OP of the bug report has only tested on nVidia binary drivers, by the look of it, and has not managed to reproduce on nouveau. Only an nVidia engineer has said that it was an X bug, nobody else, and that's hardly gospel.

Maybe it's just a cock-up in their binary driver? Who knows? And it doesn't look like an awful lot of people have the same problem.

It's a thread synchronisation instruction available on certain processors.

Why? Because you cannot make code run in different sections. Here, the physical hardware is PROVIDING the facility to access a table which is normally privileged, which determines whether a program is allowed to access ANY AND ALL RAM.

The privilege is not normally available, and would normally block almost all such attacks. This is a complete way around all the hardware features that are supposed to stop this kind of access and so, of course, the kernel can do NOTHING about it.

The problem is that most software bugs DO NOT give up escalation at all, except where poor code is run in an escalated context because it HAS to. It's actually quite hard to find a privilege escalation bug that an ordinary user can actually exploit anywhere near reliably, and they are usually patched EXTREMELY quickly. This is actually a hardware bug meaning that all such hardware precautions, restrictions and security are basically bypassed because of a hardware bug.

THEIR exit nodes.

There's nothing stopping such a high flux of new exit nodes in the face of censorship. Especially as ANY client can be an exit node, in theory.

Let's say it's ten a day.

That's still hundreds of days. Maybe still thousands.

And that's if it even shows up on side-scanning sonar at all, in any way, whatsoever now.

Just finding a cable that you KNOW is exactly down THERE to within a good error margin can take weeks.