Realize that the early demos of Star Craft were seen as WC in space and were hated. Blizzard rewrote the game in the next year and put out a game that people loved.
"I am not an Orc!"
"This is not WarCraft in space!"
"It's... much more sophisticated!"
"I know it's not 3-D!"
--Artanis, Protoss hero unit
I think we need a law that deals with crimes against the Constitution.
Any person caught proposing a law or voting for a law which is later found to be in violation against the Constitution shall be banned from any government work, either as elected or appointed.
Here's a slightly more relaxed variant I came up with some years ago.
When Congress spends time debating and passing
laws which end up being ruled unconstitutional,
it is wasting time, taxpayer money, and its own
attention. A law that ends up being ruled null
and void, after all, costs just as much in
Congressional salary and support costs as a law
that is effective. Members of Congress who
support and vote for such laws are in effect
advocating that Congress throw its time away -- and
unnecessarily panic the populace to boot.
Therefore, members of Congress and the voting
public need a proportional incentive to
spend time debating and passing only laws which
are constitutional. One way to do this would be
to penalize every member of Congress a fraction of
his or her vote for every unconstitutional law
he or she votes for.
So, for instance, if Sen. Jones voted for the
Communications Decency Act and four other
unconstitutional laws in one year, he would end
up with only 0.95 votes once the Supreme Court
had ruled the laws unconstitutional. Thus, to
preserve his own power base, he would have every
reason to stick closely to the Constitution.
Moreover, this would be an effective alternative
to term limits. Since every member of
Congress is likely to vote for a couple of
unconstitutional laws every year, challengers
would have an automatic advantage over incumbents,
since constituents would prefer to be represented
by a full vote (which every freshman congressman
would bring) rather than just the 90% or 80% of a
vote which an incumbent might have left.
Basically, since the GPL is the only document granting you permission to use the software, violating the GPL revokes your rights under it. That means that if it is found that they violated the GPL (which seems a foregone conclusion if the reporting is accurate), they will no longer be able to distributed MySQL code at all. In other words, put completely out of that business.
I agree that GPL compliance is important, but I am
not clear on the legality of this license termination
business. What is to keep NuSphere from just
downloading a fresh copy of the mySQL sources --
from MySQL AB or another GPL licensee -- and
working from there? That copy would, after all,
come with a fresh new license.
The doctrine that MySQL AB seems to be pushing is
that once an entity violates GPL on a product, not
only has that entity's existing license to the
product been terminated, but that entity is
tainted, forbidden from accepting any future
license to that product. This does not
appear to be what the GPL itself says. The GPL
speaks of voiding the instant license, but not of
tainting the offending licensee from accepting a
future one.
Does anyone have an explanation for the disparity?
A furious Quebec consumer had the constitutional right to erect a sign denouncing an insurance company that he felt had done him wrong, the Supreme Court of Canada ruled yesterday.
...
The appellant, Roger Guignard, was charged under a City of Saint-Hyacinthe bylaw after he put up a sign complaining that his claim for damage to a building he owned had not been settled.
The bylaw in question was a restriction on
billboard advertising, incidentally. This case
doesn't have terribly much to do with online
freedom of criticism, which has usually been a
matter of copyright or libel law -- not municipal
"visual pollution" regulations.
[The following is my response to the authors of this draft.]
I am sure that you are receiving dozens of comments on this draft, so I
will try to keep mine brief. I am a security technician and sysadmin
for a large nonprofit research organization. In your draft's terms I
believe I represent a "User" more than a "Reporter" -- though a user
with security-specific experience.
It seems to me that your draft undervalues the powers of users to
protect themselves independent of the actions of vendors. Users are not
entirely reliant upon the vendors of the software they presently use to
protect themselves, and they can make use of published security
information even if a vendor does not choose to acknowledge or proceed
responsibly with the knowledge of a vulnerability. Moreover, they have
a need for this information outside of its use in getting patches for
existing software.
Most software users are not obligate users of particular pieces of
software. They choose among competing software products (or even system
designs), and make use of published information about these products in
making their choices. They may choose to migrate from an installed
software product to a competing one on the basis of published security
concerns.
Because users need security disclosure to make informed decisions about
the costs and benefits of pieces of software, they have an interest in a
fuller and more analytical disclosure than vendors may desire. Large
vendors may prefer users who have already purchased their products not
to later question this purchase. They may resist the idea that a/pattern/ of vulnerabilities or poor practices exist in their software.
And for a vendor to quietly roll security patches into an "upgrade" may
help the user to avoid being cracked, but does not help him or her make
responsible decisions about future purchases.
Security researchers, it seems to me, have an ethical obligation not to
aid criminals in attacking users. However, they (you) do not have an
obligation to keep vendors from losing business, or to allow vendors to
keep users in the dark regarding the comparative security strengths of
software products. In many cases, users would be better served by being
advised when the software they are using is poorly designed, has a
history of vulnerabilities, and is likely to remain vulnerable to new
sorts of attack -- rather than merely being told to wait for a patch, or
not told anything independently at all.
According to RISKS Digest, someone went along to watch a friend getting laser eye surgery & noticed (a) the technician was blindly hitting RETURN to clear pesky annoying error messages, and (b) the machine was running Win95. Oh, and this machine was taking the details of the subject's eye geometry, & controlling the laser that was about to shave a thing slice off the front of the eyeball to correct some minor astigmatism (IIRC; don't have the url to hand, anyone? )
A quick Google search for "risks digest eye surgery" yields this link. Pretty frightening stuff, and it does show how well many users have become trained to treat error conditions as part of the normal behavior of computer operating systems and applications.
Anthony, it sounds to me like you're confusing
selling a copy you've bought (which is not the
kind of "distribution" controlled by copyright
law) with making new copies and selling them
(which is).
First answer this. Do you agree or disagree that I have the right to distribute Red Hat CDs.
If you buy (or otherwise legally obtain) a Red Hat
distribution on CD, you have the right to sell
that Red Hat distribution on CD, because it is
your property. That is, you can go to the store,
buy a CD set, visit me, and sell me the
CDs you bought. Neither Red Hat nor Linus have
any power to stop you from doing this.
You also have the right to buy a Red Hat CD set,
split it up into source CDs and binary CDs, and
sell me only the binaries, keeping the
sources -- without copying anything.
In addition, because the entirety of Red Hat Linux
is licensed under terms that allow you to do so,
you have the right to make a copy of the
entire distribution (sources included) and sell
the copy, retaining the original and the right to
use it. This is a right granted to you by the
authors of the software contained in Red Hat Linux
-- under the GPL, BSDL, and other licenses.
However, you do not have, and never have had, the
right to make a copy of only the binaries
and sell the copy without providing sources. The
programs contained in Red Hat Linux are copyrighted
works, and their authors have not given you the
permission to copy and distribute their works
without sources.
Distributing Red Hat CDs without distributing source code is a right that I have, that Red Hat does not have. Do you agree with that?
You are using the word "distributing" to mean two
things: "publishing" on the one hand, and
"reselling" on the other. These two cases are
completely different under copyright. When Red
Hat presses CDs and sells them, they are making
copies of Linus's code. When you buy Red Hat CDs
and then resell them, you are not making copies;
you are merely selling copies Red Hat has made.
Again, the example of books makes it obvious. If
I buy a copy of Programming Perl and sell
it, I am not making copies, and O'Reilly has no
authority to stop me. If I buy a copy, scan it
into my computer, and email PDFs of it to all my
friends, I am making copies, and to do so legally
I need permission from O'Reilly.
Now, assuming you do agree to that, explain to me why Red Hat does not have that right. I am asserting that it is because they gave that right up when they agreed to the GPL.
Red Hat never had the right to copy and distribute
Linux without sources. Neither did you. So
neither of you ever had the opportunity to "give up"
that right. However, when you resell Red Hat
binary CD-ROMs you have bought, you aren't making
copies.
And it's really rather simple when you stop
confusing the issue: Are you making
copies? If not, copyright law has no hold over
you. If so, it does, and you need the author's
permission. GPL gives you permission to make
some sorts of copies (source-included) but not
others (binary-only).
Because Red Hat gave up the right to first sale when they agreed to the GPL. Red Hat was deprived of it's right to distribute CDs without distributing source.
Nope. Remember that Red Hat is distributing other people's code, not their own. In the absence of the GPL, Red Hat has no right at all to distribute (for example) Linus's code -- with or without source. If there were no GPL (or comparable license), then in printing and selling its CD-ROMs Red Hat would be violating Linus's copyright. With the GPL in place, Linus has granted unto Red Hat a limited right to distribute Linus's code: a right to distribute it with source but not without. If Linus placed his code in the public domain, or sold the copyright to Red Hat for that matter, Red Hat would have an unlimited right to distribute it -- but he hasn't done that.
You don't have to "agree to the GPL" to be bound by its provisions when you copy GPLed software, because all the "restrictions" of the GPL are actually just the plain old ordinary restrictions of copyright law, by which you were already bound. The GPL isn't a "license agreement" -- a contract -- but rather a "license" -- a unilateral grant of limited rights. It says "You may do these particular things with my code (distributing with source) which otherwise would be illegal -- not anything you want, but some particular things. Other things (distributing without source) remain illegal as they were already."
Just like most EULAs, the GPL grants rights provided that you give up others.
Nonsense. In the absence of a license, you have no right to copy and distribute software someone else wrote. Under the GPL, you have limited right to do so. Of course, if the author has placed the software in the public domain, you have unlimited right to copy and distribute it. However, the presence of a less limited alternative does not mean that the GPL involves "giving up" anything.
Here is an analogy of sorts:
Let us suppose that I have two apple trees on my property, one to the east and one to the west. Lacking my permission, you lack any right to take apples from either tree. If you do so, you are committing a crime: theft. Now, let us say that I permit you to take apples from the eastern tree, but not the western one. You now have limited rights with regards to my trees. If you take from the eastern tree, you are free and legal; but if you take from the western tree, you are committing the same crime as before.
When I granted you permission to take apples from the eastern tree, I was not requiring you to "give up" anything. I certainly did not ask you to give up a right to take apples from the western tree -- since you never had that right in the first place. True, I gave you a limited right, rather than an unlimited one which it was within my power to give -- but it is a vicious lie to say I took anything away from you. I have done nothing but give, and you accuse me of taking away from you something you did not have in the first place!
The same applies to GPLed software. In the absence of a license, you have no right to copy a copyrighted work. To say that the limited grant of rights under the GPL deprives you of anything, or requires you to "give up" other rights, is a vicious lie.
The GPL attempts to restrict first sale rights, by requiring that I distribute source whenever I distribute binaries.
Not so fast. The GPL is a limited grant of rights under copyright; it doesn't "restrict" or "require" anything. All it does is grant you limited rights to do things you couldn't legally do otherwise under copyright law. Thus, its provisions can only apply to activities that are themselves restricted by copyright law. Section 0 (zero) of the GPL makes this clear: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." If someone sells you a CD-ROM containing GPLed software and you sell that CD-ROM to someone else, you're not doing anything that copyright touches. Put another way, you're not doing anything over which the author has power.
There is one extremely unusual case in which you might be on to something, and I suspect it is unintentional in the language of the GPL. Suppose you purchase a boxed copy of Red Hat Linux. It contains binaries and sources, but on separate CD-ROMs. You retain the source CD-ROMs and sell the rest of the box to someone else. It seems to me (IANAL) that you're not doing anything copyright can touch: you're not copying, or making a derivative work, or the like. The buyer does (for the time being) end up without sources, and this is something the spirit of the GPL intends to avoid. However, copyright law has no teeth to prevent this, and the GPL never has more teeth that copyright law itself.
But, I would guess that you would say that the GPL is not as free as the BSD license?
The BSD license gives you even more freedom. It may potentially give the user of your derivative work less "freedom" but that's another matter.
The point of the GPL is to grant particular freedoms to all software users, yes: freedoms to read, learn from, and improve the software they use. It isn't the public domain, and it's not meant to be the public domain. By requiring makers of derivative works to grant their users the same freedoms they themselves enjoy, it aims at maximizing the amount of software for which users have these freedoms.
The (modern, ad-free) BSD license is very close to the public domain. A piece of public-domain software allows its immediate user all the same freedoms a piece of GPLed software does. The difference is that by placing a work in the public domain, an author gives up all the power that copyright law affords him or her. In contrast, the author who places his work under the GPL gives up most of that power, but makes use of some of it to protect the future freedoms of users of the code base.
The GPL does not restrict your rights under copyright law.
Well, it may not restrict you, but you have additional responsibilities. Namely if you make changes you then release to anyone else, you must then also public the source, and attach the same GPL license to that code...
That's not quite accurate. You might want to reread the GPL, particularly section 3, which governs redistribution options.
First off, the GPL doesn't impose any "additional responsibilities" upon you (the licensee of a work) -- it just grants you specific rights, and doesn't grant you others. It grants you the right to release source-and-binary, GPLed derivative works. It doesn't grant you the right to release binary-only derivative works. Releasing source when you release binaries isn't an "additional responsibility"; it's just a term of the right you're granted.
Second, the GPL never requires that you post source publicly. If you give me binaries, you're required to give me source. So it makes sense that if you post binaries publicly, you should post source publicly to ensure your obligations are discharged. But if you're a consultant working for Frobozz Magic Corp. and you customize gcc for them, you don't need to post your diffs publicly at all; you just need to give them to Frobozz.
This second point is important. Some non-GPL licenses require that you give your changes back to some particular party -- usually the original author or current maintainer of the code base. The GPL doesn't enforce that kind of centralization, even with "the public" as the particular party. The GPL ensures that the users of a binary have freedom to get at the sources; the "public review" thing the open-source folks are on about is a nice side effect.
Since the underlying protection mechanism is copyright, companies don't really want to sell it. I mean it would be really great to own Windows XP for a few hundred bucks and then to tell MicroSoft to cease and desist selling MY SOFTWARE. I'd love that. Ain't going to happen.
You are confounding buying a copy of the software with buying the copyright to the software. When you go to the store and lay down money for a box containing a CD-ROM of Windows XP, you are buying the copy -- not buying the copyright. This is rendered somewhat opaque not only by software makers' illicit "licensing" language, but also by news reports of companies "buying software" (meaning the copyright) from one another, e.g. "Microsoft bought Flight Simulator from SimLogic."
The example of books usually clears things up. When I go to the store and buy Philip Pullman's The Golden Compass, I am buying a copy. I own that copy, and I may dispose of it in the usual ways I may dispose of any piece of my property. I may use it, alter it, destroy it, sell it to another person, write notes in the margins, and so forth. However, I do not own the copyright -- the right to make copies (identical or derivative) of Mr Pullman's novel.
Moreover, I am not "licensing" anything. I do not need a "license" from Del Rey Books or from Mr Pullman to read the novel. I already have that right because the book (the copy, that is, not the copyright) is a piece of my property. I also don't need a license or other special privilege to comment on it in public; to excerpt from it under fair use in writing a review; to photocopy it at 200% magnification (and keep both copy and original) in case my vision becomes even worse; to lend the book to a friend; to donate it to a library; or the like. The book is mine, and I may do these things just as legally as I may burn it for fuel.
I would need permission from the copyright owner only to exercise a privilege held exclusive to that owner under copyright law: for instance, to publish copies of it; to record myself reading it alound and distribute the recordings; to translate it into Russian and print that; and so forth. These (among others) are rights over which copyright law grants a monopoly to the owner of a work. Reading, selling, lending, and commenting are not.
Here's another example, taken from patent law, which is similar though not identical to copyright. I recently bought a Ford Taurus car. I did not "license" that car; I own it, whole and entire. I own none of the patents that enter into the car's design, nor did I license any of the patents. Legally, may not manufacture and sell copies of the car. Yet I may sell the car, lend the car, modify the car to improve its performance or appearance (or for any other purpose), create aftermarket add-ons for the car and sell them to other Taurus owners, and so forth. I do not need special permission from Ford to do so.
If you do not believe that you own the CD of Windows XP that you got from your local computer store, then here's a question for you: Destroying other people's property is illegal. If you take that CD and microwave it, whom have you wronged? In microwaving it, you have defaced the physical medium and destroyed the recorded work stored upon it. If that copy belonged to Microsoft, then you are guilty of a crime of vandalism or destruction of property. What do you think?
And if the kernel won't pass traffic it "should", or if you need a configuration option thaty doesn't exist you can write it yourself.
Yes, of course. However, I was more interested in
demonstrating the value of source to someone who
not only doesn't edit the source, but doesn't even
look at it 99.99% of the time: when I do
need it, it's there.
The other point I wanted to get across was that
open-source systems (or, to be fair,
source-available systems) have the possibility of
provability. The behavior of a program is
defined by its code, not its documentation. If a
user comes to me and claims that my firewall is
wrongly breaking his application, and I have the
docs but not the source, my only response is,
"Well, it says here in the docs that it drops 'invalid
traffic', so your app must be putting out some of
that 'invalid traffic' stuff, whatever that is."
The source tells me exactly what is going
on, so I can be confident first that I am
telling the (useful) truth, and second that I
can do something about it.
Forgetting all the myriad reasons source code is useful, the one best thing about getting source code for your product is: it's the ultimate documentation for the program.
Yes, exactly. Here's an example:
My workplace is in the market for a new firewall.
However, we have some staff who periodically need
to do weird things with the network, and want to
make sure that the firewall can be set not to
interfere with them. Many commercial firewalls
do particular classes of filtering (such as flood
filtering, rejection of invalid packets, etc.) in
a way which is not completely documented. So we
can't tell whether they will interfere or not, or
which functions we need to enable or disable in
order to get them to work for our purposes.
Enter OpenBSD. I am not the sort of person who
usually reads kernel source -- whether on the job
or for fun -- but I can pick up the kernel source
for OpenBSD's pf packet filter and know
(for instance)
exactly which combinations of TCP flags it rejects
as invalid. I can then look at a network dump and
tell someone exactly what pf will do with
the traffic represented there. I can, in short,
prove that my firewall will or will not
pass that traffic.
I can't do that with a product that comes with
nothing but a guide to "Basic Firewalling for the
Beginning Networks Staffer" and a command
reference.
You've missed out on iCab, the German-engineered lightweight browser for Mac OS and Mac OS X. It's officially still in beta, but it's quite stable. It supports the usual assortment of standards, Netscape plug-ins, and a nice array of extra features such as image filtering and per-site JavaScript restriction.
To put it bluntly, what's the big
freakin' deal?? Delete it and move on....or am I
missing a larger point?
Well, first of all, spam is theft. But on the
practical side... did you miss that part about
"1400 pieces of spam per person per day in five
years"?
Spamming has no marginal costs. It costs the
spammer the same amount (i.e. nothing -- a free
one-month AOL account) to send a million spam
messages as to send a thousand. Therefore, it
is in every spammer's interest to spam as much as
possible. That is to say, the demand that
spammers place upon the email facility is by
nature unlimited.
However, the demand that legitimate users place
upon the email facility is finite. Compared to
the number of people a spammer targets, a real
user only exchanges email with a small number of
people. Moreover, real users write their email
individually -- they don't send the same message
to a million addresses.
If spam is "legitimized", then that infinite
demand will take over. The number of spam
messages you get will dramatically outnumber
the legitimate messages you get from people you
actually want to converse with. The email facility
will become useless, drowned in the noise, just
like many USENET newsgroups.
Better to get spam then junk snail
mail...spam doesn't have to be recycled.
Interesting you should mention that. When
someone sends you junk snail mail, s/he is paying
for the privilege. In the United States, the
postal service actually makes so much money off
of bulk mail that even though bulk mail gets a
discount for pre-sorting, it ends up subsidizing
non-bulk mail.
The cost of sending bulk mail varies in proportion
to the number of pieces of mail sent. If I want
to send out a million postcards advertising
herbal Viagra, it will cost me about a hundred
times as much as if I sent out only ten thousand.
I have to pay the postage, as well as costs such
as printing, sorting, and getting the things to
the post office.
However, as mentioned above, spamming has no such
marginal cost. If I write a Perl script to send
spam messages, it doesn't cost me any more to
send a million than ten thousand. It just takes
a bit longer.
How can any thief be trusted? How can
any vandal be trusted?
Spam is theft. Never forget that. Sending email
to someone requires the use of resources which
that person legitimately owns or controls, and you
do not. Therefore, if you are habitually sending
email to people who do not want it, you are
appropriating resources to which you have no
right. That's stealing.
It doesn't matter if the commercial offers made in
a spam message are themselves legitimate or if
they are fraudulent. A legitimate advertisement
wrapped around a brick and thrown through my
window is just as offensive to my rights as a
fraudulent advertisement delivered in the same
way.
Opposing spam is not about opposing commerce, or
"commercialization of the Net", or the free
market. It is about defending private property
from trespass and theft -- and defending a useful
service (the email facility) from its ruination.
For if spamming is "legitimized" by crooks such
as these, the email facility as we know it is not
long for this world.
Wouldn't the randomness itself indicate an intent to deceive?
On the contrary. Having a bunch of nodes behind an OpenBSD NAT firewall with state modulation should, it seems to me, look the same to an outside observer as having a single OpenBSD node.
Nevertheless, the documented point of state modulation isn't to hide the fact that you're doing NAT. It's to correct for the fact that many operating systems pick initial sequence numbers poorly, and are thus vulnerable to
sequence prediction attacks. So there may well be ways to tell the difference -- though it would surprise me.
In the end, though, I agree with the sentiment expressed elsewhere under this topic: that ISPs are misguided in trying to penalize intelligent use of their services, but also that users are misguided in playing hide-and-seek with bad ISPs' policy enforcement rather than choosing more honest and professional ISPs.
i've probably dropped a few details here, so feel free to flame me with corrections. that aside, i can see a new open source project brewing: Stealth NAT. A NAT implementation that will rewrite TCP sequence numbers and randomize anything else that would give the impression that multiple machines were in use.
OpenBSD
can actually already do this: it's called the
modulate state directive to the pf
packet filter. From what I can tell, it works
under NAT and bridged filtering as well as straight
routing-type filtering.
Basically, what modulate state does is
rewrite TCP initial sequence numbers using the same
cryptographically strong randomness OpenBSD uses
for its own sequence numbers. For more information, check out the "STATE
MODULATION" section in the
pf.conf manpage.
Syntax aside, which one is better? by better I mean maintain security, smallest hit to bandwidth?
that should be the first concern. If the one that is least intuitive provides more reliable secutity, then go with it and write yourself a script take input in a way thats intuitive to you, and spits it out in the correct format.
of course, IF all things are equall, the go with the one thats easier to set up and maintain.
Believe me, there are other measures involved in picking a firewall besides its security (where there are a lot of decent entries) and its cost in terms of latency. (It isn't likely to hit bandwidth unless it's overloaded, btw.) The factors that I see involved in picking firewall kit shake out into two categories: technical and social, as follows.
Technical factors:
Transparency. For design reasons, we need a bridging firewall, not a routing firewall. (In network jargon, Layer 3 inspection, Layer 2 operation.) That is, the firewall must not appear as a hop in a traceroute; it needs to act like a filtering switch, not a filtering router. Among other things, this makes it harder for an attacker (or a disgruntled user) to know where the firewall is, or how it works.
Security. This is the "no-brainer" of the bunch. A firewall that is itself at any avoidable risk of compromise is simply out of the running. Moreover, a firewall should be as preëmptively secure as possible: it shouldn't need a lot of maintenance to keep it that way. This leads into...
Reliability. I need a system which is not going to fail or fall over, and which is not going to need a lot of ongoing administration for the underlying system. Ideally, it should (for instance) be able to go for months without needing to be patched or upgraded. (Needless to say, it should be a minimal system.)
Versatility. I'd like to be able to do more than just "block this host" or "allow that host to receive nothing but SSH sessions". Being able to easily plug in things like application proxies, tunnels, and other security enhancements is a significant plus. Of course, being sure that these things will work correctly in bridging mode (see above) is essential.
Social factors:
Documentation. I need to be able to bring the other staff up to speed on this system quickly and comprehensively. Complete -- and complete-sounding -- documentation is a must. HOWTOs with sections that say "(Need to finish writing up such-and-so a feature)" do not inspire confidence, in either the firewall itself or in the security administrator pushing that firewall. Moreover, see under "boss-proofness" below.
Ease of use... for our definition thereof. Since we don't have the funding to beef up our security staff, most of the people who will be doing network monitoring here are Unix sysadmin types. They don't like GUIs and Web interfaces of the sort that commercial firewalls-in-a-box offer. They like vi. They like languages that are easy to edit in vi, and which conform to their (okay, "our") Unix-biased idea of how languages should work. (Hint: pf supports shell variables. That's a plus.)
Boss-proofness. My boss's first idea when I mentioned we needed a new firewall was to the effect of, "Let's just do that on our Cisco routers. I can always hire a CCN* if you quit." He's fond of "standard" systems, "supportable" systems, and things he thinks he can easily hire new staff to maintain in the event that current staff might not be around forever.
The next best thing to "You can hire someone with thus-and-so certification, and you're guaranteed they can write new rules for this right away" is something like "This system is so straightforward that anyone who knows Unix can pick it up in an hour and write new rules for it. Oh, and here's the complete documentation -- and I can assure you that there are...
... No surprises." 'Nuff said.
I'm not saying OpenBSD is the only system that can meet these goals. (After all, I'm still waiting on the OpenBSD 3.0 CD to show up so I can set up a testbed to prove it's a better choice than more Cisco gear.) I'm saying it's not quite as easy as "pick whatever works and doesn't eat the network, and wing the rest."
IPtables and Rusty's Netfilter code has been kicking ipfilter's proverbial ass since the first release of Linux 2.4, both in terms of features and security.
Political rhetoric aside, I'm curious about this.
As someone with 5+ years of Linux experience who's
now in the process of choosing a new organizational
firewall, I've taken a long look at
iptables. What
I see is, well, a mess compared to either IPFilter
or OpenBSD's pf.
I'm not talking about the raw feature set. I'm
talking about the syntax for rules, and the
maintainability of large rulesets. The
iptables
rule syntax is made up of numerous, disparate
command-line options, and files of rules become
increasingly hard to read and maintain. In
contrast, IPFilter and pf have what seems
to me to be a clear and easy-to-use rules language
well-adapted to large files of rules. Here's a
comparison, a rule I just tossed together, with
the intent being "allow SSH sessions only from my
internal hosts":
pf: block in proto tcp to any port ssh
pass in proto tcp from 10.11.0.0/16 to any port ssh keep state
Don't get
me wrong -- iptables is certainly Good Enough to
implement IP access rules for a single host, or
to serve as a back-end for firewall toolkits such
as the one Red Hat's added to their latest
releases. But it's sure a surprise to someone
who's spent some time on both when BSD comes up
with a system that's both prettier and easier than
Linux's.
I'm looking to put together a new organizational
firewall soon, and am in the process of selling my
boss on the idea of doing it on OpenBSD with
pf. (His original preference had been to
implement it on our Cisco routers, which strikes
me as a loss for maintainability.) Prior to
settling on OpenBSD, I'd looked into using
IPFilter on Solaris or FreeBSD, but OpenBSD's
reputation clinched it for me.
Nevertheless, I'm wondering: Am I missing
something? Besides rule-for-rule compatibility
with older IPFilter systems (which we don't have),
is there any actual, concrete advantage of
IPFilter over pf?
Since Apple both does the BIOS,
and the OS, no nasty hack like hidden partitions
or weird NT drivers to get things to work
properly.
Funny you should mention that. Actually, as
you'll discover if you ever install Linux on a
Mac, there are several "hidden partitions".
These include:
The partition map itself (type Apple_partition_map0
Two or more partitions to hold the disk drivers (type Apple_Driver_ATA)
One for the I/O Kit drivers (type Apple_Driver_IOKit)
One for firmware patches (type Apple_Patches)
One for the boot loader (type Apple_Bootstrap)
One for the Dark Lord on his dark throne (type Apple_Ring1... er, just kidding.)
Those are what I've discovered on a single
Macintosh (Blue & White G3 model) which had
been running Mac OS 9 and onto which I'd installed
Debian. I'm sure there are even more on a modern
system with Mac OS X. And no, the Mac doesn't use
the PC partition format with its "primary" vs.
"logical" limitations.
Thing is, you're mostly right... in Mac OS
itself, you never have to worry about these things.
Slashdot Mirror
"I am not an Orc!" ... much more sophisticated!"
"This is not WarCraft in space!"
"It's
"I know it's not 3-D!"
--Artanis, Protoss hero unit
Here's a slightly more relaxed variant I came up with some years ago. When Congress spends time debating and passing laws which end up being ruled unconstitutional, it is wasting time, taxpayer money, and its own attention. A law that ends up being ruled null and void, after all, costs just as much in Congressional salary and support costs as a law that is effective. Members of Congress who support and vote for such laws are in effect advocating that Congress throw its time away -- and unnecessarily panic the populace to boot.
Therefore, members of Congress and the voting public need a proportional incentive to spend time debating and passing only laws which are constitutional. One way to do this would be to penalize every member of Congress a fraction of his or her vote for every unconstitutional law he or she votes for.
So, for instance, if Sen. Jones voted for the Communications Decency Act and four other unconstitutional laws in one year, he would end up with only 0.95 votes once the Supreme Court had ruled the laws unconstitutional. Thus, to preserve his own power base, he would have every reason to stick closely to the Constitution.
Moreover, this would be an effective alternative to term limits. Since every member of Congress is likely to vote for a couple of unconstitutional laws every year, challengers would have an automatic advantage over incumbents, since constituents would prefer to be represented by a full vote (which every freshman congressman would bring) rather than just the 90% or 80% of a vote which an incumbent might have left.
Strom Thurmond would be long gone.
I agree that GPL compliance is important, but I am not clear on the legality of this license termination business. What is to keep NuSphere from just downloading a fresh copy of the mySQL sources -- from MySQL AB or another GPL licensee -- and working from there? That copy would, after all, come with a fresh new license.
The doctrine that MySQL AB seems to be pushing is that once an entity violates GPL on a product, not only has that entity's existing license to the product been terminated, but that entity is tainted, forbidden from accepting any future license to that product. This does not appear to be what the GPL itself says. The GPL speaks of voiding the instant license, but not of tainting the offending licensee from accepting a future one.
Does anyone have an explanation for the disparity?
The bylaw in question was a restriction on billboard advertising, incidentally. This case doesn't have terribly much to do with online freedom of criticism, which has usually been a matter of copyright or libel law -- not municipal "visual pollution" regulations.
I am sure that you are receiving dozens of comments on this draft, so I will try to keep mine brief. I am a security technician and sysadmin for a large nonprofit research organization. In your draft's terms I believe I represent a "User" more than a "Reporter" -- though a user with security-specific experience.
It seems to me that your draft undervalues the powers of users to protect themselves independent of the actions of vendors. Users are not entirely reliant upon the vendors of the software they presently use to protect themselves, and they can make use of published security information even if a vendor does not choose to acknowledge or proceed responsibly with the knowledge of a vulnerability. Moreover, they have a need for this information outside of its use in getting patches for existing software.
Most software users are not obligate users of particular pieces of software. They choose among competing software products (or even system designs), and make use of published information about these products in making their choices. They may choose to migrate from an installed software product to a competing one on the basis of published security concerns.
Because users need security disclosure to make informed decisions about the costs and benefits of pieces of software, they have an interest in a fuller and more analytical disclosure than vendors may desire. Large vendors may prefer users who have already purchased their products not to later question this purchase. They may resist the idea that a /pattern/ of vulnerabilities or poor practices exist in their software.
And for a vendor to quietly roll security patches into an "upgrade" may
help the user to avoid being cracked, but does not help him or her make
responsible decisions about future purchases.
Security researchers, it seems to me, have an ethical obligation not to aid criminals in attacking users. However, they (you) do not have an obligation to keep vendors from losing business, or to allow vendors to keep users in the dark regarding the comparative security strengths of software products. In many cases, users would be better served by being advised when the software they are using is poorly designed, has a history of vulnerabilities, and is likely to remain vulnerable to new sorts of attack -- rather than merely being told to wait for a patch, or not told anything independently at all.
A quick Google search for "risks digest eye surgery" yields this link. Pretty frightening stuff, and it does show how well many users have become trained to treat error conditions as part of the normal behavior of computer operating systems and applications.
Anthony, it sounds to me like you're confusing selling a copy you've bought (which is not the kind of "distribution" controlled by copyright law) with making new copies and selling them (which is).
If you buy (or otherwise legally obtain) a Red Hat distribution on CD, you have the right to sell that Red Hat distribution on CD, because it is your property. That is, you can go to the store, buy a CD set, visit me, and sell me the CDs you bought. Neither Red Hat nor Linus have any power to stop you from doing this.
You also have the right to buy a Red Hat CD set, split it up into source CDs and binary CDs, and sell me only the binaries, keeping the sources -- without copying anything.
In addition, because the entirety of Red Hat Linux is licensed under terms that allow you to do so, you have the right to make a copy of the entire distribution (sources included) and sell the copy, retaining the original and the right to use it. This is a right granted to you by the authors of the software contained in Red Hat Linux -- under the GPL, BSDL, and other licenses.
However, you do not have, and never have had, the right to make a copy of only the binaries and sell the copy without providing sources. The programs contained in Red Hat Linux are copyrighted works, and their authors have not given you the permission to copy and distribute their works without sources.
You are using the word "distributing" to mean two things: "publishing" on the one hand, and "reselling" on the other. These two cases are completely different under copyright. When Red Hat presses CDs and sells them, they are making copies of Linus's code. When you buy Red Hat CDs and then resell them, you are not making copies; you are merely selling copies Red Hat has made.
Again, the example of books makes it obvious. If I buy a copy of Programming Perl and sell it, I am not making copies, and O'Reilly has no authority to stop me. If I buy a copy, scan it into my computer, and email PDFs of it to all my friends, I am making copies, and to do so legally I need permission from O'Reilly.
Red Hat never had the right to copy and distribute Linux without sources. Neither did you. So neither of you ever had the opportunity to "give up" that right. However, when you resell Red Hat binary CD-ROMs you have bought, you aren't making copies.
And it's really rather simple when you stop confusing the issue: Are you making copies? If not, copyright law has no hold over you. If so, it does, and you need the author's permission. GPL gives you permission to make some sorts of copies (source-included) but not others (binary-only).
Nope. Remember that Red Hat is distributing other people's code, not their own. In the absence of the GPL, Red Hat has no right at all to distribute (for example) Linus's code -- with or without source. If there were no GPL (or comparable license), then in printing and selling its CD-ROMs Red Hat would be violating Linus's copyright. With the GPL in place, Linus has granted unto Red Hat a limited right to distribute Linus's code: a right to distribute it with source but not without. If Linus placed his code in the public domain, or sold the copyright to Red Hat for that matter, Red Hat would have an unlimited right to distribute it -- but he hasn't done that.
You don't have to "agree to the GPL" to be bound by its provisions when you copy GPLed software, because all the "restrictions" of the GPL are actually just the plain old ordinary restrictions of copyright law, by which you were already bound. The GPL isn't a "license agreement" -- a contract -- but rather a "license" -- a unilateral grant of limited rights. It says "You may do these particular things with my code (distributing with source) which otherwise would be illegal -- not anything you want, but some particular things. Other things (distributing without source) remain illegal as they were already."
Nonsense. In the absence of a license, you have no right to copy and distribute software someone else wrote. Under the GPL, you have limited right to do so. Of course, if the author has placed the software in the public domain, you have unlimited right to copy and distribute it. However, the presence of a less limited alternative does not mean that the GPL involves "giving up" anything.
Here is an analogy of sorts:
Let us suppose that I have two apple trees on my property, one to the east and one to the west. Lacking my permission, you lack any right to take apples from either tree. If you do so, you are committing a crime: theft. Now, let us say that I permit you to take apples from the eastern tree, but not the western one. You now have limited rights with regards to my trees. If you take from the eastern tree, you are free and legal; but if you take from the western tree, you are committing the same crime as before.
When I granted you permission to take apples from the eastern tree, I was not requiring you to "give up" anything. I certainly did not ask you to give up a right to take apples from the western tree -- since you never had that right in the first place. True, I gave you a limited right, rather than an unlimited one which it was within my power to give -- but it is a vicious lie to say I took anything away from you. I have done nothing but give, and you accuse me of taking away from you something you did not have in the first place!
The same applies to GPLed software. In the absence of a license, you have no right to copy a copyrighted work. To say that the limited grant of rights under the GPL deprives you of anything, or requires you to "give up" other rights, is a vicious lie.
Not so fast. The GPL is a limited grant of rights under copyright; it doesn't "restrict" or "require" anything. All it does is grant you limited rights to do things you couldn't legally do otherwise under copyright law. Thus, its provisions can only apply to activities that are themselves restricted by copyright law. Section 0 (zero) of the GPL makes this clear: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." If someone sells you a CD-ROM containing GPLed software and you sell that CD-ROM to someone else, you're not doing anything that copyright touches. Put another way, you're not doing anything over which the author has power.
There is one extremely unusual case in which you might be on to something, and I suspect it is unintentional in the language of the GPL. Suppose you purchase a boxed copy of Red Hat Linux. It contains binaries and sources, but on separate CD-ROMs. You retain the source CD-ROMs and sell the rest of the box to someone else. It seems to me (IANAL) that you're not doing anything copyright can touch: you're not copying, or making a derivative work, or the like. The buyer does (for the time being) end up without sources, and this is something the spirit of the GPL intends to avoid. However, copyright law has no teeth to prevent this, and the GPL never has more teeth that copyright law itself.
It's a pathological case. Those happen.
The point of the GPL is to grant particular freedoms to all software users, yes: freedoms to read, learn from, and improve the software they use. It isn't the public domain, and it's not meant to be the public domain. By requiring makers of derivative works to grant their users the same freedoms they themselves enjoy, it aims at maximizing the amount of software for which users have these freedoms.
The (modern, ad-free) BSD license is very close to the public domain. A piece of public-domain software allows its immediate user all the same freedoms a piece of GPLed software does. The difference is that by placing a work in the public domain, an author gives up all the power that copyright law affords him or her. In contrast, the author who places his work under the GPL gives up most of that power, but makes use of some of it to protect the future freedoms of users of the code base.
First off, the GPL doesn't impose any "additional responsibilities" upon you (the licensee of a work) -- it just grants you specific rights, and doesn't grant you others. It grants you the right to release source-and-binary, GPLed derivative works. It doesn't grant you the right to release binary-only derivative works. Releasing source when you release binaries isn't an "additional responsibility"; it's just a term of the right you're granted.
Second, the GPL never requires that you post source publicly. If you give me binaries, you're required to give me source. So it makes sense that if you post binaries publicly, you should post source publicly to ensure your obligations are discharged. But if you're a consultant working for Frobozz Magic Corp. and you customize gcc for them, you don't need to post your diffs publicly at all; you just need to give them to Frobozz.
This second point is important. Some non-GPL licenses require that you give your changes back to some particular party -- usually the original author or current maintainer of the code base. The GPL doesn't enforce that kind of centralization, even with "the public" as the particular party. The GPL ensures that the users of a binary have freedom to get at the sources; the "public review" thing the open-source folks are on about is a nice side effect.
You are confounding buying a copy of the software with buying the copyright to the software. When you go to the store and lay down money for a box containing a CD-ROM of Windows XP, you are buying the copy -- not buying the copyright. This is rendered somewhat opaque not only by software makers' illicit "licensing" language, but also by news reports of companies "buying software" (meaning the copyright) from one another, e.g. "Microsoft bought Flight Simulator from SimLogic."
The example of books usually clears things up. When I go to the store and buy Philip Pullman's The Golden Compass, I am buying a copy. I own that copy, and I may dispose of it in the usual ways I may dispose of any piece of my property. I may use it, alter it, destroy it, sell it to another person, write notes in the margins, and so forth. However, I do not own the copyright -- the right to make copies (identical or derivative) of Mr Pullman's novel.
Moreover, I am not "licensing" anything. I do not need a "license" from Del Rey Books or from Mr Pullman to read the novel. I already have that right because the book (the copy, that is, not the copyright) is a piece of my property. I also don't need a license or other special privilege to comment on it in public; to excerpt from it under fair use in writing a review; to photocopy it at 200% magnification (and keep both copy and original) in case my vision becomes even worse; to lend the book to a friend; to donate it to a library; or the like. The book is mine, and I may do these things just as legally as I may burn it for fuel.
I would need permission from the copyright owner only to exercise a privilege held exclusive to that owner under copyright law: for instance, to publish copies of it; to record myself reading it alound and distribute the recordings; to translate it into Russian and print that; and so forth. These (among others) are rights over which copyright law grants a monopoly to the owner of a work. Reading, selling, lending, and commenting are not.
Here's another example, taken from patent law, which is similar though not identical to copyright. I recently bought a Ford Taurus car. I did not "license" that car; I own it, whole and entire. I own none of the patents that enter into the car's design, nor did I license any of the patents. Legally, may not manufacture and sell copies of the car. Yet I may sell the car, lend the car, modify the car to improve its performance or appearance (or for any other purpose), create aftermarket add-ons for the car and sell them to other Taurus owners, and so forth. I do not need special permission from Ford to do so.
If you do not believe that you own the CD of Windows XP that you got from your local computer store, then here's a question for you: Destroying other people's property is illegal. If you take that CD and microwave it, whom have you wronged? In microwaving it, you have defaced the physical medium and destroyed the recorded work stored upon it. If that copy belonged to Microsoft, then you are guilty of a crime of vandalism or destruction of property. What do you think?
Yes, of course. However, I was more interested in demonstrating the value of source to someone who not only doesn't edit the source, but doesn't even look at it 99.99% of the time: when I do need it, it's there.
The other point I wanted to get across was that open-source systems (or, to be fair, source-available systems) have the possibility of provability. The behavior of a program is defined by its code, not its documentation. If a user comes to me and claims that my firewall is wrongly breaking his application, and I have the docs but not the source, my only response is, "Well, it says here in the docs that it drops 'invalid traffic', so your app must be putting out some of that 'invalid traffic' stuff, whatever that is." The source tells me exactly what is going on, so I can be confident first that I am telling the (useful) truth, and second that I can do something about it.
Yes, exactly. Here's an example:
My workplace is in the market for a new firewall. However, we have some staff who periodically need to do weird things with the network, and want to make sure that the firewall can be set not to interfere with them. Many commercial firewalls do particular classes of filtering (such as flood filtering, rejection of invalid packets, etc.) in a way which is not completely documented. So we can't tell whether they will interfere or not, or which functions we need to enable or disable in order to get them to work for our purposes.
Enter OpenBSD. I am not the sort of person who usually reads kernel source -- whether on the job or for fun -- but I can pick up the kernel source for OpenBSD's pf packet filter and know (for instance) exactly which combinations of TCP flags it rejects as invalid. I can then look at a network dump and tell someone exactly what pf will do with the traffic represented there. I can, in short, prove that my firewall will or will not pass that traffic.
I can't do that with a product that comes with nothing but a guide to "Basic Firewalling for the Beginning Networks Staffer" and a command reference.
You've missed out on iCab, the German-engineered lightweight browser for Mac OS and Mac OS X. It's officially still in beta, but it's quite stable. It supports the usual assortment of standards, Netscape plug-ins, and a nice array of extra features such as image filtering and per-site JavaScript restriction.
Well, first of all, spam is theft. But on the practical side ... did you miss that part about
"1400 pieces of spam per person per day in five
years"?
Spamming has no marginal costs. It costs the spammer the same amount (i.e. nothing -- a free one-month AOL account) to send a million spam messages as to send a thousand. Therefore, it is in every spammer's interest to spam as much as possible. That is to say, the demand that spammers place upon the email facility is by nature unlimited.
However, the demand that legitimate users place upon the email facility is finite. Compared to the number of people a spammer targets, a real user only exchanges email with a small number of people. Moreover, real users write their email individually -- they don't send the same message to a million addresses.
If spam is "legitimized", then that infinite demand will take over. The number of spam messages you get will dramatically outnumber the legitimate messages you get from people you actually want to converse with. The email facility will become useless, drowned in the noise, just like many USENET newsgroups.
Interesting you should mention that. When someone sends you junk snail mail, s/he is paying for the privilege. In the United States, the postal service actually makes so much money off of bulk mail that even though bulk mail gets a discount for pre-sorting, it ends up subsidizing non-bulk mail.
The cost of sending bulk mail varies in proportion to the number of pieces of mail sent. If I want to send out a million postcards advertising herbal Viagra, it will cost me about a hundred times as much as if I sent out only ten thousand. I have to pay the postage, as well as costs such as printing, sorting, and getting the things to the post office.
However, as mentioned above, spamming has no such marginal cost. If I write a Perl script to send spam messages, it doesn't cost me any more to send a million than ten thousand. It just takes a bit longer.
How can any thief be trusted? How can any vandal be trusted?
Spam is theft. Never forget that. Sending email to someone requires the use of resources which that person legitimately owns or controls, and you do not. Therefore, if you are habitually sending email to people who do not want it, you are appropriating resources to which you have no right. That's stealing.
It doesn't matter if the commercial offers made in a spam message are themselves legitimate or if they are fraudulent. A legitimate advertisement wrapped around a brick and thrown through my window is just as offensive to my rights as a fraudulent advertisement delivered in the same way.
Opposing spam is not about opposing commerce, or "commercialization of the Net", or the free market. It is about defending private property from trespass and theft -- and defending a useful service (the email facility) from its ruination. For if spamming is "legitimized" by crooks such as these, the email facility as we know it is not long for this world.
On the contrary. Having a bunch of nodes behind an OpenBSD NAT firewall with state modulation should, it seems to me, look the same to an outside observer as having a single OpenBSD node.
Nevertheless, the documented point of state modulation isn't to hide the fact that you're doing NAT. It's to correct for the fact that many operating systems pick initial sequence numbers poorly, and are thus vulnerable to sequence prediction attacks. So there may well be ways to tell the difference -- though it would surprise me.
In the end, though, I agree with the sentiment expressed elsewhere under this topic: that ISPs are misguided in trying to penalize intelligent use of their services, but also that users are misguided in playing hide-and-seek with bad ISPs' policy enforcement rather than choosing more honest and professional ISPs.
OpenBSD can actually already do this: it's called the modulate state directive to the pf packet filter. From what I can tell, it works under NAT and bridged filtering as well as straight routing-type filtering.
Basically, what modulate state does is rewrite TCP initial sequence numbers using the same cryptographically strong randomness OpenBSD uses for its own sequence numbers. For more information, check out the "STATE MODULATION" section in the pf.conf manpage.
Believe me, there are other measures involved in picking a firewall besides its security (where there are a lot of decent entries) and its cost in terms of latency. (It isn't likely to hit bandwidth unless it's overloaded, btw.) The factors that I see involved in picking firewall kit shake out into two categories: technical and social, as follows.
Technical factors:
Social factors:
The next best thing to "You can hire someone with thus-and-so certification, and you're guaranteed they can write new rules for this right away" is something like "This system is so straightforward that anyone who knows Unix can pick it up in an hour and write new rules for it. Oh, and here's the complete documentation -- and I can assure you that there are ...
I'm not saying OpenBSD is the only system that can meet these goals. (After all, I'm still waiting on the OpenBSD 3.0 CD to show up so I can set up a testbed to prove it's a better choice than more Cisco gear.) I'm saying it's not quite as easy as "pick whatever works and doesn't eat the network, and wing the rest."
Whoops. That would be a typo.
Political rhetoric aside, I'm curious about this. As someone with 5+ years of Linux experience who's now in the process of choosing a new organizational firewall, I've taken a long look at iptables. What I see is, well, a mess compared to either IPFilter or OpenBSD's pf.
I'm not talking about the raw feature set. I'm talking about the syntax for rules, and the maintainability of large rulesets. The iptables rule syntax is made up of numerous, disparate command-line options, and files of rules become increasingly hard to read and maintain. In contrast, IPFilter and pf have what seems to me to be a clear and easy-to-use rules language well-adapted to large files of rules. Here's a comparison, a rule I just tossed together, with the intent being "allow SSH sessions only from my internal hosts":
iptables :
iptables -A INPUT -s 10.11.0.0/16 -p tcp -o tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -o tcp --dport 22 -j DENY
pf:
block in proto tcp to any port ssh
pass in proto tcp from 10.11.0.0/16 to any port ssh keep state
Don't get me wrong -- iptables is certainly Good Enough to implement IP access rules for a single host, or to serve as a back-end for firewall toolkits such as the one Red Hat's added to their latest releases. But it's sure a surprise to someone who's spent some time on both when BSD comes up with a system that's both prettier and easier than Linux's.
I'm looking to put together a new organizational firewall soon, and am in the process of selling my boss on the idea of doing it on OpenBSD with pf. (His original preference had been to implement it on our Cisco routers, which strikes me as a loss for maintainability.) Prior to settling on OpenBSD, I'd looked into using IPFilter on Solaris or FreeBSD, but OpenBSD's reputation clinched it for me.
Nevertheless, I'm wondering: Am I missing something? Besides rule-for-rule compatibility with older IPFilter systems (which we don't have), is there any actual, concrete advantage of IPFilter over pf?
Funny you should mention that. Actually, as you'll discover if you ever install Linux on a Mac, there are several "hidden partitions". These include:
Those are what I've discovered on a single Macintosh (Blue & White G3 model) which had been running Mac OS 9 and onto which I'd installed Debian. I'm sure there are even more on a modern system with Mac OS X. And no, the Mac doesn't use the PC partition format with its "primary" vs. "logical" limitations.
Thing is, you're mostly right ... in Mac OS
itself, you never have to worry about these things.