Re: [Cooker] 7.0beta - oxygen
Will Oxygen be 2.3 or 2.2 based? Oxygen is 2.2 based, 2.3 are development kernels and should not be used in production environment, however you are free, AT YOUR OWN RISKS, to install the hackkernel packages which provides development version of the linux kernel. -- Warly
Re: [Cooker] 7.0beta - oxygen
Florent Villard [EMAIL PROTECTED] writes: Oxygen is 2.2 based, 2.3 are development kernels and should not be used in production environment, however you are free, AT YOUR OWN RISKS, to install the hackkernel packages which provides development version of the linux kernel. On what version is actually based hackkernel ? The last stable :) version is 2.3.30 cos 31, 32 33 and 34 are not stable enought. I'm just compiling 2.3.35pre1 that may replace 2.3.30 as we are now nearly in pre2.4 and that all remaining bugs are getting corrected 2.3.30/31 are *extremly* instable... ( thing like process not killable, lock problem ). I'm using 2.3.34, it seem to be stable, on my home system ( except the video4linux bttv stuff ). -- -- Yoann, http://www.security-addict.org It is well known that M$ products don't call free() after a malloc(). The Unix community wish them good luck for their future developments.
Re: [Cooker] 7.0beta - oxygen
On 22 Dec 1999, Vandoorselaere Yoann wrote: Florent Villard [EMAIL PROTECTED] writes: Will Oxygen be 2.3 or 2.2 based? Oxygen is 2.2 based, 2.3 are development kernels and should not be used in production environment, however you are free, AT YOUR OWN RISKS, to install the hackkernel packages which provides development version of the linux kernel. On what version is actually based hackkernel ? 2.3.30-preXX right now I think, but it will be updated fairly regularly. 2.3.35-preXX has some fixes in it, as well as a lot of new K00L code. :) Jeff
[Cooker] Testing Beta
Hi I'd like to test the beta, but I can't find an iso image, which would make downloading 7.0 a lot easier. Can youhelp? Thanks. Ron Rosenthal [EMAIL PROTECTED]
[Cooker] Mandrake 7.0
What improvement 7.0 will have against 6.1 if even major version is incremented? Mindaugas
Re: [Cooker] Mandrake 7.0
On Wed, 22 Dec 1999, Mindaugas Riauba wrote: What improvement 7.0 will have against 6.1 if even major version is incremented? The Web site has a feature list. Over and above that, Mandrake 7.0 features upgrades of your favorite packages, which include tons of new features and bug fixes. Too many to list, in fact :)
[Cooker] [cooker] GRUB rpm
If anyone is interested, I built a rpm for grub 0.5.93.1 (on a redhat 6.0 box, but it works fine on an helios box). Just tell me where to upload it. It just contains the files, no automatic configuration. Read /usr/doc/grub../grub.ps Bruno
[Cooker] New auto boot
Ok i've updated the autoboot that hasn't been touched sense cooker started (ok almost) Nothing to major, updated initrd and vmlinuz for all the install methods try a little harder to backup and keep a orignal autoexec.bat and config.sys (still recommend putting them on floppy) add an Uninstall.bat to restore the autoexec.bat and config.sys Should be finished uploading here in about 10-15mins, it's avalable from the usual place (ftp://ftp.mandrakesoft.com/pub/axalon/autoboot) -- MandrakeSoft http://www.mandrakesoft.com/ --Axalon
[Cooker] iso?
I'd like to beta test, but can't find an iso image. Is there one? Download NeoPlanet at http://www.neoplanet.com
[Cooker] slightly off topic: Where is the rest of C++???
I just tried updating LyX to 1.1.3 from a copy in the contrib directory and was greeted with a dependency on the strangely named libstd++libc2.1-1.so or some such obscurity; I fetched the sources from lyx.org, but this was greeted with unresolved includes for the standard C++ includes (iostreams or ostreams, vector etc); a scan of my drive confirms these files are nowhere to be found and a scan of all the pgcc... rpms shows very few C++ includes. What packages am I missing here? -- Gary Lawrence Murphy [EMAIL PROTECTED] TeleDynamics Communications Inc Business Telecom Services : Internet Consulting : http://www.teledyn.com Linux/GNU Education Group: http://www.egroups.com/group/linux-education/ "Computers are useless. They can only give you answers."(Pablo Picasso)
Re: [Cooker] slightly off topic: Where is the rest of C++???
Oops ... never mind --- I don't know why stdc++-devel was missed, but now that I have it, all is well again :) -- Gary Lawrence Murphy [EMAIL PROTECTED] TeleDynamics Communications Inc Business Telecom Services : Internet Consulting : http://www.teledyn.com Linux/GNU Education Group: http://www.egroups.com/group/linux-education/ "Computers are useless. They can only give you answers."(Pablo Picasso)
Re: [Cooker] Mandrake's only mistake
Redhat does the same thing. Plus you would loose the nice desktop settings that mandrake is known for. On Thu, 23 Dec 1999, you wrote: Why dont you do it yourself? Borrow RH's KDE RPMS and install them? It cant be too hard. Also theres no reason to complain just because there not in the directory where *YOU* want them. Happy Holidays, Sam
Re: [Cooker] 7.0beta - oxygen
Chmouel Boudjnah wrote: Alwyn Schoeman [EMAIL PROTECTED] writes: Is this just a name change? If so WHY? not just a name change, a complete rebuild and a roughly tested tree. --Chmouel Ok, but will cooker stay where it is on the mirrors? -- ~~ Alwyn Schoeman Systems Engineer Prism Secure Solutions
Re: [Cooker] On /usr/bin
Traditionally, we have two traditions, one based in ATT and the other based in BSD. I've long ago forgotten which is which. The rational for Unix path assignments was quite logical /usr probably never meant "user" but "unix system resources" or some such. /usr was the basic Unix with /lib, /bin and /sbin taking more primitive roles as the bootloader, recovery disk, command monitor or other low-level sysadmin-eyes-only toolkit. sbin meant "static binary" not "system binary" and should only include programs statically linked as insurance against dynamic linker emergencies. /usr/bin, /usr/sbin, /usr/share, /usr/lib were for Unix distribution files, ie, those packages shipped by the O/S vendor. Therefore RH is historically justified in placing KDE in there because it is included in their RH disks. When you do your backups, you should not need to include these directories (because you have them all on CD anyway) and when you upgrade, only these directories are affected. FSF (I believe) first started the tradition of offering their GNU packages based at /opt although this may have been a Sun convention for any extra packages added by the system administrator for access by all users. We would use /opt for packages we were unrelated to the distro, as a means to keep them out of the way of official package upgrades. /opt is, not surprisingly, "optional" and all items in there come from other sources. If you call your vendor tech support about /opt packages, they politely hang up on you. Thus, KDE is perfectly right to place their RPMs in here because their RPMs come from KDE.org, not from your O/S vendor. Not everone knew about /opt, and prior to Richard Stallman, most 3rd party software (who is the 2nd party?) was placed into /usr/local to make it easy to commit to tape backup. Thus does Apache today install itself to /usr/local as does most experimental beta and alpha software. /usr/local, back when people were honest, decent folk, traditionally had open or group-write permissions (or at least /usr/local/share). If I found some program for my team and we thought others might want to use it, we would place it into /usr/local, most often without bothering the system admins. /usr/local meant "caveat emptor: buyer beware", "ops does not support this" and no guarantees were given or expected. This was typically unprofessionally installed and unsanctioned skunkworks software, and thus, even in modern Linux, the root account, by default, does not include /usr/local for fear of it containing trojan-horses masking out important commands. Most often, users had /usr/local/bin and /usr/local/lib ahead of the system paths so the administrator could create wrappers around apps that may need more protections before the unwashed masses could use it. Today this custom persists in the Netscape shell script that checks for a running process before it launches a new browser window (although RH puts this script into /usr/bin) As time went on and backup methods matured, /var was added to move out all those files considered too volatile to be usefully added to a tar archive, and /home was added to allow sharing personal files across many machines so you would log in to your own one set of files regardless which terminal or server you approached. Similarly, we added /export for non-sensitive material that could be offered for varying degrees of NFS access. Alas, the world is a different place today, our civilization is going to ruin, the young people have no respect for their elders and they spend all their days in the pubs (actually, that statement is a quote, inscribed thousands of years ago on the walls of the Great Pyramid of Giza ;) and all our best intended conventions have been cast aside on whims of fancy. -- Gary Lawrence Murphy [EMAIL PROTECTED] TeleDynamics Communications Inc Business Telecom Services : Internet Consulting : http://www.teledyn.com Linux/GNU Education Group: http://www.egroups.com/group/linux-education/ "Computers are useless. They can only give you answers."(Pablo Picasso)
