launchd is awesomesauce; good riddance to init and the tree of ugly rc scripts.
Good bye to idiosyncratic runlevels.
Good bye questions about whether something should be in/etc/rc*, or should be managed by inetd or xinetd, good bye complexities of cron scripting, and so forth.
Take a look around in/System/Library/LaunchDaemons and/System/Library/LaunchAgents.
Start here:
boot single user (command-s during POST) # fsck -fy/ # mount -uw/ # cd/System/Library/LaunchDaemons # launchctl load/System/Library/LaunchDaemons/com.apple.kextd.plist # launchctl load/System/Library/LaunchDaemons/com.apple.notifyd.plist # launchctl load/System/Library/LaunchDaemons/com.apple.configd.plist # launchctl load/System/Library/LaunchDaemon/com.apple.DirectoryServices.plist # echo whee, now i can do useful things # diskutil list # diskutil repairVolume/Volume/other
etc.
if you want more things to be runing, you just launchctl load it; you can use launchctl stop or launchctl unload to turn off things as they become unnecessary.
when you switch to multiuser mode, launchd will load in plist files in its search path; when you log in as a user, it does so for things in the user's search path, as that user. Very handy.
Note that the plist files are all in xml1 format, and you can run ed on them if you want.
plutil -convert xml1 binarypreferencelist.plist
lets you use ed on any system configuration file. the system will reconvert to binary format for efficiency in most cases, either as the file is loaded initially or when it is next written out by any apps that manage it.
launchd/launchctl have extensive debugging facilities and will let you know what launchd is doing without having to resort to "ps | grep...".
You can manage a Mac using nothing but ed, plutil, launchctl, softwareupdate, your favourite pager or tail or cat, (and on Mac OS X server, you may want to use serveradmin for some things). You can probably do everything you need to with a fully headless Mac without resorting to anything other than ssh (i.e., no 'cheating' with VNC/ARD). A number of people have one or more Macs that are managed in this sort of GUIless way, and most people using Darwin alone (e.g. on non-Apple-branded hardware!) pretty much have to.
You will also want to know about opendirectory stuff if you have a network full of machines, or want to edit user accounts.
You can use dscl or the ldap tools to explore or modify your directory information; no more fussing around with password, shadow password, group,... files, and if you have a network, you just substitute "/LDAPv3/server.fq.dn" for "/Local/Default", depending on what search policy you configure.
Finally, although I am quite happy to attack things at the command line via SSH, I sure appreciate the opportunity to be lazy for some things, and connect via VNC, either by clicking in the Finder sidebar on the Mac I'm sitting at, or by using command-K and a vnc://.../ URL.
There's a lot of new stuff in 10.5 for someone who is more used to an Edition VII Workbench style of system management, or even standalone NetBSD or Linux systems. Opendirectory is pretty straightforward for anyone used to networks of managed workstations and single sign on (whether in the land of Windows or MIT Athena). launchd is easier to learn than it was to learn all the places where processes could be started up. plists and good hygeine in hierarchical file naming mean that "locate com.apple.xgrid.agent" (or mdfind instead of locate) will find you all the relevant config files. these plists can be converted to xml1 as necessary
Fire : Mule comparison is new to me, so I hope you don't mind if I play.:-)
Mules are composed of cells. Fire is clearly not cellular life. Of course, viruses aren't cellular life either, but they are still bounded (encapsulated) and readily quantified given a sufficiently powerful microscope. Fire is not made up of encapsulated anything at any scale at all, even given a microscope that can see right down to the level of an atomic nucleus.
That said, prions and the primordial inhabitants of hypothetical RNA-world are pretty arguably life too, and they aren't encapsulated either. However, they are characterized by two physical attributes.
Firstly, they have a per-species similar, quantifiable, many-atom molecular structure that is more abundant given a larger sample. It's hard to argue this is the case for fire, which almost always reduces the count of many-atom molecules. Fire is almost entirely oxidization/catabolism; there is practically zero reduction/anabolism, and to the extent that molecules of more than a few daltons are produced by any fire at all, the molecules are largely dissimilar.
Secondly, life couples to background thermodynamically-favourable reactions in order to pay for thermodynamically-unfavourable ones (like anabolism). This is one of its key characteristics, and the presence of an electron transfer chain and/or protein pump that does work across an unfavourable gradient is a critical aspect of life. That is, a key aspect of life is that it decreases entropy[*] locally by exporting it to the less-local environment. Fire does not do this; it is in itself a thermodynamically favourable local increase in entropy; ash has a lot less macroscopic structure than wood, for example.
So, for reasons of metabolism (in the thermodynamic sense) and structure (molecular or cellular), mules are alive, whereas fires are not.
I deliberately did not discuss "reproduction" up to this point.
Mule cells reproduce themselves by mitosis, differentiation and other processes, so mules are a collection of reproducing things, like sponges, jellyfish or slime moulds, rather than a single reproducing thing. Most biologists (particularly evolutionary ones) don't really consider reproductive potential except as an after the fact assessment of environmental fitness. So a mule is no different from a non-sterile horse that dies before producing viable offspring.
Moreover, not all mules are sterile. Some (merely dozens) of female mules have produced viable offspring naturally with both horses and donkeys. Although male mules are much much much more likely to be unable to produce a viable foal with an egg from a horse or donkey, the chances are not zero, and they increase substantially if the other partner is a female mule. Given an environment which sustains mule populations at all, it is impossible to totally preclude a population of fertile mules. (In general it would "merely" require some minor mutations to the mule DNA polymerase in the female egg, matching the DNA polymerase mutation which resulted in the 60-ish mule-born foals; the second mutation would allow the integration of the mule male's sperm into the initial zygotic cell and its somatic and germline descendants).
So, adaptation is also a key feature of life. Fires are not adaptable. Evidence of a fire that adapts to its environment over geological time scales (like life did) would be pretty good evidence that fire is alot more life-like than it is generally considered. There are living organisms on the planet which are provably thousands of years old, and there is speciation of microbes (and Drosophilids) in labs.
Do you know of a fire which is provably thousands of years old, or which has mutated in a way consistent with evolution (minus the DNA/RNA part) in a laboratory environment?
There is good evidence of adaptation of prions to environmental selection pressures in laboratory conditions. There is exceptionally good evidence favouri
They're there. You have to work around them. That's an engineering fact, not a comment on their aesthetics. Such aesthetic concerns are not really in the realm of engineering; it is not engineering if you are unwilling to engineer a fix or workaround just because the problem is ugly.
Moreover, simply repeating "NATs are ugly" or listing off justifications for that opinion is not going to get rid of them.
That there are difficulties in NAT traversal for protocols that require knowledge of counterparty NLAs or for applications that require rendezvous with particular counterparties at arbitrary times is a truism, not an argument against engineering a generic workaround API.
Confusing a truism that is part of the problem statement with a solution is poor engineering practice. "If only they weren't there!" does not make NAT traversal easier for anyone.
That said, there are several largely working toolsets for doing NAT traversal; several are open source, freely available and probably unencumbered. The people working on them accept bug reports, especially where your (reduceable, repeatable) experience conflicts with the expectation of "it just works". Presumably people working on 3rd party applications that have problems traversing NATs take bug reports too. You know the drill.
"A bit of glue to tie NAT-and-firewall-hole-punching"? Really? It's just that easy?
Yes. http://www.dns-sd.org/ for DNS queries with dyanmically updated A and SRV RRs (among others); NAT-PMP or uPNP or STUN (or Teredo) for acquiring the information to update into those RRs.
Literally millions of people use these technologies daily as part of either using Back to my Mac, using a Mac OS X system behind an Apple Airport wireless station, or both. It works pretty well, and users don't even notice other than seeing their various machines in Finder window sidebars as they move their laptops around from subnet to subnet. It's also straightforward to put a NetBSD system into the mix (probably other similar sytems too), or to set up your own multiplatform Wide Area Bonjour server.
Gateway implementation bugs are not necessarily NAT-specific, as you note. Any feature -- new or existing, optional or mandatory -- can have bugs.
Policy issues affect non-translating firewalls just as they affect translating firewalls.
No, they aren't trivial problems (bugs bad; policy elucidation or creation problems bad) but they are not specific to NAT.
That NATs get in the way of operation should be incentive for generic workaround API development, rather than hoping that the NATs will just get out of the way. They're established and aren't going to vanish soon.
Port forwarding through a stateful firewall and NAT hole punching are identical for a higher level communication that does not embed network layer addresses (NLA, in this case IPv4) and expect them to be useful for the other party or for a long period of time or both.
Think of a trivial service like echo (TCP, RFC 862) where whatever application data is sent from the client is reflected back to the client unchanged by the server. If the client connects to 128.100.100.1 tcp port 7 it does not matter whether 128.100.100.1 is the actual server address behind a firewall that allows that connection, or is the address of a NAT that forwards port 7 to an internal host. Right?
Complex services which require rendezvous often have made unreliable assumptions about NLA lifetime and isotropy. These assumptions are the source of frustration. The lack of a stanard generic workaround for future rendezvous in the presence of ephemeral NLAs is another problem.
Trying to make NLAs non-ephemeral is a poor solution (it ends up becoming bridging); a better one is to have a stable handle that maps to a dynamically updated NLA/service-address. Wide Area Bonjour does this (mDNS + dns-sd + private dynamic DNS zones for updating A RRs and SRV RRs as they become discovered through NAT-PMP, uPNP, probing and feedback), and it helps with any application protocol that transfers DNS names and symbolic port names as rendezvous points instead of IP addresses (with implicit mappings for well-known ports).
Essentially all Mobile Me (formerly.Mac) users have a private (key-protected) DNS zone membername.members.mac.com that is updated by their various Mac OS X systems so that they can rendezvous with one another ("Back to my Mac"); the zones mainly contain A and SRV RRs keyed to the configured Computer Name (in System Preferences > Sharing).
Most Mobile Me customers can therefore do things like:
ssh mycomputername.mymembername.members.mac.com
which will result in a DNS service discovery query of
(and/or possibly other RRs like PTR, A, AAAA, CNAME or TXT).
Behind a NAT that might become "0 0 2193 nat-dns-name.some.where." or "0 0 41111 128.100.100.1".
ssh then will resolve the DNS name or use the IP/IPv6 literal, and use the port literal, and connect appropriately and seamlessly; host key checking is done on its argument, rather than on the intermediate indirection symbolic names or the ultimate NLA.
This works just as well for datagram type services as for connection-oriented ones.
Most of this is unencumbered open standards documented at http://www.dns-sd.org/ (for example).
The point however is to use something that really is long-lasting and isotropic, like a DNS name, as a rendezvous point. The Back to my Mac approach is illustrative, but is not a good choice, since key-protected private DNS names obviously are only isotropic for those that know the key!
A standard API for this sort of rendezvous among hosts that are subjected to NATs and being moved from one part of the network to another, and a general consensus about avoiding the use of NLAs as remotely-useful long-lived rendezvous handles, has been elusive in the IETF, mainly for political reasons.
This is particularly sad since many IETF conference goers migrate their own laptops from the conference wifi to their hotel rooms several times during the conference, and many of them have home and work machines behind a NAT or firewall they do not personally control, and yet they don't seem to mind the lack of session survival (or the hotchpotch of per-application recovery approaches) that results.
The problem lies in any apps written since the mid-1990s that make two critical assumptions about its own network layer (IP *or* IPv6) address (NLA, generically), and the same about its counterparties'.
Assumption one: the local address is universal and isotropic.
Assumption two: the local address is fixed and permanent.
These assumptions are bad with or without the presence of NAT, because of DHCP, renumbering, multihoming and mobility.
The first assumption leads to the embedding and use of NLAs in higher level protocols that lead to breakage when the NLA cannot be used as a destination address as it is. This can be because of transient routing problems (or deliberate policy), and can be avoided simply by using a simple indirection through the DNS or equivalent mapping database that will give up one or more NLAs which are valid as destination addresses.
NAT mainly serves to increase the incidence of problems associated with assumption one, because it generally introduces anisotropy to addresses. Obviously if "A" knows it's 10.0.0.6 and tells a counterparty "B" to connect to it at that address, if B is somewhere far away topologically, "B" is unlikely to be able to make use of it. One solution: embed symbolic DNS names into the stream and indirect through that. Instead of "10.0.0.6" with the assumption that a well known port (e.g. TCP, 20) embed (for example) ftp-data._tcp.mysymbolichostname.mygatewaydnszone.somesite.com into the stream and expect the other side to use do a SRV RR lookup in the DNS.
A bit of glue to tie NAT-and-firewall-hole-punching into an on-NAT/on-firewall nameserver is most of what's necessary to remove the need for application-level gatewaying and translating for simple connectivity purposes.
Older protocols (like ftp) are going to remain a problem; the reasons these have not been fixed already are largely political -- these older protocols are known to have serious security problems, and there are many people who reject wholesale the idea of adapting to the existence of NLA anisotropy in the real Internet.
This also gets in the way of host and subnet mobility and multihoming. We lack a standard session protocol which would allow for generic graceful reconnects of application-to-application communications as e.g. a mobile phone moves from a wifi to a 3g wireless provider and then to another wifi unrelated to the first; or as a conference attendee walks with her laptop from the conference wireless network to her hotel room. The standard again would largely involve a bit of glue around DHCP and dynamic DNS, and is stalled for mostly political reasons (security of DNS, and acceptance of this mode of mobility necessarily leading to transience of addresses and typically leading to transitioning from one anisotropic address to another).
NATs are simply there. Not adapting to them for aesthetic reasons is a poor engineering choice. Complaining that they are in the way is complaining about that engineering choice.
However, one thing to realize about P2P is that because there are often dozens of active TCP connections transmitting from one machine, fairness goes pretty much out the window anyway
TCP (and any RFC 2001 congestion avoidance) fairness is on a per bulk transfer basis. Multiple bulk transfers for the same application is fair for all the bulk transfers, but unfair from the perspective of an application that runs only one bulk transfer. In the limit of low numbers of flows, with two data-moving applications sharing the same bottleneck with one bulk transfer each, "A" and "B" both get half of the bottleneck bandwidth; with four flows for "A" and one for "B", the former gets 4/5 of the bottleneck bandwidth and the latter 1/5, once the flows reach equilibrium.
This is still fair in the technical sense, because the bulk transfers find equilibrium. In the limit of large numbers of flows -- tens of thousands seen over a one second interval -- this works very well for sharing bottleneck bandwidths. This is important in places where congestion is most noticeable by the largest number of users: inter-provider gateways (like at internet exchange points) and in front of very long haul links (like across oceans). Individual users are unlikely to be able to gain a significantly larger share of that sort of bottleneck bandwidth just by opening lots of flows, because they will saturate a bottleneck somewhere else along the end to end path.
So a technical definition of fairness (bulk transfers find equilibrium and roughly equally distributes bottleneck bandwidth among the bulk transfers) is hugely useful in the most expensive parts of the Internet infrastructure.
However, at smaller, cheaper bottlenecks where opening multiple parallel bulk transfers gains a much larger share of the bottleneck, *and* where it causes adverse interference for the users of applications that open single bulk transfers, there are two answers: one is simply to expect that other apps that traditionally use a single TCP bulk transfer to parallelize the transfers. This will reduce goodput per packet transmitted because the probing of the bottleneck bandwidth will always incur packet, and that is likely to synchronize at FIFO bottlenecks. Another approach is to do smarter-than-FIFO queueing at bottlenecks, especially ones which carry small numbers of bulk transfers.
Ultimately, routers can only forward, delay or drop packets. FIFO forwards a packet immediately if there is nothing in the queue (no bottleneck), otherwise it delays a packet in a queue; if the queue is full, FIFO drops the packet. One can probabilistically impose an early delay or drop on packets easily (in terms of the amount of computation needed in the router), in a way which is more likely to punish the least congestion avoiding users (i.e., the ones with aggressive timers, or which open multiple parallel bulk transfers to try to dominate the bottleneck).
One approach is to look at the actual queue regularly, and preferentially drop from the largest occupant of the queue, where an occupant is identified by a tuple such as (src, dst) address 2-tuples. This requires lots of state and computation. random early drop (RED) is a very close approximation -- the liklihood of a drop increases in proportion to the queue depth, and it is very likely that an increasing drop probability will hit the largest user (as in src,dst) of the bottleneck when the queue depth is non-zero. A large user who does not increase queue pressure will not be penalized; a small user whose traffic is synchronized with queue growth will be signalled to avoid the congestion, and will probably spread out its use. RED works very well, and is cheap and easy. It is also counter-intuitive -- sadly, many network operating people don't like the idea of a random early packet drop, and don't understand that it does help, even when confronted with before and after graphs of real traffic; RED with ECN marking is an attempt to appeal to t
Large correction: the transport layer port numbers are not canonically part of the IP header. The protocol number is, however.
However, as I'll repeat below, I don't mind considering a pseudoaddress of {IP address (32 bits) + IP header protocol field (8 bits) + transport layer (src or dst) port (16 bits for UDP or TCP)} as a fundamentally routable object, provided one also sees almost every IP router implementation as imposing an in-built minimum prefix length filter of 32-bits.:-)
This change didn't hurt anything, aside from an increase in router complexity
So this is wrong because "16-bit port" is a transport layer address and is transport layer protocol-specific. Even though UDP and TCP both use 16 bit port values, the mapping between well-known (and espeically dynamic) numbers to actual servers and clients is non-identical.
A smaller correction: the [32-bit opaque address] varies in opacity depending on topological location. On the originating host it's not opaque because the host has to distinguish at least between system-local traffic, subnet-local traffic (which should be resolved using ARP) and non-local traffic (which should be forwarded through a router). The distinction is that a local subnet has a known prefix and mask, which means there is structure expected in the 32 bits. Likewise at every intermediate system it's not opaque because it is subject to a CIDR-style mask-and-match search for an appropriate forwarding rule. Only at the final destination is it nearly opaque, in the sense that either the entire 32-bit value matches "me, the recipient, 1.2.3.4/32", discarded, or probably forwarded into a loop. (The final destination can also do a header-rewrite and then forward, which is most of what a NAT does).
Another small correction: CIDR decreased the complexity of the forwarding path of routers because a lookup was reduced to a trie (usually done as a Patricia tree or as an M-way search tree) which was amenable to mask-and-match optimizations in hardware. Nothing special was really needed in the path for the reserved unicast, local or multicast address spaces.
With classful exterior routing, there was no obvious way to avoid longish pipelines of mask-and-match-or-shift in hardware, or class-finding loops in software. In retrospect, with the early-2000s use of smallish TCAMs, this approach could have been tuned somewhat into at most four TCAM lookups with two being the typical case, however that approach was not available in the early 1990s.
BGP became slightly more complex code-wise, but the processing and storage complexity fell for the same set of NLRI data with the implementation of CIDR, independent of aggregation and route summarization, which caused even further falls by reducing the amount of NLRI data needed for full global default-free routing knowledge. Policy controls benefited from CIDR as well.
Classless interior routing benefited where the protocols could handle subnetting already. RIPv1 could not. Most others in use could, or were easily modified to allow for "supernetting", which tended to reduce the number of routers required to service the same number of physical subnets. Classless interior routing also led to complexity reductions in run time and storage in most intermediate systems (routers, switches, brouters, policy filters,...). Those that had to cope with end systems that could not cope with non-classful routing at all (I am looking at you IBM AS/400!) accumulated kludgey configurations, however.
These days, instead of saying "connect to mydomain.foo.cx", for example, you have to say "connect to mydomain.foo.cx at port 12345". That's out of band address information, and should never be needed.
His mental condition is a defence or mitigation that he can raise during the trial. It may help. The US legal system offers many defences and mitigations in federal criminal law.
Try to remember that he has had a couple of years to fight the extradition, which hinges on the separate decisions of several independent legal officers that there is a case to answer in U.S. Law, including at least two officers who had already concluded that the Crown Prosecution Service could not demonstrate a clear case to be answered under criminal law in the United Kingdom. Moreover, there have been at least two accountable-to-Parliament-and-their-local-electors Cabinet Ministers who have been briefed and were convinced enough that there was a case to be answered in the USA. It is unlikely that they would put their own political futures and those of their party allies on the line if the opposite was true, especially given how much information leaks out of Whitehall these days.
McKinnon has not been kidnapped, he is not the victim of extraordinary rendition, he is not going to Guantanamo, and he is not facing a trial any different than that of any other person accused and indicted by a Grand Jury in the United States. He will have a trial -- by Jury if he chooses -- and will have available the full range of defences available to any American in the same position.
He is not facing execution, he is not facing being held in Camp X-Ray like conditions, and he is unlikely to "just vanish" from the public eye in the UK or be notably "sold out" by either government this late in the electoral cycle on both sides of the Atlantic.
There are some real worries about how a less in-the-public-eye case might have unfolded. McKinnon in turn has certainly benefited from the public interest in the Natwest Three case. That there are systematic weaknesses in the current arrangement with the USA is fairly obvious now.
However, this is not being nabbed on the street in Milan and held in US custody without access to the US system of justice, as happened with Abu Omar (the Imam Rapito affair).
It is also, fortunately, not being shot seven times in the head on the Tube, a crime for which some police officers have yet to answer in court. Don't let these still senior police commanders hide behind a statute of limitations, an autrefois convict excuse following the "harsh" health and safety conviction of the police force as a whole, or a sweeping gesture towards all the other weaknesses in the British justice system.
In short, don't let the real baddies distract you by getting you to worry more about the system when it is working transparently and non-violently (like in this case) than when it uses millions of pounds of your taxes to kill someone arbitrarily and cover up and whitewash the murder.
Bear in mind that the extradition treaty is an expresson of sovereign will enabled by an Act of Parliament introduced in the democratically elected and accountable-to-the-voters House of Commons.
So, the undermining of UK sovereignty was a sovereign decision, as with any other treaty that constrains the executive or judicial system, or which delegates sovereignty to some extranational body like the European Union or Council of Europe. Unless there is a conflict with other strong expressions of sovereignty ("entrenched statute and practice", i.e, the Constitution) there is no issue of erosion.
There were arguments raised in the past (Soering v United Kingdom 11 Eur. Ct. H.R. (ser. A) (1989); Bermingham, Mulgrew & Darby * - v - Director of Serious Fraud Office and The Attorney General (HCJ Judicial Review 2004, appeals to CA and ECHR denied)) that the treaty was unconstitutional on its face; these were rejected by the Court of Appeal for the United Kingdom, and by the European Court of Human Rights. The general thrust of the rulings is that if there is prima facie a case to answer, and a valid extradition treaty and process, and the extradition is to a state generally recognized as democratic, with an independent judicial system upholding the rule of law, then there is no constitutional impediment to extradition to be found in human rights law provided that the punishments faced are broadly in line with Council of Europe standards.
That is not to say that the treaty is a good one, or that the entire electorate (or House of Commons, or Parliament) supports the one-sided nature of extraditions for crimes that rely upon some degree extraterritorial jurisdiction, the low bar on evidence (there merely has to be enough to warrant a trial), or the long long long period of waiting in partial custody in the USA for a trial date as in the case of the Natwest Three. It is also not clear that the USA is universally regarded as having a particularly fair judicial system ( cf http://freegary.org.uk/ ), but then McKinnon is not a black man facing a capital crime trial in the Texas state courts.
If you feel like helping change the minds of the electorate and some future democratically accountable government, feel free to make a donation to http://liberty-human-rights.org.uk/ or pointing your UK-resident friends at it.
ZPM power production[*] is rated in the non-SI unit "Plot" (analogous to J/s, the second derivative of energy[**], and the first derivative of work[***]).
A ZPM's normal production appears to be approximately 0.1 Plot per episode in which it is portrayed, although in some episodes a ZPM shows how powerful a device it can be, delivering just shy of a full Plot.
The third derivative of energy, "Twist", analogous to J/s^2, can be used to analyse the output of the ZPM over the duration of an episode. In some cases the ZPM provides a substantial Twist, progressing from normal power production to zero or to explosive overload within the span of an Act.
A high-Twist, high-Plot device is consistent with the ZPM as portrayed in Stargate SG-1.
I never got into Stargate Atlantis, sorry.
[*] or production power, which may be more appropriate. [**] Writer's energy, that is. [***] Professionally employed TV writer, that is.
First, a couple paragraphs about your parent article:
The ease with which single photons are emitted varies with wavelength. High energy photons (gamma rays) are fairly straightforward to produce using a radioisotope, spallation or annihilation emitter, a screen opaque to longer-wavelength photons, and a gate (either polarizing or deflecting). Single emissions of lower energy photons (~ 1300-1600 nanometre useful-in-fibre wavelengths, for example, and some visible wavelengths too) have recently become possible using lattices of nm scale quantum dots.
One variety of these single photon "gun"s use a two qdot arrangement where both dots are excited electrically and then one is stimulated into emission in such a way that iff the first dot emits exactly one photon of the proper frequency, the second dot will also be stimulated into an emission of exactly one photon of the desired frequency. (If the first qdot "photon emitting diode" emits multiple photons or one or more photons of the wrong energy the second qdot will not be excited into emitting anything).
The photopsin-transduction cascade is remarkably efficient given how it is driven it is by statistical chance.
In cone cells there is a gel (literally) of photopigments, various phosphorylization states of guanosine, and mechanisms which develop a charge on the neuronal side of the cone cell while phosphorylating GMP and GDP to GTP (this is paid for by the normal ATP energy processes in cells). They simply float around in the gel; there is very little ordering of cone cell cytosol compared to the majority of other cells, and what ordering there is is akin to drops of oil stirred up in water.
The photopsins are structured somewhat like radio antennas -- rhodopsin, the monochromatic pigment in rod cells especially looks like a ladder antenna. An incoming photon of a suitable energy (i.e. wavelength) striking the "antenna" part of the molecule kicks an electron into a higher orbital; this causes some local bending which is amplified through the photopsin molecule creating a conformational change, sort of analogous to causing a Venus Flytrap's maw to close by tickling its hairs, except that the conformational change cycle -- shut, open -- is brief (nanoseconds, with some reactions taking place in femtoseconds).
The "maw" is a binding site that accepts GTP. If a GTP molecule just happens to be in the binding site when it closes, the opening rips it apart producing GDP + P. Free GDP is taken up by a worker molecule in the cytosol which delivers it to the ATP->ADP+P --> GDP+P -> GTP + charge on mebrane process.
That is, what we "see" is really the phosphorylation of GDP to GTP. GDP is produced by a photon-powered GTP dephosphorylator.
Neurons are very sensitive to charges, and it is not very surprising that an amplification of one GDP->GTP charge is "perceptible". Mammal retinal neurons are (evolutionarily) extruded parts of the visual processing part of the brain, so there is a great deal of signal processing being done by brain matter local to the retinas, which reduces the bandwidth required between the eyes and the visual cortex much further back in the skull. Alot of the processing deals with the signal gain based on accumulated charges; information reduction ("lossy encoding") is greater when there is a lot of GDP->GTP activity in the visual cells (i.e., when it's bright), while amplification and (probably) some extrapolation occurs when there is less GDP->GTP activity. This is a much shorter control loop than the one which causes iris contraction, or look-away reflexes, and is what is studied when it comes to frame rates and "psychovisual compression" (and a large part of why movies with 24fps look much better in a dark cinema or room and 60Hz monitors look flickery in a brightly lit office).
What is surprising is that the reaction cross section of the photopigments in the human eye is as large as it is
I think we're likely to see flying cars, Turing-level AI, and vacations on the moon before we need 128-bit pointers.
128-bit linear addressing is not so useful, but you can introduce structure into the address so that (for example) the first 64 bits is a network address and the second 64 bits is the address of storage at that network address. This requires distributing the functionality of the MMU across various network elements, but is not especially novel, and from a software perspective is a special case of NUMA. (The special case lends itself to some clever scheduling based on the delay hints available in a further structured network address, especially if you generally organize things such that the XOR of two network addresses is a useful (if not perfect) delay metric from the perspective of an accessor).
This can even be done "in the small" on a non-networked host by allocating "network addresses" in the top 64 bits to local random access storage. You could look at this as a form of segmented memory (MULTICS style) or as an automatic handling of open(2)+mmap(2) based on (for example) a 64 bit encoding of a path name in the MSBs of the addresses. That is, dereferencing computer memory address 0xDEADBEEF00000001 automatically opens and mmaps a file corresponding to 0xDEADBEEF.
The opportunities to abstract away networked file systems without losing (or even while gaining) useful information about objects' characteristics (proximity, responsiveness, staleness) suggests that the address size used at the level of a primitive ISA that uses pseudo-flat addressing is mainly limited by the overhead of hauling around extra bytes per memory access. Pseudo-flat addressing can also in principle steal ideas from X86's various addressing models for dealing with addresses of different lengths.
Ultimately, the difficulty is in the directory problem. That does not go away even if you use radically different "addresses" for objects -- directories are already a pain if you use URLs/URIs for example, or if you use POSIX style filenames, or whatever, and the problem worsens when you have different "addresses" for the same logical object.
(Fun is when you have to figure out race conditions involving a structured set of bytes that is in a file shared out by AFP, SMB, NFS, and WebDAV, as well as being in use locally, with client software responsible for choosing the most appropriate available access method since there is no guarantee that any one of these methods will work for all clients at all times).
One possible approach to this is to insist that any reachable object is a persistent object, with a permanent universal name. If you have the permanent universal name, the object is either available to you or errors out. If you do not have the permanent universal name, you are out of luck unless you have a "locator" that points to it (or points to something that points to something that... points to it). This is in some ways much easier if what is pointed to by a permanent universal name is immutable, and if most such objects are compositions of primitive PUNs, the most primitive and common of which ("well known PUNs") can be cached or recalculated locally.
[cf Church encoding, Morgensen-Scott encoding and normalization in the computer science sense]
3000nm flight paths are in the limit of short haul hypersonics mainly because of accelerations, even assuming straight-out/(nearly)straight-up and (nearly)straight-down/straight-in terminal flight profiles to avoid lingering in high drag conditions.
The critical problem is accelerations versus passenger tolerance; reaching TASes in the range of 1.3-1.7e03 m/s and back again at comfortable accelerations (say, < 0.4 m/s^2) will take considerable time (an hour), even assuming a constant acceleration is feasible (it's not, without lots of work on propulsion economics). In flight "kicks" are plausible within limits (people strap in when turbulence is predicted, but swivelling chairs have posed serious interior design -- not decoration! -- problems).
Aggressive acceleration that keeps passengers seatbound throughout a 2 hour flight is unlikely to be very popular unless it's also much cheaper than a traditional transonic flight at about five hours (averaging the jetstream, which is also not really present at economic altitudes for hypersonic transport).
For passenger transport, it is the longest haul flights that are the most attractive, since the biggest gains against subsonic flight are made when the time spent in hypercruise is longest.
It is possible that specific travellers (business people? politicians? 'puter nerds?) might put up with sustained uncomfortable accelerations for marginally faster trans-USA flights, of course, but intercontinental flight seems more attractive.
The big advantage would be to allow supersonic or hypersonic flights over continental landmasses
Like Eurasia and the various populated islands on the "Kangaroo Run", certainly.
However, even considering strictly over-water routes, not leaving a boom carpet across the ocean is going to make for happier environmentalists (and ocean ship crews, especially if numbers of flights start climbing to those experienced on NATs/PACOTs).
the drag drops
Assuming that having to fly at all in the trans-sonic regime (even for short periods) does not add a ridiculous mass penalty (fuel, propulsion system), and that L/D is reasonable enough in subsonic that terminal phases aren't hugely consumptive of fuel, and that great circle routing is straightforward, hypersonic transport should be competitive with foreseeable developments in transonic, ultra-long-haul commercial air transport except in the area of fatter, fuller planes. There is considerable scope for efficiency gain in post-A380 superjumbos, with respect to kg fuel per revenue passenger mile.
(On the other hand, the vast array of "in-flight entertainment" available on steamships did not save the passenger liner industry from the discomforts of early intercontinental passenger aviation, despite the cost, discomfort (noise! yikes!), technical stops, unsurvivable catastrophic accidents, and so forth).
the heating issues are still uhh, very non-trivial
Materials science is one of the critical paths in aviation in all flight regimes.:-)
Probably the biggest problem with hypersonic engineering is that replicating hypersonic flight conditions is, uh, extremely challenging.
There are lots of ideas about metal alloy foams and aerogels, many of which are increasingly cheap and easy to make, but predicting their in-flight behaviours becomes harder and more expensive with increasing Mach number.
Development costs will dwarf manufacturing costs, or it simply won't happen. If the full development costs are rolled into the final products then you would hate to know what a fleet of such jets would cost. That is unlikely to happen though, mainly since it has never happened before.:-):-) With the hardest development costs paid for through funded academic research and to some degree military application, hypersonic aircraft may (in all likelihood, must) not cost much more than subsonic aircraft, in present value terms of the full capital and running costs.
People survive for quite some time in cold hypoxic or anoxic environments, but time of useful consciousness is on the order of single-digit seconds, and time to recover useful consciousness is proportional to time and degree of exposure, but is at least on the order of several minutes. Pilots likely would have to be masked, and possibly suited, for operations at that altitude, since an emergency descent is limited by structural considerations (how quickly you can decelerate without snapping -- or melting -- flying surfaces) and can take many minutes from that altitude.
Outright onboard fatalities from exposures of several minutes during an emergency descent would be unlikely in healthy adults, and don't seem exceptionally risky in healthy walking children. However, a few minutes of near anoxia and several more minutes of hypoxia will not do anyone much good -- there will be a hell of a hangover at the very least, and a substantial risk of fatal complications of HAPE and HACE arising later.
Another important consideration is fuel loading -- at tolerable altitudes (below 4000m AMSL) the aircraft will not be able to sustain a high subsonic Mach number without huge fuel burn, and is unlikely to carry sufficient fuel for longer, slower flight. The emergency travel distance is therefore a factor. This raises another key problem: inertia.
Turning times are limited by acceleration forces ("gees") both for passenger comfort and structural integrity. The radius of a turn increases with the square of velocity for a given "gee", which implies either a much more straight-line flight pattern than is usual even under ETOPS rules, or higher accelerations in turns (felt by passengers and by structure). A reasonable ultra-long-haul hypersonic flight pattern would be nearly a great circle, which means an emergency descent over an ocean may require a water ditching simply because a suitable airstrip cannot be reached after descending below 4000m.
Accelerations are also important in the climb and descent phase in normal operations, since passengers will not enjoy long periods of noticeable (> 0.1 gee) longitudinal (front-to-back/back-to-front aircraftwise) acceleration, or even short periods of noticeable lateral accelerations, since both will keep passengers seatbound. Accelerations of greater than 1 g have serious structural implications and will preclude a variety of travellers. Accelerations of greater than 2 g are infeasible for commercial travel.
Operations research in this area uses flight simulators a lot (Laminar Research's X-Plane is a popular engine/front-end because it produces acceptable approximations of real physical conditions in almost aribtrary situations, and lets plug-ins do a better job as necessary). Simulated fast supercruise and hypercruise routinely runs into the descent planning problem -- gentle acceleration accumulates a great deal of kinetic energy which has to be gently ditched, and timing problems of merely a few seconds in hypersonic travel (M > 4.0) routinely lead to overshoots or underruns of hundreds of kilometres. These are unavoidable without compromising passenger comfort, structural integrity, or fuel budget. Reentry test vehicles generally trade away human comfort and fuel budgeting (many are almost entirely unfuelled) for structural integrity in order to hit a target area on the ground. This is not a reasonable tradeoff for commercial passenger travel. Fuel is expensive, and backtracking can be just as expensive (and much slower) as powering through a descent started too early. Passengers won't fly if it hurts, even if they are willing to put up with the discomforts of long haul subsonic travel in cramped conditions.
The biggest problem in hypersonic commercial transport is going to be that it intersects with subsonic commercial transport in the terminal phases of flight (ascent, descent, and probably ground operations) but the regulatory regime above FL
No, the 1/24 is not the expected state. It is the case that if 25 flows are in equilibrium, each will occupy 1/25 of the bottleneck bandwidth, however there are several reasons to expect that equilibrium is transient.
1. Slow start is disequilibriating.
2. Slow start happens when each new web-surfing TCP connection starts pumping replies back from the server.
3. Web surfing is typically bursty because of the transactional nature of HTTP (even accounting for pipelining). These bursts are themselves disequilibriating. Bulk transfers certainly happen in web surfing, however, but consider:
4. P2P bulk transfers tend to be broken into chunks of a few (9-10ish) megabytes, after which the TCP session is frequently closed. This behaviour is rarely synchronized, so serves as a further disequilibriating pressure upon the other TCPs using the bottlneck, by introducing both quiet periods and slow starts.
5. TCP bulk transfers are mutually competitive; they continually probe the bottleneck bandwidth (additive increase per lossless window) and the additional segment is disequilibriating.
Random early drop disciplines bust up equilibrium in a statistically fair way (the biggest user of a bottleneck with a random drop discipline is most likely to experience the drop), which in turn breaks up unfairly large buffer occupancy, which is the biggest source of noticeable delay for new TCP connection establishment. Whether cleverer disciplines work better is a matter for fine-tuning, but any RED configuration that permits multiple buffer occupancy statistically, up to a maximum less than the total buffer size, is always better than tail-drop (which permits total occupancy).
User-noticeable congestion is worst when initial handshake delays are high due to retransmits without a reasonable RTT estimate. The next most noticeable problem is a full round-trip timeout, even when the sRTT is well understood by the retransmitter.
An argument can be made to reduce the occurrence of triggering a full RTO by dropping first against known heavy users of a bottleneck. Whether the accounting necessary to guarantee this outweighs any stochastic approach is an open question in congestion avoidance research.
"... to keep his traffic from walking all over you..." is and should be a non-goal. TCP connections are mutually competitive, and the actual goal is to avoid situations where interactive users notice slowdowns because of the behaviours of automated/unmonitored traffic. Making assumptions about that is hazardous, since there are difficulties in knowing a priori whether a given bulk flow is being monitored by an impatient human being. Thus, we want to focus on the most common states that trigger user impatience, and those are almost entirely due to RTO.
Early drop avoids RTO at the cost of fast-retransmit/fast-recovery or checkerboarding retransmissions due to implicit signals (drops), or processing early explicit congestion signalling slowdowns as if the actual drop happened.
Reducing the incidence of default-RTT-estimate RTO is probably useful, if it can be done without enormous extra processing power or state retention in routers.
Unfortunately, many network operators think of deliberate-discard implicit congestion signalling as somehow evil, despite evidence that it works better than tail-drop in the real Internet.
The problem for the two users in your scenario is that bulk transfers with differing round trip times tend to synchronize through constructive interference. This will be felt hardest by the interactive user whose traffic is inherently bursty rather than smooth bulk transfers, and short lived rather than long lived, since the transmitter will not have gathered enough information about the RTT and congestion window to adapt well to the wavelike patterns that develop during synchnronization.
Synchronized drops/synchronized recovery is bad. Full occupation of bottlenecks with useful tra
Personally, I think that the inability to go back and edit posts is one of the great strengths of/.
Accepting a few "oops, I really meant..." clarifications instead of a set of complex rules on what a "small tweak" is worthwhile.
Preserving the flow of conversation is useful for third parties (e.g. moderators and metamoderators), and it is difficult to do this if earlier parts of the conversation can be edited.
Inserting a "not" or "un" to reverse an initial (and wrong) assertion, for example, could be unfair unless all interested parties can see the before and after... and how do you notify people in the middle of reading or otherwise participating in a conversation that earlier parts of the conversation have just been edited?
It is easier to avoid most of these types of questions altogether, and it turns out that the cost is mainly a few extra clarifying postings from time to time, and nearly-simultaneous redundant replies that persist "forever". And typo jokes. Lots of those.
Mbone has been obsolete for years. Native multicast has been done with sparse mode PIM (for joins and prunes), BGP multicast NLRI (for source information), and a (1,*) approach for several years now. The (*,*) (S,G) (source,group) approach simply did not work out in practice.
Several ISPs offer multicasting as part of leased line services. There is little magic in it, and initial setup is pretty much fully automatable after assigning group addresses. Consequently, these ISPs usually don't charge extra for native multicast.
There are three big issues with respect to native multicast for content distribution.
(1). PIM-SM+BGP-mNLRI means few (one) transmitters per multicast group. This is generally called single-source-multicast (SSM), and scales to large numbers of G in (S,G) == (1,*) state. Multiple transmitters can feed into the single source through other channels (unicast or anycast, for example), and Mbone was ultimately shut down operationally by gatewaying Mbone groups through a single source controlled by David Meyer, then of the University of Oregon, several years ago.
P2P applications are not geared for SSM, and (1,*) native multicast is probably not useful for distributing anything other than tracker or other directory information.
Although one could align a P2P system such that each chunk gets its own S,G state, the processes for assigning group addresses is not well automated globally, and worse, the process for *announcing* active sources is essentially restricted to a combination of BGP and the equivalent of bulletin board pastings (i.e., out of band pre-announcements). This is not fundamentally different from how most P2P systems work now, but introduces more complicated machinery for little (or no) obvious gain.
(2). Most point to point connections (e.g. DSL) use routing equipment which does not transmit native multicast, does not talk PIM-SM, and/or does not gateway IGMP. Sourceward joins and prunes therefore require some anycast magic, and actual traffic requires some form of unicast tunneling. There are a variety of approaches to this, but they all introduce network overhead. This is unattractive for P2P.
(3). The nature of multicast leads to an efficiency gain when large portions of a S->G tree are shared among multiple joiners. Generally this favours live broadcasts; P2P is almost always recorded content, and while multicast can repeat the content in a loop with a schedule that helps clients determine when to join or prune, actual P2P that searches swarms for missing appears to be more efficient. A hybrid approach is possible, but the potential gain does not appear large enough to justify the additional complexity and overhead of (1) and (2).
(3) (a) Missing chunks / side channels. When multicasting to a large group, a source does not want to be buried in control messages (ACKs, NAKs), so flow control is almost essentially non existent, and missing chunks are usually replayed to a set schedule as per (3). Listeners need side channels to acquire that schedule. A P2P search is more straightforward and probably more responsive, and rare chunks may distribute faster in a reasonable swarm than waiting on a loop from a relatively slow SSM originator. Asks propagated to the SSM originator are known to cause swarm slowdowns for P2P; they can become unintentional DDOSes (or exploited to create intentional DDOSes) on multicast sources in any (S,G) model.
(4). Multicast does not have a flow control mechanism. A listener joining to a group takes all that group's traffic, or none. If the traffic exceeds bandwidth availability, the listener will observe many missing packets, and there may be collateral damage due to congestion. The only reasonable response a listener has is to unjoin the group.
There are two approaches to this which scale with (1,*) state, namely many parallel groups, where each group adds extra detail, and listenerward caching. The former runs into administrative issues (group add
Yes, very true. European Union has more legislative power than national goverments, de jure
Without nitpicking about the legal entities involved (the EC is more legislatively important right now), the overall EU project's legislative and regulatory competence has been constrained by the principle of subsidiarity, which was formalized in the Maastricht Treaty, and is presently found in the current version of the European Community Treaty in Aritcle 5, with detailed rules in Protocol 30.
Included in the wording is the condition that the EC may legislate and regulate "only if and in so far as the objectives of the proposed action cannot be sufficiently achieved by the Member States ".
The proposed Constitution constrains both the European Union (as it then will be) and the Member States with respect to acting only when it is manifestly inefficient or ineffective to do so at a regional or local level.
Note that the ECJ has ruled fairly consistently against overreaches that are not in keeping with the principle of subsidiarity, which is one reason why a frequent course of events is for the Commission to propose to the Member States that they individually pass legislation consistent with something agreed to in Brussels by the Commission and the Member States (by consensus), rather than using the formal Pillar system. Apart from the obvious practice of avoiding the scrutiny and occasional interference by the European Parliament (which is surprisingly good at detailed study of proposed legislation), it is also a recognition that the ECJ might insist that the Member States individually pass the appropriate legislation anyway.
Unfortunately this looks somewhat undemocratic, since the consensus building in Brussels is not transparent, and since the Member States who helped form the consensus "complain" to their domestic audience that unpopular legislation that they helped formulate is being imposed "by Brussels". Also, Member States's governments of the day actively discourage one another from resiling from such consensus agreements when they turn out to be unpopular, which misses the whole point of bringing the agreed policies to the national parliaments in the first place.
One of the side effects of TECE, including the current Lisbon Agreement version, is that the consensus building process will be made more transparent, especially to the European Parliament, which will also be able to insist on its own review of "backdoor" Union-wide initiatives. Substantial delaying and derailing power is therefore being put into the hands of the directly-elected MEPs, which is part of the ongoing evolution of the Union as a union of the people living in it, rather than a union only of the governments of the day of the various Member States.
De facto power, many people feel, is still on the local city / country government
There should be a written recognition that the power of all parts of the European Union originates in individual citizens of the Union. Period.
Subsidiarity is a step in that direction. The new Article 8 proposed in Lisbon addresses subsidiarity and proportionality directly, with grudging compromises among the factions who see the union membership of that of the Member States and those who see it as being a body for the people in Europe.
You might want to take a look in particular at the proposed new clauses 8(a)(1-3) and 8(b)(4).
If I disclose information to you, your power with respect to me increases. One way to address this power imbalance is for you to similarly disclose information to me. We both have less privacy, but the balance of power is maintained. But this mechanism fails utterly if you and I have different power levels to begin with.
The reality is that right now there are already enormous differences in power between employers and obligate employees -- people who must work for a living, and whose skills (whatever they may be) are not readily sold to another employer locally. This power is used now to force asymmetrical disclosures -- everything from details of the employee's personal life to directly observed urinating into sample jars.
Even if one rejects the idea that fairness is a useful -- or even possible -- goal, mandating symmetrical or at least mutual disclosures almost certainly would limit the amount and invasiveness of personal disclosures the more powerful require from the less powerful in the general case.
In exceptional cases there will be powerful people -- including those who are financially independent -- who would willingly disclose every aspect of their personal lives. This will include many celebrities, especially "celebutant[e]s", as well as those who believe that they live exemplarily moral lives.
In the more general case, even financially independent people fear exposure, social disapproval and accusations of hypocrisy over at least some things, mainly because humans are rarely completely socially independent, non-judgemental or unconcerned with their public image.
If voters demand that their politicians live in a goldfish bowl before they support monitoring members of the electorate, there are lots of politicians who probably would be more keen on constraining surveillance, since there is an abundance of them hiding embarassing personal secrets from the public.
On the other hand, if this discourages people with secrets from holding elected offices, they might end up with porn stars and self-destructive musicians as legislators! Or bloggers...
A lot of this depends on how franchise holders (electors or shareholders) organize and use their votes. There is occasional political pressure to introduce things like a Freedom of Information Act or entrenched legal protections for professional investigative journalists and amateur whistleblowers. Occasionally corporate shareholders will require greater openness by executive remuneration committees or individuals hoping to sit on the board of directors.
That these activities do not end a power-imbalance is not surprising, and is not even the point. The issue is preventing abuses by the already powerful against the already less powerful, especially when those abuses increase the existing power-imbalance.
If preventing further exploitation is the point, then the judgement that symmetrical disclosures "fail utterly" appears to be contradicted by the evolution of open government and corporate transparency over the past fifty years in (most) OECD countries (most of the time).
If mutually assured disclosures also "fail utterly" to limit exploitation, then why do governments and senior corporte executives work so hard to keep secrets from voters and shareholders, to the point of redaction, document-destruction, unminuted decision-taking meetings, frequent assertions of privileged confidentiality, and so forth?
An alternate reality in which DNSSEC does not suck?
The DNS is a generalized database; since at least Project Athena's Hesiod (1983), and in IETF standards since at least RFC 1464 (1993), storing management and user information in the DNS has been commonplace. Why? Because it's useful to have a distributed hierarchical database with a light weight and rapid query/response, good failure resilience, decent caching, and a host (pardon the pun) of other features. It's especially useful when the keys are aligned with the hierarchy of DNS names anyway.
Some of this information is private for a variety of reasons, and servers are often configured to give it only to particular ranges of addresses.
Encrypting the sensitive RRs with a pre-shared key would be feasible (give or take the difficulties in the "pre-" part, which are probably soluble with DHCP), but that eliminates the light weight and rapid query/response because encrypted information tends to require large responses, leading to partial-loss/full-retransmissions risks, or [T]TCP, both of which increase the total amount of data, state, and time-to-acquire-answer.
However sometimes the domain name parts themselves are sensitive, and that conflicts badly with DNSSEC as it exists now because of NSEC following. NSEC3 is now at best experimental and subject to substantial change, in spite of the wording in the I-Ds. Split domains are hard, DNSSEC makes it harder.
Dynamic DNS updates and DNSSEC don't interoperate well at all, and Secure Dynamic Update and NSEC3 still have some open interoperability problems. This is a bear in a world where one acquires new A or especially AAAA RRs by arriving on a LIS supporting DHCP or prefix autoconfiguration (for example) but want to maintain a consistent global hostname.
DNS has been an absolutely reliable indicator of the authenticity of a site
No, it's an indication of authenticity of the origin of the DNS information one gets from some random cache, including negative caching information (NXDOMAINs), and it also provides additional data integrity as a side-effect.
Making authentic information cacheable is a useful goal for scalability reasons.
However, DNSSEC does this in a way which precludes a number of other practical uses of the DNS, for which the answer "don't use the DNS for private data, replicate the DNS hierarchy in another separate directory system!" is not currently realistic.
Moreover, the scalability win of caching data which are authentic for the duration of the ttl is clawed back by the increase in TCP-based transfers caused by zone enumeration (or the extra caching of large amounts of probably extraneous data to try to mitigate that for the originating server).
Authentic DNS information is useful in determining the binding between sets of entries in the DNS (typically that the fully qualified DNS name has an A or AAAA RR and that the corresponding IN-ADDR.ARPA. or IP6.ARPA. DNS names point back to the FQDN). This does not tell you whether the IP/IPv6 routing system will take your packets to the target you want -- routing attacks, interception attacks, and subverted hosts are not detected by DNSSEC.
Where DNSSEC helps (a little) is in the promulgation of PKI public keys that can detect these attacks, either at the application/service level (as with TLS) or at the network level (IPSEC). However, DNSSEC is not necessary for distributing PKI keys tied to the DNS hierarchy (one can still verify public keys out of band), and TLS is unlikely to be replaced by cleartext application conversations protected by opportunistic IPSEC ESP.
Sadly, my take on DNSSEC is that what it does is so readily misunderstood, even by people who are familiar with the DNS, that the standards are going to remain fluid for a while, and deployment will happen only by early adopters who have the time to adapt to the possible changes.
Firstly, this is a matter of civil law, rather than criminal law. The balance of power between juries and judges are dramatically different in trials at civil law than in criminal cases. More on that later.
In criminal law, in Canada, there is a real legal difference between a jury's refusal to convict an accused person at a criminal trial, and the U.S. concept of jury nullification. This is primarily due to substantial differences in case law which developed in the mid-to-late1800s in both legal systems which entrenched a right to make legal arguments to a jury, or to a judge in the presence of a jury which could form its own impressions of the arguments in the rendering of a verdict under certain circumstances (United States vs Fenwick 1836, Stettinius vs United States 1839 contra Games vs Stiles 1840, Sparf vs United States 1895). In the mid to late 20th century several cases in the USA upheld the jury's power to refuse to convict based on points of law, but hedged by restricting officers of the court from informing jurors of the power with the argument that it gives licence to jurors to disregard the law entirely in favour of deciding any individual case based on personal prejudices and feelings about the parties involved.
In Canada, juries have long been able to make strong (but not always binding) suggestions with respect to sentencing, if they choose to convict -- almost always this involves urging a lighter sentence upon the trial judge, often a conditional discharge. This is unusual in systems which inherited the English criminal justice tradition, but has had the effect of reducing even further the liklihood of a refusal to convict at all. As a result, there are only a handful of Supreme Court cases which have dealt with the issue directly.
R. v. Morgenthaler, [1988] 1 S.C.R. 30 is the culmination of appeals by the Crown against successive juries' refusal to convict Dr Morgenthaler in spite of what they believed was a clear cut case and clear instructions from the Judges. The decision confirms the right and moral duty of juries to refuse to convict when their consciences tell them otherwise; in their commentaries on the case history Dickson CJ, Lamer and Wilson JJ all made reference to the section 2(a) of the Canadian Charter of Rights and Freedoms (freedom of conscience) with respect to the actions of jurors, making it fairly clear that a jury's refusal to convict in the end was not sufficient reason to invalidate the outcome of a trial.
However, from the ruling:
Per Curiam: In a trial before judge and jury, the judge's role is to state the law and the jury's role is to apply that law to the facts of the case. To encourage a jury to ignore a law it does not like could not only lead to gross inequities but could also irresponsibly disturb the balance of the criminal law system. It was quite simply wrong to say to the jury that if they did not like the law they need not enforce it. Such practice, if commonly adopted, would undermine and place at risk the whole jury system.
Subsequent cases have followed this line: juries can refuse to convict, and that refusal is on its face insufficient grounds for appeal [R. v. Krieger, 2006 SCC 47, [2006] 2 S.C.R. 501], but at the same time judges are entitled to vigorously and forcefully instruct juries not to do so [R. v. Latimer, 2001 SCC 1, [2001] 1 S.C.R. 3]: "The trial judge did not prejudice the accused's rights in replying to the question from the jury on whether it could offer input on sentencing. The trial did not become unfair simply because the trial judge undermined the jury's de facto power to nullify... Guarding against jury nullification is a desirable and legitimate exercise for a trial judge; in fact a judge is required to take steps to ensure that the jury will apply the law properly."
As the powers -- and even the existence -- of a jury were claimed in the face of proper tyrants looking to jail or execute people for personal an
Redundancy isn't the problem. Mirroring writes of something that overwrites good data with bad data is a poor strategy.
Recovery is the problem. When you accidentally delete a file, save bad data on top of an existing file, or a bug or hardware crash strikes and messes important data up, you want to be able to undo that easily.
That is, while your data-scatter idea is fine, the data-gather part needs to work when the user decides the existing version of data is bad, and that a previous version might be good.
The German post of Chancellor is approximately that of Prime Minister; there is also a President. Power primarily resides with the Chancellor though.
Maybe if I added parentheses and changed a conjunction, my initial meaning would have been clearer:
In France (or Germany), for example, the President (or Chancellor in Germany)...
In other words, there is no disagreement here.
However:
(I can't think of any case in recent history where someone was PM who wasn't also leader of his or her party.)
There are only three Prime Ministers in recent history. Four if you go back 17 years to Thatcher.
Tony Blair ceased being the leader of the Labour Party on 24 June 2007 and ceased being the Prime Minister on 27 June 2007.
That's not a very long period of time, and neither was Margaret Thatcher's single day (27-28 November 1990), but it underscores an important Constitutional point: a Prime Minister always has the right to face Parliament to attempt to secure the confidence of the House of Commons in his or her own right.
A Motion of Confidence introduced by the government (i.e., by the Prime Minister, the Leader of the Government in the House of Commons, or another senior Cabinet Minister) also takes precedence over all other business of the House of Commons excluding those calling upon the Speaker to see Strangers. They are rare -- the last one voted in Westminster was in 1945, and the most recent one tabled was in 1993 -- and are essentially threats, such that if the Nays prevail, the House immediately adjourns in anticipation of dissolution. However, they are a significant tool of the Prime Minister in that if he can demonstrate command of the House of Commons despite the opposition of M.P.s in his own party, there is no constitutional mechanism by which they can force him to resign.
By contrast, the UK Prime Minister serves at the whim of his or her party... without any need for a formal impeachment.
No, the Prime Minister continues to serve at his or her own whim, until he dies, names a replacement, or loses the confidence of the House of Commons twice -- the first triggering a general election, and the second during the exercise of his right to face Parliament and secure the confidence of the House of Commons.
It is a strong tradition that Prime Ministers rapidly "recommend" a successor to the monarch after losing a general election, but the Constitutional convention is that the PM is not obliged to do so, since she may be able to assemble a majority of MPs from different parties willing to vote in her favour on matters of confidence.
Thatcher could not assemble such a majority, and had no prospect of being able to do so after a general election, so she resigned about as gracefully as she could manage. Legally, however, she could have dissolved the House of Commons, fought a general election campaign, seek the confidence of the newly elected and re-elected M.P.s, fail to do so, and dissolve the House of Commons yet again, in order to seek the confidence of the newly newly elected and re-elected M.P.s probably to find that there would be none left. At that point, not naming a successor who would likely command the House of Commons would provoke a serious Constitutional crisis involving the monarch acting on her own or with the advice of someone other than the Prime Minister. Those two things are never done.
In fact, the Constitution of Ireland codifies this explicitly to make it clear that the President has absolute and exclusive say over a Prime Minister's fate if the latter seeks a dissolution immediately after an election triggered by a loss of confidence. Canada has been pursuing a similar statutory codification, although it may require an outright constitutional amendment there.
Slashdot Mirror
launchd is awesomesauce; good riddance to init and the tree of ugly rc scripts.
Good bye to idiosyncratic runlevels.
Good bye questions about whether something should be in /etc/rc*, or should be managed by inetd or xinetd, good bye complexities of cron scripting, and so forth.
Take a look around in /System/Library/LaunchDaemons and /System/Library/LaunchAgents.
Start here:
boot single user (command-s during POST) / / /System/Library/LaunchDaemons /System/Library/LaunchDaemons/com.apple.kextd.plist /System/Library/LaunchDaemons/com.apple.notifyd.plist /System/Library/LaunchDaemons/com.apple.configd.plist /System/Library/LaunchDaemon/com.apple.DirectoryServices.plist /Volume/other
# fsck -fy
# mount -uw
# cd
# launchctl load
# launchctl load
# launchctl load
# launchctl load
# echo whee, now i can do useful things
# diskutil list
# diskutil repairVolume
etc.
if you want more things to be runing, you just launchctl load it; you can use launchctl stop or launchctl unload to turn off things as they become unnecessary.
when you switch to multiuser mode, launchd will load in plist files in its search path; when you log in as a user, it does so for things in the user's search path, as that user. Very handy.
Note that the plist files are all in xml1 format, and you can run ed on them if you want.
plutil -convert xml1 binarypreferencelist.plist
lets you use ed on any system configuration file. the system will reconvert to binary format for efficiency in most cases, either as the file is loaded initially or when it is next written out by any apps that manage it.
launchd/launchctl have extensive debugging facilities and will let you know what launchd is doing without having to resort to "ps | grep ...".
You can manage a Mac using nothing but ed, plutil, launchctl, softwareupdate, your favourite pager or tail or cat, (and on Mac OS X server, you may want to use serveradmin for some things). You can probably do everything you need to with a fully headless Mac without resorting to anything other than ssh (i.e., no 'cheating' with VNC/ARD). A number of people have one or more Macs that are managed in this sort of GUIless way, and most people using Darwin alone (e.g. on non-Apple-branded hardware!) pretty much have to.
You will also want to know about opendirectory stuff if you have a network full of machines, or want to edit user accounts.
# dscl /Local/Default -read /Users/Guest /Local/Default -read /Groups/wheel
# dscl
You can use dscl or the ldap tools to explore or modify your directory information; no more fussing around with password, shadow password, group, ... files, and if you have a network, you just substitute "/LDAPv3/server.fq.dn" for "/Local/Default", depending on what search policy you configure.
Finally, although I am quite happy to attack things at the command line via SSH, I sure appreciate the opportunity to be lazy for some things, and connect via VNC, either by clicking in the Finder sidebar on the Mac I'm sitting at, or by using command-K and a vnc://.../ URL.
There's a lot of new stuff in 10.5 for someone who is more used to an Edition VII Workbench style of system management, or even standalone NetBSD or Linux systems. Opendirectory is pretty straightforward for anyone used to networks of managed workstations and single sign on (whether in the land of Windows or MIT Athena). launchd is easier to learn than it was to learn all the places where processes could be started up. plists and good hygeine in hierarchical file naming mean that "locate com.apple.xgrid.agent" (or mdfind instead of locate) will find you all the relevant config files. these plists can be converted to xml1 as necessary
Fire : Mule comparison is new to me, so I hope you don't mind if I play. :-)
Mules are composed of cells. Fire is clearly not cellular life. Of course, viruses aren't cellular life either, but they are still bounded (encapsulated) and readily quantified given a sufficiently powerful microscope. Fire is not made up of encapsulated anything at any scale at all, even given a microscope that can see right down to the level of an atomic nucleus.
That said, prions and the primordial inhabitants of hypothetical RNA-world are pretty arguably life too, and they aren't encapsulated either. However, they are characterized by two physical attributes.
Firstly, they have a per-species similar, quantifiable, many-atom molecular structure that is more abundant given a larger sample. It's hard to argue this is the case for fire, which almost always reduces the count of many-atom molecules. Fire is almost entirely oxidization/catabolism; there is practically zero reduction/anabolism, and to the extent that molecules of more than a few daltons are produced by any fire at all, the molecules are largely dissimilar.
Secondly, life couples to background thermodynamically-favourable reactions in order to pay for thermodynamically-unfavourable ones (like anabolism). This is one of its key characteristics, and the presence of an electron transfer chain and/or protein pump that does work across an unfavourable gradient is a critical aspect of life. That is, a key aspect of life is that it decreases entropy[*] locally by exporting it to the less-local environment. Fire does not do this; it is in itself a thermodynamically favourable local increase in entropy; ash has a lot less macroscopic structure than wood, for example.
So, for reasons of metabolism (in the thermodynamic sense) and structure (molecular or cellular), mules are alive, whereas fires are not.
I deliberately did not discuss "reproduction" up to this point.
Mule cells reproduce themselves by mitosis, differentiation and other processes, so mules are a collection of reproducing things, like sponges, jellyfish or slime moulds, rather than a single reproducing thing. Most biologists (particularly evolutionary ones) don't really consider reproductive potential except as an after the fact assessment of environmental fitness. So a mule is no different from a non-sterile horse that dies before producing viable offspring.
Moreover, not all mules are sterile. Some (merely dozens) of female mules have produced viable offspring naturally with both horses and donkeys. Although male mules are much much much more likely to be unable to produce a viable foal with an egg from a horse or donkey, the chances are not zero, and they increase substantially if the other partner is a female mule.
Given an environment which sustains mule populations at all, it is impossible to totally preclude a population of fertile mules. (In general it would "merely" require some minor mutations to the mule DNA polymerase in the female egg, matching the DNA polymerase mutation which resulted in the 60-ish mule-born foals; the second mutation would allow the integration of the mule male's sperm into the initial zygotic cell and its somatic and germline descendants).
So, adaptation is also a key feature of life. Fires are not adaptable. Evidence of a fire that adapts to its environment over geological time scales (like life did) would be pretty good evidence that fire is alot more life-like than it is generally considered. There are living organisms on the planet which are provably thousands of years old, and there is speciation of microbes (and Drosophilids) in labs.
Do you know of a fire which is provably thousands of years old, or which has mutated in a way consistent with evolution (minus the DNA/RNA part) in a laboratory environment?
There is good evidence of adaptation of prions to environmental selection pressures in laboratory conditions. There is exceptionally good evidence favouri
They're there. You have to work around them. That's an engineering fact, not a comment on their aesthetics. Such aesthetic concerns are not really in the realm of engineering; it is not engineering if you are unwilling to engineer a fix or workaround just because the problem is ugly.
Moreover, simply repeating "NATs are ugly" or listing off justifications for that opinion is not going to get rid of them.
That there are difficulties in NAT traversal for protocols that require knowledge of counterparty NLAs or for applications that require rendezvous with particular counterparties at arbitrary times is a truism, not an argument against engineering a generic workaround API.
Confusing a truism that is part of the problem statement with a solution is poor engineering practice. "If only they weren't there!" does not make NAT traversal easier for anyone.
That said, there are several largely working toolsets for doing NAT traversal; several are open source, freely available and probably unencumbered. The people working on them accept bug reports, especially where your (reduceable, repeatable) experience conflicts with the expectation of "it just works". Presumably people working on 3rd party applications that have problems traversing NATs take bug reports too. You know the drill.
Yes. http://www.dns-sd.org/ for DNS queries with dyanmically updated A and SRV RRs (among others); NAT-PMP or uPNP or STUN (or Teredo) for acquiring the information to update into those RRs.
Literally millions of people use these technologies daily as part of either using Back to my Mac, using a Mac OS X system behind an Apple Airport wireless station, or both. It works pretty well, and users don't even notice other than seeing their various machines in Finder window sidebars as they move their laptops around from subnet to subnet. It's also straightforward to put a NetBSD system into the mix (probably other similar sytems too), or to set up your own multiplatform Wide Area Bonjour server.
Gateway implementation bugs are not necessarily NAT-specific, as you note. Any feature -- new or existing, optional or mandatory -- can have bugs.
Policy issues affect non-translating firewalls just as they affect translating firewalls.
No, they aren't trivial problems (bugs bad; policy elucidation or creation problems bad) but they are not specific to NAT.
That NATs get in the way of operation should be incentive for generic workaround API development, rather than hoping that the NATs will just get out of the way. They're established and aren't going to vanish soon.
Port forwarding through a stateful firewall and NAT hole punching are identical for a higher level communication that does not embed network layer addresses (NLA, in this case IPv4) and expect them to be useful for the other party or for a long period of time or both.
Think of a trivial service like echo (TCP, RFC 862) where whatever application data is sent from the client is reflected back to the client unchanged by the server. If the client connects to 128.100.100.1 tcp port 7 it does not matter whether 128.100.100.1 is the actual server address behind a firewall that allows that connection, or is the address of a NAT that forwards port 7 to an internal host. Right?
Complex services which require rendezvous often have made unreliable assumptions about NLA lifetime and isotropy. These assumptions are the source of frustration. The lack of a stanard generic workaround for future rendezvous in the presence of ephemeral NLAs is another problem.
Trying to make NLAs non-ephemeral is a poor solution (it ends up becoming bridging); a better one is to have a stable handle that maps to a dynamically updated NLA/service-address. Wide Area Bonjour does this (mDNS + dns-sd + private dynamic DNS zones for updating A RRs and SRV RRs as they become discovered through NAT-PMP, uPNP, probing and feedback), and it helps with any application protocol that transfers DNS names and symbolic port names as rendezvous points instead of IP addresses (with implicit mappings for well-known ports).
Essentially all Mobile Me (formerly .Mac) users have a private (key-protected) DNS zone membername.members.mac.com that is updated by their various Mac OS X systems so that they can rendezvous with one another ("Back to my Mac"); the zones mainly contain A and SRV RRs keyed to the configured Computer Name (in System Preferences > Sharing).
Most Mobile Me customers can therefore do things like:
ssh mycomputername.mymembername.members.mac.com
which will result in a DNS service discovery query of
_ssh._tcp.mycomputername.mymembername.members.mac.com
which will resolve a SRV RR like
0 0 22 computername.real.dom.ain.
(and/or possibly other RRs like PTR, A, AAAA, CNAME or TXT).
Behind a NAT that might become "0 0 2193 nat-dns-name.some.where." or "0 0 41111 128.100.100.1".
ssh then will resolve the DNS name or use the IP/IPv6 literal, and use the port literal, and connect appropriately and seamlessly; host key checking is done on its argument, rather than on the intermediate indirection symbolic names or the ultimate NLA.
This works just as well for datagram type services as for connection-oriented ones.
Most of this is unencumbered open standards documented at http://www.dns-sd.org/ (for example).
The point however is to use something that really is long-lasting and isotropic, like a DNS name, as a rendezvous point. The Back to my Mac approach is illustrative, but is not a good choice, since key-protected private DNS names obviously are only isotropic for those that know the key!
A standard API for this sort of rendezvous among hosts that are subjected to NATs and being moved from one part of the network to another, and a general consensus about avoiding the use of NLAs as remotely-useful long-lived rendezvous handles, has been elusive in the IETF, mainly for political reasons.
This is particularly sad since many IETF conference goers migrate their own laptops from the conference wifi to their hotel rooms several times during the conference, and many of them have home and work machines behind a NAT or firewall they do not personally control, and yet they don't seem to mind the lack of session survival (or the hotchpotch of per-application recovery approaches) that results.
The problem lies in any apps written since the mid-1990s that make two critical assumptions about its own network layer (IP *or* IPv6) address (NLA, generically), and the same about its counterparties'.
Assumption one: the local address is universal and isotropic.
Assumption two: the local address is fixed and permanent.
These assumptions are bad with or without the presence of NAT, because of DHCP, renumbering, multihoming and mobility.
The first assumption leads to the embedding and use of NLAs in higher level protocols that lead to breakage when the NLA cannot be used as a destination address as it is. This can be because of transient routing problems (or deliberate policy), and can be avoided simply by using a simple indirection through the DNS or equivalent mapping database that will give up one or more NLAs which are valid as destination addresses.
NAT mainly serves to increase the incidence of problems associated with assumption one, because it generally introduces anisotropy to addresses. Obviously if "A" knows it's 10.0.0.6 and tells a counterparty "B" to connect to it at that address, if B is somewhere far away topologically, "B" is unlikely to be able to make use of it. One solution: embed symbolic DNS names into the stream and indirect through that. Instead of "10.0.0.6" with the assumption that a well known port (e.g. TCP, 20) embed (for example) ftp-data._tcp.mysymbolichostname.mygatewaydnszone.somesite.com into the stream and expect the other side to use do a SRV RR lookup in the DNS.
A bit of glue to tie NAT-and-firewall-hole-punching into an on-NAT/on-firewall nameserver is most of what's necessary to remove the need for application-level gatewaying and translating for simple connectivity purposes.
Older protocols (like ftp) are going to remain a problem; the reasons these have not been fixed already are largely political -- these older protocols are known to have serious security problems, and there are many people who reject wholesale the idea of adapting to the existence of NLA anisotropy in the real Internet.
This also gets in the way of host and subnet mobility and multihoming. We lack a standard session protocol which would allow for generic graceful reconnects of application-to-application communications as e.g. a mobile phone moves from a wifi to a 3g wireless provider and then to another wifi unrelated to the first; or as a conference attendee walks with her laptop from the conference wireless network to her hotel room. The standard again would largely involve a bit of glue around DHCP and dynamic DNS, and is stalled for mostly political reasons (security of DNS, and acceptance of this mode of mobility necessarily leading to transience of addresses and typically leading to transitioning from one anisotropic address to another).
NATs are simply there. Not adapting to them for aesthetic reasons is a poor engineering choice. Complaining that they are in the way is complaining about that engineering choice.
TCP (and any RFC 2001 congestion avoidance) fairness is on a per bulk transfer basis. Multiple bulk transfers for the same application is fair for all the bulk transfers, but unfair from the perspective of an application that runs only one bulk transfer. In the limit of low numbers of flows, with two data-moving applications sharing the same bottleneck with one bulk transfer each, "A" and "B" both get half of the bottleneck bandwidth; with four flows for "A" and one for "B", the former gets 4/5 of the bottleneck bandwidth and the latter 1/5, once the flows reach equilibrium.
This is still fair in the technical sense, because the bulk transfers find equilibrium. In the limit of large numbers of flows -- tens of thousands seen over a one second interval -- this works very well for sharing bottleneck bandwidths. This is important in places where congestion is most noticeable by the largest number of users: inter-provider gateways (like at internet exchange points) and in front of very long haul links (like across oceans). Individual users are unlikely to be able to gain a significantly larger share of that sort of bottleneck bandwidth just by opening lots of flows, because they will saturate a bottleneck somewhere else along the end to end path.
So a technical definition of fairness (bulk transfers find equilibrium and roughly equally distributes bottleneck bandwidth among the bulk transfers) is hugely useful in the most expensive parts of the Internet infrastructure.
However, at smaller, cheaper bottlenecks where opening multiple parallel bulk transfers gains a much larger share of the bottleneck, *and* where it causes adverse interference for the users of applications that open single bulk transfers, there are two answers: one is simply to expect that other apps that traditionally use a single TCP bulk transfer to parallelize the transfers. This will reduce goodput per packet transmitted because the probing of the bottleneck bandwidth will always incur packet, and that is likely to synchronize at FIFO bottlenecks. Another approach is to do smarter-than-FIFO queueing at bottlenecks, especially ones which carry small numbers of bulk transfers.
Ultimately, routers can only forward, delay or drop packets. FIFO forwards a packet immediately if there is nothing in the queue (no bottleneck), otherwise it delays a packet in a queue; if the queue is full, FIFO drops the packet. One can probabilistically impose an early delay or drop on packets easily (in terms of the amount of computation needed in the router), in a way which is more likely to punish the least congestion avoiding users (i.e., the ones with aggressive timers, or which open multiple parallel bulk transfers to try to dominate the bottleneck).
One approach is to look at the actual queue regularly, and preferentially drop from the largest occupant of the queue, where an occupant is identified by a tuple such as (src, dst) address 2-tuples. This requires lots of state and computation. random early drop (RED) is a very close approximation -- the liklihood of a drop increases in proportion to the queue depth, and it is very likely that an increasing drop probability will hit the largest user (as in src,dst) of the bottleneck when the queue depth is non-zero. A large user who does not increase queue pressure will not be penalized; a small user whose traffic is synchronized with queue growth will be signalled to avoid the congestion, and will probably spread out its use. RED works very well, and is cheap and easy. It is also counter-intuitive -- sadly, many network operating people don't like the idea of a random early packet drop, and don't understand that it does help, even when confronted with before and after graphs of real traffic; RED with ECN marking is an attempt to appeal to t
Large correction: the transport layer port numbers are not canonically part of the IP header. The protocol number is, however.
However, as I'll repeat below, I don't mind considering a pseudoaddress of {IP address (32 bits) + IP header protocol field (8 bits) + transport layer (src or dst) port (16 bits for UDP or TCP)} as a fundamentally routable object, provided one also sees almost every IP router implementation as imposing an in-built minimum prefix length filter of 32-bits. :-)
So this is wrong because "16-bit port" is a transport layer address and is transport layer protocol-specific. Even though UDP and TCP both use 16 bit port values, the mapping between well-known (and espeically dynamic) numbers to actual servers and clients is non-identical.
A smaller correction: the [32-bit opaque address] varies in opacity depending on topological location. On the originating host it's not opaque because the host has to distinguish at least between system-local traffic, subnet-local traffic (which should be resolved using ARP) and non-local traffic (which should be forwarded through a router). The distinction is that a local subnet has a known prefix and mask, which means there is structure expected in the 32 bits. Likewise at every intermediate system it's not opaque because it is subject to a CIDR-style mask-and-match search for an appropriate forwarding rule. Only at the final destination is it nearly opaque, in the sense that either the entire 32-bit value matches "me, the recipient, 1.2.3.4/32", discarded, or probably forwarded into a loop. (The final destination can also do a header-rewrite and then forward, which is most of what a NAT does).
Another small correction: CIDR decreased the complexity of the forwarding path of routers because a lookup was reduced to a trie (usually done as a Patricia tree or as an M-way search tree) which was amenable to mask-and-match optimizations in hardware. Nothing special was really needed in the path for the reserved unicast, local or multicast address spaces.
With classful exterior routing, there was no obvious way to avoid longish pipelines of mask-and-match-or-shift in hardware, or class-finding loops in software. In retrospect, with the early-2000s use of smallish TCAMs, this approach could have been tuned somewhat into at most four TCAM lookups with two being the typical case, however that approach was not available in the early 1990s.
BGP became slightly more complex code-wise, but the processing and storage complexity fell for the same set of NLRI data with the implementation of CIDR, independent of aggregation and route summarization, which caused even further falls by reducing the amount of NLRI data needed for full global default-free routing knowledge. Policy controls benefited from CIDR as well.
Classless interior routing benefited where the protocols could handle subnetting already. RIPv1 could not. Most others in use could, or were easily modified to allow for "supernetting", which tended to reduce the number of routers required to service the same number of physical subnets. Classless interior routing also led to complexity reductions in run time and storage in most intermediate systems (routers, switches, brouters, policy filters, ...). Those that had to cope with end systems that could not cope with non-classful routing at all (I am looking at you IBM AS/400!) accumulated kludgey configurations, however.
The latter semantic
His mental condition is a defence or mitigation that he can raise during the trial. It may help. The US legal system offers many defences and mitigations in federal criminal law.
Try to remember that he has had a couple of years to fight the extradition, which hinges on the separate decisions of several independent legal officers that there is a case to answer in U.S. Law, including at least two officers who had already concluded that the Crown Prosecution Service could not demonstrate a clear case to be answered under criminal law in the United Kingdom. Moreover, there have been at least two accountable-to-Parliament-and-their-local-electors Cabinet Ministers who have been briefed and were convinced enough that there was a case to be answered in the USA. It is unlikely that they would put their own political futures and those of their party allies on the line if the opposite was true, especially given how much information leaks out of Whitehall these days.
McKinnon has not been kidnapped, he is not the victim of extraordinary rendition, he is not going to Guantanamo, and he is not facing a trial any different than that of any other person accused and indicted by a Grand Jury in the United States. He will have a trial -- by Jury if he chooses -- and will have available the full range of defences available to any American in the same position.
He is not facing execution, he is not facing being held in Camp X-Ray like conditions, and he is unlikely to "just vanish" from the public eye in the UK or be notably "sold out" by either government this late in the electoral cycle on both sides of the Atlantic.
There are some real worries about how a less in-the-public-eye case might have unfolded. McKinnon in turn has certainly benefited from the public interest in the Natwest Three case. That there are systematic weaknesses in the current arrangement with the USA is fairly obvious now.
However, this is not being nabbed on the street in Milan and held in US custody without access to the US system of justice, as happened with Abu Omar (the Imam Rapito affair).
It is also, fortunately, not being shot seven times in the head on the Tube, a crime for which some police officers have yet to answer in court. Don't let these still senior police commanders hide behind a statute of limitations, an autrefois convict excuse following the "harsh" health and safety conviction of the police force as a whole, or a sweeping gesture towards all the other weaknesses in the British justice system.
In short, don't let the real baddies distract you by getting you to worry more about the system when it is working transparently and non-violently (like in this case) than when it uses millions of pounds of your taxes to kill someone arbitrarily and cover up and whitewash the murder.
Bear in mind that the extradition treaty is an expresson of sovereign will enabled by an Act of Parliament introduced in the democratically elected and accountable-to-the-voters House of Commons.
So, the undermining of UK sovereignty was a sovereign decision, as with any other treaty that constrains the executive or judicial system, or which delegates sovereignty to some extranational body like the European Union or Council of Europe. Unless there is a conflict with other strong expressions of sovereignty ("entrenched statute and practice", i.e, the Constitution) there is no issue of erosion.
There were arguments raised in the past (Soering v United Kingdom 11 Eur. Ct. H.R. (ser. A) (1989); Bermingham, Mulgrew & Darby * - v - Director of Serious Fraud Office and The Attorney General (HCJ Judicial Review 2004, appeals to CA and ECHR denied)) that the treaty was unconstitutional on its face; these were rejected by the Court of Appeal for the United Kingdom, and by the European Court of Human Rights. The general thrust of the rulings is that if there is prima facie a case to answer, and a valid extradition treaty and process, and the extradition is to a state generally recognized as democratic, with an independent judicial system upholding the rule of law, then there is no constitutional impediment to extradition to be found in human rights law provided that the punishments faced are broadly in line with Council of Europe standards.
That is not to say that the treaty is a good one, or that the entire electorate (or House of Commons, or Parliament) supports the one-sided nature of extraditions for crimes that rely upon some degree extraterritorial jurisdiction, the low bar on evidence (there merely has to be enough to warrant a trial), or the long long long period of waiting in partial custody in the USA for a trial date as in the case of the Natwest Three. It is also not clear that the USA is universally regarded as having a particularly fair judicial system ( cf http://freegary.org.uk/ ), but then McKinnon is not a black man facing a capital crime trial in the Texas state courts.
If you feel like helping change the minds of the electorate and some future democratically accountable government, feel free to make a donation to http://liberty-human-rights.org.uk/ or pointing your UK-resident friends at it.
Argh, typo. That should be "metric expansion of space", not "space time" or even "spacetime".
ZPM power production[*] is rated in the non-SI unit "Plot" (analogous to J/s, the second derivative of energy[**], and the first derivative of work[***]).
A ZPM's normal production appears to be approximately 0.1 Plot per episode in which it is portrayed, although in some episodes a ZPM shows how powerful a device it can be, delivering just shy of a full Plot.
The third derivative of energy, "Twist", analogous to J/s^2, can be used to analyse the output of the ZPM over the duration of an episode. In some cases the ZPM provides a substantial Twist, progressing from normal power production to zero or to explosive overload within the span of an Act.
A high-Twist, high-Plot device is consistent with the ZPM as portrayed in Stargate SG-1.
I never got into Stargate Atlantis, sorry.
[*] or production power, which may be more appropriate.
[**] Writer's energy, that is.
[***] Professionally employed TV writer, that is.
Wow, your UCR link is old :-)
First, a couple paragraphs about your parent article:
The ease with which single photons are emitted varies with wavelength. High energy photons (gamma rays) are fairly straightforward to produce using a radioisotope, spallation or annihilation emitter, a screen opaque to longer-wavelength photons, and a gate (either polarizing or deflecting). Single emissions of lower energy photons (~ 1300-1600 nanometre useful-in-fibre wavelengths, for example, and some visible wavelengths too) have recently become possible using lattices of nm scale quantum dots.
One variety of these single photon "gun"s use a two qdot arrangement where both dots are excited electrically and then one is stimulated into emission in such a way that iff the first dot emits exactly one photon of the proper frequency, the second dot will also be stimulated into an emission of exactly one photon of the desired frequency. (If the first qdot "photon emitting diode" emits multiple photons or one or more photons of the wrong energy the second qdot will not be excited into emitting anything).
The photopsin-transduction cascade is remarkably efficient given how it is driven it is by statistical chance.
In cone cells there is a gel (literally) of photopigments, various phosphorylization states of guanosine, and mechanisms which develop a charge on the neuronal side of the cone cell while phosphorylating GMP and GDP to GTP (this is paid for by the normal ATP energy processes in cells). They simply float around in the gel; there is very little ordering of cone cell cytosol compared to the majority of other cells, and what ordering there is is akin to drops of oil stirred up in water.
The photopsins are structured somewhat like radio antennas -- rhodopsin, the monochromatic pigment in rod cells especially looks like a ladder antenna. An incoming photon of a suitable energy (i.e. wavelength) striking the "antenna" part of the molecule kicks an electron into a higher orbital; this causes some local bending which is amplified through the photopsin molecule creating a conformational change, sort of analogous to causing a Venus Flytrap's maw to close by tickling its hairs, except that the conformational change cycle -- shut, open -- is brief (nanoseconds, with some reactions taking place in femtoseconds).
The "maw" is a binding site that accepts GTP. If a GTP molecule just happens to be in the binding site when it closes, the opening rips it apart producing GDP + P. Free GDP is taken up by a worker molecule in the cytosol which delivers it to the ATP->ADP+P --> GDP+P -> GTP + charge on mebrane process.
That is, what we "see" is really the phosphorylation of GDP to GTP. GDP is produced by a photon-powered GTP dephosphorylator.
Neurons are very sensitive to charges, and it is not very surprising that an amplification of one GDP->GTP charge is "perceptible". Mammal retinal neurons are (evolutionarily) extruded parts of the visual processing part of the brain, so there is a great deal of signal processing being done by brain matter local to the retinas, which reduces the bandwidth required between the eyes and the visual cortex much further back in the skull. Alot of the processing deals with the signal gain based on accumulated charges; information reduction ("lossy encoding") is greater when there is a lot of GDP->GTP activity in the visual cells (i.e., when it's bright), while amplification and (probably) some extrapolation occurs when there is less GDP->GTP activity. This is a much shorter control loop than the one which causes iris contraction, or look-away reflexes, and is what is studied when it comes to frame rates and "psychovisual compression" (and a large part of why movies with 24fps look much better in a dark cinema or room and 60Hz monitors look flickery in a brightly lit office).
What is surprising is that the reaction cross section of the photopigments in the human eye is as large as it is
128-bit linear addressing is not so useful, but you can introduce structure into the address so that (for example) the first 64 bits is a network address and the second 64 bits is the address of storage at that network address. This requires distributing the functionality of the MMU across various network elements, but is not especially novel, and from a software perspective is a special case of NUMA. (The special case lends itself to some clever scheduling based on the delay hints available in a further structured network address, especially if you generally organize things such that the XOR of two network addresses is a useful (if not perfect) delay metric from the perspective of an accessor).
This can even be done "in the small" on a non-networked host by allocating "network addresses" in the top 64 bits to local random access storage. You could look at this as a form of segmented memory (MULTICS style) or as an automatic handling of open(2)+mmap(2) based on (for example) a 64 bit encoding of a path name in the MSBs of the addresses. That is, dereferencing computer memory address 0xDEADBEEF00000001 automatically opens and mmaps a file corresponding to 0xDEADBEEF.
The opportunities to abstract away networked file systems without losing (or even while gaining) useful information about objects' characteristics (proximity, responsiveness, staleness) suggests that the address size used at the level of a primitive ISA that uses pseudo-flat addressing is mainly limited by the overhead of hauling around extra bytes per memory access. Pseudo-flat addressing can also in principle steal ideas from X86's various addressing models for dealing with addresses of different lengths.
Ultimately, the difficulty is in the directory problem. That does not go away even if you use radically different "addresses" for objects -- directories are already a pain if you use URLs/URIs for example, or if you use POSIX style filenames, or whatever, and the problem worsens when you have different "addresses" for the same logical object.
(Fun is when you have to figure out race conditions involving a structured set of bytes that is in a file shared out by AFP, SMB, NFS, and WebDAV, as well as being in use locally, with client software responsible for choosing the most appropriate available access method since there is no guarantee that any one of these methods will work for all clients at all times).
One possible approach to this is to insist that any reachable object is a persistent object, with a permanent universal name. If you have the permanent universal name, the object is either available to you or errors out. If you do not have the permanent universal name, you are out of luck unless you have a "locator" that points to it (or points to something that points to something that
[cf Church encoding, Morgensen-Scott encoding and normalization in the computer science sense]
The critical problem is accelerations versus passenger tolerance; reaching TASes in the range of 1.3-1.7e03 m/s and back again at comfortable accelerations (say, < 0.4 m/s^2) will take considerable time (an hour), even assuming a constant acceleration is feasible (it's not, without lots of work on propulsion economics). In flight "kicks" are plausible within limits (people strap in when turbulence is predicted, but swivelling chairs have posed serious interior design -- not decoration! -- problems).
Aggressive acceleration that keeps passengers seatbound throughout a 2 hour flight is unlikely to be very popular unless it's also much cheaper than a traditional transonic flight at about five hours (averaging the jetstream, which is also not really present at economic altitudes for hypersonic transport).
For passenger transport, it is the longest haul flights that are the most attractive, since the biggest gains against subsonic flight are made when the time spent in hypercruise is longest.
It is possible that specific travellers (business people? politicians? 'puter nerds?) might put up with sustained uncomfortable accelerations for marginally faster trans-USA flights, of course, but intercontinental flight seems more attractive.
Like Eurasia and the various populated islands on the "Kangaroo Run", certainly.
However, even considering strictly over-water routes, not leaving a boom carpet across the ocean is going to make for happier environmentalists (and ocean ship crews, especially if numbers of flights start climbing to those experienced on NATs/PACOTs).
Assuming that having to fly at all in the trans-sonic regime (even for short periods) does not add a ridiculous mass penalty (fuel, propulsion system), and that L/D is reasonable enough in subsonic that terminal phases aren't hugely consumptive of fuel, and that great circle routing is straightforward, hypersonic transport should be competitive with foreseeable developments in transonic, ultra-long-haul commercial air transport except in the area of fatter, fuller planes. There is considerable scope for efficiency gain in post-A380 superjumbos, with respect to kg fuel per revenue passenger mile.
(On the other hand, the vast array of "in-flight entertainment" available on steamships did not save the passenger liner industry from the discomforts of early intercontinental passenger aviation, despite the cost, discomfort (noise! yikes!), technical stops, unsurvivable catastrophic accidents, and so forth).
Materials science is one of the critical paths in aviation in all flight regimes.
Probably the biggest problem with hypersonic engineering is that replicating hypersonic flight conditions is, uh, extremely challenging.
There are lots of ideas about metal alloy foams and aerogels, many of which are increasingly cheap and easy to make, but predicting their in-flight behaviours becomes harder and more expensive with increasing Mach number.
Development costs will dwarf manufacturing costs, or it simply won't happen. If the full development costs are rolled into the final products then you would hate to know what a fleet of such jets would cost. That is unlikely to happen though, mainly since it has never happened before.
That's one of several procedural problems.
People survive for quite some time in cold hypoxic or anoxic environments, but time of useful consciousness is on the order of single-digit seconds, and time to recover useful consciousness is proportional to time and degree of exposure, but is at least on the order of several minutes. Pilots likely would have to be masked, and possibly suited, for operations at that altitude, since an emergency descent is limited by structural considerations (how quickly you can decelerate without snapping -- or melting -- flying surfaces) and can take many minutes from that altitude.
Outright onboard fatalities from exposures of several minutes during an emergency descent would be unlikely in healthy adults, and don't seem exceptionally risky in healthy walking children. However, a few minutes of near anoxia and several more minutes of hypoxia will not do anyone much good -- there will be a hell of a hangover at the very least, and a substantial risk of fatal complications of HAPE and HACE arising later.
Another important consideration is fuel loading -- at tolerable altitudes (below 4000m AMSL) the aircraft will not be able to sustain a high subsonic Mach number without huge fuel burn, and is unlikely to carry sufficient fuel for longer, slower flight. The emergency travel distance is therefore a factor. This raises another key problem: inertia.
Turning times are limited by acceleration forces ("gees") both for passenger comfort and structural integrity. The radius of a turn increases with the square of velocity for a given "gee", which implies either a much more straight-line flight pattern than is usual even under ETOPS rules, or higher accelerations in turns (felt by passengers and by structure). A reasonable ultra-long-haul hypersonic flight pattern would be nearly a great circle, which means an emergency descent over an ocean may require a water ditching simply because a suitable airstrip cannot be reached after descending below 4000m.
Accelerations are also important in the climb and descent phase in normal operations, since passengers will not enjoy long periods of noticeable (> 0.1 gee) longitudinal (front-to-back/back-to-front aircraftwise) acceleration, or even short periods of noticeable lateral accelerations, since both will keep passengers seatbound. Accelerations of greater than 1 g have serious structural implications and will preclude a variety of travellers. Accelerations of greater than 2 g are infeasible for commercial travel.
Operations research in this area uses flight simulators a lot (Laminar Research's X-Plane is a popular engine/front-end because it produces acceptable approximations of real physical conditions in almost aribtrary situations, and lets plug-ins do a better job as necessary). Simulated fast supercruise and hypercruise routinely runs into the descent planning problem -- gentle acceleration accumulates a great deal of kinetic energy which has to be gently ditched, and timing problems of merely a few seconds in hypersonic travel (M > 4.0) routinely lead to overshoots or underruns of hundreds of kilometres. These are unavoidable without compromising passenger comfort, structural integrity, or fuel budget. Reentry test vehicles generally trade away human comfort and fuel budgeting (many are almost entirely unfuelled) for structural integrity in order to hit a target area on the ground. This is not a reasonable tradeoff for commercial passenger travel. Fuel is expensive, and backtracking can be just as expensive (and much slower) as powering through a descent started too early. Passengers won't fly if it hurts, even if they are willing to put up with the discomforts of long haul subsonic travel in cramped conditions.
The biggest problem in hypersonic commercial transport is going to be that it intersects with subsonic commercial transport in the terminal phases of flight (ascent, descent, and probably ground operations) but the regulatory regime above FL
No, the 1/24 is not the expected state. It is the case that if 25 flows are in equilibrium, each will occupy 1/25 of the bottleneck bandwidth, however there are several reasons to expect that equilibrium is transient.
..." is and should be a non-goal. TCP connections are mutually competitive, and the actual goal is to avoid situations where interactive users notice slowdowns because of the behaviours of automated/unmonitored traffic. Making assumptions about that is hazardous, since there are difficulties in knowing a priori whether a given bulk flow is being monitored by an impatient human being. Thus, we want to focus on the most common states that trigger user impatience, and those are almost entirely due to RTO.
1. Slow start is disequilibriating.
2. Slow start happens when each new web-surfing TCP connection starts pumping replies back from the server.
3. Web surfing is typically bursty because of the transactional nature of HTTP (even accounting for pipelining). These bursts are themselves disequilibriating. Bulk transfers certainly happen in web surfing, however, but consider:
4. P2P bulk transfers tend to be broken into chunks of a few (9-10ish) megabytes, after which the TCP session is frequently closed. This behaviour is rarely synchronized, so serves as a further disequilibriating pressure upon the other TCPs using the bottlneck, by introducing both quiet periods and slow starts.
5. TCP bulk transfers are mutually competitive; they continually probe the bottleneck bandwidth (additive increase per lossless window) and the additional segment is disequilibriating.
Random early drop disciplines bust up equilibrium in a statistically fair way (the biggest user of a bottleneck with a random drop discipline is most likely to experience the drop), which in turn breaks up unfairly large buffer occupancy, which is the biggest source of noticeable delay for new TCP connection establishment. Whether cleverer disciplines work better is a matter for fine-tuning, but any RED configuration that permits multiple buffer occupancy statistically, up to a maximum less than the total buffer size, is always better than tail-drop (which permits total occupancy).
User-noticeable congestion is worst when initial handshake delays are high due to retransmits without a reasonable RTT estimate. The next most noticeable problem is a full round-trip timeout, even when the sRTT is well understood by the retransmitter.
An argument can be made to reduce the occurrence of triggering a full RTO by dropping first against known heavy users of a bottleneck. Whether the accounting necessary to guarantee this outweighs any stochastic approach is an open question in congestion avoidance research.
"... to keep his traffic from walking all over you
Early drop avoids RTO at the cost of fast-retransmit/fast-recovery or checkerboarding retransmissions due to implicit signals (drops), or processing early explicit congestion signalling slowdowns as if the actual drop happened.
Reducing the incidence of default-RTT-estimate RTO is probably useful, if it can be done without enormous extra processing power or state retention in routers.
Unfortunately, many network operators think of deliberate-discard implicit congestion signalling as somehow evil, despite evidence that it works better than tail-drop in the real Internet.
The problem for the two users in your scenario is that bulk transfers with differing round trip times tend to synchronize through constructive interference. This will be felt hardest by the interactive user whose traffic is inherently bursty rather than smooth bulk transfers, and short lived rather than long lived, since the transmitter will not have gathered enough information about the RTT and congestion window to adapt well to the wavelike patterns that develop during synchnronization.
Synchronized drops/synchronized recovery is bad. Full occupation of bottlenecks with useful tra
Personally, I think that the inability to go back and edit posts is one of the great strengths of /.
..." clarifications instead of a set of complex rules on what a "small tweak" is worthwhile.
Accepting a few "oops, I really meant
Preserving the flow of conversation is useful for third parties (e.g. moderators and metamoderators), and it is difficult to do this if earlier parts of the conversation can be edited.
Inserting a "not" or "un" to reverse an initial (and wrong) assertion, for example, could be unfair unless all interested parties can see the before and after... and how do you notify people in the middle of reading or otherwise participating in a conversation that earlier parts of the conversation have just been edited?
It is easier to avoid most of these types of questions altogether, and it turns out that the cost is mainly a few extra clarifying postings from time to time, and nearly-simultaneous redundant replies that persist "forever". And typo jokes. Lots of those.
Mbone has been obsolete for years. Native multicast has been done with sparse mode PIM (for joins and prunes), BGP multicast NLRI (for source information), and a (1,*) approach for several years now. The (*,*) (S,G) (source,group) approach simply did not work out in practice.
Several ISPs offer multicasting as part of leased line services. There is little magic in it, and initial setup is pretty much fully automatable after assigning group addresses. Consequently, these ISPs usually don't charge extra for native multicast.
There are three big issues with respect to native multicast for content distribution.
(1). PIM-SM+BGP-mNLRI means few (one) transmitters per multicast group. This is generally called single-source-multicast (SSM), and scales to large numbers of G in (S,G) == (1,*) state. Multiple transmitters can feed into the single source through other channels (unicast or anycast, for example), and Mbone was ultimately shut down operationally by gatewaying Mbone groups through a single source controlled by David Meyer, then of the University of Oregon, several years ago.
P2P applications are not geared for SSM, and (1,*) native multicast is probably not useful for distributing anything other than tracker or other directory information.
Although one could align a P2P system such that each chunk gets its own S,G state, the processes for assigning group addresses is not well automated globally, and worse, the process for *announcing* active sources is essentially restricted to a combination of BGP and the equivalent of bulletin board pastings (i.e., out of band pre-announcements). This is not fundamentally different from how most P2P systems work now, but introduces more complicated machinery for little (or no) obvious gain.
(2). Most point to point connections (e.g. DSL) use routing equipment which does not transmit native multicast, does not talk PIM-SM, and/or does not gateway IGMP. Sourceward joins and prunes therefore require some anycast magic, and actual traffic requires some form of unicast tunneling. There are a variety of approaches to this, but they all introduce network overhead. This is unattractive for P2P.
(3). The nature of multicast leads to an efficiency gain when large portions of a S->G tree are shared among multiple joiners. Generally this favours live broadcasts; P2P is almost always recorded content, and while multicast can repeat the content in a loop with a schedule that helps clients determine when to join or prune, actual P2P that searches swarms for missing appears to be more efficient. A hybrid approach is possible, but the potential gain does not appear large enough to justify the additional complexity and overhead of (1) and (2).
(3) (a) Missing chunks / side channels. When multicasting to a large group, a source does not want to be buried in control messages (ACKs, NAKs), so flow control is almost essentially non existent, and missing chunks are usually replayed to a set schedule as per (3). Listeners need side channels to acquire that schedule. A P2P search is more straightforward and probably more responsive, and rare chunks may distribute faster in a reasonable swarm than waiting on a loop from a relatively slow SSM originator. Asks propagated to the SSM originator are known to cause swarm slowdowns for P2P; they can become unintentional DDOSes (or exploited to create intentional DDOSes) on multicast sources in any (S,G) model.
(4). Multicast does not have a flow control mechanism. A listener joining to a group takes all that group's traffic, or none. If the traffic exceeds bandwidth availability, the listener will observe many missing packets, and there may be collateral damage due to congestion. The only reasonable response a listener has is to unjoin the group.
There are two approaches to this which scale with (1,*) state, namely many parallel groups, where each group adds extra detail, and listenerward caching. The former runs into administrative issues (group add
Without nitpicking about the legal entities involved (the EC is more legislatively important right now), the overall EU project's legislative and regulatory competence has been constrained by the principle of subsidiarity, which was formalized in the Maastricht Treaty, and is presently found in the current version of the European Community Treaty in Aritcle 5, with detailed rules in Protocol 30.
Included in the wording is the condition that the EC may legislate and regulate "only if and in so far as the objectives of the proposed action cannot be sufficiently achieved by the Member States ".
The proposed Constitution constrains both the European Union (as it then will be) and the Member States with respect to acting only when it is manifestly inefficient or ineffective to do so at a regional or local level.
Note that the ECJ has ruled fairly consistently against overreaches that are not in keeping with the principle of subsidiarity, which is one reason why a frequent course of events is for the Commission to propose to the Member States that they individually pass legislation consistent with something agreed to in Brussels by the Commission and the Member States (by consensus), rather than using the formal Pillar system. Apart from the obvious practice of avoiding the scrutiny and occasional interference by the European Parliament (which is surprisingly good at detailed study of proposed legislation), it is also a recognition that the ECJ might insist that the Member States individually pass the appropriate legislation anyway.
Unfortunately this looks somewhat undemocratic, since the consensus building in Brussels is not transparent, and since the Member States who helped form the consensus "complain" to their domestic audience that unpopular legislation that they helped formulate is being imposed "by Brussels". Also, Member States's governments of the day actively discourage one another from resiling from such consensus agreements when they turn out to be unpopular, which misses the whole point of bringing the agreed policies to the national parliaments in the first place.
One of the side effects of TECE, including the current Lisbon Agreement version, is that the consensus building process will be made more transparent, especially to the European Parliament, which will also be able to insist on its own review of "backdoor" Union-wide initiatives. Substantial delaying and derailing power is therefore being put into the hands of the directly-elected MEPs, which is part of the ongoing evolution of the Union as a union of the people living in it, rather than a union only of the governments of the day of the various Member States.
There should be a written recognition that the power of all parts of the European Union originates in individual citizens of the Union. Period.
Subsidiarity is a step in that direction. The new Article 8 proposed in Lisbon addresses subsidiarity and proportionality directly, with grudging compromises among the factions who see the union membership of that of the Member States and those who see it as being a body for the people in Europe.
You might want to take a look in particular at the proposed new clauses 8(a)(1-3) and 8(b)(4).
The reality is that right now there are already enormous differences in power between employers and obligate employees -- people who must work for a living, and whose skills (whatever they may be) are not readily sold to another employer locally. This power is used now to force asymmetrical disclosures -- everything from details of the employee's personal life to directly observed urinating into sample jars.
Even if one rejects the idea that fairness is a useful -- or even possible -- goal, mandating symmetrical or at least mutual disclosures almost certainly would limit the amount and invasiveness of personal disclosures the more powerful require from the less powerful in the general case.
In exceptional cases there will be powerful people -- including those who are financially independent -- who would willingly disclose every aspect of their personal lives. This will include many celebrities, especially "celebutant[e]s", as well as those who believe that they live exemplarily moral lives.
In the more general case, even financially independent people fear exposure, social disapproval and accusations of hypocrisy over at least some things, mainly because humans are rarely completely socially independent, non-judgemental or unconcerned with their public image.
If voters demand that their politicians live in a goldfish bowl before they support monitoring members of the electorate, there are lots of politicians who probably would be more keen on constraining surveillance, since there is an abundance of them hiding embarassing personal secrets from the public.
On the other hand, if this discourages people with secrets from holding elected offices, they might end up with porn stars and self-destructive musicians as legislators! Or bloggers...
A lot of this depends on how franchise holders (electors or shareholders) organize and use their votes. There is occasional political pressure to introduce things like a Freedom of Information Act or entrenched legal protections for professional investigative journalists and amateur whistleblowers. Occasionally corporate shareholders will require greater openness by executive remuneration committees or individuals hoping to sit on the board of directors.
That these activities do not end a power-imbalance is not surprising, and is not even the point. The issue is preventing abuses by the already powerful against the already less powerful, especially when those abuses increase the existing power-imbalance.
If preventing further exploitation is the point, then the judgement that symmetrical disclosures "fail utterly" appears to be contradicted by the evolution of open government and corporate transparency over the past fifty years in (most) OECD countries (most of the time).
If mutually assured disclosures also "fail utterly" to limit exploitation, then why do governments and senior corporte executives work so hard to keep secrets from voters and shareholders, to the point of redaction, document-destruction, unminuted decision-taking meetings, frequent assertions of privileged confidentiality, and so forth?
The DNS is a generalized database; since at least Project Athena's Hesiod (1983), and in IETF standards since at least RFC 1464 (1993), storing management and user information in the DNS has been commonplace. Why? Because it's useful to have a distributed hierarchical database with a light weight and rapid query/response, good failure resilience, decent caching, and a host (pardon the pun) of other features. It's especially useful when the keys are aligned with the hierarchy of DNS names anyway.
Some of this information is private for a variety of reasons, and servers are often configured to give it only to particular ranges of addresses.
Encrypting the sensitive RRs with a pre-shared key would be feasible (give or take the difficulties in the "pre-" part, which are probably soluble with DHCP), but that eliminates the light weight and rapid query/response because encrypted information tends to require large responses, leading to partial-loss/full-retransmissions risks, or [T]TCP, both of which increase the total amount of data, state, and time-to-acquire-answer.
However sometimes the domain name parts themselves are sensitive, and that conflicts badly with DNSSEC as it exists now because of NSEC following. NSEC3 is now at best experimental and subject to substantial change, in spite of the wording in the I-Ds. Split domains are hard, DNSSEC makes it harder.
Dynamic DNS updates and DNSSEC don't interoperate well at all, and Secure Dynamic Update and NSEC3 still have some open interoperability problems. This is a bear in a world where one acquires new A or especially AAAA RRs by arriving on a LIS supporting DHCP or prefix autoconfiguration (for example) but want to maintain a consistent global hostname.
No, it's an indication of authenticity of the origin of the DNS information one gets from some random cache, including negative caching information (NXDOMAINs), and it also provides additional data integrity as a side-effect.
Making authentic information cacheable is a useful goal for scalability reasons.
However, DNSSEC does this in a way which precludes a number of other practical uses of the DNS, for which the answer "don't use the DNS for private data, replicate the DNS hierarchy in another separate directory system!" is not currently realistic.
Moreover, the scalability win of caching data which are authentic for the duration of the ttl is clawed back by the increase in TCP-based transfers caused by zone enumeration (or the extra caching of large amounts of probably extraneous data to try to mitigate that for the originating server).
Authentic DNS information is useful in determining the binding between sets of entries in the DNS (typically that the fully qualified DNS name has an A or AAAA RR and that the corresponding IN-ADDR.ARPA. or IP6.ARPA. DNS names point back to the FQDN). This does not tell you whether the IP/IPv6 routing system will take your packets to the target you want -- routing attacks, interception attacks, and subverted hosts are not detected by DNSSEC.
Where DNSSEC helps (a little) is in the promulgation of PKI public keys that can detect these attacks, either at the application/service level (as with TLS) or at the network level (IPSEC). However, DNSSEC is not necessary for distributing PKI keys tied to the DNS hierarchy (one can still verify public keys out of band), and TLS is unlikely to be replaced by cleartext application conversations protected by opportunistic IPSEC ESP.
Sadly, my take on DNSSEC is that what it does is so readily misunderstood, even by people who are familiar with the DNS, that the standards are going to remain fluid for a while, and deployment will happen only by early adopters who have the time to adapt to the possible changes.
In criminal law, in Canada, there is a real legal difference between a jury's refusal to convict an accused person at a criminal trial, and the U.S. concept of jury nullification. This is primarily due to substantial differences in case law which developed in the mid-to-late1800s in both legal systems which entrenched a right to make legal arguments to a jury, or to a judge in the presence of a jury which could form its own impressions of the arguments in the rendering of a verdict under certain circumstances (United States vs Fenwick 1836, Stettinius vs United States 1839 contra Games vs Stiles 1840, Sparf vs United States 1895). In the mid to late 20th century several cases in the USA upheld the jury's power to refuse to convict based on points of law, but hedged by restricting officers of the court from informing jurors of the power with the argument that it gives licence to jurors to disregard the law entirely in favour of deciding any individual case based on personal prejudices and feelings about the parties involved.
In Canada, juries have long been able to make strong (but not always binding) suggestions with respect to sentencing, if they choose to convict -- almost always this involves urging a lighter sentence upon the trial judge, often a conditional discharge. This is unusual in systems which inherited the English criminal justice tradition, but has had the effect of reducing even further the liklihood of a refusal to convict at all. As a result, there are only a handful of Supreme Court cases which have dealt with the issue directly.
R. v. Morgenthaler, [1988] 1 S.C.R. 30 is the culmination of appeals by the Crown against successive juries' refusal to convict Dr Morgenthaler in spite of what they believed was a clear cut case and clear instructions from the Judges. The decision confirms the right and moral duty of juries to refuse to convict when their consciences tell them otherwise; in their commentaries on the case history Dickson CJ, Lamer and Wilson JJ all made reference to the section 2(a) of the Canadian Charter of Rights and Freedoms (freedom of conscience) with respect to the actions of jurors, making it fairly clear that a jury's refusal to convict in the end was not sufficient reason to invalidate the outcome of a trial.
However, from the ruling:
Subsequent cases have followed this line: juries can refuse to convict, and that refusal is on its face insufficient grounds for appeal [R. v. Krieger, 2006 SCC 47, [2006] 2 S.C.R. 501], but at the same time judges are entitled to vigorously and forcefully instruct juries not to do so [R. v. Latimer, 2001 SCC 1, [2001] 1 S.C.R. 3]: "The trial judge did not prejudice the accused's rights in replying to the question from the jury on whether it could offer input on sentencing. The trial did not become unfair simply because the trial judge undermined the jury's de facto power to nullify ... Guarding against jury nullification is a desirable and legitimate exercise for a trial judge; in fact a judge is required to take steps to ensure that the jury will apply the law properly."
As the powers -- and even the existence -- of a jury were claimed in the face of proper tyrants looking to jail or execute people for personal an
Redundancy isn't the problem. Mirroring writes of something that overwrites good data with bad data is a poor strategy.
Recovery is the problem. When you accidentally delete a file, save bad data on top of an existing file, or a bug or hardware crash strikes and messes important data up, you want to be able to undo that easily.
That is, while your data-scatter idea is fine, the data-gather part needs to work when the user decides the existing version of data is bad, and that a previous version might be good.
Maybe if I added parentheses and changed a conjunction, my initial meaning would have been clearer:
...
In France (or Germany), for example, the President (or Chancellor in Germany)
In other words, there is no disagreement here.
However:
There are only three Prime Ministers in recent history. Four if you go back 17 years to Thatcher.
Tony Blair ceased being the leader of the Labour Party on 24 June 2007 and ceased being the Prime Minister on 27 June 2007.
That's not a very long period of time, and neither was Margaret Thatcher's single day (27-28 November 1990), but it underscores an important Constitutional point: a Prime Minister always has the right to face Parliament to attempt to secure the confidence of the House of Commons in his or her own right.
A Motion of Confidence introduced by the government (i.e., by the Prime Minister, the Leader of the Government in the House of Commons, or another senior Cabinet Minister) also takes precedence over all other business of the House of Commons excluding those calling upon the Speaker to see Strangers. They are rare -- the last one voted in Westminster was in 1945, and the most recent one tabled was in 1993 -- and are essentially threats, such that if the Nays prevail, the House immediately adjourns in anticipation of dissolution. However, they are a significant tool of the Prime Minister in that if he can demonstrate command of the House of Commons despite the opposition of M.P.s in his own party, there is no constitutional mechanism by which they can force him to resign.
No, the Prime Minister continues to serve at his or her own whim, until he dies, names a replacement, or loses the confidence of the House of Commons twice -- the first triggering a general election, and the second during the exercise of his right to face Parliament and secure the confidence of the House of Commons.
It is a strong tradition that Prime Ministers rapidly "recommend" a successor to the monarch after losing a general election, but the Constitutional convention is that the PM is not obliged to do so, since she may be able to assemble a majority of MPs from different parties willing to vote in her favour on matters of confidence.
Thatcher could not assemble such a majority, and had no prospect of being able to do so after a general election, so she resigned about as gracefully as she could manage. Legally, however, she could have dissolved the House of Commons, fought a general election campaign, seek the confidence of the newly elected and re-elected M.P.s, fail to do so, and dissolve the House of Commons yet again, in order to seek the confidence of the newly newly elected and re-elected M.P.s probably to find that there would be none left. At that point, not naming a successor who would likely command the House of Commons would provoke a serious Constitutional crisis involving the monarch acting on her own or with the advice of someone other than the Prime Minister. Those two things are never done.
In fact, the Constitution of Ireland codifies this explicitly to make it clear that the President has absolute and exclusive say over a Prime Minister's fate if the latter seeks a dissolution immediately after an election triggered by a loss of confidence. Canada has been pursuing a similar statutory codification, although it may require an outright constitutional amendment there.
By way of contrast, Tony Blair's awkward relation