Re: Boot-time improvements
2008/9/14 Tristan Wibberley [EMAIL PROTECTED]: On Thu, 2008-09-11 at 12:51 +0200, Krzysztof Lichota wrote: As an author of Prefetch, I cannot agree that it would not fix seeks ;) Part of my implementation, not enabled by default as it is highly experimental, is ext3 defragmenter which puts all files for prefetch in one place on disk, so the requests to read them can be merged into big streaming reads. There could be an automatic algorithm for this if done inside the filesystem. If there is a last-read counter in the filesystem kernel object then the filesystem can pick a pseudorandom number n on some histogram chosen empirically and set last-read to the nth block read, then pick a new pseudo random number m and move the mth block next to the last-read one from earlier. then repeat with a new n and m. set last-read to the start of the disk to begin with and start with selecting an m to move and your filesystem will tend to gather time-related files in space. After several boots you'll have a boot-up and login readahead tailored specifically to your typical use case. This would have practically no discernable overhead or dead-time and requires very little system analysis by humans. It is also something that Ubuntu could very easily give back by delivering to upstream. It is not necessary. Prefetch analyses boot and application startup and knows how files should be layed out. The problem is in relocation of files. -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/12 Mackenzie Morgan [EMAIL PROTECTED]: On Fri, 2008-09-12 at 09:35 +0200, Krzysztof Lichota wrote: Thanks. There are some rough edges in patches themselves which should be straightened out. And the feedback on using prefetch was pretty much non-existing. What is the recommended way of enabling prefetch to test? And can it be tested by people still using Hardy? There are 5 Ubuntu laptops in the room right now... There is an installation instruction at http://code.google.com/p/prefetch/wiki/TestingBootPrefetching This is still Gutsy kernel, but it should work on Hardy. You can also install Hardy kernel which was prepared by Scott James Remnant (available at: http://people.ubuntu.com/~scott/prefetch/ ). Before and after installation please measure boot time and, if possible create bootcharts for comparison. Please report results to [EMAIL PROTECTED] -- Krzysztof Lichota -- 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: Full boot in 45s, 3 possible improvements (for Jaunty Jackalope 9.04?)
2008/9/15 Andre Mussche [EMAIL PROTECTED]: I want to try to use e2defrag on my ext3 disk, to try to reorder the bootfiles (of the readahead list), so less head movements. e2defrag is dangerous, can destroy your data, and should not be used. See http://marc.info/?l=ext3-usersm=116231468911590w=2 -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/11 Mackenzie Morgan [EMAIL PROTECTED]: On Thu, 2008-09-11 at 12:57 +0200, Krzysztof Lichota wrote: That's what have been done by Microsoft for XP - they had the goal to bring boot time to 30s and managed to do it. Apparently they forgot to do the same for Vista ;) But as mentioned before, they did it by shoving off a bunch of the stuff til after the desktop shows so that it's unusable for a few minutes after login while the hard drive churns away. Yes. But users see the desktop after 30 seconds and they think Linux is slow to boot. It is psychological thing. And 30s is considered bringing it down? Wow, how long was it before? Is there a goal we have for boot time? 30s seems about average for boot time right now. At least, all of my laptops boot in 25-35 seconds. You have 25-35 seconds from GRUB till desktop appearing (using autologin)? -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/12 Chris Jones [EMAIL PROTECTED]: I'm not quite sure what all the ranting is all about regarding Ubuntu boot times. I never really even thought of it until it was mentioned on the mailing list here. So, as a test, I timed my own system how long it takes to boot. From GRUB boot to login screen, it was 36.72 secs. And that is on a Celeron D with 512MB DDR RAM and booting from an old IDE hard drive. I'd imagine that a more recent dual core setup with more ram and a more recent sata hard drive would have better results. But my mere 36 secs is certainly nothing to rant about. Most of the seeks (small file reads) happen when loading desktop environment and it takes substantial part of boot time. Enable autologin and then measure boot time until the desktop appears. Faster CPUs, more memory and even faster disks do not help much to fight time wasted on disk seeks. -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/12 Timo Jyrinki [EMAIL PROTECTED]: 2008/9/11 Krzysztof Lichota [EMAIL PROTECTED]: As an author of Prefetch, I cannot agree that it would not fix seeks ;) Part of my implementation, not enabled by default as it is highly experimental, is ext3 defragmenter which puts all files for prefetch in one place on disk, so the requests to read them can be merged into big streaming reads. I stand happily corrected :) Hopefully you will get some help in testing the defragmenter and getting that part stable in time, too. The hard part in the whole prefetch is probably it being kernel-based, but the diff [1] seemed quite non-invasive, ie. only a few calls in the existing kernel code and then some new calls. Thanks. There are some rough edges in patches themselves which should be straightened out. And the feedback on using prefetch was pretty much non-existing. -- Krzysztof Lichota -- 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: Boot-time improvements
2008/9/11 Timo Jyrinki [EMAIL PROTECTED]: 2008/9/10 Przemysław Kulczycki [EMAIL PROTECTED]: Maybe we could achieve it using Prefetch? https://wiki.ubuntu.com/DesktopTeam/Specs/Prefetch https://wiki.ubuntu.com/AutomaticBootAndApplicationPrefetchingSpec Prefetch would be nice, and definitely would improve the user experience. In the end, it would however not fix the problem with seeking to thousands of different files / positions. The only way to fix that problem is to go with sequential, big files, either by precisely reordering stuff on the disk in an area that can be made 100% sequential, or by copying files to a cache of sort, being a single sequential file which contains everything needed and is updated when needed. As an author of Prefetch, I cannot agree that it would not fix seeks ;) Part of my implementation, not enabled by default as it is highly experimental, is ext3 defragmenter which puts all files for prefetch in one place on disk, so the requests to read them can be merged into big streaming reads. -- Krzysztof Lichota -- 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: readahead slow down
2008/8/28 (``-_-´´) -- Fernando [EMAIL PROTECTED]: Ubuntu (and also Fedora) are trying to make the boot of a system be the shortest possible, but on my system, readahead is adding up to 90 seconds to my boot time. I've attached my lastest bootchart log and my dmesg to LP #262311. On dmesg between line 505 and 506, it's visible the 90 sec pause. [8.869740] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e0180003a853e6] [ 104.088084] udevd version 124 started I wonder if it would there be any interest in collecting bootcharts and boot dmesg so common problems like this could be traced by a ubuntu-core-dev https://bugs.launchpad.net/bugs/262311 This bug is not accessible - permission denied. Is this some security issue? Can you sum up the results and post bootcharts somewhere else? I am interested in this issue. -- Krzysztof Lichota -- 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: Backtracing, Invalidated Bugs and Quality
2008/8/21 Christopher James Halse Rogers [EMAIL PROTECTED]: In what way is this different to the current Apport infrastructure? My understanding is that the client sends in the crashdump and the apport retracers on launchpad replay it on a system with the debugging symbols installed. The retracable crashdumps are already nicely handled; how does the symbols server help in cases when the retracers would fail? I don't know apport architecture, but the people in this thread were discussing installation of debug packages on client to improve backtraces, so I assumed they are needed for something... -- Krzysztof Lichota -- 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: Backtracing, Invalidated Bugs and Quality
2008/8/20 Null Ack [EMAIL PROTECTED]: I'm not convinced that the strategy of asking users to install specialised debugging packages is the right way to go. I see a very low hit rate with this working in practice. It is not surprising. Asking people to install multi-megabyte packages and reproduce bug is not going to work as: 1) the bug often cannot be reproduced (and the user does not want to be hit by a bug again) 2) the user is requested an extra work he does not understand 3) some users do not have resources to install debug packages as they are huge IMO the solution would be to create debugging symbols server. Microsoft had these for years. The information about debugging symbols is only needed on server, client only sends (in simplest version) MD5 sum of library and address offset, which is transformed into the symbol by symbol server. -- Krzysztof Lichota -- 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: LTS and release methodology
2008/7/10 Matt Zimmerman [EMAIL PROTECTED]: On Thu, Jul 10, 2008 at 10:13:00AM +0200, Krzysztof Lichota wrote: Well, IMO in most cases this would require just creation of appropriate packaging process and appropriate build tools. Build systems already support installing to different directory prefixes, with prefixes/suffixes to binary names, etc. Some build systems do, some don't. The only ones we would have to care about are the build systems for major apps: Firefox, Openoffice, etc. I guess they have such abilities. And I don't think this would require linear time. It would be one-time job to convert it and then the maintenance would be the same. So the tradeoff would be to make current version mediocre. But to really tell it, we would have to start an experiment and try it. Indeed. If you believe that some one-time work will solve your problem, you are in an ideal position to test this. OK, I will try to test it. Given my poor packaging skills and little spare time it will take much longer than if it was done by person who already knows application packaging/build system. It is generally possible to keep obsolete packages installed after an upgrade, so there's no forced upgrade here. However, the packages from 6.06 won't receive maintenance updates on 8.04. If you install OpenOffice from Hardy, you cannot keep the one from Dapper. No, but you were talking about PostgreSQL, where you can. But only because it supports multiple parallel versions. So I guess you support my point that parallel versions are useful? And I really don't think the one from Dapper would work on Hardy. I would be surprised if it stopped working. I will check it. Maybe this version in newer LTS should get limited transition support which ends when the support for older LTS ends. This way security fixes from older LTS would be simply forward-ported to newer LTS. It is already more complex than we would like for users and administrators to understand which packages on their system receive maintenance and support, and which don't. The idea of LTS is that one can deploy the system and not think about it too much for a few years. Adding time bombs where certain applications start to reach end-of-life earlier than others would complicate what is presently a simple cycle to understand. Simple notification popup Your OpenOffice 2.3 reaches end of lifecycle next month would be doable and simple. Sending e-mail to customers would be even simpler. Limited transition support packages would be targeted at IT departments and are added value for transition periods, so I think IT departments would be aware how they have to handle end of lifecycle announcements. No additional security-related effort would be needed. First of all, porting changes to different versions of a package is real work. Second, security updates are semi-automatically deployed to millions of Ubuntu systems and need to be regression tested before being released. Don't be fooled by the fact that they are available for free; this is not a trivial service. It is not porting security changes, it is backporting security-fixed package again. Example from my Firefox packages: I am taking Firefox 2.0.0.14 from Feisty and backporting it to Dapper. When security update (Firefox 2.0.0.15) appears I am not taking security fixes and apply it to 2.0.0.14. Instead I am taking Firefox 2.0.0.15 from Feisty again and backport it to Dapper. It is much simpler (but of course it also requires regression testing). I am aware it is not always possible with each application and lifecycles might come into play, but it is possible for some apps. You must anyway ask which version of _Ubuntu_ user is using. And I think it is even harder to get this information, it is not in any way obvious to user. System-About Ubuntu. Slow to start, but discoverable enough. Novice user would not find it. And on Kubuntu it is even harder. Anyway, asking app version is equally difficult and can be guided by helpdesk person the same way. This is what IT departments define. Users would mostly use OpenOffice (the default set by IT department) unless support/power users would tell them to use other version. The vast majority of Ubuntu users don't have an IT department supporting them. The development team must make sensible choices on their behalf. Yes, so the defaults would be the same as now. Nothing changes. Except from the fact that when default application version does not work, user can get to know on support forums/blogs/etc. how to run/install alternate version and not get one of the responses he gets currently: a) Install previous distribution release b) Wait for next distribution release c) Wait for fix (which might never come) All of them require significant changes and take significant time, while users expect they can do the job immediately. Additionally b) and c) are not reliable (bug might not be fixed), a) and c) might not work
Re: LTS and release methodology
2008/7/10 Mario Vukelic [EMAIL PROTECTED]: On Thu, 2008-07-10 at 10:15 +0200, Krzysztof Lichota wrote: The main point is that it is possible (and easy) to install Firefox 3 on Windows XP (released 2001), while try to install Firefox 3 on Dapper (released 2006). FWIW: download from firefox.com, unpack, run installer. Granted, it is not under the control of the package manager in this case, but neither is it in Windows (which lacks one altogether). Try it and you will see why it does not work. Firefox 3 requires GTK 2.10 which is not present in Dapper. -- Krzysztof Lichota -- 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: LTS and release methodology
2008/7/9 Mackenzie Morgan [EMAIL PROTECTED]: On Wed, Jul 9, 2008 at 3:47 AM, Krzysztof Lichota [EMAIL PROTECTED] wrote: It is a lot of effort, but if we want to compete with Windows, which makes it possible (and easy), it should be done. Er, not really. You can't have FF2 and FF3 or IE6 and IE7 both installed on Windows, or if it is somehow possible, it's certainly not easy. Maybe, it has been really long time since I last used Windows. But I remember it was possible for some applications. This is secondary point, though. The main point is that it is possible (and easy) to install Firefox 3 on Windows XP (released 2001), while try to install Firefox 3 on Dapper (released 2006). -- Krzysztof Lichota -- 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: LTS and release methodology
2008/7/7 Matt Zimmerman [EMAIL PROTECTED]: On Mon, Jul 07, 2008 at 10:43:44AM -0500, Luke L wrote: --New software should not be included simply because it is new, quite the opposite: new software should rarely included. Firefox beta and OOo 2.4 are notable examples. I can't agree with you on this point. In my experience with open source software, I have nearly always been better off with current software. Ubuntu was founded with the idea of delivering this to users. Newer software may introduce some new problems, and it may fix some. However, software which remains unchanged will never improve. I can't agree here. IMO bugs which people already know, they got used to and found workarounds for, are less damaging for system reputation than bugs which are unexpected. Imagine an office user which works on an important office document for his boss' meeting. He recently got his brand new LTS system. Now, in scenario 1, he gets LTS system with old, but stable version of OpenOffice 2.3 with known bug - let's say printing to PDF does not work. He will just not print to PDF but print directly or use some other way to print to PDF, because he knows what to expect. In scenario 2, he gets LTS system with new OpenOffice 2.4 which has PDF printing fixed, but during the work on very important document, it turns out that the it displays Arabic numbers instead of decimal numbers. Both of these bugs can be potentially damaging for system reputation (user cannot perform office tasks), but the first one can be worked around beforehand by IT department or other means. BTW. IMO it would be useful to prepare such list of corporate-important LTS bugs so that IT departments would be aware what problems they can expect. My example is a little biased and someone can point out that version 2.3 might have critical bug which renders 2.3 useless for some group of people, while 2.4 has this bug fixed. But it can be also the other way round - 2.4 might have critical bug, which is not present in 2.3 (for other group of people). So the question which version to choose seems hard. But the answer is pretty simple: do not choose. Ship both versions and let users choose which version to use. Preferably make application possible to live side-by-side, i.e. version 2.3 and 2.4 can coexist at the same time. Additionally, ship _newer_ versions of important apps to LTS releases, so that continuity is kept. If LTSx release contains OpenOffice 2.2 and new version 2.3 appears, port it to LTSx, so that when version LTSx+1 appears with version 2.3 and 2.4, they will be able to transition smoothly by using version 2.3 (assuming it works for them). Just my 2c :) -- Krzysztof Lichota -- 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: Customized CD
2008/6/8 Alexandre Conrad [EMAIL PROTECTED]: Hi, I'm not sure I'm on the correct list here. I'm trying to setup a customized CD for future installations on a large number of computers. During the installation, I'll have no network, so I can only depend on CD. Why don't you just use UCK (http://uck.sourceforge.net) and create your own customized CD which will have everything needed already installed? -- Krzysztof Lichota -- 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: Ubuntu boot speed fall in Hardy
2008/5/22 Scott James Remnant [EMAIL PROTECTED]:
On Tue, 2008-05-13 at 14:07 +0200, Krzysztof Lichota wrote:
The kernel module writes it. For boot prefetching, userspace script
processes the lists as they are merged and sorted for last 3 runs.
I noticed that you get lists (in /) for the phases, but files
in /prefetch for applications named PATH-stamp?
Yes, boot prefetch files are in /.prefetch-boot-trace.PHASE (I should
change that), while application files and historical boot files are
kept in /prefetch.
Could you give a little more detail on what files to expect, and what
the content/format of those files are?
You should expect:
/.prefetch-boot-trace.PHASE
/prefetch/.prefetch-boot-trace.PHASE.TIMESTAMP (3 files for each phase)
/prefetch/APPNAME-HASH for each application using prefetching
Prefetch file format is simple, the header and then series of trace records.
You can see the structures in file prefetch_types.h in prefetch
userspace tools source.
Header structure:
typedef struct {
///Trace file signature - should contain trace_file_magic
char magic[4];
///Major version of trace file format
u16 version_major;
///Minor version of trace file format
u16 version_minor;
///Trace raw data start
u16 data_start;
} prefetch_trace_header_t;
Trace record:
typedef struct {
kdev_t device;
unsigned long inode_no;
pgoff_t range_start;
pgoff_t range_length;
} prefetch_trace_record_t;
You can print the contents of the trace using prefetch-print-trace
utility included in prefetch userspace tools.
Init scripts (similar to readahead scripts) are run and they tell
kernel module which files to load and when.
So boot prefetching can be easily changed by modifying these scripts,
without touching the kernel part.
I noticed the phases stuff.
Have you considered instead using cgroups to collate them? Phases are
divided by time, which becomes problematic with a boot sequence running
in parallel.
A cgroups subsystem for prefetch would solve this, since cgroups are
inherited from parent to child.
E.g.
* rcS is placed into the boot cgroup
(thus all apps run by it are)
* rc2 is placed into the system cgroup
* gdm is placed into the gui cgroup
You can then still generate app prefetch lists for individual apps
(since apache can be started by hand, _and_ by rc2). But also we can
generate combined lists for each cgroup.
When I was writing this, cgroups were not available. But it seems like
a good idea. Can you tell something more how to use them?
CCing prefetch-devel mailing list, I think this list would be better
for further discussions as it is getting too much into details for
ubuntu-devel-discuss.
--
Krzysztof Lichota
--
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: Ubuntu boot speed fall in Hardy
to predict which programs will be run, so this could be useful. But I don't know how it will behave (in terms of performance) together with prefetch - prefetch for apps might think preload is loading the files for itself and this could make prefetch perform poorly. HTH -- Krzysztof Lichota -- 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: Changing dpkg-deb default compression from gzip to lzma for Hardy
Scott Ritchie napisał(a): I did some experimentation with my Wine package. Here's the filesize of the latest .deb passing different options to dpkg-deb: 11081456 default 10090930 bzip2 7682608 lzma That's over a 30% reduction in bandwidth for me and my humble third party repository. I've heard that lzma will be included by default in main for Hardy. This is a very good idea. Changing package build scripts to manually pass lzma compression using dh_builddeb -- -Z lzma would be very tedious, however. In IRC pitti proposed that we do this centrally - changing the default of dpkg-deb (currently gzip) seems to be the best place for this. Thoughts? It is hard to judge best compression using only one package. It is possible that for other packages other compression schemes would be better. Have you run built other packages? ?The best would be to rebuild whole repo with new compression scheme and compare the results, so that it does not appear, for example, that packages stop fitting into one CD. Another thing is decompression time - on some machines the limiting resource is CPU, not bandwidth nor disk space and changing compression would mean significant burden as packages would be unpacked much longer and put more stress on system, making user experience unpleasant. This could be mitigated by running unpacking process with nice, but AFAIK it is not the case now. If these 2 issues are addressed, I think it in general a good idea :) My 2c. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Changing dpkg-deb default compression from gzip to lzma for Hardy
Scott Ritchie napisał(a): It's been shown that lzma is, in general, much better. If we happen to find a specific case where it's not, then we can always set that package to a non-default by tweaking the dh_builddeb line. I couldn't find any paper about lzma. But you are right, if it can be tweaked per-package, then there is always a way out. We just have to check package sizes in some way. I believe lzma has a fairly efficient decompression time. We should note, however, that package installation time is one of the least important places to optimize CPU usage - it's not user-interactive, and is very frequently done after the user has stopped doing other things. Why do you think so? I always run system update when I am doing other things. And I can notice when installing packages starts, although I have 3 GHz CPU. I don't have any data, however from my own personal experience with moderately fast broadband it seems like most of my package installation time is during downloading rather than unpacking/configure by a very wide margin. A 30% reduction there would require a much larger amount of time to unpack to make it not worthwhile. It is not about time to do update, but the user comfort. If music stops playing because packages are installed then it is not pleasant user experience. I have already suggested running background tasks with ionice (https://blueprints.launchpad.net/ubuntu/+spec/low-priority-io-for-background-tasks), running them with nice is also recommended as CPU can be starved, for example when playing video. Krzysztof Lichota signature.asc Description: OpenPGP digital 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
Access denied (403) when trying to fetch security updates for Dapper
Fetching security updates for Dapper fails, as *smb* packages have wrong access permissions on web server. Other updates were fetched properly. I have tried getting them using wget and Firefox and it is the same, so problem lies for sure on web server. Here is the message from Firefox: Forbidden You don't have permission to access /ubuntu/pool/main/s/samba/libsmbclient_3.0.22-1ubuntu3.4_i386.deb on this server. And here is the output of apt-get: $ LC_ALL=C sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following packages will be upgraded: libsmbclient libsmbclient-dev samba-common smbclient 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 6225kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? Err http://security.ubuntu.com dapper-security/main smbclient 3.0.22-1ubuntu3.4 403 Forbidden Err http://security.ubuntu.com dapper-security/main samba-common 3.0.22-1ubuntu3.4 403 Forbidden Err http://security.ubuntu.com dapper-security/main libsmbclient-dev 3.0.22-1ubuntu3.4 403 Forbidden Err http://security.ubuntu.com dapper-security/main libsmbclient 3.0.22-1ubuntu3.4 403 Forbidden Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/smbclient_3.0.22-1ubuntu3.4_i386.deb 403 Forbidden Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/samba-common_3.0.22-1ubuntu3.4_i386.deb 403 Forbidden Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient-dev_3.0.22-1ubuntu3.4_i386.deb 403 Forbidden Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/s/samba/libsmbclient_3.0.22-1ubuntu3.4_i386.deb 403 Forbidden E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Access denied (403) when trying to fetch security updates for Dapper
Matt Zimmerman napisał(a): On Sat, Nov 17, 2007 at 08:21:54PM +1100, Serge de Souza wrote: See https://bugs.launchpad.net/ubuntu/+source/samba/+bug/163042 basically a bad push and permissions were changed on the debs to prevent them from being downloaded. Wouldn't a new release without the broken packages fix the problem of people trying to download something they can't? As you can see from the discussion in the bug report, the circumstances are as follows: - This regression only affects specific configurations (apparently those using the deprecated smbfs module) - There is a straightforward workaround (cifs works) - The vulnerability is not believed to be serious (denial of service only) Therefore, withdrawing the update in order to fix the problem was deemed an appropriate response, given the severity of the issue in affected configurations. Preparing and testing a new update is something which takes time, and should not be rushed. This temporary emergency measure (which is admittedly confusing for users) prevents further downloads while a proper response is prepared. Could you in such cases send announcement that such measure was taken and that update will fail (security announcement or at least a message on ubuntu mailing lists). It would at least not leave users wondering why the heck is my automatic update not working. Especially in case of Adept it is a surprise as it shows the same message when it cannot download the file and when packages system is broken - which happens often if dependencies are not fulfilled or package is half-configured. So I have gone through usual dpkg --configure -a, apt-get install -f, but it didn't work, as the problem lies in completely different place. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: GetDeb Project
Scott Kitterman napisał(a): I was thinking about this some more. My objection isn't to the installation method, but to the packages. Someone earlier in the thread mentioned the benifits of the web front end that Getdeb provides. Rather than remove something like gnucash from getdeb, what really needs to happen is just pointint from the getdeb package to the Ubuntu one. In the gnucash case it would be changing: http://www.getdeb.net/download.php?release=1496fpos=0 http://www.getdeb.net/download.php?release=1496fpos=1 http://www.getdeb.net/download.php?release=1496fpos=2 with http://launchpadlibrarian.net/9958499/gnucash_2.2.1-1ubuntu4%7Efeisty1_i386.deb http://launchpadlibrarian.net/9958498/gnucash-common_2.2.1-1ubuntu4%7Efeisty1_all.deb http://launchpadlibrarian.net/9959217/gnucash-docs_2.2.0-1%7Efeisty1_all.deb The web front end could stay. This would have a number of advantages: Reduced storage and bandwidth usage for getdeb Fewer packages users have to uninstall before an upgrade Fewer issues due to unofficial package use How about something like that? I've no objections to that approach myself. I think it is a good idea, but I see 2 problems: 1. Ubuntu should provide links to debs which do not change in time or some way of automatically feeding changes to deb names to getdeb, so that updates do not require manual intervention. 2. Pure .deb packages are not signed (as far as I understand APT system). Only repos are. So the security problem stays the same. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: GetDeb Project
Ming Hua napisał(a): On Wed, Oct 17, 2007 at 01:45:04AM +0200, Krzysztof Lichota wrote: Scott Kitterman napisał(a): Generally I enable backports, install what I want, and the disable it again. That I think most people can do. Maybe they can, but: a) they have to know about it They have to know about GetDeb, too. They have to know only the URL. For package pinning, switching repos they have to know a lot more. b) it is very inconvenient c) you do not get updates to installed app (i.e. security fixes) This makes me curious: how do you get security fixes for a package installed from GetDeb? You don't. But you should. I just drew your attention that switching backports repository on and off does not solve it either. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: GetDeb Project
Scott Kitterman napisał(a): Generally I enable backports, install what I want, and the disable it again. That I think most people can do. Maybe they can, but: a) they have to know about it b) it is very inconvenient c) you do not get updates to installed app (i.e. security fixes) It doesn't cause upgrade to all the newest versions of a lot of packages. That only happens if the user specifically requests it. Unless after enabling backports and updating repo a nice upgrade icon appears which inexperienced user will click and fetch the updates. Maybe if there was a graphical inteface to do what you described it would do, but currently it is rather a hack around the problem. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: CD boot installer for Windows contribution
Evan Dandrea napisał(a): The functionality to fix the boot order issue has been implemented as another option in Wubi, which is the ideal course anyway as it does not make sense to have both Wubi and a modified Instlux as part of the installer. I do appreciate the intended contribution though, and I am glad that it solves the problem for your derivative. Great :) I didn't know Wubi is so advanced :) If Wubi has the option to boot from CD, then it makes my installer obsolete. Thanks for info. Maybe some other people find it useful though :) Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Broken Packages Dependencies
Matt Zimmerman napisał(a): On Sat, May 19, 2007 at 12:39:21PM +0200, Thilo Six wrote: Since developers only can work serial on packages these things get usually (from my experience) sorted out in a short days. Note also that the archive is automatically scanned for problems like this, because they can be detected by analyzing the dependencies. https://wiki.ubuntu.com/UbuntuDevelopment#head-9827dcffcca6eba8f5fd799ad13d3fa7f8116c39 This can also be caused by packages which are still building, or waiting to build, on some architectures, and other normal processes. When I cannot install new package, because package manager complains to run apt-get -f install, then it should not be a usual situation. And it is the first time when this is so serious - tens of packages seem broken. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Broken Packages Dependencies
Krzysztof Lichota napisał(a): When I cannot install new package, because package manager complains to run apt-get -f install, then it should not be a usual situation. And it is the first time when this is so serious - tens of packages seem broken. Sorry, I have replied to some old e-mail by accident. Apparently I am too tired to use e-mails today. But I got some broken dependencies today which fitted exactly the scenario. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: Kernel with automatic boot tracing and prefetching available for testing (GSoC 2007)
Phillip Susi napisał(a): Krzysztof Lichota wrote: How it works? - During boot file accesses are recorded. - During subsequent boots this trace is used to prefetch files before they are used in order to speed up boot. How is the data prefetched? I know that the readahead package used the readahead() system call to load entire files that were accessed during boot. This is sub optimal because often times the entire file is not needed, only certain pages of it. Prefetch works on page-size chunks, so only used parts of files are prefetched. As for reading, prefetch uses force_page_cache_readahead(), so it is the same function as used by readahead() call. Also the readahead was done synchronously one file at a time, which does not keep the disk at full utilization. Ideally you just want to read in the required pages, in the order in which they are required, with several asynchronous requests in the queue at a time. This is good idea, it might improve results a bit. I will try it in the future. However, room for improvement is quite small, as you can see on this bootchart: http://prefetch.googlecode.com/svn/trunk/results/boot-prefetching/testmachine-kl1/test-9-versus-plain/bootchart-prefetch-sync.png During readahead disk is almost 100% utilized. You also want to wait until some of the data is read before continuing with the boot process, but you don't want to wait until ALL of it is read. It depends. I have done some experiments with asynchronous prefetching and in most cases it is better to wait for readahead to finish before proceeding than to let readahead go in parallel with execution of apps. This is consistent with results of other prefetching systems. The exception is when you can prefetch some files in advance, before execution of apps starts. This approach is used in prefetch to prefetch GUI in advance. The boot is split into 3 phases: 1. boot - since root partition is mounted until all filesystems are mounted 2. system - when all partitions are mounted till KDM/GDM is started 3. gui - when desktop environment is started Each phase is traced separately. For boot and system phase files are prefetched synchronously at start of the phase, but GUI phase files are prefetched in background right after system phase files are prefetched. I have done quite a lot of experiments to find the proper combination of parameters. See the page with descriptions of experiments: http://code.google.com/p/prefetch/wiki/InitialBootPrefetchingResults Of course there is always room for improvements. This implementation of prefetch is just the beginning :) Thanks for insightful comments. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: Kernel with automatic boot tracing and prefetching available for testing (GSoC 2007)
(``-_-´´) -- Fernando napisał(a): Isnt this the same as puting profile on the grub when you get a new kernel?! No, because with readahead you have to remember to do it upon each change (not only new kernel, but also installing libraries, enabling services, adding autostart apps, etc.). With prefetch it is done completely transparently for user, it just adapts to new environment. Also, as I mentioned in announcement, with prefetch it is possible to do tracing and prefetching at the same time. Prefetch tracing facility also makes possible adding more sophisticated optimizations: prefetching during application start and reordering files on disk. Both are in the works and I will announce them when they are ready. Krzysztof Lichota signature.asc Description: OpenPGP digital 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
Announcement: Kernel with automatic boot tracing and prefetching available for testing (GSoC 2007)
Hello everyone. I am working this summer on Automatic boot and application start file prefetching project as part of Google Summer of Code for Ubuntu. I am glad to announce that first version of kernel with automatic boot tracing and prefetching is available for widespread testing :) How it works? - During boot file accesses are recorded. - During subsequent boots this trace is used to prefetch files before they are used in order to speed up boot. Everything is done automatically, without user intervention, and tracing is possible to do at the same time as prefetching - as opposed to currently used readahead package, which requires manual run of tracing (and prefetching is not done during tracing). Results from my latest tests, standard boot, average of 9 runs: Prefetch kernel + prefetch : 54.91s Prefetch kernel + readahead : 58.76s Ubuntu kernel + readahead : 61.21s Results of tests with OpenOffice run at boot, simulating disk-intensive applications run at boot, average of 9 runs: Prefetch kernel + prefetch : 65.53s Prefetch kernel + readahead : 74.43s Ubuntu kernel + readahead : 81.01s Debs with kernel and supporting userspace utilities are available on project page. Please see this webpage for instructions how to install them: http://code.google.com/p/prefetch/wiki/TestingBootPrefetching If you would like to do some automatic tests to accurately measure boot time and effect of prefetching, please see this page: http://code.google.com/p/prefetch/wiki/BootTimeMeasurementInstruction Please report successes and possible problems to: [EMAIL PROTECTED] (no registration necessary). Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer - What I need as a third party APT repository maintainer
Scott Ritchie napisał(a): Right now, approximately 70 thousand people use the Winehq APT repository to keep an updated Wine package. Every one of them had to follow the instructions here: http://www.winehq.org/site/download-deb Simply put, these instructions suck. Google has GUI instructions for their repository, and those also suck: http://www.google.com/linuxrepositories/apt.html Both are as simple as we can make them, and they are inordinately frightening to new users. Pasting arcane shell commands as root into a terminal is not easy to use; neither is the 7 step graphical process Google gives. Exactly, that's the reason behind creating One Click Installer :) I, as an upstream ISV with my own third party repository, need it to be easy for the user to use my software. It should be so easy that I don't even need to give instructions - just a link to a single file that they can double click on. A user should be able to download a standard repository file, double click it, be informed about what packages and repository it's going to install, enter their password, and then be done. That's exactly what One Click Installer does. Thanks for explaining things from developer's point of view. Some people just don't get it. And without third party applications Linux is not going to be viable alternative for Windows as multipurpose desktop operating system. From what I can tell, this is going to be handled exactly by Third Party Apt, and I hope it can be finished in time for Gutsy. Will One Click Installer also do this, perhaps embedding the internals of Third Party Apt on Ubuntu systems? Yes, One Click Installer can do this and even more: it can embed installation information for other systems than Apt, and can provide user with nice which parts to install dialog, so that he can choose if he wants, for example, to install docs or plugins. More features for ease of use are planned, like possibility to add icon to the desktop (hard to do by beginners). Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Matt Zimmerman napisał(a): On Tue, Aug 07, 2007 at 09:57:42PM +0200, Krzysztof Lichota wrote: Matt Zimmerman napisał(a): This provides the experience of locating the software on the web while retaining the security and maintenance characteristics of the distribution model. This is the approach of apt:// protocol. It is not extensible and it will not make Ubuntu competitive to rich software ecosystem of Windows. There _must_ be the way for third party software creators to publish their software easily. Otherwise they will not be interested in creating their apps for Linux. The two are not mutually exclusive, and an ideal solution would incorporate both. One Click Installer can be used for both, providing trusted, signed installation files signed by Ubuntu and providing unsigned files for third party developers. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Matt Zimmerman napisał(a): On Wed, Aug 08, 2007 at 04:58:21PM +0200, Krzysztof Lichota wrote: Matt Zimmerman napisał(a): On Tue, Aug 07, 2007 at 09:57:42PM +0200, Krzysztof Lichota wrote: This is the approach of apt:// protocol. It is not extensible and it will not make Ubuntu competitive to rich software ecosystem of Windows. There _must_ be the way for third party software creators to publish their software easily. Otherwise they will not be interested in creating their apps for Linux. The two are not mutually exclusive, and an ideal solution would incorporate both. One Click Installer can be used for both, providing trusted, signed installation files signed by Ubuntu and providing unsigned files for third party developers. It is not a question of whether the file is signed or not; it is a different abstraction. One is install package X from repository Y. (One Click seems to do this, from your description) The other is install package X from your existing, configured repositories (this is like apt:// and similar ideas) The key difference is that in the latter case, the metadata does not supply a repository, and there should be (notably) none of the usual security issues, regardless of whether the metadata is authenticated. Exactly, so how in this case you want third party developers to provide their apps? Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Matt Zimmerman napisał(a): We are talking past each other. There are two distinct use cases here, and I am a) saying they could both be fulfilled by the same software mechanism, and b) asking whether your system does both. From the sound of it, it only addresses the explicitly third-party repository case, and not the case where the application is implicitly available from Ubuntu. Yes, there are third-party developers who could make use of such a system to publish their applications, but there are also developers who are well served by the existing system and would benefit from having a web-oriented way to indicate that their software is included in the Ubuntu repositories, delegating all decisions about repository location and authentication to the package manager. OK, now I understand what you mean. Yes, you can provide One Click Installer installation file which has only information which package to install and does not contain any repository information. This should cover the second case. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Kevin Fries napisał(a): As for the OPs problem with Synaptic... That is 500% off base. I know this because I have sat down with end users and showed them synaptic, and the gnome installer. If more geeks like us did this with their favorite Windows user, I believe there would be more people asking why Windows does not install as nicely as Linux. Want proof? Yeah, and then they go into Synaptic and want to install Firefox 2.0 (or 3.0, 4.0, etc.) and it is not there. So they go to Firefox website and download source tarball or RPM, or whatever. And run away scared, because Linux is too difficult. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Greg K Nicholson napisał(a): Krzysztof Lichota: And I do not think such amount of information should be put in URLs, it is just too big. URLs should not hold data. I imagine that the major Linux vendors would each host a library server, SourceForge might have one too, as would some or all of the servers that currently provide mirrors for open source projects' downloads. Remember, we're only dealing with short snippets of metadata, not the installers themselves, so this isn't a universal repository of all software — just a universal repository of all software installation metadata (ideally). So you are taking away power from users and centralizing it. It is exactly the opposite of what was the key of success of WWW (giving power to users). I'm visualising this library as a vast table with program versions down the left, and distro/version/etc combinations across the top. At the intersections are instructions like: package repo=http://bar.example.com;foo/package Sometimes there are several instructions: package repo=http://bar.example.com;foo/package gpgkeyhttp://baz.example.org/gpgkey/gpgkey Please see the specification of One Click Installer file format (http://one-click-installer.googlecode.com/svn/trunk/one-click-inst/README) and you will see exactly that. And the library of servers becomes just a loose bunch of web servers holding One Click Installer installation files. Just One Click Installer gives everyone a possibility to create one, not only distributions and big players. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Matt Zimmerman napisał(a): Thanks for sharing your ideas with us in detail. This is an idea which has been on many of our minds for some time, but no one had gotten around to prototyping it yet. One concern that I have is that I feel it is important to ensure that applications and their dependencies are installed from the Ubuntu repositories wherever possible: if the application is available from Ubuntu, it should be installed from there, even if the user found it via a third-party website. This ensures that it will receive official updates, and upgrade properly to the next release of Ubuntu, which is one of the great strengths of package management. Of course, there will be applications which cannot be added to Ubuntu, and so third-party repositories are necessary, but they should be avoided where they are redundant, as they complicate maintenance and upgrades. Does your design address this? Creator of One Click Installer installation file decides which repository will be used. If the application is available in Ubuntu repository I do not see the point why he would prefer to point to some other repository. Additionally, Ubuntu could make such need void by providing prepackaged, trusted installation files - only installation files signed using Ubuntu key are trusted by default by One Click Installer. Files signed with untrusted key are not installed and files without signature spawn warning and default to aborting installation. I have described security model in this e-mail: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-August/001385.html So Ubuntu could just provide signed files for applications hosted in its repository, signed with its key for use by everyone else. Files would be hosted on Ubuntu server and everyone else (forum support people, bloggers, journalists, ...) could just provide links to these files instead of creating them on their own. To give it kick start this could be even automated to create installation files based on descriptions from .deb files themselves. Then they could be polished to provide better user experience (provide optional documentation installation, language packs, etc.). Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Sebastian Heinlein napisał(a): I haveb't look at the code in depth, but have you thought about using the apt python bindings instead of command line calls (apt-get install --assume-yes is a bad idea)? aptsources even provides an abstraction of the sources.list. I did not know about apt bindings and I had command line interface from my other project. I have tried using Adept Batch, but it is not very convenient nor portable. So if someone can improve that code, you are welcome to join the project :) The code is open and definitely there are many ways to improve it :) Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Sebastian Heinlein napisał(a): even a signed software can do a lot of harm to your system. installing software from the internet blindly is perhaps the cause for most unstable windows systems. Any software can harm your system when used inappropriately. But it is not the reason to forbid people to use it. If someone is security conscious, he will take the risk into account. If he is not aware of it, we can make him at least aware. Then the decision is in the hands of user. if you require to only install signed packages only you would at least make sure that the package creator has got some basic skills. furthermore it could be nice to make use of the gnupg web of trust here. you could calculate a trust level from the number and kind of signatures. This is interesting proposal. But the problem is how to measure such trust level? By requiring web of trust to reach one of Ubuntu developers? what are your plans about an translation infrastructure for the oci files? if you don't find any translators you won't get any translations - the current problem of ddtp. The basic principle is that anyone can create installation files in decentralized manners. So it would be up to local Ubuntu teams to provide installation files with translated contents. Any central repository (based on Rosetta or DDTP) should only help by providing some coordination place. you mentioned tucows and a central wiki page many times. any plans on this? the idea was discussed several times in the past, but it was never implemented in the official ubuntu frame work. perhaps an error, since now we seem to get a lot of separated sites with no central quality assurance. I have not mentioned central wiki page :) My vision is completely different - there should be many places where installation links can be provided. Some of them more formal and trusted (for example packages.ubuntu.com, Ubuntu pages, etc.), some supported by community (getdeb.net, etc.), some completely freelance - blogs, forums, wikis, etc. One Click Installer allows all these places to host installation links. It is up to maintainers of packages.ubuntu.com, getdeb.net or any other site to use it. And distributions such as Ubuntu can help creating this ecosystem by providing signed installation files for everyone to link to. Of course I would really like to see central Ubuntu software repository with trusted, signed installation files, extensive descriptions, ranks, comments, etc. But it should not be the only place. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Jerome Haltom napisał(a): I wanted to point you to my existing effort with regards to this: https://wiki.ubuntu.com/GAptI Someday I will in fact finish this. Please take a look at it though. Yes, I have seen it long time ago. But it supports only APT. One Click Installer strives to be the solution for all Linux (and non-Linux) distributions. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Jerome Haltom napisał(a): Now that I actually read this, I don't see any actual difference between it and GAptI. Is there one? Other than the file being some weird XMLish thing. With hard coded command line options in it. Command line option was added as hack specifically to support installing Skype deb from their repository. I couldn't believe it but they have put repository with debs without signing it! It will go away as soon as I find better solution. I choose the format I choose for GAptI because it was keeping in-line with the traditional Name: Value pair format used by both dpkg and apt itself. Not whole worlds is using apt. XML is more flexible when it comes to supporting unexpected things. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Matt Zimmerman napisał(a): So Ubuntu could just provide signed files for applications hosted in its repository, signed with its key for use by everyone else. Files would be hosted on Ubuntu server and everyone else (forum support people, bloggers, journalists, ...) could just provide links to these files instead of creating them on their own. There is no need for Ubuntu to provide additional metadata for the thousands of programs available in the repositories. Instead, the metadata file need only provide the name of the package, and the local package manager can install it from the official repository. This provides the experience of locating the software on the web while retaining the security and maintenance characteristics of the distribution model. This is the approach of apt:// protocol. It is not extensible and it will not make Ubuntu competitive to rich software ecosystem of Windows. There _must_ be the way for third party software creators to publish their software easily. Otherwise they will not be interested in creating their apps for Linux. And if you want to provide higher security, you can turn off installing unsigned files in One Click Installer. This way inexperienced users will not be able to install untrusted software easily. But of course advanced users will be able to work around it. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Jerome Haltom napisał(a): So this works for Yum too? Not yet, but I hope it will. And Yast, ebuild and TGZ as well. I can create versions for most popular packaging/distribution systems, but it is up to distribution developers to integrate it or add support for their unique packaging system. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Greg K Nicholson napisał(a): Krzysztof Lichota: Creator of One Click Installer installation file decides which repository will be used. If the application is available in Ubuntu repository I do not see the point why he would prefer to point to some other repository. Maybe the OCI file's creator uses a different distro. This is supposed to be distro-neutral, right? Right. But if the application is in an official, supported repository for given distro, it is better for the author to point to such repository as its quality should be higher than some other, third party. Unless the third party provides some feature which is not available in official version, but well, it is a tradeoff here. It is up to installation file author to balance what he thinks is better. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Scott Kitterman napisał(a): On Tuesday 07 August 2007 15:57, Krzysztof Lichota wrote: This is the approach of apt:// protocol. It is not extensible and it will not make Ubuntu competitive to rich software ecosystem of Windows. There _must_ be the way for third party software creators to publish their software easily. Otherwise they will not be interested in creating their apps for Linux. I spend a lot of time packaging software for the Debian packaging system. It sounds to me like you believe this is a waste of my time because a generally extensible packaging system that will result in reliable installations across diverse architectures and hardware either exists or it trivial to create. Is that right? No, you got completely the wrong idea. Deb packages built for specific distro are useful as they provide best integration with underlying distribution. And One Click Installer does not at all address the issue of common packaging format or whether DEB is better than RPM. It is just a convenient way for users to have their favourite app installed without knowing what their distro is, what their packaging system is, how to add repository, how to update it, how to add keys, etc. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Scott Kitterman napisał(a): OK, so for a Debian system, where do the.debs come from that One Click is needed for? The debs are already in repositories. It is about giving users easy access to them. This is the part that keeps confusing me. You seem to think if installing were just easier, people would install more stuff (probably true), but I think the real limiting factor is getting the stuff properly packaged. Try reading forum posts or the Scribus page I have mentioned (http://www.scribus.net/index.php?name=Sectionsreq=viewarticleartid=4page=1). They are full of descriptions how to add repository, how to add key, etc. Repeated all over again. And in many cases they go to most common denominator (modifying /etc/apt/sources.list and using apt-key in console), because if they describe one application (like Synaptic), then user might be using different (like Adept). Now imagine you are user who wants to install application. And he must take so many difficult steps to achieve simple goal - installing application. Or you are an application author which can either depend on his users to know how to add repository, or he can create description how to do it once again. This is the problem I am trying to solve. Krzysztof Lichota signature.asc Description: OpenPGP digital 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
Announcement: One Click Installer
and backend it should be quite easy to implement other frontends (especially Gtk). If you can want to help with development (adding other frontends, backends and porting to distributions), please write to project mailing list: [EMAIL PROTECTED] File format specification could especially benefit from look of some XML guru, as I am definitely not XML expert. Please forward this announcement to people who might be interested in creating cross-distribution installation file format (in Debian, Suse, Mandriva, etc.). Having common, simple installation wizard will be benefit for everyone. One Click Installer has been developed for my Ubuntu derived distro: Olá! OS (http://ola-os.com - in Polish) and is used to provide my users with online software catalog. I want to contribute it back to Ubuntu community as part of thanks for creating such great distro :) Comments welcome Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Kevin Fries napisał(a): On Mon, 2007-08-06 at 13:03 -0600, Conrad Knauer wrote: Individual DEB files installed with Gdebi provide this sort of thing currently (e.g. try http://www.getdeb.net/) Or even better: http://digg.com/linux_unix/Ubuntu_Install_applications_from_Internet_with_a_single_click?t=7711876 This solution works first of all within the existing distribution tools, and second without trying to turn Linux into Windows. We all know how well the first Windows turned out, and the OP does not get that point. People are seeking something better than Windows. Many will tell you otherwise, but when pushed, I think overall satisfaction with Windows is right up their with the cell phone companies... Nobody is happy, but don't feel that Linux or Mac are realistic choices... Resolving that misconception about the usability of Linux is how we solve Bug #1. I am not suggesting to create installers like in Windows. If you look at the architecture of One Click Installer, it leverages good ideas in Linux software management (packages with software for easy uninstallation without leaving rubbish, dependencies, repositories, signing, etc.) to create ease of use similar to Windows installers or even better (one link to click for all versions, not a few). As for apt:// protocol idea, it has the same problem as Klik - centralization. In order to have flourishing software ecosystem we have to provide third party application developers, packagers and users opportunity to provide their own installation repositories, which suit their needs. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Greg K Nicholson napisał(a): Conrad Knauer: On 8/6/07, Krzysztof Lichota [EMAIL PROTECTED] wrote: Package installation applications (Synaptic, Adept) and apt repositories do not solve the problem for the following reasons: 1. Repositories must be added manually and this exceeds skills of average Windows user. Keys must be added also and repositories updated. Too many steps, too difficult. Solve this! :-) Seriously, this is the problem that needs a good solution. The apt protocol ( https://wiki.ubuntu.com/AptFirefoxFileHandler ) will fix this. Yes, this is similar to what I want to achieve, but: - it does not provide information for different distributions and other systems than APT - it does not provide multiple versions for different distribution versions - it does not provide localized application descriptions And I do not think such amount of information should be put in URLs, it is just too big. URLs should not hold data. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Announcement: One Click Installer
Chris Wagner napisał(a): Every time someone comes up with a new, more-intuitive way to install software on Linux, there seems to be more negative comments about it than positive. I recall similar comments when Gdebi was proposed, but it seems to have gone over okay. I only see one major flaw in Krzysztof's model: security. (Am I wrong? Are there other serious problems?) Unfortunately, that's arguably the most important issue. Rather than shrug off this solution, though, why not come up with a mechanism for making it (at least somewhat) secure? I completely agree the security is important. One Click Installer files can be signed using GPG key. If the file is unsigned, user is asked if he wants to proceed with explanation why he should not install not signed file and the default option is to cancel installation. In first implementation I have completely disallowed unsigned files, but it would prevent creating installation files by anyone else than distribution developer with access to its signing key. So I dropped it as too strict. But it is easy to provide, for example, a configuration option to forbid installing unsigned files and provide way for advanced users to skip it. If the file is signed, but the key is not trusted (see below), the installation stops with verification failure. The trust delegation is currently based on keys used by apt. If the key is trusted by apt to sign repositories, then it is trusted to sign installation files. In particular, keys used to sign Ubuntu archive are trusted as signers of installation files, so Ubuntu developers can sign installation files they think are trustworthy and they will be shown as trusted by Ubuntu users of One Click Installer. The rationale behind that is that if key is trusted to install packages, then these packages can do anything during installation or later as they run with root privileges during installation. The undesirable effect of this scheme is that if you install repository of some person you delegate the trust to create installation files to him. If someone can come up with better scheme, I would be happy to implement it in One Click Installer. Krzysztof's solution seems like the quickest possible way to have a cross-distro (even potentially to non-Linux OS's) method for installing software. Exactly, One Click Installer file can hold any kind of installation data, even for FreeBSD, Solaris or any other OS. Of course, the ideal solution would involve all Free Software platforms using a common, all-in-one package management system, but that day is a bit far off. Right. We have to do whatever we can until this day comes :) Installing software via the Web is not just a bad habit created by Microsoft Windows; it makes sense. What isn't a good idea, is installing random bits of software from untrusted sources. Even as an advanced GNU/Linux user, I would venture to say that I *usually* discover new software via the Web. For me, a system like One Click Installer is just an extra convenience (it often just saves me the time of apt-get install ...). For most people, however, it could be the difference between understanding how to get along with Linux, and not. I couldn't agree more. Thank you for your balanced and insightful post :) Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Looking for mentor for Google SoC idea - application start prefetching
Krzysztof Lichota napisał(a): Matthias Klose napisał(a): Full text of application: http://www.mimuw.edu.pl/~lichota/soc2007-prefetch/application.html Please could you write down the project idea in a wiki page at wiki.ubuntu.com? Use the SpecTemplate for the page. If you didn't already apply (see [1]), then please do so before Mar 26. Evaluation and ranking of the submitted projects will start next week. I have already applied using Google WebApp. I will put the description on wiki in a few days. Is there any special place where I should add link to this wiki page? Should I create spec in Launchpad? I have added the wiki page (https://wiki.ubuntu.com/AutomaticBootAndApplicationPrefetchingSpec), but I don't know what to do next. Should I link it from some other page? Krzysztof Lichota signature.asc Description: OpenPGP digital 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: Desktop responsiveness in Feisty (vs Edgy)
Scott Henson napisał(a): Sitsofe Wheeler wrote: Hi, Has there been a change to which preemption patches are included in the default Ubuntu kernel used in Feisty? I ask because I seem to have noticed far more stutters (both when sound is played and when moving things like the mouse pointer in X) and periods of up to half a second where interaction is not possible. I think what you want is to install linux-lowlatency. It should give you more responsiveness at the cost of battery life (if your on a laptop) and a slightly busier processor. Once you have installed it, reboot into the new lowlatency kernel. I don't think that mouse getting stuck for half second is normal for any kernel. It must be a bug. Low-latency kernel is for special purposes, not for getting normal system responsiveness. Krzysztof Lichota signature.asc Description: OpenPGP digital 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: An Entirely Different Approach on LiveCD Installer.
Jonathan Carter napisał(a): As for the RHGB/Firstboot idea, I tend to agree with you. We already do it in tuXlabs, where we have a dialog that pops up before the desktop loads on the live CD, asking whether the user wants to install, or use the LiveCD. This makes it possible to install using Ubiquity on a machine with only 128MB RAM. How did you do it? I have tried it by spawning only Xserver+window manager+Ubiquity, but 128 MB was still not enough. Is your version available somewhere? Krzysztof Lichota signature.asc Description: OpenPGP digital 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
