[TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM
kennethgoodwin56 at gmail.com
Mon Apr 5 12:58:57 AEST 2021
On storage discipline-
UNIX derived systems deliberately don't enforce file formats. In the UNIX
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 :
There are several conversion programs available as well as write your own.
On Sun, Apr 4, 2021, 9:36 PM Bakul Shah <bakul at iitbombay.org> wrote:
> On Apr 4, 2021, at 4:33 PM, Clem Cole <clemc at ccc.com> wrote:
> On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah <bakul at iitbombay.org> wrote:
>> On Apr 4, 2021, at 3:25 PM, David Arnold <davida at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS