amboar

What are the benefits of make-kpkg over the kernel's own 'deb-pkg' make target?

This is exactly how I work as well. My feeling is the only way to truely understand a piece of code is to try solve the problem yourself and not simply read someone else's solution. But, half the battle is then understanding _every problem the code is solving_. Often this seems undocumented. Further, even the simplest high level problems often have a bunch of corner cases that are only documented in a solution's implementation, and it's on encountering these corner cases in your own solution that it becomes obvious why the code was written in its original manner. Coming to a full understanding of the problem and solution often leaves me happy to throw away my own attempt. Sometimes I'll simply end up adding some comments to the code about the problems it's solving.

Sure, so long as the bug is a genuine bug and not a misunderstanding. Debian's openssh valgrind warning springs to mind. Crypto implementations can be subtle and non obvious. Maybe it's crap design for that reason, but it seems like it's what we've got to work with currently.

I don't know what the gp's skills are, but assuming he's not a computer security professional then the 'other people should do this' club is exactly the club he should be in. Would you trust his audit of the code if he wasn't heavily experienced? it's the same case as "don't roll your own crypto".

Right. Yes - I missed the workspace specific part of your complaint before replying - sorry about that.

As paulyg mentioned above, you can use Alt-` (tilde) to cycle through multiple instances of an application after using Alt-Tab to select the group. I think it actually make the experience less tedious.

I actually thought "what's he done /this/ time?" before reading the announcement. Then wondered the same thing.

I've been thinking about this a lot recently after discussing the merits of code review against design review for software. My opinion very much aligns with the article, and I've started drafting blog posts/essays describing my arguments just to get a clear understanding of what they are. I'll have to get them cleaned up and reviewed so I can contribute to the view...

Not to detract from the interesting difference between pointers and unbounded arrays in a struct, but get_at() is surely broken. It looks like the condition uses the wrong inequality:

int get_at(const struct foo_t *foo, int pos) {    return foo->len >= pos ? -1 : foo->data[pos]; }

!(foo->len >= pos) = (pos >= foo->len) => foo->data[pos] = foo->data[foo->len + x] where x >= 0, which is undefined.

It seems the author got caught up trying to be tricky, and the fix has the bonus of reading more naturally:

return (pos < foo->len) ? foo->data[pos] : -1;

It is late though. Maybe my brain isn't in gear...

No worries. Just throw them both in your .bashrc and you should be good to go.

Here's the tab completion script:

http://pastebin.com/mR8y1Rks

Note it's the only tab completion script I've written, and it's probably a hack :P

Here's the script for ct:

http://pastebin.com/M1k1WL88

Looks like I wrote the tab-completion script on my work machine. I don't have access to it right now, but if I remember when I do have access I'll pastebin that as well.

I'm on my phone at the moment, but I did something similar except avoided the counting. I have a shell function called `ct` for "climb tree" where you specify the name of the directory you want to climb to; calling it will place you in the first directory above cwd whose name matches the argument and in addition I wrote a bash completion module for it so I only have to type minimal characters. I'll post the source for both shortly.

This may sound a little batty and is perhaps off-topic, but some time ago I bothered to do an unofficial upgrade of my galaxy s purely so I could install the Woolworths (Aus supermarket chain) Android app. It has the ability to create and store multiple shopping lists, and to sort lists by aisle for the store of your choice. Best feature for ninja strikes; get in and get out with maximum efficiency. I hate shopping.

Is it really so much effort to format your patch as required in comparison to doing the work to create the improvements you claim?

Clearly the sane route would be write T in C then once complete run T through T to emit a C to go translator in go.

The top seven are all things I'm concerned about, but I was initially surprised at the fact that my preference order is pretty much the reverse. Then I wasn't surprised. Then I was just happy that permission over-reach, intrusive ads and forced social logins made it to the top seven.

'3. "Earnings missed estimates." No. Earnings don't miss estimates; estimates miss earnings. No one ever says "the weather missed estimates." They blame the weatherman for getting it wrong. Finance is the only industry where people blame their poor forecasting skills on reality.'

I reckon the software industry could give that last claim a run for its money. Ignoring incompetence, sometimes there simply isn't an elegant solution that fits time, budget, stability and technical debt constraints, yet it's somehow not an estimate issue.

Err, whoops... that was unintended. I read the article, reached the end, thought it was interesting and hit share. Damn Ars and their pagination! I will pay more attention in the future.

I thought it was mildly amusing and it held my attention. I understand your point of view though; whilst I work a lot with open source software I also work for a closed source shop that uses closed source products. As you mention some things will never be an itch that any one would want to scratch and others are just way out of reach, however that shouldn't detract from the benefit that open source software provides, especially to people that have skill but not necessarily domain knowledge: At least they can learn from it, not just build on top or be required to settle for workarounds. However, as you mention, that requires the happy nexus of domain knowledge and computing skill to have contributed some code in the first place.

In conclusion I thought the article made enough of a point to be worthwhile, though maybe it's been done to death and could have been delivered in a less snarky fashion

Probably this guy, because he curates ccan: http://rusty.ozlabs.org

Previous submission: https://news.ycombinator.com/item?id=6546700

At work I have set up a nightly Jenkins job to merge all verified, un-submitted patches from Gerrit and process the resulting history with Sonarqube[1].

This has revealed many bad habits and allowed us to correct them through review comments prior to changes being submitted. It's also shown me just how "legacy"[2] our code-base is, but thanks to sonarqube (which runs PMD and FindBugs as part of its analysis) we're improving.

[1] http://www.sonarqube.org [2] http://www.amazon.com/gp/aw/d/0131177052

The collection maybe a little eclectic, but ccan might interest you: http://ccodearchive.net

Yeah, I read through the forum to set whether this was a mistake in the article. I think my point was that the lazy author was the source of confusion of the name.

I don't know why the article needed to conclude with 'The explanation is "a little geekalicious,'' he said'. The article would be much better without that one sentence.

The article currently says "Sandpit"

I've found a good approach to resolving the last issue is to write the documentation for the method. This forces you to think about what you want it to do outside of the implementation.

Interesting. What's the rough order of magnitude of the "end state" patch size? 50, 500, 5000 lines?

Given one of your other comments here, I get the impression you don't use code review tools much, eg Gerrit. Is that the case?