You know that little screen they put in the back of the seats? Do you think they're stupid enough to cable that into the engine management?

The air-phones? Do you think they're stupid enough to just tie that into the cockpit comms?

When you're talking life-dependent systems (which pretty much no-one here will ever have to deal with and certify, which is why all your electronics ALL say that it's not to be used in life-support devices etc.) like airbag deployment and plane avionics, it's heavily regulated, heavily specified, heavily tested and heavily scrutinised. Rarely does a aircraft system specified on the "jumbo jet" level do anything more than exactly what it's designed to do. Plane crashes are caused by outside influences, human input overriding the computer and by DESIGN decisions, not software failure because someone forgot to renew the licence of two DHCP servers fought over who assigned IP's to the engines.

It's an entirely different class of system that you want to hope that you never have to deal with. That's WHY large planes cost HUNDREDS of millions of dollars and you have to train for decades to be allowed near the switches - even if you're servicing them.

And, no, VLAN's would never operate in a system like that and if they did they'd be proven-safe mathematically and, hell, even my cheap commodity switches only respond to management requests on the management VLAN and no other.

They is why the guy responding is so clear on this. It's just not done. Ever. If you change a cable, or a panel, or redesign a bit of hatchway, or push out a software upgrade for a commercial airliner, it takes hundreds of people checking it, re-certification of the end-result, testing and all sorts.

At the very least, I'd expect a VLAN.

In actuality, I'd expect disparate, unconnected systems possibly even running in separated VLANs and subnets with IPS on the avionics controls JUST IN CASE.

Given that avionics are used to dealing with highly technological and highly critical systems, I think I could trust them to not mess it up. Especially if it in any way could even theoretically allow a possibility for an attacker to affect a flight path.

Airport security, the guy loading my luggage, or the guest wifi in the lounge? Yeah, separate problem with trust in question. But on-board wifi? I'd be damned if you could send a single packet from the wifi to the avionics even in theory.

I have never ticked that box.

Yet my servers have it on.

I'm not saying you're lying, but something, somewhere turned that on and it wasn't me.

Don't Intel models just fail without warning and die on you?

Your turn.

It's fun this "let's pick a random complaint against a manufacturer based on one affected product over many years out of dozens that work just fine".

OSI layering model?

The kernel shouldn't be peering into packets for data. It should (just/only) deal with the TCP packet information (and in a strictly confined way so you don't get things like the age-old flag attacks on TCP packets) and route accordingly.

It shouldn't ever be peering down into the HTTP packet itself and acting upon it as the attack surface is SO MUCH larger on a complicated application protocol.

P.S. What happens if SPDY becomes a standard? How does Microsoft migrate to HTTP/2 etc.? We're talking a KERNEL upgrade for an ever-evolving protocol, and that's just stupid.

But it's a good way to obsolete old OS, no doubt. Sorry, but Server 2008 can't handle HTTP/2 so we're just abandoning it - unless of course you want to turn off kernel-level IIS and run some dog-slow configuration, etc.

Putting something into the kernel just because it could mean less context switches in a particular application is a poor excuse and just shows bad respect for kernel-space.

Having it on by default is suicide.

And the problem is - that's a well-documented problem with other web servers historically and quite simple bounds-checking at fault there.

Seriously,MS, audit your damn basics occasionally.

I always shudder when I think of the MS software operating on the frontline of a businesses Internet connection.

Internet-facing service running as SYSTEM.

"Think of them as a small sensor package combined with a data logger and some basic smartphone features"

Like... the smartphone that's in my pocket.

The use case is in combination with a smartphone, which it duplicates the features of, or in replacement for a smartphone, which we pretty much all have anyway.

I wear a cheap, waterproof, digital, rubberised, lasts-forever watch that costs an absolute pittance. It shows time and date on the front screen, which is my biggest buying point of them.

It gets in the way whenever I'm digging into a PC, so I take it off.

My ex and my girlfriend tried, when they first met me, to buy me "nice" watches as expensive presents. I never wore either, but I did at least explain why.

Sorry, a fancy watch is an old status-symbol. And whenever I do forget my watch, I just use my phone. I'd be a million times more lost without my phone than without my watch. Why I'd want my watch to talk to my phone, I can't fathom.

There are fancy microwaves and ovens galore, with all kinds of flashiness on them.

I buy the one with the lowest number of dials and without any electronics, if at all possible.

Microwave: One dial power, other dial time.
Oven: One dial for each component for temperature. One dial for On/Off/Lights/etc.

