skysight-inc/HackerNews huggingface dataset:
A few summers ago I was an intern at JPL working on a static analysis suite for this exact standard.

Writing code checkers for these sorts of rules is a really interesting exercise and it helped me grow a lot as a programmer! I went from having no exposure to formal languages, parsing, and grammars to actively playing around with these concepts to try and help build more reliable software. It was a humbling, challenging, and incredibly rewarding experience.

Sometimes, a rule is extremely simple to implement. For example, checking a rule that requires that an assert is raised after every so many lines within a given scope is just a matter of picking the right sed expression. Other times, you really need an AST to be able to do anything at all.

A rule like "In compound expressions with multiple sub-expressions the intended
order of evaluation shall be made explicit with parentheses" is particularly challenging. I spent a few weeks on this rule! I was banging my head, trying to learn the fundamentals of parsing languages, spending my hours diving into wikipedia articles and learning lex and yacc. The grad students at LaRS were always extremely helpful and were always willing to help tutor me and teach me what I needed to learn (hi mihai and cheng if you're reading!). After consulting them and scratching our heads for a while, we figured we might be able to do it with a shift-reduce parser when a shift or reduce ambiguity is introduced during the course of parsing a source code file. This proved beyond the scope of what I'd be able to do within an internship, but it helped me appreciate the nuance and complexity hidden within even seemingly simple statements about language properties.

Automated analysis of these rules gives you a really good appreciation of the Chomsky language hierarchy because the goal is always to create the simplest possible checker you can reliably show is able to accurately cover all the possible cases. Sometimes that is simple as a regular language, but the next rule might require you to have a parser for the language.

For what it's worth, this is only one of the ways the guys at LaRS (http://lars-lab.jpl.nasa.gov/) help try to improve software reliability on-lab. Most of the members are world-class experts in formal verification analysis and try to integrate their knowledge with missions as effectively as possible. Sometimes, this means riding the dual responsibility of functioning as a researcher and a embedded flight software engineer, working alongside the rest of the team.

If anyone's interested in trying out static analysis of C on your own, I highly reccomend checking out Eli Bendersky's awesome C parser for Python (http://code.google.com/p/pycparser/). I found it leaps and bounds better than the existing closed-source toolsets we had licenses for, like Coverity Extend. At the time, it had the extremely horrible limitation of only parsing ANSI 89, but Eli has since improved the parser to have ANSI 99 compliance. Analyzing C in Python is a dream.
It's a sign of decay. No forum can last forever.
Yet another "i hate <this>" article :-)
Wait.... no malloc or sbrk? That means all space has to be stack allocated? That's a pretty serious limitation and would probably make it hard to do anything really interesting.
I bought a retina macbook pro off apple's webstore and it was fine. My credit card number got stolen in between placing the order and them charging, and was resolved in a quick phone and they sent me a follow up email so when I got the new card I could sort it out quickly. They also didnt try charge the card until it was actually ready to ship, so was not stuck in limbo.

I also had a problem with some updates, again a call to support and the service was about as good as it could be, knowledgeable staff, timely responses, follow ups etc. A+ would shop again.

It sounds like the re-seller just isn't very good.
This advice is mostly awful.

If 'retaining your right to sue them' is at all a factor in your decision, you should be working for a big company.

If you want to be 'paid by the hour' and/or receive overtime, freelance or work for a big company or work in a unionized occupation. At a startup, your equity is your only overtime pay.
This behavior wasn't really introduced with "Save as..." in ML. In Lion, if you rotate a page in the middle of a PDF, then quit and reopen the file hoping to undo the rotate, it will still be rotated. Fortunately, it was someone else's presentation where I first saw this.

Anyhow, ML isn't doing a "save" and "save as..." now; it had already done the "save" part. Apple really should do a better job explaining this, but it's most likely not consistent across all apps. Does XCode even do this now?

It reminds me of the preferences behavior where you make your changes and that's it, rather than requiring you to hit an "OK" or "Apply" button as in Windows.
Exactly. Facebook fills a certain need reasonably well at the moment, and it's massive because of the network effect. But I have no difficulty imagining much better things arriving in the next 5-10 years. Same deal with Twitter.

