From Newsgroup: comp.lang.misc

Andy Walker <anw@cuboid.co.uk> wrote:

On 20/08/2025 01:43, Lawrence DrCOOliveiro wrote:
[I wrote:]

From time to time I wonder what would happen if we ran
7th Edition Unix on a modern computer.

The Linux kernel source is currently over 40 million lines, and I
understand the vast majority of that is device drivers.

You seem to be making Janis's point, but that doesn't seem to
be your intention?

If you were to run an old OS on new hardware, that would need drivers for
that new hardware, too.

Yes, but what is so special about a modern disc drive, monitor, keyboard, mouse, ... that it needs "the vast majority" of 40M lines more
than its equivalent for a PDP-11? Does this not again make Janis's point?

Lawrence gave a good list of things, but let me note few additional
aspects. First there is _a lot_ of different drivers. In PDP-11
times there were short list of available devices. Now there is a lot
of different devices on the market and each one potentially need a
specialised driver in the kernel. Linux actually make a good job here:
typical driver handles a group of similar devices and various tables and conditonals in the code take care of differences between devices in the
group. But still, there is a lot of different driver and generality
of a single driver means it is more complicated than driver for a
single device.

On my desktop kernel boot messages say "14342K kernel code". Nominally assuming 10 bytes per source line it means 1.4 milions of lines of
running code, so relatively small part of total kernel source.
Note that this is generic kernel provided by distribution (Debian)
which is supposed to run "on any PC". Compiling specialised
kernel one can exclude various features from the kernel. I did
not try this with recent kernels for PC, but past experience indicates
that by exluding features and device support one can get substantially
smaller kernel. I would guess 4MB for PC kernel with reasonnable
set of features and possibly smaller if one decides to drop essential
features.

Second, modern devices frequently require complex setup control.
Let me mention issue that probably does not affect PC-s but indicate
tendency. Namely, I deal with small microcontrolles. One may wish
to attach a LCD screen to such microcontroller. To setup one
particular screen one need send about 100 numerical parameters to
the chip controlling the display. Some parameters can be taken
from a simple table, but some may vary and need to be computed
by initialization routine. Once initialized display behaves as
dumb frame buffer, so is rather simple to drive. Compared to
that initialization code is surprisingly complex. Coming back
to PC devices, such devices frequently have complex initialization.
Actual operation may be more complex than earlier devices.
Simply, device manufactures tend to move complexity to driver
software.

Third, we live in era of multicore machines. OS is supposed to
efficiently utilize all cores and share work between them. This
requires a lot of carefuly placed locks and when possible special
code seqences using ordinary or atomic instructions that work
when run in parallel on different cores. That leads to bigger
code, especially at source level.

Granted that the advent of 32- and 64-bit integers and addresses
makes some programming much easier, and that we can no longer expect
browsers and other major tools to fit into 64+64K bytes, is the actual
bloat in any way justified?

I think that Linux kernel actually is somewhat reasonable range.
Early version of Linux would take say 1MB of 8MB available in the
machine. Modern Linux takes more, but it is tiny part of the
whole available memory. And given growth in functionality growth
is size of kernel binary does not look so bad.

I think that comparisons with early mainframes or PDP-11 are
misleading in the sence that on early machines programmes struggled
to fit programs into avaliable memory. Common technique was keeping
data on disc and having multiple sequential passes. Program
itself could be split into several overlays. Use of overlays
essentially vanished with introduction of virtual memory coupled
with multimegabyte real RAM. More relevant are comparisons
with VAX and early Linux.

AFAICS bloat happens mostly in user level. One reason is more
friendly attitude of modern programs: instead of numeric error
codes programs contains actual error messages. Internationalization
and Unicode add to this. GUI-s demand event driven programming,
which leads to much more complicated code than earlier programs.

Sometimes programmes get lazy. I remember essay about Netscape
mail index. I fetched it from the net and my impression was that
the author was J. Zawinsky, but I can not find it on the net now.
Anyway, the essay explained tricks used to save mail index in
rather compact space ensuring fast loading. In later versions
programmers replaced custom code by generic database, leading
to something like 50 times bigger space use and slower loading
of mail index. Overal code footprint probably also increased,
as after change it included database handling code. But there
were no need to maintain previous custom code.

One reason that modern system are big and bloated is recursive
pulling of dependencies. Namely, there is tendency to delegate
work to libraries and more generally to depend on "standard"
tools. But this in turn creates pressure on libraries and
tools to cover "all" use cases and in particular to include
rarely used functionality. In turn to provide a lot of
functiality libraries and tools delegate part/most of work
to different tools. This lead to complex dependency nets
where most of functionality in total package (that is including
all dependencies) is not needed for concrete application.

It's not just kernels and user software --
it's also the documentation. In V7, "man cc" generates just under two
pages of output; on my current computer, it generates over 27000 lines,
call it 450 pages, and is thereby effectively unprintable and unreadable,
so it is largely wasted.

For V7, the entire documentation fits comfortably into two box
files, and the entire source code is a modest pile of lineprinter output. Most of the commands on my current computer are undocumented and unused,
and I have no idea at all what they do.

Hmm, on my machine '/usr/bin' contains 2547 commands. IIRC "minimal"
install give some hundreds of commands, so most commands is from
packages that I explicitely installed or their dependencies. Of course,
I remember only minority of commands, but 'man' gives me information
about many commands (my impression is that about majority, but I did
not check this). I can easily find out which package installed given
command and packages have at least short description, so even if I forget
why I installed given package usually it is easy to find out general
purpose of a command.

Yes, I know how that "just happens", and I'm observing rather
than complaining [I'd rather write programs, browse and send/read e-mails
on my current computer than on the PDP-11]. But it does all give food for thought.

--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Sat, 4 Oct 2025 01:11:29 -0000 (UTC), Waldek Hebisch wrote:

On my desktop kernel boot messages say "14342K kernel code". Nominally assuming 10 bytes per source line it means 1.4 milions of lines of
running code, so relatively small part of total kernel source.

Sounds close to the figure that Greg Kroah-Hartman gave. He also said that
a Linux kernel build for an Android device requires about 3|u that amount
of code.

That little device in your pocket/purse is a whole lot more complex than
the ones on your desktop or in your data centre. ;)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 04/10/2025 02:11, Waldek Hebisch wrote:

Andy Walker <anw@cuboid.co.uk> wrote:

On 20/08/2025 01:43, Lawrence DrCOOliveiro wrote:

[...]

If you were to run an old OS on new hardware, that would need drivers for >>> that new hardware, too.

Yes, but what is so special about a modern disc drive, monitor,
keyboard, mouse, ... that it needs "the vast majority" of 40M lines more
than its equivalent for a PDP-11? Does this not again make Janis's point?

Lawrence gave a good list of things, but let me note few additional
aspects. First there is _a lot_ of different drivers. In PDP-11
times there were short list of available devices. Now there is a lot
of different devices on the market and each one potentially need a specialised driver in the kernel. [...]

Yes, but one would expect that to drive standardisation rather
than bloat. There are rather a lot of devices that I can plug into the
mains in my home, but I don't have to install hundreds or thousands of different types of socket.

I think that comparisons with early mainframes or PDP-11 are
misleading in the sence that on early machines programmes struggled
to fit programs into avaliable memory. Common technique was keeping
data on disc and having multiple sequential passes. Program
itself could be split into several overlays. Use of overlays
essentially vanished with introduction of virtual memory coupled
with multimegabyte real RAM. More relevant are comparisons
with VAX and early Linux.

I would take issue with some of the historical aspects, but it
would take us on a long detour. Just one comment: we've had virtual
memory since 1959 [Atlas].

AFAICS bloat happens mostly in user level. One reason is more
friendly attitude of modern programs: instead of numeric error
codes programs contains actual error messages.

The systems I've used have always used actual error messages!

[...]

One reason that modern system are big and bloated is recursive
pulling of dependencies. Namely, there is tendency to delegate
work to libraries and more generally to depend on "standard"
tools. But this in turn creates pressure on libraries and
tools to cover "all" use cases and in particular to include
rarely used functionality.

Yes, but that's the sort of pressure that needs to be
resisted; and isn't,

[...]

Hmm, on my machine '/usr/bin' contains 2547 commands. IIRC "minimal"
install give some hundreds of commands, so most commands is from
packages that I explicitely installed or their dependencies.

I have 2580 in my "/usr/bin". That is almost all from the
"medium (recommended)" installation; a handful of others have been
added when I've found something missing (I'd guess perhaps 10). Of
those I've actually used just 64! [Plus 26 in "$HOME/bin".] I
checked a random sample of those 2580; more than 2/3 I have no
idea from the name what they are for [yes, I know I can find out],
and I'm an experienced Unix user with much more CS knowledge than
the average punter. If I were to read an introductory book on
Linux, I doubt whether many more than those 64 would be mentioned,
so I wouldn't even be pointed at the "average" command.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Necke
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Tue, 7 Oct 2025 22:03:07 +0100, Andy Walker wrote:

On 04/10/2025 02:11, Waldek Hebisch wrote:

In PDP-11 times there were short list of available devices. Now
there is a lot of different devices on the market and each one
potentially need a specialised driver in the kernel. [...]

Yes, but one would expect that to drive standardisation rather than
bloat. There are rather a lot of devices that I can plug into the
mains in my home, but I don't have to install hundreds or thousands
of different types of socket.

Most of your electronic devices would not plug directly into the
mains, they would likely use some kind of DC adaptor/charger. How many
of those do you have?

You are trying to make an argument by analogy, and that is already
heading for a pitfall. Those power connections you talk about are for transferring energy, not for transferring information. Information
transfer is a much more complex business.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 08.10.2025 00:04, Lawrence DrCOOliveiro wrote:

On Tue, 7 Oct 2025 22:03:07 +0100, Andy Walker wrote:

On 04/10/2025 02:11, Waldek Hebisch wrote:

In PDP-11 times there were short list of available devices. Now
there is a lot of different devices on the market and each one
potentially need a specialised driver in the kernel. [...]

Yes, but one would expect that to drive standardisation rather than
bloat. There are rather a lot of devices that I can plug into the
mains in my home, but I don't have to install hundreds or thousands
of different types of socket.

Most of your electronic devices would not plug directly into the
mains, they would likely use some kind of DC adaptor/charger. How many
of those do you have?

You are trying to make an argument by analogy, and that is already
heading for a pitfall. Those power connections you talk about are for transferring energy, not for transferring information. Information
transfer is a much more complex business.

While analogies have, as you correctly note, an inherent problem
the key statement - to aim towards standardization; and especially
if computer scientists and experienced IT folks are involved! - is
valid and should be emphasized and supported (instead of fostering
pointless excuses, mollifying ourselves given the bad quality and
lousy design of quite some of the software we suffer from today).

Janis
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:

Not to mention that taking too long to 'polish' your product, you
risk ending up lagging behind your competitors.

I would say, the open-source world is a counterexample to this. Look at
how long it took GNU and Linux to end up dominating the entire computing landscape -- it didnrCOt happen overnight.

Actually, open source nicely illustates this. First advice to
open source projects is "release early, release often". Projects
that delay release because they are "not ready" typically loose
and eventually die.

Open source projects typically want to offer high quality. But
they have to limit their efforts to meet realease schedules.
There are compromises which know bugs get fixed: some are deemed
serious enough to block new release, but a lot get shipped.
There is internal testing, but significant part of problems
get discovered only after release.

One can significantly increase quality by limiting addition of
new featurs. But open source projects that try to do this
typically loose.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 08.10.2025 16:03, Waldek Hebisch wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:

Not to mention that taking too long to 'polish' your product, you
risk ending up lagging behind your competitors.

I would say, the open-source world is a counterexample to this. Look at
how long it took GNU and Linux to end up dominating the entire computing
landscape -- it didnrCOt happen overnight.

Actually, open source nicely illustates this. First advice to
open source projects is "release early, release often". Projects
that delay release because they are "not ready" typically loose
and eventually die.

Open source projects typically want to offer high quality. But
they have to limit their efforts to meet realease schedules.
There are compromises which know bugs get fixed: some are deemed
serious enough to block new release, but a lot get shipped.
There is internal testing, but significant part of problems
get discovered only after release.

