Different require proof of concept, abusing eval for the sake of clearer definitions




// Sample module libraries (would probably be in their own files)
someModules = { 
	testModule: {test: function(){console.log("test from someModule")}},
	anotherModule: { doStuff: function(){console.log("Doin stuffs!");}}
};

sampleRequire = function() {
	
	// Load the modules
	for (var i=arguments.length-2; i>=0; --i){

		// Create a local variable reference to the module
		eval ('var '+arguments[i]+' = someModules.'+arguments[i].toString());
	}

	// Redefine the programmer's function so that it has my local vars in its scope
	eval("var fn = "+arguments[arguments.length-1]);

	return fn;
}

// Main code...
sampleRequire( 'testModule', 'anotherModule',
 	function(){ 
		testModule.test();
		anotherModule.doStuff();
	}
)();
Advertisements
Posted in Uncategorized | Tagged | Leave a comment

Truthfulness of empty arrays in Javascript… that’s not cool!


An empty array when cast to Boolean evaluates true, indicating that it is truthy.

Boolean([])
true

An empty array compared to true evaluates false, indicating that it is not truthy.

[] == true
false
[] == false
true

And yet the Boolean opposite of an empty array still evaluates false, implying that the empty array is truthy.  What’s an interpreter to do?

![]
false
!![]
true

Just some more contradictory anecdotal evidence to help drive you mad.

Boolean([]) == []
false
Boolean([]) == ![]
false
Boolean([]) == !![]
true
!Boolean([]) == []
true

Conclusion?  I’ll just bit my tongue this time.

Posted in Uncategorized | Leave a comment

Dynamic Linking of Shared Libraries in Go


Dynamic linking has taken a lot of flack from the go team, and they present some pretty irrefutable points, and yet I still feel like this is a necessary solution in some cases. Perhaps dynamic linking as we’ve all come to know it isn’t the correct answer, but a newer similar solution would be.

My proposal would be to design a style of dynamic linking that is based explicitly on function’s signatures rather than just symbols, just as is in static linking. If a black box is implemented to guaranty a certain output based on a given input, then it should be fair to hold whomever implements a library responsible for incompatible version changes. I would also like to see programmers take more care in ensuring the same library could be equally easily linked statically as dynamically–but that’s a different topic.

Justifications

Security: Take go’s fastcgi package for example. If you’re running a standalone instance using the fastcgi library, and a vulnerability comes out in that library, you will be required to upgrade every single package that utilizes it. To programmers who crave a world rid of shared libraries, that might not be a big deal, but imagine this from an intermediate sys admin’s perspective. Depending on your operating system’s distribution, you will have to either download new binaries for every one of these softwares, or else you will have to maintain sources for every single package you run in production, and remember to recompile all of them whenever this library is updated. I agree that in a lot of cases Dynamic linking is overkill and doesn’t save enough in disk space or can potentially use more memory and longer exec times, but this is one case where I’d rather see the library maintained separately from the solution.

Modular Applications: How would you go about writing something like the Apache Web Server, or the Pidgin Internet Messenger? Both of these applications have a daunting supply of official and user-contributed plug-ins made both efficient and possible by dynamic linking. The best alternative I can think of would be to rely heavily on some IPC techniques, which seems less efficient… but what do I know.

The Runtime:  I think this should be optional at compilation.  For example, Debian does a wonderful job maintaining consistent dependencies on glibc without breaking things, so why should that privilege be revoked?  Why would we want tons of 1 to 3 MB binaries for trivial operating system tools (echo, cat)?  On the other hand, statically linking the run-time (which I don’t see an obvious means to do in c++), does serve a great advantage for binary portability.  This provides a fantastic edge for proprietary manufacturers.

Memory

In my brief and naive research, I got the impression that one of the downfalls of dynamic linking is that the entire library is loaded into memory, whereas otherwise only the required components are.  And in the same article, it notes that shared libraries loaded by many applications can be loaded into memory just once.  While this of course still implies that the entire library is loaded into memory, this could still save some memory over time.  However, I wonder if this is only made possible by the fact that glibc is always loaded dynamically, and therefore it is able to coordinate that particular sharing of memory–or perhaps I’ve misinterpreted something altogether.

On the other hand, how necessary is it that we save that megabyte of RAM (or even disk space) this day in age?  This topic is a growing internal conflict of mine, but I still believe that making software as resource-efficient as possible should be a much higher priority than it is.  Any serious implementation should consider the possibility of running on small, low-power, low-memory embedded devices.  While flash memory is so inexpensive, there’s still a pretty active scene for modifying consumer wireless routers which lacks that resource.

All in all, I already see Go as a fantastic opportunity for developers who want to be able to write powerful and flexible applications on a smaller and more efficient development and run-time stacks.

 

Related reading:

taking a Go at plugin architecture

Posted in Programming | Leave a comment

TFTP GET transfer failing for some clients


This never dawned on me, but I spent too much time today figuring out why certain machines were unable to get files from a certain TFTP server. It turns out the “Certain TFTP Server” was not at all the issue. The tftp client (at least the one I’m using) opens up UDP port 34362 and waits for the server to drop data to it.

This of course means that you need to allow that traffic through the firewall.

Posted in Uncategorized | Leave a comment

Preseeding debian with software RAID (The kernel was unable to re-read the partition table … Invalid argument)


This is a problem I’ve been occasionally going back to for a couple months now. The problem is that I’m using preseed.cfg to perform a fully unattended debian installation via netboot and I keep hitting my head on this one obnoxious warning message “The kernel was unable to re-read the partition table on /dev/md2 (Invalid argument)”… which turns out doesn’t even matter. If you just hit “Ok” the installation goes through and succeeds just fine.

Today I spent hours researching preseed answers and all the processes and scripts involved in rendering these dialogs back to the user looking for any desperate means to abolish this message, when I got this other desperate idea…. cat /dev/mem > /mnt/mem . Yeah that’s right. I am going to personally read my RAM.

A quick search using less brought me to this section of the file:

@GO
T high partman/exception_handler_note
IPTION The kernel was unable to re-read the partition table on /dev/md2 (Invalid argument).  This means Linux won't know anything about the modifications you made until you reboot.  You should reboot your computer before doing anything w
ith /dev/md2.

And of course what stands out is high partman/exception_handler_note

A quick google search for “partman/exception_handler_note preseed.cfg” turns out a handful of samples where the line d-i partman/exception_handler_note note shows up in other folks’ configs. Why it was so difficult to track down this particular question for preseed is beyond me, but I suppose I’m just glad I didn’t give up on my roundabout detective work.

So the partition region of my preseed file looks like this:

d-i partman-auto/method string regular
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-md/confirm boolean true

d-i partman-auto/disk string /dev/sdb
d-i partman-auto/method string raid

d-i partman-auto/expert_recipe string                   \
      multiraid ::                                      \
              500 1000000001 1000000000 raid                    \
                      $primary{ } method{ raid }                       \
              .                                         \
              512 513 512 raid                          \
                      $primary{ } method{ raid }        \
              .                                         \
              512 513 512 raid                          \
                      $primary{ } method{ raid }        \
              .

d-i partman-auto-raid/recipe string             \
    1 1 0 ext3 /                                \
          /dev/sdb1                             \
    .                                           \
    1 1 0 ext3 /mnt/utility                     \
          /dev/sdb2                             \
    .                                           \
    1 1 0 swap -                                \
          /dev/sdb3                             \
    .

d-i partman/exception_handler_note note
d-i partman-md/confirm boolean true
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true

Beware…
Now of course I need to toss up some sort of disclaimer. The question “partman/exception_handler_note” is not very specific of course, and implies that this could be used for other unforeseeable problems. I’m comfortable using this because I’m in a controlled environment where I’m using the same distribution, installer version and same hardware across the board, but of course if you do this, you’re doing it at your own risk. I just have to say I’m so glad this is over.

Posted in Admin, Computer | Leave a comment

Dealing with SYSLINUX


Syslinux is simple and works great, but I wasted a lot of time today with a setup that refused to boot. Apparently if you install syslinux on a bootable partition, that just isn’t enough for the PC to boot.

By any means necessary find the mbr.bin file that came with your version of syslinux and cat it to the disk device (not the partition of course). For me “any means” meant a simple apt-get source syslinux. install-mbr simply did not work despite what debian’s guide said.

Most of what I know was given to me by rolling a custom debian installer. Of course I read all the way through their guide except the very bottom where there was a user contributed note expressing what I just explained. But I wanted to drop that note here just for the sake of polluting the Internet.

Here’s an example of what I’m working with for this project.

Files:

development:~/usb-disk# find .
.
./mbr.bin
./mkinstalldisk.sh
./boot-contents
./boot-contents/boot.txt
./boot-contents/initrd.gz
./boot-contents/vmlinuz
./boot-contents/initrd-autodisk.gz
./boot-contents/syslinux.cfg

And the script “mkinstalldisk.sh” … note that this is very crude…

#!/bin/bash
if whiptail --yesno "This is a dangerous tool... do you want to quit?" 8 40
then
    exit 1
fi

if whiptail --yesno "Are you SURE you want to wipe all data on disk $1 ???" 8 40
then

    # Destroy whatever's going on with this disk
    dd if=/dev/zero of=$1 bs=512 count=1

    # Add a FAT32 partition for the size of the disk
    echo -e "n\np\n1\n\n\nt\nc\na\n1\nw" | fdisk $1

    # Format....
    mkdosfs $11

    # Install SYSLINUX on this bootable partition
    syslinux $11

    # Install a valid MBR on the disk itself
    cat mbr.bin  > /dev/sdb


    # Add the boot environment

    mntdir=/mnt/target-`date +%s`/
    mkdir $mntdir
    mount $11 $mntdir
    cp `dirname $0`/boot-contents/* $mntdir
    umount $mntdir
    rmdir $mntdir

fi

Posted in Uncategorized | 1 Comment

Modify & Rebuild an initrd Image


Let’s assume your image is located at  ./boot-contents/initrd.gz

# Get into an empty directory
mkdir initrd-files
cd initrd-files
# Unpack the image
zcat ../boot-contents/ | cpio -id

Now make whichever changes you need.

# Rebuild the image
find . | cpio --create --format='newc' | gzip  > ../boot-contents/initrd.gz

Posted in Uncategorized | Leave a comment