All the successful "social" stuff captures and defines how we're using technology now, but that changes very quickly.
There are plenty of abstractions on top of git - most UI implementations abstract away the hard details, at the cost of not being able to understand what happens when something bad occurs because you never had to learn its intricacies prior. Seeing the consequences of such things it makes me appreciate git is left as raw interactions. Git is not for people that do not want to understand it. To me, it's similar to vim - its basic implementation is bare essentials and complicated concepts, but once mastered, far outweigh competitors who roll those concepts up into simpler ones and leave you with workflows on their terms.
Anything that makes it "very easy to do wrong" is not a good idea in flight software. A missing semi-colon in FORTRAN once completely killed a space mission.
I highly recommend looking for any dissonance between the ground-floor workers and management/leadership.

The best scenario you can find (a truly rare gem of an employer), whether startup or established company, is where everyone is on the same page. Vision should be clear, strengths should be accurately gauged, and problems should be acknowledged and well-understood. You should be able to share what you've learned from the workers with management (and vice versa) without any looks of shock, fear, or panic. Overall visible stress should be almost non-existant.

The worst scenario is where the company's leadership lives in its own reality and blames any issues on workers or outsiders. Run from these employers; no amount of money is worth working for such people. The easiest way to test for this case is to just talk openly about what you've learned about the company and how the future looks given their strengths and weaknesses. Watch out, in particular, for the hushed phrase "I shouldn't tell you this, but..."

Realistically, though, you'll find a lot of employers somewhere in between. Just know that the distance between the reality of leadership and worker is going to be proportional to the pain you'll feel working at that employer and that such distance tends to increase over time.
Can't wait to see your version.

When it does come out, I hope others can be constructive without coming across like a cunt. Nobody likes that stuff, and as we all know, it's not very helpful.
http://namesake.com/ might be what you want
I believe in the power of user interfaces, and I believe tools should be as easy to use as possible, and I dislike the "I don't like to learn new things" argument because actually, yes, your tools should make you learn as little as necessary to use them. But quotes like:

here’s a diagram illustrating the commands a typical developer on a traditional Subversion project needed to know about to get their work done. This is the bread and butter of VCS: checking out a repository, committing changes, and getting updates.

make clear that when this author says they're listing ten things git does wrong as a version control system, but what they're listing is ten ways git isn't Subversion, and I'm sorry, but maybe if instead of writing blog posts about how a tool's user interface wasn't like what you unfairly expected of it, you actually learned how to use the tool, you'd be using it right now to make something awesome.

What I'm saying is, I think I'd rephrase

Number 1-5 are mostly "I don't want to learn new things"

to

Number 1-5 are mostly "I'm going to blame my tool for me refusing to do the bare minimum to learn how to use it"
Well that's unfair. I think there are legitimate arguments to be made against rewriting history besides "I've been brainwashed by SVN."
You mention longjmp as useful in an STM implementation.

But you'd never see something like that in flight control software. Simplicity begets correctness. Correctness begets safety.

When the software is flying a rocket ship, I'm okay with it being 10% longer but 10% safer.
The article actually hints at this: "We the people have decided that big companies are more responsible when they report to a broad base of shareholders". So, by that logic, we the people are to blame -- for the overhead that fast growing companies now need to avoid by staying private longer.
Very cool, adding to my list of things that I will immediately start trying to use irrespective of actual need or requirement!

Fyi, debug is still on for your chartulo.us site, after watching the animated typing produce a url, that url leads to the django yellow 404 :)
As fun as getting out our tribal aversion to managers who don't respect geeks is, let's focus on the actionable career point: do not work for cost centers.
Always assume that every change you make is saved automatically, much like cutting down a physical photo.

If you still want the original photo, and another cut down version, you would use a photo copier to Duplicate the original, then cut the copy.
smsm42 already said it, and you say you're still missing something, so I'll try another try another way.

If I want to work on some code locally, I might want to experiment and break things, and in the process of doing so I want the ability to commit and have the safety net of version control. That said, a lot of those experiments might be garbage, and I don't want to send garbage to my co-workers when I make a pull request.

So instead, I splash about in my local repo and make tons of commits and screw around with my experiments until they're fully baked, and have tests, and comments and docs and so on. Then I can use rebase to clean up that mess and present them with something atomic and contained that makes clear what I really wanted to publish. The garbage can be tossed from the history or it can be kept around locally, but at least I'm not asking my colleague to trudge through my own thought and work-process.

Does that not sound like a worthwhile feature? If it doesn't that's pretty cool too, you don't have to use rebase at all. Feel free not to, Git works fine without it.
You don't want your space ship flight to be "interesting".

Note that it says "after task initalization". What this really implies is that you must use O(1) heap space, and you should get what you need ahead of time.