One can significantly increase quality by limiting addition of
new featurs. But open source projects that try to do this
typically loose.

We can observe that software grows, and grows rank. My experience
is that it makes sense to plan and occasionally add refactoring
cycles in these cases. (There's also software planned accurately
from the beginning, software that changes less, and is only used
for its fixed designed purpose. But we're not speaking about that
here.) A principal advantage of the "open-source world" (or rather
the non-commercial world) is that there's neither competition nor
need to quickly throw things into the market. So this area has at
least the chance to adapt plans and contents without time pressure.
Whether it's done is another question (and project specific). It
should also be mentioned that some projects have e.g. security or
quality requirements that gets tested and measured and require some
adaptive process to increase these factors (without adding anything
new).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

antispam@fricas.org (Waldek Hebisch) wrote or quoted:

Actually, open source nicely illustates this. First advice to
open source projects is "release early, release often".

I had thought about using this for my projects, but I can see
the downsides too:

If some projects drop too early, they still barely have any
capabilities. The first curious potential users check it out and
walk away thinking, "a toy product and not the skills that actually
matter in practice". That vibe can stick around - "You don't get
a second shot at a first impression." - and end up keeping people
from giving the later, more capable versions a chance.

Projects that delay release because they are "not ready"
typically loose and eventually die.

Exagerated.

The actual TeX program version is currently at 3.141592653
and was last updated in 2021. It is one of the most successful
programs ever and the market leader for scientific articles
and books that include math formulas.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Wed, 8 Oct 2025 16:21:50 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

A principal advantage of the "open-source world" (or rather the non- commercial world) is that there's neither competition nor need to
quickly throw things into the market. So this area has at least the
chance to adapt plans and contents without time pressure.

Yes and no. There's definitely *less* pressure to make a specific
release window and a project won't necessarily die just because there's
no money in it - but large-scale open-source projects do compete for "mindshare" among open-source developers, who are a large but finite
group with a finite amount of time and energy to sink into them.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

"You don't get a second shot at a first impression."

And then there's the inertia. Once you publish something, you
also want to put out all the side stuff like manuals and tests.

But those, along with the users, just add more weight.

Every little tweak means updating the docs again, and the
users complain whenever something changes that they just got
used to. Without all that mass and pressure, you can move a
lot faster and try different things until it slowly becomes
clear what really works best.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

Andy Walker <anw@cuboid.co.uk> wrote:

On 04/10/2025 02:11, Waldek Hebisch wrote:

Andy Walker <anw@cuboid.co.uk> wrote:

On 20/08/2025 01:43, Lawrence DrCOOliveiro wrote:

[...]

If you were to run an old OS on new hardware, that would need drivers for >>>> that new hardware, too.

Yes, but what is so special about a modern disc drive, monitor,
keyboard, mouse, ... that it needs "the vast majority" of 40M lines more >>> than its equivalent for a PDP-11? Does this not again make Janis's point? >> Lawrence gave a good list of things, but let me note few additional

aspects. First there is _a lot_ of different drivers. In PDP-11
times there were short list of available devices. Now there is a lot
of different devices on the market and each one potentially need a
specialised driver in the kernel. [...]

Yes, but one would expect that to drive standardisation rather
than bloat. There are rather a lot of devices that I can plug into the
mains in my home, but I don't have to install hundreds or thousands of different types of socket.

Note that a lot of companies do not want to compete in commodity
market. They want to collect "extraordinary added value" by
innovating. But most innovation is either in drivers or need
driver support. So companies have motivation to limit use of
drivers to their devices. I other words they _want_ to be
incompatible with other devices. Of course, this is mitigated
by total developement cost. But there is a bunch of gratitious incompatibilites. There are independently developed products,
again developement is frequently secret and when devices enter
market they need separate drivers.

I think that comparisons with early mainframes or PDP-11 are
misleading in the sence that on early machines programmes struggled
to fit programs into avaliable memory. Common technique was keeping
data on disc and having multiple sequential passes. Program
itself could be split into several overlays. Use of overlays
essentially vanished with introduction of virtual memory coupled
with multimegabyte real RAM. More relevant are comparisons
with VAX and early Linux.

I would take issue with some of the historical aspects, but it
would take us on a long detour. Just one comment: we've had virtual
memory since 1959 [Atlas].

1) You enough real memory to make virtual memory really effective.
There are things that you really want to keep in real RAM.
2) Fact that some big or innovative machine allows to do thing
better is not enough. Programmers typically work with available
hardware, so hardware/software support must be popular enough
to matter for programmers practice.

AFAICS bloat happens mostly in user level. One reason is more
friendly attitude of modern programs: instead of numeric error
codes programs contains actual error messages.

The systems I've used have always used actual error messages!

Well, first trick to fit program into available memory that I have
seen was to eliminate textual messages, debugging support etc.
That was especially in case of small systems without hard drive
(so trick with storing messages on the disk was not possible).

I already mentioned overlays, but let me add that they frequently
were combined with multipass approach. Having less passes gives
better speed as long as you have enough memory.

Another trick used bytecode interpreters. Interpreter itself can
be quite small and well-chosen bytecode typically is much smaller
than machine code. But execution needs more CPU time. With
careful tuning and rewriting critical parts in machine code
one can get reasonable result, at cost of approproiate programmer
effort.

[...]

One reason that modern system are big and bloated is recursive
pulling of dependencies. Namely, there is tendency to delegate
work to libraries and more generally to depend on "standard"
tools. But this in turn creates pressure on libraries and
tools to cover "all" use cases and in particular to include
rarely used functionality.

Yes, but that's the sort of pressure that needs to be
resisted; and isn't,

Well, I am trying to limit dependencies for my software, which
may mean writing my own function for some purpose instead of
using a library. OTOH if shared library is loaded into RAM
by another user, than runtime cost of additional user is
rather low. And writing my function means extra source code.
So that is tricky balance.

Concerning rarely used functionality in libraries, alone I do
not think it is big problem. I mean, having such code in
library means that sharing at source code level is possible
so it is likely to lead to decrease in total amount of
source code needed to implement functionality of modern
systems.

