Easy "Add/Remove Porgrams" for non-sudoers with local PREFIX?

2007-12-20 Thread Carsten Agger
Like in many packages, you can say

./configure PREFIX=~/bin

you'll install the package locally and don't need to be superuser. Are
there any plans to integrate this functionality with synaptic/Add-Remove
for non-sudoers, or am I missing something?

br
Carsten

--
http://www.modspil.dk


-- 
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: regular fsck runs are too disturbing

2007-12-20 Thread Chris Jones
>>A little while ago there was a discussion here about fsck running at
>>boot,
>>and the program AutoFsck. The author of AutoFsck just contacted me and
>>asked
>>me what his next step should be. I don't have any official standing in
>>the
>>Ubuntu dev community, so I'm just going to forward his message out
>>here in
>the hopes that it will get opened up for a more comprehensive
>>discussion.

>>Evan

>>PS I also sent him a link to join this list, so hopefully he'll be
>>able to
>>contribute to the discussion.


I too was contacted by a Jonathon Musther.
But the email I received was different. It reads...

Hi Chris Jones 
 
I wouldn\'t normally use this mailing list for anything other than
announcements about new versions of AutoFsck.  But I have been inundated
with people requesting information on how to promote AutoFsck, and get
it (or something with the functionality) into the Ubuntu distribution.
I\'ve been trying to do this myself for a long time, but have not got
very far.  To this end I have set up a petition at the bottom of the
page:
http://wiki.ubuntu.com/AutoFsck

Please read it and consider adding your name.

Also feel free to email me if you have any comments, suggestions etc:
[EMAIL PROTECTED]

Kind Regards

Jonathan Musther
 


I'm not quite sure why I received it either. I suspect it's just because
I'm a member of the AutoFsck Mailing List.


-- 
Chris Jones <[EMAIL PROTECTED]>


-- 
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: fsck on boot is major usability issue

2007-12-20 Thread Mario Vukelic

On Thu, 2007-12-20 at 22:17 +0100, Mario Vukelic wrote:
> When ext3 was new, I am pretty certain that I have read quotes by
> Theodore T'so that he does not recommend turning off the checks. It's
> been a long time though, and searching now turns up nothing definitive
> for me.


Ah, I think I found an incomplete quote of what I had in mind. It's not
really conclusive, and I'd like to know that was edited out
anyway. http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html

"Q: If a system shutdown hard, even with journaling is it at all
necessary to run e2fsck?

Theodore Ts'o said:

It's best to just always run e2fsck. [...]
E2fsck will run the journal automatically, and if the filesystem is
otherwise clean, it skip doing a full filesystem check.
If the filesystem is not clean (because during the previous run the
kernel noticed some filesystem inconsistencies), e2fsck will
automatically do a full check if it is necessary.
If you have multiple disks, fsck will run multiple e2fsck processes in
parallel, thus speeding up your boot sequence than if you let the kernel
replay the journal for each filesystem when it tries to mount it, since
then the journal replays will be done sequentially, instead of in
parallel."

Here's Stephen Tweedie, he clearly states that no fsck is needed after a
dirty unmount, but I don't find anything on periodic scheduled checks
(which can be scheduled only on a server, not a personal computer). Is
Tweedie still at RedHat? If so it should be no problem to ask.
http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html

"And some of these EXT2 filesystems are getting really rather big. Even
24 months ago, there were people building 500 gigabyte EXT2 filesystems.
They take a long time to fsck. I mean, really. These are filesystems
that can take three or four hours just to mkfs. Doing a consistency
check on them is a serious down time. So the real objective in EXT3 was
this simple thing: availability. When something goes down in EXT3, we
don't want to have to go through a fsck. We want to be able to reboot
the machine instantly and have everything nice and consistent.