Having to deal with out of memory conditions 4 seconds after main engine turn-on is not a fun party. Neither is blocking on malloc() so you can prepare your struct course_adjustment to send to another task.
The parent was pointing out the conflation of action (double-tap to fit, overloading volume control with on/off features) and mechanism (fitting algorithm, physical design of said button). The former is not patentable, or rather should not be, while the latter might be.

It's the difference between going to the patent office with an idea for "an engine that runs on steam" and actually designing a steam engine. See how much broader in scope the first one is?
This is a great list! Thank you.The last point is something I had not thought about.
SSL is not about encryption
No. I'd love to try out Diaspora but I signed up for an invite months ago and haven't heard anything from them. So it's not just a marketing problem, they're clearly not ready for mass use yet.
You don't want to do anything interesting in a space flight mission. Code affecting a space mission only has one chance to get it right in many cases. In general, memory management in these systems is extremely serious business. Think of all the ways that manual memory management in C has damaged the reliability of software you have written in the past.

In addition, a lot of the rules are created to make the task of reading source code easier, both for humans and machines. I remember Dr. Gerard Holzmann once half-joked in a meeting that he wanted to disallow any declaration of pointers except at static initialization. I sort of thought he was joking, but then he assured me that it was a serious consideration. He reminded me of the gravity of the situation and explained that $2 billion of public funds were on the line.

Disallowing pointer indirection would make the task of certain automated analysis techniques much, much simpler to perform. Adding a pointer indirection can really conflate matters sometimes.
Using man files and in-built help is probably always going to only give you half the story. Have you considered reading the Pro Git book? http://git-scm.com/book
It just means no dynamic allocation. This is not an uncommon restriction for certain classes of embedded systems (engine controls, avionics, medical, etc.) I've worked primarily in this environment and haven't found it to be too much of a nuisance.
Our standups are at 11:45, so we have impetus to keep it brief and get to lunch. In any case, even if it does cut into a stretch of programming, it serves as an invaluable reminder to go get lunch.

Yeah, I agree that I'd be annoyed with standup at any time before 11:30, but 11:45 is perfect and basically doesn't interfere with anything. In a certain sense it doesn't cost any dev time at all if you take it for granted that your developers should stop coding midway through the day and eat lunch. (We absolutely do not eat lunch during standup - we have standup, then we physically leave the office to go eat.) Sure, some days we end up in endless meetings which mean we're stuck in the building eating takeout, but that has nothing to do with standup.
3 Tips to Get the Most Out of Your Mobile Spray Tan Business
Owning a mobile spray tan business is just like owning any other business — you’ve got to do things to set yourself apart from the competition.
Since when? I just merged 3 files together because GHC complained of the cyclic imports. I would love to pull them apart again.
When you want a commit, you tell git to commit and it will commit.

When you don't want to revoke or mutate a commit ("irrevocably and permanently immutable"), you don't tell git to revoke or mutate the commit and it won't revoke or mutate the commit.

When you fucked up history and you want to change it, there are some simple git commands to do this and some very, very tedious svnadmin commands to do this.

Some of us fuck up history and want to change it. Some of us don't. Git serves both of us well. Subversion only serves one of us well. A lot of the time we have to use the same version control system, because we want to collaborate.
It really is. It took years after the Amiga for the average PC to have preemptive multitasking. The same story repeats with 64-bit machines and multi-processors. In the latter case, it took so long for the average PC to have more than one CPU/thread most current software (and programming languages) simply isn't designed for it and cannot take advantage of those extra compute engines. Even if it were, most programmers never learned how to write software this way.

The PC standard set us back at least a decade, most probably two.
As a business, you want to look for "sustainable competitive advantage." A way to differentiate themselves from competition and make a profit.

Having closed-source code is a sustainable competitive advantage for many companies selling heavily software-dependent products like games, apps, websites, etc. "Advantage" because your competitors don't have it, "sustainable" because, with adequate investment in new features, you can keep your platform ahead of copycats.

There are a variety of strategies to make money with open source, but as a business, your first priority should be figuring out how you'll make enough money to adequately pay your owners, employees and vendors. The answer to that question is sometimes "open source," but not always.

Strategic reasons can sometimes justify open source products. For example, consider infrastructure components that are an incidental byproduct of your operations, not a core piece of your product. Twitter Bootstrap immediately comes to mind. Twitter releasing Bootstrap as open source doesn't help its competitors in the same way that open sourcing the code to its main website would, and allows the community to provide some amount of testing and improvement which may help them in the future.

