[Pc_Support] Re: The problem with Windows (as only 0.1% of us understand) -- YUM/YaST, _not_ RPM

[Bryan J. Smith]

On Sat, 2006-05-13 at 16:14 -0400, Ray Brunkow wrote:
> Well by step in the right direction i was referring to a closer to RFCs, 
> at least an attempt even if in reality they fell short.

The problem with Microsoft has always been embrace, extend, extinguish.
As usually, the 10% of Microsoft that doesn't want that is drowned out.

Microsoft even supported OpenGL from virtually day 1 in NT, and only
went to DOS Direct Memory Map aka WinG aka DirectMM aka Direct2D aka
DirectX after OpenGL support in "Chicago" absolutely tanked.

> Also IF you use the "user levels" and other settings available for
> security steps and it is far better then the win9x line of OSs from
> MS.  yes i came from the win95/98 line into win2k.

But because 100% of Microsoft's own, signature software _failed_ it's
own "Designed for Windows NT" logo certification program, privilege
levels became _useless_ in Windows NT -- at least for
desktops/workstations, as well as most server services.

>From that point on, it didn't matter what Windows NT did, it was
Chicago's bitch and had to conform.  Hence why privilege, RBAC/MAC and
other things were rather useless.  Kinda said, because NT was _superior_
to UNIX in design in the early '90s when it came to RBAC/MAC (even if it
wasn't true multi-user like UNIX).

Despite all the bitching, moaning and complaining on _true_ RBAC/MAC,
Red Hat is forcing it on the community with SELinux.  And they are
conforming.  SELinux is not broken at all (boy I've had that argument
too many times), it's just that the legacy UNIX community only knows
DAC, not RBAC/MAC.

Red Hat is always a PITA for most people, but they are pushing Linux
forward -- and everyone benefits from that.

> yes, that is setting up the users properly for a semblance of security.  

No, it's a joke.  Still is today, even under "locked down" XP Pro SP2.
What you have is basically UNIX-like sudo functionality, and _not_ true
MAC/RBAC.

Not because Microsoft didn't design Win32 correctly.
Not because ISVs didn't write to the Win32 API.
But because _both_ Microsoft's own tool developers didn't write to
Win32, and _all_ Microsoft applications were written for "Chicago."

> it is not as secure as Linux or Unix, but it is better then win9x.

Anything is better than MS-DOS with 386Enhanced mode, and that is
_exactly_ how Win32 works under "Chicago" (Windows 95/98) -- MS-DOS 7.x
and Windows 4.x in 386Enhanced mode.  It's why Microsoft had to pay off
Caldera in a ~$250M settlement over illegal product bundling.

> i never really worked with NT before 2k so i can not comment on NT4
> or older vs.

NT 4.0 "Cairo" was a joke and proof that NT was now Chicago's bitch.
And even then, MS-DOS 7.x compatible Int20-3F functions didn't make it
into NT 4.0.  They didn't come around until NT 5.0 (2000) a few years
later.

NT 3.51 "Daytona" was a bad idea.  It basically hacked it so "Chicago"
applications could run.  And even then, you still didn't have MS-DOS 7.x
compatible Int20-3F functions, so you often got 8.3 only file support.

NT 3.5 (3.50) was flawless.  Of course, *0* of Microsoft's own
"Chicago" (Windows 95) applications would run on it.  Microsoft's
"Designed for Windows NT" Visual Studio 4.x series produced code that
would _not_ run on 3.50.  It was the worst fiasco I've ever seen.

100% of _all_ Microsoft "Chicago" applications _failed_ on NT 3.5.
Microsoft's own "Designed for Windows NT" logo program _never_ passed
_any_ of its own software -- only a few 3rd party software from Digital,
Bentley Systems/Intergraph, etc...

Hence NT 3.51 "Daytona" -- so MS Office 95 and other applications would
run on NT.  Because they were written for "Chicago" not NT -- even back
in 1994 (a year before Windows 95 was released).

> yup, that is why we have LEAP and i am glad to be able to learn from you 
> guys. 

