Penguinistas Group Blog

question

Wednesday, November 16, 2005 3:11 PM
This is probably more of something I should email to the group rather than blogging, but I feel blogging is less intrusive so here goes:

Does anyone here know a way to determine under what kernel a file was compiled?
Visibility: Anyone
1. Posted by
Is that information even stored in a compiled binary? I can imagine which operating system the file was built for (in a general sense, e.g. Linux, Solaris, HP-UX) being stored there, as well as the compiler used, but a specific kernel version seems like unnecessary information.
11/16/2005 4:34 PM
 
2. Posted by
That's certainly something I've considered, and I wouldn't be suprised if that's the case. I am hoping it isn't since it would be very convenient for something I'm working on.
11/16/2005 4:52 PM
 
3. Posted by
You might have some luck if it is an installed RPM. You could try querying the rpm with something like:

%rpm -q rpm_name

If it returns the full rpm name, then you'll know what version you're using. Build and release info is found by typing

%rpm -qi rpm_name

The date of the build might give you a good idea of whether its built on kernel 2.4/2.6 or something older.
11/17/2005 1:35 PM
 
4. Posted by
No it's a module that we compiled. So far the closest I've come is using

%strings filename

and it contains an entry "kernel_version=2.4.26"

at first I was unsure if this entry definitely means that it was compiled under 2.4.26, but I am reasonably confident now
11/17/2005 2:59 PM
 
5. Posted by
True that works for 2.4 kernel modules, and "vermagic" works for 2.6 kernel modules; but for your average compiled binary you're not going to find that information.
11/18/2005 11:12 AM
 
6. Posted by
Unless it matters for the binary (for example, firewalling software may be kernel version dependent), that generally shouldn't be an issue. You should probably download the source and look around in there. If you got the package through your distro or from a third party repository, it is likely that the package was compiled with the default kernel supplied by that repository. However, this is not always the case, especially for smaller (i.e., package specific) repositories, so if you can download the source (or even better, if your distro uses .rpm, you might be able to look at the source rpm), look through the source tree at the changelogs and buildscripts. If you're lucky, you'll find any relevant info there.
11/18/2005 6:29 PM
 
7. Posted by
True, but in the case where the binary is kernel version dependent you aren't necessarily going to be guarranteed to find it by doing a "% strings filname | grep kernel_version". I'm not saying the information isn't in there, simply that there is no standardized way to figure out whether a binary (independent of its packaging) is kernel version dependent and which version it is dependent on.
11/21/2005 9:27 AM
 
8. Posted by
Hmm. This is why packages normally have some sort of package-maintainer contact info. If it doesn't, there should be a way to get ahold of the person or people in charge of either the repository from which it was downloaded, or at worst, find the home page for the project and ask around on the mailing list(s) or forum(s). If this is important information, the information will probably be somewhere. If the information is not to be found, file bug reports.
11/25/2005 2:24 AM
 

Not specific to Penguinistas...

Monday, October 31, 2005 4:27 PM

But I think people in here might have some feedback... Has anyone here tried the Dvorak keyboard layout?  I hadn't heard of it until just now and I'm intrigued....

 

http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard

Visibility: Anyone

Adoption of linux... the Anti-linux conspiracy

Tuesday, October 18, 2005 8:34 PM
This just got slashdotted, so I'm sure a lot of you have already seen it.  Nonetheless, it's a decent summary and expreses a lot of what I feel.
http://searchopensource.techtarget.com/originalContent/0,289142,sid39_gci1134910,00.html 
I'd say it actually starts getting better at part 2.

By the way, my Ubuntu Breezy 5.10 install went perfectly and I found a cool script - anyone else considering Ubuntu should use Easy Ubuntu after the install, it sets up everything that Ubuntu can't legally put on the distribution (like Quicktime, Realplayer, MP3 support and all that proprietary garbage...).

jet
Visibility: Anyone

gnome vs kde the never ending dispute...

Friday, September 9, 2005 2:50 PM
So first a bit of background from the Wiki entry on Gnome, those already familiar could skip:
-------

The GNOME project was started in August 1997 by Miguel de Icaza and Federico Mena to provide an alternative to KDE.

KDE is a free software desktop environment that relies on the Qt toolkit — a piece of software written by Trolltech that did not use a free software license. Members of the GNU project became concerned about the use of such a toolkit for building a free software desktop and applications and launched two projects: "Harmony", to create a replacement for the Qt libraries, and the GNOME project to create a new desktop without Qt and built entirely on top of free software.[2]

In November 1998, the QT toolkit was licensed under the open source Q Public License (QPL), but debate continued about compatibility with the GNU General Public License (GPL). In September 2000, Trolltech made the GNU/Linux version of the Qt libraries available under the GPL, in addition to the QPL, thereby removing most of the objections that had fuelled years of licensing debates.[3] The licensing of Qt is still controversial for some people because the use of the GPL for a library imposes restrictions on the licensing of code linking to it, including the KDE framework and any applications written for it. In particular, in order to develop proprietary software with KDE and Qt, it is necessary to purchase a commercial license from Trolltech.

In place of the Qt toolkit, the GIMP Toolkit (GTK+) was chosen as the base of the GNOME desktop. GTK+ uses the GNU Lesser Public License (LGPL), a free software license that allows software linking to it, such as applications written for GNOME, to use almost any license.[4] The GNOME desktop itself is licensed under the LGPL for its libraries, and the GPL for applications that are part of the GNOME project itself.

The GNOME desktop is written in the C programming language. A number of language bindings are available, allowing GNOME applications to be written in a variety of languages, such as C++, Java, Ruby, C#, Python, Perl and many others.

----
So I think that is a pretty good summary of Gnome's history, but my question to the community, how objectionable is the Trolltech license today?  Regardless of the state of each desktop environment, is it better to support Gnome since it is truly free and, in part because of this, will provide a better platform to build on for the future?  I've heard GTK+ is improving rapidly (since this was a weakpoint of Gnome compared to KDE for development) and that GTK+ 2 is around the corner with various improvements (although no backward compatibility). 


I'm using Gnome now and will support it and encourage others to use it almost entirely on the basis that the licensing is better than KDE, although the fact it is community developed and improving rapidly are also key factors.  Do others agree with this, or do they believe the licensing of the Qt toolkit is not of that much importance?


Visibility: Anyone

ancient laptop adventure

Friday, September 9, 2005 12:52 AM
I should probably mention here my recent adventure installing linux onto my laptop. I apologize in advance for my short, choppy sentences and confusing tenses. I normally write in the present tense. If you can't stomach profanity, I offer a mild apology. I try to moderate myself, but I'm not always good at it.

Ancient Fujitsu LifeBook 530T, circa 1996. Nothing other than the default apps installed except for a demo of some silly game. Norton AV physically removed but not uninstalled. Win95 in all its glory. CD Rom drive , no floppy drive, no USB drive (1996! you gotta be kidding!), internal modem, no network card. 1.3 Gb hard drive. Not much RAM (I'm not currently remembering how much). I should mention that such experiments are not for the faint of heart. Installing onto sufficiently old hardware, especially laptops, can be a frustrating experience. It might work, it might turn the computer into a brick. Fortunately this computer was free (for me, anyway... I think that in 1996, this may have been state of the art).

The original owners were friends of my grandmother. They wanted to throw it away. She wanted to see if one of us kids could use it.

First thing I want to try is a Live CD. Since I'm a musician, I like to have a dyne:bolic CD around. Pop it in, reboot. Boots to Windows. Check BIOS settings. Asks for password. Damn thing is locked. Boot Windows again. Look through the contents of the dyne:bolic CD to see if there is a way to load linux from DOS (I'd remembered reading something like this on their website once). Found Loadlin.

