Begin with a recursive definition of a path: EMPTY is a path and if p is a path and n is a local file identifier then the sequence obtained by appending  n to p (on the left) is a path.  And there are no other paths than the ones that can be built from a finite number of applications of this rule.  We can write “n/p” for the path obtained by appending n to p (appending on the left). Let’s require of course that the separator symbol “/” is not in any local file identifier. Other than that, there is no need to say anything at all about the set of file identifiers now – you can think of it as the set of strings that are “/” free if that helps, but they could be anything at all that is “/” free and can be connected into sequences. And  ”/” is just the name we use for the separator, it can be anything at all too.

UNIX style file systems are nearly always constructed on top of flat file systems. That is, we suppose we have a primitive set of “flat file names” of some sort and a map F that maps flat file names to the corresponding file contents.  Flat file names can be the same as local file identifier or different – it doesn’t matter. Right now we don’t have to say much about these flat file names at all but we have some demands on file contents. In particular, files need to be able to “encode”  lookup tables that relate local file identifiers to flat file names. Since we will require that a local file identifier appear at most once in such a table, we can think of the file contents as encoding a function- the “directory function”.  If “i” is a flat file name and F(i) is defined, we need to be able to associate F(i) with a type: plain or  directory (to start). Plain is just some data. If F(i) is defined, and F(i) has type directory, there is some function d= D(F(i))  we can decode from F(i) so that for some finite set of local file identifiers, “d” maps those identifiers to flat file names.

The idea is that we can start with some flat file name “i” and a path, say,  p=a/b/c and follow p from “i” as follows. First get i’=D(F(i))(a) if F(i) is a directory. Then get i”= D(F(i’))(b) and i”’= D(F(i”))(c) – assuming that the intermediate flat files are directories and they encode functions that map the flat file names “a”, “b” and “c”.  There’s some complexity because we’re not assured that everything will work out – we may only be able to follow a path partway before coming to a dead end.

So define a function R to take a flat file function F, an initial flat file name “i” and a path p and produces either a terminal flat file name or FAIL if the path cannot be followed all the way.  First we do the easy case R(F,i,EMPTY)= i.  The recursive case is

Associate F with a special flat file “r” – the root file. Then we can define U(p) = F(R(F,r,p)) if R(F,r,p) is not FAIL and let U(p)= FAIL otherwise.

And that’s it – except that now the flexible nature of the file system becomes clear. Let’s add a new file type “indirect” so that if F(i) is indirect, then we can extract a flat file map and a root flat file name from the contents. That is, if F(i) is an indirect file we can produce (F’,r’) = X(F(i)) where F’ is a flat file map and F’(r’) is a directory under F’.  Say “i” is a properly defined indirect file under F if and only if F(i) is indirect and for (F’,r)=X(F(i)) we have F’(r) as a directory. We can now redefine R as follows to switch flat file systems on an indirect file.

Note that the first definition of R is obviously primitive recursive – because we lose one element of the path sequence on each recursive step – but it’s not obvious that the version of R with indirect calls must terminate. The final condition on the indirect case assures us that at least every second step must remove one element from the path.

The A5 processor – the brain in the iPhone 4S and iPad 2 – is now made in a sprawling 1.6 million square feet factory in Austin owned by Korean electronics giant Samsung Electronics, according to people familiar with the operation.
One of the few major components to be sourced from within the United States, the A5 processor is built by Samsung in a newly constructed $3.6 billion non-memory chip production line that reached full production in early December

http://www.reuters.com/article/2011/12/16/us-apple-samsung-idUSTRE7BF0D420111216

 

http://en.wikipedia.org/wiki/Dennis_Ritchie

The US military’s unmanned Predator and Reaper drones are continuing to fly remote missions overseas despite a computer virus that has infected their US-based cockpits.
Government officials are still investigating whether the virus is benign, and how it managed to infect the heavily protected computer systems at Creech Air Force Base in Nevada, where US military pilots remotely fly the planes on their missions over Iraq, Afghanistan and elsewhere.
“Something is going on, but it has not had any impact on the missions overseas,” said a source, who was not authorized to speak publicly.
Armed tactical unmanned planes have become an increasingly valuable tool used by the US military to track and attack individuals and small groups overseas, but the virus underscores the vulnerability of such systems to attacks on the computer networks used to fly them from great distances.
Rob Densmore, former US navy airman, told Al Jazeera that the infection was a common keystroke logging virus – which registers the keystrokes pilots use to control the unmanned drones from afar.
“It has to have a point of access, so we know that thumb drives – basically USB drives – are used to upload navigational information, guidance information to Predator and Reaper drones.
“And if there’s a way somehow that that information, or that thumb drive, can come into contact with a network or with the internet, that’s where the danger is because that basically means that information can be carried across from the Reaper drones.”

