Glitz

What bootloader do you have in the MBR? This is what the BIOS will boot. Somehow you have to get that bootloader to boot linux. Glitz.

OpenMandriva LX 2013.0 Final was released on November 22, 2013 and work has started on 2014. I gave it a try in live mode yesterday and it looks pretty spiffy. Give it a spin! Glitz. PS. I tried posting this in Portal News but the post disappeared so I'm posting it here instead.

OpenMandriva 2013.0 Final was released on November 22, 2013 and work has begun on 2014! Hopefully, this will liven up the discussion around here ;-) I am currently writing this from the OpenMandriva 2013.0 live boot. Find it here: http://www.openmandriva.org Cheers, Glitz.

This is just a quick tip on getting digital audio out working on the SBlive! and possibly other soundcards especially with the ALSA system. In KMIX (with SBlive! soundcard): Make sure the following settings in the Switches section are set properly: 1. IEC958 Optical Raw -> Unless you are using a fiber optic cable make sure this is deselected. 2. SB Live Analog/Digital Output Jack -> Make sure this is selected. Note that the regular sound volume controls no longer have any effect. You have to use the ones in the Input section. eg. Surround, Synth, Wave. For digital CD input use IEC958 TTL. For analog CD input set Capture to about the fifth tick (more tends to introduce distortion) and use the AC97 slider in the Output section. Make sure the volume controls are not set to zero. This will ensure that audio data is being sent out of the SPDIF port. Now, it may happen that you still have no sound. Or, it can happen that the sound works fine but TOTEM (or some other video program) was using the AC3 passthrough option and it crashed, leaving you with working AC3 passthrough but no sound otherwise. This is annoying, and contrary to what you might find on the internet, does not require a re-install of linux. After reading many, many manpages, I figured out what was happening and how to fix it. Quick technical aside: Data piped out of the digital port to a receiver requires header information for the receiver to know how to interpret the signal. The soundcard automatically appends this data to the LPCM signal output from the soundcard. However, when invoking AC3 passthrough mode, the soundcard is disabled from attaching this header since the AC3 data already has the necessary headers for the receiver. It then just passes the data unaltered. When AC3 passthrough mode is enabled and the video player crashes, it tends to stay enabled and does not get switched back again (even if you load up the player again and then exit). And so the LPCM data gets no headers attached and the receiver doesn't have a clue what to do with the data. Now, how can you tell if this has happened? From a command console run: iecset You will get some output that looks like this: Mode: consumer Data: audio Rate: 48000 Hz Copyright: permitted Emphasis: none Category: PCM coder Original: original Clock: 1000 ppm In particular, note the field that says "Data: audio". If it says this then headers are being added and you should have sound. If it says "Data: non-audio" then no headers are being added to the output (it is in AC3 passthrough mode). To change this flag use the following command: iecset audio 1 You should now have sound. If you still don't have sound then as a last resort open up System->Configuration->Configure Your Desktop and select Sound->Sound System. From here select "Test Sound". If no sound is heard then deselect "Enable the sound system". Press apply and then Reselect "Enable the sound system". Press apply one more time and the select "Test Sound". If you still don't hear anything then something else is wrong and I'm afraid I can't help you any further. Good Luck!

I've been using a Mandriva 2006 64 bit install as my main system for about a year now. There are still a few things you can't find on the 64 bit version (eg. codecs) that would be nice but you can run 32 bit programs as well (or so they say). The installer does get confused sometimes and tries to fill dependencies for x86_64 programs with i586 packages, even though 64 bit ones exist. The linker and makefile system also get confused if your compiling source code and they try to link in 32 bit libraries instead of the 64 bit versions if both exist on the same system. This is especially problematic with a site such as PLF. When installing packages, if such a conflict occurs, you can first install the 64 bit versions of any problem packages and then try again to install the package you originally wanted. As for crashes and things of that nature, I have had no problems. The Nvidia drivers work great. I'm hoping that 2007 will fix some of these issues. Glitz.

Actually, TS in this case stands for Transport Stream. An MPEG TS file is one that combines several video mpeg and audio streams together with time synchronization information. This is the native format of cable and over-the-air HD broadcasts in North America. PES stands for Program Elementary Stream and is usually either a single video stream or a single audio stream. PS stands for Program Stream and may contain one or more PES streams (usually a video stream and its accompanying audio stream). I typically record raw MPEG TS files from over-the-air HD programs to DVD or DVD DL disks and then play them back on my HD TV using Kaffeine. Glitz.

