It is ridiculous of course. It is also a common attitude among PI's toward their postdocs and students, especially in high-profile, high-pressure labs.

This letter from a PI to a worker made the rounds a few years ago. The PI claimed later it was a joke. It doesn't read like a joke, and the exact same attidude is not uncommon at all:

http://www.chemistry-blog.com/...

I used to ride every day. But my place of work changed, so now I walk and take the train instead. Around home we generally walk as well, so my bike sits unused for months on end.

Walking is also good exercize of course, but it does limit the range of places to go. I should fix up the bike and start using it again come spring.

Automation changes the source of production from workers to machines. And that separates the source of production from the source of consumption.

To put it simply, robots produce wealth but does not consume it. Humans consume wealth, but (in this possible future) can no longer produce it. Robots have owners of course, but even if you ignore what happens to the majority of people, a few extremely wealthy people can not possibly make up for the consumption shortfall. Ten-thousand people with 10k each vastly outconsume (by necessity) a single person worth 100M.

So, if the entities making wealth and those using wealth become separate, you need a way to transfer wealth from one to the other. If not, you will see a slow-moving economic collapse, as lack of demand and cost-cutting automation drive each other down.

A basic income, generated from a tax on production (transaction tax, energy tax, direct tax on machinery) is one way, and has the benefit of being simple, straightforward and having low administrative overhead.

The time spent selecting questions, then answer them in a simple and understandable way is not free. Especially in a climate where even keeping a blog in your spare time is sometimes seen as a suspect frivolity that takes time from your research.

That said, I spend several years of my life helping to get rid of the Morse Code test for radio hams, so that smart folks like you could just take technical tests to get the license.

I'm currently assembling a Softrock Ensemble receiver just to play with SDR. I'm starting to become interested in more than passive receiving â" but a major part of my curiousity is about Morse, not voice. I can talk to anybody over the net after all, while Morse code communication feels like a very different kind of thing.

[...] and rather than cutting the least important program, they cut the most visible program, in an attempt to get their funding restored.

Honestly, though, a qestion-answer service for school children probably does rank among the least important programs for a research lab. I very much doubt this is part of their written remit (as opposed to communicate their actual research to the public), and the people spending time at work answering the questions certainly get zero professional recognition for it.

It does sound like a very nice, fun service. And I do agree that this kind of outreach is important. But if this is not part of what their funders want them to do, then it should come as no surprise if it's among the first things to go when money becomes tight.

You want this kind of thing to continue? Make sure there's funding (and paid time) earmarked for doing it. In fact, that may be a good idea in general: add a small fraction (.1% or even less) to any research grant over a certain size for general science outreach. If it's part of your funding, that also removes the career obstacles toward doing outreach we too often have now.

[...] please ensure that your channel's primary focus is on gaming or music creation."

Sing your code. Problem solved.

So, "assert(Ieiei == True)"

becomes

"Aaaand IIIIIIIIIIeeeeiiiiiiieeeeiiii wiiiiilllll aaaalways be Ttrrrruuuuuuueeeeeeeee"

I'm talking about the silicon chips doing the things that our brain can do, such as designing the next intel chip.

The major stumbling block isn't processor speed or capacity. It's that we don't know how to architect such a system in the first place.

And if you think about it, a lot of the "smart" things we want to automate really don't need anything like human-level or human-like intelligence. A car with the smarts of a mouse would do great as an autonomous vehicle. Real mice manage to navigate around a much more difficult, unpredictable and dangerous environment, using a far more complex and tricky locomotion system, after all.

Software testing doesn't protect against a user pressing the wrong button, which then works as expected. I agree it's a management error, but the failure in such cases is a lack of user testing.

Systems should be designed to follow the interactions that are more likely to be made by users, not the other way around - forcing users to follow the path that a developer thought would make sense. Unfortunately, user-centered design is still a foreign concept to a good chunk of developer houses.

Or you can blame the idiot designer who didn't properly explain the consequences of "doing this" in their black-box interface, so that the user could make an informed decision.

" 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.