gnomr

I’ve been thinking for a while that it’d be useful as all hell to have a solid configuration tool for gnome to generate kiosks. Internet kiosks. With one click of a checkbox.

 

So, I started reading the gnome sys admin guide today. It looks like this won’t be too hard to pull off, especially if I concentrate on getting it working well in just one linux distribution and in FreeBSD and accept that that’s the limit of my ambitions. In either case, FreeBSD’s gnome configuration is different enough to most linuxes that I imagine that alone would be a good couple of cases to ensure cross-distro viability.

 

It might be simplest to configure things how I want using the tools in gnome2 itself, rather than attacking the xml config files, then dump out the xml configs and write a tool that’ll just copy ’em over a user’s defaults.

remote port building issue #1

So, I have some ruby and some shell. I think the shell is doing better than the ruby, but I can also see where teh ruby is coming in.

I have this vague design in mind:

1. locally, you state that you want to perform installation of port X.
2. a list is built which is rsynced over to the remote machine
3. the remote machine has a daemon listening which can build the packages — yeah, there’s a good chance of a security hole here, but that’s recognised.
4. build the software as packages remotely
5. notify the machine that its build is ready — some mechanism to acknowledge this and allow for the reverse rsync automagically will be nice.
6. install the packages

—

Now, see the problem? Libraries. Ports are nefarious beasts; the machines need to perfectly in sync to do this easily, which is doable with Jails, but.

I don’t want jails to have to be the solution. Building the packages statically would help out, but inflate things.

I need to work out what changes to the ports infrastructure would make this easier. Any ports ninjas reading this?

decisions, decisions, decisions

I’ve been thinking about writing a new ports installation tool which solves a few problems I’ve always thought would be neat to solve. Thus:

1. decision 1 — write a new ports tool or extend an existing one?

This is really hard. I’d write a new ports tool in ruby or shell. Guess what the two existing main ports tools are written in? That’s right, ruby and shell! So I just sit here thinking about the wisdom of potentially rewriting a lot of functionality. Especially with portupgrade being written by a hacker who’s ten times the programmer I am, and portmaster being, well, fucking fantastic.

Here’s some of my aims:

1. The ability to instruct a remote machine to build every port needed
    for a local upgrade of ports as a packaged to be pkg_added.
2. The ability to cross compile everything. This means that a local
    arm board can upgrade its onboard dns server by having a remote
    xeon based computer build the port.
3. The ability to run the command without super user privileges. I
    want to have a directory I have write access to that my ports
    can build to and be able to do an upgrade of those ports
    automatically.
4. The ability to synchronise ports across machines. This should be
    architecture independent, and should take into account that
    ports can with this tool be installed into home.

Which leads to decision 2:

2. How do I technologically best accomplish this?

Which is the same as decision one, really.

There are so many decisions. How do you search for a port when someone wants to install it? The other two tools I usually use for this stuff answer this question by saying “we don’t”.

So, accepting my premise that I’m not as good as these other folks at solving this issue, I won’t either.

A second: how do you determine if a port is to be upgraded? Well, there are two options I see:
1. roll my own method of doing so
2. use someone else’s method of doing so

I prefer the idea of number 2. Software is something that should be built modularly, so that each piece can be upgraded independently. And if I just use someone else’s tool, then I inherit their improvements.

portupgrade looks like the tool I shoould be thinking about, but I don’t want to follow their design decisions. I instinctively think portmaster has the right idea with not using an external database; maintaining pkgdb is annoying, irritating, and a whole host of other words which mean the same damn thing. There are a host of poorly documented prompts when repairing the database; stale dependency, eh? Great! What does it MEAN? I’ve always _assumed_ it was a reference to the idea that a dependency listed in the database is no longer needed, or somesuch thing; googling around can tell you, I’m sure, but the man page for pkgdb doesn’t, and if it ain’t in the man page then it’s undocumented. And that means that yes, I do consider man man to be inadequate because it tells you there a re other sections of the manual but doesn’t tell you _what_they_are_. I know what they are, they’re historically significant and everyone should know them, but man man should list them too.

I’m getting dangerously close to ranting, when I’m actually trying to document something. The aim here is to give people who’ve never written this sort of tool an idea of how the thought process goes. It’s all decisions, and no decision is correct.

Where’s the damn GSOC Code, dude?

I was talking to my mentor the other day about having committing code because, let’s face it, FreeBSD has some of the world’s greatest coders writing for it. And I’m terrified and nervous. Because I write crappy code, I know I write crappy code, I’m comfortable writing crappy code, because I never distribute my crappy code.

This last part changed with GSOC. I have to have people able to read my code, I have to distribute the code, all that stuff. And the official SCM is Perforce, but I’m not a huge fan so far. I much prefer git.

So this is the git URL for the code:

git://github.com/jamesh/shinybsd.git

It’s called shinybsd; feel free to track it. If you want to actually commit to the repo, let me know and I’ll help you get set up. Be aware that you’ll need an account on github.com

I’ll be syncing this back up semi-regularly with perforce, so no worries if that’s what you want to watch.

ca-ca-catching up

I did something today that I’ve never done before. I decided that I was going to see how far that FreeBSD and gnome integrate with each other. Whenever I install FreeBSD, I usually run it as a CLI os. I install a window manager, but it’s not there as anything really other than support for multiple terminals. I use ubuntu for a nice pretty OS with integration between all the disparate elements, and FreeBSD for real work.

So I started following the instructions from the FreeBSD Gnome folks for auto-mounting this and pleasant integration that. In the process, amazing things happened. Screensavers started working brilliantly, icons that were missing showed up out of nowhere, and I started to see the truth of a friend of mine’s observation to me two years ago that FreeBSD and Gnome are exceptionally well integrated with each other.

I almost feel like writing a port that’s just a shell script to execute the relevant bits and pieces to make FreeBSD shine with Gnome; it’s amazing that all this time I could have had this on the desktop and instead was using linux.

—

I privately noted an interesting thing today. I started using the _excellent_ portmaster tool to solve ports issues instead of portupgrade recently, and out of nowhere the amount of circular dependencies registered in pkgb skyrocketed. It’s probably merely a coincidence, but still.

—

trap just became my new best friend: http://docs.hp.com/en/B2355-90046/ch23s07.html

I’ve been following the code for NanoBSD of late; it’s extremely clearly written and provides excellent examples of shell code. Well worth a look.

I’ve also been following my interests down the path to the source code of common utilities. What’s neat is the little things I hadn’t thought of. For example, from boot0cfg, in the case statement that reads argv, Robert Nordier sets a variable to equal 1:

case 'f':
fpath = optarg;
break;

Then,

/* save the existing MBR if we are asked to do so */
if (fpath)
write_mbr(fpath, O_CREAT | O_TRUNC, mbr, mbr_size);

Robert directly tests for truth on the fpath variable. I’ve always called my variables something like fpath_test to remind myself that they’re essentially booleans; however, looking at this I’m suddenly hit by the “Oh, there’s no real need to do what I do, and it might sacrifice a little clarity”.

This suddenly makes me wonder: would there be any performance impact of using boolean types here? I can’t imagine there would be, as I assume the boole types are little more than static constants.

I noticed this little gem in the code for boot0cfg, too:

opttbl[] = {
{"packet", 0},
{"update", 1},
{"setdrv", 0}
};

Is it just me, or is that sucker a dictionary/hash?

I need to include the following to satisfy the license:

/*
* Copyright (c) 1999 Robert Nordier
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS“AS IS” AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
* OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
* OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/