I have been battling with the LILO timestamp mismatch problem for about a week now (LM10.0 on an Epia M10000). I don't know if your problem is the same or not but maybe my experience will help. I have been duplicating disks in an embedded system by booting from /dev/hdd and copying to /dev/hda (for reasons that will not become any clearer right now) and when I have two drives in the system I often get this error. I also get this error when I have two flash disks in the system. This time on /dev/hda and /dev/hdc. However, I never get the problem if one of the two devices is blank. Additionally, when having multiple possible disks to boot from in the system at the same time, the BIOS does not honor the order in which I place the boot devices. In fact, I believe it simply boots off the first partition marked bootable going in the order /dev/hda, /dev/hdb, /dev/hdc, then /dev/hdd. That last bit seemed to be the clue I needed. From what I could tell, it would load the first boot sector off the disk from the proper drive but would not assign that drive to 0x80. This meant that when LILO tried to continue the boot process using BIOS drive 0x80 it would in fact load LILO's second stage boot off of the other disk and hence there is the timestamp mismatch. As far as I can tell, the problem is with the BIOS, but I've found a clever work around. Simply disable all drives in the bios except the boot drive. This way the BIOS has no choice but to keep the drive as 0x80. For linux this is not a problem since it does its own scan during bootup to determine what devices are connected. So far, this works like a charm. In your case, the problem is a little different but probably produces the same result. What partitions do you have marked as bootable in the partition table? I suspect that there may be more than one thus causing the BIOS to load the boot sector from one partition and then assign drive 0x80 to a completely different partition (one with another copy of LILO on it). Then again, I could be completely wrong about your case ;-) But I hope that this might at least provide a clue. Glitz. PS. By the way, if you haven't already guessed, the LILO timestamp error occurs when the first boot sector and the rest of LILO have different timestamps. PPS. I don't know if GRUB used the BIOS to access drives at all. This could explain why it doesn't run into these sorts of problems.

Okay...so explain to me again, how having to pay a large sum of money has any affect on the effectiveness of someone else's methods of copying your technology... Glitz.

Just out of curiosity, if someone develops commercial applications with KBASIC, how is the QT license handled? Just in case anyone actually knows... Glitz.

Sorry, I can't help you but for what it's worth you're experiencing the chicken and egg problem. I installed LM9.2 on a 512MB bootable USB flash drive. The bios loads the boot sector just fine. After that, however, LILO doesn't have USB drivers to access the flash disk (it gets as far as LI). Booting off a hard drive and telling LILO that your system is on a USB key doesn't help either. It manages to load the kernel off the USB key but the kernel drivers for USB access can't be loaded (since they are on the USB drive) so the kernel panics. I've heard of a kernel patch for thiis but I've had no luck locating this. Good luck, Glitz.

It might be worthwhile to just chuck the Dell SB Live! card and purchase a barebones OEM SB live! 5.1 for $35CDN (approx. $25US). I recommend a card with a copyright notice of 2002 or earlier. The 2003 version is not properly recognized in the ALSA version that comes with LM9.2. It may be properly recognized in the ALSA version that comes with LM10.0. Glitz.

Just out of curiosity, does anyone know how this would affect a person who designed their own computer and wrote their own operating system for personal use? Glitz.

Turn based RPG's (eg. Wizardry series), turn based strategy games (eg. Master of Orion series), text adventure games (eg. Zork series, Suspended, Starcross), and old arcade games (eg. Pacman, Puzzle Bobble, Lode Runner). Glitz.

The new GF-FX6800 Ultra with the new NV40 core is coming out in a month or two. The benchmarks show it to be over twice as fast as the GF-FX5600 and the graphics quality is as good as the ATI cards. It may take a little longer for the support to show up in the Linux drivers though. Their other cards should drop in price though. Check out: http://www20.tomshardware.com/graphic/2004...0414/index.html Glitz.

It's been a while since I've had to specifically compile Linksys drivers for Linux (over 4 years) but back then they had instructions on their site for how to compile and install them. I think it took some digging to find them but they were there. I'm sorry I don't have the link bookmarked anymore. Good Luck! Glitz.

Thanks Anon! Now I've finally been able to track down that CRON file that's been taking up over 50MB on my server :D Glitz.

My Linksys 10/100 ethernet cards clearly stated on the box that they worked with Linux. Glitz.

If you are referring to speech recognition software then the only open source one I know of is sphynx. I've never tried it though. Glitz.

I didn't recompile (I still have my previously compiled attempt). When I try to 'make install' the following errors occur: depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7108e.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7111a.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/saa7113h.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tuner.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tvaudio.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tvmixer.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/tw98.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/vpx32xx.o If I then do 'modprobe rivatv' the following errors occur: /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_master_send /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol proc_root_driver /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol __wake_up /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol proc_symlink /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol kernel_flag_cacheline /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol pci_free_consistent /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol create_proc_entry /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_bit_del_bus /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol video_register_device /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol remove_wait_queue /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol video_unregister_device /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_bit_add_bus /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol pci_alloc_consistent /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol remove_proc_entry /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol add_wait_queue /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol i2c_master_recv /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol mem_map /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol irq_stat /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o: unresolved symbol vmalloc_to_page modprobe: insmod /lib/modules/2.4.22-10mdksmp/kernel/drivers/media/video/rivatv.o failed modprobe: insmod rivatv failed Glitz.

