The Best Antivirus for 2012 - <AUTHOR> http://www.pcmag.com/article2/0,2817,2372364,00.asp#fbid=-TEbYGCRFlt

<comment><USER2> there's just sooooo much anti virus available out in the market lately that consumers are getting confused as to which is better for what and how are they different.

this article was very useful to compare the ones already out in the market, but then again, it still lacks the information as to which viruses are these anti-viruses are for.</comment>


A React environment for cross platform native desktop apps - <AUTHOR> https://github.com/kusti8/proton-native <comment><AUTHOR> For lazy folks, this uses libui underhood to render to native components via a React API.

[1]: [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

<comment><USER2> I'm guessing you know something I don't, because the specified dependency is actually to a forked copy of parro-it/libui.

Does parro-it/libui derive from andlabs/libui?</comment></comment>


Look for the duct tape - <AUTHOR> http://rachelbythebay.com/w/2018/03/23/ducttape/ <comment><USER2> For non-programmers, usually the duct tape is a spreadsheet. I have seen people who invent a CRM on a spreadsheet while not knowing what CRM means.

Looking for a SaaS idea? Ask random people in a target industry what kinds of things they do with Excel.

<comment><USER3> You don't need a domain-specific tool for every problem your business has. If a spreadsheet works, great. If it ain't broke, don't fix it.

In a similar vein, there are plenty of small software teams that use nothing more than a whiteboard for project management. Yet there are teams tooled up with Jira/Trello/Slack with much less productivity.

<comment><USER4> I have to argue against this, because spreadsheets are a real pet peeve of mine. It can be hard sometimes to see _why_ a spreadsheet is broken. Spreadsheets simply don't scale (and I don't mean lolwebscale or whatever.)

If two business processes interact through a spreadsheet, or more than two people edit, you're going to immediately run up against the rough edges. Multiple people editing the same sheet inevitably ends in error. It can take a really gross amount of time to update the data when you're pulling/pushing from two sources. It may seem small on the surface, but even 2 hours a week adds up to nearly 3 weeks of work over a year. Can you replace this spreadsheet in 3 weeks?

I've seen this play out many times at large and small scale. The first example that comes to mind is a 10-hour day trip my wife took to go out of town and manually update a whiteboard because somebody messed up the shared spreadsheet. She was very unhappy, and this wasted a precious day during a _very_ busy period. Initially, the whiteboard and spreadsheet worked great, so they didn't "fix" it. It didn't scale to the busy times and really screwed them over.

At a much smaller scale, I wrote a quick SQL query to get some business metrics for the CEO. He asked if I could run it for him every week. Since I didn't have a good place to put this query, I just ran it manually and emailed it to him at first. Then he wanted to share it with someone on the opposite coast outside our network, so he asked if I could start putting it in a shared spreadsheet. My initial thought was to bang out a page they could pull up instead, but I figured it wasn't worth it. Then he wanted another metric. And another that required a bit of logic that couldn't be done in SQL. Pretty soon I was spending an hour a week manually running SQL and copying the results in to a spreadsheet. (We're a Google Drive shop. No way to connect Sheets to DB2.) That's simply not worth my time. I should've listened to my first instinct.

The initial investment in a spreadsheet isn't large, but the ongoing maintenance can really rack up hours. I think it's very often worth investigating any spreadsheet that users have been maintaining/recreating for more than a quarter.

<comment><USER5> > _We 're a Google Drive shop. No way to connect Sheets to DB2._

FWIW, Google has an API that can be used to get data into and out of things like Sheets. The documentation for it is abysmal and there are only a few libraries out there, most of which aren't complete. But, I've done it, and have some rough (but easy-to-understand) code that can "import" Sheets into MySQL. Going the other way should be a matter of tweaking the Google account permissions and calling a couple of different functions.

It's in PHP, but it's not gross PHP, so you can probably translate it into whatever you're familiar with.

<comment><USER6> Here's a freebie that I wrote in like 15 minutes and use in multiple prod situations. Treat any Google Sheet like a JSON data source. [https://gist.github.com/chrsstrm/3fb0ce6820acecf62c5490d220d...](https://gist.github.com/chrsstrm/3fb0ce6820acecf62c5490d220d4ec5f)

Yes, the App Script API is kind of limited, but also extremely powerful for simple services or to glue services together.

</comment></comment></comment></comment></comment><comment><USER7> This is an excellent tenet in general. A landscape designer at school was re- doing the engineering quad and there was a lot of debate about where to put foot paths, and the designer said, "We will put down grass everywhere, then after a year come back and see where the paths are, then we will add stones for the foot paths." It was pretty effective.

I think if you were a product designer you would do well to have users send you their customization files to extract things that were common to all of them to put into the product.

And of course Windows was pretty famous (infamous?) for taking what ever shareware thing people were giving out to make Windows work better and then incorporating it into the base OS. I read a review of Windows '95 that called it "Windows 3.1 with Norton Desktop pre-installed."

<comment><USER8> > _We will put down grass everywhere, then after a year come back and see > where the paths are, then we will add stones for the foot paths._

The old desire path that is based on user experience not design [1][2]. Never fight the desire path, it is a losing battle.

