Google's Nest is disabling some of its customers' old smart-home devices - <AUTHOR> http://uk.businessinsider.com/googles-nest-closing-smart-home-company-revolv-bricking-devices-2016-4 <comment><USER2> This is neither the first time Google's done something like this to customers, nor the first time Tony Fadell has been directly involved. When they pulled Google Glass from the market, it was concurrent with moving the Glass team to Fadell's leadership. They didn't go quite so far as to push an update to brick devices, but they left the software in a broken state, and refused to open source their fork of Android so users could fix it themselves. Nest has also burned a lot of Google's goodwill with badly designed smoke detectors ([https://www.youtube.com/watch?v=BpsMkLaEiOY](https://www.youtube.com/watch?v=BpsMkLaEiOY)) and thermostats ([http://www.nytimes.com/2016/01/14/fashion/nest-thermostat- gl...](http://www.nytimes.com/2016/01/14/fashion/nest-thermostat-glitch- battery-dies-software-freeze.html)).

And then there's this, on a recent HN thread: [https://news.ycombinator.com/item?id=11105510](https://news.ycombinator.com/item?id=11105510)

> "I still wake up with something like PTSD occasionally from getting yelled > at and bullied by Tony Fadell almost literally every day while I was there."

> "Tony literally stood up at an all-hands after the Alphabet thing and said > "Fuck being Googley" (direct quote)."

I think Google/Alphabet need to take a serious look at what Nest has been doing to their brand. A few thousand very-pissed-off people here and a few thousand very-pissed-off people there add up to a serious liability for a company like Google.

<comment><USER3> They can easily fix this. If they don't, it speaks volumes about how Nest/Google/Alphabets values customer relationships. Take all the other google services and imagine what would happen if google were just as reckless, especially with long life products like home installed devices.

Home automation installation services or even contractors would also be cautious about Nest.

<comment><USER4> Companies sunset SAAS products (with subscription fees, one time setup fees etc) all the time when the cost to support them becomes too high, growth stalls etc. Clearly Alphabet/Nest could have done a better job of customer service and offered users a partial refund or discount on a replacement product. That said, is it realistic to expect a company to support a software service indefinitely (when the business case no longer makes sense), just because it's tied to a piece of physical hardware that you paid $199 for a few years ago?

<comment><USER5> > when the business case no longer makes sense

Doing this kills ALL future business of this type. Who would buy such a device knowing this could happen?

Unless they don't plan on making consumer appliances anymore.

<comment><USER4> I'm not saying it's an ideal outcome for a company to sunset a product, but why is the consumer expectation so different for pure software vs a connected hardware device (i.e. software + hardware)? Consumers experience sunk cost when any product gets sunset, whether it's hardware or not.

<comment><USER6> What bugs me is how many companies these days want to include reliance on the cloud for features that don't require it at all, in the interest of gaining access to more customer usage data, but then when they turn the servers off the product becomes useless.

This has become a key thing that I look for when buying new products. If the product relies on the cloud for a feature that I think should be entirely offline, the product will be immediately returned and a negative review will be left on the resellers site.

A perfect example was the early version of the Lockitron device. It required cloud access but had a one time payment. Based on that information alone I could not justify the purchase to myself even just to play with because it's a bad business model.

<comment><USER7> Fitbit. I fail to see why tracking my health, location, etc. is a cloud function, beyond selling my data. At least give me the watch free if you're going to sell my data too.

They then add insult to injury by making me sync via a dongle /connected cable to my laptop; at which point I could just as easily sync to a desktop client vs their otherwise "disconnected cloud".

<comment><USER6> I wouldn't have such a grudge against fitbit if they would make it easier to log to your own server. Even if I had to hijack DNS to accomplish it, I wouldn't mind. Its not like many people would take advantage of the option.

But the fact that they force you to use their servers to store _your data_ so that they can turn around and sell it, frankly I hope they get sued for something. Anything.

There should be a law against selling customer data without the expressed consent of the customer whos data is being sold, per purchase. Even if the company is acquired.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I bought a Dropcam when they were a new thing. When I realized they did literally everything via a cloud service and would be a brick without that service, I was furious. The incredible arrogance of a company making a webcam that sends your video to their servers, and provides no means to use the camera in a secure/local fashion, was astonishing to me.

I still can't believe something like Dropcam is such a huge success. The level of security awareness the general public has is terrifyingly small, and companies are taking advantage of it to produce brickable devices. It is the legal variant of ransomware...They can hold your data hostage for any reason and at any time. You're completely at their mercy, with regard to pricing and availability, and you have to trust they won't fall on hard times, or get tired of running the service.

This is the next front in the battle for electronic freedom, and lots of folks (even nerds) don't seem to realize it.

<comment><USER9> counter point: i pre-ordered dropcam for the reason that it was limited to cloud-use only. I wanted something dead simple to use so my wife / house sitter / etc could easily move it as needed, we had access anywhere without configuration, and devops/it being handled by someone else incase i'm not around. Classifying their cloud-only product design decision as "incredible arrogance" quite a stretch... if anything, sounds like incredible ignorance on part of buyer?

To your point about it being a brickable device... I figured by the time the product was "bricked" (e.g. company going bust, product end-of-life, etc), that the hardware would be so out of date that it'd be time to replace it anyway.

With that said... after Nest acquired them, there's been no new meaningful features, no decrease in price, no new camera features, etc. I cancelled the "DVR" plan and will be finding an alternate system later this year.

<comment><USER8> _" if anything, sounds like incredible ignorance on part of buyer?"_

I read the box. It listed a bunch of cool features. I bought it.

Nowhere on the box did it say, "We will keep all of your video and there is no way for you to use this device without Dropcam.com acting as an intermediary." I'm sure if I'd read some reviews, it would have been more clear to me what I was buying. But, I've bought cameras in this category before (first one I bought was a Panasonic Petcam about a decade ago, which worked _wonderfully_ for many years, and didn't have the ability to hold my data for ransom), and never had one of them be this...um...useless, without the service associated with it. My expectation as a consumer of these kinds of devices was not, at all, met by what Dropcam is.

So, yes, I was ignorant of how Dropcam worked; but that ignorance was fostered by omission of key information on the Dropcam packaging.

 _" With that said... after Nest acquired them, there's been no new meaningful features, no decrease in price, no new camera features, etc. I cancelled the "DVR" plan and will be finding an alternate system later this year."_

So...we're agreed, then, that you are at their mercy. You just have a much more forgiving attitude about their practices than I do. I consider it unethical (particularly the misleading copy on their packaging, but the general case of a device being ransomware, as well). Obviously, I'm not in the majority, since Dropcam is well-reviewed, and well-liked by a lot of people. I can't make people care about privacy, security, device re-usability, longevity of devices, reducing e-waste, and being able to make my own decisions about how I can use my devices, but I do still care about those things. Ease of use does not require giving up consumer choice.

<comment><USER10> ah but you didn't read ALL of the 300 page EULA, and discuss with the lawyer its specific interpretations and possible outcomes, therefore this is really your fault you see...

</comment></comment></comment></comment><comment><USER11> It is a sad evolution of things. What happens to your Model S if Tesla goes out of business? The whole "remote compute / hosted" thing is a challenge. I hit it recently when I was looking to demonstrate an old game that used to run on Win98 and realized the version on the CD was unplayable and the servers where it originally downloaded the 2 gigabyte "patch" was no longer online. I found an older image of my C drive from back in the day and with a lot of work got that running under vmware workstation, only to have it still be unusable because I couldn't get the vmware version to simulate a 3D card that DirectX 4 would talk to. So well and truly dead as far as I am concerned.

So having all this stuff depend on other stuff which is only relevant at the current point in time where all the systems are online, is a recipe for massive loss of infrastructure support. The whole "long lived home server" thing starts to become a compelling response.

<comment><USER12> This is something that hits gaming especially hard, yeah. It sucks. What especially sucks is most people don't understand the downsides. Most people don't understand that their kids won't be able to play or even look at those games.

Most game devs don't even realize it. I had an interesting chat with one of the WoW devs a few months back and I asked him what his thoughts were on the ephemerality of what's created. Not only how nobody will experience the content but how all the lessons learned from creating the content, all the man-years spent in creating the art, the design etc are also lost. Well, he didn't really have an answer, I think the question just made him feel bad. Understandable.

</comment></comment><comment><USER13> This is also one of the reasons I've moved most of my "hub like" functions to home assistant [https://home-assistant.io/](https://home-assistant.io/) which is open source 100% [https://github.com/balloob/home- assistant](https://github.com/balloob/home-assistant)

I was burned by them buying Revolv, the most promising of all hubs due to having multiple antennas and touted as supporting multiple new protocols via software updates (which never happened post merger).

<comment><USER14> So... are there any hubs that specifically work with home-assistant? I like the idea of home-assistant, but I've already got a ton of z-wave already in my house.

<comment><USER15> I am in the very early stages of home automation. I've had a Nest for years, but only last week I installed a Z Wave dimmer (one of the Cooper Aspire series) and set up Home Assistant with with Aeon Labs Gen5 Z Wave dongle[1].

I've been very impressed with Home Assistant. The developer is very active, and happy to discuss development proposals in the project gitter.im chat room.

