Niten

OK but before we all get on the public shaming bandwagon, I ask whether you know for sure that Ortiz is the primary target of Lessig's (rightful) criticism here? I know Ortiz was involved, but Lessig doesn't explicitly name Ortiz in this article and he refers to the prosecutor as a "he".

And please pardon my skepticism if it is in fact Carmen Ortiz, but I'm not familiar with the case and I think a healthy dose of skepticism is a good idea whenever "internet justice" is called upon.

Anyway, rest in peace Aaron.

I'm perfectly fine with that, but you seem confused about the argument here. GPL code distributors don't have the right to say curiosity, or any other reason, is invalid cause to enforce the GPL.

And while I do not have standing to request GPL licensed code from Tesla, they have a legal obligation to either distribute that code directly, or a provide a transferable offer to distribute that code, to their customers. Code properly distributed as such inevitably would make it back out into the wider open source community; this is the design of the GPL. If Tesla currently does not meet this obligation under the GPL, that is a problem.

> If it's curiosity, well, I wish we weren't enforcing that with the GPL.

It's simple, either you comply with the GPL or you don't distribute GPL-based code. As an author of GPL licensed software, I think it's pretty damned arrogant for someone like you to imply curiosity isn't a good enough reason to get back modifications in accordance with the chosen license. Who are you to judge? And anyway, what reason could possibly be more worthy than curiosity?

It's the authors' choice, not the peanut gallery's; and if they hadn't intended for all distributed modifications to be made available under the GPL, they would have chosen BSD or another license instead. And if you don't like that, too bad.

Because of the GPL, companies using Linux are required to release the kernel modifications they made to get it running on this wide variety of hardware, and this improves Linux as a whole.

EDIT: This article's extreme focus on the consumer mobile market is pretty narrow-minded, though: "There’s no denying the success of Linux in many areas, with Android being the foremost example." No, if you want to see where Linux really dominates, look to HPC and embedded systems.

I had no idea about that, thanks

As much as I don't like Microsoft, I actually think the .NET CLR would be an excellent choice for such a runtime. NaCl not so much; target architecture-dependent compiled code is a major downside.

Yeah I'm surprised to see them essentially drop support for this common workflow... downloading auto-tarballed tagged SCM commits is insufficient for Autotools projects, or other situations where you need to do pre-processing on your source code with (potentially fragile / version sensitive) tools which you don't want to require your end users to have installed.

It's not like inexpensive file hosting is difficult to come by these days, thankfully. And it's probably better for one's main distribution site to be on a domain under one's own control, anyway. But it was more convenient to be able to just put it up on GitHub, and somewhat more inspiring of confidence in the source archive's integrity.

I wonder how much this feature was costing them, anyway? And whether they'll lose out in any significant way when links to projects' canonical release archives point away from GitHub...

I am by no means a Microsoft fan or Windows developer, but if auto-generated code is that big of a deal to the author then he really needs to spend some time playing with Visual Studio...

But like I explained in detail above, using Mercurial bookmarks it is tedious to avoid pushing your throw-away branch to the main repository, and you can't simply delete the branch when you're done with it. Git is much superior in this regard.

More options, certainly, but I find git to be much more painless in this regard. Mercurial doesn't have anything equivalent to git's convenient workflow for creating temporary, local throwaway branches, without changing to a new working directory.

I use both extensively (git for most personal projects, Mercurial at work), so I feel like chiming in here.

I really do think that Mercurial's user interface is easier for beginners to pick up, and more difficult to shoot oneself in the foot with. It's the little things, like the fact that Mercurial's push and pull commands do exactly the opposite of one another, that hg clone/pull URLs are identical to what you type into a web browser to browse the repo, and the ease of dealing with Mercurial "bare" repositories (hg up -r null) for mirroring and backup purposes.

And the way Mercurial's command-line interface strongly discourages one from modifying history; it makes it harder for things to get messed up on a small team coordinating with a shared-access repo. Yes, I know git has the reflog, but in general people seem to have much fewer "OMG WHAT JUST HAPPENED TO MY BRANCH" moments with Mercurial than with git. That (along with mq, which provided a unique solution to our team's needs) was the major reason I chose Mercurial over git at work. If we're going to brandish about the term "UX" here, then I'd say Mercurial definitely has a better "UX" than git.

But Mercurial has pain points, too. The biggest one, in my opinion, is the way branches work: Mercurial started out with named branches, which it seems the community has recognized as a mistake, and has moved to replace with git-style branches (called "bookmarks" in Mercurial land). These work better, but there are still some drawbacks: for one thing, Mercurial lacks the notion of a "remote", so unlike in git your local bookmarks and remote bookmarks have to share the same namespace. This leads to counter-intuitive behavior when it comes to synchronizing bookmarks with a remote server, and often you'll find that bookmarks aren't necessarily updated when you'd expect them to be.

