They want to create the first file-sharing economy of agents, servers, and search engines in which senders and receivers can agree on prices for each transaction and use micropayments to get paid
AMIX (American Information Exchange) was the first "market for paid file sharing" I'm aware of, and I think there have been a few others.
AMIX used a centralized file and transaction server and proprietary software for the clients.
(The latter was an error IMHO. They could have saved a lot of time and money by writing for VT-100-emultaing terminal programs to go cross-platform. Their project started before Mosaic came out, launched and died before commercial use of the Internet, the web, and browsers-as-OS-neutral-platforms rose).
They died for lack of promotion to get a critical mass of merchants and customers involved.
Cube cases (or almost cube) cases aren't really anything new -- many server cases that are cubes have been around for years.
Yes. But...
Cobalt built a cute little cube. Then they trademarked the name "Qube" and had a big advertising campaign.
Apple's box is somewhat similar in appearance. So far no big deal. But...
They mad a big publicity splash, calling it the "Cube". That dilutes Cobalt's trademark.
And of course they did it AFTER they'd (successfully) sued other manufacturers, who had ONLY used colored translucient cases, for trademark infringement against the Imac.
Oops!
I've been wondering why Cobalt hadn't hauled them into court ever since I first heard of Apple's name for their box. Now it looks like it was just a duck-alignment delay.
The FBI knows [shutdowns would get the world to route around the US in the future] too, and even if their Carnivore toys have some builtin facility to shut down the whole trafic this will be used very carefully, and probably not nationwide.
But given that over 70% of the rest of the world's inter-country traffic goes through the US, why should the FBI ever turn the faucet off, and start people re-routing around the US?
Given their intelligence-collection function, it makes more sense for them to tap the communication as it comes through the US.
And that gives them a big incentive to avoid using a shutdown feature even if they have one.
They're also noted for "dirty tricks" tactics, forging communications to disrupt people and groups they don't like. Carnivore would be a great platform for that feature, since it could inject forged traffic in reasonable-looking places, defeating some attempts to detect such forgeries from delivery-path analysis.
And imagine trying to track down a DDS hosted by Carnivore boxes!
Knowing the specific purpose behind the protocol design of the Internet (back when it was ARPANET) -- to withstand bombing of nodes on the network without losing networking ability between the remaining nodes of the network/internet -- you should still be able to send your email with the U.S. ISP's being "off" (after the FBI's 'carnivore' switched us off).
The "work during and after nuclear attack" network functionality no longer exists.
Among the things that took it down:
- The router tables became too large, and other solutions had to be found. They're more tree-like. - Router table update methods were modified to be more robust against deliberate attack - at a cost in automatic flexibility. - The rise of ISPs changed the network topology from a net of co-operating sites with total routing flexibility to a set of leaf sites with single feeds, attached to ISP networks that tend toward inflexible tree structures with limited (if any) routing flexibility, attached to a backbone network.
The point isn't that shutting down anything in the U.S. won't shut down computers in the UK (or anywhere), of course it won't. []the point is really: Are there links around the U.S. lines in case the U.S. shuts down?
The question is more than that.
You need to ask whether there are any network services in the US that are necessary to the operation of the net. For instance: Root servers for the domain naming system that aren't adequately mirrored - or adequately maintainable in the absense of live US-hosted services - outside the country.
You also need to ask whether the routing can automatically recover from the loss of the connections in the US (or can be manually tweaked back into operation in a reasonable time).
The original routing protocols were designed to withstand atomic attack and "find a way" if one existed. But with the expansion of the net the routing tables became too big to store in all the routers, issues of router spoofing attacks came up, and the rise of the ISPs created sections of the net with more tree-like and fixed connectivity. So the Internet is now routed very differently from the original ARPANet, and the original "work during and after a nuclear war" scenarios no longer apply.
Not once have I ever voted for the guy that gets the Democratic/Republican nomination in the primaries, but I've done my part. My signature is on that list, but that doesn't mean that it's all my fault that I haven't given up school and my job to go work for their party. This is like saying it's my fault there's war in the Middle East because I'm not over there trying to stop it.
You have my sympathy. (It's an informed sympathy, too. I've yet to have a presidential candidate that >I worked and/or voted for succeed. And I've been at this since Johnson/Goldwater.)
I wasn't trying to blame you for anything. I just wanted to point out that there are ways to affect what choices are offered on the ballot.
I console myself with this observation: Republics are so stable because they are a good model of how the civil war would come out, so you don't have to fight it. If the bulk of the population who care enough to vote really ARE behind the two big candidates, the little guys' armies wouldn't have stood a chance if it had come to a fight.
Of course they only remain stable while the election IS a good model of the hypothetical civil war. So if there is major systematic election tampering and the population realizes it, you might see things like committees of vigilance or less pleasant unrest.
Meanwhile, the parties don't have a lock. Look at Jessie Ventura for a shining example.
No matter what the results of this case show we have already won. Sure, American developers won't be able to distribute this DVD software, but don't worry about that. In this world are places and countries that are far from the authority of the USA and the MPAA.
We may have won part of the battle - the continued availability of DeCSS.
But by even being sued we're losing another part - the right to exercise our rights without penalty.
Think what a "chilling effect" it is on the exercise of these rights when every programmer who does so finds himself harassed via the legal system.
Yes there are a lot of us. But losing one - or years of his productivity and the bulk of his assets - for every program written that annoys an established interest is not, IMHO, acceptable.
We need to go beyond keeping the software alive out-of-jurisdiction, and beyond even winning this case. We need to get to the point where we, via the very legal system now being used to harass us, can drastically punish the opposing interests for misusing that system in this way.
Bullies won't stop attacking you until attacking you gets them hurt.
Not where I live. You have to have a certain number of signatures to get on the ballot. I literaly don't have any options other than Bush or Gore. There's no one else on the ballot.
You misunderstand my point.
You're starting too late. If you are concerned about this issue, you should already be active long before the ballot finalized.
If you wanted Nader, why weren't you out collecting signatures for the Green party?
Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).
That the formal language you must use to operate the validation program specifies constraints on an algorithm, rather than an algorithm, in no way invalidates my argument.
You might have been on stronger ground had you taken issue with my characterization of writing these constraints as "writing a program". But even there I'd maintain I was correct, because in my opinion the constraints qualify as a "program" for the validator tool.
Validation tools that work from constraints have an input that qualifies as a very "different way to express" the program requirements - one where difficult-to-express-as-algorithms requirements can be concicely and clearly stated, improving the odds for non-overlapping bug sets.
I note that ebay hasn't posted a www.ebay.com/robots.txt file.
Apropos of nothing, but interesting nonetheless.
Since robots.txt expresses the site's intent regarding robotic processing of the site's content, perhaps J. Random Friend of the Court should bring this up with the judge.
Bidder's Edge might bring it up also, if it must defend against claims for damages from their previous work.
I agree completely that, if the courts DO end up creating/recognizing some kind of proprietary right against robotic extraction of site content, assertion of that right should require posting of a standardized, robot-readable "no tresspassing" sign, and the assumption in the absence of the sign should be that the intent was not to assert such a right.
Types are in a class system. You have your most generic polymorphic types and then the set of values can be restricted as much as the programmer needs. I can't explain it exactly, but I think it is this that prevents the need for them weird hacks you described.
Sounds to me like the sort of type safety C++ provides.
Types may be basic, enums, agregates (structs) or classes. Classes can have arbitrary characteristics - including classes that look, act, and are stored like variables of the basic types but with arbitrarily limited ranges. Class types can be arranged in a forest of inheritance trees. Arguments of a type at a particular node in the inheritance tree allow passing of objects of that type or any descended from it. A class can be defined in a way to prevent further subclassing.
Many of these indirect benefits are not actually characteristic of functional languages, but are easily available in imperitive languages. Some examples:
- Concurrency. Writing concurrent programs in a functional language is so much more natural. It's easier to avoid certain kinds of race conditions too, since you don't update variables in a functional language.
OOP does this well, also. There are several approaches. One method is to use "actors" (objects whose instantiation represents a thread of execution, where message-send represents an actual intertask message rather than a function call).
A major part of preventing interthread trouble is to use a style where variables are private, manipulated by accessor functions. Then you can build the concurrency control into either the accessor or the inter-object messaging.
It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful.
Actually, it's been done. A notable example is C++. A problem, though, is that classes and books on C++ tend to put their focus on the wrong parts of the language, neglect to teach the use of types as a means of encoding programmer's intent.
Features of functional languages like garbage collection and non-updatable values make it easier to define a language with a powerful type system.
Non-updatable values ("const") are readily available in C++.
Genaralized garbage collection can be built on top of it with some effort. But the language supports four distinct storage regimes for objects (static, dynamic, member, and heap), rather than a garbage-collector-based language's one.
The politically-correct method for handling heap-allocated objects in C++ is with explicit allocation and freeing, then building (or importing by inheritance) appropriate automation for particular classes' usage patterns as appropriate.
Using garbabe collection as the primary has several problems:
- It leads to a style of constructing composite objects as a web of primitive heap-allocated objects, rather than a single object. This vastly increasing the storage management overhead.
- It has unfortunate interactions with finalization (destruction), a very important semantic construct in C++'s style of OOP.
- Garbage collectors tend to work well only for particular patterns of usage - and are usually optimized for program development. This leads to variable and hard-to-characterize latencies in time-critical production applications. (C++ lets you use GC only on those classes that need it, and to use distinct garbage collection schemes for different objects, according to their needs.)
(What keeps C++ from being a nearly ideal language for practical OOP is an obscure hole in the standard: The deliberate, explicit failure to specify which overriding of a virtual member function is invoked if one is called during construction/destruction of member variables of object type. It SHOULD be the derived class' version from the first executable statement of the constructor to the last of the destructor, and base class' version otherwise.)
- Machine independence. Making a type system usually means hiding away the details of the machine, and this usually means that the execution of your program is completely predictable. (Compare to C/C++ "undefined" behavior!)
This is the result of C++ inheritance of C's ambiguous primitive data types. The standard workaround (also available in C) is to construct a small, machine dependent include file that defines a set of unambiguous types (i.e. int_16, uint_32), then use THOSE instead of the primitives elsewhere in the code.
Signature Ascription - This allows you to define abstract data types by naming a type and some operations on it (and their types). This is similar to header files in C (much more refined), but thanks to the type system, you can guarantee that the user can ONLY use your abstract data type the way you intended. They cannot cast, subclass, or use any other tricks to get at your datatype.
For defining abstract interfaces: Abstract base classes. (One or more member functions are not defined until the concrete subclass.)
To protect the guts from tampering: private member variables and private functions.
Yes, you can get around the protection. C++ explicitly gives you enough rope to hang yourself. But you have to express your INTENT to violate the protection by a particular set of casts, or you end up buried in warning messages and NOT trashing the variable.
I have to take a position distinct from both of those above.
[] once your programs typecheck, they Just Work
This is a myth.
I agree with the second poster on this point. But...
[the errors] that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.
Strong type checking in imperitive languages (particularly OO langues such as C++, but to a lesser extent non-OO languages such as ANSI C) is often criticized as being too restrictive and too complex. But in my direct experience, complaints that type-checking was too restrictive or onerous were mostly made by software "cowboys", whose code tended to be horribly bug-ridden. (I trust the second poster doesn't fall into that category.)
What strong type checking does is provide toolset support for catching design and implementation errors characterized by mismatched interfaces. When combined with a good OOP-style type declaration system you can express your intent clearly to the compiler - and to yourself and the other members of the project. The key to making it your friend is to understand it and use it in that way: Take a few moments to express the intended uses of your variables via types.
Mismatched operands are a symptom of lack of clarity of thought about what is going on at the interface. That lack of clarity leads to much more subtle bugs than just exchanging operands - bugs you can hunt for for days if they're not pointed out, but which jump out at you as soon as a compiler complains.
A good type system, properly used, doesn't normally get in your way. And in those rare cases where it does some languages (such as C++) give you a mechanism (such as cast to void or pointer-to-void, recast to alternative type) to explicitly override it, while expressing your intent to do so.
While my experience is primarily with imperitive languages, I suspect the same is true of functional languages - providing the type safety doesn't get in the way of code reuse (as it did to a small extent in C++ before templates, though this could be easily worked around with macros).
you might want to try ML, since it's the only language I know of which lets you declare your own infix operators. (C++ only lets you overload, not declare new ones)
I maintain that a correctness proof of a program - in the ordinary meaning of the words - is not possible. Consider:
What behavior is "correct" depends on the job to be done. (For instance: A perfectly correct implementation of "grep" is utterly broken if what you wanted was an implementation of "finger" or "gcc".)
Assume you had a perfect formal correctness proving tool or methodology. You must specify what it means for the program to be correct, in a formal language accessable to the tool/methodology.
This is exactly the process of writing a program. Did you write that program correctly? Prove it!
This is NOT to say that what are called "formal correctness proofs", or "correctness-proving tools", are useless. Quite the contrary - they're extremely valuable. They're just misnamed.
What these tools do is automate the comparison of two distinct descriptions of a portion (possibly all) of a design's behavior.
This is very important, because the only effective ways known to find and eliminate the bugs in a design amount to expressing it twice, in distinct forms that use distinct modes of thinking, and compare the two.
In the classic "manual" (though often machine assisted) approach to software development, the two expressions are the canonical specification documentation (the "spec" or "bible") and the source code. The spec is optimized for human readability, while the source code is optimized for processing by compilation tools.
In a large project they will be written by different people. In a small project the differences in language tends to create enough of a different mindset in a single person that they tend toward non-overlapping bug sets. In a very small project the "spec" may be the program comments. A good programmer comments well, not just to make things clear to others later, or to keep them clear to himself later, but to deliberately create this second mindset, reducing the chance for undiscovered bugs.
The source code does NOT strictly fall out of the spec. Instead the two co-evolve as the project procedes. The debugging/QA/verification process detects "bugs" which are defined as differences between the spec (or its non-canonical derivitaves) and the executable derived from the source code. The bugs are fixed either in the source code or the spec. A spec bug may be an ambiguity, an internal inconsistency, an ommission (including deliberate ommissions to allow flexibility to implementors, later filled in with the choice made), an error deriving non-canonical documents (such as comments or user documentation) from the spec, a misfeature, missing feature, unnecessary/difficult feature, or an adequate design choice that is later replaced by something considerably better discovered during implementation. A source bug is any program behavior that doesn't match the spec in a way that doesn't expose a spec bug.
What the so-called formal correctness proof tools can do is automate various aspects of the comparison. Once properly configured they can do, with machine-level reliability and speed, many of the same things that software QA people do. (For instance: Identify "edge" and "corner cases", determine that the behivor is right at and near the edge/corner, and generate inductive proofs that the behavior will be correct throughout the parameter ranges.) And once the tools themselves are debugged, they can do more of it, with less chance of error, than can be done by human effort. This also allows them to perform classes of testing that would be impractical without them, because of the manpower and time costs, because the complexity of the test would lead to errors and thus to missed bugs and bogus bug reports, or because they perform a class of test that is just not a good fit for a human mind.
Finally, formal tools provide additional specification languages, distinct from the implementation language, leading both to clarity of thought and a distinct mindset in the creation of the second expression of the program's behavior, and thus to less overlap of the bug set in the two expressions.
It was found. But the new twenty character nickname/handle limit was permanent. So they'd have had to cut off something else to have it reattached.
One of the big names (I think it was Cmdr Taco, but I'm not sure, and don't have the old email handy) volunteered to perform the operation. But given that the default credit line comes out:
by Ungrounded Lightning (rod@node.com)
and given that I couldn't figure out a 20-character nickname that worked as well and would still be easily recognizable to people used to the old nick, I decided to decline the surgery.
By the way: The handle is a reference to an incident at a former employer - one noted for promoting open access to computer networks and electronic publishing - and also for being somewhat far out. Netnews had just been installed, and he was asked whether there were any posting limits (besides not disclosing company secrets). He said that as a matter of policy they weren't, but he'd prefer that we avoided jepoardizing the company's already-strained credibility by making far-out posts on unrelated matters as someone recognizably employed by the company. He referred to this as "being a lightning rod".
So I created a "guest account" for myself for participating in certain controversial newsgroups, and from that account never posted about who I actually was or whether I was an employee or a friend-of-the-company. (The company also had a history of handing out guest accounts to controversial figures who were friends of project members or had done something to support the project in its early days.)
Even the injunction wouldn't be able to keep MAPS from publishing their address in a way that is NOT automated.
If MAPS had put them in the RBL, they could get things working again within hours after cleaning up their act. If thousands of individual sysadmins start adding them to their sites' individual black hole lists, it's likely they'll NEVER get their domain's mail working right again.
I think that even if the suit succeeds they're dead meat - as is any other domain operator that uses the legal system to block MAPS from black-holeing them.
God, I don't need internet censors deciding what I can and cannot see.
So open an SMTP port on your machine, publish an MX record pointing to it, and don't filter the mail with the MAPS list.
I don't believe that ISP's should turn to censoring their client's mail.
Isn't that a matter for the ISP and the client to agree on by contract? Isn't it the client's right to switch to a different ISP if he doesn't like the way the service is handled?
Why should ISPs be constrained to filter or non-filter mail according to YOUR preferences, rather than that of their clients?
And if all you're asking for is a signup option, why don't you try asking an ISP for it? If enough people ask for an option to have their mail unfiltered, I'm sure some ISPs will be willing to provide it.
Perhaps at an extra charge, to cover all the extra processing. B-)
But somehow I doubt that there's all that much demand for this "service".
Meanwhile, you can always sign up with an ISP that gives you a fixed IP address and a nameservice, open an unfiltered SMTP port, post an MX record pointing to it, and get all the spam you want.
Post a few netnews articles to get your ID on a few spammer lists, while you're at it. It might change your mind.
What gives you (or anybody else for that matter) to decide what mail should or should not be allowed?
You misunderstand, or misrepresent, what is going on.
A lot of people don't want to receive unsolicited commercial eamil. And a lot of ISPs and business sites don't want their resources used to forward it, or their employees distracted from doing work while deleting it.
MAPS publishes a list of sources of unsolicited email. ISPs, businesses, and individual users may chose to use this list to filter out mail they don't want to bother to read or forward.
Use of the list is strictly voluntary.
Having your email forwarded, on the other hand, is not a right. It is a voluntary service of whomever forwards it. If a site does not wish to forward unsolicited commercial email - or any other email - originating from you, that's that site's prerogative.
so far, we've no evidence that the system is a) always-on, and b) indiscriminate.
So far we also have no evidence that the system is NOT always-on and NOT indiscriminate.
"Innocent until proven guilty" applies to those that the government accuses. The government itself is a separate category, and the functionaries of governments (both the US and others) have a long track record of improper actions.
Government is granted extraordinary power. Strict scrutiny of government operations by the citizens is both proper and necessary to keep the government from exceeding both its own rules and its mandate.
Slashdot Mirror
They want to create the first file-sharing economy of agents, servers, and search engines in which senders and receivers can agree on prices for each transaction and use micropayments to get paid
AMIX (American Information Exchange) was the first "market for paid file sharing" I'm aware of, and I think there have been a few others.
AMIX used a centralized file and transaction server and proprietary software for the clients.
(The latter was an error IMHO. They could have saved a lot of time and money by writing for VT-100-emultaing terminal programs to go cross-platform. Their project started before Mosaic came out, launched and died before commercial use of the Internet, the web, and browsers-as-OS-neutral-platforms rose).
They died for lack of promotion to get a critical mass of merchants and customers involved.
I see no mention of a camera in the device, nor the word "cam" in their product literature. So why is it labeled a "cam" in the Slashdot article?
Cube cases (or almost cube) cases aren't really anything new -- many server cases that are cubes have been around for years.
Yes. But...
Cobalt built a cute little cube. Then they trademarked the name "Qube" and had a big advertising campaign.
Apple's box is somewhat similar in appearance. So far no big deal. But...
They mad a big publicity splash, calling it the "Cube". That dilutes Cobalt's trademark.
And of course they did it AFTER they'd (successfully) sued other manufacturers, who had ONLY used colored translucient cases, for trademark infringement against the Imac.
Oops!
I've been wondering why Cobalt hadn't hauled them into court ever since I first heard of Apple's name for their box. Now it looks like it was just a duck-alignment delay.
The FBI knows [shutdowns would get the world to route around the US in the future] too, and even if their Carnivore toys have some builtin facility to shut down the whole trafic this will be used very carefully, and probably not nationwide.
But given that over 70% of the rest of the world's inter-country traffic goes through the US, why should the FBI ever turn the faucet off, and start people re-routing around the US?
Given their intelligence-collection function, it makes more sense for them to tap the communication as it comes through the US.
And that gives them a big incentive to avoid using a shutdown feature even if they have one.
They're also noted for "dirty tricks" tactics, forging communications to disrupt people and groups they don't like. Carnivore would be a great platform for that feature, since it could inject forged traffic in reasonable-looking places, defeating some attempts to detect such forgeries from delivery-path analysis.
And imagine trying to track down a DDS hosted by Carnivore boxes!
Knowing the specific purpose behind the protocol design of the Internet (back when it was ARPANET) -- to withstand bombing of nodes on the network without losing networking ability between the remaining nodes of the network/internet -- you should still be able to send your email with the U.S. ISP's being "off" (after the FBI's 'carnivore' switched us off).
The "work during and after nuclear attack" network functionality no longer exists.
Among the things that took it down:
- The router tables became too large, and other solutions had to be found. They're more tree-like.
- Router table update methods were modified to be more robust against deliberate attack - at a cost in automatic flexibility.
- The rise of ISPs changed the network topology from a net of co-operating sites with total routing flexibility to a set of leaf sites with single feeds, attached to ISP networks that tend toward inflexible tree structures with limited (if any) routing flexibility, attached to a backbone network.
The point isn't that shutting down anything in the U.S. won't shut down computers in the UK (or anywhere), of course it won't. []the point is really: Are there links around the U.S. lines in case the U.S. shuts down?
The question is more than that.
You need to ask whether there are any network services in the US that are necessary to the operation of the net. For instance: Root servers for the domain naming system that aren't adequately mirrored - or adequately maintainable in the absense of live US-hosted services - outside the country.
You also need to ask whether the routing can automatically recover from the loss of the connections in the US (or can be manually tweaked back into operation in a reasonable time).
The original routing protocols were designed to withstand atomic attack and "find a way" if one existed. But with the expansion of the net the routing tables became too big to store in all the routers, issues of router spoofing attacks came up, and the rise of the ISPs created sections of the net with more tree-like and fixed connectivity. So the Internet is now routed very differently from the original ARPANet, and the original "work during and after a nuclear war" scenarios no longer apply.
I find this amusing because these are Microsoft's tactics.
So why should Micro$oft have a monopoly on them?
Not once have I ever voted for the
guy that gets the Democratic/Republican nomination in the primaries, but I've done my part. My signature is on that list, but that doesn't mean that it's all my fault that I haven't given up school and my job to go work for their party. This is like saying it's my fault there's war in the Middle East because I'm not over there trying to stop it.
You have my sympathy. (It's an informed sympathy, too. I've yet to have a presidential candidate that >I worked and/or voted for succeed. And I've been at this since Johnson/Goldwater.)
I wasn't trying to blame you for anything. I just wanted to point out that there are ways to affect what choices are offered on the ballot.
I console myself with this observation: Republics are so stable because they are a good model of how the civil war would come out, so you don't have to fight it. If the bulk of the population who care enough to vote really ARE behind the two big candidates, the little guys' armies wouldn't have stood a chance if it had come to a fight.
Of course they only remain stable while the election IS a good model of the hypothetical civil war. So if there is major systematic election tampering and the population realizes it, you might see things like committees of vigilance or less pleasant unrest.
Meanwhile, the parties don't have a lock. Look at Jessie Ventura for a shining example.
No matter what the results of this case show we have already won. Sure, American developers won't be able to distribute this DVD software, but don't worry about that. In this world are places and countries that are far from the authority of the USA and the MPAA.
We may have won part of the battle - the continued availability of DeCSS.
But by even being sued we're losing another part - the right to exercise our rights without penalty.
Think what a "chilling effect" it is on the exercise of these rights when every programmer who does so finds himself harassed via the legal system.
Yes there are a lot of us. But losing one - or years of his productivity and the bulk of his assets - for every program written that annoys an established interest is not, IMHO, acceptable.
We need to go beyond keeping the software alive out-of-jurisdiction, and beyond even winning this case. We need to get to the point where we, via the very legal system now being used to harass us, can drastically punish the opposing interests for misusing that system in this way.
Bullies won't stop attacking you until attacking you gets them hurt.
Not where I live. You have to have a certain number of signatures to get on the ballot. I literaly don't have any options other than Bush or Gore. There's no one else on the ballot.
You misunderstand my point.
You're starting too late. If you are concerned about this issue, you should already be active long before the ballot finalized.
If you wanted Nader, why weren't you out collecting signatures for the Green party?
Meanwhile, write him in.
Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).
That the formal language you must use to operate the validation program specifies constraints on an algorithm, rather than an algorithm, in no way invalidates my argument.
You might have been on stronger ground had you taken issue with my characterization of writing these constraints as "writing a program". But even there I'd maintain I was correct, because in my opinion the constraints qualify as a "program" for the validator tool.
Validation tools that work from constraints have an input that qualifies as a very "different way to express" the program requirements - one where difficult-to-express-as-algorithms requirements can be concicely and clearly stated, improving the odds for non-overlapping bug sets.
It does have one - http://cgi.ebay.com/robots.txt
And (as another poster pointed out) others on search.ebay.com and listings.ebay.com.
Guess I should have looked more deeply. Thanks for the correction.
I note that ebay hasn't posted a www.ebay.com/robots.txt file.
Apropos of nothing, but interesting nonetheless.
Since robots.txt expresses the site's intent regarding robotic processing of the site's content, perhaps J. Random Friend of the Court should bring this up with the judge.
Bidder's Edge might bring it up also, if it must defend against claims for damages from their previous work.
I agree completely that, if the courts DO end up creating/recognizing some kind of proprietary right against robotic extraction of site content, assertion of that right should require posting of a standardized, robot-readable "no tresspassing" sign, and the assumption in the absence of the sign should be that the intent was not to assert such a right.
Types are in a class system. You have your most generic polymorphic types and then the set of values can be restricted as much as the programmer needs. I can't explain it exactly, but I think it is this that prevents the need for them weird hacks you described.
Sounds to me like the sort of type safety C++ provides.
Types may be basic, enums, agregates (structs) or classes. Classes can have arbitrary characteristics - including classes that look, act, and are stored like variables of the basic types but with arbitrarily limited ranges. Class types can be arranged in a forest of inheritance trees. Arguments of a type at a particular node in the inheritance tree allow passing of objects of that type or any descended from it. A class can be defined in a way to prevent further subclassing.
Sound like the same sort of thing to you?
Many of these indirect benefits are not actually characteristic of functional languages, but are easily available in imperitive languages. Some examples:
- Concurrency. Writing concurrent programs in a functional language is so much more natural. It's easier to avoid certain kinds of race conditions too, since you don't update variables in a functional language.
OOP does this well, also. There are several approaches. One method is to use "actors" (objects whose instantiation represents a thread of execution, where message-send represents an actual intertask message rather than a function call).
A major part of preventing interthread trouble is to use a style where variables are private, manipulated by accessor functions. Then you can build the concurrency control into either the accessor or the inter-object messaging.
It's difficult to design a language (and many smart people have tried) that's imperative, type safe, and powerful.
Actually, it's been done. A notable example is C++. A problem, though, is that classes and books on C++ tend to put their focus on the wrong parts of the language, neglect to teach the use of types as a means of encoding programmer's intent.
Features of functional languages like garbage collection and non-updatable values make it easier to define a language with a powerful type system.
Non-updatable values ("const") are readily available in C++.
Genaralized garbage collection can be built on top of it with some effort. But the language supports four distinct storage regimes for objects (static, dynamic, member, and heap), rather than a garbage-collector-based language's one.
The politically-correct method for handling heap-allocated objects in C++ is with explicit allocation and freeing, then building (or importing by inheritance) appropriate automation for particular classes' usage patterns as appropriate.
Using garbabe collection as the primary has several problems:
- It leads to a style of constructing composite objects as a web of primitive heap-allocated objects, rather than a single object. This vastly increasing the storage management overhead.
- It has unfortunate interactions with finalization (destruction), a very important semantic construct in C++'s style of OOP.
- Garbage collectors tend to work well only for particular patterns of usage - and are usually optimized for program development. This leads to variable and hard-to-characterize latencies in time-critical production applications. (C++ lets you use GC only on those classes that need it, and to use distinct garbage collection schemes for different objects, according to their needs.)
(What keeps C++ from being a nearly ideal language for practical OOP is an obscure hole in the standard: The deliberate, explicit failure to specify which overriding of a virtual member function is invoked if one is called during construction/destruction of member variables of object type. It SHOULD be the derived class' version from the first executable statement of the constructor to the last of the destructor, and base class' version otherwise.)
- Machine independence. Making a type system usually means hiding away the details of the machine, and this usually means that the execution of your program is completely predictable. (Compare to C/C++ "undefined" behavior!)
This is the result of C++ inheritance of C's ambiguous primitive data types. The standard workaround (also available in C) is to construct a small, machine dependent include file that defines a set of unambiguous types (i.e. int_16, uint_32), then use THOSE instead of the primitives elsewhere in the code.
Signature Ascription - This allows you to define abstract data types by naming a type and some operations on it (and their types). This is similar to header files in C (much more refined), but thanks to the type system, you can guarantee that the user can ONLY use your abstract data type the way you intended. They cannot cast, subclass, or use any other tricks to get at your datatype.
For defining abstract interfaces: Abstract base classes. (One or more member functions are not defined until the concrete subclass.)
To protect the guts from tampering: private member variables and private functions.
Yes, you can get around the protection. C++ explicitly gives you enough rope to hang yourself. But you have to express your INTENT to violate the protection by a particular set of casts, or you end up buried in warning messages and NOT trashing the variable.
I have to take a position distinct from both of those above.
[] once your programs typecheck, they Just Work
This is a myth.
I agree with the second poster on this point. But...
[the errors] that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.
Strong type checking in imperitive languages (particularly OO langues such as C++, but to a lesser extent non-OO languages such as ANSI C) is often criticized as being too restrictive and too complex. But in my direct experience, complaints that type-checking was too restrictive or onerous were mostly made by software "cowboys", whose code tended to be horribly bug-ridden. (I trust the second poster doesn't fall into that category.)
What strong type checking does is provide toolset support for catching design and implementation errors characterized by mismatched interfaces. When combined with a good OOP-style type declaration system you can express your intent clearly to the compiler - and to yourself and the other members of the project. The key to making it your friend is to understand it and use it in that way: Take a few moments to express the intended uses of your variables via types.
Mismatched operands are a symptom of lack of clarity of thought about what is going on at the interface. That lack of clarity leads to much more subtle bugs than just exchanging operands - bugs you can hunt for for days if they're not pointed out, but which jump out at you as soon as a compiler complains.
A good type system, properly used, doesn't normally get in your way. And in those rare cases where it does some languages (such as C++) give you a mechanism (such as cast to void or pointer-to-void, recast to alternative type) to explicitly override it, while expressing your intent to do so.
While my experience is primarily with imperitive languages, I suspect the same is true of functional languages - providing the type safety doesn't get in the way of code reuse (as it did to a small extent in C++ before templates, though this could be easily worked around with macros).
you might want to try ML, since it's the only language I know of which lets you declare your own infix operators. (C++ only lets you overload, not declare new ones)
I mourn the death of "MAD".
I maintain that a correctness proof of a program - in the ordinary meaning of the words - is not possible. Consider:
What behavior is "correct" depends on the job to be done. (For instance: A perfectly correct implementation of "grep" is utterly broken if what you wanted was an implementation of "finger" or "gcc".)
Assume you had a perfect formal correctness proving tool or methodology. You must specify what it means for the program to be correct, in a formal language accessable to the tool/methodology.
This is exactly the process of writing a program. Did you write that program correctly? Prove it!
This is NOT to say that what are called "formal correctness proofs", or "correctness-proving tools", are useless. Quite the contrary - they're extremely valuable. They're just misnamed.
What these tools do is automate the comparison of two distinct descriptions of a portion (possibly all) of a design's behavior.
This is very important, because the only effective ways known to find and eliminate the bugs in a design amount to expressing it twice, in distinct forms that use distinct modes of thinking, and compare the two.
In the classic "manual" (though often machine assisted) approach to software development, the two expressions are the canonical specification documentation (the "spec" or "bible") and the source code. The spec is optimized for human readability, while the source code is optimized for processing by compilation tools.
In a large project they will be written by different people. In a small project the differences in language tends to create enough of a different mindset in a single person that they tend toward non-overlapping bug sets. In a very small project the "spec" may be the program comments. A good programmer comments well, not just to make things clear to others later, or to keep them clear to himself later, but to deliberately create this second mindset, reducing the chance for undiscovered bugs.
The source code does NOT strictly fall out of the spec. Instead the two co-evolve as the project procedes. The debugging/QA/verification process detects "bugs" which are defined as differences between the spec (or its non-canonical derivitaves) and the executable derived from the source code. The bugs are fixed either in the source code or the spec. A spec bug may be an ambiguity, an internal inconsistency, an ommission (including deliberate ommissions to allow flexibility to implementors, later filled in with the choice made), an error deriving non-canonical documents (such as comments or user documentation) from the spec, a misfeature, missing feature, unnecessary/difficult feature, or an adequate design choice that is later replaced by something considerably better discovered during implementation. A source bug is any program behavior that doesn't match the spec in a way that doesn't expose a spec bug.
What the so-called formal correctness proof tools can do is automate various aspects of the comparison. Once properly configured they can do, with machine-level reliability and speed, many of the same things that software QA people do. (For instance: Identify "edge" and "corner cases", determine that the behivor is right at and near the edge/corner, and generate inductive proofs that the behavior will be correct throughout the parameter ranges.) And once the tools themselves are debugged, they can do more of it, with less chance of error, than can be done by human effort. This also allows them to perform classes of testing that would be impractical without them, because of the manpower and time costs, because the complexity of the test would lead to errors and thus to missed bugs and bogus bug reports, or because they perform a class of test that is just not a good fit for a human mind.
Finally, formal tools provide additional specification languages, distinct from the implementation language, leading both to clarity of thought and a distinct mindset in the creation of the second expression of the program's behavior, and thus to less overlap of the bug set in the two expressions.
It was found. But the new twenty character nickname/handle limit was permanent. So they'd have had to cut off something else to have it reattached.
One of the big names (I think it was Cmdr Taco, but I'm not sure, and don't have the old email handy) volunteered to perform the operation. But given that the default credit line comes out:
by Ungrounded Lightning (rod@node.com)
and given that I couldn't figure out a 20-character nickname that worked as well and would still be easily recognizable to people used to the old nick, I decided to decline the surgery.
By the way: The handle is a reference to an incident at a former employer - one noted for promoting open access to computer networks and electronic publishing - and also for being somewhat far out. Netnews had just been installed, and he was asked whether there were any posting limits (besides not disclosing company secrets). He said that as a matter of policy they weren't, but he'd prefer that we avoided jepoardizing the company's already-strained credibility by making far-out posts on unrelated matters as someone recognizably employed by the company. He referred to this as "being a lightning rod".
So I created a "guest account" for myself for participating in certain controversial newsgroups, and from that account never posted about who I actually was or whether I was an employee or a friend-of-the-company. (The company also had a history of handing out guest accounts to controversial figures who were friends of project members or had done something to support the project in its early days.)
The earth was due to be hit with a mag storm from a solar flare. Such things can be a problem for data networks.
I noticed that, even now (6:20 AM EST) the main page isn't updating with the number of comments.
Even the injunction wouldn't be able to keep MAPS from publishing their address in a way that is NOT automated.
If MAPS had put them in the RBL, they could get things working again within hours after cleaning up their act. If thousands of individual sysadmins start adding them to their sites' individual black hole lists, it's likely they'll NEVER get their domain's mail working right again.
I think that even if the suit succeeds they're dead meat - as is any other domain operator that uses the legal system to block MAPS from black-holeing them.
You need to take your troll detector in for a checkup. If the last sentance of his post didn't tip you off, I'm amazed you can operate a keyboard.
One of the forms of hacker humor is to respond literally to a totally outrageous statement or question.
B-)
God, I don't need internet censors deciding what I can and cannot see.
So open an SMTP port on your machine, publish an MX record pointing to it, and don't filter the mail with the MAPS list.
I don't believe that ISP's should turn to censoring their client's mail.
Isn't that a matter for the ISP and the client to agree on by contract? Isn't it the client's right to switch to a different ISP if he doesn't like the way the service is handled?
Why should ISPs be constrained to filter or non-filter mail according to YOUR preferences, rather than that of their clients?
And if all you're asking for is a signup option, why don't you try asking an ISP for it? If enough people ask for an option to have their mail unfiltered, I'm sure some ISPs will be willing to provide it.
Perhaps at an extra charge, to cover all the extra processing. B-)
But somehow I doubt that there's all that much demand for this "service".
Meanwhile, you can always sign up with an ISP that gives you a fixed IP address and a nameservice, open an unfiltered SMTP port, post an MX record pointing to it, and get all the spam you want.
Post a few netnews articles to get your ID on a few spammer lists, while you're at it. It might change your mind.
What gives you (or anybody else for that matter) to decide what mail should or should not be allowed?
You misunderstand, or misrepresent, what is going on.
A lot of people don't want to receive unsolicited commercial eamil. And a lot of ISPs and business sites don't want their resources used to forward it, or their employees distracted from doing work while deleting it.
MAPS publishes a list of sources of unsolicited email. ISPs, businesses, and individual users may chose to use this list to filter out mail they don't want to bother to read or forward.
Use of the list is strictly voluntary.
Having your email forwarded, on the other hand, is not a right. It is a voluntary service of whomever forwards it. If a site does not wish to forward unsolicited commercial email - or any other email - originating from you, that's that site's prerogative.
so far, we've no evidence that the system is a) always-on, and b) indiscriminate.
So far we also have no evidence that the system is NOT always-on and NOT indiscriminate.
"Innocent until proven guilty" applies to those that the government accuses. The government itself is a separate category, and the functionaries of governments (both the US and others) have a long track record of improper actions.
Government is granted extraordinary power. Strict scrutiny of government operations by the citizens is both proper and necessary to keep the government from exceeding both its own rules and its mandate.