[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Round two mPlayer -- basic UNIX/Linux (and MacOS) approaches



Thanks for your reply.  It reminded me of  an old joke:

A man takes a balloon ride at a local country fair. A fierce wind
suddenly kicks up, causing the balloon to violently leave the fair and
carry its occupant out into the countryside. The man has no idea where
he is, so he goes down to five meters above ground and asks a passing
wanderer: "Excuse me, sir, can you tell me where I am?"

Eyeing the man in the balloon the passer-by says: "You are in a downed
red balloon, five meters above ground."

The balloon's unhappy resident replied, "You must be 
"How could you possible know that?" asked the passer-by. 
"Because your answer is technically correct but absolutely useless, and
the fact is I am still lost". 

"Then you must be in management", said the passer-by.
"Thats right! How did you know?"
"You have such a good view from where you are, and yet you don't know
where you are and you don't know where you are going. The fact is you
are in the exact same position you were in before we met, but now your
problem is somehow my fault!"

You must be an engineer. And, I don't say that just because your address
is IEEE.

I had closed out mplayer.  Issued a "ps -A" at the prompt to see if
there was a process running that would likely retain control of the dvd
player after the application running it had ended.  There were no
obvious candidates.

The system "knew" there was no other user logged in.  So the only
processes that could be dependent on the DVD were those the sole user
launched or the system itself.

I'm using KDE as my interface.  Gnome is ok,  I tried it.  KDE is the
desktop that gets most of the print in the subscription I have to TUX an
emagazine so I went with that interface.

Right there in the desktops you have a large redundancy. Two complete
graphical interfaces and there is yet another out there.

Windows problems like other system's problems stem from the assumptions
made at the origin of the systems. UNIX, minix, AIX, BSD, Solaris, and
the forty bazillion other variants all come from the same perspective
multi-user, multi-function.  It only natural that these systems would
police their processes, connections, and identities more closely.  They
started with those issues as part of their original problem set.  MS-DOS
and Windows started from the beginning with a different set of original
problems.  The primary problem for Apple and then eventually IBM and its
knockoffs was cost, power, ease of use, and market penetration.

I was using computers in the early sixties.  The word virus didn't even
hit the computer world until sometime in the eighties by which time the
computer makers were committed to their various strategies.  It wasn't
until the late eighties that viruses emerged as a significant problem.
At that time about the only net for most places was sneaker-net.  The
point is there were architectural and philosophical reasons that the
various hardware and software makers did what they did.

UNIX and mainframe OS's had robustness, reliability and security as
their primary drivers.  That's because they ran multi-user,
multi-process systems.  It is interesting to note that the first serious
virus incident was on VAXes or Vaxen, as some would have it.  Vaxes ran
UNIX variants usually.

Windows was originally built for single users, to be easy for users, to
run on cheap hardware.  Hardware manufacturers for their part put speed
toward the top of the list.  So, it certainly shouldn't surprise anyone
that security wasn't at the top of the list.  The first serious virus
incident didn't occur until some time in the Nineties when the Internet
was just getting general public momentum.  

It is easy now that connectivity and data travel around like oxygen in
the air to say that security should be the number one design criteria.
It wasn't so clear around 1978 when I bought a used black Bell and
Howell Apple II.  Not only was security not an issue.  I couldn't give
my data to anyone except on paper.

So now you have had MY lecture.  I hope you enjoyed it as much as I did
yours.

I hope that some time you might consider phrases in your lexicon like
"stupid users" and think what some of those users might say about
engineers that have trouble with spelling or grammar.  I'd suggest that
having trouble with technology isn't a hallmark of stupidity any more
that having problems with spelling and/or grammar is.  It's just
different sets of talents.

As to rebooting, I only had to reboot Mandrake once or twice in about 6
months to a year of using it as I recall.  Fedora Core 4 has not been so
kind.  You'd probably tell me that it was KDE or it was Open Office.
Being a "stupid user" I just know that when the mouse and keyboard stop
responding, I have to restart.


Well, enough.  I can drone on some more.  But I won't.  I appreciate the
venue where I can ask a question from a balloon and sometimes get a
useful answer.

On Sat, 2005-10-15 at 10:27 -0500, Bryan J. Smith wrote:
> On Sat, 2005-10-15 at 03:58 -0500, Brian Keefe wrote:
> > My latest was that mplayer would not permit me to eject the dvd tray
> > to change movies.
> 
> That's not MPlayer, but the Linux kernel.  If any file is in use, the
> filesystem is busy and the Linux kernel will prevent ejection.  While
> this is not as crucial with read-only media, if you've mounted something
> like DVD-RAM or DVD+RW, let alone a EEPROM "thumbdrive", you quickly get
> to appreciate the "UNIX way of things."
> 
> Furthermore, if you mounted the media as another user than the one
> running MPlayer, that will also prevent ejection.  *UNLIKE* Windows,
> where any user can mount/umount media, Linux _never_ compromises
> security for ease-of-use.  With Windows servers, stupid users have taken
> down servers by merely ejecting the CD/DVD.
> 
> > Pushing the hardware button on the tray hand no effect.
> 
> Of course not!  Linux, like MacOS, will _refuse_ a digital eject if the
> media is in use or mounted.  Linux further enforces security on who
> mounted it, and someone who presses the eject button is _not_ someone
> who can be authenticated as the owning user.
> 
> Frankly, I wish Linux systems had MacOS-like floppy drives with a
> digital eject as well, instead of a physical button.  And EEPROM
> "thumbdrives" would be much safer if there were clamps on the USB port.
> God I've had too many users just "yank out" them and seen them
> corrupted, and the "safely remove" toolbar icon is _not_ as perfected as
> the 30+ year-old UNIX "umount" command to ensure synchronization.
> 
> This has been a recurring theme
> 
> > I could not find an eject function on the gui.
> 
> There are _tons_ of ways.
> 
> First off, in GNOME (at least on Red Hat systems), the mounted device is
> on the desktop, just like MacOS.  If you right click and tell it to
> unmount, then it should eject.
> 
> Secondly, also in GNOME, you can add an "applet" to manage various
> drives.  You simply click it to mount/unmount as that user.  No fuss, no
> issues -- *UNLESS* some application is using that device.
> 
> >From the age-old Red Hat Linux 6.1 manual (yes, it's been around 6+
> years):  
>   http://www.redhat.com/docs/manuals/linux/RHL-6.1-Manual/getting-started-guide/appletsutil.html#APPLETSDRIVE  
> 
> Understand the "in use" and "security" aspects of mounting devices (and
> preventing their unmount) in UNIX/Linux is a _major_feature_ compared to
> Windows.  It might seem like a PITA for read-only media, but for
> read/write optical, EEPROM "thumbdrives" and other details, it is a
> savior!
> 
> > It wasn't until I thought of opening the terminal and issuing 'eject'
> > from the prompt that I could eject the tray,
> 
> Again, this is _for_your_protection_.  UNIX/Linux takes mounting media
> seriously, _unlike_ Windows, which will let you corrupt read/write media
> without any warning.  The same issues that resulted in a $2B lawsuit
> against Toshiba (was it?) in the '90s -- a fault of _Microsoft_, not
> Toshiba -- for floppy drives is seeing a repeat with EEPROM devices.
> 
> It's the way the OS works, _not_ the device.
> 
> Now as far as the GUI, use the GUI facilities.  GNOME should have an
> icon on the desktop _just_ like MacOS.  It's clear that you're assuming
> UNIX/Linux (let alone MacOS) should act _poorly_ just like Windows, and
> you're _never_ going to see that.
> 
> Additionally, the GNOME Drive Applet is very nice.
> 
> > that or a restart.
> 
> Never do that.  There is _rarely_ a reason to reboot Linux -- hardware
> errors are the _only_ reason.
> 
> > I am having to relearn the idea of the terminal as the court of last
> > resort.  I am constantly having to have an internal dialog along the
> > lines of "You're just learning the system.  Don't be comparing with the
> > ease of Windows.  It is just that you KNOW Windows that it seems
> > better." A lot of times I'm not convincing myself.
> 
> _Very_bad_ approaches in Windows will _never_ be mirrored in UNIX/Linux.
> Again, if you think UNIX/Linux is "wrong," then you must agree that
> MacOS is also "wrong" too.
> 
> Again, I was professional appualed with Microsoft's _horrendous_ OS
> design resulted in the $2B floppy drive settlement, because it was the
> OS, not the drive (from what I read from the filings).  It really goes
> back to the fact that a digital eject is what was needed on a PC floppy,
> which the Mac has.
> 
> That's why CD/DVD drives also have a digital eject.  In UNIX/Linux, like
> MacOS, the digital eject _never_ overrides the OS' safety/security.  But
> in Windows, it'll let you screw up read/write media, and screw up your
> services with even read-only media (e.g., in the case of SMB shares).
> 
> > I don't understand the concept of supplying all these redundant
> > partially working programs.
> 
> What is "redundant"?  There is but *1* command/control for
> mount/unmount.  GUI programs then use that command/control.
> 
> In Windows, you actually have far _more_ redundancy.  Different programs
> use different -- and sometimes _conflicting_ -- methods.  Take firewalls
> for instance (don't get me started ;-).  And when it comes to scanners,
> printers, etc... -- different, conflicting subsystems at times.
> 
> Windows is a _darth_ of standards.  Most people don't see it because
> they just choose *1* piece of software as standard.  But load more than
> one version of MS Office, or two firewalls, or two TWAIN devices (like a
> camera and scanner -- especially from different vendors), or two
> Postscript printers (especially if you use the vendor's installer -- let
> alone if the printers are networked!) and see what happens.
> 
> If you understand how an OS _properly_ mounts/unmounts -- whether it is
> UNIX/Linux or even legacy MacOS -- that will address your issue nicely.
> There are damn good reasons why you just can't press the eject button --
> and I can take you through a number of "crash the system" examples in
> Windows to show you why (even the "Please insert CD EEAD123A into the CD
> drive" super-circle-jerk is bad enough ;-).
> 
> > I think that maybe Fedora Core was a bad choice.
> 
> First off, Fedora Core and not even Fedora Extras provides MPlayer.
> Heck, Debian does not either!  You cannot blame Fedora Core or Debian
> for issues with MPlayer, it is provided by 3rd parties.
> 
> And you can't blame Fedora Core or Debian for legal issues on why
> MPlayer is not included.  Just like you can't blame Fedora Core or
> Debian for not including nVidia's drivers -- or even nVidia or ATI these
> days for the patent-infested 3D world of closed source drivers (blame
> Intel, Microsoft, etc... -- yes, Intel, they leave stuff out of their
> own drivers too).
> 
> I think your problem is that UNIX/Linux, or even MacOS, doesn't work
> like Windows.  Windows will let you do rather stupid things in the name
> of "ease-of-use."  That includes ejecting a device in the middle of a
> buffer flush or other read/write operation.
> 
> > I was reading somewhere that FC was supposed to be the bleeding edge.
> 
> So was Red Hat Linux before it compared to Red Hat Enterprise Linux.
> Red Hat Linux and Fedora Core are released every 6-9 months, and some
> versions adopt the latest stuff whereas other releases are more mature.
> 
> Red Hat Enterprise Linux is then a 18-month release afThe system "knew" there was no other user logged in.  So the only processes that could be dependent on the dvd were those the sole user launched or the system itself.ter a few of the
> Red Hat Linux/Fedora Core releases.
> 
> But your issues have *0* to do with this.
> 
> > If I would have known that I would have chosen something else.  
> > I had Mandrake.  It seemed better, more stable, a little cleaner. But,
> > Mandriva??  What's up with that?   I think that I will try Ubuntu next
> > if I reformat this system.  
> 
> This has _nothing_ to do with distribution choice.
> 
> Both Red Hat and Debian have _excellent_ release models.  Red Hat is
> heavily respected for the quality of their distributions -- although if
> you adopt a "new" release of Red Hat Linux / Fedora Core with brand new
> versions (e.g., kernel, GCC, GLibC, etc...) you can expect to have
> compatibility issues.  Same deal with Debian Sid and even Testing at
> times.
> 
> The "safest" choice in the Red Hat world is Red Hat Enterprise Linux, or
> rebuilds like CentOS if you don't want to pay for the services/SLAs of
> RHEL.  But then you're now using _older_ versions, and you'll find
> yourself wishing for features.
> 
> 
> 
> -- 
> Bryan J. Smith     b.j.smith@ieee.org     http://thebs413.blogspot.com
> ----------------------------------------------------------------------
> The best things in life are NOT free - which is why life is easiest if
> you save all the bills until you can share them with the perfect woman
> 
> 
> -
> To unsubscribe, send email to majordomo@silug.org with
> "unsubscribe silug-discuss" in the body.


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.