Additionally, the notion of a "tip" makes working with feature branches frustrating, because by default Mercurial will check out from whatever branch was pushed to most recently, rather than a de-facto standard "master" as in git. Hand in hand with this complaint, by default Mercurial will want to push all your changesets, not just those under your current working bookmark, so you have to constantly specify e.g. "hg push -r master" to keep from pushing local throw-away branches. And it's not easy to delete local throw-away branches if you decide you don't want them (the downside of Mercurials aversion toward history modification), so one generally winds up using a separately-cloned repo for temporary work, which is unfortunate in contrast with git.

Mercurial and git are both great, efficient, high-performance tools. But if I had to generalize, I'd say that Mercurial is better for beginners and for "enterprisey" usage, whereas git, despite its interface inconsistencies, can be more powerful once you fully understand it and its data model (but only if you aren't working primarily on Windows, and don't need Mercurial Queues).

Dalvik isn't the JVM, and Android is more than Dalvik.

Android applications can also rely on ARM binaries developed against the NDK, so full ARM emulation is required in order to realistically test these.

Is it brash to suggest that maybe those "8 white guys" actually did have the most merit out of all candidate speakers, and that you would have done the conference a disservice by bumping one of them for someone else, based on sex or gender alone?

Whatever racial or gender or economic biases might exist that influence the shape of the global developer community, these need to be addressed at the source: in kids' youth when many programmers take on computers as their lifelong obsession, or in high school curricula and college programs.

The conference organizer's job, as it pertains to race and gender bias, is to provide a neutral selection process that chooses the best speakers on their own merits. Their job is not to diminish the quality of the conference by imposing their own, nobly intended but horribly misguided, form of bias on the candidates. More than hurting just the conference or the candidates, I fear that this can have serious unintended consequences relating to public perception of the quality of e.g. female programmers, in the same way that "affirmative action" does on college campuses.

> I was excited until I saw "use autotools".

People love to gripe about autotools, but if you take the time to understand it and get comfortable with what it is and is not, it will get the job done.

There are alternatives like cmake, but they just suck differently. I use autotools to manage cross-platform (Linux/glibc, Linux/uclibc, mingw32, OS X) C library projects and their Python extension module wrappers, with heavy dependencies on system-specific functionality and symbol replacement (e.g., if strlcpy isn't in libc, then link in libbsd if you can find it there, otherwise compile our own copy of strlcpy.c). Autoconf is a wonderful tool for this once one RTFMs and gets over the fact that it's a bunch of helpers for writing a shell script, rather than a fully abstracted programming language of its own.

Or in the words of Lennart Poettering, "every custom config/makefile/build system is worse for everybody than autotools is":

https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=...

First this is patent, not copyright law.

And the issue is that Apple has effectively committed libel against Samsung in the UK with its repeated claims that the Samsung tablet is a copy of the iPad. This claim has turned out to be legally false, and now Apple is obliged to correct any turn of public opinion against Samsung that it instigated by making this false claim in the first place.

Cool stuff... Andrew Ng's excellent Machine Learning course on Coursera also had a programming exercise that involved using k-means to reduce an image's palette (in Octave, though, rather than Python), so if you find this interesting you might consider signing up for his course the next time it comes around:

https://www.coursera.org/course/ml

Maybe some AP courses don't hold up as well, but for my part I took AP Calculus BC and Physics C in high school, and using solely what I learned there was able to ace my electricity and magnetism and calculus III courses at a well-respected engineering school without touching the textbook.

My experience may have been skewed by unusually good teachers, but making that kind of legitimate education available to high school students is anything but a scam.

Wait, Level3 is a patent troll now?

I'm taking both of those also, and the math in ML isn't intensive... but there is much more exposure to calculus and linear algebra in ML than in Algorithms I, and while I agree with the other commenter who said Andrew Ng walks you through it, an understanding of both helps with getting the "why" of things like the gradient descent formulas introduced in the linear regression lectures.

The ML course does start out with an optional linear algebra review lecture, but it's very focused on mechanics rather than underlying mathematical reasoning... for conceptual mastery (or even just brushing up) I'd recommend going through Khan's videos on the subject, if you have the time.

It's hard to take comments like this seriously when the private American health care system has worse outcomes and more than double the cost of numerous socialized systems.

You can blindly chant "government isn't the solution" all you want, but it doesn't change the fact that it undeniably is the solution in a large number of countries with functional health systems.

In truth, I wouldn't use anything other than a plain Python string to represent an artist's name, if that's the only thing about the artist you're interested in. But it's hard to have a meaningful conversation about such a contrived example as in that link.

To answer your question, though, yes: all other arguments about Python vs. Java aside, the LOC ratio would change dramatically in Python's favor once you start to add actual program logic. (Unless you're stuck with an architecture astronaut for a Python programmer.)

