[svlug] Inits, sysV, systemd, uci, etc.

Jesse Monroy jesse650 at gmail.com
Sat Jan 3 02:15:54 PST 2015


CORRECTION: I should have the cron process, not the boot process  (in
2004). FWIW, very similar issues occur.

Jesse

Sent from my Samsung Tab2
On Jan 3, 2015 2:10 AM, "Jesse Monroy" <jesse650 at gmail.com> wrote:

> I've got a dog in this fight.
>
> In years past, I had a great illusion of creating a computing cluster.
> At the time, I called it BUDs (BSD Unix Distributed simply). The
> allusion to California's #1 cash crop was intentional - much to the
> horror of my room mates.
>
> Back on track, My first task was to create tunnels between systems,
> then my insurmountable task was at hand -
>
>     * REMOVE ALL UNNECESSARY FILES - text and binary
>
> I made good progress in identifing text files - that were plainly for
> different languages. Then I proceeded to identify binaries that had no
> MAN entry. More than 10% of binaries had no reference - much of the
> FreeBD documentation team preferred to imitate the 3 wise monkeys.
> Yes, this was a deadend.
> http://en.wikipedia.org/wiki/Three_wise_monkeys
>
> Eventually, I reached the boot process. Here in 2004 you'll see my
> second attempt to document the boot process. And as far as I know, no
> one used used this. But I did pubicize it again and again - as I
> could.
>
>
> http://web.archive.org/web/20060315163941/http://www.svbug.com/documentation/freebsd-default-crontab.r3.x.html
>
> Around this time a host of efforts were underway to get *BSD on to
> embedded devices. Included in them was PicoBSD, which sometime
> afterwards put forward UCI (Unified Configuration Interface Project)
> http://people.freebsd.org/~abial/UCI.html
> http://people.freebsd.org/~abial/
>
> YES UCI, one of those projects no one has heard of - unless (of
> course) you are developing for MIPS on linux. (Which by the way MIPS
> development was start at NETBSD, not OpenBSD, and not one of the minor
> *nux (at least to my knowledge)).
>
> For those of you unacquainted with UCI it is prized in the wireless
> community and industry because it is unencumbered with heavy UI (User
> Interface) issues -- like (X) windows, hald, keyrings,
> source-registry, kworker, and various unused and unwanted utilities.
>
> As matter of fact, most of the modern wifi AP (Access Points) and
> Routers - use OpenWRT which rely on UCI to do most of the
> configuration. The graphical interface to many of these wifi devices
> is a rather light-weight, but powerful webserver - known as
> ''uhttpd''. The admin graphical interface is called LuCI - this
> because it uses LUA (http://www.lua.org) and UCI
>
> Table of Hardware - OpenWRT
> http://wiki.openwrt.org/toh/start
>
> uHTTPd
> http://wiki.openwrt.org/doc/howto/http.uhttpd
>
> LuCI – Technical Reference
> http://wiki.openwrt.org/doc/techref/luci
>
> == Fast forward to me ==
>
> So now it's been almost 15 years since I tried my hand at trimming the
> boot process, and I find myself full circle - but this time on the
> Arduino Yún. Oddly enough the same sort of computing power is at
> hand**. Now - up until 4 weeks ago I would have praised the Raspberry
> Pi for its innovation, but today I see this toy as much, much better.
> (I won't go into Pi shortcomings here)
>
> http://arduino.cc/en/Main/ArduinoBoardYun
>
> == Now to the Dog Fight ==
>
> At this point, I am unlikely to head or help much with any effort to
> trim the general UI and/or boot process. But in reading Steve Litt's
> notes (and blog post) just before the year's end got me to thinking.
>
> http://lists.svlug.org/archives/svlug/2014-December/060014.html
>
> Back in the early 2000's I made a public statement at an SVLUG
> meeting. Someone said I should talk to Jef Raskin - I said, "Jef Who?"
>
> http://www.folklore.org/StoryView.py?story=The_Father_of_The_Macintosh.txt
>
> http://comm6480rpi.blogspot.com/2009/09/jef-raskin-black-sheep-hero-of-humane.html
>
> http://www.icreatemagazine.com/featured/did-you-know-the-origin-of-the-macintosh/
>
> I meet Jef about a year or two before he died. He did mention he was
> fighting cancer, and he also mentioned he did hide his academic degree
> from Jobs and Apple because he was afraid of descrimination.
>
> So last night in the row (ruckus), I was going to throw in my two
> cents, but decide perhaps I could find some better words. Below you'll
> read Jef Raskin's essay on elements for a better UI, but in fact the
> same principles can be used to fix the BOOT PROCESS.
>
> Title: The Humane Interface (c) 2000
> Author: Jef Raskin
> ISBN: 0-201-37937-6
>
> In Chapter Six - ''Unification'', Jef puts it plainly. It is worth quoting.
> pg 99-100
>
> """
> In trying to create a general-purpose interface that takes into
> account the requirements that we have delineate in the previous four
> chapters, we find that basic changes from present practice are
> necessary. Many directions are possible; one tack is to see what we
> can do within the limitations of the Internet and with hundreds of
> millions of computers and information appliances that exist and that
> are being manufactured today.
>
> The most common personal computer hardware configuration is nearly
> universal at present. By taking a point of view that emphasizes the
> commonality of physical actions across almost all applications, using
> the common hardware elements, rather that looking at vast disparity of
> tasks, we can develop a general yet simple interface.
>
> The list of actions a user can take to influence content--be that
> context textual, graphical, or multimedia--can be arranged into simple
> taxonomy, which allows us to describe any application's interface in a
> uniform way. This organization can help guide us in simplifying
> interface designs. Implementating a universal undo/redo facility also
> helps to develop a unified interface, eliminating much of the need for
> individual programs to handle error recovery.
>
> Different applications have different commands, and a user cannot in
> general use the command from Application A while working in
> Application B and vice versa. By liberating command from applications,
> we eliminate the inherent modality of applications. The total number
> of commands a user must master drops dramatically with this kind of
> unification, primarily because unification rids us of the immense
> duplication of commands. (... at this point Jef goes into an example
> ...)
> """
>
> At this point I'll outline Jef's design:
>
> 1) basic changes from present practice are necessary
> 2) emphasizes the commonality of physical actions (...) rather that
> looking at (the) vast disparity of tasks
> 3) (list user actions) "into simple taxonomy"
> 4) implement a universal undo/redo facility
> 5) (use general commands to) "eliminate the inherent modality"
>
> You might ask, Will any of these suggestions come into being?
>
> I think not. For the course of things to change, it requires that
> programmers give up their ego. YES, I said ego.
>
> Anyone of the boot processes you can name has some person's ego
> embedded. Whether that ego is impressed by their professor or that ego
> is developed by self-study, matters not.
>
> Is 'UCI' the answer? I think not. At best, it is part of an answer.
> Is 'systemd' the answer? Yes, it will work best for maintaining fiefdoms.
> Is 'sysVinit' the answer? No. sysVinit was form to placate corporate
> entities that still remain, and as many friends remind me - the
> emperor still has no clothes.
>
> What about Upstart, et al? I respond, "Up who?"
>
> In closing, I'd like to remind my many friends in the SVLUG community
> - I'm stuck in El Paso, Texas; and likely the smartest computer person
> in town (but only because I'm the only computer person in town).
>
>
> Cheers, best to all.
> Hope to see you when I return in March of this year.
> Jesse
>
> ----
>
>
> ** Arduino Yún is equivalent to the Pentium II, except now we have
> wifi (802.11g/54Mbits vs. 802.11b/11Mbits in 2000), 100Mbit ethernet,
> USB2 (with microport) http://gct.co/usb-connectors/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.svlug.org/archives/svlug/attachments/20150103/ea316c94/attachment-0001.htm


More information about the svlug mailing list