Linux-Development-Sys Digest #231, Volume #6 Thu, 7 Jan 99 09:14:16 EST
Contents:
Re: Re: things I'd pay to have developed for Linux... (Adrian 'Dagurashibanipal' von
Bidder)
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (George MacDonald)
Re: WDM Emulator, anyone? (J�rgen Schmied)
Re: WDM Emulator, anyone? ("Andy Lutomirski")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Adrian 'Dagurashibanipal' von Bidder)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: Re: things I'd pay to have developed for Linux...
Date: Wed, 06 Jan 1999 20:13:38 GMT
On 2 Jan 1999 12:50:47 +0800, Ilya <[EMAIL PROTECTED]> wrote:
>LVM.
Sorry my ignorance - but what's that?
--
Greets from over there
Dagurashibanipal
EMail: [EMAIL PROTECTED]
Nothing travels faster than light.
With, of course, the exception of bad news. -- D. Adams
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Thu, 07 Jan 1999 04:24:44 GMT
In article <76ugf0$pb5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Tue, 05 Jan 1999 19:46:56 +0000, Walt <[EMAIL PROTECTED]>
> wrote:
> >> On 22 Nov 1998 23:03:23 GMT, Christopher B. Browne
<[EMAIL PROTECTED]>
> >> wrote:
> >> >In contrast, if you write code that uses Qt, you indeed *do* have to
> >> >negotiate licensing with Troll Tech or an assignee thereof
> >> >depending on your circumstances.
> >>
> >> So they might have to read a license agreement before playing around with
> >> the software. Big deal. If they don't want to deal with licensing
> >> issues, then they can just ignore Qt-devel and live in bliss.
They could but they won't, and there's the rub. Hopefully Troll Tech
will be able to create something similar to the CORBA models where you
can use the stuff, but if you want to be able to get QT support for your
commercially supported software, you'll pay the retainers. Troll Tech
could also make good money on training, certification, training
certification, and all the other functions required to generate a massive
support organization.
There is the risk of embrace/extend, just like with FreeBSD. It's a risk
that developers need to weigh when choosing a development platform.
Developers who extend are vulnerable to Open Source counter-standards, and
open-source developers are vulnerable to proprietary extensions.
> >> >It all really begs the important question:
> >> > Why do you think Red Hat software would consider it a good idea to
> >> > promote Troll Tech's programming tools?
Red Hat is promoting a number of commercial grade development tools. The
folks who like gcc, gdb, and emacs don't need the expense of GUI-based
script generators. The folks who like GUI-based drag-and-drop generators
won't hesitate to spend an extra $1,000/developer. The developer will
spend at least $2,000 learning how to effectively play with the GUI.
The guy who can read the BNF and understand the syntax, browse the HTML
hierarchy, and drag-n-drop the sample-code into usable script just gets
paid a lot more because he can deliver more product in less time. He usually
gets called in to create the stress-testing system anyway.
> >> >That really is the upshot of it all.
> >> Red Hat wouldn't be promoting Qt at all, certainly not any more than
> >> they promoted xv, Metro X, or Applixware.
>
> Note that none of [xv, Metro X, ApplixWare] represent, in their normal
> use, development tools. Qt does. Development tools, and the
> attribution of licensing thereon, is a fairly complex matter.
It's true. Again, it would probably be better for Qt to use a service
based model priced on a quality of service and percentage basis. If you're
a casual user and you can wait for help via e-mail, support is free, if
you need to be able to make a phone-call at 3:00 AM and get a problem solved
before 6:00 A.M., you're ready to pay a little extra.
> >> >If someone installs Red Hat Linux, plays with Qt,
> >> >and then decides that they
> >> >like it, they're going to have to pay Troll Tech
> >> >the >$1K in order to use it
> >> >for anything commercial.
> >>
> >> Again, big deal. So, if they don't want to pay Troll Tech, they can
> >> just ignore Qt-devel.
The big question is, what does Qt-devel get you, and when do you need it.
If you need to fork up $1000 "up front", it's a hard sell. If you whip up
a pilot project in a few weeks, and you are ready to roll it into limited
production, the support license is an easy sell. Iona Sells a lot of ORBIX
that way.
> >> >Please explain how this is beneficial to Red Hat Software,
> >> > when it is pretty
> >> >clear that they want to be involved in selling development and systems
> >> >integration services.
> >>
> >> It is beneficial in that some customers want Qt.
Remember, Red Hat is largely functioning as a support brokerage. People
buy/install Red Hat Linux, pay the $1500/year and make a call to someone
who calls a guru who is on retainer to answer calls. Red Hat has less than
100 employees, but it leverages that into a formidable array of consultants
and service providers.
> >QT is doing an open source version for 2.0. Look at the Kde home page
> >http://www.kde.org
>
> Which may satisfy some desires, and not others.
Sounds like most of the Open Systems and Open Source world. The main
advantage of Open Source is that you can mix-and-match to meet your
preferences. It's not difficult to run KDE and GNOME concerrently.
When X11 was going through it's "Window Manager Wars", Motif touted a
superior user interface, but it required massive amounts of RAM (back
when UNIX WorkStations had all of 8 meg. OpenLook was pretty, but not
quite as friendly, and the XNeWS X-Server made the SparcStation seem
much slower than other systems, but it needed much less RAM. TWM and
Athena widgets were downright ugly, but it was fast and you could run
it on a PC with 4 meg of RAM and a VGA display.
We're in about the same place with Gnome/KDE. Gnome has advantages in it's
CORBA interface in and that it can be interfaced to different platforms,
servers, languages, and operating systems. KDE has advantages in that
it can be quickly programmed for local C++ applications.
> >Qt is by far superior to the gnome development libs.
>
> An arguable claim; see <http://www.computers.iwz.com/e-zine/gtk.html>
> for the claim that GTk is quite good.
I think a big issue here is the toolkits being used. Looking at how to
write a dialogue box in C is intimidating. It reminds me of learning to
write to Widgets (Motif, Athena, OLIT). One of the key features of Motif
was UIL and later UIM. True purists would program in C, but we were learning,
even then, that it's often better to leave the business rules and "smarts"
in a server and make a client that "sets properties and invokes requests".
Looking at samples in the C++ bindings are much easier to use.
It's about like arguing about Java vs PYTHON vs TCL vs PERL, each has it's
place and all will be useful in that they will provide desirable functionality
at competitive prices (free use, $$ support).
> >Its WAY easier to write apps for.
>
> That doesn't parse particularly well. And is, at best, only true for a
> subset of situations, particularly those where the remainder of an
> applications is being written in C++. The last "library survey" I did
> indicated that there don't actually seem to be all that many widely used
> Linux applications written in C++.
He's got a point there :-).
> It is not evident that it is "way easier" to script up applications
> using Guile with Qt than it is to do so with GTk. Ditto for writing
> applications using C, or Objective C. Those are all situations for
> which "helper code" is available for GTk/GNOME whereby GNOME represents
> a preferable choice.
>
> --
> "By golly, I'm beginning to think Linux really *is* the best thing since
> sliced bread." (By Vance Petree, Virginia Power)
> [EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
>
--
Rex Ballard - Open Source Advocate, Internet Architect, MIS Director
http://www.open4success.com
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Thu, 07 Jan 1999 10:25:28 GMT
Christopher Browne wrote:
>
> On 05 Jan 1999 19:59:16 -0500, Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >Tristan Wibberley <[EMAIL PROTECTED]> writes:
> >> 2) then a couple of libraries for parsing flat text will be most
> >> appropriate no? Simplest to implement.
> >
> >agreed. this would be the first logical module to implement. i actually
> >have two of them in front of me now (profile code from the kerberos package
> >courtesy ted t'so, and libconfig from sunsite), one of which will probably
> >end up getting stuffed into the flat text module.
>
> Indeed.
>
> Note that there will likely be two pieces:
> a) Read the config, and
> b) Write the config.
>
> The UNIX "approach" has been for these to be distinctly separated.
> Which is, for things that are commonly referenced, but seldom changed, a
> Good Thing.
>
This model works well for CLI based users who know the unix "model".
However newer users and GUI based users have a learning curve to be
able to do the "write" part. Linux is becoming more of an application
platform and it would be nice to be able to minimize the required learning
for users who are task oriented. So one big question is, do you want to
support a newer GUI based model for "end users"
support the CLI model where users work with CLI and file tools
support both
I think doing both is the best approach.
> The "Windows Registry" approach is to have a unified database that puts
> a common "API" onto both aspects. This is nice for those things that
> get fiddled with all the time, but definitely makes *everything* in the
> registry as vulnerable as the weakest link in/to the Registry.
>
> >> The talk of complex network databases is far too premature at the moment
> >> - everyones always in such a rush to "innovate".
> >
> >you certainly have a point - there always seems to be a few people looking
> >to implement the latest, sexiest theoretical paradigms, the type who want
> >change for change's sake. however, sometimes change can be a good thing.
> >i think that the opStore project has the potential to definatelly be a good
> >thing.
>
> Everyone seems to want to come up with a "sexy" system that will
> represent the "be-all and end-all."
>
> "I'll come up with the perfect configuration system, and it will make
> me famous!"
>
Even the best config system would get you a wet rag response! Don't
count on getting famous out of it, you may help a lot of developers
and end users, but most likely they won't even give it a passing
thought. In fact if it's done well, it will be invisible.
> Unfortunately, actually implementing such a universal thing requires
> that a *lot* of programs be modified. Which requires more effort than
> anyone is likely to be willing to employ. It's *not* as simple as
> coming up with the "perfect config system."
>
More wisdom, any good solution will find a way to work with the
existing mechanism and extend it to be better. Also as you
say it should not take much effort on the part of a developer
otherwise they won't bother. I belive they should get something
out of using a config service and not the other way around.
> If, in contrast, a scheme is set up that is *useful enough* and
> *convenient enough* that it convinces *SOME* developers to adopt it,
> thereby reducing the number of completely independent configuration
> systems, that's GOOD ENOUGH.
>
> We don't need a "Unified Field Theory" of configuration systems; we need
> something that's Good Enough, and perhaps that's somewhat better than we
> have now.
>
I tend to think through a problem to come up with a nice clean conceptual
solution. This includes describing the *ultimate* desired solution. Then
I back up to see where things currently are, and figure out how to get
from here to there in a sequence of incremental, viable steps.
Each step incurring a small cost and yielding a benefit. I would like
to describe the problem, a nice long term solution and then
implement the core features, allowing for growth towards the end
result. I find this a useful technique as one gets to see what the
final solution is, and still manage to get valuable results
relatively quickly.
Of course it's always fasted just to write the code, but that assumes
the solution is known. I have done this a few times as well! In
fact once I wrote code as someone explained the problem! But that's
only a viable approach for one person! If many people are going
to work on the code, a clean well communicated design is
manditory. And of course the only way to get a clean design is
to have a really good understanding of the problem to be solved.
> >> I have to admit that the overriding values for local machines will be
> >> awkward to implement using the network fs scheme, but I hope to figure
> >> out a way of doing it that's quite easy to configure on the backend, and
> >> transparent on the client. Maybe write some scripts to help.
> >
> >simply check the values in /etc/foo.defs, ~/.foocfg, then in /etc/foo.cfg,
> >and have the last assigned value take precedence.
>
> Make sure it is documented clearly how this is to work, so that it is
> *CLEAR* which files will be evaluated in what order. The problem with
> (in contrast) X resource information is that the order of evaluation is
> *not* clear.
>
How so? I thought it was .Xdefaults, any xrdb'ed values, app-defaults,
$HOME/AppName, command line, internalized defaults
Well ther is XAPPRES and the localizing, ... Jesh that's at least 8
levels!!!
The directory locations should not be fixed, perhaps a default
list defined in a
/etc/app.conf
and maybe a switch kind of mechanism like that used in /etc/nsswitch.conf,
perhaps
/etc/appswitch.conf
I'm wondering if apps should be able to have their own switch.conf
files, or perhaps a line in the config file that specifies the
evaluation order and the types of sub-service to use.
This would allow setting system wide defaults for applications,
i.e. get from local files, then CORBA, then ACAP, ...
and then allow individual apps to change from that.
Well this is one way to seperate the data from the storage
mechanism. There are also other ways to do this.
> I would suggest documenting something on the order of five sets of
> places for defaults to come from, for application foo:
> 1) Site config: /etc/site/foo.conf (/etc/site might be NFS mounted
> from a central server; feel free to suggest a better location to stick
> this...)
> 2) Host-based config: /etc/foo.conf
> 3) $HOME/.foo.rc
> 4) $HOME/etc/foo.conf
> 5) $HOME/GNUStep/Library/Defaults/foo/Defaults
That's a good example of typical complexity, but the number of levels
should really be arbitrary, no?
/etc is typically for system related config files, app config files
are found all over the place /usr/lib/$app /home/$app /opt/$app
/usr/local/lib/$app ... I think this should be site configurable,
perhaps in the /etc/app.conf
Also I don't think using a "/etc" in the $HOME will work,
I commonly have my hown etc directory and I have seen many people
use the same. So a .something is preferable. I have also seen
.etc used in $HOME, but don't recall exactly where.
Finally my $HOME already has way to many .$app dirs, too many
for my tastes, hence one of the reasons for my desire to push
them down to ".userStore/Applications". I suppose this could also
be configured in /etc/app.conf. Perhaps with a
usersApplicationConfigRootDir=".userStore/Applications"
I would prefer to make the default at least one level under
$HOME. This is also already done elsewhere, see gnome, CDE
and other complex desktops. For "legacy" apps that have to be
in $HOME a symbolic link from their "app" dir to $HOME
would allow the library to have a cleaner model. The lib
could even create the link if it's missing.
>
> ... Note that I'm not sure what the precise ordering of these five
> *ought* to be; it might be something that ought to be configurable as an
> option in /etc/foo.conf ...
>
> --
> The real problem with the the year 2000 is that there are too many zero
> bits and that adversely affects the global bit density. -- Boyd Roberts
CORBA has a y30k problem!
--
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] (J�rgen Schmied)
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Thu, 07 Jan 1999 09:20:53 GMT
Reply-To: [EMAIL PROTECTED]
>Wow, you seem to care about the project, should I count you in? I got
>one other developer and an open invitation from the wine guys you use
>whatever I need from wine.
Thats in the wine licence: "do whatever you want with the code" ;-)
Since we do implementing the ntdll-api it would be useful to share
code. (What licence you plan to use?)
Till now there are only a few functions of the ntdll implemented.
Whats running are as example big parts of the interprocess
synchronisation/registry (the win32api stuff).
Ciao
Juergen
------------------------------
From: "Andy Lutomirski" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Wed, 6 Jan 1999 13:43:00 -0800
You do NOT need the NT system call interface. At all. This is
undocumented, and Mark Russinovich is the only person who uses it.
You will want a bogus service table so drivers can think they are modifying
it.
Andy
SONE Takeshi <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>I used to think of kernel-level NT emulator for linux.
>One part of it is PE EXE/DLL loader, which is rather trivial.
>The other part is NT system call handler.
>AFAIK, all NT API call become INT XXh kernel call (through NTDLL.DLL
>etc).
>They can be handled by a kernel module.
>This part, NT kernel emulator, naturally becomes the layer to help NT
>drivers to run.
>
>Inaki Castillo wrote:
>>
>> > Actually, WDM starts with the NT Driver model. We would probably start
>> > with the NT DKK.
>> >
>>
>> Have you any idea of what are you saying ?
>>
>> NT DDK is nothing by itself, you should reproduce all NT Kernel
>> components to do any simple piece of driver to work. That is all the
>> operating system. Win32 is in fact a layer above that.
>>
>> Maybe is better to move to NT.
>
>--
>SONE Takeshi $B$=$M(B
$B$?$1$7(B
>mailto:[EMAIL PROTECTED] Office Craftsman Arts
>http://www.cma.co.jp/~ts1/
------------------------------
** 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
******************************
