elehack

Didn't intend to imply anything negative by "abnormal". It just isn't the "traditional" way to use processes for a user-facing, semi-desktop system. But given Android's special-purpose, single-user nature, it is a perfectly logical system (and quite clever, really). It just isn't the way users are used e.g. on my Fedora laptop.

I simultaneously welcome and fear this development.

It's a great move for security, as a well-configured SELinux deploy can provide much finer-grained access control than standard Unix permissions (although, given that Android uses the Unix user & permission model a bit abnormally, I don't know if it will bring benefit over that or not).

OTOH, for locked devices, it gives vendors more tools to prevent rooting.

Why not? Classes are just one implementation/realization of OOP. They're the most common, to be sure, but they're by no means the only way to do objects, nor are they necessarily the best.

“There is more to OOP, Horatio, than is dreamt of in your philosophy.”

Yes, not all complexities are created equal.

Haskell, and to a bit of a lesser extent Scala, have a lot of their complexity arise from combinatorial explosion of interactions of simple features.

Also, relentless abstraction (particularly in Haskell). Yes, you can think of lots of things as arrows. But does it necessarily make it easier to write a particular problem to do so, or does the cognitive load required to maintain the abstraction <-> problem mapping outweigh the benefit of casting it as the abstraction?

I've also found my Scala experience to feel disturbingly reminiscent of C++ (and I have grown to love Scala). I find a significant difference, though, in that C++ has a lot of complexity, while Scala has a lot of complex emergent behavior from a few simple core ideas (and the complexities needed to work out their details).

Then there's the library, where yes, you see a hairy mess like that. Very difficult to read and understand, but it is a powerful combination of relatively simple and orthogonal concepts. Which doesn't necessarily mitigate the complexity.

FWIW, you rarely need to write code with types that complex, and there is talk in the Scala community of how to simplify the presentation of methods with complex types in the documentation. But that doesn't make it more approachable today.

I think it depends a lot on what you're wanting out of the language.

If your primary goal is Java sans pain, then Xtend, Kotlin, or perhaps Groovy should fit reasonably well and have a gentle-ish learning curve. Both Xtend and Kotlin seem to be designed particularly for this niche, with a dash of Scala-is-too-complex mixed in to their marketing materials.

If you're wanting an interesting new language that goes beyond traditional Java thought patterns, however, Scala (or Clojure) seems like a much better option. Both Scala's type system and its deep and insightful fusion of OO and functional thought make it a far more interesting language to think about and work with.

IMO, YMMV, etc. of course.

I think that this kind of abuse is an irresistable temptation of a walled garden. If the garden's curators don't succumb to it themselves, the single-point-of-pressure is too much of a temptation to would-be government or external private sector censors.

When dealing with situations like this, we have a couple options. We can accept walled gardens and hope that the gardeners are made of stern stuff and love freedom.

Or we can reject walled gardens and demand ecosystems in which this kind of blocking can't happen, not just won't.

I prefer worlds where it can't. Trusting that it won't is setting up for disappointment IMO.

First-to-file doesn't nullify the idea of prior art. If your invention is published before first filing, it still counts as prior art for invalidating patents.

I hope Jeff succeeds in promoting an alternative to the level of ubiquity of PHP. I think PHP is a generally awful language, eclipsed in sheer programming linguistic badness only by such systems as MUMPS (which, fortunately, I have never had the opportunity to work with). Fractal of bad? Check.

And it isn't just a bad programmer thing. PHP's bad habits encourage novice (or uncaring) programmers to pick up bad habits, especially if they are not particularly inclined to study how to use their tools well. Given a language where the obvious thing to do is right vs. one where it's wrong (see PHP < 5 database queries - no prepared statements, mysql_escape_string) vs. an environment where the obvious thing, encouraged by the introductory tutorials, is right, I think that the more correct/safer language will encourage programmers to write better code.

But reading the comments here and on Jeff's post, it is humbling to remember that people are using it, every day, to build more and better software than I ever have. I may have a visceral dislike for the language, but good programmers are able to do good work even with a double-clawed hammer.

Tin-foil-hat reason: it has been shown that there exist a set of numbers with a particular relationship to the elliptic curve numbers, and that it is possible that whoever generated the elliptic curve numbers may also have generated the other set of numbers, which basically form a skeleton key to ECC.

Schneier on the attack: http://www.wired.com/politics/security/commentary/securityma...

Yes, but Apple was the first to make lockdown an acceptable, or even desirable, thing for general-purpose consumer computing devices on a large scale. The idea was around, and implemented in a number of places (especially on phones), but Apple was the first to pull the marketing trick of getting the world to accept or welcome it in a domain thought of as computing rather than peripheral or special-purpose devices.

There is a fine line between slippery slope as a fallacy, and the legitimate concern that the very existence of a feature like this invites abuse. Or the even more legitimate desire to build a world in which bad actors (corporations, governments, etc.) cannot do remote evil, rather than a world that works only because they don't do remote evil.

That which does not exist cannot be abused. I'd much prefer a world where authorities cannot disable software, not a world where they merely don't.

That's not fallacious slippery slope reasoning. It's an argument for structural and technical rather than merely moral, ethical, or legal impediments to abuse of authority.

We have a solution for this: preliminary injection.

IANAL, so perhaps this is still opening up for lots of liability, but I'd much prefer Apple say "You want it taken down? Ask the judge for a preliminary injunction. Until then, go away."

Preliminary injunctions are the due process mechanism for causing the action to cease while it's litigated rather than continue. They, not Apple's whim/decision/liability-aversion, should be how this kind of thing happens IMO.

There's a crucial difference: it's easy to tell when someone violates a Do Not Call list. They call you.