But there is no one-size-fits-all answer; whether to open-source your code, and what to open-source, depends on your specific situation.
You first have to decide what kind of startup you're looking for. Do you want to be hire 1-10, 10-50,50-100, or 100+? Each of those company sizes is a substantially different beast and depending on which one is more suitable to you the other questions change dramatically.

If you're looking at the 50-100 range then the startup is obviously more mature and the nature of the company isn't as important so much as the work you'll be doing. If you're looking to be hire 1-10 then the company itself is a lot more important, especially the founders.

Let's assume you're looking to join a smaller team. If that's the case then I'd concentrate almost everything on the founders. Ultimately it comes down to trust. Do you trust these people to focus on important matters? Do you trust them to be fair and mature about tough decisions? Do you trust them to treat you and your coworkers right?

For many people this can be a difficult thing to gauge and it's made especially more difficult since the founders will be actively trying to sell you and therefore make themselves look better.

Ultimately there are some high level filters that can help carve out a lot of options and save you a lot of time. And these are actually the same kind of filters that investors apply:

Are they a YC company?

What is the experience of the founders? Have they done a startup before? Do they have an "in" for the space?

Does the company have traction?

The reason why I put YC company first is that pg and co are going to be better than most people at picking winners. So if you limit your choice to YC companies then you're going to have a much lower chance of joining the wrong company. I say that from some bias as being a founder of a YC company, but also because I've met many of the founders of other YC companies, and it's just crazy how many of them are awesome and trustworthy.
Indeed. It seems to be a "I hate git, because I don't understand what it is trying to achieve, and I haven't bothered to learn the concepts".

Unfortunately, this tends to invalidate many of the points he is making. The author is assuming that git should work exactly the same way as subversion, except that it has a fundamentally different way of viewing version control and uses it's own terminology which can sometimes get in the way of those who know subversion.
But without pointer indirection and dynamic memory allocation, why even use C? The big idea of C is pointers. Aren't there languages designed for mission critical and embedded environments (Ada for instance) ?
Hardware implementors suck at implementing firmware. Didn't you ever had trouble trying to boot from a pendrive? They couldn't get it right with BIOS, why should I think they won't screw it in UEFI? And if they screw it, what will be the workarond? Enable Secure Boot?
An option for free SMS is to use the free gateways that a large majority of carriers have set up. I have yet to find any legality against using them, and would be interested if anyone had any information on it. It takes a touch of time to set it up, but it is free.
If you choose that route then you can send an SMS message as a standard e-mail, and it's relatively easy to then monitor an inbox for responses.

My SMS Carrier Data
http://www.visionsofafar.com/SMSCarriers.csv
http://www.visionsofafar.com/SMSCarrierGroups.csv
A tl/dr version would be

1. Runway - how much runway do they have until they run out of money assuming revenues will not increase (which of course they should)

2. Culture - does it seem good? Good gauge - are people there even when they don't have to be.

3. Compensation - does it pay enough to make your comfortable and have upside in stake? If so, raises don't matter as much, make your own raise by adding value to your stake.
Putting GPS in a car to measure distance traveled is like putting cameras in your home pointed at your kitchen and bathroom sinks, shower and washing machine in order to measure water consumption.
Like the article that was recently posted about smart headlights letting drivers see through rain. Once you read the headline, you instantly know "camera(s), projectors, and motion-tracking algorithms" without having to click through to the article. Maybe the specific combination of motion tracking algorithms could be patentable for a short time, but not in such a way that an independent implementation necessarily infringes the patent.
Have people done hallway usability testing on git?

i.e. just take a smart undergrad CS major and record their screen (& audio) while they try to figure out how to use it. I think this would definitely turn up some tasks within it that are way harder than they need to be. Do people really feel confident that learning git is a smooth process, not involving a lot of swearing?

The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools! We shouldn't just keep insisting that the customer (programmers) needs to toughen up and learn (as the default answer, anyway; some things really are hard)

Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you?" every time you use a man page? I bet the success rate would be pretty low.

In general why isn't there any information about which man pages are good and which are terrible? They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. Yet there are probably ones out there which would be rated "useless" 99% of the time, and have been for 10+ years with no change.
And no matter how you look at it, these are children that would otherwise end up physically and mentally deformed

You really need to keep your racism in check. I really don't know what else to say if your view is this twisted.