http://english.aljazeera.net/news/americas/2011/10/201110816388104988.html

Government approach to security can be described as designing an unsinkable boat that has no doors between compartments and then, to make it usable, cutting a random and increasing number of undocumented holes between compartments.

A file is simply an ordered sequence of elements, where an element could be a machine word, a character, or a bit, depending upon the implementation. A user may create, modify or delete files only through the use of the file system. At the level of the file system, a file is formatless. All formatting is done by higher-level modules or by user-supplied programs, if desired. As far as a particular user is concerned, a file has one name, and that name is symbolic. (Symbolic names may be arbitrarily long, and may have syntax of their own. For example, they may consist of several parts, some of which are relevant to the nature of the file, e.g., ALPHA FAP DEBUG.) The user may reference an element in the file by specifying the symbolic file name and the linear index of the element within the file. By using higher-level modules, a user may also be able to reference suitably defined sequences of elements directly by context.

A directory is a special file which is maintained by the file system, and which contains a list of entries. To a user, an entry appears to be a file and is accessed in terms of its symbolic entry name, which is the user’s file name. An entry name need be unique only within the directory in which it occurs. In reality, each entry is a pointer of one of two kinds. The entry may point directly to a file (which may itself be a directory) which is stored in secondary storage, or else it may point to another entry in the same or another directory. An entry which points directly to a file is called a branch, while an entry which points to another directory entry is called a link. Except for a pathological case mentioned below, a link always eventually points to a branch (although possibly via a chain of links to the branch), and thence to a file. Thus the link and the branch both effectively point to the file. (In general, a user will usually not need to know whether a given entry is a branch or a link, but he easily may find out.)

?

Apple’s initial legal victory over rival HTC in a patent infringement suit could pave the way for Apple to collect high royalties from devices running Google Android, according to one analysis.

Mike Abramsky with RBC Capital Markets believes that Apple has the upper hand over HTC, which is a smaller handset maker with a limited portfolio of intellectual property. As such, Apple could potentially push for an injunction and ask the U.S. International Trade Commission to bar the import of HTC handsets.

Instead, Abramsky believes it’s more likely that Apple will try to establish a high royalty precedent on Android devices. He said the iPhone maker could garner a deal that’s similar to or even higher than the $5 per unit that Microsoft collects on HTC Android devices.

From Apple Insider

$5 a unit. Wow.  But Apple has some remarkable technology covered by the patents at issue. For example

When the handler 44 requests a facsimile transmission, for example, the real-time function block issues commands to start the real-time engine and install the various modules that are needed for it to function as a virtual telephone. Binary facsimile image data is transferred to the real-time engine via the FIFO buffers, where it is encoded as PCM data which is further encoded according to the transport medium over which it is to be transmitted. If the adapter is connected to a telephone line, for example, these signals can be encoded as 16-bit pulse-code modulated (PCM) samples, and forwarded directly to the adapter 36 via the serial driver 42 . Alternatively, if the transport medium is an ISDN line, the modem signals are encoded as mulaw-companded 8-bit PCM signals. The different types of encoding are stored in different tables, and the appropriate one to be used by the real-time engine is installed by the real-time function block during the initial configuration of the engine and/or designated by the API 48 at the time the command to transform the data is issued.

Too stunning. There should be a Nobel prize in there – at least. Take a look.

(read/write, diskaddress, buffer_address, count, notification_address)

so that the disk drive controller wrote a completion code in the notification_address when done.  Would that be hard? Why is it that virtualization hardware on modern processors devotes tens of millions of transistors to functionality that is not useful in any sensible virtual machine kernel but makes interrupt emulation into a nightmarish mish mash. Why are obvious bottlenecks in multi-core performance, like snooping caches made more an more elaborate and non-deterministic in operation when it’s been known for 30 years that they don’t scale at all?  Why is it that the painfully obvious design flaws of USB can never be corrected even as it becomes more and more unavoidable?

Eventually, we’ll reach a breaking point where someone builds a Corolla or a Tesla and the manufacturers of power guzzling, unreliable, legacy hardware have to scramble to catch up.

It’s something I do worry about; and I do share your concern. At the same time, the reality is that we are a little like the Old Dutch Masters, who had take into account the preference of their patrons (i.e., in our case, those who pay our paychecks .

One of those rare moments when art, commerce, and engineering collide to produce comedy.