Sampling: What Nyquist Didn't Say, and What to Do About It

MS are good at making software that is easy to get started with, without considering the long-term effects. So the great majority of Word users use the quick-to-learn manual formatting, rather than learning to use the tool properly. Even the few that get proper training use styles effectively - they use manual formatting because they are lazy and it gets the job done fastest, even if the end result is poorer and the long-term efficiency is worse. Word /does/ have usable tools for proper structured and consistent document layout. They are not great, and the program is often unstable when documents get large, but they do exist - if people would use them. MS software is like a reasonable supermarket, selling fairly healthy food that people can take home and cook. And then they've put a burger bar by the entrance.

As you can guess, I /don't/ bother with it. However, if you are happy with the restricted set of (La)TeX that it works with, then it is much less intimidating and has a much easier learning curve than "proper" (La)TeX.

Trivial with <

>

--
Many thanks,

Don Lancaster                          voice phone: (928)428-4073
Synergetics   3860 West First Street   Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml   email: don@tinaja.com

Please visit my GURU's LAIR web site at http://www.tinaja.com

Then "Merry Christmas" (let's see... I guess it's still the 24th, there, as I type this)

Understood. You'd rather be lying flat on your face, hung over from too much eggnog... ;-)

Understood. It is, however, interesting to see what can be done (and done differently) in an interactive environment.

*BSD's tend to treat "ports" as things you build and "packages" as those same things, prebuilt.

Then, you also have to deal with the various *ports* to different CPU's... :-/ Sort of like the terminology overloading that comes to play wrt "partitions", etc.

I don't think the *BSD approach automates "updates". IIRC, there are hooks that let you periodically check to see if any of the packages on *your* machine have (new) security advisories that are applicable. But, I think you still have to explicitly decide that you want to go find a new version, etc. Most "packages" are only supported in one or two "releases" (at a time). So, going back to a particular release may be impossible once the system "marches on" (i.e., I keep snapshots of pkgsrc)