And I am trying to see things in the context. People have
a lot of computing needs, some really important, some of
lower priority. Computing hardware is much cheaper than it
was in the past, so main barrier to satifying "all" computing
needs is cost of creating software. Especially for less
common needs it makes sense to use rather inefficient approaches
because doing things "properly" would require too much programming
effort. So, instead we try to maximize amount of functionalty
given avaliable programmer effort and available computing
resources. Which frequently mean that we are happy that
a program works at all and not bothered to much by bloat.

Let me add that personally I am probably much less tolerant
to bloat than average. But when I use open source software,
should I complian that it uses more resources than strictly
neccessary? I certainly can not create myself all that
software (or pay for its creation).

[...]

Hmm, on my machine '/usr/bin' contains 2547 commands. IIRC "minimal"
install give some hundreds of commands, so most commands is from
packages that I explicitely installed or their dependencies.

I have 2580 in my "/usr/bin". That is almost all from the
"medium (recommended)" installation; a handful of others have been
added when I've found something missing (I'd guess perhaps 10). Of
those I've actually used just 64! [Plus 26 in "$HOME/bin".] I
checked a random sample of those 2580; more than 2/3 I have no
idea from the name what they are for [yes, I know I can find out],
and I'm an experienced Unix user with much more CS knowledge than
the average punter. If I were to read an introductory book on
Linux, I doubt whether many more than those 64 would be mentioned,
so I wouldn't even be pointed at the "average" command.

I use debian 12. "Bigger" install options tend to pull in GUI
stuff that I do not want. I use LXDE and prefer to avoid KDE
or Gnome. Of course there are Gnome/KDE programs that I use
and that pull corresponding shared libraries, but AFAICS I get
less Gnome and KDE programs that I would get choosing it as a
desktop environment. On other machines I did minimal (non-GUI)
install and it was much smaller. On a small machine I did GUI
install, but installed only limited number of packages. On
that machine I have 1274 programs in /usr/bin. So majority
of programs on my main machine goes beyond "small" GUI install.

Note: I do not remember if I did minimal install first and
then added GOI or choos GUI option during initial install.
The point is that this is GUI that I actually use, most commands
is invoked from menus but I start some GUI things from command
line.

64 commands that you actually used looks very low. I am too lazy
to count commands that I use. But I have cross-developement
toolchains for AVR (27 commands), ARM (28 commands), RISC-V
(25 commands). I have both normal x86_64 toolchain and
support to x32 variant (28 commands). x86_64 toolchain installs
things under duplicate name, 74 commands have prefix
'x86_64-linux-gnu-' and each probably have unprefixed version.
So only counting part of development commands that I use
I have about 256 commands that I am reasonably likely to use
(some commands come under multiple names, normally I would
use only one name, but I may use other names say for ease of forming
names in build scripts). Note that by default Debian installs
essentially no developement support (Debian install 'cpp' for
use by some other programs), so those are present because I
need them.

Also, note that stuff that used to be in '/bin' is now in
'/usr/bin'. That is tens of simple command that any serious
Unix user is likely to use.

Of course, if you take an "average user", then such person may
be unaware of existence of command line so number of commands
that such person explicitely uses would be 0. Even some
developers apparently depend on GUI tools and are lost when
they need say to write a Makefile. But a lot of behind the
scene machinery (and some commands) exists to allow such user
productively use computers.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Wed, 8 Oct 2025 08:08:22 -0700, John Ames wrote:

... large-scale open-source projects do compete for
"mindshare" among open-source developers, who are a large but finite
group with a finite amount of time and energy to sink into them.

The rCLmindsharerCY is among the passive users who take whatrCOs given and complain about how it doesnrCOt fit their needs.

WhatrCOs more important is the rCLcontribusharerCY -- the active community that
contributes to the project. That matters much more than sheer numbers of users.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Wed, 8 Oct 2025 21:18:58 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

... large-scale open-source projects do compete for
"mindshare" among open-source developers, who are a large but finite
group with a finite amount of time and energy to sink into them.

The rCLmindsharerCY is among the passive users who take whatrCOs given and complain about how it doesnrCOt fit their needs.

WhatrCOs more important is the rCLcontribusharerCY -- the active community that contributes to the project. That matters much more than sheer
numbers of users.

If that's the terminology you prefer, sure. The point stands.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Wed, 8 Oct 2025 14:31:31 -0700, John Ames wrote:

On Wed, 8 Oct 2025 21:18:58 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

... large-scale open-source projects do compete for "mindshare" among
open-source developers, who are a large but finite group with a
finite amount of time and energy to sink into them.

The rCLmindsharerCY is among the passive users who take whatrCOs given and >> complain about how it doesnrCOt fit their needs.

WhatrCOs more important is the rCLcontribusharerCY -- the active community >> that contributes to the project. That matters much more than sheer
numbers of users.

If that's the terminology you prefer, sure. The point stands.

You were talking about thinking, not doing. ItrCOs the doing that counts.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 08.10.2025 16:03, Waldek Hebisch wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:

Not to mention that taking too long to 'polish' your product, you
risk ending up lagging behind your competitors.

I would say, the open-source world is a counterexample to this. Look at >>> how long it took GNU and Linux to end up dominating the entire computing >>> landscape -- it didnrCOt happen overnight.

Actually, open source nicely illustates this. First advice to
open source projects is "release early, release often". Projects
that delay release because they are "not ready" typically loose
and eventually die.

Open source projects typically want to offer high quality. But
they have to limit their efforts to meet realease schedules.
There are compromises which know bugs get fixed: some are deemed
serious enough to block new release, but a lot get shipped.
There is internal testing, but significant part of problems
get discovered only after release.

One can significantly increase quality by limiting addition of
new featurs. But open source projects that try to do this
typically loose.

We can observe that software grows, and grows rank. My experience
is that it makes sense to plan and occasionally add refactoring
cycles in these cases. (There's also software planned accurately
from the beginning, software that changes less, and is only used
for its fixed designed purpose. But we're not speaking about that
here.) A principal advantage of the "open-source world" (or rather
the non-commercial world) is that there's neither competition nor
need to quickly throw things into the market. So this area has at
least the chance to adapt plans and contents without time pressure.

