Recent blog entries for star

18 Oct 2001 (updated 19 Oct 2001 at 01:33 UTC) »

Todays useless script, is because I found I was doing this by hand. I keep seeing these long URL requests full of Ns in my apache log. And the 404's looking for foolish .exe's. So I have a new script at my scripts page. This is msg-infected-server.expect. You just pass it a server as the argument and it attempts to email it this message to that server.

Hello, your server appears to be infected with some kind of a worm, code red or NIMBDA, it attacked my server.

Please update your server. http://windowsupdate.microsoft.com most of these worms fixes have been available for more than six months.

I have not included my email address as I do not like recieved infected attachments. Thanks!

from a concerned Internet user.

note this entry was modified to have the expect version rather than the netcat version since nc would feed data faster than the server could react so it wouldn't accept the connection.

12 Oct 2001 »

So I am still facinated that nearly a hundread hits per month on my web server are for my static route script. It has one seriouos flaw that it contains and embedded tab, so you cannot copy and paste it and expect to use it. The embedded tab is just so it can accept either tab or space in the config file. NOONE has ever written me about this script, to say it sucks or they liked it, or I did it all wrong. What are all these people doing?

Attempt to codify last nights supper.

Three Mushroom Chicken

2 chicken breasts
4 tablespoons butter
1 onion
4 cloves garlic
2 teaspoons poultry seasoning
2 teaspoons black pepper
1 dash of salt
6 shitake mushrooms
9 button mushrooms
2 portobello mushrooms
2 cups chardonay (preferbly fruity)

Dice the onion, place in a pan with the butter. Then chop the shitake and button mushrooms. Mince the garlic and add the garlics, and shitake and button mushrooms to the onions, and stir. Add the chicken breasts, sprinkle half the poultry seasoning and half the black pepper on the two chicken breasts, also lightly salt. Place the portobello mushrooms on top of the chicken breasts. Add half a cup of wine, cover (this dish will be cooked near high for the entire time it is cooking). After the wine has evaporated, flip the chicken over, season the other side with the rest of the poultry seasoning, black pepper, and a little salt and replace the portobellos on top. Add another 1/2 cup of wine and cook covered. Flip the chicken and add more wine at least 4 more times (you may add less than 1/2 a cup from now on). Once the Chicken is cooked through, uncover and do not add wine, but flip rappidly for a few minutes untill it has a brown edge.

server with the portobello on top, and the onion, mushroom saute covering the chicken. also serve with the asparagus tomato salad, and sliced potatos.

asparagus tomato salad

1 bunch aspargus
2 cloves garlic
2 tomatos
lettuce leaf
salt
black pepper
balsamic vinegar

Tear off and was 1 large lettuce leave per serving. Place on the plate. Slice the tomato in lateral rounds, place 4-6 rounds on the lettuce covering it. Add vinegar, salt, and pepper to the tomatos. Steam the aspargus with garlic for less than 5 minutes (remember when steaming the steamer must be steaming before you add the food) so that the aspargus is bright green and should remain slightly crunchy. Place the aspargus on the tomatos, dash a little more salt and pepper on aspargus.

steamed purple potatos

2 purple potatos
2 cloves garlic
1/2 cup button mushrooms (whole)
salt
pepper

Prepare steamer. Slice potatos laterally into 3mm slices. Add potatos, garlic, and mushrooms into the steamer. Steam for over 15 minutes, untill potatos are soft. Serve, and salt and pepper to taste.

11 Oct 2001 »

Well I figured I would post something. For those people who have ever been by my desk, which is not most of you, I have crazy colours everywhere that give people headaches.

Now I have made it easy so you can do this yourself! And now it doesn't require getting any crazy code to compile that didn't ship with your favourite OS. You too can use xterm-setter and get the crazy colours you need. Sorry it only works for xterms, not gnome-terminal, kterm, zvt, MacOS term or any other crazy or much improved terminal. If you want to read more about it you can go here but it wont' really help.

Have fun, and bond to the colours!!!

11 Jun 2000 »

Ok it took me long enough to get this here, but I did add some more information about what you need to get nautilus compiled to the HACKING file. I know it is a lot of stuff to get out of CVS, but within two months it will be much less and will be fairly simple. I have started the project to minimize the number packages that need to come that way, but it will take some time, as I have other things to worry about. I also will need to coordinate a release of some modules as there are some bug fixes that nautilus needs from packages like ORBit.

Build Stuff

OK, todays topic on build stuff is what to do about packages!

One interesting problem with open source development is you may have to switch back and forth between three different ways of recieving code fairly frequently. The three majore forms are.

CVS
Release Tar Balls
System Package

Now what I want is to create sensible meta data for modules. We can call them module objects, that have all the properties you will need when refering to a module. Most likely the functions you will want are build(), get_code(), clean(), install(), remove_code(), update_code(), clean(), get_state(), configure().

So the properties of a module object would be.

Name

Simply a way to reference the module.

Version

A number to reference what release this

Type

the name in the repository

:pserver:rslomkow@cvs.gnome.org:/cvs/gnome

