Jorge Martinez de Salinas

Today I tried to extract documentation from source code programmed in Visual Studio using doxygen. The Latex document didn’t compile correctly because of encoding problems. Googling for a solution I’ve discovered that Visual Studio may include some strange characters in the saved files.

To fix the files I’d recommend using an Hexadecimal Editor. In my case I’ve chosen hexedit. Opening the file with Hexedit shows those unwanted characters at the beginning of the file. By removing them and saving the file the problem with Latex disappeared. Hope it helps in case someone runs into the same issue.

If you need to open a file from the command line (e.g. a PDF file) you can use the open command:

open -a Preview filename.pdf

In general working from the console is fast and effective, specially if you combine it with bash scripting skills.

Microsoft has published a research paper on a browser that uses different processes to isolate page content elements. It builds on the concept of multiprocess browsing but goes one step further and uses more fine-grained isolation to expand on the security advantages that are already included in Chrome and are being developed in Firefox. This is the paper’s abstract. The full article can be found here.

Original web browsers were applications designed to view static web content. As web sites evolved into dynamic web applications that compose content from multiple web sites, browsers have become multi-principal operating environments with resources shared among mutually distrusting web site principals. Nevertheless,no existing browsers, including new architectures like IE 8, Google Chrome, and OP, have a multi-principal operating system construction that gives a browser-based OS the exclusive control to manage the protection of all system resources among web site principals.

In this paper, we introduce Gazelle, a secure web browser constructed as a multi-principal OS. Gazelle’s browser kernel is an operating system that exclusively manages resource protection and sharing across web site principals. This construction exposes intricate design issues that no previous work has identified, such as cross-protection-domain display and events protection. We elaborate on these issues and provide comprehensive solutions.

Our prototype implementation and evaluation experience indicates that it is realistic to turn an existing browser into a multi-principal OS that yields significantly stronger security and robustness with acceptable performance.

Google has announced its new Operating System – Google Chrome OS. According to the Official Blog:

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010.

Google Chrome OS will run on both x86 as well as ARM chips …

The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies …

We hear a lot from our users and their message is clear — computers need to get better. People want to get to their email instantly, without wasting time waiting for their computers to boot and browsers to start up. They want their computers to always run as fast as when they first bought them. They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files. Even more importantly, they don’t want to spend hours configuring their computers to work with every new piece of hardware, or have to worry about constant software updates…

Another step further towards the Google World Domination?

To include less than (<) and greater than (>) symbols in your Latex document enclose them in dollar signs:

This is the less than symbol $<$ and this is the greater than $>$ symbol.

Generally, Mac applications come with code for architectures you don’t need (e.g. PowerPC code) and with many languages you don’t use. Xslimmer removes these unneeded features, saving a great amount of disk space. In my case I’ve recovered 3GB, impressive huh?

To start the video streaming execute:

# vlc -v -I rc movie.avi --sout "#standard{access=http,mux=ogg,dst=npserver.labplan.southpark:8080)

Since we’re using the remote control interface (-I rc), we don’t need a graphical environment. This feature is specially useful if we want to stream the video without starting an X Window session.

On the client side execute the following command to receive the stream:

# vlc http://npserver.labplan.southpark:8080

If the DNS server isn’t installed on your Linux box, install it with the following command:

yum groupinstall "DNS Name Server"

We need to configure two things. First we need to specify the domains we’re going to resolve in named.conf. We will resolve the labplan.southpark domain.
Our DNS server will support both direct (name->ip) and reverse (ip->name) resolution.

According to APNIC the use of ip6.int is deprecated in favor of ip6.arpa for
reverse resolutions. However, since many programs still use it, we’re going to define
the ip6.int version as well. We need to add the following lines to named.conf:

zone "labplan.southpark" IN {
type master;
file "labplan.southpark.zone";
};
//deprecated
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.int" {
type master;
file"reverse-fec1_64i.IP6.INT";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.arpa" {
type master;
file "reverse-fec1_64.IP6.ARPA";
};

Next we have to fill the zone records. The information for direct resolutions is stored on labplan.southpark.zone:

$TTL    86400
@               IN SOA  @       root (
		42              ; serial (d. adams)
		3H              ; refresh
		15M             ; retry
		1W              ; expiry
		1D )            ; minimum
 
          IN NS           ns6.labplan.southpark.
 
 
ns6		 IN      AAAA    fec0::20c:29ff:fe8f:8f16
customer	 IN      AAAA    fec0::20c:29ff:feff:4b37
npserver	 IN      AAAA    fec0::20c:29ff:fe4a:fae0
an		 IN      AAAA    fec0::20c:29ff:feb4:bee2

The PTR records used for reverse resolution are stored on reverse-fec1_64i.IP6.INT (deprecated ip6.int) and reverse-fec1_64.IP6.ARPA (recommended ip6.arpa). This is the ip6.arpa zone (to edit an ip6.int zone just replace arpa with int):

$TTL 3d ; Default TTL 
@       IN SOA 0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. root (
                200906170       ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL 
)
                                IN     NS     ns6.labplan.southpark.
7.3.b.4.f.f.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR costumer.labplan.southpark.
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR npserver.labplan.southpark.
2.e.e.b.4.b.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR an.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR gw.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR ns6.labplan.southpark.

