Re: GIMP *final* release for Gutsy?
On Fri, 9 Nov 2007 21:03:20 -0800 Aaron C. de Bruyn [EMAIL PROTECTED] wrote: Aaron C. de Bruyn: Upgrading simply because there is a newer version number is the wrong attitude. It's not that fact that it's a newer version (number): it's that it's a final, stable release versus a non-final non-stable release. And what makes a release stable or non-stable? The version number? No. It's the code that goes into it. So unless you are running into a bug, there is no need to take a developer away from working on Gutsy to have him fix a problem that no one is having. -A So what is it that an Ubuntu developer develops for Gimp? I thought it was the Gimp developers who developed Gimp. If I find a bug in Gimp I will address it with the Gimp developers and not with an Ubuntu developer. That's like saying if you run into a bug with Firefox on windows you'll write Microsoft. I appreciate the patches that Ubuntu developers make, I've seen them when creating packages but when an update of a package comes out, not a major release but a minor one like Gimp 2.4-rc3 - 2.4.0 - 2.4.1 , it's my believe you'll only have to check if your patches are still relevant. Is it Ubuntu's policy to do QA on all the packages it puts in the repositories? -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] signature.asc Description: PGP signature -- 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: GIMP *final* release for Gutsy?
On Nov 10, 2007 9:22 PM, Peter [EMAIL PROTECTED] wrote: So what is it that an Ubuntu developer develops for Gimp? I thought it was the Gimp developers who developed Gimp. If I find a bug in Gimp I will address it with the Gimp developers and not with an Ubuntu developer. That's like saying if you run into a bug with Firefox on windows you'll write Microsoft. Ubuntu developers perform three major activities (and lots of others), specifically packaging available software, patching that software to address reported bugs, and working to integrate that software with the rest of the distribution. If an issue is encountered with a package, it is much preferable to report it to Ubuntu, as it may or may not affect the upstream package (and the Ubuntu developers will forward the report if it does). I appreciate the patches that Ubuntu developers make, I've seen them when creating packages but when an update of a package comes out, not a major release but a minor one like Gimp 2.4-rc3 - 2.4.0 - 2.4.1 , it's my believe you'll only have to check if your patches are still relevant. Is it Ubuntu's policy to do QA on all the packages it puts in the repositories? Yes, every update to a release goes through a QA process to ensure that it does not cause regressions in behaviour. Packages in each development cycle are tested thorugh a series of Alpha and Beta releases, where the developers attempt to address any discovered outstanding bugs. Further, near the end of a development cycle, and for the life of a supported release, effort is made to not update the software in such a way that might introduce new bugs, specifically meaning that while additional patches are applied to address old bugs, new version are only very rarely imported, to reduce the chance of a new change causing additional bugs. -- Emmet HIKORY -- 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)
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. -- 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
Re: Password-protect grub interactive commands
The issue for now is clear: you can't let your, say, laptop to anybody for an hour or even less without risking ha may easily get root access and maybe change your password or modify your system. It can simply be used to read confidential files, like personal mail, not like military secret but just private. Ubuntu is almost inviting you to do this by simply rebooting and choosing Recovery, without any restriction (you need to know ho to use the very basics of console). OTOH, inserting a LiveCD is almost as simple, and we can't prevent it. Still, it's more complex to do. 1) The person must have the CD here by hand, it may take time to get it 2) He must browse the system disks to find the data ha wants, use a chroot to change passwords (much more complex, only quite advanced users can do that) 3) This is a slightly different pace, since the attacker must use an external software/disc to do that, as opposed to the included Recovery mode. Using a CD is clearly choosing to attack the computer. Anyway, you have to secure your BIOS if you want a reasonably secured computer. But locking GRUB would help the user to go this way if he wants to. Now what are the drawbacks of asking for a password in GRUB? The only I can see is if you've lost your root/admin user password, or you have to work on a system in which you don't have any password though you have the authorization/request to administrate it. In this case, I think requiring the admin to use a LiveCD in not abusive. 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? Cheers. -- 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
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. Cheers. bye -- 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
Re: Password-protect grub interactive commands
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, 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.). 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
Re: GIMP *final* release for Gutsy?
Aaron C. de Bruyn spake thusly: Wouldn't logic dictate that if their latest release was for bugfixes, that they would recommend an update? Or do developers update software just for the heck of it? I haven't done an official study or anything, but I'd be willing to bet that a month after Gutsy is out, about half the packages are out-of-date if you look at version numbers. So what? Upgrading simply because there is a newer version number is the wrong attitude. I agree. And if this were about 4.0 to 4.1 or 4.3 to 4.7, I would be 100% with you. But this is not the case. Ubuntu shipped with a *pre-release* version of GIMP. Would it ship with a *pre-release* of GNOME or Metacity? I think not... This is a package in the *main* (*supported* free software) repository. It's not one of the 23523 packages from Universe. This is a program so good and so popular that Ubuntu (like most every other distro on the planet) chose to include it with a default installation. As someone else pointed out, the masses (particularly the newbies that the SABDFL wants very much to attract) have been (for the most part) trained that alpha, beta and any pre-release software is unstable and ill-advised. Granted, many pre-releases are identical (or virtually identical) to the final release. But many are *not*. And if you look at the changelog on the GIMPs site you'll note that there are *numerous* bugfixes already in the .1 release (not unusual .0 releases are notoriously buggy - in any program). But even if it were 100 bug-free. We're not talking about just a simple version number change here *sigh* -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ Elmer Fudd. All Wites Wesewved -- 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: GIMP *final* release for Gutsy?
Greg K Nicholson spake thusly : Aaron C. de Bruyn: Upgrading simply because there is a newer version number is the wrong attitude. It's not that fact that it's a newer version (number): it's that it's a final, stable release versus a non-final non-stable release. BINGO! -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ Elmer Fudd. All Wites Wesewved -- 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: GIMP *final* release for Gutsy?
Aaron C. de Bruyn spake thusly on 249490952 :: Aaron C. de Bruyn: Upgrading simply because there is a newer version number is the wrong attitude. It's not that fact that it's a newer version (number): it's that it's a final, stable release versus a non-final non-stable release. And what makes a release stable or non-stable? The version number? No. It's the code that goes into it. So unless you are running into a bug, there is no need to take a developer away from working on Gutsy to have him fix a problem that no one is having. And how do you know that no one is having a problem? Oboviusly *somebody* is or the latest release would not be 4.0.1. You may be surprised to learn this but quite a few people using buggy software just put up with it. They never bother to report bugs. I suspect this is especially true of users new to Linux (from Windows or Mac) who are not accustomed to bug reporting anyway as it doesn't exist in thier world (at least not in the same fashion as is it does in the FLOSS world). And just becasuse Ubuntu users haven't reported the bugs that the GIMP devs cite, doesn't mean they don't exist. And lastly, what are the Ubuntu devs *developing* in the case of compiling existing source code from the GIMP? As far as I can tell there is nothing different between the version of the GIMP shipped with Ubuntu Feisty as there was with Fedora 7 (both now *old* Linux distros). -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ Elmer Fudd. All Wites Wesewved -- 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: GIMP *final* release for Gutsy?
Emmet Hikory spake thusly: If an issue is encountered with a package, it is much preferable to report it to Ubuntu, as it may or may not affect the upstream package (and the Ubuntu developers will forward the report if it does). I often report it to both Ubuntu and Upstream. Things tend to get fixed more quickly that way. Ubuntu bugs can sit for *months* (and even over a year) untouched. Is it Ubuntu's policy to do QA on all the packages it puts in the repositories? Yes, every update to a release goes through a QA process to ensure that it does not cause regressions in behavior. Packages in each development cycle are tested thorugh a series of Alpha and Beta releases, where the developers attempt to address any discovered outstanding bugs. Further, near the end of a development cycle, and for the life of a supported release, effort is made to not update the software in such a way that might introduce new bugs, specifically meaning that while additional patches are applied to address old bugs, new version are only very rarely imported, to reduce the chance of a new change causing additional bugs. But if a package was buggy (notably those in Universe) in the previous release of Ubuntu and wasn't causing problems/conflicts with any other package, it's bumped up to the next release as is (with all bugs in tact). So much for QA. -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. ©2007 angrykeyboarder™ Elmer Fudd. All Wites Wesewved -- 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: GIMP *final* release for Gutsy?
On Thu, 2007-11-08 at 23:22 -0700, Scott (angrykeyboarder) wrote: Emmet Hikory spake thusly: On 11/9/07, Scott (angrykeyboarder) wrote: Scott Kitterman spake thusly : On Thu, 08 Nov 2007 16:48:55 -0700 Scott (angrykeyboarder) wrote: Gutsy shipped with a *non-final* release of The GIMP (2.4 RC3, to be specific). In situations of this type (my) logic would dictate that Gutsy would be updated (gutsy-updates?) with the Final version soon after it's release (rather than leave users with an unfinished product in main). As a rule, developers aren't terribly impressed by version numbers. What problem are you having that you think this would fix and that is severe enough to warrant a stable release update? None that would interest [some Ubuntu] developers, I suppose OK... It is important to understand the nature of the issue. Many of the bugfixes that are applied in upstream GIMP 2.4 final are also included in the current Ubuntu package (although the version number is different). This is to confuse us, correct? ;) There seems to be some confusion here: regardless of the content of the version string, bug fixes from upstream will have been ported back to the current Ubuntu package. The two releases are functionally identical, the only difference is the content of a string. If the apparent appearance of a pre-release piece of software is troubling, notwithstanding that it might have any fixes already applied, then that is a different issue. signature.asc Description: This is a digitally signed message part -- 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: GIMP *final* release for Gutsy?
On Sat, 2007-11-10 at 12:30 -0700, Scott (angrykeyboarder) wrote: And lastly, what are the Ubuntu devs *developing* in the case of compiling existing source code from the GIMP? As far as I can tell there is nothing different between the version of the GIMP shipped with Ubuntu Feisty as there was with Fedora 7 (both now *old* Linux distros). Maybe you should actually get involved with ubuntu development, learn how some things work (not packaging as you've already stated you can't possibly do that, how about bug triaging?) to realise the countless hours of effort every day put in by the Ubuntu developers with little to no thanks and many people like you with these clever new ideas and generalisations. Pricey -- 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: GIMP *final* release for Gutsy?
Hello, I am sorry for the LONG mail, but I had no volunteer time this week and this thread is related to my main commitment to the Ubuntu community so I would like to provide my input. Ubuntu developers perform three major activities (and lots of others), specifically packaging available software, patching that software to address reported bugs, and working to integrate that software with the rest of the distribution. If an issue is encountered with a package, it is much preferable to report it to Ubuntu, as it may or may not affect the upstream package (and the Ubuntu developers will forward the report if it does). Because Ubuntu developers individually try to resolve the reported bugs of the entire universe(I am referring to problems which are not packaging related) they do contribute to a lot of open source developers, however they also fail to provide to the users a lot of software, fixes and improvements provided by other open source developers. It should be clear that is the result of resources management option, and based on it, the software currently provided on Universe quality is strongly based on the interest of the Ubuntu developers which may not match the user's requirements/impact . If you work on a pure, developers to developers project, this continuously collaboration effort is sufficient, if you care about users also, there is a lot more you need to address, the existing Ubuntu developers man power and processes are not sufficient. Yes, every update to a release goes through a QA process to ensure that it does not cause regressions in behaviour. Packages in each development cycle are tested thorugh a series of Alpha and Beta releases, where the developers attempt to address any discovered outstanding bugs. Further, near the end of a development cycle, and for the life of a supported release, effort is made to not update the software in such a way that might introduce new bugs, specifically meaning that while additional patches are applied to address old bugs, new version are only very rarely imported, to reduce the chance of a new change causing additional bugs. The QA effort for development has a major cost from the toolchain changes and other major packaging policy or distro related changes, again upstream related changes will be based on the work previously performed by DDs (merging) or on the current Ubuntu developers interest. Open source has evolved from the initial developers to developers relation to current developers to home users/business, I hope such changes will also be brought to more open source related processes. Some people refer to the inability to fulfill some of the user's requests as a scalability problem. I personally believe that we are still too much developers-centrict without sufficient ability/concern to turn end user's interest into collaboration. About this particular request for GIMP final, let's play the user and not the developer. Let's imagine I am a regular GIMP User (which I am not) and I am not a GIMP nor Ubuntu Developer, when I start GIMP on Ubuntu I see a Release Candidate message on the splash screen. I do not need to know about development cycles to figure that this is not a final product. Later, I read on some regular software news source that GIMP Final was released, because I am not familiar with the Ubuntu software packaging and policy I have no idea whether there is some nasty bug that is about to blow up on me or not. I found that totally reasonable from an user's perspective. It is not about the numbers, it is not about developers, it is about common sense. Scott Kitterman, You were of the persons that recently described some of the merging/update requests as denial of service attack, you have a proper reason to request an SRU, according to your known public position on this matter there are are unskilled users that will waste developers and supporters efforts that should be applied into serious problems on several packages that will not be fixed. Daniel, based on your assessment of the changes there are no upstream changes that would technically meet SRU requirements but would worth the backports effort, have you checked the changes ? So far no one was able to provide any details about the changes to identify the specif processes to be used. If the upstream changes provide both SRU and non SRU changes, both SRU and backports should be used. Sebastien, is not the universe security/important bug fixes one of the main reasons to keep with supported repositories ? Isn't someone actually tracking the upstream changes to identify such security/QA ? Are this security/important bug fixes provided based on user requests ? Emmet, if you do believe that potentially this change from RC-Final is only with the splash screen logo, which if it's the case would resolve the problem from the user's expectation perspective, why bringing generic theoretical regression concerns without actually checking the changes ?
Re: GIMP *final* release for Gutsy?
On Nov 11, 2007 5:28 AM, João Pinto wrote: if you do believe that potentially this change from RC-Final is only with the splash screen logo, which if it's the case would resolve the problem from the user's expectation perspective, why bringing generic theoretical regression concerns without actually checking the changes ? I have (lightly) reviewed the changes in gimp 2.4.1, and compared to the Ubuntu changes. The specific updates in gimp that I believe might be worth an update to the package are 4211466, 290055, 490198, 490048, and 490617. Of those, at first appearance, at least 490198 and 490048 appear to be fixed in the current Ubuntu revision, and I am unsure if the Ubuntu shipped video drivers can trigger 412466. I am insufficiently familiar with the gimp codebase to determine if the others should be applied. I would be opposed to seeing fixes for 488170, 418284, 490068, and 490785 released as a stable update, unless there was a test case demonstrating the the new code patch was preferable for an installed Ubuntu gutsy system. I do not have a strong preference either way for the rest of the changes. More generally, if there is an identified issue (especially one that may cause a crash) in an installed Ubuntu system, and a test case may be constructed to test the fix for this issue, I believe it should be applied to the package. On the other hand, if it is a theoretical bug, or does not affect an Ubuntu system with the Ubuntu configuration, I do not believe it should be applied to tbe package. Further, I believe that such fixes should only be applied as a patch, rather than a new source update, and I do not believe that the reported version number is important in determining the stability of the package. About the lack of control on getdeb, I do not understand your comment, getdeb uses LP for bug tracking and it is open for anyone willing to participate. My apologies for the confusion. I specifically mean that Ubuntu does not control getdeb, not that getdeb is not controlled, and so Ubuntu cannot provide support for packages from getdeb, and may have difficulty providing support for users with packages from getdeb installed, depending on the getdeb packages and the relation to the discovered issue. As I indicated previously, any given getdeb package may be perfect, but it also may not be perfect (this is also the case for Ubuntu packages). If getdeb packages are installed, the getdeb comments and getdeb bugtracker are the appropriate support mechanisms, rather than the Ubuntu IRC channels, forums, mailing lists, or bugtracker. -- Emmet HIKORY -- 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: GIMP *final* release for Gutsy?
On Nov 11, 2007 5:28 AM, João Pinto wrote: if you do believe that potentially this change from RC-Final is only with the splash screen logo, which if it's the case would resolve the problem from the user's expectation perspective, why bringing generic theoretical regression concerns without actually checking the changes ? Has anybody considered simply removing the words Release Candidate from the splash screen? So far, the countless emails on this topic seem to point out the shock and confusion that a new user will experience when seeing Release Candidate. The emails seem to try and extend this reasoning to make points about the exception process, the getdeb project and the philosophy of Ubuntu as a whole. Whatever my view on the rest of the issues (the debate on which seems to generate a lot of noise while progressing very little), I can see that it isn't very professional to have something labelled Release Candidate in the default install when the final version is available. Is there any reason that we cannot just wipe off those words? I appreciate that the included version is not the final version, but with the patches that Ubuntu includes, it isn't really the release candidate either. Worst case scenario, we could have the splash screen without the RC, but with an Ubuntu version comment. Regards, Aaron -- FSF Associate Member: 5632 -- 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: GIMP *final* release for Gutsy?
Toby Smithe: There seems to be some confusion here: regardless of the content of the version string, bug fixes from upstream will have been ported back to the current Ubuntu package. The two releases are functionally identical, the only difference is the content of a string. So we're actually getting 2.4.1 (or something very much like it), but labelled “2.4.0rc3”? -- 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: GIMP *final* release for Gutsy?
On Sat, 10 Nov 2007 21:50:27 +0900 Emmet Hikory [EMAIL PROTECTED] wrote: On Nov 10, 2007 9:22 PM, Peter [EMAIL PROTECTED] wrote: So what is it that an Ubuntu developer develops for Gimp? I thought it was the Gimp developers who developed Gimp. If I find a bug in Gimp I will address it with the Gimp developers and not with an Ubuntu developer. That's like saying if you run into a bug with Firefox on windows you'll write Microsoft. Ubuntu developers perform three major activities (and lots of others), specifically packaging available software, patching that software to address reported bugs, and working to integrate that software with the rest of the distribution. If an issue is encountered with a package, it is much preferable to report it to Ubuntu, as it may or may not affect the upstream package (and the Ubuntu developers will forward the report if it does). Because of the patches created by the Ubuntu developers you'll have to report it to Ubuntu developers which means a big workload compared to releasing the package as provided by the original developers. I appreciate the patches that Ubuntu developers make, I've seen them when creating packages but when an update of a package comes out, not a major release but a minor one like Gimp 2.4-rc3 - 2.4.0 - 2.4.1 , it's my believe you'll only have to check if your patches are still relevant. Any comments for this one??? Is it Ubuntu's policy to do QA on all the packages it puts in the repositories? Yes, every update to a release goes through a QA process to ensure that it does not cause regressions in behaviour. Packages in each development cycle are tested thorugh a series of Alpha and Beta releases, where the developers attempt to address any discovered outstanding bugs. Further, near the end of a development cycle, and for the life of a supported release, effort is made to not update the software in such a way that might introduce new bugs, specifically meaning that while additional patches are applied to address old bugs, new version are only very rarely imported, to reduce the chance of a new change causing additional bugs. I understand the point of view of not fixing bugs at the end life of a cycle, but certain software updates aren't in Ubuntu yet while new version have been out for a while now. Azureus for example is still 2.5.0.0 in the official repo while 3.0.2.2 has been out before the package freeze for Gutsy. -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] signature.asc Description: PGP signature -- 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
Azureus was - Re: GIMP *final* release for Gutsy?
On Saturday 10 November 2007 21:49, Peter wrote: I understand the point of view of not fixing bugs at the end life of a cycle, but certain software updates aren't in Ubuntu yet while new version have been out for a while now. Azureus for example is still 2.5.0.0 in the official repo while 3.0.2.2 has been out before the package freeze for Gutsy. Azureus is a special case. The packaging was sufficiently convoluted that no developer was willing to touch it. I substantially more sane package has been uploaded to Hardy and work is ongoing to backport it (need to backport iced tea first). Scott K -- 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
Re: Password-protect grub interactive commands
The only extra security measure I think is worth debating is full disk encryption. I assume that by full disk, you mean the areas that may have personal data. Several places discuss this concept and I understand that there is already an option in the Alternate CD to encrypt /home/. Have a look at: https://help.ubuntu.com/community/EncryptedFilesystemHowto https://wiki.ubuntu.com/EncryptedFilesystems ( https://blueprints.launchpad.net/ubuntu/+spec/encrypted-filesystems ) https://blueprints.launchpad.net/ubuntu/+spec/privacy-tools and, to a lesser degree: https://blueprints.launchpad.net/ubuntu/+spec/easy-encryption https://wiki.ubuntu.com/EncryptedStorage https://wiki.ubuntu.com/EncFSIntegration and, if you are really bored: https://blueprints.launchpad.net/ubuntu/+spec/password-protected-folders https://blueprints.launchpad.net/ubuntu/+spec/encryption-by-default https://blueprints.launchpad.net/ubuntu/+spec/transparent-home-encryption Hope this helps, Aaron -- FSF Associate Member: 5632 -- 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
