OT Win7 updates

Page 2 of 8  
On 05/19/2016 07:31 AM, Mayayana wrote:
[snip]

There must have been a lot of progress since then. I booted Ubuntu CD about 5 years later, and was looking at a web page a few seconds after booting (It helped that I already use Firefox). It was still awhile before I started using Linux regularly (and not Ubuntu, I never liked Unity).

For most of those problems, I found help on the web.

I think the documentation that came with my first Linux explained about the root thing. There's a way to fix it if you want to use the old way.
[snip]
--
Mark Lloyd
http://notstupid.us/
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/20/2016 12:27 PM, Mark Lloyd wrote:

That will vary based on the distro yuo're using. And, the versions of the individual "programs" that are involved.
E.g., configuring BIND9 is significantly different than BIND8. The general concepts are the same (somewhat) but the settings in named.conf(5) are very different and have added functionality.
A persistent gripe, for me, is that systems are not "shipped" with fully populated configuration files. I.e., if the default setting for <parameter> is <value>, then it can't hurt to include: <parameter>=<value> in the configuration file. Yeah, it might slow down the startup of the program by a few milliseconds as another option has to be parsed. But, it clearly documents what *can* be set and what those settings actually *are* -- no need to chase down a (potentially out-of-date) man(1) page to figure it out!
[It's taken me the better part of a week to create named.conf(5) for my new system -- despite the fact that my old system was successfully providing that service up until the moment I "upgraded"]
And, there is seldom an explanation for why changes were made. At least, not in any comprehensive document ("Gee, what happened to the 'tty' UID? Why is it, apparently, no longer needed?")
[A good part of my building new systems is going through this painful -- though trivial -- exercise. Hence my inclination not to "fix something" unless it's truly BROKE!]
OTOH, Windows just makes changes and doesn't even let you know there WERE changes!
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/20/2016 01:51 PM, Don Y wrote:

That's a good idea. I often use an empty string as the default for parameters enabling optional functionality. If the string isn't set, the functionality is turned off. Being a programmer, I document it like
foo default : ""
So, a little after five on a Friday, one of our ops guys managed to catch me on the way out to tell me the program wasn't working right. I checked the configuration file and sure enough
foo = ""
So now I put
foo default : "" (empty string)
but I know its a matter of time before ops puts
foo = empty string
The sad thing is I'm not dealing with the general public, just our operations people.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/20/2016 7:06 PM, rbowman wrote:

Yeah, like encountering: foo=none when you're trying to indicate that there is NO default or "nil"/null

People astonishingly overestimate their own abilities. EVERYONE thinks they are "above average" (really? then where are the offsetting souls that bring the average DOWN to where it is??)
I dislike spending (wasting?) time on maintaining equipment and tools. And, I have a pretty eclectic mix of them. So, I spend a fair bit of time researching the dark corners of many things.
Having sorted out those details, it would be foolish NOT to record them, someplace! And, having recorded them, foolish not to leverage that moving forward to new systems/updates.
E.g., disktab(5) and floppytab(5) are largely obsolete. And, have disappeared (or been seriously trimmed) in newer releases. But, they have a fair bit of information embodied in them -- that would be hard to accumulate independently. As a result, I harvest these and propagate them forward -- even if they aren't actively referenced in the system (software). I;m not keen on having to relearn some old bit of information that I already "knew".
[I have designed several devices that have built in modems -- so they can literally "phone home". To test these, I would use serial line protocols from a UN*X box through an external modem. After a year or more of NOT needing to do this, how long would it take me to rediscover the proper settings for the modem to get it to negotiate the connection properly?]
Below, the introduction to my bootptab(5) file -- the file I have to tweak next in bringing up this box. I think you'll be amused at how much it *says* and how little it *does*!
----8<--------8<--------8<---- # $Id$ # # bootptab(5) # # This is a termcap(3) style database. # # Blank lines are ignored. # Lines introduced with '#' are ignored. # Host entries are separated from one another by newlines. # Fields are separated by ':'. # Whitespace is ignored. # Lines terminated with '\' are continued on the following line. # (Be careful about including backslashes where needed. Bad things # can happen when a backslash is omitted where one is intended.)
# The first field is the "entry name". (may be FQDN and probably should be) # Following a tag name with '@' discards any previous definition. # Octal numbers must be prefaced with '0'. # Hexadecimal numbers must be prefaced with "0x" or "0X".
# Each "address list" accepts a whitespace delimited list of IP addresses. # An "IP address" is specified in standard Internet dot notation and may # use decimal, octal, or hexadecimal numbers. # An "IP address" can alternatively be specified using a symbolic name # which the BOOTP server will resolve using gethostbyname(3).
# Supported capabilities: # bf Bootfile # bs Size of bootfile in 512-octet blocks # cs Cookie server address list # df Merit dump file # dn Domain name # ds Domain name server address list # ef Extension filename ## ex Command to be exec(3)'d when processing request # gw Gateway address list # ha Host hardware address # hd Bootfile home directory # hn Send client's hostname to client # ht Host hardware type (see Assigned Numbers RFC) # 1 | ether | ethernet 10Mb ethernet # 2 | ether3 | ethernet3 3Mb experimental ethernet # 3 | ax.25 AX.25 Amateur Radio networks # 4 | pronet Proteon ProNET Token Ring # 5 | chaos Chaos networks # 6 | ieee802 | tr | token-ring IEEE 802 networks, # 7 | arcnet ARCNET networks # im Impress server address list # ip address of client # lg Log server address list # lp LPR server address list ## ms Reply packet size ## mw Minimum delay (in seconds) between recognized requests # ns IEN-116 name server address list # nt NTP (time) Server (RFC 1129) address list # ra address list to which reply should be directed # rl Resource location protocol server address list # rp Path to mount as root # sa address of TFTP server client should use # sm Host subnet mask # sw address of Swap server # tc Table continuation (points to similar "template" host entry) # td TFTP root directory used by "secure" TFTP servers # to Time offset in seconds from UTC # ts Time server address list # vm Vendor magic cookie selector # auto determined by the client's request # rfc1048 ( 99, 130, 83, 99 ) # rfc1084 ( 99, 130, 83, 99 ) # cmu ("CMU") # yd YP (NIS) domain name # ys YP (NIS) server address list # Tn Generic tag 'n' (0 < n < 255)
# The "bf", "hd" and "hn" tags may be enclosed in double quotes. # The full pathname to the boot file is formed by catenating the values # of the "hd" and "bf" tags. # The "td", "hd" and "bf" tags are interpreted in the TFTP server's context. # Be careful if running chroot(8)! # A client supplied boot file name overrides any "bf" or "hd" settings. # The "bs" tag may be specified as a decimal, octal or hexadecimal number. # It represents the number of 512B blocks in the bootfile. # The value "auto" for the "bs" tag computes the boot file size. The # actual existence of the bootfile (bf) is only verified when "auto" # is specified. # If computing boot file size, it is interpreted on the BOOTP server (not "sa"). # If specified as a boolean, the "bs" tag is treated as having the value "auto". # The "ha" tag may be specified as a hexadecimal numeric value or as a # symbolic hostname resolved via ethers(5). # When specified as a hexadecimal numeric value, the "ha" tag need not be # prefaced with "0x" nor "0X". # An unspecified "ha" tag will be resolved via ethers(5) if the "ht" tag is # effectively "ethernet" or "ieee802". # The "ht" tag may be specified in decimal, octal or hexadecimal numeric form. # The "ht" tag must effectively precede the "ha" tag. # If unspecified, the "ht" tag is assumed to be "ethernet". # If the "hn" tag is asserted and the fully-qualified hostname will not fit # in the reply packet, it is abbreviated to just the host portion unless # this will not fit in the packet in which case it is omitted entirely. # An unspecified "ip" tag defaults to the name of the entry. # An unspecified "sa" tag defaults to the address of the BOOTP host. # If specified numerically, the "to" tag must be a signed decimal value. # The value "auto" for the "to" tag uses the BOOTP server's time zone. # If specified as a boolean, the "to" tag is treated as having the value "auto". # Template entries should, by convention, have names beginning with '.'. # Templates must be defined prior to being referenced. # Explicit tag values override implicit values from referenced "tc" tags. # The "vm" tag may optionally contain an IP address. # Generic tags may assume hexadecimal numeric or string values. # Generic tag strings must be enclosed within double quotes. # Address lists consist of whitespace separated IP addresses. # IP addresses are specified in dot notation with octal, decimal or hexadecimal # numbers. Octal values begin with '0' while hexadecimal values begin with # "0x" or "0X". # Tags followed by '@' character deletes the value associated with the tag.
# Space in the reply packet is limited. The following parameters have # dedicated space reserved for them within the packet: # Client's IP address from the "ip" tag. # Pathname to boot file from the "td", "hd" and "bf" tags. # Name of TFTP server intended to supply the boot file from the "sa" tag. # The remaining parameters are conveyed in the vendor specific area of the # reply packet which is nominally 64 bytes in length. Each parameter is # accompanied by one byte identifier and length fields. # # Parameters are inserted in the following order: # ID SIZE DESCRIPTION # - 4 Magic cookie from "vm" tag. # 1 4 Subnet mask from the "sm" tag. # 3 4n Gateway from "gw" tag. # 13 2 Size of boot file from "bs" tag. # 18 ~ Extension file name from "ef" tag. # 2 4 Time offset from "to" tag. # 16 4 Swap server from "sw" tag. # 17 ~ Root path from "rp" tag. # 14 ~ Dump file from "df" tag. # 6 4n Domain servers from "ds" tag. # 15 ~ Domain name from "dn" tag. # 41 4 NIS server from "ys" tag. # 40 ~ NIS domain from "yd" tag. # 5 4n IEN-116 Name servers from "ns" tag. # 11 4n RLP server from "rl" tag. # 4 4n Time server from "ts" tag. # 42 4n NTP servers from "nt" tag. # 12 ~ Host name from the entry name. # 9 4n lpr(1) server from the "lp" tag. # 8 4n Cookie server from the "cs" tag. # 7 4n Log server from the "lg" tag. # ~ ~ Generic "T*" tags in the order encountered. # The following tags appear to be omitted from reply packets: # 10 4n Impress server from the "im" tag. # 57 4 DHCP maximum message size from the "ms" tag. # although the "DHCP maximum message size" is used to define the actual # length of the reply packet.
# Note that the services referenced by the "ns" and "ts" tags are # obsolescent and have been replaced by similar services referenced # by the "ds" and "nt" tags, respectively. Preference should be shown # for these newer services. While not prohibited, it should not be # necessary to specify tags for both the old and new versions of a # particular service.
# Template names should be chosen in such a manner as to prevent their # conflict with valid names. Introducing each such template name with # a period ('.') minimizes this possibility.
# Define a set of defaults to cover parameters that should not be omitted. .default:\ :dn="My.Domain.Name":\ :td="/tftpboot":hd="/":bf=null:\ :hn:to=auto:vm=rfc1048:
# Define a global template which specifies the stuff every host uses. .global:\ :tc=.default:\ :dn="My.Domain.Name":\ # :ds=DNS1 DNS2:\ :ds.0.1.99:\ # :gw=Gateway:\ :sa=Boot:\ :sm%5.255.255.0:\ :nt=Time:\ :to000:
# The NCD X-Terminals support the following tags: # bf Bootfile # ds Domain name server address list # gw Gateway address list # ha Host hardware address # hd Bootfile home directory # hn Send client's hostname to client # ip address of client # ns IEN-116 name server address list # sm Host subnet mask # to Time offset in seconds from UTC # ts Time server address list # vm Vendor magic cookie selector # As a result, tags definitions inherited from other templates should be # "undefined" to increase the space available in the BOOTP reply packet.
# In addition, they also support the following device-specific "generic" tags: # T15 Domain name # T28 IP broadcast address # T31 ICMP router discovery enabled # T49 XDM host address list # T144 Pathname to configuration file
# The "vm" tag must be "rfc1048". # The configuration file is expected to reside on the host that is acting # as the TFTP server. # The file service translations supported in the terminal at IPL are limited # to the "/usr/lib/X11/ncd" and "/" file hierarchies. Files within these # hierarchies are translated to the same file hierarchy on the host server. # As a result pathnames specified in these parameters -- most notably the # pathname to the configuration file -- must be resolvable within these # translations. Note that the configuration file, once loaded, can # augment these translations.
# To economize on the amount of space required in the vendor area of the # reply packet, any parameters which can be conveyed via the individual # terminal's configuration file (as indicated by the T144 capability) # are omitted from the BOOTP configuration data. These include: # :ds=DNS: # :hn: # :to: # :T15="My.Domain.Name": # :T49="BamBam BamBam":
# Define a template -- built on the global template -- that specifies the NCD stuff .NCD:\ :tc=.global:\ :hn@:\ :to@:\ :ht=ethernet:
Fred:\ :ha=Fred:ip=Fred:\ :bf=Fred:\ :T144="/etc/NCD/Fred":\ :tc=.NCD:
Barney:\ :haºrney:ipºrney:\ :bfºrney:\ :T144="/etc/NCD/Barney":\ :tc=.NCD:
...
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/20/2016 09:54 PM, Don Y wrote:

I don't miss modems at all. We send pages out to the people responding to an incident and in the bad old days it was literally dialing out to a paging service that would send a text to an alphanumeric pager. Hayes compatible was a laugh and then you had to figure out what Mom's Paging Parlor was capable of. Towards the end I had to break the bad news to some clients that the whizzbang 56k super modem they had bought was utterly incapable of dumbing itself down enough to talk to some 2400 baud paging terminal.
They're still around though. One of our support people was setting one up this week. Fortunately it is a direct line to a Zetron 2200 so there's no modem involved.
The fun thing with modems was when the dispatchers would get annoyed with the squeals and turn it off. "We're not getting pages anymore!"
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/20/2016 11:00 PM, rbowman wrote:

Before the internet was as ubiquitous as today, it was the only practical way to connect two points electronically.
And, the narrowness of the pipe meant you had to think real hard about what you sent down it!
On an early system, users could "dial in" and get a "console" to control and configure the device (Z180 based). I wrote a curses(3) implementation so I could develop "screens" instead of a "command line based interface". Client saw these elaborate screens and you could almost see the gears turning in his head as he was counting: 25 lines, 80 characters per line, 2000 characters per screen, ~200 characters per second -- WTF?! This is going to be DOG SLOW!
"Trust me..."
When he saw my first dog-and-pony, he was blown away at how fast it was! "But how is that possible??" Hadn't occurred to him that there were numerous optimizations that I could perform in the software to ELIMINATE data going down the wire, needlessly.
In fact, when I installed a fallback "command line mode" (when $TERM=none), he was annoyed at how much slower this simpler scheme actually was! (and, of course, far less user friendly)

I had a lot of modems over the years -- but always Telebits. This made things great for UUCP, etc. But, lousy when dealing with the rest of the (Windows) world!
I still keep a pair of 8840's: <http://i.ebayimg.com/00/s/NzY4WDEwMjQ=/z/vWoAAOxyoVZTJbXA /$_35.JPG> as i used them to develop some modem protocols for some of my projects (two land lines so they could "call each other")
And, a QBlazer (battery powered, portable) just because it was so cute! <http://www.ebay.com/itm/TELEBIT-Q-BLAZER-PLUS-TQB2-V-32-HIGH-SPEED-MODEM-W-AC-ADAPTER-/200940776718 But, there are just too many damn "S registers". And, everyone's idea of the Hayes Command Set was slightly different. The PEP support just made my life a bit harder when talking to other things (including the boxes I was designing -- 212 modems, etc.)

What I didn't like was how often you'd receive a call that was a modem or fax machine thinking it was calling a modem/fax machine! Of course, you couldn't TELL IT that it had reached a wrong number. And, it would dutifully call back some minutes later to try again to get a carrier...
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/21/2016 12:25 AM, Don Y wrote:

That happened to me....repeatedly. I always sent them 10 pages of solid black background with white text telling them to stop faxing my number.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/21/2016 7:56 AM, Farquar wrote:

Nice thing is you can save the black sheets, and use them on the next guy.
--
.
Christopher A. Young
learn more about Jesus
  Click to see the full signature.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/21/2016 12:25 AM, Don Y wrote:

This state had a massive 2400 baud backbone. I suppose it was a step up from a 300 baud acoustic. I was on Delphi and that was really styling.

Ah, curses... The early db_VISTA database had a curses based management tool. When Windows dropped ANSI.sys in 7 that was all she wrote -- almost. The gamers who loved their old DOS games had developed DOSBox and life was good again.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/21/2016 11:43 AM, rbowman wrote:

I found it a delightful programming environment! It was relatively trivial to "pop up" an error message and leave the majority of the screen/display intact (instead of forcing the user to look back through a list of commands/responses that might remain, serialized, on his screen).
Likewise, putting a "current time" display (with seconds ticking off!) in the corner of the screen really was over-the-top compared to competing products (where you had to ASK for the current time -- which was displayed as a snapshot of "the time as of when you asked")
Lack of a mouse (telephone line??) made it less convenient than modern point-and-click GUI's. But, tabbing between fields and using hot keys (by HIGHLIGHTING one of the letters in the displayed field!) made it relatively easy for folks to do things quickly and efficiently.
It's sad to see folks forgetting old solutions. Or, failing to realize how those could be applied to modern problems! (e.g., how many little devices have "serial consoles"? Why restrict them to "sequential command lines" when you could present a windowed user interface to the user -- like screens(1)!)
An old IBM "mini" had a delightful feature that I've been waiting to use. The user interface operated asynchronously with the job scheduler. So, you could type a head while the previous job was still running.
Unlike PC's (where those keystrokes aren't YET visible), the user interface would display the commands you'd "typed ahead". So, you could see what you were typing and what you'd ALREADY typed (you could get pretty far ahead of the machine if it was doing some real crunching!).
Whenever there was typeahead information queued, the display would split into two halves -- the screen as it existed while you were awaiting the results of the currently running job would be on top; and the screen containing the list of enqueued type-ahead keystrokes was visible on the bottom.
As jobs finished, the corresponding commands from the type-ahead queue would be pulled up into the top portion of the screen and the bottom portion shrunk, accordingly.
This is brilliant! Consider what it's like to type-ahead on a UN*X box -- you don't readily know what you've got enqueued for the system at any given time!
Couple this with a scrollback buffer (so you can review past commands and the associated output) and you've got a powerful -- but cheap -- UI!
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/21/2016 02:49 PM, Don Y wrote:

I don't have any hard figures but some of our users prefer the tabs and so forth even with a GUI. I recently fixed a bug that we had a hard time reproducing. It was a simple form with a few preset fields. We'd edit the one field of interest, click on Okay, and it worked as intended. Even watching the user remotely we didn't pick up on the additional action. He would tab, triggering a value changed callback which would reset the field to its original value and then click.
No problem fixing it after we found the path but it was one of those thing that leaves you scratching your head. "It's been like that for 10 years, and this is the first person to hit on the bug?"
I've never done much 'business' programming but I did an inventory application for the company I was working for. It was a very primitive interface based on BRADS, a cut down sort of RPG that came with an IBM 5110. I learned quickly that the people inputting the inventory info didn't even look at the screen after a short time. field, tab, field, tab, field, tab, field, enter, and on to the next item.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/21/2016 3:24 PM, rbowman wrote:

Yes. Mouse/GUI requires you to take your hands off the keyboard. Then, find their proper positions, again, once you've adjusted the mouse. Much quicker to move a particular finger up to a particular "next field" key and leave the mouse off in the corner.
Watch a touch-typist and you'll see how incredibly inefficinet GUI's are. And, why you want a common set of keystroke shortcuts that spans applications!

I do much the same when entering columnar data, etc. Keep my eyes focused on the input text (cuz relocating where you *were* is prone to errors and takes a fair bit of time each time you look away) and let some "background process" control my fingers.
Much of Windows is tedious for me to use because of the GUI aspect of the OS/window manager AND all the applications!
E.g., if I have to rename a bunch of files, it's easier to dump the list of files into a text file. Then, copy each filename to the end of its current line (inserting a space between the first and second instances). Then, pasting "RENAME " in front of each line and manually walking down the list of "second instances" changing them to whatever I'd like them to be.
I was editing MP3 tags last week and faced with this problem. Easy to change filenames (using this trick). But, virtually impossible to change the associated tags IN each file -- because the application didn't provide a means to "export" the tags to a simple text editor and later reimport them!
(There's a reason I use UN*X as much as possible!)
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/21/2016 05:24 PM, Don Y wrote:

Even my Windows boxes have enough Cygwin tools it's sometimes hard to tell the difference. Except for the damn backslash. That's right up there with <CR><LF> on my shit list.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/21/2016 7:53 PM, rbowman wrote:

I open an X server and talk to a UN*X box -- there's always at least one running. I've got "shortcuts" set up to open telnet, ssh, ftp, etc. sessions on each of my hosts for each target. I use cartoon character names for host names so I just use little images of those characters as the icons for the machines. Too many things are hard to do in Windows.
Then there's the Slowaris boxes that manage to make things even more "interesting".
I've had to resort to all sorts of little tricks to give me clues as to what I'm talking to -- a Slowaris console can look an awful lot like a NetBSD console or a DOS box.
And, the virtual desktops in Windows need to be differentiated from the virtual desktops under CDE or NetBSD's native X.
It's easy to get confused and start typing on the wrong keyboard into the wrong window to the wrong host. Then, wondering why you're not seeing the results you expected! :-/
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/19/2016 5:31 AM, Mayayana wrote:

The advantage of having the sources is that you can examine the "programs" that access these files to see what they expect to encounter. *That* is the definitive reference (not the man(1) page)

The bigger problem with any of the (free) Eunices is that there are lots of quirks that a casual user would not appreciate -- and could easily break. Too much of the "UN*X experience" RELIES on "experience". You can't just throw things together and hope it does what you want efficiently *or* effectively.
(Windows and its installers hide a lot of this from the casual Windows user)

The same is true of Windows. That's why there are patches released each week. (and that doesn't even address the applications/userland).

What "tips and advice" COULD you give someone -- without knowing how they will be using their machine as well as their goals?
What tips and advice would you give a car owner -- without knowing how they will be using their vehicle and what they expect/value from it?
Windows tries to be all things to all people (by being nothing to no one). The Eunices primarily target technical users. That audience gets a great deal of value from these offerings. For folks whose expectations end at the window manager, disappointment abounds! Trying to "back port" usability into a "product" that was designed for technical users is like trying to remove the hump from the camel...
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/20/2016 01:41 PM, Don Y wrote:

I had some quality time with one of those gotchas today. I'm doing a web service interface and wanted a quick and dirty test interface so I wrote a short C program to log what was coming over and threw it into the Apache cgi-bin on a Windows box. Worked like a champ.
I was working on my Linux box and wanted to do the same thing there for convenience. First, find out where apache lives so I can find out where it thinks cgi-bin is. Copy my little cgi executable in. No go. Cryptic error in the apache error.log. Play with permissions. Play with the log file path.
After a certain degree of frustration find out that on Kubuntu you're locked down tight enough what a process spawned by apache isn't going to write anything anywhere. (although it can create an empty file). Okay, that's not entirely accurate:
fprintf(stderr, "%s", "I'm losing my mind");
actually does write to the apache error log. And it even works on Windows...
Fortunately, reading a file is no problem so I could deliver a JSON payload for the GET.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/20/2016 7:21 PM, rbowman wrote:

The question then becomes, "where are you going to DOCUMENT this?" (besides here) So, you don't shoot yourself in the foot again, later?
My perpetual problem is partition sizing/layout. I keep experimenting with different partition (slice) configurations to make for a more maintainable/expandable system.
E.g., set up / as R/O -- but then /etc needs to be someplace "special" (or, "mount -u /", update /etc, then remount / as R/O).
Or, set up a separate /var to support a large amount of data; then cringe when you boot single user and / runs out of space!
Or, ...
But, there's no place to ANNOTATE my decisions! The current information is stored in the disk label. And, while it LOOKS like a text file when you try to edit it (disklabel -e), that's an illusion; even the "comments" that appear are synthetic comments -- you can't ADD anything to them!
So, I've taken to storing a copy of the label in ~root and editing it to add those comments. Then, just remembering not to delete this "note"!
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/20/2016 11:27 PM, Don Y wrote:

JIRA. The cgi test code will be checked in and built with the deliverables. I'll attach a sample of the JSON file used to dummy up data for the GET return. There will be notes for QA on setting up the apache server and where to look for the logs from the cgi process. There will also be instructions for setup on the live system. The JIRA issue will reference the FSD that the client signed off on, as well as the API provided by the third party.
We also have a directory off the source tree for informal programming documentation that includes quirks we've found, little tricks, and cookbooks for various tasks.
The biggest problem is not knowing the documentation is there. There is a good deal of interaction between the programmers but over the years each of us has drifted into separate areas of expertise along with the general maintenance programming. If someone stumbles across a real pitfall or interesting nugget it comes up at the next formal meeting.
Still, there is a problem disseminating the corporate experience. I have a vague idea what the Java guys are up to and sometimes undertake limited Java tasks to keep my hand in, but they're a lot better at it than I am. otoh, I've had to navigate the labyrinth of WCF and can turn out a SOAP interface easily given a wsdl.
All this is a problem for any organization. We're small and informal enough that there are no barriers between programming. QA, operations, and support like you find in larger companies but those areas of specialization exist and knowledge doesn't always flow as well as it might.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 5/21/2016 11:13 AM, rbowman wrote:

That's the advantage of building it into the actual object that uses it (e.g., configuration files). You *know* where you will be going to make the changes -- and, there is the information you need to make them!
In my current project, all of this is centralized in an RDBMS (there is actually no concept of a "file system"; all persistent storage happens *in* the RDBMS so it's harder to create some ad hoc entity than it is to create a structured one!).
Each schema is commented so you can examine a description for each "column parameter". Individual rows (entries) can place comments in the "comment parameter" (present in all of the tables I build).
Of course, no way to force future developers to perpetuate this discipline. But, I've built mechanisms that automatically convey these things to the user (i.e., "What's the role of the 'Delay Prior to Restart' parameter for the HVAC controller?" "The 'Delay Prior to Restart' parameter controls the hold-of period between the end of one furnace activation and the start of the next") So, hopefully, future developers will find it easier to "fill in the blanks" in the database instead of having to develop their own "help system".

*If* they remember it -- and haven't just worked-around it.
I believe people are lazy. And, always opt for expedients. So, I try to cater to that and provide my solutions to tolerate (or even encourage!) that sort of behavior (as above).

The problem is much greater, IME, when you are dealing with highly disparate knowledge domains. E.g., hardware folks are often oblivious to the concerns (or capabilities!) of software folks; neither are savvy to the issues regarding packaging and physical interfaces; NO ONE cares about the things important to the bean counters; programmers document the code for other programmers -- but not the user; etc.
I was real tight with my best friend from school. At one time, we worked on a joint project -- I designed the processor (built entirely of bipolar logic) and he wrote the code for it. Nothing on paper -- just ideas that we "discussed over lunch".
When I got the prototype built, we installed his software (written without having access to any hardware or even a "simulator"). NOTHING worked! Despite each of us being 100% confident in our own designs AND in the capabilities of the other party!
As it turned out, I had designed a 16b machine. Everything was 16b (or multiples thereof). He had thought of everything in terms of bytes. So, all of his (byte-oriented) addresses were twice *my* (word oriented) addresses! I.e., "CALL 6042" should really have been "CALL 3021". A true "Homer" moment. But, one that we could fix in a few minutes (tweak the assembler he wrote to divide everything by two and reassemble the sources).
Folks anxiously watching us bring up the new hardware were amazed at the fact that it "came up on the first attempt" (discounting this SNAFU). Without all sorts of formal documents to indicate how everything SHOULD work.
But, that sort of deep sympatico is rare -- not something I'd encountered with anyone else in the years since!

OTOH, there are a lot of projects that are just too large for small organizations to tackle. I've worked on multidisciplinary "teams" of 1 to ~30. The smaller ones are far more agile than the larger. Less formality required in the interactions. OTOH, you've got lots of extra minds and bodies with the bigger ones so you can get more done per unit time.
In my current project, I have to deal with an undefined, faceless "support team" that will take my work in directions I've probably not foreseen. So, I have to build a solid foundation to impose as much guidance as I can on the design to keep it from meandering in the absence of my guidance down the road. "Talking to the future" is tough cuz they can't talk back!
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 05/21/2016 01:25 PM, Don Y wrote:

One of my favorite books is 'The Mythical Man-Month'. In any social structure the abilities of the individuals vary. The larger the organization the more hiding places for the timeservers and those who should have been in another career entirely.
There is an advantage to corporations that are too big to fail. Lockheed Martin and Northrup Grumman consistently fail but the money keeps flowing in.
https://www.london.gov.uk/what-we-do/mayors-office-policing-and-crime-mopac/governance-and-decision-making/mopac-decisions--33
That's the latest failure in my field. Missing the go-live date might have been smoothed over with a penalty but reading between the lines London had no confidence that NG could ever deliver a working system.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Related Threads

    HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.