And that's all it does. It's a minimal extension to the existing EXT2
filesystem to add journaling. And it's really important, EXT2 is the
workhorse filesystem. It's the standard stable filesystem. We don't want
to turn EXT2 into an experimental filesystem. For one thing, users
expect to have EXT2 there as a demonstration of how to code filesystems
for Linux. It's a small, easily understood filesystem which demonstrates
how to do all of the talking to the page cache, which has changed in
2.4, all of the locking in the directory handling, which has changed in
2.4. All of these changes in the VFS interface and the VM interface that
filesystems have to deal with are showcased in EXT2. So there are
multiple reasons why we really do not want to start making EXT2 into an
experimental filesystem, adding all sorts of new destabilizing features.
And so the real goal for EXT3 was to provide the minimal changes
necessary to provide a complete journaling solution. [03m, 26s]

So it provides scaling of the disk filesystem size and it allows you to
make larger and larger filesystems without the fsck penalty."



-- 
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: fsck on boot is major usability issue

2007-12-20 Thread Mario Vukelic

On Fri, 2007-12-21 at 09:44 +1300, Jonathan Musther wrote:
> I would very much like to hear from somebody on the ext3 team about
> this.

When ext3 was new, I am pretty certain that I have read quotes by
Theodore T'so that he does not recommend turning off the checks. It's
been a long time though, and searching now turns up nothing definitive
for me.

I find the long-standing insecurity abut this topic very weird, though.
If an important ext3-using distro like Ubuntu asked the ext3 team,
wouldn't they get an answer quickly? I would think so.


-- 
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 Screens/Resolutions Management - or the reason i still MUST use m$ windows

2007-12-20 Thread Sid Arth
What card are you using? I was just wondering if anybody else is
having troubles with nvidia cards and two monitors?

On Dec 16, 2007 6:58 PM, (``-_-´´) -- Fernando <[EMAIL PROTECTED]> wrote:
> Hi there.
> I meant to write this email to Ubuntu-Desktop ML, but since you brought this 
> topic, I'll reply here.
>
> Last Saturday, I did a small presentation on apt-cacher, and using Ubuntu 
> Hardy, without any xorg.conf due to the new X 7.3 and xrandr 1.2, and plug-in 
> for the
> first time a projector (@ 1024x768 vs 1280x800 12.1" LCD) with hardy on my 
> 855 Intel, it was a great surprise that (almost) everything "Just Worked".
> After GDM started, I could see both screens. Sure, some parts of it were 
> cut-off 'cause of the 1024<1280.
> After login, i just clicked on Grandr v0.2 applet and changed the resolution 
> to 1024. For some freak setting, my LCD got turned off, and I was left with 
> only the
> projector.
> I opened up a console, and typed xrandr --auto. My LCD turned on, the top and 
> bottom bars were set to 1024 px, but I still could see and use an extra screen
> space at the right of the screen.
>
> Bottom line, at least on Hardy, most of it worked great, and even better then 
> using displayconfig-gtk (which requires X restart) or grandr UI ( that seems 
> to not
> work that great on current xrandr and crashs a bit).
> Didnt had the time to test using xrandr  --left-of /--right-of 
>  (to have a dual-monitor system, instead of clone screen system) or 
> --size (to fix
> my LCD strange look), but I guess I'll give it a go with an external CRT/LCD 
> this week.
>
> Sure, I agree with you, that the OS/X should (automatically) detect the the 
> VGA is no longer in use, instead of requiring the  [power]user to punch 
> xrandr --auto,
> but I can live with it on an Alpha/Developement OS. My magor peeve with my 
> transaction from windows still remains the lack of S-Video / TV Out support on
> pre-9xx Intel GPUs.
>
>
>
> --
> BUGabundo  :o)
> (``-_-´´)   http://Ubuntu.BUGabundo.net
> Linux user #443786GPG key 1024D/A1784EBB
> My new micro-blog @ http://BUGabundo.net
>
> --
> 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: fsck on boot is major usability issue

2007-12-20 Thread Jonathan Musther
I've spent a lot of time looking for the reasoning behind still doing the
checks, all I've found is anecdotal evidence, some people say they have
first hand experience of errors creeping in, which were then fixed by fsck.
On the other hand some people, although a small number, have turned them off
with no apparent trouble.  I would very much like to hear from somebody on
the ext3 team about this.

