Re: Database port
Henry Keultjes wrote:
>
> Mike:
>
> Q: Are you proposing using a database engine as a file system?
>
> That's probably a good a way to describe it. However, remember that the
> criteria is that both Linux and MD applications have to work. I believe
> that this is plowing virgin ground.
>
> Q: Can you name this database?
>
> Pick (Raining Data) is the original and the rest are clones. What
> exactly MD-Linux will use will be part of a confidentiality agreement.
>
Why would that be confidential? Wouldn't the database company want to
have the publicity of being the backend in your product?
> Q: Are you planning on selling "enterprise" software to the typical
> physician with one or two doctors?
>
> Applications will be sold by commercial enterprises. MD-Linux does the
> R&D to develop the product that those commercial enterprises can use.
>
OK, I think I'm getting the concept a little better.
> Q: The user should like your product so much, and find it so useful that
> they wouldn't want to switch.
>
> My sentiments exactly
>
My point is: I hope you see standards as useful instead of a
hinderance. This may make your product acceptable where it might not
have been in a larger setting. You cannot possibly make a product that
will fit into everyone's problem and fix it. What if they want to use
their current email server, or email client, you should make allowances
for this type of situation. It cannot do anything but help the
companies sell the product.
> Q: Linux is known for taking old machines and making them useful. You
> could at least make the client available on other platforms such as x86
> m68k, or even open source, and be helpful to developers that want to
> port that code. Hopefully, it wouldn't have endian problems.
>
> Looking at this from a commercial perspective, given the right "offer"
> prospects always exceed the capability to supply. Therefore support
> issues and profit objectives dictate a single platform. MD-Linux does
> not have to do those ports to prove the viability of the concept.
>
Then open sourcing the client shouldn't be a problem. Depending on
where most of the processing will be done this can be made easier. For
instance, if you have most of the business dicesions processed on the
server, you can have a thinner client, and smaller code base that needs
to be open source.
> Q: Maintaining a debian system is much easier than redhat, and that is
> why
> you would be thankful.
>
> Yes I know that Debian is easier and yes I will be thankful . . . but
> that requires that I get the "port" done.
> .
The there may be a problem if you plan to diverge from the way debian
does things now. At least if you plan to keep in sync with it. If not,
then you need to be able to divote the resources to maintain a
distribution. This is why I'm trying to keep your product as an "addon"
or "value add" to debian.
> Q: You already state that the DB engine is ported to linux, so it should
> work on debian without modification.
>
> No it will not, specifically because the existing ports are either Intel
> or AIX. So either the OS is not right or the chip is not right. I
> mentioned earlier that I have written an article "Perfect Pair - PowerPC
> and Linux" that is supposed to go in the May issue of Linux Journal.
> Very few people have this "narrow offering" approach that I have.
> However, this approach has always worked well for me. Find a niche and
> be better than anyone else. Finding a profitable niche in Intel, even
> if it were possible, would not interest me. If you look at how Jack
> Welch runs GE, his approach has been the same, only on a much much
> bigger scale. However, I believe that a commercial company build on the
> MD-Linux foundation can become a $10B company.
>
So, you plan on selling the hardware, is that right? I don't know about
you, but I've known quite a few doctors that pinch pennies. By only
supporting powerpc, you could be limiting your market, and thereby
hindering the adoption of md-linux by your supervisors or dicesion
makers in your organization. I can also see that having a wider list of
hardware will make more cost in support, and maybe you don't want a
doctor to go out and buy the latest consumer compaq and call support and
complain that he can't get it to work.
It can be a headache for support, but it can also be a revenue stream
also. I can see both sides, but maybe this will show you another
perspective.
> Q: What exactly do you want the debian geeks to help you with?
>
> First I have to make them believers in the concept. Than, together with
> the MD geeks they need to help me define the work and the hurdles.
>
Looks like we're headed there. Though, if you want to leverage the
power of the debian system, your product should be able to integrate
into the current system. In other words, don't change the location of
files, don't change the package manager. Do make your system a set of
packages, etc. This can only help you.
> Q: How will you be participating?
>
> I am the idea man and the project leader who has to do the convincing
> that this approach is right. I will also be responsible for day-to-day
> operations of the (non-profit) corporation and I will have to raise the
> money to be able to pay those people.
>
> Q: What, besides more users from your products will we receive out of
> this participation?
>
> Cash and satisfaction. Like Red Hat offered stock to a bunch of Linux
> geeks, so would the commercial companies building on this be inclined to
> treat the geeks who worked on this right. However, that is not a
> guarantee so I look at this as pay as you go. If stock happens it will
> be a bonus.
>
OK, looks interesting.
> Q: What parts would be closed and open?
>
> MD-Linux itself would be totally open. However, the "rejuvenator" tools
> would remain proprietary so that the non-profit has a means of
> sustaining itself, similar to the way Battelle sustains itself. Note
> that none of these tools will be needed to write applications that work
> in MD-Linux.
>
We'll get more specific later, but this should be defined before any
works starts.
> Q: What do you want to change on debian?
>
> It will probably work something like that. However, that whole system
> is now running a "database file system" so whatever changes need to be
> made to accommodate those needs will have to be incorporated.
>
Here is where I need more information from you. Please let me know how
deep your understanding of file system goes. At this moment, I'll be a
little vague...
As long as the file system supports:
* standard unix user,group,other type permissions
* File hierarchy, EX: /a/b/c/d etc...
* long filenames
* standard unix tools, such as chown, chgrp, chmod, etc work on them.
...you should be all set.
If you plan on using ACLs you would want to talk to the other projects
that are implementing ACL support in linux before starting.
> Q: Why couldn't the system be configured to use xdm for graphical
> login, and automatically startup your front end?
>
> I am not sure I would want a graphical login. A scripts login is much
> more convenient because it can be customized so much easier. Remember,
> we are trying to build a better mousetrap for the user. Each user has
> issues with users and security that work oh so well in a script. One of
> my favorite saying has been that the alphabet is the greatest invention
> of all times. It allows us to express our wants, needs, desires etc in
> an infinite number of ways with 26 characters. I like the graphics
> "face" mostly for its ergonomic features, the ability for subtle shading
> and boxing and scrolling, those things that make the graphics screen so
> much easier than a green screen. Beyond that, however, the mouse is a
> lousy substitute for a keyboard when it comes to productivity. That may
> change with voice recognition, perhaps, if they ever solve the issue of
> making that work in the typical cubicle/cattle farm.
>
I'm all for the remote control conveniences of the command line, but
don't forget what comes with the GUI. The feeling of working with
something "new" and 21st century. This type of thing will leave a
lasting impact on the client. Keyboard shortcuts can be a happy
substitute for keyboard only users.
On another note, without graphics, it may be even easier to integrate
with the current debian system. You just put a reference in
/etc/profile to the client program and you're set. So, once the user is
logged in, you system comes up. You could even customize the login
prompt.
> Q: How does the current debian setup hinder your goal?
>
> The current Debian set-up is a stepping stone, rather than a hindrance.
>
Let's change that from stone on a path through water to foundation for
your building.
> Q: Will this be the open source part? How does this fit into the above?
>
> I hope that I have explained this adequately already because I don't
> understand your exact question, relative to the place where it was
> posed.
> Please expand on your question if I did not answer it.
I really don't know if the client will be open source. It looks like
the database core won't, maybe the database tools should be open source
though.
>
> Q: Has anyone else responded to your message?
>
> Yes, a few have. Nothing exciting yet.
>
Maybe this conversation will help change that...
> Q: Maybe I can help you in some way.
>
> That would be great. It would help if I knew more about what you are
> running and for what kind of a company/organization so that I can
> explain things in terms of your perspective.
>
I am a system administrator for a medium sized mail shop in california.
I have experience with dos starting on 3.3, then
win3.1,win95,winNT4,linux,win98,macOS in that order. I have been using
linux for over two years now, and strive to base all of my servers on
it. I have learned MacOS by necisity to support it here at work. That
is where my powerpc work comes in, and I have been running linux on mac
for a couple months now.
As you can see, most of my experience is with computer technology.
> Q: advantage of using KDE Did your message get cut off?
>
> No, just forget wiping that out. I was going to get into that issue. I
> have a strong preference for KDE because Trolltech also has an embedded
> version of X with a much smaller footprint. However, it may be possible
> to write the front in XUL
>
> http://www.zdnet.com/eweek/stories/general/0,11011,2682331,00.html
>
> and if that indeed can be done, than the issue of KDE vs Gnome becomes
> moot so why should I reduce the response by signaling my preferences to
> people with strong feelings, one way or the other?
>
OK, I'll leave it at that. I haven't made a preference because I'm just
starting to use linux as a desktop.
> Q: Endian - MD databases work better with the Linux endian than the
> Intel edian.
>
Let's keep this specific. That would be powerpc endian, and you can get
the same endian on sparc and m68k.
> Again, I sure appreciate your comments. I hope to hear more from you.
>
As do I. I hope this will end with all parties benefiting.
> Mike Fedyk wrote:
> > Henry Keultjes wrote:
> >
> > Mike:
> >
> > 1. There is no win32 front end. Current front-ends are green screen.
> >
> > 2. What is the standard Linux file system? You will have to admit that
> > there are many choices, thus no standard. MD-Linux will take one of
> > those and make it more capable so that it does allow the application
> > from the Linux side and the existing MD applications to run as a single
> > set of applications.
>
> linux supports several different file systems, and even more recently,
> but most will agree that ext2 is the "standard" file system at the
> moment, and has been for years.
>
> Are you proposing using a database engine as a file system?
>
> >
> > 3. "Porting" will be native.
> >
>
> Glad to hear it.
>
> > 4. You name a type of business or type of organization and there is
> > most likely an existing application. Each one of those will have
> > $millions of work and experience in it and "rejuvenating" those
> > applications is much easier than rewriting them in Linux. However, all
> > those applications are already available to Linux because the same
> > database that we will use to devise MD-Linux has already been ported to
> > Linux and it is a super product. It is just that I want to take it a
> > step further because it is a step further. Progress is inevitable.
> >
>
> Can you name this database?
>
> > 5. In the enterprise application arena where I have been for the last
> > twenty two years, the requirements are a lot more stringent than "just
> > want the computer to do work". We are talking about applications like
> > those that SAP, Baan, JD Edwards and Oracle Financials provide.
> >
>
> Are you planning on selling "enterprise" software to the typical
> physician with one or two doctors?
>
> > 6. I did not want to get into specific of the GUI issue. However, the
> > option to use the command line will be an essential part of all the
> > applications.
> >
>
> Sounds good.
>
> > 7. You suggest that we continue with the Linux and Unix concepts. The
> > answer is most likely but we may find that there are places where we
> > should divert. That is progress. Many MD people hate what I am
> > proposing because it breaks the chains to the portability of
> > applications that has been adhered to for 35 years. Look at what Linus
> > did. He broke with the chains of the past. Better that we do the
> > breaking within Linux than letting BG3 break us.
> >
>
> The point I wanted to make was "don't reinvent the wheel". Case in
> point; using cron. Most people administrating a unix are familiar with
> cron, so you don't need to create another scheduler. Case in point;
> smtp, pop3 or imap. These are very capable email tools, and should
> probably be used in your system.
>
> In other words, don't reimplement standard tools just to lock in the
> users to your product. The user should like your product so much, and
> find it so useful that they wouldn't want to switch.
>
> > 8. Yes they will have existing X86 machines in their office and those
> > machines were obsolete before they arrived. They have been replacing
> > machines at a very rapid pitch. What's wrong with one more cycle and
> > than slowing it down. That's what PPC is all about, getting away from
> > the cat chasing its tail!
> >
>
> Linux is known for taking old machines and making them useful. You
> could at least make the client available on other platforms such as x86
> m68k, or even open source, and be helpful to developers that want to
> port that code. Hopefully, it wouldn't have endian problems.
>
> > 9. I can't ever be thankful for choosing Debian unless we get the
> > project running on DEbian. It's a Catch 22!
> >
>
> Maintaining a debian system is much easier than redhat, and that is why
> you would be thankful. You already state that the DB engine is ported
> to linux, so it should work on debian without modification.
>
> > 10. It did not seem to make sense to ask more specific questions. What
> > I am looking for is some Debian geeks that are willing to make this
> > thing work. If then they have questions those geeks can pose more
> > intelligent questions than I can.
> >
>
> What exactly do you want the debian geeks to help you with? How will
> you be participating? What, besides more users from your products will
> we receive out of this participation?
>
> > 11. We will use proprietary pieces to make an Open Source MD-Linux
> > product that meets the requirement of the Debian license - or we will
> > not do it at all.
> >
>
> What parts would be closed and open?
>
> > 12. Can't be an add-on package because that would not be progress. As
> > I stated above, Linux ports for the same database exist already and
> > those applications work fine for most people. The problem is that they
> > rely on win32 front-ends to make them salable. I want applications that
> > are 100% pure Linux - no BG3 stuff.
> >
>
> What do you want to change on debian? Why couldn't the system be
> configured to use xdm for graphical login, and automatically startup
> your front end?
>
> How does the current debian setup hinder your goal?
>
> > 13. MD-Linux Scientific is for all practical purposes an R&D
> > organization. People that will take MD-Linux and sell their
> > applications on top of it can pick a more suitable name.
> >
>
> Will this be the open source part? How does this fit into the above?
>
> > 14. If you are not part of the Debian team, what are you part of. How
> > did you get this post?
> >
>
> I'm just your typical system administrator. I got your message because
> you sent it to the powerpc list. I am not representing debian in any
> way, but I am a debian user.
>
> Has anyone else responded to your message?
>
> > 15. Your comments are appreciated because they allow me to hone down to
> > the essentials. Please keep them coming.
> >
> > Henry
> >
>
> Maybe I can help you in some way.
>
> > , advantage of using KDE
>
> Did your message get cut off?
Reply to: