I live in another Bay Area city that recently imposed a ban on natural gas for all new construction, whether residential or commercial. In addition, the ban forces existing homeowners to install all electric appliances if the cumulative cost of remodels in a 3-year window is over $250,000.
I find this idea absolutely bonkers when our electric infrastructure is terrible. The aerial power lines are subject to trees or large branches falling over and causing large power outages. Just this winter we had 4 major power outages, lasting from few hours to multiple days. Not only my city, the whole Silicon Valley had no power! The place supposedly having the brightest minds, trillion dollar companies, and the most advanced technology in the world! Not only we didn't have electricity, we had no Internet and cellular phones either. Absolutely insane!
Yeah, I do have solar power and battery backup, but during the winter relying on them does not always work. Luckily I had enough solar and battery generated electricity to power my natural gas furnace so I can have my house heated. The fan on the furnace uses 700W when pushing air, far less than electric heaters that would kill my Tesla batteries in a few short hours.
Why would anyone rely on a single source of energy, especially one that's so unreliable? Until we fix the electric grid, we shouldn't force everybody to switch to it.
As far as an uninstall procedure is concerned, the expectations of a MacOS X user do not involve looking up instructions on a web site. The user should be able to quite the app, drag it to the Trash and clean it.
In addition the instructions you posted on the web site do not work. There are two running processes shown in Activity Monitor: a KiteHelper and a KiteEngine. Killing them both does not work, they are resurrected by some process.
I had to manually rm -rf Kite.app, and reboot the machine to get rid of the pesky KiteHelper and KiteEngine processes. Totally unacceptable "uninstall" procedure.
1. On MacOS X it's quite impossible to kill the helper and engine processes, so you can remove Kite.app. Something is restarting them automatically, which is really frustrating.
2. It's completely unacceptable to upload code to the cloud.
As I said, it's not only kubectl that has the problem. None of the services implemented by Kubernetes are HA: kubelet, proxy, and the scheduler. For a robust deployment you need these replicated.
Using DNS might work for the K8s services, but at least in version 1.2, SkyDNS was an add-on to Kubernetes. This should really be part of the deployed K8s services. Hopefully newer versions fixed that, I didn't check.
Preferably, the base K8s services implement HA natively. Deploying a separate load balancer is just a workaround around the problem.
FYI Google's Borg internal services implement HA natively. Seems to me the Kubernetes team just wanted to build something quick, and never got around to doing the right thing. But I think it's about time they do it.
I built Jollyturns (https://jollyturns.com) which has a fairly large server-side component. Before starting the work on Jollyturns I worked at Google (I left in 2010) on a variety of infrastructure projects, where I got to use first hand Borg and all the other services running on it.
When I started more than 5 years ago few of the options mentioned in the article were available, so I just used Xen running on bare metal. I just wanted to get things done as opposed to forever experimenting with infrastructure. Not to mention the load was inexistent, so everything was easy to manage.
After I launched the mobile app, I decided to spend some time on the infrastructure. 2 years ago I experimented with Marathon, which was originally developed at Twitter, probably by a bunch of former Google employees. The reason is Marathon felt very much like Borg: you could see the jobs you launched in a pretty nice Web interface, including their log files, resource utilization and so on. Deploying it on bare metal machines however was an exercise in frustration since Marathon relied heavily on Apache Mesos. For a former Googler, Mesos had some weird terminology and was truly difficult to understand what the heck was going on. Running Marathon on top of it had major challenges: when long-running services failed you could not figure out why things were not working. So after about 2 weeks I gave up on it, and went back to manually managed Xen VMs.
Around the same time I spent few days with Docker Swarm. If you're familiar with Borg/Kubernetes, Swarm is very different from it since - at least when it started, you had to allocate services to machines by hand. I wrote it off quickly since allocating dockerized services on physical machines was not my idea of cluster management.
Last year I switched to Kubernetes (version 1.2) since it's the closest to what I expect from a cluster management system. The version I've been using in production has a lot of issues: high availability (HA) for its components is almost non-existent. I had to setup Kube in such a way that its components have some resemblance of HA. In the default configuration, Kubernetes installs its control components on a single machine. If that machine fails or is rebooted your entire cluster disappears.
Even with all these issues, Kubernetes solves a lot of problems for you. The flannel networking infrastructure greatly simplifies the deployment of docker containers, since you don't need to worry about routing traffic between your containers.
Don't be fooled by the title of the bug report, the same component used in kubectl to implement HA could be used inside Kube' servers for the same reason. I guess these days the Google engineers working on Kubernetes have no real experience deploying large services on Borg inside Google. Such a pity!
I have the same problem: I'm using various C2000-based Supermicro boxes running pfSense. The most cost-effective DIY, rack mountable solution for a pfSense box was until now SYS-5018A-FTN4. Do you know if Supermicro issued a technical bulletin about this box?
For Jollyturns (https://jollyturns.com) I'd like to overlay my users' ski tracks data, as well as various ski resort objects (lifts, runs etc) on a 3D Earth, to be displayed inside a browser.
Why would I use Melown instead of CesiumJS (https://cesiumjs.org/)? Especially since the latter appears to be free?
Depending on where you are, cell phone coverage could be between great to totally nonexistent. The mobile apps are built to be able to handle intermittent cell phone coverage. You can see yourself on a ski resort's map at all times, as well as see your own statistics. When you get in a cell phone coverage area the app sends the latest information to my servers, and receives information about your friends. You might get some stale information, but that's still better than nothing. And of course, if you're in a ski resort with great cell phone coverage, your friends location is fresh most of the time.
I built Jollyturns (https://jollyturns.com), a ski and snowboarding oriented business. I currently have a fairly extensive web site, and two mobile apps, on iOS and Android. I started with the iOS mobile app, I wanted something to show me on a ski resort's map where my friends are, and keep track of my skiing statistics.
I tried finding a partner to work with, but that's pretty much impossible in Silicon Valley where I live. Most good engineers want to work for one of the glamorous companies in the Valley. Oh well...
I've been working on Jollyturns for the past 5 years. It's been a lot of work, but I do it at my own pace since I still want to enjoy myself. The experience is unique. I write all the software myself, and hired few people to help map the ski resorts. I built a bunch of custom tools for the mapping work, so people can map the location of lifts, ski runs, restaurants inside a ski resort. I ended up having mapped all the ski resorts in the world, about 2700 of them.
Being by yourself, you need to be prepared to be a full-stack engineer. I built my own Supermicro servers, and host them in a colocation facility. I found that if you're in it for a long time it's cheaper this way. I run Kubernetes for cluster management, Postgres with PostGIS for database, Redis for caching, nginx for web proxy. Server side is written in a mixture of Python and C++. Web frontend is AngularJS (JavaScript). For iOS I write C, C++ and Objective-C. On Android I use Java.
Writing the code is the easy part. I found marketing to be the hardest. You need to find a way to make the world know what you built, and that's hard!
When I worked at Google I built a Blaze extension to be able to build Android apps. It worked really well, though I'm not sure how well it was maintained after I left in 2010. Internally at Google, Blaze was extremely customizable, and I hope Bazel too, so one can easily add support for building iOS apps etc.
EDIT #1: I see support for building Objective-C apps is already present in Bazel.
EDIT #2: Bazel uses Skylark, a Python-like language, which could be used to implement all sorts of extensions, including the one I was referring to.
The whole series of videos about various astronomic subjects is extremely well done. The music and narration of Dennis Overbye remind me of the old Carl Sagan movies, this time made for the newer generation, with a shorter attention span.
The account merging part is something your server should handle.
In my app I maintain a users table that has columns (google_account_id, facebook_account_id, twitter_account_id, etc), pointing to individual rows in a separate accounts tables (e.g. google_accounts, facebook_accounts, twitter_accounts etc). When a user adds an existing account_id, I take care of merging the two different users rows, populating appropriately the account_id in one of the rows, then deleting the extraneous users row. I also migrate the existing data referring to the to-be-deleted user row to the one I plan on keeping.
I find this idea absolutely bonkers when our electric infrastructure is terrible. The aerial power lines are subject to trees or large branches falling over and causing large power outages. Just this winter we had 4 major power outages, lasting from few hours to multiple days. Not only my city, the whole Silicon Valley had no power! The place supposedly having the brightest minds, trillion dollar companies, and the most advanced technology in the world! Not only we didn't have electricity, we had no Internet and cellular phones either. Absolutely insane!
Yeah, I do have solar power and battery backup, but during the winter relying on them does not always work. Luckily I had enough solar and battery generated electricity to power my natural gas furnace so I can have my house heated. The fan on the furnace uses 700W when pushing air, far less than electric heaters that would kill my Tesla batteries in a few short hours.
Why would anyone rely on a single source of energy, especially one that's so unreliable? Until we fix the electric grid, we shouldn't force everybody to switch to it.