This won't have a "chilling effect" on Internet communications because any publically available Internet publication is not private communication, but a public medium.
If I print a statement of my opinion about you on my personal Web site, operated on my own host, on the end of an Internet connection I pay for, you have no right to demand that I incur similar expenses to carry your opinion of my opinion. It doesn't matter how popular my site is, or whether you think of it as a "blog" or a "news medium" or what-have-you: the fact that I spend money to promulgate my opinion in no wise obligates me to spend money to promulgate yours.
To propose the contrary is indeed chilling -- because it means that if I post something you object to, you have the right to impose costs upon me. It means that unless I am able to bear the costs of printing both my own opinion and the opinions of everyone who disagrees with me, I cannot print my own opinion. It also means that if I am unable to countenance spending money to print the opinion of any particular objector -- for instance because said objector's views are vile and repugnant to me -- that I may not print my own.
Such a "right of reply" may be survivable by "big media" organizations which do not really have any views of their own. It would be, however, fatal to the "small media" organizations -- individual, idiosyncratic, and opinionated, devoted to exposing those sides of stories that do not get mainstream coverage -- that the Web in particular permits to thrive.
Re:The only real argument I see is...
on
A Mighty Wind
·
· Score: 1
There's another great example discussing a local oil tanker that leaked oil into the sound. It basically did far more damage than any wind farm could ever do.
Actually, the old, single-hulled tanker leaked oil into Buzzards Bay, not Nantucket Sound. It came damned near to washing up on the beach a block from my house, so I'm more than a little irritated at the irresponsibility of the oil shipping industry -- and I'm all for the wind farm.
I am mostly very libertarian in my political views. However, when it comes to energy or transportation policy, I find that it is ironic for ostensible free-marketers to object to government subsidies of low-pollution technology such as railroads or wind power... since the government already heavily subsidizes the high-pollution technologies such as highways and fossil-fuel power.
Every penny a government uses to build highways is a subsidy to the automobile and trucking systems and thus to oil fascism. In light of this, free-marketers have no business objecting to the funding of Amtrak, rail shipping, or the like -- which do a lot less harm to the populace. Better, perhaps, to not subsidize anyone -- without someone else paying to maintain highways at above a level the market would naturally sustain, you'll damned well take the train! But if you have to subsidize SUV shite (who bend our nation over for the pseudo-Islamic fascists in Saudi Arabia) by building roads for them at everyone else's expense, damned better have some balance for the rails.
End of rant. That said, though, I'm pro-nuclear as well as pro-wind-power... simply because nuke plants produce less radioactive pollution than coal plants; and if you build 'em such that the design criteria are power production and safety rather than conversion to weapons production, they don't melt down. (Google for "pebble bed reactors".)
Re:Clarification on the enzyme issue.
on
Steal This Idea
·
· Score: 3, Insightful
Who cares if it was fundemental. They researched it, found it, and claimed "FIRST POST!^H^H^H^H^HPATENT!" It's their right to get a patent for their work.
And here we have an elegant example of the logical fallacy known as "begging the question"; that is, assuming for your argument the very conclusion which is under contention: whether or not there is, or should be, a right to exclude others from a discovery in fundamental science, simply because one manages to file it first.
(It is the claim of the U.S. Constitution, for instance, that patent and copyright are not natural rights akin to life, liberty, and property: they are, rather, privileges created by Congress for a purpose. They rest on a consequentialist ethical system rather than a natural-law one: specifically, they exist to promote progress in the sciences and useful arts. If they fail to meet that purpose, then they fail to be justified.)
There has been no evidence cited that the consequentialist argument defends the extremity of patent (and copyright) that is presently enforced. Pursuers of greater copyright restrictions, and pursuers of vague and obvious patents, both assert that artists and researchers would have greater incentive to create and discover, if their works received greater monopoly protection.
However, this is a bare assertion without any evidence for it; a statement of faith and not of reason. It should not motivate the restriction of the public by further onerous laws. In the absence of evidence for the claim that a restrictive law would further the public good, a free nation should err on the side of preserving liberty and not on the side of extending further monopolies for the already-privileged.
My job includes being the computer security guru for my workplace. In that role, it's my job to understand the way my clients' systems work, so that I can recommend effective operational ways to improve their security. It's also my job to understand the world of attacks -- not just keeping my ear to the ground regarding what kind of shit is going down at the moment, but understanding what attacks are possible, which are likely, and which are worthy of taking special defensive measures.
I recommend strongly that anyone in a role like mine take some time to study viruses, exploits, rootkits, and other pieces of hostile code. These are a basic part of the security environment in the field. The more you understand the crap that the Net's rejects and crackheads are throwing at you, the better a job you can do.
Here's just one example of what we can learn from viruses; a bit of an older example, so I'm not doing too much of your work for you:
Let's say your client is considering a bonehead move -- like, say, deploying Microsoft Outlook enterprise-wide. Any security nerd can say "duh, Outlook sux0r, it's full of vulnerabilities, that's why it spreads viruses." However, if you have read the source code of the LoveLetter and Melissa viruses, you will realize (and can explain to your client) that these viruses do not exploit vulnerabilities at all -- at least, not in the sense of buffer overflows and other attacks which target bugs in software. These viruses don't crack anything -- they use perfectly ordinary, documented API calls. It isn't holes in the Windows Mail API that make it a virus breeding ground -- it's just its built-in, designed, intended functionality. That's why these viruses can still spread after years of bug fixes: their critical paths do not rely on bugs at all.
What do we learn from these viruses? Security is not about patching bugs, or having bug-free software. It is about correctly modeling the trust relationships people have with each other regarding their computer resources, in software. The Windows MAPI's design implies an assumption that people want to entrust word-processing documents with the power to send hundreds of emails. That's obviously wrong -- and that, not any bug, is what must be explained to convince someone that Microsoft's mail software is a bad security choice.
There are many more lessons to be learned by understanding hostile code. There are lessons about user interface design: many email viruses depend on getting the user to take some action (opening a message, running a macro, etc.) which unintentionally grants the virus trust and privilege (even the privilege to run code) that it should not have. To design secure systems for users, we must have user interfaces which do not promote such deception. There are lessons about system monitoring and the habits of sysadmins: Unix rootkits, which alter the system to conceal the tracks of an attacker, show just how easily a too-shallow maintenance or log-checking routine can be deceived. There are many lessons.
Get yourself some virus source code. Google will help. Read rootkit code, and the analyses thereof which researchers on SecurityFocus and other sites have published. Understand these attacks, and you will understand the systems they target better than you do now.
It seems to me that security efforts have focused too strongly on detecting and blocking known categories of attacks, rather than on creating systems which are secure against innovative future attacks. There are projects for which this isn't the case, such as OpenSSH (and OpenBSD in general), but the preponderance of security work seems to be profoundly backward-looking.
Naturally, fighting in the dirt with the black hats is a lot "sexier" and more entertaining than building highly robust and reliable systems which will guarantee future security. The popularity of honeypots with security hobbyists (as opposed to researchers) seems to be a result of this: people enjoy seeing the attacker flummoxed, feeling superior to him, defeating him. Yet this doesn't really result in the improvement of security against new attacks, and it arguably distracts from that purpose.
I'm interested to know where you see progress in security assurance, as opposed to scanning or blocking of old, known attacks. Who else, besides OpenBSD, is in the camp of improving the guarantees that systems provide their users: guarantees such as W^X, packet normalization, and so forth?
Trivial passwords should fall into the same category - you can't be bothered to take care of your data/services, you can't bitch when someone else reads it/uses them.
Trivial doors should fall into the same category -- if you can't be bothered to lock all your TV set and fancy gaming computer in a steel safe every time you go out, you shouldn't bitch when someone else takes them. Uh-huh.
See the problem? People have expectations of privacy that go beyond the physical mechanisms they have in place to forcibly keep others off their land or out of their houses. That is why we have trespassing and theft laws at all, instead of just leaving everyone putting up solid steel fences and arming themselves to the teeth. We believe in the rule of law -- not the rule of the highest fence and the biggest cannon.
The same needs to apply to the Net. People should take precautions with their systems just as they lock their doors and cars. However, when those precautions or locks are violated by someone with ill intent, that is a crime and must be treated as such. Though both the user with bad passwords and the guy who leaves his door unlocked are fools, it remains illegal to steal from fools.
Of course it's authorized. Your browser preferences allow pop-up to be displayed, or you'd never see them.
That isn't at all an "of course" issue. If I place an unpatched default installation of Red Hat 6.2 on an Internet-connected host, my "preferences" (read: installed software) by default allow remote users to obtain root access. No matter how stupid or negligent I would be to do so, I would still expect that for someone to take advantage of those "preferences" to r00t the b0x0r would indeed be illegal. Similarly, just because Jane Winecooler's browser by default allows the installation of spyware and the forced display of popup spam, does not authorize anyone to set up booby-trapped Web sites which do such things to her browser.
The idea that any access that my host does not block is by default an authorized access is compelling to the hacker (in the old sense) since it means that everything one can do, one may do, provided it is not obviously harmful. Under this construction, if you leave your box r00table, then I may r00t it -- but I may not (for instance) delete your files or use your host to DoS someone. However, I do not think this is a solid foundation for a polity which must include non-hacker computer users. Such people expect that unless they intend to grant access, nobody may access their computers.
I hold host operators responsible for their own hosts' behavior and security. However, I also hold abusers responsible for their behavior in exploiting vulnerable hosts to do things that they know would be unwelcome to those hosts' owners. Spyware, abusive popup spam, r00ting, email spam, and the many other unwelcome abuses of people's systems are all simply different degrees of unwelcome, unauthorized access.
Since the article suggests the idea of applying disk-volume concepts (RAID) to databases, I thought I'd bring this up: For a while now I've been wishing there was an equivalent of NFS for databases, a way to mount a running database's tablespace into another database. This would allow one to draw together disparate databases, creating views and running joins across tables which natively reside in different databases, on different hosts.
Here's an example of an application: I have a database-driven Web application that allows my onsite clients to register network services for openings in the firewall. Another software component probes the registered hosts for daemon version information and records it in the database, so that we can send out alerts when security holes are discovered in particular versions. I use PostgreSQL on Debian and Solaris. Independently of my work, our networking office has a Microsoft SQL Server database of IP addresses, MAC addresses, and physical switch ports and jack numbers.
What I'd like to do is mount both my database and the networking office's database into some sort of "meta-database" -- analogous to mounting filesystems from two different hosts via NFS -- and run SQL queries that span both data sets. I wouldn't expect to be able to write to this conjoined database -- locking would be a nightmare -- but being able to SELECT across the two sets would be incredibly valuable.
So, would someone care to explain why you wouldn't just use NetBSD instead of trying to run a Linux environment with a NetBSD kernel? What benefit does this give you? One of the benefits of BSDs is that they're coherent systems and not a hodgepodge of kernels and userland apps. So again, what is being gained here?
Debian isn't exactly a hodge-podge either. Every package in Debian stable has been tested for compatibility on all the platforms for which it ships; its dependencies and conflicts documented; its license terms checked; and its configuration files tweaked to use standard locations for things wherever possible. Debian also provides bug tracking for all packages, providing a centralized place to get in touch with someone who considers him- or herself personally responsible for the package.
And then there's the fact that Debian has more packages than any other system I've seen. The version currently in beta ("testing" in Debian terms) has almost 11000 packages. That's a lot of software -- how many does your ports tree have?
It's a terminology quibble on what's otherwise an insightful post, but a secure system (to the extent it means anything at all) is a system that protects things to the level which the security policy requires.
A system that keeps its promises (nice phrase) is a good description of a trusted system.
Thanks for the distinction. It's interesting how much people ask for "security" when they do not have a coherent security policy -- and when what they are really thinking of is a system that can be depended upon. Many elements of site security policies that I've seen don't really strike me as security policies -- more as a cross between internal acceptable-use policies and attempts to provide by fiat rather than technology the kind of guarantees I'm talking about.
Yet even if people don't have a clear idea what they want out of "security", I think they could still get a lot out of the idea of guarantees provided by various security gear and other systems. A guarantee is a reduction in uncertainty, and a lot of what makes people edgy about network and system security is uncertainty: "Who knows what someone might do to our network? The 'hackers' are always one step ahead; how can we keep up? The Internet out there past our border is dangerous and anarchic, and any packet might be a frag-routed masqueraded spoofed forged DDoS rootkit script-kiddie flood!"
A good computer-science word that could take the place of "guarantee" above is "invariant". An invariant is a condition which is intended always to be true when a loop or task executes. When an invariant is not preserved, that is by definition a bug, a failure. Design by contract is an elaboration of the idea, and it might not be too far off to say that what I'm thinking of is security design by contract. (Naturally, this may need to be more paranoid than programming design by contract, though the latter in its more explicit forms is often more paranoid than many security plans.)
For instance, one may wish to establish a certain security contract with one's border router. The border router will discard non-IP frames, perform ingress and egress IP filtering, and drop directed broadcast and unwanted multicast. This provides the guarantee that the only packets which will pass it inbound are IP packets with outside source and inside destination addresses.
Based on that guarantee, an OpenBSD pf firewall (inboard of the border router) may provide guarantees that the only inbound packets which pass it are unfragmented, valid by checksum, and belong either to an outgoing flow or an incoming connection to a known server host/port combination.
To "enforce" our "contracts", we can toss a custom snort ruleset behind the firewall, tuned to look for things which should not be present: spoofed packets, fragments, and so forth. This isn't an IDS, whatever it may say on the manpage -- it's a fault detection system. (We can put an IDS in too if we like -- but, by Skuld, they're noisy.) It's there not to "catch hackers" but to throw a wild fit whenever a frame is on the network that doesn't belong -- a contract is not being met.
From this view, the traffic incoming is no longer anywhere near as threatening and unknown as it might be if we planned a border and firewall from the standpoint of "blocking attacks" against our delicate servers. Instead of port blocks and a loud yammering IDS, we have assurances, and (almost a bonus!) we can assign responsibility for failures. "I see an inbound frag. Frags don't belong here. It's the firewall's job to defrag packets, so the firewall is at fault. Who broke the firewall?"
And that's just the outer border. Deeper levels of security should provide additional guarantees, naturally including ones about internal traffic. Application proxies might be a valuable step, ensuring traffic to servers is well-formed and imposing li
I've had the discussion with a BSD-zealot friend of mine whether Linux or BSD is better, and all we could come up with is that both are much better than Windows:)
Not for everything. Windows beats Unix if you want to run Photoshop.:) I was talking specifically about server systems, where reliability and understandability of the system is crucial. I think the Unix edge is not merely the Unix architecture, but also the history and deep understanding which Unix professionals bring. It just isn't possible for a culture to have that kind of deep understanding of a system that has just been released -- no matter how featureful it may be.
To be snarky about it: On Unix systems, novices know they have no idea what is going on, and experts know that they know what is going on. On Windows systems, novices think they know what is going on, and experts know that they do not know what is going on. That may make Windows experts more Socratic ("Socrates is wisest, because he knows that he knows nothing") -- but I would not want my enterprise database dependent upon Socrates.
A lot of the dialogue on computer security takes it as read that security is about keeping hackers out or about patching holes or about reducing exposure by blocking attacks... or something of those ilk. I'd like to suggest that none of these are really what people want out of security, and while they may provide useful tactical steps they do not provide the insight needed for an overarching security strategy.
Here's what I would offer as a cornerstone for thinking about your systems' security: A secure component is one that keeps its word. That is, it provides guarantees -- assurances -- of its behavior, and it meets those guarantees. Because it provides these guarantees, other components can depend upon it (though they need not depend exclusively upon it). And once a system is built out of dependable components, staff can place their trust in it and not be betrayed.
Take an example: a firewall. A firewall is commonly thought of as a tool for blocking attacks or reducing exposure. I would suggest that it is, rather, a tool for providing assurance that certain traffic will not enter the network from a certain point. Systems behind the firewall should not be thought of as being made "more secure" (what muddy thinking!) on account of the firewall's presence. They should be thought of as receiving a guarantee from the firewall that certain traffic will not enter.
This allows for evaluation. Under the blocking-attacks model, we must rate a firewall as doing its job if it blocks attacks. Which attacks? "Uh -- some attacks, the ones from the other side of the firewall." But what about attacks from other places? "Uh -- the firewall can't help you there, it's only at the border." But then what good is it? "Uh -- it makes your security better. That's what everyone says." With a clear understanding of the guarantees the firewall provides, we can evaluate its success with a clearer mind: does it succeed or fail at meeting those guarantees?
(Microsoft's marketing folks recognize that people want dependability when they talk about "trusted computing". They're using it as a nasty trick, of course, but they have the right words. By "secure system" people don't just want a system that rejects today's attacks, but one that provides dependable assurances of its behavior. Too bad they are wasting the memetic capital of the phrase "trusted computing" on a despicable power grab.)
What are the advantages of FreeBSD over Windows 2003 Server. Both are stable OSs, capable of running a high traffic server. But, with Windows, you get the award-winning support of a Fortune 500 company. With BSD, you get nothing.
With BSD, or most any other Unix system including Linux distributions, you get a time-tested and proven base upon which all the system's services rest. You get a well-understood system upon which hundreds of thousands of people have built upon, and millions of people have hands-on experience using. You get not only an operating system, but a thoroughly proven model for maintainability, ease of administration, and security.
Windows 2003 Server is a new and unproven offering from a company whose past successes in marketing have been dwarfed in the public eye by the harms due to their failings (see, e.g., Nimda, SQL Sapphire Worm). Nobody has years or even months of experience on Windows 2003 Server, and its frequently accurate technical documentation cannot match the depth of understanding which Unix professionals bring with their platform.
You could choose Windows 2003 Server, and your staff might be able to make it work for you. But what will you do in two years? BSD, Linux, and the rest of the Unix heritage will still be going strong -- but if history is any guide to the future, Microsoft will be running ads touting Windows 2005 Server, a new and equally unproven platform, and telling you that 2003 Server is a piece of unstable trash. What kind of a future is that for your business?
Many GPL-covered applications packaged for Mac OS X put a copy of the GPL in the "license" slot in the standard OS X installer package. This causes it to be displayed in the same way that an EULA would be on a proprietary package. I imagine this is the same on Windows GPLed programs that use the standard installer.
It doesn't really matter. As has been pointed out several times now, the GPL isn't an end-user license at all, and it isn't an agreement either. It's an assignment of permission to copy and make derivative works from a piece of copyrighted software -- a license, not a "license agreement".
The GPL isn't even a contract (certainly not a "contract of adhesion" like MS EULAs), and it it expressly disclaims covering the act of running the covered program. It presumes that if you came by your copy of the program legally (as by buying it or being given it) you already have the right to run it on your property -- the only things you need permission from the author to do are those things normally restricted by copyright law.
Is that "Oppenheimer" as in the head of the most politically motivated science program of all time?
Perhaps a better analogy would have been Wernher von Braun, as commemorated in Tom Lehrer's song:
Don't say that he's hypocritical
Say rather that he's "apolitical"!
"Vonce ze rockets go up, who cares vhere zey come down?
"Zat's not my depaartment," says Wernher von Braun.
The intended contrast is between the "apolitical" engineer who does not really care to what purpose his invention is used -- or by whom, as von Braun (purportedly) worked equally willingly for the Nazis as for the United States -- and the type (like Albert Einstein) who considers and possibly regrets its social consequences.
I think it would be more accurate so say that Mac OS X is gay. It clearly wins in the fashion stakes, and expresses a strong preference for interfacing with others of the same type (which is not to say it won't interface with others...).
Mac OS X is a freaking slut! It'll do anything it can get its hands on.
File sharing? Sure -- straight NFS with Unix hosts; kinky SMB with Windows; AppleShare AFP with other Macs, even old ones. It'll even play with weird new tricks like WebDAV, and it can mount an FTP server as easily as mounting a local disk.
Executables? No problem. Trick it out with the right gender-bender, and it'll run Windows programs. Lots of Linux and Unix software just takes a recompile and a little teasing -- those perverts at Fink specialize in fitting Debian parts into OS X ports.
And then there's all the perverted things it'll do in emulation...
As I see it, the greatest thing about the Debian project is the fact that they don't subscribe to the typical herd mentality so often seen in the open-source community.
What Debian has is a set of clear guarantees that it promises to maintain to the community: the Debian Social Contract. Because of this, it cannot be beholden to political alliances, such as allegiance to one desktop project (vide Red Hat's closeness to GNOME) or even to its own ideological ancestor, the FSF. It has to operate by its principles, not by the opinions of whoever happens to be its leader at the moment.
One of the principles of classical liberal politics is to be ruled by laws rather than by men. In monarchies and oligarchies, the organizing principle of society is the leadership of a special individual or group: the king, the aristocracy, the ruling party, or what-have-you. Allegiance is to this leader, and alliances with other polities are founded on amity among leaders: hence the marriages of political alliance in medieval Europe. In liberal societies, the organizing principle is not the leader principle, but rather the basic law, or constitution.
In this regard, the FSF is in many ways illiberal: yet Debian, in so many ways the FSF's descendant, is thoroughly liberal. Debian is organized by rules, rather than by adherence to a leader.
The GNU Project is shady. Make no mistake about it: The GPL restricts choice as much as an NDA would.
This, however, is going too far. (For one, I think you mean EULA rather than NDA. NDAs aren't even related to copyright licensure; they're just contracts.)
Both EULAs and the GPL are founded upon the base of copyright, but from that base they build in opposite directions. EULAs attempt to expand the powers of the owner, to control the ways in which you may use the covered software as well as the ways in which you may copy it. (Recall: copyright is not use-right; it is the right to control the making and distribution of copies, not the use of legally-obtained copies.)
The GPL, however, is a partial release of the powers of copyright. It does not at all restrict the use of software; and it grants a limited right to copy. Whereas EULAs go beyond copyright, the GPL refuses to exercise even the full power of copyright.
To contribute to GCC, in fact, it is not enough that you GPL your code and give a license to the GNU Project. No, you have to ASSIGN COPYRIGHT of the code to GNU
You are, of course, free to create your own compiler based on GCC, and retain your copyright. (Since this would be a derivative work, you would have to release it under GPL, but you would not have to assign your copyright to GNU or anyone else.) However, if you want the GCC project to accept your patches and incorporate them into their code base, that's a different matter.
This is not a matter of copyright, or you freedom to write software that is based on GCC. It is a matter of the GCC project's management. You are just as free to write software based on GCC as you are to write software based on the Linux kernel (also GPLed) -- but you cannot force the GCC developers to roll your patches into their code base any more than you could force Linus to accept a crufty patch to Linux.
I'd like to invite you to peruse this article in my Slashdot journal, which responds to that very claim. In brief: the overwhelming difference is that "Microsoft" (read: the proprietary/EULA licensing model) places onerous restrictions and risks upon the ordinary user -- not even just the programmer! -- for which there is no equivalent in Free Software.
If you're going to use it for that, take a careful look at the documentation for eval: notably, what do you want to do with __DIE__ hooks? There's more than a bit of anti-structured "action at a distance" going on there.
Something else to note is that Python and Java exceptions work hand-in-hand with the call stack, and provide useful stack backtraces if you bomb out. ISTR backtraces are an extra you have to ask for in Perl -- the Carp module's confess, if I remember correctly. How does that interact with eval? I see caveats.
If they are immutable then there is no way to implement a function like Perl's chomp() which modifies the string passed in.
That's right. The equivalent in Python is "foo = rstrip(foo)", which does rebind foo to a new string.
This prints '50', showing that g() cannot access the variable in its enclosing scope.
What you did was create a new name x, local to the scope of g.
If what you're after is to retain data among several calls, a class is probably what you want. It can be callable (as in the curry example I cited above) -- Python callable classes are practically a generalization of functions.
On the other hand, you can do closures in Python. This IBM article discusses some approaches.
Python has 'break' and 'continue' like C. But these only affect the innermost loop. Is there a way to break out of an enclosing loop? (In Perl you can label a loop and then say 'next LABEL', etc.)
Like Java and Lisp -- and unlike Perl -- Python has exception handling. The structured way to get out of an inner loop is the same as the structured way to get out of a deeply nested function call: raise an exception, and trap it at the higher level where you want to "go to".
How can I pass a variable by reference? For example, to take a reference to a string, pass it to a function and have that function modify the string passed in. More generally, is there a way to store references?
In Python, everything is a reference, but strings are immutable objects. There's no such thing as "modifying the string passed in" -- all the built-in string functions return a new string. However, for mutable types such as lists and dictionaries, functions can certainly modify their arguments, as in this example:
def foo(lst): lst.append("beer") y = ["wine"] foo(y) # y is now ["wine", "beer"]
Python advertises its support for first-class functions, but I can't seem to get closures to work. The 'lambda' keyword won't accept assignment or even sequencing inside the function body.
Especially since I have some Scheme in my programming background, this is a quirk I find annoying about Python: lambda is underpowered. It's comparable to the old BASIC "DEF FN" in that it allows only expressions, not statements, in the lambda-body.
However, you can do what you want by defining a function with a temporary name, using def, and returning it. (In Python it is perfectly valid to have function definitions inside other function definitions, and it does what you expect: defines functions whose names have local scope, but can be returned.) You can also create callable classes, which act like functions instead of object factories. There's an implementation of curry for instance in the Python Cookbook, which does this. Check it out.
Is there a do/while statement in Python? Plain 'while' is there but occasionally an 'at least once' loop is what you need. Is there an addon package or library for Python that provides a 'do' construct?
There is neither a do/while nor a repeat/until in Python. Again this is something I don't agree with, but the argument is that this keeps the number of redundant keywords down. The convention is to use while loops and escape with break when necessary.
Most anti-perspirants, afaik, work by clogging the pores with zinc.
Not according to this article by the folks at HowStuffWorks.com. The active ingredient is not zinc but rather aluminum compounds, which stimulate skin cells to absorb water and thus close the sweat pores. Basically it is a trick of osmosis, and closes rather than clogs the pores.
Zinc compounds tend to be pretty caustic stuff, but they are used in some dermatological treatments. One is dandruff shampoo. However, antiperspirant is not one of them.
Firebird is also taken as an open-source project name. It is an SQL DBMS (database system) founded on Borland InterBase. It's actually supposed to be a fast and reliable DBMS -- possibly even more so than PostgreSQL.
These folks must not have looked very hard if they thought "Firebird" was a name with no conflicts in the open-source world. Firebird SQL is on SourceForge, a pretty obvious place to look.
Slashdot Mirror
If I print a statement of my opinion about you on my personal Web site, operated on my own host, on the end of an Internet connection I pay for, you have no right to demand that I incur similar expenses to carry your opinion of my opinion. It doesn't matter how popular my site is, or whether you think of it as a "blog" or a "news medium" or what-have-you: the fact that I spend money to promulgate my opinion in no wise obligates me to spend money to promulgate yours.
To propose the contrary is indeed chilling -- because it means that if I post something you object to, you have the right to impose costs upon me. It means that unless I am able to bear the costs of printing both my own opinion and the opinions of everyone who disagrees with me, I cannot print my own opinion. It also means that if I am unable to countenance spending money to print the opinion of any particular objector -- for instance because said objector's views are vile and repugnant to me -- that I may not print my own.
Such a "right of reply" may be survivable by "big media" organizations which do not really have any views of their own. It would be, however, fatal to the "small media" organizations -- individual, idiosyncratic, and opinionated, devoted to exposing those sides of stories that do not get mainstream coverage -- that the Web in particular permits to thrive.
I am mostly very libertarian in my political views. However, when it comes to energy or transportation policy, I find that it is ironic for ostensible free-marketers to object to government subsidies of low-pollution technology such as railroads or wind power ... since the government already heavily subsidizes the high-pollution technologies such as highways and fossil-fuel power.
Every penny a government uses to build highways is a subsidy to the automobile and trucking systems and thus to oil fascism. In light of this, free-marketers have no business objecting to the funding of Amtrak, rail shipping, or the like -- which do a lot less harm to the populace. Better, perhaps, to not subsidize anyone -- without someone else paying to maintain highways at above a level the market would naturally sustain, you'll damned well take the train! But if you have to subsidize SUV shite (who bend our nation over for the pseudo-Islamic fascists in Saudi Arabia) by building roads for them at everyone else's expense, damned better have some balance for the rails.
End of rant. That said, though, I'm pro-nuclear as well as pro-wind-power ... simply because nuke plants produce less radioactive pollution than coal plants; and if you build 'em such that the design criteria are power production and safety rather than conversion to weapons production, they don't melt down. (Google for "pebble bed reactors".)
And here we have an elegant example of the logical fallacy known as "begging the question"; that is, assuming for your argument the very conclusion which is under contention: whether or not there is, or should be, a right to exclude others from a discovery in fundamental science, simply because one manages to file it first.
(It is the claim of the U.S. Constitution, for instance, that patent and copyright are not natural rights akin to life, liberty, and property: they are, rather, privileges created by Congress for a purpose. They rest on a consequentialist ethical system rather than a natural-law one: specifically, they exist to promote progress in the sciences and useful arts. If they fail to meet that purpose, then they fail to be justified.)
There has been no evidence cited that the consequentialist argument defends the extremity of patent (and copyright) that is presently enforced. Pursuers of greater copyright restrictions, and pursuers of vague and obvious patents, both assert that artists and researchers would have greater incentive to create and discover, if their works received greater monopoly protection.
However, this is a bare assertion without any evidence for it; a statement of faith and not of reason. It should not motivate the restriction of the public by further onerous laws. In the absence of evidence for the claim that a restrictive law would further the public good, a free nation should err on the side of preserving liberty and not on the side of extending further monopolies for the already-privileged.
The first time I saw that, I was reminded of a schoolyard taunt: "Your epidermis is showing!"
(To make this funny, you have to consider that not every kid knew what his epidermis was, and that it wasn't dirty for [parts of] it to be showing ...)
I recommend strongly that anyone in a role like mine take some time to study viruses, exploits, rootkits, and other pieces of hostile code. These are a basic part of the security environment in the field. The more you understand the crap that the Net's rejects and crackheads are throwing at you, the better a job you can do.
Here's just one example of what we can learn from viruses; a bit of an older example, so I'm not doing too much of your work for you:
Let's say your client is considering a bonehead move -- like, say, deploying Microsoft Outlook enterprise-wide. Any security nerd can say "duh, Outlook sux0r, it's full of vulnerabilities, that's why it spreads viruses." However, if you have read the source code of the LoveLetter and Melissa viruses, you will realize (and can explain to your client) that these viruses do not exploit vulnerabilities at all -- at least, not in the sense of buffer overflows and other attacks which target bugs in software. These viruses don't crack anything -- they use perfectly ordinary, documented API calls. It isn't holes in the Windows Mail API that make it a virus breeding ground -- it's just its built-in, designed, intended functionality. That's why these viruses can still spread after years of bug fixes: their critical paths do not rely on bugs at all.
What do we learn from these viruses? Security is not about patching bugs, or having bug-free software. It is about correctly modeling the trust relationships people have with each other regarding their computer resources, in software. The Windows MAPI's design implies an assumption that people want to entrust word-processing documents with the power to send hundreds of emails. That's obviously wrong -- and that, not any bug, is what must be explained to convince someone that Microsoft's mail software is a bad security choice.
There are many more lessons to be learned by understanding hostile code. There are lessons about user interface design: many email viruses depend on getting the user to take some action (opening a message, running a macro, etc.) which unintentionally grants the virus trust and privilege (even the privilege to run code) that it should not have. To design secure systems for users, we must have user interfaces which do not promote such deception. There are lessons about system monitoring and the habits of sysadmins: Unix rootkits, which alter the system to conceal the tracks of an attacker, show just how easily a too-shallow maintenance or log-checking routine can be deceived. There are many lessons.
Get yourself some virus source code. Google will help. Read rootkit code, and the analyses thereof which researchers on SecurityFocus and other sites have published. Understand these attacks, and you will understand the systems they target better than you do now.
Naturally, fighting in the dirt with the black hats is a lot "sexier" and more entertaining than building highly robust and reliable systems which will guarantee future security. The popularity of honeypots with security hobbyists (as opposed to researchers) seems to be a result of this: people enjoy seeing the attacker flummoxed, feeling superior to him, defeating him. Yet this doesn't really result in the improvement of security against new attacks, and it arguably distracts from that purpose.
I'm interested to know where you see progress in security assurance, as opposed to scanning or blocking of old, known attacks. Who else, besides OpenBSD, is in the camp of improving the guarantees that systems provide their users: guarantees such as W^X, packet normalization, and so forth?
Trivial doors should fall into the same category -- if you can't be bothered to lock all your TV set and fancy gaming computer in a steel safe every time you go out, you shouldn't bitch when someone else takes them. Uh-huh.
See the problem? People have expectations of privacy that go beyond the physical mechanisms they have in place to forcibly keep others off their land or out of their houses. That is why we have trespassing and theft laws at all, instead of just leaving everyone putting up solid steel fences and arming themselves to the teeth. We believe in the rule of law -- not the rule of the highest fence and the biggest cannon.
The same needs to apply to the Net. People should take precautions with their systems just as they lock their doors and cars. However, when those precautions or locks are violated by someone with ill intent, that is a crime and must be treated as such. Though both the user with bad passwords and the guy who leaves his door unlocked are fools, it remains illegal to steal from fools.
That isn't at all an "of course" issue. If I place an unpatched default installation of Red Hat 6.2 on an Internet-connected host, my "preferences" (read: installed software) by default allow remote users to obtain root access. No matter how stupid or negligent I would be to do so, I would still expect that for someone to take advantage of those "preferences" to r00t the b0x0r would indeed be illegal. Similarly, just because Jane Winecooler's browser by default allows the installation of spyware and the forced display of popup spam, does not authorize anyone to set up booby-trapped Web sites which do such things to her browser.
The idea that any access that my host does not block is by default an authorized access is compelling to the hacker (in the old sense) since it means that everything one can do, one may do, provided it is not obviously harmful. Under this construction, if you leave your box r00table, then I may r00t it -- but I may not (for instance) delete your files or use your host to DoS someone. However, I do not think this is a solid foundation for a polity which must include non-hacker computer users. Such people expect that unless they intend to grant access, nobody may access their computers.
I hold host operators responsible for their own hosts' behavior and security. However, I also hold abusers responsible for their behavior in exploiting vulnerable hosts to do things that they know would be unwelcome to those hosts' owners. Spyware, abusive popup spam, r00ting, email spam, and the many other unwelcome abuses of people's systems are all simply different degrees of unwelcome, unauthorized access.
Here's an example of an application: I have a database-driven Web application that allows my onsite clients to register network services for openings in the firewall. Another software component probes the registered hosts for daemon version information and records it in the database, so that we can send out alerts when security holes are discovered in particular versions. I use PostgreSQL on Debian and Solaris. Independently of my work, our networking office has a Microsoft SQL Server database of IP addresses, MAC addresses, and physical switch ports and jack numbers.
What I'd like to do is mount both my database and the networking office's database into some sort of "meta-database" -- analogous to mounting filesystems from two different hosts via NFS -- and run SQL queries that span both data sets. I wouldn't expect to be able to write to this conjoined database -- locking would be a nightmare -- but being able to SELECT across the two sets would be incredibly valuable.
Debian isn't exactly a hodge-podge either. Every package in Debian stable has been tested for compatibility on all the platforms for which it ships; its dependencies and conflicts documented; its license terms checked; and its configuration files tweaked to use standard locations for things wherever possible. Debian also provides bug tracking for all packages, providing a centralized place to get in touch with someone who considers him- or herself personally responsible for the package.
And then there's the fact that Debian has more packages than any other system I've seen. The version currently in beta ("testing" in Debian terms) has almost 11000 packages. That's a lot of software -- how many does your ports tree have?
Thanks! As far as I know, the phrasing is original, but it's not a new idea.
Thanks for the distinction. It's interesting how much people ask for "security" when they do not have a coherent security policy -- and when what they are really thinking of is a system that can be depended upon. Many elements of site security policies that I've seen don't really strike me as security policies -- more as a cross between internal acceptable-use policies and attempts to provide by fiat rather than technology the kind of guarantees I'm talking about.
Yet even if people don't have a clear idea what they want out of "security", I think they could still get a lot out of the idea of guarantees provided by various security gear and other systems. A guarantee is a reduction in uncertainty, and a lot of what makes people edgy about network and system security is uncertainty: "Who knows what someone might do to our network? The 'hackers' are always one step ahead; how can we keep up? The Internet out there past our border is dangerous and anarchic, and any packet might be a frag-routed masqueraded spoofed forged DDoS rootkit script-kiddie flood!"
A good computer-science word that could take the place of "guarantee" above is "invariant". An invariant is a condition which is intended always to be true when a loop or task executes. When an invariant is not preserved, that is by definition a bug, a failure. Design by contract is an elaboration of the idea, and it might not be too far off to say that what I'm thinking of is security design by contract. (Naturally, this may need to be more paranoid than programming design by contract, though the latter in its more explicit forms is often more paranoid than many security plans.)
For instance, one may wish to establish a certain security contract with one's border router. The border router will discard non-IP frames, perform ingress and egress IP filtering, and drop directed broadcast and unwanted multicast. This provides the guarantee that the only packets which will pass it inbound are IP packets with outside source and inside destination addresses.
Based on that guarantee, an OpenBSD pf firewall (inboard of the border router) may provide guarantees that the only inbound packets which pass it are unfragmented, valid by checksum, and belong either to an outgoing flow or an incoming connection to a known server host/port combination.
To "enforce" our "contracts", we can toss a custom snort ruleset behind the firewall, tuned to look for things which should not be present: spoofed packets, fragments, and so forth. This isn't an IDS, whatever it may say on the manpage -- it's a fault detection system. (We can put an IDS in too if we like -- but, by Skuld, they're noisy.) It's there not to "catch hackers" but to throw a wild fit whenever a frame is on the network that doesn't belong -- a contract is not being met.
From this view, the traffic incoming is no longer anywhere near as threatening and unknown as it might be if we planned a border and firewall from the standpoint of "blocking attacks" against our delicate servers. Instead of port blocks and a loud yammering IDS, we have assurances, and (almost a bonus!) we can assign responsibility for failures. "I see an inbound frag. Frags don't belong here. It's the firewall's job to defrag packets, so the firewall is at fault. Who broke the firewall?"
And that's just the outer border. Deeper levels of security should provide additional guarantees, naturally including ones about internal traffic. Application proxies might be a valuable step, ensuring traffic to servers is well-formed and imposing li
Not for everything. Windows beats Unix if you want to run Photoshop. :) I was talking specifically about server systems, where reliability and understandability of the system is crucial. I think the Unix edge is not merely the Unix architecture, but also the history and deep understanding which Unix professionals bring. It just isn't possible for a culture to have that kind of deep understanding of a system that has just been released -- no matter how featureful it may be.
To be snarky about it: On Unix systems, novices know they have no idea what is going on, and experts know that they know what is going on. On Windows systems, novices think they know what is going on, and experts know that they do not know what is going on. That may make Windows experts more Socratic ("Socrates is wisest, because he knows that he knows nothing") -- but I would not want my enterprise database dependent upon Socrates.
Here's what I would offer as a cornerstone for thinking about your systems' security: A secure component is one that keeps its word. That is, it provides guarantees -- assurances -- of its behavior, and it meets those guarantees. Because it provides these guarantees, other components can depend upon it (though they need not depend exclusively upon it). And once a system is built out of dependable components, staff can place their trust in it and not be betrayed.
Take an example: a firewall. A firewall is commonly thought of as a tool for blocking attacks or reducing exposure. I would suggest that it is, rather, a tool for providing assurance that certain traffic will not enter the network from a certain point. Systems behind the firewall should not be thought of as being made "more secure" (what muddy thinking!) on account of the firewall's presence. They should be thought of as receiving a guarantee from the firewall that certain traffic will not enter.
This allows for evaluation. Under the blocking-attacks model, we must rate a firewall as doing its job if it blocks attacks. Which attacks? "Uh -- some attacks, the ones from the other side of the firewall." But what about attacks from other places? "Uh -- the firewall can't help you there, it's only at the border." But then what good is it? "Uh -- it makes your security better. That's what everyone says." With a clear understanding of the guarantees the firewall provides, we can evaluate its success with a clearer mind: does it succeed or fail at meeting those guarantees?
(Microsoft's marketing folks recognize that people want dependability when they talk about "trusted computing". They're using it as a nasty trick, of course, but they have the right words. By "secure system" people don't just want a system that rejects today's attacks, but one that provides dependable assurances of its behavior. Too bad they are wasting the memetic capital of the phrase "trusted computing" on a despicable power grab.)
With BSD, or most any other Unix system including Linux distributions, you get a time-tested and proven base upon which all the system's services rest. You get a well-understood system upon which hundreds of thousands of people have built upon, and millions of people have hands-on experience using. You get not only an operating system, but a thoroughly proven model for maintainability, ease of administration, and security.
Windows 2003 Server is a new and unproven offering from a company whose past successes in marketing have been dwarfed in the public eye by the harms due to their failings (see, e.g., Nimda, SQL Sapphire Worm). Nobody has years or even months of experience on Windows 2003 Server, and its frequently accurate technical documentation cannot match the depth of understanding which Unix professionals bring with their platform.
You could choose Windows 2003 Server, and your staff might be able to make it work for you. But what will you do in two years? BSD, Linux, and the rest of the Unix heritage will still be going strong -- but if history is any guide to the future, Microsoft will be running ads touting Windows 2005 Server, a new and equally unproven platform, and telling you that 2003 Server is a piece of unstable trash. What kind of a future is that for your business?
Many GPL-covered applications packaged for Mac OS X put a copy of the GPL in the "license" slot in the standard OS X installer package. This causes it to be displayed in the same way that an EULA would be on a proprietary package. I imagine this is the same on Windows GPLed programs that use the standard installer.
It doesn't really matter. As has been pointed out several times now, the GPL isn't an end-user license at all, and it isn't an agreement either. It's an assignment of permission to copy and make derivative works from a piece of copyrighted software -- a license, not a "license agreement".
The GPL isn't even a contract (certainly not a "contract of adhesion" like MS EULAs), and it it expressly disclaims covering the act of running the covered program. It presumes that if you came by your copy of the program legally (as by buying it or being given it) you already have the right to run it on your property -- the only things you need permission from the author to do are those things normally restricted by copyright law.
Perhaps a better analogy would have been Wernher von Braun, as commemorated in Tom Lehrer's song:
The intended contrast is between the "apolitical" engineer who does not really care to what purpose his invention is used -- or by whom, as von Braun (purportedly) worked equally willingly for the Nazis as for the United States -- and the type (like Albert Einstein) who considers and possibly regrets its social consequences.
Mac OS X is a freaking slut! It'll do anything it can get its hands on.
File sharing? Sure -- straight NFS with Unix hosts; kinky SMB with Windows; AppleShare AFP with other Macs, even old ones. It'll even play with weird new tricks like WebDAV, and it can mount an FTP server as easily as mounting a local disk.
Executables? No problem. Trick it out with the right gender-bender, and it'll run Windows programs. Lots of Linux and Unix software just takes a recompile and a little teasing -- those perverts at Fink specialize in fitting Debian parts into OS X ports.
And then there's all the perverted things it'll do in emulation ...
What Debian has is a set of clear guarantees that it promises to maintain to the community: the Debian Social Contract. Because of this, it cannot be beholden to political alliances, such as allegiance to one desktop project (vide Red Hat's closeness to GNOME) or even to its own ideological ancestor, the FSF. It has to operate by its principles, not by the opinions of whoever happens to be its leader at the moment.
One of the principles of classical liberal politics is to be ruled by laws rather than by men. In monarchies and oligarchies, the organizing principle of society is the leadership of a special individual or group: the king, the aristocracy, the ruling party, or what-have-you. Allegiance is to this leader, and alliances with other polities are founded on amity among leaders: hence the marriages of political alliance in medieval Europe. In liberal societies, the organizing principle is not the leader principle, but rather the basic law, or constitution.
In this regard, the FSF is in many ways illiberal: yet Debian, in so many ways the FSF's descendant, is thoroughly liberal. Debian is organized by rules, rather than by adherence to a leader.
This, however, is going too far. (For one, I think you mean EULA rather than NDA. NDAs aren't even related to copyright licensure; they're just contracts.)
Both EULAs and the GPL are founded upon the base of copyright, but from that base they build in opposite directions. EULAs attempt to expand the powers of the owner, to control the ways in which you may use the covered software as well as the ways in which you may copy it. (Recall: copyright is not use-right; it is the right to control the making and distribution of copies, not the use of legally-obtained copies.)
The GPL, however, is a partial release of the powers of copyright. It does not at all restrict the use of software; and it grants a limited right to copy. Whereas EULAs go beyond copyright, the GPL refuses to exercise even the full power of copyright.
You are, of course, free to create your own compiler based on GCC, and retain your copyright. (Since this would be a derivative work, you would have to release it under GPL, but you would not have to assign your copyright to GNU or anyone else.) However, if you want the GCC project to accept your patches and incorporate them into their code base, that's a different matter.
This is not a matter of copyright, or you freedom to write software that is based on GCC. It is a matter of the GCC project's management. You are just as free to write software based on GCC as you are to write software based on the Linux kernel (also GPLed) -- but you cannot force the GCC developers to roll your patches into their code base any more than you could force Linus to accept a crufty patch to Linux.
I'd like to invite you to peruse this article in my Slashdot journal, which responds to that very claim. In brief: the overwhelming difference is that "Microsoft" (read: the proprietary/EULA licensing model) places onerous restrictions and risks upon the ordinary user -- not even just the programmer! -- for which there is no equivalent in Free Software.
If you're going to use it for that, take a careful look at the documentation for eval: notably, what do you want to do with __DIE__ hooks? There's more than a bit of anti-structured "action at a distance" going on there.
Something else to note is that Python and Java exceptions work hand-in-hand with the call stack, and provide useful stack backtraces if you bomb out. ISTR backtraces are an extra you have to ask for in Perl -- the Carp module's confess, if I remember correctly. How does that interact with eval? I see caveats.
That's right. The equivalent in Python is "foo = rstrip(foo)", which does rebind foo to a new string.
What you did was create a new name x, local to the scope of g.
If what you're after is to retain data among several calls, a class is probably what you want. It can be callable (as in the curry example I cited above) -- Python callable classes are practically a generalization of functions.
On the other hand, you can do closures in Python. This IBM article discusses some approaches.
Like Java and Lisp -- and unlike Perl -- Python has exception handling. The structured way to get out of an inner loop is the same as the structured way to get out of a deeply nested function call: raise an exception, and trap it at the higher level where you want to "go to".
In Python, everything is a reference, but strings are immutable objects. There's no such thing as "modifying the string passed in" -- all the built-in string functions return a new string. However, for mutable types such as lists and dictionaries, functions can certainly modify their arguments, as in this example:
Especially since I have some Scheme in my programming background, this is a quirk I find annoying about Python: lambda is underpowered. It's comparable to the old BASIC "DEF FN" in that it allows only expressions, not statements, in the lambda-body.
However, you can do what you want by defining a function with a temporary name, using def, and returning it. (In Python it is perfectly valid to have function definitions inside other function definitions, and it does what you expect: defines functions whose names have local scope, but can be returned.) You can also create callable classes, which act like functions instead of object factories. There's an implementation of curry for instance in the Python Cookbook, which does this. Check it out.
There is neither a do/while nor a repeat/until in Python. Again this is something I don't agree with, but the argument is that this keeps the number of redundant keywords down. The convention is to use while loops and escape with break when necessary.
Not according to this article by the folks at HowStuffWorks.com. The active ingredient is not zinc but rather aluminum compounds, which stimulate skin cells to absorb water and thus close the sweat pores. Basically it is a trick of osmosis, and closes rather than clogs the pores.
Zinc compounds tend to be pretty caustic stuff, but they are used in some dermatological treatments. One is dandruff shampoo. However, antiperspirant is not one of them.
These folks must not have looked very hard if they thought "Firebird" was a name with no conflicts in the open-source world. Firebird SQL is on SourceForge, a pretty obvious place to look.