Maybe it's not just transistors they're hoping to gain from this.
I think it's more like building a brain from organic matter that's the real boon. Sooner or later we'll be discarding silicon and extracting neurons from mice just to watch YouTube IX in space with our Tesla corvette cruisers and our alien barmaids serving us Soylent Green in a martini glass!
Only time will tell if I am in fact right. I'm counting on being more right than the guys who have dedicated staff who routinely shell into their servers.
I suppose we'll see if companies with sysadmins have more breaches than the guys who run their own ops using container orchestration etc. I think I'd go even odds $1k that over the next five years, most large scale data breaches will be at organizations where sys admins run the majority of ops.
There's a whole new category of errors you can make (making your bucket open, etc.) with cloud providers but the tooling has better defaults.
I guess you prove a point here: you trust that the deployment of your GKE module allows you to be safe, so your investment vs risk trade seems to satisfy you. But you, yourself, cannot even predict how insecure you are at the moment due to the complexity of the software solutions you are using.
> I suppose we'll see if companies with sysadmins have more breaches than the guys who run their own ops using container orchestration etc.
Oh, I do agree, at least with the current state of sysadmins out there.
But the problem is that you loose control of the integrity of your system once you reach a point where software complexity becomes your security entry point.
If you are sure the containers you will be using are secure, have sane defaults, are up to date, etc, then fine, good job! I just don't trust that most people will be able to reassure me that. And please keep in mind that in your case, the target is not your container platform, the target would be the containers in that platform, and the services they run.
No one can really predict their security accurately.
Say you maintain a bare-metal server in a data center that your company controls.
How much do you know about its physical security? The protocols for admitting new staff? Do you rely on your company’s physical security team and HR? Are any of those functions contracted externally, even partially?
How much do you know about the network security? Do you rely on a networking team? Is any of their work contracted externally? What about the link to the outside world?
How much do you know about the sourcing of the physical hardware?
How much of the source have you audited? How about firmware source?
GKE obviously introduces new factors and vectors, but it also simplifies many of these and adds elements of herd immunity. And it’s also the same as the rest: your system was built by many people, it will be used by many people, and it will be maintained by many people. You can spend all of your time verifying every link, or you can help them do something in the world.
You're absolutely right about not being able to predict the security. But, to be honest, I doubt people genuinely do that in a scientific manner.
And yes, I do expect the failure point to be my containers, not the container orch platform. The container orch platform allows me to use containers, though, and the fact that containers aren't append-only the way that long-running machines run by sysadmins are gives me a head start out of the gate.
It would be much easier for people to disregard the customer and not complete sales in a big company like that though. It's not only more likely, it ONLY happens with them.
A small business would never have a company that delivers be that disappointing and lazy, especially after complaints to their customer service.
Or even lack any sort of concern they lost a sale... Disappointing!
What Linus is really saying is that the way Skarupke measured the spinlock being 'bad' is wrong. Skarupke tried to measure it in C, but you can never be sure if you're not being scheduled by anything else.
Skarupke inaccurately defined this as 'mutex vs. spinlock' and an ongoing debate surrounding this as they are comparable, when in no way are they comparable as in userland you simply cannot use spinlocks.
The Windows scheduler apparently doesn't do this, and handles spinlocks better; whatever that means. But the way it works is that spinlocks should work poorly if you run them poorly. Full manual-control of when running a spinlock in userland, you will be scheduled by other things, and you should know that.
That's what Linux is really about. The ability to do something and not have the system "better-ize" it like Windows does by doing some black magic and running an unknown process alongside your spinlock to make it run better.
A spinlock run in userland SHOULD be scheduled by other things, as Linus says. As Linus implemented in the kernel.
Man I really hate all the crap websites like this put on their page these days. What's wrong with reading the article as the first thing you see? Scroll-throughs and clickables and cookies oh my.
It's just a matter of what people are interested in, and having an attitude that clearly shows you're not interested in that topic, will draw everyone who's not interested in that topic to follow you. That's why trolling is so popular.
The only thing I like about Alexa is when the servers go down and they're no logner supported in 10 years, people will be stuck holding-the-bag like Betamax and Laser Disc holdouts.
