[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wanting opinions->uController OS
From: NZG <ngustavson@emacinc.com>
> I'm just rebuking your absolute.
My example _was_ designed to be an absolute. I call this an "illogical
example" -- using your logic in reverse. My point was that if you confine
your definition of BSD as you did, then you should have clarified you
were that you were talking about uCLinux. There are some constraints
in uCLinux versus Linux -- even in 2.6.
With that said, I more than admitted that uCLinux is closer to Linux
than any off the MMUless BSDs are to common Freedomware BSD.
But you were being very broad in your Linux assertions and rather
narrow in your BSD focus, which is what I pointed out.
> I didn't miss it. I was just pointing out that it's not as well known as
> the SCO lawsuit.
Dude, get over it ...
"I have never even heard of a lawsuit against BSD." -- NZG
[ FYI, Darl McBride _did_ make claims that BSD was also a
potential target, despite the 1994 AT&T v. UCB settlement,
in a late 1993 interview with eWeek. He only dismissed
BSD as a target that was not big enough revenue-wise. ]
Furthermore, you were talking Theo's clearly yesteryear and _accurate_
statement that BSD was affected by a lawsuit (AT&T v. UCB) versus
Linux developments that are very recent. _You_ took his statements
out-of-context, which has now led down a path of backtracking by
yourself.
The more you continue to spew, the more your ignorance shines through.
Please stop, just admit the consideration slipped your mind (if you
knew about it at all).
> I am well aware that the SCO lawsuit severely lacking in merit.
Against Linux, yes. In general, that's debatable (I happen to think
IBM is going to lose on items #50-55 in the original filing, which
is going to augment their case against earlier items because it
means SCO violated the "non-compete" on Linux/IA-64).
> But it was higher profile,
Depends on your viewpoint of "high profile." In the context and time
AT&T v. UCB was proceding, there was a _clear_ "indemification"
issue at hand. Even in today's context, had it repeated itself, you
would _not_ see companies working on BSD like you are HP, Red Hat,
etc... are on Linux despite SCO's claims.
HP, Red Hat and other companies are clearly making "indemification"
promises on behalf of their users because they know the claims
lack merit. In the case of AT&T v. BSD, there was clearly some
evidence that would suggest quite otherwise.
> and scared more people, even if it lacked merit.
Quantity of a scare does not necessarily mean quality, or
even the total dollar amounts involved.
> My point was that Linux has also undergone it's share of attacks.
Attacks, yes. Real, credible legal statements, no.
You're still backtracking on the reality that unlike current
Linux IP claims, there was massive and signficiant drop-offs
in BSD development by various individuals and entities due
to the real indemification issues. That's exactly what Theo
meant.
I also think those legal questions combined with AT&T's
1986+ standardization efforts were the 1-2 punch that
really killed a lot of BSD developments until 1994 on-ward.
Although I feel BSD clearly had a _lot_ of similar efforts
in development in its early, 4.4BSDLite years (1994-1995)
that were comparable to early Linux developments.
In reality, I think it was some of Microsoft's chronic errors
(like preventing tier-1 OEMs from shipping anything but MS
SQL on Windows servers) that led to Linux's thrust to the
foreground in commercial developments and marketing buzz
in 1999+. So in that regard, Theo's comments on "Linux is
anti-Windows" is a bit of a stretch, but applicable.
> When did I say that? I said I welcome controversy as long
> as we can do it without insulting one another.
The embedded commentary. I didn't like how you responded
to Mr. Lambert.
> What do you mean by "scale"?
> Up to high end SMP systems? It can do that.
Linux itself has seriously neglected processor affinity of not
only processes, but I/O. This is due to its primary focus on
the I/O bottlenecked PC platform, which is reflected in its
non-PC ports. Most RISC platforms have had partial-mesh
interconnects for years, so their UNIX implementations have
been developed with such considerations.
My point is that for Linux to "compete," it's going to have to
radially change in design. And that's going to make it far
more difficult to develop drivers, modules, etc... So my
personal preference is to _not_ introduce it, but only introduce
code in sub-projects that address those more eccentric needs.
E.g., Linux itself doesn't need to be hard real-time.
> Do you have any numbers on this?
Linux Magazine had an eye opening review. The article is
on-line, but the benchmarks are not.
> Or evidence to back this up?
Well, to throw the same "attitude" that you displayed Mr.
Lambert, the PC platform is very immature from an I/O
standpoint, and Linux's heritage in development on it has
affected its focus. AMD has finally introduced a platform
that finally does away with the bottlenecks of the PC
platform from an I/O standpoint in the NUMA/HT Opteron
but we haven't seen the boost over legacy Intel GTL in
most of the benchmarks of Windows and Linux.
That was until Solaris/Opteron came to town. ;->
I personally wasn't expecting much until I saw the numbers.
Then the lightbulb went off in my head on why Linux isn't
impressing too much with server I/O on AMD64 v. EM64T.
Linux doesn't provide processor affinity with regards to
I/O yet -- even with the I/O MMU support.
> What absolutes are you referring too?
On your characterizations of Linux v. BSD.
> RTAI has gone through some major changes since it adopted Adeos.
> This is actually the "patchless" approach I am referring too.
> Also it's Fusion branch provides the API VxWorks.
That's for API portability, not necessarily guaranteeing the same
level of hard real-time VxWorks is capable of. Yes, RTAI is taking
some things away from VxWorks, but not all.
> To be honest, I'm a little scared of the RT preempt patch myself,
> as it will fundamentally change the kernel, but I don't know that
> I'm really qualified to argue one way or the other as I don't
> understand it very well yet.
Exactomundo. I'm no expert, but every re-entry hack I've seen for
Linux is just that, a hack. It introduces rediculous context switching
overhead IMHO, instead of a fundamental change. But I don't want
a fundamental change because that will destroy Linux as we know
it. If I want a fully re-entrant kernel, I'll use Solaris or VxWorks
as appropriate.
I think Linus had it perfected, 1 entry per CPU. In the near-future
of multi-cores and, eventually, virtual cores (the consolidation of
out-of-order execution/register renaming with virtual threading on
virtual cores), it's best to leave it to the silicon. This is not an
extension of Intel HyperThreading, which is a poor, mega-context
overhead hack for the 12 year-old i686 design, but a design that
was designed for it from day 1. So 1 entry per [virtual] core will
be extremely ideal for even general usage.
> I agree it's valid, but I think more people would be interested,
> and have more interesting opinions about it, on a dedicated list.
The problem is that if you can't see the context of Theo's comments,
then I doubt others will on a RT list. It's hard to bridge the
knowledge of both lists -- although I like to think you "ran into the
brick wall" of myself. ;->
--
Bryan J. Smith mailto:b.j.smith@ieee.org
-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.