Is It Chrysler Or Is It Not?

I think it really is Chrysler. That is what has me bothered.

[Quick update: I searched for the dealer sites. Last time I looked, I couldn't find dealer sites. This time I found sites for both dealers, and both had live chat services. Very helpful operators. It looks like the problem I had before, of not being able to contact them, has been solved. That just leaves the domain name problems.]

[Second update: (24 October) Nope. My optimism was not founded. Or only half-founded. There is no Chrysler-wide policy. I've communicated directly with sales managers at the dealerships involved, and at least one seems to have a policy that they want addresses they can automatically dump their regular sales announcements to, more than they want real customers. (Sorry to be so blunt about it.) 

How is it that people would rather have a bigger pay check now than understand where the money comes from, and why and when the stream is going to dry up?

I guess that's a subject for another blog, sometime.]

One good tell-tale for phishing used to be found in the return e-mail address or in the url link that took you to the web page the mail was sent to inform you about.

If it was different from the domain name of the purported sender, you could guess that the message was not legitimate. And delete it or send it to the spam bucket for your admin to collect and add to the spam filters.

For example, if the mail claims to be from PayPal, and the return address (as, when I click "Reply") is

advertising@deptA.paypal.com

the address is in the paypal.com domain, which I have strong reason to believe is owned and operated by PayPal. (How I have reason to believe that is a subject for another post.)

On the other hand,

paypal@deptpaypal.advertising.com

is in the advertising.com domain, and who knows who is operating that right now?

Likewise, if I copy a link url (right click, copy url or copy link) and paste it into a text editor window, I can see the raw url. Again,

    http://accountsurveys.paypal.com/custcode/?3234dsdf3324stvp1d

is a url in the paypal.com domain. Unless I have been a victim of dns poisoning, the server I would go to when I click on that should be managed by the same people that manage paypal.com. But

    http://paypal.accountsurveys.tv/custcode/?3234dsdf3324stvpld

is a url in the accountsurveys.tv domain, and could very well be somebody phishing for my PayPal password.

If PayPal wants me to trust the link they send me, but wants to outsource the advertising or the customer surveys, they should delegate a subdomain to their contractor.

Paypal would enter a domain name record that says, effectively,

deptA.paypal.com  => deptpaypal.advertising.com

(This is not the actual command, and it's a little more complicated than just a single line, but it's something a good systems administrator should be able to take care of in an hour, with spare time for a snack, easily. Or, maybe five minutes today, ten minutes tomorrow, and twenty-five minutes in a week from now, checking the results. Done quickly, does not cost a lot.)

With that setting, which PayPal controls (barring software bugs), advertising.com can do their PayPal related stuff using e-mail addresses in the paypal.com domain, and that lets me know that they are, in fact, authorized by PayPal to do it.

(Not 100 percent sure, but better than 90% sure. Again, I should talk more about that elsewhere. But if they ask for my password or login ID by e-mail I should contact paypal.com directly, instead. e-mail is currently not safe to send passwords by.)

And a similar setting can let the folks at accountsurveys.tv (if they really are legitimate) put a whole web site up under

accountsurveys.paypal.com

which is in the paypal.com domain, and, again, let me know they are authorized by paypal to do it.

Well, even so, they should never ask me to tell them my password in a survey site. Passwords are not their business.

By the way, I think I remember seeing PayPal slip up on this kind of thing once or twice in the past (new grads or summer interns?), but they are generally pretty good about it.

(If you see a message from PayPal that comes from some domain that is not a PayPal domain, it's not them. Just hit the spam button. Unless it has personal details on you, in which case, contact PayPal directly.)

But there are lots of non-IT companies who seem to be outsourcing stuff and not realizing they need to delegate the domain names to do it under. Chrysler would seem to be one.

Shoot, they have such a variety of websites that I can't tell if any of them really have anything to do with the car company. This is bad news, and may have some influence on the state of their bottom line.

Some specifics --

For more than a year, I have been regularly getting messages with subjects like this:

Hey Joel, come back to Fremont Chrysler Jeep Dodge Ram

or like this:

Your recent Dodge Grand Caravan service at Concord Chrysler Dodge Jeep Ram

Now I really liked the family car I drove when I was a teenager. It was a Mistsubishi-made Dodge Colt (circa 1974). Wonderful car, lightweight, fast, easy to park, room to cart my stereo to church for the dances, etc.

Sometime while I was taking a break from college, my parents bought a second hand Ram van and used it for a long time. Quite dependable, allowed them to travel in reasonable comfort between their home in Texas and my grandfather's home in Utah. That van was turned over to a friend who needed transportation some ten years ago, I think.

I like Chrysler vehicles in general, but I myself have never bought a Chrysler, Dodge, Jeep, or Ram. And the last several years have definitely not seen me anywhere near Fremont or Richmond.

However, there are plenty of people in the world with the same first and last name as me. Some of them have been known to be careless when giving out their e-mail address. I have had to tell people in both England and Australia that I am not the Wookie they are looking for. (And I really am not.)

It is very difficult to tell a Chrysler dealership that they have the wrong e-mail address for a customer. I've tried that and failed several times. I'll probably try looking at the dealer sites for some sort of human-powered contact again after I post this. I'm too nice. Perhaps I should keep just sending these to the unsolicited (spam) box. A click every week or so costs me less time than this post.

On the other hand, this is a good example of how people should not use the internet. So it's not a waste of time to explain what's wrong.

So, back to the subject.

In Google's webmail interface, you have the reply arrow above the message, on the right. Next to that is a little triangle pointing down. Click that triangle and you can get a lot of fun things like "reply to all", "forward", and "filter messages like this".

You can also get "show original". Click that and a new tab opens to show the raw plaintext of the message, including the e-mail headers and, if the message is html formatted, the html source code. Basically, this allows you to see through all the tricks that illegitimate mailers use to make you think a message came from someplace else.

One is from

bounce-long-string@bounce.chrysler-email.mar0.net

Who is mar0.net?

It uses links in

 http://www.feedbackpage.com/

Who are they?

And it says in the plain-text part,

PLEASE DO NOT REPLY TO THIS EMAIL. Your message will not be read. Instead, please contact us by phone at the Customer Assistance Center:

Have you ever tried calling a 1-800-number from Japan? It doesn't come free.

And it tells me the VIN of the car and gives me a PIN to register the car at

moparownerconnect.com

I remember Mopar from when I drove that Colt. Bought fan belts and distributor caps and carburetor kits from them.

But moparownerconnect is not the way to do a domain name. They could have that as a vanity domain and have it redirect to

ownerconnect.mopar.com

and that would make much more sense. But the domain should be in mopar.com.

WAITAMINUTE!

I don't own that car. But now I know the VIN. If I were a black-hat wannabee, I could cause them some serious customer problems.

No. They should not have sent me that. Not until after they had verified, probably by phone, that the real customer was getting his mail, at least. (And I wouldn't put it in unencrypted e-mail anyway. Sometime I need to blog about how to do that with the current mess, and the technical/marketing/political barriers to doing it right.)

Yes. It is important to understand what I'm trying to say in this over-long blog post.

The other has similar issues, but different.

Their contractor seems to be exacttarget.com.

exacttarget.com seems to think plaintext is evil. That is, there is no plaintext, just HTML that looks almost deliberately obscured.

And they seem to think shortened urls in e-mails are cool. Don't do that. shortened urls tell you nothing, and you really should never trust them.

Well, a shortened url within a known domain might work, I suppose. Perhaps something like

shortA0194.cdjr.com

would be reasonable, if cdjr.com were publicly advertised on the Chrysler, Dodge, Jeep, and Ram websites and in the dealers' show windows as being a shorthand site for all four brands.

There's more in this vein, but I think the above illustrate some common traps that should be avoided by users of e-mail, on both sides of the corporate divide.

Mind you, I have nothing against Chrysler/Dodge/Jeep/Ram or their dealers. And I am going to try to contact them again so they can fix this stuff. I think, if I can explain things reasonably enough, they'll be willing to go to the effort of using their domain names correctly.

Who is going to contact the other nine hundred and ninety-nine domain name abusers, I don't know.

Splitting the Return Addresses out of the Parameters

[I think I'm done editing now.]

My previous post here and some recent posts on misc@openbsd got me thinking again about significantly mitigating buffer overflows and the like by properly separating the parameters and the return addresses into separate stacks.

I posted my thoughts and asked for suggestions. Philip Guenther pointed out that I needed to unpack my thoughts a bit better.

I responded to several of his points, but I was asleep at the keyboard and didn't get my example of a function call using the separated stacks posted in my reply.

I don't want to add to the chatter on list, so I decided to unpack things here.

This is a lot more work than it seems on the surface.

First, typing in Euclid's method for greatest common divisors was faster than looking it up someplace where I've typed it in before:
Then I compiled to assembler. Don't even have to think to do that:

cc -Wall -S gcd.c

Then I modified the internal gcd() routine to use a separate parameter stack.

Here's how to call the gcd() routine:


-------------------------------

         subl    $2*4, %ebp      /* allocate parameters */
         movl    3*4(%ebp), %eax /* copy n2 for the call to gcd */
         movl    %eax, 1*4(%ebp)
         movl    4*4(%ebp), %eax /* copy n1 for the call to gcd */
         movl    %eax, (%ebp)
         call    gcd             /* return address on the flow-of-control stack */
         addl    $2*4, %ebp      /* de-allocate parameters */
 
 /* Recover the return value. */
         movl    %eax, (%ebp)    /* move the result to divisor */

-------------------------------

Here's the gcd() hand-compiled to access it's parameters on the parameter stack: 

-------------------------------

 gcd:
         pushl   %ebp    /* Frame for unwinding */
         subl    $4, %ebp        /* Locals */
         jmp     .L2
 .L3:
         movl    4(%ebp), %eax   /* numA */
         cmpl    8(%ebp), %eax   /* numB */
         jge     .L4
         movl    4(%ebp), %eax   /* numA */
         movl    %eax, (%ebp)    /* temp */
         movl    8(%ebp), %eax   /* numB */
         movl    %eax, 4(%ebp)   /* numA */
         movl    (%ebp), %eax    /* temp */
         movl    %eax, 8(%ebp)   /* numB */
 .L4:
         movl    8(%ebp), %eax   /* numB */
         subl    %eax, 4(%ebp)   /* numA */
 .L2:
         movl    4(%ebp), %eax   /* numA */
         cmpl    8(%ebp), %eax   /* numB */
         jne     .L3
         movl    4(%ebp), %eax   /* numA */
         popl    %ebp    /* Restore previous frame */
         ret

-------------------------------

(I'm not putting the full source of that up here because I'm lazy. Sorry. This is taking more time than I have.)

That wasn't too bad, but it really didn't answer Philip's objections.

From there, things got time consuming.



Providing shims to the C library functions was easy. I put generalized shims at the top of the assembler file because it was easy, but the generalized shims require loading the call address to %eax before calling the shim. Specific shims would be one instruction shorter and faster on the call, but would (potentially) require more shims, depending on how many calls of each number of parameters occurs.

There are other ways to do the shims, of course, but the shims should go away once the whole OS is compiled with the separated stacks.

Tracking which variables were where, so I could demonstrate the shims by keeping them all on the parameter stack that I allocated, required a lot of grunt work -- hand de-compiling and re-compiling.

And the comments I inserted were for my own benefit, more than for yours. Without them, I could not have tracked the variables on the stack. Thankfully, current gcc makes it easier, allocating the whole rack of local variables at function entry. I should have done the same, but I found it easier to focus on small bits of code at a time.

Note that I initially just used calloc() to allocate space for the parameter stack in a c source file I called gcddummy.c, and then shifted to using mmap, so I could map the stack up high, around 64M below the return address stack.

Placement of the two stacks requires some thinking. Putting the parameter stack above the return address stack will leave you vulnerable to certain kinds of collisions, primarily deep recursion with large local variables.

Putting the parameter stack below the return address stack will leave you vulnerable to buffer overflows more than recursion -- large overflows, that is, in the 64 megabyte range in this example. A 256M gap would be even better, but the theoretical vulnerability remains.


I chose below because it would have been much more work to move the return address stack down.

But there should be a gap of unallocated memory between the stacks, and the illegal access exception that should happen (if you have proper memory management hardware) when a buffer overflow hits the gap should prevent anything more than a denial of service to the attacker.

Recursion may be more difficult to handle, but, if the OS provides automatic extension of the stack, one might hope that it would also provide some way to detect such recursions.

Anyway, ultimately, the OS should support the second stack, so that the compiler and the source code programmer won't have to deal with the allocation, other than compiler switches for the rare case when the default size or placement of the gap is not desired.

64-bit addresses, even if not fully decoded, should help with the collision issues.

This looks pretty simple.

The problem is that no current compiler I know of does it this way. That means I have to write such a compiler myself, or I have to go find the production rules in the source of an existing compiler and see whether I can successfully modify the function call and return and parameter access without breaking the compiler.

Learning (finally) how to use compiler-compilers and lexical analyzers would be the easy part. Not breaking the compiler is the hard part.

Writing a new compiler myself might be easier, considering how familiar I'd have to get with the compiler of choice.

And then I would have to go digging through the library source, looking for all the places that directly access the stack and fixing the code that avoids the return address that isn't there any more. va_arg is just the tip of the iceburg.

It's a big project, but I think it needs to be done. It's just too easy to walk on the return addresses (and do bad things with them) otherwise.

Now it doesn't fix the general problem of using buffer overflows to modify the behavior of programs, it just makes the easiest way to do so significantly harder.

It also opens the C language to some paradigms that are currently blocked, and those paradigms just happen to make it easier to write robust programs. But that is a discussion for a later date.

Converging CPU Models on the 68K Model?

Around 1986, I was talking with a fellow student at BYU about the CPU wars that "everyone" knew had finally (Oh, the relief!) been declared in Intel's favor.

(Do not listen to the salesmen when they tell you their product is the de-facto standard. They are usually exaggerating, but, if they aren't, you should throw them out on their ears. "Everybody does it!" is never a good priority argument.)

I told him that the industry would find itself painted into a corner with the 80x86, and everyone would find themselves having to convert their code to the 680X0.

On the one hand, I did not reckon on Intel being willing to waste as much money on the race to shrink, and on implementing self-fulfilling prophecy heuristics, just to keep their brain-damaged intellectual property somewhat competitive in apparent performance.

If the same amount of money were spent on shrinking and optimizing ARM, there would be no contest at all. Likewise on Freescale's ColdFire.

AMD's 64 bit "extension" to the INTEL 80x86 model basically saved INTEL's bacon.

And this is what is amusing about this whole thing: All the successful modern processors have ended up looking a lot like the 680X0 -- about 16 internal mostly orthogonally accessible general-purpose registers, and a control-flow stack model somewhat supported in the silicon.

If you don't have enough registers (see the 6800), or if the registers are not orthogonal and general-purpose (see the 8080 and 8086), you tend to waste a lot of instructions in moving data between the registers where you will work on them and the temporary storage where you keep intermediate results. Extra code is extra processing time. And it's extra space in cache, which is extra time moving code in and out of cache.

But if you have too many registers (see all the true "RISC" processors and most modified RISC such as the PowerPC), maybe you don't have to waste time getting data in and out of registers, but you lose on code density. The instructions are bigger and they often don't quite do enough, so you end up using more. And that means that you end up with more code to move in and out of cache again.

And it's actually getting the code in and out of cache that generally dings your performance most in general purpose computing. (Embedded applications that don't depend on cache take less of a hit, but the problem of instructions that don't quite do all that you want them to do, requiring more instructions to finish a calculation, still ends up being a trade-off.)

So, there it is. Look at the AMD64 and the first thing you notice is that they generalized the registers in the 80x86 model. Lots of talk about register-renaming, but the biggest thing was making the register set orthogonal to the instructions. Then you notice that they added eight registers somewhere along the line.

We spend a lot of money and time in keeping our code in the intermediate level C language or higher level languages, so that moving to a new CPU is just a compile away.

And the high-level code eats away at performance, too, so we waste a lot of money on bad attempts at optimizing the compilers and interpreters.

Now, we gain quite a lot in developer efficiency by giving up some of the performance to higher-level source code. So higher-level code is actually a good trade-off.

Even though I was wrong in details, I was essentially right. The current most successful "desktop" CPU looks a lot more like the 680X0 than the 80x86, and that CPU competes well in the server market, as well. The code that it spends most of its time running is not 80x86 code any more.

And the most successful CPU overall is the ARM, which also looks a lot more like the 68K than the 80x86. (Low order bytes first is a bit of brain damage that still has to be exorcised from the industry. The more we deal with multi-byte character sets, the more people will realize why.)

Motorola wasted a lot of resources in the CPU war, trying to keep the 680X0 ahead of the 80x86 in salescrew friendly features, many of which turned out to be less-than-useful.

The most important features (full 32 bit branching and a reliable exception model) were implemented in the 68010. Many of the advances between the 68020 and the 68060 actually came in the form of getting rid of features in ways that didn't penalize customers too much when they had blindly used those features.

And ColdFire, which is Freescale's more modern descendant of the 68K, gets rid of even more of the fluff features from the feature wars, and improves the exception model significantly. ColdFire is actually competitive with the ARM architecture in performance and power curve at the same level of shrinkage.

(AMD64/80x86 is only competitive on the power curve in salesperson's dreams, and, even that, with serious handicaps forced on ARM designs by the prevailing INTEL-leaning customs of the industry.)

There is lots of irony in history, and the computing industry is no exception.

---

Looking ahead, there is one more big irony that I see. When we understand the run-time model a bit better, we will quit interleaving the flow-of-control (return address) stack with the data stack.

Which 8 bit processor of a bygone era had two stacks?

By the way, here's a minimal execution (register) model I see as optimal:

• Two accumulators, fully orthogonal, to allow tracking intermediate results of two different sets of calculations without hitting the memory bus;
• The ability to concatenate the accumulators to work with double-width integers and pointers;
• Two index registers, fully orthogonal, to allow referencing a source and a destination non-scalar without having to save and restore pointers;
• Fully indexable data stack, so that accessing local variables on the stack doesn't require stack manipulation or using an index register;
• Flow-of-control stack independent of the data stack, to get rid of the problems that happen when return addresses are overwritten by data;
• It would be preferable to keep the return addresses in a memory area protected from normal access;
• Local, per-task static allocation area for variables that are not accessed concurrently ("thread" local in current vernacular);
• Global static allocation area for constants, code, and variables that need to be guarded by some sort of mutual exclusion;
• Indexable program counter for calculated jump tables and constants buried in code.

Which archaic 8-bit processor fits this description almost to a "t", if you overlook the clumsiness of the 8-bit direct page register and the lack of a bus signal to indicate when a return address is being pushed or popped? Heh.

I've found that this model supports pretty much all the hand-optimized code I've produced without excess data movement, and allows a very compact machine code expression.

Now, the 6809 doesn't quite fit this model. The direct page register can't be indexed, which is okay for compiled code but not interpreted.

And it doesn't have a separate address space for a return address stack. I have a vague memory about something in the timing diagrams that might allow synthesizing a separate address space, but that's probably wishful thinking. I don't have timing diagrams handy, so I can't check.

Also, the 16 bit address limits are a bit tight.

If having products of your own company that compete with each other were a bad thing, Motorola would have been right to have de-emphasized the 6809.

But look at Freescale's current lineup. PowerPC, ColdFire, ARM? They essentially have three of their own products competing directly with each other in a lot of target product spaces.

When any two are less popular, the third keeps things stable.

The only problem here is that Freescale's salescrew have to educate themselves a bit more about the lineup. That's actually a good thing, because there is nothing more damaging to an industry than a pack of lazy salespeople.

The 68K can be programmed to fit this model, with a bit less compact machine code, except for the separate address space for the return addresses. (Again, I need to check the timing diagrams and, with certain members of the 68K family, the memory access function codes, to see if there might be some way to cache the stack.) Still, with a 32 bit address, you can get the return addresses far enough away from everything else that accidentally overwriting the return address becomes much less common, and most of the attacks on code that involve buffer overruns and such to overwrite the return addresses become very difficult.

The 68K provides other ways to concatenate small integers, so natural concatenation of accumulators is not necessary.

The PowerPC (which Freescale manufactures in cooperation with IBM) can be programmed to fit this model, too, but it usually isn't. Too many registers go unused. (It would be an interesting research project into register counts to compare the results of compiling to the large register set, single stack model on the PowerPC is more efficient than compiling to the above model. Note that the PowerPC code density is about 50% of the 68K at best.)

The ARM (which Freescale also manufactures under license) can also be easily mapped to this model. 64 bit ARM should allow even better separation of the return address stack from other parts of memory.

Renesas's SuperH has some odd non-orthogonalities that require a bit of intimacy with the processor, but it can be mapped to this run-time model as well.

80x86? Not so much. Too much funky stuff happening when you aren't expecting it, too much optimizing to the standard C runtime model which INTEL helped create. AMD64, on the other hand, should map rather well to the model. Maybe, if the register renaming doesn't get too much in the way.

Now, for the 68K, ARM, SH3, and other processors with a bit more registers than you need, the extra registers can always be used.

• A third index register allows one to access two sources and a destination without having to save and restore index registers.
• An extra index register could be used to differentiate between global constants and global variables. Yet another could be used for linking to global or parent process callbacks, particularly those for maintaining concurrent access coherency -- semaphores, monitors, mutual exclusion code, etc.
• Another index register could maintain a second data stack, to separate parameters from local variables. (It's an artificial distinction, I know, but there are many distinctions not required by the math that help optimize code and execution.)
• You might even dedicate an indexable registers to token threaded interpreter virtual instruction-code list execution.

Returning to the separate stack that is currently not part of the standard C runtime model, another benefit of a separate stack is reduced function call overhead. Since the return address is elsewhere, call frames really don't need special maintenance. If there is no need to walk the variable space of the calling routines, no frame pointers need to be generated at all.

A downside is that it adds a separate page for memory management functions to keep track of, with the added complexity of the operating system needing to make sure the return address stack and the parameter stack both always stay in memory while the process is in memory.

However, if the CPU manufacturer could be convinced to help just a little, the return address could be cached in a dedicated stack-oriented cache, and the return address page management could be greatly simplified, compared to the rest of memory. Careful caching could basically postpone, or even eliminate most of the remaining overhead of subroutine calls, reducing the overhead to the cost of the two ordinary jumps.

In addition, the return address stack does not have to maintain coherence with external memory. Spurious writes to the cache (in other words, not from the instruction fetch mechanism) could be silently dropped, or could trigger a memory access violation.

(Certain kinds of exception processing are usually done be re-writing return addresses, but there are other, better ways to do that on a decent CPU.)

I'm going to make another wild prediction. Once people get used to having 16 registers to use as the code needs it, instead of being restricted to the standard C model that INTEL helped converge around their 80x86 execution model, we'll see more multi-stack solutions. One of the first splits will be the flow-of-control stack.

(More about this model some other time.)

No Gestures Please! The Tablet UI Is Not a UI.

When I first tried an iPad at the Apple Store in Shinsaibashi (Why does the facade of that store remind me of the 1984 commercial?), I found the interface a disappointment.

I have since purchased an Android tablet. Since I paid money for it, I have been motivated to learn how to use it.

I keep finding places that contradict user interface design principles in disturbing ways. Maddening ways. Ways that make me shrug and say, oh, well, I guess I didn't want to do that anyway.

One thing a user interface should never do is delete, without recourse, without confirmation from the user.

Today, I was answering a post on the debian-user mail list. Someone had asked about stable desktop software for ARM processor machines, and noted that the only currently stable, installable desktop is XFCE4. I was going to respond with a note that I find XFCE good enough, significantly more useable than Gnome3.

The screen is dirty. Okay. I know that dirty screens cause problems.

The system hit some snag, where it couldn't track in real time to my attempt to push the message up the screen so I would have room to type. As a result, the tablet interpreted my effort to drag as a "gesture" that means "Throw this away!"

Unfortunately, it was not even kind enough to put the thing in the trashbox.

While I was searching for it, I discovered another post that apparently had made it to the trashbox in response to some misinterpreted gesture. I tried to select it and use a pop-up menu to put it back in the debian mail list folder, but the system hiccuped again. And it interpreted its own hiccup to drop the post in a random folder. I think I was able, after wasting several minutes, to find the second post and put it back where it belonged.

This is scary stuff.

Well, maybe not completely evil. One of the problems with computers is that it's easy to think they allow us to become control-freaks with impunity. God needs ways to keep us humble, and to remind us that some uses of our time are more wasteful when we accomplish what we intended to accomplish.

Still, there is a fundamental problem with gestures as a part of the UI. Even if I train the machine, a flick that means "toss it in the round file" in one place may just mean "Move up the message thread tree" in another.

And if the the CPU hiccups (because of events like a packet arriving at the wireless port, say), it's literally impossible to track a gesture meaningfully.

Trackpads, with their tap interface and more recent scroll interface, are hard enough to control. But this goes beyond getting used to.

Touchscreens have been heralded as the replacement for the mouse. Heaven help us should that happen.

What is a user-id?

Digging through posts I have started and failed to finish, I found a sub-thread I started on the Fedora list, trying to explain the difference between a system user, as represented by a user-id, and the human whose hands are on the keyboard:

http://lists.fedoraproject.org/pipermail/users/2012-April/416380.html

When you hear/see the word "user" it's only natural to think in terms of a human user. So, when you think of a user-id, there is a tendency to think of your school ID card or your driver's license certificate, or such.

But there are lots of user-ids in use on your computer. Whose are they all? Who let them in there? Why?

Maybe we should have used Latin words for the computer jargon, instead of borrowing from living languages. Dead languages are convenient. Or maybe we just could have made up new words. In this case, virtual-user-role-to-manage-a-related-collection-of-tasks, or VURTMARCOT. Shoot, just the acronym is long enough we want to take it out behind the barn and shoot it. I don't want to be talking about a VURTMARCOT-identitfier-number every time I try to figure out what is happening in my system.

So, let's just say that most of the user-ids on your computer are VURTMARCOTs and keep using the term, "user-id", instead.

No?

Uhm, okay, first we have to explain. When your system is running, there are lots of different things going on inside it. Hundreds and thousands of things. The impression that you have that it is complicated is not incorrect. That means that there has to be programs in there to manage the complexity, so that you don't have to. Lots of programs. So many that even the programs to manage the complexity have to be managed.

(Did I really have to say that? I think so.)

So we collected some of those things according to how they are related, and we gave that collection an id number, and we called it a user-id, and we invented  the concept of a (virtual?) system user to manage those things. And we ended up with lots of those system user-ids.

Now, if the system has lots of user-ids for its use, why shouldn't you?

One login user-id for when you are playing around, one for when you are working at your new job, one for the old job, one for when you are going to the bank, one for when you are keeping track of your family records, ...

Well, it's a little inconvenient, because you really don't want to log out and back in every time you shift gears. It's not just a hassle, either, because sometimes what you were playing with turns out to be useful for work, and you want to copy-and-paste from your play area to your work area.

I've blogged about a way to do that. The information is a little old, and I should post an update, with some of the options that I've found to (sort-of) work. But not today.

So, what is a user-id? It's an identifier (both a number and a mnemonic name) that you use to keep track of what's going on in your computer. You may have more than one user-id per human user, and you have lots of user-ids that have no human user.

And you should, in fact, have at least one login user-id for administration tasks, separate from the one you usually log in on to work or whatever.

Who was the first programmer?

My wife asked me and my son to change some carpet that had two desks and a chest of drawers on it. I was not enthusiastic, my son even less so. Took two hours or so, moving the furniture around in a Japanese apartment with limited space.

My son was making quite a bit of fuss about the hassle of moving desks and chairs and other things this way and then that way and then back again, just to get the carpet in place, so I mentioned that computer programming often has similar problems to solve -- updating or changing software underneath live data in a limited space without damaging things, with minimum interruption to access.

My wife heard that and asked a very interesting question:

Who was the first programmer?

Well, that question has many answers.

Ada Lovelace, who wrote a program for Charles Babbage's analytical engine, is generally considered to be the first (modern) programmer, but she was never able to see her program run on actual hardware.

Konrad Zuse is the first person generally known to have programmed a modern computer. (His work was in wartime Germany was overshadowed by the more publicly known work on the ENIAC in the US.)

The members of the ENIAC programming team are often considered to be the first group to work regularly as computer programmers.

The job of a programmer would be most accurately described (in my opinion) as implementing abstract descriptions of processes as (or in) functioning (real) systems. Since the goal is to obtain a functioning system, debugging (fixing errors in the implementation) is part of the job.

Refining or optimizing the implementation would be an optional part of the job.

The computer industry has a habit of trying to limit the definition of a computer system to the whatever can be currently manufactured and sold, but they also have a habit of trying to be the first to expand that definition into new areas. (Call the other guys' work irrelevant until you have duplicated it, then claim you are first, faster, or some other way more deserving of customers' money.)

Anyway, I see no particular reason to limit the definition of a system to whatever the computer industry is currently manufacturing and selling.

Expanding the definition of a system a bit, it becomes clear that teaching is part of the programming process. I don't want to call it an example of programming, because teachers cannot directly do the implementation part. The students themselves have to do that. (Or, rather, if the teachers don't allow the students to do the actual work of implementation, they impede, rather than assist, the processes of learning.)

Learning, on the other hand, is a programming process. So is invention. Practically every thing we do involves programming.

And now we see why my wife asked the question.

So, who were the first programmers? Can I suggest it goes back as far as human history?

Maybe even before human history, back to God? (Or, back to the parameters of the big bang, if you think that invoking gods is an anthropomorphic activity?)

Things to Fix in E-mail, Newsgroups, and Mailing Lists

I've posted a bit of soapbox-ing on the Debian User list over the last few weeks. One of my rants was about e-mail and mailing lists and the fact that they must change in both form and function. I was asked off-list about what I had in mind, and I guess it's just as well that I should post here, so that the answer is public, but not cluttering up the list further.

(More of the thoughts that have lead me to my current opinions here.)

First-off, current e-mail is actually pretty good, for people who are willing to understand the interface and take responsibility for their own use. Both imap and pop provide methods for checking message headers and deleting messages without actually downloading messages. At the GUI level, Sylpheed, for instance, has the

message -> receive -> remote mailbox 

menu item, which allows you to sort by subject, sender, and date, in addition to deleting or downloading individual messages.

Since spam tends to clump together under a sort, sorting helps greatly at handling spam without actually setting up complex filtering systems. I can clear about a thousand spam messages in about fifteen minutes to a half-hour and not worry about false positives, etc. (This won't work for everyone -- It took me several years to tune my mental filters and visual scanning techniques.)

But, speaking of spam, there you have it. Senders of unsolicited commercial messages are on questionable moral and ethical ground, and the unsolicited pseudo-commercial messages we call spam, mostly fraud or worse, are definitely cases of irresponsible use. The tendency to respond to messages that shouldn't be responded to is also a case of not-really responsible use, whether answering a message about some unknown wanting to give you money or joining in a mail-list flame war.

If current e-mail protocols and usage were sufficient for mail lists, I think we would have no need for either twitter or facebook. The biggest problem with e-mail and mailing lists is that there are always going to be irresponsible users. Even in the early days of the internet, when the users were all military researchers and academics, you'd have (for example) the occasional professor deciding he needed to get the broadest possible audience for something he was doing and address-span mailing every address in his address files.

It's not so much the volume as the lack of human judgement about which addresses to use.

With physical mail, the volume issue is significantly offset by the cost of sending physical junk mail. That's the biggest reason it usually takes more than a week of failing to empty your mailbox to cause it to explode. But if we think of a way to make mass e-mail cost, e-mail is suddenly less valuable because we then start worrying about the cost of our daily conversations.

And then there's the problem of knowing who it really is you are talking to.

We have these things called certificates, that are supposed to provide us assurance of the identity of the other guy. But they don't really work because of companies that would rather make money than provide a service, and we can't use them to tell for sure whether the message we just got really is from the person it says it is from. Without such methods, all we have to work from is the contents of the "From" header and the contents of other headers that ostensibly describe the path that the message took on its way to our in-box. And all those headers are easily forged.

With a physical envelope, we really have no way of knowing that the return address on the envelope is for real, unless the letter is sent as registered mail. (And even then we aren't quite sure.) But the content of the letter has out-of-band clues, like the hand-writing, that can help us be sure.

In current e-mail, we have neither registered mail nor handwriting. The closest thing we have to registered mail is the logs on the servers that the message has passed through. If you don't any of the servers on the path, you can't trust the path itself.

Other out-of-band stuff like pictures require html format messages, which are dead easy to use a variety of forgery techniques with. The problems are inherent in the methods we use to encode the data in the messages. ASCII and its descendants, including Unicode, don't really provide good, standardizable methods for burying identifying information in the messages. There are cases where we don't want identifying messages in our messages, but there are cases when we very much want to know who we are talking with and want them to know who they are talking with.

Back to the size issues, individual messages are generally not all that large, but when you have a lot of messages from a mail list or newsgroup, the size adds up quickly. Non-requested advertisements add up even more quickly.

Mailing list and newsgroup browsers (or the mailing list mode of your MUA) should not download the thread headers unless you request a thread listing. (And they should respect the thread-related headers, to avoid breaking threads.) And they should not download a message unless you actually request the message.

But it's often hard to tell whether you want to download a message until you've read it and decided you know who sent it, or decide you are interested in it. Since you can't read it without downloading, you're often stuck with downloading anyway. (I'm only successful in my methods of checking the headers from years of practice. If I try that with a new newsgroup or mail list, however, it's going to take a little while to learn that group/list's patterns.)

If we can put reasonably useful identifying headers in a message, and if our MUA can read those headers, we can at least make meaningful judgments about who wrote the message. And that can help us decide whether to download a message, and help us reduce our bandwidth use. (And save us time.)

The more I've used e-mail, the more I find myself storing it the same way I store newsgroup and mailing list messages -- by thread. (And that is one of the reasons I can generally identify spam just by the headers fairly quickly.)

These identifying headers require the cooperation of the mail servers and internet service providers. But the providers and servers are not interested in their users' efficiency. That does nothing to help their bottom line, and in many cases (think wireless) what is inefficient for users makes providers money. Counter-motivation here.

Until we start serving our own mail, and managing our own connections to the internet more directly, e-mail, newsgroups, and mailing lists will remain as they are, rivers where users are dragged along in the flow, instead of tools for the benefit of users. But the technology to allow ordinary users to do so is still not there.

(I think this post is getting a little closer to what I've been trying to say about the internet, and computers, for a long time, but I'm still not quite there.)