blackpage

Gidday SoulNothing Right, I hope I understood you correctly ... if you can mount the drive fine then it is probably a permission issue. One of the few things when not even root can't go into a directory is when the permission of the folder is set to "000", which stands for a clear "Go away!", even for root. To solve this you will need to boot Knoppix, become root (I think you just need to type "su" or "sudo" in Knoppix-console), mount the disk in r/w-mode, and then "chmod" the folders in question. Something like this ... Code: dude@box # chmod ug+rw -R /rootordude@box # chmod 700 -R /root I dunno what happened with your machine but maybe the occasional incantation of a "chown" might be necessary to restore things as they were. hope this helps

Evening pr-man On our boxes I've currently set up Debian, Mandrake and Gentoo mainly. As of today a FC3-box has joined the club and my personal machines are powered by Yoper at the moment. The Debian-boxes are all servers and as far as it goes for hardcore-server stuff (apache 1.3.xx, postgres etc), I would not install any other distro - Debian's just too rock solid. As for the workstations: The mainstream crates (office tasks) are fine off with MDK10, whereas most of the developer-stations dual boot either Gentoo or MDK. The latter ones because MDK blends nicely with VMWare 4 and provides a quite convenient platform for all things that deal with development in general. Gentoo's a sweet distro too, but 3 stage-1 setups per year is just about as much as I'm willing to invest time wise Fedora 3 is now installed too on some boxes, and from what I can see, it's quite a gas. Need to peek into it more thoroughly though. I, personally, have gone from MDK to Yoper now, as I'm doing a lot of 3d-programming/-animating and juggling huge image-files. And for these tasks Yoper provides a much faster platform without the tedious task of setting up a Gentoo-system. Apart from some minor flaws (see also "Menu transparency" Yoper really gets things going. GIMP was up and running via Synaptic in a few minutes and Blender skyrockets as Yoper comes with the proprietary nVidia-drivers right out of the box. So ... I concurr with SoulNothing: Plenty of distros for plenty of uses. And - isn't that a fine thing to have? have a nice day

thanx danleff I've tried out every single effect-setting that is possible but for some reason KDE keeps switching back to transparency with always the same transp. value of "87%". Anyway ... I'll just go with the non-transparent, bitmap-patched version of the themes.

Goodness me, the postings here are replied to faster than on IRC ad xconfig: if you don't have X installed yet, you will have to use "make menuconfig" which is the commandline-version of the kernel-configuration. The grouping of the items and branchings should be fairly the same. good luck

howdy If you have a "linux-2.6.5-1.358"-folder under "/usr/src" then just make a "linux"-symlink to that one, "cd" into it and launch the kernel-configuration (see posting above). Then, choose "File-Load" and load the "config-2.6.5-1.358smp" from "/boot". If no processor type is selected, choose the PII-family (pre Coppermine). Also make sure the following options are checked ... *) Generic x86 support *) Symmetric multiprocessing support And set the the nr of CPUs to "2" (double clicking the item). Still though if you load the smp-config file and none of these are selected or checked then something's wrong with the config, in which case I would not recommend to even make an attempt to compile the kernel (who knows what other options are missing too? If this is indeed the case, you should maybe ask some folks here who actually use FC2 (DepperDan does, as far as I know, and he's quite a knowledgable powerhouse as it goes for FC). In any case do not just "save" the configuration. Either discard the changes if you don't want to compile anyway, or choose "File - Save As" first, and save the configuration under "/boot/custom-config-2.6.5-1.358smp" or whatever. After that you can use "File save", and exit xconfig. From there on it's down to compiling. But please! If you've never done that before, grab a few pages from the internet that describe how a v2.6.x-kernel is compiled and installed. The info according this would by far exceed the limits of a usual forum-posting and still not cover all possibilities (chipset, device-support, filesystem-support etc.)

'lo again That is a bit strange ... if you do actually boot the SMP-kernel and yet the OS does still not recognise the second processor, then something seems to be wrong. It would maybe help if you post what your current kernel-config is. You can get these infos this way ... 1. Install the kernel-sources ... of the kernel you are using (should be "kernel v2.6.x") 2. cd to /usr/src/linux In case you don't have "/usr/src/linux" but something like this: "/usr/src/linux-2.6.x" you need to make a symlink under /usr/src first ("user@machine /usr/src: ln -s linux-2.6.x linux") 3. Launch kernel-configuration ... by typing "make xconfig" 4. Load your current configuration-file ... which is usually located in /boot and should be named (in your case) something like "config-2.6.x-smp". This will ensure the settings as used for the SMP-kernel will be displayed in xconfig. Now check under "Processor type and family" what family is selected. The Proliant is from 1999 or so and according to google it uses P2 or P3-cpus. So in your case it should be either the general "586/K5/5x86/6x86/6x86MX", "Pentium II/Celeron (pre Coppermine)", or "Pentium III/Celeron (Coppermine)/Pentium III Xeon"-family. Keep us informed

Greetings RichardLOZ You can tell whether your box is running in dual-CPU-mode in a couple of ways. Here are the two most common indicators: During boot-up sequence In case you are booting in a VESA-mode you should see some sort of logo in th upper left corner of the screen. Most distros use this space to indicate the number of found CPUs. That means: 1 logo = 1 CPU found, 2 logos = 2 CPUs found. On the shell In case FC2 doesn't show any logos, just boot the OS, launch a console and type ps fax. This should deliver an output similar to this (without the dots): Code: PID TTY .... STAT . TIME COMMAND..1 ? ...... S .... 0:01 init [5]..2 ? ...... S .... 0:00 [migration/0]..3 ? ...... SN ... 0:00 [b][ksoftirqd/0][/b]..3 ? ...... SN ... 0:00 [b][ksoftirqd/1][/b] If you only see the "ksoftirqd/0"-entry, the OS only utilizes 1 CPU. If you have both ksoftirqd-entries, then you're using both processors. Some distros also come with "custom-kernels" that have SMP-support (Symmetric Multi Processing) already compiled in. Dunny if FC2 does likewise. If you don't hae an SMP-enabled kernel, you just have to build one. D/L or install the kernel-sources, cd to /usr/src/linux and type make xconfig of make menuconfig. You'll find the SMP-options under "Processor type and features". Hope that helps

shoot! double-threads be gone! not going to paste the reply here too .. just distill the info there ... configuration prob #2

Howdy rubel What CPU you might be better off depends on what you plan to do with your box. Semprons are the "castrated" version AMDs regular desktop-CPUs which means their cache size is reduced. As a general formula you can say that the larger the caches are, the better the processor performs. If you plan to only do word-processing, a bit of OO-calc and the like, you will be fine with a Sempron. If you plan to play games or do something that requires CPU-power (GIMP-filters, audio-processing, and everything that is "3D", like Blender) then the Sempron is a lame duck. In more detail ... XP vs. SEMPRON In your case we have the following situation: Cache size Though the cache on the Sempron 2200 you suggest is reduced, it is still just as large as the cache on the (very) old Athlon XP 2200+. Both models are in access of 256kB secondary cache. So in this discipline botch CPUs score likewise. CPU core As I said, the Athlon 2200+ is quite an old piece of technology that - these days - comes in two versions: one with the "Thorton"-core and one with the "Thoroughbred A"-core. The Sempron 2200 has the newer "Thoroughbred-B"-core. A clear plus for the Sempron. Front Side Bus (FSB) The XP 2200 is only capable of running with an FSB of 133MHz (this is the frequency the motherboard applies to the CPU; as the data-transfers between bus and CPU run in "double data rate"-mode the FSB speed is normally doubled for marketing reasons. In our case the FSB would be specified as "266MHz"). The Sempron 2200 is capable of running at 166MHz ("333"MHz) which is consequently a lot faster. In this round the Sempron again outscores the XP2200+ again. Motherboard <-> CPU interlink The mobo you name has the old KT400 chipset and is therefore from a "different era" when "Sempron" probably wasn't even registered as trademark. Though the Sempron hasn't any one of the newer AMD technologies (as AMD has disabled or left out all the fancy things like on-chip-memory controller or HyperTransport), I would not swear that the KT400 and a Sempron work together in an optimal way. Though chances ain't bad they actually do. Summary The XP2200+ is not to be considered "contemporary" anymore. It's a reliable, but old cpu that misses quite some features and processing power. The Sempron is a new CPU, but still, the lack of good cache-sizes reduces the spectrum of tasks it can do well quite significantly. My suggestion If it's anyhow possible, get yourself at least a modern processor and maybe a modern mobo too. If you want a real "powerhouse", I'd recommend the Athlon XP3000+ with "Barton" core which has twice as much cache (512kB) as the Sempron, runs at up to 200MHz ("400"MHz) FSB and computes circles around any Sempron. Disadvantage: more expensive (~$130). If you are lucky (you need to check that) you can still use this CPU in your KT400-mobo if you choose the 166/333FSB-version of the XP3000. hope that sorted a few things out