It's a lot harder to detect, and probably harder yet to prove, when they're engaging in illicit tracking.

Bing gets everyone's search terms merged together, with no way to distinguish individual users. To Bing, it looks like one user doing a bajillion searches on all manner of topics.

In the AOL case, while IP addresses were stripped, users were identified with unique keys so you could see individual users' search sequences. That is not the case here.

Very nice - this will make RFC reading much easier. Would be nice to have DuckDuckGo use it - will submit !bang request.

Any timeframe on finishing RFC coverage? RFC 3514 isn't prettyfied yet.

> 1. The applet to inhibit screen sleeping went away. Without it, I often look up from working on a hard problem to discover that my screens have been blanked out.

The Presentation Mode shell extension fixes this - adds an option to the drop-down menu on the power meter to turn on presentation mode, disabling screen blanking & locking.

> 4. About half of the GNOME configuration has moved to gconf to dconf, but there's no rhyme or reason as to which half. When I discovered the new settings applet, I tried to change stuff with gconf/dconf, except I have no idea how to figure out which applications use what settings storage backend.

I think finishing this migration is a work-in-progress.

Don't have immediate solutions for the rest of your gripes. Gnome 3 seems to be a love-it-or-hate-it thing; I find it to be great (modulo a few bugs and quirks, but it isn't everyone's cup of tea.

I've been quite pleased with TinyTinyRSS lately - it's got some UI bugs, esp. in the web client, but self-hosted web-based RSS reading + sync to Android client is full of win for me.

I tried not to confuse them, but don't seem to have done a good job.

You are correct, the non-redistributability of many O'Reilly books is what they would they would object to, not cost. And not all O'Reilly books are non-redistributable - they have a number of books under open licenses.

You go over to O'Reilly and buy a DRM-free e-book. Now, the FSF likely won't suggest that because they don't like mentioning the existence of “non-free” documentation, but IMO one of the best ways to protest DRM is by saying, with our pocketbooks, that we want e-books and are willing to pay good money for them but find DRM unacceptable.

If Tor had gotten their DRM-free book thing in order by now, rather than waiting until July or so, I'd probably also be buying a Tor e-book today.

Partly - the Unix philosophy. Since you can swap out your window manager on X11, you can have your windows managed in any of a wide number of ways. If an application tries to manage subwindows on its own, there is a very good chance that it will do so differently than your global window manager. Assuming that there is a reason you picked the global WM that you did, it's rather disconcerting to be forced to use an inferior WM to manage Gimp's windows.

Add to that the multi-desktop, multi-monitor aspects (although detachable docking panes can help a lot with that).

That's why DMCA takedown notices must be filed with an assertion, under penalty of perjury, that the request is legit (requestor is authorized to issue it, it is an infringement, etc).

Not perfect, but it does make a pretty big disincentive to being caught issuing fraudulent takedown notices.

Branching is one of the big differences. I find Mercurial's named branches mostly useless; fortunately, with some care, bookmarks can be used to simulate Git-style branches.

I think, early on, the Mercurial community favored cloning as the means of creating feature branches, while Git used named branches to do so. But in many cases you want to be able to switch lines of development in a single repository (especially when using a workspace-based IDE like Eclipse), so the Git model becomes a win.

This comment - and several others - seem to only be seeing half the picture in this new policy. Yes, it says they won't distribute software the know to infringe.

But the other aspects of the policy set up working practices and operating procedures to minimize visible, organizational knowledge of patents. It seems to me that they're actively trying to avoid knowing about patents so that they don't have to invoke the no-distribute clause and, if they do get sued, can hopefully keep away willful infringement claims. I think that's in general been their goal, but the new policy provides a clear and consistent mechanism for handling the issue.

They didn't - last I knew - distribute LAME or other MP3 encoders. I think the patent enforcement situation has changed since that call was originally made, but earlier (late 90's, early 2000's), the patent owners were enforcing patents for encoders but not decoders.

Actually, wrapping the code in {} does make a difference with 'let'. A 'let' in braces does not escape the braces.

It's a “bug” (and yes, I'm using that deliberately in an opinion-as-fact sense) because it is a blatant violation of the Principle of Least Surprise, especially for those coming from C-style backgrounds. If you are a C-style language (which JS is), and you do something in a non-C-style way, you should have a very good reason (besides implementation artifacts and/or not thinking robustly about scope). I haven't seen anything indicating that var's behavior is a well-reasoned, principled choice - as far as I know, it's just how JS 1.0 worked, and we're stuck with it.

In my opinion, unnecessary surprise as a result of historical implementation artifacts is a design bug.

Yep, need to learn about it. Yep, you can, and write good JavaScript. But that doesn't mean the design is good.

JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis.

However, they cannot change var's semantics and retain backwards compatibility. So they did the next best thing: introduce a new keyword for variables that work like they should. That keyword is 'let'.

As far as I am concerned, if your JS is known to execute in an environment with 'let', 'var' might as well not exist. Too many subtle errors — “what do you mean, braces don't actually delimit scope?”

I use the excellent fastutil for primitive collections - it has great integration with java.util collections, and has a more standard design than Trove in my opinion. Works great.

I really like seeing this bill come up - the opposite of the Research Works Act, and a bill that will greatly improve access to research in the U.S.

I am concerned, however, that it uses “peer reviewed journals” as the standard for mandating publication. Computer science does most of its ongoing publication in conferences, not journals; also, specifically naming “journals” seems to me to invite name games, unless journal is defined sufficiently broadly in the bill's text.

I would prefer to see the requirements kick in when research is published in any peer-reviewed publication.

But still, this bill is a great step forward, and things like this are details that can hopefully be worked out.