You've just highlighted a lot of the problems with EULAs, especially in the server world, well done.
As far as I know(and this is from memory, and I'm not a lawyer either). The person who gets the license(and pays the fees) is the one who agrees to the Eula, that person is "intended" to be able to bind the whole company who uses the software, and in my jurisdiction, while binding clients is not heard of, they can certainly bind a subcontractant, which is what you presented yourself as earlier.
When I ask you to do something for me, you are acting as me, if I have an injunction against me not to do something, I can't hire you to do that thing for me, unless the injunction is very lax.
Most Eulas are written in such an unbalanced manner I'm surprised courts would see them above toilet paper, but again, IANAL. However, my original point was that the right to use Oracle was conditional to agreeing to Oracle's terms(as unbalanced and unreasonable as they may be), whereas writing a book about a piece of hardware you own is certainly a different matter.
I think the courts need to come out with jurisprudence that says that it is illegal to limit the rights to criticize software you pay for. Oracle wants to limit my right to benchmark them, they can let me use the software for free. Otherwise, if I contract with them, and I find their service or product despicable, ANY limit on my free speech to clarion my unsatisfaction is a dangerous precedent, IMHO, YMMV and again, IANAL.
Well considering Oracle's wording is that if you don't agree, you can't use the software, it might be a bit harder than you think. That so little effort has been spent in getting courts to declare sharing your user experience illegal, now that's something surprising. As for different countries having different laws, I dunno about yours, but in mine, the aggregate data doesn't belong to you in the first place, since it was part of a contract, UNLESS the clients actually agreed the data belonged to you at the end of the benchmarks.
That's different, when you get Oracle software, you get a Eula, and the Eula says you AGREE that it's illegal for you to do these things once you have the software.
I doubt Deitel agreed he gave up the right to publish a book about Cisco that meets a needs he identified, pointed out to Cisco, and Cisco refused to meet.
Just to clarify though, for your system to be like ours, only the House Members would get a vote, and the "party with the mouse house members"'s leader would be president.
There's no "choose for itself" here, it's more of a "Your team won, you're the captain, so you get the award, you win because you built the team that impressed us more"
Why is this distinction important? Well because first of all State Government is a whole different nine yards, for one, a little event about 30 years ago started a big stink which still impacted last election, it's something you americans are very familiar with, called seperation of powers. Now IANAL, and the event happened the year I was born or around that time, so I can't exactly comment on the event itself, but I certainly trust my state government less the more friendly it is with the country's government. In this case, a passage, which intent was rather clear, was left... unclear enough to be politicked on, and that left us with Health Care as a federal campaign issue. Furthermore, I can prove I'm not a lawyer, because I think that when that document(the last update to what I'm talking about is now known as Article 92.7 of the Canadian Constitution) mentions that Health Care and Education are provincial core competitiencies, that means the Federal Parties were exposing themselves to fines and censorship by using the world health care, and education, as opposed to referring to Provincial Transfers, period, and that they need to recognize that article 92 of the constition says "It's none of their fricking business".
Whatever I can say about the USA, I haven't seen your federal government do the literal opposite of one of your Amendments, but then, maybe I just live on the wrong side of the border.
And because the situation is bad, they can't identify the problems, ridicule them, and perhaps, within the next century actually fix one or two? If you aren't part of the solution, you're usually on the problem side.
Right on, the fact that Canada's votes are local first in nature(we vote for our representative) also brings a few differences with the American system:
Instead of electors, we elect a local representative, who affects local issues in our "Congress" we call it parliament. That means you have to live with your "Elector" for four years, and so you better pick a good one.
I've seen arguments about the complexity of the systems, I'd like to object that Complexity doesn't scale well, and that complexity by itself isn't a solution. If you graph the power relationships in Canada, you see a directed graph Electors many->one Representative Many->One Party One->One Party Leader
Can anyone supply an equivalent graph for the US? Now note that superior complexity might be an asset for manageability, provided it doesn't obscure the power relationships involved.
On a related note, when I as a Canadian go vote, I see the name of a candidate, and the name of his party, I can't say I don't know how my vote will be interpreted.
In the US, with the Elector system, do the citizens who vote understand the system enough to feel that secure?
I have a question for you, wouldn't the fact that some parts of the country allow for different methods than others, some more stringent, some less strict, allow for more contestation of the results?
The urban legend is that serious, dedicated technical people are loathe to release any hackable/exploitable technology, at least knowingly. Those self-same semi-mythical people are also perfectly ok with not having a product at all until their technical standards are met. The equally semi-mythical people in marketing are loathe to wait to have a product to sell it.
The real world hates such classifications, of any type, you can find crooked people anywhere, and everywhere. What is important to remember is that e-voting is a chain of people, who must all perform honestly, and verifiably, for a trustable result. Any crooked people in the process throws the whole verifiably/trustworthiness aspect out of the window. That means we must have more stringent control and verification procedures than for say, money-printing(the mint) or Narcotics manufacturing(pharmaceutical companies, the high-security types, like Morphine Sulfate). Right now we don't have that, e-voting is done by a single company because we barely have a proper security model of the threats facing them, and very few suppliers. Perhaps one way to get trustable e-voting would be to have TWO machines record each vote, through two different computer systems, linked through two mediums(one fiberoptic, the other wireless to off-premise, for example) to two different tallying centers. Two seperate, double-blind tallies should be used, using the double blind method whenever possible. If anything, the only problem is that unlike paper vote, with its paper trail and such, where attempted fraud is perceived as likely, unless proven otherwise, we have an e-voting method, which is intended to save money, where as long as we can run a few cursory checks, and save that money, we are content. E-voting should also consider prime facie each vote to be a fraud, and include tally marks from each person from the two booth election officers who noted that the vote was valid, and where it was taken, down to all the relay points where the vote was passed. TCP/IP(even with IPSEC) is a bad choice for the network, as it is meant to route around failures, whereas an e-voting network should consider a network failure a breach of trust with a remote site, requiring to reestablish trust explicitely.
We would be better advised not to try to do e-voting on the cheap, e-voting can work, provided we treat each vote like an anonymized, but valid command to launch a nuclear warhead. It has practically the same importance that we validate where it's from, and who it is, except we don't know who it is, that information is only allowed to the voter who voted himself.
But that's actually a current model in software engineering. The only problem is that the current model(indeed NO software modeling technique) requires you to answer all the questions, go through ALL the iterations, especially in the requirements phase, before you start building the first prototype.
the FCC licensed user in this case is the Military. The keyless car entry is the Unlicensed user, in this case, it's the BAD guy. A smart keyless entry system user might make a request for a small bit of spectrum, and market a "free from interference" keyless entry that works "even near military bases".
Apt is "available" on other distros, but it's NOT the same apt that debian has.
Quite simply, because a deb gets through more QA before release, not to mention that the standard debian packages have the following advantages:
1) most debian packages manage config file changes by the user, and try to merge them(at least in unstable, not 100% sure about Sarge as of yet) 2) Debian's userid/tcp-ip ports management through dpkg catches more errors and allows better handling for special situations(like development boxes running several different kinds of web servers, for instance), that might just be my personal experience however(although the amount of work I had to perform to get 6 different types of webservers on a single debian box was lower than on any other distro I've tried by a large amount) 3) I take exception to your "What's the point of getting Debian stable, when it is so out of date?" statement. Until you replace stable with unstable, I read that as an oxymoron. Stable software was out of date last month, it is however, secure, usable, and third parties have had months to work out their alphas and beta phases, so now you can use it with your 12321322123112 machines with no worries that a bug hasn't been found YET. Not that Debian is IMMUNE to bugs, but up-to-date software IS rife with bugs(and if you're lucky, you don't wait too long for your fix). But with debian stable, that's confusing the security patches, with the next generation release, and that's bad juju.
The branch of Debian I notice you don't mention anywhere, is testing, which just might do what you think is Stable's job. For the rest of us, I'll go pray that some 3rd parties get a clue from Debian and start producing Stable branches of their software that break less often than their Unstable ones.
Considering one of the first, and arguably, one of the most popular, live cd distros is knoppix, which is debian-based, your point is?
Also, the social contract changes apply to what third party(the non-free, IIRC) packages get distracted which ways. The new debian-installer's schedule is unchanged by this, since it was not part of non-free.
Since debian's unstable also leads the way in a lot of other fields(Debian was among the first three distros to adopt the new non-XFree86 xserver, again IIRC), I find your comment curious.
This is a policy change about what can be included in the edges of Debian, Debian-Stable's habit of being more than plenty stable enough to run hundreds of servers on and sleep at night, isn't likely to change. For everyone else, there's backports and sid.
You got it, except that "data about data" or "information about information" is usually interesting, but a bit vague. In this case, we'd be talking about "Data about computer contents". We're actually super-classing, as it were, RDF, which is usually "data about written text", an article on slashdot, for instance.
Your computer already stores data about its files and such, but that's metadata's readability by humans is a bit questionable(all the concepts except file name and an eventual comment only make sense inside a computer). What's interesting about this new idea, is that RDF will allow to encode data that makes no sense to your computer, like say, "Saved voice mail from hottie" Yes this could be in a comment, but it might also be say, a MacOSX label, or something more formal, note that the article also implies you can attach several different types of metadata to a single "datum", and you can also specify a role to each. Say you could associate a second bit of metadata once you learn the hottie's name. Using comments means you'd have to alter the comment.
To get back to your question, we can't define metadata, not in this case, since you have the exact definition. What we need to do, is specify what DATA we're talking about.
Data about desktop contents is a bit different than say webserver contents, or database contents, or metadata about confidential information about a patient, but it's still data about data, hence, metadata.
The LizardMan, the Shocker, the Chameleon, Kraven the Hunter would be good choices. The Vulture wouldn't be so good. And for those with long memories, the Kingpin was an enemy of both Daredevil and Spidey, but who fought him first is something I can't remember. I suspect that Mysterio the actor, or LizardMan would be areas filmmakers would explore first(Mysterio would be a tie-in to MJ, and LizardMan well that's a spoiler hehehe.
If you count the price of downtime because their team was too small, yes. MUCH more expensive. On the scale of bankrupt, try again next state. Now mind you, there are no guarantees, but moving even a/22 where clients' and resellers' nameservers are involved(not moving a/22 that only involves you) can certainly be very time consuming, costly and complicated. Not that lawyers are inexepensive, but playing russian roulette with your livelyhood HAS to be more dangerous than a paid consultant(which a lawyer is a derivative of...)
You're right, but think of it this way if you're too small for Arin, what are your chances that someone you want to BGP peer with you will think you're big enough?
IPv6 avoids this problem altogether. For IPv4, you will probably have trouble getting routing for any "grain" smaller than/21,/20 in many cases actually. This is consistent with Arin's policy on ownership, btw. That's why those with smaller blocks can't own ips, they lease/use the ones from their providers, who aggregate them into larger routes, and this keeps routing tables smaller.
It's for a block of IPs, I estimate about a/20's worth. And yes, litigation could have been avoided in that case, but mostly that would have required legal council before signing the contract(45 days notice is not a lot for a network that size)
The guy is moving hundreds of dedicated servers belonging to his clients, most of which run nameservers, give him a break. It's a LOT more work than you think. He has to notify his clients in advance, hope they all change to the new addresses, make sure the dns on the new addresses answer properly. Etc... With the size of the client I garnered from the TRO, 45 days with a 5+ persons team is probably optimistic.
Not every client of an ISP runs a small not-for-profit club that has only two members...
IANAL, but 1) the article seems to say a different thing than the actual TRO 2) I'll explain why if the court had ruled like the article said, we'd be in deep shit, and second, I'll document my understand of the TRO
The main difference is that your cell phone company can't lose your cell phone number without a major cause. ARIN can decide to remove any number at its wish, meaning that someone could go to court, trying to block an ARIN reassignment from Provider ISP, even if they are the CAUSE of that reassignment. Say if client is not using 80% of its space, and ARIN, who granted that space(ARIN may grant space in many forms, but most ISPs prefer contiguous blocks, for routing reasons.), then when the Provider notifies the client that they messed up, asking for too large a block from them, the client could try to sue, thereby interfering with the priorly business-as-usual motions of ARIN-Provider-Client.
IP addresses are assigned to your provider by ARIN/RIPE/APNIC and may be taken away from them at a moment's notice. They are also organized in network topologies, meaning that if the ruling stands, the entire routing of the Internet has to be re-thought. Well ok, just migrating everyone to IPv6, and using v6-to-v4 tunnels might do the trick, Provided the judge doesn't make the claim you own your v4 address too, which with dynamic addresses, would get messy even faster.
Also, for that matter, what about static dhcp addresses, addresses that are assigned by a dynamic method, but keep up coming to the same value for a specific client, does the ruling say the client own them? If they do, I can imagine a whole bunch of dsl providers going "no we don't offer static ips anymore". And that's because the ISP, which is responsible for routing, and for making sure the routing is coherent, and router-friendly, and that their own AS is reachable, is no longer involved in the assignment of those ips.
The only people who actually use ip addresses, and who have trouble with numbers, are people who operate nameservers, since their job is to offer address to name translation, so having their address be static is a requirement of the job, so they can be found. Now some of those are assigned in/32 increments, and indeed, a naive reading of the article might indicate that if I assign a client, and that client sues, the routing table of the internet might soon have 2^32 routes, and most routers crash.
Ruling that they own that ip address, considering the contracts between Arin and suppliers, means all those contracts have been invalidated. If I was ARIN, I'd be very very afraid right now. If you can own a block, what will you do if ARIN takes a block back for lack of use? Sue them of course, it's what the court just indicated by rendering your lease of those ips unenforceable, by virtue of saying you could own your ip numbers.
Now, I'm not sure why, but the article makes no mention that the the court issued a temporary restraining order, until migration is complete. That means NAC has to offer ip forwarding for a limited time, to help migration, especially since the client applied to own ips at ARIN directly already. The restraining order also looks(But IANAL) written in such as way as to prevent guerilla action on the part of NAC against the client, more than anything. I do find it interesting that (I've done a lot of moves for my clients in similar situations, although perhaps smaller than this particular client) the client preferred to go to court, instead of putting pressure on NAC to renew at current prices, while preparing it's migration. 45 days is certainly not a lot of time for a truly large network, but just how many days did they win by going to court, including the TRO and the remand to higher court?
Although, maybe they just wanted some insurance, considering the penalties that NAC would incur if the client was down without "due cause". The amount in dollars for an 8-hour or more outage would certainly help with migra
I was saying 1) a) Just how much more power could we get? is beyond my mere predicate logic skills at this time.
Explaining just what power is missing from SQL to explain "the full power of relational models" in the context of the article, where it is said relational algebra can represent tree-like structures etc... is beyond me.
I am not interested in how hard relational is to use.
1)a) was referring to expressing, just what's missing in all the SQL servers, that could be reached if they were truly relational. In this case it has a lot more to do with how we define what you can AND on, a lot more than what operations you can use. I can understand AND just fine, I have a lot more problems with understanding how the experts say on one breath "it's not flat tables anymore" and on the next, no explanation on what operations you can use on a non-flat table... Say is the AND of a pair of arrays of floats the matrix product of the ands of the arrays? In what precision? Or are they just saying "the tables aren't flat, they can be linked" but you gotta restrict your operations on the virtual flat tables that overlay your more esoteric structures?
ADABAS D had arrays and such(it's now MySQL MaxDB I believe) inside sql-addressable tables, but that was a relatively poorly supported feature, once which wasn't well modeled( you can see from my examples why it wasn't well modeled, I think, it brings up questions about the domains of each operation)
We can certainly agree on the lousy marketer and packager, but you know what? The marketers won't help you write your complex queries either, Codd's theories just might(well again, they might not, but that's what the original post was about).
I'm sure I misunderstand more about predicate logic than you've understood in the time it took you to read these lines, but I was aware of those limitations, and kept my post in line with that.
You however chose to limit the relational model's power, to the logical operators it uses, without mentioning that the relational model also includes rules on how you can organize what objects you can apply those operators TO, which is a rather important distinction, and probably closer to weaknesses of SQL, as evidenced in the article anyways. Anyone can write relational algebra if you got scalar booleans, but if you got an array of complex numbers to multiply by a matrix of floats, and all that needs union(or any other type of join etc...) with userids, full names and addresses, it gets a little bit more fun.
Thus, we extended the "language" of Boolean to closer match human language. As long as our extensions are defined using the primatives and don't break the rules of our system, we can have our cake and eat it to. True Boolean geeks can still use NAND if they want.
Well "the rules of our system" also include just what we can NAND (or AND or XOR) ON, not just those operations. The definition domain of those operations is also important, that's why in SQL's fuzzy logic, ANDing with a NULL gives you a NULL. Now if there's an impedence mismatch between sql and relational theory, it's probably on the definition domain of the operations(NULLs, non-scalars values, strings) and not on AND itself, which is pretty much a "simple" operator, at least when you limit yourself to scalar values like booleans, and logical predicates.
The experts who know what the heck the relational model is and is not argue that the language we use to query a specific type of relational-like database, that they call the SQL databases, the SQL language, has unsufficient representation power to represent the whole model, and hence can't be used to get the whole power of the model.
That's certainly interesting, and leaves us to ponder two things:
1) a) Just how much more power could we get? b) And at what cost?
2) What about alternatives, can we get that same power elsewhere, cheaper?
1)a) is beyond my mere predicate logic skills at this time.
1)b) The cost of a model for data storage, representation and management is directly linked to it's adaptability to the data you represent. The article mentions a lot of errors with NULLs(I remember thinking, while reading the article: a NULL was an attempt by the language developers to simulate an interrupt in a language that doesn't have any, this is of course, an oversimplification on my part, but considering stored procedures and triggers[SQL's own exceptions] weren't around yet, they sound like a good basis for further research.) There are a lot of other hidden "costs" for people who use a relational tool for not-quite-so-relational data, but that's not part of the cost of a relational language, per se.
2) Brings up a few notions: there are the types of databases relational databases replaced, like network databases, and there are attempted replacements, like object databases. There are also further possibilities that I will explore deeper later. Object databases can certainly be interesting, in the sense that by bundling data with code, you can have data that can handle itself, in the very basic sense that we humans apply it to ourselves. The problem is that we tend to have a very fuzzy, real-world view of such data, and can't work with it that easily(we are using computers to make data easier to work with, so if we had software that could handle real-world data complexity outside of our brains, we wouldn't be having this discussion). Object data is certainly very adept with data that has some broad commonalities, re-usable behaviours, and follows set-rules. We can call those business rules for now. Those business rules imply that a certain subset of "The Universe" interests us more than the rest, and follows predictable commonalities, making our mental models a lot less complex. On the other hand, object methodology is not always well understood, and the documentation and models it generates sometimes dwarf some production systems implemented to solve the same problems.
Now, at the beginning, Relational Systems were data-handling "toolkits" set to handle specific subsets of data, who also followed business rules. That's interesting to my purpose, simply because I can envision, at this time(some vendors have similar concepts, but don't formalize them in any way), a new set of "toolkits" where the relational model is only one of many "toolsets" available.
Indeed, what is probably the most used sql-based server available(MySQL) has been lacking true relational functionality for most of its life, yet that doesn't make the tool less useful for most of its users. Future toolkits can inspire themselves by focusing on specific uses of technology to solve specific problems, and yet keep the SQL as a sort of security blanket, since that's where most of the training about databases(and indeed, usually most of the training about data, period, is in database classes and perhaps, some algorithmics classes)
After reading the linked articles about XML's weaknesses, though, I don't think it belongs into any toolkit of that nature. Simply because the tool that belongs in the toolkit is the "self-documenting data", and XML's weakness in that area is evidenced there. XML's early focus as a medium of e
Slashdot Mirror
You've just highlighted a lot of the problems with EULAs, especially in the server world, well done.
As far as I know(and this is from memory, and I'm not a lawyer either). The person who gets the license(and pays the fees) is the one who agrees to the Eula, that person is "intended" to be able to bind the whole company who uses the software, and in my jurisdiction, while binding clients is not heard of, they can certainly bind a subcontractant, which is what you presented yourself as earlier.
When I ask you to do something for me, you are acting as me, if I have an injunction against me not to do something, I can't hire you to do that thing for me, unless the injunction is very lax.
Most Eulas are written in such an unbalanced manner I'm surprised courts would see them above toilet paper, but again, IANAL. However, my original point was that the right to use Oracle was conditional to agreeing to Oracle's terms(as unbalanced and unreasonable as they may be), whereas writing a book about a piece of hardware you own is certainly a different matter.
I think the courts need to come out with jurisprudence that says that it is illegal to limit the rights to criticize software you pay for. Oracle wants to limit my right to benchmark them, they can let me use the software for free. Otherwise, if I contract with them, and I find their service or product despicable, ANY limit on my free speech to clarion my unsatisfaction is a dangerous precedent, IMHO, YMMV and again, IANAL.
Well considering Oracle's wording is that if you don't agree, you can't use the software, it might be a bit harder than you think. That so little effort has been spent in getting courts to declare sharing your user experience illegal, now that's something surprising.
As for different countries having different laws, I dunno about yours, but in mine, the aggregate data doesn't belong to you in the first place, since it was part of a contract, UNLESS the clients actually agreed the data belonged to you at the end of the benchmarks.
That's different, when you get Oracle software, you get a Eula, and the Eula says you AGREE that it's illegal for you to do these things once you have the software.
I doubt Deitel agreed he gave up the right to publish a book about Cisco that meets a needs he identified, pointed out to Cisco, and Cisco refused to meet.
Doesn't FC2 bring synaptic with it?
I know it's only at apt-get install synaptic away at worse, but it might solve this particular problem
Just to clarify though, for your system to be like ours, only the House Members would get a vote, and the "party with the mouse house members"'s leader would be president.
There's no "choose for itself" here, it's more of a "Your team won, you're the captain, so you get the award, you win because you built the team that impressed us more"
Why is this distinction important? Well because first of all State Government is a whole different nine yards, for one, a little event about 30 years ago started a big stink which still impacted last election, it's something you americans are very familiar with, called seperation of powers. Now IANAL, and the event happened the year I was born or around that time, so I can't exactly comment on the event itself, but I certainly trust my state government less the more friendly it is with the country's government. In this case, a passage, which intent was rather clear, was left... unclear enough to be politicked on, and that left us with Health Care as a federal campaign issue. Furthermore, I can prove I'm not a lawyer, because I think that when that document(the last update to what I'm talking about is now known as Article 92.7 of the Canadian Constitution) mentions that Health Care and Education are provincial core competitiencies, that means the Federal Parties were exposing themselves to fines and censorship by using the world health care, and education, as opposed to referring to Provincial Transfers, period, and that they need to recognize that article 92 of the constition says "It's none of their fricking business".
Whatever I can say about the USA, I haven't seen your federal government do the literal opposite of one of your Amendments, but then, maybe I just live on the wrong side of the border.
And because the situation is bad, they can't identify the problems, ridicule them, and perhaps, within the next century actually fix one or two?
If you aren't part of the solution, you're usually on the problem side.
Right on, the fact that Canada's votes are local first in nature(we vote for our representative) also brings a few differences with the American system:
Instead of electors, we elect a local representative, who affects local issues in our "Congress" we call it parliament. That means you have to live with your "Elector" for four years, and so you better pick a good one.
I've seen arguments about the complexity of the systems, I'd like to object that Complexity doesn't scale well, and that complexity by itself isn't a solution. If you graph the power relationships in Canada, you see a directed graph
Electors many->one Representative Many->One Party One->One Party Leader
Can anyone supply an equivalent graph for the US? Now note that superior complexity might be an asset for manageability, provided it doesn't obscure the power relationships involved.
On a related note, when I as a Canadian go vote, I see the name of a candidate, and the name of his party, I can't say I don't know how my vote will be interpreted.
In the US, with the Elector system, do the citizens who vote understand the system enough to feel that secure?
I have a question for you, wouldn't the fact that some parts of the country allow for different methods than others, some more stringent, some less strict, allow for more contestation of the results?
The urban legend is that serious, dedicated technical people are loathe to release any hackable/exploitable technology, at least knowingly. Those self-same semi-mythical people are also perfectly ok with not having a product at all until their technical standards are met. The equally semi-mythical people in marketing are loathe to wait to have a product to sell it.
The real world hates such classifications, of any type, you can find crooked people anywhere, and everywhere. What is important to remember is that e-voting is a chain of people, who must all perform honestly, and verifiably, for a trustable result. Any crooked people in the process throws the whole verifiably/trustworthiness aspect out of the window. That means we must have more stringent control and verification procedures than for say, money-printing(the mint) or Narcotics manufacturing(pharmaceutical companies, the high-security types, like Morphine Sulfate). Right now we don't have that, e-voting is done by a single company because we barely have a proper security model of the threats facing them, and very few suppliers. Perhaps one way to get trustable e-voting would be to have TWO machines record each vote, through two different computer systems, linked through two mediums(one fiberoptic, the other wireless to off-premise, for example) to two different tallying centers. Two seperate, double-blind tallies should be used, using the double blind method whenever possible. If anything, the only problem is that unlike paper vote, with its paper trail and such, where attempted fraud is perceived as likely, unless proven otherwise, we have an e-voting method, which is intended to save money, where as long as we can run a few cursory checks, and save that money, we are content. E-voting should also consider prime facie each vote to be a fraud, and include tally marks from each person from the two booth election officers who noted that the vote was valid, and where it was taken, down to all the relay points where the vote was passed. TCP/IP(even with IPSEC) is a bad choice for the network, as it is meant to route around failures, whereas an e-voting network should consider a network failure a breach of trust with a remote site, requiring to reestablish trust explicitely.
We would be better advised not to try to do e-voting on the cheap, e-voting can work, provided we treat each vote like an anonymized, but valid command to launch a nuclear warhead. It has practically the same importance that we validate where it's from, and who it is, except we don't know who it is, that information is only allowed to the voter who voted himself.
But that's actually a current model in software engineering. The only problem is that the current model(indeed NO software modeling technique) requires you to answer all the questions, go through ALL the iterations, especially in the requirements phase, before you start building the first prototype.
the FCC licensed user in this case is the Military. The keyless car entry is the Unlicensed user, in this case, it's the BAD guy. A smart keyless entry system user might make a request for a small bit of spectrum, and market a "free from interference" keyless entry that works "even near military bases".
Apt is "available" on other distros, but it's NOT the same apt that debian has.
Quite simply, because a deb gets through more QA before release, not to mention that the standard debian packages have the following advantages:
1) most debian packages manage config file changes by the user, and try to merge them(at least in unstable, not 100% sure about Sarge as of yet)
2) Debian's userid/tcp-ip ports management through dpkg catches more errors and allows better handling for special situations(like development boxes running several different kinds of web servers, for instance), that might just be my personal experience however(although the amount of work I had to perform to get 6 different types of webservers on a single debian box was lower than on any other distro I've tried by a large amount)
3) I take exception to your "What's the point of getting Debian stable, when it is so out of date?" statement. Until you replace stable with unstable, I read that as an oxymoron. Stable software was out of date last month, it is however, secure, usable, and third parties have had months to work out their alphas and beta phases, so now you can use it with your 12321322123112 machines with no worries that a bug hasn't been found YET. Not that Debian is IMMUNE to bugs, but up-to-date software IS rife with bugs(and if you're lucky, you don't wait too long for your fix). But with debian stable, that's confusing the security patches, with the next generation release, and that's bad juju.
The branch of Debian I notice you don't mention anywhere, is testing, which just might do what you think is Stable's job. For the rest of us, I'll go pray that some 3rd parties get a clue from Debian and start producing Stable branches of their software that break less often than their Unstable ones.
Considering one of the first, and arguably, one of the most popular, live cd distros is knoppix, which is debian-based, your point is?
Also, the social contract changes apply to what third party(the non-free, IIRC) packages get distracted which ways. The new debian-installer's schedule is unchanged by this, since it was not part of non-free.
Since debian's unstable also leads the way in a lot of other fields(Debian was among the first three distros to adopt the new non-XFree86 xserver, again IIRC), I find your comment curious.
This is a policy change about what can be included in the edges of Debian, Debian-Stable's habit of being more than plenty stable enough to run hundreds of servers on and sleep at night, isn't likely to change. For everyone else, there's backports and sid.
You got it, except that "data about data" or "information about information" is usually interesting, but a bit vague. In this case, we'd be talking about "Data about computer contents". We're actually super-classing, as it were, RDF, which is usually "data about written text", an article on slashdot, for instance.
Your computer already stores data about its files and such, but that's metadata's readability by humans is a bit questionable(all the concepts except file name and an eventual comment only make sense inside a computer). What's interesting about this new idea, is that RDF will allow to encode data that makes no sense to your computer, like say, "Saved voice mail from hottie" Yes this could be in a comment, but it might also be say, a MacOSX label, or something more formal, note that the article also implies you can attach several different types of metadata to a single "datum", and you can also specify a role to each. Say you could associate a second bit of metadata once you learn the hottie's name. Using comments means you'd have to alter the comment.
To get back to your question, we can't define metadata, not in this case, since you have the exact definition. What we need to do, is specify what DATA we're talking about.
Data about desktop contents is a bit different than say webserver contents, or database contents, or metadata about confidential information about a patient, but it's still data about data, hence, metadata.
anyone notice some numbering systems aren't very resillient, and some others are?
When are we expected to run out of MAC addresses?
The LizardMan, the Shocker, the Chameleon, Kraven the Hunter would be good choices. The Vulture wouldn't be so good. And for those with long memories, the Kingpin was an enemy of both Daredevil and Spidey, but who fought him first is something I can't remember. I suspect that Mysterio the actor, or LizardMan would be areas filmmakers would explore first(Mysterio would be a tie-in to MJ, and LizardMan well that's a spoiler hehehe.
If you count the price of downtime because their team was too small, yes. MUCH more expensive. /22 where clients' and resellers' nameservers are involved(not moving a /22 that only involves you) can certainly be very time consuming, costly and complicated. Not that lawyers are inexepensive, but playing russian roulette with your livelyhood HAS to be more dangerous than a paid consultant(which a lawyer is a derivative of...)
On the scale of bankrupt, try again next state.
Now mind you, there are no guarantees, but moving even a
You're right, but think of it this way
if you're too small for Arin, what are your chances that someone you want to BGP peer with you will think you're big enough?
IPv6 avoids this problem altogether. /21, /20 in many cases actually. This is consistent with Arin's policy on ownership, btw.
For IPv4, you will probably have trouble getting routing for any "grain" smaller than
That's why those with smaller blocks can't own ips, they lease/use the ones from their providers, who aggregate them into larger routes, and this keeps routing tables smaller.
Decent size is already defined /21 for multihomed networks /20 for singlehomed networks
That's from arin's papers.
Once you reach that size(hint, it's harder than you think) you also pay Arin a fixed amount of money a year for your allocation.
You obviously haven't read the whole thing.
/20's worth. And yes, litigation could have been avoided in that case, but mostly that would have required legal council before signing the contract(45 days notice is not a lot for a network that size)
It's for a block of IPs, I estimate about a
The guy is moving hundreds of dedicated servers belonging to his clients, most of which run nameservers, give him a break. It's a LOT more work than you think. He has to notify his clients in advance, hope they all change to the new addresses, make sure the dns on the new addresses answer properly. Etc... With the size of the client I garnered from the TRO, 45 days with a 5+ persons team is probably optimistic.
Not every client of an ISP runs a small not-for-profit club that has only two members...
IANAL, but
/32 increments, and indeed, a naive reading of the article might indicate that if I assign a client, and that client sues, the routing table of the internet might soon have 2^32 routes, and most routers crash.
1) the article seems to say a different thing than the actual TRO
2) I'll explain why if the court had ruled like the article said, we'd be in deep shit, and second, I'll document my understand of the TRO
The main difference is that your cell phone company can't lose your cell phone number without a major cause. ARIN can decide to remove any number at its wish, meaning that someone could go to court, trying to block an ARIN reassignment from Provider ISP, even if they are the CAUSE of that reassignment. Say if client is not using 80% of its space, and ARIN, who granted that space(ARIN may grant space in many forms, but most ISPs prefer contiguous blocks, for routing reasons.), then when the Provider notifies the client that they messed up, asking for too large a block from them, the client could try to sue, thereby interfering with the priorly business-as-usual motions of ARIN-Provider-Client.
IP addresses are assigned to your provider by ARIN/RIPE/APNIC and may be taken away from them at a moment's notice. They are also organized in network topologies, meaning that if the ruling stands, the entire routing of the Internet has to be re-thought.
Well ok, just migrating everyone to IPv6, and using v6-to-v4 tunnels might do the trick, Provided the judge doesn't make the claim you own your v4 address too, which with dynamic addresses, would get messy even faster.
Also, for that matter, what about static dhcp addresses, addresses that are assigned by a dynamic method, but keep up coming to the same value for a specific client, does the ruling say the client own them? If they do, I can imagine a whole bunch of dsl providers going "no we don't offer static ips anymore".
And that's because the ISP, which is responsible for routing, and for making sure the routing is coherent, and router-friendly, and that their own AS is reachable, is no longer involved in the assignment of those ips.
The only people who actually use ip addresses, and who have trouble with numbers, are people who operate nameservers, since their job is to offer address to name translation, so having their address be static is a requirement of the job, so they can be found. Now some of those are assigned in
Ruling that they own that ip address, considering the contracts between Arin and suppliers, means all those contracts have been invalidated. If I was ARIN, I'd be very very afraid right now. If you can own a block, what will you do if ARIN takes a block back for lack of use? Sue them of course, it's what the court just indicated by rendering your lease of those ips unenforceable, by virtue of saying you could own your ip numbers.
Now, I'm not sure why, but the article makes no mention that the the court issued a temporary restraining order, until migration is complete.
That means NAC has to offer ip forwarding for a limited time, to help migration, especially since the client applied to own ips at ARIN directly already.
The restraining order also looks(But IANAL) written in such as way as to prevent guerilla action on the part of NAC against the client, more than anything.
I do find it interesting that (I've done a lot of moves for my clients in similar situations, although perhaps smaller than this particular client) the client preferred to go to court, instead of putting pressure on NAC to renew at current prices, while preparing it's migration. 45 days is certainly not a lot of time for a truly large network, but just how many days did they win by going to court, including the TRO and the remand to higher court?
Although, maybe they just wanted some insurance, considering the penalties that NAC would incur if the client was down without "due cause". The amount in dollars for an 8-hour or more outage would certainly help with migra
I was saying
1) a) Just how much more power could we get?
is beyond my mere predicate logic skills at this time.
Explaining just what power is missing from SQL to explain "the full power of relational models" in the context of the article, where it is said relational algebra can represent tree-like structures etc... is beyond me.
I am not interested in how hard relational is to use.
1)a) was referring to expressing, just what's missing in all the SQL servers, that could be reached if they were truly relational. In this case it has a lot more to do with how we define what you can AND on, a lot more than what operations you can use. I can understand AND just fine, I have a lot more problems with understanding how the experts say on one breath "it's not flat tables anymore" and on the next, no explanation on what operations you can use on a non-flat table... Say is the AND of a pair of arrays of floats the matrix product of the ands of the arrays? In what precision? Or are they just saying "the tables aren't flat, they can be linked" but you gotta restrict your operations on the virtual flat tables that overlay your more esoteric structures?
ADABAS D had arrays and such(it's now MySQL MaxDB I believe) inside sql-addressable tables, but that was a relatively poorly supported feature, once which wasn't well modeled( you can see from my examples why it wasn't well modeled, I think, it brings up questions about the domains of each operation)
We can certainly agree on the lousy marketer and packager, but you know what? The marketers won't help you write your complex queries either, Codd's theories just might(well again, they might not, but that's what the original post was about).
I'm sure I misunderstand more about predicate logic than you've understood in the time it took you to read these lines, but I was aware of those limitations, and kept my post in line with that.
You however chose to limit the relational model's power, to the logical operators it uses, without mentioning that the relational model also includes rules on how you can organize what objects you can apply those operators TO, which is a rather important distinction, and probably closer to weaknesses of SQL, as evidenced in the article anyways. Anyone can write relational algebra if you got scalar booleans, but if you got an array of complex numbers to multiply by a matrix of floats, and all that needs union(or any other type of join etc...) with userids, full names and addresses, it gets a little bit more fun.
Well "the rules of our system" also include just what we can NAND (or AND or XOR) ON, not just those operations. The definition domain of those operations is also important, that's why in SQL's fuzzy logic, ANDing with a NULL gives you a NULL.
Now if there's an impedence mismatch between sql and relational theory, it's probably on the definition domain of the operations(NULLs, non-scalars values, strings) and not on AND itself, which is pretty much a "simple" operator, at least when you limit yourself to scalar values like booleans, and logical predicates.
That SQL is mostly a kludge?
Let me restructure that...
The experts who know what the heck the relational model is and is not argue that the language we use to query a specific type of relational-like database, that they call the SQL databases, the SQL language, has unsufficient representation power to represent the whole model, and hence can't be used to get the whole power of the model.
That's certainly interesting, and leaves us to ponder two things:
1) a) Just how much more power could we get? b) And at what cost?
2) What about alternatives, can we get that same power elsewhere, cheaper?
1)a) is beyond my mere predicate logic skills at this time.
1)b) The cost of a model for data storage, representation and management is directly linked to it's adaptability to the data you represent. The article mentions a lot of errors with NULLs(I remember thinking, while reading the article: a NULL was an attempt by the language developers to simulate an interrupt in a language that doesn't have any, this is of course, an oversimplification on my part, but considering stored procedures and triggers[SQL's own exceptions] weren't around yet, they sound like a good basis for further research.) There are a lot of other hidden "costs" for people who use a relational tool for not-quite-so-relational data, but that's not part of the cost of a relational language, per se.
2) Brings up a few notions: there are the types of databases relational databases replaced, like network databases, and there are attempted replacements, like object databases. There are also further possibilities that I will explore deeper later. Object databases can certainly be interesting, in the sense that by bundling data with code, you can have data that can handle itself, in the very basic sense that we humans apply it to ourselves. The problem is that we tend to have a very fuzzy, real-world view of such data, and can't work with it that easily(we are using computers to make data easier to work with, so if we had software that could handle real-world data complexity outside of our brains, we wouldn't be having this discussion). Object data is certainly very adept with data that has some broad commonalities, re-usable behaviours, and follows set-rules. We can call those business rules for now. Those business rules imply that a certain subset of "The Universe" interests us more than the rest, and follows predictable commonalities, making our mental models a lot less complex. On the other hand, object methodology is not always well understood, and the documentation and models it generates sometimes dwarf some production systems implemented to solve the same problems.
Now, at the beginning, Relational Systems were data-handling "toolkits" set to handle specific subsets of data, who also followed business rules.
That's interesting to my purpose, simply because I can envision, at this time(some vendors have similar concepts, but don't formalize them in any way), a new set of "toolkits" where the relational model is only one of many "toolsets" available.
Indeed, what is probably the most used sql-based server available(MySQL) has been lacking true relational functionality for most of its life, yet that doesn't make the tool less useful for most of its users. Future toolkits can inspire themselves by focusing on specific uses of technology to solve specific problems, and yet keep the SQL as a sort of security blanket, since that's where most of the training about databases(and indeed, usually most of the training about data, period, is in database classes and perhaps, some algorithmics classes)
After reading the linked articles about XML's weaknesses, though, I don't think it belongs into any toolkit of that nature. Simply because the tool that belongs in the toolkit is the "self-documenting data", and XML's weakness in that area is evidenced there. XML's early focus as a medium of e