" 1 + 3 * 4 is still parsed as 1 + (3 * 4), but 1+3 * 4 is parsed as (1+3) * 4"

What. The. Fuck?

I think the main point is to have a low-cost development board that people can use to port their software to AArch64 and/or test it on that platform (as said by the AC I originally replied to). I'm also sure that even with bandwidth limitations, the octocore will prove its worth when running our compiler test suite.

Additionally, the AArch64 instruction set has been redesigned from scratch and a lot of historical baggage and special cases have been thrown out (e.g. no more arbitrary changing the PC with half of the available instructions, and no more two different instruction sets with dynamic switching between them), so it wouldn't surprise me if over time AArch64 processors could actually become more power-efficient than regular ARM cores. Right now the AArch64 cores still include the ability to run regular ARM code too, but I'm pretty sure that over time this functionality as well as the entire regular ARM line will be dropped in favour of AArch64.

This. Just logged in because I wanted to say exactly the same. Until now, afaik the cheapest option was actually a jailbroken iPad Mini 2 (and you obviously can't run Linux on that).

Like wiki pages, Flow posts have their own revision history. Flow-enabled pages have a wiki-style header. Each thread has a summary which can be community-edited. Threads can be collapsed and un-collapsed by anyone. All actions are logged. In short, wiki-style principles and ideas are implemented throughout the system.

However, a core property of wikis -that the structure of the page can be edited in any shape without the need for programming- is missing. Flow is a threaded conversation system by design, and only a threaded conversation system - it can't be tweaked by their users into something else, and the sequence of comments is shown in order enforced by the tool. All discussion regarding how the tool could be generalized to support other kind of collaboration workflows or those basic needs such as reordering and merging comments, which are trivial to make in the basic wiki "everything is a stream of text" model, were dodged or delayed to be studied at future "more complex" use cases. That didn't provide any confidence that those needs were understood by the design team.

I find your post interesting, and your points in many ways are an accurate analysis of many major problems with Wikipedia - yet I still find your point 11 ("The wiki is the problem") a non-sequitur. A wiki is in essence a model for data storage, where the expectations for interaction and data management are closer to control versioning than to the classic CRUD cycle. As such, it's a neutral tool that could be used in many other ways and improved to cover most of the current shortcomings; in particular, there's no reason why those other "practical solutions" and workflows for organizing content couldn't be built on top of a wiki-like storage layer, so the contradiction you see doesn't exist in essence.

The problems you mention are for the most part caused by the community dynamics and rules, with a few caused by the current wiki platform, rather than the wiki storage model itself.

The only point directly related to organizing things as a wiki is point 6, "Page ownership" - which is a real problem, but only exists because of the decision to build an encyclopedia where each page is an article that can be edited by anyone, not because the tool for storing the page is stored a wiki system. Every other point is caused by the project's original view as an anarchist playground which permeates all its policies, not any inherent limitation of the software.

-----

As for the approach taken by newslines.org, I agree that there's a need to give visibility to contributions from any user without giving the next editor in the line the possibility of removing them completely without trace; though that doesn't the benefits of a wiki.

Newslines is good for news-driven topics, but there's a need for an encyclopedia-like description of the topic, that a list of unrelated news doesn't cover; there needs to be a coherent wording that describes the highlights of the topic and how each part relates to the whole, and a wiki page covers that need. Compare the pages for Ebola at Wikipedia and at Newsline - which one would you prefer for first learning about the disease, and which one for staying up to date with recent developments? It's clear that they serve different, complementary purposes.

Thank you for giving it a spin and reporting back, glad your tests worked. :-) Our policy is to not execute JS at all on older browsers like IE6 and IE7 (for security and maintenance reasons), which has the side effect of keeping us honest in ensuring all core features work without JavaScript.

Hey gl4ss, these are fair points, but I stand by my original estimate, including overhead & travel. A couple of things to keep in mind: 1) Although WMF is based in the SF Bay Area, it is a non-profit, there are no bonuses or stock options, and base comp is good but not as high as you can get elsewhere. We also hire internationally and our teams often include remote folks in regions with different pay scales. For positions like community liaisons, we often hire younger folks who don't get quite as high an hourly rate as an experienced engineer would. 2) Yes, managers need to get involved, there are meeeetings, etc., but our engineering managers tend to be responsible for pretty large groups (20+ folks) since teams working on user-facing features have their own dedicated Product Managers and most of the day-to-day decision making exists at the team level. This reduces the risk of micromanagement and keeps managers focused on supporting teams rather than getting in their way. 3) The delta in compensation between engineering managers and engineers is not as high as you might think.

Hi TuringTest, thanks for your comment! Contrary to your past tense, Flow continues to be in active development, and continues to be deployed to new use cases, most recently a new user help forum on French Wikipedia, and a technical support forum on Catalan Wikipedia. Since the only way to roll out a system like this is to replace existing use of wiki pages, we're proceeding conservatively to test it out in social spaces where people want to try a new approach, and improving it in partnership with real users in those venues.