'lo again Quote: Does any option that you've mentioned above have debug tools(like watch, breakpoints and so on, like the turbo pascal or borland pascal for windows have)? Yessiree, the Lazarus IDE comes with a more or less full blown set of debugging tools like "local variables", "call stack" and whatnot. Check out this screenshot here ... Lazarus at work Looks like the Lazarus-project has evolved to a point that I should check it out again

gidday As a hardcore pascal-coder from the very early TurboPascal- to the most recent Delphi-times, I'm sorry to inform you that you won't get something as "spiff" as Delphi for the *ix-platforms. The only solution that I know of, and which "works to some extent" is the Lazarus Project which you can find at >> http://www.lazarus.freepascal.org Lazarus is a quite nice attempt to bring a RAD-IDE a la Delphi to Linux, still though, it's based on the FreePascal-compiler. That, of course, means that you have to download the FP-compiler, the Lazarus-IDE and maybe some other modules. I've tested Lazarus (quite some time ago) under RedHat 7something, I think) and if you stick to somewhat standard-components like edit-boxes, combos, treeviews and the like you can stitch together GUI-apps quite comfortably. One question remains, though, and that is "installation". I have no clue if the Lazarus-RPM can smoothly be integrated into MDK, so, you will have to do a little "try and error" regarding that matter. The other solution would be of commercial status, comes from Borland, and is called "Kylix". Kylix was once advertised as _the_ RAD-IDE for the major OS, but truth revealed it was more of a "rapid pain in the a**". Installation issues on *ix-flavours aside from RedHat, imcompatibilites everywhere and IDE and apps crashing for no apparent reason have been commonplace up to the most recent versions that I have tested (v3something, I think). My advice: If it has to be Pascal, check out the Lazarus-thingie, as it's free and quite well documented. Another option would be to go with some languages that *ix-OS' have been made of, to wit: C or C++ (C#). For those you get a fancy IDE (KDevelop e.g.) with all the tools a developer could hope for (CVS, diff etc.). Or you might give the Eclipse-IDE a try and divert into Java for total platform-independancy. If neither C nor Java are valid options, just dismiss the last lines hope that helps

Gidday Whiskers Since I prefer to set up firewall-rules by poking the necessary stuff into iptables, I'm not too sure how shorewall handles things. But it should be generally along the same patterns. Here's what to check ... Option 1: Unrestricted LAN-access If you don't have security concerns for you rlinux box you might as well allow the complete traffic to/from your box by generally assigning a "PERMIT" to the LAN-IP-range. Those are typically in the "192.164.0.0"- the "10.0.0.0"-ranges. Just check what IPs your boxes are assigned. Option 2: Fine-granulated access For this, not only the IP of the LAN-workstation you want to grant or deny access is relevant, but also the ports. For normal LAN operations you should at least allow traffic on the "typical Microsnot"-ports, as there are: 137, 139 and 445 (all TCP + UDP). Regarding whether or not the above ports are used as "DESTINATION" or "SOURCE"-ports it may also be necessary to grant access on all ports higher than "1024". For more info you might want to check this link Shorewall-Samba quick-info Hope that helps

A good day good ladies and gents Roaming around the Redhat site I found this ... http://www.redhat.com/security/ Looks like some low down lifeforms have prepared an SSH-backdoor disguised as a "RedHat security update". As I know that a couple of folks here are running RH/Fedora and may therefore be on some mail lists regarding these OS', making them possible targets for those mails, I thought I'd just throw in that bit of news. have a nice day

