Why a career in computer programming sucks (2007) - <AUTHOR> http://www.halfsigma.com/2007/03/why_a_career_in.html

<comment><USER3> I'd respond to the author if I could but the article is from 2007 and comments are closed.

The author tends to cite jobs in law and finance as better routes of work. I'd disagree. Only graduated recently (2010) but I went to a T[op]14 school. I've since worked at two small law firms (personal injury and foreclosure) and also abroad as a financial analyst for a real estate division of a conglomerate in Asia. I'll try to be short about my points.

1\. While law and finance don't necessarily suffer from the same knowledge turnover rate as programming, they do suffer typecast-inducing problems. Lateral movement among subfields is extremely difficult. This becomes a bigger problem if the first field you land in is meant to be a stepping stone.

2\. Prestige is bullshit. I've associated with V5 lawyers and Bulge Bracket bankers. Very few of them are not socially awkward. You may hear rumors about "models and bottles," but rest assured, it's mostly just bottles.

3\. Foreignization is a growing concern for law and automation has been a huge concern for finance for a while. There are various work arounds to the rules regarding unauthorized practice of law. As for finance, there are a few small documentaries lamenting the fall of the floor trader. Guess who's been replacing them?

4\. Management roles are nearly ubiquitous. That said, you do get escalating responsibilities in law. The problem is, will you last the grind leading up to it? A good friend of mine once messaged me while I was working abroad. It was 2a.m. in NY at the time. He told me his entire week was spent indenting, printing out, and placing into a folder a table of contents for a case. Among my friends, he's at the best law firm out of all of us.

5\. Conditions in law and finance are part of the golden handcuffs you graduate with. They're good, no doubt, but they come at the price of lots of hours. Those who work in law are at the mercy of clients. Same could be said about finance in some areas.

I responded to this, not to say that a career in computer programming doesn't suck. It might. But the grass is always greener on the other side, and from where I'm standing, my lawn is looking pretty brown. I responded because I disagree with the underlying message: you are better off getting a law or finance job through a law degree or MBA. Degrees aren't measures of success and they aren't golden tickets to it either. There are pros and cons to every career path. Just have to figure out where, for you personally, the former will outweigh the latter.

TL;DR: law and finance sucks too. But in the end it all comes down to personal preference.

<comment><USER4> > But in the end it all comes down to personal preference.

Yep, I have always chuckled when I see someone trying to decide what career field to go in to based on how much money they imagine they will make. In any career where there is oppurtunity to make large sums of money there are 10,000(,000,000) other people, as smart or smarter than you, scrambling to do the same thing. If you get into a profession to make money and not due to a passionate interest in the area, you are unlikely to rise to the top no matter how clever you consider yourself to be. It is one of the great paradoxes. Some of the smartest, most talented people I know in the field (and also very likely to be in the top earning bracket) are MUCH more motivated by passion and interest in the area than paycheck. Conversly most of the people I have met that are motivated primarily by paycheck size are, honestly, a lot less talented than they believe themselves to be and not really the 'in-demand' types that would allow them leverage to get the greater paydays they seek.

</comment></comment><comment><USER5> Other fields certainly are not immune to the declining value of knowledge capital. Ask any older auto mechanic how much his knowledge of carburetors is worth these days, just as one example.

Any profession that works with continually advancing technology is going see this effect. Granted it does seem more pronounced in the computer field... but yet there are some areas where you don't see it so much. If you are a "C" programmer, everything you've learned over the decades is still relevant and useful. Unix system administration is another example. Yes things change, but a lot of the old knowledge, e.g. tools like sed and awk are still plenty relevant.

Also the author doesn't acknowledge that a lot of knowledge transcends language. Knowledge of data structures and algorithms carries over as language fads come and go, and there's a lot of core knowledge you don't lose in the transition from one to the next.

I've been in the software profession for over 20 years, and what I've noticed is that the stuff that fades away quickly is the stuff that sucked from the get-go. COBOL? Sucked, now mostly gone. Mainframes? Sucked, now mostly gone. Visual BASIC? Sucked, now mostly gone. C? Dangerous, but powerful... still around. Unix? Pretty fun, very flexible, still around. SQL? Still one of the best ways to work with data, still around.

<comment><USER6> _Also the author doesn't acknowledge that a lot of knowledge transcends language._

In my experience, employers don't know that, either. Neither did college admissions, come to think of it.

</comment></comment><comment><USER7> I disagree with many of the points here. First, it sounds like this guy is on the Microsoft Treadmill (TM). It's a widely know fact that MS routinely retires technologies and platforms at a breakneck pace (I mean, really? you're going to retire a whole programming language -- VB 6.0?).

Well, I work in C and C++ on linux/unix platforms. The C programming language has been around for decades and will continue to be around for decades to come.

He keeps saying that old knowledge is worthless. This isn't entirely true, as I believe that this knowledge builds up into a kind of intuition. Intuition gained over several years allows seasoned programmers to very quickly pick up on new concepts, programming languages or platforms.

I still can't get over the fact that MS retires programming languages. It's almost as if they want to squeeze more money out of their customers, so they cook up some new technology that is the _must have_. Oh, that's what they're really doing? Oh, ok.

<comment><USER8> It's a good point. In videogame development, C has been a standard for a very long time. Wolfenstein 3D was written in C, 20 years later, Modern Warfare is still being written in C (albeit a bit modified). Most other game development is done in C++, also not exactly a brand new technology.

Had you invested correctly in the right languages, you'd be doing just fine today.

</comment></comment><comment><USER9> wow, this is terrible.

"So what advantage does a 60-year-old .NET programmer have over a 27-year-old .NET programmer when they both have, at most, 5 years of experience doing .NET programming? Absolutely none."

Umm, I would say that 40 years of experience building software applications is a pretty huge advantage. I've been writing iPhone apps longer than most of the older guys I work with, but that doesn't mean that I know more about development than they do.

Languages and technologies may be temporary knowledge capital, but they're also one of the least valuable things a good developer will have.

As far as prestige and foreignization? It's amazing how much things can change in 5 years. Programming is (sorta) becoming cool thanks to things like The Social Network. 2/3 major operating systems are developer almost exclusively in the United States. All major programming languages are in English. Software development isn't going anywhere in the US.

<comment><USER6> _Umm, I would say that 40 years of experience building software applications is a pretty huge advantage._

I have to admit, I don't see a whole lot of gain after about five years. As everyone is saying, CS knowledge is timeless, but aside from the basics, it's really not that useful outside of research positions. _Most_ of software development is making CRUD apps, integrating APIs, and other tedious but non- complex stuff like that.

Regarding prestige, most of the time when I'm at a non-techie party, when asked what I do, people have _nooo_ idea what "software engineer" means. :-)

<comment><USER10> _Most of software development is making CRUD apps, integrating APIs, and other tedious but non-complex stuff like that._

Isn't that sort of like saying that most of the restaurant business is flipping burgers? Just because something is more common, that doesn't mean you won't be able to move up the food chain a little after _40 years_ of programming. Companies still have plenty of hard problems to solve in network performance, hard drive performance, UI architecture, cryptography....

<comment><USER6> If the vast majority of jobs are in burger flipping, and the limited number of elite chef positions are generally filled by a small subset of candidates (e.g. top schoolers) who were on the elite chef track from the get go, then yes, it's exactly like saying that.

You don't really "work your way up" from years and years of CRUD apps and API gluing to hard CS. In fact, if you get a CS degree and don't go straight into hard CS, you will forget most everything you learned in a few years, not to mention miss out on years of focused practice.

<comment><USER8> I agree with that. I'm personally stuck in one of these positions and it's a black hole that's really hard to get out of. Once you've learned most of what there's to learn about CRUD implementation and gluing them together, you need to get out as soon as possible or a couple of years down the line you'll simply not be qualified enough for any other position in CS.

That or you can write code in whatever spare time you might have from your 8-10 hours a day job. Based on what's said around HN, people putting in 14 hours a day coding are not that uncommon these days, so perhaps it's something programmers are better get used to. Remember to blog, have a rich github portfolio, contribute to OSS and run your own consulting consulting company in the spare time from your full-time job.

</comment></comment></comment></comment></comment><comment><USER11> My dad is a 60 year old lawyer, working his tail off for 40 years straight in a suit every day, spending his wealth to look as rich as friends. I am looking forward to being unemployed at 60, after working 40 years, on a pile of money saved from a career spent on intellectually interesting work in comfortable class these

</comment><comment><USER12> Well, a lot has changed since 2007. I'd argue that programmers are held in high regard now--witness all of the news articles in the past year about "software engineers taking over the world". Further, the work conditions might be better? Maybe it differs by where you're working, but every hip software company out there touts its awesome facilities and free food and free everything.

<comment><USER13> >I'd argue that programmers are held in high regard now--witness all of the news articles in the past year about "software engineers taking over the world"

This doesn't prove much. The media you follow might have these articles, but most of the world still don't know much about programmers or hold them in high regard. If you work in Silicon Valley, I'd say it's a bubble, outside of which people think very differently about ICT.

