Blocklist of all Facebook domains - <AUTHOR> https://github.com/jmdugan/blocklists/blob/master/corporations/facebook/all <comment><USER2> Not the way I'd do it, since you can easily miss on some new domain that belongs to facebook (or perhaps some server that does not look like it belongs to facebook in the first place, but it is sitting in their assigned subnets).

If you really want to block all traffic from/to facebook, lookup the IP prefixes associated with their AS number(AS32934), and setup your firewall to block those. If you are using PF, tables are your friend. With netfilter, consider using ipset.

<comment><USER3> Facebook only has one AS?

<comment><USER4> That's fairly typical.

An AS (identified by an ASN) is an _autonomous system_. It's comprised of multiple _CIDR blocks_ , contiguous regions of IP addresses. The _network definition_ (by CIDR block) is fairly dynamic, as blocks can be added, deleted, or consolidated.

An autonomous system is _a single administrative domain_ over public IP space. Essentially, autonomous systems _are what the Internet is inter-networking between_ , through BGP (border gateway protocol). BGP and AS are what Cisco (and other router) gear are ultimately all about.

So yes: organisations typically have one AS. Exceptions are typically the result of corporate mergers (not uncommon) or government space (where the domains are large).

(Disclaimer: I'm not a networking bithead, don't muck with routers much, and have a rough knowledge of much of this, though it should be vaguely accurate.)

<comment><USER5> And if you end up with more than one AS due to a merge, you usually pick one them as your primary and connect the other ones to it, then announce their prefixes from your primary, ie. your primary AS becomes transit for your other ones. That way you only have to maintain one external border.

</comment></comment></comment></comment><comment><USER6> It's inefficient to specify a large number of hosts in the facebook.com domain instead of blocking the whole domain.

For this, you can run dnsmasq and use the "\--address" option or "address" command in dnsmasq.conf:

      $ man dnsmasq
      [...]
           -A, --address=/<domain>/[domain/]<ipaddr>
                  Specify an IP address to  return  for  any  host  in  the  given
                  domains.   Queries in the domains are never forwarded and always
                  replied to with the specified IP address which may  be  IPv4  or
                  IPv6.  To  give  both  IPv4 and IPv6 addresses for a domain, use
                  repeated -A flags.  Note that /etc/hosts and DHCP  leases  over‐
                  ride this for individual names. A common use of this is to redi‐
                  rect the entire doubleclick.net domain to  some  friendly  local
                  web  server  to avoid banner ads. The domain specification works
                  in the same was as for --server, with  the  additional  facility
                  that  /#/  matches  any  domain.  Thus --address=/#/188.8.131.52 will
                  always return 22.214.171.124 for any query not answered from /etc/hosts
                  or  DHCP  and  not sent to an upstream nameserver by a more spe‐
                  cific --server directive.

<comment><USER7> Is there the concept of an 'administratively prohibited' error in the DNS? So your resolver could return an error with that code rather than an incorrect result.

<comment><USER8> NXDOMAIN [1] ?

Dnsmasq can return nxdomain responses

echo 'server=/.example.tld/' >> /etc/dnsmasq.conf

Check dnsgate [2] or FreeContributor [3]

