arlen
-
Posts
17 -
Joined
-
Last visited
arlen's Achievements
New Here (1/7)
0
Reputation
-
Loaded Wine. it worked OK but there was a problem with one of the pieces of Win software I was running, so I upgraded to the latest version. Everything worked well, until suddenly all the fonts went bad. I tried removing it completely and reinstalling, with no luck at all. Any ideas how I can get the fonts back? [moved from Software by spinynorman]
-
Looking for software that can easily do full and incremental backups to a DVD-RW drive. Any suggestions?
-
I can use alsaconf to configure the card and everything works fine until the next boot. Then I get an error message on startup, and I have to rerun alsalconf to set up the card again. What's going on here?
-
It'll cause problems any way you look at it. If WinIE doesn't see a DOCTYPE as the very first line in the file, it lapses into "quirks" mode, and you'll have a hard time making it look the same across browsers. Leave it out and with a good DOCTYPE WinIE will go into standards mode, and you'll have more luck getting the page to look good. problem #2...this: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> makes the page look wrong perhaps i'm not being standards compliant *runs off to check* alright, there's way too many errors here. using that doctype, it doesn't like a whole list of attributes i'm using that are necessary for the page to look how it does... The easy answer is that the attributes aren't necessary. You just think they are. It's not that hard to make a page look good across browsers without using tables, and the pages end up lighter and easier to maintain as well. All it takes is thought. But since you're going to continue using those attributes, why use a DOCTYPE that doesn't allow them? Drop back to HTML 4.01 or something if you really want to build the page that way. Don't just drop a DOCTYPE in the file because it's cute; the DOCTYPE should reflect the version of (X)HTML you're using on the page.
-
Yes, an HP. I've a monologue over in the hardware section to back that up: http://www.mandrakeusers.org/index.php?showtopic=16276 I've a Belkin card with the same chipset. I'd been tearing myhair out because the Belkin drivers weren't working, then I found another set of drivers over on the HP/Compaq site (same name and same byte count) and when I used them, all my troubles went away. It should be easier than this, though.
-
You pointed out the driver I needed, and everything else eventually flowed from there, so thanks. But it's not a Mandrake Wizard thing that wiped my module config. it happened when the alsa config thingummy got petulant after I said it couldn't write to the file. It appears that it pulled some default config out of a bodily orifice and plastered it in place of the one I had, probably in some sort of a half-baked attempt at an "undo". (Oops, he said don't write it after all!) At least it only fried *that* file, so the ifcfg-wlan0 and other assorted files associated with the wireless card were still there. All I had to do was check that everything was still working through iwconfig and then restitch a new config file.
-
C2 Orange Book or C2 Red Book? Orange is relatively simple. Red Book is harder. In both cases I question its utility. They belong to a bygone era, when changes in the industry happened over the course of decades, not minutes. C2 certification is for a specific hardware and software configuration; deviate one bit and the cert is invalid. Apply the kernel patch which covers the cracker exploit just recently discovered, and the cert is no longer valid (I'm not aware of a single example of a bug found during certification, though the fact that NT4 received the cert should be ample evidence that bugs have passed through unnoticed). The testing sequence is long; if you wait for the patch to be tested and certified before you apply it, you're toast. If you apply it, you're protected, but no longer certified. (Yes, that's a catch-22; it's also the truth. When I was in the service, we had to get both facilities and security to sign off on the disposition of disc storage. But we couldn't dispose of it until facilities signed off, and they wouldn't sign off until security signed off, and security wouldn't sign off until the storage was disposed. It's the way life in the DoD works.) Bottom line: C2 is minimally secure, but add a peripheral or a s/w patch, and you have to go through the testing process again, so it's of little practical value. Novell went for it, so MS felt they had to, now RH seems to be joining the game. It's a waste of time and money, but it gives you another set of letters to add to the marketing pitch.
-
Now that was interesting. Downloaded the file tyme pointed to and built the drivers. MCC still couldn't recognize the card or load the drivers, but I've grown less trusting of it lately, so I started looking elsewhere. And progress was made. After following the instructions in the readme file (following instructions -- imagine that, what a novel concept) there was still no sound coming from the speakers, even after starting soundcore. So I ran the alsa configuration utility, and the only card it wanted to install was an ATI card, not a RealTek one. (Yes, I know, bear with me for there's a point to be had by the time I digress again.) So, when it asked if I wanted it to modify the module config file, I chickened out and said no. So, since I didn't want to let it have its fun with the config file, it took revenge by completely wiping out my wireless networking setup. <sigh> After rebuilding the actual config file I wanted, instead of what it insisted I should have, and getting my network access back (Digression: Linux builders seem to hate it when you add something. I've had to manually re-add the wireless networking parameters so often this week that I have the 128-bit hex access key memorized!) I went back and looked up the system specs: my chipset is RealTek, true, but it's part of an ATI system, so the ATI IXP alsa had offered up was the right choice after all. I went back and added it, this time telling it to go ahead and write the configuration (and crossing my fingers that I'd still have the network when it finished -- wonders never cease, I did). It said to unmute the card with a mixer, but of course Kmixer proved incapable of doing this, so after digging around through the system for a while I found alsamixer, and, after some trial and error, got the correct sound channels unmuted. (Along the way getting treated to a nice loud burst of static. as a consequence of unmuting a channel I guess I shouldn't oughtta unmuted, so I remuted it.) Thanks for the pointer, and, to make a long story short (too late) it's now working fine.
-
Ooops. Turns out MCC was just too stupid to configure the printer properly, even if it could find and recognize it. I bypassed MCC and went straight to CUPS (http://localhost:631/admin) and fixed that, and now everything's fine. Lesson learned: MCC is like a trade show Booth Babe (or Booth Beef, depending upon your preference). Easy on the eyes and nice to have around, but not to be counted on to get the technical details right.
-
I have a RealTek 650 sound system in the PC, but Mdk 10 doesn't recognize it, and the configuration tool doesn't seem to help.
-
Mdk 10 won't print to my Lexmark X73 printer. It recognizes it, claims to be installing the drivers for it, but when it tries to print a test page, nothing happens.
-
Murphy's law. After I posted I picked up another set of drivers for the Broadcom chipset that's in the Belkin card from: ftp://ftp.compaq.com/pub/softpaq/sp23001-23500/SP23067.exe Then I uninstalled the Belkin drivers and installed the newly acquired ones, and all works. The Compaq download is a self-extracting installer, so you'll need to d/l them, get them to a Winbox and run it. Tell it to extract the files to a known location, then quit the installer and get the files over to your Linux box. The other thing I did was to install the pciutils rpm, to get the real lspci, and not lspcidrake. Then simply follow the instructions in the ndiswrapper installer doc, and it works.
-
Further note: located a real lspci, and went back to square one (again). Now everything works fine up to the "modprobe ndiswrapper" step, then the lockup occurs.
-
Thanks a bunch. While I've been coding for decades, I've never had the time to more than just play around with Linux until now, so I'm not sure where to find some things. At the moment, I'm beating my head against the wall trying to get a cheap wireless card to work. I've heard nebulous rumors about it working for some people, but they all have conflicting stories about how they did it, and I begin to suspect none of them did it on Mandrake. (for example, it uses a switch on lspci that the version off the Mdk10 discs says is an invalid option.) Ah, well, if it were easy, anyone could do it, right?