After several reboots and the problems that led to them, I successfully run loadlin. Kernel panic. Swearing ensues. Decide to examine the guts of the computer to see where the battery is so that I can reset the BIOS. I take it apart once, tentatively. I've never done something like this before. Put it back together after finding no battery. Try loadlin again, but with the Debian disk. Debian installer needs too much memory?! Damn ancient laptop! Not enough memory to run the Debian installer from DOS!

Try taking the thing apart again. Find new screws to unscrew. Take it more apart than I need to, fully removing the keyboard, afraid that I may not be able to get the tabs back together properly. Damned battery is soldered. Since I don't solder, I leave it, consider other options.

Boot back to Windows, since this is the only way I can figure out how to get the damned computer to recognize the CD Rom. There's got to be a way to not have to boot Windows. I hate having to look at it. Call the brother, leave an urgent -- but not desperate -- sounding message. Call another friend who is able to offer sympathy, but can't understand why on earth I'm wasting my time like this, who advises me to edit the autoexec.bat and config.sys files. Shit. Google offers little help, and my 4am brain isn't making matters any better.

I think at this point, I recognized that there were things I would want to install that come on Debian disk 2, and began downloading it.

A day or two passes.

Eventually, the brother comes over. Probably to drop me off after climbing at the gym. Looks at it, wonders why the autoexec.bat comments out the cdrom drive. Now, at least, no more having to load Windows just to access the CD Rom.

Memory comes to the rescue. I have a Slackware disk lying around somewhere. I root around my room and find it.

Using my recently-acquired Loadlin know-how, I easily load the Slackware installer. Not looking forward to trying to configure x11. There is an installer kernel for low memory situations. This is a low memory situation.

I install a base system with far more than I need. Every few packages fails. I try installing again. Same problem, but different packages fail. Try again, with minimal choices, but keeping X11. Fewer packages fail, none important, but including an X11 app or two... I can reinstall those. Installation succeeds, reboot. Wait. If it's fucked, this has been a waste of hours and hours of my life. At least the damned thing was free.

Boots. There are very few things more satisfying than the first login prompt of a recently installed OS. Ok, that's a lie. There are a lot of much more satisfying things. But this time was more satisfying than any other. I bask in my own glory for a few moments.

Run startx. As lucky as I expected to be. It crashes. Complains about pointer devices, displays, and many other issues. Since this is the exact thing I didn't feel like doing from the beginning (lazy me), I modify the Lilo config file to include the Debian CD. Forget to run /sbin/lilo. Reboot. Slackware loads. Dumbshit. Run /sbin/lilo. Reboot. Debian installer runs! Not too little memory now!

Debian installer goes without problems. I obsess a little too long over how to partition the drive. Base system installs without a hitch. First reboot, no problem. This is a little eerie. Ok, one problem. Debian, for some silly reason, changes the console font. Now it's harder to read. But at least I have a Debian laptop. Install X11 and windowmaker (what can I say, I like windowmaker), answer debconf's questions about the hardware. Run startx. I have a working gui!

At this point, I have three disks of the Debian repository (out of, what, 14?). A few packages I'd like to install, but am not interested in wasting another platter for the total of six or twelve packages that would end up being installed. I'll buy a cheap ethernet or wireless adaptor that's known to work with linux, install them then. I have some minor, but odd, questions for the Debian community. Namely:

Why is the ASClock themes package on disk 3, but ASClock is on disk 4. ASClock themes are useless without ASClock.

Similarly, Why can I install freeciv-data (on disk 3), but not freeciv (on disk 4)? Same problem.

I know the actual reasons for this (the popularity-contest package that lets the debian developers know what's most popular, so what should be on the earlier disks), but still. Useless is still useless.

But. The damn thing works. As soon as I can get it hooked up to the internet, I'll install LilyPond and ASClock. Freeciv if I have space available. (Hell, if I have time available!)


Visibility: Anyone