[1] [https://www.dnsknowledge.com/whatis/nxdomain-non-existent- do...](https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/)

[2] [https://github.com/jakeogh/dnsgate](https://github.com/jakeogh/dnsgate)

[3] [https://github.com/tbds/FreeContributor](https://github.com/tbds/FreeContributor)

</comment></comment></comment><comment><USER9> Alternatively you can use Adblock to block it.

[https://secure.fanboy.co.nz/fanboy- antifacebook.txt](https://secure.fanboy.co.nz/fanboy-antifacebook.txt)

Disclaimer, list Author.

<comment><USER10> Your list blocks fewer things, though.

<comment><USER9> When a site adds Facebook it's using connect.facebook.* the main bulk of the list is just whitelists for Facebook users (first-party). The hosts file will break all of Facebook even if you visit it directly. The better option is to just block Facebook outside of Facebook.

<comment><USER11> No. The better option is to just block facebook _everywhere_ , including direct access.

Just my humble opinion.

</comment></comment></comment></comment><comment><USER10> If you're blocking Instagram, shouldn't you be blocking the Oculus Rift site (and any subdomains) too?

<comment><USER12> Not really, Instagram is a social network, Oculus is a device?

It depends on the purpose of the list, of course, but for me they're very different.

<comment><USER13> Knowing corporate org charts for what they tend to be, reporting and analytics initiatives, and any server statistics therein, are considered revenue generating information (leads), and thus subject to agreements for the exchange mutually beneficial data sets.

Across my various jobs, I've had to write reports for departments, and open up permissions to internal people, to give read access for things they'd have no natural reason to care about.

If data is being collected at all, weird people will be looking at it. If not today, maybe tomorrow. But, no matter when, it's there for the looking whenever some internal lookie-loo decides it might be interesting.

</comment></comment></comment><comment><USER14> No need do this, come to China prepared everything for you like this.

<comment><USER15> Well technically speaking, because of the way the Great Firewall works, you might still be able to get some packets if the server is fast enough.

</comment></comment><comment><USER16> This does just the same: _.facebook.com_.facebook.com _.fbcdn.com_.fbcdn.net _.facebook.com.edgekey.net_.facebook.com.edgesuite.net _.instagram.com_.instagramstatic-a.akamaihd.net _.instagramstatic-a.akamaihd.net.edgesuite.net_.cdninstagram.com _.tfbnw.net_.whatsapp.com _.fbsbx.com facebook-web-clients.appspot.com_.fb.me fbcdn-profile-a.akamaihd.net h-ct-m-fbx.fbsbx.com.online-metrix.net ac-h-ct-m- fbx.fbsbx.com.online-metrix.net

<comment><USER17> You can't do wildcards in a hosts file.

<comment><USER4> You can with dnsmasq.

[http://www.thekelleys.org.uk/dnsmasq/doc.html](http://www.thekelleys.org.uk/dnsmasq/doc.html)

</comment></comment></comment><comment><USER18> I've been blocking facebook for years (nowhere near as comprehensive as this list though).

Many of the most unfortunate problems with these sites are social in nature rather than technical. For example, no matter how much I plead with people not to, they keep uploading information about me to these type of sites, including photographs with timestamps and GPS location metadata, which they then "tag" my face as being me.

I don't have any idea how much of this information is even out there, since these sites require signing up in order to find out. Maybe I should look into my rights under data protection legislation...

<comment><USER19> Who are you that you are so worried about this?

<comment><USER18> This question sounds a little too close to "nothing to hide, nothing to fear" to me, but in any case I think it's Facebook, attempting to build dossiers on billions of people for profit, who need to justify themselves; not me for wanting to remain undocumented.

As far as concrete reasons go, I've had to deal with far too much fallout from being incorrectly flagged by braindead processes trawling private databases which I didn't even know I was in. Since lots of these databases share information, but not necessarily updated corrections, I still run into the same mis-flagging every few years, across utilities, courts, credit agencies, banks, letting agents, etc.

As far as Facebook goes, being a citizen of the CCTV-riddled UK makes me acutely aware of the power, and potential abuse, that facial recognition technology can bring; having images of my face tagged and fed into a database does not sit well with me.

Since I don't use Facebook, I don't even get the meagre upside of whatever services they build on top of this database (some kind of gallery, I presume).

</comment></comment></comment><comment><USER20> Would wildcard support in hosts files be too heavy for the performance needed? Most of these are subdomains that *.facebook.com would have blocked.

<comment><USER21> My first impression when I saw it was something along the lines of "this would be so much cleaner if one were writing this as a dnsmasq config"

<comment><USER8> I agree. From this project I discover FreeContributor [1], which use dnsmasq has a DNSBL.

[1] [https://github.com/tbds/FreeContributor](https://github.com/tbds/FreeContributor)

<comment><USER22> Is it possible to apply this at the network level? I want to update my home router easily so that all devices in my home can benefit, not just my own laptop (since most of these lists are just updating /etc/hosts)

<comment><USER8> Is it possible to apply this at the network level?

Yes. Please check pi-hole project [1] or flash your router with open-wrt/dd- wrt and run dnsmasq with the FreeContributor lists.

[1] [https://pi-hole.net/](https://pi-hole.net/)

<comment><USER22> sweeeet thanks.

do people usually do this directly on their FIOS router or is it easier to get a separate wifi router?

<comment><USER22> oh you configure the fios router to use that as your dns:

[https://pi-hole.net/faq/can-i-set-the-pi-hole-to-be-the-dns-...](https://pi- hole.net/faq/can-i-set-the-pi-hole-to-be-the-dns-server-at-my-router-so-i- dont-have-to-change-settings-for-my-devices/)

good stuff

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I can understand the multiplication of sub domains, to be able to use multiple connections. But what's the rationale for the multiplication of domain names? Ad blocker avoidance?

<comment><USER24> Maybe separation of cookies?

</comment></comment><comment><USER25> I just want to say "Privacy matters, thanks you" (even more when FB decided to leverage their like/share button for a global ad netwotk) :-) non tech saavy guys may love a simple .sh / .bat to automatically add those entries to the /etc/hosts on windows & unix

<comment><USER26>
        curl https://raw.githubusercontent.com/jmdugan/blocklists/master/corporations/facebook/all | sudo tee -a /etc/hosts

<comment><USER27> Data straight from the net into a system file as root...

You are a bad, bad man Mr Rochacon.

</comment></comment></comment><comment><USER28> I'm sorry, I've been away for a couple of hours... What happened ?

Why should I (we) block all facebook domains ?

<comment><USER29> This is probably a reaction to the news that Facebook is now officially tracking non-users to create shadow profiles and serve adverts to them off Facebook itself. I think it's the serve-adverts-off-Facebook-itself part that's the actual news; all of the moderately chilling tracking and profile construction was of course happening already.

[http://www.theverge.com/2016/5/27/11795248/facebook-ad- netwo...](http://www.theverge.com/2016/5/27/11795248/facebook-ad-network-non- users-cookies-plug-ins)

<comment><USER30> And yet, Google started going down a similar path since December 2009 when they introduced personalized searches for non-logged-in users and nobody tries to block them.

<comment><USER31> The problem with blocking all google doains is the amount of sites it would break. Youtube, gmail, googleapis for js libraries, google's blog platform, maps based on google maps and more would break.

<comment><USER32> Technically true, but blocking all Facebook domains breaks comments on many sites and the login feature on a few crucial ones too.

<sarcasm>It also 100% breaks your social life, but maybe there's little of that left to disrupt anyway, amongst the typical target audience for these lists :P</sarcasm>

<comment><USER33> It's actually the other way around. Normal people have managed their social lives without facebook for generations. It's only the recent crop or two who seem unable to do it.

<comment><USER32> No, "Normal people" who care about their social lives use whatever their friends use to get together at the time. Nowadays this is social networking sites, i.e. Facebook.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> Will there be a point where the government will step in or is all of this tracking within fair use of non-logged in Facebook users visiting a website?

<comment><USER35> I doubt it. Judging by history, it's more likely they'll demand access to all that data.

<comment><USER36> > they'll demand access to all that data

Snowden has made it clear that that government grants itself direct access, whatever the legal situation really is.

It's also become clear that the government lets itself get away with it. And that there is no resistance from the voters who voted the politicians in and are paying not only for the politicians' salaries but also for their own total surveillance.

</comment></comment></comment><comment><USER37> Should you not also include `::` IPv6 entries?

</comment><comment> iam-TJ With the help of a couple of prefix aggregation tools [1] [2], the BASH shell, and the RIPE database, it is straightforward to block any Autonomous System with, e.g:

        $ ASN=32934; for IP in 4 6; do \
         whois -h riswhois.ripe.net \!${IP/4/g}as${ASN} |\
          sed -n '2 p' | tr \  \\n | aggregate${IP/4/} |\
           while read NET; do echo ip${IP/4/}tables -I OUTPUT -d ${NET} -j REJECT;\
         done; done

(note this command uses _echo_ to show the command it could execute)

[1] aggregate [http://packages.ubuntu.com/source/xenial/aggregate](http://packages.ubuntu.com/source/xenial/aggregate)

[2] aggregate6 [https://github.com/job/aggregate6](https://github.com/job/aggregate6)

</comment><comment><USER38> I'm wondering ... what's the best approach to automatically collect all domains of a company?

<comment><USER39> there is no consistent way of defining the meaning of "all domains of a company". Who pays for the registration? Which email is listed as technical contact? Who has the authority to change DNS-records? Which email listed in the DNS SOA-record?

</comment></comment><comment><USER40> Oh wow, I didn't know it were that many, I had like 20 in my hosts file. Thanks!

</comment><comment><USER41> Aside from being easier to automate, getting IP's via the ASN lookup is also better for blocking HTTPS requests when you are MITM, since the HTTPS request will only contain the IP and not the FQDN.

Also, many firewalls do a 1-time DNS lookup of a given FQDN to resolve a single IP address when a FQDN based rule is created. This doesn't work well if you have an FQDN that can resolve to many different IP's, which is typical for cloud services.

<comment><USER42> TLS connections from browsers usually include the SNI extension that has the destination host name in clear text. It requires an TLS specific blocker, rather than IP firewalling, but is probably more flexible. You could also just block the names in DNS.

</comment></comment><comment><USER43> Isn't Ghostery a better solution for something like this? If we are talking about browsers that is.

<comment><USER44> This uses less system resources.

</comment></comment><comment><USER45> Slightly off topic: It would be nice to have some kind of extension for Chrome that blocks all Time-Wasting websites with one click. Has anyone seen something like that?

<comment><USER46> I discovered that using [https://chrome.google.com/webstore/detail/waitblock/kcnjfepp...](https://chrome.google.com/webstore/detail/waitblock/kcnjfeppclpdinikcljfjigoongebpkh) to add a delay before opening the time-wasting website actually works better when trying to procrastinate less. Waiting 60 seconds before Fb loads gives you enough time to think about whether you want to visit it, but is also not so inconveniencing that it would make you disable it straight away when you actually want to visit the site.

<comment><USER47> It's really interesting. It kind of turns your impulsiveness against itself, so your monkey is saying "Ugh, waiting for Facebook is boring, let's do something else."

</comment></comment></comment><comment><USER48> Did you add the Facebook Tor Onion address?

facebookcorewwwi.onion

Might as well make it a complete block. Make sure those creative types don't find that last alternate path to FB.

</comment><comment><USER19> This list is missing the very obvious messenger.com

</comment><comment><USER49> It is faintly terrifying just how long the list is.

<comment><USER2> Considering the infrastructure Facebook is running, it's really not IMHO.

</comment></comment><comment><USER50> Do you how to apply this just for my user on OS X? My partner is heavy FB user and I don't want to block her...

<comment><USER51> uBlock Origin can handle hosts files, so you can just add it on the bottom of the Third Party Filters tab. It will auto-update it too.

[https://raw.githubusercontent.com/jmdugan/blocklists/master/...](https://raw.githubusercontent.com/jmdugan/blocklists/master/corporations/facebook/all)

<comment><USER52> Though hosts files can be fed to uBlock Origin ("uBO"), it will enforce their content differently.

With uBO, a "facebook.com" entry in a hosts file will also cause _all_ subdomains of "facebook.com" to also be blocked, so there is no need to list all subdomains as is done here if the goal is to block "facebook.com" with uBO.

If one wants to block Facebook via uBO, I personally advise to do it through dynamic filtering[1]. This way one can always point-and-click to create exceptions on a per-site basis.

[1] [https://github.com/gorhill/uBlock/wiki/Dynamic- filtering:-to...](https://github.com/gorhill/uBlock/wiki/Dynamic- filtering:-to-easily-reduce-privacy-exposure)

<comment><USER51> Well, if my goal is to block all of Facebook's domains, I wouldn't complain if uBO happens also to block new.sub.domain.fbcdn.net even if it's not in the hosts file :)

Does uBO optimize these cases, though? E.g. if there's "apps.facebook.com", "connect.facebook.net" and plain "facebook.com", does it collapse to just 1 filter (facebook.com)? I see it says "880 used out of 881" which is the number of entries in the file.

</comment></comment></comment></comment><comment><USER53> Im going to start trying this out. Awesome. Also as marios said block AS32934's networks.

</comment><comment><USER44> Any idea of an easy/quick way to toggle these edits on/off on Ubuntu?

<comment><USER54> I've put them in my host file and created an alias that switches between naming the host-file "hosts" (which will be recognized by the OS) and hostx.

from my .zshrc:

#block Twitter, Facebook, reddit and Linkedin. alias on="sudo mv /etc/hostx /etc/hosts" alias off="sudo mv /etc/hosts /etc/hostx"

<comment><USER44> Awesome! Thanks.

</comment></comment></comment><comment><USER44> >On Windows 7, the default AV security scan will try to remove the # facebook.com entry

Wat?

<comment><USER21> I'm guessing some sort of crude malware tried to MitM Facebook logins so they started cleaning host files?

<comment><USER55> Microsoft was an investor in Facebook, [http://whoownsfacebook.com](http://whoownsfacebook.com) and they are planning an undersea cable between the US and Europe that will only be used by the two companies.

<comment><USER44> What for? I can see Trading companies doing that but why would Microsoft/Facebook need that?

<comment><USER56> they are trading data

</comment></comment></comment></comment></comment><comment><USER57> So awesome. Facebook: Server not found

</comment><comment><USER58> IMHO the only way to block things efficiently is via a proxy these days, IP/domain-based blocking are not reliable or efficient.

<comment><USER59> What can you set up on proxy that you can't set up on your machine?

</comment></comment><comment><USER60> Thank you! Now I can censor, too

</comment><comment><USER61> Honest question because I seriously don't know: Is facebook really worse than google when it comes to privacy?

I kind of wonder who exactly are the people telling everyone to block facebook everywhere while everyone seems to collectively ignore google.

Google and facebook seem to both purposely ignore the known implications of their data collection programs. They likely have handed over data to the NSA, and we know they sell the data.

<comment><USER62> Not really. We know that they sell ads which can be targeted to users with specific characteristics. If you have discovered actual user data for sale from Google or Facebook, that's news.

</comment></comment><comment><USER63> This is awesome. Facebook needs to go to the graveyard with friendster, myspace and AOL.

</comment><comment><USER64> dramatic and useless.

</comment><comment><USER65> I would actually do it for Google. But, we all know we have became to dependent on them.

</comment><comment><USER66> Who really cares?

<comment><USER63> Facebook is a disease on the net, the next aol.</comment></comment>


Why we send our friends investor updates - <AUTHOR> https://blog.yalabot.com/why-we-send-our-friends-investor-updates-about-our-startup-a96fd012f453#.idcbma52t <comment><USER2> I love this idea. Investor updates are one of the little things that feel painful to do at first, especially if you don't have much traction, but end up being quite impactful in terms of building relationships. People look at you differently when they can see & be part of the whole story behind your company, not just the façade you put forward at meetings, parties and such.

The one critique of this essay I have is that the suggested investor update format is too long. I would cut it to two graphs, one or two sentences on metrics, and at most five bullets giving updates on company priorities and where you need help.

</comment><comment><USER3> We ([http://www.opencagedata.com](http://www.opencagedata.com)) are sending such updates. Only 3-4 metrics, less blog articles and more open thinking about future plans, priorities, conferences we attend. 6-8 paragraphs. We ask for feedback but at the same time stress that it's optional.

We get praise for being open, honest, on-time (once per month) and even send updates if there isn't anything new.

We're self-funded so strictly we don't have to send anybody any updates (other than the tax office).

<comment><USER4> Off topic, but is there a technical reason to limit the Large package to 15 requests/sec ? Multiply that with the number of seconds in a day, and you'd go over your limit of 1M/day less than 30%. Even with minor fluctuation in traffic, you'll have dropped requests.

<comment><USER5> Hi,

one of the co-founders here. If this is keeping you from becoming a large customer let's chat, happy to find a solution for you. Please ping em via the contact form on the site

</comment></comment></comment><comment><USER6> | Illustration by Lssey Miyake

Actually, the illustration is by wdart[1], and the title is Lssey Miyake, a reference to the BaoBao bag in the illustration[2].

[1] [https://dribbble.com/shots/2722408-Lssey- Miyake](https://dribbble.com/shots/2722408-Lssey-Miyake)

[2] [http://isseymiyake.com/en/brands/bao_bao.html](http://isseymiyake.com/en/brands/bao_bao.html)

</comment><comment><USER7> Good stuff.

Try to always link to your website in your blog post. Read this post and the example, yet didn't visit their product as there was no link to it.

<comment><USER8> The very first link in the article is to their website.</comment></comment>


Show HN: Sysdig, a tool for Linux system exploration - <AUTHOR> http://www.sysdig.org/

<comment><USER2> The tool looks amazing but...

This page is interesting: [http://www.sysdig.org/wiki/sysdig- examples/](http://www.sysdig.org/wiki/sysdig-examples/)

This page is not: [http://www.sysdig.org/](http://www.sysdig.org/)</comment>


iBackpack - <AUTHOR> http://ibackpack.co/

<comment><AUTHOR> Smart backpack with a battery, WI-FI, multiple USB ports, mobile app (iPhone, Android, Apple Watch, Android wear, bluetooth proximity locator.</comment>


Ask HN: could HN threads be upvoted using machine learning? - <AUTHOR> Could HN threads be upvoted using machine learning based on the comments (read/write behaviors)?<p>EDIT: in a way that would satisfy the current HN audience of course <comment><USER2> By the time threads start getting multiple comments, they've gotten enough exposure from humans to upvote them to the front page if they deserve it.

More interesting is to scan new submissions, download the article and run a model to predict whether it's interesting enough to upvote. You can start by scanning old articles and trying to predict votes.

A major challenge is detecting dupes, follow-on articles and blogspam where the text looks relevant, but the topic has already been covered.

<comment><AUTHOR> > More interesting is to scan new submissions, download the article and run a > model to predict whether it's interesting enough to upvote. You can start by > scanning old articles and trying to predict votes.

While I see why you see that as interesting, I think that submissions should not be filtered by a computer based on content for quasi-ethic reasons.

<comment><USER2> Do you believe any automatic content-based ranking is unethical? Even filtering exact duplicates? Or just some? If so, can you elaborate?

</comment></comment></comment><comment><USER3> Yes</comment>


Stop cherry-picking, start merging, Part 1: The merge conflict - <AUTHOR> https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 <comment><USER3> I would normally rebase the feature branch onto master if I need fixes from master and no one else is working on it. Usually this is the case - <USER2> developer works on each feature in a feature branch until it becomes a Pull / merge request and gets commented on and eventually merged.

I will sometimes make a fix in a feature branch that should go onto master before the feature is ready, and cherry pick it to a new bugfix branch. Once it's merged, if you rebase the feature onto master git will normally sort it all out, or you can use rebase -i to skip the cherry picked commit manually.

<comment><USER4> Rebasing is great for branches you haven't pushed that nobody else is working on. For that case, definitely rebase before you push.

If that is not the case and you have previously pushed your branch somewhere remote already, rebasing would end up rewriting history and things get a bit more tricky. You can still get away with this if it is just you.

Now here comes the crux: if you have a branch that you've been working on for several days, you really should be pushing it regularly to remote so that you don't lose your work. Also you should be creating lots of small commits and create a giant commit that touches everything. So if you then go and rebase, you are potentially rewriting history for someone. If that is at all going to be an issue, the better solution is to create a new branch and push that (or for Github folk, create a new pull request).

Many bigger projects will be configured to flat out reject rebased histories overwriting existing ones. Most of the public projects only allow you to create pull requests that have to be accepted by someone with commit rights on the main repo. And many of those people prefer clean rebased histories when they are merging so that they can do a so-called fast forward merge where the history stays nice and linear. If you have a branch with lots of back and forward merges, that is likely not going to go down well. It makes reviewing a lot harder and you may be better off creating a new branch and then rebasing the old one on top. Typically you'll have a bit of work re-solving all the conflicts you resolved earlier. This is a good argument against long lived branches.

Cherry-picking is sometimes useful but it potentially creates issues for the subsequent merge (fast forward or not). The nice thing with the pull request model is that it is not the problem of whomever cherry-picked but only that of whomever created the branch. If there is a conflict, it would be theirs to sort out before they can get their PR merged. If you are cherry-picking small fixes, this is usually not a big issue and a perfectly valid way of solving a small issue without landing a lot of work in progress.

<comment><USER5> Rebasing is perfectly fine for shared branches, all you have to do is pull —rebase and push —force-with-lease when changing branch history.

I do this at work for all the feature projects I work on with my team.

You mostly run into problems when people get confused about what is happening when they see the branch history has changed.

Git histories are wonderful and immutable so messing around with commits is quite easy if you know how to move branches around to undo changes if you mess up.

<comment><USER4> Git histories are only immutable if you don't rewrite them with --force. That's why it's called --force. It means you messed up and need to rewrite history. Nice to have the option but probably not great to make it a habit to mess up your history.

It's a feature that gets turned off server side in bigger projects and on OSS projects you don't get to push your changes at all and instead you need to work to get people to pull your changes. I'd argue that's a great way to isolate yourself from people misbehaving on their own branches since it is entirely their problem to get their branch in a a shape where it is straight forward to pull (as in fast forward merge). Rebasing can be a valid tool to get there. Force push is not thing generally in such projects except maybe on your own private fork.

</comment></comment></comment></comment><comment><USER6> Stop merging if you need to cherry-pick [https://blogs.msdn.microsoft.com/oldnewthing/20180709-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20180709-00/?p=99195)

<comment><USER7> I agree.

If you need to move a fix into multiple branches, isolate that fix in its own branch to begin with. The entire branch is the cherry. Each target branch deserves its own merge because chances are, seeing as the thing is so critical, the merge needs adequate attention each time to get done correctly (causing more work and friction is sometimes healthy).

If you're reaching the end of your sprint and your branch isn't ready to merge, chances are the entire branch could use another sprint in the oven. You've completely run out of time and you want to isolate a few changes, that's great if you want to move fast and _break things._

In TFVC (and SVN, CVS, Perforce, etc.), branches are expensive. It has taken me months to "unteach" people at work antipatterns that arise due to that. Management still doesn't get it - there is this holdout perspective that branches have to be micromanaged. This was the only sensible way to manage the mess caused by TFVC+co.

If you're finding unusual degrees of friction with Git (Mercurial, Bitkeeper, etc.), chances are that you're artificially introducing issues caused by your legacy version control and trying to solve them. Start forgetting and unlearning.

<comment><USER8> SVN branches are not expensive. They use a copy-on-write.

[http://svnbook.red- bean.com/en/1.8/svn.branchmerge.using.htm...](http://svnbook.red- bean.com/en/1.8/svn.branchmerge.using.html#svn.branchmerge.using.create)

<comment><USER9> Good luck using hard links on Windows without accidents.

Apart from sarcasm, SVN branches use suffer-on-merge: creating a branch means immediate technical debt of the most useless kind, which is more expensive than any inefficient file copying.

From the same manual:

"To perform a sync merge, first make sure your working copy of the branch is "clean"—that it has no local modifications reported by svn status."

"One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Subversion working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions."

</comment></comment></comment></comment><comment><USER10> This gets more complex when you have, for example, a volatile open source codebase as an upstream.

At work. we regularly merge upstream FreeBSD into our codebase, and run a suite of tests to make sure that we have not introduced a regression in performance or functionality. These tests take days to run, and roughly another day to analyze.

What causes a cherry pick is if we realize late in our release process that we're suffering from a bug that was fixed upstream (or that we can fix upstream). Since we're late in the release process, we don't want to take a full sync to the tip of the upstream master and consume potentially unstable changes, as that will mean re-running all our tests and resetting the clock on the release. So we cherry pick the fix (sometimes after committing it upstream ourselves).

<comment><USER11> Out of curiosity. What are you working on? A derivative of FreeBSD?

<comment><USER10> The Netflix CDN. We run a slightly modified version of FreeBSD.

<comment><USER12> Is this just the kernel, or the OS as a whole? This is probably a redundant comment, but maintaining a fork of a vendored product kind of defeats the purpose of using the vendored product. If at all possible I would recommend either to use the vanilla release, or fork it once and stop integrating. If you were shipping your custom FreeBSD to customers, and they were relying on it being FreeBSD plus your changes, I can see integration providing significant value. But since it's for a CDN, it's probably only being used by your team.

</comment></comment></comment></comment><comment><USER13> I only cherry-pick when it's the only commit of a feature branch that's going to be removed anyways. If development continued in that branch, I would merge master back into the feature branch again, or rebase the feature branch on master.

Not sure why, but I always knew from the beginning that cherry-picking is something not to be done from a live in-development feature branch without taking steps afterwards.

</comment><comment><USER14> How else do you get bugfixes onto a release branch when the main develop branch has already moved on? Should you rebase your feature branch on the release branch instead, then merge it?

<comment><USER15> Branch off the release branch for fixes to it. Then merge back into release and develop branch.

<comment><USER14> But what happens if it's a fix that was made to master. Then later, the boss decides that they need that change as a bugfix to the current release? How do you accomplish that without cherry-picking? Do you rebase the feature branch it was a part of and merge it?

</comment></comment></comment><comment><USER8> Looking through the comments, seems like stacked diffs would serve better in a lot of these cases...

<comment><USER16> Some background on stacked diffs in case people aren't aware:

[https://medium.com/@kurtisnusbaum/stacked-diffs-keeping- phab...](https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phabricator- diffs-small-d9964f4dcfa6)

I've been using stacked diffs for years now after trying various other git workflows, and I love the freedom it gives me. I almost always structure my work as a single branch (not a separate branch per feature), one commit per code review, and I'm free to edit, reorder, split, and combine changes as I please (mostly with interactive rebase). When a commit gets accepted, I just move it to the bottom of my stack (if it's not there already) and push it. It makes it easy to split changes into a "pipeline" of logical steps that can each be independently reviewed and landed, with multiple steps in code review at once.

I hate it when people treat dependent code reviews as an "advanced feature". They're only advanced if you make your workflow so advanced that they're hard to keep track of (many commits per review, many branches, merge commits). If you keep it simple (one commit per review, always rebase), that simplicity gives you much more power in other areas that IMO are more important.

I just wish it wasn't so much of a pain to get working in GitHub.

</comment></comment><comment><USER17> Merges is the stupidest thing there ever is in the land of source control. Contrary to the author I struggle to find even a single use that would make merge merited.

My main point is that merges are not easily computable. comm3 = merge(comm1, comm2) is not a kind of function you can run and see for yourself. Instead it is a kind of hand wavy magic in which we declare that those two apples plus a lemon equals three mangoes. You throw the beauty of hash tree out of the window like an overdue christmas tree.

<comment><USER18> What's the alternative? Only work on master and only on one document at a time?

<comment><USER19> Rebase everything so you get a clean timeline without meaningless "merge of bla" commit messages. Can be made mandatory by turning your repo fast-forward- only.

<comment><USER18> I'm really bad at rebase, but doesn't rebasing a branch A onto branch B, remove all the history from A?

<comment><USER20> Rebase has a lot of options, including squashing many commits into one or more "good" commits. This is usually a good thing if you have commits that are "work in progress" commits. You can use squash/skip to avoid having commits in your history that break the project or feature, which is great if you use git bisect.

The major downside of rebase is that even if you don't squash/skip it _changes_ the hash of every commit. This is very problematic when others have ever checked out your branch locally, or made commits that haven't been pushed. It takes greater communication between the team in my experience.

<comment><USER21> > It takes greater communication between the team in my experience.

You can also, as a substitute for greater communication, establish a protocol around branch naming and follow it.

What works for us is using the word "release" and "wip" in our branch names. If a branch is a "release" branch, then it is safe to base other work on it. If a branch is a "wip" branch, then it is not safe for merging upstream.

These two are not exclusive. For example, you might have a branch "dev" and a branch "release", and maybe another branch "release-dev-wip" – these all have different properties. "release-dev-wip" is a short-lived merge target for features that might not be completed yet. It is not safe to merge this upstream, unless you've checked with all of your colleagues who merged feature branches to it, and they all certified that it is no longer "Work In Progress."

The key I think to make this protocol work is to distinguish between "feature branches" and "environment branches" – dev is an environment branch, and a permanent one, so it should not be rebased. Feature branches merge back to environment branches, and environment branches are deployable.

You can break this rule, say if someone hotfixes master, which is upstream from dev... but it should probably be an exception to do this, and not a regular occurrence, as many people may have already based their work on "dev" and they will all need to rebase on the new (rebased) dev, in order to get a clean merge later. This is where the communication is not always optional. It might be a better choice, if the hotfix is unavoidable, but the project is large and this type of communication is logistically impossible, to merge in reverse (checkout dev, then merge master – back to dev). It might be ugly, but it's considerate. Either way, there should be a clear protocol and no ambiguity on the matter of whether you have a feature branch or an environment branch when you hold it in your hand. Feature branches represent work, environment branches probably ought to just combine the work, and maybe keep a record of how it was deployed.

The branch "dev-wip" is a temporary environment branch – it might be deployed to a dev environment for example, but you should not expect it to remain permanently in the git history. At some point, perhaps it will be renamed to describe the features it contains, and then rebased and merged back to dev. If you merged your feature to it, you might expect that you will need to keep the feature branch around, so you can rebase it on "dev" or "master" later, and finally merge it back.

The whole branch might not get merged upstream at once. (You can also call it "release-dev-wip" and then, the person who looks at it will know that it may contain some completed features that for some reason were not ready to merge upstream, but perhaps should not be discarded entirely. I personally like to rebase wip branches on their upstream before discarding them, just to be sure I'm not throwing away someone's work that they may have thought they merged.)

Protocol is just a different form of communication that is done up-front. If you decide on a protocol and forget to explain it to your team before you implement it, you will obviously not have solved any problems. It's also important to be clear and confirm understanding, so that you can be sure nobody is imputing meanings that you didn't intend. Some teams might choose to only do prod deploys from the "release" branch, and that anything in the "master" branch must be safe to merge to release and send off to production. You could easily get yourself into trouble if you didn't understand when your team expects to work this way. Some teams might prefer to organize their releases on a "release" branch, and then use Continuous Delivery to trigger prod deploys when the release is merged to master. Other teams might prefer to use a tag for that.

Mostly I think we can all agree that you should not rewrite a commit once it has been tagged, but again, this is not something that is strongly enforced by git, so it may vary from team to team. If a release that was tagged broke prod, it might actually make sense to wipe that tag from history and reroute the master branch around it. I've never seen that, but I think you're right, the most important thing is to communicate with your team so there is no ambiguity around these kinds of expectations.

</comment></comment></comment></comment></comment></comment><comment><USER22> You should only use merging to merge two divergent or unrelated histories. Merging should be a tool you use infrequently. GitHub has trained you to do it wrong.

<comment><USER23> Github is respecting the original intention of git. For a long time it didn't even _have_ cherry-pick functionality.

<comment><USER22> Citation needed. So far as I can tell from reviewing git's source code, cherry-pick was there since at least September 2005, after which the trail runs cold because of a big refactor. Git's first release was in April 2005.

</comment></comment></comment><comment><USER24> Stop excessive branching if you can use feature flags.

<comment><USER25> This is only a good idea if the things you're working on are isolatable "features", and you have an explicit process for garbage-collecting old feature flags. Otherwise the combinational explosion of possible flags kills your testing over time.

</comment></comment><comment><USER26> Wonderful general Git resource: [https://github.com/k88hudson/git-flight- rules](https://github.com/k88hudson/git-flight-rules)

</comment><comment><USER27> Does anyone have any references / recommendations along the vein of "guide to branch strategies" for certain development methodologies? For example: working in sprints / AGILE, branches for testing/QA/user-acceptance environments, etc?

(While I would hope the answers to this question would be widely useful, I mostly work on C# applications, with less focus on JavaScript-based applications. Maybe that's relevant for deciding on strategy - hopefully not!)

<comment><USER28> The most commonly referenced references to read can be found by searching for GitFlow (heavier) and GitHubFlow (lighter).

Personally, I recommend the GitHubFlow and CI/CD for "agile", and never branching per-environment but there are almost as many opinions as there are developers.

</comment></comment><comment><USER29> This sort of discussion makes me even more grateful for patch-based systems (Darcs, and possibly Pijul) than does having to use git for apparently simple tasks required to make contributions to things.</comment>


Internet Archive Wayback Machine's New Beta - <AUTHOR> http://waybackmachine.org/

<comment><USER2> Looks pretty slick, but it still has the search-form glitch I run into _every single time_ :

Whenever I want to use it, I wind up pasting a URL that I copied from somewhere else into the URL input at top. My URL invariably starts '<http://>, but the '<http://> that's prepopulated in the form as rendered doesn't go away. So I wind up doing a search on '<http://http://whatever...>, which of course turns up nothing.

It may be some odd browser dependency, but I've seen it at least in several versions of Firefox...

</comment><comment><USER3> An explanation of what's new: [http://faq.waybackmachine.org/whats-the- difference-between-t...](http://faq.waybackmachine.org/whats-the-difference- between-the-classic-wayback-machine-and-the-new-beta-version/)

</comment><comment><USER4> It would be great if there was a combo of internet archive wayback machine + google fastflip-type browsing <http://fastflip.googlelabs.com/>

</comment><comment><USER5> a modern look is nice, but it doesn't really add any functionality that was missing. how long will it take for them to offer full-text search? could someone else provide it?

</comment><comment><USER6> Nice! Was long overdue for an update - wasn't a fan of the old site, and hated the inconsistencies in product names / branding. Thanks for sharing.</comment>


Lessons from last week's cyberattack - <AUTHOR> https://blogs.microsoft.com/on-the-issues/2017/05/14/need-urgent-collective-action-keep-people-safe-online-lessons-last-weeks-cyberattack/ <comment><USER3> The quote bombshell here, and what hasnt yet gotten much attention since sysadmins the world over are busy dealing with fallout, is that the NSA and therefore the US government is directly responsible for the current global cyber-carnage. We developed the capability, we chose to keep it unpatched, we tried to keep it secret, we lost control of it.

This has similarities in type, if not in horror, to the development and subsequent spread of nuclear weapons. When we lost control of those secrets, it was a BFD [0].

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

<comment><USER4> Complete BS. This is what happens when you have top class PR at your disposal to define the narrative.

Microsoft is responsible for their shit software getting exploited first and foremost. Seriously fine Microsoft and by day after tomorrow that 3500 security engineer number will jump to something realistic.

Instead what will happen is more tightening of the walled garden, overcharging of support/security contracts and propping up of another billionaire or two. I can hear the whisky glasses clinking.

Corporations do not get to set the agenda and the narrative. When they are allowed to, the results are very predictable - in this case Microsoft will make more than they loose. Who here disagrees that is going to happen? And who here believes that is right?

The answer is simple whether its Microsoft today or Facebook and Google tomorrow win-win should not be an option when such things happen.

<comment><USER5> Uh, except Microsoft had already patched the vulnerability, just not for XP that was still being run. Of course you can punish them and force them to support all legacy OSes forever, until that strangles the life out of them at which point large institutions _still_ have to run the old OS because they have too much investment in computer controlled hardware with no forward migration. Now they are locked into an insecure technology stack with no vendor to take responsibility and no source code to even take on the problem themselves.

There's plenty of blame to go around to be sure, but giving the NSA a pass for developing zero days is batshit insane. These guys are playing god instead of helping make infrastructure more secure overall, and it will not end well, even if they outcompete the Chinese or whatever other bogeyman they cook up to justify their power grab.

<comment><USER6> This is why free software is necessary.

Proprietary software makes you rely on a company to fix _everything_. It's like driving a car without being able to replace a flat tire.

<comment><USER7> Assuming these hospitals keep updating and do not get stuck at Ubuntu 10.04.

<comment><USER8> Anyone can seek help on the open market to support Ubuntu 10.04 forever if they like. You can't go to another company if you don't like the price Microsoft sets for support for Windows XP.

<comment><USER9> This comment makes my blood boil. Please ask yourself:

1\. why would anybody want to keep 10.04 alive?

2\. do you think the type of people who stubbornly continue to use 10.04 would know/care enough about security to seek an alternative source for security patches?

 _edit: should maybe add why this pisses me off: just logged into a production server running 12.04, default install apache and updates _turned off_. the owner looked confused (and slightly bored) when I explained the problem to him._

<comment><USER10> Whatever hardware that is running that 12.04 system can be upgraded, free of charge, for likely the next 20 years if the past 20 years of linux is anything to go by.

Even if you pay money for the windows 10, it is unlikely to even start on the hardware that XP ran on. Not only will the people have to go through the budget to pay for the software, but now you need a full upgrade plan.

To put this in a concrete example. If a hospital had a check-in system running 12.04 they could just take someone internal from IT and go and fix it. If it was Windows XP then they need to go through finance, then get a offers from competing companies, fitting the upgrading into the budget, and last have people installing it in each of the hospitals entrances. The first case has a project length of days and the other of months and in worst case years.

<comment><USER11> I understand the argument, but I think "just take someone internal from IT and go and fix it" is vastly oversimplifying the skills/manpower/time required for doing something like this.

<comment><USER10> I can only speak of my own experience as a sysadmin, but the more isolated the system is and the less critical it is for operation, the easier it is to delegate the job of doing a software update to coworkers and new hire. Especially if all the issues from doing an update has already been established on several other machines, in which case the update is more or less mechanical in nature.

It reminds me of the story about a thirty year old Commodore Amiga running the AC system for a school district. The district finally decided to modernize the AC for $2 million, but until then it was just cheaper and easier to continue paying a person to run it every year. Replacing hardware systems is expensive and political complicated, while continuing paying an employee is just status quo.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> One of the reasons why such attack was possible is poor security in Windows. Port 445 that was used in an attack is opened by a kernel driver (at least that is what netstat says on WinXP) that runs in ring 0. This driver is enabled by default even if the user doesn't need SMB server and it cannot be easily disabled.

Most of services in Windows are run under two privileged user accounts (LocalService or NetworkService). Many of them are enabled by default and are listening on ports on external interface so the potential attack surface is large.

Microsoft uses programming languages like C++ that is very complicated and a little mistake can lead to vulnerabilities like stack overflow, use-after- free, etc.

Microsoft (and most companies) prefers to patch vulnerabilities with updates rather than take measures that would reduce attack surface.

Oh, and by the way Linux has similar problems. In a typical Linux distribution a program run with user privileges is able to encrypt all of the user's files, access user's cookies and saved passwords on all websites, listen to microphone and intercept kestrokes.

<comment><USER13> Why do you claim C++ relates to poor security? OSX and iOS are primarily C, C++, and assembly, (objective C at the higher levels). And linux of course is C and assembly.

Are you saying all of the major operating systems have poor security because they use "vulnerable" languages?

<comment><USER14> > Are you saying all of the major operating systems have poor security because > they use "vulnerable" languages?

Absolutely.

<comment><USER15> Does this include OpenBSD?

<comment><USER14> Is it a program written by humans and have parts that accept user input or network input? then yes.

<comment><USER15> By that definition, pretty much all software has "poor security" regardless of language. I don't think your definition of "poor security" is proportionate or useful.

<comment><USER14> > By that definition, pretty much all software has "poor security" regardless > of language.

My definition of "poor" is that it must have a babysitter to maintain and patch it. Whether or not this is the case depends on the attack surface, which of course depends on the complexity of what it does. A system that has no attack surface can be very buggy without having poor security. But an internet connected machine with modern windows/posix OS that does some useful work will likely need a security patch already within the first couple of years - <USER2> that I consider pretty poor.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Another lesson learned: don't bundle your security updates with your cool new features nobody wants, Microsoft. This will aggravate the problem as more people/companies will defer updates.

<comment><USER17> I disabled updates on my Windows 7 last September when I feared that I'd wake up to a Windows 10 machine like my wife did when her laptop updated to Windows 10. Unfortunately I can't seem to resume updates and fear that I may be vulnerable to WannaCrypt. (Some recent updates succeeded but I don't know if i patched for it)

<comment><USER18> Why do you fear updating to Windows 10?

<comment><USER19> a) telemetry

b) I'm worried my fairly nicely working Win7 environment will not work so well after updating to 10, as much as I want to get current with some genuinely useful features.

I'm generally a Microsoft "fan", but this is one of the many reasons I hate on them as much as Linux fans.

<comment><USER18> Sounds reasonable, thanks for replying!

</comment></comment></comment></comment></comment><comment><USER20> There's a lot of blame being thrown around, and I think it's all merited, but an inordinate amount needs to be on the users. I don't know how many times I've heard things like: "I don't think I'll update to Windows 10" or "That update has been nagging me for months" or even security advocates saying "Windows 10 is a privacy nightmare, I'll stay on 7". Being on the latest secure upstream isn't a nicety, it's what you have to do if you want any semblance of a secure environment. If you don't like upstream, jump to another.

It's definitely not end-users either. There's a grocery store that just went up nearby that I saw Windows XP splash screen on when one of the cashiers rebooted. No joke, new store, Windows XP computers that handle money. Microsoft may have cultivated this nightmare, but it seems everyone wants to live in it.

<comment><USER21> > Being on the latest secure upstream isn't a nicety, it's what you have to do > if you want any semblance of a secure environment.

Windows 7 is in extended support to 2020. So as far as I know security wise still up to date.

> There's a grocery store that just went up nearby that I saw Windows XP > splash screen on when one of the cashiers rebooted.

The cash register may be even running with a user interface written in VB6. Don't attach it to an external network and it will work just fine. No need to invest in new hardware/software when you can get it old, working and cheap.

> Windows XP computers that handle money.

In what way do they handle money? A computer virus isn't going to steal paper money and the device operating the card reader should have been sufficiently separated to begin with.

<comment><USER22> Do you really think that the machine does not handle credit cards a well? Provide a daily management report? Report inventory? Provide a Facebook interface between customers via the big blue E icon?

<comment><USER21> > Do you really think that the machine does not handle credit cards a well?

I don't know about the U.S., but as far as I know were I live these card readers have to be almost completely separate systems. The connection between these two should only exist to a) set the price to pay and b) confirm that a payment was made.

> Provide a daily management report? Report inventory?

No longer managing money directly, so the possible abuse for financial gain is quite restricted. You could argue that someone manipulates the reports in order to skim some money for himself, however that would be a rather targeted attack with someone on the inside profiting and could be detected when the physical goods no longer line up with the reported values.

> Provide a Facebook interface between customers via the big blue E icon?

Are we even talking about the same thing?

</comment></comment></comment></comment><comment><USER23> No one in the UK seems to be tying this attack to the Conservative Party's desire for backdoors everywhere, which is a shame because it's a nice example for the public of how the government have got this very wrong.

<comment><USER24> Reddit is all over it although it has turned into something suitably reminiscent of Alex Jones' material. Jeremy Hunt is apparently directly responsible for running XP on all NHS equipment and pulling the plug on the support contract for post-extended-support causing the deaths of thousands of people while he rolls around in the dust of the crushed skulls of all his victims.

I would rather see it used to leverage an opinion against back doors and surveillance culture but alas this is merely administrative incompetence and failure to either upgrade or airgap systems which have had a clock ticking on them and plenty of notice from the vendor to sort. The buck should stop at the trust IT directors as this was entirely avoidable with a properly managed estate.

</comment></comment><comment><USER14> One scary thing about these security holes is that it's almost impossible to _check_ if your system is affected.

There are at least 50 different releases of Windows 10 alone, and it's hard enough to find which is actually used.

The "System" dialog Shows "Windows 10 2015 LTSB". "Winver" on the command line shows "Windows 10 2015 LTSB build 10240" \- but there are several releases of that and only the latest ones, e.g. from 10240.17236 and up have the patch - But I can't seem to find which one I have.

I don't doubt I have a patched version, but out of curiosity I'd just like to double check.

<comment><USER25> Go to your Windows Update History and check if you have KB4013429 installed.

[https://support.microsoft.com/en- us/help/4013429/windows-10-...](https://support.microsoft.com/en- us/help/4013429/windows-10-update-kb4013429)

EDIT: Or KB4012606 / KB4013198 for older Windows builds.

<comment><USER14> How do I know that's the one? I'm was curious about the _process_ of knowing how to find out if my system is patched against vulnerability X.

<comment><USER25> Here's the complete process I followed:

1\. Search for "windows smb server vuln" in Google.

2\. "Microsoft Security Bulletin MS17-010 - Critical"[0] is the link I'm looking for.

3\. Search for your version in the list. Mine is "Windows 10 Version 1607", listed in the table with 4013429 (right next to the Windows version, not in "Updates replaced"). That's my update number.

[0] [https://technet.microsoft.com/en- us/library/security/ms17-01...](https://technet.microsoft.com/en- us/library/security/ms17-010.aspx)

<comment><USER14> I think a lot of the confusion here is what constitutes a "version" of windows 10.

<comment><USER25> Indeed. As far as I can tell they are like what used to be Service Packs?

E.g.: I didn't install the so-called Creators Update so I'm not in the latest Windows 10 version.

I'm no Windows sysadmin though so I'm not really sure.

</comment></comment></comment></comment></comment></comment><comment><USER26> a lot of people kicking sand in MSFT's eyes for having such a vulnerability.. but come on, the code base for windows is enormous. The feat of engineering that is microsoft windows (and its many iterations) is pretty amazing when you really look at it. Yes, plenty of flaws, but show me some other software which has endured?

Further, all of the major infections are based on Windows XP. Windows XP mainstream support ended a full year before the first gen iPhone was out! It's seriously ancient and there are very few excuses for people to have this crap on a network in 2017. For the folks who dont run XP, but got infected because they didn't patch? No excuses.

If I booted a RedHat (5.2 came out in 2009ish) or FreeBSD machine from 2009 without patches, and put it on the internet, I'm pretty sure it'd be hosed just as bad (shellshock, heartbleed, ?). the difference is, everyone would tell me I'm an idiot for putting a machine online from 2009.

<comment><USER27> > If I booted a RedHat (5.2 came out in 2009ish) or FreeBSD machine from 2009 > without patches, and put it on the internet, I'm pretty sure it'd be hosed > just as bad (shellshock, heartbleed, ?). the difference is, everyone would > tell me I'm an idiot for putting a machine online from 2009.

As a tongue in cheek (but totally true) correction, FreeBSD from 2009 would NOT be vulnerable to the shellshock vulnerability unless you explicitly install `bash` and make it the shell used by apache-cgi.

By default, FreeBSD lacks bash.

<comment><USER28> True, but FreeBSD can't guarantee perpetual security for releases. It also doesn't provide warranties, like the majority of software out there.

FWIW, I do hold FreeBSD in high regard. It's just that expecting perfection security-wise from complex systems is a fools errand.

<comment><USER29> > It's just that expecting perfection security-wise from complex systems is a > fools errand.

I think that may have been the OP's point. Bash is more complex than sh has to be hence because FreeBSD choose the simpler option they avoid the inherent security implications of complex systems.

(I use bash myself and don't use FreeBSD.)

<comment><USER22> Exactly, FreeBSD uses the simplest solution for the task, in the name of security. FreeBSD isn't "secure from Heartbleed because they don't use Bash" but rather, FreeBSD is "secure because by default only the most basic, necessary software is installed" which happened to be sh instead of bash.

</comment></comment></comment></comment></comment><comment><USER30> Should hospitals such as UK's NHS and other such organizations use dumb terminals (or chromebooks) instead of Windows? That way data is centralized on servers where it is easy to backup and harder for hackers to hold to ransom.

<comment><USER31> It'd be a good start if they just didn't use Windows.

But yeah, definitely. It's pretty damned unlikely that an OpenBSD backup server would get wormed, unless an ME exploit is involved.

<comment><USER32> Let's be clear on this. No matter how secure the operating system initially, if it stays unpatched then over time it will become more and more vulnerable as uncovered exploits go unfixed.

The reason a machine might go unpatched is because it might support some critical hardware (eg medical) for which there is only one or two vendors and only a particular combination of HW and SW are supported (eg due to a specific custom hardware driver).

To lay the blame for this at a single vendor's feet is naive.

<comment><USER33> True, but I'm sure there are a lot of cases where the OS wasn't updated because of the necessary investment to jump to a new Windows version.

<comment><USER34> There are very few free/open-source operating systems that get security patches for as long as Windows does.

Major versions of OpenBSD are only supported for 5-6 years. Most Linux distributions only get 3-5 years. Red Hat promises 10 years of support, the same as Windows 7/8/10\. None comes close to the 13 years that Windows XP was supported for.

So you're gonna have to update anyway, at roughly the same interval if not more often, as if you had used an enterprise edition of Windows.

<comment><USER35> _Major versions of OpenBSD are only supported for 5-6 years._

I thought that security updates are only made for -current, the current stable release, and the previous stable release. So, 1 year of support, not 5-6.

A cursory look at the errata seems to confirm this.

<comment><USER34> Most of the time, upgrading from one minor version to the next is painless. If you installed OpenBSD 5.0, you are expected to keep updating all the way to 5.9. (For some reason, OpenBSD always makes exactly 9 minor versions for each major version.)

Most Linux distros don't even make any fuss about minor versions, using them only as an opportunity to build fresh installation images. New minor versions _are_ security patches for the major version and all previous minor versions.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> > We need governments to consider the damage to civilians that comes from > hoarding these vulnerabilities and the use of these exploits.

This whole incident is really raising the profile of the creation of "cyber weapons".

They aren't like physical weapons with physical controls -- they are digital, controls and costs to copy/distribute are more like digital music than anything a Goverment organization is used to.

</comment><comment><USER16> One thing that strikes me with this malware is that it hits pretty much every single country. Don't hackers try to follow the proverbial "don't shit where you eat" proverb? They have nowhere to hide if they are identified now.

<comment><USER37> You're assuming it was released on purpose and worked on the intended scale, I'm not sure either are true.

<comment><USER38> This malware was first released as part of a massive spam campaign, and then from there wormed its way onto other systems. It was definitely released on purpose.

<comment><USER37> Has any of that been confirmed? I thought patient zero's were still mostly speculation.

<comment><USER38> I don't have a citation I can point you towards, just the word of a coworker who's a malware researcher, sorry.

</comment></comment></comment></comment></comment><comment><USER39> For those who think that using free software would be similar (naming ubuntu or even centos).

The real question is why a hospital is still running windows xp even though it's not supported by its own vendor.

The answer is vendor lock ins. The upgrade is not a matter of simple command. Upgrade cost involves more licenses and hardware upgrades (which is not needed as old hardware is fine, but this is how things work between microsoft and hw vendors) it's like you need a new buy watch to apply dst summer time.

Also mirosoft and old school desktop software vendors used to make sure switch or upgrade cost is really high ex by using non stanard formats.. to lock users from switching to mac or linux

If you remember active x and internet explorer specific vbscript...

If you use free software from an expensive but decent vendor like redhat you can upgrade software on same hardware

And if it software was expensive you can switch to centos, scientific linux or pay anyone to handle that for you are fair rate. There is no vendor lock in. Every thing is stardard and no vendor lock in.

</comment><comment><USER40> Microsoft's version:

        I see three areas where this event provides an
        opportunity for Microsoft and the industry to improve.

Fixed version:

        I see three areas where this event provides an
        opportunity for Microsoft, the industry, and
        government to improve.

To be fair, he does go on to point out how this is partly the fault of poorly conceived government policies, namely the NSA's foolish practice of stockpiling exploits. But Microsoft and the industry should keep the heat on the government about this at every opportunity, because the horrifically bad and analogous idea of having government master keys is still being pushed forward.

</comment><comment><USER41> And what about the lesson that software should be mortal, and should one day die? By what metric is, e.g. Windows XP, subject to evergreen updating to mitigate (prevent or reduce impact of) this exact scenario, forever? Does Microsoft have the right, and even the obligation, to remote detonate all Windows XP in existence on a certain date?

Perhaps EOL should be literal. The software kills itself and does not function.

The lesson I'm getting is our software can become malicious, and that malice can spread like wildfire. Is a company obligated to patch any wildfire type of bug forever? Is that a cost of proprietary software? Or is setting a date for its death the cost?

I think aging proprietary software has a much greater chance of becoming a weapon than it does becoming inconveniently obsolete. So forcing a company to release the code as free and open source software upon EOL date, I think just enhances the chances that it gets weaponized. There's a greater incentive to find exploits than to fix them, in old software.

Another lesson is most people really shouldn't be using Windows. If you can't afford to pay Microsoft to keep your software up to date, then use something that's FOSS and is up to date. (Same rule applies to Apple, if you can't afford new hardware in order to run current iOS/macOS versions that are being maintained, then don't buy stuff from Apple anymore.)

</comment><comment><USER42> How did MS know to patch a month before the exploits leaked? Did they get advanced notice as a courtesy from NSA, or someone else, that the exploits leaked?

<comment><USER43> I'm assuming this was contained in the vault7 leak: [https://en.wikipedia.org/wiki/Vault_7](https://en.wikipedia.org/wiki/Vault_7)

</comment></comment><comment><USER44> Lesson 1: don't use Windows. Lesson 2: be it a web resource or your pc, make sure you can restore all your data/sw from clean/current copies. Lesson 3: test lesson 2 periodically.

<comment><USER6> Lesson 1: don't use proprietary operating systems.

<comment><USER45> If Windows were open-source, would the situation have been any different?

Would organisations with very conservative attitudes to upgrade paths or a requirement to run an older OS version have suddenly been patching nightly?

Would the exploits used have been identified and patched prior to their malicious deployment?

Would organisations with a vested interest in stockpiling exploits have elected to immediately notify projects' maintainers?

The answer to these swings wildly between 'maybe' and 'probably not', so the eventual endpoint is likely largely the same. It's a compound issue brought about by a chain of decisions made by disparate organisations, and using it as a stick to beat Microsoft or proprietary vendors in general with is missing a very important point -

Security is the responsibility of everybody involved, from vendors and the government, all the way down through to the people innocently opening infected attachments.

<comment><USER6> Windows update is, put simply, a pain in the ass.

That has been the case for over a decade, and it has been getting worse over time.

The reason I recommend a _free_ operating system is not because you are allowed to read the source (although that is a bonus), it is because you have the freedom to _control_ your operating system.

The problem with Windows is that "updates" are done in the most inconvenient way possible, and with no control by the user. They often include changes that the user _does not want_ bundled in with security patches. To contrast, a free operating system gives you options (liberty). If I just want an old stable version of Debian with security patches, I can get it.

The issue here stems from using proprietary software in the first place. Proprietary software is controlled by the company, not the user.

</comment></comment></comment></comment><comment><USER46> I think the lesson is to have less uniform, opaque bloatware controlled by disinterested parties whether through proprietary technologies, walled gardens, OR paternalistic update policies. Have some diversity in the network, let people really know and choose what they want on and off, and have the minimum of what is needed for the job turned on by that endowed choice, and half of these problems go away.

</comment><comment><USER47> How to prevent an attack from internet is really a big problem. More open the system is, more dangerous the system maybe. like this attack, the macOS and Linux is safe. Maybe just because the system is not that open and malicious program cannot get some access to do something bad. And usually the update to prevent some kind of attack is later than the attack itself.

</comment><comment><USER48> It's not just a question of people not keeping their computers updated. I have bought a few second hand computers with windows 7 the last few months and they have all had problems when updating. I doubt most people even notice this and think they are updated.

</comment><comment><USER49> Side note, I posted [https://news.ycombinator.com/item?id=14334776](https://news.ycombinator.com/item?id=14334776) on custom support and MS quarterly earnings.

</comment><comment><USER50> I'm curious what kind of vulnerability it was. A buffer overflow? Stack corruption? A memory safety issue at all, or something else?

<comment><USER24> Overflow on a cast between a 16/32 bit value I think.

</comment></comment><comment><USER51> I think the lesson here is to disband all spy agencies when not at war with another nation state.

</comment><comment><USER52> Why not use Linux or MacOS?

<comment><USER53> You have to be pretty delusional if you think macOS or Linux don't have security problems.

<comment><USER54> Of course they do, yet we still haven't seen an outage like this, even though most of the web world is running on some kind of linux.

Most probably it's due to the high variety in kernels, versions and the subtle differences in linux distributions.

</comment></comment></comment><comment><USER55> LESSON: UPDATE YOUR SHIT

</comment><comment><USER56> stackoverflow nazis; this should not be a closed question

</comment><comment><USER57> The real question should be: Can Microsoft write an OS that does not have to be constantly patched, month after month?

We know they have written such things as part of research. But still they continue to release software that is unfinished.

They have trained their users that failure to update is fatal. No doubt, if they are using Windows.

They also like to conflate "update" with "upgrade". They use these security problems in Windows to scare people into upgrading.

Windows 10, whether they like it or not. As others have noted, _by design_ the new versions are not safer than the old ones.

Retroactively fixing reported issues does not make a new version more secure _by design_. They could just as easily fix the issues in the older version.

Can this company get anything right the first time? Will they ever design a system that is secure?

Do they have any interest in doing so?

Are they incapable?

There is nothing wrong with releasing something simple, secure and _finished_.

Does MS believe Windows users are not worthy of a secure OS?

I think Microsoft Research have contributed to development of L4 systems that run on baseband.

Do these systems have the same vulnerabilities as Windows?

Fixing problems _after they occur_ (past problems) is admirable but other free opens source OS written by volunteers accomplish the same thing. The question is whether the design of the system is such that _future problems_ are avoided.

Does Microsoft believe Windows users deserve more security? Can Microsoft deliver it?

All indications suggest the answer to both questions is no.

With no viable alternatives, no one can blame Windows users for sticking with it despite red flag after red flag, but it makes no sense to defend the Microsoft approach to security for Windows users. The company has no respect for Windows users.

Being responsive to a constant stream of reported vulnerabilities is an improvement from 1995 but as we can see it is not enough. Their software is still full of mistakes. They need to prove they can make something that is secure _by design_ and that they are willing to do so for users.

(Truthfully, they probably do not need to do anything.

Quotes of 80% of Windows installations being tied to purchases of hardware are probably not far off the mark.

There is no selection of OS by most computer users.

A majority of users still get Windows pre-installed on the computers they purchase.

Microsoft could completely ignore users and it would not hurt their business, as long as they continue to maintain relationships with hardware manufacturers.)

<comment><USER58> Most of these fit into a tweet. You could have asked Tay if it was still around :-)

</comment></comment><comment><USER59> Lesson 1: don't use Windows.

</comment><comment><USER60> stop exposing functions ment to run in private networks (LAN) to the internet. please make stuff secure by default.

</comment><comment><USER61> _Second, this attack demonstrates the degree to which cybersecurity has become a shared responsibility between tech companies and customers._

Victim blaming at its finest.

</comment><comment><USER62> Pretty sure this is a highly targeted piece of PR designed to shift the blame from Microsofts appallingly poor operating system design especially when it comes to security. Are the NSA a deceptive, anti-humanist organisation that performs atrocious acts against people - yes - I absolutely believe so and they play a HUGE part in this, but Microsoft - they are the irresponsible software vendor here and do they reimburse people that have PAID for their software? No.

</comment><comment><USER63> > Finally, this attack provides yet another example of why the stockpiling of > vulnerabilities by governments is such a problem. This is an emerging > pattern in 2017. We have seen vulnerabilities stored by the CIA show up on > WikiLeaks, and now this vulnerability stolen from the NSA has affected > customers around the world. Repeatedly, exploits in the hands of governments > have leaked into the public domain and caused widespread damage. An > equivalent scenario with conventional weapons would be the U.S. military > having some of its Tomahawk missiles stolen. And this most recent attack > represents a completely unintended but disconcerting link between the two > most serious forms of cybersecurity threats in the world today – nation- > state action and organized criminal action

Did the Microsoft President just confirm that NSA develop the vulnerability which led to the attacks on hospitals this weekend?!

<comment><USER64> This is public knowledge at this point.

<comment><USER65> Citation please?

<comment><USER66> The NSA hoarding / leaking aspect of this vulnerability has been reported by most major news outlets. Even the mainstream ones. Albeit most haven't expanded on that point to the level that Microsoft did here.

<comment><USER65> Sorry I misread it as the NSA was developing the holes as in backdoors, intentionally creating the vulnerability.

<comment><USER67> Effectively, that's what happened.

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

 _> A month prior, on March 14, Microsoft had released a security update to patch this vulnerability and protect our customers. While this protected newer Windows systems and computers that had enabled Windows Update to apply this latest update, many computers remained unpatched globally._

They stopped supporting Windows XP years ago, including with security updates.

There are still around 100 million computers around the world running XP.

It seems irresponsible to just leave them to hang out to dry when there are that many machines out there running it. A virus seems inevitable if they do. And shifting the blame onto the customers is not reasonable when there are still 100 million customers who are "doing it wrong" by not upgrading to a later version of Windows.

This entire article pertains to directly shifting the blame onto their customers, and the governments of the affected countries (!)

 _> The fact that so many computers remained vulnerable two months after the release of a patch illustrates this aspect_

Again, XP systems are the most affected, and there was no patch released for XP. This is extremely irresponsible of Microsoft and this article shifting the blame onto everyone but themselves is reprehensible.

<comment><USER69> How long should Microsoft be required to support XP? They extended the original support period TWICE. Why are customers entitled to support when they were informed prior to purchasing the product that support expired on a given date?

<comment><USER12> Maybe newer OS do not have any useful features for those customers? Maybe they are even worse for them because work slower, are not compatible with old drivers, contain spyware (telemetry)?

<comment><USER69> Is a company obligated to sell a product with features that you consider useful? Intel doesn't make pre-ME CPUs anymore. Apple doesn't make Power PC iMacs anymore. And Microsoft doesn't make Windows XP anymore. In all these markets, there are consumers who would prefer to purchase the discontinued product. So what? Products get discontinued.

Consider a discontinued product from another industry, like a car or an appliance. When the product is discontinued, the manufacturer only creates replacement parts for existing machines for a limited time period. After some years, it's difficult for a consumer to maintain their copy of the discontinued product because it is difficult to find replacement parts.

The point is, mass produced engineering products have lifecycles. Microsoft clearly defined (and extended) Windows XPs lifecycle and provided patches for the entirety of that lifecycle. It's hard for me to understand how that doesn't fully meet their obligations to be fair to their customers.

<comment><USER12> While you are right, there is a difference that you can drive a 20-30-year old (if repaired) car on modern roads but you once you connect a PC with 20-year old OS to the internet, it will get infected. And 20-year old browser will not be able to display modern websites.

Maybe when cars will become more computerized(?) and connected, they will become unusable faster.

</comment></comment></comment></comment></comment><comment><USER70> Microsoft is feature and sales oriented not quality oriented. Security is an aspect of quality. So if you voluntarily like to put yourself at risk, by all means use their products.

Their product design doesn't emphasize security. For example, remember the extremely convenient AUTORUN.INF feature? That has probably resulted in billions of dollars lost and that number continues to grow every day.

Rendering fonts on the kernel... fantastic idea! What's the next great Microsoft idea? Continue to buy their products and figure it out.

<comment><USER71> >implying ransomware has only ever affected Windows</comment></comment>


Amazon Beats Analyst Expectations with $25.4B in Sales - <AUTHOR> http://techcrunch.com/2015/10/22/amazon-handily-beats-analyst-expectations-stock-spikes-9/ <comment><USER2> Some interesting tidbits I read:

* AWS grew 78% from t̶h̶e̶ ̶p̶r̶e̶v̶i̶o̶u̶s̶ ̶q̶u̶a̶r̶t̶e̶r̶ the year-ago quarter!

* GE moving workload to AWS, downsizing from 34 data centers to 4.

<comment><USER3> I think you misread the AWS growth paragraph, it is 78% year over year:

"Amazon reported net AWS sales of $2.085 billion, up from $1.169 billion in the same quarter a year earlier. That's a 78% jump in net sales for the company's AWS business, which it started breaking out earlier this year. It's even a big quarter-over-quarter jump: Amazon $1.82 billion in net sales for AWS in the previous quarter. It's reporting $5.5 billion in AWS net sales for the first nine months of the year, compared to $3.2 billion in the first nine months of the year prior."

</comment></comment><comment><USER4> AMZN stock has almost doubled since January this year... that's insane

<comment><USER5> Might actually be worth enduring the inhospitable work culture for returns of this magnitude on RSUs.

<comment><USER6> The issue is the RSUs are super backloaded.

<comment><USER5> From what I know talking to AMZN engineers, they still vest over 4 years, but you do not get a big chunk of it until year 3.

Probably still worthwhile when the $200k initial grant turns out to be worth 2-3X more after 4 years.

edit: typo

<comment><USER7> Last I saw (a long time ago, stock was <$100/share), the grants were $50K/4years ($2.5k/$7.5k/$20k/$20k)

<comment><USER6> I think that's still the target.

</comment></comment></comment></comment></comment></comment><comment><USER8> Put money in on Monday so pretty pleased with this. I was hoping for $600. After market today trading $620-630.

</comment><comment><USER9> nice to see them crush earnings for the past 2 quarters after all the super smart analysts were doubting if they could make any money for the year before that...</comment>


Violet (Nabaztag, Mirror RFID reader) file for bankruptcy - <AUTHOR> http://www.engadget.com/2009/08/11/nabaztag-cant-make-rfid-cool-has-to-file-for-bankruptcy/ <comment><AUTHOR> The Nabaztag and Mirror devices they sell won't work without the violet webservice running behind them. This will increasingly become a problem when more "Internet of Things" devices are sold</comment>


Ask HN: How to connect serverless lambda functions to custom domain? - <AUTHOR> I generated a free ssl certificate from sslforfree to host my lambda functions to api.ansaar.in whose DNS is managed by GoDaddy.
I have a serverless AWS Lambda APIs project. I intend to deploy it on a custom domain.
The custom domain's SSL certificates were imported successfully.
As suggested by serverless blog successfully ran sls create_domain
sls create_domain
sls deploy run seems successfully too:
serverless deploy
Now, whenever I hit api.ansaar.in - it doesn't work at all.
What is the problem here? <comment><USER2> You will need to setup Amazon API Gateway which will give you http/https end point for your Lambda function.</comment>


Neil Sloane: the man who loved only integer sequences - <AUTHOR> http://www.theguardian.com/science/alexs-adventures-in-numberland/2014/oct/07/neil-sloane-the-man-who-loved-only-integer-sequences <comment><USER2> Great to see this article about Neil, a warm and brilliant guy - I had the chance to meet him personally the last time the joint AMS meetings were in San Francisco.

Also, when I submitted a simple integer sequence[1] to OEIS on _Thanksgiving Day_ a few years ago, he took the time _that day_ to respond and educate me about some delightful related math.

[1] [https://oeis.org/A168521](https://oeis.org/A168521)

</comment><comment><USER3> The concept of the original published _Handbook_ and the subsequent OEIS was pure genius. Almost no consequential objects in math can be easily looked up (i.e., ordered), but these sequences can.</comment>