Linux-Advocacy Digest #682, Volume #27           Fri, 14 Jul 00 18:13:04 EDT

Contents:
  Re: Oracle on Linux Justification (rich)
  Re: Just curious, how do I do this in Windows? (Aaron Ginn)
  Re: Linsux as a desktop platform (ZnU)
  Re: Are Linux people illiterate? (Nathaniel Jay Lee)
  Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
  Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
  Re: Tinman digest, volume 2451740 (Tholen) (tinman)
  Re: Linsux as a desktop platform (ZnU)

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

From: [EMAIL PROTECTED] (rich)
Subject: Re: Oracle on Linux Justification
Date: 14 Jul 2000 21:34:34 GMT
Reply-To: [EMAIL PROTECTED]

Also schrieb [EMAIL PROTECTED]:
>I'm looking for case studies to justify to our management why we should
>go with Oracle on Linux.  We have the Oracle part nailed down, they
>just aren't so sure about Linux.  

There's an egroups group out there called oracle-on-linux. You might
join it and get some good responses from them.

-- 
Catch the cluetrain.  http://www.cluetrain.com
ALL programs are poems, it's just that not all programmers are poets.
    -- Jonathan Guthrie in the scary.devil.monastery

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

From: Aaron Ginn <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Just curious, how do I do this in Windows?
Date: 14 Jul 2000 14:06:10 -0700

"Drestin Black" <[EMAIL PROTECTED]> writes:

> "Mike Marion" <[EMAIL PROTECTED]> wrote in message

> >
> > From the experience I've had with VB, it sucked.  Perl is much more
> > powerful IMO (and I can use perl on almost every platform out there).

> More powerful? Perhaps. But is it as easy to use as VB? I use VB cause I can
> crank out code in a hurry and with very little debugging and the tools and
> 3rd party support is fantastic.


I'm no fan of VB by any stretch of the imagination, but I will agree
with Drestin in that Perl can be pretty bad in terms of readability
and maintainance, which is at least as important as the power of the
language in question.

I've recently begun using Python for projects that I previously would
have used Perl, and I have to say that it's been a breath of fresh
air!  Python's available on all your Windows varieties as well.  If
you know Tcl and/or Perl, the learning curve for Python is
ridiculously easy.  I wrote a fully-functional FileBrowser GUI in
about four hours, including learning the syntax of the language, and
I'm no expert programmer.

Having said that, Perl is an amazingly powerful tool if used in the
correct circumstances, particularly, as a text processing tool in
place of the traditional awk/sed/grep family.  Perl 3rd-party support
is second to none as well with CPAN.

Aaron

-- 
Aaron J. Ginn                     Motorola SPS
Phone: (480) 814-4463             SemiCustom Solutions
Fax:   (480) 814-4058             1300 N. Alma School Rd.
mailto:[EMAIL PROTECTED]    Chandler, AZ 85226

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

From: ZnU <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Fri, 14 Jul 2000 21:40:15 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
wrote:

> Said ZnU in comp.os.linux.advocacy; 
> >In article <[EMAIL PROTECTED]>, 
> >[EMAIL PROTECTED] 
> >> What is bad is forgetting that the user is supposed to be in 
> >> control of the apps, not the other way around.
> >
> >The user can't control CPU scheduling manually. That isn't an 
> >option. The choice is either to let the apps do (CMT) it or let the 
> >OS do it (PMT), and the OS is much more qualified.
> 
> Not the scheduling, no, but the weighting, preference, or priority of 
> scheduling.  My theory is that with CMT, the market handles whether 
> the end result is valid and useful,

No. First, as has been said many times, it is impossible to make a CMT 
app that behaves as it should. Moreover, in most cases it is simply 
insane to thing a user can just abandon a particular app and switch to 
another.

> and with PMT, it was the engineer 
> who insists CMT is 'stupid' and ridicules people who question that 
> tenet.

Obviously it is the engineer who decides which system is superior. The 
end user isn't qualified.

>    [...]
> >> The cost of learning an interface cannot be considered a component 
> >> of its *use*, merely of its adoption. User's don't have to 
> >> "consciously remember how things work" if they are going to use 
> >> the software.
> >
> >They do if they have to constantly switch between applications that 
> >work in totally different ways.
> 
> No, only if they are learning new apps.  Switching between already 
> learned sets of control features is automatic and, if I might be so 
> bold, intuitive.  Again, that which speeds the new user up all too 
> easily slows the experienced user down.  My brother always likes 
> bringing up the QWERTY keyboard whenever the opportunity presents 
> itself.  The principle is the same, even though the keyboard's 
> physical (as opposed to entirely mental, since all GUIs use the same 
> keyboard and mouse) implementation makes it an inappropriate analogy.

