> Yes, this would work, if you, for some reason, wanted to arbitrarily limit the > number of Heliocentric planets to nine
The problem here is that the number of known small iceballs out there past Neptune is growing fairly rapidly, and if we classify them all as planets, we'll no longer be able to teach elementary school children the list of planets.
Personally, I think Pluto should be grandfathered in just because it was classified as a planet before its size was known, but apart from Pluto anything with less than about 5% of Earth's mass should be considered a "minor planet" or "planetoid" if it's roughly spherical, a comet if it has a "tail" pointing away from the primary more than about twice its diameter in the other direction (at periapsis), or an asteroid (or meteoroid, or speck of dust if it's really small). This is all assuming that the bulk of its acceleration relative to the rest of the system is due to the gravitational pull of a primary; if a planet has a larger impact on its motion than the primary does, then it's a moon. (That leaves the definition of "primary" to be sorted out later, but for the purposes of the solar system the Sun is obviously the only primary.)
> This is important if the server *wants* cookies to expire, such as if used for authentication.
If you want the cookie to expire, then put an expiration date in your cookies table. You can also send the expiration date to the browser, but be aware that some browsers allow the user to arbitrarily modify the expiration date at the browser end. You *could* encode the expiration date into the cookie, but then things start getting complicated and you end up with needlessly complex cryptographic schemes. Bah. Needless complexity is a root of all kinds of evil. KISS. Put the expiration date in the cookies table. You need to do that anyway, so that a daemon can periodically delete expired records from the table. Otherwise the cookie table grows without bounds.
The cookies table really only needs four fields: token, expiration, clientip, and either userid or sessionid. The magic token itself (i.e., the string you send to the browser and have it send back to you) can be the primary key. The client's IP address is needed only if the cookie is to be limited to that IP (otherwise can be null), and either a session ID (if you allow anonymous sessions, e.g., in a "shopping cart" scenario wherein the user might do things you'll want to remember before identifying himself) or a user ID (if you hand out the cookie on login). Some rare scenarios might want both sessionid and userid fields, but usually only one of them should be required. Anything else you need to remember can be in another table keyed on the sessionid or userid value.
Just plain old ordinary lemon juice. Nothing added. And don't chug it, just sip. It should take you about an hour to finish off a 32-oz glass. Then you go for a refill. Other juices that work include white grapefruit, lime, or a mixture of lime and cranberry.
> Ironically this could force China to improve the overall > education level, which would of course backfire as an > educated populace is much more difficult to control.
In some ways, an educated populace is easier to control. Of course, it depends somewhat on what kind of control you're talking about, but an educated populace is much more likely to comply with or succumb to insane bureaucratic-type requirements, e.g., absurd licensing fees, mountains of red tape, and so on and so forth. The proles just ignore you and go on about their lives.
> Allchin: Before you had to get RMS software for a client from someplace else. We're making it simpler.
That's really great to hear. I mean, after you go to the CFO for a PO to an OEM and UPS a batch of PCs from CWH to IT, it'd sure be nice if you didn't have to GET your RMS software from the FSF, roll it into an MSI for the ITW to do an SRO via GP.
On a side note, is it just me, or did anyone else notice that this article had more than its fair share of TLAs?
> I'd suggest using a text-only email client if you can stand it.
For Windows users, I generally recommend Pegasus Mail. It's easy to use, but it's also excellent. If it were available for all the major operating systems, I'd probably still be using it myself, but it is pretty much Windows only. Regarding malware, it handles that in the best possible way: if the filetype of the attachment is anything even vaguely executable, and you try to save it, it displays a warning dialog with "Virus" in the title and Cancel as the default action. You _can_ save an executable attachment that someone sends you to the filesystem, but the default is not to to so. As far as _launching_ attachments, Pegasus Mail doesn't. It does have the ability to display.png,.jpg, and.gif attachments, and in recent versions has its own rendering engine for HTML, and of course for plain text. Any other filetype you can just save to the filesystem.
Pegasus Mail is also very mature, being one of the oldest GUI-enabled mail clients in existence, possibly the oldest, and older than a lot of text/console ones as well. (Pegasus itself started life as a text/console client, adopting the GUI circa 1991.) Having been around for a while, it's fairly feature-complete. For instance, its filtering system supports regular expressions, flow control, and a wide variety of possible actions (including the ability to execute a predetermined external command, send the contents of a predetermined file back to the sender, highlight the message in a certain color in the list of messages, add or remove the sender from a distribution list,...). I have looked high and low and far and wide for another mail client with anything approaching Pegasus Mail's functionality, and the only thing that even comes close is Gnus. (Gnus, however, is not really GUI-enabled, does not do things like checking for new messages as asynchronously as might be desired, and has a MUCH higher learning curve.) Clients like Evolution and Eudora look like toys next to Pegasus Mail, to say nothing of junk like MSOE.
It's not open-source, but it has always been free to download and use, and it's possible to get permission to redistribute it (e.g., if you are an ISP). If you're looking for a good email client for Windows, I highly recommend having a look at Pegasus Mail.
And yes, if you're trying to avoid malware, it is absolutely critical that you don't use Outlook or Outlook Express. I don't recommend Thunderbird easier; it doesn't AFAIK execute attachments automatically like Outlook can sometimes be made to do, but it does make it *way* too easy to launch one without significant forethought; basically all you have to do is click, and it's running. Not good. Plus it's feature-poor anyhow, and there are much better options.
> How easy is it to change the value of the USER environmental variable in Mac OS X?
Trivial. The environment belongs to the process that is executing therein, and can be changed by that process in any way at any time. A child process inherits its values from the parent process, and shells (csh, tcsh, bash, whatever you happen to be using) by design allow the user to change environment variables at will and launch arbitrary child processes. This is all normal and expected, a part of the regular functioning of the system.
> Is there a universal username that is member of the admin group on all Mac OS X installations?
This is a better question, and one that I can't answer with any degree of certitude. I know that root _login_ is not enabled by default on OS X, but it may be that the account does exist.
Either way, nothing should ever trust the value of an environment variable for anything relevant to security, on any operating system.
> Go ahead try: setenv USER 'name', and see what happens. Want to know? The next env > command will show USER=name. Then do a 'who' command, and guess what? "who" command > returns whatever name was already logged in, not the newly-set environment variable. > Oh no, doesn't work does it? Maybe relaunch the console, try again. Then what happens? > Run the command 'env' and you get the original, valid logged-in username, NOT the > 'made up name' from the half-assed setenv USER 'trickadminname'. Trivial on Windows? > Too bad, shoulda bought a Mac, or at least wiped the drive and loaded Linux, BSD, etc.
The behavior you describe is the behavior on all systems, because the environment belongs to a particular process, not to the logged-in user. It is normal for a given process to modify its environment. If you want the USER variable to be set to a particular value for all of your processes, you have to change it in a configuration file. (Yes, you can do this on OS X.)
The only difference on Windows is that the who utility is not included with the operating system, so if you want to be able to type who and get any meaningful result you have to download a third-party who utility.
The vulnerability happened because something _trusted_ an environment variable that shouldn't have, since it is known and expected that users are permitted to set environment variables to any value they want.
As far as an equivalent attack on Windows, there is actually an unpatcheable one due to a design flaw in the Win32 API; however, it's much more difficult to exploit than setting an environment variable and probably requires direct user interaction (i.e., probably cannot be automated like this could), since it is necessary to identify a process that is running with special privileges and send an event to a window owned by that process. There is almost always a privileged process running on Windows (antivirus software is a prime candidate), but one has to be identified, and exploiting it is complicated.
As for this OS X vulnerability, it's old news, a story about something that was already patched.
> I'd quit if I had a choice, but I really need the money, yet I'm unable to look > for a new job because of lack of time.
If you are working overtime every week (not just an hour or two but considerable overtime, as you seem to imply) and can't afford to take any time off, your budget is out of control. Tighten it.
Are you paying for cable TV? The way you describe your free time quota, it sounds like you don't have _time_ to watch TV, and if you did have time, you could just as well read slashdot, right? Right, drop the cable, save twenty bucks a month, or more.
Now, about food... if you're anything like typical, a little discipline can trim 30% off your food budget without even *messing* with sales or coupons, and without going totally spartan. (Somebody said beans and rice... but you don't necessarily have to go that extreme, just cut out the processed foods and deli stuff.)
You're not renting movies at the video store, are you? Find a public library, and drop them off on time even if you haven't had a chance to watch them. (You can always borrow them again, which costs you nothing, versus late fees which don't cost nothing, typically.)
Besides food, gas, clothes, and regular payments (loans, rent/mortgage, &c), what else are you buying? Don't. You don't need it. Even the stuff you think you need, you don't need it. Speaking of that: never carry money, unless you have a specific need to spend it. Seriously. Your wallet? Keep your ID in it, but leave the money at home. If the thing you're thinking of buying isn't worth planning ahead to buy, it's not worth spending the money. Don't carry a checkbook either, except when you have a specific need to write a check for a specific and unavoidable purpose. Credit cards? Get rid of them, or lock them in a box in the attic and keep the key under something heavy in the basement. Credit cards make it too darned convenient to part with your money.
Basically, what you're doing here, is you're buying your sanity back instead of all the less important things you've _been_ spending your money on. When you've paid off your credit card depts and saved up three months' expenses, then you can decide whether to quit your job and look for a different one (which, if they're still forcing large amounts of unwanted overtime down your throat, will probably be a good idea at that point).
Yes, you *can* pay off your debts and save money on what you're making. I paid off my college loans in four years, and most of that was while I was working fast food and making minimum wage; during the same timeframe I also saved up for and bought a $2000 computer. You just have to spend less than you make. Prioritize the things your money goes into, with the most important ones at the top of the list, and then draw a line through the middle of the list at the point where the stuff above the line adds up to about 80% of your income. Cut off the bottom part of the list, everything below the line.
I say 80%, not 90%, because you will have unexpected things come up that you didn't anticipate, but which are important enough to make the top part of the list. If you plan to spend 90% of your money, you end up saving little or nothing. Plan to spend 80%, and you can actually save 10%. Paying off debts counts as a form of saving and indeed is the preferred form if the debt has higher interest than you can make on a savings account. Low-interest debts are less urgent to pay off, but paying them off still counts as saving, because it improves your net worth. So, when I say, "save 10%", I mean, "use 10% to pay off debts and/or put in savings". If your savings account goes past about six months' expenses, then there are other forms of savings you should look into (mutual funds...), but I get the impression that's not something you have to worry about just yet.
> People yield code. I was replying to the statement that the Linux kernel is more popular > with both individuals and companies because it is more flexible (from a copyright > standpoint) than HURD.
No.
Linux is more popular than HURD because at certain critical points in history it was "working" and "ready" for definitions of "working" and "ready" that could not really be applied to HURD at the time. Basically, Linux was in the right place at the right time. HURD never showed up to the party, and there was a licensing lawsuit connected with BSD at a particularly critical point in time which left it just a little behind in just the wrong ways at just the wrong time, allowing Linux to get "ahead" in terms of mindshare and popularity in the developer community. Consequently, there was a several-month time window, at a particularly important time in history (right about when a lot of college undergrads were first getting net access) when if you wanted a freely-available, freely-modifiable, freely-redistributable operating system, Linux was _the_ obvious choice. That gave it a leg up, got a lot of people involved with improving it, and made it the leading and most popular free OS. Nothing has yet managed to unseat it from that position.
Just to be clear, I'm not saying that the FSF's policies haven't hampered HURD development. They likely have. What I'm saying is that that is not the key important reason why Linux is ahead of HURD (both in terms of popularity and development cycle). The key reason is because Linus had working, usably complete code at an important time when the FSF (in terms of a kernel) did not.
If the timing had worked out differently, the HURD might have been in the leading position, in spite of the FSF's (admittedly rather strict) copyright policies. It is notable that a number of the FSF's *other* projects, despite said policies, are leading implementations in their respective niches, because those projects were finished to the degree they needed to be and working to the degree they needed to be when they needed to be. Emacs for instance was there enough and working enough (for _most_ of the folks who wanted an Emacs, albeit not for Lucent) that XEmacs is just another, somewhat less popular alternative, rather than completely eclipsing Gnu Emacs as Linux has done to HURD.
> From the article: > The filter cannot be broken in the same sense that one cannot crack time-tested > public-key encryption functions such as those already used for Internet commerce > and banking applications.
In _what_ same sense. Public-key cryptography relies on the attacker not having any access to the computer system where the private key is stored. Otherwise, it can be broken very very easily. If this filter cannot be broken in the "same sense", it implies only that it cannot be broken by someone without any access to the system running the filter. Is that really all they're claiming? That doesn't seem like a particularly useful or meaningful claim.
> In that aspect, it's essentially a bullet-proof technology.
> But it is still possible to find out what it does in practice, since the nature of the > data it processes is known. Just run it in a simulation and see what it does. > No reverse-engineering required.
Actually, that's one of the most common and useful reverse engineering techniques: run it in a controlled environment and see what it does. The people who are claiming that they have a mathematical proof that this thing _can't_ be reverse engineered are either very dishonest or very ignorant about computer technology, likely both.
"imposible" is not one of the four words that Schneier said make no sense in the context of security, but it could have been; certainly in this context it means basically the same thing as "unbreakable" or "absolute".
> So, it has been mathematically been proben impossible to reverse engineer... > has it also been mathematically proven impossible to socially engineer?
I'd like to see a definition of reverse engineering that excludes social engineering without making a special exception for it. Any such definition would be so narrow that it would also exclude numerous other common types of reverse engineering. (No, it won't do to say that the information obtained by the process has to be obtained directly from the item that is being reverse engineered. Such a definition excludes several common types of non-social reverse engineering, e.g. wherein timing and network traffic are analyzed.)
Obviously it hasn't been mathematically proven to be impossible to social-engineer, has it? Given that, it follows almost as a correllary that it also hasn't been mathematically proven to be possible to reverse engineer, given any reasonable definition of "reverse engineer". The claim sends the needle on my bogosity detector spinning.
> They claim they have proven that the it cannot be determined by other what the program does.
Yeah, but it's a totally bogus claim. I want thirty minutes in a room with the "mathematician" who "proved" this and a blackboard. It isn't possible to make code that can't be reverse engineered because, fundamentally, the processor that executes the code has to know what the low-level operations are in order to execute them. Quite aside from that, in order to prove that code can't be reverse-engineered, you'd have to define in mathematical terms either what reverse engineering is or how it works. Any such definition is likely to have substantial holes in it.
Just for instance, Germany could potentially get into a civil war scenario pretty much overnight. The political climate in Germany is outright scary. Deep emotional baggage left over from the last big war is a major formative factor in the current culture (and counterculture). The law and the majority of the population both support the enforced suppression of distasteful political ideas and symbols, yet copycat groups giving lip service to the very ideas and symbols that the majority most want to suppress are more common in Germany than anywhere else in the world; many of these groups are personality cults centered around charismatic leaders.
Of course, that all _could_ come to nothing; the emotional baggage could fade in a generation or two, and the whole thing could blow over. But, that isn't what happened last time.
As I said, there also could be war in the Middle East at any time. The outcome would be predictable (and the impact on the rest of the world limited) _provided_ the US and Europe and Russia all stay out of it, but if any of those countries became involved, the predicatability would go right out the window.
> Which means that browser type checking will need to > remain pretty much for the forseable future.
Maybe, but if IE7 has the major things content developers want (cheifly: alpha channel support, this, and good support for CSS selectors), I think it'll be out for less than a year before you start to see a lot of websites refusing to support IE6 at all. There are already a *lot* of webmasters who are *tempted* to drop support for IE6 but talk themselves out of it on the grounds that IE has the largest market share. The improvements that can be made both to the web development process and the user experience (and also to accessibility) by dropping IE6 support are substantial, and if IE7 delivers most of these improvements, webmasters may again start telling users to upgrade their browsers, as was quite common practice during the 90s.
> Microsoft would never come up with such a catchy name [as MicroPod], > they'd call it something stupid and bland like MS Portable Audio
Indeed. Other names they might actually use include Microsoft Music, Microsoft Sound, Microsoft Listen, Microsoft Media Player, Microsoft Portable Player, or maybe just Microsoft Player.
> I see what you mean, but I'm a skeptical that you can really predict things like > this at the level of "Eastern Thinking" vs "Western Thinking".
Some things are more predictable than others. I'm not saying I know the future, just that I judge war between the US and China as unlikely in the current political setting. (The political setting can, of course, change, and does change over time...) It's not just that Eastern and Western thinking are different but that, unlike before WWII, both sides are now aware of the differences and take them into account in various ways. The political situation between the US and China currently is, in a word, stable. Also the situation between the US and Russia is quite stable now.
In terms of world wars starting, I'd be more worried about nations nobody's been paying much attention to yet, or about civil wars starting _within_ certain internationally significant nations and causing international fallout. There are, for instance, a couple of EU member nations that, if they were to have a civil wars spring up, it could have thoroughly unpredictable consequences internationally. No, I don't mean the balkans. There could be war in the balkans at any time, of course, but I don't think it would spark WWIII, at least, not right now. But it is very hard to predict what would happen at the international level if e.g. Germany were to have a civil uprising, because it's very hard to say whether and how various nations would become involved.
The Middle East, of course, is *always* politically unstable (well, at least for the last four millennia or so) and a potential source of trouble of one kind or another. The only thing I can safely predict about the middle east is that there won't be a real lasting peace agreement reached.
> In related news, my pants were the leading distribution > method for iPod nanos, in the USA, in California, in my > house, yesterday.
Ah, but my research shows that iPod nanos are on the way out, because the results I've just collated indicate that xmms is now the leading method of listening to music for middle-aged college-educated male computer geeks between the ages of 30 and 32 using FreeBSD, in small-town USA, in Ohio, at my house, for the last several days running. Also, according to the same study, the leading music writer now is apparently J.S. Bach, with the performer market shared among several major players, notably Wendy Carlos, Karl Munchinger, and the Stuttgart Chamber Orchestra. Meanwhile, AMD market share hovers around 50% adoption in the same demographic.
No, you've badly misunderstood him. I'd go so far as to say you completely missed what he was talking about. (Either that or you're using a straw man, but I'll give you the benefit of the doubt and consider your post sincere.)
> There was a study which found that the better the reader, the less likely they were to > notice spelling errors when reading for comprehension. There was a famous case where > they added a small article (I believe it was "a") at the end of a line, and at the > beginning of the next. The faster readers (who I'm sure you're aware also tend to have > higher comprehension) were less likely to notice this than the slower readers.
That's all true, but these are not the type of mistakes the other poster was talking about. Sure, mistakes like doubling an article, or minor misspellings like "rediculous" or "preposterus" are unlikely to be noticed by good readers. Its also true (ahem) that in some cases, depending on the sentence, substitution of homophones will be so immediately apparent that the brain can correct the mistake immediately before reading any more of the sentence, and in that case the flow of reading is not substantially interrupted.
However, the other poster was (especially in context, i.e., if you are familiar with the previous post to which he refers) very clear that he was talking about another sort of mistake altogether, the sort wherein looking only at the first part of the sentence leads to an incorrect parsing with a different meaning. The grandparent and the frist psot were both talking about those types of errors. There not only occasionally present on slashdot, but actually fairly common. These are the sorts of errors that present a problem.
Nobody (except maybe the occasional grammar nazi, sure) is getting very worked up over affect/effect, for instance, because the wrong meaning seldom survives the initial parsing phase; it doesn't fit the preceding context, and the brain discards it and selects the intended meaning immediately. It also helps that both words function as the same parts of speech. A fluent speaker of the language will generally have no problem here, and we do indeed "get over it" pretty easily.
Homophones (like its and it's) or near-homophones (like you're and your and yore or their and they're and there) that are different parts of speech are especially likely to be problematic. They're not *always* a problem, because sometimes the structure of the preceding portion of the sentence clarifies which meanings are possible. However, in many cases the _end_ of the sentence has to be read before the error can be understood and mentally corrected, and *those* are the cases we're complaining about.
> The question is: is Perl becoming a LISP implementation?
It depends how you look at it. From one angle, Perl6 looks like an advanced Lisp variant. However, if you walk around to another side, it looks like an improved version of Smalltalk.
Perl is a multiparadigmatic language. Perl5 supports functional programming in a limited way, and it supports OO in a limited way. Both are sufficiently implemented in Perl5 to be useful, but neither is really complete. In Perl6, both of these paradigms become full-blown entirely implemented first-class paradigms. The contextual paradigm that was pioneered in earlier Perl versions also becomes a full-blown and entirely implemented first-class paradigm, and of course there is still the procedural paradigm for those who want it.
So with Perl6 you can use the right tool for the right job, without having to entirely switch languages.
> Without that book, Perl can just be extremely weird, after reading the book it at > least makes sense in its own world, no matter how unconnected that world seems to > be to the rest of the universe:-)
Has it ever occurred to you that maybe it's the rest of the universe that's weird?
(Okay, okay, so maybe *I'm* weird... Nah, couldn't be. Thinking in Perl isn't weird, is it?)
> And thats why they should use the GPL- to make sure it *remains* free
This is silly. BSD code remains free. Nobody can come along and say, "Because I based my proprietary work on this, you can no longer have it." It's still free. Another work _based on_ it may not be free, of course, but the work _itself_ is still free.
The GPL is all about what _derived works_ can or cannot be made and how they can or cannot be distributed. The work itself is actually less free than it would be under the BSD license, because there are a number of (sometimes complex) situations in which it cannot be used (most notably, when you also want to link against a library you don't have rights to; under the GPL, you can't do that, at least, not if you intend on redistribution of any kind). If I use the BSD license for my code, I can be confident that, even if I accept patches from others, I can still always use my program for whatever I want, however I want. I can use it in a personal capacity at home, or I can take it to a future job with me and use it there, or whatever I choose to do with it.
Other people can do these things also, but that does not restrict what *I* can do.
If I use the GPL for my code, and I don't accept any patches from anyone else, then I can still relicense my code however I want, but, importantly, if I use the GPL and then start accepting patches from others, basing my own changes on those patches, and so on, the code is no longer all mine, and I lose certain rights. If I then want to link against a proprietary library, I can't. If I want to use the code (which is primarily my own code, remember) in a job context as part of a larger work that uses a proprietary license, I cannot. I'd have to recreate my work from scratch. Who wants to do that? Boring.
The FSF claims that the GPL is all about guaranteeing freedoms. This is rhetoric. Putting the code in the public domain would forever guarantee[1] everyone's freedom to use, modify, and redistribute it. What it wouldn't do, which the GPL does, is place all kinds of restrictions on the conditions under which they can do so.
The only reason you should use the GPL for your code is if you *want* to restrict what people can use it for, e.g., if the idea that someone might include some of your code in a proprietary product bothers you. Such an idea does not bother me. I wrote the code because I wanted to be able to use it, and I released it (as opposed to just keeping it on my hard drive) because I thought other people might find it useful too. What exactly they use it for is neither here nor there as far as I'm concerned (as long as they understand I'm not contractually bound to support it or anything, which is why there's a warranty disclaimer in practically every license, certainly in all versions of the GPL as well as the BSD and MIT licenses).
If you just want to guarantee everyone the rights to your code, the BSD license is fine. The purpose of the GPL is to get some guarantees *back* from the people who use your code. That's a different thing.
[1]: Well, okay, there's the patent issue, but I'm not convinced any license you put your code under can prevent some other clown from coming along and filing a patent. The PTO is not going to check, before granting a patent, whether there are any GPLv3 works that implement the technique and, if so, decline to grant the thing.)
Slashdot Mirror
> Yes, this would work, if you, for some reason, wanted to arbitrarily limit the
> number of Heliocentric planets to nine
The problem here is that the number of known small iceballs out there past Neptune is growing fairly rapidly, and if we classify them all as planets, we'll no longer be able to teach elementary school children the list of planets.
Personally, I think Pluto should be grandfathered in just because it was classified as a planet before its size was known, but apart from Pluto anything with less than about 5% of Earth's mass should be considered a "minor planet" or "planetoid" if it's roughly spherical, a comet if it has a "tail" pointing away from the primary more than about twice its diameter in the other direction (at periapsis), or an asteroid (or meteoroid, or speck of dust if it's really small). This is all assuming that the bulk of its acceleration relative to the rest of the system is due to the gravitational pull of a primary; if a planet has a larger impact on its motion than the primary does, then it's a moon. (That leaves the definition of "primary" to be sorted out later, but for the purposes of the solar system the Sun is obviously the only primary.)
> This is important if the server *wants* cookies to expire, such as if used for authentication.
If you want the cookie to expire, then put an expiration date in your cookies table. You can also send the expiration date to the browser, but be aware that some browsers allow the user to arbitrarily modify the expiration date at the browser end. You *could* encode the expiration date into the cookie, but then things start getting complicated and you end up with needlessly complex cryptographic schemes. Bah. Needless complexity is a root of all kinds of evil. KISS. Put the expiration date in the cookies table. You need to do that anyway, so that a daemon can periodically delete expired records from the table. Otherwise the cookie table grows without bounds.
The cookies table really only needs four fields: token, expiration, clientip, and either userid or sessionid. The magic token itself (i.e., the string you send to the browser and have it send back to you) can be the primary key. The client's IP address is needed only if the cookie is to be limited to that IP (otherwise can be null), and either a session ID (if you allow anonymous sessions, e.g., in a "shopping cart" scenario wherein the user might do things you'll want to remember before identifying himself) or a user ID (if you hand out the cookie on login). Some rare scenarios might want both sessionid and userid fields, but usually only one of them should be required. Anything else you need to remember can be in another table keyed on the sessionid or userid value.
Just plain old ordinary lemon juice. Nothing added. And don't chug it, just sip. It should take you about an hour to finish off a 32-oz glass. Then you go for a refill. Other juices that work include white grapefruit, lime, or a mixture of lime and cranberry.
> Ironically this could force China to improve the overall
> education level, which would of course backfire as an
> educated populace is much more difficult to control.
In some ways, an educated populace is easier to control. Of course, it depends somewhat on what kind of control you're talking about, but an educated populace is much more likely to comply with or succumb to insane bureaucratic-type requirements, e.g., absurd licensing fees, mountains of red tape, and so on and so forth. The proles just ignore you and go on about their lives.
Straight from the horse's mouth...
> Allchin: Before you had to get RMS software for a client from someplace else. We're making it simpler.
That's really great to hear. I mean, after you go to the CFO for a PO to an OEM and UPS a batch of PCs from CWH to IT, it'd sure be nice if you didn't have to GET your RMS software from the FSF, roll it into an MSI for the ITW to do an SRO via GP.
On a side note, is it just me, or did anyone else notice that this article had more than its fair share of TLAs?
> I'd suggest using a text-only email client if you can stand it.
.png, .jpg, and .gif attachments, and in recent versions has its own rendering engine for HTML, and of course for plain text. Any other filetype you can just save to the filesystem.
...). I have looked high and low and far and wide for another mail client with anything approaching Pegasus Mail's functionality, and the only thing that even comes close is Gnus. (Gnus, however, is not really GUI-enabled, does not do things like checking for new messages as asynchronously as might be desired, and has a MUCH higher learning curve.) Clients like Evolution and Eudora look like toys next to Pegasus Mail, to say nothing of junk like MSOE.
For Windows users, I generally recommend Pegasus Mail. It's easy to use, but it's also excellent. If it were available for all the major operating systems, I'd probably still be using it myself, but it is pretty much Windows only. Regarding malware, it handles that in the best possible way: if the filetype of the attachment is anything even vaguely executable, and you try to save it, it displays a warning dialog with "Virus" in the title and Cancel as the default action. You _can_ save an executable attachment that someone sends you to the filesystem, but the default is not to to so. As far as _launching_ attachments, Pegasus Mail doesn't. It does have the ability to display
Pegasus Mail is also very mature, being one of the oldest GUI-enabled mail clients in existence, possibly the oldest, and older than a lot of text/console ones as well. (Pegasus itself started life as a text/console client, adopting the GUI circa 1991.) Having been around for a while, it's fairly feature-complete. For instance, its filtering system supports regular expressions, flow control, and a wide variety of possible actions (including the ability to execute a predetermined external command, send the contents of a predetermined file back to the sender, highlight the message in a certain color in the list of messages, add or remove the sender from a distribution list,
It's not open-source, but it has always been free to download and use, and it's possible to get permission to redistribute it (e.g., if you are an ISP). If you're looking for a good email client for Windows, I highly recommend having a look at Pegasus Mail.
And yes, if you're trying to avoid malware, it is absolutely critical that you don't use Outlook or Outlook Express. I don't recommend Thunderbird easier; it doesn't AFAIK execute attachments automatically like Outlook can sometimes be made to do, but it does make it *way* too easy to launch one without significant forethought; basically all you have to do is click, and it's running. Not good. Plus it's feature-poor anyhow, and there are much better options.
Yeah, but these are _unprivileged_ users with admin rights.
Ahem. Actually, the article summary is just worded very badly.
> How easy is it to change the value of the USER environmental variable in Mac OS X?
Trivial. The environment belongs to the process that is executing therein, and can be changed by that process in any way at any time. A child process inherits its values from the parent process, and shells (csh, tcsh, bash, whatever you happen to be using) by design allow the user to change environment variables at will and launch arbitrary child processes. This is all normal and expected, a part of the regular functioning of the system.
> Is there a universal username that is member of the admin group on all Mac OS X installations?
This is a better question, and one that I can't answer with any degree of certitude. I know that root _login_ is not enabled by default on OS X, but it may be that the account does exist.
Either way, nothing should ever trust the value of an environment variable for anything relevant to security, on any operating system.
> Go ahead try: setenv USER 'name', and see what happens. Want to know? The next env
> command will show USER=name. Then do a 'who' command, and guess what? "who" command
> returns whatever name was already logged in, not the newly-set environment variable.
> Oh no, doesn't work does it? Maybe relaunch the console, try again. Then what happens?
> Run the command 'env' and you get the original, valid logged-in username, NOT the
> 'made up name' from the half-assed setenv USER 'trickadminname'. Trivial on Windows?
> Too bad, shoulda bought a Mac, or at least wiped the drive and loaded Linux, BSD, etc.
The behavior you describe is the behavior on all systems, because the environment belongs to a particular process, not to the logged-in user. It is normal for a given process to modify its environment. If you want the USER variable to be set to a particular value for all of your processes, you have to change it in a configuration file. (Yes, you can do this on OS X.)
The only difference on Windows is that the who utility is not included with the operating system, so if you want to be able to type who and get any meaningful result you have to download a third-party who utility.
The vulnerability happened because something _trusted_ an environment variable that shouldn't have, since it is known and expected that users are permitted to set environment variables to any value they want.
As far as an equivalent attack on Windows, there is actually an unpatcheable one due to a design flaw in the Win32 API; however, it's much more difficult to exploit than setting an environment variable and probably requires direct user interaction (i.e., probably cannot be automated like this could), since it is necessary to identify a process that is running with special privileges and send an event to a window owned by that process. There is almost always a privileged process running on Windows (antivirus software is a prime candidate), but one has to be identified, and exploiting it is complicated.
As for this OS X vulnerability, it's old news, a story about something that was already patched.
> I'd quit if I had a choice, but I really need the money, yet I'm unable to look
> for a new job because of lack of time.
If you are working overtime every week (not just an hour or two but considerable overtime, as you seem to imply) and can't afford to take any time off, your budget is out of control. Tighten it.
Are you paying for cable TV? The way you describe your free time quota, it sounds like you don't have _time_ to watch TV, and if you did have time, you could just as well read slashdot, right? Right, drop the cable, save twenty bucks a month, or more.
Now, about food... if you're anything like typical, a little discipline can trim 30% off your food budget without even *messing* with sales or coupons, and without going totally spartan. (Somebody said beans and rice... but you don't necessarily have to go that extreme, just cut out the processed foods and deli stuff.)
You're not renting movies at the video store, are you? Find a public library, and drop them off on time even if you haven't had a chance to watch them. (You can always borrow them again, which costs you nothing, versus late fees which don't cost nothing, typically.)
Besides food, gas, clothes, and regular payments (loans, rent/mortgage, &c), what else are you buying? Don't. You don't need it. Even the stuff you think you need, you don't need it. Speaking of that: never carry money, unless you have a specific need to spend it. Seriously. Your wallet? Keep your ID in it, but leave the money at home. If the thing you're thinking of buying isn't worth planning ahead to buy, it's not worth spending the money. Don't carry a checkbook either, except when you have a specific need to write a check for a specific and unavoidable purpose. Credit cards? Get rid of them, or lock them in a box in the attic and keep the key under something heavy in the basement. Credit cards make it too darned convenient to part with your money.
Basically, what you're doing here, is you're buying your sanity back instead of all the less important things you've _been_ spending your money on. When you've paid off your credit card depts and saved up three months' expenses, then you can decide whether to quit your job and look for a different one (which, if they're still forcing large amounts of unwanted overtime down your throat, will probably be a good idea at that point).
Yes, you *can* pay off your debts and save money on what you're making. I paid off my college loans in four years, and most of that was while I was working fast food and making minimum wage; during the same timeframe I also saved up for and bought a $2000 computer. You just have to spend less than you make. Prioritize the things your money goes into, with the most important ones at the top of the list, and then draw a line through the middle of the list at the point where the stuff above the line adds up to about 80% of your income. Cut off the bottom part of the list, everything below the line.
I say 80%, not 90%, because you will have unexpected things come up that you didn't anticipate, but which are important enough to make the top part of the list. If you plan to spend 90% of your money, you end up saving little or nothing. Plan to spend 80%, and you can actually save 10%. Paying off debts counts as a form of saving and indeed is the preferred form if the debt has higher interest than you can make on a savings account. Low-interest debts are less urgent to pay off, but paying them off still counts as saving, because it improves your net worth. So, when I say, "save 10%", I mean, "use 10% to pay off debts and/or put in savings". If your savings account goes past about six months' expenses, then there are other forms of savings you should look into (mutual funds...), but I get the impression that's not something you have to worry about just yet.
> People yield code. I was replying to the statement that the Linux kernel is more popular
> with both individuals and companies because it is more flexible (from a copyright
> standpoint) than HURD.
No.
Linux is more popular than HURD because at certain critical points in history it was "working" and "ready" for definitions of "working" and "ready" that could not really be applied to HURD at the time. Basically, Linux was in the right place at the right time. HURD never showed up to the party, and there was a licensing lawsuit connected with BSD at a particularly critical point in time which left it just a little behind in just the wrong ways at just the wrong time, allowing Linux to get "ahead" in terms of mindshare and popularity in the developer community. Consequently, there was a several-month time window, at a particularly important time in history (right about when a lot of college undergrads were first getting net access) when if you wanted a freely-available, freely-modifiable, freely-redistributable operating system, Linux was _the_ obvious choice. That gave it a leg up, got a lot of people involved with improving it, and made it the leading and most popular free OS. Nothing has yet managed to unseat it from that position.
Just to be clear, I'm not saying that the FSF's policies haven't hampered HURD development. They likely have. What I'm saying is that that is not the key important reason why Linux is ahead of HURD (both in terms of popularity and development cycle). The key reason is because Linus had working, usably complete code at an important time when the FSF (in terms of a kernel) did not.
If the timing had worked out differently, the HURD might have been in the leading position, in spite of the FSF's (admittedly rather strict) copyright policies. It is notable that a number of the FSF's *other* projects, despite said policies, are leading implementations in their respective niches, because those projects were finished to the degree they needed to be and working to the degree they needed to be when they needed to be. Emacs for instance was there enough and working enough (for _most_ of the folks who wanted an Emacs, albeit not for Lucent) that XEmacs is just another, somewhat less popular alternative, rather than completely eclipsing Gnu Emacs as Linux has done to HURD.
> For crying out loud, this is spyware, by definition.
No, spyware by definition runs on the user's computer. I don't think that's the case here.
> From the article:
> The filter cannot be broken in the same sense that one cannot crack time-tested
> public-key encryption functions such as those already used for Internet commerce
> and banking applications.
In _what_ same sense. Public-key cryptography relies on the attacker not having any access to the computer system where the private key is stored. Otherwise, it can be broken very very easily. If this filter cannot be broken in the "same sense", it implies only that it cannot be broken by someone without any access to the system running the filter. Is that really all they're claiming? That doesn't seem like a particularly useful or meaningful claim.
> In that aspect, it's essentially a bullet-proof technology.
This sentence is grade-A snake oil.
> But it is still possible to find out what it does in practice, since the nature of the
> data it processes is known. Just run it in a simulation and see what it does.
> No reverse-engineering required.
Actually, that's one of the most common and useful reverse engineering techniques: run it in a controlled environment and see what it does. The people who are claiming that they have a mathematical proof that this thing _can't_ be reverse engineered are either very dishonest or very ignorant about computer technology, likely both.
"imposible" is not one of the four words that Schneier said make no sense in the context of security, but it could have been; certainly in this context it means basically the same thing as "unbreakable" or "absolute".
> So, it has been mathematically been proben impossible to reverse engineer...
> has it also been mathematically proven impossible to socially engineer?
I'd like to see a definition of reverse engineering that excludes social engineering without making a special exception for it. Any such definition would be so narrow that it would also exclude numerous other common types of reverse engineering. (No, it won't do to say that the information obtained by the process has to be obtained directly from the item that is being reverse engineered. Such a definition excludes several common types of non-social reverse engineering, e.g. wherein timing and network traffic are analyzed.)
Obviously it hasn't been mathematically proven to be impossible to social-engineer, has it? Given that, it follows almost as a correllary that it also hasn't been mathematically proven to be possible to reverse engineer, given any reasonable definition of "reverse engineer". The claim sends the needle on my bogosity detector spinning.
> They claim they have proven that the it cannot be determined by other what the program does.
Yeah, but it's a totally bogus claim. I want thirty minutes in a room with the "mathematician" who "proved" this and a blackboard. It isn't possible to make code that can't be reverse engineered because, fundamentally, the processor that executes the code has to know what the low-level operations are in order to execute them. Quite aside from that, in order to prove that code can't be reverse-engineered, you'd have to define in mathematical terms either what reverse engineering is or how it works. Any such definition is likely to have substantial holes in it.
> Who do you mean?
Just for instance, Germany could potentially get into a civil war scenario pretty much overnight. The political climate in Germany is outright scary. Deep emotional baggage left over from the last big war is a major formative factor in the current culture (and counterculture). The law and the majority of the population both support the enforced suppression of distasteful political ideas and symbols, yet copycat groups giving lip service to the very ideas and symbols that the majority most want to suppress are more common in Germany than anywhere else in the world; many of these groups are personality cults centered around charismatic leaders.
Of course, that all _could_ come to nothing; the emotional baggage could fade in a generation or two, and the whole thing could blow over. But, that isn't what happened last time.
As I said, there also could be war in the Middle East at any time. The outcome would be predictable (and the impact on the rest of the world limited) _provided_ the US and Europe and Russia all stay out of it, but if any of those countries became involved, the predicatability would go right out the window.
> Which means that browser type checking will need to
> remain pretty much for the forseable future.
Maybe, but if IE7 has the major things content developers want (cheifly: alpha channel support, this, and good support for CSS selectors), I think it'll be out for less than a year before you start to see a lot of websites refusing to support IE6 at all. There are already a *lot* of webmasters who are *tempted* to drop support for IE6 but talk themselves out of it on the grounds that IE has the largest market share. The improvements that can be made both to the web development process and the user experience (and also to accessibility) by dropping IE6 support are substantial, and if IE7 delivers most of these improvements, webmasters may again start telling users to upgrade their browsers, as was quite common practice during the 90s.
> Microsoft would never come up with such a catchy name [as MicroPod],
> they'd call it something stupid and bland like MS Portable Audio
Indeed. Other names they might actually use include Microsoft Music, Microsoft Sound, Microsoft Listen, Microsoft Media Player, Microsoft Portable Player, or maybe just Microsoft Player.
> I see what you mean, but I'm a skeptical that you can really predict things like
> this at the level of "Eastern Thinking" vs "Western Thinking".
Some things are more predictable than others. I'm not saying I know the future, just that I judge war between the US and China as unlikely in the current political setting. (The political setting can, of course, change, and does change over time...) It's not just that Eastern and Western thinking are different but that, unlike before WWII, both sides are now aware of the differences and take them into account in various ways. The political situation between the US and China currently is, in a word, stable. Also the situation between the US and Russia is quite stable now.
In terms of world wars starting, I'd be more worried about nations nobody's been paying much attention to yet, or about civil wars starting _within_ certain internationally significant nations and causing international fallout. There are, for instance, a couple of EU member nations that, if they were to have a civil wars spring up, it could have thoroughly unpredictable consequences internationally. No, I don't mean the balkans. There could be war in the balkans at any time, of course, but I don't think it would spark WWIII, at least, not right now. But it is very hard to predict what would happen at the international level if e.g. Germany were to have a civil uprising, because it's very hard to say whether and how various nations would become involved.
The Middle East, of course, is *always* politically unstable (well, at least for the last four millennia or so) and a potential source of trouble of one kind or another. The only thing I can safely predict about the middle east is that there won't be a real lasting peace agreement reached.
> In related news, my pants were the leading distribution
> method for iPod nanos, in the USA, in California, in my
> house, yesterday.
Ah, but my research shows that iPod nanos are on the way out, because the results I've just collated indicate that xmms is now the leading method of listening to music for middle-aged college-educated male computer geeks between the ages of 30 and 32 using FreeBSD, in small-town USA, in Ohio, at my house, for the last several days running. Also, according to the same study, the leading music writer now is apparently J.S. Bach, with the performer market shared among several major players, notably Wendy Carlos, Karl Munchinger, and the Stuttgart Chamber Orchestra. Meanwhile, AMD market share hovers around 50% adoption in the same demographic.
> You are wrong.
No, you've badly misunderstood him. I'd go so far as to say you completely missed what he was talking about. (Either that or you're using a straw man, but I'll give you the benefit of the doubt and consider your post sincere.)
> There was a study which found that the better the reader, the less likely they were to
> notice spelling errors when reading for comprehension. There was a famous case where
> they added a small article (I believe it was "a") at the end of a line, and at the
> beginning of the next. The faster readers (who I'm sure you're aware also tend to have
> higher comprehension) were less likely to notice this than the slower readers.
That's all true, but these are not the type of mistakes the other poster was talking about. Sure, mistakes like doubling an article, or minor misspellings like "rediculous" or "preposterus" are unlikely to be noticed by good readers. Its also true (ahem) that in some cases, depending on the sentence, substitution of homophones will be so immediately apparent that the brain can correct the mistake immediately before reading any more of the sentence, and in that case the flow of reading is not substantially interrupted.
However, the other poster was (especially in context, i.e., if you are familiar with the previous post to which he refers) very clear that he was talking about another sort of mistake altogether, the sort wherein looking only at the first part of the sentence leads to an incorrect parsing with a different meaning. The grandparent and the frist psot were both talking about those types of errors. There not only occasionally present on slashdot, but actually fairly common. These are the sorts of errors that present a problem.
Nobody (except maybe the occasional grammar nazi, sure) is getting very worked up over affect/effect, for instance, because the wrong meaning seldom survives the initial parsing phase; it doesn't fit the preceding context, and the brain discards it and selects the intended meaning immediately. It also helps that both words function as the same parts of speech. A fluent speaker of the language will generally have no problem here, and we do indeed "get over it" pretty easily.
Homophones (like its and it's) or near-homophones (like you're and your and yore or their and they're and there) that are different parts of speech are especially likely to be problematic. They're not *always* a problem, because sometimes the structure of the preceding portion of the sentence clarifies which meanings are possible. However, in many cases the _end_ of the sentence has to be read before the error can be understood and mentally corrected, and *those* are the cases we're complaining about.
> The question is: is Perl becoming a LISP implementation?
It depends how you look at it. From one angle, Perl6 looks like an advanced Lisp variant. However, if you walk around to another side, it looks like an improved version of Smalltalk.
Perl is a multiparadigmatic language. Perl5 supports functional programming in a limited way, and it supports OO in a limited way. Both are sufficiently implemented in Perl5 to be useful, but neither is really complete. In Perl6, both of these paradigms become full-blown entirely implemented first-class paradigms. The contextual paradigm that was pioneered in earlier Perl versions also becomes a full-blown and entirely implemented first-class paradigm, and of course there is still the procedural paradigm for those who want it.
So with Perl6 you can use the right tool for the right job, without having to entirely switch languages.
> Without that book, Perl can just be extremely weird, after reading the book it at :-)
> least makes sense in its own world, no matter how unconnected that world seems to
> be to the rest of the universe
Has it ever occurred to you that maybe it's the rest of the universe that's weird?
(Okay, okay, so maybe *I'm* weird... Nah, couldn't be. Thinking in Perl isn't weird, is it?)
> And thats why they should use the GPL- to make sure it *remains* free
This is silly. BSD code remains free. Nobody can come along and say, "Because I based my proprietary work on this, you can no longer have it." It's still free. Another work _based on_ it may not be free, of course, but the work _itself_ is still free.
The GPL is all about what _derived works_ can or cannot be made and how they can or cannot be distributed. The work itself is actually less free than it would be under the BSD license, because there are a number of (sometimes complex) situations in which it cannot be used (most notably, when you also want to link against a library you don't have rights to; under the GPL, you can't do that, at least, not if you intend on redistribution of any kind). If I use the BSD license for my code, I can be confident that, even if I accept patches from others, I can still always use my program for whatever I want, however I want. I can use it in a personal capacity at home, or I can take it to a future job with me and use it there, or whatever I choose to do with it.
Other people can do these things also, but that does not restrict what *I* can do.
If I use the GPL for my code, and I don't accept any patches from anyone else, then I can still relicense my code however I want, but, importantly, if I use the GPL and then start accepting patches from others, basing my own changes on those patches, and so on, the code is no longer all mine, and I lose certain rights. If I then want to link against a proprietary library, I can't. If I want to use the code (which is primarily my own code, remember) in a job context as part of a larger work that uses a proprietary license, I cannot. I'd have to recreate my work from scratch. Who wants to do that? Boring.
The FSF claims that the GPL is all about guaranteeing freedoms. This is rhetoric. Putting the code in the public domain would forever guarantee[1] everyone's freedom to use, modify, and redistribute it. What it wouldn't do, which the GPL does, is place all kinds of restrictions on the conditions under which they can do so.
The only reason you should use the GPL for your code is if you *want* to restrict what people can use it for, e.g., if the idea that someone might include some of your code in a proprietary product bothers you. Such an idea does not bother me. I wrote the code because I wanted to be able to use it, and I released it (as opposed to just keeping it on my hard drive) because I thought other people might find it useful too. What exactly they use it for is neither here nor there as far as I'm concerned (as long as they understand I'm not contractually bound to support it or anything, which is why there's a warranty disclaimer in practically every license, certainly in all versions of the GPL as well as the BSD and MIT licenses).
If you just want to guarantee everyone the rights to your code, the BSD license is fine. The purpose of the GPL is to get some guarantees *back* from the people who use your code. That's a different thing.
[1]: Well, okay, there's the patent issue, but I'm not convinced any license you put your code under can prevent some other clown from coming along and filing a patent. The PTO is not going to check, before granting a patent, whether there are any GPLv3 works that implement the technique and, if so, decline to grant the thing.)