[1] [https://i.imgur.com/fAmGY2A.jpg](https://i.imgur.com/fAmGY2A.jpg)

[2] [https://www.reddit.com/r/DesirePath/](https://www.reddit.com/r/DesirePath/)

<comment><USER9> [https://www.imgur.com/r/desirepath](https://www.imgur.com/r/desirepath) (I used to work at Imgur...)

</comment></comment></comment><comment><USER10> As an engineer-turned-programmer/sysadmin, working with other engineers, I've built a career out of doing this. Unfortunately, as a person with only- marginally-better-emotional-quotient than other engineers, I've expected my solutions to be widely regarded, based purely on merit. After 25 years of this, I'm once again hitting roadblock after roadblock because I didn't "kiss the ring" of the people in charge.

I've made them look stupid by building something pretty good where they have been failing for 10 years with an entire team. Then I went and wrote another application in a strange new framework that had been invented in the past 15 years, and this startled and frightened them.

Don't be like me, kids. Play the political game. If you don't want your managers being told to dismantle the things you build, simply because you didn't kiss enough butt, learn how to raise your "EQ" and ensure the success of what you build. Otherwise, like me, you will have just written a bunch of stuff users loved, but management hated, and forced them to stop using.

It's too late for me; save yourselves.

<comment><USER11> I agree with this as I currently find myself in this very situation. I was a Unix admin for a decade and then found myself having to embrace Linux and then Windows Server to have a job. I've been a sysadmin for 20 years and one is who quite happy to work as a "coder" when needed.

I took a new job about a year ago, one that found me in a group of people who were struggling to do "simple" things, but doing them the "hard way". I came into this job, and because the core infrastructure is Windows Server, I learned PowerShell in about 6 months and started "solving" their problems by automating this and that. Things got easier, but the existing people thought me strange that I would resort to the "mere command line" for a solution rather than go about things using a GUI. My rule of thumb has always been "if I have to do it more than twice, script it."

These people have poo-pooed my every effort along the way and the boss has even called me out on it, despite me showing him that we are making strides where the team once did not. Sorry, I'm a command line guy at heart, and this will never change. I'm not a method man by any stretch. PowerShell is the orthodox way of handling Windows Server issues and that these people I work with don't want to embrace it is not going to slow me down.

We engage in useless meetings to have meetings. We talk about senseless things to jabber. I want to write scripts to automate certain tasks, but no. "What happens if you get hit by a bus, bro? No one knows how to code in PowerShell." My response to them was "I came here not knowing PowerShell, but I took the time to learn it and I'm productive in areas where you could be, too. I'll be happy to show you everything I've learned and coach you when you have time." They look at me like the proverbial deer in the headlights. I'm toying with leaving this year, as I want to work around like-minded, always-curious people, not people stuck in yesteryear.

<comment><USER12> When upper management see you are 10 times more effective, doing the same job as 10 other people, they might become interested. But if there's not enough job and you get paid for just sitting there, then use that free time to contribute on open source or something. Or maybe there's someone else there who has a pet project you can work on. If this is the case you should consider yourself lucky. At most jobs there's never a shortage of work. Eg. there are always more tasks that you can possible do and pressure from management that it needs to be done today, if not yesterday.

Also if you are that much more effective you could start your own business, hire people and train them, then have 10x bigger margins then your old employer.

<comment><USER11> Thank you for your comments. I have toyed with the idea for years of going into business for myself, but have no ideas. I'm a sysadmin who knows *nix, macOS, Linux, and Windows very well. I can only write in "scripting" languages, as my jobs all the years required only those. I never really branched out into Python (I can read it), or C++, etc.

I have no idea what to do, what to offer, etc. It's funny, because when I'm at work, I don't really have to think too hard about solving a task. I'm generally the "smooth over" guy who fixes the things other people don't really see as issues, but having been in IT for so long, I can see the problems in the distance for a given job, as I've encountered them before. Most people just fly by the seat of their pants, but I love doing things once and well.

<comment><USER12> Maybe you can be one of those solo entrepreneurs where everything is automated. Pick a niche that is very boring and are currently done by mundane manual work. For example accounting. Kick start by taking an existing product and sell the patchwork/scripts as a module/plugin. Maybe something like SAP. Don't quit your job until you are profitable though, and can just kill the project if it doesn't work out. It usually takes a few tries and a lot of learning until you figure out what works and what doesn't as an entrepreneur. eg. selling something people want (a faster horse) vs trying to sell something _you_ think they desperately need (a car). Eg. pick the low hanging fruit, and don't be tempted to solve the hard problems until you have enough resources.

</comment></comment></comment></comment></comment><comment><USER13> > What bugged me about the (X) environment when I was there? What would I > change?

I recently started as lead dev at a small company experiencing some real growing pains. The CEO wisely had me spend a couple days my first week going around talking to team leads. It was very productive.

I started with almost the exact same question Rachel suggests here. My version:

> What's currently frustrating you?

I deliberately left it open-ended and found many of the non-technical answers worth passing along to management. "Let the fools have their tartar sauce!":

[https://www.youtube.com/watch?v=X25rP4rTw3A](https://www.youtube.com/watch?v=X25rP4rTw3A)

The other question I came up after my first couple meetings. I called it the Magic Lamp question:

> If, as the magic genie of this company I could grant you three wishes, what > would they be?

By day two, these were the only questions I needed to ask. Following up with the CEO, we came away with a very clear vision of what our development priorities needed to be. Most of it aligned with what I already sensed coming in, but there were still some useful surprises for us both.

(And, yes, found a few clever spreadsheets functioning as de-facto business applications.)

<comment><USER14> That Simpsons clip leaves out the punch line, where Smithers attributes the decrease in the accident rate to the promotion of Homer.

<comment><USER13> True. I noticed that, too. And I think that lesson is as important as the "listen to your grunts" message: beware false metrics.

It's a dense passage to be sure.

</comment></comment></comment><comment><USER15> Moment of appreciation for the title of this post. This is a rather "sticky" way to share this idea (in the spirit of Made To Stick by Chip & Dan Heath). I get the gist of Rachel's idea without even needing to read the article.

</comment><comment><USER16> Really hard to read blog, because the context is often missing. But through reading a few articles it gets more clear.

(probably from another article than the one linked above)

> First thing, do not stick your neck out.

This advise always frustrates me. I know it's true, but feel it's really, really hard to implement.

a) What do you do if you don't get any direct command from your manager? If you then choose to do nothing you get the negative feedback that you didn't do enough. If you go left, you get the feedback that you should go right. If you go right, you get the feedback that you should go left. If you go straight, you get the feedback that you are too direct. With everything you do, there's automatically, intrinsically something you don't do, and that will be used as negative feedback.

b) I don't know about other people, but becoming more successful is really a necessity for me. If you always get negative feedback, how could you progress? So I start hinting at the left and when the negative feedback to go right is incoming I show that I actually moved right. You can believe me, I speak from expeirence, that's when the real shit starts to hit you. Suddenly you are not just a stupid employee, you are also disloyal and an intriguing schemer. You are dangerous and need to get rid off. So apparently that's sticking the neck out.

But then, what else to do? If (a) and (b) both is not acceptable, then what is (c)?

PS: Also this article. Feels so much like my current situation: [http://rachelbythebay.com/w/2012/01/09/rigor/](http://rachelbythebay.com/w/2012/01/09/rigor/)

<comment><USER17> First step is try to have an honest conversation with your manager. You cannot really win if your manager is your opponent. If you cannot have a positive relationship with your manager, you should look for a position elsewhere.

If your manager continues to be ambiguous and you haven't managed to leave, then I would try to go orthogonal. Achieve something unrelated. It is hard to blame someone who succeeds even if that success is unrelated to the main quest.

<comment><USER18> We had someone do that, then brag about it during end-of-the-year reviews. The managers were quite upset that the person had spent valuable time working on things that not only hadn't been assigned to them, but also hadn't been brought into the process for scheduling them or even brought to the attention of anyone else in IT.

So no, it's not hard to blame someone for working on the wrong things when they should have been working on something else.

</comment></comment></comment><comment><USER19> Absolutely nothing to do with the topic at hand, but Rachel had a really cool scanner project online for a while that paired well with my temporary obsession with all things RF - [http://scanner.rachelbythebay.com/](http://scanner.rachelbythebay.com/)

Back then your options were basically Ettus transceivers for >$1K or the little RTL dongles for $20 that didn't have sufficent bandwidth to do much good. Since then a whole crop of SDRs have hit the market in the <$500 range that could do this kind of thing.

<comment><USER20> I really like this project. Not only did the radio audio have great quality, the way that the snippets are arranged makes a very good gui.

<comment><USER21> Thanks! We were really lucky in that the Santa Clara city system was still using analog voice channels with lots of bandwidth (20K0F3E). If you check out the SVRCS system that replaced it (and I also logged for a few years), the audio quality is a lot worse. Super-compressed audio which then gets crammed through /another/ codec (MP3) isn't great.

I will admit that I actually listened to the original system a lot with headphones, so I had every reason to fine-tune it until it sounded as awesome as possible. If you go back far enough into 2011, you can find a bunch of calls with terrible audio before I figured out the finer points of squelch, tuning errors, and 48 vs. 44.1 kHz :-)

I haven't decided whether it's worth building another system now that I have time to actually listen again. Hmm...

<comment><USER22> When I lived near the airport I made an ACARS monitoring box with the B200 and GR. Had a bunch of fun analyzing engine performance data and the funny messages going back and forth. Travelling with my rtlsdr has saved my butt a few times. Always nice being the first to know that a flight has been cancelled.

</comment></comment></comment></comment><comment><USER23> I enjoyed reading this as well as some the other blog posts on her site. I was curious about the following:

>"I've been having some wonderful conversations in the real world since resigning and jumping off the merry-go-round."

What merry-go-around or where did she resign from?

<comment><USER24> I'm pretty sure she used to work at Facebook, but she's never explicitly mentioned it on her blog. Previously, she worked at Google, where she also resigned.

<comment><USER23> Yeah I gathered she has spent some significant time in the valley. I hope she might consider writing a post on her question of:

>"... and how to succeed in the "2018 version" of the culture which now exists"

<comment><USER25> She wrote briefly about it in "How to look out for yourself inside a particular company". [http://rachelbythebay.com/w/2018/03/21/next/](http://rachelbythebay.com/w/2018/03/21/next/)

<comment><USER23> Thanks for pointing this out. Cheers.

</comment></comment></comment></comment></comment><comment><USER26> Agree, but you have to be willing to invest your time and effort into a task when you look for it that way.

Sometimes you can be better off doing things the simple aka duct tape way, when it just works.

Anyone who's not read tacobell programming should take the 2 minutes to do so now because it underlines my point very good.

[http://widgetsandshit.com/teddziuba/2010/10/taco-bell- progra...](http://widgetsandshit.com/teddziuba/2010/10/taco-bell- programming.html)

Incase my point is not clear: you have to differentiate, the concept of work with the concept of problem solving.

<comment><USER27> Taco Bell Programming can lead to duct tape.

You start with a simple script to do a simple job. It works - well. People want more features. You keep going until nobody can understand what you've created.

Then you leave the company.

Any software that works will be extended given enough time. To adapt the Peter Principle, every piece of software rises to its own level of incompetence.

<comment><USER28> _every piece of software rises to its own level of incompetence._

Which, from a simple review of the contemporary software landscape, is obviously false.

<comment><USER29> i think the landscape has changed quite a bit in the last 10 years, but its not clear we're in a golden age of simple, robust and composable software either.

maybe you can paint a more detailed picture?

<comment><USER28> The thing about Taco Bell programming is that sometimes Taco Bell increases the number of available ingredients. What was 8 in the 1970s is at least a few more now. Gorditas, for example. And once upon a time they sold zero varieties of nachos. Don't forget to set up a Red Hot Cheeto cobranding partnership if you want some more variety.

Almost the entire Unix software ecosystem is simple, robust, and composable. I don't know where "golden age" comes from, though the list of existing software that has not risen to their own levels of incompetence stretches back decades.

</comment></comment></comment></comment></comment><comment><USER30> Fantastic article! This is precisely why founders that are novices in their industry sometimes come up with the really big ideas. As counter-intuitive as it is, it's easier to see the duct tape when you're looking with fresh eyes.

<comment><USER31> I wonder if fresh eyes don't see the "stigma" of a duct tape approach; rather seeing a good-enough solution for now that'll work. Instead of agonizing over a better way to do it, they implement and get on with it.

I think more senior engineers fall into the trap of seeing the maintenance burdens ahead and not wanting to, or not being able to, make the call to use the duct tape.

<comment><USER28> IME, Jugaard is a rare skill.

[https://en.wikipedia.org/wiki/Jugaad](https://en.wikipedia.org/wiki/Jugaad)

</comment></comment></comment><comment><USER32> One tool that I would like (and is probably) out there is tool that would easily let me compare and merge directories. I think this goes beyond Beyond Compare. But here's my use case:

I have videos, images of our children in various places (my phone, one drive, dropbox, maybe usb sticks) that I want to go into the target directory (probably one drive). the tool would go through all the other directories, checksum them against all the other directories, and then present them as "these are the files that should be merge into your target directory".

Can regular diffing tools do something like that in an easy manner?

<comment><USER33> Maybe off-topic to your original need. But I've always wanted / needed a utility that can de-duplicate media (images, music, videos) that I have scattered around which are the same thing just at different qualities/resolutions.

I get that for music and video this is actually quite challenging but images - - I would've thought quite easy? I've tried a few tools which claim to do this over the years but they all fail rather miserably / require a paid upgrade to do it better (although what is demonstrated in the free version is never impressive enough to consider paying).

Might be a good project for myself in my spare time, but wondered if anyone knew of anything obvious I was missing? FSLint and stuff is great for general filesystem de-duping, this is a slightly more complex case.

<comment><USER34> I work a lot with image and video processing - this sounds like the kind of thing I'm interested in. Would you want to chat some time? Email is in my profile.

</comment></comment></comment><comment><USER35> A related observation I would offer is that not every environment / system can be fixed with a layer of duct tape like this.

Unintuitive defaults, annoying long command-line options, needing to take many separate steps to complete one task are all problems that can be trivially and permanently solved with shell macros and wrapper scripts.

Performance problems, using the wrong data structures, random crashes, on the other hand _cannot_ be solved this way.

</comment><comment><USER36> This is exactly what led me to build Dependabot - dependency management was a minor pain at my old job that we'd written some scripts to handle better.

Another group of friends started Personably from exactly the same strategy - we had a script to create dozens of calendar invites for new joiners with all their onboarding details, so things didn't get missed.

<comment><USER37> And is it going well?

<comment><USER36> A qualified "yes".

Dependabot has ~100 paying customers, and makes just over $2,000 a month. It's still quite a lot of work adding new features, but if I wasn't extending it's functionality it would be passive income.

Personably have raised money and landed some big paying customers - I think there's scope for them to be solving a relatively large problem, having started from a duct-tape fix.

The only proviso I'd add to the article is that sometimes the problems you find like this are small. Dependabot will never be a full-blown startup - it's scope is too small. That's not necessarily a bad thing, though - I think the problem has still been well worth solving thoroughly.

[https://dependabot.com](https://dependabot.com) [https://personably.co](https://personably.co)

<comment><USER38> Don't any of the langauges you support have options to keep all dependencies up to date? Eg. By putting wildcards in version numbers

<comment><USER36> That's normally an option for your manifest file (e.g., a Gemfile or package.json), but most production applications also (sensibly) use a lockfile. Updating the versions in that lockfile is what Dependabot is great for.

</comment></comment></comment></comment></comment><comment><USER39> This is why open source software works so well- layers of duct tape transition seamlessly into the thing itself.

</comment><comment><USER40> Always a good approach, but also recognize that not every duct tape solution is worth productizing.

</comment><comment><USER41> I took the scripts concept as a metaphor for the broken aspects of a company's culture, and how people work around these broken aspects with "scripts" of behavior that they've learnt over the years.

Curious to hear about people's duct tape fixes for team/company culture issues.

<comment><USER42> I once has to log time on everything. It was a tempting workaound to log time to the wrong ticket (still one of mine though) so that none of the tickets go over estimate, so I wouldn't be taken to task. I even thought of writing a tool to keep the mapping of real ticket to fake ticket.

Also better to try and get more nebulous work that can carry a higher estimate/ buffer in the first place. And never refactor in the same ticket. Create a new one. But that won't get done so just let it go.

</comment></comment><comment><USER43> \- A nuance: Consider a hammer with a cracked handle.

What's key is not the hammer crack (bad enough?) or the duct tape repair (good enough?).

Instead it's the generality (portable, abstract concepts behind it like 'gluing' 'joining') and availability (common, cheap, simple) of the duct tape that enables the (w)hack.

People don't buy duct tape to fix cracked hammers.

\- Afterthought : A Stack Exchange user answers: "why use duct tape when you could just use super glue" (or rubber bands, zip ties...).

<comment><USER44> Me, I tend to use super glue, some duct tape to reinforce, and finally heat- shrink tubing for neatness and durability.

</comment></comment><comment><USER45> This is why I was so frustrated with a co-worker a few years back -- he set up his home directory to be unreadable, so I couldn't go look at his ~/bin directory!

</comment><comment><USER46> this post helped me realize I had a whole open source project in my collection of shell scripts. great post to help you look right in front of you to find something good to work on.

</comment><comment><USER47> "a whole bunch of dumb little shell scripts"

This is definitely my duct tape. I am neither a developer nor a sysadmin, just a dumb end user. When something cannot be written using only shell builtins, I use a relatively small set of external programs in my dumb scripts, utilities that would be found on most UNIX install media.

If I had the skills I would write many of these in a compiled language, i.e. C or in assembler. As a non-programmer, I have found fasm to be the most useful e.g. its ability to easily call C libs, but I also keep coming back to inline asm as I like the extra bit of control over registers that if offers. I use a small, old assembly level debugger that I prefer over gdb.

History suggests more than a few well-regarded projects originally began life/were prototyped as shell scripts. (I would bet most readers are using at least one today.)

Even though I lack the knowledge and experience of a career programmer, I do not feel ashamed for using Almquists shell to test ideas. Though I certainly understand the use of the word "dumb". However the truth, no matter how "dumb", is that shell builtins are faster than most of the other scripting languages I have tried, and not just in theory.

For some of these dumb little shell scripts, I have managed to replace them with compiled programs (often with the help of flex/yacc), but most are beyond my C/asm "implementation skills".

The point is that if a C programmer came to me, an end user, asking for ideas of what "new" or "missing" utilities they could write (not sure if thats what the author is describing), I could supply a lengthy list. Double digits, maybe even triple.

As I understand it, programmers want people to use their software. Given that I use many of these dumb little shell scripts every day, I could guarantee at least one loyal end user.

<comment><USER48> Care to share your top 5-10 missing utilities? Maybe I'm that programmer

<comment><USER47> Examples of your work?

<comment><USER49> Does it matter? Just post your list. Worst case, none of them get implemented.</comment></comment></comment></comment>


Lisp, L stands for Leverage - <AUTHOR> http://vicsydev.blogspot.com/2017/01/in-lisp-l-stands-for-leverage.html <comment><USER2> "Lisp was created to make it possible to solve ... problems so complex that holding back any power from users would have rendered the result useless. The designers of Lisp went all in to provide the best tool set they could imagine for solving the most complex problems they could imagine, and mostly managed to leave egos on the shelf while doing so. The reason it isn't changing much is because it's a masters tool set, forged from an ocean of experience; the types of software people build in Lisp change at least as fast as the rest of the world."

I'm a very long time and continuing lisper, but every assertion above seems to me either false, so grossly overstated as to be effectively false, or true of many other languages, and therefore not interesting qua lisp.

<comment><USER3> The statement is false in the sense that the designers actually realized that the problem space is vast, and impossible to target all of it with dedicated tool sets. So they provided not a tool set but a tool making factory. And not even the final tool-making factory: rather one which teaches something more important: a very good general pattern for designing tool-making factories.</comment></comment>


Software error doomed Japanese Hitomi spacecraft - <AUTHOR> http://www.nature.com/news/software-error-doomed-japanese-hitomi-spacecraft-1.19835#1 <comment><USER2> This really sucks but I really hope we get a very detailed explanation of what went wrong like with the Toyota unintended acceleration case. I find these sorts of things so interesting</comment>


Why did Google feel that Google Wave was a good product? - <AUTHOR> http://www.quora.com/Why-did-Google-feel-that-Google-Wave-was-a-good-product/answers/380212 <comment><USER2> To me, Wave failed because it wasn't a product. It was an engineering exercise. There was a lot of interesting technology in Wave (eg the Wave protocol itself, federated servers).

But what problem did it solve?

No one really seemed able to answer that.

When I looked at Wave I saw a set of primitives from which you could build email, IM, Twitter or any other number of communication mediums. The problem is that people could already do all of those things elsewhere. Did Wave make it easier? If it did, it might've stood a fighting chance. But it didn't. The UI was complicated. On most browsers it was slow.

Part of what made Google the search behemoth that it is (apart from the obvious algorithmic improvements over what came before it) was the simplicity of it. It was the simplest of pages (compared the shotgun portals of Yahoo and the like) with a giant text box. Anyone could look at it and know what to do. What's more it was _fast_.

So I would take Wave as an object lesson in what happens when you seek to solve an interesting engineering problem rather than build a product.

<comment><USER3> For me, Wave had one very strong use case: collaboration and discussion intended to result in a persistent document. Forums, mailing lists, e-mail, etc. are great for discussion, but they are generally ephemeral. Documents are persistent, and with Google Docs can be created collaboratively, but the communication channels around them are weak. You're limited to distracting in- document text, limited comments, or entirely out-of-band communication e.g. e-mail. With Wave you could have the document, editable by anyone, and embed discussion in it and around it. You can discuss a point, updating the base document as discussion converges. It's a brilliant medium for group brainstorming and drafting.

That use case alone is enough to make me miss it.

<comment><USER4> While I definitely agree this would have worked as a great collaboration tool, anyone I tried it with just did not get it, and we ended up using it as a I'm-seeing-what-you're-typing chat box.

</comment></comment></comment><comment><USER5> Despite the hype... I don't think Wave failed. I blame all of 'us' (where 'us' is defined as alpha geeks, silicon valley startup folks, techies, etc) for this misrepresentation. We all this products must be wildly successful with millions of users or it has failed... we tend to see failure and success as this very black and white / binary thing... but it's not.

Google is probably discontinuing use of Wave because it didn't live up to their expectations and didn't have as many users as they need it to in order for it to be viable. If this were created by a smaller company, however, it could still be considered successful... I haven't been able to find any numbers on how many active users wave has but I'd guess somewhere around 50k - 100k... For any smaller company that'd be a huge success...

I'm really tired of reading all of the rhetoric that acts as if it's just oh so obvious that Wave isn't a good product. For 50k users it's a great product that they love... It doesn't need to have 2 million users to be a good product... Personally, I think Wave is a BRILLIANT piece of software and I use it exclusively for communication with my 6-10 close personal friends.

I have one gripe - the mobile interface is terrible... Maybe if this could've been fixed more people would've used it.

<comment><USER6> When you market to 100M+ people, you can find 50K-100K people to love almost any product. That does not make the product good nor a success for the company that created it.

</comment></comment><comment><USER7> I personally opted to join the Wave team because it was the first time that I'd seen Google try something quite different. Google has many other cool products, but many of them are online versions of existing desktop tools, or Google versions of existing online tools. Wave was a unique blend of a variety of communication tools, and it intrigued me.

In addition, I was in a role where I spent half of my time communicating and collaborating with different groups, and after failing to be impressed with existing tools, I was particularly interested in seeing how Wave might make my role easier. And despite its various flaws, it did indeed make it better.

In the end, I'm happy that I joined the Wave team. It was a really interesting project to work on and a great learning experience.

<comment><USER8> And that was great, I could feel your enthusiasm from your posts and answers. They were a big plus for Wave.

</comment></comment><comment><USER9> Once I got into it, I liked Wave _a lot_.

The real problem for Wave was that it had a 20-60 minute learning curve, almost no one I knew was using it, and it was hard to convince people to use it because of the learning curve and no one else was using it.

<comment><USER10> Wave is going to be one of those things people talk about for years afterwards wondering why it failed.

In the end, it probably was two things: 1) Wave didn't fit into some neat category that people already had about stuff, and 2) Google wanted to own all the data

<comment><USER11> You are correct about #1 but #2 is way off. Where did you get that assumption? From everything that was said or done about Wave, it seemed like they have no problem with having the data be outside of Google's silos. If they wanted to control it all, why did they want to have it be federated and distributed using multiple variations of Wave or custom apps that speak the same protocol?

<comment><USER10> Thanks for the clarification.

I contacted the development group at Google and was told the Wave server code was proprietary and they weren't giving it out. Yes, the _protocol_ was open, and the idea was that there would be a lot of clients and such that would use it, but if a team wanted to take the server code as-is and start plugging in sensitive information? The data couldn't live in-house.

That's why several projects I had decided not to use Wave. Shame, really. I liked it a lot. I hear that the server will be made available under the Apache license, so I'm looking forward to that happening.

<comment><USER12> Google's own Wave servers probably plugged in to BigTable and who knows what other proprietary stuff. So the source code probably wouldn't have been so useful anyway.

</comment></comment></comment></comment></comment><comment><USER13> It _was_ a great product, but it became 'another inbox' to me. It was designed to make communication frictionless, but it felt like a drag to check.

New communication services need to provide big, obvious benefits over existing services, then communicate those benefits with early adopters in a way that trickles downstream.

If we can learn one thing from Wave, it's how deeply embedded existing communication methods are in our way of living and working; it's hard to pry business users away from email and social users away from Facebook even if you're Google.

In this sense, Wave wasn't a bad idea; it was a great idea ahead of its time. I suspect that communication methods that are natural evolutions of existing popular systems (e.g. fax machines, Skype) are likely to have higher adoption rates than methods that take brilliant leaps too far too soon.

<comment><USER14> Not much changed since Wave launched, they could've iterated more. Just creating a platform and API isn't enough.

<comment><USER13> I'm not sure that iterating more would have helped Wave. The basic concept of a live chat/document editing platform was too far removed from what people are familiar with, so finding a clear use for it was hard. I don't think Google could have changed anything in the product to fix that, although they could have iterated the _marketing process_ to pitch it to whatever audience were using it most and spur uptake in that community, perhaps.

It would be interesting to see if a Wave-like collaboration platform would be widely adopted if it grew organically over time out of an existing Google product -- like Gmail.

<comment><USER14> Wave from what I read was developed for use internally at Google when Gmail was insufficient. I'd be curious to see what's being used within Google right now in the collaboration space. People who were once using wave, what are they now using?

<comment><USER7> Up until the day I left Google (last Friday), my team was still using Wave. We were a bunch of ex-Wavers though, so we were more likely than others to still be holding on.

I should point out that our internal version of Wave was different from the external version in at least one very important way: when a wave was shared with a group that you were a member of, the wave was sent to your inbox. Externally, you would have to set up a search to find that wave, so basically nobody ever read group waves. The idea behind the decision was to reduce inbox noise (particularly important in beginning few months), but that also meant reducing utility for group collaboration.

We were close to releasing proper groups support in the external version, so you could easily choose which groups to follow/unfollow inside your Wave inbox, but were discontinued before that made it out.

So, Wave was awesome for group collaboration, but unfortunately, we never gave the external world much of a real opportunity to witness that.

(And yes, there were other issues with Wave. Just thought I'd point out that one.)

<comment><USER15> That makes a lot of sense. My campus ACM group used Wave an enormous amount when the beta invites started going out, and we kept two organizational waves which mimicked the system you describe. One was a list of the screen names of every member, and the other was a list of waves.

</comment></comment></comment></comment></comment></comment><comment><USER16> When Wave came out I thought it was really cool and used it for several weeks. Then it wore off, we began using email for stuff we did on Wave, nobody was on Wave anymore, so it slowly died.

One of the major factors for me was the crappy, slow UI.

Also, I think Wave lacked CONTEXT. It was great for collaborative editing, but which kind? With friends about parties? With classmates about projects? With colleagues about code? With customers about products? It imported a few Gmail contacts from each group, not enough for either one to make sense in the long run. It had some great features, but not enough for either one [compared to email/Facebook/specialized webapp].

<comment><USER17> > One of the major factors for me was the crappy, slow UI.

For me, that wasn't a problem in Chrome, interestingly enough. It was indeed extremely slow in Firefox though. Maybe Google didn't have enough time to optimize it for other browsers before the novelty started to wear off.

</comment></comment><comment><USER18> Wave was an amazing product and set of technologies.

It was a release and marketing failure. Should have been in the Google incubator at least another 6 months before Alpha/Beta, and shouldn't have made the huge mistake of releasing a product to users with limited invites when the entire purpose is collaboration. And that's what the focus of its marketing should have been: collaboration. Group chat, forums, and wikis, here's your replacement. Planning a trip or party? Use Wave instead of Gmail. That's all it needed. Geeks want to hear about the cool technology in it, everyone else just wants to know what the hell am I going to use this for.

</comment><comment><USER19> I'm obviously not privy to Google's internal deliberations, but I've always thought that Wave was a _great_ product - for people working in large institutions like Google. If I had to regularly collaborate with people in different offices, and with customers and suppliers, to keep track of a variety of project state and planning documents, Wave would be an _excellent_ tool.

Unfortunately, my colleagues are in the same room, and I already have other ways of communicating with my friends, so Wave isn't much good to _me_ , and would probably never achieve mainstream success. It might have had a chance with corporations fed up with Outlook, though.

</comment><comment><USER20> Personally, I've never been surprised at Wave's apparent failure. To me, it was no different than any other attempt at a "revolutionary idea" that didn't work later in another revision or iteration (I think Hacker News readers understand this very well;a poor analogy would be a Microsoft Tablet and an iPad). A lot of discussion about it's failure is a direct result of Google's status and the amount of resources required to come up with a product like wave.

When I consider Wave in retrospect, I really think they limped in on this . It was a grand experiment. If they really wanted this to succeed, I don't think they would have proceeded with the launch the way they did. Reading the Quora answer sort of jives with this.

I'm surprised no discussion touched upon the Anonymous response in the Quora thread. It's more interesting than "why Wave failed" and is indicative of the state of Google. It brings an additional perspective to the discussion around Google's (apparent) talent retention problems. Combined with other anecdotal evidence, it really look like Google is at a loss for how to continually motivate employees with their current organizational structure

<comment><USER21> Agreed. The most interesting bit of information from the thread is the structure of the Wave team and how the incentives may have contributed to the quality (or lack thereof) of the shipped product. Kind of like incentives on Wall Street rewarding risky behaviour.

</comment></comment><comment><USER22> I don't know Quora. Is it all like this? (hearsay, public knowledge with some narrative on top)

<comment><USER23> Yes.

</comment></comment><comment><USER24> In case anyone didn't know, Wave is now in the Apache Incubator: <http://incubator.apache.org/projects/wave.html>

</comment><comment><USER25> Briefly (I need to run), when it was announced/described, I saw it solving a lot of problems I've encountered:

Submarining discussions and decisions (e.g. email's that don't include the whole group or that don't get shared with new members joining the group).

Excessive work to reconstruct discussions, events, decisions. (Again, "big wads of emails" being a typical example.)

Centralized, rigid access controls. (You have to go through systems administration to add somebody to a project. Sometimes, that in turn means management sign off. Quickly, you're back to copy/pasting crap into, oh, for example, email.)

Wasted time. For example, the last three points.

Lack of dynamic, group discussion separate from physical and chronological synchronization and separate from the need for productivity killing meetings. Some companies have (finally) caught onto internal bulletin boards and the like, for this. But then somebody has to set them up, add users and credentials, and centralize a whole lot of bureaucratic decisions that might better be pushed out to the teams involved.

Lack of a centralized, uniform project communication history.

Etc.

Anyway, Wave seemed promising. But the client Google offered up was unusable for most people. It was literally too slow, at first, on the client side. It reflected the worst of Google's trend to abandon discoverability in its UI. (I'm reminded of this in a smaller fashion every time I help a client's employee take the dive into their calendar product. I'd argue that Android has a fair amount of it, too.)

Also, early adopters would join and have no one to work with. Even when you could get someone else invited, most didn't want to tackle it. Growth stagnated.

I still think Wave' paradigm solves a lot of problems. Maybe Apache and third parties will have better luck producing a usable client.

P.S. There were also many niggles and problems with the UI, such as default decisions about account creation and account information sharing. The UI was, basically, quite underdone. Finally, Google didn't continue to pour effort into it nor give it enough time to take off.

</comment><comment><USER26> GMail's invite-based beta worked because there were no network effects in the product's value proposition. Even if those with whom I frequently corresponded did not use GMail, I benefited from the product. Wave was totally different -- everyone with whom I wanted to collaborate (at least in a particular context) had to have accounts, and I didn't have that many to give out. The product should have been implemented so that email/IM/whatever were used as fall-back "protocols" for those who had not yet adopted Wave. Also, the invites should have granted one the right to create N waves involving, say, 50 people max.

</comment><comment><USER27> It can also be viewed in the context of recently posted (don't remember who's) article which analyzed RIM's "interactive pager" vs. TIVO's PVR as example of marketing positioning of "extension of existing product" vs. "a product creating new product category".

In this case it may have been more successful if they developed and marketed it as an "live collaboration" extension to GMail or as interactive collaboration layer on top of Google Docs.

<comment><USER28> So true... Wave was actually pretty damn cool in a lot of ways, but they seemed to do little or nothing to explicitly position / market it. Coupled with the fact that the original UI was a bit, erm, awkward, and we get what we have here today.

Thankfully Wave lives on at the ASF and hopefully people are going to be able to use the technology to do some mondo radical stuff.

</comment></comment><comment><USER29> The answer seems to be that they didn't think it was a good product, it was just a bone to keep someone around?

</comment><comment><USER30> Google wave was classic groupware ( see <http://www.jwz.org/doc/groupware.html> ). And I think the people at Google got confused in the sense they used it at a place they love (Google) so they thought it was great (Wave).

</comment><comment><USER31> Because Wave looked cool in demos.

Because it required interesting technology and was challenging and fun to implement.

Because it solved problems (granted, all of the easiest and least important problems).

A lot of products are brought to market through the same flawed process. Look at the Segway for a perfect case in point.

<comment><USER23> > Because it solved problems (granted, all of the easiest and least important > problems).

Unifying the benefits of email and IM in a single conversation isn't, for me, easy or unimportant.

I thought Wave was engineering led rather than user led, but with some polish and integration into existing apps (like GMail and Outlook) could have been a killer.

</comment></comment><comment><USER32> Haha. That's the problem with new ideas.

If they take off, you're heralded as a genius.

If the flop, they question why you even started in the first place.

Wave was spin to try and reinvent internet communication. It wanted to merge email and IM and all these other communication forms together. Perhaps it was way too ahead of its time. Perhaps the execution was not as well thought out as it should have been. But the overarching concept is not ridiculous.

</comment><comment><USER33> All I want Wave to be is Google Docs + Gchat on the same page. Possibly with the ability to link parts of the doc with the Gchat conversation going on when they were written.

</comment><comment><USER14> Wave actually shows the other person typing and editing. Really cool. Skype doesn't do that, does/will Convore?

I use Wave and the main problem is the load time, and basically speed. They need to get some HTML5 and local storage into it, maybe some Node.js.

Also, Waves can seem to go on and on, and one forgets why a wave was created in the first place, and when one should be ended/closed.

So there should be a splitter button to start a new wave within an existing wave.

It's rather like a text chat with someone. You never know what's going to come up, so how can you categorize it before it's even begun? Or if you do, and it goes off-topic, then what? Do you head-butt a wall or do you go to the beach?

</comment><comment><USER8> I think the biggest problem, despite the invite system, was the missing migration path from email.

Technically it was great and had soon my attention.

</comment><comment><USER34> Wave failed in the UI department. Common users don't like complexity.

</comment><comment><USER35> IMHO .....because it was, the real problem was that people didnt see its value, scalable online collaborative editing where some of the editors are programmable bots, i dont think people really realised its potential sadly.....

<comment><USER36> I'm not sure why people are anti wave. I still use it for the purpose of multiple collaboration and it serves that purpose well. I honestly do not think it is "ultimately useless".

<comment><USER37> Just because you aren't a fan of a particular technology doesn't mean that you are actively "anti". I actually went back and watched the original Wave demo on Youtube just so I could reconstruct my original reactions, where were basically:

\- That looks really cool

\- I wonder how they do _that_ (the synchronized live edits)

\- _I can't really think of any scenario where I would want to interact like that_

Now I can see how some people might like it, but I really didn't - and I still find it a struggle to see it being used.

Perhaps the gulf between email and instant messaging isn't just a technological one, but actually corresponds the way most people are happy interacting?</comment></comment></comment>


Killing C.I.A. Informants, China Crippled U.S. Spying Operations - <AUTHOR> https://www.nytimes.com/2017/05/20/world/asia/china-cia-spies-espionage.html <comment><USER2> From my readings of CIA memoirs and spy novels, CIA Agents (aka sources or informants) are really foreign people reporting information to the CIA Officers which are US Government employees.

If these were US government workers reporting secrets to the Chinese I would expect imprisonment, etc. I guess it isn't too shocking they would do the same, albeit more cruelly, to their own traitors.

There was a post recently about how easy it was for foreign governments, in the 1970's, to track the actual CIA Officers on station at an embassy. TL;DR: Reading job titles and observing who they hung out with was one way. Also mentioned was that CIA officers rarely intermingled with actual Diplomats and support staff often knew who was who because of secret areas of the embassy that were off limits.

The article mentions a potential hack into the systems but it could have been good old spy-craft by following people and noticing patterns to find the sources.

<comment><USER3> > The article mentions a potential hack into the systems but it could have > been good old spy-craft by following people and noticing patterns to find > the sources.

I suspect that is the case, too. Especially this:

> Some officers met their sources at a restaurant where Chinese agents had > planted listening devices, former officials said, and even the waiters > worked for Chinese intelligence.

I sometimes go to some fancy and downtown restaurants in the Eastern European capital where I live, and you very often can see politicians there and people you very often see on TV as having had problems with the law. I often joke with one of my work-colleagues about how most probably all the restaurant tables in those kind of places are wired. It doesn't help that the most fancy party place in the city is partially owned by the daughter of a the director of the Security Services back in the 1990s. All these places are also filled with foreign businessmen and I suspect there are also people working for foreign embassies.

While I used to live and eat out in the poorer parts of the city I never, never saw what looked to be foreign persons eating at those restaurants. They are all gravitating around the same area in downtown city. I suspect a very similar thing is happening in China and in other countries' capitals around the world. Most of the Western diplomats who are also carrying intelligence activity on the side don't seem very capable of just blending in in a foreign environment.

<comment><USER4> Ok, since we both know the city, which big restaurant is owned by the blue- eyed daughter?

<comment><USER3> Club Loft and Anca Magureanu, the daughter of former SRI director Virgil Magureanu. I'm on mobile and am too lazy to link here, but the info is easily searchable.

</comment></comment></comment></comment><comment><USER5> "Candace Marie Claiborne, accused of lying to investigators about her contacts with Chinese officials. ...Chinese agents wired cash into her bank account and showered her with gifts ...iPhone, a laptop and tuition at a Chinese fashion school...fully furnished apartment and a stipend."

Recklessness of this is beyond my comprehension, not just accepting cash but also communication and computing devices like iphone and laptop that may have been tampered with.

Details of the charges and bribery here.

[https://www.justice.gov/opa/pr/state-department-employee- arr...](https://www.justice.gov/opa/pr/state-department-employee-arrested-and- charged-concealing-extensive-contacts-foreign-agents)

Unbelievable lapse in judgement.

<comment><USER6> Check this out: [https://www.usatoday.com/story/news/nation- now/2017/05/02/fb...](https://www.usatoday.com/story/news/nation- now/2017/05/02/fbi-translator-secretly-married-islamic-state- leader/309137001/)

FBI translator secretly married Islamic State leader

People are cray.

<comment><USER7> To be fair the dating scene in DC is pretty rough.

</comment></comment></comment><comment><USER8> > _By 2013, China's success in identifying C.I.A. agents had been blunted — it > is not clear how._

If I can make a software analogy here, this is the least satisfying resolution to a bug in your program. Imagine a devastating but intermittent bug, that simply disappears after a period of time or after innocuous changes to your program. Not knowing what happened or how it "fixed itself" is very frustrating.

Alternate theory: The F.B.I. and the C.I.A. know exactly how they fixed it, but they won't tell The New York Times that part.

<comment><USER9> Your alternate theory is likely to be the correct one. As a general rule with very few exceptions, read espionage tales published in the popular press for entertainment not accurate information. The first rule of spying is : EVERYBODY. LIES.

</comment></comment><comment><USER10> This is historical, being 7 years old. No one knows for sure when the Office of Personnel Management hack began, only that it was detected, by accident in 2015.

This OPM hack is probably the most damaging for the US government's spying efforts, even more than the Snowden disclosures.

<comment><USER11> > even more than the Snowden disclosures.

Snowden took only documents that describe the overall global surveillance infrastructure.

Snowden had access to raw data streams for almost all SIGINT operations. System administrators like Snowden received special "root access like" clearance called PRIVAC (Privileged Access) where people allowed to be exposed to information of any classification, regardless of what their position actually needs, apparently because they are sysadmins and need to see what's going on. Snowden had 'technical' access to live feeds for all active operations, drone feeds and other information regardless of classification all over the world was wider than anyone participating in operations had.

It's not hard to imagine that there are other people with PRIVAC access who are actual spies. Just by observing important stuff and not taking anything compromises the system. If they downloaded some of that stuff, it has been open doors all this time.

Only after Snowdon's revelations NSA has added the two-man rule for sysadmins. Apparently it was too costly before. Increasing the data collection was more important than building the system.

I think there is systemic failure in US/UK intelligence organizations. They constantly emphasize offense over defense even when they know that they are very vulnerable. It's hard to show results for good defensive posture.

<comment><USER12> FYI even users with low access can view drone feeds.

<comment><USER11> Access to drone feeds from basically all CIA/DIA operations provides breath of access that compromises the security at completely different level than being part of a operation.

</comment></comment></comment></comment><comment><USER13> >But the C.I.A.'s top spy hunter, Mark Kelton, resisted the mole theory, at least initially, former officials say. Mr. Kelton had been close friends with Brian J. Kelley, a C.I.A. officer who in the 1990s was wrongly suspected by the F.B.I. of being a Russian spy. The real traitor, it turned out, was Mr. Hanssen. Mr. Kelton often mentioned Mr. Kelley's mistreatment in meetings during the China episode, former colleagues say, and said he would not accuse someone without ironclad evidence.

You would think that a counter-espionage chief would be much more "paranoid". I would guess that in the world of intelligence, getting "ironclad evidence" of something is probably the exception and not the rule.

<comment><USER14> No, I imagine that the biggest fear a CIA counterintelligence chief has is of becoming the next Angleton.

<comment><USER15> Although Angleton ultimately was proven correct by Mitroyken.

</comment></comment></comment><comment><USER16> It this implying that America's informants in Russia are all being killed right now, or am I reading too much into it?

</comment><comment><USER17> We (the US) imprison people indefinitely for not turning over encryption keys and passwords.

We search and copy laptops and phones at borders, with no kind of court order.

We put non-dangerous people in jail for weeks because they can't pay $500 bond, even though it costs us more to have them in jail than to just forgo the bond payment.

It was just on 60 Minutes last night that in Cook County IL, people are being held in prison so long before being convicted, that by the time they are convicted, they've already served their sentence, and often have served way more than their sentence.

I can forgive the Chinese for killing or imprisoning US spies. I'm sure we do the same thing or worse. As far as I'm concerned, the US has lost any moral high ground when it comes to imprisonment.

</comment><comment><USER14> Is there good Sino-Western spy fiction?

<comment><USER18> Look into The Tourist/Milo Weaver trilogy by Olen Steinhauer. The third book (An American Spy) is where you'll find the US/Chinese intrigues (and an incident that has a similar ring to it as the above news article). I recommend the full trilogy, as the first two books set up the third.

You might also try The Honourable Schoolboy by John Le Carré. Set primarily in Hong Kong, it's part spy novel, part sweeping tour of Southeast Asia just as the last dominos are falling to Communism in the 1970s. Although it's technically in the George Smiley series, I don't think you really need to read those in any particular order.

Steinhauer if you like beach reads/page turners. Le Carré if you like a more literary slow-burner.

<comment><USER14> I've read just about everything by Le Carré, including, of course, The Honourable Schoolboy. I might check out Steinhauer. I think I read something by him, but can't remember what.

</comment></comment></comment><comment><USER19> Interesting how American citizens / informants are seduced and reckless, whereas Chinese sources act out of worries about corruption.

E7ther biases, or possibly about to change sharply in age of Trump.

<comment><USER20> Have you ever seen the anti spying posters in china? They totally are oriented around seduction and recklessness (Chinese girls are warned about handsome foreigners, and so on).

<comment><USER19> I suppose, I expect more from NYT

</comment></comment></comment><comment><USER21> > By 2013, the F.B.I. and the C.I.A. concluded that China's success in > identifying C.I.A. agents had been blunted

how can the CIA conclude the problem is resolved when they have no idea what the problem is? this sounds exactly like a government report to CYA (all too familiar if you've ever worked for the USG).

<comment><USER22> If they knew, would they tell the New York Times?

</comment></comment><comment><USER23> Reading between the lines, a lot of the mole suspicion seems to focus on ethnically Chinese CIA employees.

<comment><USER24> Between speaking the language fluently and not sticking out when meeting sources, it makes sense to me there would be a lot of ethnically Chinese employees in the spying-on-china division.

</comment></comment><comment><USER25> Why do people keep acting like we are living in a poorly scripted movie from the 70s? Its a small world. Can it really not be civilized?

<comment><USER26> huh, can't believe no one has ever thought of this before

</comment></comment><comment><USER27> Is it legal to spy on another country's government? This article suggests it is legal. Does the US government let chineese operatives work in the US government?

<comment><USER28> [https://en.m.wikipedia.org/wiki/Chinese_espionage_in_the_Uni...](https://en.m.wikipedia.org/wiki/Chinese_espionage_in_the_United_States)

It goes both ways. Geopolitical peers and adversaries always spy on each other.

</comment></comment><comment><USER29> non-survivor bias? We don't know how many spies remain undetected.

</comment><comment><USER30> Every time I read news like this, I remember that nyt has many choices of what to publish and they CHOSED to publish this. Why? It feels like this article is designed to increase sympathy for the CIA.

<comment><USER31>
        > they CHOSED to publish this. Why?

Is "they think people will click on it" too complicated an answer?

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

> From the final weeks of 2010 through the end of 2012, according to former > American officials, the Chinese killed at least a dozen of the C.I.A.'s > sources.

Hillary Clinton was secretary of State from 2009 to early 2013. In October 2010, she traveled to Vietnam for the ASEAN conference while using a personal, older model Blackberry. This timeframe also overlaps with her personal email server.

> In Vietnam in particular, analysts say, there's a concern Chinese government > hackers could pull information from the Vietnamese government-owned telecom > — either through an intelligence-sharing agreement with Vietnam or because > Vietnamese officials make little effort to keep Chinese spies out of their > networks.

[http://www.politico.com/story/2015/03/hillary-clintons- perso...](http://www.politico.com/story/2015/03/hillary-clintons-personal- blackberry-less-secure-116200)

</comment><comment><USER33> Wow, a piece i could read on the NYT. I hope it's not just me, reading this thinking; this story reads so much differently than their typical Trump hit piece. It doesn't take a side, it doesn't try to fire you up, it just informs.

I like being _informed_. This story is incredible - it shows a massive failure of the US system. The most likely source, a leak inside. A leak they were never truly able to detect.

It bodes for sloppiness. The incredible level of _sheer sloppiness_ we are seeing from the deep state is beyond incredible.

If the reality is the intel services need a bad and serious reshaping, and we are watching them actively try to avoid that possibility. This article exposes a little more truth of the matter.

Our spies have been assassinated. Our most sensitive databases breached. Our own weapons stolen and used for bullshit crap coded ransom-ware. I would hope this story sticks around and becomes a talking point, but the media will strangle this out.

<comment><USER34> > The most likely source, a leak inside. A leak they were never truly able to > detect.

This is pure conjecture.

It is quite easy to do data mining on your subjects if you aren't actually bound by laws, evidence, or human rights.

The drug lords were using AS/400 mainframes decades ago to ferret out traitors. Sure, they killed a few people who weren't, but, meh, who cares, right? I can't imagine the Chinese government actually cares to any greater degree.

Unless an informant doesn't actually want any tangible benefit, there is going to be _SOME_ trail in the electronic ether nowadays. Even the act of _disabling_ your phone is going to be a trail nowadays.

If you simply kill off anybody who falls afoul of your "standard profile" you're going to get your intelligence agents.

<comment><USER26> >The drug lords were using AS/400 mainframes decades ago to ferret out traitors.

do you have any reading on this?

<comment><USER34> 2002 article date--arrests were 8 years earlier: [http://cocaine.org/cokecrime/](http://cocaine.org/cokecrime/)</comment></comment></comment></comment>


Only fast languages are interesting - <AUTHOR> http://scottlocklin.wordpress.com/2011/11/30/only-fast-languages-are-interesting/ <comment><USER2> There are a few things wrong with this benchmark. In Lush, he's measuring the time it takes to sum 3 million pre-computed random numbers. In Clojure, he's measuring the time it takes to generate 3 million random numbers, and then sum them.

It also looks like he's using two different data structures. In Clojure, its a lazily generated linked list of objects; in Lush, it appears as if he's using a vector pre-initiated to the right size.

He also doesn't mention which versions of Clojure and Lush he's using, or how much memory Lush uses. He complains that a JVM with a 130M is too small, but the 30 million long array in Lush would have been almost twice that size if it was populated with 64-bit doubles.

For reference, it takes me 571ms to run the 300 thousand number example that took him 861ms. If I factor out the random-number generation from the Clojure benchmark, it cuts the time down to 120ms.

If then I use a pre-generated fast array and the specialized areduce function (to match his specialized idx-sum function), I get 16ms for 300k, 22ms for 3m and 230ms for 30m.

So performance is on par with Lush, so long as you compare like for like.

<comment><USER3> "The point is, Lush has datatypes for fast numerics: it's designed to do fast numerics. Clojure doesn't have such datatypes..."

He knows he's not comparing like for like. What he apparently doesn't know is that there _is_ a better data type.

<comment><USER4> Whats the better datatype? I'm looking at doing some numeric programming and I wondered about Clojure for this.

<comment><USER2> If your aim is raw speed, not a lot beats a standard JVM array.

</comment></comment></comment></comment><comment><USER5> This is flamebait, especially the headline.

There are various tools you can use, and using a screwdriver instead of a hammer won't help you much if what you have is nails.

From my point of view, you may get back to me when Lush has data structures for concurrent programming and does (nearly) pauseless GC on multicore machines with heaps of 12GB composed of complex data structures, not just vectors of numbers. This is what I get with Clojure and for my applications it works great. Oh, we also do numerics, quite a bit in fact. But whenever I need actual raw-metal double-adding performance, I use an appropriate tool, e.g. an extension/library. For certain string operations we even went down to x86-64 assembly, with great results.

What you describe is a JVM limitation, not a Clojure limitation — and you're right in only one thing: Clojure is not the right tool for you.

<comment><USER6> Digression here, but I like the "(nearly)". This bit always amuses me about garbage collection wonks. The pauseless bit is a real time requirement. Saying your GC has great latencies or is "(nearly) pauseless" is tantamount to telling a real time engineer your system only fails some of the time. It makes you look dumb.

GC is great. GC makes a ton of things simpler. GC as implemented in popular environments still sucks for real time use.

<comment><USER7> The 'pauseless' bit is not just a real-time requirement. A website that stalls for 2 seconds once every 10 minutes is unacceptable to me. That application thus requires a garbage collector that is _nearly_ pauseless: the pauses are small enough that your users won't notice them. So I don't think it makes anyone look dumb at all to speak of a 'nearly pauseless' garbage collector.

</comment></comment></comment><comment><USER8> I can relate to this. Nothing is more disappointing than putting together a nice piece of code and then seeing it run too slow to be practical.

A while ago, I wrote some physics simulation in Python. The code turned out to be really neat and quite idiomatic Python code. The code ran very slow, I was seeing only 10-20 frames per second when I was shooting for something closer to 120 frames per second. All I was doing was simulating a cube suspended on a plane with four dampened springs, and I was only simulating one of those where I wanted lots of 'em.

The problem was that my code was allocating and freeing way too many objects. The proper solution would have been to go from a neat idiomatic approach where the code resembles the mathematical equations it simulates to some kind of structure of arrays -style code with Numpy. Needless to say, there isn't much fun in using Python that way, so I might as well write the damn thing in C.

Later I went on to rewrite that code in C and running it on my GPU with OpenCL. I did write it in a structure of arrays style, so maybe the Python experience gave me a valuable lesson. Now it runs fast enough for my purposes.

<comment><USER9> > nice piece of code

Too many developers are paying way too much attention to the code being "nice" or it being in a "nice" language, and not enough attention to "does it work" "is it fast".

<comment><USER10> Nice code is maintainable code. High-level languages exist for the sole purpose of making code "nice."

You pay enough attention to "is it fast" and you'll find yourself writing everything in assembler. There's a time and place for that, sure, but when you have a high level language that can theoretically optimize idiomatic code into something faster, it should opt to.

<comment> buff-a _You pay enough attention to "is it fast" and you'll find yourself writing everything in assembler_

Not everything. Not even then. Just the good bits maybe. Sometimes none of it. It might make me prefer C# over Java for example, because C# can lay down structs linearly in memory so I can throw them to the graphics card directly. Or maybe I'd do all the hard work in C and SWIG it so I could use Ruby.

But what I certainly wouldn't do is attempt to write a _physics simulation_ in _python_ , "idiomatic" or not.

<comment><USER11> > I certainly wouldn't do is attempt to write a physics simulation in python, > "idiomatic" or not.

<http://numpy.scipy.org/>

Life can be good.

<comment><USER12> But that's the thing - I would argue that NumPy code is not "idiomatic" Python which uses built-in operations/structures, like list comprehensions, tuples, and dictionaries. I had a similar experience during extensive NumPy coding where I thought, why am I not just writing this in Fortran.

</comment></comment></comment></comment></comment></comment><comment><USER13> The title is link bait to the point of nearly trolling. He didn't do his research, he should have jumped on the Google group or Stack overflow or something before writing this. Someone named Mike in the comments on the OP comes up with a fix that uses Java primitives and that is very fast, in the range of his Lush examples.

[http://scottlocklin.wordpress.com/2011/11/30/only-fast- langu...](http://scottlocklin.wordpress.com/2011/11/30/only-fast-languages- are-interesting/#comment-2529)

There's almost nothing to see here, except maybe that there should be better documentation on this kind of optimization.

</comment><comment><USER14> All the clojure examples test linked lists!

The first example lets lazy evaluation of the random numbers leak into the timing, toss a (dorun tmp) before the timing for a little more sense.

The type annotation ^doubles is useless - it's telling Clojure to expect the definition to get an array of doubles, but then binds it to the same old linked lists.

<comment><USER15> Can you fix his code and paste it? Why not have him run the bench and post it as an update?

<comment><USER16> Based on the work of a previous commenter, I posted this code in the blog comments:

      (defn add-rands []
        (let [ds (double-array 30000000)]
          (dotimes [i 30000000] (aset ds i (Math/random)))
          (time (areduce ds i res 0.0 (+ res (aget ds i))))))

This adds 30,000,000 numbers in 73ms on my machine. His Lush code added 30,000,000 in 180ms. I estimate my computer is twice as fast as his, putting them on par. Hopefully he will run the code so we can see all the run times on the same machine. (I never could get his Lush code running.)

Of course, the Clojure code here is fairly involved to do some basic stuff, but if you did things like this often it would not be hard to add some nice syntactic sugar over it.

</comment></comment></comment><comment><USER17> To me, this reads like someone who used C to add a large list of numbers recursively and concluded C was trash because they ran out of stack.

There's no denying there is a specific problem. People are certainly entitled to decide that solving that problem is too much hassle for them. But how seriously should we take their opinions when they do that?

I'd say it depends on the quality of the effort they did invest. In this case, the OP admits that they used the wrong data structure in Clojure and the right one in Lush, which makes the entire exercise meaningless.

<comment><USER18> <http://pastebin.com/2fGefex4>

      $ gcc -o addalot --std=c99 -Os addalot.c
      $ ./addalot
      [1500117.315354] 0.000032 per iteration on average.

Works fine for me.

<comment><USER19> This is not the correct C program, this is a C program for the compiler with tail call optimization (or with the stack large enough for it to work). There's no TCO in the C standard.

<comment><USER20> There is no restriction against TCO in the C standard either. TCO is a valid optimization for a compiler to apply. So what is incorrect about it?

<comment><USER19> Because it relies on the particular implementation of C compiler, not on the C standard. Take -Os flag away or use a compiler that doesn't have TCO, and the program has a bug.

See also:

* using memcpy() for overlapping regions (relies on the particular implementation of memcpy(); was exposed by a change in glibc - <http://lwn.net/Articles/414467/>);

* memory aliasing assumptions;

* passing NULL, 0 to memcpy() (<http://code.google.com/p/spiped/source/detail?r=8>);

etc.

<comment><USER20> It is ansi C standard code. There is an implementation limitation (stack size) that this program runs into. However that doesn't violate the C standard in any way, because the standard doesn't specify available stack space.

So the program is compatible with certain C implementations in certain configurations. Given the C standard allows a C implementation to pick any stack size they like (including zero) we could claim that about all valid C programs that make any use of the stack.

</comment></comment></comment></comment></comment></comment><comment><USER21> Languages where the upgrade path to fastness isn't horrible are okay with me also. In Common Lisp, for example, you can start adding in type declarations in speed-critical areas, which Clojure also has something similar to (not as familiar with it, so not sure how it compares to CL's type declarations).

</comment><comment><USER22> Probably should have added "for large-scale numeric computations" to the title :P

<comment><USER5> Yes, but then the flamebait/trolling factor would be gone. The title is such obvious flamebait that I hesitated whether to flag it.

</comment></comment><comment><USER23> Here is another place where Go hits the sweet spot between performance and expressiveness/simplicity.

Also by giving you control over how memory is laid out you can be much more efficient both in space and time, and when you need to go even faster you can optimize things quite tightly.

</comment><comment><USER24> Guy Steele said it better though. He wants not the fastest language, but the fastest way to get to the solution. It may mean that the language isn't as fast to run, but faster to program.

</comment><comment><USER25> Interesting that the people who complain about performance are almost always in, ahem, 'quantitative finance'? The LMAX stuff, this guy...

I'm just a simple caveman, but I can't help but think the world wouldn't be dramatically worse off if the HFT bots ran a touch slower.

</comment><comment><USER26> Learn to be more calm and patient. Maybe you need to think in another way, if you use another language and another VM. Maybe this language or VM really isn't strong for what you want to do, but for what other tasks.

Also you might stop thinking in absoluta. There are no fast languages. Every good and well known language has their strengths and their weaknesses and all optimizations are a tradeoff. If you get stronger in one thing you MUST get worse something else. So if you have a fixed set of problems you really just need to find out which language solves your problemspace best. And if you find it, that doesn't say this language is better then the others.

</comment><comment><USER27> Synthetic benchmarks are rarely useful.

If you want to benchmark two languages you need to do this:

Find N coders skilled in language X and N coders equally skilled in language Y. Have all of them code several small but realistic systems of various kinds, then benchmark the results and compare. Better yet, benchmark real, live systems of comparable purpose built using different languages. Anything else leaves you open to having your results dominated by differences in level of coding skill, quirks specific to your synthetic benchmark, and effects that are only prominent for tiny, overly simplistic programs.

</comment><comment><USER28> Very well-written, but it's a non-story.

Check the comments. Mike has contributed a clojure solution using `double- array` that runs fast, without blowing up the heap with a linked list.

</comment><comment><USER29> But there are no fast languages, only fast implementations...

<comment><USER14> ... and benchmarks that compare linked lists to ontiguous vectors

</comment></comment><comment><USER30> Not sure what he means by "interesting". I'm often delighted to learn new languages.. and even ones that are only on paper.

</comment><comment><USER31> One more benchmark for Clojure fans:

      R> system.time(sum(runif(3000000)))
         user  system elapsed
        0.100   0.000   0.101
      R> system.time(sum(runif(30000000)))
         user  system elapsed
        1.037   0.020   1.058

not as good as lush, yet human syntax and Scheme scoping can compensate.

</comment><comment><USER32> Mathematica

      In[1]:= AbsoluteTiming[
       Nest[RandomReal[] + # &, 0, 3000000]]

      Out[1]= {0.3276005, 1.50067*10^6}

      In[2]:= AbsoluteTiming[
       Nest[RandomReal[] + # &, 0, 30000000]]

      Out[2]= {2.9952052, 1.5001*10^7}

Not bad I think.

</comment><comment><USER33> Oh god, you know what's just as bad as a slow language? That Wordpress iPad theme. Please stop using that, it's ridiculously unusable.

</comment><comment><USER34> So I think you should stop with clojure and start to code in asm.

</comment><comment><USER35> This guy should look at Scala: Functional, runs on the JVM, and has performance comparable to "normal" Java code.

<comment><USER36> You mean like this guy? <https://news.ycombinator.com/item?id=3292555>

Scala vs. Clojure is not something to discuss for this use case, I guess. As <https://news.ycombinator.com/item?id=3293261> points out in that other thread, you won't write (recognizable) Scala (or Java. Or Clojure) code anymore if you want the best performance.

<comment><USER37> With respect to the second link: It always helps to know your data structures & their purposes--no matter what language you use, recognizable or not.

With respect to performance: you might want to try writing a c-like solution and run the code distributed over several machines.

</comment></comment></comment><comment><USER38> A language can't be fast; a language is a notation. Only implementations can be fast or, perhaps, generate fast code.

For an example, look at GHC versus some toy-Haskell whipped up in Common Lisp. Now, with those two implementations to hand, is Haskell 'fast' or 'slow'?

<comment><USER39> _A language can't be fast; a language is a notation. Only implementations can be fast or, perhaps, generate fast code._

Theoretically, maybe. But it is nearly impossible to come up with an implementation for Ruby, that is as performant as a compiled C program (and retains the characteristics of Ruby).

So, it is definitely true that it easier to compile some languages to fast machine or byte code than other languages. As a consequence, people will call Ruby slow, and C fast.

<comment><USER11> > But it is nearly impossible to come up with an implementation for Ruby, that > is as performant as a compiled C program

PyPy is getting there.

JIT, Runtime type detection and path optimization go a long way. And it's much easier to write correct Ruby than correct C.

When I went to college, the HP-41 was HP's top-of-the-line calculator and all the rich kids had them. I had a BASIC-programmable CASIO PB-700. In the end, I was able to finish tests in less time than it took the HP guys to program their calculators to spit the answer. I think it was the first time (1986 or so) I realized a more expressive programming language could be a decisive advantage over your competition.

<comment><USER40> "And it's much easier to write correct Ruby than correct C."

No, it isn't. C may be spartan, but its failure modes are predictable and manageable. A ruby program can be incorrect for a host of reasons completely unrelated to the program (interpreter bugs, garbage collection problems, etc.) and the language as a whole provides features (dynamic typing, method injection, exceptions) that make it harder to write correct programs.

Ruby may make it easier to write _programs_ , but it definitely doesn't make it easier _correct_ programs.

<comment><USER41> Eh, Ruby's failure modes are predictable too. I've never tracked a bug down to a "garbage collection problem", whatever that is. But I certainly have come across problems with C's lack of type safety, lack of memory safety, lack of GC, etc.

</comment></comment></comment></comment></comment><comment><USER9> Or you could just use java...

The title says only fast languages are interesting, then rules out using Java because it's not lispy enough :/

Either you want speed, or you want your favorite syntax and high level stuff. You can't have both.

FWIW My favorite syntax happens to be c/java/assembly type stuff. I'd hate to be one of the developers who hates those, must put you at a big disadvantage - as shown in the original post.

<comment><USER42> Why not? Apparently lush gets it right: C-like speed on numerics with a Lisp- ish syntax this guy likes. Yes, C-style stacks are going to beat Lisp-style closures; but there is no reason why a "fancy" language can't do fast matrix operations, which is 99.9% of numerical code anyway.

Even Scheme has (rather un-Lisp-ish) vectors in addition to the standard linked lists.

<comment><USER43> > C-style stacks are going to beat Lisp-style closures

It has been a long time since the "λ the ultimate..." series of papers gave the lie to this myth.

</comment></comment></comment><comment><USER44> Remeber kids "real" programmers use FORTRAN

<comment><USER45>
        real, dimension(30000000) :: a

        call random_number(a)

        print *, sum(a)

That's 30 million doubles, takes 0.04s on my machine.</comment></comment>


Recursive Make Considered Harmful (1997) [pdf] - <AUTHOR> http://aegis.sourceforge.net/auug97.pdf

<comment><USER2> This brings back some memories. While it's nearly 20 years old, it's taken a surprisingly long time for this to become widely understood and tackled.

Even today, tools like Automake default to recursion. It offers a non- recursive mode if you explicitly enable it and adapt your code to use it. I did this for my projects when the support was originally added, and the improvement is noticable, from both a speed point of view and overall maintainability. If you're not using Makefile generators, the effect is even more dramatic.

Today I use CMake for all new projects and have converted from Automake for some older projects. This is always non-recursive but split up into separate files. Having a global DAG of dependencies for the whole project and being able to run a parallelised make over a huge source tree is a wonderful thing to behold, and greatly reduces build times.

</comment><comment><USER3> Am I alone in my annoyance of "Considered Harmful" named papers?

"Considered Harmful" considered harmful. And annoying.

<comment><USER4> The fact that this is nearly 20 years old gives it a pass in my eyes. I certainly agree for anything new, though.

</comment></comment><comment><USER5> I recently spent a week replacing all Makefiles in a reasonably complex embedded arm project I maintain with apenwarr's redo [1] (revamping our cobbled-together CI).. Which allows recursive make structured .do files, without tbe downsides - global dependencies and build state is cached across invocations in a throw-away .redo directory. It's an absolute joy to be able to stamp things that aren't files (eg docker containers) and just use one syntax (script of your choice) to orchestrate builds.

Cross-compiled kernel, bootloader, custom packages, full distro rootfs to final sdcard image without a single Makefile. I owe that man a beer.

[1] [https://github.com/apenwarr/redo](https://github.com/apenwarr/redo)

<comment><USER6> This is an interesting anecdote, but we wouldn't really expect you to waste a week doing something pointless like this and then tell us it wasn't awesome. You'd experience cognitive dissonance, so in order to avoid the dissonance of admitting that that redo is not really much better than make (if at all) you are just singing its praises.

<comment><USER5> I spent a week pulling apart our old build scripts (which were dysfunctional) and putting it all back together again with something new. I'd have done almost the same amount of work if I had stuck with make. In fact I spent two days doing just that prior to my redo adventure: I gave redo a whole day, and found I'd achieved a lot very quickly despite never having used it before. So I completed my spring cleaning with redo.

Edit: I'm not singing redo's praises because I think the world should stop using make; fundamentally redo has potential scaling issues for very large codebases, but for the other 99.9% of projects if you want to explore an alternative, you could do much worse than djb redo.

</comment></comment></comment><comment><USER7> Pretty much anything to do with make ends up being harmful, in my experience. It's just not a good language.

<comment><USER6> If good is defined in terms of economic utility, then Make is possibly the best language of all time. The majority of the world's compute infrastructure depends on make. (See what I did there?:)

<comment><USER7> Ha!

</comment></comment></comment><comment><USER8> AOSP's build system is based on non-recursive make. I like it quite a bit.</comment>


Ask HN: Do you sell a product/service? What do you offer your prospects? - <AUTHOR>

I'm curious about the process of some salesmen over here.<p>If you talk to the prospects, which services do you sell? <comment><USER2> I works solo and tend to find the place I could be of use. My customers don't know technology and are going to me for solutions. I sell customer specific solutions. I do this because I like to learn new things all of the time. Another approach would be to sell the same thing over and over again. AKA milking it. Milking it is is only valid for a limited time and is vapid.</comment>


Overcoming Bias: Expelled Beats Sicko - <AUTHOR> http://www.overcomingbias.com/2008/05/expelled-beats.html <comment><USER2> Belongs on Reddit, at best. Does not belong here.

<comment><AUTHOR> I picked it for HN because it was out of the ordinary. If it was about Sicko beating Expelled, then I'd agree with you.</comment></comment>


Benford's Law - <AUTHOR> http://www.rexswain.com/benford.html <comment><USER2> It is interesting to consider how effects like this operate at different levels.

For example, if I picked up a coin, flipped it 6 times, and got heads each time, then I might reasonably be suspicious about the coin. On the other hand, when someone claims to have flipped a coin 200 times, it is the ones who never get 6 in a row that are suspect.

Similarly, a tax return that does not have numbers beginning with 1 is certainly suspicious. On the other hand, if you gave me a million tax returns, and _all_ of them had lots of numbers beginning with 1, then I would be suspicious of the collection as a whole. Benford's Law deals only with probabilities, after all; we should expect some deviations from what it predicts.

Given the sizes of data sets that governments deal with, the ideas outlined in this article can certainly be useful. However, the virtual certainty of false positives is something that also needs to be dealt with. It is to be greatly hoped that these ideas are implemented in the context of human wisdom and manual fact checking, and not merely as a yes/no way of determining who gets treated like a criminal.

In any case, this was a thought-provoking article. Thanks for posting.

</comment><comment><USER3> I have a copy of Nigrini's book. I've tried getting copies for my company, but other than the occasional $200+ used copy on Amazon, it appears like this book isn't just "out of print" but withdrawn from the market (the publisher sells training now, not books that anyone can read).

[http://www.amazon.com/Digital-analysis-using-Benfords- Law/dp...](http://www.amazon.com/Digital-analysis-using-Benfords- Law/dp/B0006RJJRC/)

<http://www.nigrini.com/data_analysis_books.htm></comment>


Climate change: Meet the lab-coat liberals - <AUTHOR> http://www.politico.com/story/2017/07/23/liberal-scientists-trump-climate-change-240852 <comment><USER2> Where did it explain why those scientists running for office are liberals?

One of the arguments by a candidate is: 'Do you want your kids going outside at recess? Yes? OK, then we need to have protections for air quality in place.'" If this is a liberal-only view, then what's the conservative view?

Nor do I think it's specifically a liberal view. Nixon, for example, put the EPA in place using a similar argument.

There's the general view that these candidates 'cast themselves as a counterforce to the Trump administration's dismissal of climate science and de-prioritization of innovation funding.' That seems to say that current Republicanism = conservatism, and therefore policies opposed to Republican politics = liberal. But that's not true.

There's the argument that "Researchers have long bemoaned stagnating federal investment in innovation". As I recall, the large government funding of research and innovation started during WWII and continued for decades under both parties. For example, ARPA started under Eisenhower, a Republican. In fact, it was a Democrat, Mansfield, who pushed the law which required [D]ARPA to work only on military projects, rather than basic science. [https://en.wikipedia.org/wiki/DARPA#Later_history](https://en.wikipedia.org/wiki/DARPA#Later_history) . So it's not like this is an essentially liberal policy either.

Finally, a comment about 'However, Brown said, "Where I question scientists running for Congress is more in their … power of public persuasion."'. Like Thatcher, B.S. in Chemistry with a dissertation on the gramicidin structure, who worked as a research chemist?</comment>


Michigan makes strides in keeping entrepreneurs on 'Third Coast' - <AUTHOR> https://www.crainsdetroit.com/voices-michael-lee/michigan-makes-strides-keeping-entrepreneurs-third-coast#disqus_thread <comment><USER2> Duo security isn't really in Detroit. They are in Ann Arbor, which is much different.

Ann Arbor is home to the University of Michigan and many talented engineers that graduate there.</comment>