Linux-Development-Sys Digest #256, Volume #6     Mon, 11 Jan 99 15:14:31 EST

Contents:
  Re: disheartened gnome developer ([EMAIL PROTECTED])
  Re: 2 stacks? (Richard Jones)
  Kernel 2.2 and Cyrix processors (Dale Pontius)
  K6-2 300 Problem (Marcos Silva)
  Re: Adopting COM? (Brett W. McCoy)
  crash dump on Sparc? (Michael Hart)
  Re: Registry for Linux - Bad idea (George MacDonald)
  Re: Kernel 2.2 and Cyrix processors (Dr Dale Mellor)
  Re: disheartened gnome developer (Marco Anglesio)
  Re: disheartened gnome developer (Marco Anglesio)
  Re: glibc and utmp/wtmp (J.H.M. Dassen (Ray))

----------------------------------------------------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Mon, 11 Jan 1999 17:13:58 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (jedi) wrote:
> On Sun, 10 Jan 1999 21:14:53 GMT, Perry Pip <[EMAIL PROTECTED]> wrote:
> >On Sun, 10 Jan 1999 17:59:53 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> >>In article <[EMAIL PROTECTED]>,
> >>  [EMAIL PROTECTED] wrote:
> >>> Yes, but they are just co-owners. Take a look at the Gtk+ and Gnome
> >>> sources and you'll see copyrights not only owned owned by Redhat, but buy
> >>> FSF, and dozens of other individuals.
> >>
> >>Look at the sources of control-panel and you will see a different
> >>thing.
>
>       You'll have to be more specific.
>
>       All I've found so far in the Redhat control-panel are like thus:
>
> Red Hat Linux netcfg 2.18
> Copyright (C) 1996, 1997 Red Hat Software
> Redistributable under the terms of the GNU General Public License

Gee, so the control panel is owned by Red Hat, and they could rerelease them
tomorrow under a proprietary license. Just like I said they could (and said
they wont do it) when you called me a liar.

I suppose you wont apologize, of course.

--
Roberto Alsina (KDE developer, MFCH)
&#137;

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: Richard Jones <[EMAIL PROTECTED]>
Subject: Re: 2 stacks?
Date: Mon, 11 Jan 1999 16:49:14 +0000

Johan Kullstam <[EMAIL PROTECTED]> wrote:
: Richard Jones <[EMAIL PROTECTED]> writes:

:> ** LuCiFeR ** <[EMAIL PROTECTED]> wrote:
:> : Thought about that too.. The code is normal C for now but I already
:> : adjusted it to be usable with C++ compilers (// comments are SO handy :P)
:> : Is there a way to automatically dispose objects at functionreturn which
:> : were allocated as local variables?
:> 
:> alloca (3)

: in a C++ program, how do i convince a constructor to use alloca
: instead of malloc where appropriate?  is it even possible without
: rewriting the c/d-tors themselves?

In a C++ program it's not a problem, because the
language supplies you with a method for creating
any object on the stack, like so:

        fn ()
        {
          BigObject obj;

          // Object obj is allocated on the stack
          // and freed as soon as we return from
          // the function by any means.

        }

Note the implication here that obj's constructor
is called with a pointer to stack memory as its
implicit first argument ...

In fact, with gcc and pure C, alloca isn't necessary
either because gcc extends C to provide useful (albeit
non-portable) ways to allocate variable-sized arrays
on the stack.

Rich.

-- 
-      Richard Jones. Linux contractor London and SE areas.        -
-    Very boring homepage at: http://www.annexia.demon.co.uk/      -
- You are currently the 1,991,243,100th visitor to this signature. -
-    Original message content Copyright (C) 1998 Richard Jones.    -

------------------------------

From: [EMAIL PROTECTED] (Dale Pontius)
Subject: Kernel 2.2 and Cyrix processors
Date: 11 Jan 1999 18:23:05 GMT

I've seen indications of problems with Kernel 2.2 running on Cyrix
processors. One post even had someone trying to compile 2.2 for
386, (not 486,++) and still being unable to get the thing to run.
I've read other things about some Cyrix stuff 'being left behind'.

So what's the scoop on Kernel 2.2 and Cyrix? Does it really work,
and the one report just local problems? Were Cyrix fixes dropped
somewhere, and have they been picked back up?

Or, since I have an OLD stepping of a Cyrix CPU, am I outta luck
for 2.2 until I upgrade my mobo later this year? I'd rather have
some outlook before going through the lengthy download and rather
not lose hair if this is doomed to failure.

Dale Pontius
(NOT speaking for IBM)

------------------------------

From: Marcos Silva <[EMAIL PROTECTED]>
Subject: K6-2 300 Problem
Date: Sun, 10 Jan 1999 23:47:49 -0200


I installed Linux RedHat 5.2 in a computer and itīs all ok with the
installation, but when the system boot, it lock in "Loading
Linux......".

My computer configuration is k6-2 300Mhz, RAM 64Mb, HD 2Gb, CD 32x
Creative, network card 3C509, video card SVirge 4Mb.

I have another computer (Pentium II) running Linux and it's all ok.

--
Marcos Ferreira da Silva
Centrio Universitario do Triangulo
Uberlandia - MG
Brazil



------------------------------

From: [EMAIL PROTECTED] (Brett W. McCoy)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Adopting COM?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Jan 1999 16:53:48 GMT

On 10 Jan 1999 21:01:42 GMT, Christopher B. Browne
<[EMAIL PROTECTED]> wrote:

>On the other hand, it is likely that one or another of the ORBs will
>become a "preferable option."
>
>Applications tend to get deployed for a specific ORB; the client and
>server code *is* ORB-specific to at least some extent.  As a result,
>GNOME apps will almost certainly be ORBit-specific.  They may request
>services that are being provided via another ORB; nothing stops you
>from installing multiple ORBs.

This is true to some extent, but a client application needs not know the
platform-specific implementations of a server, and vice versa (this is the
idea behind CORBA, isn't it?).  An application using ORBit should be able
to make the interfaces available to clients (even ones running on Windows
95, for that matter) that are using compliant ORBs.  Can someone write a
GNOME-compliant distributed application based soleley on IDL?

-- 
Brett W. McCoy           
                                        http://www.lan2wan.com/~bmccoy/
=======================================================================
"The number of UNIX installations has grown to 10, with more expected."
   -- The UNIX Programmer's Manual, 2nd Edition, June, 1972

=====BEGIN GEEK CODE BLOCK=====
Version: 3.12
GAT dpu s:-- a C++++ UL++++$ P+ L+++ E W++ N+ o K- w--- O@ M@ !V PS+++
PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ G++ e>++ h+(---) r++ y++++
======END GEEK CODE BLOCK======

------------------------------

From: Michael Hart <[EMAIL PROTECTED]>
Subject: crash dump on Sparc?
Date: Mon, 11 Jan 1999 09:37:13 -0500

I'm running Redhat 5.1 on a SPARC IPX workstation (using KDE as the
window manager.). It has crashed several times in the past month, with
no noticeable error messages. /var/log/messages shows nothing, and the
only message on the screen is a BIOS messages: Illegal instruction. It
only seems to happen when i'm not around. I usually leave the system
locked using xlock...

Is there a core dump somewhere I can look at? Any other places that may
contain messages or hints as to why it crashes? This isn't helping me
trying to introduce Linux into this company... :(

cheers,
mike ([EMAIL PROTECTED])


------------------------------

From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 04 Jan 1999 23:41:38 GMT

Frank Sweetser wrote:
> 
> George MacDonald <[EMAIL PROTECTED]> writes:
> 
> > I want to be able to update the config from within an application, i.e.
> > a preference type mechanism. I have been thinking about what it would
> > take to create X resources on the fly, and update an application
> > config file. In fact it could be several config files that are included
> > in one X resource file. But this design requires X, which is not generic
> > enough for all applications.
> 
> it shouldn't be too hard to set up a simplistic, probably inneficient
> scheme using some gratuitous file locking.  the difficult part, i think,
> would be seperating system defaults in /etc/ from user preferences.  if a
> setting is specified in /etc/foo.conf but not in ~/.foo.conf, you wouldn't
> want to write out the value to ~/.foo.conf unless it differed... hmm... i
> think i might have just answered my own question, treat ~/.foo.conf as a
> COW copy of /etc/foo.conf =)
> 
> > It is also missing many advanced features, such as ensuring changes
> > are made atomically to multiple config files.
> 
> hmm... it should be fairly easy with a single config file.  what kind of
> scenario do you see where it would be updating multiple config files as a
> single operation?
> 

Hmm, lets see. If I create a "component" that is a file selector and I
create a seperate resource file for that component. Then include
that resource file in any app resource file that uses the new file
selector component. This allows me to set a resource for the new
file selector Class in one place. Now lets say I'm running an app
and I want to change one of the resource values for the new file
selector. In this case lets assume I have a favorite places in
the file selector. I may want to update the Class(the new place
is visible in all apps) or update the instance(the new place
only shows up when used via the current app) or I may want to
do both.

Also I may want to update several resources at the same time
in several files.


> > >
> > > >       No typing/classifying of values so can't write one parser - see
> > > >       SNMP MIB's
> > >
> > > not sure what you mean here... would you mind clarying this a bit?
> >
> > Sure,
> >
> > SNMP = Simple Network Management Protocol,
> > MIB  = Management Information Base
> 
> okay... i'm familiar with the concept of SNMP, just didn't see how your
> point applied here (good def of SNMP, though =).
> 
> > The MIB is a data file, it can be read by Network Management Systems which
> > can then query the devices for information and or get/set config parameters.
> > The really cool thing is that the NMS systems have *no* code that is
> > written for the specific piece of hardware! i.e. new hardware can
> > be supported just by adding new data files.
> 
> partially true... i think the reason that most network hardware works like
> that is because so many of the values are shared (byte counts, packet
> counts, errors, etc).  for more advanced, often proprietary stuff (filters,
> security) the software must be aware of the meanings of those values.
> trust me, we've had to upgrade the NMS software on our machine here to deal
> with new hardware in anything but the basic generic functions several
> times...

Yes but a generic NMS system can be built, like OpenView ..., that can
be used as the framework to plug in device specific modules. Even
without the modules some generic functionality can be used on the
new device. i.e.

        Monitoring/Logging changes
        Graphing values

Also devices that have a common set of values can use existing
MIB's and thus use existing tools.


> 
> however, to get back OT, i don't think this would be an issue, as the
> config library would simply be handing back values for the requested keys
> and letting the application deal with 'em from there.
> 

It would be nice to be able to leverage configuration components. Lets say
a user want's to define a color for the background of a widget.
In such a case one could have a "color selector" component that does
the selecting. Thus a developer would not need to write one. Also
if done right new color selector components could be written and
plugged into apps at run time.

> >
> > > > > No range specifiers so can't have independent tools validate
> > configs > > shouldn't be hard for numerical values, not sure how it would
> > apply to > strings.
> >
> > Well, one needs an external description to know what type the fields are.
> >
> > Strings are more complicated, some simple ones are length, list of
> > valid OCTETS, ... This is an area where plug in modules might be useful.
> 
> fair enough.  perhaps a strlen and valid charset?  any other data types
> beyond numeric, str, and groupings thereof?
> 
> >
> > >
> > > >       No syncronized writes i.e. for multiple processes
> > >
> > > >       No networking so I can pull config from another site
> > > >       No publishing so I can publish part of my config.
> > >
> > > what protocols would you propose using?
> > >
> >
> > I was thinking of developing one, then also allowing SNMP, CORBA,
> > RPC, HTTP, ... to be added as modules. Many of these are not
> > required for small systems, which for the most part could get
> > by with a small library. The above protocols would allow
> > adaptation to existing large site managment mechanisms.
> >
> > The protocol I had in mind was an OO based extensible protocol
> > which would allow security, encryption, authentication objects
> > to be pushed in the protocol stream as needed.
> >
> > It would be easier to just say CORBA, but I don't want to be
> > bound to it as it's not yet universal.
> 
> i like it, i like it.... an API with something like
> 
> get_key(char *key)
> set_key(char *key, foo *value)
> create_num_key(char *name, int upper_bound, int lower_bound)
> create_str_key(char *name, foo charset)
> write_config(pointer to the whole config tree)
> 
> also, what language were you planning on using?
> 

I was hoping to be language neutral, i.e. define an interface
to a config service and then do language bindings for  

        C, C++, Java, Python, Shell ...

Also to be Object Oriented but not requiring an OO language, i.e.
the half way approach taken by Xt, GTk+  etc.

> i'm not sure it would be worth it to develop a new protocol and
> accompanying server for it.  to me, the most useful ones would be local
> files, SNMP (fairly lightweight, for smallish networks primarily), SQL so
> you can store 'em on a full-featured database for better scalability,
> backups, transactions, etc, and HTTP (to make it simply, could use the same
> file format as local files... would make writing the config files a little
> harder - WebDAV, perhaps?) primarily for roaming users to get around
> firewalls and low bandwidth configs.  CORBA sounds like it would also be
> well suited for this, and it seems to be getting more common nowadays.
> 

I think you pretty much nailed what I was thinking. I would prefer to
leverage off of existing implementations as much as possible, but
can't find one protocol that does what I want. Well CORBA does but
thats one heck of a requirement for an app that only has a couple
of settings. Thus I don't want to be bound to CORBA, but at the same
time think it could be used for the higher end of the service.

> i definatelly like the way this project is looking.... i'd be willing to
> contribute, if you're interested.

Great! I am putting together a web site for this purpose, and have started
to put togther a feature list ... See

  http://at.home/gmd/opStore/

This is a very rough first cut and everything is subject to change.

I am shooting to get a project definition in the next week or two and
an outline of an architecture spec by the end of the month. I could
see a basic library coming together in a month or two and a core
service framework in 3-6 months(depending on how many people
want to get involved). This estimate does not include many of the
advanced features CORBA/HTML/SNMP interface modules etc. But
would provide the architecture/plugin points for them.

My primary interest is in a config system for an app I am developing,
i.e. treeps

    http://24.1.97.22/gmd/tps/treepsfm.html

which is already very configuration dependent and about to become much
more so. My needs for it exceed all current config systems I find, so
am going to write my own anyhow, may as well make it useful for others
and extensible for later needs. It appears it's also something that
needs doing!

I am going to dedicate 6 months of full time activity to this task
and am open to either joining a project or coordinating it. Anyone
who wants to help is welcome.


-- 
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: Dr Dale Mellor <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.2 and Cyrix processors
Date: Mon, 11 Jan 1999 18:44:03 +0000

Dale Pontius wrote:
> 
> I've seen indications of problems with Kernel 2.2 running on Cyrix
> processors...

    I found it necessary to disable SMP before it would even boot (on a
Cyrix 120+). I'm still not entirely satisfied that the networking is
okay (I often get long delays when rlogin'ing)
                                                                  Dale

------------------------------

From: Marco Anglesio <[EMAIL PROTECTED]>
Subject: Re: disheartened gnome developer
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Date: Mon, 11 Jan 1999 15:58:41 GMT

In comp.os.linux.development.system steve mcadams <[EMAIL PROTECTED]> wrote:
> What if such a company believes that its support should be costless
> because it is a point of HONOR and/or INTEGRITY to keep your software
> working correctly?  Do they just get screwed?  They all have to go and
> flip burgers for a living because they don't do phones for money like
> the other 900-girls?

Not to seem condescending, Steve, but the cost of support is written in to
any license that provides support at no cost. Either that or your pricing
structure is built to fail. Support is extremely labour-intensive work,
and it increases as the user base increases (development, OTOH, is a
relatively stable cost - developers also provide second or third level
support at most companies, so it increases at a lower rate than first
level support).

> And worse yet, what if these guys writing the CODE are SO GOOD that
> NOBODY ever NEEDS SUPPORT?  Are they supposed to sit there and either

What if, what if, what if? It would be nice, but any company buying your
code will still sign a support contract because they can't see the future.
If it turns out bug-free (and users are magically made competent,
instantly, upon receipt of the software), that's fine, but you find that
out after your client uses the software, no? Likewise for documentation -
it costs money, it costs developer time, it costs technical writer time
and support time to back it up.

If you sell a shrink-wrapped product, even if it is GPL'ed, you still have
plenty of profit centers. RedHat, for example, gets fifty bucks a copy for
a free product, and from this it pays for documentation, user support,
R&D, promotion, production, and distribution. If RedHat's user support is
cursory and takes a while to get out, remember that you get what you pay
for; they're probably more than willing to offer you more support at a
price.

There's also buy-in as a source of future profit. If everyone uses the Red
Hat Package Manager, rpm, then everyone has an incentive to buy more stuff
from Red Hat, not all of which will be GPL'ed and some of which may
actually be bespoke work. Red Hat used to sell CDE, it still sells Motif,
and both of these come at a much steeper price. A lot of people that
bought RedHat 5.0 bought 5.1 and 5.2, and many of the people that bought
5.0 had already bought previous versions of RedHat. 

This is actually the strategy that IBM used for the model 360 mainframe -
an extensible architecture, true, but it also locked in the customer for a
long, long time, with software upgrades, with hardware upgrades, with
operating system upgrades, etc.

In conclusion, even if development for the main application brings in new
revenue for a GPL'ed product, there are still a number of profit centers
remaining: end-user support, developer support, alternate licensing (like
Sendmail, like Aladdin Ghostscript), documentation, and lock in.

marco

--
Marco Anglesio                                    Like Captain Idiot 
mpa at the-wire dot com                 in Astounding Science comics
http://www.the-wire.com/~mpa              (The Manchurian Candidate)


------------------------------

From: Marco Anglesio <[EMAIL PROTECTED]>
Subject: Re: disheartened gnome developer
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Date: Mon, 11 Jan 1999 16:01:19 GMT

In comp.os.linux.development.system steve mcadams <[EMAIL PROTECTED]> wrote:
> Do you have a url where I can see their financial statements to verify
> this?  Otherwise unless you are a Microsoft employee with access to
> their financial statements, you may as well be talking out your ass.

Check the Microsoft SEC filing. Given that they are a public company, they
are required to go in some detail as to their expected sources of revenue.

marco

--
Marco Anglesio                                    Like Captain Idiot 
mpa at the-wire dot com                 in Astounding Science comics
http://www.the-wire.com/~mpa              (The Manchurian Candidate)



------------------------------

From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: glibc and utmp/wtmp
Date: 11 Jan 1999 19:17:53 GMT

Tom Daley <[EMAIL PROTECTED]> wrote:
>I recently upgraded to glibc-2.0.6.  I have also started building my system
>programs to use the library. After building and installing sh-utils-1.16 I
>have noticed that "users" and "who" don't work (they run but give no
>output).

Quoting the FAQ included with glibc:
:3.2.    Why does getlogin() always return NULL on my Linux box?
:
:{UD} The GNU C library has a format for the UTMP and WTMP file which
:differs from what your system currently has.  It was extended to fulfill
:the needs of the next years when IPv6 is introduced.  The record size is
:different and some fields have different positions. The files written by
:functions from the one library cannot be read by functions from the other
:library.  Sorry, but this is what a major release is for.  It's better to
:have a cut now than having no means to support the new techniques later.

This means that if you run both libc5 and glibc applications that manipulate
utmp and wtmp, these files will be corrupted.

>Does anyone know how I can get this working again?

One option is to recompile all utmp/wtmp manipulating code with glibc.
Another is to update your libc5 to one that handles glibc's utmp/wtmp format
(Debian's libc5 as been patched for this) and recompile programs that
manipulate utmp/wtmp directly (instead of through the library functions),
like some versions of ssh, with glibc. 


HTH,
Ray
-- 
Obsig: developing a new sig

------------------------------


** 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
******************************

Reply via email to