This is the difference between the Linux camps and the BSD's. First, Linux is *just* the "kernel". You can't do anything without the rest of the distro (at least, that's my understanding). With the BSD's, you end up with a functional system -- the typical "core services and utilities" (X, inetd, ntpd, ftpd, nfsd/c, etc.) right out of the box. And, there is no (real) change in them between BSD's.

OTOH, the "rest of the distro" in the Linux world drags in things that BSD treats as "applications" -- relegated to the packages/ports system.

For example, starting X leaves me with a "rootweave" screen and an xterm. I *think* twm is probably there.

But, kde, gnome, etc. -- none of that cruft is even present in the filesystem! Want to browse the web? Sorry. Want to view a PNG? Sorry (i.e., libpng doesn't exist!).

Where folks will tout "damn small linux", this is relatively *easy* to get to in the BSD camps -- because none of the "other crap" is there to begin with!

So, each time you drag a "package/port" onto your machine, you start pulling in all this extra cruft. When I build ports, I keep an ordered list of what I build and when. This allows me to tackle the "common prerequisites" early so that I am sure I have them configured the way *I* want them -- without relying on the system building them 'automatically' to satisfy a prerequisite for some other "port"

Granted. In one case, you rely on the programmer to have written a portable piece of code. OTOH, you rely on the "package author" to know how to ensure things are portable AS WELL AS understand the code he is "porting" (packaging?). My experience has been that people fixated on "porting" the code often are just trying to get it to compile -- hopefully "clean". But, they don't often look *into* the code to see if that "clean build" *should* have been clean or if there isn't an error lurking behind this seemingly "perfect" build.

[and, of course, more often than not, the build *isn't* clean]

I suspect the "difference" that sets FM users apart is that they are concerned with "publishing" and not just "getting a document out the door". I.e., if forced to layout a manual in MSWord,

*I* would probably (grimace) make an effort to "do things right" *assuming* I was going to be STUCK with MSWord thereafter.

I.e., if you are willing to shell out $$ for a DTP tool then, chances are, you are aware of the DTP issues vs. YetAnotherWordUser.

Well, I'd replace "fairly healthy" with "greasy hamburgers" and "burger bar" with "cotton candy dispenser" -- but your point is made.

Sorry, let me rephrase. "Why would SOMEONE bother with it?" I.e., what does it offer that justifies it's presence/bulk/potential for bugs/etc.?

E.g., adding a preprocessor to C *gives* you something -- for relatively little cost (it doesn't really get in your way, doesn't dramatically impact the reliability of the tool, etc.).

But apparently had *8* columns (instead of 2)? I.e., how quickly could you insert "JVC" (alphabetically) into the list?

It would depend on how much data, other than just a single line with a title. I would have to edit the following pages, but that is simple cut & paste to move the header data down to the proper page breaks. Maybe ten minutes. BTW, JVC didn't exist when those service manuals were written. :)

--
For the last time:  I am not a mad scientist, I'm just a very ticked off
scientist!!!

My point was that your table has the "fold" inherent in the location of the individual cells *in* the table.

E.g., the scheme I outlined lets me make a table like:

COLUMN ANOTHER A AAAAA B BBBBB C CCCCC D DDDDD E EEEEE F FFFFF

(i.e., a table that is conceptually a TWO COLUMN table)

and then have the layout tool AUTOMAGICALLY display it as:

COLUMN ANOTHER COLUMN ANOTHER A AAAAA D DDDDD B BBBBB E EEEEE C CCCCC F FFFFF

*or*

COLUMN ANOTHER COLUMN ANOTHER COLUMN ANOTHER A AAAAA C CCCCC E EEEEE B BBBBB D DDDDD F FFFFF

etc. as space permits.

Since this is *still* the same "two column" table, I can add a line anywhere and the lines after will move around as necessary:

COLUMN ANOTHER COLUMN ANOTHER A AAAAA E EEEEE B BBBBB 1 11111 C CCCCC F FFFFF D DDDDD

Yes, but it cost me nothing for the software and takes only minutes to get an acceptable file. It isn't pretty print, but it has a uniform style that is easy to edit. What is real fun is creating web pages that scale to different resolutions and still look OK. Like the title bar on one I did. A solid bar that matches the background in the company logo covers the entire width, and the logo stays centered. The alternative is a lot of different sized pages with Javascript to select multiple versions for different screen widths. That was easy, when there were only a few.

--
For the last time:  I am not a mad scientist, I'm just a very ticked off
scientist!!!

I think newer browsers now can resize JPEG's (?) so this gives you an option for a "device independent" graphic.

Yes but it doesn't keep the same shape, and can look like crap. The neat thing is you can grab the corner of the window, and watch it resize, yet the logo is unchanged. According to the server logs a lot of visitors are using older browsers that would crash, or look like crap. For a new business, you can't afford to tick off any potential customers.

--
For the last time:  I am not a mad scientist, I'm just a very ticked off
scientist!!!

It's now the 25th, and a day for relaxing here (in my house, anyway - traditions vary). Merry Christmas to everyone else, or "Happy Holidays" for those that prefer that (I can't understand the reasoning behind that phrase, but each to his own).

Eh, something like that...

Absolutely.

I thought "ports" was the name of FreeBSD's package manager, but I could be wrong.

I don't know of any Linux distributions that try to force new updates on you, or even make it the default. Many /check/ for updates by default, but it's your choice to install them or not.

Correct.

The huge majority of these parts are common between Linux and *BSD.

It's just a slight difference in the terminology. Technically, "Linux" is just the kernel. What people actually use, is a Linux distribution (or a "GNU/Linux" distribution if you prefer, since many important parts of the system are GNU). But people typically refer to the whole system as "Linux", or by distribution name.

In the *BSD world, there are three BSD's - OpenBSD, NetBSD and FreeBSD. I think they all operate on much the same principle. These are all roughly equivalent to Linux distributions in that they cover the whole system packaging, but differ in that it is the same group that develops the kernel and the packaging.

Then there are a few odd-bod systems - Debian packages with a BSD kernel, non-standard BSD distributions, etc.

It's all there in the BSD package manager system. You install it if you want.

All you are really saying here is that the BSD system /you/ installed was fairly minimal. You can do that with Linux too. Many distributions will include the browser and Gnome in the base install. Others have very little, while most of the "big" distros (Debian, Fedora, Ubuntu) have something like Gnome by default, but you can choose not to install it if you don't want it.

Oh, it's all there, because it is not "crap" but is useful software. These things are personal choice - for some people, "twm" is all the window manager they need. Other people - the great majority of users - prefer something more advanced, such as Gnome or KDE. BSD makes it easy to install Gnome too.

You seem to go through an awful lot of effort here - effort that the very clever folks at FreeBSD (or NetBSD or OpenBSD, if that's what you use) have already made. They have already done all this work precisely so that users like yourself will not have to bother. Of course, clever though they are, they are not perfect, and may make mistakes or have not tested or considered some particular special situations. And you certainly have the /choice/ to do this work yourself. But it's not necessary - only a tiny proportion of BSD or Linux users micro-manage their systems in this way.

I believe it is intended to be sanitized of religious references. E.g., "safe to use in mixed company"

It's hard to be pedantic, here -- hence my use of quotation marks -- as the terms are heavily overloaded. And, as I mentioned, the introduction of support for different architectures adds yet another dimension to the "mix".

First, the distinction that all *BSD's contain more than just a kernel. I.e., "NetBSD" is *a* kernel (usually several different configurations are shipped in each release -- PER ACHITECTURE)

*plus* a set of core tools/services. So, with *a* BSD, you have a complete working system (whatever that means). You can write code, compile it, run X (and a core set of x apps), support a full set of network services (httpd is NOT included but things like tftpd, ftpd, ntp, etc. *are*), build new kernels, etc. (you can opt NOT to install large portions of *BSD -- e.g., all the X related stuff, fonts, sources, etc. -- if you really to minimize your disk footprint).

Beyond that, all of the "applications" are handled by the "ports collection" (port being a bad choice of word as it is also used for a "port" to another architecture -- I suspect the origin of the term in this context was in light of "porting an application *to*

*BSD"). So, emacs is NOT present in any of the BSD's but is added as an "application". Ditto for apache, KDE, GIMP, etc.

The mechanism that allows for this application support exists in two different forms. You can chose to download and install a PREBUILT "package". Or, you can build that package yourself from "pkgsrc" (this being little more than a hierarchy of patches, makefiles, scripts and "relationships" between "packages").

The "packages" are created by "someone" sitting down and building an app *in* the pkgsrc distribution. E.g.,

# cd /usr/pkgsrc (typically) # cd archivers/zip

edit system-wide pkg configuration -- or specify pertinent options for this particular application

# make (build the application) # make (I forget what the name of the target is to bundle the installable files into a "pkg") # make clean

I.e., the "packager" saves you the trouble of having your machine crunch through the compile (I've run NetBSD on 40MHz SPARCs; FreeBSD on 25MHz 386's; etc. You used to be able to run FBSD on a 5MB 16MHz 386sx -- can you imagine trying to make kde on such a box?? Just wqaqtching the disk thrash would feel like inhuman punishment!)

I don't think that capability exist in the pkgsrc or ports collection. I know you can have pkgsrc fetch an updated "vulnerabilities" file and then examine the pkgs installed on your system to inform you of any "vulnerabilities" that may have been discovered since you built/installed them.

My point was that "Linux" doesn't mean anything -- you have to reference which distribution you are talking about.

OTOH, OpenBSD/NetBSD/picoBSD/FreeBSD/etc. each define a particular "core system" (which varies from release to release). So, configuring "ntpd" on OpenBSD has definite connotations. (in fact, it is probably the same for all of the BSD's -- though there are some personality induced differences :> ) Saying the same for "Linux" begs the followup questions, "Which distro? Which kernel version?"

But a BSD system is typically more narrowly defined than a Linux distro. E.g., you *won't* find kde in any of the BSD's (well, I may be wrong here as I am two full releases out of date and haven't watched FreeBSD since 2.6 or so).

There are three groups associated with BSD maintenance. Kernel hackers maintain the three different (where "different" means "incredibly similar" :> ) kernels; others provide the assorted "core utilities" that flesh out the "system". Then, there are a group of "packagers" that work on porting the various "applications" -- usually, WITHOUT regard to a particular BSD. I.e., the files in the pkgsrc hierarchy have a lot *literally* shared between all of the BSD's and some tweeks for each *particular* BSD. So, if one camp wants "packages" in /usr/pkg while another wants them in /usr/local...

No, you're missing the point. If I download *BSD, I *don't* get any of the PNG sources. There is nothing *in* the BSD's that needs them so the philosophy is (or at least "had been") to not deal with them in the various BSD's but, instead, deal with them as "application" issues.

IIRC, the options I have(had) for installing NetBSD:

- base

- comp

- etc

- games

- kernel(s)

- man

- misc

- text

- source

- xbase

- xfonts

- xcomp

- xfonts

- xserver

So, if I don't want X, I don't bother unpacking the x* groups. If I don't want man pages, I don't install the man group. If I don't want to build/compile anything, then I omit the comp group. I think the bare minimum system can be run with etc, base and *a* kernel from the kernel group. A "full install" would include all of the above (this is the *binary* distribution).

Note that this exists on a "per architecture" basis. I.e., the SPARC "base" is different from the i386 "base" (some are shared -- like man)

Then, there are the "source" groups:

- gnusrc

- sharesrc

- src

- pkgsrc

- syssrc

- xsrc

The syssrc is typically the kernel sources. Xsrc is obviously the X sources. The src group is the bulk of the system. There is an active attempt to quarantine all GNU/GPL software in the gnusrc group (UNLIKE Linux, you can distribute the BSD's

*without* source code -- including the changes that YOU make to the kernel, applications, etc.).

The pkgsrc is the issue I was talking about earlier.

I have downloaded/installed ALL OF THE ABOVE. Yet, there is no libpng, libjpeg, etc. on my system AT THAT POINT. It is only when I delve into applications that I build out of the pkgsrc hierarchy that these things get drawn into the picture -- but,

*separate* from NetBSD itself!

The reason for taking on the responsibility myself hails back to the "three groups" that maintain the sources. Look at them as concentric rings -- kernel maintainers in the center, pkgsrc authors at the periphery. The skill set required *tends* to increase as one moves inward -- the repercussions of mis-steps increase.

Given the shear number of applications (thousands!), the number of folks authoring and maintaining "packages" exceeds those maintaining the kernel. And, the commitment of folks in package land is usually much less than that of the core team (kernel + system).

As it is a volunteer effort, there is no one riding herd over these people verifying the quality of their work, enforcing conventions, etc. (keep in mind, I got on the NetBSD bandwagon at 0.8 -- early 1990's -- I think they are now at 5.mumble) Since I don't take a kitchen sink approach with my UN*X boxen (I pick, carefully, what I will use on each), I *can* invest the time to carefully examine *how* a package is being built. I can make changes that are more in favor with the way I want to use a package. I can chase down bugs that are important to me (with that number of packages, some are obviously NOT going to see regular usage) without waiting/hoping for the "package author" or "port maintainer" to stumble on the same problem. (for years, my primary contribution to FreeBSD was in this role -- just feeding patches to friends who would dress them up and submit them formally to "whomever". I no longer do that as I don't chase the current releases unless I am researching a particular bug/problem)