Even if I accept that "sets of control features" is just as fast as 
using a single set (which I don't), the fact still remains that in the 
vast majority of cases non-standard UIs offer no advantages at all.

[snip]

> Yes, it is.  The QWERTY keyboard is still the overwhelming standard. 
> Most will readily point out that alternatives are faster, and that it 
> was even specifically designed to slow down the action.  But what 
> isn't often pointed out is that the edge that super-typists have with 
> their custom keyboards do not correlate to any specific improvements 
> (other than the obvious 'the frequent letters should be the home row' 
> guideline).  The speed improvements found if an effort to change from 
> QWERTY to *any other standard*, such as the Dvorak layout, do not 
> outweigh the individual *or* the total cost of switching.  If they 
> did, we'd have bagged the QWERTY keyboard decades ago.

You seem to be arguing that users would be just as fast if they had to 
constantly switch between different keyboard layouts as they are now. I 
don't agree.

[snip]
 
> It doesn't matter how long it takes for something to become 
> intuitive. Once it is intuitive, it is the most correct and efficient 
> way of doing it, and even that something might in the abstract be 
> better or even more efficient is not sufficient reason to change it.

You're arguing my case for me here.

[snip]
 
> Innovation occurs on user's desktops.  That is its rightful home.  
> Give me three ways to do it, if I want them, and then I'll be happy 
> to tell you which one is best.

This should be done in usability tests before a product ships. You 
should never ship a system with multiple inconsistent interfaces.

[snip]

> The scheduler is not an island unto itself.  When discussing its 
> function, I'm not referring merely to the one block of code which 
> handles the chore of switching from one app to another a million 
> times a second.  I'm discussing its implementation in the system.  
> The apps have to at least know if they're PMT or CMT, don't they?

Apps in a PMT system are written as if they are the only apps on the 
system. The developer doesn't need to worry about any multitasking 
issues. Apps in a CMT system need significant amounts of extra logic to 
behave properly. Of course this means higher development cost, long time 
to market, more bugs, and possibly significant performance penalties.

> (Aside from the fact that apps can't "know" anything.) I would 
> assume, in fact, that the difference might be crucial in the 
> architecture and development of the application, or at least it 
> should be.  How the scheduler works inside is irrelevant; the issue 
> of PMT or CMT is outside that box.

I have no idea what that means.

> >> In CMT, the user is in charge, not the apps.  If the app I bring 
> >> to the foreground doesn't yield sufficiently and stops my 
> >> download, then I will get rid of that app and get one that works.
> >
> >I don't see how that puts the user in charge. You're not choosing 
> >where the CPU time is going, the app is. If an app yields to CPU too 
> >much, it takes a performance hit.
> 
> And its a slow app, and bombs in the market.
> 
> >If it doesn't yield it enough, other apps take a performance hit.
> 
> And is a problematic app, and bombs in the market.

Every app would bomb then. There is no "right" amount to yield the CPU.

> > Any given app has no idea how much it should be 
> >yielding, because it has no idea what else is running on the system. 
> 
> But the user does, and with a different, though not necessarily as 
> important, perspective than the OS.

The user might know, but its the computer that has to allocate CPU time. 
Unless you know of users with sub-nanosecond reflexes? No? Then the 
computer will do a better job.

> >There's no way to write an app that is "friendly" under all 
> >conditions in a CMT system.
> 
> Yes, I'm sure there is, you just haven't figured it out, yet.  ;-)

No, there isn't. Even if there theoretically was, it wouldn't be viable 
to implement it. Even if you managed to get every app to implement it, 
it would only be as good as PMT, not better.

> Innovation comes from diversity, not taking only one out from a 
> problem because any alternative is "stupid" and not worth 
> considering.

CMT has been considered and rejected.
 
> >Again, putting the user in charge is not an option here. The closest 
> >you could come would be a PMT OS that provided a very easy interface 
> >for setting priorities. But I suspect a good scheduling algorithm 
> >would be better at it than any user could be in the vast majority of 
> >cases.
> 
> And it is that suspicion, not the fact that PMT is more robust, less 
> problematic, and better suited for a modern computer.

That doesn't seem to be a complete sentence.

> I encourage all engineers to *fight* the people telling you that 
> users want to remain ignorant and out of control.  They may be right, 
> they may be mistaken. But then, considering they can make more money 
> off of clueless users than ones that understand "priority", even if 
> they don't understand scheduling algorithms, it is also worth 
> considering that they're just plain lying.  And lying loudly and 
> often (and sometimes subtly) enough to even convince the users 
> themselves!

You assume decisions about issues like that are just arbitrary. They're 
not. They're based on actual research.

> I have been teaching people how to use PCs for more than a decade, 
> easily, and I have yet to have one remark to me after learning a new 
> feature "Wow, that's *way* more control and efficiency than I really 
> want to have."  Not to say they haven't ever mentioned they'd like 
> the interface to be simpler.  But they just meant "easier to learn", 
> not "less powerful or capable".  And everybody knows that as soon as 
> a more complex interface becomes familiar to you, you scoff at people 
> who still use the "toy GUI" simple version, in most cases.

Programs that allow the user to easily change task priority exist for 
virtually every PMT OS. Almost nobody uses them. Draw your own 
conclusions.

>    [...]
> >I'm not sure what you mean by "mimic a CMT system." You mean it will 
> >become unresponsive under load?
> 
> You're going to deny again that CMT puts the user in charge, I know 
> it. I also suspect I know why it is, but I've had enough of pointing 
> out others' conceptual glitches for the next few days.  So just 
> assume you don't know what I mean and leave it at that.  There's no 
> need for veiled ridicule.  I meant one which doesn't assume an 
> algorithm is the answer to everything.

I don't know what you mean. How does CMT put the user in control? As 
nearly as I can tell, you say its by letting the user get rid of apps 
that don't multitask correctly. Why is this better than a PMT system in 
which all apps multitask correctly with no work on the part of the app 
developer or the user?

Think about what you're saying. Would you rather have a car that can be 
replaced with a different model when if it breaks down, or would you 
rather have one that never breaks down?

>    [...more, but its getting a tad repetitive...]

-- 
The number of UNIX installations has grown to 10, with more expected.
    -- The Unix Programmer's Manual, 2nd Edition, June 1972

ZnU <[EMAIL PROTECTED]> | <http://znu.dhs.org>

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

From: Nathaniel Jay Lee <[EMAIL PROTECTED]>
Subject: Re: Are Linux people illiterate?
Date: Fri, 14 Jul 2000 16:37:38 -0500

[EMAIL PROTECTED] wrote:
> 
> Ahh.. yet another linux user skirting the REAL issue by attacking my
> spelling.. Look PimpleDick..my post is not documentation therefore is
> not subject to scrutiny.  The Linux Documentation Project on the other
> hand is representative of the operating system itself.  THAT is the
> issue, not my spelling.  If Document I cited is representative of the
> OS, then whoooo whoooo....no wonder it's so lame.
> 
> Phhht.
> 

I'm just curious about something here.  Is it worse to be a PimpleDick,
or a DickPimple?

Seriously though, ease up.  Someone volunteers to write something and
then asks that any typos be reported so he/she can clear them up, do you
really expect it to be perfect.  This isn't a paid professional, it's a
volunteer that probably doesn't even work as a
writer/editor/proof-reader.  Your assertion that mis-spellings and bad
gramar in a voluntarily written document (but not in your voluntarily
written post) is a reflection of retardation and stupidity is in fact a
good indication of problems in your mentallity.  I know how to spell, I
know gramar (fairly well), but when writing something voluntarily I
rarely proof-read as I go, and hardly ever look it over afterwards. 
Especially if I know there are hundreds of other people out there that
will be kind enough to point to any mistakes (and I ask them to report
the mistakes to me), it seems pointless for me to edit/proof something. 
After all, the thousands of eyes in the community at large is far better
than my two.  Isn't this why Linux has happened at all?  Scrutiny by the
many leads to larger imrovements than scrutiny by the few.  The scrutiny
discussed, the problems fixed, and onward and upward we go.

-- 
[EMAIL PROTECTED]
Nathaniel Jay Lee

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

From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Fri, 14 Jul 2000 17:43:21 -0400
Reply-To: [EMAIL PROTECTED]

Said Peter Seebach in comp.os.linux.advocacy; 
>In article <[EMAIL PROTECTED]>,
>T. Max Devlin  <[EMAIL PROTECTED]> wrote:
>>I know what software costs to right, too, and I'm not even a developer.
>>It costs about 1/100, at best, of what most companies sell it for.  I
>>think Windows9x has been calculated to be selling at 800% or 2000%
>>profit margins, or something.
>
>It depends an awful lot on the software.  Windows has been sold to tens of
>millions of people, many of whom didn't want it or need it.  Niche market
>software often sells for a fixed 25% cut over what it costs to write.

Only for creative values of "what it costs to write it".

>1/100th is a ludicrous number; if it were anywhere near there, software
>companies would never go under.

Other than getting bought out or having their market disappear, I'm not
sure if very many have.  Not the large commercial ones.  One product
developer's trying to play the trade secret game die off all the time,
of course, but that's not the same thing.

I'm not sure if you're clear on how "profit" relates to "fixed" and
"variable" costs.  The trick with software is its all in the fixed
costs.  That's why they're really more of a services business model.
And service business models love to *pretend* that their costs are
variable, but they never are.  Software companies pretend to be
manufacturers, however, with the justification of "trade secret" raw
materials and "license" inventory metaphors.  Microsoft, I believe, even
championed the move to allow them to pretend for book-keeping purposes
that they are a manufacturer, and that almost *all* of their overhead
costs, which are fixed and unchanging regardless of the amount of
product sold, are now treated as if they were variable costs, and
amortized across the delivered goods.  This had tremendously profitable
tax ramifications.  Which ballooned up software companies real profit
even further.  A true profit margin on software is almost incalculably
close to infinity once you've sold millions upon millions of copies,
even if your company spent all that money and pretended it was a cost of
goods.  Only the initial development should get amortized, and that's
the cheap part.

I'm sure there must be *someone* who's got more specifics on this.  Is
Rex Ballard around here anywhere?  Maybe he can help.

--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
ELTRAX Technology Services Group 
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
   my employer, has to pay for them, subject to
    applicable licensing agreement]-


