It is pretty common knowledge why they did this. Original plans for the BART had it traveling over the Golden Gate Bridge into Marin County. Due to high winds across the bridge, they wanted a wider gauge to prevent trains from tipping.
With strange, custom-construction-requiring stuff like this, I tend to wonder how much of it would be explained by "help self/a buddy get rich". It's practically guaranteeing that there's going to be a single company supporting it for all time, which is a potentially-extremely-lucrative business deal.
If that's the case, obfuscating the reasons for these decisions is a rational move.
It's a bit cynical to say this but running HSR on an incompatible network protects it against future politicians who may seek to sabotage it by merging networks.
This sounds similar to the reason why the Glasgow Subway runs on a 4' (1219mm) gauge: to stop it from being taken over by the numerous (at the time privately owned) railways around the city which were all standard gauge.
If you're seriously worried about the NSA logging things - I'd be more concerned with the device you carry on your person every day, with a microphone, two cameras, a GPS device, 24 hour battery, and probably 10x the processing power of the Alexa.
It seriously is no worse than OK Google or Siri and you should seriously be more worried about your cell phone.
The device I carry day-to-day needs to be specifically compromised. With voice assistants using an internet service, only that internet service needs to be compromised. For bulk surveilance, I think it's far more likely for the Echo servers to be attacked than my smartphone.
I'm starting to get tired of this. I really don't understand this sentiment on a forum called "hacker news" of all places. You don't have to trust anyones word about it not listening 24/7. It is t r i v i a l to look at the data from the echo transiting across the network. You can see that the traffic spikes after you say alexia as it sends the audio data out.
How? If you say "by analysing the amount of data it transmits when not in use", then not really - they could record it locally and then sneak it alongside a normal request.
I don't know how Echo's update, but they potentially could also sneak in an update that does listen 24/7, then a couple days later push an update that turns that off.
What does this mean, "specifically compromised"? You bought it compromised if we are being congruent with these sorts of accusations or precautions. If you assume the Echo is always listening, you should also assume that Apple, Google, and Facebook are also always listening... and, in fact, I recall earlier this year a quite vast conspiracy that Facebook did exactly that[0]. This was denied by Facebook, for the record – or do you not believe them?
The questions I ask are designed to help me learn about the actual environment I'd potentially be walking in to. Understanding the technical parts are easy, grok'ing the environment is a bit tougher. You're making a decision for potentially years after only a few hours of input.
1. If there is one thing you could get the company to stop doing today, what is it?
2. On that note you're in tech, there are numerous opportunities everywhere, what are the top three things that keep you here?
3. What's the job you want after this one? Why? How is the company helping you get there?
4. What do you and your manager discuss in your 1:1s? What do you and your reports discuss in your 1:1s?
5. Name a mistake you made in the past year. What did you learn from it? How did your team and/or manager respond?
These questions all really resonate with me. If I were to receive these questions as an interviewer, it would speak to someone who has been around the block a few times (which I would count as a positive).
Someone once said that the public cloud was never about virtualization but rather automation. I would contend that the container revolution we're going through now isn't really about containers but ultimately distributed system platforms. And if it changes the way many have traditionally approached problems great!
My main point is that we're really just at the beginning of all of this. I'm not picking on Docker (I'm actually embracing containers) but rather pointing out that many of these next gen solutions are only tackling the basic use cases right now. While I'm excited there is so much more work left to be done. Implementing many of these solutions still requires a bunch of engineering effort and I'd like to see more turnkey solutions. The developer end is definitely getting easier and more productive but the operational end is getting more complex and still not solving some use cases everyone has. How many different ways can different companies implement HA MySQL for example?!
There are tons of other platforms out there that have recognized and solved many of this class of problems for years but the Cloud and microservices are actually starting to make this worse as adoption skyrockets. Platforms are not really a new thing, we went through this with JVM Platforms a ~decade ago, Heroku style PaaS ~five years ago, and now containers + cloud today.
Ha you weren't kidding about the number of HA MySQL drop-in engine replacements out there, damn. At least most people follow the ANSI-SQL standard, which is something.
I'm not being snarky, but what are the use-cases that everyone have? I'd argue authentication and authorization would be one of the few things, and it was already solved with JSR 196 like 15 years ago. It worked, had a well defined spec, and most importantly it had interop with PAM on UNIX, Kerberos, LDAP, raw db's, mixed mode, you name it. Everyone complained it was too enterprisey and no one used it, so they re-invented the wheel in the early 00s with Rails and Devise and Authlogic and a billion other non-standards. Transactions? Persistence? Java's spec took care of that too, and fairly rigorously. So I'm with 100% with you on this being a solved problem.
We're making gradual progress (i.e., the option to develop in a language where the correctness of our code can be formally verified thanks to more readily available, mathematically sound type-systems) but like any society there are trends, and where there are trends you'll have the recurrence of many old things (Interpol ripping off Joy Division) and the invention of a few new things (where are often the composition of two older ideas, or the implementation of a new idea which wasn't computationally feasible previously but now is, or a concept from another industry like signal analysis or three-phase road traffic theory applied to our code-monkey'ing domain).
RE: Overall progress - Microsoft is doing some fantastic things in Powershell, effectively taking concepts like package management, man pages, and the shell, extracting the best elements from each of those, and implementing them in a consistent manner. No more choosing between systemd or init.d or other holy wars. If you want to do it differently, you effectively have a standardized interface to write your new implementation against within most of the platform. Don't like ASP.NET's templating system? No problem, it's all open source, and you can swap your own in, but it's all modular so nothing will break, and your co-workers can continue working in the traditional Razor templating.
We're undertaking a similar project and the latency is almost negligible. In fact the latency is lower bridging between classic and vpc in the same availability zone than between two classic availability zones.
Truckers don't like to change gears. It's much more efficient for them to stay in a lower gear and coast at a consistent speed than it is to constantly change gears and brake.