</comment></comment><comment><USER14> I have trouble thinking this 60 year old programmer exists. There were only 2000 computers in existence in 1960. Today a 60 year old programmer that spent a _career_ in computer science is a very small group of people.

I'm going to wait and see how this really turns out.

<comment><USER15> 1960? If one's career is considered to start at age 22, a 60-year-old would have started in 1974.

<comment><USER14> Good point :) To be fair I started writing code much younger, but I still chose a bad date.

I still think my main point is valid.

</comment></comment></comment><comment><USER16> > [P]eople born in this country have more rights to the money being created > here than foreigners. Asian countries feel the same way about foreigners. > Asian countries are, typically, a lot less open to foreign worker immigrants > than is the U.S.

I would like to know why being born in a given country should entitle you to more or less opportunity than anyone else who wants to do business in that country.

I would settle for an explanation of how bad immigration policies can be justified by pointing to states with worse ones.

<comment><USER17> Easy: the government of any given nation exists to promote the well-being of its citizens and absolutely nobody else.

<comment><USER16> I fear you are confusing positive with normative claims, even if your highly doubtful positive claim is true. How do you make the citizens of a given state better off on average by preventing them from engaging in mutually voluntary associations with whomever they want?

When you read that San Jose is one of the fastest growing cities in the US, do you conclude that San Jose will soon be a desirable place to live and do business, or that undeserving foreigners from other states are "taking San Joseans' jobs?"

<comment><USER18> I fear you are confusing counties with countries.

<comment><USER16> The fact that the OP is confusing a positive claim: "states often exhibit little or no regard for the people outside their boundaries" with a normative claim "states _ought_ to act that way" is plainly evident.

That counties and countries are two different things is also obvious, but you need to offer reasons to believe that they are morally distinguishable with respect to economic growth and immigration.

<comment><USER18> Your analogy doesn't hold. San Jose is not a country, and it has no legal right to prevent US citizens from entering its borders. If (eg.) more people enter than its hospitals or roads can comfortably handle, then it can appeal to the Federal government for assistance. The US cannot.

I don't think the original statement is entirely true either - I can think of plenty of countries which don't promote the well-being of their citizens - <USER2> I would class those as broken countries, rather than trying to say that the notion of a country is broken. Certainly most western countries exist to benefit their citizens.

<comment><USER16> The analogy holds precisely for the reason that San Jose does not consider itself beleaguered by the influx of immigrants who want to live there. The fact that you could entertain thought experiments in which the net consequences of immigration are negative (e.g., a giant flashmob of 50 million people immigrates simultaneously) does not suffice to show that San Jose's hospitals and roads are overwhelmed in the actual world.

In the actual world, San Jose is not in fact appealing to the federal government for assistance; it is reaping the benefits that attend a growing metropolitan population and tax base. On average, San Joseans are better off when more people become San Joseans, for all the same reasons that New York is a more desirable place to live (as measured by the demand for housing) than Wichita.

I've never claimed that there are no states who do not take their citizens' interests into account. I claimed that states often take little or no consideration of the interests of non-citizens. In absolute terms, for example, malaria is a much more pressing human affair than corn subsidies. But corn subsidies primarily affect people within the US whereas malaria primarily affects people outside the US, so corn subsidies dominate malaria in contest for the attention of the US government.

<comment><USER18> There are plenty of cases where immigration can be negative, particularly in the short term, so controlling the amount of immigration makes sense.

In the case of corn subsidies you can argue that the political process has been derailed in favour of special interest groups. If you follow the chain from corn -> HFCS -> diabetes and heart disease, it's not even acting in the citizen's best interests.

Similarly, it's also trade issues that make malaria worse than it has to be. Screens for windows would make it much less likely to spread - but the material is too expensive for most of the people who really need it.

<comment><USER16> I don't mean to distract with the examples of corn subsidies and malaria. I don't think it's terribly difficult to find a plethora of examples in which a state's concern for rather trivial internal affairs dwarfs its concern with globally momentous affairs that happen not to affect its citizens. The fact that the spread of malaria could be, but has not been, mitigated by relatively cheap counter-measures just goes to show.

I am not claiming that immigration is an unalloyed good, nor that there are no caveats to consider. I am claiming that freedom of travel is a human right, and that this freedom is largely compossible with the flourishing of the new states into which immigrants move. I just cannot locate any moral claim I have against people who want to move to the part of the world circumscribed by US borders, nor any moral obligation they would have to recognize one. Where is the argument? I can certainly understand that citizens in certain industries would prefer that immigrants with similar skill-sets not immigrate, but protection from competition is not a human right.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Why is this 5-year old article submitted?

It's not that well-reasoned either. It's written by someone that does not have that much knowledge in the field, and his reasoning is amateurish.

Nothing interesting to see here.

</comment><comment><USER20> A career in doing stuff you don't like sucks. If you like programming, then you're not going to mind spending time to brush up on your skills. You just see it as shiny new technology & toys to mess around with :)

</comment><comment><USER8> Anecdotally, a relative of mine who's now in his 60s and has been a mostly unemployed programmer since the 1970s. He's yet figure out how object-oriented programming works, it's very hard in his words, although I don't think he complains much about it on the internet.

</comment><comment><USER21> Seems like this article has made the rounds here a few times already.

</comment><comment><USER22> Mediocre people will have mediocre lives. This is true for programming and (not surprisingly) any other career.

If after 40 years of programming all you have is temporary knowledge then you were a lousy programmer your whole life and still are.

<comment><USER6> Sounds like the confident words of someone who hasn't experienced much yet.

</comment></comment><comment><USER23> I didn't get very defensive here, you and I probably understand(even more considering it's 2012 and there's a lot of different stuff now) that a lot of this things are not 100% certain...but you gotta admit a lot of things are true of the profession and yes they will get to hit a lot of people(and us, maybe) with their pants down...

</comment><comment><USER24> The opportunity to work by yourself easily, build stuff, travel to any place and usually find a job.. terrible stuff!!

One of the only downsides I find. It can get tiring for your brain (and stressful if you are not working on a project you enjoy).

I guess it's not as fun and exciting as being a Mexican Wrestler.</comment>


FDA cracks down on thousands of websites for selling bad drugs - <AUTHOR> http://www.reuters.com/article/2012/10/04/us-fda-baddrugs-idUSBRE8930SN20121004 <comment><USER2> Title is incorrect. There is no evidence presented anywhere that any of the drugs were "bad". According to the article, the FDA has claimed that they were "potentially" fake, meaning that they didn't even try to verify that anything was actually fake, or couldn't find anything that was actually fake. If they'd actually verified something as fake, the article would've said so, unless you think they'd fail to boast about that.

<comment><USER3> Clearly the Internet is now teaming up with Canadians to poison our drugs.

</comment></comment><comment><USER4> > 18,000 illegal pharmacy websites and the seizure of $10.5 million worth of > drugs

What a fail... $583 in drugs per "illegal" website shutdown. I really don't like the US being the world police and it seems like they always do so on behalf of giant US based corporations (MegaUpload comes to mind, the counterfeit jersey bust, etc). Very dangerous territory.

Update: In other news, the DOJ announced a huge bust on Medicare fraud today to the tune of $430 million (and all that fraud is from just 91 people!). This is a real crime and it actually costs taxpayers money instead of the theoretical losses of a US based company.

<http://www.justice.gov/opa/pr/2012/October/12-ag-1205.html>

<comment><USER5> Those numbers are independent. Dividing the value of drugs over number of website shutdowns is a misleading stat. They made domain seizures for most of the takedowns. I'm guessing the drugs were taken from a few major players.

<comment><USER4> $10M in seizures for a worldwide bust is ridiculously not news worthy. This is at "street" value too, which for Viagra is around $10 a pill and for Tamiflu is a cool $50-100 per pack.

To put it into context, a decently large cocaine bust these days is "worth" orders of magnitude more.

</comment></comment></comment><comment><USER6> These drugs have been legally sold and manufactured in many countries. The use of the word "illegal" to describe them is hysterical and inappropriate. If the FDA wishes to regulate pharmaceuticals that enter the United States, that's fine; but the FDA's jurisdiction should stop at its borders. It looks to me like this crack-down had little to do with health and safety but a lot to do with protecting entrenched distributors.

<comment><USER7> Control over the supply chain is what stops fake drugs from reaching consumers. A few months back a number of vials, purported to contain a cancer drug, were found to be nothing but solution of saline.

If anything, you're going to see many more actions like this, the FDA is scared about the integrity of the drug supply (and apparently so are many other countries, based on the article).

<comment><USER8> A lot of these drugs were almost certainly made by competent, regulated pharmaceutical manufacturing firms in countries such as India. The FDA doesn't care - if it's not manufactured in FDA-approved plants they treat it just like they would a total fake, even if it's manufactured using the same methods and to the same standards as the genuine article, and they'll shut down any company that tries to sell them.

<comment><USER7> I don't disagree with your comment at all. However, I think the FDA's approach is "The easiest way to control unsafe drugs is to assume that anything that didn't come through approved supply channels is a fake."

It's a harsh way of approaching the problem, but you need to remember that the FDA suffers far worse when someone is harmed by a fake drug than if it seizes drugs that are safe.