What you wrote corresponds to one-man hobby project. There is a lot
of such projects. But more important is software from multiperson
project. And by now a lot of open source is developed by paid
developers in commerial setting. Note that GPL requires that
distributor makes code available to recipents of binaries.
So comercial entity improving GPL-ed program has to open-source
the improvements. Given that they can not keep improvements
secret there is incentive to conribute them back to original
project: if improvements are integrated maintanence on contributor
side gets easier. But this calculation breaks down if original
source keeps intermediate code secret and rarely is doing
releases. Even if developement tree is public and contributions
are promptly integrated rare releases means that users wanting
improvement must use potentially unstable developement versions.

Sometimes comercial entities want to ship some product which
makes use of some system tool installed on user system. They
may need improvement to this tool and for them things get
easier if improved tool quickly enters distribution.

Coming back to hobby case, one reason people contribute is
because thay want some extra feature, they develop it and
wnat it included.

All 3 cases above have common factor: contributor really want
feature included in the program. If maintainer/lead developer
rejects the code or introduces large delay, then potential
contributors are discouraged, so project may loose developers
(or at least fail to gain new ones).

There is also question of popularity among users. While by
definition "ordirnary users" do not contribute code, they
report bugs, ask for enhancemts, sometimes help with documentation,
project website or simply spead positive opinion about project.
This is important too: without good documentaion potential
users may consider program to be buggy, without user contributed
bug reports discovering (and hence fixing) bugs may be hard,
without user feedback developers may concentrate on wrong features.

And of course, to join a project developers must first realize
that the project exists and get interested in it.

Whether it's done is another question (and project specific). It
should also be mentioned that some projects have e.g. security or
quality requirements that gets tested and measured and require some
adaptive process to increase these factors (without adding anything
new).

Actually, security is another thing which puts pressure to
release quickly: if there is security problem developers want
to distribute fixed version as soon as possible.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

Stefan Ram <ram@zedat.fu-berlin.de> wrote:

antispam@fricas.org (Waldek Hebisch) wrote or quoted:

Actually, open source nicely illustates this. First advice to
open source projects is "release early, release often".

I had thought about using this for my projects, but I can see
the downsides too:

If some projects drop too early, they still barely have any
capabilities. The first curious potential users check it out and
walk away thinking, "a toy product and not the skills that actually
matter in practice". That vibe can stick around - "You don't get
a second shot at a first impression." - and end up keeping people
from giving the later, more capable versions a chance.

You need to manage expectations. Yours and your users. You may
think that you have some cool thing, but even if it is working
well in your opinion first potential user to come may trash it
and discourage others. Or you may hit into something that a lot
of people want, but is not handled by existing software. Then
even if buggy/imperfect program may easily gain a lot of users.

If you decide to distribute some early not entirely finished version
it makes sense to explicitely say alpha/beta/for developers only
as appropriate.

Unless your program is close to trivial and you spent a lot of
effort to make it correct expect that if you get users they
will discover bugs.

A lot depends how you view your project. If it is something
that you want to "give" to users and expect good words in
return, you may be disappointed. AFAICS potential benefits
of distributing code are:
- you get bug reports or enhancement ideas allowing you to
improve the program
- you get contributions, so part of work is done by others

OTOH:
- contributors may want to take project in quite different
direction that you want
- you may get spurious bug reports, where program works as
designed, but user expected soemting else
- you may get harsh critique

If you feel that what you have is too immature, then it makes
sense to keep it private. Similarly, you want things
designed/impemented in specific way it is best to do it
in private.

But IMO in most cases releasing early makes sense.

Projects that delay release because they are "not ready"
typically loose and eventually die.

Exagerated.

The actual TeX program version is currently at 3.141592653
and was last updated in 2021. It is one of the most successful
programs ever and the market leader for scientific articles
and books that include math formulas.

I am well aware of TeX and I would interpret things in rather
different way. First, main selling point of TeX proper is
backwards compatibility, that is rendering old papers now
in the same way as when they were written and hopefully current
paper in the future will be rendered the same as now. While
compatibility in general is good, in case of scientific articles
it is especially important.

Second, despite first point there is continuing dissatisfaction
that TeX proper misses various features. Some things get
added but are not reflected in official version number, there are
mutated versions and attempts to created rather different
thing (like Lyx and Texmacs). There was a faild attempt
(or possibly multiple attempts) at developing compatible
replacement.

Third, TeX is a macro processor and a lot of formatting functionality
in use is implemented via TeX macros and not in TeX proper.
There is rather fast stream of changes to available macro
packages and a lot of bloat there. TeX proper is about 24kloc
of source code after macro expansion. Modern binaries contain
similar (or somewhat larger) amout of "system support", which
orignally was intended to be rather small wrapper around needed
OS functions but now adds extra functionalty (not reflected in
main version number). If you install supporting macro packages
and extra tools like Debian 'texlive-full' package they will use
about 9 GB.

So TeX is very special case: there is strong compatibility
requirement and there is a lot of changes outside core part
written by Knuth.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09.10.2025 02:34, Waldek Hebisch wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

We can observe that software grows, and grows rank. My experience
is that it makes sense to plan and occasionally add refactoring
cycles in these cases. (There's also software planned accurately
from the beginning, software that changes less, and is only used
for its fixed designed purpose. But we're not speaking about that
here.) A principal advantage of the "open-source world" (or rather
the non-commercial world) is that there's neither competition nor
need to quickly throw things into the market. So this area has at
least the chance to adapt plans and contents without time pressure.

What you wrote corresponds to one-man hobby project. [...]

No. (I wasn't speaking about "one-man hobby projects"; rather more
the "opposite" project setup.)

[...] But more important is software from multiperson project. [...]

Yes.

[ open source and GPL stuff ]

I wasn't specifically speaking about that.

[ specific sceneries and assumptions ]

[ more open source specific sceneries and assumptions ]

[ open source example sceneries and assumptions about involved people ]

(I wasn't focusing on these things you expanded on. - And I won't
comment on that.)

Whether it's done is another question (and project specific). It
should also be mentioned that some projects have e.g. security or
quality requirements that gets tested and measured and require some
adaptive process to increase these factors (without adding anything
new).