[1]: [http://www.amazon.com/Aeon-Labs-Aeotec-Z-Wave-Z- Stick/dp/B00...](http://www.amazon.com/Aeon-Labs-Aeotec-Z-Wave-Z- Stick/dp/B00X0AWA6E/)

<comment><USER13> Yup, balloob is about as nice as it gets for an open source maintainer. He is why I started trying to contribute to Home Assistant (that and it is actually overall very good python code and how an OSS project should be organized).

</comment></comment></comment></comment><comment><USER16> Companies are getting more and more creative with interpreting what 'ownership' actually means. Books you've bought evaporate, equipment stops working, cars that can't be serviced other than at authorized dealerships and so on. Ownership is a term that has been stretched way beyond the breaking point.

Any device that needs an internet connection in order to function should be leased, not bought.

<comment><USER17> Well it was apparently leased, just the customer wasn't informed about that. The nice side benefit is they get to have a nice container of hummus at the end -- don't have to return it.

Then these companies complain and cry how everyone is pirating things and nobody wants to buy their products. A lot of people in Western countries, I feel use pirated products not because they don't have the money to pay, but because it is a better user experience -- no forced commercials to watch, FBI warnings over which you can't fast-forward, music doesn't disappear if they buy a new device and so on.

<comment><USER18> > Then these companies complain and cry how everyone is pirating things and > nobody wants to buy their products

To be fair, I think you'll find that there's very little overlap.

</comment></comment></comment><comment><USER19> I think what users actually need is a smart home computer: one device, for the entire family, which provides sits on the Internet and provides secure access to home-network devices (e.g. security cameras, media players) and which gives easier-to-use (albeit perhaps less-secure) access to those things on the LAN. It could use containers to run blobs of code from different vendors. Given modern computing resources, it could actually _be_ the computer, with mom & dad & the kids all using tablets, phones and lightweight network computers as little more than X servers.

In this situation, there's no need to worry about a vendor's servers being shut down: one's own server continues to run, and continues to provide service. One has _control_ , and yet for the vast majority of people who don't care, one needn't think about it until one wishes to.

<comment><USER20> Agreed. In fact, there is overlap in what you've just described and what I call "Personal Application Omnipresence," [1] a model of computing where applications run to service you (and your family) but are made available to all of your IO devices (phones, tablets, desktop terminals).

[1] [http://tiamat.tsotech.com/pao](http://tiamat.tsotech.com/pao)

</comment></comment><comment><USER21> Wow, this is certainly something to think about in the age of the IoT's.

I guess the question should be asked as to where the line is between when a user should and shouldn't expect a device to work. Especially in the coming age of drivers less cars.

I can easily see a case where each driver-less car will need to talk to a mother-ship if for no other reason than syncing with other cars around it, getting new GPS maps, etc.

I think most people would be rightly disappointed if their car was suddenly bricked and unable to work due to the car's manufacturer end of lifeing their car.

Where is the line between bricking a $300 device and a $30,000 device?

The only close analogy that quickly comes to mind is video games. Most now require online servers to play, or at least get the most out of them. Some companies like ID software have been good about releasing the required code to keep their games online long after they no longer want to support them, others companies have been, ummm, less willing or able to do so.

<comment><USER22> Ha - imagine a bank robbery escaping in a driverless car, only to have the manufacturer brick it during their daring escape.

<comment><USER23> I can imagine a much scarier scenario...

You use whatever app to summon a car. You give it a destination, and instead, the car makes a detour to the local police station. the address you entered is in a higher crime rate locality, and therefore the car owner approved further "screening". So the car goes to the local police station for a routine search of the car (authorized by car owner) and a dog search of you...

That kind of future is one I am worried about.

<comment><USER24> just because the car owner allow search of his property, it does not make your property available.

and i am also pretty sure even a bad lawyer could get you a criminal kidnap case out of this.

<comment><USER25> Hah. Has anyone been able to uphold a "You agree to being abducted" in a terms of service before?

<comment><USER26> It's not, legally, abduction when you are in an airliner and the pilot reroutes because of a security incident; why would it be in a single passenger commercial automated vehicle?

<comment><USER25> Because you can't just safely step off of a plane? Come on, that's a terrible analogy. Taxi cabs can't suddenly re-route you to the police station against your will.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> It's interesting how so many people think this is a new problem because of IoT.

This problem has existed for years with games. If you had a game that had to be online to play, and the company decided to stop running the servers, you were screwed.

Sure, sometimes people reversed engineered it, and while the company usually didn't care, it was technically illegal.

We need some laws to protect consumers, that either say that they must release their API if they're going to shut down, or at least make reverse engineering the system legal.

<comment><USER28> > _We need some laws to protect consumers, that either say that they must > release their API if they 're going to shut down, or at least make reverse > engineering the system legal._

The EFF proposed making a DMCA exemption for reverse engineering game server functionality when the official servers have shut down, making the game useless. And of course the industry (with a little help from the MPAA) has fought it tooth and nail:

[http://arstechnica.com/gaming/2015/04/publishers-fight-to- bl...](http://arstechnica.com/gaming/2015/04/publishers-fight-to-block-third- party-revival-of-abandoned-game-servers/)

Apparently "hacking" abandoned games encourages hacking in general, and, as in the classic orphan work argument, allowing reverse engineering for all abandoned works would rob publishers of the revenue for the tiny, tiny portion of them that they may (or may not) re-release some day.

The Librarian of Congress gave limited approval of the proposal, allowing circumvention of the case you mentioned, where an online check is required just to play local single player, but not anything else. Creating a new multiplayer server, for instance, is still illegal.

[http://arstechnica.com/gaming/2015/11/u-s-govt-grants- limite...](http://arstechnica.com/gaming/2015/11/u-s-govt-grants-limited- right-to-revive-games-behind-abandoned-servers/)

</comment></comment><comment><USER29> Planned obsolescence is extremely prevalent (just see Apple's view on it - [http://www.geek.com/apple/phil-schiller-thinks-its-sad- that-...](http://www.geek.com/apple/phil-schiller-thinks-its-sad-that-people- use-5-year-old-computers-1650316/)), and this intentional bricking is a close and sinister cousin. Before the idea of regularly replacing your hardware was so widespread, companies needed to at least pay lip service to the idea of continuing support. Now that it's become the status quo to buy a new phone every two years, it looks like some are starting to conclude that the savings in support costs are worth the PR hit.

Very pro-profit, very anti-consumer.

<comment><USER30> That Phil Schiller quote is, frankly, a pretty lousy attempt at establishing that that is Apple's "view" on planned obsolescence. The swipe at Apple in this context is absurd. I have 15-year-old Apple products that are still working perfectly well. I have a 9-year-old iMac on my desk that is still up 24/7.

I have zero (0) Apple products that have been unceremoniously bricked by Apple in the way Google is doing to the product in question. Zero.

<comment><USER31> Google has nothing to do with it. Nest is a subsidiary of Alphabet, and even then the responsibility is 100% with Nest and not Alphabet. Tony Fadell comes from an Apple pedigree, if we're blaming one of the two.

<comment><USER32> The name change to Alphabet and movement of project/product ownership to Alphabet's subsidiaries is a recent thing. People will, for quite some time, equate Alphabet and Google when speaking about the parent company (Alphabet) in relation to other subsidiaries.

</comment></comment></comment></comment><comment><USER33> I really dislike the tendency of the new economy to simply pull the plug, not because of end of life, or unprofitability, but apparently because they're excited to work on something new.

To hell with your exciting journey, I paid good money for something I'd like to _work_ for a reasonable length of time. I want home automation and appliances to work until they go pop.

It puts me off buying a lot of these things. We've already had smart TVs turning off features like Skype in 2 yo sets.

</comment><comment><USER34> I wish Synology would get on the stick and and make/acquire a Dropcam-like device for their NAS products. Why would Synology, a maker of mass storage appliances, head off to the topsy-turvy world of consumer products? Look at their software offerings that run on their hardware. DS Note, an Evernote/OneNote competitor? They have put a non-trivial amount of work to produce it, and it's good enough I use it in lieu of aforementioned products. Does it sell more NAS products? Dunno, I'm assuming it must. I just know that all of my notes stay on a machine that I own. That machine is five or six years old, and Sinology continues to crank out updates for it. When they stop, my box will still work.

DS Note is just one example, there's buttloads of software that Synology cranks out for these little boxes, including security cam software. Problem is, tracking down which camera works with the NAS is non-trivial, and frankly more trouble than I care to expend. Now if Synology said, "here's a $200 camera. Point it at your NAS. All data stays on your local network, no 'cloud' services to rely on. Sorted.", I'd buy four of them that same day, no questions asked, shut up and take my money.

<comment><USER28> Don't people already do this with Synology NAS boxes? Just a normal IP camera, writing to storage and with remote access set up it should work. Not consumer plug and play, but I swear I've read about people doing this...

<comment><USER34> Oh, people do it. I was _going_ to do it, but there's a list of hundreds of compatible cameras. Of those hundreds, which ones suit _my_ needs? Which ones are less than $300? What is the definition of "works"? (There's "works, but...", and then there's "works out of the box with five minutes of configuration, and here's a link to the settings you want".)

IOW, yes, there is a currently available solution. What there isn't, AFAICT, is a "click here, wait two days for Amazon, have it running five minutes after you open the box" like Nest or Withings.

</comment></comment></comment><comment><USER35> This is starting to be a real problem. What if Tesla decides to shut down their cars after 7 years or your phone stops working after 2 years? I bet somebody somebody will come up with an idea for a house that shuts down after a certain time.

If you can't rely on ownership of something anymore we'll be in big trouble. Maybe there will be a countertrend where instead of relying on the cloud as storage/computing service computing and storage will go back to the customer.

<comment><USER36> We already have housing as a service (eviction is close enough to shutting down, so it has that to).

It's not so bad, people generally understand the implications of renting and there are laws protecting their rights.

I wonder if people were clearer that these gadgets were unlikely to stick around for 3 years if they would buy them at all.

</comment></comment><comment><USER37> As a longtime Dropcam owner, I find this very unsettling. Truth be told, Dropcam service has steadily decreased in quality ever since the Nest acquisition. Not a month passes without an unexplained multi-hour outage; our mobile apps are randomly logged out every few days, requiring us to enter lengthy passwords while nervously wondering what that motion alert might be about. One day the whole Nest rigmarole will become inconvenient for google and _poof_ \- our $200+ camera will become yet another paperweight.

My only hope is that FOSS will become an option for these devices. There have been examples[0] of Dropcams getting rooted, so perhaps not all is lost here.

[0]: [http://blog.includesecurity.com/2014/04/reverse- engineering-...](http://blog.includesecurity.com/2014/04/reverse-engineering- dropcam-rooting-the-device.html)

<comment><USER38> How long, as a practical manner, is google required to run these servers? Until all the devices die? 3 years? 5 years?

Don't get me wrong, I'm with you. I think 4 years from sale is reasonable though. Whatever the commitment is, it should be on the packaging, and it would be nice if the various state and federal consumer protection laws were applied here.

<comment><USER39> I think the business model of "selling things" may be out-of-date at this point, and instead we'll see companies giving away hardware that requires that you subscribe to a monthly service to use it.

A number of old-economy businesses already do this, eg. razors, printers, car leases, apartments. Kinda ironic that this comes on the heels of the "ownership society" though.

<comment><USER40> Long time coming.

I read The Goal and its sequels in the early 90s. The struggling fictional businesses were turned around by transitioning from production towards service oriented business models. Very out of the box thinking at the time.

[https://en.wikipedia.org/wiki/The_Goal_(novel)](https://en.wikipedia.org/wiki/The_Goal_\(novel\))

I really enjoyed the books at the time. Not great literature. But very thought provoking.

</comment></comment></comment></comment><comment><USER5> Very cutesy title, but a very poor title.

This is why I refuse to buy any 3rd party internet connected (I mean connects to a 3rd party, not just TCP/IP) appliance unless I can install anything I want on it.

It doesn't matter if internet connectivity is required or optional - if I'm not in charge of the software on it, and it connects to a 3rd party I refuse to buy it.

I have a feeling more and more people will refuse to buy these devices until this fad moves on.

<comment><USER41> Nice for you to say as a developer, but not every customer cares about this. I mean of course one should be able to flash new firmware. But more importantly people like Google shouldn't brick devices the customer has bought, whether they can be flashed with a new / alt firmware or not.

<comment><USER42> I think most customers that don't care about it are simple lacking the information to correctly assess the impact of it. I think accurately explaining a few of the possible downsides:

\- If your internet if not functioning, the device may or may not function

\- If the company that sold it to you closes, it may immediately stop functioning

\- If the company that sold it to you decides to discontinue the product, it may stop functioning

\- The company that sold it to you may remove or break functionality at any time. It may be left in this state for many reasons.

And then pointing to concrete examples of products where each of these cases happened, which shouldn't be that hard to do, and how long it took to happen in each case (from initial product launch and from last device sold), would result in a lot of people caring about exactly this problem.

In other words, I don't think it's that people don't care, it's that they don't know enough to know they care. It's a relatively new development, compared to items like cars, fridges and dishwashers, which is probably how a lot of people think about their appliance devices.

</comment></comment></comment><comment><USER43> I'm not against IoT devices but when it requires an external service to work at all I put my foot down. I looked at devices like Nest but decided against it.

My Synology NAS has some cloud like services but it does not require any external services to work. Just the way IoT should be.

<comment><USER44> Centralized IoT servers would be a lucrative target for hackers. And as much as I would like the luxury of setting my thermostat remotely as I'm leaving work; it's not worth making it accessible over the internet.

<comment><USER19> > Centralized IoT servers would be a lucrative target for hackers. And as much > as I would like the luxury of setting my thermostat remotely as I'm leaving > work; it's not worth making it accessible over the internet.

Well, that's a problem with centralisation. There's no reason that you shouldn't be able to connect directly & securely to your thermostat, or access it indirectly & securely via your router or home server.

Among the issues of doing this are asymmetric Internet speeds and NAT, but those are solvable.

</comment></comment></comment><comment><USER45> Reminds be of when I bought a Nexus One because Google promised it would receive updates as soon as they were ready. The next Nexus device came out with the update, and my Nexus One didn't get it. I think it came out a half year later, but by then I'd moved on to cyanogenmod and then to iOS and never looked back. I've been weary of Google ever since.

<comment><USER46> ahh the nexus one and its ridiculously small system partition.

I still love the design of this phone, but it has severe oversights as far as evolvability goes.

</comment></comment><comment><USER47> And here's another reason not to buy any Nest devices now that they're owned by Google. How long until Nest itself gets shut down?

</comment><comment><USER23> Ah. Now we see the end of the beginning of the age of IoT.

I have consistently complained that these companies are completely deficient in requiring some cloud service (read: other peoples' servers). And guess why I had those issues? Because they offload all processing to these machines to retain control of them.

I am not against companies trying to make a buck. Instead of tying your service that __will __explode, support open standards like MQTT, CoAP, and AMQP. Doing anything less shows to me that your business is a house of cards.

<comment><USER48> > Because they offload all processing to these machines to retain control of > them.

That makes it sound like their primary concern is keeping control of the devices. In reality I think it's just laziness. We all know how much easier it is to support code running on a server than to support code running on hardware sitting on somebody's dusty garage shelf with no internet connection.

<comment><USER23> > That makes it sound like their primary concern is keeping control of the > devices. In reality I think it's just laziness.

I sincerely believe that many of these entrants into IoT do want to remain in control of the devices and the users who "rent" said hardware. I've seen laziness in code before. It's usually sloppy, unmaintained/badly maintained, and just messy.

These products are polished, just work, and smooth... and make you go through their systems. That's an intentionally designed system.

> We all know how much easier it is to support code running on a server than > to support code running on hardware sitting on somebody's dusty garage shelf > with no internet connection.

Indeed true. I'm not advocating axing out those features. I said to add in another: which is to use open standards as well.

I also develop IoT hardware (not for sale). I use Arduino Nanos, nRF24L01+ radio chips, whatever sensors/actuators for the hardware. For the software, I use Node-Red, Mosquitto (MQTT server), and Apache NiFi. For "cloud support", I use Tor Hidden Services at every gateway machine, and communicate between .onion addresses. I effectively treat all my machines in the world as a simple ethernet hub. I'm just an individual, and was able to figure all this out.

<comment><USER48> > I'm just an individual, and was able to figure all this out.

Getting something to work one time is not remotely the same task as getting it to work for every user, every time. Getting the setup you described to work correctly is doable. Getting that setup to work for everyone who takes a box off the Home Depot shelf and plugs it in? That's hundreds of times more work. Writing a nice UI is a piece of cake in comparison. I'm still inclined to see laziness here rather than malice.

Not that it matters. The end result is the same either way: devices that spy on you unless they get bricked. I wonder if the 1984 Big Brother webcam had more than a two-year warranty.

</comment></comment></comment></comment><comment><USER49> Google basically paid a billion dollars to Tony Fadell to get him to come to Google.

I wonder how they feel about that "investment" now.

</comment><comment><USER50> This is a big problem for HVAC control devices that ought to last decades. Even Honeywell only offers a 2-year warranty on their Lyric network-enabled thermostat.[1]

[1] [https://customer.honeywell.com/resources/techlit/TechLitDocu...](https://customer.honeywell.com/resources/techlit/TechLitDocuments/95C-00000s/LyricWarranty_Retail.pdf)

<comment><USER36> Out of curiosity I went and found a random hydronic component. 3 year warranty:

[https://customer.honeywell.com/resources/Techlit/TechLitDocu...](https://customer.honeywell.com/resources/Techlit/TechLitDocuments/68-0000s/68-3092.pdf)

5 years on a simpler thermostat:

[https://customer.honeywell.com/resources/Techlit/TechLitDocu...](https://customer.honeywell.com/resources/Techlit/TechLitDocuments/50-0000s/50-9363.pdf)

</comment></comment><comment><USER51> This has been going on for, oh, a few hundred years, in many different industries. They even have a word for it: "renting". You get something for a while, and then when the term is up, you're done with it. You can extend the lease and they can agree to let you do so, but when you're done you're done.

The only issue here seems to be that the COMPANY views the transaction as a rental while the CONSUMER views the transaction as a purchase. Legally, I'd be willing to bet good money that the company is "correct", but I'll also bet that same cash that they'll always lose in the court of public opinion.

<comment><USER52> Interestingly, all the robots are leased, not purchased, from US Robotics and Mechanical Man, in the fictional universe of Isaac Asimov.

<comment><USER53> Not all. There was one very prominent robot that was responsible for that rule.

See the story: The Bicentennial Man

</comment></comment></comment><comment><USER54> I'll be really surprised if this doesn't turn into a class action lawsuit.

I'd grab the popcorn on that one too, interesting legal questions.

</comment><comment><USER55> I think this is an inherent problem of the design of hardware-software-cloud combined products. Forget Google for a second; what if this was a startup that simply ran out of money and shut down? They wouldn't have money to run their servers, and the software portion that relies on servers would necessarily fail with the company's loss of funds. What are you going to do, ask the founders and investors to support server costs out of their pockets post- shutdown?

Google isn't any different; they have the _right_ to pull the plug on server- side stuff and make whatever budget cuts they need to make in order to keep their company running and keep their shareholders happy. It might affect customer relations. You might choose not to buy their products again. But they have that right.

They can also choose to continue to keep the service running at a loss in order to keep customer relations happy for future products, and build a good reputation. They would have to weigh the pros and cons of this, given that the number of Nest users is miniscule compared to other Google products. It's their decision.

Keep this in mind when buying any hardware that comes with a cloud-based software component. You also have the _choice_ not to buy such products.

On another note, I have my thermostat controlled by an Arduino and web interface run on a Raspberry Pi. It's not going to be shut down any time soon.

</comment><comment><USER56> This is a relevant thread on reddit:

[https://np.reddit.com/r/Nest/comments/4dbbgh/is_anyone_conce...](https://np.reddit.com/r/Nest/comments/4dbbgh/is_anyone_concerned_about_the_future_of_nest/)

<comment><USER57> That top comment - oh dear. Of course, it is an anonymous Reddit comment, so approach with skepticism, but FWIW, it _does_ match up with what I have been hearing through other channels like Glassdoor and old-fashioned gossip.

</comment></comment><comment><USER58> Is there room here for some sort of industry body or label group to promote a "Works Offline" sort of brand, like organic and kosher food labels? Device makers would get to use the logo if their device wasn't utterly dependent on cloud services.

</comment><comment><USER13> FWIW, I bought a Revolv hub looong ago before google bought them. They stopped updating the app and the hub when they were acquired by Nest, which is when it stopped being super useful. It has been mostly useless since then, and now the service no longer works. This sounds worse than it is as they more or less did this when they were acquired, since it was a very new product that hasn't had any updates since.

</comment><comment><USER59> Cool. Now you will be expected to replace your smoke alarm, thermostat, and security system on a 6-12 month cycle like they already expect you to do with your telephone. Anybody willing to invest in smart windowpanes? Attic stairs as a service? Is there any way that we can rent people's own hands back to them? Some sort of a glove that analyzes everything you touch and only pays taxes in Ireland?

</comment><comment><USER60> Note to self: never buy a Google device.

<comment><USER61> I bought my Nest before they were owned by Google...

<comment><USER62> So did I. But I managed to re-sell my Nest to someone else shortly thereafter. :D

<comment><USER60> There's a sucker born every minute

<comment><USER62> I warned said user in advance, told them why I was selling it, etc. But they're a Google Developer Group leader and such, so they're kinda baked into the Google ecosystem. Who am I to argue? If he wants it, and I want to get rid of it, there's a deal!

</comment></comment></comment></comment></comment><comment><USER63> With all of the love for Tesla and their v3 of late, it's worth remembering that Tesla can and does brick their cars as well.

[http://syonyk.blogspot.com/2016/03/is-tesla-building- throwaw...](http://syonyk.blogspot.com/2016/03/is-tesla-building-throwaway- cars.html)

If it has software, and automatic update capabilities, it's never yours.

</comment><comment><USER64> Good to know this is how Nest operates. I will be steering clear of their devices in the future.

</comment><comment><USER65> This is the ultimate irony in that the only people I know who are obsessed with controlling things like the light bulbs in their home or regimenting the appliances and other devices to a strict schedule to their exacting demands are having the carpet pulled out from under them. Basically, enter your control freak with a penchant for organizing, classifying and making things that worked just fine before "smart" and "iOT" were mere buzzwords in a drunken dinner conversation with Tony Fadell now told they can't control a thing.

"Sike!" Tony Fadell and the beloved Google had all the control the entire time. As if Google isn't collecting data in the background on when your lights were turned on.

It's one thing if you're a nerd and build your own Arduino home controlled device as a hobby project. But I don't have sympathy for the class of consumers who buys these devices.

<comment><USER66> Do you have pull cords on all of your lights or switches on the wall? Controlling lights, etc... via IP is a natural progression. Yeah, early adopters are weird but you're crazy if you think this is just a fad for control freaks.

</comment></comment><comment><USER67> This has been up for an hour and made the front page and we still don't have a Google Reader mention? Who are you and what have you done with Hacker News?

<comment><USER68> they did a lot better with closing Google reader than this. at least then, they gave you what you needed to get the same service through a different provider, whereas here, theres nothing

</comment></comment><comment><USER69> Could you sue Nest / Google for this? Or would the EULA have something that says you have to go through arbitration.

</comment><comment><USER70> There's really no good reason for this kind of behavior from Google. They have the infrastructure to continue to support old products and they don't do this _every time_ they do an acqui-hire.

I recall years ago when I was a huge SageTV fanatic. They acqui-hired the company behind SageTV and integrated their product into Fiber (yet another reason for me to be jealous of Fiber). The products were immediately pulled from market but generally continued to function for years (I'm not sure how long since I abandoned the platform and went full-on cord-cutter), but last year they decided to fully open-source the code. Yeah, it would have been nice if it was done much sooner, but at least they gave enthusiasts of the platform an opportunity to pick up where the company left off after they were acquired and their core product was force-pivoted.

It seem to me that something similar could have been done here but they opted not to. That's unfortunate and it will play into my ever growing concerns about committing to _any_ google product beyond search[1].

[1] I'm GMail and Android committed to but I'm not happy with the rapid, radical changes happening on that platform, either. Though they're unlikely to sunset the product any time soon, it appears to be evolving into something that's so different that I can no longer call it the same product I fell in love with years ago.

</comment><comment><USER71> To be honest, some things are better with old-technology

Like the Bluetooth door lock fiasco, like some complaints about "you have to download an App to turn the lights on in this house", the IoT/"Smart Home" people are not accustomed to the reliability expected of such things

Having a device that _requires_ it to be online to work I can only accept if I don't "need it" (like to get in my home or heat it when it's cold - have fun heating your house after a snowstorm knocks your internet)

<comment><USER72> Could local building regulations not be used to require the existence of a heating system that can be turned on when mains electricity/gas is available i.e. some kind of manual over-ride to any digital control system?

</comment></comment><comment><USER73> I don't understand why anyone would buy a home automation/smart-home device that can't work fully independent of "the cloud" (butt) with local management. If I can't talk to it over private IP space and run a local daemon/server on the same layer 2 ethernet fabric to manage it (eg: Unifi), I don't want it.

If I want to remotely access a camera or something like dropcam I am perfectly capable of VPNing in to my own home network to do so. I don't need the butt.

</comment><comment><USER74> On the other hand, this seems to provide a really good opportunity to hobbyists, if they can get the ball rolling quickly enough.

If the problem with smart-home devices is their over-reliance on the cloud, the best solution would be to create a self-hosted system. Expensive, powerful, otherwise-bricked devices provide a great incentive to create such a system.

As inspiration I am thinking of the Pogoplug devices that seem to be littered around thrift stores and "sold-as-is" bins. Without a connection to the previous owner they are bricks - the default web interface doesn't even come up if there is a registered user, and they can't be de-authed without the original user signing in. But they have multicore ARM CPUs, a decent amount of RAM, multiple USB ports, and even SATA ports. Canny users have found ways of popping a shell, rooting them, and turning them into home servers to do myriad tasks (there are versions of both Arch and Debian targeted at many versions of the Pogoplug).

I don't own any smart home devices, and I'm sure it would require a non- trivial amount of work to get a self-hosted system running, but it would be great as a platform for hobbyist experimentation. Particularly these Revolv devices which contain radios to communicate on multiple protocols.

</comment><comment><USER75> It's time that IoT vendors understand that they are making devices that are a part of homes themselves, and those things have lifecycles of decades, not months. Many people like to not unnail and unscrew everything every 2 years because the manufacturer decided to not maintain them anymore. Whereas the dumb equivalents didn't need that much maintenance to begin with.

How many phones and computers have you replaced in the past 20 years? When was the last time you replaced the outlets you plug them into? IoT has a long way to go to be viable for people like Moms and Dads.

> The fact is that I can fix the problem by purchasing a replacement device > such as a Samsung SmartThings hub. It's not terribly expensive, a few > hundred dollars.

Many people will think that is terribly expensive to keep novelty automation happening. And from what I've heard about Samsung's touch screen refrigerators, I bet that it's lifecycle won't be any better.

[https://productforums.google.com/forum/m/#!msg/calendar/Uhfp...](https://productforums.google.com/forum/m/#!msg/calendar/UhfpcwO0X0c/paA4iQNen9IJ)

</comment><comment><USER76> And this boys and girls is why the IoT is only useful if _you_ control the device.

</comment><comment><USER77> There should be some sort of law saying that these types of things can operate in a basic mode without the need for an internet connection - at least post initial setups. There needs to be a way to protect customers from devices that don't really need the internet to function (like a nest thermostat) when they become obsolete.

</comment><comment><USER78> Pretty much the only reason why these devices are cloud connected in the first place is to allow people to easily control the device from their phone/laptop when away from home (Adding 5mb of webpage/API wouldn't increase the cost of a device that much).

What is needed is a easy to setup, widely supported VPN so people can leave their phones/laptops connected to the home VPN so they can access their smart devices. The VPN should be no harder to setup than Wi-fi as current VPN solutions are too much for non technical people. As a side benefit is it could cut down on the shenanigans mobile carriers can pull with rate limiting specific traffic as people could funnel all traffic through their homes connection.

Getting all of the various manufactures to support the same easy VPN standard would be the hardest bit, as the technical side is assembling already existing pieces into something easy to use.

</comment><comment><USER79> I repeat myself like an old scratched LP, you should build your smart-home around an open standard like KNX[0] which is supported by 100's of hardware vendors, many software vendors including OSS and can fully run without any kind of server.

[0]: [https://knx.org/](https://knx.org/)

</comment><comment><USER80> From the article:

> The fact is that I _can_ fix the problem by purchasing a replacement device > such as a Samsung SmartThings hub. (emphasis's author's)

No chance. Most'll never learn.

I wonder, how many hardware-driven-by-the-cloud businesses (home automation, "smart" routers, etc) have SLA contracts that require providers to actually maintain their service (including security updates etc) for any extended period. Guess, not many. Out of curiosity, I've tried to search for, say, "Google OnHub SLA" and found... nothing.

</comment><comment><USER81> Why do people buy this crap?!

Look, if you buy hardware that stores your data in "THE CLOUD", you're screwed if the company just decides to, well, do this.

</comment><comment><USER82> I had a similar problem with Boxee Box which wasn't bricked but put the platform on end-of-life.

Is really annoying to see the website talking about "We are excited about the next chapter for our team." Thanks guys. [http://www.boxee.tv/](http://www.boxee.tv/)

Luckily the box was insecure enough that someone found a hole to allow installation of Kodi.

</comment><comment><USER83> They should at least open source their revolv server.

</comment><comment><USER84> Hm. This is why we need a non-cloud based alternative to existing smart home hubs. Check our approach: [https://www.indiegogo.com/projects/protonet-zoe- start-your-s...](https://www.indiegogo.com/projects/protonet-zoe-start-your- secure-smart-home-now/)

</comment><comment><USER7> The problem with some of these IoT products is that they are more focused on being a vector or platform for broader automation than they are at doing one thing well.

Nest (the thermostat) itself is completely overrated, and is an over- engineered and unnecessary "solution" to a problem that's already been solved.

</comment><comment><USER85> The smart/connected device companies seem to be headed toward Hardware-as-a- Service for a business model.

It's unsettling.

</comment><comment><USER86> This sort of behavior is going to boomerang back on them; at some point consumer annoyance will force the creation of rules similar to those the FCC promulgates about RF interference for electronic devices.

</comment><comment><USER87> This is a bigger problem than anyone realizes. The thermostat in my home had been here for probably 30 years and worked fine. Then some idiot went an bought a Nest and replaced it. Me.

</comment><comment><USER88> Google's done a lot of crappy and questionable stuff over the years, but intentionally bricking devices is unquestionably evil.

</comment><comment><USER89> Why buy from a company that kills your purchase at some time in the future?

</comment><comment><USER90> I was going to get a Nest, but now I'm having serious second thoughts.

</comment><comment><USER91> Do not trust the cloud. Do not trust the cloud. Do not trust the cloud.

If you didn't build it and you don't know where it is, it could go away at any time for any reason and you will have zero recourse.

DO NOT. TRUST. THE CLOUD.

<comment><USER92> I'd say make sure that you are paying a fair amount of money. Otherwise you are stuck in a "kinda free"-Tier that might not get the legacy attention that you might expect.

<comment><USER91> As a OneDrive user, I can assure you this isn't necessarily true.

</comment></comment></comment><comment><USER93> >1 points by tomc1985 10 days ago | parent | on: OneDrive reduces free tier from 15GB to 5GB

>Never trust the cloud, it will always stab you in the back... eventually

Posted this before, got downvoted...

...posting this again, and will probably get downvoted again...

Seriously people, suck it up and run your own shit if it matters at all

<comment><USER94> You can do that if you have unlimited time. Eventually there's just too much "own shit" to take care of, if you keep adding all kinds of services. This is quite familiar to me, having run a bunch of email/web/container/database/file servers for personal use. After a while, it's pretty tempting to just trade money or privacy for time and convenience.

<comment><USER95> Also if you know how to do it in the first place, have the resources to afford learning-related mistakes, etc.

</comment></comment></comment><comment><USER96> 2 Words for people

Open Source...

and/or

Open protocols

if you buy into a proprietary systems, with proprietary software and walled gardens, I have no sympathy for you.

Consumers need to demand companies adopt open source software and open protocols, this is not the first shutdown of this type, and it will not be the last.</comment>


Show HN: I created the simplest human language - <AUTHOR> https://medium.com/@minilanguage/mini-the-minimal-language-3f3710e28166 <comment><USER2> I love this!

> What Mini lacks, however, is technical vocabulary of any sort. You will > never be able to discuss Kantian philosophy, file a quarterly financial > report, or write a prescription in Mini. In fact, you may have severe > difficulty in describing any single subject in depth.

Any plans to add domain-specific vocabulary like this, perhaps as an extension?

If Mini catches on, people will naturally make up their own new terms. Might as well come up with a logical set first, before this gets too messy.</comment>


Rust explained using easy English - <AUTHOR> https://github.com/Dhghomon/easy_rust <comment><USER3> Very nice work.

It's a good exercise to put complicated ideas into very simple language.

George Orwell had that job during World War II. The BBC used to broadcast news to the British Empire in India and Hong Kong, using Basic English. Orwell's job was to translate the news into Basic English. He later wrote that this is a political act. Converting news to Basic English means taking all the ambiguity out. If a political statement was ambiguous, removing the ambiguity means making a political decision. Someone has to decide what the statement really means.

That's where Newspeak, in "1984", came from.[1]

[1] "Orwell, The Lost Writings", [https://www.amazon.com/Orwell-Lost-Writings- George/dp/087795...](https://www.amazon.com/Orwell-Lost-Writings- George/dp/0877957452)

<comment><USER4> thank you for this, that is a fascinating snippet of information that sent me down a rabbit hole

<comment><USER5> Similarly, Room 101 was a room where he had to suffer long boring meetings.

Many years back I used to suffer long meetings in another 101 meeting room - <USER2> suspect that numbering scheme might be quite common.

[Edit: Mind you in the same building a lecture room where I used to suffer maths lectures is now a bar! The building having been converted to a hotel.]

</comment></comment></comment><comment> a-ve [https://fasterthanli.me/blog/2020/a-half-hour-to-learn- rust/](https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/)

This is also a good introduction.

<comment><USER6> This is great, thanks for sharing.

</comment></comment><comment><USER7> I think the paragraphs are simple enough, but my personal preferences is, some paragraphs better come first than others.

I am not sure if it's the same to others, but for me to learn a language for the first 15 minutes, I am really not interested with the differences of signed vs unsigned integers. I may have look of this when I got stuck somewhere later.

I think a better order will be:

1\. play ground

2\. hello world

3\. control flow

4\. function declaration

5\. string, list and dict

6\. featured stuff with this language (e.g. threading, async call)

I should be able to write basic stuff and play around with the above. Then I would try to sort out all kinds of remaining pitfalls myself :)

</comment><comment><USER8> I'm picking up Rust again, and one of our lead architects tried to pick it up but ran into the same issues I've ran all along: third party libraries (even extremely popular ones) have outdated example code or docs that are inconsistent with actually released versions. So in the meantime I will focus on learning the out of the box features of Rust.

It is a shame because I love the potential of Rust but it seems that not much has changed in the two years since I last touched it in the regards to documentation for external projects. I still am not good enough with Rust to start producing my own projects as a result, which in other languages you can do rather quickly. I hope the ecosystem matures in this regard because I love everything else, the tooling, the build system is very modern and mature as best as I can tell.

<comment><USER9> The issues with documentation aren't really something I'd attribute to the Rust ecosystem, but just to people/humans in general. I've had this problem with every language I worked with: JS/TS, Haskell, C/C++, Go.

Eg,the C++ boost docs are IMO completely decrepit, but people still manage to be productive using it.

If you see a mistake in the docs, open an issue (or a PR), it only costs you little time.

<comment><USER10> > I've had this problem with every language I worked with: ... Haskell ...

By the way, if you see outdated Haskell docs please report them on [https://github.com/tomjaguarpaw/tilapia](https://github.com/tomjaguarpaw/tilapia). I am (slowly) collecting examples and trying to improve the ecosystem.

</comment></comment></comment><comment><USER11> The discussion about shadowing variables doesn't seem to make a very good case to me about this feature. Why would you want to introduce all those variables on the stack, each of a different type (even if they have the same name, presumably they are new pieces of stack memory)? Why not just mutate an existing variable each time?

<comment><USER12> Sometimes you need a different type and you don't care about the intermediate values. Parsing a string into an integer is a good example. Once you have the integer, generally you don't care to use the string anymore.

      let num = String::from("10");
      let num: i32 = num.parse().unwrap();

</comment></comment><comment><USER13> I like efforts like this that try to use different wording to explain the same concepts. That said, this document still uses words I would not consider to be "simple English".

There are many such cases in the document, but let's take for example "inference". There is a definition of what "type inference" is in the first paragraph of the section. But the reader must still then learn this phrase at the same time as learning the programming language. Maybe a simpler English statement would be "Automatic types", using the word automatic, which is more wide spread and is adopted in many languages. The meaning is not as precise but the document can then further explain what it is.

I am not a native English speaker but have become so used to using it that it is sometimes difficult to know which terms cause issues to programming language learners. Perhaps HN is the wrong place to ask this but I would be very interested in knowing which terms other non-native speakers have problems with.

<comment><USER14> Unfortunately, we still need technical terms to define precise concepts. I'd argue that "inference" in "type inference" is not something a non-technical native English speaker would understand either, so it's less a matter of "simple English" vs. "technical vocabulary".

<comment><USER13> I agree. The problem is that most people learn these precise technical terms first in their own language and must then learn them also in English (well, in truth, for me it was the other way around :) ).

I think that this write-up could use a simpler English, as it is titled, then the reader can later proceed to learning the more precise technical terms in other material.

<comment><USER15> > The problem is that most people learn these precise technical terms first in > their own language and must then learn them also in English

I think this is only possible true for people who speak languages with large programming communities - Chinese and maybe Russian - but I doubt it's true for anyone else.

<comment><USER13> I am from a small country of two million people. We have our own language and the faculties have a mandate to coin new technical terms in our language. Our theses all have to be written using these terms (they are updated annually).

Unfortunately, we in the industry largely don't follow these updates so in our conversations we use English terms. People just graduating, however, may be exposed to the English terms anew when they start working.

A dilligent student would have studied material in English as well but it is possible for people to get to a Masters in Computer Science and do all their studying in our native language.

<comment><USER15> Interesting! I guess I am proven wrong. If you don't mind saying, what country are you from?

<comment><USER13> I am from Slovenia. We have had confusions with Slovakia, which is a source of a few jokes here, so just to disambuguate :) [https://en.m.wikipedia.org/wiki/Slovenia](https://en.m.wikipedia.org/wiki/Slovenia)

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> This could really use a Table of contents

<comment><USER17> It has one now

</comment></comment><comment><USER18> I feel this is like the condensed version of a book. Very useful, gets the job done so you can make yourself a quick picture of what is it like programming in Rust.

This not IMO newbie programmer material so I think a caveat could be added.

</comment><comment><USER19> Do you have specific examples of what is difficult to understand in the standard books for a non-native speaker?

Just asking out of curiosity and maybe readers can learn a thing or two about making documentation more accessible.

<comment><USER20> I'm not overly familiar with rust's documentation in particular but in my limited experience of teaching programming to a few unfortunate souls, the issue is usually figuring out what framing device to use.

The actual level of English in good documentation is usually fairly "low" \- i.e. keep it simple, assume your reader wants to learn (Too many people suffer from _I 'll let you google that for me_). That and a lot of non-native speakers probably speak better English than me (I know more words but I'm lazy)

I know how to program, I've been bitten by memory bugs - rust's design makes sense to me (i.e. the borrow checker is relatively intuitive because I've written and worked on compiler/s). That is difficult to convey in 10 minutes to someone who only knows how to plot a graph in python (for example).

My approach is usually to state all my assumptions as I go, while naming as much as I can as I go (e.g. googling for operators can be very difficult) when explaining things. In writing, I find that writing documentation away from the code can be quite fruitful otherwise the overall structure and meter of the code can be hard to divine.

<comment><USER21> > someone who only knows how to plot a graph in python (for example).

Hey, I've been writing Python daily for 12 years and I struggle with that!

First you have to get matplotlib installed. That often works nowadays, but you have to be sure you've installed numpy first, and on a bad day you'll find yourself looking at some sort of C compiler error and copying stuff from stackoverflow to make libgfortran be found or whatever.

Then you try to remember the bizarre way people import matplotlib. Your mind briefly flits to memories of blog posts explaining that matplotlib has two parallel APIs, and you start feeling annoyed about that. Then you start feeling annoyed that one of the APIs is based on matlab; why should a key part of the python ecosystem be apeing matlab? It's not like anyone has ever thought matlab had APIs, or anything really, worth emulating. Anyway, it's something like `from matplotlib.pyplot import plt`, or some nonsense like that. So you spend a few minutes failing to remember, and then googling for it with a rising sense of frustration.

Then you get this error:

_ __RuntimeError __: Python is not installed as a framework. The Mac OS X backend will not be able to function correctly if Python is not installed as a framework. See the Python documentation for more information on installing Python as a framework on Mac OS X. Please either reinstall Python as a framework, or try one of the other backends._

And now you're really quite annoyed. What the fuck is a framework? It's some MacOS thing but it's always been clear that it's a non-UNIXy concept that you don't want to and shouldn't need to know and you kind of suspect it shouldn't even exist. But holding that opinion would require finding out what it is.

So you google for how to overcome that. And then... there's some weird thing where you have to put a line in the middle of your inport statements before importing matplotlib... and finally you wish you hadn't been so stubborn and had just used an IPython notebook, but you just kind of hate them despite how beautiful and well-engineered they are. They can't be version-controlled, you hate typing code into your browser, you always end up with an incomprehensible mess of mutable state, etc.

I used to use R and, back then, I enjoyed making plots and did so efficiently and reasonably well.

<comment><USER20> Ignorance is bliss when you can just copy and paste example code and swap out the plotted function (is what I was alluding to)

</comment></comment></comment></comment><comment><USER22> I like the general idea. I haven't got the time to do more than skimming right now but I already feel that a single markdown file (especially without a table of contents) isn't the right medium for this.

<comment><USER23> I assume the markdown is the source and that other presentational forms will follow.

</comment></comment><comment><USER24> You can try your hand at writing in this style here:

[https://splasho.com/upgoer5/](https://splasho.com/upgoer5/)

<comment><USER25> Interesting tool - I tried pasting in your comment and it seems like the word "style" is not permitted!

      Uh oh! You have used a non-permitted word (style)`

<comment><USER26> Because it isn't in the list of accepted words[0] (most used words) as inspired by XKCD[1].

[0] [https://splasho.com/upgoer5/phpspellcheck/dictionaries/1000....](https://splasho.com/upgoer5/phpspellcheck/dictionaries/1000.dicin)

[1] [https://xkcd.com/1133/](https://xkcd.com/1133/)

Edit: I just figured out you might fully realize that and were probably just pointing it out to OP. Ignore me. :)

<comment><USER25> Indeed I did :) but still useful to have the links for other interested readers!

</comment></comment></comment></comment><comment><USER27> I'm confused. Only u8 can be cast to char, but char is 4 bytes long? How do those two things works together?

<comment><USER14> I found the paragraph about char a bit unclear; especially when explaining that all chars are 4 bytes long, and std::mem::size_of_val("Hello!") is 6 bytes. I would have expected it to be 24 bytes long!

<comment><USER28> A Rust String is encoded as UTF-8, it is not an array of char-s. You can get an iterator over individual codepoints using the chars() method.

[https://doc.rust- lang.org/std/string/struct.String.html#meth...](https://doc.rust- lang.org/std/string/struct.String.html#method.chars)

<comment><USER29> Don't most other languages use utf16 for strings?

<comment><USER30> It's fairly complicated in other languages.

Languages that were developed before the advent of Unicode, like C and C++, frequently leave the encoding of strings up to the system; but this can be complicated, because there are a number of different legacy 8 bit encodings, along with legacy encodings that don't fit into 8 bits. So they have two character types, char and wchar_t; char is a type that can always encode at least 8 bits, and wchar_t is an implementation defined wide character type, which is 16 bits on some platforms and 32 bits on others.

When Unicode was first designed, and released as Unicode 1.0, it was envisioned as a 16-bit universal encoding, with the expectation that you would use it just like 8 bit character encodings but with 16 bit character types instead. This encoding is known as UCS-2.

However, experience and unification of the Unicode standard with ISO 10646 showed that 16 bits would not be sufficient for all of the characters in all of the world's writing systems; in order to fit CJK characters into that 16 bit encoding, a large effort was made to unify characters from different languages that represented basically the same thing but might be written slightly differently in Traditional Chinese, Simplified Chinese, Korean, Japanese or the historical Vietnamese writing system. Additionally, a lot of decisions had to be made about inclusion of historical or obscure characters, and so there were many characters which couldn't be encoded properly in early Unicode.

This led to Unicode 2.0 introducing a surrogate character mechanism, now known as UTF-16, in which certain unused ranges of code points were used in pairs to represent a wider range of code points, in order to expand Unicode from a single 16 bit plane of characters to 17 16-bit planes.

Meanwhile, Ken Thompson and Rob Pike adapted an earlier 8-bit encoding of ISO-10646 called UTF-1 into UTF-8, which had a number of desirable properties; it was a superset of ASCII, the interpretation of the ASCII subset of bytes never depended on state, and it was self-synchronizing, so if you started reading in the middle of a multi-byte character, you could always find the start of the next character.

This meant it was possible to use UTF-8 in all of the traditional APIs and file formats which were compatible with 8-bit extensions of ASCII; which meant that you could migrate to Unicode support without significant changes to APIs and file formats. Also, for text which consists mostly of the ASCII subset, which includes many ASCII-based markup languages, it was much more efficient than UTF-16.

In the early days, however, many languages and systems which adopted Unicode started doing so via UCS-2, and then with the advent of Unicode 2.0 and surrogate pairs, needed to adopt to UTF-16. This was done somewhat inconsistently, and it can cause a lot of pain and confusion.

I've already probably written more than is necessary, so I won't go into the history of each system, but a quick survey of a few popular platforms and languages and their native string encoding:

* C and C++: Support 8-bit unspecified encoding strings (char * , std::string), unspecified width wide characters (wchar_t * , std::wstring, which are 16-bit UTF-16 on Windows and 32-bit UCS-4 on most other platforms), and explicit widths (char8_t * , std::u8string, char16_t * , etc...) which are explicitly UTF-8, UTF-16, and UCS-4.

* Windows uses 16-bit wchar_t * , nominally in UTF-16 but not enforced, as its native string type, and also provides 8 bit APIs with character encoding which can vary at runtime

* Linux and other Unix systems generally use 8-bit char * in an unspecified encoding (which can vary at runtime) as their native string type; most systems these days are using UTF-8 as that 8-bit encoding, but it's not guaranteed

* Java, JavaScript, and C# all use UTF-16 as their native encoding, though in many cases there are still APIs which make most sense for UCS-2 rather than UTF-16.

* Python 2 used unspecified 8-bit encodings for the str type, and a custom encoding that supports all of Unicode for the unicode type. Python 3 changed so that the bytes type was 8-bit with unspecified encoding, and str type was Unicode in a custom encoding; a bytes type alias for str was added to Python 2 to ease the transition, as was a unicode type alias for str in Python 3

* Go and Rust use UTF-8 as their native string types

* Most text-based file formats, such as HTML, have standardized on UTF-8 as the backwards compatibility with ASCII is a big benefit for such formats.

There are a few references on why UTF-8 is generally a better choice for languages and APIs than UTF-16, despite some of the legacy use of UTF-16 in languages and APIs:

* [http://utf8everywhere.org/](http://utf8everywhere.org/)

* [https://www.cl.cam.ac.uk/~mgk25/unicode.html](https://www.cl.cam.ac.uk/~mgk25/unicode.html)

</comment></comment></comment></comment></comment><comment><USER31> Nice!

Sometimes I wish we had a basic "algorithms" language that was used absolutely everywhere, and every book everywhere teaching another language would assume the person knows how to program using the basic language and then teach the new language as a diff of the basic one.

Why do I say this? Because as someone who is versed in quite a few languages, I find the signal to ratio of these texts to be uncomfortable. For example, I know C really well, so the explanations of integer sizes are irrelevant, I know what is shadowing, etc., but the explanation of the return statements is really useful, the variable declaration is interesting, so I keep having paragraphs I can skip followed by paragraphs I have to read, followed by paragraphs I can skip, etc. I get tired quickly when reading like this.

</comment><comment><USER32> Word choices are very important. Yes we want to use smaller common words but not to the point of being misleading.

> Type inference means that if you don't tell the compiler the type, but it > can decide by itself, it will decide.

The word 'decide' implies that there was a choice that was made. I would think of inference more as 'determine' as the process is deterministic just not always successful. Or are there actual cases where the compiler infers a type that's close but not entirely correct?

</comment><comment><USER33> I think a wiki format might better suit this presentation. It's tough because you wash to be comprehensive but when you have one page, that means you'll have to clutter your document with all the comprehensive details. In a wiki, you can hide those details in deeper pages for only the more curious reader to find (or for those on their second read-through). Nevertheless, this document is phenomenal and I will refer to it in the future.

</comment><comment><USER34> As the author of a programming language ; ) I find this article very inspiring.

I just want those new to programming to understand the joy of systems and simple graphics programming like in the ol' Turbo Pascal days!

[http://www.adapplang.com/](http://www.adapplang.com/)

</comment><comment><USER11> The most interesting thing I've learned yet from this, and I'm not quite done with it, is that you can pass a constant (let) to a function, which can accept it as mutable, and therefore actually mutate data that the caller thinks cannot be mutated! I'm not sure how I feel about this.

<comment><USER35> Note that that is passing by value, so its moving/copying ownership. Its like having a immutable integer variable and copying it to a different mutable variable.

</comment></comment><comment><USER36> As a non-native English speaker, I can read this faster than my usual technical content! Great work!

</comment><comment><USER37> Such simple language allows my mind to instantly start composing syntax. Excellent work.

</comment><comment><USER38> this is great. it really helped demystify rust and get me started writing some. thank you.

</comment><comment><USER39> only `u8` can be cast as `char`, not `i32`

Can someone explain that in basic english?

<comment><USER40> Say you have eight books of equal size on a shelf. It's easy to put these eight books on another shelf of equal size or larger. If you have a shelf holding thirytwo books, it is impossible to fit them all on the smaller shelf, so it's better to simply not do it.

</comment></comment><comment><USER41> found this on reddit for this post:

"I applaud this. And it reminds me of the up-goer five. [https://xkcd.com/1133/"](https://xkcd.com/1133/")

<comment><USER42> You link doesn't work because of the double quote at the end.

Working link: [https://xkcd.com/1133/](https://xkcd.com/1133/)

<comment><USER43> Randall Munroe did a whole book in this style: [https://xkcd.com/thing- explainer/](https://xkcd.com/thing-explainer/)

It's a lot of fun.</comment></comment></comment>


6 Signs You Don't Care about Workers - <AUTHOR> http://www.businessweek.com/managing/content/jul2008/ca20080717_668877.htm?campaign_id=rss_topEmailedStories <comment><USER2> Should be called "6 Signs you don't care about your HR workers".</comment>


Controlling Times Square's Screens With a Phone, for Real This Time - <AUTHOR> http://bits.blogs.nytimes.com/2011/03/22/controlling-times-squares-screens-with-a-phone-for-real-this-time/?src=twrhp

<comment><AUTHOR> Discussion of original hoax: <http://news.ycombinator.com/item?id=2322401></comment>


Twitter Calls SOPA Shutdowns "Foolish" - <AUTHOR> http://news.cnet.com/8301-13506_3-57360068-17/twitter-shutting-down-for-sopa-thats-just-foolish-ceo-says/?tag=mncol;txt

<comment><USER2> I'm inclined to agree with Mr. Costolo that the blackouts are foolish, but not for the reason he cites. SOPA and PIPA are not just "single-issue national politics". If passed, they would have far-reaching and unforeseeable global consequences for the Internet.

However, I do regard the blackouts as ineffectual, as they don't send the right message to Congress and are too hostile ("hijacking" or "hostage-taking" come to mind).

I can't be the only one here who thinks the clamoring for blackouts by major websites is ill-thought-out, and might not produce the desired effect. They might even achieve the opposite of their intent, pushing Congress deeper into the pockets of Hollywood lobbyists and away from hostile tech companies.

<comment><USER3> the blackouts are drastic but they need to be to capture peoples attentions. If SOPA/PIPA passed the first site to go down wont be reddit it will be foreignmusicdemosharing.com. People dont notice slow gradual change and by the time they do it could be too late.

</comment></comment><comment><USER4> I tend to agree that I don't think it's the most effective way to change but i actually think tech should be much more hostile. Tech has much more revenue/resources than hollywood does and more leverage and should really be throwing their money around more. Politics is a game and it seems like tech is not willing to play the same way.</comment>


FingBox the HW companion to Fing (network scanner app) - <AUTHOR> https://www.indiegogo.com/projects/fingbox-wifi#/ <comment><AUTHOR> Disclaimer: I am a friend of one of the two guys that put this on Indiegogo, but I am not in any way involved or profiting from this.</comment>


Ask HN: Smart people sleep late? - <AUTHOR>

Some researches suggest that people with higher IQ sleep late. e.g., <http://bit.ly/OUp4m6> (google the keywords and you get bunch more)
However, this doesn't make sense to me because I personally know some brilliant people are morning type: maybe wake up at 4am or even 3am.
HN people, do you sleep late? Do you feel you have a higher IQ? <comment><USER2> Asking people to self-report their IQ will give you misleading results. I'd expect people with embarrassingly low IQs (in comparison to those IQs that are reported) to be less likely to comment.

I don't remember ever taking an IQ test... but my personal anecdatum is that I feel more productive when I have a regular sleep cycle, but that can involve waking up at 7am or 9am or earlier or later and what that depends on, beyond the seasons, I don't know.

</comment><comment><USER3> I have taken a few of those online IQ tests and they show to be well above average. I don't believe those tests to be accurate and more importantly I don't believe IQ is an accurate measurement of anything meaningful.

That being said I am an odd mix of morning person, night person. I function very well if I am out of bed by 6-6:30am, then I drop off about 11:00am. From 7pm-1am I again function at a high level. I typically only sleep about 4-5 hours per night and feel very groggy if I sleep more than that.

I agree with most of the other responses. I think your peak production period depends on the season, type of work and lifestyle.

</comment><comment><USER4> Not sure about IQ, but I remember when I had to prepare for some exam, in a subject uninteresting to me, I was procrastinating a whole day and only starting to study at 00:00 midnight till 3:00-4:00.

For me, it also depends on where I am. In the city - get up late, go to bed late. In the village/farm house - get up 5:00-6:00 morning, go to bed earlier, usually 21:00-22:00.

</comment><comment><USER5> I challenge the validity of the statements. There doesn't appear to be any good-quality research on correlation of IQ and sleep habits.

</comment><comment><USER6> I'm dumb as a rock and I sleep late/wake up early. Only get to enjoy REM on Sundays.</comment>


When Can I Reuse This Calendar? - <AUTHOR> https://www.whencanireusethiscalendar.com/ <comment><USER2> If your old calendar includes holidays, you'd have to remember to ignore the ones that are based on rules other than the Gregorian calendar (e.g. Easter was April 21 this year but will be April 14 in 2047). Clearly those holidays are just a conspiracy by Big Calendar to get us to buy more calendars.

Cool project otherwise!

</comment><comment><USER3> The real benefit of this is that for the next hundred years or so, you can continue to set your VHS Recorder's clock / calendar, which has only a two digit year. Some of them display weak day calculated from the year. So always setting the calendar year back by 28 years, for years after 2000 can extend your VHS unit's life an extra century or so.

<comment> streb-lo Wow great tip thanks.

</comment></comment><comment><USER4> If only people would be less set in our ways, you could use the same calendar every year:

[https://en.m.wikipedia.org/wiki/World_Calendar](https://en.m.wikipedia.org/wiki/World_Calendar)

<comment><USER5> It seems most dissenters are people upset that the calendar is incongruent with their favorite religious texts. If we change the calendar then we might invalidate creation myth, oh noes!

<comment><USER5> Upon second reading, I don't get it. There is still a saturday and a sunday and the other 5 days we are used to.

</comment></comment></comment><comment><USER6> Hands up, who headed straight to ebay looking for old calendars?

<comment><USER7> Why would you do that?

<comment><USER8> Because using a 1992 calendar in 2020 would be pretty cool.

</comment></comment></comment><comment><USER9> Does it take Easter into account? When is the last year that has the same days as 2019, and has the Easter(s) on the same days?

<comment><USER10> Just as a side note: here's an accepted official rule of Easter, which even itself has some differentiation - in my opinion - the craziest (that I know) rotating schedule ever:

 _Easter falls on the first Sunday after the Full Moon date, based on mathematical calculations, that falls on or after March 21. If the Full Moon is on a Sunday, Easter is celebrated on the following Sunday._

[https://www.timeanddate.com/calendar/determining-easter- date...](https://www.timeanddate.com/calendar/determining-easter-date.html)

<comment><USER11> > the craziest (that I know) rotating schedule ever

I'm guessing you aren't Jewish? Easter is based on the Jewish calendar, but they didn't want to admit that, so they came up with these crazy rules based on the Christian calendar to approximate the Jewish calendar. Easter is supposed to be three days after passover, and in many years, it is, but every few years they are way off and Easter is either a few weeks before or after the Seder.

</comment></comment></comment><comment><USER12> Yes! I love this! I once wrote a Python script for this same purpose. Thinking about that problem really gave me much more familiarity with the ins and outs of the Gregorian calendar.

<comment><USER13> I did something similar with perl and my university's bus schedule. I find those kind of simple, probably over-engineered projects where the time put in probably isn't worth it[1] to be really useful ways for learning something like times or dates far better than reading about it would.

At the very least it made sure I always knew how many days each month had!

1: [https://xkcd.com/1205/](https://xkcd.com/1205/)

<comment><USER14> Thanks. It indicates I would probably gain from automating entering my time sheets.

</comment></comment></comment><comment><USER15> So how many calendars do I need to buy, so that I don't need to buy any ever again?

<comment><USER16> 14? Seven for the years with leap days and seven for the years without.

<comment><USER17> You could get away with 7 if you're willing to switch calendars in the middle of the year. Buy one leap year calendar for each day of the week. If it's a leap year, use as normal. If it's not, on March 1, just switch to the calendar with the correct March 1 day.

<comment><USER18> This would be a lot easier if the year ran from March 1 to February 28/29\. Which it did, for the ancient Romans - so the additional day was at the end of the year. This also explains why September through December come from roots meaning 7 through 10, despite being the ninth through twelfth months.

</comment></comment></comment></comment><comment><USER19> Heh! Nice one :-) . I remember taking a competitive exam called CAT for admission to MBA. CAT is notorious for being highly competitive and also has some questions involving calendars. Some tricks and tips involving calendars here - [https://www.hitbullseye.com/Quant/Modern- Mathematics.php](https://www.hitbullseye.com/Quant/Modern-Mathematics.php)

</comment><comment><USER20> You can use this bash one-liner to enumerate all same-calendar-years of 2019 between 1900 and 2100.

      $ printf '%d\n' {1900..2100} | while read year; do printf "$year %s\n" $(cal $year | sed 1d | md5sum | cut -d ' ' -f 1) ; done | grep "$(cal 2019 | sed 1d | md5sum | cut -d ' ' -f 1)" | cut -d ' ' -f 1 | xargs
      1901 1907 1918 1929 1935 1946 1957 1963 1974 1985 1991 2002 2013 2019 2030 2041 2047 2058 2069 2075 2086 2097

</comment><comment><USER21> Alas, I wrote in my diary with a pen. I will have to turn the pages 90 degrees and write at right-angles. But having said that, I do keep calendars and diaries. This could actually work for me. As a humour point. An obsessional diary of the films I saw in London in 1985/6 would make a poignant backdrop to my current diarizing of more humdrum daily existence in 20xx

<comment><USER22> >Alas, I wrote in my diary with a pen. I will have to turn the pages 90 degrees and write at right-angles

I don't get it. Please explain?

<comment><USER23> The OP might be using "diary" the way some people use "planner," a notebook that comes hard-coded with days of week, date, and month written at the top of a given page

i.e. [https://plannerpads.com/media/wysiwyg/2016-EXCD-Green-SB- Spr...](https://plannerpads.com/media/wysiwyg/2016-EXCD-Green-SB-Spread.jpg)

Presumably this planner/diary has text in it that would be confusing to write beneath. One's messages from 1983 or whatever would conflict with the ones you're writing that are applicable to 2020.

If you turn it upside down, you know to only read text that's "right side up" when the notebook is upside down.

I could be wrong.

<comment><USER21> You are almost right. By turning 90 degrees, I am writing ACROSS the old words, not upside-down with respect to the old words. It becomes a cross- hatch.

Writing across, is how in the old days, people used to reply to letters. Didn't always work well for joined-up writing but worked well-enough.

The Diary was days-of-the-week. So, the same semantic intent as for a calendar wired to a specific year. I need monday to be the "right" monday.

</comment></comment></comment></comment><comment><USER24> Except all the Indian holidays would be on different dates :).

</comment><comment><USER11> I have some John Deere and Harley Davidson calendars that I got free in 2016. Let me know if anyone wants them to hold on to until 2044.

</comment><comment><USER25> Would be great to see the source code of this. I think the logic used would be fun to read.

<comment><USER26> I wouldn't be surprised if it was just a for loop checking for all the years in a range, whether they start on the same day of week, and are/are not leap years :)

<comment><USER27> The calculations are actually really easy. Note that the length of a (regular) year is 1 mod 7, which means weekdays slip by 1 day each year, except for leap years. Over the 400-year Gregorian calendar cycle, there are 97 leap years, for a total of 497 days of slip... so adding 400 years to the current calendar year will always yield the same calendar.

More specifically, there are 14 possible calendars. The leap year cycle is 4 days (excluding the 100 year skips), and the weekday cycle is 7 days, so the leap year×weekday cycle is 28 years. So the starting weekdays are on a 28-year cycle, but you have to slip your resulting calculation by the number of centuries from the beginning of the 400-year cycle (i.e., integer division of year by 100). You'll reuse a leap year calendar in 28 years (40 years, if it crosses a round-hundred year), and you'll reuse a non-leap year calendar in 6 or 11 years (12 or 6 years, if it cross a round-hundred year).

The easiest way to code it is to just precompute the year % 400 table and report the results.

<comment><USER28> > The leap year cycle is 4 days (excluding the 100 year skips)

I think you mean "The leap year cycle is 4 days (excluding the 100 year skips, except every fourth 100 years when they don't)," eg how 2000 _was_ a leap year despite this individual rule.

(I know it's accounted for elsewhere in the modulo logic, but you shouldn't resist the impulse to point out just how crazy it all is!)

<comment><USER27> The 400 year rule is already accounted for by taking the year mod 400. 2000, 2400, 2800, etc. will all use the same calendar.

<comment><USER28> Yes, I did mention you had it taken care of, just not explicitly pointed out :)

</comment></comment></comment></comment></comment></comment><comment><USER29> Love the FAQ about lunar cycles.

<comment><USER30> What's the deal with that URL that links to "pageok"? Just a dead website or deeper joke?

<comment><USER29> I'm guessing just a dead website.

</comment></comment></comment><comment><USER31> Ignoring leap years, the pattern within a century [1] is that the calendar for year Y, where Y is the 2-digit year, can next be reused in:

Y+6 if Y is of the form 4N or 4N+1

Y+11 if Y is of the form 4N+2

Y+5 if Y is of the form 4N+3

If you start at a 4N year, this takes you to a 4N+2 year, then 4N+1 year, then a 4N+3 year, and then back to a 4N year, so you'll step through the century in steps of 6, 11, 6, 5, and repeat.

So, for 2019, 19 = 4x4+3, and we at at the add 5 stage of that 6, 11, 6, 5 pattern, and so (ignoring leap years) we get the same calendar in 2019+5 = 2024, 2024+6 = 2030, 2030+11 = 2041, 2041+6 = 2047, 2047+5 = 2052, 2052+6 = 2058, 2058+11 = 2069, 2069+6 = 2075, 2075+5 = 2080, 2080+6 = 2086, and 2080+11 = 2097.

Now it is time to stop ignoring leap year. 2019 is not a leap year, so strike from that list any leap years, leaving 2030, 2041, 2047, 2058, 2069, 2075, 2086, and 2097.

Note you can also go backward. 2019-6 = 2013, 2013-11 = 2002.

Another way to do this, perhaps simpler, is to note that two 2-digit years, Y1 and Y2, in the same century have the same calendar (ignoring leap years) if Y1 + Y1//4 == Y2 + Y2//4 mod 7.

The smallest year for which Y + Y//4 == K mod 7, for K=0,1,2...,6 is: 0, 1, 2, 3, 9, 4, 5.

So, back to 2019. 19 + 19//4 == 2 mod 7, which we see from the prior paragraph first occurs in 2002. That's a 4N+2, so we start the 6, 11, 6, 5 pattern at 11. Get the next three years that match 2002 from that pattern: 2013, 2019, 2024.

You could continue the cycle from there to finish off the century, buy perhaps easier is to note that the whole pattern of calendars and leap years repeats every 28 years.

28 years added to 2002, 2013, 2019, 2024 gives 2030, 2041, 2047, and 2052. Another 28 years gives 2058, 2069, 2075, and 2080. Next is 2086 and 2097.

Let's bust out of our confinement to the current century. Century C has the same calendars as century C+4, so our 2019 calendar will work in 2402, 2413, 2419, and so on.

Using 2000 as the base, whenever we cross a century boundary within the current 400 century span, it is like adding 5 to the Y + Y//4 value.

For 2019 we were using 19 + 19//4 == 2 mod 7 for our target. When we cross into the 2100s we pick up 5, and so need to subtract 5 from that 2 to compensate. Remember, we do all that mod 7, and the result is 4. In the 2100 century, then, we are looking for years with Y + Y//4 == 4 mod 7. As we saw 6 paragraphs back, 2109 would be the first such year.

2109 is a 4N+1 year, which puts us at the second 6 in the 6, 11, 6, 5 pattern, giving us 2115, 2120, 2126 as the other matching years in the first 28. Repeat those every 28 to fill with the 2100s.

Don't forget to delete the leap years!

Note: the calendars for the leap years are only off during January and February. You can go ahead and use, for example, the 2019 calendar in 2024 for March through December.

[1] for our purposes, century == fullyear//100, in Python 3. E.g., the current century is [2000, 2099].

<comment><USER32> This reminds me of the efforts I made to answer the following question from a Soviet puzzle book I happened upon."Does New Year's Day fall more often on a Sunday or a Saturday?". I will leave the working out of the answer to the curious.

</comment></comment><comment><USER33> Someone needs to send this to Kavanaugh

<comment><USER29> Who?

<comment><USER34> I guess we are talking about the newest justice of the US Supreme Court. His nomination was controversial because of multiple sexual assault allegations and his overall questionable character. I don't really get the connection to calendars though.

<comment><USER13> Part of the "evidence" from his lawyers was Kavanaugh's high school calendar over the summer in question (1982): [https://www.pbs.org/newshour/politics/see-four-months-of- bre...](https://www.pbs.org/newshour/politics/see-four-months-of-brett- kavanaughs-calendar-from-1982)

Supporters said it showed no party, which was where the assault occurred. Detractors said it didn't prove a negative and that numerous events were suspicious. Everybody was shocked that someone would keep a high school calendar for 35 years.

This is all offtopic but per the site, a 1982 calendar would next be reusable in 2021, 2027, and 2038.</comment></comment></comment></comment>


The types of attachments we see in malware email - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/spam/MalwareAttachmentTypes-2019-03 <comment><USER2> It really depends on your userbase and email security solutions in my experince.

Two things that make me question this stat: after tens of thousands of manual phishing email screening at multiple orgs I have never,not once witnessed a phish that used a .txt attachment for payload delivery. Second,I see a _ton_ of phish delivered via pdf attachments. Are they considering malware delivery phish the same category as credential theft phish (frauduent sites that social engineer users for their logins)? If so,that's counting apples with oranges.

For malware delivery,if you have a good email security solution in place, word documents should be #1.

You should block zip attachments that contain specific types of files. Blocking zip or rar as a category makes little sense. Scripts of any kind,executables,jar files and such in a zip file should result in a quarantined email.

If you can't afford a decent email security appliance: setup a cuckoosandbox instance,detonate attachments and quarantine (for human review) any attachments that generate network activity or drops suspicious files. Also quarantine word documents with macros (yara rule analysis).

I would also see a lot of value in blocking google drive,onedrive and dropbox. A common phish in 2019 would be exploitation of compromised email accounts,the attackers would reply-all to email threads with links to something like onedrive. Instead of sending the file as an attachment,they host it on Onedrive. This kills two birds with one stone:the file is hosted on a trusted platform and they avoid attachment filtering.

Lastly,unpopular opinion: user education does not help much. Fix the tech,not the user.

</comment><comment><USER3> Follow up about "good" attachments is worth a read too: [https://utcc.utoronto.ca/~cks/space/blog/spam/GoodAttachment...](https://utcc.utoronto.ca/~cks/space/blog/spam/GoodAttachmentTypes-2019-03)</comment>


Lifehacker Pack for Android: Our List of the Best Android Apps - <AUTHOR> http://lifehacker.com/5616299/lifehacker-pack-for-android-our-list-of-the-best-android-apps <comment><USER2> Excellent list; no battery-killing "task killers", for once!

</comment><comment><USER3> Does anyone use <https://snaptic.com/> ? I've been using them for a while, and they're awesome. Awesome web-based interface along with a native iOS and Android app. I haven't been able to find anything better than them so far.

<comment><USER4> Thanks for the kind comments Harry!

We just launched our new Google Closure based webclient today, lots of spiffy new stuff coming. Stay tuned!

Feel free to contact me at aschobel (@) snaptic.com

<comment><USER5> I thought Chrome pulled in some really bad font, but apparently your designer thought "text-shadow:1px 1px 1px white;" was a great idea to use on your website. Will I blow some circuits if I look at the actual application? :-)

<comment><USER6> I'll second that the text is a little hard on the eyes. Won't go so far as to say that I'll blow a circuit reading it, and I'm definitely gonna check Snaptic out, but a easier-reading font would be nice!

</comment></comment></comment></comment><comment><USER7> ConnectBot

Terminal emulator

Soundcontrol widget

Stopwatch

Realcalc

Aldiko

Auto rotate switch

Gesture search

Wifi analyzer

Voice recorder

Smooth calendar

Now my nexus is almost as useful as my old e61i.

Too bad I can't download a real keyboard</comment>


Ask HN: Security Strategy Buildung Blocks - <AUTHOR> An IT security strategy aims to ensure confidentiality, integrity, and availability of IT systems and information. This has to be traded off against economic and practical realities. What building blocks do you consider for a security strategy?
Examples are
- Deep defense. Consider everything hostile. No unencrypted traffic over the network. Spectre attacks matter a lot because you cannot trust other users on the host.
- Tough on the outside, soft on the inside (also M&M security). Try hard to keep bad guys of your intranet but trust your internal users. Spectre attacks don't matter because you trust the other users on the host. <comment><AUTHOR> _Log, monitor and punish_. If data has to be readily available but should only be used for intended purposes.

I.e. in a hospital medical data has to be immeadiatly available to all medical staff to react quickly. However, if medial data leaks (i.e. about a celebrity or in large scale) the bad guy can be caught by looking at the access logs to the data.

</comment><comment><AUTHOR> _Data avoidance_. Data that is not collected does not have to be protected and is automatically confidential.</comment>