Re: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM

[Kenneth Goodwin <kennethgoodwin56@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5238 bytes --]

On storage discipline-
UNIX derived systems deliberately don't enforce file formats. In the UNIX
philosophy
Everything is a file.

Inter program portability can be achieved in a multitude of ways.

Pure ascii format with either defined field widths or the more common
"special character"  delimited fields. Ie pipe delimited or comma or :
delimited.

xml formatted.

There are several conversion programs available as well as write your own.

On Sun, Apr 4, 2021, 9:36 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On Apr 4, 2021, at 4:33 PM, Clem Cole <clemc@ccc.com> wrote:
>
>
>
> On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah <bakul@iitbombay.org> wrote:
>
>>
>>
>> On Apr 4, 2021, at 3:25 PM, David Arnold <davida@pobox.com> wrote:
>>
>>  For us UNIX historians, we need to be careful and learn from our own
>> history here -- the Cell Phone/Mobile target is the engine for the next
>> Christenian style disruption.  It is by far the #1 target for people
>> writing new programs (which I find a little sad personally - but I
>> understand and accept -- time has marched on).  In the end, a small mobile
>> target will be the tech on top, and available will be driven by market
>> behavior and those suppliers will be "who has the gold.”
>>
>>
>> I feel I should point out that both the dominant mobile operating systems
>> are Unix-hased.  The UI is necessarily new, but astonishingly the 50 year
>> old basic abstractions are the same.
>>
>>
>> Except Unix is kind of hard to see. It wasn't just the hierarchical file
>> system but the idea of composability. Even now we whip up a shell
>> "one-liners" to perform some task we just thought of. All that is lost. And
>> not just on mobile devices. For example search through email messages for
>> something in an email "app". And no UI composability. We have to use
>> extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s
>> /Application/X-code" takes tens of seconds!) to painstakingly construct a
>> UI. We can't just whip up a dashboard to measure & display some realtime
>> changing process/entity. There may be equally heavyweight third party tools
>> but there has been no Bell Labs like research crew to distill it down to
>> the essence of composable UI and ship it with every copy. The idea that
>> users too can learn to "program" if given the right tools.
>>
>
> Exactly my point.  The only difference I suspect is I just don't bother
> with the IDE (Xcode or VS).   Frankly, vi/emacs, or as we discussed a few
> days ago, ed is still way more preferable when I'm programming.
>
>
> Many things are easier to convey visually. It would be neat if unix
> paradigms can be extended to visual design as well. And you certainly can't
> do visual design easily in vi/emacs. Just like in Autocad you need both
> interactivity and programmability for creating visual elements.
>
> I mentioned in another email Intel's new development suite - OneAPI.
> Absolutely speaking for myself here, I am a bit at odds with management WRT
> to much of it, as I feel the direction is a bit miss guided.   But I do
> understand why Intel is doing it/trying.   Everyone in the industry seems
> to be saying "use my Framework, my language, my solution and I will solve
> your problem."  "You will sell more copies of the program if you use my
> portal, *etc*."  Intel to compete, needs to do the same things.     To
> me, it seems a bit like fairy dust - a promise that will work for a set of
> people, and of course, some firms like my own employer will keep making
> money (or in the words of the Dr. Sueuss Lorax character: "Biggering and
> Biggering."   As I said in the previous message, it is driven by the other
> golden rule.
>
>
> IMHO a bigger need is some discipline on storage. As things stand, it is
> hard to extract data from applications for legitimate uses but not so hard
> to extract for illegitimate uses. If app A for some specific domain dies,
> there is no guarantee that app B for the same domain can use A's data.
>
> What I always felt made UNIX powerful was that it did not seem like the
> BTL folks were trying to sell anything.  They were trying to solve real
> problems they and the folks at AT&T had when it came to realistically
> building and deploying systems.   Yes, there were hidden from the profit
> motive at the time because of the unique rules of the 1956 consent degree
> and we all were winners because of it because they say -- sure here you can
> use it too.
>
>
> Similar conditions existed and exist to a certain extent in research orgs
> of some companies but I think that is a necessary condition, not
> sufficient. The right research crew can bring in another kind of
> interactivity -- in creativity, in trying out and critiquing each others'
> ideas and building on them. And you still need the right key people.
>
> Now that we are back to a winner take all market, (OSVM/360 *vs.* VMS
> *vs.* winders ...) I think we have traded away designing for the sake of
> getting the job done properly, for designing to sell as many as possible (
> *i.e.* be sexy and capture a market, not be simple and do the job well).
>
>
>

[-- Attachment #2: Type: text/html, Size: 8460 bytes --]