The key is to not assume.
Far too many people do this in the Linux world, as well as Windows.
They comment on what they don't know.

It's hard to curb that, I know.
Even I had to learn to do that, and I was bad until about 2001 or so.
It's best to let others comment on what they know when you don't.

> again, this goes to my limited skills with those distros.

That's why I reserve comment when I don't have first-hand experience in
a _production_ environment.

I haven't run Debian in a production environment since 3.0/Woody.

I haven't run Mandrake in any environment since 8.1.

I follow developments, but I really _avoid_ commenting on them as I'm
just going to be ignorant.

In the same regard, about 98% of what you hear about Red Hat and Fedora
is based on information and assumption that is pre-21st Century.

> the default install of SuSe and FC/RH line is very full of stuff that
> is not needed vs Debian.

Not true on Fedora Core!  You don't have to install Fedora Core from the
Anaconda installer, just like you can do an initial image install of
Debian.

Most people just _choose_ the _legacy_ Anaconda GUI installer when it
comes to Fedora Core.  Fedora Core is _not_ Red Hat Linux or Red Hat
Enterprise Linux.

> Now that I know enough about debian i can install with the first CD
> and just do a base install and apt-get everything else after manually
> editing my sources.list.

And so you can with Fedora!

Not only can you do that "so-called bloated" the Anaconda installer with
_only_ CD #1 with _any_ Fedora Core release, Fedora Core 2+ actually
lets you do a 90MB "minimal" install and YUM everything!  You can do
this _completely_outside_ the Anaconda installer.

I've even plunked down the 6MB EEPROM key image into a system and done
it from that!  Then I'm a Kudzu here and a YUM there ... Done.|

> I am sure if i knew the RPM model as well as i know the debian,

_Not_ "RPM model"!  "RPM model" _died_ in the 20th Century.

Debian is "APT model," using DPKG as the back-end.

Fedora-based has always been "YUM model," with RPM as back-end, even if
there was a heavy amount of use of APT in the early 21st century.  YUM
is the only one officially supported, and APT-RPM is all but dead now.

SuSE-based has always been "YaST model," with RPM as back-end.  There
are APT and YUM options too -- but YaST is the only one officially
supported.

A big problem with current production APT is the multi-architecture.
YUM and YaST solve the multi-architecture issue and allow full POSIX
lib64 and lib inter-mixing.  YUM also has the same 3-tier and
group-based approaches as APT.

APT and YUM are so similar now that the Connectiva (the guys that first
created APT-RPM), now Mandriva, have created the uber-"SmartPM" (Smart
Package Manager) that handles DPKG, RPM, TAR.GZ (including Slackware)
back-end and APT, YUM, URPMI and other front-ends.  It even has a
standard GUI front-end built-in, among 3 other interfaces.

> and that is not near as well as i know windows,

Windows is simple.

They have InstallShield -- be it executable or install (.inst) package
-- which does _minimal_ dependency checking and *NO* conflict
resolution.

Microsoft uses digital signatures to public X.509 certificates, but
there is _no_ enforcement.  I.e., someone can _blindly_ fire off an
executable and you'll get _no_ warning if the signature is bad.

DPKG and YUM use USTAR format archives, OpenPGP signatures and other,
automated features.  APT and YUM then _enforce_ them -- anally.

> i could also build a much cleaner running RPM distro.

Again, I'd start using the term "YUM" or "YaST" and _not_ "RPM."  Just
like people don't say Debian is "DPKG," but "APT."

This is the 21st century, despite 98% of non-Fedora/SuSE users still
thinking they are 20th century.

> It seems i will be learning enough soon how to do that.
> good for me *grins*

The only time you use "RPM" itself is the same when you use "DPKG" in
Debian.  If you run Fedora-based or SuSE-based distros, you use "YUM"
and "YaST" -- _not_ RPM.


-- 
Bryan J. Smith            Professional, technical annoyance
mailto:b.j.smith at ieee.org      http://thebs413.blogspot.com
-----------------------------------------------------------
Americans don't get upset because citizens in some foreign
nations can burn the American flag -- Americans get upset
because citizens in those same nations can't burn their own