Actually, security is another thing which puts pressure to
release quickly: if there is security problem developers want
to distribute fixed version as soon as possible.

Yes, but I wasn't speaking about fixing security holes [quickly].

I was speaking about planning a software in a development process
with requirements including security and principles to guarantee
quality. That doesn't prevent measures to continuously get back
in feedback loops to enhance the structure, plan growth, redesign
and refactor necessary parts, especially when new features are
planned to be added.

And I was speaking about software that obviously doesn't adhere
to such principles, and grow rank.

The point with open source software (where you seem to have a bias
for) is a special set of beasts. But as said; they'd have a chance
(but typically and often don't use it, it seems).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09.10.2025 03:39, Waldek Hebisch wrote:

[...]

But IMO in most cases releasing early makes sense.

LOL, yeah! - Let the users and customers search the bugs for you!

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 09.10.2025 03:39, Waldek Hebisch wrote:

[...]

But IMO in most cases releasing early makes sense.

LOL, yeah! - Let the users and customers search the bugs for you!

Maybe you think that you can write perfect software. There are
widely available statistics which show that software of nontrivial
size have bugs. Developer may plan things (FYI I spent a lot
of time on planning befor I start coding), test things but after
some time arrives at point of diminishing returns: finding new
bugs takes a lot of effort. If you have paying customers you should
have money a hire testers. You should hire multiple developers
and do code reviews. But within reasonable resource bounds and
using known tecniques you will arrive at point where finding new
bugs takes too much resources.

If your customers need/demand higher quality they should pay
appropriatly to cover needed cost. But expecting no bugs is
simply unrealistic. I read about developement of software
controlling Space Shuttle. Team doing that boasted that
that have sophisticated developement process ensuring high
quality. They had 400 people working on 400 kloc program.
Given that developement was spread over more than 10 years
that looks as very low "productivity", that pretty high
developement cost. Yet they where not able to say "no bugs".
IIRC they where not even able to say "no bugs discovered
during actual mission", all that they were able to say
was "no serious trouble due to bugs". Potential effects
of failure of Space Shuttle software were pretty serious,
so it was fully justified to spent substantial effort on
quality.

What I develop is quite non-critical, I am almost certain
that "no serious trouble due to bugs" will be true even if
my software is full of bugs. And similar thing applies to
substantial part of open source software. I wrote above
about hiring testers. Non commercial open source projects
typically do not have money to pay for testing. But
there are people who are willing to do testing for free.
More precisely, given not critical nature of software
bugs are just inconvenience and frequently there are
folks who consider inconvenience due to bugs as small
compared to benefits offered by software.

When I wrote about releasing early, I mean releasing when
stream of new bugs goes down, that is attempting to predict
point of diminishing returns. More conservative approach
would continue testing for longer time in hope of finding
"last bug". Some people may use formulation like "do
all what it possible to increase quality and after that
release", but there is always something more that could
be done. So one need to decide when it is enough and release.

I have a problem (and tone of your message suggest that you
may have this problem too), I really would prefer to catch as many
bugs as possible during developement and due to this I
probably release to late. Note that part of my testing may
be using a program just to do some work. Now, if program
is doing valuable service to me, there is reasoble chance
that it will do valuable work for some other people.
Pragmatically you can view this a a deal: other people
get value from work done by the program, I in exchange get
defect reports that allow me to improve the program.
I see nothing wrong in such a deal, as long as it is
honest, in particular when provider of the program
realistically states what program can do.

BTW: Some users judge quality of software looking at number of
bugs reports. More bugs reports is supposed to mean higher
quality. If that looks wrong to you more detailed reasoning
goes as follows: number of bug reports grows with number of
users. If there is small number of bug reports it indicates
that there is small number of user and possibly that users
do not bother reporting bugs. Now, user do not report bugs
when they consider software to be hoplessy bad. And user
in general prefer higher quality software, so small number
of user suggest low quality. So, either way, low number
of bug reports really may mean low quality. This method
may fail if you manage to create perfect software free of
bugs with perfect documentation so that there will be no
spurious bug reports. But in real life program tend to have
enough bugs that this method has at least some merit.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

antispam@fricas.org (Waldek Hebisch) wrote or quoted:

If your customers need/demand higher quality they should pay
appropriatly to cover needed cost. But expecting no bugs is
simply unrealistic. I read about developement of software
controlling Space Shuttle. Team doing that boasted that
that have sophisticated developement process ensuring high
quality. They had 400 people working on 400 kloc program.
Given that developement was spread over more than 10 years
that looks as very low "productivity", that pretty high
developement cost. Yet they where not able to say "no bugs".
IIRC they where not even able to say "no bugs discovered
during actual mission", all that they were able to say
was "no serious trouble due to bugs". Potential effects
of failure of Space Shuttle software were pretty serious,
so it was fully justified to spent substantial effort on
quality.

Recommended reading:

"They Write the Right Stuff" (1996-12) - Charles Fishman.

Was on the web for a very long time, but I think
they now have some kind of wall before it, but it
might still be in some archives.

The gist is:

- About half the people, even in leading positions,
are women.

- They work from 9 to 5, no "sprint" long nights,
maybe rare exceptions from this rule.

- About half the staff are testers, but as the programmers
do not want them to find errors, the programmers already
do their own testing before they give their code to the
actual testers. So more time is spend on testing than on
coding.

- The quality measure is a statistical estimate of the
number of bugs remaining per line of code which has to
be below a certain value

One discipline that is set up to write software free from errors is
/cleanroom software engineering/ (not to be confused with /cleanroom
engineering/ of software for avoiding problems with copyright).

I have a problem (and tone of your message suggest that you
may have this problem too), I really would prefer to catch as many
bugs as possible during developement and due to this I
probably release to late.

I am only writing software in my leisure I want to use myself.
I should release it after it has proven to be usable and helpful
to myself. But sometimes I feel inpatient and tempted to release
something for the satisfaction of having released something, even
when it's not useful, like the frontend of a compiler without a
backend. I need to put effort into some self-control not to do this.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Thu, 9 Oct 2025 00:09:50 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

If that's the terminology you prefer, sure. The point stands.

You were talking about thinking, not doing. ItrCOs the doing that
counts.

I was talking about the doing; you just want to use a different word
for it. That's all fine, but it doesn't change what I was saying.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Thu, 9 Oct 2025 08:44:31 -0700, John Ames wrote:

On Thu, 9 Oct 2025 00:09:50 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

If that's the terminology you prefer, sure. The point stands.

You were talking about thinking, not doing. ItrCOs the doing that counts.

I was talking about the doing ...

You used the word rCLmindsharerCY. Trying to redefine what rCLmindrCY means, now?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Thu, 9 Oct 2025 21:52:08 -0000 (UTC)
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

If that's the terminology you prefer, sure. The point stands.

You were talking about thinking, not doing. ItrCOs the doing that
counts.

I was talking about the doing ...

You used the word rCLmindsharerCY. Trying to redefine what rCLmindrCY means, now?

No, just using it in the context of developer minds.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 07/10/2025 23:04, Lawrence DrCOOliveiro wrote:

On Tue, 7 Oct 2025 22:03:07 +0100, Andy Walker wrote:

On 04/10/2025 02:11, Waldek Hebisch wrote:

In PDP-11 times there were short list of available devices. Now
there is a lot of different devices on the market and each one
potentially need a specialised driver in the kernel. [...]

Yes, but one would expect that to drive standardisation rather than
bloat. There are rather a lot of devices that I can plug into the
mains in my home, but I don't have to install hundreds or thousands
of different types of socket.

Most of your electronic devices would not plug directly into the
mains, they would likely use some kind of DC adaptor/charger. How many
of those do you have?

Actually, most of mine /do/ plug directly into the mains. Or
do you not count computers, TVs, printers, [music] keyboards, ... as electronic? Yes, I also have some that come with some kind of charger
or connector. They are surprisingly diverse: shavers, toothbrushes,
various ornaments, ... as well as 'phones, portable drives, USB sticks
kindles, .... A feature is that all those mentioned work via a USB
connexion [supplied with the device], irrespective of whether the Man
on the Clapham Omnibus would describe them as "electronic". Is that
not standardisation in action? [Of course there are many other formal
or informal standards, such as MIDI, UTF-8, MPEG, ... to choose from.]

You are trying to make an argument by analogy, and that is already
heading for a pitfall. Those power connections you talk about are for transferring energy, not for transferring information. Information
transfer is a much more complex business.

USB sticks, portable drives, ... transfer information as well.
But again, if information transfer is so complex, one would expect that
to drive standardisation rather than everyone re-inventing the wheel.
I note nearby articles giving reasons for the diversity, but commercial interests of companies don't coincide with the interests of users.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Simpson
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On Fri, 10 Oct 2025 01:11:56 +0100, Andy Walker wrote:

A feature is that all those mentioned work via a USB
connexion [supplied with the device], irrespective of whether the Man
on the Clapham Omnibus would describe them as "electronic". Is that
not standardisation in action?

Do you know how many different kinds of rCLUSBrCY there are?

USB sticks, portable drives, ... transfer information as well.
But again, if information transfer is so complex, one would expect that
to drive standardisation rather than everyone re-inventing the wheel.

Besides the different versions of USB previously alluded to, let me also mention BlueTooth, BlueTooth LE, HDMI, DisplayPort, ZigBee, all the
different flavours of Ethernet, with and without PoE, Wi-Fi, DECT (if you happen to have a cordless landline phone), 3G, 4G, 5G ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09.10.2025 16:19, Waldek Hebisch wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 09.10.2025 03:39, Waldek Hebisch wrote:

[...]

But IMO in most cases releasing early makes sense.

LOL, yeah! - Let the users and customers search the bugs for you!

Maybe you think that you can write perfect software.

No. (What makes you think that I would think that one could be
sure to write [non-trivial] software error-free and perfect?)

But there are methods to write more reliably reliable software!

Also, that software has more or less bugs doesn't justify, IMO,
"early releases" as principle, and especially not as principle
to obtain software quality; this was the inherent point of the
statements in previous posts.

[...] But within reasonable resource bounds and
using known tecniques you will arrive at point where finding new
bugs takes too much resources.

And this is also no rationale for "early releases".

If your customers need/demand higher quality they should pay
appropriatly to cover needed cost. But expecting no bugs is
simply unrealistic.

This is again the same straw-man; no one said or implied such
a thing.

I read about developement of software
controlling Space Shuttle. Team doing that boasted that
that have sophisticated developement process ensuring high
quality. They had 400 people working on 400 kloc program.
Given that developement was spread over more than 10 years
that looks as very low "productivity", that pretty high
developement cost. Yet they where not able to say "no bugs".
IIRC they where not even able to say "no bugs discovered
during actual mission", all that they were able to say
was "no serious trouble due to bugs". Potential effects
of failure of Space Shuttle software were pretty serious,
so it was fully justified to spent substantial effort on
quality.

And sometimes it doesn't help if the methods aren't applied
consequently! (Since you mentioned a space technology example
you may want to read about the Ariane 5 incident; the
post-mortem report is very enlightening concerning errors in
demanding software projects that are basically extremely good
organized!)

What I develop is quite non-critical, I am almost certain
that "no serious trouble due to bugs" will be true even if
my software is full of bugs. [...]

I've no insight in your projects and methods. (That's not my
business.)

From the professional projects I participated in in the past
we could not risk having lots of bugs or severe bugs. So we
either had or installed the necessary methods and provisions
to achieve the high quality we needed; and that worked well.

So probably you have other projects in mind; but even then,
the costs for fixes of problems appearing later are much
higher than detecting them early in the development process.
(In your area maybe "only" loss of reputation, not money, or
lives.)

When I wrote about releasing early, I mean releasing when
stream of new bugs goes down, that is attempting to predict
point of diminishing returns.

The problem with that is that bugs - assuming we speak about
those reported; mind your "early release" approach! - appear
too late to be fixed cheaply. (And predictions need numbers
and project context information! And experience.)

More conservative approach
would continue testing for longer time in hope of finding
"last bug". [...]

That is not a "conservative approach" but nonsense, and I've
never heard such procedure to be established in professional
contexts; unless you could apply a formal verifier you cannot
say when there's no bugs any more.

No. Conservative, or standard approach, is to apply all the
methods of software development, from formal specification,
tools testing specifications, designs, tests on the various
levels, supporting tools, experts on the respective QA and
project management tasks, and of course trained programmers.

I have a problem (and tone of your message suggest that you
may have this problem too), I really would prefer to catch as many
bugs as possible during developement and due to this I
probably release to late. [...]