</comment></comment></comment></comment><comment><USER9> _Action taken between September 25 and October 2 resulted in the shutdown of more than 18,000 illegal pharmacy websites_

I wonder if this means that 18,000 domain names were seized. And, I'd also love to see the list, given that the US has a tendency to add a few pet project domains to these seizure-fests.

<comment><USER10> I own the website drugcite.com, I instantly checked it after reading your comment. Seizures of this size really scare me for false positive reasons

</comment></comment><comment><USER11> Give the people what they want! Dangerous drugs like nicotine and alcohol are readily-available to most citizens. Whereas, pain medications and stimulants are so tightly controlled that they drive honest people to the Internet to obtain the drugs they can't afford or their doctors are afraid to prescribe.

</comment><comment><USER5> Original PR from the FDA: [http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/uc...](http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm322492.htm)

Looks like most of the sites are being shut down through domain registrars.

</comment><comment><USER12> This is very good news for those of us that are actually looking to start a legitimate online pharmacy.</comment>


The Linux Backdoor Attempt of 2003 - <AUTHOR> https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-2003/ <comment><USER2> Ehh. I think this article overstates just how clever this backdoor is. With the entire kernel source to play with, and the underlying assumption that the CVS change would pass into BitKeeper without a thorough review, there had to be much more subtle ways to insert a local privilege escalation.

Besides, it's not as if Linux local privilege escalations are incredibly rare, and it would be surprising if anyone with enough money, time and expertise couldn't uncover them at a rate sufficient to make this kind of skulduggery unnecessary.

<comment><USER3> What's clever about that code is that the conditional will always fail. The assignment expression setting the uid to 0 will itself evaluate to 0, which will cause the conjunction to evaluate to "false." On first glance, the code makes you believe that the body of the conditional is necessary, when it's in fact dead code. That's nice camouflage.

<comment><USER4> I like the extra parens in the if condition. It's genius.

On the face of it, it appears that the parens are to ensure correct operator precedence because a bitwise OR is used (a common idiom because bitwise operators have the wrong precedence versus comparison in C).

But that's not what the parens are really for! They are there because gcc complains about assignments inside of conditionals _unless_ you put parens around it.

</comment></comment></comment><comment><USER5>
      if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
            retval = -EINVAL;

> ...A casual reading by an expert would interpret this as innocuous error- > checking code...

Wait... Wait... A casual reading by any expert should result in the question "why is this code setting current->uid to 0?"

After all, in case said expert has forgotten the difference between = and ==, this little bit of code all by itself has _two_ correct reminders about what those operators actually do.

<comment><USER6> Even better: Emacs has cwarn-mode, which by default highlights = (assignment- equal) in tests in BRIGHT RED. I'm sure Vim has something similar; maybe the customized version of uEmacs/PK 4.0.15 Linus uses does not.

