what are the most popular building and packaging tools for python ??

[Alex Martelli]

kosh <kosh at aesaeion.com> wrote:

> On Monday 25 October 2004 5:44 pm, Bengt Richter wrote:
> 
> > It's an interesting problem. Personally, I like open source, but I think
> > secret stuff should be possible, and I think it will be one of these
> 
> I have to admit I hope it is not ever really possible.

But it _IS_, just keep it on your own host.  Bengt's suggestion is
technically interesting, but with networking becoming more and more
pervasive "real secrecy", now "really possible" for applications that
cover maybe 80% of the software market (though with some limitations,
e.g. you're selling an app that can't fully run on a laptop on a flying
plane), will become possible for a wider and wider range and with fewer
and fewer limitations (e.g., wifi on planes is gonna be a standard
feature soon, and as it costs so little for airlines to provide it I
predict it will spread pretty fast).


> I certainly hope that does not happen and will continue to advise customers
> not to touch things that even try to do stuff like that. I have seen too many
> people burned badly when some proprietary app they had which required some
> special key server just stopped working. The company would go out of 
> business, decide that they did not want people to use the old version any
> more etc etc. Either way the ammount of lockin with a system like that is

This is certainly a very valid business consideration.  Without (at
least) source in escrow, or the like, betting your business on ANY
closed-source app may be very unwise.

Nevertheless, people and businesses use (e.g.) google daily, and depend
on it -- they don't have google's sources, and if they did they'd be
little use since the real value in this case is in the huge database
they're acessing.  Why should any other webservice be different?


> staggering. Even if the software did not cost any money the price is far too
> high for what you lose. However the software tends to be very expensive which
> makes it an even worse investment. The worst ones are those you can't really
> get the data back out of.

And _that_ is a customer protection law I'd love to see: requiring all
applications using proprietary formats for user data to provide an
export functionality (possibly as an auxiliary program) that is able to
write out the data as XML according to a DTD (or Schema, or RelaxNG,
whatever) to be published and filed in some accessible archive, and
import such an XML file back into the app's own format.

Some tolerance for closed source is one thing, hijacking users' data is
the bit that REALLY makes me see red!-)


> > Instead, I would hope it would enhance the possibilites for making
> > dependable agreements, which should be good for everyone, so long as access
> > to the the secure kitchen core hardware functionality is open, and
> > optional, and does not have back doors.
> 
> These agreements belong in the legal system not in the technology. That is why
> you have contracts and you have penalties for breaching a contract.

It is not reasonable to insist that, since laws exist to protect you,
you cannot take further precautions to guard against scofflaw, where
technically reasonable.  It's normal, for example, to place a lock on
some sort of property, even though the legal system may also forbid
others from removing said property of yours.

The cable/networking supplier who serves this apartment building (a few
tenants have bought various kinds of cable access from them -- TV, video
on demand, telephony, 10 mbps internet, etc -- it's a fiber-optic cable,
so I'm sure they have plenty of spare capacity;-) has (with my
permission as the building's owner) installed a service cabinet in the
cellar, with such interesting toys in it as Cisco routers, fiber optic
modems/multiplexers, etc.  As part of my agreement with them, I have
agreed that their cabinet can be locked (and it generally is, except
when some of their technicians forgets to re-lock it, which is why I
know what's in it).  If tomorrow they go out of business (unlikely but
no more so than for an average software supplier), their internet
connectivity is no doubt going to go down for quite a while until the
bankruptcy courts sort things out; anybody relying on that connection
for their business is going to be scrambling pretty bad to find
alternate suppliers, _and_ is going to hurt if they have left important
data on their IMAP server, etc, etc.

Yet one may evaluate this as a reasonable risk to take (some do).  ((Me,
I'm still using ADSL, waiting for more maturity in those 10 mpbs lines
before I trust them; in any case I always have an ISDN modem ready to
take over, so my connectivity _should_ degrade smoothly rather than ever
get cut off abrubtly... in theory...)).  It does not appear to me that
trusting a specific web service for your business presents any
substantial difference from trusting a connectivity supplier in general,
and the 'locking' aspects of the service (as long as no hijacking of
user data is involved) parallel the locking of the connectivity
supplie's service cabinet -- an extra precaution in addition to laws and
contracts, just in case.

And Bengt's idea (apart from requiring a highly specialized CPU in lieu
of pretty generic network access) doesn't appear to be any more
objectionable than web services, either.


Alex