basename of tarball

ftp://ftp.gnome.org/pub/foo/bar/mod-version.tgz

system package name

ftp://ftp.gnome.org/pub/foo/bar/mod-version.tgz

Build Prefixes
Setup Script
At the moment I don't warrent the confusion of additional logic in this object to handle how you build, I am just going to leave that to the configure() and build().

Now the tricky part is how to allow the user to be able to override parts of the object, in a simple config file. Which brings up the issue, should I create as of yet a new configuration file format? Or should I make it easy for it to be interpreted by my parser. I know all the user interface guys say make it easy for the user! But If I make a new format then they have to learn somthing new! Most people knkow how to write basic perl these days. Also if I make it easily machine interperatable then extending it may be easier.
Human Interest
It is amazing how small the software world is. Just a couple years ago, everything was made by mysterious people elsewhere, now I have met the people who wrote most of the software I use. And it seems the web just extends and fills in the gaps. You take a new job and meet another 20.

5 Jun 2000 »

Well Today I finally got nautilus compiled on my home debian machine. Yay!!! It turns out that if you use and old version of libpng such as 0.96, everything (imlib, gnome-libs, nautilus) will compile fine, but as soon as you run it you will get SIGSEV in __morecore in libc.so.6. It will drive you batty and won't be able to run nautilus. I am not sure where the correct place to check for the version of libpng is. libpng 1.0.3 and higher work fine. (debian package libpng2 and libpng2-dev ) will give you what you need. So I now have a full configuration for what you need to build gnome and nautilus on Debian. Perhaps I will post the needed packages a little later.

I am still working on my portable development tools. Currently I am focusing on things that work for both a bourne derived shell and perl. I am doing most things in perl, but it makes sense to have hooks so korn, bourne, bash, and zsh users can have their environment setup the same way the build is.

I have some working prototypes, all ready packaged up to be used as perl libraries that I use to do gnome builds. I will add some more functionality soon.

incremental build of multi-package systems

notion of a purge build, that will wipe out the destination directories and the source directories

a generalized notion of levels of rebuild

I also wrote a static route startup script using a config file. It is designed for Debian, since they seem to still be lacking this, at least with potato Debian has a sensible networking script. If you need static routes for your machine you can grab my stuff here. It just uses a very basic config file and will add and remove the routes with a stop and start.

26 May 2000 »

Yay today I did my first commit to Nautilus, OK it was someone elses code, but I did commit something.

Right now I am going over some various idea for how to deal with developer environments.

Do not store data in the environment unless you have to.

Keep configuration information seperate from logic, or even seperate from a particular programming language.

Use a sensible programming language. I am choosing perl despite some complaints that it is not sensible.

Keep it easy, yet keep it simple.

Configuration Information You always need to have value pairs, X=Y, this is simple and generic and you will need it for any programming or configuration. It makes the most sense to store this in a file, that you have other scripts/application parse to gain the configuration. This way you do not have to hard configs into your application (other than the location of the configs) and it makes it easily extensible, so you could have an IDE load the configs, a series of installation scripts, and possibly even and environment. This also bennifits maintainability greatly, if you only have to change setting once! Not in 15 million files.

I am currently working on some tools so you can have a perl modules or a bourne derived shell extract settings from the same file and then set those settings for further use.

sensible programming language Maintainability, Maintainability, Maintainablity. Tools do not have heavy performance requirements. They need to be changed and adapted frequently, for integration with other tools, other networks, new releases of OS's. They need to be able to do fancy text processing and deal with meta-data. Your tools will also need to call other tools at the OS level. Continual change, and text processing, and calling external utilities makes scripting languages ideal for this.

Generally builds have enough complexity and logic, that you want a language with decent referencing, library abilities, and scopeing.

Shell is a little weak, as is tcl. Perl I chose because, way more people know it than others (this is important for maintainability), it is easy to learn (if you are familiar with programming in any other language - I would never reccomend perl as a first language), perl integrates very nicely with calling outside programs, and perl has LOTS of usefull ready made modules. The problem with perl is that it can be difficult to maintain your code, the language discourges you from writing clean code, but it does not require you to write unreadable code.

keep it easy keep it simple The idea for tools is to make developers more effective, and to allow a new developer to become effective quickly. At the same time, it is not worth while to reduce the number of commands if it requires additonal conceptioual complexity. DO NOT make context senstive setup commands. This saves typing but does not make it easier for people to become familiar with what is going on.

Some other ideas are that their should be one command to do.

initialize an environment from scratch.

This just saves time. New developer comes in, gets new OS, runs one command gets all the required tools and setup, should download the packages needed, should setup the filsystem, give the developer the localizations they need.

update tools and source.

Things change, it happens. Developer should have one command to hit a centralized spot, and find out what changed and be up to date.

build and release everything.

This is really needed to verify that a setup is correct and that the code that was there doesn't break anything. It needs to be done, it should do all related components.

initialize development environment to work on a project.

In a command line world this is one command, in a GUI world this is a button or open the IDE config file, but there should be one simple way to grab all the settings for a project. These need to be maintained regularly.