Some would even say that faith requires belief without evidence.

No, you misunderstand.

Everything you think is true is something you believe. If someone says, "1+1=2," you say, "Yes, that is true." What you really mean is, "Yes, I believe that to be true." Certainly, things are true or false absent of any belief, but when we're asking about whether or not an individual thinks something is true or false, we're exactly talking about belief. We're not talking about accuracy of scientific or mathematic laws, theories, or models. We're talking about the nature of knowledge, perception, and human understanding.

Think of it this way. For thousands of years humans believed that when they saw a sunrise that the sun had revolved around the earth on a crystal sphere. That's what their knowledge of the universe told them was true, so that is what they believed, and that's what their knowledge told them they saw. That was as true to them as the truth you belive in when your knowledge tells you that the earth is held in orbit by gravity and rotates to bring the sun back into view. The fact that your knowledge might be more accurate or might have more evidence behind it is irrelevant. Your belief that it is true, or belief that it is false, or fundamental misunderstanding of what is truly going on doesn't change what's really going on. Nevertheless, knowing who agrees with your beliefs and therefore agree with what the common knowledge tells us about the universe can be valuable.

You can do the same thing with any scientific model. Consider big bang vs steady state theory. Did you know that, to this day, scientific papers are published in journals relating to the steady state model of the universe? Consider the model of the atom. We've gone from the plum pudding model, to the ring model, to the Bohr model, which is still the most commonly taught model, I believe. None of them really represnt the atom that well, of course, but people still imagine the Bohr model when you say "atom" to them. That's not what an atom actually is or looks like, but that is what people believe.

Pretty sure it was a joke.

Many managers and business owners mistake fault tolerance for disaster recovery (and vice-versa).

Oh, I'm not disputing that. I'm just saying what my experience has been. Every time I've encountered the "osteopathy is bunk" rhetoric, it's invariably from someone outside the US where, I assume, you can't get a medical license as a DO.

Modern osteopathic physicians in the US practice evidence-based medicine and are trained essentially identically to any other medical doctor in the US. DOs and MDs have essentially converged. There are some minor philosophical differences, but that's it. Outside the US, though, I don't think they were ever accepted as practicing physicians.

Part of the issue here is that osteopathy outside the US has much lower credibility. I'm not sure if there's regulations in the US about who can call themselves an osteopath or apply osteopathic treatment, or if osteopathy has a stronger tie to traditional medicine in the US, or exactly what the reason is for the difference.

Because she works at NYU as an assistant vice provost recruiting students. One of her jobs is to go out and find academic talent and bring it to NYU. So her job is to determine what skills are most valuable in an academic sense, which is exactly what NCWIT is talking about with concerns about women in technology.

Whoops. Wrong post. Regardless, my points stand.

I agree.

Regardless of the fact that a computer is piloting the vehicle, there still needs to be an operator/navigator to determine the destination and make other decisions for the vehicle. I like the example given of an elevator. Most elevators today are required to have emergency stops and emergency phones. Operators need to know what to do when there is an emergency inside the vehicle. They need to show they've learned the basic regulations and requirements of operating the vehicle, such as what laws apply, where and when you are and are not allowed to operate the vehicle, basic vehicle safety, what class of vehicle you're allowed to operate, etc. They also need to know how to navigate the vehicle, but without standard interfaces that is fairly complicated. Even if you throw out the bit about siting behind the wheel and pedals, there's still an amount of knowledge you need to have to be able to operate the vehicle in a safe and secure manner. You need a license to own a gun, fish, or camp in a state park because a) shit costs money to maintain, and b) you have to prove you're not too stupid to pass a license test or fill out a license form.

I've said this many times before, but all they've done is just merged major and minor version numbers into a single version. We're really at around Firefox 7 or 8 if they'd kept the old versioning scheme. Somewhere out there there's a branch map that shows they've only done a major branch a handful of times.

Think about normal versioning and updates. You get:
1. Major updates - These are supposed to have major features and UI changes. Major version increment.
2. Minor updates - These are supposed to have minor features and bug fixes. Minor version increment.
3. Security and fast track updates - These just have security fixes or emergency bug fixes. Point version increment.

The question to ask is: what's the difference between 1 and 2? If you're spending a lot of time delaying features or arguing about what needs to be delayed for six months to a year to wait for an official release, then you're spending a lot of time spinning your wheels. You develop a major feature, and can't implement it for a year. Then, a year later after you've forgotten everything, you finally get feedback and bug reports. Now everything you built on top of your new feature also has to be reconsidered, and God forbid you have to do a rollback. So, let's scratch that. When major features get finished, they get released. You get immediate feedback, don't have to learn to ride the horse again to fix them, and feel a lot more free to get stuff done.

However, since there's no longer a distinction between 1 and 2, you can't use different version elements. You can't predict when a release will have a major feature, you don't want to argue about what a major feature is, and you don't want to backslide into the old versioning nomenclature and delaying features needlessly. So, you throw out the major and minor. Now you just have point releases (emergency bugs and security) and version number (everything else). However, also notice that because you can't predict when you'll release a major feature, you can't predict your release schedule. At all. So, instead of constantly hemming and hawing about when to release, you just do it periodically. After X weeks or months, you do a freeze and then a bit later you push dev to test and test to prod.

The drawback is you irritate your users. Consumer users won't really care that much, although many won't understand why your version numbers move so fast. Businesses will get annoyed because they like to standardize on single versions and stick with them for far too long, so maybe you create an "extended support" version which has old style version numbers. In that system, your major version number is whatever arbitrary release you pick, and then some unfortunate soul gets to backport security and emergency fixes. They don't get any of your new features, but they're businesses. They won't want features. They just want functionality and conformity.

There is also a less discussed 3rd option which is called Twitch Turbo which costs the twitch user 8,99 per month gives nothing to the stream your watching, no advertisements and a icon. Most streamers hate the turbo users because they are pretty much paid ad blocking and taking revenue out of the pocket of the streamer. To the defence of those Turbo users they usually get turbo and also buy a subscription to their favourite channel(s).

You have no idea how Turbo works.

Turbo gives 100% fill rate for ads. That is, every time a broadcaster's channel would play an ad, Twitch pays the broadcaster as if the Turbo user had seen an ad. 100% fill rate is essentially unheard of otherwise simply because there aren't enough ads in every region for every quarter.

Well, the class was taught by the Math department, not the Computer Science department. There were no practical applications for any of the material. Math classes always seem to assume your formulae already exist.

And I've never had to do any of those things you mention. All my programming has been with business data originally, and (today) with systems analysis on student information and school finance systems. None of my analyses have had to deal with multidimensional data. While I'm sure you could apply some of those transformations could produce useful results on the systems I work on, nobody has ever asked me for them in the past 10 years.

Really?

I took a semester of linear algebra, too, and it was hands down, full stop the most useless course I took in my entire college career. Like the most useful seeming thing was solutions of groups of linear equations, but I have never been in a situation where I knew or could construct an equation to build into a system. We touched somewhat on linear regressions, but never got far enough into them to do anything useful. Other than that it was a huge amount of fairly basic algebraic geometry.

I'd already completed two semesters of calculus, statistics, relational algebra and a class in formal logic. There was no translation in the program from mathematics to applications in computer science, either, so everything was left so abstract and disconnected from any purpose in reality that it was merely learning the mechanics of solving complex problems without ever beginning to understand how to identify such a problem or what the solution actually meant. Nobody comes up to you and says "here is a matrix that represents a set of linear equations. solve it." and that's all that class did. Where do these equations come from? How do I construct them? How do I know they're related? What does performing these mathematical operations mean? Why is this mathematical solution important? Knowing how to multiply 6 * 7 is fantastic, but if we're talking about 6 as the fourth octet of an IP address, and 7 as the number of chairs in the conference room that are blue, then multiplying 6 * 7 isn't particularly meaningful. It was like taking calculus without physics, or trying to learn SQL without a database to play with, or learn how to write a class without a useful object to represent and useful functions to operate against. It was a complete waste of time.

I assumed it was Jimmy Two Times.

A standard support contract with Microsoft is for them to provide security and bug fixes, not to research any random issue. Your issue sounds like a random issue.

If your situation isn't repeatable on different hardware, then it's probably not a Windows bug and certainly isn't a critical bug. If it's repeatable on hardware from the same vendors, then it's probably a bug with the firmware on one of the two pieces of hardware or poor configuration on your part. If it's repeatable on hardware from different vendors, then it *might* be a Windows issue. Even then it's unlikely, because the install base of Windows is so large that's it's grossly unlikely that the bug you're discovering is a new bug with Microsoft code. The fact that it works with Linux is not particularly relevant because that doesn't mean your hardware isn't incompatible: it just means Linux knows how to work around it or the driver you have on Linux is different or you're doing something really stupid like running custom firmware.

Your problem is exactly why Microsoft wanted $300 to listen to you.

These are telecommunications companies. Sanity doesn't figure in to their business plan.