On Friday 21 December 2007 20:04, Robert Millan wrote:
> How well does compression work for GRUB 2 ? core.img is already compressed
> (with lzo); if LZMA makes better results perhaps it'd be a good idea to
> switch.
It's not that simple. LZO was chosen instead of gzip, because of the size
requir
On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
> > - All developers are forced to install new software and learn it (always
> > a pain).
>
> Developers are used (or ought to) to learn new things since it's of
> programming art. I guess learning wouldn't be a problem.
From a theoretical
On Tuesday 18 December 2007 17:29, Pavel Roskin wrote:
> We can alleviate it by switching to software that is already widely
> used, so that the time invested into learning can be used on other
> projects. Mercusial and git are good examples, as they are used in
> many other projects. Monotone an
On Dec 22, 2007 4:06 PM, Yoshinori K. Okuji <[EMAIL PROTECTED]> wrote:
> On Friday 21 December 2007 20:04, Robert Millan wrote:
> > How well does compression work for GRUB 2 ? core.img is already compressed
> > (with lzo); if LZMA makes better results perhaps it'd be a good idea to
> > switch.
>
>
On Saturday 22 December 2007 10:03, Bean wrote:
> On Dec 22, 2007 4:06 PM, Yoshinori K. Okuji <[EMAIL PROTECTED]> wrote:
> > On Friday 21 December 2007 20:04, Robert Millan wrote:
> > > How well does compression work for GRUB 2 ? core.img is already
> > > compressed (with lzo); if LZMA makes bette
Here's a new patch, with some cleanup. The main difference is that memdisk.c
doesn't include any arch-specific code.
I've spotted a memory management problem. The memdisk image, at the location
that it's usually uncompressed, tends to collide with the payload loading
region (grub_os_area_{addr,
On Sat, Dec 22, 2007 at 12:28:26PM +0800, Bean wrote:
>
> Yes, i think this concept is great, and i just think of an improvement
> for the module.
I don't like the idea of making memdisk filesystem-dependant. But adding
a more size-oriented filesystem to GRUB would be nice of course.
> we can a
On Sat, Dec 22, 2007 at 09:28:28AM +0100, Yoshinori K. Okuji wrote:
> On Tuesday 18 December 2007 13:05, Otavio Salvador wrote:
> > > - All developers are forced to install new software and learn it (always
> > > a pain).
> >
> > Developers are used (or ought to) to learn new things since it's of
>
On Saturday 22 December 2007 13:18, Robert Millan wrote:
> Here's a new patch, with some cleanup. The main difference is that
> memdisk.c doesn't include any arch-specific code.
You forgot to attach it. :)
Okuji
___
Grub-devel mailing list
Grub-devel
On Saturday 22 December 2007 12:24, Robert Millan wrote:
> On Sat, Dec 22, 2007 at 12:28:26PM +0800, Bean wrote:
> > Yes, i think this concept is great, and i just think of an improvement
> > for the module.
>
> I don't like the idea of making memdisk filesystem-dependant. But adding
> a more size
On Saturday 22 December 2007 12:20, Robert Millan wrote:
> On Sat, Dec 22, 2007 at 09:50:50AM +0100, Yoshinori K. Okuji wrote:
> > > Finally, things like grub4dos should not be forks, they should be
> > > branches. This would give then a better exposure. CVS branch support
> > > is pathetic, and
On Sat, Dec 22, 2007 at 09:50:50AM +0100, Yoshinori K. Okuji wrote:
> > Finally, things like grub4dos should not be forks, they should be
> > branches. This would give then a better exposure. CVS branch support
> > is pathetic, and the same applies to Subversion, although for
> > different reason
Quoting Robert Millan <[EMAIL PROTECTED]>:
Maybe you find interesting to know that I never use RCS (any of them) merging
feature at all. I prefer to extract patches from RCS and manage them myself.
I often even manage branches by hand as well.
Just to clear any misunderstanding, extracting a
13 matches
Mail list logo