evening together I'm running a couple of SanDisk sticks under MDK10, even though I cannot really call my MDK-setup "out of the box". As danleff said, MDK does a whole lot with supermount, and as far as I can recall the sticks wouldn't work properly on my machines at first either. Here's what I have now: 1. /etc/fstab/entry ... Code: /dev/sda1 /mnt/usb vfat umask=0,user,noauto,sync 0 0 Add such a line to your /etc/fstab file and adapt the umask-settings to your liking. But you should keep the "sync" option for USB-devices. 2. USB-modules Contrary to the otherwisely excelent USB-tutorial that DapperDan pointed to, MDK10 here never seemed to really like the described procedure. So here's what I did ... a) lsmod for "usb-storage" On the console do a "lsmod" and check if "usb-storage" gets listed. If it doesn't, fire a "modprobe usb-storage" a) lsmod for "usb-ohci" As above check for the availability of usb-ohci (not usb-uhci as described in the article). If both modules are loaded you can then mount the stick via a simple ... Code: mount /mnt/usb (or whatever path you have used in /etc/fstab) What could happen? If all goes well you will have your stick mounted and ready for access in whatever way. As it seems that you are running the original MDK-kernel a couple of other things might occur too. This is the major reason why I don't use MDK's "do it all on my own plus supermounting and patched to no end"-kernel. Such "omnipotent" kernels might be of help for a task or another but in the end they just limit you due to their non-standardness. All the MDK10-boxes here run a straightforward 2.6.8 kernel, directly from kernel.org, and with those, all I have to do for the SanDisks is Code: modprobe usb-storagemodprobe usb-ohcimount /mnt/usb Pity that I never had the time to work out something that works well with the patched MDK-kernel. On the other hand: I hate automounting/autostarting stuff anyway, and so I prefer the "manual solution" as I have it now anyway. Nevertheless, I hope that this at least sheds bits of light here and there cu

howdy kobedf Sound setup can generally be tricky at times. First off: are you using the ALSA-drivers that are included in the kernel, or did you d/l the sources from the ALSA-site, or did you do some APT/DSELECT-thing? If you have installed ALSA via "dselect" or "apt-get" I can't tell you much as I don't use those tools too much as they never gave me a single software-piece without a thorough headache, but that's a different story. In case it's the kernel-version, make sure you have "Alsa"-support checked and also check if you have included support for the respective sound-chip of your mobo. More info about the HW would be necessary at this point to tell you something more specific (mobo-vendor/type, soundchip). It's also possible that the support for ALSA is already there and the module just doesn't get loaded. I did all my ALSA installs by compiling the sources from the ALSA-site. For this you need to make sure that you only have soundcard-support enabled in the kernel-config. The ALSA-driver then does the rest. The "./configure"-run can take heaps of parameters, so I recommend to do something like "./configure --help > alsa_options.txt" first. This creates the above textfile with infos about what you exactly can pass to "confgure" as parameters. Take a thorough look at those and pick the options you need to pass to "configure". This should look something like ... # ./configure --with-cards=emu10k1 --with-sequencer=yes [and so on] You will find plenty of info about supported chips and cards plus many installation docs on ... > http://www.alsa-project.org/alsa-doc/ Lil tip: If you ever plan to give Doom3/Linux a go, also activate the otherwisely deprecated OSS, as this is the only sound-system Doom3 supports (haven't tested if it would also run without OSS as I have OSS installed anyway for some sound-apps) hope that helps

