|
||||||||||||||||||||||||||||||
show i'm going to show you how to use Per Lidèn's pkgutils on systems other than CRUX. if you don't already know pkgutils is a port system that was developed for CRUX Linux. it works like the FreeeBSD ports systems (openbsd, netbsd, gentoo, etc.) ports are stored in /usr/ports/catergory_name/port_name/. when you type 'pkgmk -d -i' in that directory it will download, configure, compile, make a binary package, and install the package on your system. you can read the man pages for more info. first of all, to install it your going to want to download it, extract it, configure it with --prefix=/usr, compile and install it. then you're going to want to do some minor adjustments to set it up:
to do anything usefule you're going to need some ports. i'd prefer to eventually have an entire different ports repository for Slothware but that's going to take some time. right now i have a few ports up alread. you can find them here. if you want to use the crux ports you can get the "ports" program by downloading it and putting it in a directory and doing 'pkgmk' like this:
there you go, now it'll be installed with both cvsup and httpup as backends. then you're going to want to check out /etc/ports and look at the cvsup files and adjust them to your liking. there's a lot of repositories that you can check out at the CRUX Linux Communities' Port Database. if you click on a repository you can see the link at the top of the page saying, for example, "Download httpup: opt.httpup." put this file in /etc/ports and you should be good. after you download all of the cvsup and httpup files you want then you're going to sync your local ports repository (/usr/ports) with theirs.
there! now you should have plenty of ports that you can use pkgmk to install. i wrote this by hand, including the code, so correct me (mailto: guerrilla_thought at gmx dot de) if i'm wrong .
okay i just figured out something so awesome. i wanted to estimate the size that a bzip2 or gzip file would take up if i extracted it since it would be several times larger than the tar.bzip2 file.
okay so i did my first talk at a local hacker/geek meeting. it was kind of bouncing around a wole lot.. origionally it was supposed to be about the ELF file format, but i ended up starting out stalking about the SPARC processor and it's amount of registers and it's awesome register based stack.. i plan to implement my own stack base don powerpc registers.. it would be nice to use a g5 because it has a lot more register s(and they are bigger) than the g3, but i plan on trying to do my best on the g3.. it will use a fixed size for the stack frame to store a return address, a couple of function arguments, etc.. depending on what i deem a reasonable size for it..so anyway.. since i was talking about SPARC and assembly i went into some more detail about assembly and did some comparison of the registers and some other features of the P4, g5 and my beloved g3. anyway.. i finally got to some info about the ELF file format, not as much i wanted. i dont think it was interesting, but i did cover the compilation process.. preprocessing, assembling, compiling and linking and then i covered the linking (static, dynatmic , relocatable,etc) i explained why you get garbage on your screen when you cat a binary (ascii, bits, etc) i did a brief overview of the sections in the ELF file format, but basically i didn't see people as interested.. i talked a lot about the kernel.. about the scheduler( best candidate, hardware interupts, etc) then i talked about the swap daemon a lot more indepth because it relates a lot to dynamically linked executables.. ( dirty pages, page faults, file system buffers, file system cache, etc, swapping, and so on and so fourth.. i aslo talked some more about static libraries and static executables, overview of how 'ar' works, i talked about addreses, symbols, offsets into objects, etc, etc... i also talked a bit about the process image in memory, but not as much as i could have, because i am saving it for my next presentation. i also talked a fair amoutn about buffer overflows, shell code and stuff since i was already talking about assembly and process images and stuff.. i unfortunately didn't get to the interesting stuff in /proc, but i will get to this later since it's more related to process images than stuff in the objects on disk. i did not talk very much about the filesystem because i deemed it quite off topic and a more comlicated topic than i felt everyone was interested in listening to the gory details an hour into my presentation.. i talked pretty fast to about 4 people who were actually listening, who i felt understood and took something useful from it and a couple of other guys who weren't as interested.. hopefully next time i will have a much larger turnout, it was very disapointing because we had a lot of people confirm, but barely anybody showed up.. sad. oh well, it was quite fun and i got some practice in front of a smaller audicne anyway. i think the most practical thinsg i talked about would be buffers/cache, LD_LIBRARY_PATH and ld.so.conf and why you get garbage on your console, otherwise a whole lot of it was just specification quoting, and a whole lot of theory and explintation on how things work..i suppose the the assembly info was interesting to someone. so i will shut the hell up and let you know that you can DOWNLOAD ALL MY PRESENTATION MATERIAL INCLUDING ALL OF MY NOTES AND CODE AND BINARIES AS WELL there are plenty of links related to all of these subjects, including the "programming from the ground up" book on assembly by gnu, links to ELF specs, and other stuff like the title and author of "THe Design Of the Unix OPerating System" other junk will be updated later... there are links in my notes too..
as usual, i'm posting things in the middle of the night.... i just wrote a little script that will dowload, unpack, configure, compile and install a standard source package for you. a notable feature is that when it goes to install the package it will ask you for your root password so that you don't have to be root while downloading and compiling the package. although it doesn't have a name yet, you can get it here remember, it's for standard unix source packages, meaning 'configure' script and a 'Makefile' with an 'all' and a 'install' target. if you don't know what that means, just try the package on the url you want anyway. to use it just make the script executable and then run it with the URL of a source package and watch it do it's magic (hopefully)
okay so i made a patch to wget so that it ignores robots.txt. i'm not sure it works 100% of the time.. but you can get it here. let me know how it works out.
i also wanted to point out the -U or --user-agent="" option.. i found this while we were having a problem using wget to download files from faqs .org.. so, for example, we would try:
on the other hand, when you try the user-agent trick, it works:
ok, i'm cool now. i just wrote my first program to use a function from a shared object (all those little files in /lib). let me try and explain a little: test.c is compiled as a library(test.o) with the function second() which just prints "this is the second function". main.c is compiled as a dynamically linked executable (main) and brings the binary executable code into it's process from the library and executes it. (i.e. it calls second() as if it were it's own function)
you can download the source code source code here but remember to set LD_LIBRARY_PATH="." in your environment and you can learn more about dlopen, dlsym, dlerror and dlclose from their man page. and if you want to learn more about ELF executables and shared objects and more, please go to this site and excuse it's URL.
|
||||||||||||||||||||||||||||||
|