Archivo de la etiqueta: Obsolescencia

Un sello distinguirá a empresas por fabricar productos sin obsolescencia programada

http://www.eldiario.es/norte/euskadi/obsolescencia-programada-sello-certificacion-empresas-partidos_0_454254701.html

La fundación impulsora de la certificación, que es gratuita, reclama a los partidos que incorporen en sus programas medidas contra esa estrategia comercial de reducir deliberadamente la vida de un producto para incrementar las ventas.

El impulsor de esta corporación es Benito Muros, un ingeniero conocido por su bombilla diseñada para durar 90 años.

mmmmmm

El espíritu de resistencia de los consumidores hacia la obsolescencia programada, la estrategia comercial de reducir deliberadamente la vida de un producto para incrementar su consumo, está creciendo. Y a esa tendencia opositora se suman ahora las propias empresas. Frente a los muchos fabricantes que diseñan productos o servicios de tal modo que, tras un periodo de tiempo calculado de antemano, se vuelven obsoletos o inservibles consiguiendo el incremento de las ventas y la aceleración del consumo, hay otros tantos dispuestos a abandonar esas prácticas. Un ejemplo muy conocido en Euskadi es el de Koopera, un proyecto dedicado a la reutilización de aparatos eléctricos y electrodomésticos.

Esta organización y el resto de las que rechazan la elaboración de productos diseñados para morir rápidamente, podrán ser distinguidas con un sello que certifique ese buen hacer.  Se trata del sello ISOPP, innovación Sostenible sin obsolescencia programada, al que puede aspirar cualquier organización que cumpla un decálogo de buenas prácticas. Entre ellas destacan que los productos sean reparables por un coste menor al de comprar uno nuevo o que la garantía del producto sea superior a los dos años obligatorios por ley. Lo novedoso de este sello es que se otorga además de manera gratuita.

Etiquetado , ,

Cómo el copyright puede hacer un tractor obsoleto

Cómo el copyright puede hacer un tractor obsoleto

Algunos productos de hardware se quedan obsoletos debido al software que llevan aparejado, pero los fabricantes ponen trabas para que los usuarios entren en sus productos con el fin de actualizarlos

Ocurre con un iPhone, pero también con un tractor. Para dotar de nueva vida al hardware la colaboración del fabricante es necesaria

Cómo fue el caso del jailbreak y Apple y qué piden ahora John Deere, BMW y otros fabricantes a la Oficina de Copyright en Estados Unidos

El Gobierno aprueba los últimos decretos de aplicación de la PAC para 2015-2020

John Deere es el nombre del mayor fabricante de maquinaria agrícola a nivel mundial. Podría ser el de cualquier ciudadano corriente de origen anglosajón, de hecho fue el nombre del fundador de la compañía, de profesión herrero, que emigró a Illinois en busca de mejor fortuna. La encontró y casi dos siglos después la empresa que creó domina su sector.

Los tractores y en general la maquinaria agrícola son productos con una vida útil longeva pero también muy costosos. Para un agricultor la compra de uno de estos vehículos es una inversión, que tratará de amortizar al máximo en los siguientes años. Asimismo intentará alargar la vida útil de su inversión, para lo que necesitará hacer reparaciones. Y aquí es donde entra en juego la petición que John Deere hizo recientemente a la Oficina de Copyright de Estados Unidos.

El documento enviado a las autoridades estadounidenses en materia de propiedad intelectual afirma que los clientes que compran sus vehículos reciben “una licencia implícita” para usar el software que contiene el tractor o la cosechadora. Esta licencia permanece vigente durante la vida útil del producto, según apunta el documento, y no permite que el usuario tenga la propiedad del software, solo derecho a su uso. Dada la creciente cantidad de software que contienen los vehículos, sin que los de tipo agrícola sean una excepción, este aspecto resulta fundamental para alargar su vida útil.

Alargar la vida útil gracias al software

Sin software, un smartphone no sería “smart” ni “phone” y un tractor moderno tan solo es una robusta pieza de ingeniería que no se puede encender. Los fabricantes de productos donde el software es esencial restringen las actualizaciones, de manera que con el paso de los años los dispositivos más antiguos no pueden instalar las nuevas versiones del sistema operativo o del firmware.

