In 2002, my hus­band and I be­came se­ri­ously ill af­ter a va­ca­tion to Martha’s Vineyard. It took ten doc­tors and a year to dis­cover the root cause: We’d been bit­ten by un­seen ticks har­bor­ing the par­a­sites that cause Lyme dis­ease and babesio­sis, a malaria-like dis­ease.

Our road to re­cov­ery was gru­el­ing, re­quir­ing five years of in­ter­mit­tent an­timi­cro­bial treat­ments. Later, I dis­cover that my sit­u­a­tion was­n’t all that un­com­mon. About one in five Lyme pa­tients con­tinue to suf­fer from on­go­ing symp­toms af­ter be­ing treated with the rec­om­mended course of an­tibi­otics. After that ex­pe­ri­ence, it was abun­dantly clear that we need bet­ter treat­ments.

That’s why I was ex­cited to hear about a study from Stanford Medicine re­searchers and their col­lab­o­ra­tors that pro­vides ev­i­dence that the drug azlocillin elim­i­nates the bac­te­ria that cause Lyme dis­ease at the on­set of in­fec­tion in lab mice and cul­tures.

Lyme dis­ease, the most com­mon vec­tor-borne dis­ease in the United States, af­fects more than 300,000 peo­ple a year. It is caused by the bac­terium Borrelia burgdor­feri, which is trans­mit­ted to hu­mans through the bite of in­fected black­legged ticks. If the dis­ease is­n’t treated promptly, it can lead to life-threat­en­ing heart is­sues and chronic neu­ro­log­i­cal prob­lems. Common per­sis­tent Lyme symp­toms in­clude fa­tigue, joint pain, mus­cle pain, numb­ness, tin­gling, burn­ing pains, and changes in mood, mem­ory or men­tal clar­ity.

Standard treat­ment of Lyme dis­ease is oral an­tibi­otics, typ­i­cally doxy­cy­cline, in the early stages of the dis­ease; but for rea­sons that are un­clear, the an­tibi­otics don’t work for up to 20% of peo­ple with the tick-borne ill­ness. One pos­si­bil­ity is that drug-tol­er­ant bac­te­ria cause the lin­ger­ing symp­toms.

This drug study, pub­lished on­line in Scientific Reports, was con­ducted by a team led by Jayakumar Rajadas, PhD, as­sis­tant pro­fes­sor of med­i­cine and di­rec­tor of Stanford’s Biomaterials and Advanced Drug Delivery Laboratory, and re­search as­so­ci­ate Venkata Raveendra Pothineni, PhD.

The team ze­roed in on azlocillin as a promis­ing drug can­di­date through the use of high through­put drug screen­ing. This process en­tails ac­quir­ing “libraries” of thou­sands of known chem­i­cal com­pounds and drugs, then mix­ing Lyme bac­te­ria with each in tiny wells to see which ones are best at killing the or­gan­isms. The best drug can­di­dates were retested in larger cul­ture dishes, then the safest of these were tested in vivo in seven mice.

Early re­sults of this team’s screen­ing process, first pub­lished in 2016, led to the dis­cov­ery of an­other promis­ing Lyme drug can­di­date, disul­fi­ram, which is ap­proved by the Food and Drug Administration for the treat­ment of al­co­hol abuse dis­or­der. This drug is cur­rently be­ing eval­u­ated in a clin­i­cal trial with pre­vi­ously-treated Lyme pa­tients. The trial co­or­di­na­tors are still look­ing for vol­un­teers.

According to the re­cent study, azlocillin shows promise be­cause it ap­pears to be able to kill the two mor­pho­log­i­cal forms of the Lyme bac­te­ria — the ac­tively repli­cat­ing spi­ral forms and the semi-dor­mant round-body forms.

Azlocillin also ap­pears to kill drug-tol­er­ant per­sis­ters very ef­fec­tively. These pro­tec­tive per­sis­ters form when the bac­te­ria are threat­ened with de­fen­sive im­mune sys­tem bio­chem­i­cals or an­tibi­otics. After the threat has passed, the bac­te­ria can reemerge to cause ac­tive dis­ease. Many re­searchers be­lieve that doxy­cy­line’s in­abil­ity to clear the per­sis­ters may ac­count for the on­go­ing symp­toms of some Lyme suf­fer­ers.

Although azlocillin is an FDA-approved drug, more re­search needs to be done be­fore it is used to treat Lyme pa­tients. Rajadas and Pothineni have patented the com­pound for the treat­ment of Lyme dis­ease and are work­ing with a com­pany to de­velop an oral form of the drug. Researchers plan to con­duct a clin­i­cal trial.

As Pothineni said in the Stanford Medicine news re­lease:

“We have been screen­ing po­ten­tial drugs for six years … We’ve screened al­most 8,000 chem­i­cal com­pounds. We have tested 50 mol­e­cules in the dish. The most ef­fec­tive and safest mol­e­cules were tested in an­i­mal mod­els. Along the way, I’ve met many peo­ple suf­fer­ing with this hor­ri­ble, lin­ger­ing dis­ease. Our main goal is to find the best com­pound for treat­ing pa­tients and stop this dis­ease.”

A for­mer sci­ence writer with Stanford Medicine, Kris Newby is the au­thor of Bitten: The Secret History of Lyme Disease and Biological Weapons. She is now work­ing on a doc­u­men­tary based on the book.

Photo by Image by Gabor Tinz/Shutterstock. Image cour­tesy of Michal Tal, PhD, in­struc­tor at Stanford’s Institute for Stem Cell Biology and Regenerative Medicine.

As the Coronavirus pan­demic con­tin­ues to force peo­ple to work from home, count­less com­pa­nies are now hold­ing daily meet­ings us­ing video­con­fer­enc­ing ser­vices from Zoom. But with­out the pro­tec­tion of a pass­word, there’s a de­cent chance your next Zoom meet­ing could be “Zoom bombed” — at­tended or dis­rupted by some­one who does­n’t be­long. And ac­cord­ing to data gath­ered by a new au­to­mated Zoom meet­ing dis­cov­ery tool dubbed “zWarDial,” a crazy num­ber of meet­ings at ma­jor cor­po­ra­tions are not be­ing pro­tected by a pass­word.

Each Zoom con­fer­ence call is as­signed a Meeting ID that con­sists of 9 to 11 dig­its. Naturally, hack­ers have fig­ured out they can sim­ply guess or au­to­mate the guess­ing of ran­dom IDs within that space of dig­its.

Security ex­perts at Check Point Research did ex­actly that last sum­mer, and found they were able to pre­dict ap­prox­i­mately four per­cent of ran­domly gen­er­ated Meeting IDs. The Check Point re­searchers said en­abling pass­words on each meet­ing was the only thing that pre­vented them from ran­domly find­ing a meet­ing.

Zoom re­sponded by say­ing it was en­abling pass­words by de­fault in all fu­ture sched­uled meet­ings. Zoom also said it would block re­peated at­tempts to scan for meet­ing IDs, and that it would no longer au­to­mat­i­cally in­di­cate if a meet­ing ID was valid or in­valid.

Nevertheless, the in­ci­dence of Zoombombing has sky­rock­eted over the past few weeks, even prompt­ing an alert by the FBI on how to se­cure meet­ings against eaves­drop­pers and mis­chief-mak­ers. This sug­gests that many Zoom users have dis­abled pass­words by de­fault and/​or that Zoom’s new se­cu­rity fea­ture sim­ply is­n’t work­ing as in­tended for all users.

New data and ac­knowl­edg­ments by Zoom it­self sug­gest the lat­ter may be more likely.

Earlier this week, KrebsOnSecurity heard from Trent Lo, a se­cu­rity pro­fes­sional and co-founder of SecKC, Kansas City’s longest-run­ning monthly se­cu­rity meetup. Lo and fel­low SecKC mem­bers re­cently cre­ated zWar­Dial, which bor­rows part of its name from the old phone-based war di­al­ing pro­grams that called ran­dom or se­quen­tial num­bers in a given tele­phone num­ber pre­fix to search for com­puter modems.

Lo said zWar­Dial evades Zoom’s at­tempts to block au­to­mated meet­ing scans by rout­ing the searches through mul­ti­ple prox­ies in Tor, a free and open-source soft­ware that lets users browse the Web anony­mously.

“Zoom re­cently said they fixed this but I’m us­ing a to­tally dif­fer­ent URL and pass­ing a cookie along with that URL,” Lo said, de­scrib­ing part of how the tool works on the back end. “This gives me the [Zoom meet­ing] room in­for­ma­tion with­out hav­ing to log in.”

Lo said a sin­gle in­stance of zWar­Dial can find ap­prox­i­mately 100 meet­ings per hour, but that mul­ti­ple in­stances of the tool run­ning in par­al­lel could prob­a­bly dis­cover most of the open Zoom meet­ings on any given day. Each in­stance, he said, has a suc­cess rate of ap­prox­i­mately 14 per­cent, mean­ing for each ran­dom meet­ing num­ber it tries, the pro­gram has a 14 per­cent chance of find­ing an open meet­ing.

Only meet­ings that are pro­tected by a pass­word are un­de­tectable by zWar­Dial, Lo said.

“Having a pass­word en­abled on the meet­ing is the only thing that de­feats it,” he said.

Lo shared the out­put of one day’s worth of zWar­Dial scan­ning, which re­vealed in­for­ma­tion about nearly 2,400 up­com­ing or re­cur­ring Zoom meet­ings. That in­for­ma­tion in­cluded the link needed to join each meet­ing; the date and time of the meet­ing; the name of the meet­ing or­ga­nizer; and any in­for­ma­tion sup­plied by the meet­ing or­ga­nizer about the topic of the meet­ing.

The re­sults were stag­ger­ing, and re­vealed de­tails about Zoom meet­ings sched­uled by some of the world’s largest com­pa­nies, in­clud­ing ma­jor banks, in­ter­na­tional con­sult­ing firms, ride-hail­ing ser­vices, gov­ern­ment con­trac­tors, and in­vest­ment rat­ings firms.

KrebsOnSecurity is not nam­ing the com­pa­nies in­volved, but was able to ver­ify dozens of them by match­ing the name of the meet­ing or­ga­nizer with cor­po­rate pro­files on LinkedIn.

By far the largest group of com­pa­nies ex­pos­ing their Zoom meet­ings are in the tech­nol­ogy sec­tor, and in­clude a num­ber of se­cu­rity and cloud tech­nol­ogy ven­dors. These in­clude at least one tech com­pany that’s taken to so­cial me­dia warn­ing peo­ple about the need to pass­word pro­tect Zoom meet­ings!

Given the pre­pon­der­ance of Zoom meet­ings ex­posed by se­cu­rity and tech­nol­ogy com­pa­nies that os­ten­si­bly should know bet­ter, KrebsOnSecurity asked Zoom whether its ap­proach of adding pass­words by de­fault to all new meet­ings was ac­tu­ally work­ing as in­tended.

In re­ply, Zoom said it was in­ves­ti­gat­ing the pos­si­bil­ity that its pass­word-by-de­fault ap­proach may fail un­der cer­tain cir­cum­stances.

“Zoom strongly en­cour­ages users to im­ple­ment pass­words for all of their meet­ings to en­sure un­in­vited users are not able to join,” the com­pany said in a writ­ten state­ment shared with this au­thor.

“Passwords for new meet­ings have been en­abled by de­fault since late last year, un­less ac­count own­ers or ad­mins opted out,” the state­ment con­tin­ues. “We are look­ing into unique edge cases to de­ter­mine whether, un­der cer­tain cir­cum­stances, users un­af­fil­i­ated with an ac­count owner or ad­min­is­tra­tor may not have had pass­words switched on by de­fault at the time that change was made.”

The ac­knowl­edg­ment comes amid a se­ries of se­cu­rity and pri­vacy stum­bles for Zoom, which has seen its user base grow ex­po­nen­tially in re­cent weeks. Zoom founder and chief ex­ec­u­tive Eric Yuan said in a re­cent blog post that the max­i­mum num­ber of daily meet­ing par­tic­i­pants — both paid and free — has grown from around 10 mil­lion in December to 200 mil­lion in March.

That rapid growth has also brought ad­di­tional scrutiny from se­cu­rity and pri­vacy ex­perts, who’ve found plenty of real and po­ten­tial prob­lems with the ser­vice of late. TechCrunch’s Zack Whittaker has a fairly com­pre­hen­sive break­down of them here; not in­cluded in that list is a story he broke ear­lier this week on a pair of zero-day vul­ner­a­bil­i­ties in Zoom that were pub­licly de­tailed by a for­mer NSA ex­pert.

Zoom CEO Yuan ac­knowl­edged that his com­pany has strug­gled to keep up with steeply grow­ing de­mand for its ser­vice and with the ad­di­tional scrutiny that comes with it, say­ing in a blog post that for the next 90 days all new fea­ture de­vel­op­ment was be­ing frozen so the com­pa­ny’s en­gi­neers could fo­cus on se­cu­rity is­sues.

Dave Kennedy, a se­cu­rity ex­pert and founder of the se­cu­rity con­sul­tancy TrustedSec, penned a lengthy thread on Twitter say­ing while Zoom cer­tainly has had its share of se­cu­rity and pri­vacy goofs, some in the se­cu­rity com­mu­nity are un­nec­es­sar­ily ex­ac­er­bat­ing an al­ready tough sit­u­a­tion for Zoom and the tens of mil­lions of users who rely on it for day-to-day meet­ings.

“What we have here is a com­pany that is rel­a­tively easy to use for the masses (comes with its chal­lenges on per­sonal meet­ing IDs) and is rel­a­tively se­cure,” Kennedy wrote. “Yet the in­dus­try is mak­ing it out to be ‘this is mal­ware’ and you can’t use this. This is ex­treme. We need to look at the risk spe­cific ap­pli­ca­tions pose and help voice a mes­sage of how peo­ple can lever­age tech­nol­ogy and be safe. Dropping zero-days to the me­dia hurts our cred­i­bil­ity, sen­sa­tion­al­izes fear, and hurts oth­ers.”

“If there are ways for a com­pany to im­prove, we should no­tify them and if they don’t fix their is­sues, we should call them out,” he con­tin­ued. “We should not be putting fear into every­one, and lever­ag­ing the me­dia as a method to cre­ate that fear.”

Zoom’s ad­vice on se­cur­ing meet­ings is here. SecKC’s Lo said or­ga­ni­za­tions us­ing Zoom should avoid post­ing the Zoom meet­ing links on so­cial me­dia, and al­ways re­quire a meet­ing pass­word when pos­si­ble.

“This should be en­abled by de­fault as a new cus­tomer or a trial user,” he said. “Legacy or­ga­ni­za­tions will need to check their ad­min­is­tra­tion set­tings to make sure this is en­abled. You can also en­able ‘Embed pass­word in meet­ing link for one-click join.’ This pre­vents an ac­tor from ac­cess­ing your meet­ing with­out los­ing the us­abil­ity of shar­ing a link to join.”

In ad­di­tion, Zoom users can dis­able “Allow par­tic­i­pants to join the meet­ing be­fore the host ar­rives.”

“If you have to have this fea­ture en­abled at least en­able “notify host when par­tic­i­pants join the meet­ing be­fore them,” Lo ad­vised. “This will no­tify you that some­one might be us­ing your meet­ing with­out your knowl­edge. If you must keep your meet­ing un­pro­tected you should en­able ‘Mask phone num­ber in the par­tic­i­pant list.’ Using the wait­ing list fea­ture will pre­vent un­wanted par­tic­i­pants from ac­cess­ing your meet­ing but it will still ex­pose your meet­ing de­tails if used with­out a pass­word.”

This en­try was posted on Thursday, April 2nd, 2020 at 10:43 am and is filed un­der A Little Sunshine, The Coming Storm, Time to Patch.

You can fol­low any com­ments to this en­try through the RSS 2.0 feed.

You can skip to the end and leave a com­ment. Pinging is cur­rently not al­lowed.

Other uses for Touch ID and Face ID

How data files are cre­ated and pro­tected

When a user sets up a Mac on their own

When a Mac is pro­vi­sioned by an or­ga­ni­za­tion

Sending pass­words to other users or de­vices

Adding credit or debit cards from an iTunes Store ac­count

Pay with credit and debit cards in stores

Pay with credit and debit cards within apps

Paying with credit and debit cards on the web

