Domain: freelords.org
Stories and comments across the archive that link to freelords.org.
Comments · 10
-
Re:8.1 will have to wait...
Graphical boot messages screen so my bootup can get slower
I believe you want the Linux Progress Patch. Pro: graphical bootup. Con: you need to apply the patch to your kernel and recompile. :->.But I am guessing you want it on by default from RedHat
:) -
remember warlords?
I used to play SSG's Warlords2 like a crack addict. I recently found an open source project to clone it, much like freecraft did for warcraft. It's still in development, but projects like this are the bread and butter of classic gaming (sans emulators, of course.)
-
Done.
Runs on a commodity Pentium-class or higher (assume approximately ~166 MHz or higher) x86 hardware, 32 MB of RAM, preferably within 16 MB of RAM.
Sounds reasionable. Use Keith Ps TinyX X server, which is used on Microwindows any many oother embedded Linux systems.
Is very barebones - I do not need a full distro. Under ~128 MB in size would be great.
My work does embedded Linux consumer devices for Large Unnamed Japanese Electronics Company. 128MB is doable.
Pico or VIM is okay for a default editor.
They're unecessary too. Obviously the end user won't modify text files. Keep the whole development on a seperate OC and cross compile - this keeps the shit off the small box and means you can compile things faster.
Requires no user intervention to boot, get a DHCP lease, load X-Windows, start the rdesktop client, and connect to a machine with the DNS name of "termserver" or other similiar handy name.
Cool. Autologin to X by a particular user is supported by most display managers. Then in whatever users .xinitrc or .xsession (I can never remember which is which) put:
START
#!/bin/bash
# Change the background color and cursor
xsetroot -solid rgb:39/6d/a4 -cursor /terminal/cursor.xpm /terminal/mask.xpm
# Set the variable lasthost to the content of the .rdplasthost file
lasthost=`cat .rdplasthost`
# Set the variable host to the stdout of Xdialog
host=`Xdialog --stdout --icon rdesktop.xpm --no-cancel --ok-label "Connect" --inputbox "" 400x200 $lasthost`
# If we can ping the host, continue. If not, fuck off :)
# Seems good. Lets remember it for next time.
rm -rf .rdplasthost
touch .rdplasthost
echo $host >> .rdplasthost
# Run an rdesktop session on the host
rdesktop -g 1152x864 -f $host
END
Provides a clean, friendly method of powering off the machine without causing data corruption on the file-system level (ie, after disconnected, will prompt for re-connection or shutdown).
Have the button on the front force a shutdown. This is easy with most embedded hardware. You'd also use a journalling filesystem.
Supports at least three commodity network cards
Linux can do that if you want, but I don't think you want that. Buy an untra tiny embedded box from Advantech that fits in the back on an PCD display. This way the hardware is a `known quantity' and problems are a lot easier to troubleshoot - less variables equals less things to go wrong, which is important to anyone making embedded boxes. How often do you change the hardware on your NCD thinterm RDP terminals? That's right - not very often.
Supports a VESA standard SVGA video card, with X-Windows running in 800x600 @ 8 bit color (256 colours). The Windows 2000 Terminal Server will not support anything higher than 256 colours so its not needed to support high/true color modes.
Cool. But fuck 800 x 600. Give them 1024 LCDs. You know you want to, and you'll sell more boxes.
Hides all boot messages from the kernel etc, and instead replaces them with a friendly "Please Wait" message.
Linux Progress Patch will do exactly that.
Is distributed to me in the form of a ghost-compatible image that when restored to disk is ready to run as described above.
Ghost is a waste of money unless your doing multicast installs. For the rest of us, PartImage will perform the same function more reliably with
far less expense.
Testing under VMware shouldn't be a problem, but again, I'd test on the actual device.
Everything I've mentioned is BSD / GPL license compatible (including PartImage). -
Re:what about boot messages?
Linus was all for it however I seem to remember some other people (Alan Cox beng one of them) saying its the only recognition they get and so no one implemented it.
There is a patch called the Linux Progress Patch which gives you a graphical startup with a bar and some explanation of what is going on. Its quite pretty and if there is an error the normal messages can be seen on the second console. -
Re:yes but that is a test kernel
What you want is the Linux Progress Patch, my friend.
-
Useful for configuration
I disagree with this. I have used the Linux boot process to identify an unknown system that a friend wanted Windows installed on, so that I'd know which Windows drivers to look for! I find one of the best ways to take hardware inventory of an unknown computer is to attempt to boot Linux on it. Even if the boot is unsuccessful, the console messages tell a lot about the hardware and what's in there!
I sincerely hope the drivers aren't edited down to prevent this logging. All of the text should be available to read with dmesg. What I hope is that a compromise can be reached: default to a pretty-boot process, but have a way for the knowledgeable user to still see the console (perhaps by pressing the ESC key).
Or, use the priority system of printk to prioritize each message, and have an optional boot parameter that would control how many messages get printed. It could be something like bootverbosity=8, given on the boot command line. This already exists, look at the argument to klogd -c!
Doing a kernel-wide purge of all informational messages is just the Wrong Thing, as these messages will then be lost and there will be no way to print them when they are needed to solve problems!
Super eurobeat from Avex and Konami unite in your DANCE! -
That 2.4 kernel
Actually, it's surprisingly responsive on such old hardware. I wouldn't call it "fast", but for a Pentium with 40MB of RAM, I'd recommend it. Does the video card on that baby have Linux Framebuffer support for (say) a cool boot process like the one from the Linux Progress Patch project?
Unfortunately, my laptop doesn't. I think the video card only has 512K of RAM; I don't know, because I wasn't (and still am not) suicidal enough to throw X on there. However, I did manage to fit glibc, egcs, mysql, and apache on there... a full server in less than 200 MB of space, all running from a laptop! it's insane. I'm a walking UNIX server! : ) -
Re:Linux Progress Patch
When it can be integrated into a users system in a matter of seconds is when people will start checking it out more.
Unfortunately, I'd guess that most people will start using it exactly when one of the big distros adopts it as standard. Oh well; they already have a Debian theme.
(Also, you need to put a ml at the end of the Energy Star link in this story).
And in case that page is as hugely slow to load for you as it is for me, here's Google's cache of it. The process is also described at:
-
I think it already does show the last line
If you look at the screenshot, the bottom of the screen says starting gdm-- so I'd guess it already does do this.
M
-
Broken links
The energy star link should be http://bios.new.com.ua:8100/energy.html
.. also, on the linuxnews.pl page, the url got a extra " that screws things up .. http://lpp.freelords.org is the right url for the Linux Progress Patch ;). Anyhow, this is good, but - haven't tested it, can you press escape or something to see the _real_ boot msgs? :P