Ocurre con los iPhone, pero también con los dispositivos Android, pues los fabricantes versionan el sistema operativo, con lo que cada actualización del mismo tiene que pasar antes por sus manos para que sus terminales puedan instalarla. Sin nuevas actualizaciones el hardware se empieza a quedar obsoleto, aunque aún despliegue un buen rendimiento. A algunos se les podría alargar su vida útil introduciendo en ellos otro tipo de software más ligero, pero para esto es necesario acceder a las tripas del dispositivo.

Una herramienta de BMW ayuda a resolver un problema de mecánica difícil, pero la compañía no la ofrece a talleres y su propiedad intelectual impide que nadie construya algo parecido. El problema solo se soluciona en la planta de reciclado de BMW, por la que pasan 6.000 coches al año en comparación con los 1,8 millones que la firma vendió en 2012.

Por una simple cuestión de negocio, los fabricantes no piensan en alargar la vida útil de sus dispositivos, al contrario, cuanto más cortos sean los ciclos de renovación de producto mayores serán sus ventas. De ahí que se pongan trabas para acceder al interior de un dispositivo. En electrónica algunas marcas como Dell, HP y Lenovo ofrecen sus manuales de servicio abiertamente. En cambio, otras como Apple, Acer o Sony no permiten el acceso a sus manuales de servicio, reparación o mantenimiento. Si estos se filtran, las compañías hacen uso de sus derechos de propiedad intelectual para sacarlos de la Red.

Con una palabra que significa literalmente “fuga de la cárcel” se denomina al proceso de “destrabar” un iPhone u otro dispositivo de Apple, es decir, suprimir algunas de las limitaciones impuestas por este fabricante en dispositivos que utilicen el sistema operativo iOS mediante el uso de kernels modificados. Tras un jailbreak, el usuario puede acceder por completo al sistema operativo, descargar aplicaciones que no estén disponibles en la tienda oficial sin dejar de poder hacer uso de todas las funciones del dispositivo.

Apple llegó a afirmar que el jailbreak era ilegal en Estados Unidos porque contravenía el DMCA (Digital Millenium Copyright Act), pero la Electronic Frontier Foundation preguntó a un regulador federal si esto era realmente así. Un año y medio después se obtuvo la respuesta: hacer jailbreak al iPhone es legal en Estados Unidos, aunque Apple anunció que puede violar la garantía.

El móvil se convierte en un dispositivo médico

En el caso de los smartphones la conexión entre el software y el alargamiento de la vida útil del hardware se ve más directamente. Pero este nexo también existe con los tractores o con los coches. Este tipo de productos se podrían reutilizar más de lo que lo hacen, pero para ello serían necesarias técnicas de ingeniería inversa y el desbloqueo de los sistemas digitales.

Parar reparar estos vehículos, donde la vertiente digital ha adquirido una gran importancia, se necesita tener acceso a los códigos de diagnóstico y los esquemas de los circuitos. Se trata de información que los fabricantes mantienen en secreto. Tampoco ofrecen las piezas de reparación ni las herramientas, de software propietario, que ayudarían a la arreglar los vehículos.

En The Guardian expusieron el caso de una herramienta desarrollada por BMW que ayuda a resolver un problema de mecánica difícil de manejar. Pero la compañía no la ofrece a talleres y su propiedad intelectual impide que nadie construya algo parecido, con lo que este problema mecánico solo se soluciona en la planta de reciclado de BMW, por la que pasan 6.000 coches al año en comparación con los 1,8 millones que la firma vendió en el ejercicio de 2012.

El DMCA como guía

En Estados Unidos, el Digital Millenium Copyright Act entró en vigor en 1998 para legislar un campo borroso entre el hardware y el software. En esta ley se han amparado las compañías para afirmar que los consumidores no poseen el software de sus productos sino solo una licencia de uso. Algunas empresas han utilizado esta normativa para evitar que se modifique el software de sus productos, ya sean estos una tableta o un tractor.

Y es que para modificar el software muchas veces hay que copiarlo, para lo que a su vez hace falta romper la seguridad de los productos. De esta manera, cualquier hacker que lo haga está violando la legislación de copyright. El sector de la electrónica es solo uno de ellos: los coches y, como ha pedido John Deere, también la maquinaria agrícola podrían regirse por estas normas.

Son varias las marcas que han realizado peticiones similares a las de John Deere, que la Oficina del Copyright de Estados Unidos tendrá que resolver en el mes de julio, definiendo qué dispositivos se pueden modificar y cuáles no.

Por el momento, la inversión de 100.000 dólares que hizo Kerry Adams, un agricultor de California, en dos máquinas transplantadoras, se ha volatilizado. Las máquinas están rotas y sin una herramienta de diagnosis adecuada se antoja imposible la reparación. La suya es solo una historia individual.

Etiquetado , , ,

Lavadoras con muerte anunciada

http://economia.elpais.com/economia/2014/10/31/actualidad/1414761553_335774.html

Francia y la UE planean leyes para combatir y castigar la obsolescencia programada

Ordenadores desechados en un punto limpio de Madrid. / santi burgos

En el centro de reparación de Koopera, un grupo de cooperativas sin ánimo de lucro del norte de España, casi no se reparan frigoríficos. “No vale la pena. La mayoría llegan con fugas de gas que no podemos localizar porque las tuberías están incrustadas dentro de los muebles, y cada vez es más difícil desmontar los muebles. Hace años se podía llegar a cualquier pieza, pero ahora son todo obstáculos”, explica Txelio Alcántara, técnico del taller. “También es cada vez más difícil arreglar aparatos pequeños. Les ponen tornillos de seguridad, que solo giran para cerrar, y ni siquiera podemos abrirlos”.

Cafeteras, máquinas de afeitar, secadores de pelo, microondas, frigoríficos, lavadoras, ordenadores… Miles de aparatos acaban en la basura antes de tiempo porque es demasiado caro repararlos, por falta de repuestos o porque no hay modo de desmontarlos. Es una forma reconocida de obsolescencia programada, una manera de acortar la vida de un producto antes de que se desgaste. Un caso sonado fue la demanda colectiva a la que tuvo que enfrentarse Apple en 2003 por no ofrecer baterías de recambio para sus reproductores MP3. Los demandantes, tras probar que las baterías se estropeaban antes que el aparato, ganaron el juicio y obligaron a la empresa a fabricar repuestos.

Sigue leyendo

Etiquetado , , , , , , , ,

Francia aprueba castigar penalmente la obsolescencia programada

http://www.ecoportal.net/Eco-Noticias/Francia_aprueba_castigar_penalmente_la_obsolescencia_programada

07/10/14 Por Gonzalo Garteiz

Los diputados franceses han aprobado en la Asamblea que establecer una duración determinada de un producto por un fabricante, la denominada obsolescencia planeada, se puede castigar penalmente, acarreando una pena de prisión de dos años y una multa de hasta 300.000 euros que se añadiría a otras ya integradas en la Ley de Consumo.

La introducción del castigo penal en una práctica de la cual se abusa en muchos procesos productivos, la fabricación de electrodomésticos y aparatos electrónicos, bombillas, etcétera, se debe a una enmienda de los Verdes en el proyecto de ley de la transición energética, que considera la obsolescencia realizada premeditadamente un engaño y un fraude. Los Verdes son el grupo político que más ha combatido esta práctica por considerarla muy dañina para el medioambiente y la sostenibilidad.

El Comité Económico y Social de la UE exige su prohibición en toda Europa La posición francesa trae el debate a toda la Unión Europea. El próximo 17 de octubre, el Comité Social y Económico Europeo (EESC, por sus siglas en inglés) organiza una mesa redonda sobre la obsolescencia planificada de la que se espera surja la presión necesaria sobre la Comisión Europea para que se castigue esta práctica. El EESC ya hizo una llamada a la prohibición total en un pleno en octubre del año pasado.

Sigue leyendo

Etiquetado , , , , , , ,

Engineering obsolescence

http://ethnographymatters.net/blog/2014/04/21/engineering_obsolescence/

Marisa Cohn

Editor’s Note: Marisa Leavitt Cohn writes to us from Stockholm, where she is a postdoctoral scholar studying the politics of software systems and computing work practices.

In this contribution to the series on Hackers, Makers, and Engineers, she tells us about her research on relationships to technological change in a long-lived NASA-ESA software infrastructure project. Her research considers how people live alongside technological change, inhabit the temporal rhythms of computing work, and approach concerns of legacy, inheritance, and survival of computational practices as they contemplate the end of life of the mission.

Marisa has a BA in anthropology from Barnard College and a PhD in informatics from UC Irvine, and she’s joining ITU Copenhagen as a professor in the fall. She’s a member of the ISTC-Social


Ethnographers have often been positioned in the technology field as translators between the worlds of technology use and design. When I first began my fieldwork with an engineering team at a NASA space science mission, I thought I might be able to trouble this dyadic concept of translation work between design and use by examining a case in which a complex set of translations took place between a diverse set of organizational actors, from scientists to engineers to managers. Indeed, I observed the engineers on the team working on a weekly basis to turn hundreds of observation requests from scientists all across the globe into commands that can be executed on a spacecraft over a billion kilometers away. This complex translation work was supported in turn by hundreds of software tools that had been developed over the years to, as one engineer described it, “turn scientists’ dreams into vectors.”

 

Yet when I presented early versions of this work to the social computing research community, I found that the relevance of my work was often challenged. The engineering project I was examining was deemed a “one-off,” a bespoke system that served a single purpose, and which was ultimately “disposable” since the spacecraft would be destroyed in space once it had run out of fuel and completed its mission. Not only that, the software tools that I was studying in organizational contexts were now decades old. They were written in FORTRAN and some of the earliest graphical interface programming languages, tools which have largely been abandoned by the engineering community – reaching end of support, dying out, or even being actively petitioned into retirement.

These challenges begged the question – what is to be gained by studying the work of engineers maintaining a space robot from the 90s? What is the role of the ethnographer in studying the so-called technological “dinosaurs” – the old-timers who are stuck in engineering methods and tools of the past? What relevance do these obsolete software tools and engineering practices that go along with them have for understanding technology today? Even to many of the engineers at the mission, my interest in their software tools seemed a bit odd. As one responded to my research,

You think our software is interesting?! It’s not Google or anything.

Legacies of a 90s space robot

These questions put me on the defensive about my contribution to the study of sociotechnical systems and my role as an ethnographer in the field. What was my role, as a translator or participant or otherwise? One of the roles I was enlisted into at the mission organization showed that this defensiveness was a part of my informants’ reality as well. I was asked to help with their work towards a final mission report, to help preserve some of the stories of their engineering accomplishments for the historical archive. The archive of scientific data was already assured, but what about the engineering knowledge gathered over the course of the mission? Might the work they have done over the past two decades be of any use for future outer planets missions? What if there is not another mission of this kind for another 50 or 100 years?

 

As Charlotte Linde has pointed out in her work considering the question of whether we still remember how to go to the moon, obsolescence of storage formats and engineering architectures means that we may find most technical specifications and infrastructures useless in the future. Yet the struggles and pains that the engineers I studied went through in figuring out how to sustain cutting-edge science with the limited computational resources of an outdated vision (from a time when 2 gigabits was considered forward-thinking) might yet have some value. Their questions about the translatability of engineering practices across generational gaps and changing engineering paradigms became my own, as I too had found myself in the position of having to justify the relevance of understanding their social-computational work practices, and ask what role the ethnographer plays in translating across engineering cultures past and present.

This caused me to reflect on the ways that ethnographers of technology are often called upon to understand what is technologically au courant. As recent critiques have pointed out, studies of technology have tended to focus on novel systems and their introduction and adoption and adaptation to various contexts, presenting a bias towards the early phases of technological life cycles. This is a time, perhaps, when technologies are still open-ended and malleable, when ethnographic work might provide value through design implications or critique, or when cultural values are embedded into systems with consequences for how these technologies in turn shape current practices. This is not to say that such work is not critical of the privilege placed on novelty and innovation, but there is still a tendency not to make visible the stories of when and how technologies become old or outdated.