It's true that talk pages, being ordinary wiki pages, support "making your own workflow". I love the Douglas Engelbart reference, though I doubt Engelbart would have remained content with talk pages for very long. The lack of a discrete identity for separate comments makes it impossible to selectively monitor conversations you're participating in (you literally have to use diffs to know what's going on), or to show comments outside of the context of the page they were added to. This is a pretty tough set of constraints to work with. At the same time, you're absolutely right that a modern system can't simply emulate patterns used by web forums or commenting systems like this one.

Like wiki pages, Flow posts have their own revision history. Flow-enabled pages have a wiki-style header. Each thread has a summary which can be community-edited. Threads can be collapsed and un-collapsed by anyone. All actions are logged. In short, wiki-style principles and ideas are implemented throughout the system. At the same time, we believe that as we add modern capabilities like tagging, we can replace some of the convoluted workflows that are necessary in wikitext. Already, Flow adds capabilities missing from talk pages -- notifications for individual replies, watching specific threads (rather than a whole page), in-place responses, etc. More to come.

Hello metasonix! First, congratulations on the successful article submission. In answer to your question, I was referring to LQT development. LQT was put into maintenance mode in early 2011, so of your "10 plus year project", about 7 years elapsed with a little bit of paid effort dedicated to the development of LQT. $150K max spent (not all of it by WMF) on LQT is really a high estimate -- Andrew Garrett, the only dedicated developer, also worked on other projects during that time, including the widely used AbuseFilter extension.

Flow development kicked off in summer 2013, about 18-19 months of development effort so far by a team that's fluctuated in size but currently comprises three full-time engineers, about half a person's time for UX design and research, a product manager and a community liaison. During that entire timeframe, I would estimate money spent on the project so far at less than $1M. Even if you combine both efforts, "millions of dollars spent" is pure hyperbole, and adding up elapsed time to exaggerate scale and scope of these efforts is equally misleading.

I've been following the development of Flow, and it's definitely not hyperbole.

The problem with Flow is not that it's not a valid talk system, it's that Wikipedia talk pages are not mere talk system. Even if Flow was the niftier, most standard, most boring talk software, there were needs in the ways that the users actually use the software that were never addressed in its design, and which caused all the backlash.

Wikipedia talk pages are based at their core on a wiki system, and wikis are the closest thing to the original vision of a hypertext made for "augmenting the human intellect" - it's the purest native digital way to store information for collaborative authoring and communication; it's the equivalent of clay for modelling thoughts, and Flow was a mere striped notebook. Flow took the power away from their users, and the users revolted.

Flow might have been an interesting tool to be used on a different new project, but was a poor fit for the existing user base, who were already used to a more powerful and flexible tool.

The article summary speaks of "millions of dollars spent" on a new discussion system for Wikipedia. The article actually tells a very different story -- the LiquidThreads extension started out as a Google Summer of Code project, was funded for a while by an interested third party, and then received a little attention from the Wikimedia Foundation (one designer, one developer) before development was put into maintenance mode. I would ballpark the total money spent around $100-$150K max. Elapsed time does not equate money spent. LQT continues to be in use on a number of projects, but its architecture and UX needed to be fundamentally overhauled.

Flow, the designated successor to LQT, continues to be in development by a small team, and is gradually being deployed to appropriate use cases. It is now running on designated pages in a couple of Wikipedia languages, and old LiquidThreads pages are being converted over using a conversion script developed by the Flow team. Contrary to the article's claim, WikiEducator upgraded to a recent version of LQT, and will be able to migrate to Flow in future using the conversion script.

You can give Flow a try in the sandbox on mediawiki.org and see for yourself whether the article's claims are hyperbole or not. Disclaimer: I am the person referenced in the headline of the Wikipediocracy article, so take my view with a grain of salt, as well. ;-)

LEGO is an abbreviation (though not an initialism) of Leg godt, danish for "play well" - or perhaps more like "have fun (playing)"

So it appears that it is an acronym

It's not, actually. It's a portmanteau.

Lego is likely quicker to use and more easily accessible than creating the same from "real" mechanical parts. So not necessary, but quicker and easier - and within the zero budget they likely had for doing this.

Not quite what I'm saying. Your tools make some things easier, and other things harder. And what those things are will change depending on which tool you have on hand.

To take your kitchen analogy, if you have a blender/food processor it's easy to make things that need a lot of fine mincing or difficult blending. You _could_ still do it by hand with a kitchen knife, a bowl and a whisk, but as a practical matter you're less likely to even consider such recipes because of the time and effort required. Imperfect analogy, but it sort of points to what I want to say.

Back to photography, I have a DSLR, a 35mm compact and a medium-format rangefinder, all with the same field of view. And technically I can take the same shots and get the same picture with any one of them (modulo technical quality differences). Yet, the different way they handle nudges me to look for different kinds of situations and different subjects. In theory I _could_ take the same picture with any one of them. As a practical matter I could not.

These are tools.

Off on a tangent, but yes, these are tools. And the tool we use shapes not just the result but what we attempt to do, and how we approach the task. In other words, irregardless of the technical similarities, using a different kind of camera (or camera-lens combination) will give you different results.

As a simple example, if you have a long zoom lens on your DSLR, you will look for, and shoot, very different kinds of pictures than if you had a small, wide fix-focus lens on it. A DSLR will invite different kinds of pictures than a pocket cam, or a smartphone. Switch to a film camera and the limited shots and lack of feedback invites yet other ways to see pictures around you. Go further out and try an old TLR, or a medium-format folder - or a view camera! - and the world will change around you again.

We want to have many different cameras not because one of technically reasons, but because they enable different kinds of photography. Nobody expects the car industry to settle down on a single type of car. Why should cameras?