Yes, I try to reduce the cases where bugs may slip in. For my
personal toy-projects that's not critical, but if I want to
(sort of) "publish" anything I spend yet more effort. For the
professional projects I was engaged in it was non-negotiable,
though; the quality measures were a must!

Note that part of my testing may
be using a program just to do some work. Now, if program
is doing valuable service to me, there is reasoble chance
that it will do valuable work for some other people.
Pragmatically you can view this a a deal: other people
get value from work done by the program, I in exchange get
defect reports that allow me to improve the program.
I see nothing wrong in such a deal, as long as it is
honest, in particular when provider of the program
realistically states what program can do.

Personally I don't want to publish in a quality that results
in a lot of feedback that requires a lot of time to handle.
And it's not only about coding-bugs but also about software
design. (My rants often have a strong focus on "lousy design"
and on bugs only as a secondary factor; my experience tells
me also that lousy designs are also a significant source of
implemented bugs.)

BTW: Some users judge quality of software looking at number of
bugs reports. More bugs reports is supposed to mean higher
quality.

More bug reports primarily suggests that the software is of
inferior quality (presuming all other factors for comparison
are equal or appropriately normalized).

If that looks wrong to you more detailed reasoning
goes as follows: number of bug reports grows with number of
users.

This is not necessarily the case.

If there is small number of bug reports it indicates
that there is small number of user and possibly that users
do not bother reporting bugs.

This is not a given consequence.

Now, user do not report bugs
when they consider software to be hoplessy bad. And user
in general prefer higher quality software, so small number
of user suggest low quality. So, either way, low number
of bug reports really may mean low quality. This method
may fail if you manage to create perfect software free of
bugs with perfect documentation so that there will be no
spurious bug reports. But in real life program tend to have
enough bugs that this method has at least some merit.

It is always sensible going for high quality early in the
development process to create less bugs and less bug reports.
Frankly, to say that a lot of bug reports (thus bugs) is good
or useful in any way is completely erroneous. You can draw
quality conclusions also from no or "too few" bugs and focus
on these.

Mind also that fixing bugs often is also "patching" software;
with many bug reports you have to do a lot of changes, in a
way defined by the time scale as they arrive, not by design.
In well-designed and well-written software that may be a
less critical factor, but to achieve that quality state in
the first place you'd have to install some quality measures.

Lots of bugs and bug-reports is nothing you sensibly want to
achieve to obtain software quality.

Though you should track all numbers you can get from your
development process to be able to draw conclusions and act.

Anecdotally, to give an impression of contexts I worked in...

We had a client server component architecture, each component
with one dedicated person responsible for it. We measured the
errors from tests on various levels (unit, system, integration,
acceptance tests). We also measured check-ins, and number of
changes of the requirements (for example). I installed the QA
measures I found to be necessary, and we had the best outcome;
best outcome means quasi-zero bugs!

In another context I took responsibility for a refactoring of
governmental software, software that evolved over years before
I joined. Here the refactoring not only reduced LOCs but also
restructured the code. The number of bugs reduced linearly with
the reduction of code, and yet more with the better structure.
(But of course that needed the QA infrastructure and processes
we had invented, it's not a given.)

PS: You wrote quite some hypotheses about open source and the
user community there; I'm positive that the principles we got
from the commercial professional software development are also
valid for the area you were focusing on. But YMMV, of course.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 09.10.2025 16:48, Stefan Ram wrote:

Recommended reading:

"They Write the Right Stuff" (1996-12) - Charles Fishman.
[...]
The gist is:
[...]
- About half the staff are testers, but as the programmers
do not want them to find errors, the programmers already
do their own testing before they give their code to the
actual testers. So more time is spend on testing than on
coding.

(It's dangerous to reply on a quoted text. Anyway. A few comments...)

I cannot tell where that is from, what project context, company, etc.
Just hoping that "the programmers" is not meant as generalization but
that it's meant just for the context/company he writes about.

The author write as if there's just one sort of testing, and this done
by ominous "testers". We had (in the various companies) indeed testers
but they were doing component tests, system tests, integration tests,
another group did the acceptance tests, and the programmers/developers
did unit tests and component tests. Each type of tests has its reason
and is important. All added to high quality software.

The quoted last sentence seems to suggest - but I may misinterpret -
that it's bad to spend a sensible time on "testing". In a way it gives
the impression that many LOCs are the "productive" and more important
part of the job, and sadly I got to know stupid managers that believed
such nonsense.

Janis

PS: Whenever QA effort gets reduced it gets expensive, money and lives.
When was it that Boing reduced QA staff and subsequently a couple 737s
crashed? (You can find similar stories from other companies.)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.misc

On 10/10/2025 02:39, Lawrence DrCOOliveiro wrote:
[I wrote:]

A feature is that all those mentioned work via a USB
connexion [supplied with the device], irrespective of whether the Man
on the Clapham Omnibus would describe them as "electronic". Is that
not standardisation in action?

Do you know how many different kinds of rCLUSBrCY there are?

Is this an exam? I have a decent-enough idea, inc the various ways
in which the versions are compatible with each other. Standardisation is
not the same as "everything stays the same for 30 years despite the huge changes in what domestic devices can do". More to do with things "just working" without someone having to write 40 million lines of code in case
I happen to install some obscure peripheral on my computer.

[...]>> But again, if information transfer is so complex, one would expect that >> to drive standardisation rather than everyone re-inventing the wheel.

Besides the different versions of USB previously alluded to, let me also mention BlueTooth, [...], 4G, 5G ...

So which is it? Are devices becoming standardised or are people insisting on re-inventing the wheel? Is this what consumers want or is
it large companies trying to lock them in to their products? Cui bono?
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Lehar
--- Synchronet 3.21a-Linux NewsLink 1.2