| TOC |
|
This document describes a collection of reference material to which ISC DHCP has been implemented as well as a more complete listing of references for DHCP and DHCPv6 protocols.
Copyright (c) 2006-2007,2009,2011 by Internet Systems Consortium, Inc. ("ISC")
Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
 IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
1.
Introduction
2.
Definition: Reference Implementation
3.
Low Layer References
3.1.
Ethernet Protocol References
3.2.
Token Ring Protocol References
3.3.
FDDI Protocol References
3.4.
Internet Protocol Version 4 References
3.5.
Unicast Datagram Protocol References
4.
BOOTP Protocol References
5.
DHCPv4 Protocol References
5.1.
DHCPv4 Protocol
5.1.1.
Core Protocol References
5.2.
DHCPv4 Option References
5.2.1.
Relay Agent Information Option Options
5.2.2.
Dynamic DNS Updates References
5.2.3.
Experimental: Failover References
5.3.
DHCP Procedures
6.
DHCPv6 Protocol References
6.1.
DHCPv6 Protocol References
6.2.
DHCPv6 Options References
7.
References
7.1.
Published DHCPv4 References
7.2.
Published Common (DHCPv4/DHCPv6) References
7.3.
Published DHCPv6 References
§
Authors' Addresses
| TOC |
As a little historical anecdote, ISC DHCP once packaged all the relevant RFCs and standards documents along with the software package. Until one day when a voice was heard from one of the many fine institutions that build and distribute this software... they took issue with the IETF's copyright on the RFC's. It seems the IETF's copyrights don't allow modification of RFC's (except for translation purposes).
Our main purpose in providing the RFCs is to aid in documentation, but since RFCs are now available widely from many points of distribution on the Internet, there is no real need to provide the documents themselves. So, this document has been created in their stead, to list the various IETF RFCs one might want to read, and to comment on how well (or poorly) we have managed to implement them.
| TOC |
ISC DHCP, much like its other cousins in ISC software, is self-described as a 'Reference Implementation.' There has been a great deal of confusion about this term. Some people seem to think that this term applies to any software that once passed a piece of reference material on its way to market (but may do quite a lot of things that aren't described in any reference, or may choose to ignore the reference it saw entirely). Other folks get confused by the word 'reference' and understand that to mean that there is some special status applied to the software - that the software itself is the reference by which all other software is measured. Something along the lines of being "The DHCP Protocol's Reference Clock," it is supposed.
The truth is actually quite a lot simpler. Reference implementations are software packages which were written to behave precisely as appears in reference material. They are written "to match reference."
If the software has a behaviour that manifests itself externally (whether it be something as simple as the 'wire format' or something higher level, such as a complicated behaviour that arises from multiple message exchanges), that behaviour must be found in a reference document.
Anything else is a bug, the only question is whether the bug is in reference or software (failing to implement the reference).
This means:
That is the lofty goal, at any rate. It's well understood that, especially because the ISC DHCP Software package has not always been held to this standard (but not entirely due to it), there are many non-referenced behaviours within ISC DHCP.
The primary goal of reference implementation is to prove the reference material. If the reference material is good, then you should be able to sit down and write a program that implements the reference, to the word, and come to an implementation that is distinguishable from others in the details, but not in the facts of operating the protocol. This means that there is no need for 'special knowledge' to work around arcane problems that were left undocumented. No secret handshakes need to be learned to be imparted with the necessary "real documentation".
Also, by accepting only reference as the guidebook for ISC DHCP's software implementation, anyone who can make an impact on the color texture or form of that reference has a (somewhat indirect) voice in ISC DHCP's software design. As the IETF RFC's have been selected as the source of reference, that means everyone on the Internet with the will to participate has a say.
| TOC |
It may surprise you to realize that ISC DHCP implements 802.1 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the gap there between these physical and DHCP layers, it must also implement IP and UDP framing.
The reason for this stems from Unix systems' handling of BSD sockets (the general way one might engage in transmission of UDP packets) on unconfigured interfaces, or even the handling of broadcast addressing on configured interfaces.
There are a few things that DHCP servers, relays, and clients all need to do in order to speak the DHCP protocol in strict compliance with [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.).
The above isn't as simple as it sounds on a regular BSD socket. Many unix implementations will transmit broadcasts not to <IP_ADDRESS>, but to x.y.z.255 (where x.y.z is the system's local subnet). Such packets are not received by several known DHCP client implementations - and it's not their fault, [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) very explicitly demands that these packets' IP destination addresses be set to <IP_ADDRESS>.
Receiving packets sent to <IP_ADDRESS> isn't a problem on most modern unixes...so long as the interface is configured. When there is no IPv4 address on the interface, things become much more murky.
So, for this convoluted and unfortunate state of affairs in the unix systems of the day ISC DHCP was manufactured, in order to do what it needs not only to implement the reference but to interoperate with other implementations, the software must create some form of raw socket to operate on.
What it actually does is create, for each interface detected on the system, a Berkeley Packet Filter socket (or equivalent), and program it with a filter that brings in only DHCP packets. A "fallback" UDP Berkeley socket is generally also created, a single one no matter how many interfaces. Should the software need to transmit a contrived packet to the local network the packet is formed piece by piece and transmitted via the BPF socket. Hence the need to implement many forms of Link Layer framing and above. The software gets away with not having to implement IP routing tables as well by simply utilizing the aforementioned 'fallback' UDP socket when unicasting between two configured systems is needed.
Modern unixes have opened up some facilities that diminish how much of this sort of nefarious kludgery is necessary, but have not found the state of affairs absolutely resolved. In particular, one might now unicast without ARP by inserting an entry into the ARP cache prior to transmitting. Unconfigured interfaces remain the sticking point, however...on virtually no modern unixes is it possible to receive broadcast packets unless a local IPv4 address has been configured, unless it is done with raw sockets.
| TOC |
ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant of IEEE 802.2. No good reference of this framing is known to exist at this time, but it is vaguely described in [RFC0894] (Hornig, C., “Standard for the transmission of IP datagrams over Ethernet networks,” April 1984.) see the section titled "Packet format"), and the following URL is also thought to be useful.
http://en.wikipedia.org/wiki/DIX_Ethernet
| TOC |
IEEE 802.5 defines the Token Ring framing format used by ISC DHCP.
| TOC |
[RFC1188] (Katz, D., “Proposed Standard for the Transmission of IP Datagrams over FDDI Networks,” October 1990.) is the most helpful reference ISC DHCP has used to form FDDI packets.
| TOC |
RFC760 (Postel, J., “DoD standard Internet Protocol,” January 1980.) [RFC0760] fundamentally defines the bare IPv4 protocol which ISC DHCP implements.
| TOC |
RFC768 (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] defines the User Datagram Protocol that ultimately carries the DHCP or BOOTP protocol. The destination DHCP server port is 67, the client port is 68. Source ports are irrelevant.
| TOC |
The DHCP Protocol is strange among protocols in that it is grafted over the top of another protocol - BOOTP (but we don't call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP and DHCP share UDP packet formats - DHCP is merely a conventional use of both BOOTP header fields and the trailing 'options' space.
The ISC DHCP server supports BOOTP clients conforming to RFC951 (Croft, B. and J. Gilmore, “Bootstrap Protocol,” September 1985.) [RFC0951] and RFC1542 (Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol,” October 1993.) [RFC1542].
| TOC |
| TOC |
"The DHCP[v4] Protocol" is not defined in a single document. The following collection of references of what ISC DHCP terms "The DHCPv4 Protocol".
| TOC |
RFC2131 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131] defines the protocol format and procedures. ISC DHCP is not known to diverge from this document in any way. There are, however, a few points on which different implementations have arisen out of vagueries in the document. DHCP Clients exist which, at one time, present themselves as using a Client Identifier Option which is equal to the client's hardware address. Later, the client transmits DHCP packets with no Client Identifier Option present - essentially identifying themselves using the hardware address. Some DHCP Servers have been developed which identify this client as a single client. ISC has interpreted RFC2131 to indicate that these clients must be treated as two separate entities (and hence two, separate addresses). Client behaviour (Embedded Windows products) has developed that relies on the former implementation, and hence is incompatible with the latter. Also, RFC2131 demands explicitly that some header fields be zeroed upon certain message types. The ISC DHCP Server instead copies many of these fields from the packet received from the client or relay, which may not be zero. It is not known if there is a good reason for this that has not been documented.
RFC2132 (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) [RFC2132] defines the initial set of DHCP Options and provides a great deal of guidance on how to go about formatting and processing options. The document unfortunately waffles to a great extent about the NULL termination of DHCP Options, and some DHCP Clients (Windows 95) have been implemented that rely upon DHCP Options containing text strings to be NULL-terminated (or else they crash). So, ISC DHCP detects if clients null-terminate the host-name option and, if so, null terminates any text options it transmits to the client. It also removes NULL termination from any known text option it receives prior to any other processing.
| TOC |
RFC2241 (Provan, D., “DHCP Options for Novell Directory Services,” November 1997.) [RFC2241] defines options for Novell Directory Services.
RFC2242 (Droms, R. and K. Fong, “NetWare/IP Domain Name and Information,” November 1997.) [RFC2242] defines an encapsulated option space for NWIP configuration.
RFC2485 (Drach, S., “DHCP Option for The Open Group's User Authentication Protocol,” January 1999.) [RFC2485] defines the Open Group's UAP option.
RFC2610 (Perkins, C. and E. Guttman, “DHCP Options for Service Location Protocol,” June 1999.) [RFC2610] defines options for the Service Location Protocol (SLP).
RFC2937 (Smith, C., “The Name Service Search Option for DHCP,” September 2000.) [RFC2937] defines the Name Service Search Option (not to be confused with the domain-search option). The Name Service Search Option allows eg nsswitch.conf to be reconfigured via dhcp. The ISC DHCP server implements this option, and the ISC DHCP client is compatible...but does not by default install this option's value. One would need to make their relevant dhclient-script process this option in a way that is suitable for the system.
RFC3004 (Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, “The User Class Option for DHCP,” November 2000.) [RFC3004] defines the User-Class option. Note carefully that ISC DHCP currently does not implement to this reference, but has (inexplicably) selected an incompatible format: a plain text string.
RFC3011 (Waters, G., “The IPv4 Subnet Selection Option for DHCP,” November 2000.) [RFC3011] defines the Subnet-Selection plain DHCPv4 option. Do not confuse this option with the relay agent "link selection" sub-option, although their behaviour is similar.
RFC3396 (Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4),” November 2002.) [RFC3396] documents both how long options may be encoded in DHCPv4 packets, and also how multiple instances of the same option code within a DHCPv4 packet will be decoded by receivers.
RFC3397 (Aboba, B. and S. Cheshire, “Dynamic Host Configuration Protocol (DHCP) Domain Search Option,” November 2002.) [RFC3397] documents the Domain-Search Option, which allows the configuration of the /etc/resolv.conf 'search' parameter in a way that is RFC1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [RFC1035] wire format compatible (in fact, it uses the RFC1035 wire format). ISC DHCP has both client and server support, and supports RFC1035 name compression.
RFC3679 (Droms, R., “Unused Dynamic Host Configuration Protocol (DHCP) Option Codes,” January 2004.) [RFC3679] documents a number of options that were documented earlier in history, but were not made use of.
RFC3925 (Littlefield, J., “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4),” October 2004.) [RFC3925] documents a pair of Enterprise-ID delimited option spaces for vendors to use in order to inform servers of their "vendor class" (sort of like 'uname' or 'who and what am I'), and a means to deliver vendor-specific and vendor-documented option codes and values.
RFC3942 (Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,” November 2004.) [RFC3942] redefined the 'site local' option space.
[RFC4280] (Chowdhury, K., Yegani, P., and L. Madour, “Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers,” November 2005.) defines two BCMS server options for each protocol family.
RFC4388 (Woundy, R. and K. Kinnear, “Dynamic Host Configuration Protocol (DHCP) Leasequery,” February 2006.) [RFC4388] defined the DHCPv4 LEASEQUERY message type and a number of suitable response messages, for the purpose of sharing information about DHCP served addresses and clients.
| TOC |
RFC3046 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [RFC3046] defines the Relay Agent Information Option and provides a number of sub-option definitions.
RFC3256 (Jones, D. and R. Woundy, “The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option,” April 2002.) [RFC3256] defines the DOCSIS Device Class sub-option.
RFC3527 (Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “Link Selection sub-option for the Relay Agent Information Option for DHCPv4,” April 2003.) [RFC3527] defines the Link Selection sub-option.
| TOC |
The collection of documents that describe the standards-based method to update dns names of DHCP clients starts most easily with RFC4703 (Stapp, M. and B. Volz, “Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients,” October 2006.) [RFC4703] to define the overall architecture, travels through RFCs 4702 (Stapp, M., Volz, B., and Y. Rekhter, “The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.) [RFC4702] and 4704 (Volz, B., “The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.) [RFC4704] to describe the DHCPv4 and DHCPv6 FQDN options (to carry the client name), and ends up at RFC4701 (Stapp, M., Lemon, T., and A. Gustafsson, “A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR),” October 2006.) [RFC4701] which describes the DHCID RR used in DNS to perform a kind of atomic locking.
ISC DHCP adopted early versions of these documents, and has not yet synchronized with the final standards versions.
For RFCs 4702 and 4704, the 'N' bit is not yet supported. The result is that it is always set zero, and is ignored if set.
For RFC4701, which is used to match client identities with names in the DNS as part of name conflict resolution. Note that ISC DHCP's implementation of DHCIDs vary wildly from this specification. First, ISC DHCP uses a TXT record in which the contents are stored in hexadecimal. Second, there is a flaw in the selection of the 'Identifier Type', which results in a completely different value being selected than was defined in an older revision of this document...also this field is one byte prior to hexadecimal encoding rather than two. Third, ISC DHCP does not use a digest type code. Rather, all values for such TXT records are reached via an MD5 sum. In short, nothing is compatible, but the principle of the TXT record is the same as the standard DHCID record. However, for DHCPv6 FQDN, we do use DHCID type code '2', as no other value really makes sense in our context.
| TOC |
The Failover Protocol defines means by which two DHCP Servers can share all the relevant information about leases granted to DHCP clients on given networks, so that one of the two servers may fail and be survived by a server that can act responsibly.
Unfortunately it has been quite some years (2003) since the last time this document was edited, and the authors no longer show any interest in fielding comments or improving the document.
The status of this protocol is very unsure, but ISC's implementation of it has proven stable and suitable for use in sizable production environments.
draft-ietf-dhc-failover-12.txt (Droms, R., “DHCP Failover Protocol,” March 2003.) [draft‑failover] describes the Failover Protocol. In addition to what is described in this document, ISC DHCP has elected to make some experimental changes that may be revoked in a future version of ISC DHCP (if the draft authors do not adopt the new behaviour). Specifically, ISC DHCP's POOLREQ behaviour differs substantially from what is documented in the draft, and the server also implements a form of 'MAC Address Affinity' which is not described in the failover document. The full nature of these changes have been described on the IETF DHC WG mailing list (which has archives), and also in ISC DHCP's manual pages. Also note that although this document references a RECOVER-WAIT state, it does not document a protocol number assignment for this state. As a consequence, ISC DHCP has elected to use the value 254.
An optimization described in the failover protocol draft is included since 4.2.0a1. It permits a DHCP server operating in communications-interrupted state to 'rewind' a lease to the state most recently transmitted to its peer, greatly increasing a server's endurance in communications-interrupted. This is supported using a new 'rewind state' record on the dhcpd.leases entry for each lease.
[RFC3074] (Volz, B., Gonczi, S., Lemon, T., and R. Stevens, “DHC Load Balancing Algorithm,” February 2001.) describes the Load Balancing Algorithm (LBA) that ISC DHCP uses in concert with the Failover protocol. Note that versions 3.0.* are known to misimplement the hash algorithm (it will only use the low 4 bits of every byte of the hash bucket array).
| TOC |
[RFC2939] (Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types,” September 2000.) explains how to go about obtaining a new DHCP Option code assignment.
| TOC |
| TOC |
For now there is only one document that specifies the base of the DHCPv6 protocol (there have been no updates yet), [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.).
Support for DHCPv6 was first added in version 4.0.0. The server and client support only IA_NA. While the server does support multiple IA_NAs within one packet from the client, our client only supports sending one. There is no relay support.
DHCPv6 introduces some new and uncomfortable ideas to the common software library.
Precisely how to correctly support the above conundrums has not quite yet been settled, so support is incomplete.
| TOC |
[RFC3319] (Schulzrinne, H. and B. Volz, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” July 2003.) defines the SIP server options for DHCPv6.
[RFC3646] (Droms, R., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” December 2003.) documents the DHCPv6 name-servers and domain-search options.
[RFC3633] (Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.) documents the Identity Association Prefix Delegation for DHCPv6, which is included here for protocol wire reference, but which is not supported by ISC DHCP.
[RFC3898] (Kalusivalingam, V., “Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” October 2004.) documents four NIS options for delivering NIS servers and domain information in DHCPv6.
[RFC4075] (Kalusivalingam, V., “Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6,” May 2005.) defines the DHCPv6 SNTP Servers option.
[RFC4242] (Venaas, S., Chown, T., and B. Volz, “Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” November 2005.) defines the Information Refresh Time option, which advises DHCPv6 Information-Request clients to return for updated information.
[RFC4280] (Chowdhury, K., Yegani, P., and L. Madour, “Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers,” November 2005.) defines two BCMS server options for each protocol family.
[RFC4580] (Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option,” June 2006.) defines a DHCPv6 subscriber-id option, which is similar in principle to the DHCPv4 relay agent option of the same name.
[RFC4649] (Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option,” August 2006.) defines a DHCPv6 remote-id option, which is similar in principle to the DHCPv4 relay agent remote-id.
| TOC |
| TOC |
| TOC |
| TOC |
| TOC |
| David W. Hankins | |
| Internet Systems Consortium, Inc. | |
| 950 Charter Street | |
| Redwood City, CA 94063 | |
| Tomasz Mrugalski | |
| Internet Systems Consortium, Inc. | |
| 950 Charter Street | |
| Redwood City, CA 94063 | |
| Phone: | +1<PHONE_NUMBER> |
| Email: |<EMAIL_ADDRESS>|


