> From: Random832
> I think he means the fact that MIME specifies the type of the main
> message body (not just attachments), so you can have a message with *no*
> text parts.
Right, that I could discern; what I couldn't get with an definitiveness was
_why_ that was particularly a problem.
(Another possibility, other than the one I previously gave, is perhaps that
there simply is no text part, which one can peruse, ignoring the rest?)
Noel
Hello.
Perhaps you haven't been made aware yet of these series of --IMHO--
very interesting articles about Xenix 386, entitled "Xenix 2.2.3c
Restoration", by Michael Casadevall, a.k.a. NCommander at the geek site
https://soylentnews.org (of which he is one of the founders):
Part 1: https://soylentnews.org/article.pl?sid=17/03/03/1620222
Part 2: https://soylentnews.org/article.pl?sid=17/03/07/1632251
Part 3: https://soylentnews.org/article.pl?sid=17/03/11/2014253
I wish Bela Lubkin, ex- kernel engineer at "classic" SCO, would have
joined the list to comment on those articles and pour some light into
the more obscure points. I sent an email to Bela some time ago telling
him about the TUHS mailing list, but I didn't hear back from him.
--
Josh Good
Hmm yes although perhaps controversially I see this as a bad feature and
one area where Microsoft actually gets it right. Despite the old issues of
"DLL Hell" which have largely been resolved by standardizing all DLLs and
in newer code by using assemblies... you have to admit that they provide a
direct, local API (indeed ABI) to every subsystem you would want to use,
here I am thinking of GDI, but also lots of things that would require
ioctls (CD burning, say) or domain specific languages (such as Postscript)
on Linux. This makes it really easy for Windows developers to use the
feature and the interface is fast and reliable. And where a domain specific
language is actually NEEDED (printing to a Postscript printer on Windows,
or RDP-type desktop remoting etc) it is easy to insert a proxy DLL or
object or device driver that does the necessary scrambling and
unscrambling. It is not so easy to go the other way as it requires
extensive emulation (think of ghostscript driving my Canon non-PS printer).
I wrote about this issue earlier using some examples like an "ESC ["
capable terminal as opposed to a memory mapped local console, or an "AT"
capable external modem as opposed to an internal "WinModem" that just
exposes its D/A and A/D converters with minimal signal processing and needs
the host to do the heavy lifting. Same thing applies to a graphics
terminal. Of course it should be programmed at a high level by specifying
shapes, etc to be drawn, regions to be blitted, clipping regions and pens
etc, a font manager, and it should be possible to load bitmaps, etc, into
its offscreen memory and/or create offscreen drawing buffers, if these
features are used correctly by applications then it is of course trivial to
add a remoting proxy driver similar to Microsoft's RDP, or indeed X Windows.
But the difficulty with X Windows is that the remoting layer is always
there, even though it is almost completely redundant today. This hurts
performance but more importantly it requires extensive workarounds as you
described, which add enormous extra complexity and in my view sharply
increase the learning curve and setup costs. Having said that, Xlib does
offer a decent API/ABI so if we just code to that it's not TOO bad, I would
like to see the rest of it deprecated though, and vendors encouraged to
implement Xlib with whatever backend seems appropriate.
The ridiculous thing here is that X setup is so damn convoluted and
incestuously tied in with the window, session and display managers, THAT IT
IS IMPOSSIBLE TO RUN X REMOTELY ANYMORE AND HAVE A FULL FEATURED DESKTOP, I
have tried many times and have had various tries at thin clients and
terminal serving in my home network and it basically fell over because
environments like Gnome do not support multiple sessions of the same home
directory, not to mention numerous other problems that mean if you login
remotely you basically just get a blank screen with a default X cursor and
maybe a context menu that can run an Xterm. Bleh! In my experience you have
to use a remoter like VNC and guess what that does, tricks X into thinking
it's running locally and then intervenes further up in the display stack to
do the actual remoting.
It's a complete dog's breakfast and frankly could never compete with
Windows in any realistic way. I use it because it is the least bad of the
available options (no way am I having advertising in my start menu and my
computer loaded with bloatware and spyware before I even open the box, and
no way am I putting up with vague messages like "Something went wrong" or
"Windows is making some checks to optimize your experience" or whatnot),
and because my computer is so fast despite being 6yrs old that X only feels
borderline sluggish, i.e. is tolerable. But so much better would be
possible with a redesign. CUPS is also a dogs breakfast and hugely
unreliable, Windows GDI printing just wins hands down for all the same
reasons. End rant.
Nick
On Mar 15, 2017 5:49 AM, "Ron Natalie" <ron(a)ronnatalie.com> wrote:
Nice thing about X was that it would talk to remote displays. I still
remember sitting in the Pentagon demonstrating that the Suntools screen
lock wasn't particularly secure.
Then there was NeWS. This was Gosling's first attempt at a deployable
language. However PostScript (even with Owen Densmore's class
extensions), while a reasonable intermediary language is really sucky to
actually develop. Java was a bit more refined.
Of course, lots of things either implement X under the native window system
or backdoor X with local extensions. We got around doing high frame rate
image work on X via the SharedMemoryExtension and the ability to flip
buffers on the retrace interval (both extensions, but commonly implemented
by many servers).
Sorry, in this context, SunOS means 4.1.4 - not Solaris SVR4
I run Solaris myself, and love it.
On 3/15/2017 11:48 AM, Joerg Schilling wrote:
> Arthur Krewat <krewat(a)kilonet.net> wrote:
>
>> You make a valid point, and re-reading what I wrote, I find that I
>> pushed the example too far :)
>>
>> The subject was originally that SunOS at it's end-of-life did not have
>> the features that Linux now does, and comparing their development
>> lengths brings up an interesting question. What would SunOS have become
> So you believe that SunOS-5.11 is no longer alive?
>
> There is an Oracle based version and a OpenSolarisd based version developed by
> the community.
>
> Jörg
>
Hello all.
I was perusing the list of officially branded UNIX systems, according to
the "UNIX 03" specification and tests done by the Open Group, and I
found there listed something called "Huawei EulerOS 2.0".
https://www.opengroup.org/openbrand/register/xy.htm
Intriguing, ain't it?
So I went to Wikipedia, to see what it has to say about such a beast.
https://en.wikipedia.org/wiki/Single_UNIX_Specification#EulerOS
And I quote: "EulerOS 2.0 for the x86-64 architecture were certified as
UNIX 03 compliant. The UNIX 03 conformance statement shows that the
standard C compiler is from the GNU Compiler Collection (gcc), and that
the system is a Linux distribution of the Red Hat family."
So, Linux (some variety of it, very closely resembling Red Hat) is now a
"officially branded" UNIX.
I think Mr. Stallman can now say: mission accomplished. GNU *is* now
UNIX. (Linux the kernel might not be a FSF project, but it certainly is
under the GNU General Public License.)
--
Josh Good
How are y'all? And greetings from the piney woods of south Georgia.
If anybody wants to help get an Internet innovator into the Internet Hall
of Fame, please drop me a note at jsqmobile(a)gmail.com. No rush; deadline is
tomorrow. He's not a Unix person, but you'll recognize him. Hint: early ISP.
-jsq
On Tue, Mar 14, 2017 at 3:48 PM, Arthur Krewat <krewat(a)kilonet.net> wrote:
> So what I'm hearing is Linux's timeline, which includes things that were
> not developed just for Linux, extends further out than SunOS does.
>
​Mumble... the problem of course is the under those rules, SunOS goes back
to research which goes back to V0....
​
>
>
> ​...​
> All I'm saying is comparing Linux's timeline to something like SunOS has
> to include everything that went into both because they both relied on
> precursors.
>
Except for any possible legal reasons....​why differentiate ? Looks like a
Duck, Quacks Like Duck or from a Turing Test.... I'm mostly can not tell
the difference.
>
> Side note: I'm a bit of a bitch when it comes to Linux - which doesn't
> mean I don't think Linux is "UNIX" - it just means I think it's the
> Coherent of today's UNIX ;)
>
​I guess it doesn't matter to me that much. Some of the changes are
gratuitous and annoying, which brings out my inner curmudgeon as its make
its tough to type to sometimes. But the fact is, UNIX, Linux, Macos are
pretty much the same thing - much more so than winders. They are way more
similar than different and I can be productive with all three. To me its
like ethnicity in people. It says a little about some of how you might
look at something, what some of you shared positions/starting points are,
but we are way more alike than different and I would rather learn from the
differences than fight them or try to inflict my wishes. We are better
with diversity.
Clem​
> From: Clem Cole
> rms had access to Masscomp b= ox we gave him fairly early on.
> ...
> I'm sure the MC-500 was not the first 68000 he had access. I think he
> was using HW in Steve Ward's lab that the Trix guys were developing
> with TI and he might have had access to an Apollo system.
> ...
> Noel do you remember how that went down?
Sorry, no. From the end of '82 to early '84 I was out of the US, waiting for
my permanent residency to come through, so I missed a chunk of events in that
time period. Maybe one of the DSSR/RTS (Steve Ward, or someone) could clarify
what access RMS had to their 68K machines?
Noel
Nice thing about X was that it would talk to remote displays. I still remember sitting in the Pentagon demonstrating that the Suntools screen lock wasn't particularly secure.
Then there was NeWS. This was Gosling's first attempt at a deployable language. However PostScript (even with Owen Densmore's class extensions), while a reasonable intermediary language is really sucky to actually develop. Java was a bit more refined.
Of course, lots of things either implement X under the native window system or backdoor X with local extensions. We got around doing high frame rate image work on X via the SharedMemoryExtension and the ability to flip buffers on the retrace interval (both extensions, but commonly implemented by many servers).
Allowing more or less arbitrary attachments was a real convenience.
But allowing such stuff to serve as the message proper was
dubious at best. Not only did it require recipients to obtain
special software to read some messages; it also posed a
security threat.
I still use mailx precisely because it will only display plain text.
With active text such as HTML, it is all too easy to mistakenly
brush over a phishing link. Outfits like Constant Contact do their
nonprofit clients a disservice by sending stuff that I won't even
peek at. And it's an annoying chore when companies I actually want
to deal with send receipts and the like in (godawful) HTML only.
Doug