Ask HN: Favorite mailing lists, IRC channels - <AUTHOR> I've recently come to appreciate true veterans of technology hang around mailing lists and IRC channels.<p>What are some of your favorite programming/security/sysadmin mailing lists and IRC chaneels? <comment><USER2> The liberation-tech list is interesting sometimes: [https://mailman.stanford.edu/mailman/listinfo/liberationtech](https://mailman.stanford.edu/mailman/listinfo/liberationtech)

The rest of the mailing lists/IRC channels I read are all related to specific software projects, though.

I feel like I should add something here about how spending a lot of time on IRC can be inversely correlated with being someone who's doing a lot of work, in some cases. The veterans you're seeing might be people who now spend more time talking about technology than creating it, unless they're using IRC to coordinate their contributions to a project with its other members.

<comment><USER3> I would love to see some sort of service that logs an IRC channel and condenses down the most popular topics, keywords, users, etc.

<comment><USER4> +1

</comment></comment></comment><comment><USER5> Pycoder's Weekly: [http://pycoders.com/](http://pycoders.com/) Python Weekly: [http://www.pythonweekly.com/](http://www.pythonweekly.com/)

...and a shameless plug for my Django bi-weekly

Django Round-up: [http://eepurl.com/yZh21](http://eepurl.com/yZh21) (Archive: [http://us2.campaign- archive1.com/home/?u=24fce4628ba1d5814de...](http://us2.campaign- archive1.com/home/?u=24fce4628ba1d5814debef334&id=2d6dd01daf))

</comment><comment><USER6> #python on Freenode. If you can live with being asked questions when you're asking something funny long enough to convince regulars you _usually_ know what you're doing, it's an excellent congregation of some hella smart people.

(Disclaimer: I'm a regular of the channel myself. I also run the official Python channels on Freenode.)

<comment><USER7> thanks for the help getting started! you helped me out a ton 2 years ago!

<comment><USER6> Glad to hear it! What's your nickname?

<comment><USER7> neataroni

</comment></comment></comment></comment><comment><USER8> This is my list of favs. [http://suhairhassan.com/2013/04/17/newsletters-for- hackers.h...](http://suhairhassan.com/2013/04/17/newsletters-for-hackers.html)

<comment><USER9> Nice list, thanks for putting it together & sharing.

Slightly OT, for people with email sending experience: I've noticed that some of these lists require you to confirm an email subscription ("double opt-in"), which afaik is standard operating practice for any email list these days.

Yet a couple (Bootstrappist, Web Design Weekly to name a couple at random) don't, they just send a welcome email. Are those two able to avoid the double opt-in requirement by virtue of being larger/older/more established lists, or are they assuming their open rates will keep their deliverability % high, w/o needing the extra confirmation step?

Has the double opt-in requirement become a relic?

</comment></comment><comment><USER10> NANOG, [http://www.nanog.org/list](http://www.nanog.org/list)

MailOP, [http://chilli.nosignal.org/mailman/listinfo/mailop](http://chilli.nosignal.org/mailman/listinfo/mailop)

VoiceOPS, [http://puck.nether.net/mailman/listinfo/voiceops](http://puck.nether.net/mailman/listinfo/voiceops)

Full Disclosure, [https://lists.grok.org.uk/mailman/listinfo/full- disclosure](https://lists.grok.org.uk/mailman/listinfo/full-disclosure)

Outages, [http://puck.nether.net/mailman/listinfo/outages](http://puck.nether.net/mailman/listinfo/outages)

DNS Operations, [https://lists.dns-oarc.net/mailman/listinfo/dns- operations](https://lists.dns-oarc.net/mailman/listinfo/dns-operations)

</comment><comment><USER11> Shameless plug, I've written a small piece of software which will send you daily aggregates of github activity via email. There are also weekly / monthly options as well.

[http://gitstreams.com/](http://gitstreams.com/)

<comment><USER12> Cool! I've been searching for something similar to this.

</comment></comment><comment><USER13> #haskell on Freenode. Great group of smart hand helpful people.

<comment><USER14> \+ haskell café maillist

</comment></comment><comment><USER15> Some of us are on #startups on Freenode.

<comment><USER16> There are a lot of good channels on Freenode generally, but it's a bit like saying one's circle of friends are good.. they're not so great until you know them, etc. #startups is probably one of the better ones for strangers, but it's certainly worth branching out into several at a time, particular technology specific ones where newcomers are expected and frequent (e.g. #redis, #rubinius, #ruby-lang). You can then get invited or drawn into the more cliquey but interesting channels that no-one talks about as much.

<comment><USER17> The best channels are the invisible ones no one talks about.

</comment></comment></comment><comment><USER18> I really like the Ruby Rogues Parley [http://rubyrogues.com/parley/](http://rubyrogues.com/parley/) and ruby weekly [http://rubyweekly.com](http://rubyweekly.com) One is great just to get up to date and the other has really great discussions with all kind of people involved with Ruby in one or the other way.

</comment><comment><USER19> #Techendo ([http://techendo.co](http://techendo.co)) on freenode -- a lot of good people there from the SF tech scene, but I'm biased because I started the channel.

</comment><comment><USER20> IRC: Freenode: #security, ##freebsd, ##hardware, #debian - all good Rizon: #baot As for mailing lists, Full Disclosure for sure, Bugtraq, all the big name security ones have really interesting posts.

</comment><comment><USER21> #slicehost on freenode. I know the company doesn't exist anymore, but I learned so much about setting up my first debain box from these guys/gals. It is still going strong 6 years later.

</comment><comment><USER22> I'm a fan of digital currencies so I frequently visit Freenode channels: #bitcoin #litecoin #bitcoin-dev #mtgox

Its interesting to observe the growth of the channels during bitcoin's hype cycles.

</comment><comment><USER23> I run a small IRC channel for webby types, mainly UK based and theres not many of us but anyone's welcome. irc.chatwebdev.com #chatwebdev

</comment><comment><USER24> #python #bash #awk #go-nuts on Freenode...

</comment><comment><USER25> irc.mozilla.org and then #webdev #webapi #b2g #developer and others. Keeping the web free and open to all ;-)

</comment><comment><USER26> I'm a fan of scala-lang/scala-internals both of which are very interesting.

</comment><comment><USER27> ##c on Freenode. If there's one channel to visit, it's that one.

<comment><USER28> Last time that I tried being a regular in ##c, regulars over-zealously referred people away (That's GNU C, go away!) and most often responded by using a bot to deliver an automated message. People scolded me for answering questions sincerely. Maybe just a one off experience, but not a big fan.

</comment></comment><comment><USER29> #ebooks on irchighway.net

</comment><comment><USER30> #oftn on freenode is a great open source programming channel.

</comment><comment><USER7> aside from all the obvious #<language>, #scikit-learn is really good for general ML and obviously good for more specific questions about scikits.learn machine learning libs

</comment><comment><USER31> My favorite mailing list is closed and private (no, I'm not inviting you), and has been running since the 1990s.

<comment><USER32> This added nothing but arrogance to the conversation.

<comment><USER31> Not arrogance, practicality. Closed groups are a fantastic way to maintain quality. No need for moderation, no newbies, no stupid questions, very high signal/noise ratio, comraderie of many years together.

There's a great deal to be said about the value of exclusive clubs. That's why they're so popular.

<comment><USER33> Maybe there's an interesting discussion to be had about that. But OP asked:

> What are some of your favorite programming/security/sysadmin mailing lists > and IRC chaneels?

He is looking for open channels, and you leave a pointless comment about some elite closed channel you're a part of. Then you further crapped up the thread trying to rationalize this with some chin-stroking about the 'tragedy of the commons'. That being the case I think it's totally fair (if not charitable) to characterize your response as arrogant.

<comment><USER31> The OP didn't say "open". And frankly, the closed ones are often the best sources. Getting involved in a really high-quality closed list can solve a lot of problems.

Downrating my response? I can see that. Bitching about how "arrogant" it is? So WHO crapped up the thread, exactly? You're not exactly being fair here. I don't think it's unreasonable for me to respond to getting flamed.

Or alternately, you can view this whole unfortunate affair as the sort of tragedy of the commons that undermines the quality of discussion in public forums. You can close your mind to the point, or you can open it. Your call.</comment></comment></comment></comment></comment>


Elimination of HIV-1 Genomes by CRISPR/Cas9 Gene Editing - <AUTHOR> http://www.nature.com/articles/srep22555 <comment><USER2> Reading the methods section, it looks the T-cells infected with HIV-1 that are used for targeted for gene editing came from a cell line and incubated in a cultured medium.

For people who are involved in dealing with CRISPR/Cas9, what is the effective rate of gene editing done in vitro vs. in vivo?

Would the molecular machinery of CRISPR/Cas9 encounter any natural defense mechanism of the human immune system when attempting to mutate target sites on T-cells in say, lymph nodes of adult humans (contrasting to changing DNA in the germ-lines of bacteria or even human embryo's)?

<comment><USER3> > For people who are involved in dealing with CRISPR/Cas9, what is the > effective rate of gene editing done in vitro vs. in vivo?

It will depend in part on the tissue of interest and the delivery vector. In the mouse liver, the Broad group under Zhang has gotten efficiencies as high as 40% using Staphylococcal Cas9 [1].

1 = [http://www.nature.com.sci- hub.io/nature/journal/v520/n7546/f...](http://www.nature.com.sci- hub.io/nature/journal/v520/n7546/full/nature14299.html)

<comment><USER4> I found this + the op's comments fascinating purely because I wouldn't have been able to tell if both were real, or just fake technical talk of the ilk my friends and I sometimes do with meaningless software/hardware jargon as a joke, without Googling.

<comment><USER2> Well, for the record, I am a programmer working at the Broad, a genomics center that is mired in the current CRISPR patent dispute (although I don't work with CRISPR at all).

The answerer I believe is a MD/PhD at Mass General Hospital and before that a research scientist at the Broad working on genomics (and so is the author of the cited paper on mouse liver, small world here on HN). So I can be full of BS, but I don't think the answerer is.

Tbh, I intentionally added a few more jargons more than necessary (I could have just asked "Can gene editing be effective in live humans T-cells vs. cells on a petri dish?") to field my question; but I intentionally did so to filter out the pop-sci, speculative futurists to get answers from people in life sciences research.

</comment></comment></comment></comment><comment><USER5> I was in HIV research for a time. I was unimpressed by this paper's title, introduction, methods, etc, until the part where they discussed correcting infected cells derived from human donors. As a general note, a running joke in the field is that "anyone can cure HIV in vitro", so I practically tuned out the sections where they discussed the work in T-cell cultures.

>Lentivirus (LV) mediated Cas9/gRNA delivery suppresses HIV-1 infection in human T-cells.

That should be the actual headline of this paper. Yes, it's a big deal that researchers were able to use a lentiviral vector (HIV without the disease causing bits) to genetically alter infected CD4 T-cells. This is a shot at a cure.

Simple infection of a person with the CRISPR-fortified lentiviral vector is a new therapy idea which has the potential to trump the current antiretroviral therapies because it can reduce or remove the HIV "viral reservoir"\-- the places in the body where HIV can hang out and survive even when being suppressed by antiretroviral therapy. I can imagine a therapy in which the CRISPR-vector is injected into patient lymph nodes and other similar sites with the intent of curing HIV for good. Won't be cheap for another decade, though.

</comment><comment><USER6> Seems like it could be effective to use CRISPR/Cas9 to insert the HIV resistance gene mutation (CCR5-delta32, to replace the normal CCR5 gene) into bone marrow stem cells and then inject those into the person after testing the created cells to be HIV negative (or cutting the HIV out by means in this paper). If HIV negative bone marrow cells available were sufficient to do this it could be a 'cure' for the hematopoietic system. Or use HIV-negative induced pluripotent stem (IPS) cell with hematopoietic potential derived from a tissue not normally infected by HIV.

Such cells in principle would have a survival advantage over native cells and would effectively perform a bone marrow transplant, maybe helped along by some medicinal guidance. Pies in the sky, but using HIV-negative cells may avoid the problem of removing divergent sequences of HIV in different people and ineffective gDNAs.

</comment><comment><USER7> Awesome.

I've been avidly following the CRISPR/Cas9 developments over the past five years or so, and the possibilities seem astonishing. I can't wait to see where this all leads!

<comment><USER8> Some cool stuff combined with very scary stuff, like eugenics and large scale food chain modifications with unpredictable effects (already being planned with mosquitos).

<comment><USER9> > eugenics

Well, in this case CRISPR wouldn't make much sense for _negative_ eugenics—i.e. trimming the gene pool—vs _positive_ eugenics—purposely introducing or manipulating existing genes.

While the latter is still scary, it's not exactly close to the mass sterilization people think of.

<comment><USER8> Negative eugenics is currently being planned for deployment to control which mosquitos are able to reproduce.

[http://www.nature.com/nbt/journal/v34/n1/full/nbt.3439.html](http://www.nature.com/nbt/journal/v34/n1/full/nbt.3439.html)

[https://medium.com/mit-media-lab/kevin-esvelt-joins-the- medi...](https://medium.com/mit-media-lab/kevin-esvelt-joins-the-media- lab-3e33fe24f90#.y2qfqy39w)

<comment><USER10> Which I applaud for the same reason I applaud some of the extinctions we have caused.

<comment><USER11> Which extinction do you applaud?

<comment><USER12> I can't help but feel like life is easier without sabertoothed tigers roaming the streets

<comment><USER13> There are non-extinct big scary cats. They don't cause much trouble. We'd be doing fine without that extinction.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Apparently this doesn't only diminish the infection, but can supposedly confer resistance?

"When evaluating a therapeutic strategy based on CRISPR/Cas9, it is critical to understand that not only will HIV-1 be eliminated from latently infected cells, but the majority of uninfected cells will become resistant to HIV infection. Thus, there is a high likelihood that rebounding viral infections will be contained by the resistant cells."

<comment><USER15> This confused me as well. Based on my skimming, the paper doesn't speculate on why this appears to be true, but it's very interesting that the researchers observed this phenomenon at all.

</comment></comment><comment><USER16> It has been common experience for me to check my internet news feed and see "the cure" for HIV/AIDS/Cancer/Diabetes fairly regularly.

This article does not appear to claim to be "a cure", but does seem promising. Can anybody comment on the significance of this and why the layman should care about it?

<comment><USER17> Most HIV treatments center around suppressing the virus. For example, many antivirals used in treatment interfere with viral reproduction. These people are never cured, because part of what HIV does is it inserts itself into the DNA of the infected individual's cells.

The technique proposed in this article would be revolutionary because it suggests that we may eventually be able to use CRISPR to selectively cut that HIV DNA out of infected cells, leading to a permanent cure, if 100% eradication of HIV DNA can be achieved. Unfortunately, doing it in a petri dish is much different than doing it in vivo, particularly with 100% eradication.

<comment><USER18> if we could create a reasonable number of healthy (uninfected) t-cells, would an individual be left infectious but otherwise asymptomatic (because of the retention of a working immune system)?

<comment><USER17> This would only make sense if you could make the uninfected t-cells totally resistant to infection. What this paper suggests is that even this would be unnecessary. The combination of antiretrovirals and CRISPR therapy would prevent replication and excise the embedded viral sources. With enough of this combined therapy, eradication may be obtainable, resulting in a properly cured patient.

</comment></comment></comment></comment><comment><USER19> Figure 1D is said to show "Detection of Cas9 protein by Western blot analysis", so what does "bp" stand for in that figure (above the ladder)? Usually it stands for base pair but that doesn't make sense when looking at protein.

<comment><USER5> Base pairs. I don't know the exact math and haven't ever done Westerns, but there's almost certainly a way of converting protein size (typically expressed in kDa) to base pairs, since theoretically a large enough quantity of bp would weigh as much as a protein of a given size.

The trick here is to understand that Western blots use gel electrophoresis to detect protein size, meaning that heavier proteins will not traverse as far as lighter proteins.

<comment><USER20> Come on. Having actually done Westerns, there is absolutely zero chance that the "bp"=base pair in that figure is on purpose. Western blot is a protein blot and they are always measured by their molecular weight (kDa). Base pairs would make no sense here. The numbers in the image are obviously kilo daltons.

How do we know the numbers are kilo daltons? Well, they say they're using β-tubulin as a loading control. β-tubulin's molecular weight is about 50kDa and that's what you can see in the image.

Also, look how the headers are not aligned properly in the image. As if the image is a draft.

<comment><USER21> The bp==base pair stands correct. It refers to Fig 2C, that shows the display of RT-PCR products(DNA made from RNA).

</comment></comment></comment></comment><comment><USER22> So it cuts the genomes out, does it keep the cells alive while doing so? I heard that CRISPR/Cas9 doesn't rejoin the dna it cuts. I'm new to this and would love to know from someone more knowledgeable about this.

<comment><USER23> Cells are always poised to repair DNA breaks. For example: over your lifetime, your cells will have repaired thousands of DNA breaks due to gamma radiation. The breaks due to CRISPR/Cas9 are similar to the breaks caused by gamma radiation and likely to be repaired very rapidly. If the DNA break is not resolved, there are other biochemical pathways to lead to apoptosis (programmed cell suicide).

</comment></comment><comment><USER24> "...potentially serve as a novel and effective platform toward curing AIDS."

Researchers are usually quite conservative and the media are usually the ones to sensationalize titles. Given the above quote, this is likely a major step forward.

<comment><USER25> No, that's standard boilerplate these days in papers. You have to "sell" the science a bit to reviewers and connect your work to the broader picture. Those in the field usually ignore statements like this.

<comment><USER26> When I was a research assistant in college I was encouraged for one of my presentations to emphasize safe hydrogen storage as a vehicle fuel source, when really the research was all about how minuscule amounts of hydrogen change the electrical/optical properties of thin metallic films (and desorption was on the order of days). Selling it as a building block for safer hydrogen storage was necessary to get people engaged.

<comment><USER27> Yup! I published a paper on organoselenium chemistry and was asked to add commentary about potential "anti-cancer" properties.

Sure my work could be extended in that direction, but I had done zero work to pursue it.

</comment></comment></comment></comment><comment><USER28> How did they narrow down what section of DNA is removed? That sounds to me like the really hard problem here.

I'm actually really interested in that kind of work.

<comment><USER20> Knowing the exact location in the genome, they amplified the target sequence from the DNA (using PCR) and sequenced it verifying the modification.

</comment></comment><comment><USER29> If this pans out I hope there won't be any nonsense where some pharma company charges ~$80k for a full treatment like with the hep C cure.

<comment><USER30> $80k for an HIV cure is cheap compared to a lifetime of HIV treatment.

"The most recent published estimate of lifetime HIV treatment costs was $367,134 (in 2009 dollars; $379,668 in 2010 dollars)."

[http://www.cdc.gov/hiv/programresources/guidance/costeffecti...](http://www.cdc.gov/hiv/programresources/guidance/costeffectiveness/index.html)

<comment><USER31> And so for that matter are the hep C treatments. They're that rare thing: an effective cure for a serious, chronic disease that was previously only treatable with long term medication with many nasty side effects.

</comment></comment></comment><comment><USER32> Thats the best news I've had in a long time. Great time to be a molecular biologist.

</comment><comment><USER33> !!! Amazing

</comment><comment><USER34> If it does what it says on the box, it would be in nature, not scientific reports.</comment>


I Can Tolerate Anything Except the Outgroup (2014) - <AUTHOR> http://slatestarcodex.com/2014/09/30/i-can-tolerate-anything-except-the-outgroup/ <comment><USER2> Rambling... what exactly is the point here?

<comment><USER3> It builds to honest self reflection on tribalism in a way very few articles do well. It's worth the full read. Of course, I'm not team Blue, so I might be biased. There's lots that it makes me think about regarding my own reactions to liberalism (is team Grey just doing to team Blue what they did to team Red?)...

Worth the whole read. I am inspired to write up a list of the five worst traits of my own ideological in group (which I will go with libertarians not because it's a great fit, but because it's the closest I've got), just to make myself face them honestly instead of pretending like I'm being self critical when I criticise the liberal attitudes of the community in which I live (there's not the critical mass for team Grey to really achieve that level of isolation).</comment></comment>


Is a Mini Ice Age Coming? 'Maunder Minimum' Spurs Controversy - <AUTHOR> http://www.livescience.com/51597-maunder-minimum-mini-ice-age.html <comment><USER2> Click bait.</comment>


Ask HN: What's the best way to do filesystem encryption on macOS? - <AUTHOR> Hello internet!
What's the best way of having filesystems that are 1) encrypted, 2) mounted on demand (not all the time).
Contenders are 1) encrypted disk image, 2) encrypted APFS volume, 3) 3rd party solution (which one?).
Which one is the best and why?
Thanks! <comment><AUTHOR> In particular I am interested in whether encrypted disk images or APFS volumes are "better" (by some metric), but I am interested in information about 3rd party solutions as well.</comment>


Making sense of the alleged Supermicro motherboard attack - <AUTHOR> https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/ <comment><USER3> Ok, that finally makes a bit of sense about "if" this is true, how it might be carried out. And I agree with the author that the simplest action for a chip on the SPI bus would be to hold the MISO line low during power on to suggest to the BMC chip that its QSPI flash isn't programmed (note that QSPI starts up as 'regular' SPI and then switches over[1]). I would guess that the next thing the BMC would do is assume its on the factory floor and hasn't had firmware loaded yet and so it would attempt to boot via TFTP from some server to start the firmware loading process.

FWIW at NetApp the firmware engineers called the BMC the 'BiteMeChip' because they always caused issues when bringing up a new filer motherboard. They were finicky, were often hard to update, and when misbehaving could completely screw up the system.

So I can see this as a vulnerability but really I'd want to stick some probes on that 'mystery' chip and make sure it wasn't just some LC filter or something which is shunting off noise on the data lines.

[1] [https://github.com/ChuckM/stm32f469i/tree/master/demos/qspi](https://github.com/ChuckM/stm32f469i/tree/master/demos/qspi)

<comment><USER4> One question: how do you hold an existing line low without drawing lots of current, and without cutting that line first?

<comment><USER5> It's not like the MISO line is tied to a power rail. You just need to sink more current than the output of the chip you are trying to override. So the driver is likely in the single digit milliamp range, and in any case, you don't care if you toast the output driver on that chip. In fact, if you do, bonus!

<comment><USER4> Ok, but i suppose that in the future chip output pads can have circuitry which can detect a forced output (by measuring current). When this happens, the chip could short-circuit power lines, or superimpose a signal on the power-lines to notify the rest of the system.

<comment><USER6> > When this happens, the chip could short-circuit power lines

No chip design would ever do this. The chip would incinerate itself.

> superimpose a signal on the power-lines to notify the rest of the system

The rest of the system i.e. the BMC already know that something weird is up.

</comment></comment></comment></comment></comment><comment><USER7> In another thread Walterbell points out:

From 2016, [https://arstechnica.com/information- technology/2016/03/repor...](https://arstechnica.com/information- technology/2016/03/repor..).

> Apple has begun designing its own servers partly because of suspicions that > hardware is being intercepted before it gets delivered to Apple, according > to a report yesterday from The Information. "Apple has long suspected that > servers it ordered from the traditional supply chain were intercepted during > shipping, with additional chips and firmware added to them by unknown third > parties in order to make them vulnerable to infiltration, according to a > person familiar with the matter," the report said. "At one point, Apple even > assigned people to take photographs of motherboards and annotate the > function of each chip, explaining why it was supposed to be there. Building > its own servers with motherboards it designed would be the most surefire way > for Apple to prevent unauthorized snooping via extra chips."

<comment><USER8> The industry was aware of intercepted/modified hardware shipments long before this, also giving reason to be suspicious:

From 2013: "NSA reportedly intercepting laptops purchased online to install spy malware"

[https://www.theverge.com/2013/12/29/5253226/nsa-cia-fbi- lapt...](https://www.theverge.com/2013/12/29/5253226/nsa-cia-fbi-laptop-usb- plant-spy)

Also [https://www.wired.com/2015/02/nsa-firmware- hacking/](https://www.wired.com/2015/02/nsa-firmware-hacking/)

</comment></comment><comment><USER9> I think the board that is pictured by Bloomberg is just an illustration.

For example, Elemental never used that board. See my tweets here for the actual specs: [https://twitter.com/hugelgupf/status/1048160794565861377?s=1...](https://twitter.com/hugelgupf/status/1048160794565861377?s=19)

Elemental boards come with GPUs. The blade pictured has neither GPUs nor PCIe.

</comment><comment><USER10> I think the attacks are real.

A year ago, Google announced their Titan firmware security chip[1], which would limit these kinds of attacks. I don't believe they designed and built this chip, and surrounding infrastructure, because of purely theoretical attacks.

Besides that, over the last couple years there has also been a lot of work trying to neuter the Intel ME, because of how dangerous it is. Another example is that Google had also done work to replace the EFI/Intel ME with a Linux kernel [2]. This has limited usefulness against the most recent attack, but it is related (since it's still a chip that has more privileges than the primary CPU).

I suspect that there are a very small number of people in these big companies who are aware of these attacks. It's hard for me to guess why the companies involved would deny that these exist.

1\. [https://www.zdnet.com/article/google-opens-up-on-titan- secur...](https://www.zdnet.com/article/google-opens-up-on-titan-security- heres-how-chip-combats-hardware-backdoors/)

2\. [https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...](https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf)

<comment><USER11> First guess: not being allowed to admit it due to national security reasons and it being an ongoing investigation. On the same day several Russians were exposed trying to attack OPCW. They were exposed by Dutch military intelligence. At the press briefing the UK ambassador was there. Same day US indicts several Russian spies. This to show that these are major, international events and that proper disclosure towards investors is probably on the back burner as long as operations are continuing. It must be maddening for those involved not to be allowed to discuss it, or even having to actively lie about it while government officials leak freely in the game of thrones.

<comment><USER12> If they are under a gag order, they would simply not comment on it. Lying about it is never required and puts them at risk for shareholder lawsuits.

<comment><USER13> Apple _specifically_ states that they are _not_ under any form of gag/confidentiality order/conditions:

> Finally, in response to questions we have received from other news > organisations since Businessweek published its story, we are not under any > kind of gag order or other confidentiality obligations.

<comment><USER14> Apple cannot do anything bad to China or their manufacturing stops.

Apple would have to move tens of thousands of highly specific CNC machines from China to somewhere else, set them up, and get their line moving again.

This is why I find the idea that Apple phones are "secure" to laughable on its face. China could kill _years_ of Apple revenue if they ever did something truly offensive to the ruling party.

Apple would roll over post haste if China demanded it.

<comment><USER15> China could cause huge harm to Apple, but the reverse is also true - how would the US government, other corporations, consumers and investors react to such a news?

The ultimate source of most Chinese factory equipment is Europe and US anyway, under extreme political/consumer pressure electronics factories can be setup in a matter of months in US.

<comment><USER14> > China could cause huge harm to Apple, but the reverse is also true - <USER2> > would the US government, other corporations, consumers and investors react > to such a news?

They would react as usual: lots of whingeing, no action, and roll over for a belly scratch afterward.

> under extreme political/consumer pressure electronics factories can be setup > in a matter of months in US.

It takes 9 months to make a baby no matter how many women you get pregnant ...

Many of these equipment manufacturers have entire facilities dedicated to producing equipment solely for Apple. They simply cannot replace that amount of equipment in any timely fashion.

Edit (external reference): [http://www.iphonehacks.com/2016/10/next-iphone- probably-wont...](http://www.iphonehacks.com/2016/10/next-iphone-probably- wont..).

> Koenig writes. "Apple is such a huge buyer of a particular kind of mill > (BT30 spindle drill-tap centers) that Fanuc, Brother and DMG Mori each have > factories dedicated to building machines exclusively for Apple."

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> It was reported that the security auditor used during Elemental's acquisition detected this compromise. I assume they found it in a randomly selected board. Either they were very lucky, or hundreds of boards were compromised.

Now, I think all motherboard manufacturers - and especially high end server manufacturers like SM - use sophisticated automated tests and quality control on boards. Under what circumstances is it possible that SM's QC missed this out on so many boards? Won't it affect things like the power budget, weight, and latency? What do professional EE people here think?

<comment><USER17>
        > ... high end server manufacturers like SM - use sophisticated automated tests and quality control on boards.

MFG test guy here (not supermicro!)

Not necessarily. Automated production tests are there to configure and exercise the system and confirm it works as specified. Such tests are good at things like finding bad solder joints, pick-and-place mishaps, misconfiguration of firmware and weeding out product that fails functional test. That, by itself, is hard enough.

Such tests are not _really_ able to detect things which no one is expecting, or worse, things which an adversary has specifically designed to avoid detection. Sure, if something gets "discovered" during a failure analysis, a test or process can be created to specifically address THAT problem in the future.

To find "unknown unknowns", you need an audit of some kind and that is definitely different from production test.

<comment><USER16> Thank you for the insight. I was rather naively imagining that every board is subject to some kind of x-ray image matching with the original PCB design to find differences. Not that simple, I see.

<comment><USER17> Some manufacturers do X-ray boards.

Typically this is done to check that BGA devices ([https://en.wikipedia.org/wiki/Ball_grid_array](https://en.wikipedia.org/wiki/Ball_grid_array)) are soldered properly. Usually not done on every board, but only if there's a problem suspected. When it happens they tend to focus only on particular BGA components or suspect copper traces rather than the whole PCB.

<comment><USER18> I'm guessing the answer is obviously yes that this type of x-ray would easily be able to discover / distinguish something the size of what's been described? (1mm x 2mm from what I've seen thus far?)

<comment><USER19> The x-ray picture would contain information sufficient to detect that thing, but it's quite plausible that the process/procedure of analyzing that x-ray would not find it. If they're looking for extra hardware, they're going to detect it, but if they're looking for bad solder joints, they're going to detect bad solder joints but not extra harware.

<comment><USER18> Right. It doesn't exactly align with what a normal auditor would be looking out for, I suppose. Thanks, I appreciate it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> > _Let's assume an implant was added to the motherboard at manufacture time. > This needed modification of both the board design, and the robotic component > installation process. It intercepts the SPI lines between the flash and the > BMC controller_

Circuit wise, you don't really need to "intercept" (place in series with) the SPI lines. Two parallel drivers [0] will generally fight it out quietly, and you can guarantee yours will win by designing your implant to have the beefier driver (and perhaps only changing 1's to 0's, as P-channel FETs are generally weaker).

If there already was a footprint for an extra chip (debugging, part flexibility, etc), then it would not require modification of the board design. And an extra component can easily be hand soldered afterwards outside of the standard robotic component placing.

[0] The standard topology of SPI, but in proper operation only one is active due to CS lines.

<comment><USER21> Post author here. That was what I was thinking of - simply overdriving the lines to drag them high or low in opposition to the 'official' driver. That's pretty much all you can do with 6 pins. I was trying not to overcomplicate the explanation, since the material is already complicated enough!

Fair point about hand soldering, however it would be more obvious to the manufacturing employees for an entire production batch to be diverted to have parts added manually than to simply sneak in another reel to the hundred on the pick and place machine.

<comment><USER20> I just thought that was phrased as if it were a necessary requirement for the attack, rather than a description of a likely approach. I could also see a scenario where only the occasional unit was bugged, and then an agent at the distributor made sure the right customers received the bugged units.

Thank you for writing your article! I'm currently a bit out of the security headspace and reading the Bloomberg article had me scratching my head like what are the actual details here.

</comment></comment></comment><comment><USER22> The fact that cursory examination finds the attack is not only entirely feasible, and completely undefended against, but that the hardware shown in the Bloomberg animation is _precisely_ the hardware which would be required to pull off the attack is quite astonishing.

Whose "law" is it that the closer you are to an event the more you can see that the reporting on the event is desperately flawed? This has almost always been my own personal experience.

To have the article hit the nail on the head with a entirely plausible attack means one of two things;

1) This is exactly what happened

2) A nation state wanted us to think this is exactly what happened.

Either way the NSA is involved. The people on the ground who knew it happened would have to be NSL'd from telling their superiors that it happened, so they leaked it.

Perhaps the denials from above are entirely sincere because the people who discovered it can't pass it up the chain.

The only thing I'm having trouble with is that would have required either a low-level plant to have discovered it and someone else at a low-level found out and was sworn to secrecy, or a middle-manager plant intercepted the message as it went up the line.

The alternative, that this is a false flag, is pretty fascinating in its own right. TAO would have had to conceptualize the attack vector, and then someone planted the story.

Perhaps this is equally likely. In fact, this is actually an attack I assume TAO is using in the field, which would burn this attack vector presumably because they have an even better one.

Even more interesting, the idea TAO was actively using this attack vector, saw evidence in the field their attack was discovered (devices going dark) and so preemptively planted a story to blame the opposition before they accused the US of the same thing.

<comment><USER23> Or, it could be both.

It could have been a real attack vector that didn't actually infiltrate the companies in question due to having been caught upstream.

But as "attempted attack" sounds far less sexy than "actual attack," the sources may have exaggerated the impact/discovery to further trade negotiation objectives with the spin.

In fact, the BS discovery part of the story might be an attempt to parallel construct a reason it was discovered to cover for a program that might do independent testing of hardware which, if revealed, would give attackers some sense of sampling methodology to be able to counter.

That would explain the vehement denials from the companies allegedly compromised and yet the realistic attack vector published along with the US entity bans on using Chinese hardware around that time.

</comment></comment><comment><USER24> A decade ago when I worked at Microsoft I shopped around the idea of using XBox as a basis for secure computing.

XBox was designed to function in the hands of the adversary, to be robust against peripheral attacks and even motherboard mods. Even the main memory was encrypted by the on-CPU controller. Obviously, no open JTAGs. A lot of expertise there.

In my fantasies it would form the basis of the DoD infrastructure and then trickle down to finance. It was deemed to be not solving any practical problems, so it didn't go anywhere. Oh well, I found other fun thins to do in my life.

<comment><USER25> Are you referring to the original Xbox? Modchips hit the scene for that in ~ 2 years after release. It's not exactly what I would consider a basis for secure computing. Or maybe you are just referencing the procedures "main memory was encrypted by the on-CPU controller. Obviously, no open JTAGs" should be ratified to create a basis for secure computing, a checklist of things to do/prevent before considering a device "Secure".

<comment><USER26> Didn't even need a modchip. There was a technique where you could softmod by simply unplugging the ide harddrive right after boot and hot plugging it into a desktop.

[https://www.reddit.com/r/originalxbox/wiki/hotswap](https://www.reddit.com/r/originalxbox/wiki/hotswap)

<comment><USER27> Ah the old softmod, with the 007 game as I recall. Made a great party trick.

</comment></comment></comment></comment><comment><USER28> Can someone outline some reasons for me why nobody has come up with an actual physical example of a compromised board? I'm not trying to make a point, I just want to get a more complete picture of the issue, and the biggest thing that stands out to me is the lack of physical evidence.

<comment><USER29> Well according to the original article, the attack was targeted, implying the only way to get such a thing would be from one of the compromised customers, who are probably involved in an investigation into the matter, don't have all of the info themselves, and aren't super eager to release details to the public before a full picture emerges and mitigation procedures are in place.

Further, going back to the original article, the majority of the information comes from alleged government sources, so not the people directly impacted, but rather those just helping deal with the fallout and coordination.

Assuming there is merit to the story, it will likely be some time before more details emerge, unless having the story out there now helps accelerate that process.

<comment><USER30> > the attack was targeted,

Supermicro assemble their products in US/Taiwan.

So in theory China need to accurately predict the pattern of how non-China factories install batches of the motherboard. I think it's extremely difficult to pull this off.

</comment></comment></comment><comment><USER31> This article is worth skimming/reading in order to fill in the technical gaps in the Bloomberg article; but also describes the complexity of modern computers in a way I didn't previously appreciate.

What's still missing in the overall story, is what Apple and Amazon denials mean. The Bloomberg article says Apple and Amazon independently discovered these chips (Amazon via a 3rd party) in 2015; but the blanket denials by both companies appear to deny this discovery and reporting to U.S. authorities. I'd argue it's unethical for a company to apply _falsus in uno, falsus in omnibus_ to a PR statement, but it's plausible there is a sufficiently misleading or false claim in the Bloomberg article that they feel it's legitimate to dismiss the entire article. In the meantime, the company denials have to be treated as conjecture.

</comment><comment><USER32> While it's practically certain that hacking attempts do happen from both state- and non-state actors, this particular instance is so "alleged" that it's practically theoretical.

Where's the actual hardware? Why didn't someone decap the tiny chip and probe it? Its design should be well within today's reverse engineering labs' capabilities.

<comment><USER33> What makes you think that people aren't going through they're POs and server farms and looking today? Just because a couple huge players told prior to publication, doesn't mean everyone was.

These things literally take time, and there's no indication of how widespread the targeting was.

</comment></comment><comment><USER34> There's a problem with exfiltrate via BMC network theory.

In a sane setup, your BMC connection cannot access internet. You should build an isolated intranet for it (including VLAN or hardware isolation, not just subnet/IP), and put a VPN in the front gate. As a result, you login to your data center, or go to there if you like metaphors. If nobody's there via VPN, BMC network is a silent and dark place. No connection to outside, no unknown traffic, just silence. Only exception may be the discovery packets of some BMCs, which can find similar servers and form federations for easier management. Even this needs some setup beforehand.

<comment><USER35> If the BMC has write access to host memory it could surely use that access to create a side channel using the host's network interfaces.

Having said that, it would be nice if networks were segmented in the way you describe. I've been appalled at the lack of segmentation I've seen in companies of all sizes that I've had gigs for.

<comment><USER34> Today's network cards are small computers of their own. So it'd be very hard to inject packages with all this kernel-hardware integration at the module level IMHO. The card would probably throw a tantrum if you try to access it directly.

TBH, while I'm knowledgeable about hardware, I'm a total beginner in attack side of cybersecurity.

At least, we are segmenting our networks like that.

</comment></comment></comment><comment><USER36> Where did all the boards in question go? Why wouldn't a company notice any of the outbound traffic using firewalls?

Two pieces of the story that don't add up for me.

<comment><USER37> There wouldn't be any weird outbound traffic; the attacker would use another cloud instance as a controller. They would use a US-based account (and IPs via VPNs) to control the controller.

<comment><USER36> The traffic has to travel over wire as TCP/IP, regardless of what device generated it. It has to travel over wire somewhere! The device can't magically communicate with China. Any outbound firewall could detect that, especially traffic going to ports that aren't even open/used.

<comment><USER38> Unless, just to provide a nightmare scenario, the routers that would detect it are also compromised.

<comment><USER39> The NSA did that, they literally intercepted routers en route. I'm guessing other agencies have too.

Or you can just use the default credentials Cisco is addicted to leaving in their code.

</comment></comment></comment></comment></comment><comment><USER40> Few years ago [https://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk- hacki...](https://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hacking-hard- drive-controller-chips/) popped up, basically hdd have many arm co- controllers. Nowadays everything is a processor, everything is thus virtual and fakeable. Enjoy the paranoia :)

</comment><comment><USER41> I'm no expert, but wouldn't be more efficient to completely replace the BMC with a malicious one? That way it should be virtually impossible to detect

<comment><USER42> Or even why two SPI roms?

Why not just one with special code? It's not like anyone is routinely reverse engineering the BMC boot code.

It seems like an awful lot of provable trouble to go through (note that there is no physical evidence in the public eye yet) when you could do the same thing, at the factory, with just software.

<comment><USER43> it's pretty easy to dump an SPI chip and some vendors/customers routinely do so.

In this model, the implant basically contains a binary patch that is injected at boot time over a segment of the BMC binary - counter overflows, chip cuts out the SPI and transmits its payload instead. After the payload is injected the implant goes dormant again/resumes passing through the SPI, so dumping the ROM after boot, or even physically clipping onto the SPI chip will not reveal the wu-tang secret.

<comment><USER44> Wu-tang.

</comment></comment></comment></comment><comment><USER45> Technical possibility is one thing; proving the story has actually happened is another thing. Until now, what we get is a categorical denial of the story from all related parties. And all the evidence Bloomberg can provide so far is just vague anonymous sources.

Talk is cheap, show me the code/server/chip if they ever exist. Otherwise, the story is just a blunt lie fabricated by Bloomberg serving as a propaganda to bash China amid the Sino-America trade war.

</comment><comment><USER46> I really hope that this is the straw that breaks the back of all these "management engines"

Like seriously, why does my hobby consumer motherboard need that feature? Corp IT only ever deploys to large fleets of OEM machines.

<comment><USER47> Take a look at ASpeed (BMC supplier) stock movement: [https://finance.yahoo.com/quote/5274.TWO/chart?p=5274.TWO](https://finance.yahoo.com/quote/5274.TWO/chart?p=5274.TWO)

<comment><USER48> That movement seems to have started about two weeks ago. I don't think it's related to this news.

<comment><USER47> I'm sure it didn't help!

</comment></comment></comment></comment><comment><USER49> BMCs have always been an Achilles heel.

HP's iLo could be got into if you used `curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"`

Supermicro's horrid BMCs, of which there are many, all were horrendously lax in security, long before this chip was, or was not inserted. You didn't buy supermicro if you were worried about security, you bought them if you needed to stack stuff high, cheap and dense.

There is a reason why its best practice to put them on separate networks, with as much stuff between it and anyone else. BMCs are massive backdoors, and should be treated with caution.

</comment><comment><USER50> Does this mean I can get some great deals on Supermicro boards now? :)

</comment><comment><USER51> Regardless this attack is real or not, this exposure and assessments (just like Charlie Miller and Chris Valasek did for exposing the car hacks) raised good awareness of how vulnerable BMCs are and hopefully the baseboard hardware security and firmware security will be securer in the future when they evolve.

</comment><comment><USER52> The Register's article on the matter seems also good: [https://www.theregister.co.uk/2018/10/04/supermicro_bloomber...](https://www.theregister.co.uk/2018/10/04/supermicro_bloomberg/)

</comment><comment><USER53> I don't understand why everybody assumes it must be pulling data over the network autonomously. It could simply compromise the host OS to augment other, targeted attacks. Say, by reintroducing a buffer overflow or race condition. It would be incredibly short-sighted to go to such lengths to compromise these machines just to naively pull from a command+control server, virtually advertising its presence.

Defenders simply do not think like attackers. If you're a defender it's _lethal_ to try to think like an attacker. "I can't imagine how this would be useful therefore it must not be useful" are the famous last words of everybody who has cast doubt on a new and novel attack vector. As a defender you need to first estimate the unknowns and unknown unknowns, which over the last year alone have exploded (e.g. actual and potential Intel microcode vulnerabilities). If you needed this article to convince you of feasibility or even just practicality, please don't pretend to be capable of assessing the security posture of any complex system.

And let's be clear: this is _not_ a new and novel attack vector. There are companies that have existed for quite some time researching and selling products to deal with this sort of attack vector. On the spectrum of hardware based attacks feasible today, this chip isn't at the complex end of the spectrum but rather the simple end of the spectrum. The complex end of the spectrum involves hiding logic deep within existing ICs, and there's ample literature to demonstrate feasibility of both implementation and detection.

The difficulty in pulling off these attacks lies not in the software or hardware, but the political, intelligence, and military apparatus of attacking countries. The economic costs of detection are huge precisely because, at the end of the day, fundamental security relies on trust, not technological hurdles per se.

</comment><comment><USER54> In the security world, there is always a new attack vector. With the advent of Spectre and Meltdown, I am expecting to see more hardware-based attacks in the future.

<comment><USER55> and subsidies to enrol more students in EE to build up local national talent?

</comment></comment><comment><USER56> Regardless if someone of the details turn out to be true, there's a couple of really important network security takeaways here.

First you need to run an air gapped network or at least switch enforced vnet for your bmcs. Three firmware on these is only updated every few years anyway, so they're likely full of security holes anyway.

Second, in general, outbound connections need to be monitored everywhere in your data center.

</comment><comment><USER57> Is this really that hard to imagine?

I am willing to bet that there are teams of spies who have infiltrated Google, Facebook, Amazon, etc. Spies from US, Russia, China, Britain, Israel, Germany, etc, must have dozens of spies working as engineers are getting access to all that data as we speak.

To think that they aren't would be rather naive, in my opinion. If I were head of the spy agencies in any one of those countries, it would definitely be the first thing I would do.

<comment><USER58> It's not at all hard to imagine, especially from a country who is so paranoid about backdoors from other country's operating systems that they have written their own:

[https://en.wikipedia.org/wiki/Kylin_(operating_system)](https://en.wikipedia.org/wiki/Kylin_\(operating_system\))

<comment><USER59> This is a Linux distro, not "their own OS". Many countries all over the world have had government-subsidized Linux distro projects, at national, state and city government levels. It's something that happens pretty quickly whenever and whereever a large deployment happens (e.g. LiMux).

For that matter, many a CS faculty at many a university have _actually_ created their own OS. Nothing too sensational either.

<comment><USER58> Pedantry aside, it is the reasoning behind building their own OS distro that is relevant here:

> In 2009, a report presented to the US-China Economic and Security Review > Commission stated that the purpose of Kylin is to make Chinese computers > impenetrable to competing countries in the cyberwarfare arena. The > Washington Post reported that:

> China has developed more secure operating software for its tens of millions > of computers and is already installing it on government and military > systems, hoping to make Beijing's networks impenetrable to U.S. military and > intelligence agencies.

<comment><USER59> Sounds perfectly sensible, rather than "paranoid".

</comment></comment></comment></comment></comment><comment><USER60> QSPI has 4 _data_ lines, a clock and a chip-select line.

In order to intercept a QSPI bus, you would therefore need 4+1+1+2xpower lines = 8 pins.

This is not sufficient for QSPI.

Single SPI on the other hand requires Clock, Data, ChipSelect, Ground & Power = 5 lines, so that would be plausible.

(Yes, I know you can potentially get rid of the CS line, but that depends on what else is on the bus).

<comment><USER20> You need two lines - data/ground, or data/Vdd. Probably whichever gives you voltage when idle.

You harvest power when data is idle. CS is irrelevant. The rough clock speed is fixed, and you can match the precise timing from the data line. QSPI actually gets you access to data in _both_ directions with the tradeoff of only getting one quarter of the bits.

Logically, you likely only need to recognize a few patterns that are each say 30 bits long. If you could shrink this down, it would look exactly like a boring pullup.

<comment><USER60> CS isn't irrelevant if there are multiple devices on the bus, we havent seen a schematic.

<comment><USER20> Yes it is - a tap doesn't need to be 100% sure that a given chip is selected like how we think when designing a circuit - it just needs to key off patterns that look like memory reads of interest. If you've got ambiguity you don't need to pull in more parallel bits, just record a longer serial history.

In fact I would think the most stealthy and robust way of bugging code would be to just ignore addresses and look for a context-free stream of instructions that does some security-sensitive initialization (either of the platform or of the application code). Turn off some flag that's supposed to be on, causing the code to continue running as normal but silently skipping certain checks.

Now that you mention other devices on the bus - those in fact would be a great chip to subvert with such a backdoor. Why bother fitting everything into a two terminal hack package when you could just have a malicious temperature sensor sourced from the "lowest bidder" that does the attack and jumps to its own ROM? (I think those are usually I2C but you get the point). Bonus points for only being triggered through some sidechannel - recruit a low level employee at the target, while they retain plausible deniability.

</comment></comment></comment></comment><comment><USER61> > There are few facts, and much supposition.

Can't we watch it in action? Probe it and run the system, watch for activity on the SPI lines.

Can we dissect it and look for how it might interact with the world? Does it have anything like an RF front end, or does it wait for some specific BMC/network activity before triggering?

<comment><USER42> We could do all of those things if anyone were to come forward with actual, physical evidence (i.e., a board).

But so far no one has.

</comment></comment><comment><USER62> Would be bad if a DoS attack could occur by killing the chip at a certain date or on command. Imagine electronic devices going down, and only way to fix is to get new hardware...ouch.

Maybe this will open up more manufacturing jobs in the US.

</comment><comment><USER63> If this attack vector is true, it seems overly complicated to me. Why not have the assembly house load the normal SPI flash with firmware you've altered to control the main CPU the way you want? That is WAY easier than hardware changes to the PCB design and installing a part which isn't on the approved Bill of Materials.

</comment><comment><USER64> every supermicro motherboard that I have dealt with (several 100s) always has a jumper which can enable(shorted)/disable the bmc/ipmi. i've been surprised at how many we have bought used off eBay/surplus that had the jumper open (ie bmc disabled). wouldn't having this disabled physically (jumper open), thwart this attack?

(i'm asking not suggesting)

and I do realize the majority of people do have the BMC enabled, including me)

also the fact that supermicro still offers this jumper to disable the BMC might speak to the fact that they (sm) are not in nor had any knowledge of this issue (ie they were not "In on it")

</comment><comment><USER65> So the point of the attack was to subvert the BMC firmware in a way that was resistant to firmware re-flashing, but not resistant to firmware integrity checks. But there are no firmware integrity checks?

<comment><USER66> What is likely: they connected their own flash in place of recovery flash, that was not soldered on on that particular board version, that for what that soic8 or tsop8 pad is on photos; the chip will boot from the recovery, but if someone were to read the main flash, it would output the correct content. Only if somebody specifically poked the recovery, would the bug be revealed.

</comment></comment><comment><USER67> If it is false, can/will/should Apple/Amazon sue Bloomberg?

</comment><comment><USER68> This story is ridiculous. I believe the arguments made int eh article didn't happen. Apple, amazon, and SMCI have all rebuffed. The Bloomberg journalist was duped. SMCI did nothing wrong and their business remains strong as we speaker. They will shortly: 1) Issue a detailed rebuttal with QC procedures and 2) become current with their audited financials by the end of October. As a result, the stock will revisit $30 per share within 3-6 months which is a triple from today's price. Who remembers the Johnson and Johnson Tylenol scar? Someone posiomed Tylenol and the stock cratered. This is no different, except the "poisoning" never happened. And even if it did, it was 3 years ago and was discovered.

</comment><comment><USER69> Smartphones, both iPhone and Android are manufactured in China

</comment><comment><USER70> These types of attacks are distractions from the real attacks. Doping attacks are the big attack vector now, and they can't be picked up with electron microscopes

</comment><comment><USER71> Protecting tech in transit would be a new business. Tamper-evident packaging and such.

<comment><USER72> obviously we need block-chain now, I'll start up the ICO generator script

</comment></comment><comment><USER73> > But there's another trick a bad BMC can do — it can simply read and write > main memory once the machine is booted.

Doesn't ASLR[0] mitigate this?

[0] [https://en.wikipedia.org/wiki/Address_space_layout_randomiza...](https://en.wikipedia.org/wiki/Address_space_layout_randomization)

<comment><USER74> I don't see how it would. ASLR only really helps making it harder for attackers to gain full control when they manage to execute some instructions in your process via memory corruption. It relies on the memory layout being hard to guess, however, the BMC can already just read from arbitrary memory, so it can just look it up. What would help here is isolating PCIe devices with the IOMMU, but this is currently rarely enabled, only for virtualization, apparently due to it's relatively high overhead.

</comment></comment><comment><USER75> The NSA has been caught doing this kind of stuff to Cisco routers so I can believe it.

</comment><comment><USER76> This chip looks for me like a simple fuse. This is not for spying, but rather a doomsday switch.

If activated, it will short the circuit destroying full system operations. I don't even think it contains any sophisticated digital logic inside.

</comment><comment><USER77> Test comment, please ignore.

</comment><comment><USER78> I'm just going to throw this out there: BMCs and ILOMs are for tiny shops where "the IT guy" might have to do something from the beach at Cannes on their vacation. If you are a large operator like Apple you absolutely do not need BMCs.

<comment><USER79> Not just tiny – any place where you don't want work to be rate-limited by the time it takes to get a body in front of a server. The only scale where it's not a big win is when you're so large that you have rock-solid auto-recovery in your software stack and hardware failures are handled by disabling a server and leaving it in the rack until it's periodically reaped at a regular interval.

Most businesses are in that gap – definitely not tiny, but definitely not able to just ignore remote management – especially if they have lots of physical locations and it's not practical to have 24x7 IT staffing at every branch office.

<comment><USER78> Remote office management can be handled by a KVM with remote access. These can be security hazards in their own right, but it's a lot safer than having some vendor junk literally hard-wired to your PCI bus.

<comment><USER79> Now you have a second device to buy, secure and support, and it can't do everything that an ILOM can (most importantly, remote power management). Having had security updates for KVMs, I'm also not sure your assumption that it's safer is true in any meaningful sense.

Management engine vulnerabilities have gotten a lot of hype over the last year or two but most of it has been marketing for security companies rather than a serious risk (e.g. what percentage of bugs required local network access, which should not be easy to get on your management VLAN). During a similar period, we've also had Spectre/Meltdown and the usual slew of software vulnerabilities so I have trouble with the conclusion that the answer is to stop using a useful tool rather than continuing the industry-wide effort to improve the level of security competency among development teams.

<comment><USER78> For many BMCs the second network port is a figment of your imagination. The BMC is capable of intercepting and injecting network frames on the host's interfaces. Just because you have the management port wired to a different VLAN or even a separate physical LAN means nothing.

<comment><USER65> BMC NIC is generally capable of being bridged to one of the main NICs, although it is possible to disable that feature, but also possible to override the disabling if you control the hardware.</comment></comment></comment></comment></comment></comment>


Ask HN: Any recommendations on resources for learning one algorithm a day? - <AUTHOR> <comment><USER2> This is a good resource we used in a university course I took on algorithm design and analysis...

[http://jeffe.cs.illinois.edu/teaching/algorithms/](http://jeffe.cs.illinois.edu/teaching/algorithms/)

I would probably recommend studying individual classes of algorithms, and to only move on when you feel ready, as opposed to learning algorithms in ascending difficulty (at the risk of learning them in a haphazard fashion).

VisuAlgo is another cool site that has lots of algorithm visualizations... [http://visualgo.net](http://visualgo.net)

And, if you can handle the dude's voice, I recommend checking out Xoax.net's algorithm videos... [http://xoax.net/comp_sci/crs/algorithms/index.php](http://xoax.net/comp_sci/crs/algorithms/index.php)

What you will probably find is that it's more valuable to gain experience designing your own algorithms using tried-and-true techniques such as dynamic programming, greediness, divide-and-conqur, linear programming, etc. Also keep in mind that data structures are closely linked to algorithms, and vice versa. If you are not familiar with big-O notation I suggest you begin there as it can be used as a measure of both an algorithm's time complexity and its data complexity.

<comment><USER3> I'll add another nice academic resource with visualizations of data structures and algorithms:

[https://www.cs.usfca.edu/~galles/visualization/Algorithms.ht...](https://www.cs.usfca.edu/~galles/visualization/Algorithms.html)

</comment></comment><comment><USER4> One algorithm a day -- the short answer is if you were going to really learn them and not just forget them then you would have to cheat and constantly review previously 'learned' algorithms as you go. Otherwise you will learn X algorithms and likely forget nearly X algorithms.

I have to question the value of only focusing on learning algorithms and on the idea of optimizing the quantity.

In terms of learning lots of them, it might be more useful to focus on learning more fundamental algorithms _better_ rather than tons of them. Or you might want to carefully select the most generally useful algorithms or ones in a specific field relevant to current projects.

Also, now that we have such powerful general purpose languages and efficient module versioning and distribution, learning to take advantage of those probably has more practical use.

For example, you could spend several weeks or years learning various statistical methods and algorithms for machine learning in a particular area. But then you realize that all of the algorithms are already implemented in python code libraries so you start learning how to apply the libraries in real code for applications rather than reimplementing the libraries.

But then you find out that deep learning techniques far outperform all of those algorithms you learned to implement and then apply via those libraries.

So then you train yourself on sophisticated deep learning techniques and start to implement LSTM in python. Then you realize you never quite got the fundamental understanding of neural networks so go back to work on learning that better.

Then you implement some core neural network algorithms in python and start to build back up to your LSTM implementation. Now you find out that TensorFlow exists but lacks good support for AMD which your university has (perhaps erroneously) made a large investment in.

So then you decide the best thing to do would actually be to try to fix some basic bugs that occur on your platform with the latest TensorFlow/OpenCl/AMD code (or whatever).

You manage to fix one of the minor issues and now several geniuses have their day improved by a bit or two.

The point is, trying to learn a ton of random algorithms in a short period probably isn't the best use of your time.

</comment><comment><USER5> Depending on your level of programming ability, one algorithm a day, IMHO, is completely doable. A number of comments and suggestions say that one per day is an unrealistic goal (yes, maybe it is) but the idea of setting a goal and working through a list of algorithms is very reasonable.

If you are just learning programming, plan on taking your time with the algorithms but practice coding every day. Find a fun project to attempt that is within your level of skill.

If you are a strong programmer in one language, find a book of algorithms using that language (some of the suggestions here in these comments are excellent). I list some of the books I like at the end of this comment.

If you are an experienced programmer, one algorithm per day is roughly doable. Especially so, because you are trying to learn one algorithm per day, not produce working, production level code for each algorithm each day.

Some algorithms are really families of algorithms and can take more than a day of study, hash based look up tables come to mind. First there are the hash functions themselves. That would be day one. Next there are several alternatives for storing entries in the hash table, e.g. open addressing vs chaining, days two and three. Then there are methods for handling collisions, linear probing, secondary hashing, etc.; that's day four. Finally there are important variations, perfect hashing, cuckoo hashing, robin hood hashing, and so forth; maybe another 5 days. Some languages are less appropriate for playing around and can make working with algorithms more difficult, instead of a couple of weeks this could easily take twice as long. After learning other methods of implementing fast lookups, its time to come back to hashing and understand when its appropriate and when alternatives are better and to understand how to combine methods for more sophisticated lookup methods.

I think you will be best served by modifying your goal a bit and saying that you will work on learning about algorithms every day and cover all of the material in a typical undergraduate course on the subject. It really is a fun branch of Computer Science.

A great starting point is Sedgewick's book/course, _Algorithms_ [1]. For more depth and theory try [2], Cormen and Leiserson's excellent _Introduction to Algorithms_. Alternatively the theory is also covered by another book by Sedgewick, _An Introduction to the Analysis of Algorithms_ [3]. A classic reference that goes far beyond these other books is of course Knuth [4], suitable for serious students of Computer Science less so as a book of recipes.

After these basics, there are books useful for special circumstances. If your goal is to be broadly and deeply familiar with Algorithms you will need to cover quite a bit of additional material.

Numerical methods -- _Numerical Recipes 3rd Edition: The Art of Scientific Computing_ by Tuekolsky and Vetterling. I love this book. [5]

Randomized algorithms -- _Randomized Algorithms_ by Motwani and Raghavan. [6], _Probability and Computing: Randomized Algorithms and Probabilistic Analysis_ by Michael Mitzenmacher, [7]

Hard problems (like NP) -- _Approximation Algorithms_ by Vazirani [8]. _How to Solve It: Modern Heuristics_ by Michalewicz and Fogel. [9]

Data structures -- _Advanced Data Structures_ by Brass. [10]

Functional programming -- _Pearls of Functional Algorithm Design_ by Bird [11] and _Purely Functional Data Structures_ by Okasaki [12].

Bit twiddling -- _Hacker 's Delight_ by Warren [13].

Distributed and parallel programming -- this material gets very hard so perhaps _Distributed Algorithms_ by Lynch [14].

Machine learning and AI related algorithms -- Bishop's _Pattern Recognition and Machine Learning_ [15] and Norvig's _Artificial Intelligence: A Modern Approach_ [16]

These books will cover most of what a Ph.D. in CS might be expected to understand about algorithms. It will take years of study to work though all of them. After that, you will be reading about algorithms in journal publications (ACM and IEEE memberships are useful). For example, a recent, practical, and important development in hashing methods is called cuckoo hashing, and I don't believe that it appears in any of the books I've listed.

[1] Sedgewick, Algorithms, 2015. [https://www.amazon.com/Algorithms-Fourth- Deluxe-24-Part-Lect...](https://www.amazon.com/Algorithms-Fourth- Deluxe-24-Part- Lecture/dp/0134384687/ref=sr_1_2?s=books&ie=UTF8&qid=1476022538&sr=1-2&keywords=sedgewick+algorithms)

[2] Cormen, et al., Introduction to Algorithms, 2009. [https://www.amazon.com/s/ref=nb_sb_ss_i_1_15?url=search- alia...](https://www.amazon.com/s/ref=nb_sb_ss_i_1_15?url=search- alias%3Dstripbooks&field- keywords=introduction+to+algorithms&sprefix=introduction+to%2Cstripbooks%2C192&rh=n%3A283155%2Ck%3Aintroduction+to+algorithms)

[3] Sedgewick, An Introduction to the Analysis of Algorithms, 2013. [https://www.amazon.com/Introduction-Analysis- Algorithms-2nd/...](https://www.amazon.com/Introduction-Analysis- Algorithms-2nd/dp/032190575X/ref=sr_1_12?s=books&ie=UTF8&qid=1476022775&sr=1-12&keywords=introduction+to+algorithms)

[4] Knuth, The Art of Computer Programming, 2011. [https://www.amazon.com/Computer-Programming- Volumes-1-4A-Box...](https://www.amazon.com/Computer-Programming- Volumes-1-4A-Boxed/dp/0321751043/ref=sr_1_1?s=books&ie=UTF8&qid=1476023445&sr=1-1&keywords=knuth+art+of+computer+programming)

[5] Tuekolsky and Vetterling, Numerical Recipes 3rd Edition: The Art of Scientific Computing, 2007. [https://www.amazon.com/Numerical-Recipes-3rd- Scientific-Comp...](https://www.amazon.com/Numerical-Recipes-3rd-Scientific- Computing/dp/0521880688/ref=sr_1_1?s=books&ie=UTF8&qid=1476023673&sr=1-1&keywords=numerical+recipes)

[6] [https://www.amazon.com/Randomized-Algorithms-Rajeev- Motwani/...](https://www.amazon.com/Randomized-Algorithms-Rajeev- Motwani/dp/0521474655/ref=sr_1_1?s=books&ie=UTF8&qid=1476024072&sr=1-1&keywords=randomized+algorithms)

[7][https://www.amazon.com/gp/product/0521835402/ref=pd_sim_14_2...](https://www.amazon.com/gp/product/0521835402/ref=pd_sim_14_2?ie=UTF8&pd_rd_i=0521835402&pd_rd_r=7D2XG33MH9N6HBWTYKRF&pd_rd_w=UDBGe&pd_rd_wg=19qp9&psc=1&refRID=7D2XG33MH9N6HBWTYKRF)

[8] Vazirani, [https://www.amazon.com/Approximation-Algorithms-Vijay-V- Vazi...](https://www.amazon.com/Approximation-Algorithms-Vijay-V- Vazirani/dp/3540653678/ref=sr_1_5?s=books&ie=UTF8&qid=1476024072&sr=1-5&keywords=randomized+algorithms)

[9] Michalewicz and Fogel, [https://www.amazon.com/How-Solve-Heuristics- Zbigniew-Michale...](https://www.amazon.com/How-Solve-Heuristics-Zbigniew- Michalewicz/dp/3540224947/ref=sr_1_3?s=books&ie=UTF8&qid=1476025082&sr=1-3&keywords=how+to+solve+it)

[10] Brass, [https://www.amazon.com/Advanced-Data-Structures-Peter- Brass/...](https://www.amazon.com/Advanced-Data-Structures-Peter- Brass/dp/0521880378)

[11] Bird, [https://www.amazon.com/Pearls-Functional-Algorithm-Design- Ri...](https://www.amazon.com/Pearls-Functional-Algorithm-Design- Richard/dp/0521513383/ref=sr_1_2?s=books&ie=UTF8&qid=1476025192&sr=1-2&keywords=functional+data+structures)

[12] Okasaki, [https://www.amazon.com/Purely-Functional-Structures-Chris- Ok...](https://www.amazon.com/Purely-Functional-Structures-Chris- Okasaki/dp/0521663504/ref=sr_1_1?s=books&ie=UTF8&qid=1476025192&sr=1-1&keywords=functional+data+structures)

[13] Warren, [https://www.amazon.com/Hackers-Delight-2nd-Henry- Warren/dp/0...](https://www.amazon.com/Hackers-Delight-2nd-Henry- Warren/dp/0321842685/ref=sr_1_1?s=books&ie=UTF8&qid=1476025457&sr=1-1&keywords=hackers+delight+2nd+edition)

[14] Lynch, [https://www.amazon.com/Distributed-Algorithms-Kaufmann- Manag...](https://www.amazon.com/Distributed-Algorithms-Kaufmann-Management- Systems/dp/1558603484/ref=sr_1_2?s=books&ie=UTF8&qid=1476025713&sr=1-2&keywords=distributed+algorithms)

[15] Bishop, [https://www.amazon.com/Pattern-Recognition-Learning- Informat...](https://www.amazon.com/Pattern-Recognition-Learning-Information- Statistics/dp/0387310738/ref=sr_1_3?s=books&ie=UTF8&qid=1476027557&sr=1-3&keywords=pattern+recognition)

[16] Norvig, [https://www.amazon.com/Artificial-Intelligence-Modern- Approa...](https://www.amazon.com/Artificial-Intelligence-Modern- Approach-3rd/dp/0136042597/ref=sr_1_1?s=books&ie=UTF8&qid=1476027736&sr=1-1&keywords=artificial+intelligence)

</comment><comment> LeonardA-L Last year was Advent of Code ( [http://adventofcode.com/](http://adventofcode.com/) ) and while they did not name them, each exercise was based on a known algorithmic problem (knapsack, traveling salesman, ...), and it was a fun way to engage people in a "1 exercise a day" pattern.

I guess you can also try your hand at CodinGame's puzzles ( [https://www.codingame.com/training](https://www.codingame.com/training) ) as they also involve known algorithms and they are realy fun to play.

But ultimately, both of these resources won't _teach_ you how to implement algorithms.

</comment><comment><USER6> You might try The Algorithm Design Manual, the second half of the book is a giant index of algorithms. The first part is a guide on what algorithms you should pick depending on what you're doing.

<comment><USER7> I second this. I particularly like how they have an in depth section on how to mathematically derive the O complexity of code, and how to build up the proof from there. It't not necessary, but a fun exercise in learning _how_ different algorithms get their complexity defined.

</comment></comment><comment><USER8> Just read The Art Of Computer Programming by Knuth very slowly. There's basically a different algorithm every other page. Of course, it will still take you years.

<comment><USER9> Donald Knuth says he usually writes his book 1 page a day[0]:

 _Usually when I write a book I finish about one page a day, I mean if the book is 365 pages long it takes me a year, if it 's 500 pages long it takes me a year and a half._

So its just normal to read it very slowly.

[0] - [https://github.com/kragen/knuth- interview-2006](https://github.com/kragen/knuth-interview-2006)

<comment><USER10> And his writing is generally very information dense. You can learn more in one page of his writing than 10 pages of many other authors.

</comment></comment></comment><comment><USER11> I'd say you'd be far better off deriving your own algorithm every day.

Make something to solve a real problem every day of your life and you'll be far better at solving problems then other people. I'd rather be able to do that then just parrot back sorts, graph traversals, and what not.

</comment><comment><USER12> [https://projecteuler.net/](https://projecteuler.net/) is an excellent tool for developing algorithmic thinking. From the project description:

The problems range in difficulty and for many the experience is inductive chain learning. That is, by solving one problem it will expose you to a new concept that allows you to undertake a previously inaccessible problem. So the determined participant will slowly but surely work his/her way through every problem.

<comment><USER13> I disagree with this recommendation; Project Euler is focused on mathematical questions that don't teach a type of thinking very similar to the thinking used while constructing most algorithms.

</comment></comment><comment><USER14> [https://github.com/e-maxx-eng/e-maxx-eng](https://github.com/e-maxx- eng/e-maxx-eng)

Pretty much in the beginning of translation to English, but the original resource in Russian is a trove of information on algorithms. Suits well for the "one also a day" learning format.

</comment><comment><USER15> Wikipedia? [https://en.wikipedia.org/wiki/List_of_algorithms](https://en.wikipedia.org/wiki/List_of_algorithms)

</comment><comment><USER16> You can try competitive programming course by ITMO on edx ([https://www.edx.org/course/how-win-coding-competitions- secre...](https://www.edx.org/course/how-win-coding-competitions-secrets- itmox-i2cpx)). It's going to start on 17th October.

</comment><comment><USER17> [https://www.hackerearth.com/practice/codemonk/](https://www.hackerearth.com/practice/codemonk/)

</comment><comment><USER18> You might be interested in Programming Praxis [https://programmingpraxis.com/](https://programmingpraxis.com/), a blog that posts a few exercises per week, with solutions. Some of them are more interesting, some of them less so.

</comment><comment><USER19> [https://www.interviewcake.com/](https://www.interviewcake.com/) is a great site. Eventually you need to pay, but he send out a question almost every day you can try out.

</comment><comment><USER20> I would recommend "The New Turing Omnibus" book by A.K. Dewdney: [http://amzn.to/2dGetic](http://amzn.to/2dGetic)

Jeff Atwood aka CodingHorror (of Stackoverflow and Discourse fame) recommended this book strongly in this post titled "Practicing the Fundamentals: The New Turing Omnibus ": [https://blog.codinghorror.com/practicing-the-fundamentals- th...](https://blog.codinghorror.com/practicing-the-fundamentals-the-new- turing-omnibus/)

</comment><comment><USER21> If you want to learn an algorithm I suggest implementing it as well. Since this question does not state any prerequisites I can only suggest the hands down best practical datastructure and algorithm study and reference book I've come accross: [http://infolab.stanford.edu/~ullman/focs.html](http://infolab.stanford.edu/~ullman/focs.html)

It's old but concise and very much to the point. All of the material is highly practical.

</comment><comment><USER22> [http://www.geeksforgeeks.org/](http://www.geeksforgeeks.org/) has a collection of algorithms and puzzles split by topics.

</comment><comment><USER23> In no particular order, I'd recommend reading:

* Introduction to Algorithms, by Cormen et al (aka "CLRS")

* Any of Robert Sedgewick's books on Algorithms ("Algorithms is C++", "Algorithms in Java", etc)

* The Art of Computer Programming by Knuth.

* If you want a more math-focused approach, Knuth has another book called "Concrete Mathematics" which might be worth your time.

* If you want something fun and accessible check out "9 Algorithms that Changed the Future" by MacCormick

</comment><comment><USER24> [https://www.hackerrank.com/](https://www.hackerrank.com/) Has an algorithm section, might be worth a look!

</comment><comment><USER25> I found a relevant app _Algorithms: Explained & Animated_ [1] that was just posted as a new HN story [2].

[1] [http://algorithm.wiki/](http://algorithm.wiki/) [2] [https://news.ycombinator.com/item?id=12670674](https://news.ycombinator.com/item?id=12670674)

</comment><comment><USER26> Aside from agreeing with other answers (you can't... and probably wouldn't get a good return from it)...

[https://www.hackerrank.com/](https://www.hackerrank.com/) has a lot of great algorithm challenges. They won't teach you how to do it but you need to learn the algorithms to solve the problems.

</comment><comment><USER27> We've been working on a project with a small community of developers that helps rank various tools and recommendations:

[http://www.differable.com/technical-interview-preparation- an...](http://www.differable.com/technical-interview-preparation-and-practice- problems)

Would love to hear if this is helpful to you.

</comment><comment><USER28> Code Wars is my favorite. The earlier ranks are pretty simple but there's a broad depth of challenging problems at the higher levels. Online editor and test runner verifies your solution and the community aspects are a big win.

[https://www.codewars.com/](https://www.codewars.com/)

</comment><comment><USER29> I found this Android app very nice: [https://play.google.com/store/apps/details?id=wiki.algorithm...](https://play.google.com/store/apps/details?id=wiki.algorithm.algorithms)

</comment><comment><USER30> Go for [http://www.spoj.com/](http://www.spoj.com/), every question there needed an algorithm and doing one question per day will help you in getting better and better in algorithms per day.

</comment><comment><USER31> Hackerrank! I am currently taking an Algorithms course at Uni and I have found HackerRank's questions to be a great way to practice your coding skills. It can also help you out for recruiting.

</comment><comment><USER32> Highly recommend Grokking Algorithms for beginners and refreshes.

</comment><comment><USER33> [https://algo.is/](https://algo.is/) is great

</comment><comment><USER34> I suggest a dose of reality:

You can't. You may be able to consume the knowledge underpinning an algorithm and parrot it back but any attempt to _learn_ it in one day is doomed to failure. Parrot knowledge has zero retention.

<comment><USER35> There's truth to this of course, but I do find that self-imposed checkpoints are a great source of motivation. Rather than 1 algorithm/day, a better plan (in my experience) would be to find a nice textbook, and schedule a chapter/month (depending on the density of the chosen text) with flexibility.

<comment><USER34> How about not making it a race and just learning the shit out of any one algorithm at a time?

<comment><USER35> because "learning the shit out of any one algorithm" is not a very well- defined goal and is at best, a locally optimal strategy. If the OP's goal is to become literate in a many topics, then learning those topics in broad strokes may be better than learning all the details up front.

There often can be a vast literature on any one given topic or algorithm. Are you suggesting the OP acquire researcher-level expertise in everything? Everybody, at some point while learning, makes the decision as to whether or not they understand _enough for their own purposes_ , and then chooses to dive deeper or move on to something else.

<comment><USER36> Not to overuse buzz terms, but the idea of repeatedly grazing over new concepts without ever gaining a firm grasp of them is a textbook local max way of learning.

Going deep on one algo at a time not only gives you a grasp of that individual algo; it gives you insight into computer science as a whole.

Not to mention that over time it would also look like broad strokes

</comment></comment></comment></comment></comment><comment><USER37> Taking up a new algorithm each day is the best way I can think of to be sure you don't know _any_ algorithms well. Learn what the various algorithms are, what problems they solve, and what the general classifications of them are, then move on. You are then empowered to dig deeper into the correct one once you have the actual need for one, you know if it exists or not, and how to begin.</comment>