Consider the least-squares model:
$$ y(t, \theta) = e^{-\theta_1 t} + e^{-\theta_2 t} $$
To enforce $\theta_1 > 0$, switch to log parameters:
$\theta_i = e^{\phi_i}$, $\phi_i = \log \theta_i$.
Find an expression for both the first and second directional derivatives in the direction $v^\alpha = (v^1, v^2)$ in $\phi$ coordinates.


---
layout: page
---
about:
Hello, my name is Robert Rodriguez.
I'm currently a 4th year student at UC Berkeley studying cognitive science with a focus in human centered design. I've been a part of several groups on campus including Innovative Design, Berkeley Technology Review, and Circle K International.
I have a passion for improving user experience and hope to continue to work in improving the daily lives of individuals.


Configure
Ideamart Multiuser Simulator
SMS Service Runs On :
Application ID:
Password :
URL :
Mobiles
Incoming Message Log
Mobile Number
Create Mobile
Messages sent to customer
Received Date
Number
Message
Clear All


Version 1.1 — August 31 2015
Copyright
Copyright 2014 Adobe Systems Incorporated
Permission is hereby granted, free of charge, to any person obtaining a
copy of this documentation file to use, copy, publish, distribute,
sublicense, and/or sell copies of the documentation, and to permit
others to do the same, provided that:
— No modification, editing or other alteration of this document is
allowed; and
— The above copyright notice and this permission notice shall be
included in all copies of the documentation.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this documentation file, to create their own derivative works
from the content of this document to use, copy, publish, distribute,
sublicense, and/or sell the derivative works, and to permit others to do
the same, provided that the derived work is not represented as being a
copy or version of this document.
Adobe shall not be liable to any party for any loss of revenue or profit
or for indirect, incidental, special, consequential, or other similar
damages, whether based on tort (including without limitation negligence
or strict liability), contract or other legal or equitable grounds even
if Adobe has been advised or had reason to know of the possibility of
such damages. The Adobe materials are provided on an "AS IS" basis.
Adobe specifically disclaims all express, statutory, or implied
warranties relating to the Adobe materials, including but not limited to
those concerning merchantability or fitness for a particular purpose or
non-infringement of any third party rights regarding the Adobe
materials.
The following is a list of inappropriate error messages issued by the MS Font Validator version 1.0.1286.23890 for Adobe OpenType/CFF and TrueType fonts. These messages should be ignored when checking OpenType fonts that have CFF or TrueType font data. Note that these issues may be fixed in newer versions of the MS Font Validator.
W0022 Recommended table is missing gasp W0022 Recommended table is missing kern W0022 Recommended table is missing hdmx W0022 Recommended table is missing VDMX E6059 Could not perform rasterization Unable to get data from rasterizer. 'glyf' table is not valid.
E5400 The FeatureParams field is not null FeatureList, FeatureRecord[30](size), FeatureTable2.b. The following message is causes by the presence of stylisitic set features. These feature tags are registered.
W5300 The FeatureRecord tag is valid, but unregistered FeatureList, FeatureRecord[<nnn>], tag = 'ss01'
E2127 The table length does not match the expected length for this version E2132 The version number is invalid 4 W0051 Cannot perform test due to other errors in this table OS/2 table appears to be corrupt. No further tests will be performed W2106 The version number is valid, but less than 3 2
W2101 A CodePage bit is set in ulCodePageRange, but the font is missing some of the printable characters from that codepage bit #<n>...4.b. The first release of the Adobe OpenType fonts contained PUA (Private Use Area) Unicode values. Future versions of the same fonts will contain the same PUA values in order to avoid problems between versions. However, we agree that it is best to avoid using PUA values when possible, and new fonts will not have them. As a result, the following message may be seen:
W0307 Characters are mapped in the Unicode Private Use Area4.c. The head table contains a value which indicates the lowest size at which the font can be read. This makes sense for TrueType fonts, where the itself controls many details of hinting, and the designer can usefully determine the threshold of legibility. However, in the CFF model, the hints are only suggestions, and the rasterizer may change over time. The Adobe Type Department chooses to set this value to 3 as being so low that it will not interfere with future improvements in rasterization and anti-aliasing. As a result, the following warning will be seen:
W1305 The lowestRecPPEM value may be unreasonably small lowestRecPPEM = 34.d. A font which is not an italic style of another face in the same family can nevertheless have large italic angle. Examples are script fonts and italic designs which are the only font in the family. In this case the Adobe Type Department prefers to enter the real italic angle in the post table italicAngle field. This way, the insertion bar is correctly slanted in most programs. However, this will cause the following messages:
E1316 The macStyle italic bit is clear, but the post table italic angle is nonzero E2308 The italicAngle is nonzero, but the head.macStyle italic bit is not set4.e. The Adobe Type Department prefers to set the hhea table Ascender/Descender to the same value as the OS/2 table sTypoAscender/Descender, rather than the OS/2 table usWinAscent/Descent. We also prefer to set the LineGap to 20% of the em-square, although other choices are reasonable. As a result, the following messages are usually shown:
W1404 The LineGap value is less than the recommended value LineGap = 200, recommended = <n> W1405 Ascender is different than OS/2.usWinAscent. Different line heights on Windows and Apple hhea.Ascender = <n1>, OS/2.usWinAscent = <n2> W1406 Descender is different than OS/2.usWinDescent. Different line heights on Windows and Apple hhea.Descender = <n1>, OS/2.usWinDescent = <n2>
E1703 Loca entry points outside the glyf range | Number of glyphs with the error = X
Version 1.0 First version. Read Roberts 4/24/2007
Version 1.1 Added section #5. Miguel Sousa 8/31/2015


