The concern now is that Google has all the power. It's not that they are particularly malicious (as Microsoft proveably was), but rather when one company controls everything, they can get apathetic and make bad design decisions. Ideally, there would be three or four major browsers, all competing.
That is why I lament the loss of Edge, not because I liked it (or Microsoft) at all.
The advantage of Google Translate for Japanese is: its handwriting input method is perfect. I can write the character incorrectly and a lot of times it will still figure out what I meant. That's why I keep coming back to it, even with the mediocre translation.
When you read something translated from Japanese, where gender isn't always specified in the sentence, Google translate will alternate between masculine and feminine while referring to the same individual.
Ever since the "skeuomorphic design revolution" at Apple, where they got rid of all their skeuomorphic designs, Apple has no longer been the one to copy in UI designs (and even their hardware ideas are falling flat).
When you say "never" that's a whole different class of assertion, though. A lot will happen in the next thousand years, hard to predict. Maybe if you change the way you phrase it.....
The human costs quite a lot for anything more than sporadic trips. If you could automate your commute every day, that would be something (and trains aren't the same for a lot of reasons).
It pains me to use Kubernetes on AWS because you are essentially using a VM in a VM, and if you want you can set up your own images on AWS, too. If you can't write a decent install script, using Kubernetes is not going to help you.
The only benefit I see to using Kubernetes is that it makes it easier to port from one cloud server to another, if you need to. Because it's becoming the standard that everyone supports.
BeyondCorp uses the paradigm "deploy everything on the public internet." You can only use that approach if you can trust all the software you deploy. If you need to use libraries created elsewhere (like Kubernetes at Google), and there is a good chance it is insecure, then having a firewall will give you an extra layer of security. It's not perfect but better.
Was this whole scheme dreamed up because of dependency hell?
It's because people don't know how to write install scripts anymore. We've been doing it for decades now, and it's easier than ever, but people think they can solve their problems by using a VM in a VM. They can't: if their installation process is garbage and complex, adding another layer of complexity will not help things.
The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference. Sysadmins who care about this use sudo to limit and log interactions.
Except snowden was a system administrator and he did not use his own access to exfiltrate the documents, he used 'borrowed' credentials from people whose computers he was fixing.
This sort of thing is why you can't completely stop internal threats. There are too many avenues of attack, and you can't shut them all without really slowing down things inside the business and causing problems.
So, yes, anyone who knows about this hole can take command of your Kubernetes cluster.
My understanding is this is only exploitable by people who have access to Kubernetes anyway. Your firewall should not be routing any traffic from the general internet to the Kubernetes api. So this is a good opportunity to check to make sure your firewall is configured correctly, but if you are vulnerable to outside threats, the problems run deeper than a single vuln you'll want to look seriously at your processes and make sure they are security focused. (Or make them more security focused than they are now).
Another scenario: everyone who knows how to write kernel code at Microsoft leaves. Then the remaining people try to add features, but can't. They tell their managers, "The code is too awful. We need to rewrite it." Again, they are too incompetent to rewrite it, so after messing up for a year, they say, "It's too hard. The only option left is to write it on top of Linux." Which turns out to be even harder (resulting in backwards compatibility bugs everywhere), but the UI looks decent, so they release it. Customers complain so much they finally end up open-sourcing windows 7 and discontinuing all new updates to Windows.
I actually took a crack at developing such a beast back in the day. But it was both too early and too late
How was it as an actual (or potential) product? Do you have any insight as to what might work and what doesn't? (not worrying about market acceptance, that is)
I don't understand where people get this. It's great as simple spreadsheet as well as many other software and then it falls apart when people try to use it as anything else. I used to spend so much time trying to fix errors in peoples spreadsheets where they thought that their budgets worked but when entering the numbers in a true accounting system the numbers didn't work. Seldom were they balanced.
ok, so what spreadsheet program currently available is a replacement that doesn't have that problem?
So maybe something like, Microsoft decides to make a Linux kernel driver compatibility layer, then a decade later says, "Well, no one's using our traditional driver system now, might as well delete it?" Then one day they wake up and Windows has become the Microsoft version of OSX?
IMO the ideal spreadhseet would be a GUI frontend to an APL interpreter. APL already has the column based processing and a good functional foundation that solves the same problem as Excel, but with a much more elegant approach. Scripting would have been perfectly integrated.
The biggest piece missing from LibreOffice Calc is a visualBasic interpreter. It pains me to say it, but a lot of people want it, and it's necessary for interoperability.
Slashdot Mirror
The concern now is that Google has all the power. It's not that they are particularly malicious (as Microsoft proveably was), but rather when one company controls everything, they can get apathetic and make bad design decisions. Ideally, there would be three or four major browsers, all competing.
That is why I lament the loss of Edge, not because I liked it (or Microsoft) at all.
The advantage of Google Translate for Japanese is: its handwriting input method is perfect. I can write the character incorrectly and a lot of times it will still figure out what I meant. That's why I keep coming back to it, even with the mediocre translation.
When you read something translated from Japanese, where gender isn't always specified in the sentence, Google translate will alternate between masculine and feminine while referring to the same individual.
Ever since the "skeuomorphic design revolution" at Apple, where they got rid of all their skeuomorphic designs, Apple has no longer been the one to copy in UI designs (and even their hardware ideas are falling flat).
Second, how has telecommuting been factored into this analysis.
tbh these kinds of jobs are hard to find.
You mean the self-driving taxi service that has a safety driver making sure it doesn't mess up?
When you say "never" that's a whole different class of assertion, though. A lot will happen in the next thousand years, hard to predict. Maybe if you change the way you phrase it.....
Five years.
The human costs quite a lot for anything more than sporadic trips. If you could automate your commute every day, that would be something (and trains aren't the same for a lot of reasons).
We're also approaching the year when we were promised self-driving cars. 2018, or ~2017, or 2018. It's going to be a few years of failed predictions.
It pains me to use Kubernetes on AWS because you are essentially using a VM in a VM, and if you want you can set up your own images on AWS, too. If you can't write a decent install script, using Kubernetes is not going to help you.
The only benefit I see to using Kubernetes is that it makes it easier to port from one cloud server to another, if you need to. Because it's becoming the standard that everyone supports.
1. Firewalls don't route anything. Firewalls block or allow.
Even if they only forward packets to the next hop, they are still routing.
BeyondCorp uses the paradigm "deploy everything on the public internet." You can only use that approach if you can trust all the software you deploy. If you need to use libraries created elsewhere (like Kubernetes at Google), and there is a good chance it is insecure, then having a firewall will give you an extra layer of security. It's not perfect but better.
Was this whole scheme dreamed up because of dependency hell?
It's because people don't know how to write install scripts anymore. We've been doing it for decades now, and it's easier than ever, but people think they can solve their problems by using a VM in a VM. They can't: if their installation process is garbage and complex, adding another layer of complexity will not help things.
The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference. Sysadmins who care about this use sudo to limit and log interactions.
Well, I do not totally agree with that.
I would be happy to hear why you don't agree, please explain.
Except snowden was a system administrator and he did not use his own access to exfiltrate the documents, he used 'borrowed' credentials from people whose computers he was fixing.
This sort of thing is why you can't completely stop internal threats. There are too many avenues of attack, and you can't shut them all without really slowing down things inside the business and causing problems.
This is one of the unsolved problems of security.
Because no one has ever had employees who were internal threats or had attackers gain access to a company's internal network from the outside?
You can't stop that.
So, yes, anyone who knows about this hole can take command of your Kubernetes cluster.
My understanding is this is only exploitable by people who have access to Kubernetes anyway. Your firewall should not be routing any traffic from the general internet to the Kubernetes api. So this is a good opportunity to check to make sure your firewall is configured correctly, but if you are vulnerable to outside threats, the problems run deeper than a single vuln you'll want to look seriously at your processes and make sure they are security focused. (Or make them more security focused than they are now).
Another scenario: everyone who knows how to write kernel code at Microsoft leaves. Then the remaining people try to add features, but can't. They tell their managers, "The code is too awful. We need to rewrite it." Again, they are too incompetent to rewrite it, so after messing up for a year, they say, "It's too hard. The only option left is to write it on top of Linux." Which turns out to be even harder (resulting in backwards compatibility bugs everywhere), but the UI looks decent, so they release it. Customers complain so much they finally end up open-sourcing windows 7 and discontinuing all new updates to Windows.
(That is more or less what happened to FoxPro).
I actually took a crack at developing such a beast back in the day. But it was both too early and too late
How was it as an actual (or potential) product? Do you have any insight as to what might work and what doesn't? (not worrying about market acceptance, that is)
I don't understand where people get this. It's great as simple spreadsheet as well as many other software and then it falls apart when people try to use it as anything else. I used to spend so much time trying to fix errors in peoples spreadsheets where they thought that their budgets worked but when entering the numbers in a true accounting system the numbers didn't work. Seldom were they balanced.
ok, so what spreadsheet program currently available is a replacement that doesn't have that problem?
So maybe something like, Microsoft decides to make a Linux kernel driver compatibility layer, then a decade later says, "Well, no one's using our traditional driver system now, might as well delete it?" Then one day they wake up and Windows has become the Microsoft version of OSX?
IMO the ideal spreadhseet would be a GUI frontend to an APL interpreter. APL already has the column based processing and a good functional foundation that solves the same problem as Excel, but with a much more elegant approach. Scripting would have been perfectly integrated.
The biggest piece missing from LibreOffice Calc is a visualBasic interpreter. It pains me to say it, but a lot of people want it, and it's necessary for interoperability.
Why are you sticking to their software? There are so many others around.
There's no real replacement for Excel.