Linux-Development-Sys Digest #258, Volume #6 Mon, 11 Jan 99 19:14:07 EST
Contents:
Re: Adopting COM? (Brett W. McCoy)
How do you make ld output pure binary? (Greg Law)
Re: blocksize / file write speed anomaly (jerry)
Re: PCMCIA card services (Daniel R. Grayson)
Re: CDROM under DOSEMU (Dr A O V Le Blanc)
Re: Open Configuration Storage - was Registry for Linux (Frank Sweetser)
Re: disheartened gnome developer (Frank Sweetser)
Re: Open Configuration Storage - was Registry for Linux (Frank Sweetser)
Re: Help about wish and tcl commands ! (Brett W. McCoy)
superformat and 2.2.0pre6 (bill davidsen)
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: 2.2.0pre6 booting errors (bill davidsen)
----------------------------------------------------------------------------
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 17:22:15 GMT
On Mon, 11 Jan 1999 00:33:27 +0100, Osvaldo Pinali Doederlein
<[EMAIL PROTECTED]> wrote:
>I was thinking about that. Maybe all you need is a standard procedure so
>any ORB can be plugged in the OS. People who can buy big Linux
>distributions can also get all free ORBs included on it, since there's
>plenty space in CD-ROM distributions and ORBs are not that big. The people
>doing the kernel could set up the rules to implement things like CORBA
>Services and helper daemons (like interface repositories, or
>location/activation daemons) as modules. Having standard APIs or admin
>tools to do the basic management of each pieces (these could be just
>wrappers to whatever different admin interfaces of each ORB). The idea is,
>adding to the OS some smart standards, scripts and wrapper libs to make all
>ORBs look the same to the user, administrator, and as much as possible to
>the developer. This is almost as good as having a single standardized ORB.
There is not, nor will there ever be, a standard ORB, at least not in the
sense you are making it. What is standard about CORBA is the protocol
(IIOP), the interface language and the language mappings. Here is a quote
directly from the OMG book _CORBA Fundamentals and Programming_:
"In CORBA, all a client developer needs to know is the IDL
interface definition and the description of what the object does. This is
how CORBA and IDL enable our plug-and-play component software environment.
At run time, only one other piece of information will be needed to invoke
a method on the object: its object reference..."
However, the Unix philosophy has always been based around component-based
software. It's nothing new to Unix to have small, discrete software units
with common interfaces to interact with each other in a predictable and
stable way. What is CORBA going to add to this? You could stick in an
ORB, make a public interface to, say, sed, make it available on a server,
and write an application to make use of the interface. Actually, we've
all been using RPC on Unix systems for years (RPC is just the predecessor
to CORBA) for just this purpose: this is how NFS works, for instance.
--
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: Greg Law <[EMAIL PROTECTED]>
Subject: How do you make ld output pure binary?
Date: Mon, 11 Jan 1999 16:23:23 +0000
I have 2 ELF files - one created by NASM and one by GCC. I want to link
them together (which is OK), but not so that they'll run under Linux,
rather so I get a /pure/ binary - no libraries, no symbols, just code
and a little data. I can't for the life of me figure out how to do this
using ld under Linux - please help!
Thanks in advance,
Greg.
------------------------------
From: jerry <[EMAIL PROTECTED]>
Subject: Re: blocksize / file write speed anomaly
Date: Mon, 11 Jan 1999 11:29:31 -0500
I have tested the problem on 4 machines. ( 3 ibm pc's with pentium II procs ) and a
non IBM pc
with 166 mz pentium. The results were pretty much the same so I do not think it has
anything to do
with non Intel chips.
When I first dicovered the problem , I found out some other interesting things.
1. if I set the blocksize to 512 instead of 2048 and I did the random write on 1024
X byte
offsets instead of 4096 X byte offsets, the problem went away. I then thought that
all I had to
do was write 4K as 8 512B blocks. However , when I wrote the 512B blocks on 2KB
offsets, the
problem returned.
1a. I also tried to write large blocks as a number of 512B blocks via writev but the
results were
not as good as writing 1 large block.
2.Instead of writing block 2,4,6, ... I wrote to random block offsets and the program
was a
little faster.
I did not save the original program because the 2nd program I posted was the smallest
test case to
demo the problem.
Jerry
Stefaan A Eeckels wrote:
> I've tried with fdatasync(), and without sync()ing at all, and
> I get similar results to my first test (102Mb file to eliminate
> cacheing):
>
> write_linux running ...
> Duration 18 seconds
> rwrite_linux running ...
> 25000 records written
> Duration 12 seconds
> 25000 records written
> Duration 27 seconds
> Duration 27 seconds
>
> During the test, disk IO is slowish (which is what I'd expect
> because everything is running from a single disk), but the
> system is fully functional - no freezes whatsoever.
>
> Here's the configuration:
> Intel DK440LX motherboard
> Single PII 266 processor
> 128Mb RAM
> On-board Adaptec AIC-7985 UW controller:
> disks: QUANTUM XP34550W (/, /usr, /var, /opt, swap)
> IBM DCAS-32160W (only Oracle)
>
> I just don't understand why so many people get what can only
> be described as "unacceptable behaviour".
> Do all of those who see the slowdown have AMD processors, by
> any chance (seeing that SCSI (different controllers) or IDE
> doesn't seem to be a factor).
>
> Take care,
>
> --
> Stefaan
> --
>
> PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
> ___________________________________________________________________
> Perfection is reached, not when there is no longer anything to add,
> but when there is no longer anything to take away. -- Saint-Exupéry
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Subject: Re: PCMCIA card services
Date: 11 Jan 1999 16:20:57 -0600
Dr Dale Mellor <[EMAIL PROTECTED]> writes:
> Has anyone managed to compile the PCMCIA card services stuff for a
> 2.2.0-pre? kernel? What's the trick? I could not get the stuff to
> recognise the extended kernel version number.
> Dale
Pick up the beta version that works at
[EMAIL PROTECTED]:/pub/pcmcia/NEW/pcmcia-cs.09-Jan-99.tar.gz
------------------------------
From: [EMAIL PROTECTED] (Dr A O V Le Blanc)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: CDROM under DOSEMU
Date: 11 Jan 1999 17:33:11 -0000
mvrao <[EMAIL PROTECTED]> writes:
>Well, I am getting errors using lredir.
>lredir d: linux\fs/mnt/cdrom and lredir d: /mnt/cdrom both give
>errors 'while redirecting'.
>d: is not mapped under dosemu
Have you installed a microsoft system instead of the default
freedos one? The documentation that comes with dosemu
warns that the lredir command does not work with the default
system.
-- Owen
[EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 11 Jan 1999 12:20:53 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >
> >the existing plan already includes locally configured metadata, this
> >metadata coule include default priorities for any resources that do not
> >specify one themself.
>
> If you can't obtain these values through the same mechanism you
> propose for everyone else's configurations then you have done
> something wrong.
yup. however, we had already discussed the fact that for a given key,
there would have to be the potential for more atributes than just the key's
value - type (str vs int, etc), legal ranges, etc. the priority would be
just such another tag.
in addition, there also has to be some amount of locally stored information
so that the lib knows who/what to contact for more info (other local files,
rdbms, etc). each source could also then be given a modifier applied to
any priorities from that source, at the sysadmin's discresion.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre5ac1 i586 | at public servers
And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 11 Jan 1999 12:41:25 -0500
[EMAIL PROTECTED] writes:
> > 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.
however, it's also GPL'd, so regardless of what license they redistribute
it under tommorow, you still can do everything the GPL allows with your
current copy, including demanding source.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre5ac1 i586 | at public servers
And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 11 Jan 1999 12:30:30 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >
> >one of the goals is to make the simple case simple. for a plain
> >non-networked, single user, home machine, the default opStore config could
> >just point to /etc/opStore/<app>.conf priority 5, then
> >~/.opStore/<app>.conf priority 10. this would require no maintanence on
> >the part of the sysadmin (== user here), and give the same behavior as is
> >common now - it wouldn't be a full service, but rather just another library
> >the app uses.
> >
> >with more complex systems, the system administrator would have the ability
> >to specify a more complex configuration. in that case, it can safely be
> >assumed that there would already be a system administrator capable of
> >dealing with more complex setups.
>
> I think additional goals here should be to take advantage of existing
> network data stores (LDAP, etc.) and to encourage consolidation of
> such data into something that can be maintained consistently. Personally
> I'd like to see postgresql as the back-end storage since it already
> supports transactions and has java, odbc, perl DBI, and some other
> client interfaces and is included in the RedHat distribution.
agreed. postresql does sound like a good choice for one of the initial
modules.
> >> Yes, it really is impossible to do it perfectly. However, even
> >> with config files unix is pretty sloppy already with the only
> >> transactioning mechanism being the number of people who know the
> >> root password. You might be able to make it 'good enough'.
> >
> >hrm... i think you're probably right here. we can play some tricks with
> >file locking and rename(), but for resources spread accross multiple
> >sources (in particular ones w/out true transaction support, which will
> >probably be most of 'em) there will always be a danger. having an opStore
> >lock on each resource *should* mean that 2 opStore apps won't corrupt each
> >other, though that won't help with other entities (ie, someone with vi)
> >from interfering. the best we can do in that case is make things no more
> >dangerous than they already are.
>
> You can do it right if you provide a data store that supports transactions
> and one or more interfaces to do updates (perl DBI would be good and
> easily adaptable to many SQL servers). Non-transactioning data stores
> and combining data from more than one source could still be supported
> but at the user's risk.
>
> Les Mikesell
> [EMAIL PROTECTED]
however, here's the problem. values can come in from multiple locations.
say any number of these values can be changed. one or more of these
locations do not support guaranteed record locking or transactions. say
you make a set of changes that in addition to any transaction capable
locations, also covers values originating from multiple non-capable
locations. how do you guarantee consistency accross the entire
configuration?
the more i think about it, the more i think that there just won't be a sane
way to guarantee consistensy on all sources, esp when multiple ones don't
support guaranteeing it. first off, when we write out changes, we should
only write out the delta. second, i suggest that we only write out the
changes to a single, configurable location. for the regular user, 98% of
the time this will just be ~/.opStore/<app>.conf for the admin, design a
tool capable of groking where each item comes from, and can update the
values on each one individually. by providing this tool, the work of
guaranteeing consistency is largly offloaded to the admin. it would be a
lot nicer to do it automagically, but i don't see any way that we can do it
without faking parts of it and hoping nothing blows up.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre5ac1 i586 | at public servers
And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Brett W. McCoy)
Subject: Re: Help about wish and tcl commands !
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Jan 1999 22:42:57 GMT
On Mon, 11 Jan 1999 22:21:21 +0000, YANG Tong <[EMAIL PROTECTED]> wrote:
>Just a question about tcl "langage" :
>How can I put a bitmap (and I hope a pixmap) in a button ?
>I explain with a simple example (on the sreen) :
>
>/root# wish
>% button .b1 -bitmap ??????
Try this: (replace image.gif with the file and path you need)
% set buttonImage [ image create photo -file image.gif ]
% button .b1 -image $buttonImage
% pack .b1
Experiment around with this. There are height and width parameters you
can use also, among others.
--
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: [EMAIL PROTECTED] (bill davidsen)
Subject: superformat and 2.2.0pre6
Date: 11 Jan 1999 23:11:57 GMT
Note to kernel developers: superformat won't format 1680k floppies under
2.2.0pre6, will if I boot the 2.1.132 kernel on the same hardware. Tried
twice (each kernel) on the same floppies.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Too soon we grow old, and too late we grow smart" -Arthur Godfrey
------------------------------
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:11:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Roberto Alsina writes:
> > Not "reportedly".You can see a scan of the legal papers at www.troll.no.
> > Dammit, I signed some of those papers myself.
>
> I wrote 'reportedly' to make it clear that I have only indirect knowledge
> of the matter. While I wish KDE and Troll Tech well, I do not follow their
> adventures particularly closely.
Ok, sorry.
> > No, not GPL. A really free license.
>
> A GPL compatible license? Good.
BSD like license.
> > If that happens, the code will be owned by the KDE Free Qt foundation, of
> > which I am member, and which is bound by its statutes to immediately
> > release the code under a BSD-like license.
>
> And this foundation is properly chartered and incorporated?
Of course. Signing legal papers on behalf of a not incorporated
foundation is probably illegal.
> Good. This might actually work, if you can pry the rights away from Troll
> Tech's successors in a timely fashion.
I was told that was one of the things lawyers had to think a lot about.
Basically the right to rerelease has already been granted. So, the
successors cant take it away, just like they cant take away my own Qt copy.
> > Yes, that too. And not "it looks", but it will.
>
> It certainly looks likely, but we can't be certain until it happens.
Oh, come on :-)
You can say the same thing about the FSF not going proprietary next week.
> > I found your message a bit insulting, and entirely misinformed.
>
> Don't be so hostile.
Ok, sorry.
> My point was that a work still in copyright *always*
> has an owner, and that the copyright law give that owner the right to
> license the work however it sees fit.
Unless they have signed a contract where they commit not to change the
license. For example, the foundation has to vote to allow Troll Tech
a switch of license for Qt 2.0.
Think of it as sort of a license escrow.
> In the unlikely event that Troll
> Tech went bust and your foundation acquired the code and then violated its
> charter by selling proprietary licenses, those licenses might very well be
> be considered valid by the courts, even if the board members were all
> hauled off to jail for fraud.
And you expect me to go to jail to make whoever buys Troll Tech richer?
Somehow I dont see that happening :-)
--
Roberto Alsina (KDE developer, MFCH)
‰
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: 2.2.0pre6 booting errors
Date: 12 Jan 1999 00:00:58 GMT
In article <[EMAIL PROTECTED]>,
Frank Hale <[EMAIL PROTECTED]> wrote:
| I downloaded the 2.1.132 and patched it to 2.2.0pre6 meaning I applied
| every patch from 1 - 6. Is this my problem? Also I tried to apply the
| Alan Cox 2.2.0pre6 patch on my 2.2.0pre6 system and it wouldn't go. How
| do you get that patch to work?
|
| Should I say screw the patches and download the full source?
I couldn't upgrade with patches, I think something is missing or ??? The
full 2.2.0p6 works fine. I actually cheated and pulled the full source
on a machine with T3+100Mbit connections, then built my own megapatch
2.1.132=>2.2.0pre6 and downloaded that home over the weekend. Haven't
pulled the AC patch yet, I will when I continue testing, probably this
weekend again.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Too soon we grow old, and too late we grow smart" -Arthur Godfrey
------------------------------
** 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
******************************
