Well you can't prove a negative, you can only disprove a positive.
In this case there was a (vague) assertion made, so you can try to disprove that.
354 karma · joined November 4, 2013
In this case there was a (vague) assertion made, so you can try to disprove that.
The nice thing about Hue is that their bridge can run completely disconnected from the internet and still respond to RESTful API requests, which means that when Phillips end-of-lifes Hue my bridge will keep working with Home Assistant.
Low power: it should not require much in the way of network traffic or heartbeats so that you could leave the radio mostly off.
Mesh networking: ideally the devices should be able to repeat commands so that they could be low-power and not have to broadcast across entire houses.
Secure: it should have specific ways to join a network that don't require a keyboard on the device.
IoT application focused: the protocol should make it easy to do things like turn a device on/off, set a value or read a value.
Z-Wave and Zigbee do these things (for the most part), while WiFi is sort of hacked to try to maybe accomplish it. For instance, my Z-wave thermostat has been running off the same lithium AA batteries for about a year now, and the battery level is at 77%. I can't imagine a WiFi device being able to achieve that.
I tried this. Turns out to be a bad idea. SSH will walk through each private key and attempt to authenticate with it in order. That means a lot of bad login attempts which in turn leads to getting locked out. SSH public keys are public for a reason.
What attack is this even preventing - that someone will be able to reverse ssh public keys and get the private? A better approach is to generate a unique key per client so that if you lose access to a device you can remove only its public key.
> Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions
So I becoming an Underhanded C Contest judge is the price of admission to using the internet? Can anyone really be expected to do that? Can we blame anyone who gets owned because they didn't?
To that end, while working on the web team we added a Konami code to the QL website that would change the entire site to Comic Sans. I just checked and sadly that Easter Egg got lost in a redesign.
It's hard to justify "Get out of the house" when you've built a nice work spot for yourself. Maybe it's because the audience for this is in an urban environment where it's a 5 minute walk to the coffee shop (as opposed to my suburban 10 minute drive) or maybe it's because I'm cheap and know the coffee at home is cheaper than paying "rent" buy buying coffee.
I'd really be curious to hear other remote workers' experiences with getting out of the house.
Can you point to some empirical evidence to the contrary?
Edit: I had some more thoughts about this, specifically that there is a survivorship bias to legacy code. Not all projects survive, but when they do that code can live a long life of maintenance. If you are involved in the startup world, it may make more sense to get it done quick & dirty in order to get funding than to write "good" code. That might explain the disparity of our experiences.
Doesn't this cover any website that collects personal information, since the Children's Online Protection Act prohibits that for people under the age of 13?
If either the worker or the company is not good at communicating, that will cause serious problems. Poor communication from the managers can easily cause poor motivation and execution problems from the workers. If a worker is not communicating blocks or reaching out for the help they need, that can also lead to those problems.
Or maybe there is more to consider than just one issue, but it's still worthy of criticism? Maybe an job can offer great benefits, exciting challenges, a valuable product and great coworkers but still have room for improvement in the office layout. Your solution to that situation would be "shut up and quit" over "raise awareness of the issue to improve things for everyone"?
That seems like a pretty good unique identifier, but I think it could be hashed for privacy.
> socket.on('alert_autoclick', thebutton.click() ); // click the button automatically when your server tells it to
Isn't that the whole point of this extension, to click the button when the server tells your browser to? It seems like you're implying that's a bad thing.
> socket.on('reload', location.reload() ); // reload page when your server asks to inject new code from it
This seems to be the most common JavaScript live updating technique (reload when websocket says so is what grunt watch uses). Again, it seems like you're implying that's not normal.
The craziest thing I've seen so far is that another group known as the Assassins created a fork of that extension that would claim they would press the button, but in fact wouldn't so that the timer would run out.
There are groups sabotaging other groups' code based on their goals for the button.
https://www.reddit.com/r/Knightsofthebutton/comments/31x3c0/...
Every time I see something like this that's what I think of.
Basically it stipulates that you should keep classes outside of the main page loader to be compliant.