> The real question is what does the function do, and how does it accomplish it?

Precisely, and this is where git's simplicity shines compared to other systems. After one takes some time to learn git's data structures, it's trivial to understand exactly what effect each command has on your repository. No need to mentally model your source control system in leaky abstractions, the reality itself is simple enough to handle directly.

> The first thing that struck me about git is the apparent use of SHA1 hashing as a basic foundation for the whole system. Maybe that's not even true and no doubt there is much more to it.

Yep, it is true, and that really is all there is to it. For a quick overview, see: http://gitready.com/beginner/2009/02/17/how-git-stores-your-...

> I was not aware that there were many implementations of git. I'll now be looking for some other implementations. On github of course.

Github itself runs on a proprietary Erlang implementation of Git.

With regard to your first link, I really have to take issue with code like the following as a measure of Java and Python's relative verbosity:

    class Artist:
        def __init__(self, name):
            self.name = name
    
        def __str__(self):
            return self.name

There may be an argument to, as you say, "Never, never, never use String in Java" (or other statically typed languages), but a class like this in a duck-typed language such as Python is nonsensical.

I'm not even arguing that Python's dynamically typed approach is necessarily better overall than Java, but if you're going to evaluate the two in terms of verbosity then you really have to compare idiomatic code in both languages. Whereas if you continue writing Java in Python, of course you'll only see a 2x improvement.

> As for git, it's not nearly as simple as people portray it to be.

git's famous simplicity is in the form of its well-designed and stable (and well-documented) underlying data structures, it has nothing to do with the size or runtime dependencies of a particular implementation.

> 3. You can't do closures in Java. You can. It's just incredibly verbose.

It looks like you're confusing closures with lambda expressions. That's an example of (a more verbose functional equivalent of) a lambda expression, but it isn't a closure.

Java's anonymous inner classes can close over variables in enclosing classes, but they can capture only final variables directly from the enclosing lexical scope. So Java actually does not support true closures.

> Perhaps the solution is to have legal weight (perhaps like 'Lawyer' or 'MD') behind the title, as countries like Canada have (the US has this to some extent, but it's not nearly as strong).

But here you're taking it for granted that professional licensure of software engineering is actually desirable, which is not at all agreed upon. Among the organizations against the notion are the ACM.

Huh, I didn't realize that some hardware folks are still so irrationally jealous of the label "engineer" being applied to software engineers as well. In truth the distinction between a physical versus information end-product as a prerequisite for the term "engineer" is arbitrary, self-serving on your part, and not recognized by any common definition of "engineer" of which I am aware.

Not to be too hard on you though; yes, the biggest aesthetic difference between hardware and software engineering is that with the latter, the cost of fabrication is essentially zero. But as described here: http://www.ics.uci.edu/~jajones/papers/p439.pdf

> The essential distinction between software and other engineered artifacts has always been the absence of fabrication cost. In conventional engineering of physical artifacts, the cost of materials and fabrication has dominated the cost of design and placed a check on the complexity of artifacts that can be designed. When one bottleneck is removed, others appear, and software engineering has therefore faced the essential challenges of complexity and the cost of design to an extent that conventional engineering has not.

So naturally the set of constraints is different than the ones with which hardware engineers contend, yet software engineers do fundamentally apply math and science to design products to meet hard, real-world constraints: Development time and cost, program correctness, time and space performance under expected load, reusability, and maintainability to name a few.

If there is a valid objection to the notion of software engineering as a "real" engineering discipline, it should be that a subset of the science upon which the discipline is based – that of software architecture – is at this point still underdeveloped and poorly understood, and as a result software engineers generally rely on their own intuition when it comes to architecture. (This in contrast to fundamental computer science, which is well developed enough that we can typically determine from mathematics or empirical evidence what kind of algorithm or data structure to use under given circumstances.)

But an arbitrary bias that engineers produce only physical artifacts does not constitute a valid objection.

shrug I do think it's interesting to find out, in concrete terms, the sort of real-world assumptions that a compiler might make, which make C's undefined behavior what it is. Yes, pointless in terms of fixing the actual program, though... to each his own :)

Yes, at the risk of sounding arrogant, what is this doing on the front page of HN? This isn't a security flaw and it isn't new, it's a well-understood Unix design decision.

If the aim was to educate people about Unix design principles, then it would have been useful to include references to the relevant specifications:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/un...

or at least have some meaningful discussion about the rationale for this design and its consequences. But this is just a statement of well-known fact with no context or added value, placed behind a link-bait title.

The thing I find most interesting about Flame: whoever developed it surely understood that by being released into the wild like this, their new cryptographic attack was guaranteed to eventually be discovered and analyzed. And yet they spent that attack's secrecy on a (very sophisticated, but still) fishing expedition.

So what cryptanalytical capabilities do they have which are considered too sensitive to expose via malware?