Re: Do you really want developers to be on this list was (Re: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions)
On Thu, Nov 13, 2008 at 8:55 PM, Mackenzie Morgan [EMAIL PROTECTED] wrote: On Thu, 2008-11-13 at 20:36 +1100, Sarah Hobbs wrote: Take the intel 3945 card, for example. Vincenzo says it doesn't work for him, under various modes. Various users on the forums have also mentioned that their systems don't work with these cards. However, other users on the forums, mailing lists, and a whole lot of the developers, including myself, have this card, and see that it works for them. I personally haven't seen this break since I upgraded to gutsy back at the UDS in Sevilla, 2007 (ie, pre-alpha 1), and I use WPA, which seems to be one of the areas of complaint, otherwise without problems. In my experience, it does work fine with WPA. It's WEP that's the issue. It only works with WEP (properly) using iwconfig. If you use NetworkManager, the key will *never* be accepted. And if you use network-admin (gone in Intrepid), the key will be accepted, but it won't get an IP address. And yet, my intel 3945 works fine with me with WEP NetworkManager both in Hardy and Intrepid. Don't forget there are multiple sub-models of a given model. Please report your detailled hardware information (lspci -vvnn) on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253697 (Intel 3945 Wireless in Hardy cannot negotiate WEP or WPA Keys) or/and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/223174 (Intel WLAN, 3945 (a/b/g) - low performance). -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Ubuntu Brainstorm 8.10 report
Hello there! I wrote a small document about Ubuntu Brainstorm trying to summarize what's going on there (with a few stats), what you can expect from it, a summary of the most wanted features from its users, and its impact. I wrote this hoping to give to contributors and developers (not limited to Ubuntu) some clues of the most asked features out there, and what worries our users the most. You can grab it here: http://www.ndeschildre.net/downloads/UbuntuBrainstorm810Report.html Cheers, Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorm ML and Ubuntu's own summer of code?
I wrote a blueprint on this Summer-of-code-like event. If anyone is interested to comment, discuss... it's here: https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-own-summer-of-code/ Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Brainstorm ML and Ubuntu's own summer of code?
Hi! [You are receiving this mail because either you are suscribed to the ubuntu-devel-discuss/ubuntu-qa ML or you are registered as a moderator in Ubuntu Brainstorm] Hardy is now out, and the UDS and FOSScamp are next. The ideas at the Ubuntu Brainstorm website will, or will not be a great source of inspiration during these events, we will see. Meanwhile, if you are interested as an Ubuntu developer to discuss how to make the website more efficient for you, to discuss its mechanism, or if you are interested as a Brainstorm moderator to comment your tools, please join the new Brainstorm Mailing list at https://launchpad.net/~brainstorm-dev. I would also like to take this opportunity to introduce an idea that I see as a natural follow-up to the Brainstorm website: an event similar to the Google Summer of Code, that would be launched every development cycle. Basically the concept would be similar to GSoC except that the motivation factor would not be money but the fact that the contribution would be included in Ubuntu's next version (granted it is completed on time). The event would cover Ubuntu extensions, and involves coding, but also packaging, documentation, i18n, A proposed schedule would be: selection of tasks at the UDS, one month for the pupils selection process, and the time remaining before feature freeze to complete the tasks. Finally, to make potential contributors benefit from it, the pupils would be asked to put online a report where they would explain how they worked. That's a rough idea yet that I'd like to discuss at the FOSScamp if people are interested. Please comment :) Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorm ML and Ubuntu's own summer of code?
On Thu, Apr 24, 2008 at 10:29 PM, Christian Csar [EMAIL PROTECTED] wrote: Finally, to make potential contributors benefit from it, the pupils would be asked to put online a report where they would explain how they worked. Who is being defined as a contributor here? Isn't this an organized program to encourage students to contribute? Or am I missing something. Although having a list of tasks seems likely to improve contribution as it makes things well defined. For this event, I would not see why we should limit the contributor definition to students... Anyone could pretend for a task. Christian -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorm ML and Ubuntu's own summer of code?
On Thu, Apr 24, 2008 at 9:52 PM, Alan McGovern [EMAIL PROTECTED] wrote: I'm speaking as someone who has taken part in the SoC as both a student and a mentor. From what i've seen, a SoC project always ends with the possibility of your code being bundled as part of a distribution or as part of an existing application. There's also the added bonus that you will be paid to do that. Taking mono as an example, at least 2/3's of the 2006 projects ended up shipping in various Linux distros or as part of mono itself. A similar percentage of the 2007 projects resulted in actively shipped code aswell. I'd like to think that this is one of the primary motivation factors in the SoC, with money being the added bonus. So the ubuntu SoC doesn't offer anything more than the google SoC does. It does not really offer anything more for the mentorees. But for the organizer, it obviously offers a much greater flexibility: dates adapted to the development cycle, choice of the number, contents and type of tasks (not only code tasks), control over the processes,... Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: A Look at the Ubuntu Installer
Very nice review, a lot of attention to detail. Let's hope it won't be forgotten in the depth of the ML, like many other great things... Have you directly contacted the authors? Nicolas On Jan 7, 2008 8:16 PM, Thorsten Wilms [EMAIL PROTECTED] wrote: Hi! I did a walk-through and compiled issues, suggestions and several mockups regarding the Ubuntu installation: http://thorwil.files.wordpress.com/2008/01/ubuntu_installer_thorwil.pdf Any comments welcome. I'm willing to refine things where and if there's interest. I could file requests if that's deemed helpful. The document is actually a bit older, but I decided to wait past the holidays ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands (was: rationale of root access from boot)
On Nov 12, 2007 2:15 PM, Scott James Remnant [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 14:06 +0800, Nicolas Deschildre wrote: [...] For the simplest installations, GRUB could perhaps read /etc/shadow and accept any user's password -- but that would be error-prone, open to exploit, and wouldn't support the kinds of installations you talk about later in this thread: corporate environments which often use centralised authentication. You're right, I overlooked that. And adding Jan Claeys' good remark on the keyboard layout, I'm now convinced that password protecting grub is not good by default. Thanks for your comments. This is EOT for me. Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands
On 11/11/07, Chris Warburton [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 17:41 +0100, Thilo Six wrote: Milan wrote the following on 10.11.2007 16:56 -snip- All in all, I'd rather suggest to activate password-locked GRUB, but I understand this question is hard to decide. Does anybody see other agruments on both sides? against: helping users on mailing lists or irc, with boot problems. Exactly. In my opinion password protecting GRUB by default will cause headaches for a number of people, True enough. If password protected GRUB was to be enabled, the necessary actions/patches should be done so that the users passwords can be used to unlock GRUB. (Currently only one password can be used in GRUB). but it won't really make the system any more secure since physical access is gained by that point (thus allowing live media, removing the hard drive, etc.). Gaining physical access doesn't always mean it's done. I mean, just one use case I have in mind : at an office with BIOS protected computers, lots of people passing by, I'd rather bet on a five minute snoop than to bring my screwdriver and start to dismantle my boss computer... The point is, don't make it too easy. The only extra security measure I think is worth debating is full disk encryption. Such a thing would obviously be a nightmare for tech support, but since there are real security benefits I think it is worth considering and at least looking into. To me there is very little to be gained by password protecting GRUB though, so I'm against. Thanks, Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands (was: rationale of root access from boot)
On 11/10/07, Thilo Six [EMAIL PROTECTED] wrote: Nicolas Deschildre wrote the following on 10.11.2007 07:06 -snip- Thanks for the pointer. But then, why not use this password feature by default to avoid anyone to edit boot parameter and become root? because it´s as easy as to plugin a LiveCD and overcome that. What about password protected BIOS and CD drive as last boot option? - You open up the case, take the hardrive Ok you have a house, you know that thieves can bypass advanced alarm systems by using cutting-edge technology tools, so why bother, you just let the door unlocked? Come on! Of course if you are really willing to get this data, if you put in the ressources, you will eventually have the data. The point is, *don't make it too easy*. -- Thilo key: 0x4A411E09 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Password-protect grub interactive commands (was: rationale of root access from boot)
On Nov 4, 2007 6:35 PM, Oystein Viggen [EMAIL PROTECTED] wrote: * [Nicolas Deschildre] My point was not about the parameter itself. My point was about the ability to edit the kernel parameters while booting. IIRC lilo won't allow you that. http://www.gnu.org/software/grub/manual/html_node/Security.html Thanks for the pointer. But then, why not use this password feature by default to avoid anyone to edit boot parameter and become root? Lilo has a similar password feature, but no distribution I've used had lilo passwords enabled by default. For rationale, it's just obnoxious when you finally need to boot to single user, and you get asked for a password that you haven't used since you installed the box. Øystein -- This message was generated by a flock of happy penguins. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: rationale of root access from boot
On 11/4/07, Paul [EMAIL PROTECTED] wrote: try init=/bin/bash, now do you think Linux is insecure because it has an init parameter? My point was not about the parameter itself. My point was about the ability to edit the kernel parameters while booting. IIRC lilo won't allow you that. Op zondag 04-11-2007 om 11:20 uur [tijdzone +0800], schreef Nicolas Deschildre: hi! I was wondering about the rationale of allowing anyone to easily boot root (by adding the 'single' parameter to the kernel command line with grub). While I can understand it on a server, which must be physically protected to be really secure, IMO it is pretty bad on workstations. I know that with some knowledge and perseverance, one can anyway get root access (Live CD, or if BIOS locked or no CD drive, open the box, take the drive), but here, with the 'single' parameter, it is an easy and discrete open door *out of the box*. IMO this is pretty bad security. Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
rationale of root access from boot
hi! I was wondering about the rationale of allowing anyone to easily boot root (by adding the 'single' parameter to the kernel command line with grub). While I can understand it on a server, which must be physically protected to be really secure, IMO it is pretty bad on workstations. I know that with some knowledge and perseverance, one can anyway get root access (Live CD, or if BIOS locked or no CD drive, open the box, take the drive), but here, with the 'single' parameter, it is an easy and discrete open door *out of the box*. IMO this is pretty bad security. Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Grouping preferences/Administration items?
The items in the gnome control panel are already grouped by categories (Hardware, Internet, system,...). Why not used theses groups in the System menu? Instead of current preferences/administration? This way it has advantages of both the system menu and the control panel : access easiness and logical organization. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request For Comments: blueprint around Ideastorm idea
On 9/15/07, Henrik Nilsen Omma [EMAIL PROTECTED] wrote: Hi Nicolas, Stéphane and I are working on some plans along these lines as a extension of the qa site (see: https://qa.stgraber.org/). We expect to have a demo up soon. Do you have a pointer to some blueprint or explanation on what you are planning? I would be interested to know what's your plans :) I agree that this would be a great feature for Launchpad in the future, but it will be useful to start with a prototype first. Henrik Nicolas Deschildre wrote: Hi! I have been drafting a blueprint around Dell's Ideastorm idea. Considering that the current means to get user wishes feedback is not really good (see discussion in the blueprint) and considering Ideastorm success for Dell, i was thinking of using this idea to assess the user wishes. Right now, when a user want to post a wish about ubuntu, where does he go? He goes to forums, where its posts is quickly lost in the mass. Or *if he know about it*, he goes to the bug report (bug! Not obvious!) to post a wish. But this wish report hardly represent the size of the wish. Is only one person interested by this wish, or thousands? or more? Consequently there is no real means to assess *quantitatively* and *effectively* the users wishes and needs. Thus the main guidelines of ubuntu development does not optimally match the users demand. Considering this, my blueprint try to propose a solution based on Ideastorm idea, and reusing Launchpad framework. Here it is : https://blueprints.launchpad.net/launchpad/+spec/better-community-wishes-assessment I would really appreciate any comments on this, and you are welcome to do some modifications you think appropriate. Especially I'd like to hear from Launchpad guys about the possible implementation of the spec. Thanks! Nicolas Deschildre -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Request For Comments: blueprint around Ideastorm idea
Hi! I have been drafting a blueprint around Dell's Ideastorm idea. Considering that the current means to get user wishes feedback is not really good (see discussion in the blueprint) and considering Ideastorm success for Dell, i was thinking of using this idea to assess the user wishes. Right now, when a user want to post a wish about ubuntu, where does he go? He goes to forums, where its posts is quickly lost in the mass. Or *if he know about it*, he goes to the bug report (bug! Not obvious!) to post a wish. But this wish report hardly represent the size of the wish. Is only one person interested by this wish, or thousands? or more? Consequently there is no real means to assess *quantitatively* and *effectively* the users wishes and needs. Thus the main guidelines of ubuntu development does not optimally match the users demand. Considering this, my blueprint try to propose a solution based on Ideastorm idea, and reusing Launchpad framework. Here it is : https://blueprints.launchpad.net/launchpad/+spec/better-community-wishes-assessment I would really appreciate any comments on this, and you are welcome to do some modifications you think appropriate. Especially I'd like to hear from Launchpad guys about the possible implementation of the spec. Thanks! Nicolas Deschildre -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss