msoTriStateMixed applies to aggregates. Eg, text.isBold() can be true, false, or a mix. Partly bold, partly not bold.

msoTriStateToggle isn't a real value but only used as a sort of flag. So eg, text.setBold(tristate), where "Mixed" would be invalid, and "Toggle" would flip the bold-ness of the text.

The msoCTrue one is where it gets really weird, no clue what's that for. I suppose an ill-conceived attempt to support the other way to express True.

True being -1 was a thing in Visual Basic and I suppose by some other Windows stuff. Logic being all the bits are 1.

https://xkcd.com/1170/

Obviously that's not what everyone argues, my point is that there's a lot of chaff in such arguments and not much wheat. People make a lot of noise about dramatic but completely unrealistic scenarios, while ignoring the far more boring reality.

The PauseAI people are for instance talking about human extinction, somehow. And not crappy GitHub PRs.

But yes, what you said but unironically. Like it or not it's here, it's not going away, so all the remaining options have to assume that.

Even pre-AI it was obvious that contributions have to be vetted for a bunch of reasons.

At this point it's impossible, so I concur with the parent: forget about the shutting it down and think of something actually realistic.

"No headset audio" -- displayed by the Oculus desktop app, in regards to not having audio on the headset. There's a "learn more" link, which would send you to the general troubleshooting FAQ.

So, the program knows something is wrong with the audio, but completely refuses to say what. Is it a headset problem, a driver problem, a restart needed!?

Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is:

    [{"error":"Attachment is too large. Limit 20 megabytes."}]

I like coding, I just don't particularly enjoy figuring out the framework du jour. The task at hand is interesting, but the part where I need to figure out what are the incantations to have a Qt list with images in it is not. I need a working UI to get the thing done, but the framework stands in my way, requiring me to step away from my task intended task and spend a few hours on understanding QTreeView.

That's where I really enjoy AI currently, because I can get the GUI stuff out of the way much faster and get back to the thing the GUI is for.

Now within the specific problem I'm trying to solve, sure, I enjoy thinking about the abstractions, maintainability and extensibility. That's the part that actually matters. But the Qt UI on top, that's just a visual layer with a structure that was already set in stone, there's no big decisions of interest to make there. Just to figure out how to make it do the thing.

Yeah, the problem is that a lot of those are effectively dead, subsumed by Reddit and Facebook.

I've sometimes dug up still existing sites from the 2000s I used to visit, and the results are typically depressing. Such as:

* Site still exists, but is terribly broken. Doesn't render, uses now incompatible SSL, or something. It's a forgotten server in somebody's closet, still chugging, but not being maintained, so whatever remains will probably vanish whenever the disk/PSU/etc fails.

* Last posts from 2015, mostly with "gee, it's kind of dead in here, anyone still around?" comments at the end of threads.

* Discussion is down to 5 people that post once a month, and there's also a thread with obituaries for past well known members.

Mining is what generates the coins. And you need mining because otherwise you need some other issuing organism. Without decentralized mining you get a central issuer, and that's untrustworthy and possible to shut down.

In such situations something's got to give. My choice is that the something is the rigid process. Because I think it's much preferable to make a plan with the whole team present.

It's not that big of a deal really. Flexibility doesn't mean we're always picking random sprint lengths, it means we make occasional concessions for real world constraints, which is kind of the point of Agile anyway.

It's not a law of the universe that there's got to be a sprint every 2 weeks. For instance I'd schedule them around holidays and vacations. Try to make sure for instance that the next sprint planning coincides with a team member returning from vacation. That way they're in the loop about where things are at, and we don't make a plan based on some assumption of what Bob might do when he returns mid-sprint without him being there.

Overall I think sprints are a fine idea, projects can be complex, it makes sense to me to periodically sit down and figure out if we're getting there or not and what the next steps are. We'd also try to have demos each sprint to make sure that something actually works.

I think most of the failures come down to that all those rituals have a reason for them, but that only works if the team is actually on board. That needs a good manager in place, somebody who understands what the point of it all is, pushes people in the right direction, and adapts to problems. There's a lot of room for minor changes as needed.

Take the first complaint, "My standup is people reading Jira tickets out loud". That's obviously wrong. Jira's already there for everyone to look at. Standups to me are mostly about the non-obvious things. It's where John announces he's figuring the build system needs a bit of a change, so that might conflict with other work. Where Carol complains that the ticket is taking ages because testing takes too long. Where Bob says he's not making progress because there's this weird thing with this API, and does anyone know what's up with this?

Now I'm not going to say Scrum is a magic wand or anything. It's just a bit of structure that IMO is overall a pretty decent idea overall, I just have a feeling that some organizations get lost in the bureaucracy and forget that the point is getting stuff done.

My personal biggest issue with Scrum in years of dealing with it is that I think sometimes teams should be split up. I've been on teams where a project is really made of parts with little overlap, and IMO in such a case you should consider splitting the team, because you can end up with situations where people sit through meetings where they have nothing useful to contribute. That's about the biggest time waster I've personally noticed.

Micro USB's improvement was reversing where the weak bits were. Now it's the cable that wears out, so when it does you just throw it out and buy a new one.

Attachment to the board is another thing entirely, it's all about having some sort of through hole pins to hold it in place (not all devices had that, some were purely surface mount), and good design. I think some devices had a tiny daughter board for the connector, to ensure that part could wiggle around a bit for stress relief.

Plenty people wrote plenty of Perl long ago. Yeah, the whole $ business is maybe a bit unintuitive, but it's the least of the problem really. It's easy to get past it.

IMO, the first part of Perl's downfall is that it didn't evolve fast enough. It was good enough that people tried to do big things in it and then it turned out it wasn't a good idea. Perl's OO for instance is kind of a neat hack that turns into a horrible mess with large projects. Large projects also increasingly need verification and safety because the debug costs rise higher and higher, and Perl is paradoxically safer at small scales. "use strict" works great in toy scripts and is nigh useless in OO-laden large projects where "strict" does nothing to check your $this->{foo}->{bar} hash trees. Yes, solutions sort of exist but they're all adhoc and you have to plan for them, and module writers don't use them, and...

That could have been survivable with the right improvements, but:

The second part is that Perl 6 was terribly planned and took bloody ages to get anywhere. People stopped writing Perl 5 expecting Perl 6 was around the corner, so why invest too much effort when it was clear 6 was going to be incompatible even early on? And it kept not coming out, so Python quickly ate its lunch.

Also, RJ45 is terribly fragile if you keep plugging and unplugging it, eventually that latch will break. And copper can barely support 10G and is terribly power hungry when it does that. And the cables get thick and inflexible.