Hacker Newsnew | past | comments | ask | show | jobs | submit | ericgj's commentslogin

I couldn't agree more. Well said!

The [Ethical Open Source definition][1] does include three general points on behalf of the end user: accessibility, safety, and privacy. But it does not address the relationship between developers and end users: how do those who will use the software have a voice in what gets developed? And how could it - as you say, it's time to move past licensing as the sole focal point.

[1]: https://ethicalsource.dev/definition/


> how do those who will use the software have a voice in what gets developed

Should they? If they want some feature, they can ask nicely or make a PR. Are there other options?


Thanks for your part in getting this story published!

If you have not seen it, the BBC series "The Century of the Self" details the pre-history of these tendencies in the creation of the public relations industry by Freud's nephew Edward Bernays [0]. It is truly fascinating and horrific -- all 4 or 5 hours of it!

Social media/big data has also made the consumer a (not fully willing or conscious) _producer_ of mass addiction, through the exploitation of their social graph data. There is a fictive "work contract": give me your data and we'll give you your buzz. This relationship is based on unwaged work. What if this work, the value of it to BigTech, were recognized? It leaves open the possibility of mass refusal. And in some sense how people use social media now is already composed of many types of refusal, some more and some less effective. To state one obvious way -- Facebook is used around the world as a tool for political organizing. The fact that this makes it an even more valuable commodity for repressive governments, starting with the US government, does not stop us from using it and finding it effective, does not stop us from getting together "in real life".

More needs to be said about the social basis of addiction. It's not only ad scientists pushing well-studied biological buttons. It's the trauma of living a society that locks up an insane number of people, puts its children on psychotropic drugs, poisons them with toxic environments and toxic fast food, separates poor children from their mothers, criminalizes their survival, abandons entire communities after natural disasters, bulldozes neighborhoods to make way for hi-rise condos no one can afford, etc. Or the even bigger trauma of living in a world that has the guns & money of this toxic society pointed at them, literally or potentially, every day, forcing migrations and threatening survival of entire populations.

All of these things come into play when we look at why virtual realities are more attractive than real ones, and lead us to have some sympathy for those who use them for networking with others and temporary escape.

If you have not seen it, I recommend reading some of Gabor Mate's work on addiction, for instance "In the Realm of Hungry Ghosts".[1]

[0] https://youtu.be/DnPmg0R1M04

[1] Interview with him: https://www.democracynow.org/2010/2/3/addiction


I found David Nolen's talk at React conf useful in understanding the motivation for cursors. https://www.youtube.com/watch?v=5hGHdETNteE. See in particular starting around 15:40. Cursors are used when you are strict about global immutable state; whereas Flux (like React itself) is agnostic about this. IMO this agnosticism means you end up with a more complex architecture. David's point in the video is, even with cursors and immutable state atoms, you end up with a parallel set of complications to deal with -- around questions of inter-component communication across nodes of the tree and information hiding. He sketches Om's current solution to this using observable cursors which kind of let you trace data-change dependencies between components - but I have to say without understanding Om better it's a bit hard to follow.


Can someone explain the advantages of using this over mori (which doesn't include cursors per se at the moment, but are easy to implement on top of mori data structures)?


Amongst other things, it's about 1/4 the size, and sticks to plain JS for those not familiar with ClojureScript.


Yah. I don't know ClojureScript but that doesn't stop me from using it. And David Nolen pretty convincingly addressed the size question in "Javascript Modularity Shaming"[1] - i.e.: use Google Closure Compiler.

[1]: http://swannodette.github.io/2015/01/06/the-false-promise-of...


Shouldn't they be studying how we can get more restful sleep rather than fantasizing about extracting more work out of us? I don't consider it 'productive' (much less healthy) when I spend the night grinding on some technical problem. The Mendeleev anecdote and 'solving problems in your sleep' are about something entirely different, to me.


Very nice article.

You lost me a bit towards the end re event communication but then I haven't played with d3's events. It would be great to see an article just on that.


It's a great action - and technically speaking takes us to a new level I think - I look forward to adapting the code for other campaigns I'm involved with. I appreciate the background and your work involved in bringing groups together internationally.

But my question is, with the publication/confirmation yesterday of the basis of the US drone assassination program in NSA cellphone spying (see https://firstlook.org/theintercept/article/2014/02/10/the-ns...), will you be incorporating a demand to reign in the NSA because their surveillance is killing innocent people? I think it is a real opportunity to reach out to many other groups and individuals who are opposed to and organizing against the drones both in the US and abroad.


Follow you around like a drone eh? Look, we're not the ones who politicized the term. A robotic bee mascot is not going to put off people's discomfort. Which is unfortunate because it looks like a really promising tool for CI...

cf. "The NSA’s Secret Role in the U.S. Assassination Program", published yesterday... https://firstlook.org/theintercept/article/2014/02/10/the-ns...


Haha all the proud mercenaries of HN quick to shoot down any hint of politics in their little world... A good number of us INside the US (not to mention Europe and elswhere) would certainly think twice about using a tool called drone. A lot of us want our government to stop killing people by remote, is that such a strange point to make? It is really quite an ignorant name to use, as bachback said.


Hey, Philip - thanks for posting this and also the previous write-up of your experiences as a helper in the 'boot camp' (http://pgbovine.net/teaching-librarians-programming.htm). It is very valuable, including the photos. Very nice, multi-generational group - must have been quite a challenge!

But I agree with calhoun137 when he says there is no fundamental user/programmer culture divide. Programmers are users with a deeper understanding and wider toolset. We all want to get stuff done quickly and move on with our lives rather than drown in computer-driven drudge work. So it seems like a course for beginners should start from that common point, and really be focused on (a) uncovering the problems they're already solving by hacking together the tools they know (e.g. getting data into Excel charts, or whatever) and (b) using the inefficiencies in their solutions to motivate learning or building tools with more leverage, etc.

I can't help but think from your description, the student "regular users" are the ones with a pragmatic/hacker approach, using the limited tools they know -- while the instructor "programmers" are the users stuck in religious attachment to their arcane tools. Maybe the course would go better adopting some of that "regular user culture", AKA hacking ;)

I'm sure it was more complicated than that and for one thing I can really empathize with having to deal with massive variety of platforms etc. Might be worth setting up a common VirtualBox image that everyone (students and instructors) use from day 1, to avoid some of that headache?

Anyway, thanks again for the write-up.

Eric


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: