Any idea when 1.4 (stable version, 1.3 is unstable) will be out? I tried the CVS code recently and it seemed a long way from releasable -- unstable, test program segfaulting like mad, etc..
Daniel
Re:malloc is pretty complicated to put in hardware
on
The New Garbage Man
·
· Score: 2
And anyway, how hard can malloc and free be?
Please write a memory management system and then come back. I'm sure there's some classic understatement using almost exactly those words that I can quote at you, but it doesn't come to mind..:-)
Yes, there is a way to keep this to once per login:
(setq menu-program-stays-running) in ~/.sawmillrc
You should also be able to add (menu-start-process) to.sawmillrc to make the menu process start in the background as soon as Sawmill starts. Viva la memory waste!:)
I haven't used KDE, and I'm not interested in getting you to switch at the moment. However, I am curious why Gnome is so slow for you, just because it doesn't seem that bad to me:-) There are two big things that can make Gnome look slow:
-> Pixmap themes. Pixmap themes suck. In particular, they suck memory. Big-time. Evidently imlib or the GTK+ pixmap engine (one or the other) leaks like a sieve, and it's even worse than a memory leak, because what it leaked is X pixmaps. This means that your X server memory usage has a tendency to grow without bound if you use pixmap themes heavily. Also, pixmap themes get redrawn way too many times (this is really a problem for GTK+ in general I think, but particularly painful when using a pixmap theme), and are very very slow in general.
-> gmc. This is probably the most useful thing about Gnome, especially for newbies. It would be nice, therefore, if it wasn't a horrible hack of porting a serial, text-based interface into a graphical, asynchronous environment. This is a large part (IMO) of why everyone wants Nautilus. gmc is not only unstable, buggy, and prone to randomly grabbing the X server and not letting go (last I checked), but it `feels' very slow. This is due to the fact that it's designed on a one-operation-at-a-time basis, so even the UI (redrawing windows, responding to clicks, etc) gets short shrift while it's running.
I use the ThinIce GTK+ theme and get decent performance (I also don't use gmc, and mainly stick the panel on the side of the screen for the CD player, pager, clock, and ICQ client)
A month after Debian freezes, we're seeing long-awaited major new revisions of various pieces of software (libc being the least notable) Did one of the founders of Debian anger the gods of the Internet or something?:-)
Luckily, the package-pools stuff will supposedly get this stuff into a 'semi-stable' distribution posthaste, although I'd be a little nervous about throwing a new libc in. [1]
Daniel
[1] OTOH,/usr/share/doc/libc/README.Debian.gz makes a lot of comments about 'new CVS checkout', so this might not be far from where we are..
No, there's a clause in the GPL that specifically forbids that..something to the effect that you can charge whatever you want for the source and the binaries together, or for the binaries alone, but that if you separate them the source has to be distributed for a price no greater than the cost of the media you use. (read the license itself for the precise terms:) )
I'm not surprised he saw a similarity. Anti-GPL/. reader: "Restrictions are evil. The GPL restricts me from harming other people. Therefore, the GPL is evil. QED." Libertarian: "Restrictions are evil. Law Foo [ insert one of several laws that are favorite targets ] restricts me from harming other people. Therefore, Law Foo is evil. QED."
These are entirely logical and correct conclusions, if you accept the premise that the liberty of the individual is more important than the liberty of other individuals. Which is why I've given up arguing with Libertarians, since from their point of view everything they say is absolutely and unshakably correct. But it's also the reason that the various rabid opponents of the GPL come off looking a lot like Libertarians, even if you think they aren't.
I don't speak German well either, but if you're replying to the guy I think you are (I read a few of these trolls when I was viewing this page un-logged in, without a minimum rating level), I suspect he actually is rather proficient in German. Look at the types of mistakes he makes, and at what he gets right -- being sort-of correct in a language can often be more difficult than being absolutely right.
I agree, though, that he's an idiot:-) Solche Dummkopfen soll die Slashdot-Meisters nicht vertragen!:)
I think that should have read 'deliberate, determined, persistent, and stubborn' -- from what I've read that this guy has written, if anyone would be foolish enough to take this to court it would be him. (I doubt he will, though)
Out of everyone who ever asked me for the code, everyone demanded it saying it's his or her god-given right to the code.
I get the feeling this guy hasn't read the GPL. That's rather the whole point of the license, that everyone *does* have a God-given right to the code.
Daniel
Re:Will Apple finally see OpenSource light at last
on
MacOS X DP3
·
· Score: 2
Uh, as I recall:
(a) OpenGL was designed for hardware acceleration, (b) it's been around longer than D3D (c) Microsoft still pushes D3D over OpenGL (not surprising, since GL is (somewhat) cross-platform while D3D is Windows-specific) and only grudgingly includes GL support in Windows. (not that I've used Windows recently, so this may have changed)
I haven't used either API extensively, so I can't compare their functionality, but saying that OpenGL only got hardware acceleration after D3D had been around is a blatant falsehood -- had Microsoft put the effort into OpenGL that they had into D3D..well, actually, Windows would be in much more trouble now than it is, due to programs being written to portable specifications. [1] Hmm, maybe that's why they didn't do it?
Daniel
PS - I don't have a SBLive, I don't have a force-feedback joystick, I don't have a GeForce; I just have an AWE32 and an old Number 9 video card, and I'm perfectly happy that way, thank you.
[1] Actually, in an environment that encourages people to use types like DWORD and assume they're 32 bits, this might not be something to worry about..
One other place where object-orientation is particularly useful is in user interfaces; in your average interface (especially GUIs, but curses interfaces can have this too) you have absolutely TONS of places where you want to do objectey things. Now, it's not necessarily object-orientation done in the C++/Java style (as a random example, GTK+'s signals don't map well at all onto that object framework) but it is almost always object-oriented to some degree.
I prefer...c over lisp by far...because I prefer something thats powerfull but is clean, logically and supporters concise
You haven't used Lisp, have you?
Lisp (actually Scheme) code:
(define a '(1 2 3 4 5 6 7)) (define f (lambda (x) (lambda (y) (map (lambda (n) (+ n x)) y)))) (define b ((f 5) a)) (define c ((f 6) a))
(b is '(6 7 8 9 10 11 12), c is '(7 8 9 10 11 12 13))
I tried but failed to write the equivalent C code. However, here's the equivalent of (map (lambda (n) (+ n 1)) lst) in c, except that it modifies the list in place:
typedef int (*unaryfunc)(int);
int addone(int x) { return x+1; }
void map(int *lst, int len, unaryfunc f) { int i; for(i=0; ilen; i++) lst[i]=f(lst[i]); }
When you get down to it, scripting languages themselves are the wrong way to do things. Sure, they save one programmer some hours, but they cost millions of people CPU time.
If you've done any programming, you should know that the first rule of optimization is to optimize where it matters. If all of the CPU-intensive functions of a program are written in a low-level language, scripting languages can be incredibly helpful as the logical 'glue' to bind the low-level bits together. This is not a CPU-intensive task, generally, and makes the program more extensible and (generally) easier to write at the high level. For an example of this, compare Sawmill, which wraps low-level C window management functions in Lisp and encodes all higher-level operations in Lisp routines, with Enlightenment, written entirely in the ever-so-efficient language of C. How do they compare? Sawmill is faster, stabler, has a smaller memory footprint, and is infinitely more extensible than Enlightenment. And to pick a more fair opponent, it doesn't compare shabbily at all to some of the more 'lightweight' window managers such as fvwm or icewm; it's slightly less efficient, but not nearly as much as Enlightenment.
As long as the lowest level of stuff, where (presumably) the majority of CPU time is spent, is done efficiently, efficient design is far more important than highly optimized machine code.
I have 0.3.18, but it's been in there for several versions. Look:
bluegreen:~> sudo apt-get --reinstall install hello Reading Package Lists... Done Building Dependency Tree... Done 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded. Need to get 19.5kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n]
(and it would let me reinstall hello if I hit "yes")
dpkg should be fine with this situation if the dependencies are right -- if you remove or purge libesd0 with a --force option the worst that'll happen is that libesd-alsa0 will not install, but you'll be able to reinstall libesd0 without any problems.
I also don't have any idea how to report bugs
Have you looked at the reportbug package? I also remember reading a reference to a Web-based bug reporter, although I have no clue where it is..
This gets brought up at regular intervals on debian-devel, and I believe is a longstanding wishlist item for Apt. (in fact, the apt internal structures have fields which I *think* are placeholders for tracking whether a package was installed to fulfill dependencies (the necessary information to implement this feature) )
One thing that concerns me about it is that while it makes things easy for the hypothetical New User[tm], you can get into serious trouble here with installing a library originally to fulfill a dependency, linking against it (or worse, since -dev packages depend on the library, downloading a binary linked against it) yourself, and then later removing the package depending on the library.
On the other hand, that's a rather esoteric failure case and might not be relevant. And I'm not in charge of libapt development anyway, I just use it:-)
Daniel
PS - it's possible but not really necessary (I think, 5-second conclusion, may be wrong!) to refcount, since apt tracks reverse dependencies as well as dependencies -- just iterate over the newly removed package's reverse depends and see if it still fulfills any other dependencies.
I'd like to add a brief note to my earlier reply -- abstracting the packaging system is difficult for large and complex packages, but those aren't the ones that it's really hard to keep up with, as there are relatively few of them. What this would really benefit would be packages that install a few files in/usr/bin (on Debian systems at least) and maybe some data files under/usr/share -- for example, your average weekend-hack game.
Autoconf already provides a mechanism for flexibly selecting where to install a package based (I think?) on system defaults -- for example, $datadir and $bindir -- and if used properly it *could* (er, theoretically) be extended to automatically generate a minimal proper package for various target systems. You might even get it to generate some simple package information -- eg, menufiles. It wouldn't cover every eventuality, but for small programs, or programs with simple needs, it'd be a start.
Now, the real question is, how many of these games would you trust the binaries of?:-)
Slashdot Mirror
Any idea when 1.4 (stable version, 1.3 is unstable) will be out? I tried the CVS code recently and it seemed a long way from releasable -- unstable, test program segfaulting like mad, etc..
Daniel
And anyway, how hard can malloc and free be?
:-)
Please write a memory management system and then come back. I'm sure there's some classic understatement using almost exactly those words that I can quote at you, but it doesn't come to mind..
Daniel
Yes, there is a way to keep this to once per login:
.sawmillrc to make the menu process start in the background as soon as Sawmill starts. Viva la memory waste! :)
(setq menu-program-stays-running) in ~/.sawmillrc
You should also be able to add (menu-start-process) to
Daniel
I haven't used KDE, and I'm not interested in getting you to switch at the moment. However, I am curious why Gnome is so slow for you, just because it doesn't seem that bad to me :-) There are two big things that can make Gnome look slow:
-> Pixmap themes. Pixmap themes suck. In particular, they suck memory. Big-time. Evidently imlib or the GTK+ pixmap engine (one or the other) leaks like a sieve, and it's even worse than a memory leak, because what it leaked is X pixmaps. This means that your X server memory usage has a tendency to grow without bound if you use pixmap themes heavily. Also, pixmap themes get redrawn way too many times (this is really a problem for GTK+ in general I think, but particularly painful when using a pixmap theme), and are very very slow in general.
-> gmc. This is probably the most useful thing about Gnome, especially for newbies. It would be nice, therefore, if it wasn't a horrible hack of porting a serial, text-based interface into a graphical, asynchronous environment. This is a large part (IMO) of why everyone wants Nautilus. gmc is not only unstable, buggy, and prone to randomly grabbing the X server and not letting go (last I checked), but it `feels' very slow. This is due to the fact that it's designed on a one-operation-at-a-time basis, so even the UI (redrawing windows, responding to clicks, etc) gets short shrift while it's running.
I use the ThinIce GTK+ theme and get decent performance (I also don't use gmc, and mainly stick the panel on the side of the screen for the CD player, pager, clock, and ICQ client)
Daniel
Isn't *STEP supposed to be a standard framework of some kind?
Daniel
A month after Debian freezes, we're seeing long-awaited major new revisions of various pieces of software (libc being the least notable) Did one of the founders of Debian anger the gods of the Internet or something? :-)
/usr/share/doc/libc/README.Debian.gz makes a lot of comments about 'new CVS checkout', so this might not be far from where we are..
Luckily, the package-pools stuff will supposedly get this stuff into a 'semi-stable' distribution posthaste, although I'd be a little nervous about throwing a new libc in. [1]
Daniel
[1] OTOH,
No, there's a clause in the GPL that specifically forbids that..something to the effect that you can charge whatever you want for the source and the binaries together, or for the binaries alone, but that if you separate them the source has to be distributed for a price no greater than the cost of the media you use. (read the license itself for the precise terms :) )
Daniel
I'm not surprised he saw a similarity. /. reader: "Restrictions are evil. The GPL restricts me from harming other people. Therefore, the GPL is evil. QED."
Anti-GPL
Libertarian: "Restrictions are evil. Law Foo [ insert one of several laws that are favorite targets ] restricts me from harming other people. Therefore, Law Foo is evil. QED."
These are entirely logical and correct conclusions, if you accept the premise that the liberty of the individual is more important than the liberty of other individuals. Which is why I've given up arguing with Libertarians, since from their point of view everything they say is absolutely and unshakably correct. But it's also the reason that the various rabid opponents of the GPL come off looking a lot like Libertarians, even if you think they aren't.
Daniel
I don't speak German well either, but if you're replying to the guy I think you are (I read a few of these trolls when I was viewing this page un-logged in, without a minimum rating level), I suspect he actually is rather proficient in German. Look at the types of mistakes he makes, and at what he gets right -- being sort-of correct in a language can often be more difficult than being absolutely right.
:-) Solche Dummkopfen soll die Slashdot-Meisters nicht vertragen! :)
I agree, though, that he's an idiot
Daniel
I think that should have read 'deliberate, determined, persistent, and stubborn' -- from what I've read that this guy has written, if anyone would be foolish enough to take this to court it would be him. (I doubt he will, though)
Daniel
Good point. He's still wrong, though, since he was referring to people who had downloaded the source from him. :-)
Daniel
Yes.
They do it, but there's an old saying about might and right. You may have heard it.
Daniel
Out of everyone who ever asked me for the code, everyone demanded it saying it's his or her god-given right to the code.
I get the feeling this guy hasn't read the GPL. That's rather the whole point of the license, that everyone *does* have a God-given right to the code.
Daniel
Uh, as I recall:
(a) OpenGL was designed for hardware acceleration,
(b) it's been around longer than D3D
(c) Microsoft still pushes D3D over OpenGL (not surprising, since GL is (somewhat) cross-platform while D3D is Windows-specific) and only grudgingly includes GL support in Windows. (not that I've used Windows recently, so this may have changed)
I haven't used either API extensively, so I can't compare their functionality, but saying that OpenGL only got hardware acceleration after D3D had been around is a blatant falsehood -- had Microsoft put the effort into OpenGL that they had into D3D..well, actually, Windows would be in much more trouble now than it is, due to programs being written to portable specifications. [1] Hmm, maybe that's why they didn't do it?
Daniel
PS - I don't have a SBLive, I don't have a force-feedback joystick, I don't have a GeForce; I just have an AWE32 and an old Number 9 video card, and I'm perfectly happy that way, thank you.
[1] Actually, in an environment that encourages people to use types like DWORD and assume they're 32 bits, this might not be something to worry about..
Unless your definition of "fad" includes languages that have been around, AFAIK, nearly as long as computers..
Daniel
One other place where object-orientation is particularly useful is in user interfaces; in your average interface (especially GUIs, but curses interfaces can have this too) you have absolutely TONS of places where you want to do objectey things.
Now, it's not necessarily object-orientation done in the C++/Java style (as a random example, GTK+'s signals don't map well at all onto that object framework) but it is almost always object-oriented to some degree.
Daniel
I prefer...c over lisp by far...because I prefer something thats powerfull but is clean, logically and supporters concise
You haven't used Lisp, have you?
Lisp (actually Scheme) code:
(define a '(1 2 3 4 5 6 7))
(define f (lambda (x) (lambda (y) (map (lambda (n) (+ n x)) y))))
(define b ((f 5) a))
(define c ((f 6) a))
(b is '(6 7 8 9 10 11 12), c is '(7 8 9 10 11 12 13))
I tried but failed to write the equivalent C code. However, here's the equivalent of (map (lambda (n) (+ n 1)) lst) in c, except that it modifies the list in place:
typedef int (*unaryfunc)(int);
int addone(int x)
{
return x+1;
}
void map(int *lst, int len, unaryfunc f)
{
int i;
for(i=0; ilen; i++)
lst[i]=f(lst[i]);
}
.
.
.
map(some_lst, some_lst_len, addone);
Tell me that's more logical and concise?
Daniel
When you get down to it, scripting languages themselves are the wrong way to do things. Sure, they save one programmer some hours, but they cost millions of people CPU time.
If you've done any programming, you should know that the first rule of optimization is to optimize where it matters. If all of the CPU-intensive functions of a program are written in a low-level language, scripting languages can be incredibly helpful as the logical 'glue' to bind the low-level bits together. This is not a CPU-intensive task, generally, and makes the program more extensible and (generally) easier to write at the high level.
For an example of this, compare Sawmill, which wraps low-level C window management functions in Lisp and encodes all higher-level operations in Lisp routines, with Enlightenment, written entirely in the ever-so-efficient language of C.
How do they compare? Sawmill is faster, stabler, has a smaller memory footprint, and is infinitely more extensible than Enlightenment. And to pick a more fair opponent, it doesn't compare shabbily at all to some of the more 'lightweight' window managers such as fvwm or icewm; it's slightly less efficient, but not nearly as much as Enlightenment.
As long as the lowest level of stuff, where (presumably) the majority of CPU time is spent, is done efficiently, efficient design is far more important than highly optimized machine code.
Daniel
I have 0.3.18, but it's been in there for several versions. Look:
bluegreen:~> sudo apt-get --reinstall install hello
Reading Package Lists... Done
Building Dependency Tree... Done
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 4 not upgraded.
Need to get 19.5kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n]
(and it would let me reinstall hello if I hit "yes")
Daniel
dpkg should be fine with this situation if the dependencies are right -- if you remove or purge libesd0 with a --force option the worst that'll happen is that libesd-alsa0 will not install, but you'll be able to reinstall libesd0 without any problems.
I also don't have any idea how to report bugs
Have you looked at the reportbug package? I also remember reading a reference to a Web-based bug reporter, although I have no clue where it is..
Daniel
Of course you're right. I don't think too clearly after about 10:00PM, I'm afraid.. :-)
Daniel
This gets brought up at regular intervals on debian-devel, and I believe is a longstanding wishlist item for Apt. (in fact, the apt internal structures have fields which I *think* are placeholders for tracking whether a package was installed to fulfill dependencies (the necessary information to implement this feature) )
:-)
One thing that concerns me about it is that while it makes things easy for the hypothetical New User[tm], you can get into serious trouble here with installing a library originally to fulfill a dependency, linking against it (or worse, since -dev packages depend on the library, downloading a binary linked against it) yourself, and then later removing the package depending on the library.
On the other hand, that's a rather esoteric failure case and might not be relevant. And I'm not in charge of libapt development anyway, I just use it
Daniel
PS - it's possible but not really necessary (I think, 5-second conclusion, may be wrong!) to refcount, since apt tracks reverse dependencies as well as dependencies -- just iterate over the newly removed package's reverse depends and see if it still fulfills any other dependencies.
You can reinstall packages with "apt-get --reinstall install foopkg".
Daniel
(try extracting a deb or rpm without the proper tools...
./ ./postinst ./prerm ./postrm ./shlibs ./control ./md5sums
./ ./usr/ ./usr/bin/ ./usr/bin/apt-cache ./usr/bin/apt-cdrom ./usr/bin/apt-config ./usr/bin/apt-get ./usr/lib/ ./usr/lib/apt/ ./usr/lib/apt/methods/ ./usr/lib/apt/methods/cdrom ./usr/lib/apt/methods/copy ./usr/lib/apt/methods/file ./usr/lib/apt/methods/ftp ./usr/lib/apt/methods/gzip ./usr/lib/apt/methods/http ./usr/lib/dpkg/ ./usr/lib/dpkg/methods/ ./usr/lib/dpkg/methods/apt/
bluegreen:/var/cache/apt/archives> ar t apt_0.3.18_i386.deb
debian-binary
control.tar.gz
data.tar.gz
bluegreen:/var/cache/apt/archives> ar p apt_0.3.18_i386.deb control.tar.gz | tar ztv
drwxr-xr-x root/root 0 2000-02-13 05:01:14
-rwxr-xr-x root/root 1361 2000-02-13 05:01:03
-rwxr-xr-x root/root 184 2000-02-13 05:01:03
-rwxr-xr-x root/root 534 2000-02-13 05:01:03
-rw-r--r-- root/root 29 2000-02-13 05:01:14
-rw-r--r-- root/root 757 2000-02-13 05:01:14
-rw-r--r-- root/root 2707 2000-02-13 05:01:14
bluegreen:/var/cache/apt/archives> ar p apt_0.3.18_i386.deb data.tar.gz | tar ztv
drwxr-xr-x root/root 0 2000-02-13 05:01:03
drwxr-xr-x root/root 0 2000-02-13 05:00:59
drwxr-xr-x root/root 0 2000-02-13 05:01:02
-rwxr-xr-x root/root 50776 2000-02-13 05:01:02
-rwxr-xr-x root/root 157576 2000-02-13 05:01:02
-rwxr-xr-x root/root 11148 2000-02-13 05:01:02
-rwxr-xr-x root/root 129960 2000-02-13 05:01:02
drwxr-xr-x root/root 0 2000-02-13 05:01:02
drwxr-xr-x root/root 0 2000-02-13 05:00:58
drwxr-xr-x root/root 0 2000-02-13 05:01:02
-rwxr-xr-x root/root 30288 2000-02-13 05:01:02
-rwxr-xr-x root/root 17804 2000-02-13 05:01:02
-rwxr-xr-x root/root 17108 2000-02-13 05:01:02
-rwxr-xr-x root/root 65508 2000-02-13 05:01:02
-rwxr-xr-x root/root 18652 2000-02-13 05:01:02
-rwxr-xr-x root/root 64632 2000-02-13 05:01:02
drwxr-xr-x root/root 0 2000-02-13 05:00:58
drwxr-xr-x root/root 0 2000-02-13 05:00:58
drwxr-xr-x root/root 0 2000-02-13 05:00:59
.
.
.
(etc)
Daniel
Just to reply to you again..
/usr/bin (on Debian systems at least) and maybe some data files under /usr/share -- for example, your average weekend-hack game.
:-)
I'd like to add a brief note to my earlier reply -- abstracting the packaging system is difficult for large and complex packages, but those aren't the ones that it's really hard to keep up with, as there are relatively few of them. What this would really benefit would be packages that install a few files in
Autoconf already provides a mechanism for flexibly selecting where to install a package based (I think?) on system defaults -- for example, $datadir and $bindir -- and if used properly it *could* (er, theoretically) be extended to automatically generate a minimal proper package for various target systems. You might even get it to generate some simple package information -- eg, menufiles. It wouldn't cover every eventuality, but for small programs, or programs with simple needs, it'd be a start.
Now, the real question is, how many of these games would you trust the binaries of?
Daniel