All Mac porta­bles with the Apple T2 Security Chip fea­ture a hard­ware dis­con­nect that en­sures the mi­cro­phone is dis­abled when­ever the lid is closed. On the 13-inch MacBook Pro and MacBook Air com­put­ers with the T2 chip, and on the 15-inch MacBook Pro porta­bles from 2019 or later, this dis­con­nect is im­ple­mented in hard­ware alone. The dis­con­nect pre­vents any soft­ware—even with root or ker­nel priv­i­leges in ma­cOS, and even the soft­ware on the T2 chip—from en­gag­ing the mi­cro­phone when the lid is closed. (The cam­era is not dis­con­nected in hard­ware, be­cause its field of view is com­pletely ob­structed with the lid closed.)iPad mod­els be­gin­ning in 2020 also fea­ture the hard­ware mi­cro­phone dis­con­nect. When an MFI com­pli­ant case (including those sold by Apple) is at­tached to the iPad and closed, the mi­cro­phone is dis­con­nected in hard­ware, pre­vent­ing mi­cro­phone au­dio data be­ing made avail­able to any soft­ware—even with root or ker­nel priv­i­leges in iPa­dOS or in case the firmware is com­pro­mised.

Please don’t in­clude any per­sonal in­for­ma­tion in your com­ment.

Thanks for your feed­back.

Diving deeper into PLT, though, is a great way to grow as a de­vel­oper. Not only is lan­guage de­sign a lot of fun, but a deeper un­der­stand­ing of the tools you use every day will give you a bet­ter han­dle on them, and can make learn­ing new lan­guages con­sid­er­ably eas­ier, even if you don’t dream of be­com­ing the next Guido van Rossum or Rich Hickey. And hey, you never know—your per­sonal pro­ject could be­come the next ma­jor piece of soft­ware en­gi­neer­ing in­fra­struc­ture. It’s hap­pened be­fore.

The field of study of pro­gram­ming lan­guages is called pro­gram­ming lan­guage the­ory, or PLT. Software en­gi­neers are con­fronted with pro­gram­ming lan­guages just about every day, but few de­velop a deep re­la­tion­ship with PLT. Languages are tools, pri­mar­ily, a means to an end, and most pro­fes­sion­als will do fine just learn­ing to use the pop­u­lar ones well enough to get their jobs done.

The thing is, I ab­solutely love pro­gram­ming lan­guages. I work as a graph­ics and video game de­vel­oper, which is thrilling and chal­leng­ing work, but se­cretly I would rather be hack­ing on com­pil­ers. I love lan­guages be­cause, of every­thing I’ve en­coun­tered in com­put­ing, lan­guages are by far the weird­est. They com­bine the brain-bend­ing rigor of ab­stract math, the crush­ing pres­sures of cap­i­tal­is­tic in­dus­try, and the ir­ra­tional anx­i­ety of a high school prom. The de­ci­sion to adopt or avoid a lan­guage is al­ways a mix of their per­ceived for­mal power (“Does this lan­guage even have this par­tic­u­lar fea­ture?”), em­ploy­a­bil­ity (“Will this lan­guage get me a job?”), and pop­u­lar­ity (“Does any­one im­por­tant use this lan­guage any­more?”). I can’t think of an­other en­gi­neer­ing tool that de­mands sim­i­lar quasi-re­li­gious de­vo­tion from its users. Programming lan­guages ask us to re­shape our minds, and that makes them deeply per­sonal and sub­jec­tive.

Late one night on an un­crowded sub­way car in New York City, I had my lap­top open, work­ing on a game whose dead­line was draw­ing near. A gen­tle­man sat next to me and, see­ing the walls of col­ored text on my screen, asked if I was writ­ing C++. I told him I was­n’t, and he was cu­ri­ous to hear what lan­guage I was us­ing. I was work­ing on a web game in a pro­gram­ming lan­guage I had de­signed for my­self, and I told him so—it was some­thing that I made up, I said. After look­ing at me for a mo­ment, he asked, “Why would any­one do that?” I started to an­swer, but alas, we had ar­rived at his stop, and he dis­ap­peared onto the plat­form be­fore I could ex­plain my­self. In many ways, I’ve been try­ing to an­swer that man’s ques­tion for years now.

The clas­sic ex­am­ple is a com­piler for the C pro­gram­ming lan­guage, where source code writ­ten in C is com­piled into ma­chine code that a com­put­er’s hard­ware can ex­e­cute di­rectly. In this case, a higher-level lan­guage is com­piled into a lower-level one. C# and Java are sim­i­lar, but they com­pile into byte­codes that are ex­e­cuted by the Common Language Runtime (CLR) and the Java vir­tual ma­chine (JVM), re­spec­tively, as op­posed to phys­i­cal hard­ware. Virtual ma­chines like the CLR and the JVM pro­vide cross-plat­form en­vi­ron­ments that han­dle a lot of low-level de­tails for you while pro­vid­ing ad­di­tional func­tion­al­ity like garbage col­lec­tion and a type sys­tem. There are even cases where it is de­sir­able to com­pile a lower-level lan­guage into a higher-level one. To run in the browser, the JSIL pro­ject com­piles C# byte­code into JavaScript so it can run on the web, and Emscripten does the same for C and C++. There are also sit­u­a­tions where the same lan­guage is both the source and tar­get lan­guage. The so-called tran­spilers Babel and Closure com­pile JavaScript into JavaScript in or­der to ac­cess new fea­tures of the lan­guage and im­ple­ment op­ti­miza­tions, re­spec­tively.

Bytecode re­sem­bles ma­chine code, but it is de­signed to be ex­e­cuted by a vir­tual ma­chine rather than by phys­i­cal hard­ware. As a re­sult, byte­code can be higher-level (i.e., it can rep­re­sent con­structs that hard­ware does not di­rectly sup­port) and more portable (i.e., the same byte­code can run on dif­fer­ent ma­chine ar­chi­tec­tures).

This piece, how­ever, will fo­cus on com­pil­ers. The job of a com­piler is to take source code and trans­late it into a tar­get code with the same mean­ing. Often that tar­get code is in a lower-level lan­guage like ma­chine code, but that is­n’t al­ways the case. The gen­er­ated tar­get code can then be eval­u­ated in or­der to carry out the com­pu­ta­tion of the orig­i­nal source code. Compilers can be thought of as a pipeline of trans­for­ma­tions, start­ing with the pro­gram­mer’s source code and pro­ceed­ing through a se­ries of in­ter­nal rep­re­sen­ta­tions that end in the de­sired tar­get code, af­ter which it is handed off to an­other sys­tem for eval­u­a­tion.

An in­ter­preter’s job is to take source code and im­me­di­ately im­ple­ment its ef­fects. An in­ter­preter turns source code into an in­ter­nal rep­re­sen­ta­tion that it can use to carry out the com­pu­ta­tion the source code de­scribes. This rep­re­sen­ta­tion will in­clude the func­tions, vari­ables, ex­pres­sions, state­ments, and all other se­man­tics of the source lan­guage. You can think of source code as an ex­treme, Turing-complete con­fig­u­ra­tion file that con­trols the in­ter­preter’s be­hav­ior. My first foray into lan­guage de­sign was based on Peter Norvig’s ex­cel­lent Lispy in­ter­preter in Python, and the more re­cent MAL pro­ject has amassed im­ple­men­ta­tions in 72 lan­guages. The ad­van­tages of in­ter­preters in­clude their sim­plic­ity, the fact that they can of­ten start ex­e­cut­ing faster than com­pil­ers, and their abil­ity to run in en­vi­ron­ments where com­pil­ing new code is pro­hib­ited (like on iOS or most video game con­soles).

In prac­tice, you in­ter­act with pro­gram­ming lan­guages via com­puter pro­grams or soft­ware li­braries into which you feed code in or­der to pro­duce an ef­fect. They come in two broad man­i­fes­ta­tions: as com­pil­ers and as in­ter­preters. Each ap­proach has its ad­van­tages and dis­ad­van­tages, and the line be­tween the two can be quite blurry, with frame­works like Mono go­ing so far as to of­fer both si­mul­ta­ne­ously.

The de­ci­sive fac­tor in what makes some­thing a pro­gram­ming lan­guage (or not) is known as Turing com­plete­ness. Alan Turing’s sem­i­nal work in the 1940s in­cluded the de­f­i­n­i­tion of the Turing ma­chine, a math­e­mat­i­cal de­scrip­tion of an ab­stract com­puter that be­came foun­da­tional for our un­der­stand­ing of how al­go­rithms work. A Turing ma­chine can, prov­ably, im­ple­ment any com­putable al­go­rithm, and any sys­tem that can sim­u­late the Turing ma­chine can do so as well. Such a sys­tem is deemed Turing com­plete, and most pro­gram­ming lan­guages have this sta­tus as a ba­sic goal (though there are some in­ter­est­ing lan­guages that do not). A deep dive into com­putabil­ity the­ory is be­yond the scope of this ar­ti­cle, but suf­fice it to say that a lan­guage with some no­tion of state (often vari­ables or ar­gu­ment pass­ing) and con­di­tion­als is most likely Turing com­plete. This leaves out markup lan­guages like HTML and con­fig­u­ra­tion lan­guages like YAML or JSON, but in­cludes a hi­lar­i­ous col­lec­tion of sys­tems that are ac­ci­den­tally Turing com­plete (including an abuse of HTML and CSS).

So, what is a pro­gram­ming lan­guage? This might seem like an odd ques­tion to ask about tools this ubiq­ui­tous, but start­ing from a de­f­i­n­i­tion is of­ten help­ful to fo­cus the con­ver­sa­tion. A pro­gram­ming lan­guage is a for­mal lan­guage used to com­mu­ni­cate in­struc­tions to a com­puter. It is for­mal in that it con­forms to a rigid set of rules that de­ter­mine what is and is not al­lowed. It is a means of com­mu­ni­ca­tion in that the pri­mary goal of the tool is to trans­late ideas in a pro­gram­mer’s head into a form that a com­puter can act on. The fact that you are com­mu­ni­cat­ing with a com­puter is sig­nif­i­cant. Unlike other forms of lan­guage, or even in­struc­tional arts like mu­si­cal com­po­si­tion or screen­writ­ing, the fi­nal agent ful­fill­ing the in­struc­tions is not hu­man. The re­sult is that qual­i­ties that other forms of com­mu­ni­ca­tion tend to de­pend on—like in­tu­ition, com­mon sense, and con­text—are not avail­able.

Diving deeper into PLT, though, is a great way to grow as a de­vel­oper. Not only is lan­guage de­sign a lot of fun, but a deeper un­der­stand­ing of the tools you use every day will give you a bet­ter han­dle on them, and can make learn­ing new lan­guages con­sid­er­ably eas­ier, even if you don’t dream of be­com­ing the next Guido van Rossum or Rich Hickey. And hey, you never know—your per­sonal pro­ject could be­come the next ma­jor piece of soft­ware en­gi­neer­ing in­fra­struc­ture. It’s hap­pened be­fore.

The field of study of pro­gram­ming lan­guages is called pro­gram­ming lan­guage the­ory, or PLT. Software en­gi­neers are con­fronted with pro­gram­ming lan­guages just about every day, but few de­velop a deep re­la­tion­ship with PLT. Languages are tools, pri­mar­ily, a means to an end, and most pro­fes­sion­als will do fine just learn­ing to use the pop­u­lar ones well enough to get their jobs done.

The thing is, I ab­solutely love pro­gram­ming lan­guages. I work as a graph­ics and video game de­vel­oper, which is thrilling and chal­leng­ing work, but se­cretly I would rather be hack­ing on com­pil­ers. I love lan­guages be­cause, of every­thing I’ve en­coun­tered in com­put­ing, lan­guages are by far the weird­est. They com­bine the brain-bend­ing rigor of ab­stract math, the crush­ing pres­sures of cap­i­tal­is­tic in­dus­try, and the ir­ra­tional anx­i­ety of a high school prom. The de­ci­sion to adopt or avoid a lan­guage is al­ways a mix of their per­ceived for­mal power (“Does this lan­guage even have this par­tic­u­lar fea­ture?”), em­ploy­a­bil­ity (“Will this lan­guage get me a job?”), and pop­u­lar­ity (“Does any­one im­por­tant use this lan­guage any­more?”). I can’t think of an­other en­gi­neer­ing tool that de­mands sim­i­lar quasi-re­li­gious de­vo­tion from its users. Programming lan­guages ask us to re­shape our minds, and that makes them deeply per­sonal and sub­jec­tive.

Late one night on an un­crowded sub­way car in New York City, I had my lap­top open, work­ing on a game whose dead­line was draw­ing near. A gen­tle­man sat next to me and, see­ing the walls of col­ored text on my screen, asked if I was writ­ing C++. I told him I was­n’t, and he was cu­ri­ous to hear what lan­guage I was us­ing. I was work­ing on a web game in a pro­gram­ming lan­guage I had de­signed for my­self, and I told him so—it was some­thing that I made up, I said. After look­ing at me for a mo­ment, he asked, “Why would any­one do that?” I started to an­swer, but alas, we had ar­rived at his stop, and he dis­ap­peared onto the plat­form be­fore I could ex­plain my­self. In many ways, I’ve been try­ing to an­swer that man’s ques­tion for years now.

The clas­sic ex­am­ple is a com­piler for the C pro­gram­ming lan­guage, where source code writ­ten in C is com­piled into ma­chine code that a com­put­er’s hard­ware can ex­e­cute di­rectly. In this case, a higher-level lan­guage is com­piled into a lower-level one. C# and Java are sim­i­lar, but they com­pile into byte­codes that are ex­e­cuted by the Common Language Runtime (CLR) and the Java vir­tual ma­chine (JVM), re­spec­tively, as op­posed to phys­i­cal hard­ware. Virtual ma­chines like the CLR and the JVM pro­vide cross-plat­form en­vi­ron­ments that han­dle a lot of low-level de­tails for you while pro­vid­ing ad­di­tional func­tion­al­ity like garbage col­lec­tion and a type sys­tem. There are even cases where it is de­sir­able to com­pile a lower-level lan­guage into a higher-level one. To run in the browser, the JSIL pro­ject com­piles C# byte­code into JavaScript so it can run on the web, and Emscripten does the same for C and C++. There are also sit­u­a­tions where the same lan­guage is both the source and tar­get lan­guage. The so-called tran­spilers Babel and Closure com­pile JavaScript into JavaScript in or­der to ac­cess new fea­tures of the lan­guage and im­ple­ment op­ti­miza­tions, re­spec­tively.

Bytecode re­sem­bles ma­chine code, but it is de­signed to be ex­e­cuted by a vir­tual ma­chine rather than by phys­i­cal hard­ware. As a re­sult, byte­code can be higher-level (i.e., it can rep­re­sent con­structs that hard­ware does not di­rectly sup­port) and more portable (i.e., the same byte­code can run on dif­fer­ent ma­chine ar­chi­tec­tures).

This piece, how­ever, will fo­cus on com­pil­ers. The job of a com­piler is to take source code and trans­late it into a tar­get code with the same mean­ing. Often that tar­get code is in a lower-level lan­guage like ma­chine code, but that is­n’t al­ways the case. The gen­er­ated tar­get code can then be eval­u­ated in or­der to carry out the com­pu­ta­tion of the orig­i­nal source code. Compilers can be thought of as a pipeline of trans­for­ma­tions, start­ing with the pro­gram­mer’s source code and pro­ceed­ing through a se­ries of in­ter­nal rep­re­sen­ta­tions that end in the de­sired tar­get code, af­ter which it is handed off to an­other sys­tem for eval­u­a­tion.

An in­ter­preter’s job is to take source code and im­me­di­ately im­ple­ment its ef­fects. An in­ter­preter turns source code into an in­ter­nal rep­re­sen­ta­tion that it can use to carry out the com­pu­ta­tion the source code de­scribes. This rep­re­sen­ta­tion will in­clude the func­tions, vari­ables, ex­pres­sions, state­ments, and all other se­man­tics of the source lan­guage. You can think of source code as an ex­treme, Turing-complete con­fig­u­ra­tion file that con­trols the in­ter­preter’s be­hav­ior. My first foray into lan­guage de­sign was based on Peter Norvig’s ex­cel­lent Lispy in­ter­preter in Python, and the more re­cent MAL pro­ject has amassed im­ple­men­ta­tions in 72 lan­guages. The ad­van­tages of in­ter­preters in­clude their sim­plic­ity, the fact that they can of­ten start ex­e­cut­ing faster than com­pil­ers, and their abil­ity to run in en­vi­ron­ments where com­pil­ing new code is pro­hib­ited (like on iOS or most video game con­soles).

In prac­tice, you in­ter­act with pro­gram­ming lan­guages via com­puter pro­grams or soft­ware li­braries into which you feed code in or­der to pro­duce an ef­fect. They come in two broad man­i­fes­ta­tions: as com­pil­ers and as in­ter­preters. Each ap­proach has its ad­van­tages and dis­ad­van­tages, and the line be­tween the two can be quite blurry, with frame­works like Mono go­ing so far as to of­fer both si­mul­ta­ne­ously.

The de­ci­sive fac­tor in what makes some­thing a pro­gram­ming lan­guage (or not) is known as Turing com­plete­ness. Alan Turing’s sem­i­nal work in the 1940s in­cluded the de­f­i­n­i­tion of the Turing ma­chine, a math­e­mat­i­cal de­scrip­tion of an ab­stract com­puter that be­came foun­da­tional for our un­der­stand­ing of how al­go­rithms work. A Turing ma­chine can, prov­ably, im­ple­ment any com­putable al­go­rithm, and any sys­tem that can sim­u­late the Turing ma­chine can do so as well. Such a sys­tem is deemed Turing com­plete, and most pro­gram­ming lan­guages have this sta­tus as a ba­sic goal (though there are some in­ter­est­ing lan­guages that do not). A deep dive into com­putabil­ity the­ory is be­yond the scope of this ar­ti­cle, but suf­fice it to say that a lan­guage with some no­tion of state (often vari­ables or ar­gu­ment pass­ing) and con­di­tion­als is most likely Turing com­plete. This leaves out markup lan­guages like HTML and con­fig­u­ra­tion lan­guages like YAML or JSON, but in­cludes a hi­lar­i­ous col­lec­tion of sys­tems that are ac­ci­den­tally Turing com­plete (including an abuse of HTML and CSS).

So, what is a pro­gram­ming lan­guage? This might seem like an odd ques­tion to ask about tools this ubiq­ui­tous, but start­ing from a de­f­i­n­i­tion is of­ten help­ful to fo­cus the con­ver­sa­tion. A pro­gram­ming lan­guage is a for­mal lan­guage used to com­mu­ni­cate in­struc­tions to a com­puter. It is for­mal in that it con­forms to a rigid set of rules that de­ter­mine what is and is not al­lowed. It is a means of com­mu­ni­ca­tion in that the pri­mary goal of the tool is to trans­late ideas in a pro­gram­mer’s head into a form that a com­puter can act on. The fact that you are com­mu­ni­cat­ing with a com­puter is sig­nif­i­cant. Unlike other forms of lan­guage, or even in­struc­tional arts like mu­si­cal com­po­si­tion or screen­writ­ing, the fi­nal agent ful­fill­ing the in­struc­tions is not hu­man. The re­sult is that qual­i­ties that other forms of com­mu­ni­ca­tion tend to de­pend on—like in­tu­ition, com­mon sense, and con­text—are not avail­able.

Compilers tend to pro­ceed in a lin­ear se­quence of phases, each phase pro­vid­ing the next with its in­put. Even wildly dif­fer­ent lan­guages will broadly have the same struc­ture. Comparing the com­pi­la­tion steps of dif­fer­ent lan­guages is a use­ful way to get a han­dle on the gen­eral process, and to be­gin to grok how a com­piler works.

The first ques­tion a com­piler has to an­swer is, “What did the pro­gram­mer say?” This step in the com­piler pipeline is usu­ally called pars­ing. The user pre­pares source code that is valid in the lan­guage they are pro­gram­ming in. Source code is of­ten text, but it does­n’t have to be—take the vi­sual lan­guages Scratch, Pure Data (Pd), and Max/MSP, for ex­am­ple. Once the pro­gram­mer has pre­pared their source code, the com­pil­er’s first task is to turn it into a data struc­ture that is use­ful to later stages of the com­piler. This is the stage where er­rors spe­cific to the syn­tax are re­ported, like miss­ing semi­colons or un­matched braces. This is done dif­fer­ently from lan­guage to lan­guage, but in two broad cat­e­gories: Lisp read­ing and scan­ning/​pars­ing.

Languages in the Lisp fam­ily are no­to­ri­ous for their sim­ple syn­taxes. The sim­plic­ity is a re­sult of de­lib­er­ate de­sign, but also a side-ef­fect of a prop­erty that Lisp pro­gram­mers take very se­ri­ously: Lisp source code is a lit­eral rep­re­sen­ta­tion of Lisp data. Put an­other way, Lisp source code is ho­moiconic with Lisp data. To that end, the first step in a Lisp com­piler is to turn source code text into data struc­tures that the lan­guage un­der­stands. Historically this has in­cluded lists, num­bers, and sym­bols, known col­lec­tively as “symbolic ex­pres­sions” or “s-expressions,” but mod­ern Lisps like Clojure in­clude hashmaps, vec­tors, and sets in their syn­tax. Lisps tra­di­tion­ally call this step “reading” in­stead of pars­ing (which is where the R in REPL comes from, a Lisp idea). Lisp read­ers are sim­ple enough that they tend to be writ­ten by hand. Clojure’s reader is hand­writ­ten in Java and con­tains a com­bi­na­tion of reg­u­lar ex­pres­sions and string op­er­a­tions to con­vert text into data struc­tures, even match­ing against string lit­er­als when it needs to.

Languages with more com­plex syn­tax re­quire more work. The ma­jor­ity of main­stream lan­guages re­quire a two-step process: scan­ning fol­lowed by pars­ing. A scan­ner (also known as a lex­i­cal an­a­lyzer) reads source text and pro­duces a lin­ear stream of to­kens; the parser reads the stream of to­kens and rec­og­nizes pat­terns to trans­form into nodes in an ab­stract syn­tax tree that the next step of the pipeline will deal with. The com­plex­ity of this step de­pends on the com­plex­ity of the syn­tax of the lan­guage. Some lan­guages will use hand­writ­ten scan­ners and parsers, while oth­ers will de­pend on parser gen­er­a­tors like Lex/Yacc or Flex/Bison, which take as in­put a spec­i­fi­ca­tion of the de­sired gram­mar of the lan­guage, and pro­duce as out­put a scan­ner and parser for that lan­guage.

TypeScript’s scan­ner is hand­writ­ten and fea­tures rec­og­niz­able con­structs like map­ping from key­words to to­ken types and a large state­ment switch­ing on char­ac­ter codes to de­ter­mine what to scan next. The to­kens al­low the parser to rea­son with higher-level con­structs like SyntaxKind.​AsteriskToken and SyntaxKind.​OpenBraceToken as in the parse​Im­port​De­c­la­ra­tion​Or​Im­port​Equals​De­c­la­ra­tion func­tion. CoffeeScript re­lies on Jison, a JavaScript port of Bison, for its pars­ing. We can see the lan­guage de­scribed as a gram­mar with de­clar­a­tive rules, like the rules for if ex­pres­sions. Ruby’s Yacc gram­mar is a fa­vorite of mine: In or­der to im­ple­ment Ruby’s fa­mously ap­peal­ing syn­tax, the gram­mar comes out to a colos­sal 11,400+ lines of Yacc code!

Once pars­ing is com­plete, the com­piler must an­a­lyze the parsed code into an ab­stract syn­tax tree, or AST. Analysis an­swers the ques­tion, “What did the user mean?” Languages in the Lisp fam­ily will usu­ally take an ad­di­tional step to go from the s-ex­pres­sions the reader pro­duced to an ini­tial AST, while the parsers of lan­guages out­side the Lisp fam­ily will usu­ally pro­duce an AST di­rectly. This is where the se­man­tic fea­tures of the lan­guage are im­ple­mented, like name res­o­lu­tion, con­trol flow, and func­tion in­vo­ca­tion. Additionally, analy­sis is a phase where op­ti­miza­tions can be­gin to hap­pen, by trans­form­ing the AST into se­man­ti­cally equiv­a­lent ASTs that per­form bet­ter. This is likely the most var­ied phase be­tween com­pil­ers, and each lan­guage will be rad­i­cally dif­fer­ent here. There aren’t re­ally any li­braries or APIs to lean on here, and it’s up to the lan­guage im­ple­menter to de­rive this mean­ing them­selves.

In lan­guages with types, this is where type in­for­ma­tion is in­ferred, flowed, and val­i­dated. Even dy­nam­i­cally typed lan­guages can flow type in­for­ma­tion in or­der to gain per­for­mance. For ex­am­ple, ClojureCLR uses re­flec­tion to de­ter­mine the type of its sta­tic method in­vo­ca­tions and sta­tic field lookups. This in­for­ma­tion is used to gen­er­ate bet­ter byte­code and com­piler er­rors. Languages like TypeScript pro­vide a type sys­tem to a tar­get that is dy­nam­i­cally typed by thor­oughly check­ing types in the analy­sis phase and is­su­ing a warn­ing if types do not line up. Type-safe lan­guages like Haskell will ded­i­cate a large por­tion of their analy­sis phase to type check­ing.

Once an AST is pro­duced and set­tled on, the fi­nal step is to emit the tar­get code. When tar­get­ing ma­chine code, mod­ern lan­guages will most of­ten use the LLVM tool­chain. LLVM is an ex­cit­ing pro­ject be­cause it uni­fies var­i­ous hard­ware plat­forms and op­ti­miza­tions un­der one tar­get. It spec­i­fies its own in­ter­me­di­ate rep­re­sen­ta­tion (LLVM IR) that a com­piler would emit. IR code then goes through the same parse-an­a­lyze-emit pipeline de­scribed in this ar­ti­cle to turn into ma­chine code. The ben­e­fit is that LLVM pre­sents a more straight­for­ward as­sem­bly lan­guage that is still very low level with­out con­cern­ing the lan­guage de­vel­oper with plat­form-spe­cific quirks. Targeting IR means your lan­guage can take ad­van­tage of op­ti­miza­tions writ­ten for C and C++ with no ad­di­tional ef­fort on your part. LLVM ex­poses both a C++ and a C API to gen­er­ate IR. The C API means bind­ings to other lan­guages are pos­si­ble (I’ve suc­cess­fully used them in Node and C#). LLVM can even be found in com­pil­ers for dy­namic lan­guages like Ju­lia.

Virtual ma­chine tar­gets like the CLR and the JVM are sim­i­lar, but each ex­poses a byte­code lan­guage that is at an even higher level than LLVM IR. C#’s stan­dard li­brary pro­vides a very ro­bust name­space specif­i­cally for gen­er­at­ing byte­code that ex­poses an ob­ject-ori­ented in­ter­face to emit as­sem­blies, types, meth­ods, and every other as­pect of byte­code. Java does not have a com­pa­ra­ble name­space in its own stan­dard li­brary, but third-party li­braries like ASM or BCEL can fill this gap. These APIs can be seen in some­what wrapped form in Clojure’s JVM and CLR compilers.

If the tar­get is source code in a high-level lan­guage, emis­sion might ac­tu­ally in­volve con­cate­nat­ing strings to­gether. There of­ten is­n’t an ex­ist­ing API to gen­er­ate source code in a high-level pro­gram­ming lan­guage—the ex­pec­ta­tion is that a hu­man pro­gram­mer will man­u­ally type it all out. This is an is­sue for lan­guages that com­pile to JavaScript, as is ev­i­dent in the ClojureScript and TypeScript com­pil­ers. Some lan­guages, like Carp, treat C as their com­pile tar­get, re­sult­ing in sim­i­lar-look­ing emis­sion phases.

At this point, for­mally speak­ing, you’re done! The com­piler has trans­formed code from the source lan­guage into the tar­get lan­guage and achieved its ba­sic goal. In prac­tice, how­ever, the job of a lan­guage de­signer is just be­gin­ning. Languages are more than their com­pil­ers, and the day-to-day ex­pe­ri­ence of work­ing with a lan­guage ac­tu­ally in­volves myr­iad de­vel­oper tools act­ing in con­cert. Once a lan­guage’s com­piler is work­ing, the ques­tion then be­comes one of ed­i­tor in­te­gra­tion, de­bug­ger sup­port, doc­u­men­ta­tion, a com­mu­nity, and a li­brary ecosys­tem. Most of this takes con­sid­er­able time to de­velop, and this is what gives ex­ist­ing lan­guages in­er­tia over new ones.

Historically, lan­guages had not di­rectly ad­dressed the task of man­ag­ing third-party li­braries, or pack­ages. In the pre-web, pre-open source days, when lan­guages like C++ ar­rived, the is­sue of in­te­grat­ing with a stranger’s code was nowhere near as com­pli­cated as it is now. Even lan­guages that ap­peared in the 1990s tended to not in­clude pack­age man­agers, with Ruby’s RubyGems not land­ing un­til eight years af­ter Ruby it­self. Post-web lan­guages are more likely to in­clude a pack­age man­ager as part of their stan­dard tool­ing, as Elm and Rust do. Most pack­age man­agers are spe­cific to their lan­guages, cus­tom built, and re­quire server in­fra­struc­ture, though generic so­lu­tions like Gx and Nix are avail­able as well. Gx is in­ter­est­ing be­cause it op­er­ates over IPFS, a peer-to-peer pro­to­col that re­quires no cen­tral server co­or­di­na­tion. Nix is the re­sult of Eelco Dolstra’s PhD the­sis, “The Purely Functional Software Deployment Model,” and is pri­mar­ily used in the NixOS op­er­at­ing sys­tem. It’s purely func­tional and, as a re­sult, pro­vides very re­pro­ducible de­ploy­ments.

Integrating with ed­i­tors has also been a pain, tra­di­tion­ally. Programmers ex­pect good syn­tax high­light­ing, com­ple­tion, and other fea­tures all in their fa­vorite ed­i­tor. It was usu­ally up to the com­mu­nity to pro­vide these bind­ings, lead­ing to an un­even de­vel­oper ex­pe­ri­ence across ed­i­tors. Recently, Microsoft has put out what they call the Language Server Protocol to help ad­dress these is­sues and make it eas­ier to in­te­grate new pro­gram­ming lan­guages with text ed­i­tors. It’s es­sen­tially a net­work pro­to­col for a text ed­i­tor. Your lan­guage only needs to im­ple­ment the pro­to­col once, and then every ed­i­tor that sup­ports it (which is most ma­jor ed­i­tors) can com­mu­ni­cate with your lan­guage to get au­to­com­plete and other fea­tures.

If you’re read­ing this, gen­tle­man from the sub­way, I hope it has be­gun to an­swer your ques­tion about why any­one would make up a pro­gram­ming lan­guage. It’s a won­der­ful puz­zle to solve, and more ap­proach­able than it may seem at first. Languages rep­re­sent dif­fer­ent ideas of how to cap­ture hu­man cre­ativ­ity on a ma­chine, and I’ve never been dis­ap­pointed by pulling the cur­tain back on an im­ple­men­ta­tion to see how it ticks. Seeing com­mon pat­terns across dif­fer­ent lan­guages and get­ting a sense of their trade-offs also gives you a new per­spec­tive when pick­ing up new lan­guages, some­thing every work­ing pro­gram­mer will have to do at some point in their ca­reer.

Whether you’re build­ing the next chap­ter in the his­tory of soft­ware en­gi­neer­ing or just peek­ing un­der the hood of a ma­chine that you use every day, the world of pro­gram­ming lan­guages is yours to ex­plore. It will ex­pand your mind and make you a bet­ter pro­gram­mer—and you might not even be the strangest per­son on the train.

As the coro­n­avirus pan­demic spreads across the globe, the term “virus” gets a lot of air­play. But what ex­actly are viruses, and how do they spread? Here’s a primer, with a hat tip to Stanford vi­rol­o­gist Jan Carette, PhD.

For starters, viruses are eas­ily the most abun­dant life form on Earth, if you ac­cept the propo­si­tion that they’re alive. Try mul­ti­ply­ing a bil­lion by a bil­lion, then mul­ti­ply that by ten tril­lion, and that (10 to the 31st power) is the mind-numb­ing es­ti­mate of how many in­di­vid­ual vi­ral par­ti­cles are es­ti­mated to pop­u­late the planet.

Is a virus a liv­ing thing? Maybe. Sometimes. It de­pends on lo­ca­tion. “Outside of a cell, a vi­ral par­ti­cle is in­ert,” Carette told me. On its own, it can’t re­pro­duce it­self or, for that mat­ter, pro­duce any­thing at all. It’s the ul­ti­mate par­a­site.

Or, you could say more char­i­ta­bly, very ef­fi­cient. Viruses travel light, pack­ing only the bag­gage they ab­solutely need to hack into a cell, com­man­deer its mol­e­c­u­lar ma­chin­ery, mul­ti­ply and make an es­cape.

When it comes to viruses, there are ex­cep­tions to nearly every rule. But they do have things in com­mon, said Carette.

A virus’s travel kit al­ways in­cludes its genome and a sur­round­ing pro­tein shell, or cap­sid, which keeps the vi­ral genome safe, helps the virus latch onto cells and climb in­side and, on oc­ca­sion, abets its off­spring’s get­away. The cap­sid con­sists of iden­ti­cal pro­tein sub­units, whose unique shapes and prop­er­ties de­ter­mine the cap­sid’s struc­ture and func­tion.

Some viruses also wear greasy over­coats, called en­velopes, made from stolen shards of the mem­branes of the last cell they in­fected. Influenza and he­pati­tis C viruses have en­velopes, as do coro­n­aviruses, her­pesviruses and HIV. Rhinoviruses, which are re­spon­si­ble for most com­mon colds, and po­lioviruses don’t. Here’s a prac­ti­cal take­away: Enveloped viruses par­tic­u­larly de­spise soap be­cause it dis­rupts greasy mem­branes. Soap and wa­ter are to these viruses what ex­hal­ing gar­lic is to a vam­pire, which is why wash­ing your hands works won­ders.

How do viruses en­ter cells, repli­cate and head for the ex­its?

For a virus to spread, it must first find a way into a cell. But, said Carette, “penetrating a cel­l’s perime­ter is­n’t easy.” Cells’ outer mem­branes are nor­mally tough to pen­e­trate with­out some kind of spe­cial pass. But viruses have ways of trick­ing cells into let­ting them in. Typically, a por­tion of the vi­ral cap­sid will have a strong affin­ity to bind with one or an­other pro­tein dot­ting the sur­faces of one or an­other par­tic­u­lar cell type. The bind­ing of the vi­ral cap­sid with that cell-sur­face pro­tein serves as an ad­mis­sion ticket, eas­ing the virus’s in­va­sion of the cell.

The vi­ral genome, like ours, is an in­struc­tion kit for the pro­duc­tion of pro­teins the virus needs. This genome can be made up of ei­ther DNA, as is the case with vir­tu­ally all other crea­tures, or its close chem­i­cal rel­a­tive RNA, which en­codes ge­netic in­for­ma­tion just as DNA does but is much more flex­i­ble and some­what less sta­ble. Most mam­mal-in­fect­ing virus­es’ genomes are made of RNA. (Not her­pesviruses, though.)

In ad­di­tion to the gene cod­ing for its cap­sid pro­tein, every virus needs an­other gene for its own ver­sion of an en­zyme known as a poly­merase. Inside the cell, vi­ral poly­merases gen­er­ate nu­mer­ous copies of the in­vader’s genes, from whose in­struc­tions the cel­l’s obe­di­ent mol­e­c­u­lar as­sem­bly line pro­duces cap­sid sub­units and other vi­ral pro­teins.

Capsids — a virus’s pro­tein shell — self-as­sem­ble from their sub­units, of­ten with help from pro­teins orig­i­nally made by the cell for other pur­poses, but co-opted by the virus. These fresh copies of the vi­ral genome are pack­aged in­side newly-made cap­sids for ex­port.

Viral genomes can also con­tain genes for pro­teins that can co-opt the cel­lu­lar ma­chin­ery to help viruses repli­cate and es­cape, or that can tweak the virus’s own genome — or ours. The genome can con­tain as few as two genes — one for the pro­tein from which the cap­sid is built, the other for the poly­merase — or as many as hun­dreds (as in her­pesviruses, for ex­am­ple).

Often, the virus’s plen­ti­ful prog­eny pun­ish the good deed of the cell that pro­duced them by lysing it — punch­ing holes in its outer mem­brane, bust­ing out of it and de­stroy­ing the cell in the process. But en­veloped viruses can es­cape by an al­ter­na­tive process called bud­ding, whereby they wrap them­selves in a piece of mem­brane from the in­fected cell and, in these newly ac­quired greasy over­coats, dif­fuse through the cel­l’s outer mem­brane with­out struc­turally dam­ag­ing it. Even then, the cell, hav­ing birthed myr­iad baby viruses, is of­ten left fa­tally weak­ened.

Up next: To learn more about how viruses in­clud­ing coro­n­aviruses do what they do to us — and about what we might be able to do to ward them off — see “What’s a virus, any­way? Part 2: The bad, the good and the re­mark­able.”

Graphic il­lus­tra­tion of a measles virus from the Centers for Disease Control and Prevention

PostgreSQL is the worlds’ best data­base

How to Protect Your PostgreSQL Databases from Cyberattacks with SQL Firewall

How to Protect Your PostgreSQL Databases from Cyberattacks with SQL Firewal…

Webinar: State of Full Text Search in PostgreSQL 12 [Follow Up]

Leaked notes from an in­ter­nal meet­ing of Amazon lead­er­ship ob­tained by VICE News re­veal com­pany ex­ec­u­tives dis­cussed a plan to smear fired ware­house em­ployee Christian Smalls, call­ing him “not smart or ar­tic­u­late” as part of a PR strat­egy to make him “the face of the en­tire union/​or­ga­niz­ing move­ment.”

“He’s not smart, or ar­tic­u­late, and to the ex­tent the press wants to fo­cus on us ver­sus him, we will be in a much stronger PR po­si­tion than sim­ply ex­plain­ing for the umpteenth time how we’re try­ing to pro­tect work­ers,” wrote Amazon General Counsel David Zapolsky in notes from the meet­ing for­warded widely in the com­pany.

The dis­cus­sion took place at a daily meet­ing, which in­cluded CEO Jeff Bezos, to up­date each other on the coro­n­avirus sit­u­a­tion. Amazon SVP of Global Corporate Affairs Jay Carney de­scribed the pur­pose to CNN on Sunday: “We go over the up­date on what’s hap­pen­ing around the world with our em­ploy­ees and with our cus­tomers and our busi­nesses. We also spend a sig­nif­i­cant amount of time just brain­storm­ing about what else we can do” about COVID-19.

Zapolsky’s notes also de­tailed Amazon’s ef­forts to buy mil­lions of pro­tec­tive masks to pro­tect its work­ers from the coro­n­avirus, as well as an ef­fort to be­gin pro­duc­ing and sell­ing its own masks. So far, the com­pany has se­cured at least 10 mil­lion masks for “our op­er­a­tions guys,” with 25 mil­lion more com­ing from a sup­plier in the next two weeks, Zapolsky wrote.

Amazon fired the ware­house worker Smalls on Monday, af­ter he led a walk­out of a num­ber of em­ploy­ees at a Staten Island dis­tri­b­u­tion ware­house. Amazon says he was fired for vi­o­lat­ing a com­pany-im­posed 14-day quar­an­tine af­ter he came into con­tact with an em­ployee who tested pos­i­tive for the coro­n­avirus.

Smalls says the em­ployee who tested pos­i­tive came into con­tact with many other work­ers for longer pe­ri­ods of time be­fore her test came back. He claims he was sin­gled out af­ter plead­ing with man­age­ment to san­i­tize the ware­house and be more trans­par­ent about the num­ber of work­ers who were sick.

Zapolsky’s notes from the meet­ing de­tail Amazon’s plan to deal with a wave of bad press and calls for in­ves­ti­ga­tions from elected of­fi­cials fol­low­ing the fir­ing of Smalls. They also show top Amazon brass wanted to make Smalls the fo­cus of its nar­ra­tive when ques­tioned about worker safety.

“We should spend the first part of our re­sponse strongly lay­ing out the case for why the or­ga­niz­er’s con­duct was im­moral, un­ac­cept­able, and ar­guably il­le­gal, in de­tail, and only then fol­low with our usual talk­ing points about worker safety,” Zapolsky wrote. “Make him the most in­ter­est­ing part of the story, and if pos­si­ble make him the face of the en­tire union/​or­ga­niz­ing move­ment.”

They dis­cussed en­cour­ag­ing Amazon ex­ec­u­tives to use Smalls to dis­credit the wider la­bor move­ment at Amazon. Employees at the ware­house, known as JFK8, launched an ef­fort to union­ize in 2018.

In his notes, Zapolsky wrote that there was “general agree­ment” on this point among the other at­ten­dees of the meet­ing. (Zapolsky’s notes also men­tion SVP of world­wide op­er­a­tions and cus­tomer ser­vice Dave Clark and SVP of hu­man re­sources Beth Galetti.)

In a state­ment to VICE News, Zapolsky said his “comments were per­sonal and emo­tional.”

“I was frus­trated and up­set that an Amazon em­ployee would en­dan­ger the health and safety of other Amazonians by re­peat­edly re­turn­ing to the premises af­ter hav­ing been warned to quar­an­tine him­self af­ter ex­po­sure to virus Covid-19,” he said. “I let my emo­tions draft my words and get the bet­ter of me.”

The notes also ref­er­ence Amazon’s con­cerns about the coro­n­avirus pan­demic’s im­pact on the econ­omy, and its own ef­forts to ramp up test­ing and lab ca­pac­ity both within the com­pany and around the coun­try. They dis­cussed the ben­e­fits of test­ing all em­ploy­ees, even asymp­to­matic ones.

“That can have ben­e­fits both for the sys­tem and for our em­ploy­ees,” Zapolsky wrote. “Every test we do is in­cre­men­tal and is one less test that ex­ist­ing re­sources have to do.”

Amazon also weighed ways to gen­er­ate a PR win from their mask stock­pile with “different and bold” ways of giv­ing away sur­plus masks to hos­pi­tals and in­de­pen­dent gro­cers. “If we can get masks in quan­tity it’s a fan­tas­tic gift if we do­nate strate­gi­cally,” Zapolsky wrote.

“Another idea for giv­ing masks away — give 1,000 masks to every po­lice sta­tion in the coun­try,” Zapolsky wrote, adding this “reminds folks it’s not just med­ical work­ers who need these.”

They dis­cussed al­ter­na­tive ways to ob­tain or pro­duce pro­tec­tive masks, as well as work­ing with other com­pa­nies that have ca­pac­ity to make them.

“There are ways of mak­ing FDA ap­proved sur­gi­cal and other masks from fab­ric and we’re work­ing with those man­u­fac­tur­ers as well,” Zapolsky’s notes said.

The con­sen­sus at the meet­ing was that the CDC would be rec­om­mend­ing every­one wear masks if not for the lack of sup­ply. “CDC’s hes­i­tancy to rec­om­mend masks has been to man­age sup­ply (though that’s a bad rea­son to sac­ri­fice sci­en­tific in­tegrity),” Zapolsky wrote.

Amazon has also be­gun ef­forts to to pro­duce masks it­self. While the com­pany has a “line of sight” on a sup­ply of N95 masks, the notes said, Amazon is “starting to put to­gether in­ter­nal ef­forts” for mask pro­duc­tion, though this is de­scribed as “more of a nine month type pro­ject.”

Zapolsky’s notes im­ply the com­pa­ny’s at­tempts to pur­chase N95 masks from China fell through. “China has deemed N95 masks as ‘strategic,’” Zapolsky wrote. “They’re keep­ing them for op­tion­al­ity. They also want to use them for ‘diplomacy.’ The masks in China that we thought we had prob­a­bly got redi­rected by prof­i­teers.”

Cover: Amazon em­ploy­ees hold a protest and walk­out over con­di­tions at the com­pa­ny’s Staten Island dis­tri­b­u­tion fa­cil­ity on March 30, 2020 in New York City. (Photo: by Spencer Platt/Getty Images)

This book is a cel­e­bra­tion of Leslie Lamport’s work on con­cur­rency, in­ter­wo­ven in four-and-a-half decades of an evolv­ing in­dus­try: from the in­tro­duc­tion of the first per­sonal com­puter to an era when par­al­lel and dis­trib­uted mul­ti­proces­sors are abun­dant. His works lay for­mal foun­da­tions for con­cur­rent com­pu­ta­tions ex­e­cuted by in­ter­con­nected com­put­ers. Some of the al­go­rithms have be­come stan­dard en­gi­neer­ing prac­tice for fault tol­er­ant dis­trib­uted com­put­ing - dis­trib­uted sys­tems that con­tinue to func­tion cor­rectly de­spite fail­ures of in­di­vid­ual com­po­nents. He also de­vel­oped a sub­stan­tial body of work on the for­mal spec­i­fi­ca­tion and ver­i­fi­ca­tion of con­cur­rent sys­tems, and has con­tributed to the de­vel­op­ment of au­to­mated tools ap­ply­ing these meth­ods.

Part I con­sists of tech­ni­cal chap­ters of the book and a bi­og­ra­phy. The tech­ni­cal chap­ters of this book pre­sent a ret­ro­spec­tive on Lamport’s orig­i­nal ideas from ex­perts in the field. Through this lens, it por­trays their long-last­ing im­pact. The chap­ters cover time­less no­tions Lamport in­tro­duced: the Bakery al­go­rithm, atomic shared reg­is­ters and se­quen­tial con­sis­tency; causal­ity and log­i­cal time; Byzantine Agreement; state ma­chine repli­ca­tion and Paxos; tem­po­ral logic of ac­tions (TLA). The pro­fes­sional bi­og­ra­phy tells of Lamport’s ca­reer, pro­vid­ing the con­text in which his work arose and broke new grounds, and dis­cusses LaTeX - per­haps Lamport’s most in­flu­en­tial con­tri­bu­tion out­side the field of con­cur­rency. This chap­ter gives a voice to the peo­ple be­hind the achieve­ments, no­tably Lamport him­self, and ad­di­tion­ally the col­leagues around him, who in­spired, col­lab­o­rated, and helped him drive world­wide im­pact. Part II con­sists of a se­lec­tion of Leslie Lamport’s most in­flu­en­tial pa­pers.

This book touches on a life­time of con­tri­bu­tions by Leslie Lamport to the field of con­cur­rency and on the ex­ten­sive in­flu­ence he had on peo­ple work­ing in the field. It will be of value to his­to­ri­ans of sci­ence, and to re­searchers and stu­dents who work in the area of con­cur­rency and who are in­ter­ested to read about the work of one of the most in­flu­en­tial re­searchers in this field.

The New York City Department of Education is com­mit­ted to mak­ing three free meals avail­able daily for any New Yorker. Any New Yorker who wants one can get three free meals a day at more than 400 Meal Hubs across the city.

* Meals can be picked up at all Meal Hubs 7:30 am to 1:30 pm, Monday through Friday

* Meals Hubs will op­er­ate for chil­dren and fam­i­lies from 7:30 am to 11:30 am, and for adults from 11:30 am to 1:30 pmNo one will be turned away at any timeAll adults and chil­dren can pick up three meals at one timeVeg­e­tar­ian and ha­lal op­tions avail­able at all sites

* No one will be turned away at any time

* All adults and chil­dren can pick up three meals at one time

* Vegetarian and ha­lal op­tions avail­able at all sites

* No din­ing space is avail­able, so meals must be eaten off premises

* Parents and guardians may pick up meals for their chil­dren

Use our Meal Hub lookup tool to find a lo­ca­tion near you!

Imagine you are on a pop­u­lar web­site when all of a sud­den an ad ban­ner hi­jacks your cam­era and mi­cro­phone to spy on you. That is ex­actly what this vul­ner­a­bil­ity would have al­lowed.

This vulnerability allowed ma­li­cious web­sites to mas­quer­ade as trusted web­sites when viewed on Desktop Safari (like on Mac com­put­ers) or Mobile Safari (like on iPhones or iPads).

Hackers could then use their fraud­u­lent iden­tity to in­vade users’ pri­vacy. This worked be­cause Apple lets users per­ma­nently save their se­cu­rity set­tings on a

If the ma­li­cious web­site wanted cam­era ac­cess, all it had to do was mas­quer­ade as a trusted video-con­fer­enc­ing web­site such as Skype or Zoom.