I'm not against simply disabling the checks on principle, but I would want
to be confident that it wasn't going to cause problems.


On Dec 21, 2007 9:31 AM, Phillip Susi <[EMAIL PROTECTED]> wrote:

> Jonathan Musther wrote:
> > Hi,
> >   I'm new to this list, I joined it because I saw in the archive that
> > recently you were discussing the problem with running fsck on boot as a
> > 'just in case' filesystem check.  I joined the list because I'm the
> author
> > of AutoFsck, the script you discussed which effectively moves fsck to
> > shutdown, and asks the user before it is run.
>
> I still say we should just disable the checks entirely.  No other
> filesystem still does this nonsense.  It's just a holdover from ext2,
> which had it as a leftover from ext, which had it out of convention from
> minix, which did it as purely pedantic ( or did it actually perform some
> maintenance then that needed done periodically?  I can't remember ).
>
> On the other hand, your solution looks like a great improvement.
>
>


-- 
Slingshot - a unique game everyone enjoys  - and it's free :-)
http://www.slingshot-game.org
-- 
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: fsck on boot is major usability issue

2007-12-20 Thread Phillip Susi
Jonathan Musther wrote:
> Hi,
>   I'm new to this list, I joined it because I saw in the archive that
> recently you were discussing the problem with running fsck on boot as a
> 'just in case' filesystem check.  I joined the list because I'm the author
> of AutoFsck, the script you discussed which effectively moves fsck to
> shutdown, and asks the user before it is run.

I still say we should just disable the checks entirely.  No other 
filesystem still does this nonsense.  It's just a holdover from ext2, 
which had it as a leftover from ext, which had it out of convention from 
minix, which did it as purely pedantic ( or did it actually perform some 
maintenance then that needed done periodically?  I can't remember ).

On the other hand, your solution looks like a great improvement.


-- 
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


fsck on boot is major usability issue

2007-12-20 Thread Jonathan Musther
Hi,
  I'm new to this list, I joined it because I saw in the archive that
recently you were discussing the problem with running fsck on boot as a
'just in case' filesystem check.  I joined the list because I'm the author
of AutoFsck, the script you discussed which effectively moves fsck to
shutdown, and asks the user before it is run.

I've been trying (see blueprint below) to get the functionality of AutoFsck
included in Ubuntu for a long time, with no success.  I have requested
support and guidance from the ubuntu-desktop team in launchpad, with no
response, I've gone through the idea pool and forums (with great support
from users), and had no luck.  So I'm hoping that by restarting discussion
on this list, that we might be able to get somewhere.  Here is the
blueprint, and the rest of this (admittedly rather long) email deals with
the rationale for something like AutoFsck, and what we can do next:
https://blueprints.edge.launchpad.net/ubuntu/+spec/prompt-for-fsck-on-shutdown

I think it's well established now that this is a major problem in terms of
usability - whenever AutoFsck is discussed there are some people who talk
about leaving their computer on for months, there being no need to reboot,
windows users coming to linux and complaining about perfectly sane checks,
putting data at risk by running checks on shutdown rather than boot etc.  I
think it's fair to discount these simply by calling them short sighted.  The
Ubuntu distribution aims to be easy for the new user, or simply the user who
just wants to get on with browsing the web, writing documents and looking at
photos without having the OS make life difficult for them.  This ease of use
doesn't mean we have to compromise on quality, or even on advanced features
for advanced users, but this isn't an issue of a feature which is too
complex for novice users - it's an issue of bad system design from a
usability standpoint.

So, on the one hand the check is a useful safeguard against some types of
filesystem damage, and on the other it can be very annoying to the user.
The first thing to note is that this check doesn't have to be done every 30
boots, or every 20, or every 40.  Those numbers are arbitrary, the more
often you do the check, the safer you're likely to be, it's simple
arithmetic, but it would also be absurd to suggest doing it every boot
cycle.  So it doesn't matter when the check is run, boot or shutdown, or
even during the session (forgetting for the moment the technical issues with
that) - so long as it is run periodically.

As a consequence, when I wrote AutoFsck I didn't have to worry about running
checks on a strict deadline, I thoughts simply about usability.  When is the
most convenient time to run a disk check?  The obvious answer is when the
user no longer wants to use the computer, on shutdown.  But what if they are
packing away a laptop and need it to turn of right now?  Well, have a
dialogue asking if it's a good time to do the check, if they say no, shut
down and prompt them again next time.

And there we have AutoFsck, that's all it does.  There are a few other
features, an audio prompt to get the users attention, a timeout in case they
don't see the dialogue (the computer will shut down without running the
check after 2 minutes) - but essentially that's it.

Of course there are issues with AutoFsck, I'm not suggesting it should go
into the Ubuntu distribution in its current form (although it is fully
functional).  Some people worry that users will get into the habit of saying
no (when prompted to run fsck) so they don't ever run the check.  Well to be
honest that is the users right, but I see no evidence from the users of
AutoFsck - most users are more in the habit of clicking yes, it's not often
that they need to say no.

What to do now?  I'm not entirely sure, but I'm open to any suggestions,
help with AutoFsck, discussion of how we could get this functionality into
the Ubuntu distribution, discussion of the technicalities of AutoFsck, how
it works etc.

On some AutoFsck users suggestion I've created a sort of petition for this
functionality, at the bottom of:
http://wiki.ubuntu.com/AutoFsck
The idea pool thread which relates to this is:
http://ubuntuforums.org/showthread.php?p=3985270#post3985270

Jon

-- 
Slingshot - a unique game everyone enjoys  - and it's free :-)
http://www.slingshot-game.org
-- 
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

2007-12-20 Thread Phillip Susi
Morten Kjeldgaard wrote:
> Let me add my 2 cents' worth. I don't know what algorithm is used by 
> lzma, but I think there are other factors than CPU speed and size that 
> matters. Namely memory.

lzma IS the name of the algorithm, and it is used by the 7zip program.

> As an example, I can tell you that in the past we have experienced 
> problems with the quite serious memory requirements of bunzip2. In 
> several instances, we have seen bunzip2 fail for apparently mysterious 
> reasons. Eventually, it turned out, the only way to solve the problem 
> was to change the memory sticks on the motherboard. Even though 
> memtest86+ did not reveal any problems with the RAM, bunzip2 seems to be 
> extremely sensitive to (I think) how well the particular type of memory 
> is supported by the motherboard. It is possibly some kind of timing issue.

Then the hardware was bad... nothing we can do about that.  It is 
unlikely, but possible, for there to be a hardware defect that memtest86 
will not find after a lengthy run, but will crop up under different 
memory loads.

> I want to emphasize that we never had problems running gunzip 
> decompression even on the systems affected by the bunzip2 issue. As I 
> said, I don't know the lzma algorithm at all, but I fear that in such an 
> efficient compression procedure, there is a risk that similar problems 
> could appear. Needless to say, failure to decompress packages properly 
> could completely brick the system.
> 
> The gzip algorithm may not be the most efficient of all, but it is 
> extremely reliable, fast, and memory-efficient.

lzma does use more memory to decompress ( and GOBS to compress ) but I 
don't think we should hold back progress to continue to support ancient 
machines with only 8 megs of ram.

> IMHO, the 10% gain on the size of an install CD is quickly eaten by 
> new/expanded packages, and soon, the same problem/discussion will 
> return. I think the effort is better spent in making bone-hard 
> priorities on what goes on the CD and what remains available from the 
> archives.

I think the number was more like 20%, but even if it was only 10%, 
fitting 10% more on a CD is _extremely_ useful.  You can prioritize all 
you like but at the end of the day, the difference between being able to 
fit x more packages on the cd than you could otherwise is quite a 
difference, unless you already have so many on there that the additional 
ones are so far down the list of priorities as to be not useful to most 
people.

> And, perhaps, a special "try-me-out" CD edition could be designed, with 
> samples of some of the latest and greatest software, but without some of 
> the server tools and other stuff one would normally select for a running 
> system.

The desktop CD doesn't come with any server tools.


-- 
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