====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Fri, 14 Jul 2000 17:49:55 -0400
Reply-To: [EMAIL PROTECTED]

Said Mike Stump in comp.os.linux.advocacy; 
>In article <[EMAIL PROTECTED]>,
>T. Max Devlin  <[EMAIL PROTECTED]> wrote:
>>But you see, Les, that's because nobody could ever come up with the
>>exact same story without ever knowing about the prior art.
>
>You sir are not a physicist.  Sure they can, there is a non-zero
>probability that it would happen.

So?

>Physicists tell me there is a non-zero probability that I will vanish
>and reappear on the other side of the wall.  I believe them.  Am I a
>fool?

That depends on whether you think you're going to vanish and appear on
the other side, not on whether you believe them that there's a non-zero
probability of it.  You haven't specified whether, in the ignorance of
their contention, would you believe the probability to be larger than it
is, or zero.  Should I guess?

--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
ELTRAX Technology Services Group 
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
   my employer, has to pay for them, subject to
    applicable licensing agreement]-


====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: [EMAIL PROTECTED] (tinman)
Crossposted-To: 
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Tinman digest, volume 2451740 (Tholen)
Date: Fri, 14 Jul 2000 17:59:58 -0400

In article <HrDb5.32389$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:

> Ray Chason writes:
> 
> >> Here's today's Tinman digest:
> >>
> >> 1> Incorrect.
> >>
> >> Balderdash, given your failure to comprehend the evidence
> >> presented.
> >>
> >> 1> You're merely demonstrating your difficulty in presenting any
> >> 1> evidence.
> >>
> >> Incorrect, given that I presented it multiple times.
> >>
> >> 1> On the contrary, my answer was quite appropriate.
> >>
> >> Illogical, given that you didn't provide an answer, therefore one
> >> cannot assess whether it was appropriate or not.
> 
> > And this is on topic for any of the above groups because....
> 
> Ask Tinman.  I didn't choose the newsgroups.

