I urge you all as fellow members to avoid purchasing this book. Save your time and money, as they're both valuable things that this "amazing" new theory that promises to change the world will waste. The creators want us to believe that Aspect will make some programming utopia, but you know what? Hitler said the same thing about his "great new idea" and look where it got him.
Object-oriented is a common sense, practical way to view the world. You treat the variables in your program as objects, and you think about how a real-world object and what its private values would be and what operations you would be able to perform on it. It's a very pragmatic approach.
I've read this Aspect book, though, and it sucks. There's nothing new or innovative, as I'm sure you can see from the Hello World example. Does it look like any ordinary Java or C# code? Yup.
So please, save yourself thirty dollars and a heck of a lot of time and don't ever touch this book. Spend time improving the code you've already written rather than wasting time on theoretical gibberish that won't result in any improved programs.
What we really need is better error prevention, not some new style to program in. Get your priorities straight.
I just heard some sad news on talk radio this morning - millions of expensive tape backup devices were found murdered in a Palo Alto convalescent home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss them -- even if you didn't enjoy making backups of your backups of your backups, there's no denying tape's contributions to popular culture. Truly an American icon.
Here you go, I translated it best I could with Babel. It's also just in case their server goes down.
---
Backups in videotapes MiniDV By Guillem Cantallops Ramis , Beowulf ( http://bulmalug.net/beowulf/) Created 03/03/2003 02:56 and modified for the last time 03/03/2003 02:56
Lo primero que se te ocurre cuando usas Linux o algún UNIX y sabes algo del formato MiniDV es "vaya, en esa cinta tan pequeña caben casi 13GB de datos crudos, y se graban a razón de 3.6 MB/segundo, mejor que muchas unidades de cinta para backup... estaria bién poder usar la cámara para eso!"
Y la verdad es que tiene sus problemillas, porque se trata de usar para datos generales algo que ha sido diseñado desde el principio para almacenar video, pero también tiene algunas ventajas: es divertido, si lo haces bién funciona, y sale barato si ya tienes la cámara. Veamos con qué herramientas podemos hacerlo.
Tools available
"pack" basic of tools consists of dvbackup (1) and rsbep (2) . That I know they are not in Debian (in other distributions nor idea) so there will be to lower them, to compile them and optionally to pack them by hand. They are quite small programs, with a very simple Makefile, and they are compiled in a while. I for the preliminary tests simply have put binary in my ~/bin. An important detail: for Ia-32 rsbep has the part "lasts" of the code optimized in assembler, and runs enough, but for other platforms (for example I have proven it on PowerPC) it is necessary to compile it in pure C and to work, works, but... already me entendeis... does not fly indeed.
Bién, before beginning to play with the programs, we see how they do it (although "the good" explanation is in the connections that I have happened to you ; -)
A little teoria
Basically the MiniDV uses a compression lossy , that is to say, with loss of quality, that reduces the video information to 1/5 of its "crude" size (this ratio is fixed), which usually does not affect seriously to the quality of imagenes (safe in very abrupt changes) due to the highly redundante nature of the video. This compression lossy actually seems lossless , because she is much less aggressive than any type of MPEG, to put an example: one was to arrive at a good commitment between ratio compression and quality from image, and they did bién enough.
But it is a compression clearly lossy , even without entering details on the used algorithms I I see it intuitive in terminos of of entropy: in worse of the cases (highly improbable if we captured real images) podria of arriving a sequence of virtual images impossible to compress, with a near entropy 8 bits by byte. In a case therefore the only form to reduce that information to a fifth part of its pasaria initial size to throw to the sweepings four fifth parts of that information. And as MiniDV always maintains the ratio of 1:5... is clear that it is lossy . This bién written podria to be a demonstration by absurd reduction to, but the good one, if therefore it is understood... Or; -)
He is already bién of filosofia. The question is that the video remains in "sad" () 25Mbps thanks to this compression. Without counting the audio one. And the compression somewhere uses fundamental discrete cosine transform (DCT) on blocks of 8x8 pixels. Yes, it remembers the JPEG, but now we spoke of video and in addition we worked with much quality. Each block has associate coefficients AC and DC, and standard allows to finish ("to truncate") AC with code special, so what the authors have done of dvbackup it has been simply to use the DC to paint a pretty pingüino that will visualize in all frames of the videos of backup, and to truncate coefficients AC immediately to use all the remaining space for the data of backup. As far as the audio one, one keeps without compressing in the tape. Simply dvbackup indicates in each frame that it will not be used audio, and stuffed the space reserved with more data. Brilliantly simple, and it works with many models of MiniDV cameras, including my Sony Dcr-pc101e (, by the way very recommendable because as much the video by FireWire as the photos by USB are transmitted without problems to any Linux with kernel recent... are many other models, but this he is the one that I have proven ; -)
Backups generic and restrictions of the MiniDV tapes
Like the tools that we will see next take the data from the standard entrance and somehow they end up putting them in the videotape, and what we love is to create and to recover backups of one or several systems of files, or parts of them, we will have to process the data somehow to turn them stream (a.k.a. "churro" : -) of bytes that serve to feed those programs.
Briefly, it will be necessary to use the typical ones find|cpio , or some similar thing, to select and to pack the files in one single one since all the life has become. And in principle that resulting file will be the standard exit, but there is a small problem: its 25 the MiniDV tape is recorded and frames per second (PAL) reproduces to and of you do not move it there, at least not in a normal camera. If your machine is too slow you can have problems writing in (and even reading of) the tape, which the programs that we will use more ahead call underrun or overrun according to the case.
If you are not able to feed sufficiently fast the tape when you are recording, in principle the program is able to introduce frames special without information to signalize underrun, and the only thing that happens a priori is that you waste space in the tape... but if it happens quite often (and surely it will happen, if your machine does not arrive is that it does not arrive and point) you can lose too much space for your pleasure. If however you are not able to process in "real time" what it arrives to you from the tape, you lose relatively great parts of information (overrun) and can quedarte without recovering backup, which is obvious bad. In fact if your hard disk is too slow and/or is too full there is nothing no to do. But it is that also the CPU, as iBook is the case of my, with a PowerPC G3 500MHz and a hard disk UDMA33 can limit you. We will see more ahead than often he is advisable to use compression (gzip or bzip2), and mainly detection and correction of errors (with rsbep, the other strong plate of the article). All that, together with the previous work of find|cpio (to cross the system of files and to copy things are not "free") and to the later work of the packing of the data in frames of video and the transmission by the FireWire, it can too much be for many machines. All can do it, but the problem is to do producing it an exit of 3.6MB/s maintained. For that reason often he is recommendable to use a file like intermediate storage. At least I with that technique was able to save the limitations of power of my iBook. The idea is "to divide" pipes that we will see more ahead by the part that connects dvbackup|dvconnect yet the others. Thus the critical part of read/write of the tape is made desde/hacia directly a sequential file, without hardly additional calculation. Clear that the best thing is to have a great machine and to leave itself of tonterias ; -)
We began to form the commandos...
In order to see examples of use of find|cpio , simple examples because these programs are not the subject of the article, we will suppose that we want to do backup of all ours/home , that is in a single partition. In that case, a form to obtain stream of backup by the standard exit (that is what it interests us to join it with later commandos soon, although podriamos to redirigir it to a file if we wanted) is this sequence, quite classic:
find/home | cpio - or - H crc
The part of find list by its standard exit the files that we want to keep, and the part of cpio it takes this list by his standard entrance, a code packs the files adding detector of errors CRC, and removes the result by its standard exit. So it is not happened to you to execute it so as because it will show backup to you by the terminal, thing that can be interesting at some moments to enter critical moment or something thus, but not now. In addition teneis will take much and that to finish reading this article:-P
The following thing that deberiamos to add is: compression, of optional form; and detection and correction of errors, forced form. On the compression, nothing that to say: everyone will know when it needs it, and as it is a relatively slow process often the best thing is not to use it if there is sufficient space in the tape. It is almost just like when you transmit data by network, mainly if the network is a fast LAN: if you use compression you can encontrarte the two machines that are communicating with the CPU to top compressing and decompressing, and the network dying of laughter, when podrias to have finished long before deactivating the compression, leaving peacefully to the CPUs and taking advantage of to top the network ; -)
Beam backups in MiniDV, but surely...
Nevertheless on the detection and correction of errors it is necessary to remarcar important details. Unless useis tapes (and I suppose that cameras) of much quality podeis to be sure that errors that they will prevent you to only recover with the commandos dvbackup and dvconnect are produciran stream identical to which in its day you sent towards the camera. And the CRC and similar techniques of detection of errors (that already we have used in cpio , and that probably will add again later the compressors if we used them) they can be bién to know that backup is bad, but... the idea is TO RECOVER IT, with which we needed techniques correction of errors, or a good plan to commit suicide to the first error. So we will use techniques of correction of errors, concretely one of more well-known and resistant is Reed Solomon with interleaving, which she is more or less the one that is used in the CDs, for example.
This we will do it with the small tool rsbep , that concretely uses RS(255,223) with interleaving of 765 bytes (by defect; these values can change but thus usually it goes bién). This means that by each 223 bytes of entrance, the code detector and corrector of errors generate 255 bytes of exit. This adds enough redundante information that it allows to detect many errors and to correct an important part of them. The 765 mean that the bytes of a block of Reed Solomon are interlaced, distributed, dispersed, so that between two bytes of a same block there are 765 bytes. It is not question to explain it with detail here, but if pensais with calm this does stream resulting very resistant to the bursts of errors because if for example 100 followed bytes are damaged (that are commonest, than the errors come in bursts) will be affected 100 block *** TRANSLATION ENDS HERE ***s Reed Solomon pero cada uno de ellos tendrá solo un byte dañado y podrá recuperarse sin problemas. Digamos que el interleaving reduce drásticamente la probabilidad de que un bloque quede tan dañado que no se pueda recuperar, o incluso que no se pueda detectar el error. Este interleaving unido a las propiedades del código Reed Solomon hace que el stream resultante soporte sin problemas (datos originales 100% recuperables) ráfagas de hasta 12240 bytes consecutivos dañados.
Solo queda un detalle acerca del rsbep : al crear streams a partir de un código de bloques con interleaving, a veces tiene que hacer "padding" y añadir ceros al final, siempre que el tamaño de la entrada no sea múltiplo de 223 en este caso. Esto no es importante en el caso de las herramientas que utilizaremos aquí ( cpio , etc.) y en general es inofensivo a todos los efectos, pero si decidimos proteger otro tipo de información con rsbep , es algo a tener en cuenta. Bién, una vez visto todo esto y continuando con nuestro comando, si decidieramos añadir compresión con bzip2 quedaria algo así:
find/home | cpio -o -H crc | bzip2 | rsbep
Un añadido un poco soso, pero es que tanto bzip2 como rsbep toman por defecto unas opciones bastante buenas para hacer estos backups... Por cierto, todavia NO os recomiendo ejecutar el comando, porque no está terminado! Simplemente tarda más que el de antes X'-DDD
Lo prometido: backups en MiniDV;-)
Ahora solo queda el último paso: meter los datos en algo que parezca que es video digital en el formato adecuado (tarea de dvbackup ) y mandarlos a la cámara MiniDV por el FireWire (tarea de dvconnect ). El comando completo para hacer los backups (dada una máquina suficientemente rápida) seria el siguiente:
Sencillamente el --prefix=125 añade 125 frames sin datos al principio, y el -s le dice al dvconnect que va a hacer un "send". Curiosamente los autores de dvbackup/dvconnect y rsbep no coincidieron en el tema de los argumentos por defecto, ya vereis que a la hora de recuperar hay que indicarle -d al rsbep para decirle que está descodificando, y también al dvbackup , y sin embargo el dvconnect cuando está recibiendo datos de la cámara justamente es cuando no necesita argumentos:-)
Ups... me dejo unos cuantos detalles obvios que ya habreis notado: si hay que romper el comando por alguna parte para utilizar un fichero intermedio, la mejor parte es entre el rsbep y el dvbackup:
Además estos comandos ya sí que se pueden ejecutar tal cual; pero hay que tener la cámara conectada y grabar en el momento adecuado X'-DDD
Eso es muy simple. Hay que tener el FireWire conectado entre la cámara y el ordenador (normalmente con un cable de 4 a 6 pins), el dispositivo/dev/video1394 bién creado (de carácteres, major 171, minor 16: mknod/dev/video1394 c 171 16 ) y con los permisos correctos (lectura/escritura para el usuario/grupo que vaya a hacer los backups), y el módulo del kernel video1394 cargado (con modprobe video1394 ). Luego hay que poner la cámara en modo VCR, colocar la cinta (preferiblemente virgen) en el punto donde deseemos grabar el backup (tiene que haber espacio suficiente a continuación!) y finalmente empezar a grabar instantes antes de ejecutar el comando. No es recomendable hacer esto con baterias, mejor con alimentación directa de la red, porque por ejemplo para llenar una cinta de una hora tardaremos... una hora. Hablaremos de capacidades aproximadas al final.
Ejem... y la recuperación?
No me seais vagos... es lo mismo pero al revés, leyendo unos cuantos manuales se arregla. En fin... para el comando de backup del ejemplo, el "restore" seria algo así:
Por supuesto, teniendo la cámara conectada como antes, con la cinta al principio del backup que queramos restaurar, e iniciando la reproducción instantes después de ejecutar el comando. Una vez más, la mejor parte para separar el comando utilizando un fichero intermedio es entre el dvbackup y el rsbep:
Y... tachán! Se supone que funciona. Pero haced unas cuantas pruebas antes de usarlo como vuestro único medio de backup, y por supuesto mirad la ayuda de todos los programas para encontrar variantes que se adapten mejor a vuestras necesidades o gustos. En cualquier caso ni yo ni los autores de los programas ni los responsables de esta web nos hacemos cargo de ninguna de vuestras acciones, se adapten o no a las instrucciones. Esto es un truco para hacer de forma divertida algo muy serio, y es solo apto para linuxer@s valientes O:-)
Conclusiones
Para empezar, es tan fácil que casi casi da asco. De hecho no queria escribir este artículo... pero bueno, tenerlo todo junto siempre viene bién. La cuestión es que es posible hacer cópias de seguridad en cintas MiniDV, y como decia al principio: es divertido, si lo haces bién funciona, y sale barato si ya tienes la cámara.
La capacidad de las cintas es un detalle importante. Ahí va un párrafo que escribí en nuestra lista de correo, creo que lo condensa bastante bién:
En una cinta de 60 minutos caben 13GB de video en formato MiniDV en el que puedes entremezclar hasta 10GB de tus datos con la imagen fija y silenciosa de un pingüino, y en LP la capacidad de la cinta aumenta un 50% de forma que consigues meter hasta 15GB, pero también aumenta el peligro de errores así que no queda más remedio que perder alrededor de un 14% por el overhead del código corrector de errores RS(255,223) con un estupendo interleaving de 765 posiciones que permite recuperar al 100% sin error ráfagas de hasta 12240 bytes dañados. Una forma curiosa de partir de 13GB para llegar a 13GB, no? X'-DDD
Una última recomendación sobre las cintas: las que llevan el logotipo "CM4K" o "CM16K" o algo así son más caras pero también mucho más recomendables. Son la que incluyen la tecnologia denominada "Chip Memory", que no es más que una pequeña memoria integrada en la cinta (se ven los contactos metálicos junto a la lengüeta de protección contra escritura) que guarda datos como el título de la cinta, y los inicios y los títulos de las escenas. Por una parte, estas cintas suelen ser de mayor calidad. Y por otra parte, si hay varios backups en una cinta resulta MUY práctico tenerlos indexados y poder colocar la cinta al principio de cualquiera de ellos con total precisión simplemente seleccionando unas cuantas opciones del menú de la cámara (la mia tiene pantalla táctil, no es que sea relevante aquí pero me encanta decirlo ];-)
I really hope the pervert game developers who created the WAD extension take a good look in the mirror some day when they have a wife and children and ask themselves, "Why did I disgrace women everywhere by creating gross file extensions?"
Yes, I realize that on IRC or a Web blog it's funny to make synonyms for "ejaculatory fluid", but enough is enough already. Stick to coding and leave the racist trashtalking to Republicans.
No thanks, Gimp coders. I'll stick with iMovie because it Just Works(TM) plain and simple!!!
What can iMovie do, and why use it?
Send iMovies to DVDs -- instantly
Stunning Skywalker(TM) Sound Effects
Convenient chapter markers
There's also a ton more features, such as real-time original image manipulation filters that allow you to create characters and picture transitions.
For anything aside from 2048 dpi high-motion special effects, iMovie is the much better choice. It comes with every Mac computer. Can't beat that, plus you get the BSD core:-)
My band's playing at Rudie's Pub tonight and I'd love to see ya there. Reply with your phone number and let me know if you're interested in hearin' some tunes tonight, hun;-D
Film Gimp (now SinePaint) has been used in tons of major motions pictures, such as the following:
Scooby-Doo, Harry Potter, Cats & Dogs, Dr. Dolittle 2, Little Nicky, Grinch, Sixth Day, Stuart Little, Planet of the Apes, Showtime, Blue Crush, and The Fast and the Furious II.
This is really cool. I used to think it was just another Open Source project where someone creates a SourceForge website and then abandons it two months later after no code is written.
Interesting, but why does Slashdot lower the bar for weekend news items?
It's not like the story duplicates and Jon Katz writing didn't lower the bar enough already. Now you're writing about name changes to obscure Open Source projects.
Maybe it's just me, but is this really Stuff That Matters?
As an American who is going to be living overseas for a few years (Germany, to be more exact), I'm curious as to what advice/information Slashdot could provide people like me.
My advice is this: don't go.
I have a close friend who got fed up with the constant state of (declining) flux here in the American technology job market. He'd had enough and figured to jump ship (no pun intended) and head over to Germany because everyone always said how nice Europe, especially Germany, was to work and live.
Unfortunately, he soon found out that meager pay (relative to the cost of living) was very common, and bad benefits were even more common. He was pulling in barely $32,000 USD per year and was living week to week trying to get by paying bills and taking care of his wife and baby girl.
I would advise you to please consider staying home. "The grass is always greener on the other side" as the popular saying goes. In this case, it firmly holds true.
A programmer can only code for so many hours every day. It's not like turning a light on or off; programming takes time, the right moment, and deep concentration to be done right.
I love programming. It's like a cross between a fine art, such as opera, and a deeply complex science, such as molecular physics. There's a math portion of it, and there's an art portion of it. But the bottom line is that there's no business part of coding. So, when managers and the other suits try to tell the coders, "OK, well put in a good 8 hrs of coding today, and Mike and Punjab will as well, and we'll have 24 hrs of coding done today on NewGameApp v1.0." Unfortunately, it doesn't work that way.
Go read Mythical Man Month [Link]. It's all about these typical manegerial expectations and how they're blatantly wrong.
You want to fix game development? STOP WORKING THE PROGRAMMERS SO HARD.
I've found the latest crop of games to be really great. For instance, Battlefield 1942 and Metroid Prime are probably two of the best games I've _ever_ played in my life.
I think maybe the companies put too much stress on the developers to create hits, but as a part-time developer, I think it's easier said than done to just create a smash hit out of thin air. Everything's already been done, or so it seems, so really original and entertaining gameplay+graphics is a tough combination to create.
There are companies that are still using very old, antiquated operating systems and software. The reason is justifiable though -- they still work for what they need them for.
I'm sure Dell's CIO was just stating that for Dell UNIX is dead, and sure, he's probably right that Oracle+HP UX is more expensive than PostgreSQL+Linux even though they can both do the same thing. No one would argue against this.
I mean, just look at Slashdot. There are several other codebases for dynamic websites that are now incredibly more complex than Slashdot's own Slash code project. But they still use Slash code because it fits their needs mostly, and porting it over to PostNuke or Scoop would be a lot of unnecessary work.
So yeah, UNIX is dead in terms of new solutions. But somewhere, somehow, there'll always be a VAX computer, or a COBOL program, or some other very old legacy code that still works wonders, even today.
I propose a large makeover to the Articles.pl script. Firstly, each article will have a dropdown menu that every member can use to vote 1-10 on each story. The top 30% of all stories will appear on the front page.
Each article will also have an option at the very bottom called 'Duplicate' that, if checked off enough, will totally _delete_ the article from the database. We don't need to be having the same discussions to the same story 2, 3, and in some cases even 4 times. It's really getting ridiculous.
I actually tried one anti-spam tool, and it worked very well (it was on my Windows box at work), but I couldn't help but worry that maybe I would miss an email the was marked spam but really wasn't.
And, I work really hard at my job because the economy's so bad. Good for bid that spam software would delete an email from my boss just because he used a certain popular spam token in the subject header.
Because it's got the best foundation of Linux code!
I've used it for 8 years going on 9 and have no complaints. I know where everything is and don't have to root around (no pun intended;-D) for this and that file. It's always in the same spot. I feel that Red Hat and other newer players in the Linux game move things around just a bit too much.
I like Slackware. It's stable, free, and intuitive.
But it's a matter of choice. Linux is Linux, and it's all good.
It will be unified to some extent, but it will take a bit more time.
There are already unified driver support projects, and there's a huge project at http://www.linuxbase.org/ in which the goal is "to develop and promote a set of standards that will increase compatability among Linux distributions and enable software applications to run on any compliant system."
We will do it, just give us a couple more years. Windows was written over several decades, and Linux is very new still!
Slashdot Mirror
I urge you all as fellow members to avoid purchasing this book. Save your time and money, as they're both valuable things that this "amazing" new theory that promises to change the world will waste. The creators want us to believe that Aspect will make some programming utopia, but you know what? Hitler said the same thing about his "great new idea" and look where it got him.
Object-oriented is a common sense, practical way to view the world. You treat the variables in your program as objects, and you think about how a real-world object and what its private values would be and what operations you would be able to perform on it. It's a very pragmatic approach.
I've read this Aspect book, though, and it sucks. There's nothing new or innovative, as I'm sure you can see from the Hello World example. Does it look like any ordinary Java or C# code? Yup.
So please, save yourself thirty dollars and a heck of a lot of time and don't ever touch this book. Spend time improving the code you've already written rather than wasting time on theoretical gibberish that won't result in any improved programs.
What we really need is better error prevention, not some new style to program in. Get your priorities straight.
I just heard some sad news on talk radio this morning - millions of expensive tape backup devices were found murdered in a Palo Alto convalescent home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss them -- even if you didn't enjoy making backups of your backups of your backups, there's no denying tape's contributions to popular culture. Truly an American icon.
Here you go, I translated it best I could with Babel. It's also just in case their server goes down.
.
/home , that is in a single partition. In that case, a form to obtain stream of backup by the standard exit (that is what it interests us to join it with later commandos soon, although podriamos to redirigir it to a file if we wanted) is this sequence, quite classic:
:-P
/home | cpio -o -H crc | bzip2 | rsbep
;-)
/home | cpio -o -H crc | bzip2 | rsbep | dvbackup --prefix=125 | dvconnect -s
:-)
:
/home | cpio -o -H crc | bzip2 | rsbep > FICHERO.TMP
/dev/video1394 bién creado (de carácteres, major 171, minor 16: mknod /dev/video1394 c 171 16 ) y con los permisos correctos (lectura/escritura para el usuario/grupo que vaya a hacer los backups), y el módulo del kernel video1394 cargado (con modprobe video1394 ). Luego hay que poner la cámara en modo VCR, colocar la cinta (preferiblemente virgen) en el punto donde deseemos grabar el backup (tiene que haber espacio suficiente a continuación!) y finalmente empezar a grabar instantes antes de ejecutar el comando. No es recomendable hacer esto con baterias, mejor con alimentación directa de la red, porque por ejemplo para llenar una cinta de una hora tardaremos... una hora. Hablaremos de capacidades aproximadas al final.
:
---
Backups in videotapes MiniDV
By Guillem Cantallops Ramis , Beowulf ( http://bulmalug.net/beowulf/)
Created 03/03/2003 02:56 and modified for the last time 03/03/2003 02:56
Lo primero que se te ocurre cuando usas Linux o algún UNIX y sabes algo del formato MiniDV es "vaya, en esa cinta tan pequeña caben casi 13GB de datos crudos, y se graban a razón de 3.6 MB/segundo, mejor que muchas unidades de cinta para backup... estaria bién poder usar la cámara para eso!"
Y la verdad es que tiene sus problemillas, porque se trata de usar para datos generales algo que ha sido diseñado desde el principio para almacenar video, pero también tiene algunas ventajas: es divertido, si lo haces bién funciona, y sale barato si ya tienes la cámara. Veamos con qué herramientas podemos hacerlo.
Tools available
"pack" basic of tools consists of dvbackup (1) and rsbep (2) . That I know they are not in Debian (in other distributions nor idea) so there will be to lower them, to compile them and optionally to pack them by hand. They are quite small programs, with a very simple Makefile, and they are compiled in a while. I for the preliminary tests simply have put binary in my ~/bin. An important detail: for Ia-32 rsbep has the part "lasts" of the code optimized in assembler, and runs enough, but for other platforms (for example I have proven it on PowerPC) it is necessary to compile it in pure C and to work, works, but... already me entendeis... does not fly indeed.
Bién, before beginning to play with the programs, we see how they do it (although "the good" explanation is in the connections that I have happened to you ; -)
A little teoria
Basically the MiniDV uses a compression lossy , that is to say, with loss of quality, that reduces the video information to 1/5 of its "crude" size (this ratio is fixed), which usually does not affect seriously to the quality of imagenes (safe in very abrupt changes) due to the highly redundante nature of the video. This compression lossy actually seems lossless , because she is much less aggressive than any type of MPEG, to put an example: one was to arrive at a good commitment between ratio compression and quality from image, and they did bién enough.
But it is a compression clearly lossy , even without entering details on the used algorithms I I see it intuitive in terminos of of entropy: in worse of the cases (highly improbable if we captured real images) podria of arriving a sequence of virtual images impossible to compress, with a near entropy 8 bits by byte. In a case therefore the only form to reduce that information to a fifth part of its pasaria initial size to throw to the sweepings four fifth parts of that information. And as MiniDV always maintains the ratio of 1:5... is clear that it is lossy . This bién written podria to be a demonstration by absurd reduction to, but the good one, if therefore it is understood... Or; -)
He is already bién of filosofia. The question is that the video remains in "sad" () 25Mbps thanks to this compression. Without counting the audio one. And the compression somewhere uses fundamental discrete cosine transform (DCT) on blocks of 8x8 pixels. Yes, it remembers the JPEG, but now we spoke of video and in addition we worked with much quality. Each block has associate coefficients AC and DC, and standard allows to finish ("to truncate") AC with code special, so what the authors have done of dvbackup it has been simply to use the DC to paint a pretty pingüino that will visualize in all frames of the videos of backup, and to truncate coefficients AC immediately to use all the remaining space for the data of backup. As far as the audio one, one keeps without compressing in the tape. Simply dvbackup indicates in each frame that it will not be used audio, and stuffed the space reserved with more data. Brilliantly simple, and it works with many models of MiniDV cameras, including my Sony Dcr-pc101e (, by the way very recommendable because as much the video by FireWire as the photos by USB are transmitted without problems to any Linux with kernel recent... are many other models, but this he is the one that I have proven ; -)
Backups generic and restrictions of the MiniDV tapes
Like the tools that we will see next take the data from the standard entrance and somehow they end up putting them in the videotape, and what we love is to create and to recover backups of one or several systems of files, or parts of them, we will have to process the data somehow to turn them stream (a.k.a. "churro" : -) of bytes that serve to feed those programs.
Briefly, it will be necessary to use the typical ones find|cpio , or some similar thing, to select and to pack the files in one single one since all the life has become. And in principle that resulting file will be the standard exit, but there is a small problem: its 25 the MiniDV tape is recorded and frames per second (PAL) reproduces to and of you do not move it there, at least not in a normal camera. If your machine is too slow you can have problems writing in (and even reading of) the tape, which the programs that we will use more ahead call underrun or overrun according to the case.
If you are not able to feed sufficiently fast the tape when you are recording, in principle the program is able to introduce frames special without information to signalize underrun, and the only thing that happens a priori is that you waste space in the tape... but if it happens quite often (and surely it will happen, if your machine does not arrive is that it does not arrive and point) you can lose too much space for your pleasure.
If however you are not able to process in "real time" what it arrives to you from the tape, you lose relatively great parts of information (overrun) and can quedarte without recovering backup, which is obvious bad.
In fact if your hard disk is too slow and/or is too full there is nothing no to do. But it is that also the CPU, as iBook is the case of my, with a PowerPC G3 500MHz and a hard disk UDMA33 can limit you. We will see more ahead than often he is advisable to use compression (gzip or bzip2), and mainly detection and correction of errors (with rsbep, the other strong plate of the article). All that, together with the previous work of find|cpio (to cross the system of files and to copy things are not "free") and to the later work of the packing of the data in frames of video and the transmission by the FireWire, it can too much be for many machines. All can do it, but the problem is to do producing it an exit of 3.6MB/s maintained
For that reason often he is recommendable to use a file like intermediate storage. At least I with that technique was able to save the limitations of power of my iBook. The idea is "to divide" pipes that we will see more ahead by the part that connects dvbackup|dvconnect yet the others. Thus the critical part of read/write of the tape is made desde/hacia directly a sequential file, without hardly additional calculation. Clear that the best thing is to have a great machine and to leave itself of tonterias ; -)
We began to form the commandos...
In order to see examples of use of find|cpio , simple examples because these programs are not the subject of the article, we will suppose that we want to do backup of all ours
find/home | cpio - or - H crc
The part of find list by its standard exit the files that we want to keep, and the part of cpio it takes this list by his standard entrance, a code packs the files adding detector of errors CRC, and removes the result by its standard exit. So it is not happened to you to execute it so as because it will show backup to you by the terminal, thing that can be interesting at some moments to enter critical moment or something thus, but not now. In addition teneis will take much and that to finish reading this article
The following thing that deberiamos to add is: compression, of optional form; and detection and correction of errors, forced form. On the compression, nothing that to say: everyone will know when it needs it, and as it is a relatively slow process often the best thing is not to use it if there is sufficient space in the tape. It is almost just like when you transmit data by network, mainly if the network is a fast LAN: if you use compression you can encontrarte the two machines that are communicating with the CPU to top compressing and decompressing, and the network dying of laughter, when podrias to have finished long before deactivating the compression, leaving peacefully to the CPUs and taking advantage of to top the network ; -)
Beam backups in MiniDV, but surely...
Nevertheless on the detection and correction of errors it is necessary to remarcar important details. Unless useis tapes (and I suppose that cameras) of much quality podeis to be sure that errors that they will prevent you to only recover with the commandos dvbackup and dvconnect are produciran stream identical to which in its day you sent towards the camera. And the CRC and similar techniques of detection of errors (that already we have used in cpio , and that probably will add again later the compressors if we used them) they can be bién to know that backup is bad, but... the idea is TO RECOVER IT, with which we needed techniques correction of errors, or a good plan to commit suicide to the first error. So we will use techniques of correction of errors, concretely one of more well-known and resistant is Reed Solomon with interleaving, which she is more or less the one that is used in the CDs, for example.
This we will do it with the small tool rsbep , that concretely uses RS(255,223) with interleaving of 765 bytes (by defect; these values can change but thus usually it goes bién). This means that by each 223 bytes of entrance, the code detector and corrector of errors generate 255 bytes of exit. This adds enough redundante information that it allows to detect many errors and to correct an important part of them. The 765 mean that the bytes of a block of Reed Solomon are interlaced, distributed, dispersed, so that between two bytes of a same block there are 765 bytes. It is not question to explain it with detail here, but if pensais with calm this does stream resulting very resistant to the bursts of errors because if for example 100 followed bytes are damaged (that are commonest, than the errors come in bursts) will be affected 100 block *** TRANSLATION ENDS HERE ***s Reed Solomon pero cada uno de ellos tendrá solo un byte dañado y podrá recuperarse sin problemas. Digamos que el interleaving reduce drásticamente la probabilidad de que un bloque quede tan dañado que no se pueda recuperar, o incluso que no se pueda detectar el error. Este interleaving unido a las propiedades del código Reed Solomon hace que el stream resultante soporte sin problemas (datos originales 100% recuperables) ráfagas de hasta 12240 bytes consecutivos dañados.
Solo queda un detalle acerca del rsbep : al crear streams a partir de un código de bloques con interleaving, a veces tiene que hacer "padding" y añadir ceros al final, siempre que el tamaño de la entrada no sea múltiplo de 223 en este caso. Esto no es importante en el caso de las herramientas que utilizaremos aquí ( cpio , etc.) y en general es inofensivo a todos los efectos, pero si decidimos proteger otro tipo de información con rsbep , es algo a tener en cuenta. Bién, una vez visto todo esto y continuando con nuestro comando, si decidieramos añadir compresión con bzip2 quedaria algo así:
find
Un añadido un poco soso, pero es que tanto bzip2 como rsbep toman por defecto unas opciones bastante buenas para hacer estos backups... Por cierto, todavia NO os recomiendo ejecutar el comando, porque no está terminado! Simplemente tarda más que el de antes X'-DDD
Lo prometido: backups en MiniDV
Ahora solo queda el último paso: meter los datos en algo que parezca que es video digital en el formato adecuado (tarea de dvbackup ) y mandarlos a la cámara MiniDV por el FireWire (tarea de dvconnect ). El comando completo para hacer los backups (dada una máquina suficientemente rápida) seria el siguiente:
find
Sencillamente el --prefix=125 añade 125 frames sin datos al principio, y el -s le dice al dvconnect que va a hacer un "send". Curiosamente los autores de dvbackup/dvconnect y rsbep no coincidieron en el tema de los argumentos por defecto, ya vereis que a la hora de recuperar hay que indicarle -d al rsbep para decirle que está descodificando, y también al dvbackup , y sin embargo el dvconnect cuando está recibiendo datos de la cámara justamente es cuando no necesita argumentos
Ups... me dejo unos cuantos detalles obvios que ya habreis notado: si hay que romper el comando por alguna parte para utilizar un fichero intermedio, la mejor parte es entre el rsbep y el dvbackup
find
cat FICHERO.TMP | dvbackup --prefix=125 | dvconnect -s
Además estos comandos ya sí que se pueden ejecutar tal cual; pero hay que tener la cámara conectada y grabar en el momento adecuado X'-DDD
Eso es muy simple. Hay que tener el FireWire conectado entre la cámara y el ordenador (normalmente con un cable de 4 a 6 pins), el dispositivo
Ejem... y la recuperación?
No me seais vagos... es lo mismo pero al revés, leyendo unos cuantos manuales se arregla. En fin... para el comando de backup del ejemplo, el "restore" seria algo así:
dvconnect | dvbackup -d | rsbep -d | bunzip2 | cpio -imV
Por supuesto, teniendo la cámara conectada como antes, con la cinta al principio del backup que queramos restaurar, e iniciando la reproducción instantes después de ejecutar el comando. Una vez más, la mejor parte para separar el comando utilizando un fichero intermedio es entre el dvbackup y el rsbep
dvconnect | dvbackup -d > FICHERO.TMP
cat FICHERO.TMP | rsbep -d | bunzip2 | cpio -imV
Y... tachán! Se supone que funciona. Pero haced unas cuantas pruebas antes de usarlo como vuestro único medio de backup, y por supuesto mirad la ayuda de todos los programas para encontrar variantes que se adapten mejor a vuestras necesidades o gustos. En cualquier caso ni yo ni los autores de los programas ni los responsables de esta web nos hacemos cargo de ninguna de vuestras acciones, se adapten o no a las instrucciones. Esto es un truco para hacer de forma divertida algo muy serio, y es solo apto para linuxer@s valientes O:-)
Conclusiones
Para empezar, es tan fácil que casi casi da asco. De hecho no queria escribir este artículo... pero bueno, tenerlo todo junto siempre viene bién. La cuestión es que es posible hacer cópias de seguridad en cintas MiniDV, y como decia al principio: es divertido, si lo haces bién funciona, y sale barato si ya tienes la cámara.
La capacidad de las cintas es un detalle importante. Ahí va un párrafo que escribí en nuestra lista de correo, creo que lo condensa bastante bién:
En una cinta de 60 minutos caben 13GB de video en formato MiniDV en el que
puedes entremezclar hasta 10GB de tus datos con la imagen fija y silenciosa de
un pingüino, y en LP la capacidad de la cinta aumenta un 50% de forma que
consigues meter hasta 15GB, pero también aumenta el peligro de errores así que
no queda más remedio que perder alrededor de un 14% por el overhead del código
corrector de errores RS(255,223) con un estupendo interleaving de 765 posiciones
que permite recuperar al 100% sin error ráfagas de hasta 12240 bytes dañados.
Una forma curiosa de partir de 13GB para llegar a 13GB, no? X'-DDD
Una última recomendación sobre las cintas: las que llevan el logotipo "CM4K" o "CM16K" o algo así son más caras pero también mucho más recomendables. Son la que incluyen la tecnologia denominada "Chip Memory", que no es más que una pequeña memoria integrada en la cinta (se ven los contactos metálicos junto a la lengüeta de protección contra escritura) que guarda datos como el título de la cinta, y los inicios y los títulos de las escenas. Por una parte, estas cintas suelen ser de mayor calidad. Y por otra parte, si hay varios backups en una cinta resulta MUY práctico tenerlos indexados y poder colocar la cinta al principio de cualquiera de ellos con total precisión simplemente seleccionando unas cuantas opciones del menú de la cámara (la mia tiene pantalla táctil, no es que sea relevante aquí pero me encanta decirlo ];-)
This is what we needed. Too many of us have had to struggle with archaic tape backup systems.
Thankfully we can finally enter the digital age of data backup and recovery!
I really hope the pervert game developers who created the WAD extension take a good look in the mirror some day when they have a wife and children and ask themselves, "Why did I disgrace women everywhere by creating gross file extensions?"
Yes, I realize that on IRC or a Web blog it's funny to make synonyms for "ejaculatory fluid", but enough is enough already. Stick to coding and leave the racist trashtalking to Republicans.
Or, we could just benchmark the best application for the hardware, like Apple does ;-)
Trust me boys, your stuff looks a lot better when you design chips for only one program!
What can iMovie do, and why use it?
- Send iMovies to DVDs -- instantly
- Stunning Skywalker(TM) Sound Effects
- Convenient chapter markers
There's also a ton more features, such as real-time original image manipulation filters that allow you to create characters and picture transitions.For anything aside from 2048 dpi high-motion special effects, iMovie is the much better choice. It comes with every Mac computer. Can't beat that, plus you get the BSD core
Hey babe,
;-D
My band's playing at Rudie's Pub tonight and I'd love to see ya there. Reply with your phone number and let me know if you're interested in hearin' some tunes tonight, hun
Luv,
Gwen
XOXOXO
Scooby-Doo, Harry Potter, Cats & Dogs, Dr. Dolittle 2, Little Nicky, Grinch, Sixth Day, Stuart Little, Planet of the Apes, Showtime, Blue Crush, and The Fast and the Furious II.
This is really cool. I used to think it was just another Open Source project where someone creates a SourceForge website and then abandons it two months later after no code is written.
Interesting, but why does Slashdot lower the bar for weekend news items?
It's not like the story duplicates and Jon Katz writing didn't lower the bar enough already. Now you're writing about name changes to obscure Open Source projects.
Maybe it's just me, but is this really Stuff That Matters?
As an American who is going to be living overseas for a few years (Germany, to be more exact), I'm curious as to what advice/information Slashdot could provide people like me.
My advice is this: don't go.
I have a close friend who got fed up with the constant state of (declining) flux here in the American technology job market. He'd had enough and figured to jump ship (no pun intended) and head over to Germany because everyone always said how nice Europe, especially Germany, was to work and live.
Unfortunately, he soon found out that meager pay (relative to the cost of living) was very common, and bad benefits were even more common. He was pulling in barely $32,000 USD per year and was living week to week trying to get by paying bills and taking care of his wife and baby girl.
I would advise you to please consider staying home. "The grass is always greener on the other side" as the popular saying goes. In this case, it firmly holds true.
A programmer can only code for so many hours every day. It's not like turning a light on or off; programming takes time, the right moment, and deep concentration to be done right.
I love programming. It's like a cross between a fine art, such as opera, and a deeply complex science, such as molecular physics. There's a math portion of it, and there's an art portion of it. But the bottom line is that there's no business part of coding. So, when managers and the other suits try to tell the coders, "OK, well put in a good 8 hrs of coding today, and Mike and Punjab will as well, and we'll have 24 hrs of coding done today on NewGameApp v1.0." Unfortunately, it doesn't work that way.
Go read Mythical Man Month [Link]. It's all about these typical manegerial expectations and how they're blatantly wrong.
You want to fix game development? STOP WORKING THE PROGRAMMERS SO HARD.
I've found the latest crop of games to be really great. For instance, Battlefield 1942 and Metroid Prime are probably two of the best games I've _ever_ played in my life.
I think maybe the companies put too much stress on the developers to create hits, but as a part-time developer, I think it's easier said than done to just create a smash hit out of thin air. Everything's already been done, or so it seems, so really original and entertaining gameplay+graphics is a tough combination to create.
Don't listen to the parent poster's advice please because he's dead wrong.
You can easily teach XHTML without setting any course prerequisites such as HTML knowledge.
XHTML is very intuitive and it's the cutting edge, really, these days. So go for it, I say.
Get a couple good books as references, though; they'll serve as good workbooks from which you can glean sample problems and code for the students.
Happy XHTML'ling!
There are companies that are still using very old, antiquated operating systems and software. The reason is justifiable though -- they still work for what they need them for.
I'm sure Dell's CIO was just stating that for Dell UNIX is dead, and sure, he's probably right that Oracle+HP UX is more expensive than PostgreSQL+Linux even though they can both do the same thing. No one would argue against this.
I mean, just look at Slashdot. There are several other codebases for dynamic websites that are now incredibly more complex than Slashdot's own Slash code project. But they still use Slash code because it fits their needs mostly, and porting it over to PostNuke or Scoop would be a lot of unnecessary work.
So yeah, UNIX is dead in terms of new solutions. But somewhere, somehow, there'll always be a VAX computer, or a COBOL program, or some other very old legacy code that still works wonders, even today.
That's not even the best part, though.
;-)
You'll get paid to troll. Now that's just fscking cool
I know you're joking, but you're right!
I propose a large makeover to the Articles.pl script. Firstly, each article will have a dropdown menu that every member can use to vote 1-10 on each story. The top 30% of all stories will appear on the front page.
Each article will also have an option at the very bottom called 'Duplicate' that, if checked off enough, will totally _delete_ the article from the database. We don't need to be having the same discussions to the same story 2, 3, and in some cases even 4 times. It's really getting ridiculous.
I actually tried one anti-spam tool, and it worked very well (it was on my Windows box at work), but I couldn't help but worry that maybe I would miss an email the was marked spam but really wasn't.
And, I work really hard at my job because the economy's so bad. Good for bid that spam software would delete an email from my boss just because he used a certain popular spam token in the subject header.
Because it's got the best foundation of Linux code!
;-D) for this and that file. It's always in the same spot. I feel that Red Hat and other newer players in the Linux game move things around just a bit too much.
I've used it for 8 years going on 9 and have no complaints. I know where everything is and don't have to root around (no pun intended
I like Slackware. It's stable, free, and intuitive.
But it's a matter of choice. Linux is Linux, and it's all good.
It will be unified to some extent, but it will take a bit more time.
There are already unified driver support projects, and there's a huge project at http://www.linuxbase.org/ in which the goal is "to develop and promote a set of standards that will increase compatability among Linux distributions and enable software applications to run on any compliant system."
We will do it, just give us a couple more years. Windows was written over several decades, and Linux is very new still!
Enjoy!!!
http://mirrors.sunsite.dk/collegelinux/
Most exploits that existed over 5 yrs ago are still valid.
For instance, you can recover a root password in just 10-15 minutes on ANY machine.
But sometimes you have to sacrifice quality for price.