From: Martin Gregorie on
On Sat, 13 Feb 2010 13:07:28 -0500, LR wrote:

> Do you happen to know if they've undergone any engineering changes over
> those 40 years for safety or performance enhancements?
>
Some have gone on a *lot* longer: the youngest engine on the Darjeeling
Railway was built in 1925 and I remember seeing a brass plate on one
saying that it was built in Glasgow in 1904. More recently, one was
converted from coal to oil and fitted with a diesel generator to run the
new electric water feed system and a diesel compressor for braking.
Details are here:
http://en.wikipedia.org/wiki/Darjeeling_Himalayan_Railway


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
From: LR on
Seebs wrote:
> On 2010-02-13, Leif Roar Moldskred <leifm(a)huldreheim.homelinux.org> wrote:
>> Why? We're not today, and the gears of the open source engine appears fairly
>> well greased regardless.
>
> In practice we are -- you can give stuff away labeled "WITHOUT ANY WARRANTY"
> and no one seems to feel this is a problem.
>
> The proposal that we should legislate that software CANNOT be distributed
> without warranty would be destructive.

There are also IMO free speech issues.

Can a teacher publish code in, eg a text book, without incurring
liability?

(The tangentially related (IMO free speech) issue of who may teach is
also important, although I think some states may claim the right to
limit the teaching of engineering to PEs, in Sweezy v. New Hampshire,
354 U.S. 234 (1957) in his concurring opionion Justice Frankfurter
quoted: `the four essential freedoms' of a university - to determine for
itself on academic grounds who may teach, what may be taught, how it
shall be taught, and who may be admitted to study."
http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=354&invol=234)

If code may result in liability what about tools like c2eng that I think
resulted from litigation related to DeCSS.
http://www.mit.edu/~ocschwar/c2eng.html Is the English form protected
speech? Subject to liability? I haven't read through the whole thing
but this looks interesting
http://www.cs.cmu.edu/~dst/DeCSS/Baccash/thesis.pdf

LR

From: Seebs on
On 2010-02-14, James Kanze <james.kanze(a)gmail.com> wrote:
> Really. I've not seen any free software which adopted all of
> the best practices.

Bespoke software may. But go to a store that sells discs in boxes,
and tell me with a straight face that any of those boxes contain software
developed through a development operation which adpoted all of the best
practices.

> In my experience, some of the best
> practices require physical presense, with all of the developers
> having offices in the same building. (The experiments I've seen
> replacing this with email and chat haven't turned out all that
> well.) This is far more difficult for a free project to achieve
> than for a commercial one.

True. That said, I've been on distributed teams pretty much exclusively
for the last couple of decades, and I think they certainly *can* work. It
depends a lot on building a culture that's suited to it, and probably also
on having a few aspies involved. (It is nearly always the case that I
am less efficient in face-to-face meetings than I am in pure-text chat.)

> First, free software doesn't have the highest quality. When
> quality is really, really important (in critical systems), you
> won't see any free software.

I'm not totally sure of this. Not *much* free software, probably.
It'd be interesting to see, though. Last I heard, there's no open
source pacemakers, but there are pacemaker programmers which are
built on open source platforms, because that's enough less critical.
(This is third-hand, so no citations.)

> ClearCase uses a different model than any of the other version
> management tools I've used. In particular, the model is
> designed for large projects in a well run shop---if your
> organization isn't up to par, or if your projects are basically
> small (just a couple of people, say up to five), ClearCase is
> overkill, and probably not appropriate. If you're managing a
> project with five or six teams of four or five people each, each
> one working on different (but dependent) parts of the project,
> and you're managing things correctly, the ClearCase model beats
> the others hands down.

Hmm. I'm not familiar with its model, but we've used git in that
environment and loved it. That said, we can't see the model for
the interface, which is pretty weak.

> Did you actually try using any free software back in the early
> 1990's?

I did.

NetBSD was for the most part reliable and bulletproof during that time;
it ran rings around several commercial Unixes. I had no interest in g++;
so far as I could tell, at that time, "a C++ compiler" was intrinsically
unusable. But gcc was stable enough to build systems that worked reliably,
and the BSD kernel and userspace were pretty livable.

> Neither Linux nor g++ were even usable, and emacs (by
> far the highest quality free software), it was touch and go, and
> depended on the version. Back then, the free software community
> was very much a lot of hackers, doing whatever they felt like,
> with no control. Whereas all of the successful free software
> projects today have some sort of central management, ensuring
> certain minimum standards.

I have no idea what you're talking about. I cannot point to any point
in the history of my exposure to free software (which predates the 1990s)
at which any major project had no central management. Linux was pretty
flaky early on, but then, in the early 1990s, all it had to do was be
more stable than Windows 3.1, which was not a high bar to reach for.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on
On 2010-02-14, James Kanze <james.kanze(a)gmail.com> wrote:
> On Feb 13, 4:27 pm, Seebs <usenet-nos...(a)seebs.net> wrote:
>> It's also often written by particularly good developers, who
>> care about their code.

> That I don't believe. I've seen a lot of particularly good
> developers in industry as well. People who care about their
> code---in fact, one of the most important things in creating a
> good process is to get people to care about their code.

I don't see how that argues against free software being written, in
some or many cases, by "particularly good developers, who care about
their code."

> In a well run development process, such feedback is guaranteed,
> not just "expected". That's what code reviews are for.

True. But of commercial places I've worked, only a few have been anywhere
near as active in code reviews as the free software projects I've worked with.
I have not yet seen a free software project which wouldn't reject code purely
on the basis that it had poor style or didn't match coding standards. I have
seen several commercial projects which didn't. So while good commercial
places may be that good, I've seen nothing to suggest that free software
places aren't usually that good.

> I'm far from sure about the "often", and I have serious doubts
> about "hundreds"---you don't want hundreds of cooks spoiling the
> broth---but that's more or less the case for the best run
> freeware projects. Which is no different from the best run
> commercial organizations, with the difference that the
> commercial organization has more power to enforce the rules it
> sets.

And more incentive to cheat around the edges. This is the essential
flaw of corporations.

> ClearCase is by far the best version management system for
> large, well run projects. It's a bit overkill for smaller
> things, and it causes no end of problems if the project isn't
> correctly managed (but what doesn't), but for any project over
> about five or six people, I'd rather use ClearCase than anything
> else.

Fascinating. Again, not what I've heard -- but to be fair, I've had
no call to use it.

> That is, of course, a weakness of free software.

I don't think it's a weakness in free software; I think it's a weakness in
a liability model. The ability to modify code when it doesn't quite suit
is a huge advantage. If we were dependent on reporting bugs to vendors and
waiting for their fixes for everything we use, it would be a disaster.
We put up with it, for one hunk of code, because the cost of maintaining local
expertise would be prohibitive. Apart from that, no.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Lew on
James Kanze wrote:
>> Did you actually try using any free software back in the early
>> 1990's [sic]?

Seebs wrote:
> I did.

Same here.

> NetBSD was for the most part reliable and bulletproof during that time;
> it ran rings around several commercial Unixes. I had no interest in g++;
> so far as I could tell, at that time, "a C++ compiler" was intrinsically
> unusable. But gcc was stable enough to build systems that worked reliably,
> and the BSD kernel and userspace were pretty livable.

James Kanze wrote:
>> Neither Linux nor g++ were even usable, and emacs (by

That's pure fantasy.

I used a couple of Linux distributions in the early nineties, and they worked
better than commercial UNIX variants.

I used emacs and knew many who used vi back then. They were solid.

I used gcc by the mid-90s and it was rock solid, too.

I used free software even as far back as the late 80s that worked beautifully.

The facts to back up your assertions are not in evidence.

>> far the highest quality free software), it was touch and go, and
>> depended on the version. Back then, the free software community
>> was very much a lot of hackers, doing whatever they felt like,
>> with no control. Whereas all of the successful free software
>> projects today have some sort of central management, ensuring
>> certain minimum standards.

Seebs wrote:
> I have no idea what you're talking about. I cannot point to any point
> in the history of my exposure to free software (which predates the 1990s)
> at which any major project had no central management. Linux was pretty
> flaky early on, but then, in the early 1990s, all it had to do was be
> more stable than Windows 3.1, which was not a high bar to reach for.

--
Lew