greetings tomyalarie Right away: Can't tell you much about those deb-packages but I've installed the NVIDIA drivers from source quite some times by now and so I also encountered situations where the sources would not compile. In all of these cases I just did a compilation of the kernel to make sure all the stuff that the NVIDIA-drivers would need to know about are in place (it's mostly some "kernel<->driver"-interface thingies that get generated in /usr/lib [and who knows where else] upon kernel-compilation. After that the NVIDIA-drivers always compiled like a breezw on many distros that I tested so far (including Debian). Hope that helps

evening atcskyfox That sounds as if you're dealing with a rather old mobo there. From what I recall "PnP" in those days was more some sort of "gambling" than it actually was a reliable motherboard feature that helped during OS installation. If the BIOS version you flashed doesn't contain a cruical bug-fix you defnitely need to get the mobo running, then I'd recommend you'd just go back to previous BIOS version and try to make one of the OS' install on top of those. But before you do that you might want to flash the BIOS again. It's generally a good idea with those old EEPROM-chips to repeat the flashing 3 to 5 times (also make sure the respective FLASH-jumpers on the mobo are set properly while you are flashing; don't forget to reset those jumpers _after_ the flashing). keep us informed

hi egorgry Nice link that, and from a fellow Austrian too Those "funky" patterns should help me keep the budget for psychodelic drugs low from now on have a nice day

howdy zero0w what can I say, apart from "whoa! just what I need!". At the mo I'm doing a rewrite of a very, very old application that was based upon DOS 6.22 and EMM386.EXE (THE HORROR! So a million thanks to you, dude/dudette (dunno), as this will greatly aid me in my "time-travelling" task, back to the shores of "himem.sys" and "smartdrv" as the techniques described should give me a "DOS"-box quickly on any of the dev-machines via the USB-devices, thanx! (I'm already curious what the DOS network layer has to say to the on-board gigabit-NICs, tee-hee)

greets kosu I'll start off with the "HDD-aspects" of mounting if it's all the same to you. I'm not using Fedora, but I'm pretty sure it comes with something that one could call a "control center". In there you should find some graphical mount-tool that lets you "glue" your fat32-partitions to proper mount-points under your *ix-file system. Just in case you can't find something like a "control center", here are a few tips on "how to do it the real way" The first thing, of course, is to know ... 1. Where To Add Permanent Mounts The right place to include hdd-partitions into the *ix-file structure is the file /etc/fstab. So we definitely have to open and edit this file ... Command: Code: username@machine: emacs /etc/fstab (or any other editor that floats your boat) 2. Assigning Devices To Mount-Points To successfully add your fat32-partitions to /etc/fstab you need to know 2 things: A) what logical drives are the fat partitions on the latter mount-point Ad A: most *ix-flavours refer to partitions in this way ... 1st partition on the drive that is set to "Master" on the Primary IDE-controller is /dev/hda1, the 2nd partiton would be /dev/hda2, and so on. So if your "C:\"-drive is the first partition on your primary master disk "/dev/hda1" would be the linux-device for it. Ad B: that's even simpler, cause the mount-points are just the names of directories that you plan to mount your partitions under. A good choice in your case would be e.g. /mnt/c_fat32/ or just /mnt/c. And here are the lines you would need to add to your fat32-partitions to /etc/fstab (assuming they are the first partitions on your primary and secondary master drives): Code: /dev/hda1 /mnt/c vfat user,rw,exec 0 0/dev/hdb1 /mnt/d vfat user,rw,exec 0 0 You already know about the first two parameters. The 3rd one tells linux of what type the partition is ("vfat" e.g. means "fat32"). The the 4th parameter block (user,exec ...) tells linux about the restrictions you want to apply to the partition. And the final 2 parameters set up some sort of "error-handling" and are used (at boottime) for the "dump" and "fsck"-commands. For fat32 partitions keep those set to zero. Last thing to do in the editor is to save the changes. 3. Creating The Mount-Point Directories All that's left is to create the directories you referred to in /etc/fstab. This is quickly accomplished by Code: username@machine: mkdir /mnt/cusername@machine: mkdir /mnt/d ... or whatever you used in fstab. 4. Try It Out Fire up a shell and issue the command ... Code: mount /mnt/c If you get no error messages you can browse your fat-drive with "ls /mnt/c" e.g. That's the basics for mounting IDE-harddisks. If your fat32-partitons are on SCSI- or SATA-drives the respective linux device names would be something like "/dev/sd<xy>". And in case you actually want to mount USB-stuff, then some prerequisites might be necessary (like loading modules "usb-storage" or "usb-ohci"). But for that you'd need to provide some more infos. As a failsafe, in case anything goes wrong, check out these ... http://www.die.net/doc/linux/man/man8/mount.8.html http://www.die.net/doc/linux/man/man5/fstab.5.html (some nicely displayed man pages on the web) Hope that helps

howdy JDBurnZ @flash-sites under non-Win-OS' though Macromedia has managed to produce some flashplayer-versions over the years that are somewhat "compatible" across the OS', there are still some exquisite differences. Most of all: the non-Windows-versions of the player don't support "transparent" movie clips. That issue is as old as the average politician's lie, and Macromedia hasn't bothered over years to tackle it once and for all; see also: "Oh, sweet and powerful SVG-killer-app. Why dothest thou not cometh to me rescue?" (obviously I've been playing too much Thief III lately I have only been to the Doom3 site under Linux for a brief moment, but what I have seen from the corner of my "developers" eyes it looked as if they've been using some transparency. have a nice day

gidday SoulNOTHING At the office we drive quite a few old crates based on the 440-chipset (mostly some ASUS p2b-series, mostly duals) and some of these otherwisely reliable boards showed indeed issues during the installation (wouldn't boot at all or stalled during installation) of Linux (MDK, Debian and Gentoo). One set of mobos could finally be convinced to successfully install Linux by turning off on-board devices (though none of our boards had sound, but they all have Adaptec SCSI-U2W-controllers), other boards - and I know this really sounds funny - just required a different CD-ROM-drive. I call that "funny" cause after the installations we tried the refused CD-drives and they were fully functional once the OS was installed. So I would definitely agree with you when you suggest to try other drives, and I'd also suggest to remove any cards and turn off anything "on-board" that is not required for installation. Please, keep us informed in case you arrive at some fix, cause I don't plan to let go our old boxes (as they make fantastic servers) and I wouldn't want to stumble into something similar whilst upgrading an OS or something. have a nice day

'lo InHuM@N It was in fact a Radeon 9600pro that braught me to linuxcompatible.org in the first place, and therefore I'm almost a bit grateful towards ATI that they produce gfx-cards that don't integrate into Linux all too easily as I wouldn't want to miss this incredibly helpful forum anymore Anyway ... a couple of threads here deal with Radeon-installation, amongst those you will also find this one (*** SMUG-MODE: ON *** ... http://www.linuxcompatible.org/thread26946-1.html Check it out, maybe it's what you've been looking for. In all cases I'd suggest to try an "lsmod"-command from the shell to see if your AGP- and GFX-drivers/modules are loaded properly. hope this helps

howdy anthonyi I'm not using Fedora but I suppose we all have seen i386-packages - regardless of the distro. As I personally "live by" the compiler I have never asked myself this question, as nearly all software packages that I use get custom-built anyway. But as a quickshot, I'd just say the i386-compilations are the most common denominators, in other words: the "size that probably fits (almost) all machines" regardless of SSE, SSE2, 3dNow, HyperThreading and what-not-else. You are quite right, when you think that you can gain quite some performance by using packages that are compiled with some sturdy optimizations (I still can remember my jawbone going down, watching a P3/400 under KDE after a Gentoo stage-1 installation with heavy optimization that took 3 days but performed mindbogglingly well). Despite that: higher optimization also means reduced compatibility. So it would not make much sense to install a i686-compiled package when you want to run the content on a i386-based machine. That's what source packages are for in Linux. Moreover: profiling an average machine would show something like this ... Code: wasted runtime ...=> due to non-optimized code: 0.00003141592%=> waiting on some friggin user-input: 99.99996858408% As you can see: As long as we humans take our sweet time, the vast majority of the users will be quite happy even with i386-compiled packages - and the speed-hungry? Well, those just grab the src-archive and GCC 3.4, crank up the "-O" parameter and have lift-off a couple of days later have a nice day ps: and if you are now asking yourself "but then why is blackpage compiling every package?" - well: because I'm a geeky nerd, what did you think? // edited as typing capabilities have gone temporarily berserk [Edited by blackpage on 2004-09-09 15:33:54]

howdy mdlc Two things spring to mind. The first is of cosmetic nature: you seem to have given your box the name "localhost" or the installer has picked this as default as you have not explicetly set another name. As "localhost" in network-terms is a synonym for the IP addie "127.0.0.1" it is maybe a good idea to change that at some point in the near future to keep things nice and easy. Secondly: Obviously a login is presented to you. To track down the error, log into your machine as user "root" (followed by entering the right password). Then start the GUI by typing "startx" and maybe post whatever you get in response here (mabye somethings like "no screens found", or any form of "permission denied"-messages). Generally speaking: Many "mobile" notebook-gfx cards seem to be made of gremlins rather than transistors as their major intent seems to be to pull the jolly linux-user's nerves by making a lot ado and fuss. So give it a go by manually launching "X" via the "startx"-command and let us know what your fancy LCD spews out. good luck