State diagram demos
stateDiagram
accTitle: This is the accessible title
accDescr:This is an accessible description
State1 --> State2
stateDiagram-v2
accTitle: This is the accessible title
accDescr: This is an accessible description
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash --> [*]
stateDiagram
accTitle: very very simple state
accDescr: This is a state diagram showing one state
State1
stateDiagram
[*] --> First
state First {
[*] --> second
second --> [*]
}
stateDiagram
State1: The state with a note
note right of State1
Important information! You can write
notes.
end note
State1 --> State2
note left of State2 : This is the note to the left.
stateDiagram
State1
note right of State1
Line1
Line2
Line3
Line4
Line5
end note


We embrace and promote water use efficiency.
Ira’s Water Saving Aerator fits in to existing taps. It reduces the flow, regulates the pressure without affecting your water usage experience.  It is a German product, it's quality and precision differentiate it from other products in the market.
Most popular among: households, hotels, corporates, hospitals, factories, institutes, community washing areas
Most common applications: wash basin, kitchen sink, dry balcony, shower head – hand/overhead, health faucet, community wash basins
Dignissimos asperiores vitae velit veniam totam fuga molestias accusamus alias autem provident. Odit ab aliquam dolor eius.
It depends on the flow variant componet you chose. We recommend 1.9lpm for households and a family of foure can sav 100 litres per day.
Wash basins, kitchen sinks, dry balcony, overhead/hand showers, health faucets.
10 years for corporation water supply abd 5 years for hard water.
Yes. 1 year manufacturer warranty which is covered only in case of breakage.
The variants fit 95% of the taps, we have alternate components for older taps.
No you do not need a plumber. It is very easy to install, you can refer to our video.


pgmedge(1) pgmedge(1) NAME pgmedge - edge-detect a portable graymap SYNOPSIS pgmedge [pgmfile] DESCRIPTION Reads a portable graymap as input. Outlines the edges, and writes a por‐ table graymap as output. Piping the result through pgmtopbm -threshold and playing with the threshold value will give a bitmap of the edges. The edge detection technique used is to take the Pythagorean sum of two Sobel gradient operators at 90 degrees to each other. For more details see "Digital Image Processing" by Gonzalez and Wintz, chapter 7. The maxval of the output is the same as the maxval of the input The effect is better with larger maxvals, so you may want to increase the maxval of the input by running it through pnmdepth first. SEE ALSO pgmenhance(1), pgmtopbm(1), pnmdepth(1), pgm(5), pbm(5) AUTHOR Copyright (C) 1991 by Jef Poskanzer. 04 February 1990 pgmedge(1)


Symbol Index for "Transient Property"
Symbol Index for diagram
"Transient Property"
Acquired Permanent Property (Class)
Acquired Temporary Property (Class)
Inherent Temporary Property (Class)
Lifelong Property (Class)
SPr/Persistence (Generalization Node)
Subject Property (Class)
Transient Property (Class)


Mindscaping is a mapping tool for intuitive thinking. This cartographic journal is designed to help you gain new insights about yourselves and foster a self-reflection practice.
Are you a....
New User
Old Friend