[http://www.emacswiki.org/emacs/CWarnMode](http://www.emacswiki.org/emacs/CWarnMode)

[http://en.wikipedia.org/wiki/MicroEMACS](http://en.wikipedia.org/wiki/MicroEMACS)

[http://web.archive.org/web/20061124122032/http://www.stifflo...](http://web.archive.org/web/20061124122032/http://www.stifflog.com/2006/10/16/stiff- asks-great-programmers-answer/)

<comment><USER7> Most IDEs do that today - but I wonder how many did that in 2003?

</comment></comment></comment><comment><USER8> The author is talking down and assumes too many people just learned C yesterday. An assignment of a variable called uid to 0 inside of an error check is waaaay too transparent. It's impressive that it made it into the cvs server with no history but the actual weakness relies heavily on nobody ever looking at the code. It would be spotted right away by anyone remotely competent who glanced over it.

<comment><USER9>
        It would be spotted right away by anyone
        remotely competent who glanced over it.

I'm not so sure. I'm a professional programmer mostly working in C++, and I didn't see the problem on first read-through. It took looking carefully before I saw it, and if I hadn't already known that these two lines contained a vulnerability I might not have noticed. I could see this being missed in a code review.

<comment><USER8> Going back to my earlier point, its success relies on people not seeing it. So I would think its ability to pass a code review would ultimately depend on how many other lines of code it has to hide amongst. If you are reviewing a huge diff and this is hiding somewhere, then OK, maybe I buy it, but it's pretty transparently wrong.

Another test it fails: even if it were == as they are trying to make people think, why would this return EINVAL only if the user is root? There aren't a lot of real world examples where you would want that. It pops out right away as a bogus check that makes no sense, and surprise surprise, it also sets the uid to 0, my guess is in a place where it makes no sense to even look at uid, and very superficially hiding as a "rookie mistake"...

</comment></comment></comment><comment><USER10> Quite disturbing to think about it. There are probably millions of lines of code in the kernel, how confidently can you say that there's no other instance of something like this slipping in? I mean it's just one damn '=' character.

<comment><USER11> The more I think about it, the more programming (and computers in general) frustrate me. In the non-digital world, the general rule is small mistakes lead to small consequences (for example, overcooking food will result in it burning and getting worse over time).

<comment><USER12> But not watching your cooking process can also result to blowing up whole building due to gas explosion. More often it would be just bad meal, of course. But more often small mistake in a program will just result to a compile error or bad behavior.

</comment></comment></comment><comment><USER13> I wonder how many millions of dollars of damage has been done by the bone- headed equality/assignment syntax in C?

<comment><USER14> The problem is overstated, but using := (or ->, or whatever) for assignment and = for comparison hasn't ever seemed like a bad idea.

</comment></comment><comment><USER15> There was no shortage of non-proft, non-nation-state actors engaging in backdooring open source and commercial codebases during this time. No reason to believe this was related to the NSA.

<comment><USER16> I agree, I've worked with the NSA (early 1990's when they still had some ethics) and this hack doesn't feel like what they would do.

I'm not an NSA expert though, I declined to get clearance, so salt my opinion a bit.

</comment></comment><comment><USER12> Doesn't compiler complain about assignment in condition?

<comment><USER17> I don't see any warnings when compiling "if (1 && (i = 2)) {...}", but there is an warning when compiling "if (i = 2) {...}". This is using gcc 4.7.2 with -Wall.

<comment><USER18> Both gcc and clang appear to lack any way to generate a warning in the first case. Something like splint ([http://www.splint.org](http://www.splint.org)) does, which is a good argument for including that into a C developer's workflow.

<comment><USER2> clang and gcc don't warn on this because real large codebases have an (unfortunate?) number of assignments inside boolean expressions. Most of them are intentional and at least some significant fraction are correct.

Taking advantage of assignment-as-an-expression is idiomatic in a fair amount of code I've seen, at least.

Stuff like:

        /* check_something returns non-zero on error */
        if (need_to_check && (status = check_something())) {
            handle_error(status);
        }

The clang and gcc folk tend to avoid adding default (or even -Weverything) warnings that will trigger on entirely valid, at least marginally common code, even if the style choice is problematic.

<comment><USER18> > clang and gcc don't warn on this because real large codebases have an > (unfortunate?) number of assignments inside boolean expressions

Definitely. I personally find that style bad because it's concealed a far number of bugs in the past (either things like the =/== confusion or simply logic errors when the line became long enough that scanning it is non-trivial) but the only way that could fly for a compiler would be as a flag or pragma allowing you to opt-in for valid-but-discouraged style warnings and that's served well enough by existing linters that standardization isn't worth the cost of moving it into a compiler.

</comment></comment></comment></comment></comment><comment><USER19> this is pretty interesting, thanks for posting.

<comment><USER20> Are those options for wait2 in common use, causing auto-elevation for many programs? It seems too easily accessed to be an NSA backdoor.

<comment><USER21> We seem to have forgotten that the NSA is not the only or even necessarily the most interesting entity looking to privilege-escalate and/or steal data. Corporations and individuals are malicious also.

</comment></comment></comment><comment><USER22> We still dont have a report on the kernel.org hack of 2011.

Many people say, calm down, its git they cant have inserted backdoors etc without messing up the git history/changelog/hashes/whatever. But what if, git was modified and backdoored previously to hide some objects/changes? How would such an attack work? Lets say you discover a problem in git, which allows you to omit changesets in its output. How would that work to backdoor the kernel?

<comment><USER23> Older versions of git would tell you the hashes were wrong. Implementations of git in other languages would tell you the hashes were wrong. Manually checking would tell you the hashes were wrong. It's just not feasible.

EDIT: Plus, git is stored in git, so you'd need to backdoor git first... ;)

<comment><USER24> Bootstrap operation from hell [1]

[1] - [https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...](https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290)

<comment><USER25> Thanks for the link... I've never read the README before, and it's very entertaining. Now I'm going to have "goddamn idiotic truckload of sh*t" echoing through my head all day

<comment><USER26> I read, when the project was introduced, but forgotten it a long time ago. Goddamn Idiotic Truckload of Sh*t Hub, Inc. would make a memorable name for an incorporation.</comment></comment></comment></comment></comment>


Fix All Computer Problems - <AUTHOR> https://github.com/sricola/fix-all-computer-problems

<comment><USER2> My computer has a problem that causes it to fail to shut down. Will this script fix that? ;)

<comment><AUTHOR> LOL</comment></comment>


Diffoscope: in-depth comparison of files, archives, and directories - <AUTHOR> http://diffoscope.org/ <comment><USER2> $ git clone [https://anonscm.debian.org/git/reproducible/diffoscope.git](https://anonscm.debian.org/git/reproducible/diffoscope.git) Cloning into 'diffoscope'... fatal: repository '[https://anonscm.debian.org/git/reproducible/diffoscope.git/'](https://anonscm.debian.org/git/reproducible/diffoscope.git/') not found

<comment><AUTHOR> The link was indeed posted a bit early. It is currently still named "debbindiff", but will be renamed soon. At the moment it can still be found here: [https://alioth.debian.org/plugins/scmgit/cgi- bin/gitweb.cgi?...](https://alioth.debian.org/plugins/scmgit/cgi- bin/gitweb.cgi?p=reproducible/debbindiff.git;a=summary)

</comment></comment><comment><USER3> It looks like this may be a premature announcement because the installation instructions don't work, specifically the debian notes.

If someone is listening, I would suggest adding a SYNOPSIS section to the documentation with the command-line usage. e.g., does it support 3-way base/local/remote diffs?

`git difftool` knows about a lot of these kinda tools.. if this one looks promising (it's free, so that's already a plus) then we can teach difftool about it. I guess I'll wait and see if it materializes.

Adding support to git is pretty simple: create `mergetools/diffoscope` with this (I'm guessing the cli syntax, but you get the idea):

        diff_cmd () {
            "$merge_tool_path" "$LOCAL" "$REMOTE"
        }

        merge_cmd () {
            if $base_present
            then
                "$merge_tool_path" --output "$MERGED" "$BASE" "$LOCAL" "$REMOTE"
            else
                "$merge_tool_path" --output "$MERGED" "$LOCAL" "$REMOTE"
            fi
        }

In an existing git installation, that scriptlet can be copied to `$(git --exec-path)/mergetools/diffoscope`. It can then be used as `git difftool -t diffoscope`.

</comment><comment><USER4> Looks great! Shameless plug: DiffPlug can also diff arbitrarily nested zip/tar/gz, runs on Win/Mac/Linux, and supports text/image/other stuff too. It's closed-source and GUI, but you can control it from the command line, and we're working on an Apache 2.0 API for building the differ plugins.

Open API for differs (totally incomplete, but we've already released some its pre-reqs): [https://github.com/diffplug/opendiff](https://github.com/diffplug/opendiff)

Archives and filesystems that we support: [https://docs.diffplug.com/1.6.1/Filesystems/](https://docs.diffplug.com/1.6.1/Filesystems/)

</comment><comment><USER5> Why not build a tool for every file format that simply dumps the contents of the file in a human-readable way. Then feed the output through "diff". That approach would sound more "unix-ey" to me.

<comment><USER4> Great idea! That would work well for a lot of stuff, but I don't think it would scale to diffing, say, two 4Gb iso files. Also, some structured content has user-hidden IDs which can help a differ, but they probably wouldn't show up in a "human-readable" representation.

<comment><USER5> The human-readable representation can be as long as you want. Also, one could embed checksums in the output, so that if non-displayed contents differs that would trigger an output by the diff command (granted, this way it is not so human-readable anymore because of the checksum, but it would still be a more modular approach).

<comment><USER4> I don't think diff will perform well on two 4gb inputs. I agree there should be a modular approach, but I don't think flat text is the best lowest-common- denominator. Your proposal would certainly work for a lot of cases though, and it is very unix-y!

</comment></comment></comment></comment><comment><USER6> Is this built on top of the standard Unix "diff" program?

</comment><comment><USER2> Cool! Reminds me of kdiff3 but can do terminal output. Nice.

</comment><comment><USER7> Repo seems to be down or invalid - anyone know where I can find the sources? I'd love to attempt to port this to OSX ..

</comment><comment><USER8> How does this differ from Meld or WinDiff?

</comment><comment><AUTHOR> diffoscope is now available in Debian sid.</comment>


The "Oh Crap" Moment: How do you know how much you know?  - <AUTHOR>

with apologies to Kathy Sierra...
http://joshwand.com/files/ohcrap2.png
I've had this experience with several of my startup ideas now... I learn more and more about a given problem space/market, and eventually I start feeling like I have a decent grasp of the situation. The new learning tapers off, until one day, I discover a whole new dimension I've never thought of, and I realize just how little I know about the problem.
I've come to expect a few of these "oh crap" moments early on, but I wonder what conclusions I should draw from these moments later on in the process? They tend to be rather discouraging, as plans need to be modified/rethought, and sometimes the viability of the entire project comes into question, as when you discover that there are a whole slew of other startups trying to solve the same problem as you, all of them further along than you are!
I wonder if sometimes it's worth ignoring the extra information entirely, and solving a simpler version of the problem instead? The extra information might not even be relevant if the project doesn't expand in that particular direction. EDIT: this doesn't apply as easily to the situation where you discover your competition...
Does anyone else experience these moments, and what have you learned from them?
UPDATE: added axes/legend to graph <comment><USER3> I've generally found that the best solution to a problem is also the simplest. If the complexity of your solution starts to grow more than linearly as you work on it, if it starts to look like the only way to finish it is through brute-force labour, then I've found that backtracking to right before things start to get complicated usually yields an "aha!" moment. A simple, elegant solution will be easier to implement and maintain, more fun and satisfying to work on, and will most likely even solve the problem better.

You don't always have that luxury, of course - some problems don't necessarily have a simple solution. But for me, when things get complicated I take it as a sign that I've taken a wrong turn somewhere.

I'm not sure if this actually answers your question. ;)

<comment><USER4> That is generally along the lines of what happens when working on my own stuff . The real "Oh crap" moments come when I'm trying to figure out what someone else did.

</comment></comment><comment><USER5> The great news is that this same mental complexity trap will trip up 99% of your competition. If you can avoid it you have a significant advantage. Look to the grand master: Steve Jobs. Who else would have had the balls to make a beautiful little music player that did almost nothing but play music? The Microsoft Zune is what most people will do when they start off to make a music player and realize how much they _could_ do.

The most difficult part about a simple solution is having the confidence to see it through. The ability to not feel ashamed or embarrassed when people ask "Why doesn't it have X?".

Inspiration from Steve Jobs, on what is essentially The WiFi Question:

NEWSWEEK: Microsoft has announced its new iPod competitor, Zune. It says that this device is all about building communities. Are you worried?

STEVE JOBS: In a word, no. I've seen the demonstrations on the Internet about how you can find another person using a Zune and give them a song they can play three times. It takes forever. By the time you've gone through all that, the girl's got up and left! You're much better off to take one of your earbuds out and put it in her ear. Then you're connected with about two feet of headphone cable.

More great stuff in this article: <http://www.msnbc.msn.com/id/15262121/site/newsweek/>

<comment><USER6> Mp3 players didnt have a lot of features when the iPod was launched, and I don't think a portable harddrive solution was particularly simple (engineering wise) at the time. The iPod won because it was portable and had a large capacity, mp3 players for many years were either one or the other even after the iPod shot to fame.

<comment><USER7> The iPod had a 1.8" hard drive when all the competitive MP3 players had a 2.5" hard drive, making them twice as large. People seem to forget how much smaller the iPod was compared to all the other hard drive MP3 players, I think this is the real reason it won.

<comment><USER6> Yep thats what I'm saying. It wasn't interface or brand, at least not until later. For a very long time I don't think there was a single other player with the capacity of the iPod at a comparable size.

</comment></comment></comment></comment><comment><USER8> I've gotten completely lost _following_ the competition who has been _trying_ to solve the same problem. I've realized their take and solutions will be different from mine. What I do now is write down every day the problem in one simple sentence .. e.g. "I hate traveling and every wifi is password protected!" I keep working the solution, knowing it will grow in complexity because i have to deconstruct it in order to work toward simplifying it. I then create a solution using a three step function for myself and other users. This has been helping me, especially when I get overwhelmed in thinking about more features and functions.

</comment><comment><USER9> Yes, I get these too. Pretty much every time I talk to someone who takes an interest in my startup, they raise some issue that I either hadn't thought of at all or hadn't thought about in the same way. That doesn't even cover the hacking-related 'oh crap' moments, but most of mine have been conceptual so far. It's to be expected: there are tens of startups in my space, I assume that some are technically better and many are worse.

As you point out, the hardest thing may not be the 'oh crap' moment but rather what conclusions you should draw from it, if any. In most cases I have elected to go simpler when in doubt. Other times I've decided to re-think various aspects of my project, but these are in the minority.

</comment><comment><USER10> You've just stumbled onto the reason that big companies take some many more people and so much more time than startups to solve a given problem - <USER2> don't (and can't) allow themselves to ignore the extra information and its complicated byproducts. Nevertheless these cos invariably started out small by solving one significant problem in a great way while overlooking all those other dimensions. In short, try to evaluate whether the extra information is truly a significant part of the core problem you set out to solve. If it isn't, postpone the solution. If you succeed based on your core solution you can worry about it later, when you'll have plenty of time and money to do so.

</comment><comment><USER11> Yes, I've noticed the same thing. My current idea is similar to several other start-ups. At times it seems like some companies could be competitors if only they changed their product offering a bit.

I think this is where the business/marketing side of the founders needs to kick in and be determined to differentiate and be better than what's out there.

It's all about providing value for a customer. You either need to provide a better value or have different customers. IMHO, a simpler version can be both good and bad.

Good, if you can start getting revenue and grow faster. Bad if it doesn't generate much revenue but slows you down with customer support and alerts your better funded competitors to your existence and plans.

</comment><comment><USER12> I think you are dealing with analysis paralysis. I think you should develop an internal weighting system on extra information. remember nothing beats the information gleaned from your own experience. I cant remember where but I read somewhere that the plan is unimportant but the planning is invaluable. Dont keep a plan just keep on planning and implementing. Each new Oh Crap moment is just another input to the ever changing and improving planning implementing process. IMHO.

</comment><comment><USER13> Maybe including names for the axes will made a better graph I guess Katty Sierra is happy when people use her style.

This may be a nice Creating Passionate Users post. ;)

<comment><AUTHOR> better?

<http://joshwand.com/files/ohcrap2.png>

<comment><USER13> Yeah! Much better!

I'm a fan of Katty Sierra and always read her creating passionate users blog. It's so bad that she isn't posting anymore.

</comment></comment></comment><comment><USER14> _"I wonder if sometimes it's worth ignoring the extra information entirely, and solving a simpler version of the problem instead?"_

 _Yes_. Always.</comment>


Show HN: I built simple API service gethttpheaders.com – Potential use cases? - <AUTHOR> https://gethttpheaders.com/ <comment><USER2> Even if you built a _service_ that implements this API, I don't see much use for that. Somebody needs to connect to you with HTTP to get what? HTTP headers?

<comment><AUTHOR> Yes. One use case is to find the package name of an Android app, which is returned from an AndroidWebview in the "x-requested-with" header. This could enable you to show a banner to Android users only or even do simple A/B testing.

</comment></comment><comment><USER3> Somewhat covered by existing HTTP testers, e.g.

[https://httpbin.org/headers](https://httpbin.org/headers)

<comment><AUTHOR> That's cool. Didn't come across this, when I was looking for it.</comment></comment>


Why alienating developers is a winning strategy  - <AUTHOR> http://apenwarr.ca/log/?m=201004#21 <comment><USER2> I'd disagree with the author. iPhone won't see very many large, high-risk applications developed as a result of Apple's approach. Apple screws over developers and partners too often. You will build a $1 application in a few man-months for iPhone, no questions.

Build a Google Voice? Build a Flash->iPhone compiler? You might get screwed and lose a really big wad of cash.

When business types decide what to build, they multiply out risks. You have technical risk (developers can't build it), market risk (people won't buy it), and a bunch of others. Typically, they're individually low-risk (say, 80% chance of success), but when you multiply them together, you get pretty low numbers.

If you toss in the additional risk of "Apple will cut me off if I'm successful and they want to compete with me" and "Apple will cut me off if they don't like me," it makes it a much less compelling platform.

The costs also go up if you can't share codebase. Requiring iPhone SDK is sort of sane -- you make an iPhone-specific front-end, and it looks better. Requiring Objective C or one of their other languages is kinda wacko -- you can't even share back-end logic. If I just spent millions on something complex (image processing engine, voice recognition system, or whatever), I don't want to spend another big portion of that for an iPhone port.

Worse, the same applies to custom business software, but even more so. If I have an enterprise app employees must use (think UPS guy or bus driver or anything like that), I care a lot about development time, not much about usability, and I can dictate platforms. If I can recompile to Android but rewrite for iPhone, guess what I'm gonna do?

<comment><USER3> What these authors fails to see is that innovation does not come from the big guys and that is all a heavily regulated platform will attract. In my mind I project that a lot of the authors must be younger, and have not been through one of the typical screw the developers cycles. This has been seen so many times in the tech sector, it is almost like clockwork.

The small developers will pack their bags and take their innovation to another platform, once one is up to par and that is the trick, as of now Apple is ahead of the pack, and so long as they are, developers will put up with them, but as soon as another platform is on par; The trickle will start to happen. Apple knows this and they have placed a huge bet on the fact that, they can remain the leader of the pack. I would assume that they feel that their patents are strong and that will keep them the front runner given their suit against HTC.

<comment><USER4> The author doesn't even mention innovation, and may not even see it as important in the platform game. After all, Apple spent years leading in innovation while it varied between "marginal" and "beleaguered" in the market. So clearly innovation isn't enough to win the platform game, and looking at the winner of the last big platform game I'd say that it may not even be necessary.

So while I personally value innovation, I don't see how it's relevant to the author's thesis.

</comment></comment></comment><comment><USER5> The author has entirely missed the reasons for Apple's successes and failures.

I was a Mac guy in the '90s. The Macs of the day were uninspired beige boxes. They were also expensive and used connectivity technology that made peripherals more expensive[0].

The OS also sucked. The UI was nice, but from a technical standpoint, NT4 was easily and clearly superior[1]. Even Windows 95 had better memory management and multitasking.

Everything Apple made from about 1988 to 1998 would have gotten the Steve Jobs "This is shit!" stamp. Apple lost ground in the '90s because it made average products and sold them at premium prices; it had little to do with third-party developers.

The success of the iPhone also had little to do with third-party developers. It simply has the best user experience, and a "wow-factor" that makes people want to buy one when they play with it. The iPhone would be the most popular smartphone even if it had no third-party apps at all; most people by the iPhone for the iPhone, not the apps.

[0] Not inherently, in many cases, but the result was less competition between peripheral makers than on the PC side.

[1] It pains me to say this. I've always hated Windows.

<comment><USER4> Maybe it's too early and I need my coffee, but I can't tell where you differ from the author. He also says the success of the iPhone had little to do with developers. ("Developers never had anything to do with it." is his closing line.) What you call "wow-factor" translates to the author's "awesomeness".

<comment><USER5> The last paragraph of the article is

 _Microsoft won on the desktop by being developer-friendly and Apple won in mobile by being developer-hostile._

Quite a bit of the rest of the article doesn't seem to support that conclusion, but that does appear to be the conclusion of his article. I'm saying that Microsoft being developer-friendly has little to do with them winning on the desktop instead of Apple.

Incidentally, on the desktop Apple is now making good products and being developer-friendly. They don't have a huge market share, but I recently read that they're getting 20% of the global profits from PC sales.

<comment><USER4> I see where you're coming from now, thank you. FWIW, the sentence that followed made me interpret it more like this:

 _Microsoft won on the desktop [while] being developer-friendly and Apple won in mobile [while] being developer-hostile._

(I didn't think the author meant to imply causality)

</comment></comment></comment></comment><comment><USER6> Author misses one important point - Apple doesn't need the goodwill now with a big winner on its hands, but it might need the goodwill later if they're in a competitive race in a new market. And all things being equal, I think developers would choose "the other side" if the quality/market size was close.

These sorts of short term capricious mandates don't always come back to bite a major player, but sometimes they do. It might bite Apple later, or might not. That article was a really fun read though, I do like his style and tone.

<comment><USER7> Not only that, he has a point: it might be fun to have an evil empire for hackers to rally against once more. ;-)</comment></comment>


iOS Developer/Designer Interview Questions - <AUTHOR> https://github.com/CameronBanga/iOS-Developer-and-Designer-Interview-Questions <comment><USER2> Majority of these questions seem to be Trivia, which can be looked up. I don't see any need to learn them. They are probably nice to know but are not helpful in objectively evaluating a developers iOS skills.

The important thing while talking to candidates is evaluating their understanding of technical concepts - like multithreading, GCD vs NSOperations, application lifecycle, properties, references, blocks, memory management, caches, sandboxing, responder chain.

Whats the point of someone knowing HealthKit or Voiceover or screen resolutions if they don't understand how atomic or nonatomic properties differ?

<comment><AUTHOR> Understandable, I'm mostly a designer and so the first run I had a few questions like this sounded a little rough. Have a friend contributing and helping with these a bit, but still very early on this.

If you have any suggested questions, I would love to add them. If you don't wanna go through the PR, etc, my email is in my profile. Feel free to send over and I will add.

</comment></comment><comment><USER3> If you're in a situation where the best way you have to assess a candidate is to ask them questions, I'd recommend focusing on types of questions that open up room for discussion about how the candidate thinks and works rather than simply asking trivia questions about Apple's frameworks.

In context of iOS/Obj-C/Cocoa, ask about MVC. Ask about delegates versus blocks versus notifications as mechanisms of communicating between objects. Ask about CocoaPods, but framed as a larger question of when and how to bring in and manage third-party dependencies versus building them yourself. Give them the opportunity to share how they think, not just what they know.

<comment><AUTHOR> Great points. See here, [https://news.ycombinator.com/item?id=8828209](https://news.ycombinator.com/item?id=8828209), but if you have questions, I would love to add. Send over a PR or email them (email in profile).

</comment></comment><comment><USER4> I'm afraid this isn't going to produce much beyond anxiety in your candidates. This leads to the sort of interaction where I'd end the interview early, thank the interviewer for their time, and high-tail it out of there never to return.

It's a trivia quiz. And frankly, who cares if you know what iBeacons are? What's the likelihood a project requires knowledge of both iBeacons and HealthKit?

HealthKit AND HomeKit?

HomeKit AND Apple Pay?

Why ask about something as deeply specialized as Metal, a brand new 3D graphics API, when so few projects are likely even to need it—except in game dev shops?

And in what conceivable universe does someone need to know the screen resolutions of any given piece of hardware? I've been building iOS apps for six years now, and I barely remember at any given moment.

Anyone looking for great interview questions for iOS devs should instead consult Black Pixel's excellent post here:

[http://blackpixel.com/blog/2013/04/interview-questions- for-i...](http://blackpixel.com/blog/2013/04/interview-questions-for-ios-and- mac-developers-1.html)

It talks through concepts as much as technologies, hitting the most common cases for what a developer will actually use.

</comment><comment><USER5> How does any of this prove they are a good candidate? All this proves is they can remember things. When coding all if not 99% of these questions are a 4 second Google away.

And most of them are also opinions which tend to lead to bias. "Oh this user doesn't like Xcode, while I only use Xcode, so nope to him".

<comment><USER6> This was my first thought, too. "What is widget X" isn't a good question. Questions more along the lines of "When would you use widget X over widget Y" will lead to better insight about a candidate, and will show actual experience.

In the same way, for normal CS questions, "Write a hash-table implementation" is OK but I think it's better go with a question where a good solution involves _using_ a hash-table.

<comment><USER7> Absolutely a lot of these questions were general knowledge to any techsavvy guy. I strongly recommend this book called [Cracking the coding interview] by Gayle Laakmann. It's very details and in-depth, helped me prepare for all my interviews.

</comment></comment></comment><comment><USER8> This list reads like a multiple-choice test at a community college for a "Survey of iOS Technologies" course. Casual iPhone aficionados who read 9to5Mac would dazzle an interviewer if they were merely asked these trivia- type questions.

</comment><comment><USER9> CameronBanga, appreciate you sharing this! As a long-time iOS designer and developer, I appreciate you helping and effort in finding a great one.

I unfortunately think that all of your questions are at best, filtering questions to ensure they have base familiarity with pretty benign facts and at worse, questions that give no insight at all into iOS abilities. Your design questions are, in particular, extremely trivial and almost silly.

Feel free to reach-out to me if you'd like to collab on a better list.

Everyone else reading this, no even semi-serious iOS developer or designer would endorse these questions as a robust way to filter candidates or even teach yourself.

<comment><AUTHOR> Posted a link here, [https://news.ycombinator.com/item?id=8828209](https://news.ycombinator.com/item?id=8828209), explaining. This was a quick starting point for a friend and I, hoped a post here would encourage a person or two to help out, and seeing a huge unexpected response.

I am more than happy to accept any suggestions, I understand most are super trivial, I assume these as a starting point for any conversation, or as basically a few things that could help give someone an idea as to where to start.

PRs are appreciated, or feel free to just email me questions and I will add (email in profile). Create an issue and add there as well, and I will go ahead and work in. Whatever is easiest!

Thanks for all of the attention everyone. I know it's basic, but it's a start. Hopefully we can work to evolve it into a much more detailed document that a few of you can benefit from.

</comment></comment><comment><USER10> > What's your favorite feature of Xcode?

Bonus points if they laugh bitterly.

<comment><USER11> That question really needs to be flipped (this is true of any "what's your favorite feature of [x]?" style question). It's far better to ask "what would you _change_ about Xcode / developing for iOS[1]", because anyone can recite features of a product - it's another thing to be asked to critically think about what you would actually change to make your life as a developer easier.

[1] NB: "Crash less" doesn't count as an answer for Xcode, correct as it may be...

</comment></comment><comment><USER12> First of all, thank you for taking the time putting this together.

Next, this should be used as a good example of "types of questions not to ask in a technical interview".

These will give little insight into what a candidate actually knows other than random trivia. I've seen a lot of junior interviewers focus on these types of questions, to perilous results.

<comment><USER13> I actually think high level questions like these are just conversation starters which can get into highly technical conversations quickly.

Sort of like the technologies themselves; GameCenter and CoreEverything are abstractions of lower level functionality. Being able to discuss their purpose, how to use them, and how to glue them together is what a good developer is. The rest is just syntax.

<comment><AUTHOR> Moreover, I never see these questions as just being a one-by-one trivia list for applicants. More of just a thing to look over, see the technologies that your app may use, and then use these questions as kinda a way to launch discussion with an applicant to see how well the know their stuff.

</comment></comment></comment><comment><USER14> I would add questions where answers can't be found easily by searching or on stack overflow. If the answer is found in the first search result, then I don't see the point in checking if the interviewee has memorized it.

Add questions that should lead to discussions and show general knowledge.

I would add a section for small, interesting coding challenges.

</comment><comment><AUTHOR> Hey all,

Saw a similar link a few weeks back on a list of questions for front-end website designers. I thought it was a really great lists for people looking to hire a programmer/designer here in the new year, so wanted to make something similar for iOS, as we may be hiring and it would be useful to have this on hand.

This is an early work in progress, but suggestions/PRs would be much appreciated!

<comment><USER15> would love to see similar list for android as well !!

<comment><AUTHOR> Was hoping to work on this next week, as we do a bunch of Android work as well and it would be useful for us! I'll link in this repo when I get that up.

</comment></comment></comment><comment><USER16> Shameless plug: a short article about the company I work at interviews candidates: [http://macoscope.com/blog/so-you-have-a-technical- interview-...](http://macoscope.com/blog/so-you-have-a-technical-interview-at- macoscope/)

<comment><AUTHOR> Added it into the guide as a link, thanks for the heads up!

</comment></comment><comment><USER17> Off-topic: Is there something like that for Android Developers?</comment>


CVE-2019-1347: When a mouse over a file is enough to crash your system - <AUTHOR> https://blog.tetrane.com/2019/11/12/pe-parser-crash.html <comment><USER2> One more bit of proof that if you want proper isolation _you should not bloat your kernel_. All this stuff belongs in userland. At least there the damage will be limited.

<comment><USER3> The crash is in parsing an executable file. Linux also performs this parsing in the kernel. Moving it to userland would be a microkernel design.

<comment><USER4> > The crash is in parsing an executable file.

In a context that doesn't involve executing it. On a Linux system, this functionality would probably be implemented with libelf or libbfd, neither of which depends on the kernel.

<comment><USER5> But here's a question - supposing that this functionality was moved into a hypothetical library "pe.dll"/"pe.exe", how would the kernel load this library or executable? Wouldn't one run into a catch-22 situation?

<comment><USER6> The kernel would probably statically link it.

<comment><USER7> …wouldn't that have the effect of bringing this code back into the kernel's address space?

<comment><USER6> The code itself would be in the kernel, but the "parsing while mousing over" invocation would be on userspace code.

That is, the parse logic could be a library linked by multiple application.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I assume the audience of a post like this is other security researchers?

That's a radical piece of software, though. I've never seen anything like that before.

The text and technical details supporting the screen caps is very dense and hard to approach as a complete outsider. I would love to have a glossary with all the terms and initialisms/acronyms in use. PTE (apparently means page table entry), for example, is something I've never heard of before.

<comment><USER9> I'm in the security field and do work similar to this professionally. This article it poorly written and i found the videos shown absolutely useless. If you want to see how technical articles should read, take a look at j00ru's blog (research that found this). That is how you write about this stuff.

<comment><USER10> Thank goodness!

I looked at the article and it made me mad because it seemed to be a bunch of nonsense.

I mean the second video paragraph is: "A closer look at the memcpy arguments shows that this address is built as 0xfffff8035b2a0000 + 0xe7ff, so we taint the value 0xe7ff to find where it comes from." But there's absolutely zero explanation of what we're looking at.

So it made me mad because it made me feel stupid for not understanding it, when in reality it's just poorly written. Poor communication is theft.

</comment></comment></comment><comment><USER11> This issue apparently affected Windows 8.1, Windows 10 and their corresponding Server editions (32-bit and 64-bit) and has been patched since October 8th.

</comment><comment><USER12> The real question is: why the fuck the kernel parses the PE on just a mouse over... it like Windows is asking for vulns with even more impact :/

<comment><USER13> It displays an overlay when you hover the mouse over a PE executable with information like the author/company/version/date created.

The fact that it does this in the kernel is foolish, but there's functionality directly tied to this, not an indirect chain of things that results in parsing this for little reason.

<comment><USER14> Nobody is contesting that there's a chain of events that leads to this, but doing this in the kernel is not "foolish" - it's batshit insane, amateurish and frankly laughable.

<comment><USER15> Typically these things happen because people want to reuse code. There's some code that parses executables, there's a bit of shell that wants to display information from an executable, and someone joins the two together without understanding the ramifications.

<comment><USER16> I would argue that the stronger reason is that Windows typically doesn't enforce, allow, or contains any distinction between kernel code and user-space code. This happens because there is a gigantic gravity well of pre-existing code that predates and/or precludes real separation, and the costs of concretely losing that support was nearly always judged higher than the abstract benefit of adding separation.

One old example: I have an old friend who used to do sysadmin work in the Windows 2k days, and he would often get gigs by speeding up services by 5-15% within a day. His go-to trick was to log into the headless win2k server and disable the screensaver process, then wait.

<comment><USER17> Windows NT (and as a result win2k, xp, 7, 8, and 10) has always had strict user and kernel space separation. Modern Windows also has separate 'integrity levels' within user space - for example, Chrome and Firefox run most of their functionality at 'Low' integrity to prevent compromised browser code from being used to exploit other processes. I'm not sure what the basis is for the claims you're making about the kernel. The idea that distinguishing between kernel and user code is Not Allowed is very confusing to me, how would you do that without running both user and kernel code at the same privilege level in a shared address space?

The CVE here literally has nothing to do with privilege separation or being unable to distinguish between user mode and kernel mode. It's this simple:

* Someone in user-space wanted to parse an executable to get information on it

* A syscall is exposed to parse an executable

* They used the syscall to parse the executable, and that code path had a bug in it which triggered a BSOD (since the failure was in kernel mode).

In the end, this is just "a syscall had a bug in it that caused a kernel crash, and a user-mode application issued the syscall on mouse-over".

</comment></comment></comment></comment></comment></comment><comment><USER18> The images in the article will stay a blurry mess without Javascript and will not load. Please don't do this. Use progressive images.

EDIT: Apparently they are videos, but you can still add thumbnail images to native HTML5 videos without loading 40 script files (that uMatrix reported).</comment>


A tour of BTRFS - Avi Miller - <AUTHOR> http://www.youtube.com/watch?v=hxWuaozpe2I

<comment><USER2> Only problem with BTRFS is its mainly developed by Oracle. And Oracle is well- known for its active development and support for opensource (like mysql) :p

[http://techcrunch.com/2012/08/18/oracle-makes-more-moves- to-...](http://techcrunch.com/2012/08/18/oracle-makes-more-moves-to-kill-open- source-mysql/)

[http://www.h-online.com/open/news/item/Btrfs-inventor- Chris-...](http://www.h-online.com/open/news/item/Btrfs-inventor-Chris-Mason- leaves-Oracle-1612793.html)</comment>


Cross-platform Rust Rewrite of the GNU Coreutils - <AUTHOR> https://github.com/uutils/coreutils <comment><USER2> Note GNU coreutils has a good test suite which just calls out to the various tools from shell and perl scripts. It should be easy enough to run this implementation through it. More effort goes into the coreutils tests than the code.

One of the hardest parts of coreutils is keeping it working everywhere, including handling that buggy version of function X in libc Y on distro Z. That's handled for GNU coreutils by gnulib, which currently has nearly 10K files, and so is a significant project in itself.

Some stats:

coreutils files, lines, commits: 1072, 239474, 27924

gnulib files, lines, commits: 9274, 302513, 17476

<comment><USER3> Would using a GPL test suite with an MIT implementation make the whole GPL? You're not "linking" to it, but it'd worry me somewhat.

<comment><USER4> >Would using a GPL test suite with an MIT implementation make the whole GPL?

Absolutely not. MIT is a FSF-approved GPL-compatible license and you're free to use it with whatever GPL-licensed packages you wish[0].

However, if you _package_ and _distribute_ the Rust coreutils with the GPL test suite, then the _users_ of the package are obliged to either use GPL, MIT, or some other FSF-approved OS license.

But it's simple enough to package the Rust coreutils _without_ the test suite, which puts the Rust coreutils users under no GPL obligations.

GPL2 is all about the _distributing_ of software, not how you use it.

I do agree that any use of a GPL package will make some folks using this package in commercial software nervous, given the very few (none?) actual court cases that have decided these issues.

0\. [https://www.gnu.org/licenses/](https://www.gnu.org/licenses/)

<comment><USER5> > However, if you package and distribute the Rust coreutils with the GPL test > suite, then the users of the package are obliged to either use GPL, MIT, or > some other FSF-approved OS license.

I don't think this is right. The programs in question are the test suite, and there's can certainly distribute complete programs licensed under the GPL alongside with programs under even non-free licenses (otherwise Mac OS X couldn't ship).

Since the test suite doesn't link against the individual utilities, it won't affect them, license-wise.

It is well understood that the GPL doesn't cross executable boundaries (again, otherwise Mac OS X is in trouble).

<comment><USER4> You're absolutely right. I was thinking of AGPL, which does cross network boundaries.

<comment><USER6> And that's why it's to be avoided like the plague. :(

<comment><USER7> Or, that's why to use it instead of the GPL.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I was already secretly imagining a future where Rust will completely replace C as the low level language for everything. Even the Linux kernel rewritten in it eventually. It'd be a much better world with no #ifdefs, strong type safety and memory safety depending on compilers instead of fallible programmers.

But I was expecting it would take a while before people had the ambition to start doing these things, even when it comes to the smaller ambition of rewriting the GNU coreutils. Rust is a great language already, but it's not a _stable_ language yet.

I wonder if my imagination will become reality eventually. There's really good buzz around Rust now, and it's not even 'production ready'.

<comment><USER9> I hope that never happens, because I think such a world would be extremely dystopian. Strong safety guarantees sound very beneficial at first ("safe" _anything_ in general tends to evoke that response), but as shocking as it may seem, a lot of the freedom we have today is a result of using "unsafe" languages like C: iOS jailbreaks, Android rooting, homebrew on game consoles, and many other examples of freeing one's devices from restrictions imposed by the original manufacturer and giving control back to the user depend on this. These bugs and vulnerabilities, although they can be exploited maliciously, are in some ways like an escape hatch from the tyranny of corporate control. If strongly safe languages become the norm, all these would disappear and our computing experience become even more locked-down and restricted. The thought of them being used for DRM is scary (I remember reading an academic paper that suggeted this as one of their applications, and that's one of the thing that provoked me into really starting to think about this.) Even open-source software where safer languages appear most beneficial can be used against the user.

Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.

<comment><USER8> I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a _good_ thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them?

Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

<comment><USER10> Practical experience shows that once you run into even routine systems programming elements, like writing device drivers and whatnot, you eventually have to concede some safety, or end up with an unprogrammable behemoth of such baroque complexity that you likely have more security holes, just of some other kind. There has been a lot of research into this back in the 1990s; most of the useable results produced security by architecture rather than tools.

<comment><USER11> It's almost as if what one would want is a language where you could shrink unsafe operations to as small a footprint as possible by confining them within a block with a special keyword, like this:

         unsafe { … }

Someone should invent such a thing.

 _Edit: …yeah, I was being tongue-in-cheek. This is exactly what Rust provides._

[http://doc.rust-lang.org/rust.html#unsafety](http://doc.rust- lang.org/rust.html#unsafety)

 _"...When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context…"_

<comment><USER12> If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know. And I want my function to be marked as unsafe as well (because it is) as well as any function calling my function, etc.

<comment><USER13> The way that you mark a function as unsafe is to stick a keyword in front of it:

      unsafe fn foo() { ... }

Any function marked as such is then allowed to call other unsafe functions:

      unsafe fn bar() { foo(); }

But there is a way to break the chain, which is to use an `unsafe` block without marking your function as unsafe:

      fn qux() {
          unsafe {
              bar();
          }
      }

That said, it's incorrect to think that Rust is any more unsafe than any other language because of this; most languages simply defer this behavior to their FFI. By pulling it into the language itself, Rust is actually _safer_ than e.g. calling C from Python, because Rust can do the low-level fiddling while still retaining at least some of the safety checks of normal Rust code. Even unsafe Rust is safer than C.

<comment><USER7> > Even unsafe Rust is safer than C.

This is an important point. `unsafe` blocks only let you do a few extra operations[1], not anything you want. A lot of safety checks still happen inside of unsafe blocks.

1: [http://static.rust-lang.org/doc/master/rust.html#behavior- co...](http://static.rust-lang.org/doc/master/rust.html#behavior-considered- unsafe)

<comment><USER13> Well, no, you can still theoretically do anything you want, you just need to be very, very explicit about it. :)

<comment><USER14> Some things are undefined behaviour[1]... so you _really_ don't want to want to do them (i.e. you _can_ do them inside `unsafe`, but the compiler optimises/reasons assuming they never happen: if they occur at all, you could have an arbitrarily broken program).

[1]: [http://doc.rust-lang.org/master/rust.html#behavior- considere...](http://doc.rust-lang.org/master/rust.html#behavior-considered- unsafe)

<comment><USER13> The point that I'm trying to make here is that you cannot make any assumptions about an unsafe block. Anything can happen, including really terrible undefined behavior. But the fact that anything can happen is why Rust is as powerful as C in this area.

<comment><USER7> My point is that while anything _can_ happen, it's not like Rust just turns off every single check. Yes, they can be gotten around, but it's not like the type system suddenly goes away.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> "uutils is licensed under the MIT License - see the LICENSE file for details" \- funny to see GNU software reimplemented in another open source license.

<comment><USER15> I do not understand the down votes. Can somebody explain?

I did not mean to hurt any feeling. I was just surprised to see the license of a software where "GNU" is in the title. I naturally assumed that it will be in GNU license. So it was a surprise to discover MIT.

Now I understand. I should have written "surprising" instead of "funny". Sometimes writing about a subject gives you the answer.

Sorry for those that I hurt.

<comment><USER16> Because there is a large anti-GPL contingent on HN.

<comment><USER17> Is it anti-gpl or anti-gpl3? It seems from a public relations perspective gpl3 really lost a lot of mindshare in the open source world, including me.

<comment><USER7> It's anti-GPL. Remember, a large target audience of HN are entrepreneurs, who want to use open source components in their closed-source applications that they're selling. (A)GPL prevents them from doing this, (not selling, but keeping it closed source, which many see as being important to selling) so they get pissed.

<comment><USER18> A large part of HN is developers who like to release good code and let anyone use it as they see fit.

GPL has neither of those goals and actively works against the latter.

<comment><USER7> > actively works against the latter.

For your definition of 'anyone.' BSD software often does not let the end user use it as they see fit, as they no longer have access to the source code.

<comment><USER19> How does BSD remove access to source code?

Someone else may add some modifications to my code and I may not be able to see those modifications, true. But nothing's been removed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> How stable and usable is Rust's ABI? Can I easily call Rust code from C or other languages that can easily call C functions? I ask because I think this is one area in which C++ has really failed. C++ is a bad language for building frameworks and libraries for consumption from other languages because interfacing with C++ code is such a nightmare. I'd hope any language that aspires to displace C++ has a better story here.

<comment><USER14> Rust's internal ABI (i.e. used for a default `fn foo() { ... }`) is not at all stable/usable/specified.

However, you can easily define a function with a C ABI (and a non-mangled symbol name):

      #[no_mangle]
      pub extern "C" fn foo() { ... }

I'm not sure if you regard this as better than C++'s situation.

</comment></comment><comment><USER21> While they're at it, I hope they write complete man pages rather than pointers to info pages.

<comment><USER22> While I know the basic differences between info and man pages, can you shed some more light on your preference here for the less well informed.

<comment><USER23> Man pages are more convenient for the typical unix hacker - command-line oriented, vi-using.

They are rendered in less, which supports vi-like searching.

Info, on the other hand, is one of those odd pre-www hypertext systems. Advanced for its time, it is now clumsy and nonstandard.

</comment></comment></comment><comment><USER24> > However, [other ports of coreutils to Windows] are either old, abandoned, > hosted on CVS, written in platform-specific C, etc.

I don't get how on the earth can using CVS for version control be an appropriate reason to consider a software project bad. Yes, CVS is old and centralised, but, is it that big of a deal that it's usage by a project per se projects the project old and inactive?

<comment><USER25> I know from my own experience—when you want to start a project that has been done before you, it's easy to fall into the trap of faultily rationalizing why none of the other attempts have worked and why you're going to do it better.

However, I don't think you should ever avoid writing something you'd enjoy for the sole reason that there are prior attempts (successful or unsuccessful). If you aren't motivated by money, you won't lose anything if your project doesn't get a single user, but you will always gain enlightenment and great experience.

<comment><USER24> I understand your comment and support it -- I have, many times, thought of implementing a POSIX userland in Go, but the task has daunted me, so that has not been realised till now. What bothered me was the fact that they show usage of CVS as an alert for deprecation. I concur your argument though, no-one can judge no-one else for what they choose the create in their own time. But CVS is perfectly usable software (and I am telling this as someone who has spent a month trying to CVS-checkout OpenBSD source tree, only because $CVS_RSH=rsh rather than ssh).

<comment><USER5> > What bothered me was the fact that they show usage of CVS as an alert for > deprecation.

CVS still works just as well as it ever did, but it _is_ super crusty at this point. If an open source project hasn't transitioned off of it, that's a sign to me that the maintainer either doesn't know any modern DVCSes, or doesn't care about the project enough to transition to them.

It's not a guarantee that the project is dead or outdated, but it's a smell.

Of course, I consider still being hosted on Sourceforge to _also_ be a smell.

<comment><USER24> > CVS still works just as well as it ever did, but it is super crusty at this > point. If an open source project hasn't transitioned off of it, that's a > sign to me that the maintainer either doesn't know any modern DVCSes, or > doesn't care about the project enough to transition to them.

[http://www.openbsd.org](http://www.openbsd.org)

<comment><USER5> Yes, I know. The *BSDs are the exception that proves the rules. I also said it was "a smell" and not an outright dismissal.

</comment></comment></comment></comment></comment></comment><comment><USER26> This looks like it's handy for learning purposes, but is there actually any practical use for this? I don't think that the code size and the pace of development really require changing the core language.

Past re-implementations have focused either on the learning experience, code size (for embedding or Unix "purity" reasons) or the license (i.e. not GPL).

<comment><USER27> Most of these tools are small enough and simple enough that they sort of "get finished." Probably not interesting but to some purists.

There is something to be said for the nice clean implementations of some of these tools. There is a little to be said for the language itself.

Really, something bigger and better is needed. A new HTTP server, a new sendmail or something, a new DNS server. I'd love to see Go or Rust take on Bind and produce a safe, secure, high performance implementation. The Ada guys never stepped up and produced anything interesting to show their tools' superiority, there is a lot more interest and community in Rust and Go. What's the leakiest, buggiest part of the equation right now? Go make a better one.

<comment><USER28> Well, they're building a browser engine...

</comment></comment></comment><comment><USER29> Nice. However, I feel there're two things really needed to be done here: move all that cat|du|... to some src|source|whatever directory and add 'tests' directory with somewhat more robust tests layout than the current one. It would be really cool to replace (seriously, just for the arts sake) coreutils with this one, but I wouldn't dare to do it if I'm unable to easily verify that they both _work_ and _work at least almost as fast as coreutils_ on my platform. It's important stuff, you know, otherwise it wouldn't be called "coreutils", really…

</comment><comment><USER30> It will be interesting when they get down the to-do list to fmt, which contains the Knuth-Plass paragraph reflow algorithm -- the only C-language version I've been able to find, and about the only readable one, after Knuth's "literate" one.

[1] [http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab...](http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/abstract)

</comment><comment><USER31> Why Rust? Is it better at this than, say, Go?

<comment><USER32> Well rust doesn't have garbage collection, its designed to replace* the languages that coreutils are currently written in - C (I don't think any gnu coreutils are written in C++). Go is not designed to replace these languages.

*by replace I mean occupy some of their current marketshare.

<comment><USER33> Simply comparing the two based on GC is very superficial.

<comment><USER5> Not really. The day my `cat` pauses to GC is the day I leave this field...

<comment><USER34> Why? Do you think you would notice?

(I realize your post may have been tongue in cheek, but it can be hard to tell on the interwebs.)

</comment></comment></comment></comment></comment><comment><USER35> It's not really cross platform - whoami for example depends on libc which afaik isn't native on Windows.

I wrote one of the first utilities for this when it was first opened up for collaboration, so I hope it succeeds :) I need to go back and write tests for my util.

<comment><USER36> There are many "libc"s; according to the docs, Rust's libc is a module that binds to the platform-specific libc implementation: [http://static.rust- lang.org/doc/0.10/std/libc/index.html](http://static.rust- lang.org/doc/0.10/std/libc/index.html)

</comment></comment><comment><USER19> I love this idea! When I get a few hours I'll have to try porting a small coreutil... Seems like a great way to learn Rust.

Any chance of Rust taking over embedded systems programming? That's still mostly done in C and quickly devolves into horror.

<comment><USER7> > Any chance of Rust taking over embedded systems programming?

I don't know about 'taking over' but there are some people who are using Rust for this use case.

<comment><USER19> That would be super cool. Anything publicly available to look at?

Freescale's Freedom boards are so cheap, so capable, and have such miserable tooling (mbed, DIY usb, Processor Expert, CodeWarrior, ugh)... I wonder if Rust could make them attractive.

<comment><USER7> I just know that people come into IRC, and there was some discussion about bitfields to help support embedded stuff. Not sure there's a lot written about it yet.

</comment></comment></comment></comment><comment><USER37> Interesting project. Why is there no grep in this, or on the to-do list?

<comment><USER38> grep is not part of the coreutils.</comment></comment>


Show HN: A command line password manager - <AUTHOR> https://github.com/wtsi-hgi/secrets <comment><AUTHOR> "secrets" is a command line password/secret manager that uses GnuPG to secure data and a blockchain to keep an audit trail of operations. It was motivated by Jason A. Donenfeld's "pass", but with a few key differences to make it stand out/satisfy my usage requirements.

I just pushed version 0.2.0; submitting it here as a public beta. It's been tested, but not rigorously, so have a play and let me know if you find any problems.</comment>


Turn your mobile device into a wireless mouse and keyboard.  - <AUTHOR> http://www.remotemouse.net/

<comment><USER2> Oh noes, please not yet another kind of client/server based remote control.

What would be REALLY cool is to make an app which does this using the standard Bluetooth HID profiles, so no setup is needed clientside.</comment>