New ransomware written in JavaScript discovered - <AUTHOR> http://www.scmagazine.com/new-raa-ransomware-written-in-javascript-discovered/article/504029/ <comment><USER2> For those who are interested in the guts of this, you can find the beautified code on Github[0] and a detailed breakdown here[1].

In short, Windows completely exposes its filesystem through ActiveX and WScript, skipping the need to package Node for filesystem access. Then bundle native JS crypto along with some nasty string-encoded binaries, and you've got everything you need to hold a PC hostage.

Makes me wonder if there's a way to commit such evils with AppleScript and/or JavaScriptCore...

[0]: [https://gist.github.com/Antelox/020c727e1917bd018441cb6425ca...](https://gist.github.com/Antelox/020c727e1917bd018441cb6425cae397)

[1]: [https://reaqta.com/2016/06/raa-ransomware-delivering- pony/](https://reaqta.com/2016/06/raa-ransomware-delivering-pony/)

<comment><USER3> Not "completely", there are ways to disable this sort of thing with AD policies. This corner of Windows has been de-emphasized ever since the "security push" of XPsp2, and it's all but been replaced by Powershell. Microsoft being Microsoft, they have not completely removed cscript.exe for compatibility reasons but they'll likely do it at some point.

In fact, I bet this "exploit" doesn't work on a properly-secured box with UAC on where a user is not running as a local admin, at least not for the part about Volume Shadow Copy.

It's a shame because I personally like CScript/WScript, it's the little scripting engine that could. Unfortunately, the Windows security model is too haphazard to let something like this free to run.

<comment><USER4> In Korea banks, by law, have to secure their Web sites with ActiveX plugins, which probably means this stuff is going to be around way longer than it should be.

<comment><USER5> This. South Korea's insistence on using 2001 technologies today has made Windows almost unmanageable in a highly secure environment.

<comment><USER4> Can't you block ActiveX altogether through GP? I mean... doesn't help if you're in Korea, but for the rest of us.

</comment></comment></comment></comment></comment><comment><USER6> Nothing new about this as they've been around for a long time.

As a sysadmin myself we have set all computers to open .js files with notepad by default (rather than the Windows Scripting Engine) so they will not execute if opened accidentally.

<comment><USER7> Does ntfs not have an executable bit as part of its permissions??

<comment><USER8> It has read and execute. However, the JS file is not _executed_; it's _read_ by the interpreter. So an executable bit wouldn't matter as the file could still be read by any interpreter.

<comment><USER9> The guy you're replying to is probably used to linux where you can interpret a script the same way you run an executable: [http://lxr.free- electrons.com/source/fs/binfmt_script.c](http://lxr.free- electrons.com/source/fs/binfmt_script.c)

You can even add your own executable formats to do stuff like running Java class files by typing `./main.class`: [https://www.kernel.org/doc/Documentation/binfmt_misc.txt](https://www.kernel.org/doc/Documentation/binfmt_misc.txt)

<comment> vertex-four Of course, you can run "<interpreter> <file>" anyway and it works, +x or no +x.

<comment><USER10> You can do, but because Linux has a mechanism for launching the correct interpreter which honours the +x bit it's unusual for anything to do this automatically, whereas on Windows associating interpreters with scripting formats is exactly the same as associating editors with document formats.

<comment><USER11> Amusingly this was changed with PowerShell in that .ps1 files do _not_ have powershell.exe registered to run them when double-clicked. As a result people complain about it and resort to writing a .bat wrapper around the script.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> This reminds me of some worm/virus/??? I'd see on people's computers back in the Kazaa days. It seemed like it would copy itself into the shared folder, picking filenames based on what was already there: e.g. Alanis Morisette - Ironic.mp3.js

I never looked at what its payload was. It's good to see that js viruses have also made their way to modern coding standards.

<comment><USER13> Are there still active "worms" out there?

<comment><USER14> Probably millions at this point. A worm is just a virus that can spread itself without human interaction.

</comment></comment></comment><comment><USER15> I was wondering how the hell does this access files, since there is a complete lack of any filesystem access in every normal browsers.

TIL that in Windows .js files can be executed outside of the browser...

<comment><USER16> And it's a huge security threat at that.

<comment><USER17> Why? JavaScript is just a language. A browser is just one platform it happens to run. Scripts running in a browser have certain restrictions. Scripts running directly on the host OS typically have unfettered access to the whole filesystem. If they're written in Python, batch, JavaScript, Ruby, etc... shouldn't have any role in deciding how much access the script has to the filesystem. Similarly if browsers were to support running Python that code shouldn't automatically have full filesystem access just based on the language it's written in.

</comment></comment></comment><comment><USER18> Are variables being assigned multiple times needlessly here? What's going on, is that just obfuscation? Search the code for "this._hash.words" and have a look.

[https://gist.github.com/Antelox/020c727e1917bd018441cb6425ca...](https://gist.github.com/Antelox/020c727e1917bd018441cb6425cae397)

<comment><USER19> It's a bit of obfuscation, but mostly it takes advantage of the fact that `var` assignments are sequential to cram an entire MD5 block compression into a single `var` statement. Think of it simply as a long sequence of statements without the `var` prepended and it makes much more sense.

</comment></comment><comment><USER20> I've received several emails recently discussing a court order or some such, with a zip file attached containing a lone *.doc.js file. Of course I've never tried running it, but I do wonder if it's the same sort of thing.

Further, my university (University of Calgary) was recently hit by ransomware, and I have heard that some Calgary companies have also been hit by ransomware in the last 4-6 weeks. If the attack is this prevalent, and arguably this easy for non-expert users to accidentally execute over a whole network, I think we need to seriously consider how we train our users and what kinds of default permissions we allow.

</comment><comment><USER21> I'd love to see the code for this, probably a lot you can learn about low level JS from something like this.

<comment><USER14> Code is here: [https://gist.github.com/Antelox/020c727e1917bd018441cb6425ca...](https://gist.github.com/Antelox/020c727e1917bd018441cb6425cae397)

There is no such thing as low-level JS.

Edit: For those who don't believe that JS can't be low-level, please see Wikipedia's definition of "low-level programming language"[1]:

"a programming language that provides little or no abstraction from a computer's instruction set architecture—commands or functions in the language map closely to processor instructions"

If you know literally _anything_ about JavaScript, how it runs, or how processors run, you'll know that JS is not even in the ballpark of "low- level".

Perhaps the parent comment was referring to "JavaScript without frameworks, third-party libraries, or heavy abstractions," which is still not exactly a complex or mystifying arena.

1\. [https://en.wikipedia.org/wiki/Low- level_programming_language](https://en.wikipedia.org/wiki/Low- level_programming_language)

<comment><USER19> Nit: asm.js ([http://asmjs.org/](http://asmjs.org/)) _is_ low-level JavaScript - a subset of JavaScript which is explicitly compiled into equivalent machine code ahead-of-time by supporting browsers (and interpreted otherwise). asm.js imposes significant restrictions on JavaScript in order to produce efficiently compilable code, and its operations map almost 1:1 to machine instructions.

And as you correctly note, the ransomware code does not come close to qualifying as "low-level".

</comment></comment></comment><comment><USER22> I received something like this in a spam email (I didn't get infected though), it was a fake 'court order' intended to be accidentally ran with the windows scripting engine, which has a JavaScript interpreter.

<comment><USER23> I get dozens of it everyday. Let me know if you want some.

</comment></comment><comment><USER24> I've blocked a long list of file extensions on my network with SRP for all locations users can write to, just whitelisted c:\program files etc

</comment><comment><USER25> Good, now I'm going to be even more paranoid typing

` npm install `

` pod install `

And the likes.

You know, third party services which we wholeheartedly trust and let them execute whatever they download from github on our development machines.

Ransomware is very close to being a perfect crime and I don't see why people would ever stop doing it.

Expect it to become really widespread and evolved.

That being said, if you are developing and deploying ransomware, then you are doing a very wrong thing, spiritually.

You may not believe in karma, because it's convenient to you, but the message from our ancestors has always been this - all the shit that you cause in life is going to come back to you OR your children in one form or another - multiplied. So just don't.

<comment><USER26> _all the shit that you cause in life is going to come back to you OR your children in one form or another - multiplied._

Almost all worldviews share a similar idea, but that does not make it a proven fact. Ultimately, they are all premised on a omniscient and vindictive entity (either explicitly or implicitly). I'm of the opinion that these views originate more from a desire to soothe victims than to discourage offenders.

We should do better than vague threats to improve society.

</comment></comment><comment><USER27> For when you want your malware to have 300 dependencies and take 5 hours to setup-- there's JavaScript!

<comment><USER2> Think again. This bad boy is only ~600 lines if you discount the only embedded dependency, CryptoJS.</comment></comment>


Hobbyists Rebuild Wall-E, One PVC Pipe at a Time - <AUTHOR> http://www.wired.com/gadgetlab/2009/05/wall-e-robots/ <comment><USER2> Why haven't I heard of the robot geek with the garage Johnny Five replica? Johnny Five was equally as awesome imho...</comment>


Write a mini-Redis in Rust: learn async programming with Tokio - <AUTHOR> https://tokio.rs/tokio/tutorial <comment><USER2> This is a fine tutorial, but I must note that Rust async programming is a bad way to learn about Rust, and also is a bad way to learn about async programming. You should learn the basics of both Ruts and async programming elsewhere, and then try Rust async programming.

If you disagree, take a look at compile error in [https://tokio.rs/tokio/tutorial/streams](https://tokio.rs/tokio/tutorial/streams) and think again. That is in fact NOT atypical. (Amusing paradox: you get less errors once you learned, but you get the most terrible errors when you are the least equipped to deal with them.)

To slightly exaggerate, I spend about half my time in Rust support chat channel in my locality to discourage people from trying Rust async programming without getting the basics of Rust. Their logic go: I am interested in Rust only for async network programming, I am not interested in Rust sync network programming, I also learn best by try using something in a project straight away, so I will just learn Rust by writing a Rust async programming project! This literally 100% fails, but people who do this really really want to do it that way, and discouragement doesn't really work, and they get really frustrated, and... I am not sure how to solve this.

<comment><USER3> Yeah. `async` involves a lot of sophisticated and bleeding edge machinery, and is not really "fully ready" for wide-consumption, IMO.

What's funny is that while `async` is great tool to have 99% of programs will not see a difference.

<comment><USER2> I think wide consumption is getting there, but I don't think it will be ever ready for consumption by learners. There is just a lot under the hood.

(It pains me to write that because otherwise I am very much against Joel's law of leaky abstractions, I believe in aiming for leak-proof abstractions, and I know they are possible. It's just that it probably is not always possible, and it is especially hard to abstract learnability, and it is a lot of work even when it is possible.)

While I also think most people do not need async and will not see differences, I focus on learning aspect and refrain from saying "you probably don't need it", because I found people are not stupid and people who insist on async usually have actual need for async. This may be due to what kind of people congregate on my local community and may not hold elsewhere though.

</comment></comment></comment><comment><USER4> Hold on, there is way more documentation than before ! Things like "when to use std::sync::mutex vs tokio::sync::mutex" were not there 1 version ago ! additionally, framing and streams will be of great help for my current project!

</comment><comment><USER5> Redis is one of those things that deceptively looks like it would be easy to build in the eyes of a beginner engineer but in reality is a great technical achievement.

<comment><USER6> Don't just tease the subject, share some highlights!

</comment></comment><comment><USER7> This is pretty neat. I've always thought Redis was a good way (and arguably a better one) to get to grips with network code in a new language/runtime.

I did it for asyncio, Go, Clojure and a few other things.</comment>


Tipping Is Coming to Uber - <AUTHOR> http://www.bloomberg.com/news/articles/2016-04-22/tipping-is-coming-to-uber-and-it-s-going-to-be-awkward <comment><USER2> Tipping is an awful and awkward practice that shouldn't ever be encouraged. I found I was way happier about paying for any kind of service in parts of the world where tipping isn't expected or even frowned on. Pay your employees properly. If you are self employed, roll gratuity into the fee for your service.

This is taking one of the best things about Uber and Uber-like services away. Ignoring the surge pricing BS, I don't have to keep an eye on the meter, I don't have to argue with the driver about the fare, I don't have to worry about the tip, I don't need cash on hand, etc.

<comment><USER3> I agree. Tipping is a terrible practice. Also, Uber drivers receive ratings. I can already see that drivers asking for tips would probably get lower ratings. That's not going to end well.

<comment><USER4> Riders receive ratings, too.

<comment><USER3> Then it's all out war in the making. Suppose one takes a ride and the driver strikes a conversation about tips and how they're essential and so on. And the passenger doesn't tip. Then the passenger can assume the driver will give him low rating. So in return the passenger will give the driver _really_ low rating.

</comment></comment></comment></comment><comment><USER5> This was one of Uber's big advantages over the old cab system. Tipping is archaic and bizarre and ought to be eliminated in favor of fair, predictable wages and a client/service provider relationship which does not involve a faux-Victorian status hierarchy.

<comment><USER6> Yeah, I've personally overlooked Uber's most unfortunate PR crises because darn, it's convenient to not pay a tip. But if that slim advantage goes away, I'm back to the same decision matrix that made me dislike taxis.

</comment></comment><comment><USER7> I see tipping as an excuse for an employer to pay lower salaries to it's employees, essentially shifting the burden to the client. It's an uncivilized practice. As someone said previously: "Pay your employees properly!" please.

<comment><USER8> It incentivizes them to do a great job and please the customer.

<comment><USER9> That depends on what you mean by "great service". As an Australian living in Japan, I was unfamiliar with tipping until a recent trip to the US. And the thing that surprised me even more than the bizarre idea of me having the power to underpay a worker despite them doing a perfectly good job (that would be illegal in other countries), would be the idea of "great service". Apparently in the US, great service consists of being nagged constantly to remind you that he server exists and needs a tip. Great sevice in Japan however means leave me the fuck alone and let me enjoy my meal in peace.

<comment><USER10> >Apparently in the US, great service consists of being nagged constantly to remind you that he server exists and needs a tip.

It really doesn't. It means that my water gets refilled, you don't mess up the order, you're there when I have a problem, want to order dessert, want my check, etc. I can't speak for everyone but if I have to eventually ask someone else to find you to get me my check--that's when tips go down, not because you weren't pestering me constantly.

</comment></comment></comment></comment><comment><USER11> I've been out of the states for 1.5 years and have gotten totally comfortable with how most of the world doesn't tip. Please don't force it on me again.

<comment><USER12> Yep, I absolutely adore the states it's one of my favourite places but as somebody from the UK by the time I leave I'm always glad to be leaving behind the tipping mentality.

</comment></comment><comment><USER13> >In any case, they argued that Uber shouldn't take a cut of the portion of the fare that was classified as a tip.

It getting that "am I the only sane one?" feeling from the fact that this even became a court case. There are _arbitrarily many_ fare breakdowns, all observationally equivalent, into "uncut tip", "driver's cut", and "Uber's" cut. You can equally well say that a $10 fare was:

A) $2 tip, $8 fare that Uber takes a $2 cut from, or

B) No tip, $10 fare that Uber took a $2 cut from.

Either way, the driver gets $8 and Uber gets $2. When you have no choice and Uber never itemizes a tip amount, it's equally right to say that Uber was taking 25% after a mandatory 25% tip (framing A) or that Uber was taking 20% from an untipped amount (framing B) or anything in between.

There is literally no "fact of the matter" as to which portion is a "tip" Uber is taking a cut from, and even if there were, Uber could reframe it in the light of any injunction so that the payment flows and fares are the same.

So people basically went to court over whether eggs must be labeled as "six" or a "half dozen". Wha?

</comment><comment><USER14> The main reason I liked Uber was the lack of tipping. You summon a car, go where you're going, get out and the fare is paid automatically. It's a perfectly seemless process. We've injected tips into so many transactions that it was refreshing to have one where I didn't have to try and guess what the "real" price is.

<comment><USER15> Just don't tip? I never do with Lyft.

<comment><USER14> Yeah, I probably won't. If they add a "tip" field to the app though it's going to be expected. I avoid lyft specifically for this reason.

</comment></comment></comment><comment><USER16> So uber is recreating the taxi system with all its warts. I can't wait for stage 3 where they lobby for local regulations and licensing limiting competition.

<comment><USER13> And stage 4 where they introduce "UberHand", which doesn't require an app; instead, you just wave down one of their yellow-car "driver partners" and pay them in cash. Like:

[http://uberhand.weebly.com](http://uberhand.weebly.com)

</comment></comment><comment><USER17> Why should I tip? All the driver's doing is following his GPS to the destination.

<comment><USER18> Seems like you haven't had any exceptional drivers!

I've had drivers on Uber-like services offer water, mints, candy, magazines to read. Definitely makes the experience more pleasant, but adds to the driver's overhead cost. I could see tipping to subsidize that.

</comment></comment><comment><USER19> "The company said it has no plans to add an option to tip through its app or to lower the cost of fares under the assumption people will always leave tips voluntarily."

Uber just settled that cash tips are OK, but they obviously want this to die quickly if they have no plans to integrate tipping into the application and hence the experience like Lyft. If having a "great experience" is core to Uber, I'm sure that the confusion and behavior change now that drivers can ask for tips will negatively affect people's experiences, result in lower ratings, and Uber can flag such drivers (maybe customers) as having a rating below a certain threshold and drop them (?). But keeping driver supply seems important...

</comment><comment><USER20> One of the major reasons Chinese taxi drivers prefer Didi to Uber is that they can get tips. So I think that's a huge move in the right direction. Finding a driver on a Friday evening is free market jungle at its finest. This way at least you have options.

<comment><USER21> What? I lived in China for five years, took Didi many times and never heard of anyone tipping taxi drivers except in rare occasions. The few times I tried to tip drivers they were offended or thought I was joking (unless they weren't using the meter). The reason Chinese taxi drivers prefer Didi is that Uber has virtually no market share in China.

<comment><USER20> Well then you must have been in another China than me. In the China I went to you won't even get a taxi in a busy time if you don't start the taxi search with a tip.

<comment><USER22> It's not a tip, it's a bounty. And it only applies to taxi drivers, AFAIK. Ridesharing drivers are on the same surge pricing style system that uber uses.

</comment></comment></comment></comment><comment><USER23> Interestingly Kalanick's statement on the settlement that forces the tipping notification does not contain any reference to that part of it:

"Today we announced a settlement in two important class-action lawsuits: O'Connor (California) and Yucesoy (Massachusetts). The key issue at stake in both cases is whether drivers using the Uber app should be classified as independent contractors or employees.

As part of this settlement, which covers all classification claims involving Uber in California and Massachusetts, the two sides have agreed that:

* Drivers will remain independent contractors, not employees;

* Uber will pay $84 million to the plaintiffs. There will be a second payment of $16 million if Uber goes public and our valuation increases one and a half times from our December 2015 financing valuation within the first year of an IPO;

* Uber will provide drivers with more information about their individual rating and how it compares with their peers. Uber will also introduce a policy explaining the circumstances under which we ban drivers in these states from using the app; and

* We will work together to create a driver's association in both states. Uber will help fund these two associations and meet them quarterly to discuss the issues that matter most to drivers.

Six years ago when Uber first started in San Francisco, it was easy to communicate with the handful of drivers using the app. Austin Geidt, who ran marketing, called each one regularly to get their feedback and make sure things were working well. It was clear from those early conversations that drivers really valued the freedom Uber offered.

Today, while the number of drivers using our app has grown dramatically, their reasons for doing so haven't changed. In the U.S. almost 90 percent say they choose Uber because they want to be their own boss. Drivers value their independence — the freedom to push a button rather than punch a clock, to use Uber and Lyft simultaneously, to drive most of the week or for just a few hours.

That's why we are so pleased that this settlement recognizes that drivers should remain as independent contractors, not employees. As one driver told the court: "I've been an employee and an employer, and I've also been an independent contractor. I know the difference between these things. With Uber, I'm an independent contractor. And I wouldn't have it any other way." As another said: "I wouldn't even want to be an Uber employee. I would quit if they tried to make me an employee, because I value my freedom as an independent contractor too much."

That said, as Uber has grown — over 450,000 drivers use the app each month here in the U.S. — we haven't always done a good job working with drivers. For example, we don't have a policy explaining when and how we bar drivers from using the app, or a process to appeal these decisions. At our size that's not good enough. It's time to change.

So today we've published a driver deactivation policy for the first time. It will apply across the United States, and our goal is to roll out similar policies globally over time. You can read it in English, Spanish, Mandarin and Arabic, with more languages to follow.

It's incredibly important that when people use Uber, they have a great experience — one that is safe, reliable, convenient and a good value. Otherwise, fewer passengers will use the app over time, which is bad for everyone. The policy explains why drivers are deactivated, the warnings we give and the circumstances in which drivers can use the app again.

Sometimes it's clear that a driver shouldn't be allowed on our platform: we permanently ban drivers who are violent, drink and drive, or refuse someone a ride because of the color of their skin or sexual orientation (it happens, sadly). But what if a driver's rating declines due to poor driving or a smelly car? (And it's not just bad smells that cause problems — we do get complaints about too much Febreze.) In those cases we let the driver know that there's an issue and, if things don't improve, we deactivate their account. We're also working with a number of companies to provide affordable quality improvement courses.

As part of this settlement, Uber has agreed not to deactivate drivers who regularly decline trips when they are logged into the app. If too many drivers decline the rides we send their way, it undermines the reliability of the service for riders. But we understand that drivers need breaks, and sometimes things come up — maybe a kid has gotten sick at school. When drivers aren't available, we'd just ask they turn off the app. And where drivers do have low acceptance rates — perhaps because they are multitasking at home — we will alert them to the issue. If things don't pick up, we may log them out of the app for a limited period of time.

Uber has become an important part of many drivers' lives, whether they drive all week or for a couple of hours to help pay the bills. So we've agreed to create an appeals process in California and Massachusetts for drivers who disagree with these decisions. In fact, we've been working on a pilot in Seattle for the last few months, which includes having other drivers hear these appeals. Our hope is that this kind of peer review process will improve transparency and accountability and give drivers an additional voice. If this approach is successful, we'll look at rolling it out across the U.S.

Uber is a new way of working: it's about people having the freedom to start and stop work when they want, at the push of a button. As we've grown we've gotten a lot right — but certainly not everything. This new deactivation policy is an important step forward when it comes to working with drivers. But there's more to do, which is why I'm excited about some other improvements we have planned for the not too distant future. Stay tuned." [1]

[1] [https://medium.com/@UberPubPolicy/growing-and-growing- up-6ba...](https://medium.com/@UberPubPolicy/growing-and-growing- up-6ba229682a8)

<comment><USER24> Presumably because they (rightly, IMHO) think it's a terrible idea for their service, brand, and customers & would like to keep it from becoming a norm.</comment></comment>


Show HN: Generator of stormy weather (and peaceful vibes) - <AUTHOR> http://pluvior.xyz/?play <comment><AUTHOR> using rainyday.js library</comment>


Ask HN: How do you log your services? - <AUTHOR> For long running services, for example, how do you monitor them? How do you view the logs, and how are you alerted if an exception occurs?
Is CloudWatch easy to use?
Besides just using `tail -f $file` <comment> cat-turner We use a combination of metric and events. Some trigger sns... Which trigger lambdas that forward urgent messages to slack.

<comment> cat-turner Cloudwatch search is slow af tho exploring faster options.</comment></comment>


Ask HN: If not Apache NiFi, what would you use? - <AUTHOR> I read with great interest the comments here (https://news.ycombinator.com/item?id=23144450), and there seemed to be many who didn't like it. However, I didn't really see alternatives suggested. So I wondered, suppose you have an integration task to get data flowing from one system to another. Are there open source alternatives you would recommend? Particularly ones that are friendly to dropping to custom code where needed, and are friendly to storage in (say) git? <comment><USER2> If you are completely ditching the graphical approach you'd consume your data producers and work with that, you'd throw your files into a S3 Bucket and it gets picked up - all those would require custom software to be written</comment>


Intel's Atom C2000 chips are bricking products, and it's not just Cisco hit - <AUTHOR> http://www.theregister.co.uk/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/ <comment><USER3> Reminds me of the Sandy Bridge SATA flaw.

"The problem in the chipset was traced back to a transistor in the 3Gbps PLL clocking tree. The aforementioned transistor has a very thin gate oxide, which allows you to turn it on with a very low voltage. Unfortunately in this case Intel biased the transistor with too high of a voltage, resulting in higher than expected leakage current. Depending on the physical characteristics of the transistor the leakage current here can increase over time which can ultimately result in this failure on the 3Gbps ports."

[http://www.anandtech.com/show/4143/the-source-of-intels- coug...](http://www.anandtech.com/show/4143/the-source-of-intels-cougar-point- sata-bug)

<comment><USER4> I wonder how many would even bother to get it replaced if it was discovered say only a year after launch.

<comment><USER5> I had one of those. The shop I bought it from refused to replace it from their inventory, all they would do is take the motherboard, send it back and then give me the replacement some weeks later when the RMA process was completed.

Since I needed that machine functioning, I never replaced it (the mobo had some extra SATA ports handled by a different controller, so they kept working and I switched to using them). I suspect a lot of people are in the same boat. I'll never do business with that store again.

</comment></comment></comment><comment><USER6> _sigh_ The perils of maintaining my own data center in the basement for 'fun' are coming to haunt me.

I have 2x C2758 Supermicro boxes running core routing services and a Synology RS2416+ for storage - all on the affected CPU list - guess I better double check my backups are working and allocate some funds for replacement kit in case things go belly up!

</comment><comment><USER7> If this is the related the Cisco clock signal component issue. Cisco is handling it in a really poor way. No replacements unless its under warranty even though its a known issue.

[http://www.cisco.com/c/en/us/support/web/clock- signal.html#~...](http://www.cisco.com/c/en/us/support/web/clock- signal.html#~faqs)

<comment><USER8> Under warranty or anyone who has a TAC subscription. Cisco licensed their products with a ToS that says you can't resell it, and warranties are only valid for people who bought directly from Cisco. You also can't (effectively) get TAC support for a resold device (what Cisco folks call "grey market"). It's not illegal to buy secondhand Cisco product, Cisco just won't support them or let you get software upgrades without paying them a ton of money.

100%, this wording is to make sure that grey market buyers aren't covered under the replacement. Basically anyone who bought from Cisco will be able to get a replacement.

<comment><USER9> How do they handle this in the EU, where 2 years warranty, even if resold, are mandatory?

<comment><USER10> That don't cover business buyers who I guess are most of Cisco buyers, only consumers.

<comment><USER11> Wonder how that is applied in New Zealand where the commute guarantees act basically requires sellers to sort problems out within "a reasonable time frame" of sale. It's a fantastic piece of legislation.

<comment><USER12> The CGA only applies to consumers and not business customers, and only applies between the end reseller and the customer. Cisco doesn't really sell directly to consumers.

</comment></comment></comment></comment></comment></comment><comment><USER4> Why don't they name the customer/supplier when it is obvious when the product is taken apart? Even with the Cisco DDR SDRAM fiasco, it wasn't that hard to figure out that it was Micron DDR SDRAM that is at fault.

<comment><USER13> No one can afford to name and shame Intel due to potential retaliation.

<comment><USER14> So why keep using intel

<comment><USER11> I'm likely revealing my ignorance, but what's the alternative?

<comment><USER15> ARM, MIPS. (multiple routers use these) Custom FPGA softcore even. Maybe extra ASICs. Cisco is big enough for that. However I suspect Intel might be cheapest to get for performance.

</comment></comment></comment></comment></comment><comment><USER16> Not great for Intel. These Avoton Atoms were the first Atom chips with respectable performance, so there was a chance to unsully the Atom name.

Also, I'm reasonably sure many of these were sold already permanently affixed to the motherboard, so the fix may be worse than swapping out just a CPU.

<comment><USER17> I don't think the processor cores in the Avoton chips were anything impressive, but these were the first Atom chips with a lot of I/O bandwidth.

From what I can tell, all of the Avoton chips were sold in a BGA package that required them to be soldered to the motherboard. There isn't a socketed version of Avoton.

</comment></comment><comment><USER18> Atom models affected:

C2308, C2338, C2350, C2358, C2508, C2518, C2530, C2538, C2550, C2558, C2718, C2730, C2738, C2750, and C2758.

How to tell what CPU your Synology NAS has:

[https://www.synology.com/en- us/knowledgebase/DSM/tutorial/Ge...](https://www.synology.com/en- us/knowledgebase/DSM/tutorial/General/What_kind_of_CPU_does_my_NAS_have)

My 3-month old 1815+ is on the list...

</comment><comment><USER19> "slightly higher expected failure rates under certain use and time constraints" sounds like it shouldn't be observable on the field. Do people suspect Intel are lying or is this a storm in a teacup?

<comment><USER15> Milquetoast words to stem panic. Ineffective.

</comment></comment><comment><USER20> Well, I guess it's time to replace my otherwise perfectly-good Synology NAS on the double.

<comment><USER16> This looks interesting: [https://forum.synology.com/enu/viewtopic.php?f=7&t=119727&st...](https://forum.synology.com/enu/viewtopic.php?f=7&t=119727&start=60)

See the last couple of posts in the thread as well.

Sounds like you can get an RMA, but it's a slow process.

<comment><USER20> Realistically, I'm not interested in an RMA for another DS1815 that will fail, followed by (possibly) another RMA once the problem is fixed in silicon. I'm also very uncertain about slotting the drives into a new unit and successfully recovering the RAID.

Instead, I'll shut down the NAS and buy a replacement from another company (QNAP probably) and transfer the data. The other options feel too risky.

<comment><USER21> I'm guessing the CPU must be soldered to the board on these ? I have a 1815+ that is currently working, and now I'm afraid to shut it off. I wonder if the DS2015 (not sure of #, the 10gbe model) uses this defective part ?

<comment><USER20> I would imagine - I haven't taken the unit apart.

<comment><USER21> probably to save money. that sucks, because even if you swapped it with another defective one, it would be worth it if you just had to replace the CPU every 18 months.

<comment><USER16> Learned in another area of this post that yes, they are soldered on, but that's Intel's choice. They only offer the CPU in a BGA (ball grid array) form factor. There's no such thing as a BGA socket, other than some specialty test unit things that aren't suitable for real world use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I heard a rumor that something very similar was detected on upcoming Xeon SKUs, but they will be implementing the board level workaround.

</comment><comment><USER23> Somewhat off-topic:

Are Cisco products worth the money ?

Personally i haven't had that much experience with their stuff, but i remember seeing a brand new router running hot with two fans blowing in it (other routers at the time were 2x smaller without fans). I understand that Cisco _should_ be the de facto networking standard, but is it really worth the name ?

<comment><USER24> Probably.. but that comes down to a lot of factors though. It also depends on what kind of gear you're looking to buy. Everyone will try to be compatible with Cisco's interpretation of a given standard, if you go elsewhere, it may or may not be 100% compatible with your other equipment. Also, more IT networking guys will be more familiar with Cisco.

That said, they are definitely more expensive than their peers. But then again, an Escallade is more expensive than a Tahoe.

</comment></comment><comment><USER6> ServeTheHome surveyed a bunch of affected vendors to get some more information on the issue: [https://www.servethehome.com/intel-atom-c2000-series-bug- qui...](https://www.servethehome.com/intel-atom-c2000-series-bug-quiet/)

And some technical specifics behind the problem: [https://slashdot.org/comments.pl?sid=10214953&cid=53819967](https://slashdot.org/comments.pl?sid=10214953&cid=53819967)

 _Can 't post to The Register, since they don't have ACs.

Anyway, the issue is damage to the LPC (low-pin-count) bus clock line. This is a secondary bus where you hang old ISA-style devices, like the system FLASH. If the FLASH is the only thing in there, it will mostly render the system unbootable (so, stuff that never gets power-cycled would just keep going). But LPC can generate interrupts, and one often hangs other crap to that bus, such as i2c controllers for hot-swap bays, motherboard management controllers, and other sensors. In that case, you can expect severe runtime misbehavior.

The issue is caused by "continuous degradation due to use", so repairing it is easy, if costly: replace the motherboard with a new one under warranty (and even if out of warranty period wherever this kind of "stealth" manufacturing defect is not subject to warranty time period limitations, such as in Brazil). It will "reset" the counter. This is your zero-day solution to the issue.

Depending on time-to-market for the new stepping (hardware revision) B1/C0 of the Atom C2000, you might need an interim solution, which is the "platform- level change", i.e. redesigned board with extra components that work around Intel's hardware design error. As soon as you have these, you start using these to replace any boards returned due to the defect, or start a "recall" to preemptively replace boards.

Depending on the total cost of the board plus other components, you keep the old boards you replaced around, and when revision B1/C0 of the Atom C2000 is out, you BGA-replace them in a factory (about US$ 25 per board in large volumes, if that much), maybe replace any liquid electrolytic capacitors and other crap that ages badly, and use the boards either as new or as refurbished, depending on your corporate/regulatory ethics. This kind of repair almost always really resets the boards MTBF. If Intel supplies the replacement Atoms at no charge, the cost of repair might well be far less than the cost of the production run for boards you'd want to keep around for warranty services, anyway.

Mind you, at 1.5 years per failure, it will be rare the legislation/contract that forces more than one replacement... so, let's hope they don't replace a faulty board with a brand-new virgin but-still-timebombed board. You'd have trouble to replace it a second time if it fails after the warranty period._

</comment><comment><USER25> Arista uses AMD and Intel. Their 1st switch (7124S & 7148SX) was a dual core AMD.

</comment><comment><USER26> This title seems incorrect. The article doesn't specify any other vendors or products that have been directly affected by this issue.

<comment><USER27> The title is technically correct, just annoyingly written. As someone who's build a PFSense box using a supermicro board with one of the affected chips, I'm definitely sad that I'll have to rip it apart to replace the parts.

<comment><USER28> I have the same problem: I'm using various C2000-based Supermicro boxes running pfSense. The most cost-effective DIY, rack mountable solution for a pfSense box was until now SYS-5018A-FTN4. Do you know if Supermicro issued a technical bulletin about this box?

<comment><USER29> Last Friday, my OpenBSD firewall, which runs on a SYS-5018A-FTN4, mysteriously crashed. I chalked it up to an alpha particle or something and rebooted. About 12 hours later, it failed again. This time I did some more digging. On the console was the following message:

      NMI ... going to debugger
      Stopped at    acpicpu_idle+0x22d:     nop
      ddb{0}>

I googled it and found one similar report on the OpenBSD misc mailing list from September 2016 [1]. Interestingly, the person who reported the bug was running the same Supermicro board as I was. The report didn't get anywhere other than a vague suggestion that it might be heat related. These boxes run very cool and I didn't think that was likely. I thought it might be a RAM issue and that it was probably just a coincidence that the other person had the same hardware as I, but now I'm inclined to think that both of us have experienced the issue described in TFA.

Seems like I'll be looking for new firewall hardware.

[1] [https://www.mail- email@example.com/msg149348.html](https://www.mail- email@example.com/msg149348.html)

<comment><USER30> If you were able to reboot the box then you did not hit this issue. When you hit this issue your chip is dead.

</comment></comment></comment></comment></comment><comment><USER31> That explains the issues with the C2000 family. Various Linux distros crash randomly, and not just crash sometimes really just stop opening applications or stop processing e.g. apt-get.

The BIOS is a piece of shit. It's buggy, the legacy-BIOS support is unstable, the Win7-EFI and Win8-EFI modes are not good either. I patched a Win7 DVD with Win8 files, so that I could install Win7. Now Win7 runs great and stable - <USER2> only after I installed various Intel drivers that fixed the hardware flaws.

I am seriously looking forward to the upcoming new AMD CPU - Intel dod barely anything the last five years, a 2011 highend CPU is almost as fast as Intel 2017 flagship, and costed a lot less back then, had less DRM or other shit that is broken. Intel needs a proper competitor, so a comeback of AMD on the one side, and Apple notebooks with ARM CPU are very welcome to stop Intel from siting on their quasi monopoly chair.

<comment><USER32> >That explains the issues with the C2000 family. Various Linux distros crash randomly, and not just crash sometimes really just stop opening applications or stop processing e.g. apt-get.

No it doesn't. Did you read the errata? It completely stops. There's no weirdness. It's just dead.

<comment><USER15> Random crashes are often sign of memory corruption. Sometimes broken power supply or major interference. Not of such CPU problems.

<comment><USER33> Meh, for C2000, it can be also a sign of outdated firmware. We don't get microcode updates for SoCs in the general distribution: either your system vendor does a good job of keeping up with firmware updates, or you are screwed.</comment></comment></comment></comment>


Quiet route planning for pedestrians in traffic noise polluted environments - <AUTHOR> http://k1z.blog.uni-heidelberg.de/2020/07/15/quiet-route-planning-for-pedestrians-in-traffic-noise-polluted-environments/ <comment><USER3> With coronavirus lockdown I've taken to going on long strolls while listening to audiobooks. Since I don't like wearing noise-canceling headphones due to situational awareness concerns (opting for a cheap pair of Koss PortaPros), it has struck me just how _loud_ a regular car is as it drives by at low speed. I have to crank up the volume above a safe level to continue listening to my book as one drives by. It makes me yearn for an urban future where personal car ownership is a distant memory.

And gas-powered leafblowers. Oh man, those are the worst. DC was right to ban them.

<comment><USER4> >It makes me yearn for an urban future where personal car ownership is a distant memory.

You won't have to wait that long -- EVs reduce noise substantially and mass adoption is probably one to three decades away depending on the city

<comment><USER5> Seems noise levels wont improve much with today's tires:

> Traffic noise is created by vehicle exhaust systems, engines, and by contact > of tires with the road during travel. Of these, tire contact with the road > accounts for 75 to 90 percent of the overall traffic noise.

<comment><USER6> That depends on speed for sure.

<comment><USER7> Above 20mph, you're mostly hearing tire noise as far as I can tell. And I'd say most driving is above 20.

Most people kind of forget about tire noise when purchasing tires. I don't think most people put much thought in tires ever anyway.

<comment><USER8> Exactly why there need to be regulations for tire noise.

<comment><USER7> Unlikely to ever pass - I'd assume. All those who like to go off roading would see all their tires never pass.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Of course, the authors being from Germany, they may have different expectations about how the existing noise environment colors people's concern about a little more/less noise in general.

I remember taking subways (subways!, not even to mention HSR) in Germany (Munich, Berlin, etc) where you could hear a pin drop during the journey, and where you could talk to your fellow traveler in a whisper.

Go to New York or Boston, and people look at you like you're a wimp if you ask why the train is screeching so loudly.

And then another example, if you've lived in the UK for any time, you come to believe that cars are supposed to make the constant diesel-level cranking noise even at idle. And then you go across the channel and find that miraculously, cars can actually be manufactured to be quiet.

<comment><USER10> > Go to New York or Boston, and people look at you like you're a wimp if you > ask why the train is screeching so loudly.

To me it feels like trains in Chicago can get to dangerously loud levels for significant portions of the route, and IIRC NYC is worse. It's unfortunate that cities don't really seem to care much about this.

<comment><USER11> Chicago granted CTA a special exemption to its noise ordinance.

There was a study that found that, while the subway can get uncomfortably loud, it probably doesn't represent a significant risk for riders. Probably pretty bad for operators, though. [https://pubmed.ncbi.nlm.nih.gov/28278069/](https://pubmed.ncbi.nlm.nih.gov/28278069/)

</comment></comment></comment><comment><USER12> I think a variation of this comfort-optimized route planning tool would be really useful for cyclists as well. I've found that Google Maps favors streets with bike lanes when planning bike trips, but those are typically main thoroughfares where the bike lane is a last line of defense against aggressive drivers, delivery vehicles, and "dooring". Often these are paralleled by quieter streets where cars drive at careful speeds and a bike lane is not really necessary for safety.

<comment><USER13> I think there are so many better routing apps for cyclists and walking but everybody defaults to Google Maps. Even people who ask me for advice on cycling routes sends me a Gmaps screenshot as if it's the only navigation app that exists.

Here are some examples I wrote down (I'm also an OSM mapper): [https://jakecoppinger.blog/articles/the-best-apps-for- bicycl...](https://jakecoppinger.blog/articles/the-best-apps-for-bicycle- directions-2020/)

Assuming the future is already here with better navigation, how do we encourage people to use anything but Gmaps? Would love to hear any thoughts :)

<comment><USER14> You should give [https://www.komoot.de/](https://www.komoot.de/) a try. It has a well-designed UI, very good routing, voice navigation (crucial for biking imo) and includes one map region for free.

<comment><USER13> Thanks, will do!

</comment></comment></comment></comment><comment><USER15> The US is so loud! I don't know if it's true but one of my theories is that a lot of US cities consist of uninterrupted grids, and noise from a much larger area than in cities with messily organized roads like those in Tokyo where I live now, ends up being audible at any given place. In Manhattan you can hear sirens from like 30 streets away - but here, walk 5 minutes from the biggest stations and intersections and it's dead silent.

Also, I noticed when I was living in Shanghai that it has gotten pretty silent there too with the dominance of electric vehicles, which has made places like the French Concession a pleasure to stroll in.

</comment><comment><USER16> Nice project! On the subject of different optimization goals for route planning, I was thinking about car travel. Google optimizes for travel time, but I often want to weight "route simplicity" higher than time — I'd rather take a straight shot down a mildly congested highway than wind through a bunch of peoples' backyards. And why not an option to "minimize deaths"? Some routes (and some turns) are more accident-prone than others; at Google scale you could save a lot of lives this way.

<comment><USER17> frankly, I wish there were a lot more settings to optimize for in google maps. I actually prefer to stay _off_ the highway for short trips, even if it takes a little longer. it feels super wasteful to accelerate up to 60+ mph to merge safely, then slam on the brakes one or two exits later. similarly, google will often send me through complicated (and therefore dangerous, imo) intersections which could be avoided completely with a couple extra turns. sometimes I'm not in any real hurry to get somewhere; it would be nice to have a "scenic route" option for these cases.

unfortunately, I suspect the simplicity is more a deliberate design choice rather than mere laziness. I'm not holding my breath for these features, but I hope that one day a viable competitor may emerge to offer navigation for power users.

<comment><USER18> > similarly, google will often send me through complicated (and therefore > dangerous, imo) intersections

Reminds me of another Google Maps story. Was picking up something second hand, so was driving somewhere unfamiliar. I followed Google Maps, and the route seemed reasonable.

Then I hit the residential area where my destination was. Google Maps told me to drive up this really narrow road to get onto another road. Looked really weird, but I couldn't see any other choice besides a long detour so I carefully drove up that road.

At my destination, I told the woman I was buying from about Google Maps and that narrow road. "So _that's_ why all those people are driving on that pedestrian road" she exclaimed.

Apparently I was not the first...

</comment></comment></comment><comment><USER19> Noise pollution is the worst because of how ubiquitous it is. The stuff that really bothers me is in the <120hz range. Very hard to filter it out. Everyone is an interloper to some extent and some of the noise travels for miles.

Best option for me at this point is to just move further into the country and pray I can find internet. Hopefully Starlink or something similar will eventually unshackle me from the urban center.

</comment><comment><USER20> This reminds me of the recently-posted Trail Router[0] for jogging mapping.

[0][https://news.ycombinator.com/item?id=23802317](https://news.ycombinator.com/item?id=23802317)

</comment><comment><USER21> Very cool. I would totally use that if it was available in an easy app for my city. Hopefully that research migrates quickly to the industry.

</comment><comment><USER22> Sorry if off-topic, but this community may be able to help with a long-term problem.

I live in Manhattan across the street from a firehouse. Every day they test their devices to get through locked doors that are basically chain saws. Imagine someone testing a couple chain saws every day at a random time between 9am and 7pm.

I've spoken to them to find out why daily ("It would be a shame if we showed up to a fire and found out it didn't work then."), politely pointing out that after testing it, they don't know if it works since that test may have broken it. They don't know why daily either.

Anyone have any ideas on how to optimize the testing schedule for an engine? I'd love data relating testing frequency with safety.

<comment><USER23> This is where the manufacturing monitoring guys know _a lot of stuff_. Maybe statistical process control can help, maybe some other type of fault modeling is more appropriate.

Whichever way, rest assured the manufacturing industry has studied this over Styx and back. Look up what they found out!

</comment></comment><comment><USER24> I'll be adding my observances of my commute to OpenStreetMap shortly. Thank you!

</comment><comment><USER25> This is nice but it would be better if people could enjoy their neighborhoods without having to think about noise and pollution.

</comment><comment><USER26> This is awesome. We need more human centered navigation strategies. What I've always wanted in car navigation are:

\- navigate via the least busy paths, even if it takes longer

\- navigate via the least risky paths, for e.g. avoid right turns (in LHD countries) or left turns in RHD countries. Avoid u-turns.

<comment><USER27> UPS already has a nav system that avoids right turns when possible - <USER2> they could license their routing.

</comment></comment><comment><USER28> It's probably not possible but it ought to take terrain topology and trees in to account. New motorways are usually built with earth banks topped with trees to stop noise pollution. Its very effective.

</comment><comment><USER29> I'll be a bit contrarian and say that I actually do enjoy the sounds of traffic, but only some sounds. Most late-model cars emit what I'd consider noise, but the low burbling of big V8s or the bassy notes of big trucks are music to my ears. Maybe it's just nostalgia...</comment>


Finally, Machine Learning Without Writing Code - <AUTHOR> http://product.serialmetrics.com/orion/

<comment><USER2> Reminds me of MS's azure ML offering, among others. I would be loath to use a black-box service to plug and play like this, as I think understanding the right models to build and the outcomes you want to get are crucial parts of using data science well.

However, I can see this being useful for certain folks who want to get some initial integrations done, with a clear upsell to the customization and hard stuff. I think you'd need to rework this page to be a lot more about product applications and walk-through examples - as it stands, to a non-data person it reads "blah blah data model blah automatically blah optimization blah machine learning", when it would be more powerful reading "add product recommendations to your site in 5 minutes".

</comment><comment><USER3> Guys fix your form you are showing to fields that are supposed to be hidden

<comment><USER4> Has this been fixed since you posted this? I'm not sure which fields you are referring to.</comment></comment>


Show HN: We've been working on this idea, would love feedback - <AUTHOR> http://userealtalk.com/ <comment><USER2> Here's my take. I grew up in my parent's brick-and-mortar retail business: a four-store bicycle shop that's one of the largest and busiest in the nation. We were an early pioneer on the Internet, one of the very first to sell bicycle parts online back in 1995. These days, they don't do much e-commerce but brick-and-mortar business has grown a lot and the management is still tech-savvy.

Here are the problems that I see:

1\. Employees are busy. In the bike shop, you're constantly running around, helping this customer and that customer, answering the phone, taking in a repair, doing a demo, etc. It's going to be very hard to get someone on a computer or iPad to do live chat. If an employee is typing on a computer within sight of a customer, the customer will assume that they aren't busy and will interrupt them with a question. The problem is so bad that when my father would go out onto the sales floor to fix a computer, he would put on a fake badge that said something like "DataTech Computer Repair Services" so customers wouldn't think he was a shop employee and interrupt him. Perhaps a speech-to-text interface might work but how is that better than a simple phone call?

2\. Non-technical employees (most brick-and-mortar employees) are slow, inaccurate typists. Back when my parent's store was heavy into e-commerce, we quickly found that we needed dedicated guys to take online orders over the phone because most of our guys couldn't touch-type. If your interface requires a lot of typing, the employees and the customers using it aren't going to be happy.

<comment><USER3>
      answering the phone

That's what this is.

<comment><USER2> Not according to the video demo on their landing page right now.

<comment><USER3> The video demo is fine. Text is phone these days and answering a text is exactly the same as answering a phone call asking for more info. A 20 yo retail associate at American Apparel will take to this and figure this out in an hour.

<comment><USER2> I understand where you're going with this now. Employees tap out responses on their smartphones. Put yourself in the shoes of a customer now: you walk in and see an employee looking down at their phone and tapping away. Most people won't assume that they're conversing with a customer. The phone conversation doesn't have the same "hey, I'm busy with another customer right now" effect that an audible phone or in-person conversation has. Customers will assume the worst: that they're being ignored for the sake of some employee's personal texting.

<comment><USER3> Floor staff are trained to be proactive rather than reactive. When the customer has already voiced their intent and it doesn't necessitate more interaction you can switch to another channel queue.

Obviously if that's not the dynamic of your shop then this isn't the right tool.

</comment></comment></comment></comment></comment></comment><comment><USER4> I don't think anyone has mentioned this: in my mind, the whole point of calling a business is getting an _immediate_ response.

Most of us are conditioned to treat text as a fundamentally asynchronous medium. Texts aren't something you have to reply to _now_ \-- you should get to them eventually, but they don't demand attention in that moment. Much like email, the sender really has no idea when, if ever, the receiver will respond.

Phone calls are different in that they're totally synchronous. The receiver responds immediately, and you're not left in the dark wondering if they're busy. Even if you're put on hold, someone usually answers the phone first to let you know they'll be with you soon.

Phone calls are comforting -- you know for certain that you've been heard, and you get your answer right away. I can't think of a way for text to provide this, but I'd love to be proven wrong.

<comment><USER5> How old are you? I am 32 and I agree, but my younger siblings consider a text to be similar to a phone call that demands an immediate response.

I you aren't in a hurry you send a similar message over email.

<comment><USER4> 17\. At least in my social circles, it's polite to respond to texts (and Facebook messages) within a couple hours. Texting definitely carries more expectations than email (for example, I'd consider it rude to text back the next day, yet emailing in the morning is A-ok), but it's certainly not on the level of calls.

</comment></comment></comment><comment><USER6> A complaint about the site: I like to move my mouse near the section I'm reading, but it keeps fading out the part I'm trying to read.

Also, I still don't really understand what does this do? You only give me a form but no additional information.

<comment><AUTHOR> Thanks for the tip.

RealTalk will enable you to communicate with businesses on your smart phone. Picture a messaging layer on top of your old phone book, but in your hands.

<comment><USER7> That description is a big turn off. I don't need RealTalk to communicate with businesses on my smartphone. I already have a phone, email and web access on it. Maybe even a dedicated app for that business.

Why not just say "RealTalk lets businesses handle customer service via SMS"?

</comment></comment></comment><comment><USER5> While at work I regularly use the live chat on websites to get information, and I strongly prefer that over a voice call for a number of reasons[1].

The problem I have with the chats is that they usually lack the ability to escalate an issue. Even tech support chats have you communicate with a single rep for the life of the chat. _Will this app have the ability for the employees to transfer the thread to another employee?_

[1] I don't like talking on phones, loud calls distract my office mates, I can copy and paste detailed information, and the wait times are often shorter.

</comment><comment><USER8> Love your initial presentation. The business side console looks a ton more useful than [https://talktothemanager.com/](https://talktothemanager.com/).

Might need to find a way to mesh into existing Twitter back workflows for larger enterprise customers. These guys have spent a lot of dough building distributed Twitter workforces. Need to make it ultra facile for them to come over to your more intimate product.

<comment><AUTHOR> Thanks! Thats on the roadmap.

</comment></comment><comment><USER9> Hi I'm not sure if this is useful but here in China realtime chat function for buying stuff is commonplace. I heard a stat that something like 40% of all sales on Tmall are closed via chat - be it wechat or aliwangwang. In terms of location based and in app purchase they have moved fast too.

If you need to look at consumer behavior (which for many comments here seems to be a question) it might help to look at what they are doing.

</comment><comment><USER10> Very cool idea! I am not comfortable giving my phone number to anything that is not a non-corporate person, though. I can't see how you would need to have my phone number, so I'm ambiguous on how it would improve my experience. Everything you'd want to do with SMS could be done with push notifications, and it would be both faster, cheaper, and with higher fidelity.

<comment><AUTHOR> we won't need your phone number.

<comment><USER11> Wouldn't the fact that the customer sends an SMS from their phone mean that you now have their phone number? How are you going to respond to the request without having their phone number?

Or is it not using SMS after all? Not sure that's clear from the presentation. The tag line says "Find and text any business in your area." The term "text" is generally synonymous with SMS. If that's not what this is you may want to change the wording.

</comment></comment></comment><comment><USER12> Nice presentation and solid idea. Initially I don't see the advantage over just directly calling the business. Traditional land line phones are loud, and are quickly answered. A messaging app can easily be silenced. If the user wasn't exactly sure what he/she needed I think speaking to someone is much more efficient than describing via a message.

<comment><USER13> Biggest advantage is that phone calls are traditionally inaccurate. Names are spelled incorrectly and completely wrong requests are performed often.

<comment><AUTHOR> ^ Agreed

</comment></comment></comment><comment><USER14> Kind of like [https://www.intercom.io/](https://www.intercom.io/) but for real life?

</comment><comment><USER15> I see great potential for this with small businesses, I understood from the comments that employees can answer customers using smart phones - which is great, but you need to highlight that value in your presentation, the computer-only screenshot is a bit turn-off. The video is great but it should be skippable in my opinion.

</comment><comment><USER16> I attempted to create a similar service a few years back, but my concept was more targeted at users searching for local products and services, and not targeting a specific business. We would submit the user request to all matching local businesses. Maybe something to also consider, best of luck.

</comment><comment><USER17> I'd pay good money for a Whatsapp number that I could use for my business and feed directly into our inbox/CRM tool/whatever; when given the choice our clients seem to overwhelmingly prefer Whatsapp messaging over any other contact method.

I'd write it myself if I had the time.

<comment><USER18> What kind of business do you have? Are you clients mostly under 30-35?

<comment><USER17> Yeah. I'm running a small accommodation/guesthouse business in Hong Kong and our demographic is 18-35 expats, mostly European. First contact method is 10% voice / 20% on SMS / 70% on Whatsapp.

<comment><USER18> Interesting. That's quite a ratio in favor of WhatsApp. We looked into building a WhatsApp hook via OwnerListens but since it's not that popular in the US (where most of our current customers are) we couldn't justify the resources. We'll revisit as we expand internationally. How much would you be willing to pay for such a service.

</comment></comment></comment></comment><comment><USER19> Interesting idea. Any real customers yet? I am still not sure how would it work for me as a customer? Would I download an app and then communicate with the businesses? If so, why can't I just tweet to them?

</comment><comment><USER20> Cool concept. My main hesitation around using this product would be companies signing me up for coupons/spam via text messages. I can't imagine how annoying it would be to filter out text message spam...

<comment><AUTHOR> They wont have access to your phone number. And only consumers can initiate a message. Filters will be built in.

</comment></comment><comment><USER21> It is a good idea. you may want to better understand why customers may contact a business and make the messaging experience much smoother for instance by having sample text message ready to be used by users.

</comment><comment><USER22> I don't see the business side of this being super interesting, but the consumer side is awesome.

An app where I can make any request to a business, through my phone, and you sort out the details? That's awesome.

<comment><AUTHOR> Doesn't sound like you own a business who does lots of customer service/ inbound sales inquiries/ requests from consumers?

<comment><USER22> I think they are two different problems. Either you're helping my business respond to customer requests more efficiently, or your making it dead simple for me to ask questions/order/talk to a business.

</comment></comment></comment><comment><USER23> We use LiveChat[0], which even looks like that.

People go to the site, open live chat, ask questions and get real answers immediately.

[0] [http://www.livechatinc.com/](http://www.livechatinc.com/)

<comment><USER13> If I understand correctly, this is livechat's model:

I need to ask if the Levi's store at Kanata has a Midnight black 514. To do so, I have to download Levi's app first, use the chat option (that integrates with live chat) and chat from there. The problem is I don't know when I will use the Levi's app again, maybe once more this year? I don't want an useless app to clog my phone.

Here's the RealTalk scenario:

I only have one app "RealTalk" that connects me to Levi's for jeans, Diesel for my shirts and J. crew for my sneakers.

<comment><USER23> Actually, it's not on the Levi app, it would be on the levi website. Where most people are already at if they have questions about the brand.

</comment></comment></comment><comment><USER24> Sounds a lot like ownerlistens.com Same consumer facing SMS functionality (masks your number) or an app if you want to avoid fees Backend more fully featured + has an API and supports iBeacons

</comment><comment><USER25> What percentage of businesses have someone available to answer text messages? My feeling is the answer starts with 0.0 and then may have some more zeros before a non-zero digit occurs.

<comment><USER26> What percentage of businesses have someone available to answer the telephone? This seems more convenient than that.

But it also seems like twitter.

<comment><AUTHOR> How do you message a business that doesn't follow you privately?

<comment><USER26> #businessname blah blah blah message blah

</comment></comment></comment></comment><comment><USER27> Love the presentation and as someone who prefers communications over text messages over a phone call, this has real potential if you can get businesses to respond in a timely manner.

</comment><comment><USER28> How does the user find the business?

This seems like something that can be done with a facebook personal message or something.

<comment><AUTHOR> We aggregate business data similar to Foursquare.

Not many businesses are sitting behind their facebook pages to use it as a communication channel for customer service/ sales inquires/ etc.

<comment><USER29> Not many brick and mortar businesses are sitting behind the computer either. What market is this a burning problem for?

<comment><AUTHOR> Most business owners have smart phones & so do their employees.

</comment></comment></comment></comment><comment><USER30> How is this different than TalkTo? What is the business model here?

<comment><AUTHOR> TalkTo did not integrate with third party services.

<comment><USER31> To the consumer, this functions pretty damn close to TalkTo.

My question is: how many times do you actually call a business to find out about inventory, etc.

I remember doing this in the early 2000's, but in the age of Amazon and transparent inventory on sites like Apple, it's a very rare use case.

From a business perspective, I love the idea of providing better customer service, and if this is a feature that customers actually want, then maybe it will work.

Onboarding businesses will be a huge pain in the ass. But you probably know that already :)

</comment></comment></comment><comment><USER32> Do you guys have an API?

<comment><AUTHOR> We will yes.</comment></comment>


Incremental Compilation - <AUTHOR> http://blog.rust-lang.org/2016/09/08/incremental.html <comment><USER3> Off topic — I am surprised to find this statement [1] in the blog post considering how negative were my teachers in university with the "trial and error" approach of solving a problem. They always said that you should design a solution before the implementation, and I agree that it makes sense but there are cases where you need to put a print and exit to debug something; and if you think about it, that is what a debugger does.

Nowadays — and if you are doing interviews will understand — people expect you to write flawless code from scratch using a basic code editor (looking at you HackerRank) with no time for tests. Sixty minutes to write a solution for four challenges, without autocomplete, without tests. Even the genius co-worker that comes with an optimized solution for every problem would need more than fifteen minutes to solve those crazy/random challenges that at the end will measure your ability to resolve _those_ specific questions but not problem solving skills in general.

So is trial-and-error bad or not?

[1] Much of a programmer's time is spent in an edit-compile-debug workflow.

<comment><USER4> Designing a solution is still far from having code that works. You have designed a solution, and now you need to test it. In significantly complicated codebases, there are often all kinds of obscure issues that can crop up and make your (manual or automated) testing fail. These are not things you can think of beforehand in your design because it is not possible for you to have known about all of these issues.

In fact, later in your comment you allude to this yourself -- "with no time for tests". You're worried about interviews not having time for tests. But tests _are_ a edit-compile-debug feedback loop. If a test fails, you need to debug it, fix the issue, and recompile. Often you have to do this many times. This is precisely what the blog post is talking about.

You're generalizing the term "trial and error" to mean something more than what your teachers probably meant.

(I do agree that those interview practices are silly. But the blog post is not talking about stuff like that.)

</comment></comment><comment><USER5> Nice to see it. Incremental compilation is one of those things that production compilers have but research languages usually don't have. You only need it when you have a lot of code, but then you really need it.

<comment><USER6> Production compilers often don't have it either.

(Having to split up your code manually into separate .cpp [or what have you] files doesn't qualify as incremental compilation—that's just separate compilation. Incremental compilation is when the compiler automatically figures out what needs to be recompiled, even when all you hand it is a big blob of code that hasn't been manually split up by a human in any way.)

<comment><USER7> The Delphi compiler has incremental compilation, but by your definition it wouldn't.

Delphi uses the source to figure out dependencies. That is, the compiler has make logic, and traces through the 'uses' declarations to recursively discover all the source and object files. It compares timestamps to discover which object files are out of date and need to be recompiled. Thus, if you touch a single file and do a compile, only a couple of files will be compiled - <USER2> main program source and the modified file. This dependency logic is in the compiler, not a separate make program.

If this isn't the compiler doing incremental compilation, I think we have a terminology problem. Because this is what is meant by incremental compilation as the term is applied to almost all production compilers, and if you persist in making a distinction, you may be confusing more than clarifying. ISTM that you're memoizing more parts of the compilation process than has historically been done in incremental compilers. It may be clearer to use a more qualified phrase to express this, rather than shift the generally accepted meaning of a term.

<comment><USER4> I don't see where in pcwalton's comment he alludes that the Delphi compiler's definition of incremental compilation doesn't match his own.

He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled".

(He does say that production compilers don't have incremental compilation, but that's not a matter of definition, and I read that to mean "usually don't")

<comment><USER8> > _He explicitly says "Incremental compilation is when the compiler > automatically figures out what needs to be recompiled"._

He also says that merely using the separate files to deduce this (which the parent says is what Delphi does) is not incremental compilation.

<comment><USER4> It doesn't "merely use the separate files", it traverses the use statements.

There's no manual splitting of .cpp and .h files. No manual management of dependencies.

<comment><USER7> Rust is going down the path where recompilation is done on a finer granularity than files. I was objecting to setting that as _the_ bar to meet for incremental compilation. It's technically impressive, but it will only be a win if the average compilation unit takes a noticeable amount of time to compile (this was rarely the case with Delphi). It may well be the case for Rust+LLVM.

<comment><USER4> Fair. I think Delphi counts, and I don't think that was the bar being set (but it's easy to see how it could be read that way). The C++ header file model is quite different in the amount of burden placed on the programmer over the Delphi use-statement model.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Does anyone know if there has been any work in formalizing incremental compilation? It would be great to have some sort of theoretical framework to use as a guide when implementing various incremental compilation strategies.

There is some (ongoing?) work on low-cost incremental computation by differentiating lambda calculi [1] [2] [3], and it seems like an incremental compiler could maybe be a good use case for it.

[1] [http://www.informatik.uni- marburg.de/~pgiarrusso/ILC/](http://www.informatik.uni- marburg.de/~pgiarrusso/ILC/)

[2] [http://bentnib.org/posts/2015-04-23-incremental-lambda- calcu...](http://bentnib.org/posts/2015-04-23-incremental-lambda-calculus-and- parametricity.html)

[3] [http://ps.informatik.uni- tuebingen.de/research/ilc/](http://ps.informatik.uni- tuebingen.de/research/ilc/)

</comment><comment><USER10> Great blog post ! One thing I wonder as a compiler head though is, what is the granularity of this stuff ? Is it per-file or per-function, or even per block ? If it's finer than per file, how do you do the tree diff ? Do you parse whole files and then do a node-by-node diff ? Do you have an incremental parser ?

If I was to implement incremental compilation, I'd start with per-module I guess, because it's the atomic unit for a compiler, so it would be a lot simpler. That's why I'm curious.

<comment><USER11> I can actually help you out on this one. I spent the summer hacking on the Rust compiler for my internship. If I'm understanding the code correctly, this is the enum of elements represented in the dependency graph.

[https://manishearth.github.io/rust-internals- docs/rustc/dep_...](https://manishearth.github.io/rust-internals- docs/rustc/dep_graph/enum.DepNode.html)

Note that as per:

[https://manishearth.github.io/rust-internals- docs/rustc/dep_...](https://manishearth.github.io/rust-internals- docs/rustc/dep_graph/struct.DepGraph.html)

The DepGraph that we actually care about is specialized to talk about DefIds. In rustc, DefIds are attached to the following things:

[https://manishearth.github.io/rust-internals- docs/rustc/hir/...](https://manishearth.github.io/rust-internals- docs/rustc/hir/def/enum.Def.html)

This means dependencies are analyzed down to local variables and uses. But even beyond that it tracks things such as borrow checks, linting and more!

</comment></comment><comment><USER12> From an uninformed distance this looks a bit underwhelming: initial builds are slower, incremental builds are not _that_ much faster, and build outputs are no longer deterministic functions of just the build inputs (which is useful for example for distributed build systems).

<comment><USER13> The way Rust works today is that you compile a whole crate together (all the files). The side effect of that is that the compiler can optimize the whole create vs what's in one file. You get an effect that analogous to LTO (like in C/C++). Conversely, if you now go to incremental builds the opportunity for LTO style optimizations. Thus you end up with a worse runtime performance in incremental compilation.

Caveats and fine details missing all over the place. More focused on the general point.

<comment><USER14> > Thus you end up with a worse runtime performance in incremental compilation.

Are you sure about this (in the current implementation)?

<comment><USER13> The article it self says "[...] This is because incremental compilation splits the code into smaller optimization units than a regular compilation session, resulting in less time optimizing, but also in less efficient runtime code."

<comment><USER14> Thanks, you're right. I missed that.

</comment></comment></comment></comment></comment><comment><USER15> Since rust compiles to native machine code (bytes), how does it calculate the starting address of the code? for example, If there is a JMP instruction, JMP takes an address as an operand most likely -- Doesn't the kernel determine the starting address, or is the starting address the address returned by mmap?

<comment><USER16> Modern amd64 code is position-independent, so the JMP address is relative.

On other architectures, it's the linker's job to convert symbolic addresses and it can choose all the addresses in one go as it's the final stage producting the executable.

<comment><USER15> Relative to what, the start address? Does rust determine the start address from the return value of `mmap`?

<comment><USER16> Relative to the current instruction pointer aka program counter. You say things like "JMP -100 bytes".

</comment></comment></comment></comment><comment><USER17> How does this differ from what make files have been doing for decades?

<comment><USER6> You don't have to split up your code manually. You just write one Rust crate, splitting your code into files on whatever granularity you like (with mutual recursion fully supported), and the Rust compiler automatically does the rest. You don't have to write tedious header files; the compiler figures out all the dependencies automatically.

<comment><USER17> I don't split up my code manually for the compiler, I do it for the humans, being compiler friendly is just a pleasant side effect. You can build java files the same way without header files, worst case scenario is you have some fat compilation units.

<comment><USER6> > I don't split up my code manually for the compiler, I do it for the humans, > being compiler friendly is just a pleasant side effect.

There is no human benefit to having to copy and paste function signatures—and worse, the bodies of functions you want to be inlined, including all templates—into header files. There's also no benefit to having the compiler parse hundreds of KB of header files over and over and over again.

> You can build java files the same way without header files, worst case > scenario is you have some fat compilation units.

Java (production implementations used in practice) performs whole program optimization via its JIT. It's nice for Java, but that isn't how Rust works.

<comment><USER17> I don't disagree on the header files, no sane language designed today would include that.

> Java (production implementations used in practice) performs whole program > optimization via its JIT. It's nice for Java, but that isn't how Rust works.

Whole program optimization isn't generally something you want on dev builds, which is where incremental compilation is useful. For a production build why wouldn't you do a full rebuild anyway?

<comment><USER6> > Whole program optimization isn't generally something you want on dev builds, > which is where incremental compilation is useful.

By "whole program optimization" I also include things like generic/template instantiation. Whenever you use, say, a HashMap, you have to recompile the implementation of the HashMap specialized to the size, alignment, destructor, etc. of types you're using with it.

> For a production build why wouldn't you do a full rebuild anyway?

When I profile apps written in Rust, it's important for me to be able to get good turnaround time on optimized builds.

<comment><USER18> Do Java generics work like that? I thought the JVM did not know about the generics as the types are erased at compile time.

<comment><USER19> JVM doesn't know about generic types at the runtime. There's no specialization of HashMaps, it's just arrays of points to objects all around.

With project Valhalla: [https://en.wikipedia.org/wiki/Project_Valhalla_(Java_languag...](https://en.wikipedia.org/wiki/Project_Valhalla_\(Java_language\)) there's been talk about specialization for value types.

<comment><USER20> It is already available for those that want to play with it.

[https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting- starte...](https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started- kit/content/en/openjdk-projects/valhalla.html)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Up to 15% faster or more?! =)

<comment><USER22> There's still a bunch of compiler phases they're not caching yet, so it's a very very early result.

<comment><USER23> If you click on the asterisk next to that heading, you'll see that the 15% figure is a joke reference to an XKCD. :P In practice, it wouldn't make sense for us to say "incremental compilation makes us X% faster" because the benefit will vary wildly by workload.</comment></comment></comment>


SpaceX Test Flight Detonated Over Texas Town - <AUTHOR> http://www.nbcnews.com/science/space/spacex-test-flight-detonated-over-texas-town-n186436 <comment><USER2> SpaceX official statement: [https://twitter.com/SpaceX/status/502976401729798144](https://twitter.com/SpaceX/status/502976401729798144)

</comment><comment><USER2> KWTX has some videos: [http://www.kwtx.com/home/headlines/Rocket-Explodes-at- Space-...](http://www.kwtx.com/home/headlines/Rocket-Explodes-at- Space-X-272370541.html)

</comment><comment><USER3> There's a picture and video in the Business Insider article: [http://www.businessinsider.com/spacex- explode-2014-8](http://www.businessinsider.com/spacex-explode-2014-8)

</comment><comment><USER4> Best of luck getting this program back on track.

</comment><comment><USER5> um. just wondering. they have to test for failure conditions too, yes?</comment>


Are You Using iTerm2? - oscar-the-horse http://www.horsesaysinternet.com/command-line/are-you-using-iterm2/ <comment><AUTHOR> I used to use iTerm2 (or maybe it was still iTerm then), but eventually Terminal was just good enough. I think people who have used iTerm2 for a while might forget that Terminal improves with every new version of OS X; it's not just some stagnant app that Apple ignores.

For example, Terminal on Lion includes 256 color mode and split panes. And it actually has cool features like restoring the scrollback buffers in each tab you had open if you quit or restart.

So yeah, I consider Terminal good enough these days.

<comment><USER2> > And it actually has cool features like restoring the scrollback buffers in > each tab you had open if you quit or restart.

Yeah that is an amazing feature and almost has me switching back. I can only hope they add that to iTerm2--it seems such an obvious good thing.

</comment></comment><comment><USER3> Note that my own terminal MacTerm (<http://www.macterm.net/>) also supports most of the iTerm2 features from this post. Though I feel my Full Screen support is nicer: I provide options such as a scroll bar when full-screen, and I do _not_ use Lion's widget so the switch is instantaneous and has proper multi-display support (i.e. you can have a full-screen terminal on two displays if you want to).

I don't have split-panes, though they're on my list. There are a handful of other features I don't have, but also vice-versa. In the end I won't say either app is better, but I definitely think there isn't one terminal everyone will like.

<comment><USER4> Split panes are cool, but the killer feature that I would jump ship for is full screen mode for dual monitors on Lion.

<comment><USER5> Out of curiosity, why do you need a terminal that spans two monitors?

<comment><USER4> One full-screen terminal per monitor. When you enter full-screen mode with iTerm, the second monitor shows the linen background.

<comment><USER3> That behavior is enforced by Lion itself, and that is one reason why I don't support Lion's mechanism (another being that the transition animation is way too slow). I've reported these problems as bugs to Apple long ago, and I have seen no action. I decided it was more important for Full Screen to be _right_ than it was to adhere to some fancy but broken standard approach.

</comment></comment></comment></comment></comment><comment><USER6> Plus, iTerm 2 segfaults! All the time and for no clear reason! And the performance is far, far worse than Terminal.app!

<comment><USER7> Sorry to hear that. Not that it diminishes your experience at all, but I've been using iTerm2 daily for a couple of years without any trouble like this.

I had to try to diagnose a glitchy Mac once where some funky fonts installed by MS Office ended up being the cause for crashing various programs. Any chance that could be what's going on for you?

</comment></comment><comment><USER8> I use TotalTerminal (<http://totalterminal.binaryage.com/>) and have it set up to show up on the bottom 1/3 of my screen with a transparent background when I hit the "Eject" key that I never use for anything else. As far as I can tell, I also have colors and split panes, though I rarely use them.

</comment><comment><USER9> First off, both iTerm and TotalTerminal were very useful and fairly well done.

On Mac OSX Lion though, Terminal.app supports 256 colors and split pane (although only vertical stacks). I don't know what use growl gives me, but having to update it was annoying.

What I do miss from TT and iTerm is the visor mode bound to a shortcut key. Both had downsides though: TT would mess up copy and paste, iTerm would just crash sometimes, you couldn't have the visor down while typing something on another screen. All in all I decided it wasn't worth the trouble to reinstall either when I switched to Lion.

<comment> oscar-the-horse on growl you can turn updates off. they are really annoying: they continue to pop up even if you close out the notification, that gets even more annoying.

</comment></comment><comment><USER10> iTerm2 is a fantastic Application. I did not experience any slowdowns, segfaults or anything, and i am a heavy user.

I refuse to update to Lion, so i cant judge the new Terminal from Apple. But on Snow leopard, Terminal is inferior to iTerm2.

</comment><comment><USER11> Yes, I've been using it for over a year now. And it has been quite stable.

Its killer feature for me is command+N to go to that tab.

I've never understood why Apple has not implemented commnad+N in Terminal.app

</comment><comment><USER12> I have been using iTerm 2 full time for many months. Super stable. The full screen mode with panes is wonderful. George Nachman has done a wonderful job and is very responsive with any problems.

</comment><comment><USER5> I don't get it. OSX users didn't have screen? Or the ability to full screen a window?

</comment><comment><USER13> Yes. I am.</comment>


Tutorial on Good Lisp Programming Style (1993) [pdf] - <AUTHOR> https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf <comment><AUTHOR> This guide is great; most of it is just as applicable to programming in general as it is to Lisp. One thing that stands out to me as a good way of phrasing something is "Documentation strings are better than comments." Even in something like Java with Javadoc instead of docstrings, the same advice applies: in properly factored code, most explanations should be tagged onto a function or variable in a standard way like that to explain its purpose; if you have to explain something inline, not as an interface but only to people reading that section of code, it's a sign that maybe you haven't factored your code enough. Like the quote it provides from Kernighan and Plauger says: Don't comment bad code--rewrite it.

Another line I like: Documentation should be organized around tasks the user needs to do, not around what your program happens to provide. Adding documentation strings to each function usually doesn't tell the reader how to use your program, but hints in the right place can be very effective.</comment>


Dev.to is a good demonstration of how content-based web apps should be developed - <AUTHOR> https://dev.to/bigi/dev-to-is-the-perfect-demonstration-of-how-content-based-web-apps-should-be-developed-5fa4 <comment><USER2> I found dev.to hard to read. Something about the combination of color choices, font sizes, and page layout makes it feel too busy to me. It's not impossible, it's simply a little difficult on the eyes.

</comment><comment><AUTHOR> OP note: The original article title was modified as this post's title because it was a few characters too long.

</comment><comment><USER3> technical blog platform with tumblr vibes? i'm sold. no joke.</comment>


A London coworker sharing her insights on the benefits of coworking - <AUTHOR> https://medium.com/coworking-people-spaces/meet-tobi-a-london-coworker-sharing-her-insights-on-the-benefits-of-coworking-a217cdff56e0#.olmn7ny2h <comment><AUTHOR> Best!

What would be your best coworker tip? Be an actual co-worker. Don't act like you are alone.</comment>


Anti-Fragility - <AUTHOR> http://curiouslypersistent.wordpress.com/2011/12/04/nassim-nicholas-taleb-and-antifragility/ I thought some of you might be interested in this, It's an enjoyable read. I hear echoes of many PG articles throughout.<p>http://www.randomhouse.com/book/176227/antifragile-things-that-gain-from-disorder-by-nassim-nicholas-taleb <comment><AUTHOR> I thought some of you might be interested in this. It's a good read and there are echoes of many PG articles throughout.

[http://www.randomhouse.com/book/176227/antifragile-things- th...](http://www.randomhouse.com/book/176227/antifragile-things-that-gain- from-disorder-by-nassim-nicholas-taleb)

</comment><comment><USER2> There's also a fantastic interview with Taleb that I posted a few months ago. <http://news.ycombinator.com/item?id=3631472></comment>


Should HotorNot Become Just a Facebook App? - <AUTHOR> http://www.techcrunch.com/2007/10/16/should-hotornot-become-just-a-facebook-app/ Ever since HotorNot abandoned it's experiment with going totally free  last month, the traffic to its destination site, HotorNot.com, has predictably leveled off. Meanwhile, its application on Facebook is doing pretty well, already accounting for about a third of its daily logins, and 40 percent of it total unique visitors (although the two remain separate services at this point). <comment><USER2> Arrington's argument is no. I tend to agree with him. The best part of the article is when starts comparing it to a mall, and it oddly works...

"Hong is better off sticking HotorNot in the mall than trying to get people to come to his standalone site... the social network landlord could one day create its own... like a mall owner opening his own clothing store to compete with the Gap, greeting people at the door with flyers as they enter the mall, and charging his store below-market rent... Then, of course, there's the fact that malls tend to lose their foot traffic as soon as a newer one opens up down the road."

I would add that the whole real estate analogy has been used quite a lot in technology. The only difference is that no matter if you create a super- regional shopping malls (Mills), the great power of the internet is that people can leave your place lightning fast.

</comment><comment><USER3> No.</comment>


Ask HN: What are some hacker-approved home gadgets? - <AUTHOR>

Just bought a house, live alone, want to nerdify almost anything.  Looking for hacker-approved, high quality appliances, gadgets, cleaners, tools, lighting, walls?, etc.
Thanks
PS. I already have a Nest and yes, it's remarkable. <comment> dr-how-to Grow your own food. Spend $2000 on a quality chipper/shredder to make compost for your garden. You'll have it for 25 years and use it every weekend, if you have any landscaping, at all. Talk about hacking. It's a great investment, young man. Dr-How-To</comment>