I said it would be possible to boot Linux, I didn't claim it would be a luxury liner. Obviously the more assorted the peripherals are, the more boot devices you have to configure into the bios. Adding a bit of code for keyboard input and text screen output is not difficult. Memory management is not a problem since the x86 line of processors boot in real mode. The memory management starts when the second stage or third stage bootloader runs. They can also configure the majority of the hardware or else let the OS do it. If you always have a hard drive available then the code to boot from you're super deluxe widget could be loaded off the hard drive instead of putting it in the bios. Maybe the point I'm trying to get across here is that bios's main purpose is to load in enough code from some larger device so that booting can continue from the code on that device. In this way, the booting process can be customized without relying on any one person's code. As long as the bios can read in a bit of your own code, then you are home free to load any OS you want. Obviously, the bios will have to have the ability to boot from at least one removable device so that a fresh OS can be installed. Again, more supported devices are like car accessories. The technology used to hold the bios is irrelevant. The only criteria is that it can be directly accessed by the CPU at powerup. The LG fiasco had nothing to do with the type of memory used to hold the code. The problem was that the code was buggy. Had the defective code been burned into EPROM then the only difference would have been that it would not have been repairable without physically swapping the chip. But think about the advantage of flash. You could compile a bios like a Linux kernel and configure it to boot from the devices you want. This could then be written to the flash. The small protected boot block of the flash could be used to provide a primitive method of reflashing the device from a floppy drive or CDROM (or some other device on the machine) should the rest of the bios be corrupted or unprogrammed. It seems there are as many ways of starting a computer as there are grains of sand on a beach. There may be one optimal solution but you are unlikely to find it. There are probably a few excelent ways of doing it. There are most likely many ways of doing it well. There are many, many ways of doing it adequately. And there are infinitely more ways of doing it badly. Take your pick. Glitz.

Yes, you do have to have enough code in the bios to be able to read the second stage boot loader off of whatever devices you intend to boot from. However, you don't really need any more than that. In fact, with flash bioses, you could almost customize the bios to boot off of whatever device you install the OS to at the time you install the OS. The OS could install it's own bios. Hmmm, that's an interesting idea... People, however, love to fill programs up with all sorts of eye candy (hardware candy?). At any rate, the point is that in the grand scheme of things, as soon as you have the second stage boot loader loaded, then the bios is no longer required. Or to put it another way, as long as the specs to the hardware are known (and they are) then the bios is not some kind of magic key to the system that one person (company) can control. Mind you, a bios full of "hardware candy" to configure and provide nice standard interfaces to the hardware (for the OS) is nice. It means less hardware driver programming for you. That's what makes it appealing. Linux programmers, however, have so far ignored the bios for the most part. As far as I know, only LILO (maybe GRUB) and the ACPI (and APM) driver uses it. Oh, the bios will also partially configure the PCI cards if you let it (I think Linux can do that by itself now fairly competently). Glitz.

Booting from floppy is virtually identical to booting from a hard disk. You read the second stage boot loader from the boot sector on the disk and that loads in the rest. In fact, that is exactly what happens now when you boot from floppy. As for the virus thing, well, if you put viruses on your MBR or boot sector then what do you expect? The way to prevent viruses from placing themselves there is to make sure the OS doesn't allow them to put themselves there in the first place. Glitz.

Exactly. Send the command over the ATA bus to read the MBR, stick the code in the MBR in the RAM, and branch to it. Instant bios. After that point, the operating system can be in complete control and no more bios calls should be required. Get the ATA spec, write a bit a assembly code and burn it into an EPROM or flash chip. Instant bios. All the rest of the functions normally found in the bios can be part of the OS during or after booting. You just need enough code in the bios in order to read the second stage boot code off the hard drive. After that, it is up to the second stage boot loader to read in the rest. Glitz.

The windows emulators are by no means complete. In theory they should allow any windows program to run on Linux. Unfortunately, the entire win32 API is not yet complete. Glitz.

The Athlon 64 FX and Opterons are both socket940 chips. The Athlon 64 is a socket754 chip. If you really want to buy an AMD system then you might want to check AMD's site for recommended motherboards. Select the chip you are interested in, then select "system component information", and finally (on the right) select "recommended motherboards". AMD also recommends to check the motherboard manufacturer's site to determine what memory has been tested to work with the board. This is very important. Glitz.