Re: [Cooker] Suggestion for Frozen Bubble
Greg Meyer [EMAIL PROTECTED] writes: This may not be the place, but since this is a Mandrake associated program, I thought it might be. I spent awhile playing Frozen Bubble tonight. It is very addicting. Anyway, I was think that it would be interesting to not just know how many levels I completed, but also how many shots it took me to get there. If my wife and I have both made it through level 33, we have tied for the high score, but if I can get through level 33 with 10 fewer shots than she does, that means I win, Right? :-) Yeah why not. Though if I really get time to spend on it I'll consider merging network stuff. Or is the time it takes to get there supposed to be the tiebreaker? I've used the time, yes. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Suggestion for Frozen Bubble
Ainsi parlait Guillaume Cottenceau : Yeah why not. Though if I really get time to spend on it I'll consider merging network stuff. [+] -- You know how most packages say Open here -- Why Why Why n°50
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
Claudio wrote: Hi [EMAIL PROTECTED] ;-) Since many of us are having BIG problem with the 9.2 tree on the mirror (expecially for the LG-bug), imho it would be safe to REMOVE the actual 9.2 and upload a new 9.2b or similar, with the fixed kernel (and the correct kde packages and so on...). What do you think about it? Thanks, Claudio What you suggest has been announced ages ago on the errata page... Moreover, there is nothing to remove since it has not been distributed to the public and is not available on server (except for leaked versions). Eric I mean: 9.2 is _now_ on many mirror, as announced a pair of weeks ago. Taht 9.2 _still_ have the broken kernel. Than's my suggestion: remove that tree _immediately_ to avoid furter incident. Claudio --
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
Claudio wrote: Hi [EMAIL PROTECTED] ;-) Since many of us are having BIG problem with the 9.2 tree on the mirror (expecially for the LG-bug), imho it would be safe to REMOVE the actual 9.2 and upload a new 9.2b or similar, with the fixed kernel (and the correct kde packages and so on...). What do you think about it? Thanks, Claudio What you suggest has been announced ages ago on the errata page... Moreover, there is nothing to remove since it has not been distributed to the public and is not available on server (except for leaked versions). Eric
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Fernandez wrote: Claudio wrote: Hi [EMAIL PROTECTED] ;-) Since many of us are having BIG problem with the 9.2 tree on the mirror (expecially for the LG-bug), imho it would be safe to REMOVE the actual 9.2 and upload a new 9.2b or similar, with the fixed kernel (and the correct kde packages and so on...). What do you think about it? Thanks, Claudio What you suggest has been announced ages ago on the errata page... Moreover, there is nothing to remove since it has not been distributed to the public and is not available on server (except for leaked versions). And the FTP tree, with (I assume) offending kernels in the floppy images and the modules for said kernel in the stage2's on the mirrors. http://mandrake.redbox.cz/Mandrake/9.2/i586/images/ Parent Directory - MD5SUM 23-Sep-2003 12:03 383 alternatives/ 23-Sep-2003 12:03- blank.img 23-Sep-2003 12:03 1.4M cdrom-changedisk.img23-Sep-2003 12:03 1.4M cdrom.img 23-Sep-2003 12:03 1.4M hd.img 23-Sep-2003 12:03 1.4M hdcdrom_usb.img 23-Sep-2003 12:03 1.4M memtest-x86.bin 10-Sep-2002 12:59 79K network.img 23-Sep-2003 12:03 1.4M network_gigabit_usb.img 23-Sep-2003 12:03 1.4M pcmcia.img 23-Sep-2003 12:03 1.4M Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/n+Y8rJK6UGDSBKcRAoW0AKC8cL1O+ZGCaolAAtdwyyT0VDhFRwCfc99w vWNrzdWX9LK7krQoIAOMbpw= =F6aC -END PGP SIGNATURE-
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
On Wednesday 29 October 2003 4:02 pm, Eric Fernandez wrote: Claudio wrote: Hi [EMAIL PROTECTED] ;-) Since many of us are having BIG problem with the 9.2 tree on the mirror (expecially for the LG-bug), imho it would be safe to REMOVE the actual 9.2 and upload a new 9.2b or similar, with the fixed kernel (and the correct kde packages and so on...). What do you think about it? Thanks, Claudio What you suggest has been announced ages ago on the errata page... Moreover, there is nothing to remove since it has not been distributed to the public and is not available on server (except for leaked versions). ^^^ WTH does that mean How can a public ftp server contain leaked version of Mandrake 9.2? Eric -- John Allen, mailto:[EMAIL PROTECTED] MandrakeClub Silver Member. http://allentech.homelinux.org/
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
John Allen wrote: WTH does that mean How can a public ftp server contain leaked version of Mandrake 9.2? I correct myself : leaked bittorrent links (available to non-members). Eric
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
does it mean then there will be newer ISO's or not? some people want MDK9.2 and I will be more then happy to give them the fixed public ISO's. , 29 2003, 19:10,Eric Fernandez: John Allen wrote: WTH does that mean How can a public ftp server contain leaked version of Mandrake 9.2? I correct myself : leaked bittorrent links (available to non-members). Eric -- diego, 4 Heshvan 5764 Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
On Wednesday 29 October 2003 5:10 pm, Eric Fernandez wrote: John Allen wrote: WTH does that mean How can a public ftp server contain leaked version of Mandrake 9.2? I correct myself : leaked bittorrent links (available to non-members). Well bitttorrent has nothing to do with it; the Mandrake mirrors have effectively had 9.2 since cooker was frozen, so anybody could make the ISO's themselves. Admittedly they would not be identical to Mandrake's ISO's but they would contain fundamentally the same RPMS, and therefore the same problems. Eric -- John Allen, mailto:[EMAIL PROTECTED] MandrakeClub Silver Member. http://allentech.homelinux.org/
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
Am Mittwoch, 29. Oktober 2003 18:32 schrieb Diego Iastrubni: does it mean then there will be newer ISO's or not? some people want MDK9.2 and I will be more then happy to give them the fixed public ISO's. If you would read the errata page, you would see that new ISOs and CDs are in the work. ;) Steffen , 29 2003, 19:10,Eric Fernandez: John Allen wrote: WTH does that mean How can a public ftp server contain leaked version of Mandrake 9.2? I correct myself : leaked bittorrent links (available to non-members). Eric
Re: [Cooker] Suggestion: move 9.2 to 9.2b or 9.2.1 and CHANGE the kernel!
On Wed, 2003-10-29 at 16:02, Eric Fernandez wrote: Claudio wrote: Hi [EMAIL PROTECTED] ;-) Since many of us are having BIG problem with the 9.2 tree on the mirror (expecially for the LG-bug), imho it would be safe to REMOVE the actual 9.2 and upload a new 9.2b or similar, with the fixed kernel (and the correct kde packages and so on...). What do you think about it? Thanks, Claudio What you suggest has been announced ages ago on the errata page... Moreover, there is nothing to remove since it has not been distributed to the public and is not available on server (except for leaked versions). Uh? club-internet.fr, to name just one mirror, has a full 9.2 tree. We're talking *trees* here, not ISOs. -- adamw
Re: [Cooker] Suggestion for program inclusion
On Sun, Sep 28, 2003 at 02:50:04AM -0300, Damian Gatabria wrote: I think it makes a great addition to mkisofs and bchunk. Tarball (8.1Kb) can be downloaded at: http://gregory.kokanosky.free.fr/v4/linux/nrg2iso.en.html Of course, when i say inclusion, i'm referring to 9.3/10.0. ;oP packaged it at http://www.comedia.it/~bluca/cooker/misc/ if noone objects i would add it to contribs later L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \
Re: [Cooker] (suggestion) drak control center whey not 4 in 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Hi all i was wondering whey don't we marge all 4 apps of urpmi in to 1 with a gui that provide the following - all available features are integrated in to one gui - the resualt of the searched name of the rpm should show in the detail if installed or not. - in the top bar beside view and file we can have preferences or configuration entry...in this will give a menu to update, add and remove downloading source such as plf,contrib ..etc. i don't know if i was clear or not but the bottom line is way not marge all 4 apps add, remove etc in to one and make it nice gui even better than synaptic We don't discuss this anymore, since we don't want to upset gc (rpmdrake maintainer) again. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/WFQQrJK6UGDSBKcRAj/bAJ9hjtd25G2SfKUwAKYrZeHL6GV+cgCfRc4r fRWWsV9skqz79H0H43rZIgA= =b8om -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
On Wednesday 03 September 2003 00:14, Adam Williamson wrote: I ran urpmi.setup the other day and I didn't see the opportunity to setup a plf source anywhere... it is a secret trick. you should run it from the command line, and use --allsources. -- Mickaël Scherer
Re: [Cooker] Suggestion for improved user experience
On Wed, 2003-09-03 at 07:23, Michael Scherer wrote: On Wednesday 03 September 2003 00:14, Adam Williamson wrote: I ran urpmi.setup the other day and I didn't see the opportunity to setup a plf source anywhere... it is a secret trick. you should run it from the command line, and use --allsources. In which case, the argument that it shouldn't have a drakconf link because it provides plf sources holds no water, since you simply make sure drakconf doesn't invoke it with the --allsources option. Which is the debate I was replying to. Please remain in context... -- adamw
Re: [Cooker] Suggestion for improved user experience
On Wed, 3 Sep 2003, Michael Scherer wrote: On Wednesday 03 September 2003 00:14, Adam Williamson wrote: I ran urpmi.setup the other day and I didn't see the opportunity to setup a plf source anywhere... it is a secret trick. you should run it from the command line, and use --allsources. damn...now you blew it. We secretly lobbied for months to get our secret illegal software on all mdk installs. And urpmi.setup is in main now, and we only needed to have a link in a menu or control center. And now you betrayed us! Yours, Secret Penguin Liberation Front Tux
Re: [Cooker] Suggestion for improved user experience
On Mon 01 Sep 2003 13:27, [EMAIL PROTECTED] posted as excerpted below: On Mon, 1 Sep 2003, Buchan Milne wrote: See mutray (for KDE at least) and mdk-check-update-gnome (works in KDE and GNOME, and probably the rox desktop too), both in contrib. It would be a shame not to just enable these by default or at least enable it if some visible checkbox is clicked. Both those applets are pretty new, AFAIK, introduced into contrib this beta cycle. Yes, there's a place for them. Yes, main and installed for the convenience of newbies by default would be good. No, I don't believe they should be in 9.2 by default. They aren't yet stable/mature/proven enough yet for that, IMO. Leave it in contrib this cycle, consider it for main next cycle, install it by default the third cycle, I think is a decent policy, tho installed by default in second cycle might be fine for these, if maturity and stability warrants it. AFAIK, it's the same deal with urpmi.setup. It may be a bit older, but it was just moved from contrib this cycle. As a setup for urpmi, which is a cli tool, I wouldn't expect it to be core integrated into Mandrake's centralized GUI config system yet. Perhaps a separate menu entry under config, and moving it to main is certainly appropriate for this release, but integration into Mandrake's core config can and should appropriately wait until the next cycle, IMO. One step at a time.. -- Duncan - List replies preferred. They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin
Re: [Cooker] Suggestion for improved user experience
Le lun 01/09/2003 à 20:27, [EMAIL PROTECTED] a écrit : Buchan worded it all much better than my own reply. So i leave it with only this: On Mon, 1 Sep 2003, Buchan Milne wrote: See mutray (for KDE at least) and mdk-check-update-gnome (works in KDE and GNOME, and probably the rox desktop too), both in contrib. It would be a shame not to just enable these by default or at least enable it if some visible checkbox is clicked. this should be enable only for one user ( the security admin user ), and this choice should be made during installation. Why ? I don't want normal users see all theses security advisories, and the same for my boss ... bad publicity. For example you can specify who will receive security warnings ( mutray/mdk-check-update/gdesklet-mdksecurity/karamba-mdksecurity ) during user creation ( a checkbox ), or in a separate wizard ( but need to recall the username ) and of course in userdrake ( in case you are in an NIS/LDAP network and so you don't have userlist during install )
Re: [Cooker] Suggestion for improved user experience
On Tue, 2 Sep 2003, Duncan wrote: Both those applets are pretty new, AFAIK, introduced into contrib this beta cycle. Yes, there's a place for them. Yes, main and installed for the convenience of newbies by default would be good. No, I don't believe they should be in 9.2 by default. They aren't yet stable/mature/proven enough yet for that, IMO. Leave it in contrib this cycle, consider it for main next cycle, install it by default the third cycle, I think is a decent policy, tho installed by default in second cycle might be fine for these, if maturity and stability warrants it. I can see no significant effect to system stability of a tray applet. I do see a significant effect on system stability of latest kernel changes. Same is true for urpmi.setup. If what you say is true we should also block OO.org 1.1. Freeze is very good, but do not let it lead you to idiotic descisions. There is s a big difference between a tray applet and a core library/kernel component. d.
Re: [Cooker] Suggestion for improved user experience
[EMAIL PROTECTED] writes: Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. plf other not so legal in all countries repositeries i guess.
Re: [Cooker] Suggestion for improved user experience
On Tue, 2003-09-02 at 22:13, Thierry Vignaud wrote: [EMAIL PROTECTED] writes: Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. plf other not so legal in all countries repositeries i guess. I ran urpmi.setup the other day and I didn't see the opportunity to setup a plf source anywhere... -- adamw
Re: [Cooker] Suggestion for improved user experience
On Tue, 2 Sep 2003, Thierry Vignaud wrote: [EMAIL PROTECTED] writes: Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. plf other not so legal in all countries repositeries i guess. eh...what has urpmi.setup to do with plf et al? It is already in main, and can be used to setup remote sources for main and contrib. d.
Re: [Cooker] Suggestion for improved user experience
On Sun Aug 31, 2003 at 08:02:18PM +0200, Buchan Milne wrote:
How's this?
http://www.mandrakesecure.net/en/advisories/rss.php
?
Does that do what you want?
I finally got to using it with superkaramba:
http://ranger.dnsalias.com/mandrake/screenshots/superkaramba-mandrakesecure-rdf.png
Just need to work on the graphics a bit, either use a light background,
unless there's a version available for use on dark backgounds?
Wow... that looks pretty neat. Does this superkaramba thing work in gnome
too?
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Danen wrote: On Sun Aug 31, 2003 at 08:02:18PM +0200, Buchan Milne wrote: How's this? http://www.mandrakesecure.net/en/advisories/rss.php Does that do what you want? I finally got to using it with superkaramba: http://ranger.dnsalias.com/mandrake/screenshots/superkaramba-mandrakesecure-rdf.png Just need to work on the graphics a bit, either use a light background, unless there's a version available for use on dark backgounds? Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? AFAIK, no, that's what gdesklets is for, but I haven't played with it much (besides just running the clock). Maybe it is also capable? But there is also straw, which may be able to do this: $ urpmq straw -i Name: straw Version : 0.19.1 Release : 1mdk Group : Networking/Other Size: 589648 Architecture: noarch Summary : RSS feed agregator for Gnome Never run it though ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/UxfErJK6UGDSBKcRAlRNAKCptpm0J3tYcxlABscl2zhRXxTqTwCgu7g9 bHp+VZ8SRVDEEdnQdGz/g1M= =A6S5 -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
Vincent Danen wrote: On Sun Aug 31, 2003 at 08:02:18PM +0200, Buchan Milne wrote: I finally got to using it with superkaramba: http://ranger.dnsalias.com/mandrake/screenshots/superkaramba-mandrakesecure-rdf.png Just need to work on the graphics a bit, either use a light background, unless there's a version available for use on dark backgounds? Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? That is cool. I think the equivalent of SK for gnome is gDesklets, a recent addition to contrib packaged by Götz Waschk. I haven't played around with it yet, but it looks like a fun new toy. - John
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: On Sun, 31 Aug 2003, Vincent Danen wrote: Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? ah..the price for running GNOME :-P On a more serious note, are you (=mdksoft) or are you not going to set up something like this by default? If the user has to search for packages to get security warnings than only security aware users will use it (and they probably checked mdksecure anyway). The messages need to appear on the screen of the newbie, unexperienced users, by default. Well, Danny, if we get a superkaramba that compiles on current cooker, I will make a package that includes a mandrakesecure.net theme by default (instead of opening up a dialog where you choose your theme). Maybe a similar thing can be done for gdesklets. Maybe in the future these will be in main, and installed in a default installation? Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. I agree, or at least it needs an entry in the menus. Maybe you need to file a bug on urpmi.setup (sorry Olivier ..). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Ux4HrJK6UGDSBKcRAsDqAJ9WM8q0A6yOvVzj1kxFcWj2HA3aRACfUeAc lG/em2dMDKWF+8nXwv0rnkk= =fsG0 -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
I think the equivalent of SK for gnome is gDesklets, a recent addition to contrib packaged by Götz Waschk. I haven't played around with it yet, but it looks like a fun new toy. I've packaged lot of sensors and displays for gDesklets, but no one can read RSS feeds. For now, you can use gdesklets-externalsensor to display the output of another program that read RSS feeds. -- Olivier Blin
Re: [Cooker] Suggestion for improved user experience
I think the equivalent of SK for gnome is gDesklets, a recent addition to contrib packaged by Götz Waschk. I haven't played around with it yet, but it looks like a fun new toy. This may be useful if someone want to start a such RSS applet for gDesklets : http://www-106.ibm.com/developerworks/webservices/library/ws-pyth11.html -- Olivier Blin
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Blin wrote: I think the equivalent of SK for gnome is gDesklets, a recent addition to contrib packaged by Götz Waschk. I haven't played around with it yet, but it looks like a fun new toy. I've packaged lot of sensors and displays for gDesklets, but no one can read RSS feeds. For now, you can use gdesklets-externalsensor to display the output of another program that read RSS feeds. Many superkaramba themes just use rdf.pl (in the karamba/superkaramba packages) to do just that, in fact, that is what I am using. Unfortunately it does not have proxy support (which is why I can't test it on my normal cooker box). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/UzYwrJK6UGDSBKcRAi0MAKCA9u/uA/YTJcoLNRiJBLuEPwmf5ACgyRuA 1P7JVXY6UgTRoWqk4/DGAaA= =DNzN -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
On Sun, 31 Aug 2003, Vincent Danen wrote: Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? ah..the price for running GNOME :-P On a more serious note, are you (=mdksoft) or are you not going to set up something like this by default? If the user has to search for packages to get security warnings than only security aware users will use it (and they probably checked mdksecure anyway). The messages need to appear on the screen of the newbie, unexperienced users, by default. Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. d.
Re: [Cooker] Suggestion for improved user experience
Le lun 01/09/2003 à 03:39, Vincent Danen a écrit : On Sun Aug 31, 2003 at 08:02:18PM +0200, Buchan Milne wrote: How's this? http://www.mandrakesecure.net/en/advisories/rss.php ? Does that do what you want? I finally got to using it with superkaramba: http://ranger.dnsalias.com/mandrake/screenshots/superkaramba-mandrakesecure-rdf.png Just need to work on the graphics a bit, either use a light background, unless there's a version available for use on dark backgounds? Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? I don't think as this is a hack for KDE and for gnome you have gdesklet
Re: [Cooker] Suggestion for improved user experience
On Mon Sep 01, 2003 at 11:58:46AM +0200, [EMAIL PROTECTED] wrote:
Wow... that looks pretty neat. Does this superkaramba thing work in gnome
too?
ah..the price for running GNOME :-P
On a more serious note, are you (=mdksoft) or are you not going to set up
something like this by default? If the user has to search for packages to
get security warnings than only security aware users will use it (and they
probably checked mdksecure anyway). The messages need to appear on the
screen of the newbie, unexperienced users, by default.
Well, let's put it this way. We're working on 9.2 now, and I've been doing
the security since 6.1 (IIRC) and it's never been an issue before. The
mailing list exists exactly for this kind of thing. There are a lot of
sources to determine new updates:
1) launching rpmdrake and scanning for new updates
2) visiting mandrakesecure
3) visiting mandrakeclub
4) external sources such as linuxsecurity.org (I believe)
5) mailing lists: announce, bugtraq, full-disclosure, and two others
6) new RSS feed
I don't think it's urgent that we put something like this in there by
default. Would it be nice? Hell yes! Do I think it's necessary? Not
really.
Personally, I'd like to see a little applet that's like a green light and
polls the mirrors (or rss feed) and turns red if there's something new.
Something to develop/look into for a future version. (We are in a freeze
after all).
Now that I am complaining, why does urpmi.setup not have it's own button
in drakconf (ok, it's a bit bugged, is that the reason?). It is such a
waste to have all the nice functionality of urpmi lost to most non-CLI
users.
This I can't tell you. I don't use drakconf... call me an old-school
diehard (or insane). =)
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Danen wrote: On Mon Sep 01, 2003 at 11:58:46AM +0200, [EMAIL PROTECTED] wrote: Wow... that looks pretty neat. Does this superkaramba thing work in gnome too? ah..the price for running GNOME :-P On a more serious note, are you (=mdksoft) or are you not going to set up something like this by default? If the user has to search for packages to get security warnings than only security aware users will use it (and they probably checked mdksecure anyway). The messages need to appear on the screen of the newbie, unexperienced users, by default. Well, let's put it this way. We're working on 9.2 now, and I've been doing the security since 6.1 (IIRC) and it's never been an issue before. Mandrake 6.1 wasn't competing with Windows98SE for the average user's desktop (realistically speaking). Mandrake 9.2 will be competing with WindowsXP for the average user's desktop (ie, will have a reasonable chance). So, including something like this by default on 6.1 would not have made much difference, but it does now (ie Mandrake has improved substantially since 6.1 that newbie-ish features are necessary). The mailing list exists exactly for this kind of thing. There are a lot of sources to determine new updates: 1) launching rpmdrake and scanning for new updates 2) visiting mandrakesecure 3) visiting mandrakeclub 4) external sources such as linuxsecurity.org (I believe) 5) mailing lists: announce, bugtraq, full-disclosure, and two others 6) new RSS feed The average user won't see these unless we make them see them by default. You need to cater for the people who can't get WindowsUpdate to work (they're a big market, with recent motivations to change ...). You basically need to ensure that a user can't miss the update notifications, even if they try ... I don't think it's urgent that we put something like this in there by default. Would it be nice? Hell yes! Do I think it's necessary? Not really. Personally, I'd like to see a little applet that's like a green light and polls the mirrors (or rss feed) and turns red if there's something new. Something to develop/look into for a future version. (We are in a freeze after all). See mutray (for KDE at least) and mdk-check-update-gnome (works in KDE and GNOME, and probably the rox desktop too), both in contrib. Now that I am complaining, why does urpmi.setup not have it's own button in drakconf (ok, it's a bit bugged, is that the reason?). It is such a waste to have all the nice functionality of urpmi lost to most non-CLI users. This I can't tell you. I don't use drakconf... call me an old-school diehard (or insane). =) But, I am sure (after running urpmi.setup) you will see it is valuable to have it in the menus at least? Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/U6n9rJK6UGDSBKcRAopNAJ9chpcotXnW5hgSyC9q7033ba2VsgCeMhHY byh1uSf+mu2JGD+aLuZBe38= =PCRV -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
Buchan worded it all much better than my own reply. So i leave it with only this: On Mon, 1 Sep 2003, Buchan Milne wrote: See mutray (for KDE at least) and mdk-check-update-gnome (works in KDE and GNOME, and probably the rox desktop too), both in contrib. It would be a shame not to just enable these by default or at least enable it if some visible checkbox is clicked. d.
Re: [Cooker] Suggestion for improved user experience
On Mon, 25 Aug 2003, Vincent Danen wrote: On Tue Aug 26, 2003 at 12:43:33AM +0200, Buchan Milne wrote: - daily updates/security updates if available If mandrakesecure.net had RDF this wouldn't be too difficult. Vince? RDF of what packages are available or recently released? I suppose something like that could be done, although I'd need a sample RDF file to see what it's supposed to look like. Yes, I guess something such as the bit on the advisory mails that follows the advisory number, ie: Updated perl-CGI packages fix cross-site scripting vulnerabilities RDF is XML, such as: http://pclinuxonline.com/backend.php or http://slashdot.org/slashdot.rdf There are some php modules around to do RDF AFAIK, and there was a specification for RDF at some stage, not sure what happened to it ... How's this? http://www.mandrakesecure.net/en/advisories/rss.php ? Does that do what you want? I finally got to using it with superkaramba: http://ranger.dnsalias.com/mandrake/screenshots/superkaramba-mandrakesecure-rdf.png Just need to work on the graphics a bit, either use a light background, unless there's a version available for use on dark backgounds? Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
On Tue Aug 26, 2003 at 06:13:02PM -0400, Levi Ramsey wrote:
http://www.mandrakesecure.net/en/advisories/rss.php
I can go about submitting it to the likes of K5 and Slashdot for sidebar
headline boxes if desired...
It's up to you. Doesn't really matter to me. I don't know if slashdot
would carry something like that, and I don't know what K5 is, but the more
the merrier I guess.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
On Tue Aug 26, 2003 at 12:43:33AM +0200, Buchan Milne wrote:
- daily updates/security updates if available
If mandrakesecure.net had RDF this wouldn't be too difficult. Vince?
RDF of what packages are available or recently released? I suppose
something like that could be done, although I'd need a sample RDF file to
see what it's supposed to look like.
Yes, I guess something such as the bit on the advisory mails that
follows the advisory number, ie:
Updated perl-CGI packages fix cross-site scripting vulnerabilities
RDF is XML, such as:
http://pclinuxonline.com/backend.php
or
http://slashdot.org/slashdot.rdf
There are some php modules around to do RDF AFAIK, and there was a
specification for RDF at some stage, not sure what happened to it ...
How's this?
http://www.mandrakesecure.net/en/advisories/rss.php
?
Does that do what you want?
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
Le Lundi 25 Août 2003 14:38, Buchan Milne a écrit : snip BTW, I have packages of karamba-0.22 and superkaramba-0.30, but I need some opinions on what to do with them. karamba-0.22 doesn't run many new themes (since most of them were developed after karamba-0.17 for superkaramba), but they may have some conflicts. AFAIK superkaramba dont compile with python-2.3 :/ The latest version of the ( real ) karamba is 0.17 , i think you speak about karamba-replica ( http://b1project.com/karamba.php3 ) -- Laurent Culioli :: [EMAIL PROTECTED]
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurent Culioli wrote: Le Lundi 25 Août 2003 14:38, Buchan Milne a écrit : snip BTW, I have packages of karamba-0.22 and superkaramba-0.30, but I need some opinions on what to do with them. karamba-0.22 doesn't run many new themes (since most of them were developed after karamba-0.17 for superkaramba), but they may have some conflicts. AFAIK superkaramba dont compile with python-2.3 :/ Hmmm, good point, I built it on 9.2b2 which is still python-2.3 :-(. I will have to try again ... The latest version of the ( real ) karamba is 0.17 , i think you speak about karamba-replica ( http://b1project.com/karamba.php3 ) Yes, but real karamba isn't maintained any more ... so IMHO karamba-replica *is* karamba (look at the binary name, config name, and other hardcoded uses of karamba in the source), and is at 0.22. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Sx26rJK6UGDSBKcRAuF1AKC9/GFISwrpck5IGTmuw3ygtb825QCgkQlc /ktwKaZGeCzO1QlW470Fr1U= =H9H2 -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Danen wrote: On Tue Aug 26, 2003 at 12:43:33AM +0200, Buchan Milne wrote: If mandrakesecure.net had RDF this wouldn't be too difficult. Vince? How's this? http://www.mandrakesecure.net/en/advisories/rss.php ? Does that do what you want? I can't test with karamba now (doesn't have support for authenticating proxies AFAIK), I will test from home later, but I tested with Evolution: http://ranger.dnsalias.com/mandrake/screenshots/mandrakesecure-rdf-evolution.png (It would be nice though if articles/documentation were also listed though) Fred, any chance we can get this into the default summary screen in Evolution? Now we just need to see if Club is capable of implementing something like this ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Syr8rJK6UGDSBKcRAuvoAJwOWkmuTlzZ6GHg4ZPu4u0SoB2HggCfTELr R+nPhFsAYkSlvM6wRu0tpIA= =cxhC -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
On Tue, 26 Aug 2003 11:40:12 +0200, Buchan Milne wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Danen wrote: On Tue Aug 26, 2003 at 12:43:33AM +0200, Buchan Milne wrote: If mandrakesecure.net had RDF this wouldn't be too difficult. Vince? How's this? http://www.mandrakesecure.net/en/advisories/rss.php ? Does that do what you want? I can't test with karamba now (doesn't have support for authenticating proxies AFAIK), I will test from home later, but I tested with Evolution: http://ranger.dnsalias.com/mandrake/screenshots/mandrakesecure-rdf-evolution.png (It would be nice though if articles/documentation were also listed though) Fred, any chance we can get this into the default summary screen in Evolution? Shouldn't be too difficult.. Please fill a bug so I don't forget.. -- Frederic Crozat MandrakeSoft
Re: [Cooker] Suggestion for improved user experience
On Tue Aug 26, 2003 at 11:40:12AM +0200, Buchan Milne wrote:
If mandrakesecure.net had RDF this wouldn't be too difficult. Vince?
How's this?
http://www.mandrakesecure.net/en/advisories/rss.php
?
Does that do what you want?
I can't test with karamba now (doesn't have support for authenticating
proxies AFAIK), I will test from home later, but I tested with Evolution:
http://ranger.dnsalias.com/mandrake/screenshots/mandrakesecure-rdf-evolution.png
(It would be nice though if articles/documentation were also listed though)
That's a little more difficult. The articles/docs aren't database driven
and would likely not show up very often because they don't get written or
updated very often.
Fred, any chance we can get this into the default summary screen in
Evolution?
This would be very cool.
Now we just need to see if Club is capable of implementing something
like this ...
It's Nuke-based, so it should be able to do something like this I would
think.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
On Wed Aug 27 0:24 +0200, Buchan Milne wrote: Levi Ramsey wrote: On Mon Aug 25 17:44 -0600, Vincent Danen wrote: http://www.mandrakesecure.net/en/advisories/rss.php I can go about submitting it to the likes of K5 and Slashdot for sidebar headline boxes if desired... I was hoping someone would ... Done (at least for Kuro5hin and Slashdot)... if you know of any other sites that Mandrake users might frequent, submit the RDFs. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Apocalyptica - Plays Metallica by Four Cellos - Mas Linux 2.4.21-3mdk 18:52:00 up 22 days, 4:10, 10 users, load average: 0.50, 0.87, 1.08
Re: [Cooker] Suggestion for improved user experience
Le dim 24/08/2003 à 01:30, Leon Brooks a écrit : On Fri, 22 Aug 2003 18:06, Emmanuel wrote: What do you mandrakees think about including SuperKaramba and running it by default with simple things like weather etc... I think an office with 200 or so Mandrake machines doing this wouldn't have an Internet link any more, and an individual without a permanent Internet link would find it annoying. However, the option of running some other app (besides the clock) on KDM's screen would be very attract. I'd be wanting to be sure that whatever app it was didn't run as a user with any serious privs. some suggestions : - hourly fortune messages - hourly tips/help messages - daily mdk ads - daily updates/security updates if available
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FACORAT Fabrice a écrit : | some suggestions : | - hourly fortune messages | - hourly tips/help messages | - daily mdk ads | - daily updates/security updates if available troll you forgot theses : - - hourly random memory allocation (never freed) - - hourly core dump - - dayly mdk call home to push private data (could be integrated in security updates and daly ads as well) - - dayly kernel oups (hard reset is boring) WindowsXP has all of this already and Longhorn will bring you much much more. /troll - -- ~ Léa Gris - http://www.noiraude.net/ () Campagne du ruban texte brut contre les courriels en HTML, /\ contre les pièces jointes dans un format propriétaire. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/SfXmiNTO/wgn58kRArxOAKDiSVOv1UDM9PU/SOFNdNjSWRDKXwCdGQ8J 1z6ww814I6GKmM+bZQ8WwHA= =RI96 -END PGP SIGNATURE-
Re: [Cooker] Suggestion for improved user experience
Ainsi parlait Lea Gris : FACORAT Fabrice a écrit : | some suggestions : | - hourly fortune messages | - hourly tips/help messages | - daily mdk ads | - daily updates/security updates if available troll you forgot theses : - hourly random memory allocation (never freed) - hourly core dump - dayly mdk call home to push private data (could be integrated in security updates and daly ads as well) - dayly kernel oups (hard reset is boring) WindowsXP has all of this already and Longhorn will bring you much much more. /troll and minutely cooker excerpts ? -- Guillaume Rousse Keep your boss's boss off your boss's back -- Murphy's Laws on Work n°11
Re: [Cooker] Suggestion for improved user experience
On Mon, 2003-08-25 at 12:41, Lea Gris wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FACORAT Fabrice a écrit : | some suggestions : | - hourly fortune messages | - hourly tips/help messages | - daily mdk ads | - daily updates/security updates if available troll you forgot theses : - - hourly random memory allocation (never freed) - - hourly core dump - - dayly mdk call home to push private data (could be integrated in security updates and daly ads as well) - - dayly kernel oups (hard reset is boring) WindowsXP has all of this already and Longhorn will bring you much much more. /troll I was going to post a similar response, but realised he was talking about *KDM*, not the user desktop. I don't think such features would be a bad idea for the DM - there's a bunch of wasted space there, can't see any harm in putting neat little featurettes in it. Maybe not adverts, though. Adverts are bad. -- adamw
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FACORAT Fabrice wrote: Le dim 24/08/2003 à 01:30, Leon Brooks a écrit : On Fri, 22 Aug 2003 18:06, Emmanuel wrote: What do you mandrakees think about including SuperKaramba and running it by default with simple things like weather etc... BTW, I have packages of karamba-0.22 and superkaramba-0.30, but I need some opinions on what to do with them. karamba-0.22 doesn't run many new themes (since most of them were developed after karamba-0.17 for superkaramba), but they may have some conflicts. Also, I will try and make a themes package including most useful themes with ratings 75%. I think an office with 200 or so Mandrake machines doing this wouldn't have an Internet link any more, and an individual without a permanent Internet link would find it annoying. However, the option of running some other app (besides the clock) on KDM's screen would be very attract. I'd be wanting to be sure that whatever app it was didn't run as a user with any serious privs. Of course, was my first thought. If we are going to try this, I think the first thing we need is some karamba themes that implement the pieces we want, while someone investigates running karamba in kdm ... but the themes would be useful even without this. some suggestions : - hourly fortune messages - hourly tips/help messages - daily mdk ads - daily updates/security updates if available If mandrakesecure.net had RDF this wouldn't be too difficult. Vince? Also, IMHO MandrakeClub gets too little exposure, maybe new articles and entries in RPM Voting would be interesting. But for my own purposes (we're firewalled so bad nothing can get out without proxy authorisation, so web-based stuff is useless), I would prefer things like: - -how many users are logged on - -uptime stats (so you can see CPU/mem utilisation without logging in) - -maybe /etc/motd? So, I think those who are interested should proceed by: - -making good Mandrake-themed (ie the new bootsplash themes) karamba themes - -investigate running karamba in kdm Also, it would be interesting to investigate the equivalent (of Mandrake themes for karamba) for gdesklets. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/SgNSrJK6UGDSBKcRArwbAKDBC94CabJCJTBNQSXepBhAvgLISQCeOU9L 2Te5lwBO5cK4DyB5TagP7Ig= =+BDv -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Danen wrote: On Mon Aug 25, 2003 at 02:38:43PM +0200, Buchan Milne wrote: Of course, was my first thought. If we are going to try this, I think the first thing we need is some karamba themes that implement the pieces we want, while someone investigates running karamba in kdm ... but the themes would be useful even without this. some suggestions : - hourly fortune messages - hourly tips/help messages - daily mdk ads - daily updates/security updates if available If mandrakesecure.net had RDF this wouldn't be too difficult. Vince? RDF of what packages are available or recently released? I suppose something like that could be done, although I'd need a sample RDF file to see what it's supposed to look like. Yes, I guess something such as the bit on the advisory mails that follows the advisory number, ie: Updated perl-CGI packages fix cross-site scripting vulnerabilities RDF is XML, such as: http://pclinuxonline.com/backend.php or http://slashdot.org/slashdot.rdf There are some php modules around to do RDF AFAIK, and there was a specification for RDF at some stage, not sure what happened to it ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/SpEVrJK6UGDSBKcRAorSAKCH6fdPVePc8jqPjAADH8M5nE4kDwCgyqFF v9GvvORTwsyei5ZBrxKo4wg= =rNR0 -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion for improved user experience
On Mon Aug 25, 2003 at 02:38:43PM +0200, Buchan Milne wrote:
Of course, was my first thought. If we are going to try this, I think
the first thing we need is some karamba themes that implement the pieces
we want, while someone investigates running karamba in kdm ... but the
themes would be useful even without this.
some suggestions :
- hourly fortune messages
- hourly tips/help messages
- daily mdk ads
- daily updates/security updates if available
If mandrakesecure.net had RDF this wouldn't be too difficult. Vince?
RDF of what packages are available or recently released? I suppose
something like that could be done, although I'd need a sample RDF file to
see what it's supposed to look like.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion for improved user experience
On Fri, 22 Aug 2003 18:06, Emmanuel wrote: What do you mandrakees think about including SuperKaramba and running it by default with simple things like weather etc... I think an office with 200 or so Mandrake machines doing this wouldn't have an Internet link any more, and an individual without a permanent Internet link would find it annoying. However, the option of running some other app (besides the clock) on KDM's screen would be very attract. I'd be wanting to be sure that whatever app it was didn't run as a user with any serious privs. Cheers; Leon
Re: [Cooker] Suggestion for improved user experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuel wrote: Hi all, What do you mandrakees think about including SuperKaramba and running it by default with simple things like weather etc... Superkaramba is the only thing that has crashed X on my machine in recent times, this occurs with some NVidia drivers, I don't think running something like this by default is a good idea if there's any danger of it crashing. Also, Superkaramba is quite slow on all but the fastest machines. But, it is worthwhile ensuring an up-to-date Superkaramba (and/or karamba) package is in the distro. Even possibly integrating it with KDM??? How professional would a login screen look with say the SuperKaramba weather running in the background? I could think of some better things right now, especially since our machines can't get to the internet without authentication. I would prefer better remote X support (ie Login to remote X server). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/RhQjrJK6UGDSBKcRAphpAKCpvLq8x/qzSy1MNd6klbvEiEwu0ACfWN6B Jo61f0F15WqayzKbJO6OjgQ= =kbO/ -END PGP SIGNATURE- * Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *
Re: [Cooker] Suggestion: switch order of asking for username androot password during install
Pixel wrote: Buchan Milne [EMAIL PROTECTED] writes: If the user setup is done first then new users are more likely to add themselves as a user. Then when prompted for the root/admin. password they will have already setup a non-root user that can be the default login. I don't agree with this, unless authentication is split off. Since, in any case where a network authentication method (LDAP, NIS, Windows Domain) is used, in most cases a user account will not be necessary. well, currently drakx doesn't take this into account when prompting for users to add or not... No, but the person installing does ... the thing you want to ensure (thus the one that should be done first) is that the root account gets a good password. The person installing can always add more users later, but he can't do this easily if he forgot his root password ... A root account is always necessary, and should be where the user uses their good password ;-). Of course, there are other problems which are not easily solved, in higher security levels you are asked for an account to send alerts to, before any accounts (including setting of root password) have been made. But I don't hink it would be practical to move the dialog. i tend to agree. Some people here want to merge both dialog boxes... will see... Maybe remove the alert text field, and instead add another checkbox in msec=4 (where the 'wheel', 'xgrp' etc group checkboxes are) to 'Receives security alerts'. Otherwise, maybe msec could rather send to all members of the adm group by default instead? Buchan -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Suggestion: switch order of asking for username and root password during install
Buchan Milne [EMAIL PROTECTED] writes: On Sun, 19 Jan 2003, Bruce A. Mallett wrote: If the user setup is done first then new users are more likely to add themselves as a user. Then when prompted for the root/admin. password they will have already setup a non-root user that can be the default login. I don't agree with this, unless authentication is split off. Since, in any case where a network authentication method (LDAP, NIS, Windows Domain) is used, in most cases a user account will not be necessary. well, currently drakx doesn't take this into account when prompting for users to add or not... A root account is always necessary, and should be where the user uses their good password ;-). Of course, there are other problems which are not easily solved, in higher security levels you are asked for an account to send alerts to, before any accounts (including setting of root password) have been made. But I don't hink it would be practical to move the dialog. i tend to agree. Some people here want to merge both dialog boxes... will see...
Re: [Cooker] Suggestion: switch order of asking for username and root password during install
Buchan Milne [EMAIL PROTECTED] writes: i tend to agree. Some people here want to merge both dialog boxes... will see... Maybe remove the alert text field, and instead add another checkbox in msec=4 (where the 'wheel', 'xgrp' etc group checkboxes are) to 'Receives security alerts'. Otherwise, maybe msec could rather send to all members of the adm group by default instead? ah, this is a question for security experts :) vincent? (i also mailed to [EMAIL PROTECTED], but i don't know if it'll go through)
Re: [Cooker] Suggestion: switch order of asking for username and root password during install
On Mon Jan 20, 2003 at 01:21:56PM +0100, Pixel wrote:
i tend to agree. Some people here want to merge both dialog boxes...
will see...
Maybe remove the alert text field, and instead add another checkbox in
msec=4 (where the 'wheel', 'xgrp' etc group checkboxes are) to
'Receives security alerts'.
Otherwise, maybe msec could rather send to all members of the adm group
by default instead?
ah, this is a question for security experts :)
vincent? (i also mailed to [EMAIL PROTECTED], but i don't
know if it'll go through)
I think I missed some of what we're talking about here. People want
msec to mail a group of people instead of one single person? Why?
What's wrong with the single email address msec sends to? If it's so
important that more than one person gets the mail, why not have it send
to an alias/internal exploder that will send the message to everyone in
the alias?
Or am I missing the point here? =)
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
msg86973/pgp0.pgp
Description: PGP signature
Re: [Cooker] Suggestion: switch order of asking for username androot password during install
On Sun, 19 Jan 2003, Bruce A. Mallett wrote: If the user setup is done first then new users are more likely to add themselves as a user. Then when prompted for the root/admin. password they will have already setup a non-root user that can be the default login. I don't agree with this, unless authentication is split off. Since, in any case where a network authentication method (LDAP, NIS, Windows Domain) is used, in most cases a user account will not be necessary. A root account is always necessary, and should be where the user uses their good password ;-). Of course, there are other problems which are not easily solved, in higher security levels you are asked for an account to send alerts to, before any accounts (including setting of root password) have been made. But I don't hink it would be practical to move the dialog. Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] suggestion
Try downloading with Konqueror. This feature is contained in it... gftp makes the same, if you're downloading from some ftp-sites... Taske a look at this URL http://www.krasu.ru/soft/chuchelo/ if you#re looking for a download manager. Peter Sérgio Martins wrote: when making a download it could be usefull if the browser supported download resuming, so when i close the download dialog i can start it again at other time, something like download accelerator or getright, thanx _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: [Cooker] suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AFAIK, both Konqueror and Mozilla support this, I suspect galeon does also. If you are having problems with this in a specific piece of software, you should note that, and consider rather posting the request on a forum (mailing list, bug site etc) for that application. Sérgio Martins wrote: when making a download it could be usefull if the browser supported download resuming, so when i close the download dialog i can start it again at other time, something like download accelerator or getright, - -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9yAYprJK6UGDSBKcRAuiUAJ9dhfHkDY0G9RDQctTikJciDWjKLwCeLSu5 e0/0E0n0KXXUqWhfwcAyuIE= =s+3I -END PGP SIGNATURE-
Re: [Cooker] suggestion
isn't this a download manager, that several browsers have built into them?/ ( Netscape has one that can be added to their browser, so it will work with mozilla ) opera has one built right into it. ? Martins wrote: when making a download it could be usefull if the browser supported download resuming, so when i close the download dialog i can start it again at other time, something like download accelerator or getright, thanx _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
Hi. On Wed 2002-10-30 at 10:05:21 -0700, Vincent Danen wrote: [...] Moreover, gpg itself has a nice auto-retrieve option for automatic download of missing keys from keyserver. Provided keys used for signing packages are available there, it seems sufficient for me. I never use this. I don't like keys being automatically added to my keyring. It's too easy for abuse. Intersting. That points out another weakness. Automatic adding of keys to the keyring is not easy to abuse per se. The problem is that urpmi accepts a package as soon as the signature is verifies. That a package is correctly signed only says that it is really from the source it claims to be (I ignore the part that the key could have been tempered with). What is missing a check which sources you trust. Having a key in the keyring does not mean that I trust the owner of the key at all. It just means, that I trust that he really is the owner. So, in order to make this more secure, in addition to the signature, there should be a list of sources to trust rpms from to be configurable. [...] Better yet, there should be a keyring outside of root's keyring that is read-only by users and read/write by root (not in /root/.gnupg) that contains rpm gpg keys. That removal from the user environment (especially root) adds another level of integrity. No need to seperate the key rings. A little config which list the keys to trust for such operations sounds as enough. This could even be done in a way that not each key is valid for each source, i.e. a key for plf shouldn't necessarily be valid for a package coming from mdk. Greetings, Benjamin. msg80753/pgp0.pgp Description: PGP signature
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
On Tuesday, November 5, 2002, at 05:05 PM, Benjamin Pflugmann wrote:
Moreover, gpg itself has a nice auto-retrieve option for automatic
download of missing keys from keyserver. Provided keys used for
signing packages are available there, it seems sufficient for me.
I never use this. I don't like keys being automatically added to my
keyring. It's too easy for abuse.
Intersting. That points out another weakness. Automatic adding of keys
to the keyring is not easy to abuse per se. The problem is that urpmi
accepts a package as soon as the signature is verifies.
That a package is correctly signed only says that it is really from
the source it claims to be (I ignore the part that the key could have
been tempered with). What is missing a check which sources you trust.
Having a key in the keyring does not mean that I trust the owner of
the key at all. It just means, that I trust that he really is the
owner.
So, in order to make this more secure, in addition to the signature,
there should be a list of sources to trust rpms from to be
configurable.
Actually, if you look through the cooker archives, you'll see I
mentioned this exact same thing before. apt does it (or at least
apt4rpm), so urpmi should do it as well.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
Le Mardi 29 Octobre 2002 21:28, Vincent Danen a écrit : On Tuesday, October 29, 2002, at 11:02 AM, Ben Reser wrote: How about putting your signing keys into a package that adds them to root's pubring? However this does bring up an interesting idea. Having urpmi/rpmdrake know where to find the GPG keys for various sources. I would propose that a file name is made as a standard for the key for a source that is placed in the same path as the hdlist/synthesis file. That file would contain a name or names of packages that contained the sites GPG keys. This takes a little more careful thought. Putting GPG keys up without any kind of verification of the source can cause problems. For instance, suppose that PLF has a GPG key and we provide it in a package. Because it's on the keyring, urpmi will happily not complain if a PLF key is found in updates. What happens if PLF goes rogue, hacks into a mirror, and starts replacing updates packages with trojans that are signed with the PLF key? urpmi will install them without complaint. Now, I'm not saying the PLF folks are going to do this... =) This could easily be someone stealing their private key and doing it. OK, remember me to implement some specific backdoors in all our packages %postun if [ $USER = vdanen ]; then # do some really nasty stuff here # echo \/\/3 0wN Y0U d1RtY FUd3r fi But you should see my point. On the first install from that source urpmi/rpmdrake would prompt the user if they wished to install this key. The file would then be downloaded and installed prior to any other package installations. I don't like this. The user should have to make some sort of effort to install these keys manually, or they should be in a MandrakeSoft-signed package. For instance, an rpm-gpg-keys package, provided by MandrakeSoft, signed by MandrakeSoft's key. In the future if the key would need upgrading the version/release could be incremented causing urpmi/rpmdrake to update it. urpmi/rpmdrake would store the package name(s) of the keys. So it would always cause that package to be updated in a separate rpm call prior to updating the rest of the packages. To ensure the keys and there is a trust chain it's possible Mandrake could sign the packages for these people. I don't think there are a lot of sites using the urpmi system. But perhaps Mandrake signing the packages would be a bad idea for trust and work load issues. Yup, my thought exactly. Also, urpmi would need to change before I'd advocate something like this. With apt you can define a key fingerprint that matches a particular source. For instance, one could map the security key fp to the updates source; the mdksoft official key to the cooker or distrib (ie. cd's) source. The logical step is then to map the rpmhelp key to rpmhelp.net, plf's key to plf, etc. Until urpmi can do this (Francois?), we shouldn't entertain this idea. It opens up too many possibilities I'm not comfortable with. Having urpmi do this sort of checking would make it a lot safer and, as a result, a good idea. But it's not a good idea with urpmi as it is now. This is actually something I've thought about for a while, but never brought up (dunno why). I'd like to see urpmi become more popular, and possibly adopted by other distros. A fellow locally tried to get urpmi working on a RH system... he couldn't rebuild it, but he could install it from what I understood, his preliminary tests worked (ie. he could urpmi djbdns-localcache and it worked, even if the packages themselves wouldn't work as they're highly mdk-specific). Francois? What do you think about adding this feature? It could be something configurable in a /etc/urpmi/sigs.conf or something; if there is no entry for a mirror, then do the normal thing, but if the entry exists, not only check that the gpg sig is ok, but make sure the fp matches the appropriate source. Just a thought. What do you guys think? The whole idea is interesting, but i don't understand why those keys have to be in a package, not in just another file with other uprmi data files. Moreover, gpg itself has a nice auto-retrieve option for automatic download of missing keys from keyserver. Provided keys used for signing packages are available there, it seems sufficient for me. -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
On Wednesday, October 30, 2002, at 03:35 AM, Guillaume Rousse wrote:
[...]
hacks into a mirror, and starts replacing updates packages with
trojans
that are signed with the PLF key? urpmi will install them without
complaint. Now, I'm not saying the PLF folks are going to do this...
=) This could easily be someone stealing their private key and doing
it.
OK, remember me to implement some specific backdoors in all our
packages
%postun
if [ $USER = vdanen ]; then
# do some really nasty stuff here
# echo \/\/3 0wN Y0U d1RtY FUd3r
fi
hehehe... I like... =)
[...]
Yup, my thought exactly. Also, urpmi would need to change before I'd
advocate something like this. With apt you can define a key
fingerprint that matches a particular source. For instance, one could
map the security key fp to the updates source; the mdksoft official
key
to the cooker or distrib (ie. cd's) source. The logical step is then
to map the rpmhelp key to rpmhelp.net, plf's key to plf, etc.
Until urpmi can do this (Francois?), we shouldn't entertain this idea.
It opens up too many possibilities I'm not comfortable with. Having
urpmi do this sort of checking would make it a lot safer and, as a
result, a good idea. But it's not a good idea with urpmi as it is
now.
This is actually something I've thought about for a while, but never
brought up (dunno why). I'd like to see urpmi become more popular,
and
possibly adopted by other distros. A fellow locally tried to get
urpmi
working on a RH system... he couldn't rebuild it, but he could install
it from what I understood, his preliminary tests worked (ie. he could
urpmi djbdns-localcache and it worked, even if the packages
themselves wouldn't work as they're highly mdk-specific).
Francois? What do you think about adding this feature? It could be
something configurable in a /etc/urpmi/sigs.conf or something; if
there
is no entry for a mirror, then do the normal thing, but if the entry
exists, not only check that the gpg sig is ok, but make sure the fp
matches the appropriate source.
Just a thought. What do you guys think?
The whole idea is interesting, but i don't understand why those keys
have to
be in a package, not in just another file with other uprmi data files.
Because then it's easy to forge. There has to be some form of
authentication there. If we put RPM-GPG-KEYS files on the mirrors,
what happens if a mirror gets tampered with? Someone can replace that
file with their own key easily. If urpmi automatically adds it to the
keyring, and there's a trojan rpm, signed with that trojaned key, then
urpmi will happily install it as it passes the gpg key check. By the
time someone notices it, it will be too late for other people. This is
one reason why, in updates, the md5sums files are signed. That way if
it's tampered with, someone will know quickly.
Moreover, gpg itself has a nice auto-retrieve option for automatic
download of
missing keys from keyserver. Provided keys used for signing packages
are
available there, it seems sufficient for me.
I never use this. I don't like keys being automatically added to my
keyring. It's too easy for abuse. If someone is root and reads an
email that is signed by some key and it is automatically retrieved,
that key will be added to the keyring. That unknown individual can do
the same thing then... trojan an rpm, sign it with their key (which I
automatically downloaded) and again urpmi passes the check.
This is why mapping fingerprints to a particular server (or type of
source) is important. It prevents this sort of thing from happening.
Better yet, there should be a keyring outside of root's keyring that is
read-only by users and read/write by root (not in /root/.gnupg) that
contains rpm gpg keys. That removal from the user environment
(especially root) adds another level of integrity.
I'm all for having every source out there urpmiable and easily setup
through urpmi, even via the installer. But before that is done, we
have to add a little security to the system. We have a responsibility
to, in all ways possible, make installing trojan packages as difficult
as possible. I'm all for making things easier, but not at the expense
of security.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
I agree, it would be a great thing! Why not putting mdk pubkey into RPM gnupg package? Pierre Le mar 29/10/2002 à 15:47, Brad Felmey a écrit : How about putting your signing keys into a package that adds them to root's pubring? -- Brad Felmey signature.asc Description: PGP signature
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
On Tuesday, October 29, 2002, at 07:47 AM, Brad Felmey wrote:
How about putting your signing keys into a package that adds them to
root's pubring?
This is already done by gnupg package proper. Root should have 3 keys
on their keyring... two official packaging keys (for cooker/distrib),
and one for security updates.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
On Tue, Oct 29, 2002 at 08:47:26AM -0600, Brad Felmey wrote: How about putting your signing keys into a package that adds them to root's pubring? However this does bring up an interesting idea. Having urpmi/rpmdrake know where to find the GPG keys for various sources. I would propose that a file name is made as a standard for the key for a source that is placed in the same path as the hdlist/synthesis file. That file would contain a name or names of packages that contained the sites GPG keys. On the first install from that source urpmi/rpmdrake would prompt the user if they wished to install this key. The file would then be downloaded and installed prior to any other package installations. In the future if the key would need upgrading the version/release could be incremented causing urpmi/rpmdrake to update it. urpmi/rpmdrake would store the package name(s) of the keys. So it would always cause that package to be updated in a separate rpm call prior to updating the rest of the packages. To ensure the keys and there is a trust chain it's possible Mandrake could sign the packages for these people. I don't think there are a lot of sites using the urpmi system. But perhaps Mandrake signing the packages would be a bad idea for trust and work load issues. Just a thought. What do you guys think? -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If you're not making any mistakes, you're flat out not trying hard enough. - Jim Nichols
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
Wonderful idea, perfect solution. --- Ben Reser [EMAIL PROTECTED] wrote: Having urpmi/rpmdrake know where to find the GPG keys for various sources. I would propose that a file name is made as a standard for the key for a source that is placed in the same path as the hdlist/synthesis file. That file would contain a name or names of packages that contained the sites GPG keys. On the first install from that source urpmi/rpmdrake would prompt the user if they wished to install this key. The file would then be downloaded and installed prior to any other package installations. In the future if the key would need upgrading the version/release could be incremented causing urpmi/rpmdrake to update it. urpmi/rpmdrake would store the package name(s) of the keys. So it would always cause that package to be updated in a separate rpm call prior to updating the rest of the packages. To ensure the keys and there is a trust chain it's possible Mandrake could sign the packages for these people. I don't think there are a lot of sites using the urpmi system. But perhaps Mandrake signing the packages would be a bad idea for trust and work load issues. Just a thought. What do you guys think? __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [Cooker] Suggestion: mdk-gpg-keys-1.0-1mdk
On Tuesday, October 29, 2002, at 11:02 AM, Ben Reser wrote:
How about putting your signing keys into a package that adds them to
root's pubring?
However this does bring up an interesting idea. Having urpmi/rpmdrake
know where to find the GPG keys for various sources. I would propose
that a file name is made as a standard for the key for a source that is
placed in the same path as the hdlist/synthesis file. That file would
contain a name or names of packages that contained the sites GPG keys.
This takes a little more careful thought. Putting GPG keys up without
any kind of verification of the source can cause problems. For
instance, suppose that PLF has a GPG key and we provide it in a
package. Because it's on the keyring, urpmi will happily not complain
if a PLF key is found in updates. What happens if PLF goes rogue,
hacks into a mirror, and starts replacing updates packages with trojans
that are signed with the PLF key? urpmi will install them without
complaint. Now, I'm not saying the PLF folks are going to do this...
=) This could easily be someone stealing their private key and doing
it.
But you should see my point.
On the first install from that source urpmi/rpmdrake would prompt the
user if they wished to install this key. The file would then be
downloaded and installed prior to any other package installations.
I don't like this. The user should have to make some sort of effort to
install these keys manually, or they should be in a MandrakeSoft-signed
package. For instance, an rpm-gpg-keys package, provided by
MandrakeSoft, signed by MandrakeSoft's key.
In the future if the key would need upgrading the version/release could
be incremented causing urpmi/rpmdrake to update it. urpmi/rpmdrake
would store the package name(s) of the keys. So it would always cause
that package to be updated in a separate rpm call prior to updating the
rest of the packages.
To ensure the keys and there is a trust chain it's possible Mandrake
could sign the packages for these people. I don't think there are a
lot
of sites using the urpmi system. But perhaps Mandrake signing the
packages would be a bad idea for trust and work load issues.
Yup, my thought exactly. Also, urpmi would need to change before I'd
advocate something like this. With apt you can define a key
fingerprint that matches a particular source. For instance, one could
map the security key fp to the updates source; the mdksoft official key
to the cooker or distrib (ie. cd's) source. The logical step is then
to map the rpmhelp key to rpmhelp.net, plf's key to plf, etc.
Until urpmi can do this (Francois?), we shouldn't entertain this idea.
It opens up too many possibilities I'm not comfortable with. Having
urpmi do this sort of checking would make it a lot safer and, as a
result, a good idea. But it's not a good idea with urpmi as it is now.
This is actually something I've thought about for a while, but never
brought up (dunno why). I'd like to see urpmi become more popular, and
possibly adopted by other distros. A fellow locally tried to get urpmi
working on a RH system... he couldn't rebuild it, but he could install
it from what I understood, his preliminary tests worked (ie. he could
urpmi djbdns-localcache and it worked, even if the packages
themselves wouldn't work as they're highly mdk-specific).
Francois? What do you think about adding this feature? It could be
something configurable in a /etc/urpmi/sigs.conf or something; if there
is no entry for a mirror, then do the normal thing, but if the entry
exists, not only check that the gpg sig is ok, but make sure the fp
matches the appropriate source.
Just a thought. What do you guys think?
--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
PGP.sig
Description: PGP signature
Re: [Cooker] suggestion for systems with VIA sound chips
Todd Lyons wrote: O'Riordan, Kevin wrote on Wed, Sep 11, 2002 at 04:08:46PM +0100 : I tried using the snd-via686 module, but sound is very very choppy when using esound or the xine alsa module. Sound is okay when using arts through alsa, or oss emulation. Sound is also okay with the via82cxxx module. Am running latest cooker with 2.4.19-9mdk kernel. I recall seeing someone say that setting in the XF86Config-4 file the following made a difference in sound working properly for them: Option PciRetry true You could serve as a guinea pi^W^W baseline if you would try adding this option. I also use via686. I just added this option to my XF86Config-4 file (currently Mandrake 8.2 box), running this box for few hours now, and the cranked sound with esd seems to go away. (Previously I got choppiness sometimes when Mozilla draw its contents and I played through esd). So at the very least, I think it won't hurt to add it. Michal Bukovjan
RE: [Cooker] suggestion for systems with VIA sound chips
I tried using the snd-via686 module, but sound is very very choppy when using esound or the xine alsa module. Sound is okay when using arts through alsa, or oss emulation. Sound is also okay with the via82cxxx module. Am running latest cooker with 2.4.19-9mdk kernel. -Original Message- From: Reinout van Schouwen [mailto:[EMAIL PROTECTED]] Sent: 07 September 2002 23:04 To: [EMAIL PROTECTED] Subject: Re: [Cooker] suggestion for systems with VIA sound chips Hi, Well I be it works! I have an onboard via sound chip that uses the via82cXXX and ac97 kernel modules and sound has always been problematic especially games like RTCW. Now it works fine. It doesn't seem to affect other sound Of course, you could also just ditch the via82cxxx driver and use the ALSA snd-via686 module instead.. :-) -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
RE: [Cooker] suggestion for systems with VIA sound chips
On Wed, 2002-09-11 at 10:08, O'Riordan, Kevin wrote: I tried using the snd-via686 module, but sound is very very choppy when using esound or the xine alsa module. Sound is okay when using arts through alsa, or oss emulation. Sound is also okay with the via82cxxx module. Am running latest cooker with 2.4.19-9mdk kernel. I also tried the ALSA snd-via686 module, and it refused to load, giving all manner of bad symbol errors. Nothing I could do would make it load. Switched back to the via82cxxx module, and sound works just fine again. MSI MS-6330 K7T Turbo 2 system board. -- Brad Felmey
Re: [Cooker] suggestion for systems with VIA sound chips
On Wed, Sep 11, 2002 at 12:29:29PM -0500, Brad Felmey wrote: On Wed, 2002-09-11 at 10:08, O'Riordan, Kevin wrote: I tried using the snd-via686 module, but sound is very very choppy when using esound or the xine alsa module. Sound is okay when using arts through alsa, or oss emulation. Sound is also okay with the via82cxxx module. Am running latest cooker with 2.4.19-9mdk kernel. I also tried the ALSA snd-via686 module, and it refused to load, giving all manner of bad symbol errors. Nothing I could do would make it load. Switched back to the via82cxxx module, and sound works just fine again. What did you do to load the module ? insmod of course won't work, modprobe should resolve missing symbols. It would be better you'd post the exact error message and what you did. Also: Have you tried switching to snd-via686 with draksound ? Warning: It only shows the driver to which you can switch. I have via sound on board chipset as well and it works without any problems here. (Sony Vaio FX301 laptop with AMD Duron). MSI MS-6330 K7T Turbo 2 system board. -- Brad Felmey Regards, Reinhard Katzmann -- Software-Engineer, Developer for Embedded Devices Project: Pertergrin, a role playing game system GnuPG Public Key available on request msg74948/pgp0.pgp Description: PGP signature
Re: [Cooker] suggestion for systems with VIA sound chips
On Wed, 2002-09-11 at 12:42, Reinhard Katzmann wrote: What did you do to load the module ? Tried both modprobe and (after modprobe failed) insmod. Also: Have you tried switching to snd-via686 with draksound ? Yes, also did not work. # lspcidrake -v snip via82cxxx_audio : VIA Technologies|VT82C686 [Apollo Super AC97/Audio] [MULTIMEDIA_AUDIO] (vendor:1106 device:3058 subv:1462 subd:3300) snip
Re: [Cooker] suggestion for systems with VIA sound chips
Hi Brad, On Wed, Sep 11, 2002 at 01:41:48PM -0500, Brad Felmey wrote: On Wed, 2002-09-11 at 12:42, Reinhard Katzmann wrote: What did you do to load the module ? Tried both modprobe and (after modprobe failed) insmod. Also: Have you tried switching to snd-via686 with draksound ? Yes, also did not work. # lspcidrake -v snip via82cxxx_audio : VIA Technologies|VT82C686 [Apollo Super AC97/Audio] [MULTIMEDIA_AUDIO] (vendor:1106 device:3058 subv:1462 subd:3300) snip My one looke like this: via82cxxx_audio : VIA Technologies|VT82C686 [Apollo Super AC97/Audio] [MULTIMEDIA_AUDIO] (vendor:1106 device:3058 subv:104d subd:80e3) So it seems we have different devices (at least according to subv and subd). Also I have to admin that I did not yet update to rc2 from beta4 as I'm waiting for my new hard drive to come. Tonight is too late, but if the drive does not arrive tomorrow, I'll try a custom 9mdk kernel on my laptop. Regards, Reinhard Katzmann -- Software-Engineer, Developer for Embedded Devices Project: Pertergrin, a role playing game system GnuPG Public Key available on request msg74975/pgp0.pgp Description: PGP signature
Re: [Cooker] suggestion for systems with VIA sound chips
O'Riordan, Kevin wrote on Wed, Sep 11, 2002 at 04:08:46PM +0100 : I tried using the snd-via686 module, but sound is very very choppy when using esound or the xine alsa module. Sound is okay when using arts through alsa, or oss emulation. Sound is also okay with the via82cxxx module. Am running latest cooker with 2.4.19-9mdk kernel. I recall seeing someone say that setting in the XF86Config-4 file the following made a difference in sound working properly for them: Option PciRetry true You could serve as a guinea pi^W^W baseline if you would try adding this option. Looking...Here is the original message. Hmmm, it's this same thread :( so you've probably already seen it and it didn't work. But doesn't hurt ot post it again. Good luck ---Forwarded message Date: Sat, 7 Sep 2002 02:25:26 -0400 From: Levi Ramsey [EMAIL PROTECTED] User-Agent: Mutt/1.4i To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: [Cooker] suggestion for systems with VIA sound chips There is a problem which exists on many systems with VIA 82C686 sound chips where X causes the sound to become crackly. This behavior can be fixed by adding the following to the Device section of /etc/X11/XF86Config-4: Option PciRetry true Would it be possible for DrakX to, if it detects the presence of this sound chip, to make this addition? -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The way out is the way in... Linux 2.4.19-4mdklrr 2:15am up 1 day, 4:46, 7 users, load average: 0.53, 0.29, 0.20 -- Todd Lyons -- MandrakeSoft, Inc. http://www.mandrakesoft.com/ UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-9mdk msg75018/pgp0.pgp Description: PGP signature
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
Guillaume Cottenceau wrote: Aleksander Adamowski [EMAIL PROTECTED] writes: First, I've tried to conduct an upgrade from 9.0 beta4 to 9.0 RC1 That's a side note to your report, but - people should not do upgrades from a beta version to another, because bugs from the first may add to the second. People should do upgrades from the previous stable version to the latest cooker/beta/rc, e.g. for currently, from 8.2 to RC2. Thanks! I did an upgrade from 8.1 to 9.0RC1. Is this invalid behavior? Should I have upgraded from 8.1 to 8.2 and then to 9.0RC1? (I did have some problems, see previous post) Upgrading that machine from 8.1 to 8.2 didn't work, by the way. There was some problem in the installer related to disks that I can't remember at the moment. Would be nice if people could skip a version when upgrading when this kind of thing happens. I am cc:'ing you on this message because the last two messages I sent to the cooker list didn't show up.
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
Hal Black [EMAIL PROTECTED] writes: People should do upgrades from the previous stable version to the latest cooker/beta/rc, e.g. for currently, from 8.2 to RC2. Thanks! I did an upgrade from 8.1 to 9.0RC1. Is this invalid behavior? Well it *should* work, but the farther between the two releases, the harder for us to let it work :-). Should I have upgraded from 8.1 to 8.2 and then to 9.0RC1? (I did have some problems, see previous post) I think you should upgrade directly from 8.1 to latest. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] suggestion for systems with VIA sound chips
On Sun, 8 Sep 2002 05:34, allen wrote: Right now I cannot install RC1 into VMWare for a variety of odd reasons that I hope are being addressed. Oooh, yah, why do you bury us in such overwhelmingly specific detail? (-: Cheers; Leon
Re: [Cooker] Suggestion for future 9.1 installer
On Sat, 7 Sep 2002 06:15, Igor Izyumin wrote: Also, can we have a retry button when a package fails to install? I often get problems with packages when installing over the network or on old CDROMs, and it would really help. Currently, there is only an option to cancel or continue. Is it really that hard to implement? And the option to *not* bail out *at*the*end* of the installation if some packages didn't make it? I can understand mandating a reinstall if (e.g.) glibc installation karks it but think it's a bit excessive if (e.g.) xbill bites the dust. Sorry if the idioms are hard on ESL people, but I like them. (-: Cheers; Leon
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
Aleksander Adamowski [EMAIL PROTECTED] writes: First, I've tried to conduct an upgrade from 9.0 beta4 to 9.0 RC1 That's a side note to your report, but - people should not do upgrades from a beta version to another, because bugs from the first may add to the second. People should do upgrades from the previous stable version to the latest cooker/beta/rc, e.g. for currently, from 8.2 to RC2. Thanks! -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] suggestion for systems with VIA sound chips
Levi Ramsey [EMAIL PROTECTED] writes: There is a problem which exists on many systems with VIA 82C686 sound chips where X causes the sound to become crackly. This behavior can be fixed by adding the following to the Device section of /etc/X11/XF86Config-4: Option PciRetry true Would it be possible for DrakX to, if it detects the presence of this sound chip, to make this addition? it could be. but: - are you sure it *can't* break anything, esp. that it works for every video card - do you have a web page explaining this - i'd rather have this added only for a sound card/video card combination
Re: [Cooker] Suggestion cdrom recognition
On Fri, 6 Sep 2002, Igor Izyumin wrote: On Friday 06 September 2002 03:24 am, Buchan Milne wrote: There are sometimes issues when using ide-scsi on non-burners. I have had some problems, it seems that I can't use supermount on my writer if I use ide-scsi on my dvd/cdrom, so I don't think ide-scsi should be the default for CDROMs/DVDs when a writer is detected (although we might want more opinions on this). That would be a very bad thing. CDROMs have to be SCSI [or emulated] for CD copying programs to work, and few people want to use their CD burner for reading CDs. Could you be more clear on what is bad (that, it etc are very bad words to use as a subject, since they are ambiguous). I was saying: 1)ide-scsi should not be the default for CD-ROM or DVD-ROM drives, unless we can test this on every single combination of CD-RW and CD-ROM/DVD-ROM, since there are problems that could be more serious than not being able to copy a CD (like not being able to use the writer at all, which is the case if I use ide-scsi on the CD-ROM/DVD-ROM and supermount on the CD-RW) 2)It should be easy for a user to use ide-scsi on a CD-ROM/DVD-ROM drive, so that they can set it that way, and set it back if they have problems. Since Pixel (apparently, I still haven't been able to test) added this to drakconf, this is the current status. Needing to be able to do CD-to-CD copies is normally illegitemate use of a CD-RW drive, and IMHO, legitemate use should take preference (being able to backup data on the hard disk or master CDs, or write ISO images, as opposed to being able to copy a software or audio CD). Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Suggestion cdrom recognition
Buchan Milne [EMAIL PROTECTED] writes: 2)It should be easy for a user to use ide-scsi on a CD-ROM/DVD-ROM drive, so that they can set it that way, and set it back if they have problems. Since Pixel (apparently, I still haven't been able to test) added this to drakconf, this is the current status. let me say that there's no such thing as switching back and forth from ide-scsi. you can do it by changing the append line in drakboot, and harddrake should help you changing the line in fstab
Re: [Cooker] Suggestion cdrom recognition
On Sat, 2002-09-07 at 12:26, Buchan Milne wrote: Needing to be able to do CD-to-CD copies is normally illegitemate use of a CD-RW drive, and IMHO, legitemate use should take preference (being able to backup data on the hard disk or master CDs, or write ISO images, as opposed to being able to copy a software or audio CD). This is *absolutely* not the business of a distribution to decide. The purpose of an operating system is to enable maximum possible usage of the resources available to a user. It should leave legitimate and illegitimate uses to the user, his/her conscience, and the law enforcement authorities to decide. -- adamw
Re: [Cooker] Suggestion cdrom recognition
On 7 Sep 2002, Adam Williamson wrote: On Sat, 2002-09-07 at 12:26, Buchan Milne wrote: Needing to be able to do CD-to-CD copies is normally illegitemate use of a CD-RW drive, and IMHO, legitemate use should take preference (being able to backup data on the hard disk or master CDs, or write ISO images, as opposed to being able to copy a software or audio CD). This is *absolutely* not the business of a distribution to decide. The purpose of an operating system is to enable maximum possible usage of the resources available to a user. It should leave legitimate and illegitimate uses to the user, his/her conscience, and the law enforcement authorities to decide. But if you have to choose between users being able to: 1)Write CDs, and change an option to be ablee to CD-to-CD copy or 2)Possibly be able to CD-to-CD copy, but possibly not be able to write CDs at all I think it would be idiotic to use number 2 without determining what the probability is. There clearly isn't time for that now anyway. -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Suggestion cdrom recognition
On Sat, Sep 07, 2002 at 01:26:32PM +0200, Buchan Milne wrote: On Fri, 6 Sep 2002, Igor Izyumin wrote: That would be a very bad thing. CDROMs have to be SCSI [or emulated] for CD copying programs to work, and few people want to use their CD burner for reading CDs. Far from true. Many new PCs come with *only* a CD burner, and many buyers of such PCs never use those to burn a CD. My wife has a PC with a reader and a writer (an old, 4X one of mine) and she only ever uses it to read CDs, she thinks it's great just being able to have two CDs mounted at the same time. I occasionaly use it to back up some of her stuff, never to copy CDs. Even on my own PC, I usually copy to ISO on the hard drive first, it makes it much faster to retry when the first attempt fails, which happens less often with this technique anyway. 2)It should be easy for a user to use ide-scsi on a CD-ROM/DVD-ROM drive, so that they can set it that way, and set it back if they have problems. It seems as though, if it were desired to make this easier for people, a good way to do it would be to simply add an additional boot option that appends the right module in the correct manner, so that people didn't have to muck with lilo.conf or the boot command line or whatever. --Bob Drzyzgula
Re: [Cooker] Suggestion cdrom recognition
On Sat, 2002-09-07 at 13:14, Buchan Milne wrote: But if you have to choose between users being able to: 1)Write CDs, and change an option to be ablee to CD-to-CD copy or 2)Possibly be able to CD-to-CD copy, but possibly not be able to write CDs at all I think it would be idiotic to use number 2 without determining what the probability is. There clearly isn't time for that now anyway. Of course. This isn't the point I was debating. I was worried by the separate implications of your statement. -- adamw
Re: [Cooker] suggestion for systems with VIA sound chips
On Saturday 07 September 2002 01:25 am, Levi Ramsey wrote: There is a problem which exists on many systems with VIA 82C686 sound chips where X causes the sound to become crackly. This behavior can be fixed by adding the following to the Device section of /etc/X11/XF86Config-4: Option PciRetry true Would it be possible for DrakX to, if it detects the presence of this sound chip, to make this addition? Well I be it works! I have an onboard via sound chip that uses the via82cXXX and ac97 kernel modules and sound has always been problematic especially games like RTCW. Now it works fine. It doesn't seem to affect other sound card such as the Soundblaster Live etc... Maybe a few more testers could try it and see how it works. Anyway thank you so much Levi, you just made my day, now back to RTCW.
Re: [Cooker] suggestion for systems with VIA sound chips
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pixel wrote: | Levi Ramsey [EMAIL PROTECTED] writes: | | |There is a problem which exists on many systems with VIA 82C686 sound chips |where X causes the sound to become crackly. This behavior can be fixed |by adding the following to the Device section of /etc/X11/XF86Config-4: | | Option PciRetry true | |Would it be possible for DrakX to, if it detects the presence of this |sound chip, to make this addition? | | | it could be. but: | | - are you sure it *can't* break anything, esp. that it works for every | video card | | - do you have a web page explaining this | | - i'd rather have this added only for a sound card/video card | combination | I'll try to give this a shot on the Compaq Presario 700 series of laptops to potentially confirm the Via Twister chips (Savage 4 core), they exibit the crackling sound and have that same chip. Unfortunately, I can't get to this right away. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj16bdoACgkQUMkt1ZRwL1M52ACdGEF95CoTbZeHHg1qNA3NIIks dVEAoLdlDEazTJJ9kHGmuDjdCtnrtegp =HP3u -END PGP SIGNATURE-
Re: [Cooker] suggestion for systems with VIA sound chips
On Saturday 07 September 2002 04:21 pm, Richard Houser wrote: Pixel wrote: Option PciRetry true I'll try to give this a shot on the Compaq Presario 700 series of laptops to potentially confirm the Via Twister chips (Savage 4 core), they exibit the crackling sound and have that same chip. Unfortunately, I can't get to this right away. FYI I have a Presario 715, AMD, 1.4Ghz, 512MB RAM now. I would be happy to try this. However, I will have to be able to install into VMWare, and it would have to be known to work that way. Right now I cannot install RC1 into VMWare for a variety of odd reasons that I hope are being addressed. ? -AEF
Re: [Cooker] suggestion for systems with VIA sound chips
On Sat Sep 07 12:26 +0200, Pixel wrote: Levi Ramsey [EMAIL PROTECTED] writes: There is a problem which exists on many systems with VIA 82C686 sound chips where X causes the sound to become crackly. This behavior can be fixed by adding the following to the Device section of /etc/X11/XF86Config-4: Option PciRetry true Would it be possible for DrakX to, if it detects the presence of this sound chip, to make this addition? it could be. but: - are you sure it *can't* break anything, esp. that it works for every video card - do you have a web page explaining this - i'd rather have this added only for a sound card/video card combination I picked this up from question 3.2 of the Mini ITX FAQ at http://www.mini-itx.com/faq.asp The answer to that question only mentions the OSS driver (via82cxxx_audio); whether this has any effect on the ALSA drivers is an open question. I added the line to my configuration and it seems to fix the crackling problems. Oddly enough, I'm using XFree86's nv driver, which does not list itself as supporting this option. However, it does not seem to have adverse effects on system stability. So it seems to work in the nv/via82cxxx case. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The way out is the way in... Linux 2.4.19-4mdklrr 5:30pm up 1 day, 20:01, 7 users, load average: 0.17, 0.11, 0.15
Re: [Cooker] suggestion for systems with VIA sound chips
Hi, Well I be it works! I have an onboard via sound chip that uses the via82cXXX and ac97 kernel modules and sound has always been problematic especially games like RTCW. Now it works fine. It doesn't seem to affect other sound Of course, you could also just ditch the via82cxxx driver and use the ALSA snd-via686 module instead.. :-) -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] Suggestion cdrom recognition
Hi, Thanks I need to upgrade again, my version of mcc doesn't have that yet. Yes, in the past I've done similar mod's to my machine but it doesn't always work. Usually happens when it's for someone else and it's not easy to get newbies to modify the system via command line if it didn't work straight up. dcd. ps Maybe in part because Iv'e only just passed newbie stage into tinkerer myself Buchan Milne wrote: There are sometimes issues when using ide-scsi on non-burners. I have had some problems, it seems that I can't use supermount on my writer if I use ide-scsi on my dvd/cdrom, so I don't think ide-scsi should be the default for CDROMs/DVDs when a writer is detected (although we might want more opinions on this). However, I requested that it be an option be added to MCC to be able to switch CD-ROMs to ide-scsi, and Pixel apparently did add it, I haven't had a chance to test it yet (CD-ROM drive on this machine is stuffed, so ~ it's disconnected). Please test this if you can. Anyway, all that is needed (AFAICR) is to add 'hdX=ide-scsi' to lilo.conf, run lilo, reboot. Buchan
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
I saw this bug while I was installing, and the installation failed(fresh install), I really don't know if this had anything to do with the cause, but I tried once again to do the install and it succeeded. The only thing that I did different was remove a DVD that I had forgotten to remove from my dvd- rom. Again, I don't know if that could cause the problem I saw, but I know that after removing the DVD and trying the install once again it succeeded without a single error. Also during beta4 I had a very similar problem with my USB compactflash/smartmedia card reader plugged in. Failed the install, unplugged the reader and tried again and install went off without a hitch. Aleksander Adamowski [EMAIL PROTECTED] said: Hi! I were trying to hunt for that dreaded mkinitrd bug in RC1. First, I've tried to conduct an upgrade from 9.0 beta4 to 9.0 RC1 on my machine at home during the weekend, but during the packages installation process there was a power outage. I've continued the upgradeafter the power had been restored, but some packages were left in a hosed state. The mkinitrd failed during that install, but since the installation of packages has been interrupted, I can't say that the bug really is here. Maybe some leftover beta4 packages were causing it. Second, yesterday I've tried to upgrade an old machine at work that has 8.2 installed. It has an old CD-ROM drive, so this time there were some errors about packages being not readable from the CD. The problem with mkinitrd also appeared - after the reboot there was no initrd-2.4.19-7mdk.img, but there was vmlinuz-2.4.19-7mdk. In /boot, the vmlinuz symlink pointed at the new kernel, the initrd.img symlink pointed at the old initrd. You know what are the results - kernel panic on boot. I've used the rescue mode from RC1 CD1 to mount filesystems, chroot, mount /proc and run mkinitrd manually, then correct symlinks in /boot and run lilo. But I still don't know for sure whether the mkinitd problem exists in RC1, or whether interrupted installations are at fault. Two installations in a row were hosed by external circumstances (power outage, defective CD-ROM drive?). Those things happen. So my suggestion is: make the installer fully bulletproof, so that you can literally pull the plug during installation. Particularly the packages installation phase - it takes the most time, it has the highest probability of being interrupted. E.G.: * When installing a portion of packages as a transaction: 1. create a file in the root fs named .mdk9.1_install_transactions_to_perform (or .mdk9.1_upgrade_transactions_to_perform, depending on installation class). It should contain all the information about RPM transaction that is to be executed, and about all the transactions that are planned after that, and all the information about the state of installation that is needed to resume it in case of a failure. 2. after writing contents, close that file. 3. sync. 4. conduct the RPM transaction. 5. sync. 6. optionally, sleep for e.g. 2 seconds 7. rename .mdk9.1_install_transactions_to_perform to .mdk9.1_last_committed_transaction 8. sync 9. GOTO 1. * When ending Install system stage: 1. Delete the file .mdk9.1_install_transactions_to_perform and the likes from the root filesystem * When booting from the install CD, after initial installer steps: 1. ask the user for installation class (as currently, Recommended/Expert, Install/Upgrade/Upgrade packages only) 2. detect harddrive, locate the original root filesystem, see whether the files like .mdk9.1_install_transactions_to_perform exist. 3. try to parse the file to determine what transaction needs to be replayed (with --force) and how the installation is to be continued. If its contents cannot be parsed = there was a power down when it was being written to = try to parse .mdk9.1_last_committed_transaction - it is good with 100% probability. 4. replay the transaction mentioned in the file with --force (there is a chance that transaction was hosed, so better to replay it) 5. continue the installation according to data found in that .mdk91* file. -- Just when you think you were making progress you realize that you were facing backwards.
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
David Bolin [EMAIL PROTECTED] writes: Also during beta4 I had a very similar problem with my USB compactflash/smartmedia card reader plugged in. Failed the install, unplugged the reader and tried again and install went off without a hitch. this should be ok now (in rc1, and the rc2-to-come)
Re: [Cooker] Suggestion cdrom recognition
On Friday 06 September 2002 03:24 am, Buchan Milne wrote: There are sometimes issues when using ide-scsi on non-burners. I have had some problems, it seems that I can't use supermount on my writer if I use ide-scsi on my dvd/cdrom, so I don't think ide-scsi should be the default for CDROMs/DVDs when a writer is detected (although we might want more opinions on this). That would be a very bad thing. CDROMs have to be SCSI [or emulated] for CD copying programs to work, and few people want to use their CD burner for reading CDs. -- -- Igor
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof (will make debugging cooker easier)
Also, can we have a retry button when a package fails to install? I often get problems with packages when installing over the network or on old CDROMs, and it would really help. Currently, there is only an option to cancel or continue. Is it really that hard to implement? -- -- Igor
Re: [Cooker] Suggestion for future 9.1 installer: make it more failure-proof(will make debugging cooker easier)
Igor Izyumin wrote: Also, can we have a retry button when a package fails to install? I often get problems with packages when installing over the network or on old CDROMs, and it would really help. Currently, there is only an option to cancel or continue. Is it really that hard to implement? I'd like that too. It can help when the installation CD is dirty, you can unmounteject it, clean it, insert into the drive, mount and then you'd have a chance that retry succeeds. It's ridiculous if a small lump of dirt on an installation CD's surface can ruin your 2-hour install... :(
Re: [Cooker] Suggestion cdrom recognition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dcd wrote: | Hi, |Not sure where this should be addressed to but here goes. | | I've been using mandrake for a while now myself and the most common | complaint I get from other new users | is as follows |It recognised my cdburner (and called it scsi-ide) | But I cant get any of the cdburning programs to recognise my cdrom(atapi | ide) so I can burn on the fly like i do in windows. | | My suggestion is that detection of a cd burner, then alters any atapi | cdroms detected to be scsi-ide links also. | Can these co-exist with the std setup, ie links created but not obvious | at the GUI level except when detected by programs such as xcdroast. | | dcd | IMHO this would make the whole cdrom cdburning experience much easier | especially as most howtos convert your cdrom to scsi-ide are written | for the old /dev system no longer used by Mandrake There are sometimes issues when using ide-scsi on non-burners. I have had some problems, it seems that I can't use supermount on my writer if I use ide-scsi on my dvd/cdrom, so I don't think ide-scsi should be the default for CDROMs/DVDs when a writer is detected (although we might want more opinions on this). However, I requested that it be an option be added to MCC to be able to switch CD-ROMs to ide-scsi, and Pixel apparently did add it, I haven't had a chance to test it yet (CD-ROM drive on this machine is stuffed, so ~ it's disconnected). Please test this if you can. Anyway, all that is needed (AFAICR) is to add 'hdX=ide-scsi' to lilo.conf, run lilo, reboot. Buchan - -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9eGZUrJK6UGDSBKcRAmmfAKCemMUxHokRUm1lL9IaQZR5Y3VYmQCghaQa MxCGpcnE917CPSvbcWLmZ6Y= =jnUS -END PGP SIGNATURE-