Social Graph Connections
One of the most useful features of Nobackend is the ability to create connections between entities, which allow you to model arbitrary relationships between entities. This feature is particularly powerful when applied to user entities by allowing you to model complex social graphs between users as well as groups of users.
Following/followers
To make the social graph possibilities of entity connections even easier to achieve, Nobackend also has special support for a default following/followers relationship, which offers these additional features:
Reciprocal connection: If a following connection is made between a user and another user, a reciprocal followers relationship will be created automatically. In contrast, all of other entity connections are one-way, meaning any reciprocal relationship must be created manually.
Activity feed subscription: The followed user’s activities will automatically be posted to the following user’s activity feed. For example, if Arthur is following Ford, then any activities published by Ford that Arthur is allowed to see will appear in Arthur’s activity feed.
Creating a following/followers connection
To create a following/followers connection between two entities, create the connection as you would any generic entity connection. For full details on creating connections, see [Connecting entities](../entity-connections/connecting-entities.html).
For example, the following request would create a following/followers relationship between two user entities with the usernames ‘Fred’ and ‘Barney’:
POST https://api.tbaas.co/your-org/your-app/users/barney/following/users/fred
Note
Please note that this only works when you POST
a following
connection. Creating a follower connection would not create a reciprocal following connection.
This would retrieve a list of the users that Barney is following:
GET https://api.tbaas.co/your-org/your-app/users/barney/following
And this would retrieve a list of users that are following Fred:
GET https://api.tbaas.co/your-org/your-app/users/fred/followers
Social Graph Connections¶
One of the most useful features of Nobackend is the ability to create connections between entities, which allow you to model arbitrary relationships between entities. This feature is particularly powerful when applied to user entities by allowing you to model complex social graphs between users as well as groups of users.
Following/followers¶
To make the social graph possibilities of entity connections even easier to achieve, Nobackend also has special support for a default following/followers relationship, which offers these additional features:
Reciprocal connection: If a following connection is made between a user and another user, a reciprocal followers relationship will be created automatically. In contrast, all of other entity connections are one-way, meaning any reciprocal relationship must be created manually.
Activity feed subscription: The followed user’s activities will automatically be posted to the following user’s activity feed. For example, if Arthur is following Ford, then any activities published by Ford that Arthur is allowed to see will appear in Arthur’s activity feed.
Creating a following/followers connection¶
To create a following/followers connection between two entities, create the connection as you would any generic entity connection. For full details on creating connections, see [Connecting entities](../entity-connections/connecting-entities.html).
For example, the following request would create a following/followers relationship between two user entities with the usernames ‘Fred’ and ‘Barney’:
Note
Please note that this only works when you
POST
afollowing
connection. Creating a follower connection would not create a reciprocal following connection.This would retrieve a list of the users that Barney is following:
And this would retrieve a list of users that are following Fred:


This image is aligned vertically top of the text.
This image is aligned vertically center of the text.
This image is aligned to the baseline of the text.


Name: John Bucknam
Year: Senior
Interests: Scientific Programming, Game & Graphics Development, and Algorithms
Email<EMAIL_ADDRESS>John Bucknam has always had a passion for Computers, first receiving an AAS in Computer Programming before heading to Rowan Univeristy. He has attended hackathons and code jams, including the ACM Programming Contest and has won CodeDay Philly 2014 with the other e-board members. He is hoping to get his Masters in Computer Science by Spring of 2017.
Name: Nick Weintraut
Year: Sophmore
Interests: Software Engineering, Game Development, and Algorithms
Email<EMAIL_ADDRESS>I love doing interesting projects and taking things over the top. I've created my own card-based game engine, 3d models of dragons and other goodies, and am head of Research and Development for our Animation Team subcommittee.
Name: Richard Cerone
Year: Senior
Interests: Software Engineering, Software Development, Computer Security, Theory
Email<EMAIL_ADDRESS>I love starting new projects and learning new things. I always try to learn a new langauge every year to keep myself challenged and present in the field. I have experience working on real world projects and have a concentration in Software Engineering.
Name: Jatin Bhakta
Year: Sophomore
Interests: Programming, Web Development, Chess, Archery, and Volleyball
Email<EMAIL_ADDRESS>I have done some programming in Java in high school and I would like to expand my knowledge on the subject. I have been President for two clubs (LEO/Community Service and Chess) during my senior year of high school and now I'm continuing my involvements in clubs by being a Secretary for ACM. Not yet decided on what I want to do in the future, but I'm sure I'll find out throughout my years here at Rowan.
Name: Paul Turner
Year: Sophmore
Interests: Web Development, Programming Languages, and Drones
Email<EMAIL_ADDRESS>Paul Turner is a sophomore at Rowan University and is an avid member of the Rowan ACM. Working with the Rowan Animation and Game Development Team as well as Android Development and other groups, he constantly acts as an example to the other members on how to relax and have fun while working.
Name: Nick Dondiego
Year: Sophmore
Interests: Animation and Game Development, 3D Modeling
Email<EMAIL_ADDRESS>I am a sophomore here at Rowan and I've had experience from my high school club that was involved in FIRST robotics. I plan to use this team's skills to bring the team and its work to SIGGRAPH in August! We work with an assorment of softwares like Maya, Audesk, Unity and the Unreal Engine to create games and animation.