This same tendency plays out in the world of planetary science. By the time the spacecraft was on its way to its destination, the history of the mission as an engineering accomplishment was in many ways already written. The long term maintenance and operations of a spacecraft is engineering work that is marginalized and largely invisible within the public outreach about science, or in celebrations of the historical significance of the work being done at NASA. It is devalued by a “done at launch” perspective that treats infrastructures as static resources – management thinks that “it does the job, and the job can’t change,” one engineer told me, so why should the software? At the same time, engineers are under increasing pressure to bring their infrastructure up-to-date in ways that stretch an already quite lean and fragile set of resources that maintain communication with the distant spacecraft.

In studying such legacy computational systems and obsolescent forms of engineering work, I found myself going against the implicit norm and pressure to study technologies that are current, not least of which seemed to stem from a concern that my work might be deemed obsolescent and irrelevant. Yet there was something intriguing, if a bit foreboding, about the role of ethnographer as a preservationist of dying (engineering) cultures and (programming) languages that hearkened back to the problematic colonial origins of anthropology’s study of the dying cultures and languages that such colonialist enterprises were participating in killing off.

As a result, I gave a lot of thought about what it even means to be technologically current or to be technological contemporaries. Early ethnographic work has been critiqued for constructing narratives of progress and a great chain of being in which so-called savage practices were considered backwards and taken as a window into the past. What does it mean, then, to claim that current engineering practices are backwards and stuck in the past? Is nothing to be learned from a bespoke system that has evolved over many years, even if in many ways it has evolved itself into oblivion? What is at stake in claiming a technology as irrelevant because it is obsolete, or a “one-off” or “disposable” piece of technology? Are we constructing a great chain of engineering cultures and how then is the ethnographer implicated within that?

What can be learned from legacy systems? Image courtesy the Computer History Museum.

One implication of this evolutionary framework might be a claim that some forms of engineering work have remained static while others have moved on. In actuality the engineers I studied with have continued to work with and further develop a continually dynamic and changing system. They have been exploring what might reasonably be considered a alternate set of engineering frontiers, doing things with obsolete programming languages that have never been done before, finding out what happens as an infrastructure gets old and becomes new again and again through loss, aging and decay. Another implicit claim might be to acknowledge that their work practices have co-evolved over time but that their “one-off” is a system without a legacy. It is an evolutionary dead end.

If we examine such technological systems within the context of the lab, we can see the co-evolution of practices and technologies is still afoot. There is always work to be done to keep older systems working with newer ones, and the idiosyncrasies of practice can continue to reveal novel challenges. Even “bugs” in software that is over 40 years old can surface for the first time after years of routinized work. However, when we place such systems alongside their technological contemporaries, within the context of the larger ecology of the technology industry, we realize that there is more at stake than perhaps an evolutionary framework can capture or describe.

Understanding obsolescence as a process

While it can sometimes come as a shock, the sheer abundance of legacy systems in the world means that the work of maintaining such systems is worthy of empirical investigation. Recent work on repair and database graveyards has called for precisely such an understanding of this tail end of the technological life cycle as something not well understood. What work is involved in maintaining the ability to translate between new and old systems to keep them (backwards) compatible? How do engineers working on this mission stay current in their careers and skills? How does obsolescence happen in practice?

As one of my colleagues put it,

If we were all at the bleeding edge, we would be bleeding all the time.

It turns out that the majority of systems are legacy in some way, and if we are not studying these, we are missing a big piece of technology and engineering practice. But what this also calls attention to is the fact that while we may be critical of novelty and notions of technological progress, our participation in studies of the contemporary can participate in this very privileging of the new if we do not attend to the forms of loss and decay that are concomitant with processes of innovation – that is, if we ignore the ways that we are in fact bleeding all of the time, and just just mop the blood on the floor under the rug, or fail to ask what kinds of technological possibilities we are cutting away?

Even the more progressive politics of human computer interaction and feminist science and technology studies, which call for open-ended (rather than deterministic) understandings of technology, are still invested in something that might be called “evolvability” – the inherent possibilities in (or design value of) technology so that can evolve along a multi-directional path and into multiplicity. What work might an investment in a notion of technological “evolvability” do towards increasing processes of obsolescence?

Long-lived technological imaginings