I know IoT is "the big thing" this week, but I can't see what advantage I gain. I still have to have the ingredients, I have to go through a check-in /check-out process for every ingredient, I have to buy expensive appliances and hook them all up to the Internet somehow (even on wireless, they're just sucking up my wireless bandwidth), and then I have to find the app recipe, press lots of buttons and - hopefully - it'll put the oven on 220 degrees as specified in the recipe.

Or I could just turn the dial to 220 as I read the recipe. And just because something is in the fridge doesn't mean that I want to use it, so I end up using up the last of the butter that I need for the NEXT recipe I was going to do, because the fridge told me I had enough, etc.

There are some things in life which shouldn't be over-complicated and, if you are bothering to cook from ingredients, enjoy doing so. Don't let the app rule the experience.

And it will all go wrong that day you press "Cook" on the train on the way home and the oven sets fire to that turkey you forgot you left in there last night and you come home to a pile of ashes.

Some things technology can benefit, and it's usually the stuff that's NOT lauded about as features until we're all already using them that way (e.g. SMS). The "big name features" tend to be gimmicks and fads.

Honestly, I don't WANT to manage my kitchen from an electronic device. If I don't want to bother to cook myself, I'll get takeaway or someone to do it for me. The day I have to wire the kitchen for Internet will remind me of the day I was required to install a specific driver to get a monitor to display things... I'll be reeling in horror and desperately hoping technology will backtrack before I'm forced to catch up.

And this is from a guy with RFID entry to his side-gate, dashcams and GPS-tracker in his car, etc. ffs.

Don't try to survive a fire. Your data won't. And if it does, you probably won't be allowed near it for a long time, and others might well come along and try to pillage things from the ashes if you live anywhere populated.

Avoid one fire/disaster from affecting your data completely instead.

I swap a disk with my brother every time we meet. If you didn't trust them not to read it (then why are you relying on them to store it?), you could just encrypt it.

Problem solved.

Hell, just rent a storage box somewhere and put an encrypted set of backups into it once every so often.

Though the chance of you surviving a fire is pretty low, the chances of two storage locations having simultaneous disasters such that you can't retrieve the second in time when the first has gone down, is even more miniscule. The more storage locations you add, the tinier the chances of absolute loss are.

It's a RAID. Think of it as a family-and-friends RAID if you must. And ensuring the chances of X simultaneous failures is so low that it's completely improbably is a damn sight better than trying to make a single fireproof disk.

Why does it need to be secret?

All you need is an integrity check, and the packages are all signed with the key which is included in the initial distro image (which is itself signed, available over HTTPS and has publicly published checksums).

Encryption is not necessary here. To believe it is is to completely misunderstand the purpose of encryption.

Agreed.

Now consider the average casino game, however, where up to seven packs are shuffled together.

The game rules determine the actual complexity, yes, but the point was that complexity is an inherently difficult and counter-intuitive thing to estimate, let alone calculate.

A simple pack of cards holds so many possibilities. And chess is approximately that complex (give or take a few orders of magnitude).

How often do you edit multiple document without closing the word-processor in-between or loading up other application?

Because the user that logs in, runs Word, Excel, etc. and then doesn't close any of them until they shut down is a rare beast.

And let's not even get into the swap usage of doing something like that.

Disk performance affects everything you do on a modern machine, which is why SSD's are such a boon to any desktop. Hell, even things like event logs etc. are CONSTANTLY writing to disk in the background, even if the writes are cached.

And I think you'll find that the first thing that a lot of modern word-processors do is make a temporary disk copy of your document when you first open it, so you can edit without disturbing the original. That's how it's able to "recover" your unsaved work.

Disk access is a critical part. Not every single application will need it 100% of the time, but when disk access hits as the bottleneck, you will know about it.

I'm seriously considering scrapping planned RAM/CPU upgrades at my workplace this year and just dropping in cheap SSD's as they'll make TWICE the difference that even a bit more RAM would to the average desktop user's experience.

Although the opening may seem like that, the complexity of chess is such that it's unlikely that every board position has been played.

However, this is incredibly counter-intuitive because of the numbers involved.

Do you know how many combinations there are of a standard 52-card pack of cards? 52! (factorial) = 80658175170943878571660636856403766975289505440883277824000000000000.

It would take - on average - billions of years of billions of people each shuffling billions of deck a second to end up with the exact same deck twice.

Chess's complexity provides slightly less more possible states than that but potentially much larger (over twice as complex, so billions of billions of billions of billions of....) actual viable game trees. However, Go's complexity is greater even on a 9x9 board. On the standard 19x19 board it's UNBELIEVABLY more complex.

Feudal's complexity doesn't even come close.