Galactica CIC
Setup
Pegasus Expansion
Allow Cylon Leaders
Allow players to refuse Cylon Leader
Exodus Expansion
Add one extra "not a Cylon" card into the loyalty deck.
Daybreak Expansion
Players:
3
4
5
6
7
Hint:
When selecting characters, click on the character's name to open a full card.


This is a paragraph that takes 2500 milliseconds to fade out and in.
This is a slow, linear paragraph.
This is a fast paragraph.


Across: 1. Stock initially up with strange rise, mostly enthusiasm for upgrades (10) 7. Primarily Mafia, or bikies? (3) 10. Forts pour liquid to protect from attack from water (9) 11,13. Huge boxing line-up with return of healthy and essentially loyal champion fighter (5 2 2 4) 12. Aichi position with rotation included in Hatha yoga now (6) 13. see 11 15. Within 10 tent I'm estranged frequently (10) 16. Alternately Pittman and Buttrose (3) 18. Use pan for Stephen perhaps (3) 19. Big no-no: all foolishly shooting up (10) 22. Gave up taking ecstasy after old lover went over (8) 24. see 23 down 26. Horse monument changed after men removed (5) 27. Unusual fellow in belltower in sort of bad mood (9) 28. Argentine king provides Italian singer South African saddle (3) 29. Listen carefully: interrupted sax part joined up again (10) Down: 2. Messy'n'shit... ugly! (9) 3. Evacuating in gym, pet right out of order (8) 4. Most of those abused got fired (4) 5. see 9 6. Slav OK to be moved, perhaps from Bratislava? (6) 7. Relative to speed of sound, not moving at all? Tough! (5) 8,25. "Ingrid"? You write letters solving her problems, like brother eating strange Arab halal preparation (7 4) 9,5. Director of Frozen fell far, ice-corrupted (6 10) 14. Roguish makeover of epic square (10) 16. It can help top cake or line gnocchi, without long hard mixing (5 4) 17. They have funny lines of code, semi-assembled (8) 18. Female winning 400 of 2000 liberated male (7) 20,21. Sadly rued tenor sax god (USA, departed) (6 6) 21. see 20 23,24ac. Killer doll keen to be celebrated deadly fighter (5 6) 25. see 8


Dear John
Young Savannah and American army soldier John tenderly love each other, expressing their feelings in letters that for John are the only source of joy and hope in the ongoing war. For John, there is a concept of "duty" that forces him to stay in the army after the events of September 11, preventing him from fulfilling his promise to return and marry a girl. This decision distances them from each other and letters from Savannah come less and less often.


, C# is one of the most versatile and modern programming languages in the world. It is relatively easy to learn and adapt. It also has a large online community, it's developed and backed by Microsoft, and is the programming language used by the Unity gaming engine.
, JavaScript is a programming language utilized to make websites interactive. JavaScript is an all-purpose programming language most prominently used on the client side, or "frontend." However, since the advent of Node.js, JavaScript is also run on the server side, or "backend," as well.
, Python is an easy to use and learn language that is great for beginners and seasoned programers alike. Python is also a very accessible programming languages as it utilizes simplified, uncomplicated syntax, which emphasizes natural language.


{% extends "polyaxon/index.html" %} {% load i18n %} {% load staticfiles %} {% block content %}
Your registration takes place with the email-address: {{ invitation.email }}
After logging on you can change your email-address anytime in the profile settings.
{% else %}Please sign up to get access to Polyaxon.
{% endif %}


---
layout: default
title: Projects
---
Projects
These are the main top-level overarching projects around the seL4 microkernel.
{% include project-grid-element.html project='sel4' %}
{% include project-grid-element.html project='l4v' %}
{% include project-grid-element.html project='camkes' %}
Tutorials and Examples
These are tutorials and example systems that are designed to help people get a
basic understanding of seL4, it's programming and development models, and how
a seL4-based system would look like.
{% include project-grid-element.html project='sel4-tutorials' %}
{% include project-grid-element.html project='sel4webserver' %}
Tests, benchmarks and documentation
These are a collection of projects, and tools that will help you test or
benchmark seL4-based applications or modifications to the kernel. The
documentation serves as a reference point to questions that one may have with
seL4 or its ecosystem.
{% include project-grid-element.html project='sel4test' %}
{% include project-grid-element.html project='sel4bench' %}
{% include project-grid-element.html project='docsite' %}
User level development
These are a collection of projects which build on top the seL4 kernel and
includes a number of tools and libraries which aims to make user level
development easier.
{% include project-grid-element.html project='user_libs' %}
{% include project-grid-element.html project='sel4runtime' %}
{% include project-grid-element.html project='capdl' %}
Virtualization
These are a collection of projects which contains tools and libraries that
make it possible to create virtual machines on top of a seL4 kernel. The
projects also contain example virtual machine applications that can be run on
QEMU and a few specific platforms.
{% include project-grid-element.html project='virtualization' %}
{% include project-grid-element.html project='camkes-arm-vm' %}
{% include project-grid-element.html project='camkes-vm' %}
Tooling
These are projects that contains tools that are designed to aid the developer
during the development process.
{% include project-grid-element.html project='buildsystem' %}
{% include project-grid-element.html project='dockerfiles' %}
{% include project-grid-element.html project='sel4_tools' %}
Boot process
These are projects that are related to the booting of the seL4 kernel on
hardware and simulators.
{% include project-grid-element.html project='elfloader' %}
{% include project-grid-element.html project='hardware_hacks' %}


enum ExampleEnum: Int {
case a, b, c = 5, d
}
enum GamePlayMode: String {
case cooperative, individual, competitive


Just finished reading Zeynep Tüfeçki’s utterly masterful Twitter and Tear Gas. The book is astonishing. It gave me better frames for thinking about a great many things I’ve been thinking about for a long time now, and it is a masterful work of academic scholarship presented in a way that just about anyone could read.


FBI Raids YouTuber Omi in a Hellcat's Home, Seized Cars and Bank Accounts
by VladTVFamed YouTuber Omi in a Hellcat took to the platform to reveal that he was raided by the Feds, who he claims "took everything." Omi, whose real name is Bill Omar Carrasquillo, is the founder of Gears TV reloaded, an IPTV app for Firestick.
In the video, Omi says that the Feds seized "every SD card, every camera, every television in my house," adding, "They only thing they didn’t take was my d*ck because it’s attached to my balls." He went on to explain that the feds were investigating him for alleged money laundering, tax violations as well as the legality of Gears TV. You can check out his full explanation above.