If you mean me, I have to ask if you're having reading comprehension
problems again--I didn't start this thread, nor did I choose the
newgroups. ("

Serious, to everyone out there, if you don't enjoy this kind of thing,
killfile Tholen as author and subjects with "Tholen" in them (if you don't
enjoy this kind of thing, that's safe, since I don't think Dave's ever
said anything worth reading except for grins), and I will try to put that
string in the subject of all posts contained tholeny tholenisms and other
tholenesque trivialae (and encourage others to do so as well).

-- 
______
tinman

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

From: ZnU <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Fri, 14 Jul 2000 22:00:38 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
wrote:

> Said ZnU in comp.os.linux.advocacy; 
> >In article <[EMAIL PROTECTED]>, 
> >[EMAIL PROTECTED] 
>    [...]
> >> Then other than buggy applications, there's no benefit to PMT, 
> >> right?
> >
> >Wrong.
> 
> Couldn't you just say "you're mistaken"?  Or maybe skip it entirely 
> and merely address the point, as you do below?
> 
> >> Except its easier for the engineers, and doesn't work the way I 
> >> want when I *don't* have any idle time.  What happens in PMT if I 
> >> *don't* have idle time?
> >
> >That's where a PMT system really excels.
> >
> >CPU time is still dealt out according to task priority, and, as has 
> >been pointed out, user interface processes tend to accumulate 
> >priority because they don't do anything most of the time. And what 
> >you have to realize here is that we're working on such small time 
> >scales that even if you're typing away like mad, from the computer's 
> >point of view the time between keystrokes is so long that you're not 
> >doing anything most of the time. Why shouldn't it be using that time 
> >to get other things done?
> 
> It should, but the assumption that any set of algorithms is the same 
> thing as "smart" is what makes a lot of crap available in computers 
> today.  I recognize that process scheduling is a VERY low level 
> issue, which certainly doesn't seem appropriate to this kind of 
> double-checking, but obviously I'm not the only one who thinks so, as 
> the link that Ed sent me in email will show:
> 
> http://www.uk.research.att.com/~dmi/linux-srt/wm.html

This is just an easy interface for switching task priorities. Such 
things have been around forever, and have never gained much popularity.

> There's at least one engineer at AT&T who isn't blinded by 
> assumptions, and realizes that the value of a desktop computer, 
> regardless of *all* other considerations, is entirely based on the 
> user's ability to make it work the way he wants it to work.
> 
> Even PMT systems give a nod to what I've been talking about by 
> providing re-prioritization via nice or the NT task manager.  The 
> idea that this issue is dealt with by, again, an automatical 
> algorithm which uses a rule that user interface processes should 
> "tend to" accumulate priority because they don't do anything most of 
> the time is not enough to dissuade me of the notion that there is an 
> issue here.  Apparently these scheduling algorithms are deep magic, 
> as this is the closest I've ever seen to a cogent explanation of 
> their behavior for non-engineers.

They work well enough that the vast majority of users never see any need 
to obtain a program that lets them change task priorities.

> Your "forever between keystrokes" idea is also disconcerting.  
> Because it hints that the inverse is also true; while I'm sitting 
> their for the CPU to get something *which requires CPU processing* 
> done, the reason it is only at 30% utilization is because it is 
> wasting more than two thirds of the time not getting it done.  Please 
> let me know if this is not a valid assumption.

It's not something you should be seeing. Where do you see this behavior? 
On a PMT system running a CPU-bound task, utilization will be at 100%. I 
try to avoid Windows, so most of my experience is with Unix systems, but 
provided Microsoft hasn't totally screwed up, this should hold true 
there. Play around on a Linux system with a CPU monitor running.

> I am aware that CPU is not the only bottleneck.  I am also aware, 
> most specifically, that engineers who work with the technical details 
> of a system can be surprisingly blind to the way that system actually 
> behaves in the real world.  The situation seems similar, for 
> instance, to a discussion between a frame relay and a router guy, 
> with both sides being able to explicitly "prove" that its the other 
> guy who is the bottleneck, and not them.  And neither of them are 
> even aware, often, until I explain it, that when a "network" is at 
> 50% utilization, YOU CANNOT TELL if it is because you only needed 50% 
> of the bandwidth, or if it is because you could only get 50% of the 
> bandwidth. Because both are dealing only with their system, and not 
> with its interaction, end-to-end, with the human beings who 
> ultimately decide if something is efficient or if it works.

You seem to have some strange ideas about how such things are developed. 
There is _tons_ of real-world testing of such systems before they even 
hit the market.

> >Additionally, GUI PMT systems typically give priority bonuses to the 
> >foreground app. This means everything tends to stay nice and 
> >responsive.
> >
> >In a CMT system with no idle time, you end up with apps fighting 
> >over the CPU. A heavily loaded CMT system can literally take 
> >_minutes_ to respond to a user interface event as simple as 
> >registering a mouse click.
> 
> As can, at least a bad, PMT system.  I've had Unix boxes behave that 
> way, too, but I've no idea what in particular caused the issue.  Only 
> that rebooting fixed it.  ;-)

You've watched a Unix box take minutes to respond to user interaction? 
Are you sure something hadn't crashed?

-- 
The number of UNIX installations has grown to 10, with more expected.
    -- The Unix Programmer's Manual, 2nd Edition, June 1972

ZnU <[EMAIL PROTECTED]> | <http://znu.dhs.org>

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


** 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.advocacy) 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-Advocacy Digest
******************************

Reply via email to