U.S. Election Priced as Worst Event Risk in VIX Futures History - <AUTHOR> https://www.bloomberg.com/news/articles/2020-09-01/u-s-election-priced-as-worst-event-risk-in-vix-futures-history <comment><USER2> The IV of options is almost always too high (by too high I mean option prices are too high compared to mathematical fair value) and selling couple month out Vix futures is probably a great way to make some money right now. Moreover, the IV often fails to take into account upside volatility, effectively reducing the vix to an index that is inversely correlated to market returns.

I doubt the market will fall regardless of who gets elected, so the obvious trade would be to sell Vix futures and profit off of the carry. If you get scared, simply offset your position before the election and net a smallish profit (probably).

That being said, options IV is mostly a function of supply and demand, so it's totally possible that you could get crushed without any realized volatility at all.

<comment><USER3> In broad strokes, this is similar to the strategy implemented by SVXY, an inverse volatility ETF. It is continuously short contracts of the front month and second month of VIX futures, weighted accordingly to give a 30-day effective maturity. The idea is that the VIX term structure is usually in contango (the market expects that volatility in the future will be higher, so you can short the longer-term contracts and buy them back closer to expiration). The fund was structured such that it attempted to give -1.0x the return of a VIX short-term futures index on any given day. That way, as long as the term structure stays in contango and there isn't a bulk increase in volatility across the curve, you will profit.

From early 2016 to early 2018, this strategy was extremely effective, returning over 700% from February 2016 to January 2018. Then "Volmageddon" happened[1] and the fund lost over 90% in one day. Several other similarly- structured inverse volatility funds closed after that day; from what I can tell, SVXY is the only one left, and ProShares later changed the target return factor of the fund to 0.5x to reduce the probability of a similar event in the future.

In more turbulent environments, where volatility is either in backwardation (the front month volatility is higher than later months, often during some kind of market shock), or if the whole volatility term curve just shifts upward (an overall increase in volatility across all expirations), this strategy will lose money. And, as always when trading futures, it can lose lots of money very quickly if you aren't careful.

<comment><USER2> SVXY just sells short term vix futures, so it won't capture this particular effect. There was a mid-term short vol ETN called ZIV, but Credit Suisse recently discontinued it for whatever reason.</comment></comment></comment>


Huawei Sting Offers Rare Glimpse of the U.S. Targeting a Chinese Giant - <AUTHOR> https://www.bloomberg.com/news/features/2019-02-04/huawei-sting-offers-rare-glimpse-of-u-s-targeting-chinese-giant <comment><USER2> As a side-side note, I do understand how journalists may want a career as writers and US articles tend to have pointless details/descriptions, but this is IMHO way too much:

>Khan was casually dressed in a dark peacoat, black button-up shirt, gray pants, and sneakers. Shurboff's attire was more businesslike: a light blue dress shirt, gray sports jacket, black trousers, and brand-new leather shoes.

<comment><USER3> Thank you for saying this -- this kind of fluff filler annoys me too.

It always makes me think me of a kid padding an essay to reach the teacher's limit though I'm pretty sure that's not actually the case.

<comment><USER4> It's trying to add some "human interest" to the story. It annoys those of us who want "just the facts". But for others, it makes the story come alive.

</comment></comment></comment><comment><USER5> I'll be slightly pedantic: the coating is almost certainly diamond-like carbon (DLC), not diamond.

DLC is a complicated class of materials, generally composed of amorphous carbon (no long-range order - kind of like glass) with the same kind of interatomic bonds you see in diamond (sp3 bonds). It's often applied by sputtering or ion beam deposition.

Diamond is sp3-bonded carbon with long-range crystalline order. It's most often made by chemical vapor deposition, which is slow and expensive compared to DLC deposition methods.

The DLC coating described in the article won't do much to reduce glass breakage. But it will greatly increase scratch resistance because it's nearly as hard as diamond.

Diamond doesn't melt unless you're heating it while it's also under enormous pressure to keep it from turning to graphite. It does ablate, or vaporize when hit with laser pulses. This is used to remove small graphite inclusions in diamond.

<comment><USER6> Off topic: over the next couple of years I'm looking to develop a small-scale ion-beam coating system for applying DLC as part of a single-piece-flow process cell. I currently send out my products for DLC coating, and the coater does a good job but they keep making process changes (which affects color) without warning me, so I want to bring it in-house to avoid that and to eliminate the need to batch components for them.

I would release the design as open source after it's completed. Sounds like you have some knowledge in this area so let me know if you'd be interested in collaborating!

</comment></comment><comment><USER7> > The FBI asked them to travel to Las Vegas and conduct a meeting with Huawei > representatives at last month's Consumer Electronics Show. Shurboff was > outfitted with surveillance devices and recorded the conversation while a > Bloomberg Businessweek reporter watched from safe distance.

Is this common practice for criminal investigations?

<comment><USER8> Seems like a pretty typical sting operation, except for the reporter.

<comment><USER9> >Seems like a pretty typical sting operation, except for the reporter.

I think that's the part that parent thought was unusual

<comment><USER7> Indeed, I would have thought it entirely compromises the judicial process too.

</comment></comment></comment></comment><comment><USER10> Super long read only to find out at the end, it might be nothing at all.

<comment><USER11> Yep, this isn't the first story in recent memory from Bloomberg that smells like much ado about NOTHING. What's going on with them?

<comment><USER12> Well Bloomberg reporters get bonuses based on how much the their stories move the market. Huawei is traded on the Shanghai Exchange so the incentives for the reporter are to make the stock tank (or pop, I guess).

<comment><USER13> > Bloomberg reporters get bonuses based on how much the their stories move the > market.

I was surprised to learn this is true!

[https://www.businessinsider.com/bloomberg-reporters- compensa...](https://www.businessinsider.com/bloomberg-reporters- compensation-2013-12)

<comment><USER14> This article speculates but doesn't provide any actual evidence of anything other than the fact that they probably get compensated for reporting on things that impact the market... Which makes sense considering the nature of their publication.

It doesn't provide any proof that they encourage bogus reporting for the purpose of manipulating the market. There's a difference.

</comment></comment></comment></comment></comment><comment><USER15> "They recall the gemologist saying he'd analyzed the diamond glass sample and concluded that Huawei had blasted it with a 100-kilowatt laser, powerful enough to be used as a weapon."

What? how can you determine that from a piece of broke glass?

<comment><USER16> It's a bit of a tangent, but there's an entire field of study called "fractography" which is all about doing things exactly like that.

Further tangent: "a piece of broke glass" can exhibit interesting morphology... "mirror", "mist", and "hackle" are distinctive signatures of different fracture conditions.

<comment><USER17> Fascinating! Did not know about that subject until now. For anyone that studies material engineering even casually, it's an important sub-topic (I never took material engineering in college, that's why I was ignorant about this subject prior to your comment). On a related note, I found this cool related link on Wikipedia [https://en.wikipedia.org/wiki/Category:Fracture_mechanics](https://en.wikipedia.org/wiki/Category:Fracture_mechanics). Anyway, thanks again for the comment!

</comment></comment></comment><comment><USER18> The point of the story is not whether the glass is "unbreakable" or not.

It is about the extent of the Huawei scandal.

</comment><comment><USER19> So after Businessweek's story about Supermicro sending hacked boards to companies, the FBI director Wray deflected questions by saying

>"We have very specific policy that applies to us as law enforcement agencies to neither confirm nor deny the existence of an investigation,"

Why are they now seeming to break that policy by confirming this investigation?

<comment><USER20> Political gain.

Basically, same as when 60 Minutes showed US bombers against protocol a short bit after Russia started waxing ISIS in Syria.

</comment></comment><comment><USER21> Is it really standard practice to demand a sample be returned in original condition in 60 days?

Especially a sample of glass?

Surely the buyer would want to bend it, scratch it, coat it, paint it, etc. to determine if it's suitable for their usecases?

In my experience, it's typical for samples to be provided free (or for a nominal cost), with no strings attached. If there was anything 'secret' in them, they would be protected by copyright, trademarks and patents.

<comment><USER21> It sounds to me like this company didn't have any patentable technology, and was hoping they'd be protected by dubious 'no reverse engineering' contracts... Which they weren't...

</comment></comment><comment><USER22> This descriptions does not sound like it's about something that is "virtually unbreakable" :

"The sample looked like an ordinary piece of glass, 4 inches square and transparent on both sides. It'd been packed like the precious specimen its inventor, Adam Khan, believed it to be—placed on wax paper, nestled in a tray lined with silicon gel, enclosed in a plastic case, surrounded by air bags, sealed in a cardboard box—and then sent for testing to a laboratory in San Diego"

<comment><USER15> Also according to the agreement Huawei was not supposed to "break" it. I am not sure how they are supposed to evaluate it without scratching at it.

<comment><USER23> This one stood out to me too. What benefit it even is to get a sample of protective glass if you are not allowed to test it? "Here. Look at it. Trust us that it's super resistant to scratches".

<comment><USER24> There are plenty of "unbreakable" coatings. It sounds like what makes this unique is that is was suitable as a display cover.

An initial evaluation would be measuring things like how much light energy of what frequencies is able to penetrate the coating. Is the viewing angle acceptable for a consumer device, etc.

Hitting it with a hammer can always come later when they determine that it is a good display glass first.

</comment></comment></comment></comment><comment><USER25> A marketing ruse?

</comment><comment><USER26> beauty is skin deep, Huawei is ugly to bone...

</comment><comment><USER27> I've read so many stories proclaiming Huawei's misdeeds yet nothing solid thus far, with all scenarios hanging on the hypothetical thread. Yet oddly, it is somehow working and skepticism after all is rooting certainty.

</comment><comment><USER28> Sounds like the FBI is just flailing around, and latching onto bottom feeders in the smartphone components industry in an attempt to find dirt on Huawei. This case is a good example: AKHAN had 28 employees and was going on 80 in 2014, but now it only has 5 employees and has zero revenue.

[https://www.chicagobusiness.com/article/20140917/BLOGS11/140...](https://www.chicagobusiness.com/article/20140917/BLOGS11/140919854/akhan- semiconductor-gets-3-5-million-to-stay-in-illinois)

Also, how does a startup without any sales dollars afford the services of Thompson Coburn LLP? And just LOL at Adam's final claim around disclosing the FBI investigation to help with landing a customer: do you think federal agents would have allowed him to break his non-disclosure agreements if this investigation had merit? Whole thing is pretty fishy

<comment><USER29> The Bloomberg reporter watching from a distance part was a bit weird. Also, independent of this alleged wrongdoing, the product itself clearly failed to get traction in the (mobile device) market, for reasons we can only speculate. Sure, they probably can't compete at the same level as juggernauts like Corning, but Gorilla Glass was adopted within a year of announcement back in 2008. Here we are 3 years after 2016, and presumably zero manufacturers are interested in the glass.

</comment></comment><comment><USER30> Is there anything that Huawei does that Western companies don't do, such as trying to steal their competitors secrets?

[https://www.digitaltrends.com/business/google-sues-uber- over...](https://www.digitaltrends.com/business/google-sues-uber-over-self- driving-car-secrets/)

[https://www.bbc.co.uk/news/technology-43010348](https://www.bbc.co.uk/news/technology-43010348)

For any older person this is no news. Didn't we something like this with Hitachi in the 80s?

Of course the authorities try to ban purchases from foreign companies that steal American company's secrets, but they don't apply the same rule to American companies that steal other American companies secrets.

They also don't seem so eager to launch sting operations against American companies who aim to steal other American companies secrets.

<comment><USER31> My instinct is anything our government screams at another country about, security-wise, is simply projecting the fear that everyone else is going to do the exact same thing our government is doing. Huawei might have back doors for the Chinese govt.? Oh, you mean like the FBI, NSA, and CIA have tried to (or maybe successfully) force(d) Apple, Microsoft, Facebook and Google to do?

<comment><USER32> When US intelligence goals directly oppose US business goals then the enemy has already won.

<comment><USER31> The goals of the US intelligence community should be completely independent of US business goals, unless they intersect legitimately because of security concerns, rather than anti-competitive practices.</comment></comment></comment></comment>


Ask HN: What are the best free resources to learn React? - <AUTHOR> I want to learn React from the basics all the way up to the more advanced topics. What are some freely accessible resources to help me achieve this? <comment><USER2> It's unnecessarily confusing and difficult to find a good collection of these resources because there are so many covering varying amounts of information, covering different versions, different libraries, etc.

I'll try to post what I can remember/find below:

[https://github.com/timarney/react-faq](https://github.com/timarney/react-faq)

[https://github.com/enaqx/awesome-react](https://github.com/enaqx/awesome- react)

[https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

[https://thisweekinreact.com/](https://thisweekinreact.com/)

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

React boilerplates meta-search: [http://andrewhfarmer.com/starter- project/](http://andrewhfarmer.com/starter-project/)

Discord server: [https://facebook.github.io/react/blog/2015/10/19/reactiflux-...](https://facebook.github.io/react/blog/2015/10/19/reactiflux- is-moving-to-discord.html)

General JavaScript: [http://javascriptweekly.com/](http://javascriptweekly.com/)

</comment><comment><USER3> Shameless plug:

I couple of weeks ago I paired with one of the junior engineers in the company and we created a React/Redux application from scratch (consuming our API).

I streamed it on LiveCoding.tv and uploaded to YouTube as well.

You can check it out here: [https://medium.com/@kensodev/screencast-1-1-session- building...](https://medium.com/@kensodev/screencast-1-1-session-building-a- react-redux-application-from-scratch-f888c1e74c6#.ghqxgplsc)

</comment><comment><USER4> I actually just purchased this course a couple of hours ago. While it's not free, I certainly think it's worth $20.

[https://www.udemy.com/react-redux/](https://www.udemy.com/react-redux/)

Edit: I also signed up for the free React.js Fundamentals class from [http://courses.reactjsprogram.com/](http://courses.reactjsprogram.com/)

<comment><USER5> I bought the same course (for $10 though) and it definitely worth it. The only problem is the course flow is a bit slow for an experienced developer who already knows ES6. I played the videos on 1.5x the speed and that worked for me.

</comment></comment><comment><USER6> FREE ReactJS: Mastering Best Practices for Beginners and Advanced Developers at [http://reactjs.co/](http://reactjs.co/)

</comment><comment><USER7> ...and there's the rub, isn't it? "free" All kidding aside, if you can afford a few bucks, look at the Wes Bos series.

<comment><USER8> I didn't pay for his React series, but the free Redux series - while useful - I felt wouldn't have been worth paying for. Then again, I already knew React/Flux, so perhaps I wasn't really his target audience.</comment></comment>


Reminder - London Hacker Meetup #7 tomorrow night - <AUTHOR> http://www.facebook.com/event.php?eid=59009875928 Hey guys, for those not already part of the Facebook group, here are the last minute details. Looks like we might break 100 people this month! <comment><USER2> Is it really kosher to post things to Hacker News that you can't read without signing a contract that runs to several thousand words?

</comment><comment><USER3> so hackers use facebook these days do they?

oh how things have changed

<comment><USER4> <http://upcoming.yahoo.com/event/1518202>

</comment></comment><comment><USER4> Will there be any speakers?

<comment><AUTHOR> We've got a some start-ups & hackers doing demos as usual, but no formal speaker for this one. Will be organising speakers for some of the upcoming meetups. How did you find the Erlang one? Anyone you'd particularly like to see speak?

<comment><USER5> I heard a lot of people say, and I agree, that the Erlang one was very interesting, but also too long. I think it was like 1hr 30. 20-30 mins max is best.

<comment><AUTHOR> Yeah I agree, I think any future speakers will aim for 30 mins max. The Erlang guys did an awesome job, my fault for not setting clearer guidelines...

</comment></comment></comment></comment><comment><USER6> ...heh, that's definately not the "London Hacker Meetup" I used to go to, back in the day. :]</comment>


ThinkPads 2020 - X13 AMD - X1 Nano? - fiji-flo https://github.com/alanfox2000/realtek-universal-audio-driver/blob/master/ThirdParty/Dolby/20200211_dolbyapo_realtek/releasenotes_ext_realtek_lenovo_thinkpad.txt <comment><USER2> ThinkPads make better MacBook Pros than Apple-official products - by far and large.

I've got a 2017 MacBook Pro and a 2016 Lenovo ThinkPad and the ThinkPad runs circles around it.

It's also literally a hybrid drawing tablet laptop running MacOS - <AUTHOR> unimaginably useful as a creative - and something Apple doesn't offer, unless you want half-baked iOS software (no Illustrator, no Animate, no Blender) on an iPad Pro.

Even if it wasn't for that awful keyboard (went to the Apple Store, tried the 16" keyboard, still not impressed) - there's a ton of other factors. (Not to mention the ThinkPad keyboard is so tried and true my 2016's keyboard is nearly identical to my 1996 ThinkPad...)

From the awesome amount of ports, tablet/ink support (if your ThinkPad has it), great battery life, native updates (I've not had an issue with .x updates on Mojave or Sierra/High Sierra), and about half the price for the equivalent specs, it's, IMHO, the literal best of both worlds. Even the build quality of ThinkPad laptops is lovely.

I've never had a single issue with MacOS not running as well or significantly better than the equivalent Apple hardware, with the exception of SSD write speeds.

EDIT: Forgot to mention the #1 benefit - replaceable HDD/SSD and upgradable RAM.

I will not, on principle, buy a computer whose hard drive I cannot remove with a basic computing toolkit.

And I will also not, on principle, buy a computer that cannot be internally upgraded.

The environmental impact alone is preposterous.

So what if you make your computers out of aluminum instead of plastic if you _design_ them to have no future?

I think, specifically, of the ludicrously-limited 128GB SSD models of the 2016/2017 MacBook/Pro.

Using that, for basic development - (it was sadly what we were given at the startup I was working at during the time) - was useless, by the time I put Unity and XCode on it, and started making builds, I daily saw the 'your hard disk is almost full' message - and what is there to do about that, except get a whole brand new computer?

<comment><USER3> Do they still only have lackluster displays? Thinkpads maxed out at 1080p long after other premium laptops offered 4k.

<comment><USER4> This. I tried using a Dell XPS and a Thinkpad as replacement to Macbook. But had to return both because I just can't get used to any other display after using Retina display, specially because the laptop is my TV as well.

<comment><USER5> The XPS and Thinkpads have both offered 4k for a few gens now. The real question is when Apple will offer matte screens. I can't stand the glare on the Macbook screens.

<comment><USER3> I don't think the current XPS:es have a matte screen option, last I checked the only ones with matte and known brand names and professional specs where thinkpads with low-res screens.

</comment></comment></comment></comment></comment><comment><USER6> I was feeling pulled back towards non-mac laptops for a variety of reasons, but I think I just came up with a good strategy looking forward. If I were just doing my own dev work, I'd probably have a well-specced thinkpad running some version of linux. But I need to support people using all OSes, so I need a mac. If I need a mac, I'd like that to be my only computer, and just run windows and linux in VMs.

I got a 13" MacBook pro a couple years ago, when I started needing to support mac users more consistently. I was on a budget, so I got an 8GB version. I wanted to upgrade, so last fall I bought the last new 13" I could find online that still had physical function keys, with 16GB ram. I was having trouble running VMs effectively with the 8GB system. I would love to have 32GB ram, but I don't want to go to a 15" or 16" laptop.

I thought I would sell my old 8GB laptop, but I found a really good use for it. I work at home, and I have a multiple-monitor setup that's really nice to do extended development work on. I don't like to disconnect my laptop if I don't have to, but I want to work in other parts of the house sometimes. I realized I could just use the older MacBook as a thin client when I'm not doing memory-intensive work. It's been nice to be able to do more casual work in other parts of the house.

That got me thinking, though - with this setup, there's no reason I need a laptop to power the desktop setup. It's been over a decade since I've owned a desktop computer, but I think I might buy a mac mini next time I upgrade, and keep the 16GB laptop as a thin client around the house, and also have a decent laptop to travel with.

Any thoughts on this approach?

<comment><USER7> The Mac mini is terribly overpriced. If you are going to replace your laptop by a desktop computer, get a descent GPU. That's nice.

<comment><USER8> How so? I have yet to find a cheaper system with that many Thunderbolt 3 ports.

If I didn't need macOS and Thunderbolt 3 then no, the Mac Mini makes no sense at all.

</comment></comment></comment><comment><USER9> I know lots of people here need mac hardware, but it always surprises me just how many fans of macs and macosx are here. For me Thinkpads combined with linux is a great computing experience. I love the unification of package updates and installation and being able to pick from several mature desktop environments to suit your style of working. Thinkpads are pretty tough laptops - they don't have quite the fit and finish of macbooks, but they more than make for this in durability, usability and modularity.

</comment><comment><USER10> Can't wait to see those AMD ThinkPads and I sure hope they also have AMD graphics.

<comment><USER11> The T495s is already AMD and quite good and cheap.

<comment><USER12> I use this. I like it. Upgraded the SSD and added the motherboard max of 32G RAM. If you are using Linux on a laptop, you have a choice between dealing with NVIDIA's proprietary garbage or bad integrated graphics. AMD GPU on a laptop is a godsend.

<comment><USER13> Heh, I was hoping for the same, but in reality I get sleep issues quite often, subpar battery life, and overall unpolished experience... on AMD with Ubuntu.

<comment><USER14> Which AMD cpu was this? And what version of Ubuntu were you running?

<comment><USER13> It's with Ryzen 3500U on Ubuntu 19.10, no fancy configuration.

<comment><USER12> I'm using Fedora, haven't had any sleep problems. If you're using GNOME or KDE, they are notorious for hijacking ACPI handling. Try "# systemctl suspend" to rule out it being Linux's fault.

<comment><USER13> Wouldn't it be fun if you were basically saying "AMD support on Linux is great, unless you are using GNOME or KDE"? :D

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Don't get my hopes up for a return of the X40/X60 form factor

<comment><USER16> I thought I was the only one pining for that!

<comment><USER17> And I thought everyone wanted 4:3 except for the Macbook users...

</comment></comment></comment><comment> fiji-flo Most likely some of the new ThinkPad models for 2020. Hopefully to be announced next week during some MWC replacement event. Let's stay tuned.

</comment><comment><USER18> Got my SO a E485 AMD ThinkPad for Christmas. It's slick! Battery life seems fine, but the big kickers is not having Intel's onboard graphics, which just can't keep up. My SO does casual gaming and the AMD graphics seem to be right in the sweet spot for performance and their needs

</comment><comment><USER19> X13? XTRA line started from X20/T20/A20m/R30. Before that was 3 digit like 600E or iSeries 4 digit like i1420. Doesn't look like there's so much room in that number scheme.

</comment><comment><USER20> I love thinkpads but I wish one came with a decent mobile gaming gpu. I guess that's not at all the audience the thinkpads are for though.

<comment><USER21> I have this on my P52

01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile]

It's enough for most games. However buying a thinkpad for gaming is like buying a Tank to do groceries.

<comment> blaser-waffle +1

I did some decent Linux gaming on my T450 -- moderate settings and framerates -- but ultimately they're work laptops.

<comment><USER22> Anything is possible if you are desperate enough :)

I played (and finished) the first Witcher game on a x201.

</comment></comment></comment></comment><comment><USER23> If this is a 2-in-1 laptop I'm there in a flash.

<comment><USER23> Sadly, the 2-in1 version only has Intel ¯\\_(ツ)_/¯

</comment></comment><comment><USER24> Hopefully they will have some Thinkpads with regular docking station not this ridiculous cable based solution everyone is trying to push now.

<comment><USER25> Why is it "ridiculous" to use a 10Gbps (or 40Gbps if you're spendy) bus to carry data?

'Cause I just sit down, plug _any_ of my laptops (all of which have USB-C in, and everything just works. Windows, Linux, Macs (n.b.: this required a bit of a hack because they don't support MST, but it's not a huge deal)--sit down, go.

Vendor-locked lower-bandwidth docking ports are an antipattern.

<comment><USER24> Because I can lock my laptop to the docking station, because it can also transfer power, and gives me access to many more ports than regular usb based docking station has.. and back in the good ol' days you could have a docking station with such ancient devices like cdrom and floppy - something that I don't need to carry around, but would be nice if I could access while sitting at my desk.

<comment><USER26> USB-C transfers power as well.

Are you really using cds and floppies in the year of our lord 2020, or are you just strawmanning?

<comment><USER27> Burning cds/dvds is still a very convenient and dense affordable form of offline storage for backups and/or content hoarding.

<comment><USER2> Really? With the cost of SD cards what they are? Like, I can get a 128GB SD card for $30.

That would be 170 CD's - nearly 30 DVD's - which will eventually suffer disc rot.

DVD/CD write speeds are very slow, comparatively speaking to even USB 2.0 transfer speeds - and increasing the speed, in my experience, makes exact copies of discs extremely error-prone.

Explain how this is efficient? Genuinely curious, with the price of solid state storage these days.

(I understand even solid state storage has a shelf life, but at least it also can't be so easily harmed as a CD/DVD)

<comment><USER27> SD cards are not intended for long-term archival purposes, not 10+ years. They don't go bad per se, but the data on them may not be readable after slowly discharging offline in cold storage for a decade or more.

[https://en.wikipedia.org/wiki/Data_rot#In_storage](https://en.wikipedia.org/wiki/Data_rot#In_storage)

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Possibly the latest iteration of their portable desktop. [https://www.lenovo.com/us/en/desktops-and-all-in- ones/thinkc...](https://www.lenovo.com/us/en/desktops-and-all-in- ones/thinkcentre/m-series-tiny/ThinkCentre-M90n-1/p/11TC1MNM93N) [https://news.lenovo.com/pressroom/press-releases/lenovo- unve...](https://news.lenovo.com/pressroom/press-releases/lenovo-unveils-new- intelligent-devices-solutions-enterprise/)

</comment><comment><USER29> One of the DIMMs is soldered to the board on the latest T series. I give it a generation or two before RAM is completely un-upgradable.

<comment><USER30> My 450s from 2015 has one soldered, one free slot. So the trend actually is to keep them that way.

</comment></comment><comment><USER31> Also, maybe small ryzen can be used to retrofit older thinkpads :)</comment>


Charles Stross: Where we went wrong - <AUTHOR> http://www.antipope.org/charlie/blog-static/2010/08/where-we-went-wrong.html

<comment><USER2> The only point in here that's defensible is (5), and that's because it's so vague that it doesn't mean much.

(1) Split I and D memory aren't a silver bullet against memory corruption flaws; "Harvard" architecture machines have had remote code execution flaws. Attackers aren't writing directly to program text; they're writing to data structures that effect command & control (most famously the stack) inside the process. Over the past 10 years, _randomization_ has been more effective than any explicit control over what can or can't be executed.

(2) Most modern memory corruption flaws don't involve someone's strcpy(). It's far more common to find math problems in the handling of counted data structures --- you know, like the ones Charlie Stross praises. Meanwhile, if you want "safe" string handling, you use a string library.

(3) We have pervasive TCP/IP encryption today. It does nothing to address computer integrity. Encryption only keeps attackers from talking to you if you can authenticate and authorize every connection. You talk to thousands of sites daily; authorizing them is untenable. Meanwhile, this business of "listeners promiscuously logging traffic and cracking it at leisure" (side note: nobody logs "promiscuously" anymore): it takes an awful lot of leisure to crack AES128, or even DES-EDE.

(4) "The world wide web" has problems, but it's unclear that Stross can actually point them out. Turning Javascript on is unlikely to make you "some script kid's bitch" (turning _Java_ on is another story). People turn off Javascript to avoid XSS, which makes one site a bitch, but not your whole browser.

(6) _Bloody_ Microsoft took security seriously sooner than any other large vendor, as we're all discovering to our chagrin today. Nobody took software security seriously in 2000 except for software security practitioners. It's as true in 2001 as it was in 1995 that a skilled attacker could have popped any Sun machine, any sufficiently complex web app, any document viewer, any graphics format, or any SSL stack. So why blame Microsoft? They at least got a grip on the problem.

Let me be direct: things would have been just as bad if our CPUs had split I&D memory. They'd have been just as bad if everyone used Pascal strings. They'd have been just as bad if we had pervasive IPSEC from day #1. They might be better if we didn't have the WWW, but then, we wouldn't care how good or bad things were (like we didn't seem to care so much when people were owning up DMS500 switches at the phone company in 1991). Things would have been just as bad --- maybe, believe it or not, worse --- had Solaris been the dominant OS in 2000.

The problem is, nobody really knows how to make correct software. It's a core problem in Software Engineering and it's unsolved. Without correct software, you can't have secure software. Sorry.

<comment><USER3> Re. #1, Harvard architecture also does not solve problems with source code injection attacks, as we see with SQL queries and complex data structures that direct the flow of execution.

Harvard architecture is a pain in the ass anyway. When I designed a Harvard architecture chip (8051 derivative) into a product, I added an external address space mapper to turn it into a von Neumann architecture. The software folks had to write a custom file system/linker/loader and were _thankful_. The alternative was painfully reprogramming the chip with every recompile.

Re. #5, the large system developers I know _love_ them their C# and sing the praises of Microsoft for making C/C++ avoidable. Their 500 kLOC distributed system integration project would be nearly untenable if they had to manually get every container iteration and bounds check exactly right. And Microsoft does not talk about it much, but I get the impression that they have been running heavy code reviews and static analyzers on their C/C++ software. At least there seems to have been a decline in exploitable bounds check errors.

<comment><USER2> Every piece of Microsoft software that has a customer-visible name --- and many that don't --- have been run through a gauntlet of static source code analyzers, have been reviewed by developers trained in secure C/C++ programming, have been "threat modeled" by internal and external teams to find design alternatives that reduce exposure to threats, and have been subjected to multiple external pen tests, often on the dot release.

The result is demonstrably imperfect, which just underscores the point that we don't know how to produce secure software "in the large".

Here's a shorthand: if Daniel J. Bernstein can't get it right, it's absurd to suggest that any software company's going to do any better.

</comment></comment></comment><comment><USER4> Or maybe it's "where we went right". Let's imagine a world where TCP/IP was encrypted. What consequences would this have? 1: it would have spread a lot slower. Effective encryption was VERY expensive 30 years ago. 2: The powers in charge would have been much less likely to let commercial interests and non- research institutions connect.

The most likely possibility in that environment? It may well have caused AOL to win. Remember, network effects are hugely important. Sure, the digerati would have accounts on compuserve or the Well, but they would have also have had an AOL account because everybody was on AOL.

I shudder.

<comment><USER5> Exactly. Von Neumann architecture, null string termination in C and lack of encryption in TCP/IP are all arguably the things we got spectacularly right. All these three are efficiency + simplicity vs features + complexity trade offs. Imagine how much extra energy and latency and points of failure would be introduced into the system if almost every network device was required to encrypt/decrypt every packet. Naughty things like error correction and oh a zillion tricks our everyday game programmer is using would be impossible.

</comment></comment><comment><USER6> Bull. It's not about technology, it's about people.

Back in the 1960's, people had a fear that there was going to be this one big mainframe, attended to by a bunch of priests, that would rule the world. (See "Colossus, The Forbin Project")

Just a decade later, in Don Parker's 1976 book, "Crime By Computer",

[http://www.amazon.com/Crime-Computer-Donn-B- Parker/dp/068415...](http://www.amazon.com/Crime-Computer-Donn-B- Parker/dp/0684155761)

we see that the computer crime landscape is substantially the same as it is today. We see embezzlement, computers being used to create thousands of false insurance policies, data theft through timesharing terminals, physical attacks on computers, and concerns about privacy. The only thing that's missing is phishing... And this is just before microcomputers hit the market.

By early 1980's the "Cyberpunk" genre is established in science fiction and Niel Young sang "Computer Cowboy" on his album trans... We then knew the threat of computers was anarchy, not total government control.

The fact is, evil is in the heart of man. People are going to use whatever technology is available to do what they're going to do. Criminals use cars, air travel, and telephones every day. We can certainly close off certain avenues of technological attack, but as long as there is a motive, people are going find the opportunity to commit crimes.

<comment><USER7> > The fact is, evil is in the heart of man.

Only in the heart of those that commit crimes. And we try to design our society in such a way that we reduce the crime. And the internet is now part of our society, which is very technological in nature.

So we have to design the internet in such a way that we take in to account the reality that some people are not nice.

And that makes it about technology, not about people.

<comment><USER8> > Only in the heart of those that commit crimes.

<http://en.wikipedia.org/wiki/Stanford_prison_experiment>

<http://en.wikipedia.org/wiki/Milgram_experiment>

<comment><USER9> I don't finding anything about Milgram demonstrating evil in man; it demonstrated the willingness to take orders from a perceived authority.

</comment></comment></comment></comment><comment><USER10> _According to one estimate pushed by the FBI in 2006, computer crime costs US businesses $67 billion a year. And identity fraud in the US allegedly hit $52.6Bn in 2004._

 _Even allowing for self-serving reporting (the FBI would obviously find it useful to inflate the threat of crime, if only to justify their budget requests), that's a lot of money being pumped down a rat-hole. Extrapolate it worldwide and the figures are horrendous — probably nearer to $300Bn a year. To put it in perspective, it's like the combined revenue (not profits; gross turnover) of Intel, Microsoft, Apple, and IBM — and probably a few left-overs like HP and Dell — being lost due to deliberate criminal activity._

I call bullshit. These numbers are, imho, just as made up as the RIAA's "losses to piracy" numbers. I don't believe them, not even for one second. The real numbers could be as far as 3 or 4 orders of magnitude smaller

<comment><USER2> The real numbers are no doubt N orders of magnitude smaller, but 3-4 sounds high. Could we lose billions of dollars a year to crime abetted by software insecurity? Yes.

At a first pass, remember that every piece of hardware and software that every company buys to address these problems is part of the cost. Antivirus alone gets us over a billion.

</comment></comment><comment><USER7> C doesn't really have a string type, it just has something called pointer to a character, and another thing called 'array of characters'. The standard library is what implements the string functions, not the C language, and the standard library was not written in such a way that the guts of the implementation were hidden from view so it is nearly impossible to fix after the fact. The few string routines that are now 'overwrite safe' notwithstanding, the 'old' stuff is still in use and plenty of new code is still being produced using these unsafe functions. Nul terminated strings are a convention, not a language implementation detail. So the blame does not really go to the C language but to the library implementation.

Another thing missing is homoglyphs.

<comment><USER11> Your forgetting string literals which are part of the language.

<comment><USER7> Yes, that's true. They are supposed to be stored in 'unmutable' memory though, and will cause a segfault if you try to write to them.

      jam@jam-desktop:~$ cat y.c
      main()

      {
            char * s = "abc";

            *s = 'c';
      }
      jam@jam-desktop:~$ ./y
      Segmentation fault

But you're right that they are a part of the language.

<comment><USER12> Platform-dependent behavior; what crashes on your Linux box doesn't necessarily crash on the embedded system running your flight control software...

<comment><USER2> The immutability of string literals (at least, the property Jacques is demonstrating) isn't platform-dependent.

<comment><USER13> From the standard [6.5.4][String literals]:

"If the program attempts to modify such an array, the behavior is undefined."

Hence there is no requirement to segfault.

<comment><USER2> This is just message board geekery. Nobody could reasonably argue that the requirement is to "segfault"; C runs in many places where there's no such concept. Jacques point was that C string literals are immutable. Stop bickering with him; he's right.

<comment><USER13> I appreciate your confidence, but you are wrong:

OpenSolaris/suncc, Jacques' program:

      $ cat immutable.c
      #include <stdio.h>

      int main()
      {
        char * s = "abc";
        *s = 'c';
        printf("%s\n", s);
        return 0;
      }

      $ cc -o immutable immutable.c
      $ ./immutable
      cbc

EDIT: I can't reply to you, so I have to take this route. I also think that this behavior is not desirable. However, I do not see the passage in the the standard that _forbids_ writable strings. On the contrary, in Annex J writable string literals are explicitly allowed as an extension, and I don't see any indication that the presence of writable strings make an implementation non- conforming.

Perhaps you could point to the passage in the standard that requires string literals to be immutable (your words, not mine) or that requires a compiler to issue a warning if a string literal is modified.

If you still wonder why I'm arguing this: It is not for the sake of nitpicking, but to support kabdib's post.

<comment><USER2> That Sun's CC does something goofy here has nothing to do with the argument. Code written to depend on that weird behavior is unreasonable. Why are you arguing this point? I don't get what you think you're proving here.

There are plenty of platforms that C runs on that are incapable of making anything immutable, including _program text itself_. That doesn't make C strings less immutable. Why isn't your compiler yelling at you for doing that? I think it's broken!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> These all seem pointless next to the inevitable social engineering that led John in accounting to give that Excel spreadsheet of bank info to "Dan" from an "outside auditing firm". PEBKAC!!

</comment><comment><USER15> >And Microsoft, by dropping security support for older OSs, aren't helping the problem.

I disagree with this. The only way to get users off defunct OSes, and onto the newer, fundamentally more secure ones, is to stop supporting the old ones.

<comment><USER2> It's also a total red herring.

Microsoft spends serious dollars shoring up the security of Windows XP, a 10-year-old operating system. What kind of security support do you think OS X 10.0 customers get?

Stross' comment here is probably sparked by news stories about Microsoft dropping support for Win2k and XPSP2. But the solution to the XPSP2 problem is simply to upgrade to XPSP3. I'm not sure, but I think that if you had auto- update on (and you're crazy if you don't), you got that automatically.

If you're deployed permanently on Win2K, nothing Microsoft does is going to make you secure. Win2K lives in places where access to the same Ethernet collision domain is already game-over for an attacker.

It is simply unreasonable to suggest that Microsoft is making people less secure by encouraging them to get off operating systems that were first released to QA in 1998.

 _NB: as always, I have to post the disclaimer that while we've done work for MSFT in the past, our entire company is standardized on Apple hardware and Apple operating systems._

</comment></comment><comment><USER16> >User education, or the lack of it. (Clutches head.) I have seen a computer that is probably safe for most users; it's called an iPad, and it's the digital equivalent of a fascist police state: if you try to do anything dodgy, you'll find that it's either impossible or very difficult.

I'd be interested to see some security studies that compare banking behavior on iOS/Android vs. desktop. I don't access financial data on my phone, but my impression is that the way these devices are designed to be used without much training makes it a lot easier for social engineering to succeed, which is the primary attack vector anyway.

</comment><comment><USER17> C++ hasn't been compiled to C in any production compiler for a rather long time.

<comment><USER18> Properly not, but the fact is that it can, and has been. Therefore it is still possible to do so today, which means that his claim still stand.

<comment><USER2> The point wouldn't make sense even if its premise was accurate. The JVM is also implemented in C. But you don't see a lot of ASCIIZ overflows in Java code. The C++ std::string class doesn't suffer from C's wild-west memory handling on cfront-style compilers.

</comment></comment></comment><comment><USER19> Even the app store isn't immune to attack. Wasn't there a trojan type attack recently where an apparently innocent program had a dual purpose?

I don't have a link to hand I'm afraid...</comment>


Myths of Enterprise Python - <AUTHOR> https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/ <comment><USER2> That's a great overview, will come in useful when debunking this stuff in the future.

One little niggle though, "great concurrency primitives"? I don't know about great. Acceptable for sure, usable, good enough. If you use great then you aren't leaving much room for languages with objectively better concurrency primitives.

If Python has great concurrency primitives, what does Clojure have for example? Super-duper-hyper-great?

</comment><comment><USER3> I've been a python programmer for 10 years now and am a believer in #6.

numpy is not always the answer, and cython is its own hell.

</comment><comment><USER4> > _Our most common success story starts with a Java or C++ project slated to > take a team of 3-5 developers somewhere between 2-6 months, and ends with a > single motivated developer completing the project in 2-6 weeks (or hours, > for that matter)._

A story so common they did not feel the need to share it? Even taking the least ludicrous numbers I'm going to say this is entirely made up.

\- 3 C++ devs, 40 hours a week for 2 months (8wks) = 960 hours

\- 1 Python dev, 40 hours a week for 6 weeks = 240 hours

4x difference in productivity is not a language difference, it's a programmer skill difference.

And just for the sake of seeing the numbers:

\- 5 C++ devs, 40 hours a week for 6 months (24 wks) = 4800 hours

\- 1 Python dev, 40 hours a week for 2 weeks = 80 hours

= 60x productivity

No.

<comment><USER5> You're underestimating the amount of effort put into simplifying and clarifying implementations, APIs, and documentation.

This doesn't imply that preceding implementers are unskilled. Part of this improvement is hindsight, but a not-insignificant part is Python's flexibility.

I can vouch for the apparently unbelievable productivity gains but I'm just not sure how to prove them!

Edit: As for not sharing these gains -- that's part of the point of this post to the official PayPal engineering blog :)

</comment></comment><comment><USER6> Does anyone actually believe any of these "Myths?" #6 and #8 are the only ones that could even be remotely considered half-true.

<comment><USER7> Unfortunately, unequivocally, yes, there is so much misinformation. I definitely would not have spent so much time on citations, otherwise ;)

<comment><USER6> I'm not even a python developer and I know most of these are completely untrue.

<comment><USER8> Well, sure you are not a python developer... most untrue? Which ones? Why?

</comment></comment></comment></comment><comment> vezzy-fnord I must say, this is one of the most dishonest image macros I've seen in a long time: [https://www.paypal-engineering.com/wordpress/wp- content/uplo...](https://www.paypal-engineering.com/wordpress/wp- content/uploads/2014/12/cpp_py_medium.png)

<comment><USER5> Disclaimer: I work with Mahmoud.

Presumably "ASF" doesn't mean anything to you. That's because this isn't an image macro, but rather a slide from an internal presentation that compared PayPal's Python API for a custom serialization format to PayPal's C++ API for the same.

Consequently it's important to keep in mind that advances in C++ aren't uniformly available and expertise in it is hard to acquire. That's why the image appears in a section describing the productivity wins available in Python. The point is that Python allows us to develop something that presents a clearer interface to a powerful and performant implementation, and allows our users to worry less about blowing their feet off.</comment></comment>


Vulnerabilities Induced by Migrating to 64-Bit Platforms [pdf] - <AUTHOR> https://www.tu-braunschweig.de/Medien-DB/sec/pubs/2016-ccs.pdf <comment><USER4> I thought these issues are obvious by now.

Some typical points to consider:

1) Never store a length as an _int_ , _unsigned_ , _long_ , etc. Use _size_t_ (or _ssize_t_ ) instead.

2) Never store a pointer as an _int_ , _unsigned_ , _long_ , etc. Use _uintptr_t_ (or _intptr_t_ ). _ptrdiff_t_ is the type to use for pointer differencing.

3) When comparing or casting to a signed type, watch out for sign extension. For example ( _short_ ) -1 (0xffff) becomes 2^32-1 (0xffffffff) when casted to _uint32_t_. Remember _char_ is usually a signed type.

4) Some legacy library functions return _int_ , which is a signed 32-bit value in Windows and Linux (remember point 3). Watch out for these cases. For example don't use ftell and check s[n]printf return value.

<comment><USER5> It's worth noting that ssize_t is a POSIX type, and is only guaranteed to have the range [-1, SSIZE_MAX] (basically a size type with one error value) [1]. If you need negative sizes, then ptrdiff_t is perhaps better.

[1]: [http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/...](http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html)

<comment><USER4> Thanks for the correction!

> only guaranteed to have the range [-1, SSIZE_MAX]

Oh, that's a weird type. I wonder if any compiler implementation encodes it with -1 bias, so that all bits 0 means "-1".

It could cause a disaster if/when ssize_t is encoded as anything else but standard twos complement signed number...

<comment><USER6> I'd assume it's just an unsigned number with 0xFF... representing -1. So counting would go (assuming 8 bits)

        0xFC SSIZE_MAX - <USER2>
        0xFD SSIZE_MAX - <USER3>
        0xFE SIZE_MAX
        0xFF -1

That makes more sense to me than a bias that the compiler would have to know about.

</comment></comment></comment></comment><comment><USER7> 32-bit is relatively nice because ints, longs, and pointers are all the same size; that was also one of the main motivators in the 16-to-32 transition era, since the relative size of an int and a pointer did not change. The same thing didn't happen with the x86 transition to 64-bit, because it would effectively double the memory usage of every program even if it never needed such widths.

The "bitness" of a platform has always seemed to be a bit of a vague term to me; sometimes it refers to data width, sometimes it refers to address width, and sometimes a combination of both and neither. If we refer to data width, then the 8087 was already "80-bit" (FP) or "64-bit" (integers) and the latest CPUs with AVX512 are "512-bit". If we refer to address width, then the 8086/8088 are "20-bit" machines, the 80286 "24-bit", and P6 "36-bit".

I think a lot of this confusion and the vulnerabilities thus introduced are precisely because the relative sizes of the different types have changed, and exactly how they changed is not consistent across platforms nor clearly known to most programmers.

<comment><USER8> Well we could have just done ILP64, where all three are the same size, and that would have avoided a lot of 32 bit truncation bugs. The memory size argument never really made sense to me; there just aren't that many ints in the average program. I wonder how much of the push towards LP64 (ints are 32 bits, pointers and longs are 64) was to match Java.

I think this is one place where Swift (among other modern languages) has it right. Int is pointer sized and the other integer types are explicitly sized in their name ("Int64" not "long").

<comment><USER9> Why are 64bit pointers needed to match Java? Why not 32bit pointers and a 64bit long? Java APIs very rarely expose pointers anyway (e.g. in NIO).

<comment><USER10> While it doesn't look like it's true anymore ([http://www.oracle.com/technetwork/java/hotspotfaq-138619.htm...](http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_description)), I sure seem to remember the Hotspot JVM having an option for 32 bit pointers for ... code, I think it was. Since few apps would need more than 4 GiB of code. And as you note, as the FAQ notes, this doesn't change much for most programming.

<comment><USER11> I think you mean this: [http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...](http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance- enhancements-7.html#compressedOop)

<comment><USER10> Yeah, that sounds like it, and it's at the right time.

</comment></comment></comment></comment></comment></comment><comment><USER12> I've read that catching stuff like this is a major reason that OpenBSD maintains (e.g.) SPARC64 support. Due to differences in MMU architectures, addressing modes, alignment requirements, etc., this kind of problem will often end up throwing an exception rather than silently doing almost-the- right-thing-usually.

<comment><USER13> Yep, here's a brief overview of that from 2007 [https://youtu.be/NJ9Jml0GBPk?t=1937](https://youtu.be/NJ9Jml0GBPk?t=1937) . SPARC64 is a favorite of this developer because it's some Alice in Wonderland stuff where up is down and left is right compared to other architectures. So it exposes a number of bugs that others don't.

Bugs exposed by moving to different architectures are fascinating. They always originate from assumptions that just happen to work on the architecture they were designed on. But when you go to a different arch they go from being sort of harmlessly incorrect to crash and burn type of incorrect. Or, infinitely worse, a sort of works but not in the way you expect it situation.

</comment></comment><comment><USER14> Actual title: _Twice the Bits, Twice the Trouble_

Better title: _Double the Bits, Double the Trouble_

Might seem stupid, but something like that can play a big role in memorability. I don't think we'd all remember "Smashing the Stack for Fun and Profit" by name if it didn't have such a delicious title.

<comment><USER15> Why do you think that's a better title?

<comment><USER14> "Double [the] trouble" is a somewhat common idiomatic phrase. It rhymes "double" with "trouble", and the word "double" has a pleasant ring to it in its own right.

<comment><USER16> Yes, it has a nice woody quality, "twice" is too _tinny._</comment></comment></comment></comment>


What would you do if you realize the market you target is smaller than expected? - <AUTHOR>

<comment><USER2> Whats your startup?

</comment><comment><AUTHOR> I messed up. I thought the audience my startup was targeting is huge. Turns out, it's really small.

If you realize this 8 months after launch, what would you do?

<comment><USER3> Perhaps you could grow it? How do you define "target audience"?

</comment></comment><comment><AUTHOR> never mind what's my startup. what would you do? would you continue or would you do a kiko?

<comment><USER4> If it can be targeted to another market group, do so. If you make, say, tensor analysis software, then your capacity to go after another group is dubious. In this case, it may make sense to go upstream. That is, find out what your customers would use the tensor analysis software for, and offer that service or make that product for your customer's customers.

And now for the best option of all, FAIL!

You and your startup team were mistaken about something as fundamental as the size of the market you were targeting. Please ponder that fact seriously. Why were you mistaken? Emotional attachment to an idea? "Irrational Exuberance"? Is there reason to believe that decisions taken from this point on will be based upon more factual foundations? Sober answers to all of these questions sound good in interviews for new jobs. Sober answers to these questions sound like music to the ears of Venture Capitalists or Angels when one is starting up a new venture.

Fail fast and learn.

Then demonstrate that you did so.

<comment><AUTHOR> This realization comes from insights of our startup and our competitors. Collectively, it is pittance.</comment></comment></comment>


Ask HN: Alternatives to skype? - <AUTHOR>

I am increasingly getting frustrated with skype for multiple reasons. The major one is sound quality for audio chats which is getting increasingly bad for me. The other is the constant outages and crashes of the skype client.<p>Are there any decent alternatives to skype which can work on Windows for a small team which is located in different countries? <comment><USER2> Gtalk.

</comment><comment><USER3> mumble?</comment>


Fukushima — where are the Parrots? - <AUTHOR> http://metamodern.com/2011/03/24/fukushima-%e2%80%94-where-are-the-parrots/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Metamodern+%28Metamodern%29 <comment><USER2> This seems like the kind of armchair quarterbacking that would be proffered by someone experiencing the world exclusively through a Boing Boing RSS feed. We might as well ask, "Fukushima -- where are the 3D printers?"

On the other hand, this post is exactly what I envisioned when patio11's NYT essay called for Americans' "expertise in bringing the situation at the nuclear facilities under control" in place of donations.

<comment><USER3> I was more thinking along the lines that the GE engineers who designed the plant, etc, would help out. Incredibly, in the first few days after the quake the military was on top of things but there were rumblings at the NRC of "Let's distance ourselves from this. If something goes wrong, we don't want blowback." That got mostly fixed a wee bit before it went to press. (Newspapers: yesterday's news, today!)

</comment></comment><comment><USER4> I don't know about Japan, but in the US it would take a pickup truck full of paper and 6 months of review committees before an official agency could actually locate a GSA approved vendor and buy a Parrot drone. Parrot might not even employ enough minorities to be allowed to sell directly to the US government.

Yeah, sarcasm. The point is that a G-man can't just run down to Toys-R-Us, grab one and send it on in. Even the very logically minded would at least want to stop and have a think if there's a possibility then sending in a little toy might do more harm than good if something goes wrong. I personally have no clue what large amounts of ionizing radiation does to wifi.

<comment><USER5> Considering how quickly the US military was able to deploy and utilize their flying intelligence drones in the area this week, I expect that extraordinary circumstances cut the amount of required paperwork extraordinarily.

Also, these AR Drones aren't up to the task.

<comment><USER4> That'd be this one:

[http://en.wikipedia.org/wiki/Northrop_Grumman_RQ-4_Global_Ha...](http://en.wikipedia.org/wiki/Northrop_Grumman_RQ-4_Global_Hawk)

It took a decade to develop and has been in use by the military since 2006. Its easy for the government to use what its already got, its very hard for them to start using something brand new, no matter how good it is.

But you couldn't be more right about the AR drone. I can't even get it to work in the back yard from the front. I think the point was, with all of the cool robotics floating around today, why isn't there a lot more of it at the reactor site helping out?

As for the government shortcutting paperwork in extraordinary circumstances, I think our performance after Hurricane Katrina probably best illustrates how we do with this:

 _"Hundreds of firefighters, who responded to a nationwide call for help in the disaster, were held by the federal agency in Atlanta for days of training on community relations and sexual harassment before being sent on to the devastated area. The delay, some volunteers complained, meant lives were being lost in New Orleans. "_ [http://www.nytimes.com/2005/09/11/national/nationalspecial/1...](http://www.nytimes.com/2005/09/11/national/nationalspecial/11response.html?_r=1&ei=5065&en=2ace4a93793885c3&ex=1127016000&partner=MYWAY&pagewanted=print)

</comment></comment></comment><comment><USER6> "(As you may know, Japan has displayed a special sort of organizational paralysis in this crisis, but wouldn't it be surprising if "toys" like these were used in an incident managed by Very Serious People anywhere in the world?)"

I'm pretty sick of these sorts of comments. I absolutely do NOT know that the Japanese authorities have failed to meet expectations as far as their responsiveness to this disaster. I know it strokes the pleasure center of some people to regurgitate wherever possible stereotypes of hiveminded, hidebounded, unimaginative Japanese, but let's at least wait until some actual evidence emerges of their failure to take initiatve in dealing with 1) the worst earthquake / tsunami they have experienced in modern history 2) the second most catastrophic nuclear disaster ever, in the span of two weeks.

</comment><comment><USER7> Ionizing radiation - messes with the electronics and makes things that aren't specifically built for that kind of environment break in unexpected ways.

<comment><USER8> "iPhone controlled, resistant to multiply-lethal radiation doses (as best I can tell)"

Would be a critical question, anyway.

</comment></comment><comment><USER9> Uh... Parrot drone range... 50 meters??? Does that answer the question?

The robot that they're using? 1 kilometer range. Radiation and environment sensors, stereoscopic cameras, sample collection arm... all radiation hardened...

[http://inhabitat.com/japan-sends-monirobo-robot-into- nuclear...](http://inhabitat.com/japan-sends-monirobo-robot-into-nuclear- plant-to-keep-workers-out-of-danger/)

The reason they aren't using toys is cause its a toy.

<comment><USER10> Even if you had a continuous wifi connection, they only fly for about 10 minutes before the batteries run out.

</comment></comment><comment><USER11> Thank you! I've been wondering that myself. Two possibilities occur to me: (a) would one of those ignite a pocket of hydrogen? (b) what are the risks of a lost one (one winding up ditched in the equipment)?

</comment><comment><USER12> I bet it's highly susceptible to non-lethal radiation such as short microwave bursts. I'd bet you I could take one of those things out with the parts in my microwave and a small capacitor.

Also, since we're dealing with nuclear technology there is going to be lots of EM shielding, wifi tends not to work so well with shielding in place. Especially large amounts of water.

</comment><comment><USER13> Lots of denigrating comments, but its not a bad idea for use in search and rescue.

A big problem rescuers were having was simply being blocked by so much debris. Nearly impossible on foot to navigate some rubble. Also, its slow. Imagine a team of rescuers who had a set of Parrot-like drones they could carry and launch from their backs. They would be able to immediately survey areas in their immediate surroundings that might be very difficult or dangerous to get to on foot. If something is seen via drone that looks like it might hold survivors, then they can start concentrating on that. This could have been done immediately after the earthquake and tsunami with the commercial Parrots available on the market. With drones specially designed for search and rescue, imagine longer flying times, better durability, better nav and recognition software, etc. But that wouldn't have prevented today's drones from being immediately useful, had they been available and trained for.

I do take issue with the author's comment: "Japan has displayed a special sort of organizational paralysis in this crisis". I wish he would clarify this. I've been watching NHK every night, reading a lot, reading what patio11 has said, and talking to friends in Tokyo. Their response to this collective set of disasters has been organized. There are over 200k people in shelters, being taken care of. Meanwhile here in the U.S. we couldn't mobilize for days to help people in one city, New Orleans. In Japan, everyone seems to have done what they train for since birth. The loss of 10,000+ people is horrendous, but it would be much, much worse if Japan wasn't as prepared as it is.</comment>


Using Makefile(s) for Go - <AUTHOR> https://danishpraka.sh/2019/12/07/using-makefiles-for-go.html <comment><USER3> I use Makefiles for Go projects all the time, but not in the way the article describes. First off, in a pre `go mod` world, if you had dependencies to check before running the build, then a Makefile was the easiest way to manage that. But even in a post `go mod` world, there are good reasons to use one that the article totally overlooks:

* Makefiles introduce a topological sort to build steps. This is the reason you use it instead of build shell scripts: it allows build steps to run in parallel, it guarantees order by dependency which is the best way to read build steps, and it makes file freshness an easy element to check for a build step, which is still needed for Go projects with multiple subpackages.

* Go projects usually have more than go files that are required in making an executable. If you run a web server and you are bundling static pages into your executable, Makefiles are the best way to handle that.

* If you are building for multiple architectures, or want to encode the git tag/branch into the executable, it is better to have that Makefile bake in the necessary options on the build step and keep it uniform across the build.

* If you write a Go file and bake that into a Docker image, I find it best to drop the image and container hashes into files so that I can get to them easily for docker exec/attach/rm/rmi commmands.

But there is one bigger reason Makefiles work for our entire team. We standardize on using Makefiles as the entrypoint for our builds. We have a polyglot environment at work so sometimes it gets confusing to figure out how to build a project. By standardizing on running 'make' we are all on the same page. Have a Javascript project to webpack? Run make and have make call yarn. Have a python wheel to construct? Run make and have make call python setup.py. You have a Java project that requires a sequence of maven commands to build? Run make and have the makefile call maven.

Is that inefficient? You bet it is. Does it make it easier to sort out what to do to build a project for the first time? Yes it does. Does it make it 100% easier for our CI/CD framework to work with multiple languages and scan for the necessary compilers and dependencies? Heck yeah.

[edited for lousy formatting]

<comment><USER4> Also - Make will exist pretty much in _any_ Unix-based environment. Any alternatives will require prerequisite installation of things.

Although, I work in a team where a lot of devs are on Windows, and they complain about it.

<comment><USER5> What do Windows devs prefer instead of Make?

<comment><USER6> From my experience, clicking the "build" button (or using the equivalent keyboard shortcut) in Visual Studio.

</comment></comment></comment></comment><comment><USER7> I've seen a lot of developers, especially developers with C backgrounds, reach for Makefiles when approaching Go development, and I think it's a harmful practice. So, I'd like to offer a respectful but firm rebuttal to this article. :)

I dislike using make(1) with Go for two reasons.

The first is that make was developed for building C projects, and therefore is oriented around that task. Building C projects is a lot different than building Go projects, and it involves stitching together a lot of pieces, with plenty of intermediate results.

make(1) has first class support for intermediate results, which are expressed as targets.

If you look at the article, the author has to use a workaround just to avoid this core feature of make(1).

The second reason I dislike using make(1) for Go projects is that it harms portability.

A Go project should only require the Go compiler to build successfully. Go projects that need make(1) to build will not work out of the box for Windows users, even though Go is fully supported on Windows. For me, this puts Makefiles into the "nonstarter" category, even though I do all of my own development work on Linux. There is just no reason to complicate things for people who don't have make(1) installed.

For code generation and other ancillary tasks, Go includes the 'go generate' facility. This feature was created specifically to free developers from depending on external build tools. ([https://blog.golang.org/generate](https://blog.golang.org/generate))

For producing several binaries for one project, use several different main packages in directories that are named what you want your binary to be.

Edit: corrected some terminology.

<comment><USER8> Why do people on this website use "make(1)" instead of "make" in writing? And I know it's in the man pages but what is this number even for?

<comment><USER9> The number is the "section" of the manual:

[https://www.kernel.org/doc/man-pages/](https://www.kernel.org/doc/man-pages/)

My guess is make(1) is to distinguish from make(1p) - [http://man7.org/linux/man-pages/man1/make.1p.html](http://man7.org/linux/man- pages/man1/make.1p.html)

<comment><USER10> > My guess is make(1) is to distinguish from make(1p) - > [http://man7.org/linux/man- > pages/man1/make.1p.html](http://man7.org/linux/man-pages/man1/make.1p.html)

Or just reflexively included just in case, because of commonly encountering potentially ambiguous situations that you just disambiguate by default, even for non-ambiguous situations.

</comment></comment></comment></comment><comment><USER11> This... isn't even using the `make` part of Makefiles at all.

If you look at the final example, every [1] rule is marked as `.PHONY`. `make` bundles 2 capabilities: a dependency graph and an out-of-date check to rebuild files. This demonstration uses neither.

The author would be better served with a shell script and a `case` block. The advantages:

\- Functions! The `check-environment` rule is really a function call in disguise.

\- No 2 phase execution. The author talks about using variables like `APP`, but those are make variables with very different semantics than shell variables (which are also available inside the recipes).

[1] Yes, there's a `check-environment` "rule" that isn't marked, but it likely should be since it isn't building a file target named `check-environment`.

<comment><USER12> I disagree. Make is more than a build system, it's also an automation tool. It gives you a fairly flexible format for managing different tasks with shared variables and autocompletion and more.

You can do it with a bunch of shell scripts too but I prefer having everything in a single file.

<comment><USER13> _> Make is more than a build system, it's also an automation tool._

I agree with that, but I don't believe that the GP said otherwise. Make is an automation tool, but what it aims to automate is exactly dependency tracking. Other features, like actually performing the tasks, are off-loaded to the shell and other tools.

 _> It gives you a fairly flexible format for managing different tasks with shared variables and autocompletion and more._

You could as well be describing a shell here, which already have these features.

 _> You can do it with a bunch of shell scripts too but I prefer having everything in a single file._

What stops you from using a single shell script? Likewise, you have a Makefile delegate tasks to other Makefiles (as the author has done for the build- tokenizer rule).

Anyway, you should of course use them in any manner that suits you, but for a guide on "using Makefiles for Go" I think it's an oversight to ignore the main selling point of make by just using it as you would a switched shell script with no dependency tracking. It just introduces another syntax and new caveats to the problem, adding little value.

<comment><USER14> I think people kind of talk past each other in these discussions because there isn't a standardised vocabulary. I would call that kind of anaemic Makefile a "task runner" rather than a build system. And yes indeed, a task runner can easily be written as a single POSIX/Bash shellscript that has conditional behaviour based on its first argument. The `case ... in ...` statement in shell is rather nice!

</comment></comment></comment></comment><comment><USER15> It's really frustrating seeing so many Makefiles that don't _make_ anything.

Make syntax is really odd. I see so many folks go out of their way to deal w/quirks of make when they really just need a shell script. You can see this anti-pattern very quickly when you see `.PHONY` targets for everything.

I think make is useful for some aspects of go. GOPATH is becoming less relevant now, but still helpful when you want to have build-time dependencies in $PATH

        $(GOPATH)/bin/some-dependency:
            go get -u ...

I still use make when building artifacts, especially in CI. But as a default, I almost always try to talk folks out of using make for this sort of stuff.

<comment><USER16> Is there a way to easily have something like make targets in a shell script, without a ton of boilerplate?

> Make syntax is really odd

I don't find it particularly strange, _except_ my biggest peeve - <USER2> insistence on tabs!

<comment><USER14> Here's a named task runner shellscript (as compared to a Makefile full of .PHONY being used as a named task runner).

        #!/bin/sh
        set -e

        case "$1" in
            build)
                ;;
            run)
                ;;
            clean)
                ;;
            *)
                echo "unknown: $1"; exit 2
                ;;
        esac

Someone else ITT hinted it could be done like the following. But the last line is dubious because it will happily run anything on PATH.

        #!/bin/sh
        set -e

        test $# -gt 0

        build() {
            :
        }

        run() {
            :
        }

        clean() {
            :
        }

        "$@"

<comment><USER16> > (as compared to a Makefile full of .PHONY being used as a named task runner)

Personally, I've never used PHONY, or had a need to.

That said, your bash examples are pretty simple - I especially like the 2nd example, as it would trivially allow having targets that ran _other_ targets, e.g. an "all" target from a makefile:

``` all: build push

build: @docker build --tag ${IMG} --tag ${UNSTABLE} .

rebuild: @docker build --no-cache --tag ${IMG} --tag ${UNSTABLE} .

push: @docker push ${NAME} ```

</comment></comment></comment></comment><comment><USER13> This Makefile could as well have been a shell script. It doesn't track changes to dependencies even when it's obvious how to do so. For example, the build rule has an obvious dependency (main.go) and an obvious target ($(APP)). Instead of tracking these which IMO is the primary advantage of using Make, it deliberately destroys the existing build. docked-build always necessarily rebuilds the binary as well

Presumably, Go has some kind of build cache making such dependency tracking relatively useless anyway, maybe Docker has too, but if you aren't tracking dependencies and rebuilding only when necessary why use Make instead of a big switch in a shell script?

Personally I'd only use Make for Go if I introduce some task that takes significant time and isn't already handled by the go toolchain.

Another couple of notes: there are two docker-push rules. The first seems like it was meant to be docker-build. The other is that the docker build rule will tag the build with the HEAD hash, regardless of whether it's building from a clean checkout or a dirty repo.

</comment><comment><USER17> _rm -rf ${APP}_ is a code smell. If _${APP}_ is not a directory, _-r_ should not be in this command. At best it is possibly confusing, and at worst if somehow _${APP}_ accidentally becomes a directory it will just remove it and you will have no idea that it was a directory, whereas just _rm -f ${APP}_ will fail because it can't unlink a directory. Build success is an important factor in a CI/CD pipeline, therefore builds should fail immediately under unexpected behavior.

Also, on .PHONY on a single line:

      But for Makefiles which grow really big, this is not suggested as it
      could lead to ambiguity and unreadability, hence the preferred way is
      to explicitly set phony target right before the rule definition.

If your Makefile grows really big, it's going to become a nightmare to maintain. Either split up your codebase + builds into sub-directories, or figure out some other way to structure your builds so that it's not super complicated to reason about or maintain them.

<comment><USER13> I find that complexity of a Makefile isn't necessarily a function of its size. Ideally, one should be able to reason about each target individually, specifying its dependencies without consideration for how they are generated, whether they already exist etc. In such an ideal situation, it doesn't matter how large the Makefile is. Maintenance problems IMO happen when you can't trust tasks to fully specify their dependencies or that task commands only generate the target output.

Over all I agree with your argument, though.

</comment></comment><comment><USER18> I've been using Makefiles for Go development basically since I started with the language. It's really effective for me and makes compilation and, in my case, deployment to AWS Lambdas via CloudFormation commands (also invoked by Make) really simple. It's also easy to bring someone up to speed with how building and deploying works.

<comment><USER19> It might make it easier to bring someone up to speed for your project, but he won't learn a damn thing about building other Go projects - I guess that's one of the arguments that the opponents of make, er, make...

<comment><USER20> there's no standard for building Go projects (except the use of "go build"). Make is common enough that learning how to use it is a worthwhile use of time for a new Go developer.

I also use a Makefile for my projects, for all the above reasons, but mostly so that I can hand it to a new team member and say "clone the repo, install make if you haven't already, then choose either make docker_init or make localdev_init" and know that they'll have a working installation about 15 minutes later.

Not supporting Windows is a furphy - we're developing a Linux-based web server. There's no point trying to develop this on Windows. Yes, you can do it with Docker, but you'll always be wondering if that error was from your code, or from some misalignment of stuff in your tech stack.

</comment></comment></comment><comment><USER21> Great article, but I'm not sure it's a good idea to segment your Docker images by environment. Part of Docker's appeal is that you can be sure your staging & production containers are bit-for-bit the same. I use a workflow like this:

* For all commits on all branches, run tests. If tests don't pass, don't push containers to registry.

* For all commits on all branches, build and push a container `{branchname}-{commitsha}` (assuming tests pass).

* Code review, etc.

* Merge pull request to `master` branch (tests will run, and only push a container if they pass).

* Deploy `master-{commitsha}` to staging.

* Do your final testing on staging.

* Deploy the same `master-{commitsha}` to production.

Now you're deploying to production from the master branch, which passed tests, and the container is the same one as you tested on staging.

Plus, you can always deploy your non-master `{branchname}-{commitsha}` images to a separate environment, or to staging, if you need to do a bit of experimenting.

</comment><comment><USER22> I noticed you didn't mention ".DELETE_ON_ERROR". AFAIK, it's recommended to always use it (according to the GNU make manual: "[...] 'make' will do this if '.DELETE_ON_ERROR' appears as a target. This is almost always what you want 'make' to do, but it is not historical practice; so for compatibility, you must explicitly request it.")

</comment><comment><USER23> Alternatively, you could use Bazel[1], and automatically generate most of your build rules with Gazelle[2].

This would allow you to extend your build system beyond what's available via "go build", while avoiding the well-known pitfalls of Makefiles (config complexity, reproducibility, etc.)

[1] [https://github.com/bazelbuild/rules_go](https://github.com/bazelbuild/rules_go)

[2] [https://github.com/bazelbuild/bazel- gazelle](https://github.com/bazelbuild/bazel-gazelle)

<comment><USER24> I tried Bazel for awhile on a bunch of projects and just found it to be more headache than it's worth. I like the promise, but the tool is... meh

</comment></comment><comment><USER25> I suggest reading "recursive make considered harmful". It is a wonderful introduction to make, and explains how to avoid a few pitfalls most make users (including this article) run into.

In particular, the targets in the subdirectory makefiles can and should be auto-generated using make itself. There's no need for the makefiles in the subdirectories (there is also no need to use an external tool to generate them, which is the other mistake people often make).

</comment><comment><USER26> I think the example discussed in this blog is selling Make short. A more complete example with: protoc(protobuf), Docker, DynamoDB local, go modules (and vendoring), and testing can be found at [https://github.com/rynop/abp- sam-twirp/blob/master/Makefile](https://github.com/rynop/abp-sam- twirp/blob/master/Makefile)

</comment><comment><USER27> Nice article. I use makefiles a lot, mostly for all projects that I use, both for frontend and backend, mainly to have the same commands independently of framework/platform that im using. For me its helpful to just run `make` both to build and run a go project and a react project.

Another thing you can add is:

.DEFAULT_GOAL := start

start: fmt swag vet build run

Helps define you default command soyou just need to run `make` and will run all inside of `start`

Since most of us use `.env` files for enviroment files, you can use something like:

# this allows to import into this file all current system envs

include .env

export

And it will inject all of .env file into the current running `process`

Also have some other shortcuts (variables):

GOCMD=go

GOBUILD=$(GOCMD) build

GOCLEAN=$(GOCMD) clean

GOTEST=$(GOCMD) test

GOFMT=gofmt -w

GOGET=$(GOCMD) mod download

GOVER=$(COCMD) vet

GOFILES=$(shell find . -name "*.go" -type f)

BINARY_NAME=my-cool-project

BINARY_UNIX=$(BINARY_NAME)_prod

</comment><comment><USER28> Going to throw out my 2 cents here:

1\. I don't like multiple makefiles. Icky with lots of duplication and high maintenance. Bad article.

2\. When possible I use target expansion to generate targets in the main makefile:

APPS:= app1 app2 app3

$(APPS:%=build.%)

3\. I prefer to use makefile functions rather than reaching for "bash" where possible: [https://www.gnu.org/software/make/manual/html_node/Functions...](https://www.gnu.org/software/make/manual/html_node/Functions.html#Functions)

4\. If something is really complicated - extract to bash

Make has been written in 10K languages and the original is still the best

</comment><comment><USER29> I don't mind Makefiles, and usually use them for basic command configuration.

However, when the logic gets even a little complicated and I almost always reach for bash. Everybody knows a little bash, and it's available in almost all systems.

</comment><comment><USER30> Not related to the contents of the article, but I love the font on that site. I also love the simplicity of the site as well. Nothing takes away from the ability to read. It is so clear and concise.

</comment><comment><USER31> There really is no perfect build tool, but in my experience, nothing touches invoke [http://www.pyinvoke.org](http://www.pyinvoke.org) for building and automation.

Any project will eventually have build and deployment scripts with non-trivial amounts of logic in them.

The question then becomes whether you want all that complex logic in shell scripts, makefiles, or Python.

For me, it's a no-brainer. I'll take the latter every time.

</comment><comment><USER32> You don't use makefiles in go! You just take your code, copy go.mod and go.sum into a Docker image, then RUN mod download, then re-copy the rest of the code and run bui...

Shit... Docker is a makefile...

</comment><comment><USER33> It looks very close to [https://github.com/azer/go-makefile- example](https://github.com/azer/go-makefile-example)

</comment><comment><USER34> For projects that use tags to turn on/off compilation options, Makefiles and shell scripts make sense.</comment>