I think it would be much more useful if it were a relevant,
helpful, needed project to release under the GPL for Unix in
general, not Linux in specific. Of course, if it's a sysadmin
tool, it will have to be tied to a specific variant of Unix,
but maybe something else could be found that is not so
system-dependent.
I use Solaris at school, and LinuxPPC at home. And personally,
I'm a little frustrated by how much i386-linux-specific software
is out there. I know: it's open source, so go port it yourself
if you want it.
But it seems to me that a lot of Linux programmers have a very
platform-centric vision of the world. This last comment has nothing
to do with Macphisto's message (I'm not implying that you
have a platform-centric vision of the world), it's just a
comment that pops up in my head every once in a while.
--ZZamboni
| [reply] |
How about a Perl/tk/GTK version of "make xconfig"? AFAIK, right now it's written in tk, but when you do a "make xconfig", you get the following garbage on your terminal:
nooky:/usr/src/linux-2.2.16# make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.2.16/scripts'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkparse.o
+ tkparse.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkcond.o
+tkcond.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkgen.o t
+kgen.c
gcc -o tkparse tkparse.o tkcond.o tkgen.o
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
echo "set defaults \"arch/i386/defconfig\"" >> kconfig.tk
echo "set ARCH \"i386\"" >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make[1]: Leaving directory `/usr/src/linux-2.2.16/scripts'
wish -f scripts/kconfig.tk
How cool would it be to do a perl version? That would remove the gcc compilation necessary, and i'm sure it would simplify the .config file parsing that happens. Anyone else have opinions here?
BlueLines
Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary. | [reply]
[d/l] |
We have been pre-empted by Eric Raymond working in Python.
The current project is here.
Personally I think doing a Linux-specific thing in Perl is somewhat silly. What is the point of having an ultra-portable language if the first thing you want to do is try to write unportable code? Just because you like Linux does not mean that kudra or KM shouldn't find it useful on *BSD...
| [reply] |
well, the original question asked was regarding a PerlMonks contribution to linux. I do everything but play q3 on openBSD machines, and i wasn't intending to start a holy war over this. But I can't think of anything offhand that could both benefit from being rewritten in perl and is not platform specific. I mean, just because ping/telnet/lsof can be rewritten in perl doesn't necessarily mean they should be...
how about a gui kernel configuration tool for *BSD?
BlueLines
Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.
| [reply] |
Only if the same kernel hacks (or whatever) were ported to FreeBSD ;-)
Cheers,
KM | [reply] |