There are some obvious ways in which a study of obsolete systems work might reveal insights of value. For one thing, if we are interested in shifting design towards more sustainable and long-lived systems, perhaps we should look at one that has already been sustained over many years. Is longevity something that we can achieve through developing systems that are more and more evolvable, so agile that they can remain forever relevant and current? Or, as some of my interlocutors in the field suggested, perhaps that is a naïve perspective: “Sure, the new software systems are more adaptable, more flexible,” he said, but the software used on this mission “has been around for 40 years or more. Do you think that python will still be the language that is used 40 years from now?”

While it should be obvious that any software tool or programming language will have a limited lifetime, this becomes a rather profound statement in the face of quite commonplace over-evaluations of present technologies and their futures. His statement also points out how even such values as adaptability are merely trends in software methodologies that are subject to the whims of obsolescence – or they may even participate in accelerating obsolescence.

One of the more serious consequences of this naiveté is that it obscures what is at stake here: not the death of a particular obsolete programming language, but the kinds of technological commitments that are necessary in order to imagine long-lived sociotechnical outcomes. Science missions to outer planets of our solar system become unimaginable within a framework in which technologies must be impervious to obsolescence. It takes seven years to get to Saturn, for example, and seven years is now longer than the life cycle of many technologies we design. In this paradigm, we all, engineers and users alike, have gained the skills of adaptation and evolvability, of short-lived commitments to technology, at the expense of more long-lived ones. As anthropologist of memory Paul Connerton has pointed out, planned obsolescence is itself a form of forgetting, one that is a necessary form of participation in the market.

The consequences of studying the cutting-edge

It may seem an over-reaching analogy, but if we think about the seven years it takes to get to Saturn and what it means to understand phenomena on the temporal scale of the Saturn year (29.7 earth years), we also have to imagine how our investments into technological agility might actually preclude our understanding of processes in other domains on similarly large temporal or geopolitical scales. In other words, the foreshortened lifetimes of our technologies may actually be participating in the foreshortening of other kinds of lifetimes.

As others have pointed out, we have shifted from a time when storage was expensive and processing cheaper (the world where my fieldsite still resides) to one where storage is cheap and processing is expensive. But what makes processing expensive is in part that we are so wasteful with the storage we do have, because we believe that the unlimited powers of future processing can be applied to our current storing practices. From the perspective of a long-lived system, this is naïve because of the obsolescence of storage media and the obsolescence of any particular software programming language or development paradigm. Who knows if in the future agile processes may seem outdated and not suitable to the kinds of work that needs to be done? What if slow computing, light on storage, and carefully and ethically sourced modes of processing, are actually the way of the future? What if we actually should be looking back to find a way forward?

~~~

Returning to the question of the role of ethnography in understanding contemporary engineering cultures, what would it mean to consider how obsolete engineering cultures that sit side by side with current ones are not representative of the “past,” nor of some “phase” in a essentialized technological evolutionary life cycle. Instead, they are different sociotechnical forms with different temporal patterns, and studying them might actually give us clues about the a much richer set of possible technological futures we might yet imagine.

When I first arrived to my field site, I did think of it as a kind of window into the history of computing. In many ways it was the pedagogical experience in computer science I had always dreamed of but never received – an immersive introduction to computation in practice where the histories of the field are not erased away. Oral histories of where and why a particular tool was developed were still intact. I could learn not only about new technologies but also FOTRAN and hex code. As some of the engineers pointed out, this diversity of old and new is what makes long-lived technologies a rich environment in which to work, instead of the “cookie-cutter” approach to software development found elsewhere.

However, after spending 9 months with these engineers, I realized that being an ethnographer is not only about encountering different sites of technology production, but understanding the temporal dimensions of these technologies. I was situated not within a “past” of engineer culture, but within a context which could reveal something about the lifetimes of technologies and what it means to live along side of them. I came to see myself not as a preservationist, but as someone who is a member of an engineering culture that is currently entranced with short-lived systems rather than long-lived ones. That the processes of legacy-making and obsolescence are also open-ended ones – and that I might be able to participate in building legacies that are yet to come.

 

Sigue leyendo

Etiquetado , ,