From this moment on everything should work fine. We can check the name resolution with dig:

# dig @::1 -t AAAA npserver.labplan.southpark
;; QUESTION SECTION:
;npserver.labplan.southpark.    IN      AAAA
 
;; ANSWER SECTION:
npserver.labplan.southpark. 86400 IN    AAAA    fec0::20c:29ff:fe4a:fae0

To check reverse resolution use dig’s -x flag:

#dig @::1 -x fec0::20c:29ff:fe4a:fae0
;; QUESTION SECTION:
;0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.INPTR
 
;; ANSWER SECTION:
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. 259200  IN  PTR  npserver.labplan.southpark.

Windows (win’-doze) 3.0/3.1/95/98/2000/ME/XP/Vista/7 (n.): 32-bit extensions to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can’t stand 1 bit of competition.

IPv6 has three types of addresses, which can be categorized by type and scope:

• Unicast addresses. A packet is delivered to one interface.
• Multicast addresses. A packet is delivered to multiple interfaces.
• Anycast addresses. A packet is delivered to the nearest of multiple interfaces (in terms of routing distance).

IPv6 does not use broadcast messages.

Unicast and anycast addresses in IPv6 have the following scopes (for multicast addresses, the scope is built into the address structure):

• Link-local. The scope is the local link (nodes on the same subnet)(FE80::/64).
• Site-local. The scope is the organization (private site addressing)(FEC0::/48).
• Global. The scope is global (IPv6 Internet addresses).

In addition, IPv6 has special addresses such as the loopback address. The scope of a special address depends on the type of special address. Much of the IPv6 address space is unassigned.

One of the most interesting and potentially valuable addressing features imple- mented in IPv6 is a facility to allow devices on an IPv6 to actually configure themselves independently. In IPv4 hosts were originally configured manually. Later, host configuration protocols like DHCP enabled servers to allocate IP addresses to hosts that joined the network. IPv6 takes this a step further, by defining a method for some devices to automatically configure their IP address and other parameters without the need for a server. It also defines a method whereby the IP addresses on a network can be renumbered (changed en masse). These are the sorts of features that make TCP/IP network administrators drool.

The IPv6 autoconfiguration and renumbering feature is defined in RFC 2462, IPv6 Stateless Address Autoconfiguration. The word “stateless” contrasts this method to the server-based method using something like DHCPv6, which is called “stateful”. This method is called “stateless” because it begins from a “dead start” with no information (or “state”) at all for the host to work with, and has no need for a DHCP server.

Stateless autoconfiguration exploits several other new features in IPv6, including link-local addresses, multicasting, the Neighbor Discovery (ND) protocol, and the ability to generate the interface identifier of an address from the underlying data link layer address. The general idea is to have a device generate a temporary address until it can determine the characteristics of the network it is on, and then create a permanent address it can use based on that information. In the case of multi-homed devices, autoconfiguration is performed for each interface separately, as you would expect.

The following is a summary of the steps a device takes when using stateless autoconfiguration:

1. Link-Local Address Generation: The device generates a link-local address. Recall that this is one of the two types of local-use IPv6 addresses. Link- local addresses have “1111 1110 10” for the first ten bits. The generated address uses those ten bits followed by 54 zeroes and then the 64 bit interface identifier. Typically this will be derived from the data link layer (MAC) address as explained in the topic on interface identifiers, or it may be a “token” generated in some other manner.
2. Link-Local Address Uniqueness Test: The node tests to ensure that the address it generated isn’t for some reason already in use on the local network. (This is very unlikely to be an issue if the link-local address came from a MAC address but more likely if it was based on a generated token.) It sends a Neighbor Solicitation message using the Neighbor Discovery (ND) protocol. It then listens for a Neighbor Advertisement in response that indicates that another device is already using its link-local address; if so, either a new address must be generated, or autoconfiguration fails and another method must be employed.
3. Link-Local Address Assignment: Assuming the uniqueness test passes, the device assigns the link-local address to its IP interface. This address can be used for communication on the local network, but not on the wider Internet (since link-local addresses are not routed).
4. Router Contact: The node next attempts to contact a local router for more information on continuing the configuration. This is done either by listening for Router Advertisement messages sent periodically by routers, or by sending a specific Router Solicitation to ask a router for information on what to do next. This process is described in the section on the IPv6 Neighbor Discovery protocol.
5. Router Direction: The router provides direction to the node on how to proceed with the autoconfiguration. It may tell the node that on this network “stateful” autoconfiguration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell the host how to determine its global Internet address.
6. Global Address Configuration: Assuming that stateless autoconfiguration is in use on the network, the host will configure itself with its globally-unique Internet address. This address is generally formed from a network prefix provided to the host by the router, combined with the device’s identifier as generated in the first step. Clearly, this method has numerous advantages over both manual and server-based configuration. It is particularly helpful in supporting mobility of IP devices, as they can move to new networks and get a valid address without any knowledge of local servers or network prefixes. At the same time, it still allows management of IP addresses using the (IPv6- compatible) version of DHCP if that is desired. Routers on the local network will typically tell hosts which type of autoconfiguration is supported using special flags in ICMPv6 Router Advertisement messages.