Back to home
All News: (Newest at top)
I finished up my new logo. Basically, just simplified down to 4 colors, actually used inkscape the right way this time.
The distro is on hold for a while more - it's hard to test when your testing boxes are 300 miles away. I'll let you know what's up when it's up.
Sorry guys, I haven't been a great developer for this project. The following is my reply to an email by
a faithful follower of the project:
Thanks for your concern. The polypux project will always be at least in the back of my head. The main
problem is that I have so much more important stuff in my life that, when I do find a free moment,
there's invariably something else that I'd rather be doing.
I would love to continue working on poly-p-ux, for real this time. I have a large amount of work that's
nearly finished just sitting around on my 486 development box, almost ready to go.
My most recent problem has been one with the kernel. The 2.6 kernels I'm working with now are simply too
big - they barely work on my 486, and my 386 goal computer, which I'm leaving at 2MB ram, simply does
not have enough ram to even run a kernel, let alone anything else at the same time.
I was planning on working on a livefloppy, and I can definitely do some positive work on this - however
I most definitely need a kernel to work around first. And honestly, that kind of kernel optimization
work is torture for me - I can and have done work on the kernel, but large-scale code reduction is not
If you want to help (and I'll post this reply up on my website for anyone else to read), please, get me
a kernel which I can build with support for some networking and decent storage device support at least
in less than about 500KB. Once I have this kernel, it should be no problem to build a set of floppies
for installation, and build another root for the hard drive for at least 386 and 486. 586 is a different
matter, but should be pretty fun to work on at another time.
Of course, now that I'm thinking of the project, I may just have to have a crack at a little more work
Exciting news - I now own a 386 (NEC PowerMate 325) that works... I'm keeping it at 2mb ram even though I could easily upgrade it.
But, it has come to my attention that there is a surprising lack of useful linux boot floppies that will work on a 386 with 2mb ram.
I built linux-2.0.40 using slackware 4.0 (gcc 188.8.131.52), and the basic config I used (usable, but barely) came out to 322kb - and that's enough to do SLIP and PLIP on... However, I believe in giving people the newest stuff possible (and making it so that I don't have to turn on another old computer to build a kernel), so I have some plans for this floppy set:
- linux-2.0.41. Yes, I'm aware that it does not exist - I'm currently working on that, and making great progress. Significant advances over .40 will include gcc4 build support, some backported drivers (particularly network card and squashfs), and stuff like that.
- One floppy just for kernel. The kernel certainly won't fill that - I'll make multiple kernels so you can decide how to install (one with network support, one with old-cd support, a whole set with scsi support, etc. Think back to slackware bootdisks - bare.i, bare.s, etc.).
- One floppy for in-place root. static-linked busybox with the basics, some tools for setting up various things, my init clone, etc. All wrapped up in a nice squashfs wrapper and packed on to a auperformatted (if necessary) floppy. By in-place, I mean no ram wasted on unpacking and running from there - unless I can figure out how to make that optional (so you can load off floppies), but the default will be the version that runs off the floppy.
This project is not forgotten - I'm busting my hump on fixing the dirty kernel code right now (and will be on vacation - away from computers - for a week), so by the end of summer I should have something unfinished but booting.
BTW: for those wondering why not a 2.6 kernel: a 2.6 kernel with no options enabled (completely unusable, but still technically linux) is over 1mb - I think closer to 1.5.
For those wondering why not 2.4: a 2.4 kernel with enough to run and do stuff with is between 1 and 1.5mb.
Compare this to my 322kb pretty usable 2.0 kernel - I'll give more accurate size figures for other configs later, but you get the picture.
alright, so I lied...
I kind of ran out of time back during winter break, seeing as a bunch of strange compilation problems kicked up when I least expected them. Alright, so you might say, why wouldn't I work on it some more then and get it finished by February?
#1: I have, and I hate to admit this in public, not too much use for this project right now - I mean, it's not like I use my 486 all too often... then again, I did just acquire a pair of 586's, one of which I'm putting in a shoebox, no moving parts - that'll be getting netbsd for now, until I can get polypux to the point that I like it (and it has bind, dhcpd, cups, and a few other knickknacks I need...).
Okay, so I have a bit of motive... unfortunately, thanks to school (it feels like teachers have been trying to make the last few months hard), the oppurtunity has been unavailable. I try to put in a little effort whenever I can, but honestly, that's not very often.
So, it looks like, at least until I get some outside help to whom I know what work I can give, this is my summer project that I'll try to keep up for as long as possible - sorry to dissappoint my (one or two) fans.
If you want to help me, write a package manager in C that is as minimal as possible and does what I need it to do, or build me a bootable floppy for each of the three processors that meets my requirements - in both cases, if you're remotely interested, pop in to the mailing list...
...although it's not as if anyone is reading this...
Well, I thought you might all like some good news for Christmas (since it's tomorrow... this can also be good news for Hannukah, Kwanzaa, Solstice, or whatever your preference is)...
The new builds are going to use buildroot only for building the toolchains - I'll be making the roots myself. This actually is a good idea, because of how much of a hassle buildroot actually is.
So, what's the good news? The toolchains are all built! Now I can simply build all the applications to include in the root filesystems for my 3 architectures (686 is being dropped because of build issues... I'll pick it up again later, maybe.).
I'm still aiming for a 2008 copyright date :P
Hello friends: I am not dead... just very, very busy. If nothing goes wrong, poly-p-ux 1.0 will have a 2008 copyright date :P .
I changed up how I'm doing everything - I build a buildroot toolchain once, then cross-compile everything I want.
The other day (I was home sick from school), I started this process... unfortunately, I hit some issues. I'm hanging out on the buildroot mailing list, trying to get a solution to this problem, so don't worry.
I have a busy week coming up, so don't expect any progress before next weekend, but what better way to spend the holiday break than working on a linux distribution?
Snailit now has fsck support - I basically stole the code straight from gentoo's baselayout-1, but it works just fine, and has saved me a bunch of effort already. I also fixed it so that it just gives you a little warning if you try to execute it as pid != 1.
Otherwise, I have my layout, so I know how I'm going to proceed.
Prepare for something usable!
Well, as promised, I've been working like crazy on this init replacement...
...prepare to be slightly amazed!
It now supports at least as many functions as busybox's init, it runs in less nonshared ram (128kb vs. 134), and more!
Normally, I'd be working on the actual release right now - too bad, you'll have to wait a while for that. My desktop (also main building machine) was on the AMD stock heatsink, the fan died, fortunately it hit the BIOS cutoff temperature of 85 celsius...
I'll release as soon as I get the "final" binaries on to all three of my test boxes.
this will be release version 1.00. When I get some sort of X working (probably kdrive), version 2.00 will happen.
And of course, I'm switching the shell from bash to busybox's ash... no more segfaults!
Well, thank deity, school is over for the year, the programming season has begun, and I just ordered Orange Box!
So I promised I would start working on the "major poly-p-ux redux" over summer - well, I've actually been working on it for a while. In fact, I have a well-working init system already in place. All that I must do now is reduce memory usage (I've dumped bash, zsh is huge and awkward, I'll use busybox's dash. Oh, and make it so every respawn process doesn't need a shell guiding it :D) My goal - 2mb of usage on startup. However, once I get it down to 3 (and it works on my 386 laptop), I'll release.
What should you expect? Greatness:
- A shell that doesn't segfault running scripts
- A brand new init system that is smaller and works better.
- Very low memory usage!
- A developer that will actually work on the project.
Hope to release soon!
I'm not dead yet!
School has been pretty time-consuming lately, what with summer nearing. I really have not had much time to work on poly-p-ux.
This three-day weekend is a good place to start, and after school is over, be prepared for lots of work on this.
What are my plans? Well, first off, I want to totally redo most of the system. In order to avoid the random segfaults that are plaguing me, I'll just rewrite the whole init system, probably in bash. Sure, it'll take a while, and it only might come out as well as "real" init implementations, but I'll have full control.
Also, I'm planning on phasing out other parts of busybox in favor of bash scripts that do the same thing. In other words, I'm planning to make poly-p-ux the lean, mean, bash-script machine it should be. And, I (and you) will have full control over all the system's bash scripts. This means customizability and ease of debugging.
For now, use the versions in existance (sorry about the lack of the 386 version - the copy I tried to make crashed my build machine when I chrooted into it), and join the mailing list if you want to get involved.
Well, as promised, here's poly-p-ux version 0.01 for the 586! Keep in mind that the 0.01 has NOTHING to do with the 0.01 486 release, so 0.01-586 is actually slightly more up-to-date than 0.20-486. Just use the busybox update (which will hit the site later today, probably), and you'll be most of the way there.
Use the documentation and download links to get it.
Well, as you may have noticed, there's a tip-of-the week link up top. Follow it for some cool stuff!
As for poly-p-ux itself, I've uploaded all the correct files, I just need to fix the links on the website - Not only is the 0.01 release of the 586 version of poly-p-ux ready, so is the busybox update (to 0.10.0) for 486's.
Aw, what the hell. 0.20 is now stable. After all, it's not like I'm going to change the release *now* :D .
I have been noticing a weird segfault whenever certain shell scripts are run. That should get fixed in the near future. Also, if I get bored tonight, I'll hack together new networking scripts to make everyone's lives easier.
For now, you can ssh into your favorite server and run some web browser from there, you can play adventure, or you could figure out how to use the framebuffer :D .
0.20 is *almost* stable-ready! I have successfully compiled all of the packages that were present for 0.03 AND MORE for 0.20! In fact, I'm writing this using vim on an ssh connection (to the ibibilo server) FROM MY 486!
Exciting stuff. Now it's time to write up documentation (uggh).
Bsd-games has officially been compiled for poly-p-ux! bsd-games version 2.17 is now available for 0.20 - check the packages directory in my ftp space. As soon as all the packages from 0.03 are recompiled for 0.20, and I add the recent changes to the documentation, I'll declare 0.20 stable, and replacing 0.03.
For now, have fun playing tetris-bsd!
NB: I have NOT included atc (build errors), hunt (build errors), factor (other implementations availbe, not to mention strange dependencies), and fortune (better implementation available).
I am in the process of releasing 0.20 (Don't worry - I'm not dead, just lazy). Currently, I'm working on shifting everything to keep the 0.03 stuff seperate from the new stuff. As you can see, I've already begun that organization in the ftp directory.
What's new in 0.20? Well, I can actually tell you since I have it compiled (but barely tested). The first thing you'll notice is the new 184.108.40.206 kernel (Yay, no vmsplice exploits for us!), this time compiled with EVEN MORE MODULES (for advanced configuribility), and fb support! Apologies to FreeBSoD: I forgot to apply the /dev/one patch yet again. I'll remember next time, I promise! Also new is: /dev/fd0, WCHAR/locale support in uclibc, a new method of building toolchain installs (I'll FINALLY be able to compile bsd-games!), an almost-improved module autoload feature (Well, it was *almost* cool...), and a vastly improved (read: buggy) network system.
I certainly hope to get some sort of X and a few games up for this version, ASAP. I'm working (eventually) towards all the useful/fun features of RedHat 3.0.3 and slackware 11.0 combined, in a smaller space, which is very possible.
Okay, so you're probably wondering two things: why would I suddenly wake from my sleep as far as the project is concerned, and why 0.20? Well, to answer your first question, I needed a print server, and FAST. It turned out that the parallel port header for my new computer came in before I got a chance to finish getting cups on poly-p-ux, but that's why I had to quick-compile a bunch of stuff. Why 0.20 and not 0.10 or 0.04? Well, I had a version compiling that was *potentially* binary-incompatible with 0.03, not to mention touting a bunch of new features. Well, on my computer, at least, that became 0.10. I installed it to my 486, and realized how awful it was. My oh-so-cool modules.autoload feature was completely broken, my network system was intermitten, and it was overall a failure. It did have some good ideas, though. Those were expressed, after a long break (sorry!) from poly-p-ux, in 0.20, the next major version after an unreleased one.
When will you see it? Well, I'm putting it on the shelf by tonight, so you'll be able to find it in the 0.20 directory of my ftp space, probably by the time you read this! It will be, though, only the base system. Packages will come later, after I've had a go at testing the version. Oh, and as I'm writing this, I can think of a few problems with what's in the tarball that are quick and easy-to-fix. Basically, you can try it out now, but it might be slightly different by the time it is officially released. Oh, and I won't update the documentation until the very end, and although it's mostly the same as from 0.03, there are some differences. Figure it out yourself, and don't bother me if you're installing 0.20.
There are now packages for miscfiles, tnftp, zlib, and dropbear. Check 'em out!
poly-p-ux 0.03 has been released. The only major changes are the missing packages (dropbear, mostly) from the stages. There are now packages for these in the packages/ directory in my ftp space. See Download for details. And upgrade, if you're one of the few people who have installed 0.02 already.