The output is Allow or Deny. To be Allowed, you need an policy that includes an Allow statement. If you don't have one, then the result is implicit Deny by default. Also, any explicit Deny wins over all Allows. Disclosure: I work on AWS IAM.
That's not the way to look at the numbers. First, you'd want to talk about whether the results are statistically significant. Second, when dealing with a fatal disease, people are pretty happy if their odds of survival go up by a few %.
You should stop presenting your opinions such as “Cancer only affects people who generally already have other problems” and “they will probably get something else anyway” as facts.
Imagine a reader who is not one of your lucky “most” majority. Imagine a reader whose cancer was not caused by the bad lifestyle decisions that you listed. Put yourself in the position of somebody who undergoes extensive surgery/radiation/chemotherapy and then lives with the side effects of these treatments. Consider what it’s like to live with the fear of recurrence even after such treatment. Then maybe you’ll understand why people might be excited about the potential of this sort of screening.
Here are some examples from my team’s 2019 work: We contributed numerous changes to containerd. We open sourced firecracker-containerd, and we also created a Go SDK that others are using to work with Firecracker. We contributed to Debian and the Debian kernel team. We contributed to Envoy. We collaborated with a number of communities, including Kata Containers, Red Hat’s Clair, and the Open Container Initiative. All of these examples are sustained investments, not one offs.
To clarify, an AWS customer has a shared responsibility to describe the security of their systems including how they use AWS tools, and in this respect Amazon is no different than other AWS customers.
I'm not 100% sure what you mean by utility real-time programs, but yes, this probably is they meant. Nest knows where you live (I don't mean that in a creepy way), and they can help you enroll in what are called "demand response" or "load control" programs in your area. When you enroll, you get an incentive like a bill credit or a free thermostat, and you give the utility permission to turn your AC off for a little while at some point during the summer.
Many of these utility programs actively recruit customers, so chances are (a) you'll get a chance to sign up even if you own a different type of connected (e.g. WiFi) thermostat, and (b) the sign up process won't be hard.
FWIW, the Lux Geo can run on on 24VAC, AA batteries, or micro-USB. I don't know how long the batteries last though.
There are lots of reasons why most fancy thermostats need a lot of power. For example, a fancy screen is hungry, WiFi is an expensive protocol (e.g. as compared to ZWave), etc.. Compare the Lux screen to the Nest, and you'll see at least one reason why they think they can get away with batteries.
In the NYC area, there's http://www.refactory.co/. I used to work with these guys, and they know their stuff.
They argue in favor of both designing and manufacturing locally. A quote from their blog: "If you kind of just prototype something and bring it to China expecting that then thousands of these things can be made easily without understanding the processes and materiality of manufacturing, that is gonna be a big problem for you. What works is when the design process is iterated alongside the manufacturing process."
We build a IoT platform for connected thermostats. Together, our partners have already sold over 100,000 EnergyHub-powered devices, and soon we will be managing 1 million devices.
Our easy-to-use web/mobile apps help people save money by, for example: figuring out the most efficient time to run your heat or AC; using geofencing to turn things down when you're not home; and providing customized tips to help guide your decisions. We also run critical parts of the Smart Grid by linking our thermostat customers to Demand Response programs in the US and Canada.
You will have the opportunity to work on all aspects of the software: web and mobile applications, the distributed back end system including the communication layer to connected thermostats, analytics that drive efficiency, and the tools that we use. We use modern tools, and we're open to trying out new technologies, languages, and ideas.
To apply, please send your resume and a brief note about why you're interested in EnergyHub to josh at energyhub.net.
This doesn't seem like a useful contribution. For example, even though I prefer not to write C on a daily basis, I still use C-based tools all the time.
You will have the opportunity to work on all aspects of our software: predictive analytics, communicating with embedded devices, the back end distributed system, and web and mobile applications.
The ideal candidate:
- Is fluent in a modern programming language (almost any!).
- Knows their way around computers because they like knowing how things work.
- Plays around with embedded systems.
- Has built cool web or mobile applications.
- Has worked on a distributed, fault-tolerant, and scalable system.
As a team, we:
- Like the JVM, but love Python.
- Juggle data using the right tool for the job — SQL, NoSQL, and a mixture of Pandas/SciPy/IPython.
- Scale horizontally.
- Are open to trying out new technologies, languages, and ideas.
EnergyHub is a Brooklyn-based startup located in an old factory near the scenic Gowanus Canal. We provide a cloud-hosted software platform for managing energy use in homes and small businesses. Together, our partners have sold over 100,000 EnergyHub-powered devices, and we will be managing 1 million devices in the next few years.
To apply, send the following to [email protected]:
- Your resumé.
- Why you’re excited to work at EnergyHub.
- Some code. This can take the form of a link to any of your open source projects, your github username, a code sample, or an app you wrote.