Linux-Development-Sys Digest #277, Volume #6 Thu, 14 Jan 99 02:14:01 EST
Contents:
Re: Registry for Linux - Bad idea (George MacDonald)
Re: disheartened gnome developer (Doug DeJulio)
Re: disheartened gnome developer (Christopher B. Browne)
Re: A Call To Arms (Michael Schmitz)
Re: XFree86 3.3.3 good, Matrox good, Red Hat, not so good (Re: Matrox Millenium
G-200 Drivers) ("Frank T. Lofaro")
Re: - deprecated - why? (Edward A. Falk)
Re: disheartened gnome developer (Tim Smith)
Re: things I'd pay to have developed for Linux... (Leslie Mikesell)
Re: Shared memory between PCI device and application. (Luke Scharf)
Re: Open Configuration Storage - was Registry for Linux (George MacDonald)
----------------------------------------------------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Wed, 13 Jan 1999 21:25:51 GMT
Frank Sweetser wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > Well I'm striving to come up with a paragraph or two that can define
> > the solution. It needs to be clean, clear and easily communicated. It's
> > important to be able to set a vision or framework in someone
> > elses head so you can hang the details on it.
> >
> > Saying it's a distributed hierarchical persistent network
> > based object storage system doesn't quite cut it.
>
> how about this?
>
> opStore is an advanced configuration library consisting of 4 parts.
s/library/service?
>
> 1) a powerful, flexible internal data representation format capable of
> represting a wide range of data types, including range checking and
> priority tags.
Extensible?
>
> 2) a front end api suitable for embedding in applications. it includes
> functions for reading individual and sets of values, writing individual
> and sets of values, flushing out sets of values to permenant storage,
> and verifying values are within the defined bounds.
>
> 3) a back end api for plugging in dynamically loadable modules capable of
> translating the internal data represenatation to a particular format,
> including multiple flat text files, RDBMS, and CORBA formats.
>
> 4) a core logic implemented behind the front end api for evaluating the
> values obtained from a wide range of back end modules in a highly
> flexible, user and administrator defined order of precedence, and
> returning only the highest precedence value to the calling application.
>
> how's that sound?
>
Do you see evaluating the whole tree of values? I was thinking some
optimization could be done. i.e. why go to the net if there are
values in local files.
Otherwise very good!!
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 13 Jan 1999 17:11:33 -0500
In article <01be3ee6$bd23e900$[EMAIL PROTECTED]>,
Duncan Rose <[EMAIL PROTECTED]> wrote:
>I don't think you are right. According to the GPL, under which terms the RH
>software you're talking about is distributed, if the existing (freely
>available)
>source is used to build the new version, the new version must be GPLed
>too (in my understanding -- correct me if I'm wrong).
[...]
>Do I have an incorrect understanding of the GPL here?
Yes, you do. Remember that the GPL is a copyright. It only applies
to copies, not originals.
As the original authors of the software, RedHat themselves do *not*
fall under the license.
However, if they've ever accepted a single patch for the software from
outside RedHat that was itself GPLed, and for which the ownership of
the copyright was not handed over to RedHat, then they'd be bound by
the GPL *OF THAT PATCH*, and could would be bound to keep the GPL from
that point on. (Basically, you'd have two GPLed works which are
derivative of each other held by different copyright owners, which
forces them both to keep the GPL forever.)
So, has this occured?
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 14 Jan 1999 04:57:28 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 13 Jan 1999 23:49:45 GMT, steve mcadams <[EMAIL PROTECTED]> posted:
>>When ID Software sells a copy of "Quake 2000" (or whatever) thru CompUSA
>>for $50, it is highly probable that ID Software actually receives
>>something more on the order of $5. $45 goes elsewhere, whether to:
>> - The people that do the duplication of CDs and boxes and docs,
>> - CompUSA,
>> - The wholesaler in between,
>> - The advertising group at Ziff Davis and other such places
>>and so forth.
>
>Actually, the software author or "manufacturer" usually gets anywhere
>from 55 percent up, usually between 55 - 80% of revenue, if the
>product is sold via a direct reseller such as Programmer's Paradise or
>many of the web-based companies that provide secure transaction
>services.
Which probably means that there will be more interesting stuff at
Programmer's Paradise than at CompUSA. I'm a little surprised at the
numbers, but I suppose I should have expected there to be some sort of
'tier' in between the "sticking boxes on shelves" approach of the computer
superstores and direct sales.
My aside: Some love to hate him, but Mark Bolzern's efforts at "Linux
Mall" bear more of a resemblance to Programmer's Paradise than do most
of the others. He's been making efforts to have as *large* a set
of catalogue items as possible, and I would speculate that it would
be easier to get J Random Linux Product into LinuxMall than into the
catalogues of any of the other Linux vendors.
There is surely room for some "obscure order fulfillment" in the market
to stand somewhere in between the Red Hats and CheapBytes. There are
enough people that have gotten mad at him to cause some boycotting.
It's too bad, because some of the smaller commercial vendors of software
for Linux could really grow if they had their software listed in multiple
places and received the "cachet of respectability" that comes out of
having third-party resellers.
>I know this for a fact because 45% is what Programmer's
>Shop and Programmer's Paradise wanted when they tried to get me to let
>them sell my first product, and my current web-based service ends up
>costing me about 28% of whatever "sales" I manage to attract. The
>magazines wanted me to sell to them at a 45% discount so they could
>undersell my web-site and still make a sizable profit; of course they
>didn't want to order an inventory, they wanted me to wait for orders
>and then drop-ship them, so their 45% cut was for nothing more than
>taking orders and putting a tiny paragraph in the back of their
>magazine somewhere. The larger ads, such as the full-page ones for MS
>products, cost several thousand dollars to run in a single issue.
The bit that is unexpected is that they didn't expect for you to pay
something substantial for that paragraph in their magazine. I've heard
enough about the "PC Warehouse/CDW/PC Plus/..." folks that keep sending
monthly catalogues to drive me into considerable cynicism... These
enterprises reputedly make more out of advertising than they do from
the sales of product. (Although economics is such that it all has
to balance to some degree...)
>With the availability of electronic distribution for most applications
>(not operating systems), there is little excuse for this model's
>persistence other than that Joe Average Consumer, who Microsoft's
>products are targeted for (I draw this conclusion based on the fact
>that Windows 98 comes up with a picture of Mickey Mouse in the new
>channel-bar) don't yet know enough to buy on the web, how to download
>anything, etc. It's going to be interesting in the next few years,
The crucial word for any of these things is "trust." People don't
yet trust the web for this sort of stuff. And people often are
reluctant to trust those ads in the back of DDJ; they'd rather kick
a box at a store.
That may change; if people *can* grow to trust some of the small
vendors in obscure places that indeed UPS things to anywhere, there
are great opportunities for small organizations.
>I've been thinking that I should buy stock in UPS since that's the
>primary distribution medium web-based stores are using.
And during the gold rushes of the 1800's, it was folks that invested in
hotels and mining equipment manufacture and distribution and the likes
that got rich, rather than the miners themselves.
There is wisdom there...
--> Many web search engines may grow rich, and grow bankrupt.
--> Ditto for software houses.
If you sell network routers to them all, *you* can make money...
>Anyway, I
>look to see more of these physical stores move into other businesses,
>or engorge their already high prices to an unbelievable level just in
>order to pay their outrageous leases in the strip-mall.
It appears that local stores are gradually turning into "fork lift
operations;" superstores that are basically large distribution sites,
not quite wholesalers, but almost. And they need *high* volume to
survive.
Small shops get squeezed out of their real estate in that kind of market.
Fortunately, for a few bucks, UPS will take almost anything almost
anywhere.
>In any case I
>don't think it represents an open-source paradigm.
Certainly not.
>>The notion that *any* company puts all or substantially all of their
>>resources into development is nonsense. Even with "supportless"
>>products, most of the resources go to other than development.
>
>Really. For "all" meaning zero support, well, zero-support companies
>go out of business, right? But "substantially all" is how much I
>would expect a 1-man or even a 7-man development shop to put into
>development, since they can't afford anything less unless they have
>miniscule product plans. If they can't be essentially supportless,
>provide all the support their customers need, and still crank out new
>product, then they are simply doomed under -any- model except one
>where they have received a grant of some near-unlimited amount of
>money from a patron.
A development shop needs the other roles, such as marketing, finance,
distribution, and so forth. Great coders may produce great code, but
if nobody sells it, the bills won't get paid.
The typical sort of product where *no* support is either available
or needed is where the product is a computer game. The company
needs to crank out a game or three per year, effectively seeking
to convince people that what they produced last year is now
obsolete.
Slightly less "canned" is the "office tool," such as a word processor
or spreadsheet.
If WordPerfect 5.1 has saturated the market, and is both reliable and
featureful, then there will be few continuing sales. There are three
alternatives at this point:
a) Convince the world that the old version is obsolete and bad for
them, and that they need to buy the new version;
b) Sell people on the idea of paying for support, so that they get
enhancements and assistance in learning how to use it better;
c) Sales fall, and the company will ultimately have to fold.
You've got to be selling something.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: Michael Schmitz <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.m68k
Subject: Re: A Call To Arms
Date: Wed, 13 Jan 1999 14:22:36 -0800
PHIL SMITH wrote:
> This is why Linux users are getting a such a bad reputation... say one
> thing even remotely bad about it and you get start getting jumped on.
[...]
> Waiting for the flames to begin...
Please take this discussion off c.o.l.m68k, it's off topic there (and
probably equally off-topic in the other groups it was posted to).
The appropriate forum for this is c.o.l.advocacy.
Michael
------------------------------
From: "Frank T. Lofaro" <[EMAIL PROTECTED]>
Subject: Re: XFree86 3.3.3 good, Matrox good, Red Hat, not so good (Re: Matrox
Millenium G-200 Drivers)
Date: 14 Jan 1999 05:50:59 GMT
In <[EMAIL PROTECTED]> on 10 Jan 1999 00:59:15 -0500, Michael
Meissner <[EMAIL PROTECTED]> wrote in comp.os.linux.development.system:
>Or upgrade to a complete 3.3.3 system via RedHat's rpms. For 5.2, ftp to
>updates.redhat.com, and go to the /5.2/i386 directory. I found I needed to
>delete some of the packages, because somebody moved some files around.
>--
Thanks for the advice. But having to delete some files as you put it
is ugly! RPM should've dealt with that. Right? Who knows what state
the database is in... Maybe the package management way is not the way
to go.
The admins here at this site put non-core packages in their own
directory:
/local/package/bin
/local/package/man
/local/package/lib
Sure, they have to manage dependencies themselves, but it works very
well, and no database to get corrupted, and to remove a package one
can just rm -rf the directory, etc. No problems upgrading a library
that other stuff depends on, etc.
Multiple people can, and do, work in those directories.
Yes, $PATH, $MANPATH and $LD_LIBRARY_PATH management can be an issue,
but I wrote a shell function and script to automate that for
myself. It's not hard to handle.
You could make symlinks to the normal places if need be (standards,
etc). Not too hard to manage the symlinks, since a simple stat() will
let you know where tehy go, and hence, what they are.
You could have every such package automatically get a window manager
menu and each program a menu entry. Same with the man stuff for help
menus.
Dealing with that is much easier than RPM, etc type
solutions. Dependencies can be dealt with with common sense.
You don't need a database, etc if your files from different packages
are all mixed up together.
Might be a good alternative to .rpm, .deb hell.
BTW, GNU software have no problem with being put in a specific
directory.
./configure --prefix=/local/packagename works well. I have done this
at multiple sites, without trouble.
------------------------------
From: [EMAIL PROTECTED] (Edward A. Falk)
Subject: Re: - deprecated - why?
Date: 13 Jan 1999 21:50:27 -0800
In article <77i09a$ajt$[EMAIL PROTECTED]>,
Steve Carter <[EMAIL PROTECTED]> wrote:
>[originally posted to comp.os.linux.development.apps oops!]
>
>Why in the world does linux tell me off for typing
>
>ps -e
YEAH! I had a whole bunch of scripts break because of that. Why
not leave it alone?
--
-ed falk, [EMAIL PROTECTED] *********************#*********
Visit http://www.rahul.net/falk/whatToDo.html ****#*#**************F******!**
and read 12 Simple Things You Can Do ****!*!!**********!************
to Save the Internet ***************#****#******#**
------------------------------
From: [EMAIL PROTECTED] (Tim Smith)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 13 Jan 1999 20:59:57 -0800
Duncan Rose <[EMAIL PROTECTED]> wrote:
>I don't think you are right. According to the GPL, under which terms the RH
>software you're talking about is distributed, if the existing (freely
>available)
>source is used to build the new version, the new version must be GPLed
>too (in my understanding -- correct me if I'm wrong).
You are wrong. The owner of the copyright on something can distribute it
under as many incompatible licenses as they wish.
>If they do anything else they're in violation of the GPL, which, let's face
>it, is
>not likely to be a barrier if they wanted to do such a thing (as far as I
>know the
>GPL has never been tested in court, so we still don't know where developers
>would stand if they broke the sentiment/letter of the GPL).
It's not possible for the author of the code to violate the GPL on that code,
since it is not possible for one to make a contract with himself. Think about
it for a moment--the author is going to look pretty silly trying to sue
himself to make himself stop violating GPL!
--Tim Smith
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
Date: 13 Jan 1999 16:42:13 -0600
In article <9tXm2.920$[EMAIL PROTECTED]>,
Phil Howard <[EMAIL PROTECTED]> wrote:
>While Linux's MD feature can merge multiple partitions into one filesystem,
>it would be nice if a filesystem were smart enough to understand each of
>the partitions it is using and know how to add it in, or even remove it.
>Even an LVM for Linux is going to require changes in a filesystem so that
>the filesystem knows there are more blocks available to allocate, and has
>the allocation maps grow somewhere. Will there be more superblocks? I'd
>tend to think so.
I'd like to see a filesystem that let your logical mount point be a read/write
overlay of a read-only mount, possibly NFS or CDROM. It would be nice if
the overlay had some caching and the ability to sync to a writable disk
and come back in the same state again but it would be useful even without
it. You could then use the same system image for many machines (either
shared or copied) and still make the minor changes that give each machine
its identity without any other special provisions. Has this been done
for Linux? Does Coda do anything like this?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Luke Scharf <[EMAIL PROTECTED]>
Subject: Re: Shared memory between PCI device and application.
Date: Wed, 13 Jan 1999 18:09:15 -0500
I've never written a divice driver, but I installed a PCI device
recently that required a patch to the kernel called bigphysarea.
It seems to me that bigphysarea does what you are looking for, except
that there is a cap, specified at boot time, on the amount of memory
that can be used.
I think that there's a link available on DejaNews.
-Luke
Greg Johnson wrote:
> I am writting a device driver for a PCI card that my company is
> developing. I need to create, on demand, an area of locked down memory
> that is accessable by both an application program and the PCI device.
> The area need not be contiguous in physical memory, so using
> get_free_page several time would suffice. The PCI device can handle
> non-contiguous physical memory regions so this is not a problem
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: Thu, 14 Jan 1999 06:53:58 GMT
Christopher Browne wrote:
>
> On Wed, 13 Jan 1999 06:19:24 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
> >Yes but you have to custom code for LDAP, what do you do then if
> >you want to use ACAP? Recode an application? That's not what end
> >users want, they just want to be able to use the services.
>
> Which means that it is attractive, *at least at the reading end,* to
> provide an API that allows some of these services to be easily mapped
> onto easily used forms.
>
> For instance, it's a pain to code something using API calls to
> view/manipulate SNMP configuration.
>
> But a tool that exported this into a form where it *looked* like a
> virtual file system (like /proc) would allow one to readily use existing
> file management tools to examine system configuration. And possibly
> even manipulate it, given the ability to write to the "virtual files."
>
> As far as the user is concerned, this sort of thing is "magic." Using a
> VFS would be a little bit "magical" if you want a portable system that
> isn't limited to Linux. But once this "magic" is performed, old,
> mundane tools can be used to look at, view, and manipulate the results.
>
> If we turned the configuration into a virtual file system, for instance,
> there would be no need to write a special tool to view it; the user
> could just use one of the existing "file manager" utilities.
>
> We 'win' if we can get a suitable representation that lets us use
> existing tools 'for free.'
Using /proc a lot myself, I rather like this idea. If I understand
correctly a loopback file system would allow the implementation
to be a program vs in the kernel.
In my original plan I was thinking about combining the
"system config tree" with the "user config tree" to provide
a config tree. My initial thoughts were to use "helper processes".
These could be called "store managers", and thier purpose
would be to do the notification for config change listeners
as well as other things such as performance improvements.
Your probably wondering about having a "user store" process.
I figured it would be better to also have a per user process vs just
one system daemon. Partially because of load distribution,
partially because of security issues(i.e. when writing a
file in user space the process needs to be setuid to
the appropriate user so the file ownership works). This is
similar to what sendmail does when processing mail for
a particular user.
Note this was just my original thinking, I have backed
up to a requrements phase so all the implementation stuff
will be rethought.
I suppose these store managers could provide the implementation
of the loopback file system. Your probably wondering about
the user store manager process? It could either be started
as a session process, or via the daemon when the first user
app starts.
The only problem I see with this idea is that the "object
names" would be limited to the normal file name space
limitations. Not a huge limitation.
I suppose one could either use the /proc directories or
create a new hierarchy. If using /proc perhaps a
/proc/${pid}/config which contains the running programs
config parameters. The as you say just use normal tools.
What about modifying/browsing the config of apps that are
not running? I suppose a /proc/opStore/apps/$app_name/config
/proc/opStore/$user/Application/$app_name/config
Or something similar.
Seems like it could be a workable solution, I like it.
How did you envisage implementing it? As a kernel module
or a user space process? Would you still keep user
config settings under the users space i.e. $HOME?
I have several reasons for wanting to do it that way, a big
part is that a user can copy there $HOME and all
there settings get copied.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
