From: Tim Hockin <thockin@hockin.org>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Lee Revell <rlrevell@joe-job.com>,
Linus Torvalds <torvalds@osdl.org>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: code bloat [was Re: Semaphore assembly-code bug]
Date: Sat, 30 Oct 2004 16:28:54 -0700 [thread overview]
Message-ID: <20041030232854.GA25943@hockin.org> (raw)
In-Reply-To: <200410310213.37712.vda@port.imtp.ilyichevsk.odessa.ua>
On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote:
> > Bloat is cause by feature creep at every layer, not just the app.
>
> I actually tried to convince maintainers of one package
> that their code is needlessly complex. I did send patches
> to remedy that a bit while fixing real bugs. Rejected.
> Bugs were planned to be fixed by adding more code.
> I've lost all hope on that case.
See, there is an ego problem, too. If you rewrite my code, it means
you're better than I am. Rejected.
Features win over efficiency. Seriously, look at glibc. Hav eyou ever
tried to fix a bug in it? Holy CRAP is that horrible code. Each chunk of
code itself is OK (though it abuses macrso so thoroughly I hesitate to
call it C code). But it tried to support every architecture x every OS.
You know what? I don't CARE if the glibc code compiles on HPUX or not.
HPUX has it's own libc.
> I guess this is a reason why bloat problem tend to be solved
> by rewrite from scratch. I could name quite a few cases:
From-scratch is a huge risk. But yeah, sometimes it has to be.
> It's sort of frightening that someone will need to
> rewrite Xlib or, say, OpenOffice :(
Never gonna happen.
next prev parent reply other threads:[~2004-10-30 23:29 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.58.0410181540080.2287@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <417550FB.8020404@drdos.com.suse.lists.linux.kernel>
[not found] ` <1098218286.8675.82.camel@mentorng.gurulabs.com.suse.lists.linux.kernel>
[not found] ` <41757478.4090402@drdos.com.suse.lists.linux.kernel>
[not found] ` <20041020034524.GD10638@michonline.com.suse.lists.linux.kernel>
[not found] ` <1098245904.23628.84.camel@krustophenia.net.suse.lists.linux.kernel>
[not found] ` <1098247307.23628.91.camel@krustophenia.net.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410200744310.10521@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410290805570.11823@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410290740120.28839@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <41826A7E.6020801@domdv.de.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291255400.17270@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410291103000.28839@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291631250.8616@twinlark.arctic.org.suse.lists.linux.kernel>
2004-10-30 2:04 ` Semaphore assembly-code bug Andi Kleen
[not found] ` <Pine.LNX.4.61.0410291316470.3945@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <20041029175527.GB25764@redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291416040.4844@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410291133220.28839@ppc970.osdl.org.suse.lists.linux.kernel>
2004-10-30 2:13 ` Andi Kleen
2004-10-30 9:28 ` Denis Vlasenko
2004-10-30 17:53 ` Linus Torvalds
2004-10-30 21:00 ` Denis Vlasenko
2004-10-30 21:14 ` code bloat [was Re: Semaphore assembly-code bug] Lee Revell
2004-10-30 22:11 ` Denis Vlasenko
2004-10-30 22:25 ` Lee Revell
2004-10-31 14:06 ` Diego Calleja
2004-10-31 20:53 ` Z Smith
2004-10-31 23:35 ` Rogério Brito
2004-11-01 1:20 ` Z Smith
2004-11-01 14:48 ` Diego Calleja
2004-11-01 15:09 ` [OT] " Russell Miller
2004-10-30 22:27 ` Tim Hockin
2004-10-30 22:44 ` Jeff Garzik
2004-10-30 22:50 ` Tim Hockin
2004-10-31 20:15 ` Theodore Ts'o
2004-10-31 20:21 ` Jeff Garzik
2004-10-31 21:06 ` Jan Engelhardt
2004-11-01 11:27 ` Alan Cox
2004-11-01 13:40 ` Denis Vlasenko
2004-11-01 23:04 ` Alan Cox
2004-10-30 23:13 ` Denis Vlasenko
2004-10-30 22:45 ` Alan Cox
2004-10-31 1:21 ` Z Smith
2004-10-31 2:47 ` Jim Nelson
2004-10-31 15:19 ` Alan Cox
2004-10-31 20:18 ` Z Smith
2004-11-01 11:05 ` Alan Cox
2004-10-30 23:20 ` [OT] " Lee Revell
2004-10-30 22:52 ` Alan Cox
2004-10-31 1:09 ` Ken Moffat
2004-10-31 2:42 ` Tim Connors
2004-10-31 4:45 ` Paul
2004-10-31 14:44 ` Alan Cox
2004-10-31 0:48 ` Andi Kleen
2004-10-30 23:28 ` Tim Hockin [this message]
2004-10-31 2:04 ` Michael Clark
2004-10-31 6:49 ` Jan Engelhardt
2004-10-31 21:09 ` Z Smith
2004-10-31 21:13 ` Jan Engelhardt
2004-10-31 21:48 ` Z Smith
2004-11-01 11:29 ` Alan Cox
2004-11-01 12:36 ` Jan Engelhardt
2004-11-01 15:17 ` Lee Revell
2004-11-01 16:56 ` Kristian Høgsberg
2004-10-31 6:37 ` Jan Engelhardt
2004-10-31 0:39 ` Semaphore assembly-code bug Andi Kleen
2004-10-31 1:43 ` Linus Torvalds
2004-10-31 2:04 ` Andi Kleen
2004-11-01 14:26 code bloat [was Re: Semaphore assembly-code bug] Ian Kumlien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041030232854.GA25943@hockin.org \
--to=thockin@hockin.org \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=torvalds@osdl.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).