In the last 90s I worked for a large American test equipment manufacturer. We had developed an embedded system for performing parametric testing of telephone lines when not in use (and the test would be rescheduled if the line became required).
It was great for detecting cables about to fail, that had failed, and could pinpoint where (by TDR) they likely had failed.
It worked like a charm, except for one little nuisance: downloading new firmware to the thousands of remote units usually failed. It took a while to track down, since we could not repro it in house. The control network was TCP/IP over PPP over PVCs set up over 9600 bps serial links multiplexed over X.25.
Turned out that small command and control requests did not send the large packets that software download did, and the combination of large packet size, consequently long ACK time (over the 9600 bps link), poor RTT convergence in the host TCP/IP stack, and incorrect handling of duplicated packets in the embedded TCP/IP stack was our undoing.
I engineered a small piece of code that would modify the embedded TCP/IP stack to get around the defect well enough so that it could be download, and in turn, allow for the download of a properly corrected full version.
From what I see, GreenPlug IS USB, but with a data protocol designed so that the powered device can negotiate it's charging requirements, and report it's charge status.
That would actually be rather cool.
Such a protocol, or extension thereof, would also allow AC powered appliances to report their consumption over a power-line LAN, or indeed, any physical power delivery interface on which a data stream can be piggy-backed.
I once had problems with kids trespassing, and more importantly, vandalizing my property and attacking my kids (with bb guns, of all things). Complaints to parents ("What? My little angel?? How dare you!") and police ("Sir, you have no evidence, and they deny the charge") were fruitless, so I set up surveillance cameras on my own property.
I caught kids sitting on my fence, hurling animal feces on my deck.
Shortly after I presented the evidence to their parents, police pulled me over and demanded the "pornographic tapes" I made of their children.
Realize that "child pornography" is so broad a charge, that it has been levied against people taking pictures of fully clothed children in public, doing what kids in public tend to do, namely horse around, have fun, and occasionally behave.
The childrens' parents, in my case, made the charge that I paid them to hurl feces onto my property, and taped it for my sick, depraved, pleasure later, calling it "pornography".
I told the cop, "You have no cause to detain me officer, I am leaving. Pursue at your own legal risk." The camera in my car was running and recorded the whole absurd accusation.
He didn't. (If I had to defend against a charge of producing "child pornography", I figured (at the time, somewhat paniced) a somewhat sensational car chase without cause would have helped, rather than hurt, my odds.)
This is comparable to a mini pc tucked under the TV with a wireless keyboard and/or a harmony control. The battery life and software UI on the touchpad will be critical to the success of this product.
My thoughts exactly.
Though I do like the idea of separating the control UI display from the media display. Somehow, "on screen" just looks clunky to me in a media room. With the control having an independent display, and being an independent computer in it's own right (I've often thought of using a laptop, but that's a bit too big, and currently lean toward a WiFi cell-phone with browser for this purpose), it makes for a great remote.
Not sure about UWB HDMI though: a control does not need much horsepower (though more is always betterer:-)), nore should it have to have the capability to stream HD to a remote display. Sounds like a waste of battery to me. I guess there are times when it is handy.
From Wikipedia: "A space elevator cannot be an elevator in the typical sense (with moving cables) due to the need for the cable to be significantly wider at the center than the tips."
Use the centripital force to hold them taught, arange them in a loop, and LIFT stuff up with a gear mechanism at the top or bottom. Heck, make it a REAL elevator, with a counterweight on the other side.
You only have a duty to not be negligent (make your security code public knowledge) and exercise "reasonable" diligence (not give your security code to people you don't trust (say your wife/husband or significant other).
Don't you love it when people get really clever at following the words of a law for the purpose of evading the spirit of a law?
I think it's more subtle than that.
While one can equate a rent/own arrangement to a mortgage in financial terms, and arrive at an equivalent payment stream, when one considers the ownership differences between the two arrangements, there are major differences.
Using the "infidel" concept of interest, the purchaser owns the property and is ultimately responsible for property taxes, upkeep of grounds, and generally ensuring the property does not become a danger or menace to neighbors, in the rent/own arrangement: both the "seller" and "purchaser" retain an ownership interest, and therefore responsiblilty until the property is fully paid for.
One could argue that the "seller" does not use any utilities (if these are covered by property taxes as they are some places), but s/he certainly is partly responsible for their share of roads, etc., adjoining the property and their upkeep. Further, s/he is partly responsible for ensuring the property does not present a hazard, nuisance, or eyesore. While this responsibility can be contractually transferred to the "purchaser", someone has to be held accountable if the "purchaser" defaults in this matter. Ultimately, the city could excercise eminent domain, but generally the "seller" will likely have to guarantee the "purchaser's" performance in this regard.
Of course, it is in both parties interest to maintain the value of the property, but their respective interests change over time (similarly, a high-ratio mortgage becomes less of a risk to the lender over time, and this is reflected in the freedom to eventually drop morgtage insurange (PMI in the U.S. In Canada, the cost of such insurance is paid as a lump sum of the purchase price, and added to the loan, so is paid until the property is sold).
Where the real difference comes in is in the case of foreclosure.
In an "infidel" foreclosure, the lender gets first dibs at any monies obtained to satisfy the loan, after expenses, and the owner gets what's left over (though tax liens have precedence even over first position lenders).
In this foreclosure, both "seller", and "purchaser" have an interest in the property, and therefore, proceeds of sale would be split between them. This is not the same as an "infidel" arrangement, where the owner assumes all risk (and reward) of fluctuating property values, and the lender assumes the risk of the property value falling below the selling price (against which the lender can insure at the owner's expense).
Furthermore, the "seller" could sell an interest in his/her remaining part of the property in exchange for the income stream from the "purchaser". Of course, who would want to buy a property where the existing occupant is in arrears in payments? I suppose someone (family member?) might. But, more likely might be a contractual arrangement requiring the "purchaser" to either sell their share if they become in arrears in rent, or a "reverse purchase" arrangement whereby the "purchaser" compensates the "seller" by giving back some of their ownership share.
The striking thing, though, is that if the property is, indeed sold, in the equivalent to a foreclosure, the "purchaser" will get something back, even if the property has depreciated significantly. For example, if a $200k home was purchased with the "purchaser" taking a 20% inital share, and the "seller" retaining an 80% share (so purchaser: $40k interest, seller: $160k interest), and the property value drops by 1/4 to $150k, the "purchaser's" interest is $30k, and the "sellers" is $120k. With an "infidel" arrangement, the owner's share would be -$10k, and the lender's interest remain at $160k.
This makes the financial interests of "purchaser" and "seller" much more closely related than in an "infidel" arrangement, and far less likely for their interests to be conflicted. For example, many people in the U.S. might be
Yes, but if someone impersonates you, and steals the car from the dealer, you should not be liable.
This is why credit card companies have fraud departments, and will generally reimburse you (and file a correction with the credit bureaus if necessary), if you did not recieve the product or service purchased with the credit card: you just have to sign a statement that you did not, in fact receive it. (And, if you lie, you are liable to be charged with civil and criminal fraud).
This also protects you if you legitimately purchase something, and do not receive it -- then the merchant has stolen from you.
The credit card companies handle this via "chargebacks" to the merchant, and it is the merchant's responsibility to make sure (a) the credit card company will honor the charge and (b) confirm the identity of the purchaser.
Banks that issue loans have the same problem if your identity is stolen. And they too, will forgive the loan, if you can convince them that you did not borrow the funds (though this can be a bit difficult, and usually requires at least a report to the police -- false reporting being a serious offense). Just had a friend go through this -- a former employer used her SSN to open a loan in her name, but with a different address. All was cleared up as far as my friend was concerned. The banks have fraud departments to deal with this. It's a hassle, but fixable.
Now, you do have an obligation to exercise dilligence in protecting your identity and account numbers, but that's about it.
The conveience simple identifiers offer combined with the volume of "easy business" they permit make it make more sense to absorb the costs of some frauds.
Now, LARGE transactions generally elicit more scrutiny from the parties possibly on the hook, whether merchant, credit card company, or bank. Ever buy a house with some of the funds lent to you by a mortgage company? Lots to verify there.
As far as the phone company here is concerned, this is (a) Canada, where consumers seem to have far less protections (and contingency suits, IIRC, for egregious civil offences are not possible), but (b) privacy of indentifying information to initiate a business relationship is better protected than in the U.S. (which does makes some kinds of transactions impossible without a face to face meeting, rather than insuring against online fraud).
The problem is that there appears to be little protection against the fraudulent hijacking of an existing business relationship.
Usually, in businesses with peering arrangements, fraud in either direction is about equal, so the cross-charges cancel out. But, if that is not the case, usually the peering arrangement is severed. IOW, the phone company should NOT pay the international counterpart, and not charge the defrauded customer. If the Belarus telephone company does not like this, they have the option of not peering.
What complicates the issue here, though, is that the customer, using their own equipment, might quite well have been negligent in securing it.
IIRC, Islam also forbids the lending of money at interest.
Whereas we in the U.S. are used to a lender taking a security interest in property purchased with the help of a loan, people who subscribe to faiths where lending at interest is forbidden solve the problem by the lender taking a depreciating ownership interest in the property, sharing proportionately in it's change in value (up or down), while the loan is being paid off. The purchaser's monthly payment goes partially toward purchasing more of the property and partially toward renting the part s/he does not own. Rather clever actually.
Yes, but package meta-data (what package managers use to resolve dependencies automagically), is NOT standardized.
Basically, you need a way of naming packages, an inheritance hierarchy describing which packages are extentions of others, virtual packages (so that if you need "foo" functionality, any package that implements "foo" functionality can be used), verification that packages implement the functionality of their virtual bases ("myFoo" works but "yourFOO" is buggy), a means of describing the specific installation details of a package (so that if bar needs libFoo, it knows where to look -- pkgtool does some of this), etc.
There are bits and pieces that solve some of the issues, but not all.
One of the nastyiest hurdles are config files that other packages want to edit: even had a package that needed to change some networking configuration? Is it in/etc/network/interfaces or/etc/sysconfig/network/eth? (or whatever, I'm sure I flubbed the paths somewhere). Ideally the networking "package" should define it's config file format for other packages to munge (or go the route of.d directories where orthogonal configs are separate files). The idea is if you know that use use "networkFoo" you know "networkFoo's" config file format.
But what if there's a competing network config standard for "networkBar", and you have networkBar not networkFoo installed? Shouldn't the "better" packages that depend on network packages be smart enough to deal with both (at least until the dust settles on which is better)?
You can either try to "force" a standard, and deal with issues in the package management system, or figure out the kind of metadata about a package that you need to maintain, and let the package managers arise to the challenge of using it.
Forcing a standard works only if it has already proven itself as a defacto standard that meets 95%+ of use case needs. Look at pkgtool, automake, and autoconf. Kinda ugly, but they do a fairly good job at what they do (and why.tar.gz generally works so well). Trouble is, they don't do everything, nor do they permit deferal of some decisions after compilation time (where, admitedly, there is less freedom). But, if an OS ise defined by "this" particular set of autoconf-aware parameters, presumably those things that depend on them (and only them) can be precompiled in a package for that OS, with the rest compiled at install time.
9.41. PROTECTION OF ONE'S OWN PROPERTY. (a) A person in lawful possession of land or tangible, movable property is justified in using force against another when and to the degree the actor reasonably believes the force is immediately necessary to prevent or terminate the other's trespass on the land or unlawful interference with the property.
(b) A person unlawfully dispossessed of land or tangible, movable property by another is justified in using force against the other when and to the degree the actor reasonably believes the force is immediately necessary to reenter the land or recover the property if the actor uses the force immediately or in fresh pursuit after the dispossession and:
(1) the actor reasonably believes the other had no claim of right when he dispossessed the actor; or
(2) the other accomplished the dispossession by using force, threat, or fraud against the actor.
9.42. DEADLY FORCE TO PROTECT PROPERTY. A person is justified in using deadly force against another to protect land or tangible, movable property:
(1) if he would be justified in using force against the other under Section 9.41; and
(2) when and to the degree he reasonably believes the deadly force is immediately necessary:
(A) to prevent the other's imminent commission of arson, burglary, robbery, aggravated robbery, theft during the nighttime, or criminal mischief during the nighttime; or
(B) to prevent the other who is fleeing immediately after committing burglary, robbery, aggravated robbery, or theft during the nighttime from escaping with the property; and
(3) he reasonably believes that:
(A) the land or property cannot be protected or recovered by any other means; or
(B) the use of force other than deadly force to protect or recover the land or property would expose the actor or another to a substantial risk of death or serious bodily injury.
Since the teacher can bring arbitrary force to bear against the student via a summons for help, demanding the return of his property at gunpoint seems approrpiate as does killing her if she tries to flee.
No. The student shouldn't threaten to kill the teacher. The student should just plain hunt her down, kill her, and reclaim his stolen property.
Unless there is some exception for teachers on school property, or the laws have changed, in Texas it is legal to use deadly force to secure the return of property that was stolen from you.
If charged with murder, an adequate defense is (a) this is my property, (b) she stole it. Case closed.
You might find that barbaric -- I happen to agree with it, but, unless the law has changed there, or there is some exception for schools or teachers, it's perfectly legal.
Of course, I'd consult VERY CAREFULLY with a lawyer before taking such a course of action, but this idiot who's corrupting the minds of children deserves no less.
Indeed. One could argue that bondage might be arousing, in that it gives rise to thoughts of power over the poweless, but that arises in sexual role-playing, and not bona-fide entrapement (for most people).
Here, we clearly have a child, appearing unhappy, vulnerable, and helpless.
If the intent is to depict the inevitability of the ravage of time upon youth and innosence, I'd say, "damn good job!"
I can't see how any normal, or near-normal, person could find the image sexually arousing.
I also don't buy the argument that it "fuels" desire for children: it might be a trigger for a pederast, but the pederast is one whether the trigger is present or not.
"MINUTE entry before Judge Harry D. Leinenweber : It has come to the Court's attention that the docketing department of the Clerk's Office is still inputing the names of the hundreds of defendants named in this action. This action was dismissed on 8/17/07 for failure to state a claim, and the Court of Appeals dismissed the appeal on 10/31/07 for failure to pay the required docketing fee. It is a waste of judicial resources for the Clerk's Office to continue adding these names to a closed case that the Court determined was delusional in its order of 8/17/07. The Clerk is therefore directed to cease adding the defendants' names to this docket. As this is an internal housekeeping matter, the Clerk is directed not to send notice of this order to Plaintiff. No notice to be mailed (gcy, )"
Well, M$ uses their single authentication point to also store metadata that is likely to be needed by many of their apps that look to that authentication point. OpenID would not have that metadata. (Though M$ could detect this, and create an OpenID->LiveID mapping and required the user to enter it the first time. Of course, it is in M$'s interest for the mappings to go the other way.)
The kind of metadata has to do with stuff like age, location, etc.
The thing is, not only can one single point authentication useful for a number of services, one can also envision shared metadata following some schemas useful for a (likely smaller) number of services. A central mapping of Id to location, and another one to age, and another one to medical information (horrors!), that can be used by any service that needs some or all of these: when you register with a particular service, you provide your single-point ID, and the service asks you where the metadata for all the types it needs is stored, it it isn't already associated with the ID. If you never provided it, it is obtained, stored somewhere, given a tag of it's own, and bound to your single-point ID (and vice versa), and both databases updated.
So, if some site needs, say, a Resume, for which an XML Schema is defined, it can ask you, "Your ID does not map to an XMLResume, would you like to provide the mapping or create one?", then redirect you to a resume provider, which creates a ResumeID, binds it with your single-point authentication ID, and lets you include that binding with the single point authenticator for "next time".
Of course, just who can access what data should remain under your control, but I can envision a permission system based on PKI.
Depends on what you use the logins for. I use common logins, or at least passwords, across several sites, particularly ones I don't care too much about, and different ones for sensitive sites like banks, etc.
So, yes, the number of logins you have should be more than one, but does not have to be as large as the number of sites you visit.
But, to explain how OpenID, LiveID, and all such systems work without the site requesting the authentication requiring the authenticating credentials, it's like this:
1) You authenticate with the authentication site. You get back a magic number, or some similar credential.
2) You present this credential to the site that requests your authentication.
3) It contacts the authentcation site with it, (perhaps authenticating itself too using means like a client cert), provides the credentials you supplied, and gets back all sorts of nifty metadata about you.
Your credentials expire after some amount of time.
LiveID works like this for all Microsoft and Microsoft-partnered sites. And the same for OpenID.
The issue with having Microsoft accepting OpenIDs (besides the obvious econo-political one) is likely the nature of the metadata being different between what OpenID provides and what LiveID provides (unless OpenID supports the notion of arbitrary metadata per site requesting authentication, and so could support the LiveID metadata format).
Slashdot Mirror
In the last 90s I worked for a large American test equipment manufacturer. We had developed an embedded system for performing parametric testing of telephone lines when not in use (and the test would be rescheduled if the line became required).
It was great for detecting cables about to fail, that had failed, and could pinpoint where (by TDR) they likely had failed.
It worked like a charm, except for one little nuisance: downloading new firmware to the thousands of remote units usually failed. It took a while to track down, since we could not repro it in house. The control network was TCP/IP over PPP over PVCs set up over 9600 bps serial links multiplexed over X.25.
Turned out that small command and control requests did not send the large packets that software download did, and the combination of large packet size, consequently long ACK time (over the 9600 bps link), poor RTT convergence in the host TCP/IP stack, and incorrect handling of duplicated packets in the embedded TCP/IP stack was our undoing.
I engineered a small piece of code that would modify the embedded TCP/IP stack to get around the defect well enough so that it could be download, and in turn, allow for the download of a properly corrected full version.
That would actually be rather cool.
Such a protocol, or extension thereof, would also allow AC powered appliances to report their consumption over a power-line LAN, or indeed, any physical power delivery interface on which a data stream can be piggy-backed.
I caught kids sitting on my fence, hurling animal feces on my deck.
Shortly after I presented the evidence to their parents, police pulled me over and demanded the "pornographic tapes" I made of their children.
Realize that "child pornography" is so broad a charge, that it has been levied against people taking pictures of fully clothed children in public, doing what kids in public tend to do, namely horse around, have fun, and occasionally behave.
The childrens' parents, in my case, made the charge that I paid them to hurl feces onto my property, and taped it for my sick, depraved, pleasure later, calling it "pornography".
I told the cop, "You have no cause to detain me officer, I am leaving. Pursue at your own legal risk." The camera in my car was running and recorded the whole absurd accusation.
He didn't. (If I had to defend against a charge of producing "child pornography", I figured (at the time, somewhat paniced) a somewhat sensational car chase without cause would have helped, rather than hurt, my odds.)
Have you tried with the OpenChrome, and not VIA, drivers?
My thoughts exactly.
Though I do like the idea of separating the control UI display from the media display. Somehow, "on screen" just looks clunky to me in a media room. With the control having an independent display, and being an independent computer in it's own right (I've often thought of using a laptop, but that's a bit too big, and currently lean toward a WiFi cell-phone with browser for this purpose), it makes for a great remote.
Not sure about UWB HDMI though: a control does not need much horsepower (though more is always betterer :-)), nore should it have to have the capability to stream HD to a remote display. Sounds like a waste of battery to me. I guess there are times when it is handy.
... and a great "Whoosh!" was heard above all the non-Gibson fans.
From Wikipedia: "A space elevator cannot be an elevator in the typical sense (with moving cables) due to the need for the cable to be significantly wider at the center than the tips."
I'm not sure whether to exclaim "Duh!" or "Shit".
Use the centripital force to hold them taught, arange them in a loop, and LIFT stuff up with a gear mechanism at the top or bottom. Heck, make it a REAL elevator, with a counterweight on the other side.
When I applied for (and subsequently received, in 2006) my green card, a photo and fingerprints were taken.
Only if you contractually agree to this.
You only have a duty to not be negligent (make your security code public knowledge) and exercise "reasonable" diligence (not give your security code to people you don't trust (say your wife/husband or significant other).
I think it's more subtle than that.
While one can equate a rent/own arrangement to a mortgage in financial terms, and arrive at an equivalent payment stream, when one considers the ownership differences between the two arrangements, there are major differences.
Using the "infidel" concept of interest, the purchaser owns the property and is ultimately responsible for property taxes, upkeep of grounds, and generally ensuring the property does not become a danger or menace to neighbors, in the rent/own arrangement: both the "seller" and "purchaser" retain an ownership interest, and therefore responsiblilty until the property is fully paid for.
One could argue that the "seller" does not use any utilities (if these are covered by property taxes as they are some places), but s/he certainly is partly responsible for their share of roads, etc., adjoining the property and their upkeep. Further, s/he is partly responsible for ensuring the property does not present a hazard, nuisance, or eyesore. While this responsibility can be contractually transferred to the "purchaser", someone has to be held accountable if the "purchaser" defaults in this matter. Ultimately, the city could excercise eminent domain, but generally the "seller" will likely have to guarantee the "purchaser's" performance in this regard.
Of course, it is in both parties interest to maintain the value of the property, but their respective interests change over time (similarly, a high-ratio mortgage becomes less of a risk to the lender over time, and this is reflected in the freedom to eventually drop morgtage insurange (PMI in the U.S. In Canada, the cost of such insurance is paid as a lump sum of the purchase price, and added to the loan, so is paid until the property is sold).
Where the real difference comes in is in the case of foreclosure.
In an "infidel" foreclosure, the lender gets first dibs at any monies obtained to satisfy the loan, after expenses, and the owner gets what's left over (though tax liens have precedence even over first position lenders).
In this foreclosure, both "seller", and "purchaser" have an interest in the property, and therefore, proceeds of sale would be split between them. This is not the same as an "infidel" arrangement, where the owner assumes all risk (and reward) of fluctuating property values, and the lender assumes the risk of the property value falling below the selling price (against which the lender can insure at the owner's expense).
Furthermore, the "seller" could sell an interest in his/her remaining part of the property in exchange for the income stream from the "purchaser". Of course, who would want to buy a property where the existing occupant is in arrears in payments? I suppose someone (family member?) might. But, more likely might be a contractual arrangement requiring the "purchaser" to either sell their share if they become in arrears in rent, or a "reverse purchase" arrangement whereby the "purchaser" compensates the "seller" by giving back some of their ownership share.
The striking thing, though, is that if the property is, indeed sold, in the equivalent to a foreclosure, the "purchaser" will get something back, even if the property has depreciated significantly. For example, if a $200k home was purchased with the "purchaser" taking a 20% inital share, and the "seller" retaining an 80% share (so purchaser: $40k interest, seller: $160k interest), and the property value drops by 1/4 to $150k, the "purchaser's" interest is $30k, and the "sellers" is $120k. With an "infidel" arrangement, the owner's share would be -$10k, and the lender's interest remain at $160k.
This makes the financial interests of "purchaser" and "seller" much more closely related than in an "infidel" arrangement, and far less likely for their interests to be conflicted. For example, many people in the U.S. might be
This is why credit card companies have fraud departments, and will generally reimburse you (and file a correction with the credit bureaus if necessary), if you did not recieve the product or service purchased with the credit card: you just have to sign a statement that you did not, in fact receive it. (And, if you lie, you are liable to be charged with civil and criminal fraud).
This also protects you if you legitimately purchase something, and do not receive it -- then the merchant has stolen from you.
The credit card companies handle this via "chargebacks" to the merchant, and it is the merchant's responsibility to make sure (a) the credit card company will honor the charge and (b) confirm the identity of the purchaser.
Banks that issue loans have the same problem if your identity is stolen. And they too, will forgive the loan, if you can convince them that you did not borrow the funds (though this can be a bit difficult, and usually requires at least a report to the police -- false reporting being a serious offense). Just had a friend go through this -- a former employer used her SSN to open a loan in her name, but with a different address. All was cleared up as far as my friend was concerned. The banks have fraud departments to deal with this. It's a hassle, but fixable.
Now, you do have an obligation to exercise dilligence in protecting your identity and account numbers, but that's about it.
The conveience simple identifiers offer combined with the volume of "easy business" they permit make it make more sense to absorb the costs of some frauds.
Now, LARGE transactions generally elicit more scrutiny from the parties possibly on the hook, whether merchant, credit card company, or bank. Ever buy a house with some of the funds lent to you by a mortgage company? Lots to verify there.
As far as the phone company here is concerned, this is (a) Canada, where consumers seem to have far less protections (and contingency suits, IIRC, for egregious civil offences are not possible), but (b) privacy of indentifying information to initiate a business relationship is better protected than in the U.S. (which does makes some kinds of transactions impossible without a face to face meeting, rather than insuring against online fraud).
The problem is that there appears to be little protection against the fraudulent hijacking of an existing business relationship.
Usually, in businesses with peering arrangements, fraud in either direction is about equal, so the cross-charges cancel out. But, if that is not the case, usually the peering arrangement is severed. IOW, the phone company should NOT pay the international counterpart, and not charge the defrauded customer. If the Belarus telephone company does not like this, they have the option of not peering.
What complicates the issue here, though, is that the customer, using their own equipment, might quite well have been negligent in securing it.
You can now buy USB charging dock with, for example, four USB outluts.
IIRC, Islam also forbids the lending of money at interest. Whereas we in the U.S. are used to a lender taking a security interest in property purchased with the help of a loan, people who subscribe to faiths where lending at interest is forbidden solve the problem by the lender taking a depreciating ownership interest in the property, sharing proportionately in it's change in value (up or down), while the loan is being paid off. The purchaser's monthly payment goes partially toward purchasing more of the property and partially toward renting the part s/he does not own. Rather clever actually.
Yes, but package meta-data (what package managers use to resolve dependencies automagically), is NOT standardized.
Basically, you need a way of naming packages, an inheritance hierarchy describing which packages are extentions of others, virtual packages (so that if you need "foo" functionality, any package that implements "foo" functionality can be used), verification that packages implement the functionality of their virtual bases ("myFoo" works but "yourFOO" is buggy), a means of describing the specific installation details of a package (so that if bar needs libFoo, it knows where to look -- pkgtool does some of this), etc.
There are bits and pieces that solve some of the issues, but not all.
One of the nastyiest hurdles are config files that other packages want to edit: even had a package that needed to change some networking configuration? Is it in /etc/network/interfaces or /etc/sysconfig/network/eth? (or whatever, I'm sure I flubbed the paths somewhere). Ideally the networking "package" should define it's config file format for other packages to munge (or go the route of .d directories where orthogonal configs are separate files). The idea is if you know that use use "networkFoo" you know "networkFoo's" config file format.
But what if there's a competing network config standard for "networkBar", and you have networkBar not networkFoo installed? Shouldn't the "better" packages that depend on network packages be smart enough to deal with both (at least until the dust settles on which is better)?
You can either try to "force" a standard, and deal with issues in the package management system, or figure out the kind of metadata about a package that you need to maintain, and let the package managers arise to the challenge of using it.
Forcing a standard works only if it has already proven itself as a defacto standard that meets 95%+ of use case needs. Look at pkgtool, automake, and autoconf. Kinda ugly, but they do a fairly good job at what they do (and why .tar.gz generally works so well). Trouble is, they don't do everything, nor do they permit deferal of some decisions after compilation time (where, admitedly, there is less freedom). But, if an OS ise defined by "this" particular set of autoconf-aware parameters, presumably those things that depend on them (and only them) can be precompiled in a package for that OS, with the rest compiled at install time.
Duh.
Besides, "code you have on the box beats code that might be available".
What's sad here isn't that Mr. Perens comment is, well, common sense, but rather that so many don't see it as so obvious.
9.41. PROTECTION OF ONE'S OWN PROPERTY. (a) A person in
lawful possession of land or tangible, movable property is
justified in using force against another when and to the degree the
actor reasonably believes the force is immediately necessary to
prevent or terminate the other's trespass on the land or unlawful
interference with the property.
(b) A person unlawfully dispossessed of land or tangible,
movable property by another is justified in using force against the
other when and to the degree the actor reasonably believes the force
is immediately necessary to reenter the land or recover the
property if the actor uses the force immediately or in fresh pursuit
after the dispossession and:
(1) the actor reasonably believes the other had no
claim of right when he dispossessed the actor; or
(2) the other accomplished the dispossession by using
force, threat, or fraud against the actor.
9.42. DEADLY FORCE TO PROTECT PROPERTY. A person is
justified in using deadly force against another to protect land or
tangible, movable property:
(1) if he would be justified in using force against the
other under Section 9.41; and
(2) when and to the degree he reasonably believes the
deadly force is immediately necessary:
(A) to prevent the other's imminent commission of
arson, burglary, robbery, aggravated robbery, theft during the
nighttime, or criminal mischief during the nighttime; or
(B) to prevent the other who is fleeing
immediately after committing burglary, robbery, aggravated
robbery, or theft during the nighttime from escaping with the
property; and
(3) he reasonably believes that:
(A) the land or property cannot be protected or
recovered by any other means; or
(B) the use of force other than deadly force to
protect or recover the land or property would expose the actor or
another to a substantial risk of death or serious bodily injury.
Acts 1973, 63rd Leg., p. 883, ch. 399, 1, eff. Jan. 1, 1974.
Amended by Acts 1993, 73rd Leg., ch. 900, 1.01, eff. Sept. 1,
1994.
Since the teacher can bring arbitrary force to bear against the student via a summons for help, demanding the return of his property at gunpoint seems approrpiate as does killing her if she tries to flee.
No. The student shouldn't threaten to kill the teacher. The student should just plain hunt her down, kill her, and reclaim his stolen property.
Unless there is some exception for teachers on school property, or the laws have changed, in Texas it is legal to use deadly force to secure the return of property that was stolen from you.
If charged with murder, an adequate defense is (a) this is my property, (b) she stole it. Case closed.
You might find that barbaric -- I happen to agree with it, but, unless the law has changed there, or there is some exception for schools or teachers, it's perfectly legal.
Of course, I'd consult VERY CAREFULLY with a lawyer before taking such a course of action, but this idiot who's corrupting the minds of children deserves no less.
Not much, unless the soot is a problem: it's going to burn up in the atmosphere.
Indeed. One could argue that bondage might be arousing, in that it gives rise to thoughts of power over the poweless, but that arises in sexual role-playing, and not bona-fide entrapement (for most people).
Here, we clearly have a child, appearing unhappy, vulnerable, and helpless.
If the intent is to depict the inevitability of the ravage of time upon youth and innosence, I'd say, "damn good job!"
I can't see how any normal, or near-normal, person could find the image sexually arousing.
I also don't buy the argument that it "fuels" desire for children: it might be a trigger for a pederast, but the pederast is one whether the trigger is present or not.
And here I was going for +5, Funny as in a-complete-waste-of-the-court-clerk's-time. Sigh.
"MINUTE entry before Judge Harry D. Leinenweber : It has come to the Court's attention that the docketing department of the Clerk's Office is still inputing the names of the hundreds of defendants named in this action. This action was dismissed on 8/17/07 for failure to state a claim, and the Court of Appeals dismissed the appeal on 10/31/07 for failure to pay the required docketing fee. It is a waste of judicial resources for the Clerk's Office to continue adding these names to a closed case that the Court determined was delusional in its order of 8/17/07. The Clerk is therefore directed to cease adding the defendants' names to this docket. As this is an internal housekeeping matter, the Clerk is directed not to send notice of this order to Plaintiff. No notice to be mailed (gcy, )"
The kind of metadata has to do with stuff like age, location, etc.
The thing is, not only can one single point authentication useful for a number of services, one can also envision shared metadata following some schemas useful for a (likely smaller) number of services. A central mapping of Id to location, and another one to age, and another one to medical information (horrors!), that can be used by any service that needs some or all of these: when you register with a particular service, you provide your single-point ID, and the service asks you where the metadata for all the types it needs is stored, it it isn't already associated with the ID. If you never provided it, it is obtained, stored somewhere, given a tag of it's own, and bound to your single-point ID (and vice versa), and both databases updated.
So, if some site needs, say, a Resume, for which an XML Schema is defined, it can ask you, "Your ID does not map to an XMLResume, would you like to provide the mapping or create one?", then redirect you to a resume provider, which creates a ResumeID, binds it with your single-point authentication ID, and lets you include that binding with the single point authenticator for "next time".
Of course, just who can access what data should remain under your control, but I can envision a permission system based on PKI.
Except Microsoft services REQUIRE the appropriate metadata.
So, yes, the number of logins you have should be more than one, but does not have to be as large as the number of sites you visit.
But, to explain how OpenID, LiveID, and all such systems work without the site requesting the authentication requiring the authenticating credentials, it's like this:
1) You authenticate with the authentication site. You get back a magic number, or some similar credential.
2) You present this credential to the site that requests your authentication.
3) It contacts the authentcation site with it, (perhaps authenticating itself too using means like a client cert), provides the credentials you supplied, and gets back all sorts of nifty metadata about you.
Your credentials expire after some amount of time.
LiveID works like this for all Microsoft and Microsoft-partnered sites. And the same for OpenID.
The issue with having Microsoft accepting OpenIDs (besides the obvious econo-political one) is likely the nature of the metadata being different between what OpenID provides and what LiveID provides (unless OpenID supports the notion of arbitrary metadata per site requesting authentication, and so could support the LiveID metadata format).