Re: Future of Debian uncertain?
Scott James Remnant wrote:
2-After you install the desktop environment with tasksel the gnome fonts
are "BIG". Took me a day to figure it out how to change that.
This is because the default DPI (dots per inch) setting is 100dpi,
instead of 75dpi. No idea why, there's probably a very good reason
though.
That's not what's happening. The reason for these big gnome fonts is the
order in which fonts appears in /etc/X11/fs/config file.
even if default resolution is 100 dpi the font server will put the first
well suited font from the path.
When the desktop system is installed with tasksel (It's the only way
I've do it) 100 dpi fonts appears first
than 75 dpi fonts in the font path.
I've always solve this by exchanging their positions.
Altho to be honest, I can't see why any program would have a large array
on the *STACK*!
{
int *a, i;
a = malloc(sizeof(int) * 2048);
for (i = 0; i < 2048; i++)
a[i] = 2 * i;
}
"a" itself is on the stack, using only sizeof(int *) bytes. The "array"
it points to is on the heap.
I didn't know that space allocated with malloc resides in the heap, but
it's not a common practice in large calculation programs to do that, I
asure you. Remember many of us came from FORTRAN. It's much easier to
define a big array and just begin to use it.
{
char a[8388608L];
}
That's 8MB on the stack!
Sounds more like a bug in the program to me, 8MB is more than enough
stack for anything I can think of!
Then obviously you haven't programed a big neural net, or a weather
simulation, or ....
An unlimited stack would let
infinite-recursions carry away until they took down the system, at least
8MB stops them before they go too far.
After I set stack to unlimited I made the test of runing a program that
use so big arrays that would left the system out of RAM, just to see
what happen, but to my surpprice the kernel protect itself and kill the
offender program. So this limit is really unnecesary.
Besides, you can always change the limit remember! It's not a
root-enforced limit.
$ ulimit -s unlimited
Yes, I know that now. But I don't want other people to loose the time I
lost in this stupid detail, unless they want to.
KDE is written in C++. The latest release of the GNU C++ Compiler
(g++ 3.2) breaks binary compatiblity with previous releases. Therefore
all C++ libraries are having to be recompiled before the binaries can
be.
KDE needs a LOT of libraries, these things take time.
Thank you for explain this to me.
However it doesn't quite explain the delay because there have been
unofficial repositories with kde3 for a while. How come this people can
compile the libraries for debian so fast?
Mixed would be a kind of mix of a testing debian system with the very
latest soft compiled on the fly with a system like the one Gentoo has. I
understand that Debian has some tools to generate a .deb package from
sources using a custom script, so it shouldn't be so difficult to add
dependency resolution capabilities to this system, and make this beauty
available in Debian too.
You're describing exactly what happens in unstable for the majority of
other architectures. Maintainers upload an i386 package, the
autobuilders automatically build the package for the rest.
It works, it's what we do.
So debian already have a system like the Gentoo's Portage?
And every discussion they have is OPEN, and held on OPEN mailing lists.
If you want to help, join the mailing list and offer assistance testing
things.
I would like very much to contribute even if I'm very short of time.
Now try asking RedHat, Mandrake or SuSE the same questions. I'd be
interested to hear the answers :).
I like Debian I have no plans of change to any other distro. For me it's
great your way of work and I would like to get to know it better.
Alfredo
Reply to: