> It took me less time to learn python and write my first utility > (a page generator for 195 content categories in2 languages from > source data files) than it would have to write it in perl and > debug it.
*shrug*. Maybe you just think Guido's Way. Some of us don't. I tried to learn Python, but every time I tried to do anything in it, I ran into frustrating scenarios wherein I'd need to write eighty lines of code just to do something really simple. Maybe it's because I didn't know Python well enough yet to write it compactly, but whatever the reason, I just couldn't make myself finish learning the language.
In any case, a page generator for 195 content categories in two langauges from source data files sounds more like a round of golf; if it were an actual programming task, 80% of the time would be spent deciding which three modules to use (for parsing the source data, for generating the content's form, and for the language issue), and writing the code to put it all together would be 5%. (Allow 2-3% for debugging, and the rest of the time would go into writing the documentation.) Sounds *much* easier than learning a new language. (The *fastest* I ever learned a programming language to my satisfaction (discounting data languages such as SQL) was two weeks, and I spent twice that long attempting to learn Python... there's absolutely no way writing the page generator you describe could take that long.)
> The whole "TMTOWTDI" is just wrong, from a maintainability point of view.
Why? Why does it make the code less maintainable to solve each problem in the way that is natural to solve that problem, rather than trying to coerce every problem into a particular paradigm that may or may not be a natural fit for the problem? The best feature of Perl is its multiparadigmatic nature, that allows the programmer to select the best type of solution for any given problem. (Well, okay, maybe the *best* feature is the CPAN, but the multiparadigmaticity is a close second.)
I find that well-written Perl code is much more maintainable than code in most other languages. (Poorly-written Perl code is, of course, completely unmaintainable, but it's possible to write unmaintainable code in any language.)
> And perl's greediness in matching strings
Umm, did you read the documentation? If you want non-greedy matching, that's easy enough to do. The really handy things, though, are lookahead and lookbehind assertions. I just wish we could get variable-width lookbehind; presumably Perl6 will make this possible.
> Perl - because when it all looks like line noise, nobody can > criticize the "quality" of your code.
If it all looks like line noise, the code doesn't *have* any quality.
> I still prefer to buy from companies I or my friends have > dealt with.
Of course, if you had followed that strictly 100% of the time, you'd never have bought from anyone. For any given company that you do business with, there had to be a first time.
My preferred practice is to only buy inexpensive items the first times I do business with any particular outfit. Once I've developed a feel for the quality of their service, I'm more likely to use them as a source for more significant purchases. For instance, the first time I bought from newegg it was just some little thing, an ethernet cable I think; I'd read good things about them on slashdot enough times to take the risk on a small (and easy-to-get-right) order like that. Eventually I got to the point where I trusted them enough to order a number of components for my current computer system (motherboard, CPU, RAM, graphics card, fans,...) all at one go. I wouldn't have had the confidence to place that kind of order if I hadn't ordered smaller amounts of stuff from them a number of times previously, with good results.
Before newegg I used to buy from TCWO, before they went out of business. They were recommended to me by someone local, whom I had spoken with in person on several occasions. Even then, the first thing I bought from them was a $10 network card IIRC.
> It's no wonder so many open source projects never make it as far as a v1 release - > emacs is stealing all of the version numbers! 22!!
Don't put exclamation marks on numbers like that; you'll confuse the math geeks, and 22 is a large enough version number as it stands, without taking the factorial of the factorial.
However, Emacs 22 is actually an abbreviation. It's really 0.22, of course, because Emacs also has yet to reach a 1.0 release. To reach a 1.0 release, Emacs would have to be essentially feature-complete, meeting all the major expectations people have of a text editor. I personally have a list of several hundred major features every text editor should have, which Emacs is still lacking. Perhaps the most significant has to do with threading and lazy evaluation: I'd really like to be able to do something like this...
(setq some-variable (lazy-eval (some-function stuff blah blah blah))) (message "This stuff happens while some-function is still processing.") (do-stuff foo bar baz) (message "But now we're going to use some-variable, meaning that we'll have to wait for some-function to return.") (message (concat "The lazy evaluation has now returned, and the result is " some-variable ".")) (setq my-child-process (fork (do-more-stuff))) (message "The fork function should fork off an entire process and return the PID.")
This stuff would come in really hand for things like Gnus, for instance, and it's obvious to me that no text editor is ready for a 1.0 release without these features.
Re:Support for OS X and Cygwin
on
The Future of Emacs
·
· Score: 2, Interesting
> Since we're talking about Emacs here, it would be good to clarify whether Emacs > will be running under OS X and Cygwin or the other way around.
Presumably if these are _new_ features, it would have to be OS X and Cygwin running under Emacs, since Emacs has been running under OS X and Cygwin for years. (The first time I ran Emacs under Cygwin, I was using Windows 95 OSR2 as my OS, and that was back in the days of yore, long before XFree86 was ported to Cygwin. OS X, of course, has _shipped with_ Emacs out of the box at _least_ since 10.1, probably 10.0 if I don't miss my guess.)
If this is indeed the correct interpretation, it is exciting news, since it implies great progress in the C-to-elisp compiler. I look forward to a day when I can get Gecko to compile for Emacs, so that I can get rid of that w3m thing and have a more mainstream browser on my Emacs system...
> > All applications have got pre-defined passwords that never change. > Then put them on their own network segment and mitigate their risk potential.
Yeah, I was going to do that, but when I asked the vendor's suposed firewall expert what ports needed to be opened through the firewall between workstations and the server, I could hear the jaw dropping on the other end. After going through a couple levels of "let me check with this other person...", the verdict came back that putting a firewall between the production server and the rest of the network would be a waste of a firewall, because so many ports would have to be open that it would be like not having a firewall at all. I never did get them to give me a list of what ports would be involved. Turns out the vendors intention was only to put the firwall between the network and the outside world, not to also isolate the server from the rest of the network.
So now we've got staff workstations, which run standard desktop software, on the same subnet as the production server, which is also the database server, and yes, the application uses a hardcoded password to talk to the database, and yes, it's a very weak password in the first place.
XYZZY isn't from Zork; it's from an earlier game that inspired the people who later created Zork. The game in question goes by various names, e.g., "Adventure", "Advent", "Colossal Caves". Zork also has a couple of other names (e.g., "Dungeon"), but it's clearly a quite different game from Advent (albeit in the same genre), and had an entirely different set of authors.
> Frankly someone walking away from a live terminal is more dangerous.
Yeah, that's why I set the screen saver delay to ten seconds with password protection. Now we don't have to worry about this. You should hear the users complain, though: you've never heard such whining.
> The never expiring password might be bad, but I think security policies that enforce > password expiration after too short a period are perhaps even worse
Passwords that end users have to use shouldn't change often, because the end users will A) write them down or B) complain loudly about how they have to remember it, telling anyone who will listen (effectively, random people off the street) the new password or C) both.
However, the article was talking about passwords that one application uses to talk to another (e.g., the integrated system uses it to query a database), and those *should* change regularly, for a couple of reasons. First, end users never even need to know that they *exist*, much less that they're changed. The system administrator needs to know the new password, and one or two other people, and it needs to be set in both applications, and that's it. So the arguments against regular password-changing are irrelevant for these passwords. Second, they're typically fairly dangerous passwords, passwords that confer rather more power (and at a lower level) than an ordinary end-user password.
> Who the hell 'hard codes' a user id and password into web based applications?
Even that is probably more common than you want to think, but the article is not talking mainly about "web applications" (a term I wish I'd never heard), nor about general-purpose applications like office software and media players, but rather about field-specific mission-critical "solutions", e.g., hospital software, bank software, integrated library systems, retail point-of-sale and inventory management systems, and so on and so forth. These generally are created by less competent programmers and sold to fewer customers for much larger chunks of money per site, and their security is seldom scrutinized closely enough. They typically have very poor UI compared with common mainstream desktop applications (such as office software), very poor configurability, and very poor security compared with mainstream server software for common services. There are usually between six and twelve major competitors in this space for any given field of endeavor, plus another couple of dozen minor competitors; the open-source alternatives, if they even exist, are not competitive feature-wise, and unless you're in the field (maybe even if you are), you've never heard of them, since their applicability is so narrow that they will never make a headline on a general-purpose site like slashdot or be discussed by most general-purpose local user groups. The price range for these things is "Let us know you're interested and we'll assign a sales team to you", and it's generally impossible to evaluate the security of the system until your assigned implementation manager arrives onsite, some time after you've signed a multi-year contract.
> half of all High Definition Television (HDTV) owners don't actually use the HD [...] > HDTV sets will be in approximately 16 million homes across the country by the end of [2005]
So that makes the projected HD market penetration by year's end, what, two and a half measly percent of *homes*? Compared to ordinary television's penetration level of something like three TV sets average *per* home. In other words, HDTV is all hype, and practically nobody is actually watching it.
> Sometimes I've found it easier to just pop the drop ceiling out, and climb over the wall > too, assuming there is no firewall between point A and point B. Usually inside offices > don't have them.
This is poor defense in depth, but it should be noted that anyone who doesn't have a key shouldn't be in the building at a time of day when you could do this without being noticed, so it's probably *mostly* only an issue when someone breaks into the building -- at least, in most cases.
> But, when it comes down to it, if I wanted to get into your house badly enough, I'd just > kick in the door. I have yet to find anyone who uses a New York deadbolt other than me.
Whatever elaborate six-inch-thick titanium-steel deadbolt you install, even if it extends all the way across the whole door and into the wall on both sides, plus top and bottom, it still only moves the weak point from the door to the nearest window. A standard deadbolt is generally good enough to do that already, unless your windows have significantly better than standard security.
Regarding the drywall mantrap: yeah, that's a very insecure design. Is this a facility that really needs, physically, the security of a mantrap, or is its purpose in the first place more for show?
> Raise your hand if your slashdot password would flunk any "best practice" ever invented
My slashdot password is weak, but that's an indication of the value of my slashdot account. If it is compromised, the perpetrator gets the use of a slashdot account (something he also could get just by, uhm, signing up), and I lose... what, maybe some of my reputation on slashdot? I think I'd live through it. Worst case scenario, the perpetrator changes the password *and* changes the email address for the account, so I permanently lose the ability to use my preferred username on the site in question; he could also try to impersonate me, but if the email address changes, who's he going to fool that knows me -- and what does it matter if he "fools" someone who doesn't know me into thinking he's the "real jonadab"? He gets the username, but beyond that... ? It's really a complete non-issue.
I reserve strong passwords for situations wherein they're actually warranted. I've got *enough* twenty-character mixed-case passwords with punctuation in them in my head as it is, some of which actually *matter* (well, relatively speaking; they're not for nuclear missile systems or anything). The last thing I need is to add a bunch more for protecting minor stuff like my slashdot account.
What scares me, in terms of weak passwords, is a scenario like what we have at work, wherein there are weak passwords hardcoded into the application for full access to our database, which contains the personal data for every single one of our patrons; the password in question is *extremely* weak (i.e., weak in at least three distinct ways (non-complex, identical to its corresponding username, and based on a word closely associated with the product)) inherently, and additionally is known to at *least* the IT staff (and probably more than that) of not just our software vendor but also every single one of their customers (who, incidentally, also have access to the complete customer list on the customer extranet). This is a PR disaster of epic proportions waiting to happen for us, not to mention a legal nightmare in the making, and there is nothing we can do about it, short of switching vendors. We didn't find out any of this until after we'd signed a multi-year contract for tens of thousands of dollars that we absolutely cannot afford, financially, to back out of. We can't change the password, because then the application won't work, since it's hardcoded there. Worse, we can't firewall the server off from the rest of our network, because the application requires that everything (and, in particular, the ports on which the database listens) be open from every staff workstation to the server, or the application won't work. We do have the whole network firewalled off from the outside world, but there's no defense in depth at all, and there's a big fat hole in the firewall through port 80, which the application needs to expose to the outside world for important parts of its functionality. The service listening on 80 is, you guessed it, IIS.
Additionally, there is a clause in our contract with the vendor that absolves them of *all* responsibility for our systems' security and specifies that if anything goes wrong, we have to pay *them* x number of dollars per hour to fix it. I am not making this up. I highlighted that and went to our director and said, point blank, "Don't sign the contract with this clause in it." So naturally she asked them about it, and they explained (verbally) that it's not a problem, the clause is only in there because some sites refuse to run antivirus software, and if we keep our antivirus up to date we won't have a problem, and no site has ever had a problem if they had antivirus protection. She *believed* them and signed the contract, because she's a director, not a paranoid systems administrator.
It's not mainly us that I'm worried about. We're a small-time outfit in a small city, not a target for anyone beyond the level of bored students fooling around. What scares me is that I know, deep down inside, that our vendor isn't the only vendor that pulls this sort of [language fails me; no word is foul enough].
> I do get shadow, both for the shadow password geek group, and for being a cool thing, > like "the shadow knows..."
Shadow is also an extremely common username, IRC handle, self-chosen nickname, and so forth.
> spank the monkey, nut buster (like, bust a nut.), ass bandit (like, butt pirate?)
The explanations for buster and bandit are probably more prosaic, similar to shadow: they sound (or are supposed to sound) all mocho-cool, like shadow or iceman or whatnot.
All the sports-related ones are immediately obvious; it's the *other* thing the dude's into. I suspect the names or nicknames of popular lines of sports car are also common.
> I'm guessing on Maggie, is that in our demographic (err, guys between 18 and 80), there > was a high ratio of women named Margaret to whom they were affectionally attached (married, > dating, etc).
Unless the site has some kind of geographically localized target market, I really doubt this, as it fails to explain why "maggie" would be more common than much more generally popular names such as "jenny" or cetera. I suspect that "maggie" has a cultural signficance we're missing (which would in my case anyway not be unusual; I don't follow popular culture very closely, especially television or pop music) or a colloquial meaning we don't happen to know. My gut instinct is to wonder if it's etymologically related to the slang term "magpie". Check urbandictionary.com or ask around on a teen chatroom or something.
> Just because you can make a program crash, doesn't mean you can exploit it
No, it doesn't mean that *necessarily*; however, there is historically a significant likelihood that such *might* be the case. The most recent IE remote arbitrary code execution exploit was formerly just a denial-of-service attack that for one reason or another never got patched, and eventually someone figured out how to make exploit it in a way that allows arbitrary code to be injected and executed. There are many other examples over time of cases wherein a flaw in some program or another, when initially discovered, was only a denial-of-service (or perhaps not even proven exploitable at all) but code injection and execution developed as a later, more sophisticated exploit of the same vulnerability.
This should definitely get fixed, preferably *before* anybody discovers a way to do more malicious things than DOS with it. (And I have little doubt it will be fixed, probably quite soon, if past history is any indication of future performance.)
> I think history has shown that "better content" has little to do with search engine ranking.
It's not so much _better_ content per se as it is content that many webmasters want to link to.
This is one reason why anything related to computer/technical topics is practically guaranteed to show up before even much more common alternate meanings for the same word. For instance, the word "word" is an *exceedingly* common English word, but the top result on Google is for a software product. (This phenomenon is by no means limited to Microsoft products, either. The word "firebird" makes most of the general population think of automobiles, but the top five Google results are software-related, most of them for a product that has since been renamed.) Most web content, and especially most highly-ranked web content, is created by one brand or another of computer geek, so computer-related stuff rises to the top of the results.
There are other things you can do as well, sure, but nothing is more effective than having stuff on the site that lots of well-ranked web content creators want to link to.
> Jails should be for those who have committed serious crimes. > Like it or not, sending you a virus or some spam isn't an overly serious crime.
Sending one person malicious code or whatnot is (all else being equal) not a very serious crime; however, releasing a worm that crawls its way around the internet and infects thousands of computers is thousands of times more serious. It's still not a *violent* crime, but it can easily cause (collectively) more dammage than, say, a high-profile embezzlement. In such cases, a prison sentence might very well be commensurate with the seriousness of the crime.
> The same goes for spam.
Again, sending one piece of spam to a dozen people is nothing, but nobody (well, nobody level-headed) is saying we should jail people for that, either. Sending gigabytes of spam per day to millions of people, on the other hand, is at *minimum* a really solid example of making a public nuissance of yourself on a grand scale, and frequently there are rather more serious offenses involved as well. For instance, if a spammer ignores "Don't contact me again" requests and continues to contact you, that's harrassment (the same as it would be if he were calling you on the phone and refused to stop). Fraud is also a popular legally-actionable component of some spamming operations, and there are others. Note that I'm not saying everyone who sends any junk mail at all necessarily engages in all of these crimes, but I don't think it would be in any way inappropriate to prosecute the ones who do and, if their offenses are sufficiently serious, imprison them.
> Please do not anthropromorphize the process of evolution
It's not the process that is being anthropomorphised, but the viruses. As we all know, viruses are computer programs, which, technically, are information. So what you have to ask yourself is, "Does information want to be anthropomorphised?"
> Seriously now, are viruses really evolving or is it just that the techniques used by virus > writers are evolving?
Sure, nothing a little grammar can't fix. Just settle on it this way: viruses are being evolved. Notice how the passive voice neatly avoids the whole question of who is doing the evolving; the action could equally well be transitive (authors are evolving the viruses) or reflexive (viruses are evolving themselves), since the sentence only states that the evolution is occurring, leaving the question of who or what is performing it to be determined by the reader's own assumptions.
Of course, the statement "viruses are being evolved" concerns the observable present, so it really has little or nothing to do with the intelligent design debate, which centers on the unobservably distant past.
At minimum the court should require Microsoft to send every owner of one of these units a piece of string, with instructions. It wouldn't cost them that much, but it's the principle of the thing, now isn't it?
Of course, at their option, Microsoft could instead offer replacement units (without the problem) instead of the string-fix kit. Their marketing, legal, and financial departments could duke it out over which way to go on that.
> I think Microsoft could get Google's shareholders to agree, given a high enough price.
I don't think Microsoft would be willing to pay a high enough price for that. Bear in mind, Google isn't nearly the only competitor, and Microsoft places a high value on keeping some liquid resources so that they retain the ability to react to situations that arise. They wouldn't want to expend most of their available resources on one acquisition, however big. They could offer Microsoft stock or something along those lines, but think about how much of it they'd have to shell out to get Google's shareholders to agree to the thing; it would have to be quite a lot, enough probably that it would have an impact on the market value of Microsoft's own stock (as releasing too much at once creates a surplus); Microsoft's shareholders might not care for that. (Indeed, just a well-placed rumour to the effect that something like that was *about* to be announced could cause a stock-price sag for Microsoft, although it wouldn't last very long once the rumour turned out to be nothing.)
Anyway, it's moot, because the FTC would be just about as likely to allow a three-way merger between AT&T, Sprint, and Verizon.
> But I think the corporate cultures would clash so much as to make the merger completely > detrimental to Google's future prospects.
Agreed.
I'm confused about why Microsoft doesn't diversify into some unrelated fields, e.g. open a restaurant chain or something. In software, they're the big dog at the top of the heap, and there's nowhere further to go there. (I don't mean they can't improve their software, but it's their position in the market I'm talking about.) Anybody who's had an economics class knows no company can stay on top in a field forever; you'd think they'd be working on a thirty-year plan to diversify into a dozen other industries, to ensure their continued strength as a company, irrespective of what might happen in any one industry.
> I suppose that there are reasons why Microsoft > can't just leave an inode in place after unlinking > it so that processes that use it don't lose it
Microsoft's filesystems, as far as I am aware, do not *have* any such concept as inodes or hard links. Certainly FAT filesystems don't have anything like that. NTFS is rather more complicated, and I don't fully understand it, but if it has any concept of inodes or hard links this is news to me.
Several corporations have the money, but whether any also would have the desire *and* be permitted to do so is another matter. For instance, Microsoft would want to buy Google, but such a merger would be quite unlikely to be approved, due to antitrust considerations. A company like Ikea might be able to get such an acquisition approved, but Google would be a bad investment for Ikea (for several reasons; among them, Ikea would have to view Google as potentially overvalued now and, with their recent rise, almost certainly not undervalued at this point, so there's plenty to lose and little to gain; the dynamics are different for Microsoft, which has more to gain from such an acquisition, but that's exactly why it wouldn't be approved). There probably is not a company with both the money *and* the desire, except for extremely large and profitable tech firms (cheifly Microsoft), and for them there are big antitrust issues getting in the way.
Then there's the small matter of Google's shareholders needing to approve any such thing in order for it to take place, even if the FTC *does* allow it. Raise your hand if you think Google's current shareholders would vote "yes" to acquisition by Microsoft under any balanced and reasonable terms (i.e., terms Microsoft would potentially also agree to).
> Leaked memory is memory which is still allocated to the leaking process
Only if the operating system keeps track of which process it was that allocated the memory. In general, reasonable modern operating systems do this, of course, but there have been systems that didn't. Another thing that happened on those systems was that if one program had pointer errors, it could end up corrupting the memory of another process, and the OS wouldn't even know, much less prevent it. (That's also possible on systems that do know which process owns the memory but don't protect it from other processes, e.g. because there's no security model or because memory access doesn't have to go through the OS API and any process can execute whatever machine code it wants.)
Slashdot Mirror
> It took me less time to learn python and write my first utility
> (a page generator for 195 content categories in2 languages from
> source data files) than it would have to write it in perl and
> debug it.
*shrug*. Maybe you just think Guido's Way. Some of us don't. I tried to learn Python, but every time I tried to do anything in it, I ran into frustrating scenarios wherein I'd need to write eighty lines of code just to do something really simple. Maybe it's because I didn't know Python well enough yet to write it compactly, but whatever the reason, I just couldn't make myself finish learning the language.
In any case, a page generator for 195 content categories in two langauges from source data files sounds more like a round of golf; if it were an actual programming task, 80% of the time would be spent deciding which three modules to use (for parsing the source data, for generating the content's form, and for the language issue), and writing the code to put it all together would be 5%. (Allow 2-3% for debugging, and the rest of the time would go into writing the documentation.) Sounds *much* easier than learning a new language. (The *fastest* I ever learned a programming language to my satisfaction (discounting data languages such as SQL) was two weeks, and I spent twice that long attempting to learn Python... there's absolutely no way writing the page generator you describe could take that long.)
> The whole "TMTOWTDI" is just wrong, from a maintainability point of view.
Why? Why does it make the code less maintainable to solve each problem in the way that is natural to solve that problem, rather than trying to coerce every problem into a particular paradigm that may or may not be a natural fit for the problem? The best feature of Perl is its multiparadigmatic nature, that allows the programmer to select the best type of solution for any given problem. (Well, okay, maybe the *best* feature is the CPAN, but the multiparadigmaticity is a close second.)
I find that well-written Perl code is much more maintainable than code in most other languages. (Poorly-written Perl code is, of course, completely unmaintainable, but it's possible to write unmaintainable code in any language.)
> And perl's greediness in matching strings
Umm, did you read the documentation? If you want non-greedy matching, that's easy enough to do. The really handy things, though, are lookahead and lookbehind assertions. I just wish we could get variable-width lookbehind; presumably Perl6 will make this possible.
> Perl - because when it all looks like line noise, nobody can
> criticize the "quality" of your code.
If it all looks like line noise, the code doesn't *have* any quality.
> I still prefer to buy from companies I or my friends have
...) all at one go. I wouldn't have had the confidence to place that kind of order if I hadn't ordered smaller amounts of stuff from them a number of times previously, with good results.
> dealt with.
Of course, if you had followed that strictly 100% of the time, you'd never have bought from anyone. For any given company that you do business with, there had to be a first time.
My preferred practice is to only buy inexpensive items the first times I do business with any particular outfit. Once I've developed a feel for the quality of their service, I'm more likely to use them as a source for more significant purchases. For instance, the first time I bought from newegg it was just some little thing, an ethernet cable I think; I'd read good things about them on slashdot enough times to take the risk on a small (and easy-to-get-right) order like that. Eventually I got to the point where I trusted them enough to order a number of components for my current computer system (motherboard, CPU, RAM, graphics card, fans,
Before newegg I used to buy from TCWO, before they went out of business. They were recommended to me by someone local, whom I had spoken with in person on several occasions. Even then, the first thing I bought from them was a $10 network card IIRC.
> It's no wonder so many open source projects never make it as far as a v1 release -
> emacs is stealing all of the version numbers! 22!!
Don't put exclamation marks on numbers like that; you'll confuse the math geeks, and 22 is a large enough version number as it stands, without taking the factorial of the factorial.
However, Emacs 22 is actually an abbreviation. It's really 0.22, of course, because Emacs also has yet to reach a 1.0 release. To reach a 1.0 release, Emacs would have to be essentially feature-complete, meeting all the major expectations people have of a text editor. I personally have a list of several hundred major features every text editor should have, which Emacs is still lacking. Perhaps the most significant has to do with threading and lazy evaluation: I'd really like to be able to do something like this...
(setq some-variable (lazy-eval (some-function stuff blah blah blah)))
(message "This stuff happens while some-function is still processing.")
(do-stuff foo bar baz)
(message "But now we're going to use some-variable, meaning that we'll have to wait for some-function to return.")
(message (concat "The lazy evaluation has now returned, and the result is " some-variable "."))
(setq my-child-process (fork (do-more-stuff)))
(message "The fork function should fork off an entire process and return the PID.")
This stuff would come in really hand for things like Gnus, for instance, and it's obvious to me that no text editor is ready for a 1.0 release without these features.
> Since we're talking about Emacs here, it would be good to clarify whether Emacs
> will be running under OS X and Cygwin or the other way around.
Presumably if these are _new_ features, it would have to be OS X and Cygwin running under Emacs, since Emacs has been running under OS X and Cygwin for years. (The first time I ran Emacs under Cygwin, I was using Windows 95 OSR2 as my OS, and that was back in the days of yore, long before XFree86 was ported to Cygwin. OS X, of course, has _shipped with_ Emacs out of the box at _least_ since 10.1, probably 10.0 if I don't miss my guess.)
If this is indeed the correct interpretation, it is exciting news, since it implies great progress in the C-to-elisp compiler. I look forward to a day when I can get Gecko to compile for Emacs, so that I can get rid of that w3m thing and have a more mainstream browser on my Emacs system...
> > All applications have got pre-defined passwords that never change.
> Then put them on their own network segment and mitigate their risk potential.
Yeah, I was going to do that, but when I asked the vendor's suposed firewall expert what ports needed to be opened through the firewall between workstations and the server, I could hear the jaw dropping on the other end. After going through a couple levels of "let me check with this other person...", the verdict came back that putting a firewall between the production server and the rest of the network would be a waste of a firewall, because so many ports would have to be open that it would be like not having a firewall at all. I never did get them to give me a list of what ports would be involved. Turns out the vendors intention was only to put the firwall between the network and the outside world, not to also isolate the server from the rest of the network.
So now we've got staff workstations, which run standard desktop software, on the same subnet as the production server, which is also the database server, and yes, the application uses a hardcoded password to talk to the database, and yes, it's a very weak password in the first place.
XYZZY isn't from Zork; it's from an earlier game that inspired the people who later created Zork. The game in question goes by various names, e.g., "Adventure", "Advent", "Colossal Caves". Zork also has a couple of other names (e.g., "Dungeon"), but it's clearly a quite different game from Advent (albeit in the same genre), and had an entirely different set of authors.
> Frankly someone walking away from a live terminal is more dangerous.
Yeah, that's why I set the screen saver delay to ten seconds with password protection. Now we don't have to worry about this. You should hear the users complain, though: you've never heard such whining.
> The never expiring password might be bad, but I think security policies that enforce
> password expiration after too short a period are perhaps even worse
Passwords that end users have to use shouldn't change often, because the end users will A) write them down or B) complain loudly about how they have to remember it, telling anyone who will listen (effectively, random people off the street) the new password or C) both.
However, the article was talking about passwords that one application uses to talk to another (e.g., the integrated system uses it to query a database), and those *should* change regularly, for a couple of reasons. First, end users never even need to know that they *exist*, much less that they're changed. The system administrator needs to know the new password, and one or two other people, and it needs to be set in both applications, and that's it. So the arguments against regular password-changing are irrelevant for these passwords. Second, they're typically fairly dangerous passwords, passwords that confer rather more power (and at a lower level) than an ordinary end-user password.
> Who the hell 'hard codes' a user id and password into web based applications?
Even that is probably more common than you want to think, but the article is not talking mainly about "web applications" (a term I wish I'd never heard), nor about general-purpose applications like office software and media players, but rather about field-specific mission-critical "solutions", e.g., hospital software, bank software, integrated library systems, retail point-of-sale and inventory management systems, and so on and so forth. These generally are created by less competent programmers and sold to fewer customers for much larger chunks of money per site, and their security is seldom scrutinized closely enough. They typically have very poor UI compared with common mainstream desktop applications (such as office software), very poor configurability, and very poor security compared with mainstream server software for common services. There are usually between six and twelve major competitors in this space for any given field of endeavor, plus another couple of dozen minor competitors; the open-source alternatives, if they even exist, are not competitive feature-wise, and unless you're in the field (maybe even if you are), you've never heard of them, since their applicability is so narrow that they will never make a headline on a general-purpose site like slashdot or be discussed by most general-purpose local user groups. The price range for these things is "Let us know you're interested and we'll assign a sales team to you", and it's generally impossible to evaluate the security of the system until your assigned implementation manager arrives onsite, some time after you've signed a multi-year contract.
> half of all High Definition Television (HDTV) owners don't actually use the HD [...]
> HDTV sets will be in approximately 16 million homes across the country by the end of [2005]
So that makes the projected HD market penetration by year's end, what, two and a half measly percent of *homes*? Compared to ordinary television's penetration level of something like three TV sets average *per* home. In other words, HDTV is all hype, and practically nobody is actually watching it.
> Sometimes I've found it easier to just pop the drop ceiling out, and climb over the wall
> too, assuming there is no firewall between point A and point B. Usually inside offices
> don't have them.
This is poor defense in depth, but it should be noted that anyone who doesn't have a key shouldn't be in the building at a time of day when you could do this without being noticed, so it's probably *mostly* only an issue when someone breaks into the building -- at least, in most cases.
> But, when it comes down to it, if I wanted to get into your house badly enough, I'd just
> kick in the door. I have yet to find anyone who uses a New York deadbolt other than me.
Whatever elaborate six-inch-thick titanium-steel deadbolt you install, even if it extends all the way across the whole door and into the wall on both sides, plus top and bottom, it still only moves the weak point from the door to the nearest window. A standard deadbolt is generally good enough to do that already, unless your windows have significantly better than standard security.
Regarding the drywall mantrap: yeah, that's a very insecure design. Is this a facility that really needs, physically, the security of a mantrap, or is its purpose in the first place more for show?
> Raise your hand if your slashdot password would flunk any "best practice" ever invented
My slashdot password is weak, but that's an indication of the value of my slashdot account. If it is compromised, the perpetrator gets the use of a slashdot account (something he also could get just by, uhm, signing up), and I lose... what, maybe some of my reputation on slashdot? I think I'd live through it. Worst case scenario, the perpetrator changes the password *and* changes the email address for the account, so I permanently lose the ability to use my preferred username on the site in question; he could also try to impersonate me, but if the email address changes, who's he going to fool that knows me -- and what does it matter if he "fools" someone who doesn't know me into thinking he's the "real jonadab"? He gets the username, but beyond that... ? It's really a complete non-issue.
I reserve strong passwords for situations wherein they're actually warranted. I've got *enough* twenty-character mixed-case passwords with punctuation in them in my head as it is, some of which actually *matter* (well, relatively speaking; they're not for nuclear missile systems or anything). The last thing I need is to add a bunch more for protecting minor stuff like my slashdot account.
What scares me, in terms of weak passwords, is a scenario like what we have at work, wherein there are weak passwords hardcoded into the application for full access to our database, which contains the personal data for every single one of our patrons; the password in question is *extremely* weak (i.e., weak in at least three distinct ways (non-complex, identical to its corresponding username, and based on a word closely associated with the product)) inherently, and additionally is known to at *least* the IT staff (and probably more than that) of not just our software vendor but also every single one of their customers (who, incidentally, also have access to the complete customer list on the customer extranet). This is a PR disaster of epic proportions waiting to happen for us, not to mention a legal nightmare in the making, and there is nothing we can do about it, short of switching vendors. We didn't find out any of this until after we'd signed a multi-year contract for tens of thousands of dollars that we absolutely cannot afford, financially, to back out of. We can't change the password, because then the application won't work, since it's hardcoded there. Worse, we can't firewall the server off from the rest of our network, because the application requires that everything (and, in particular, the ports on which the database listens) be open from every staff workstation to the server, or the application won't work. We do have the whole network firewalled off from the outside world, but there's no defense in depth at all, and there's a big fat hole in the firewall through port 80, which the application needs to expose to the outside world for important parts of its functionality. The service listening on 80 is, you guessed it, IIS.
Additionally, there is a clause in our contract with the vendor that absolves them of *all* responsibility for our systems' security and specifies that if anything goes wrong, we have to pay *them* x number of dollars per hour to fix it. I am not making this up. I highlighted that and went to our director and said, point blank, "Don't sign the contract with this clause in it." So naturally she asked them about it, and they explained (verbally) that it's not a problem, the clause is only in there because some sites refuse to run antivirus software, and if we keep our antivirus up to date we won't have a problem, and no site has ever had a problem if they had antivirus protection. She *believed* them and signed the contract, because she's a director, not a paranoid systems administrator.
It's not mainly us that I'm worried about. We're a small-time outfit in a small city, not a target for anyone beyond the level of bored students fooling around. What scares me is that I know, deep down inside, that our vendor isn't the only vendor that pulls this sort of [language fails me; no word is foul enough].
> I do get shadow, both for the shadow password geek group, and for being a cool thing,
> like "the shadow knows..."
Shadow is also an extremely common username, IRC handle, self-chosen nickname, and so forth.
> spank the monkey, nut buster (like, bust a nut.), ass bandit (like, butt pirate?)
The explanations for buster and bandit are probably more prosaic, similar to shadow: they sound (or are supposed to sound) all mocho-cool, like shadow or iceman or whatnot.
All the sports-related ones are immediately obvious; it's the *other* thing the dude's into. I suspect the names or nicknames of popular lines of sports car are also common.
> I'm guessing on Maggie, is that in our demographic (err, guys between 18 and 80), there
> was a high ratio of women named Margaret to whom they were affectionally attached (married,
> dating, etc).
Unless the site has some kind of geographically localized target market, I really doubt this, as it fails to explain why "maggie" would be more common than much more generally popular names such as "jenny" or cetera. I suspect that "maggie" has a cultural signficance we're missing (which would in my case anyway not be unusual; I don't follow popular culture very closely, especially television or pop music) or a colloquial meaning we don't happen to know. My gut instinct is to wonder if it's etymologically related to the slang term "magpie". Check urbandictionary.com or ask around on a teen chatroom or something.
> Just because you can make a program crash, doesn't mean you can exploit it
No, it doesn't mean that *necessarily*; however, there is historically a significant likelihood that such *might* be the case. The most recent IE remote arbitrary code execution exploit was formerly just a denial-of-service attack that for one reason or another never got patched, and eventually someone figured out how to make exploit it in a way that allows arbitrary code to be injected and executed. There are many other examples over time of cases wherein a flaw in some program or another, when initially discovered, was only a denial-of-service (or perhaps not even proven exploitable at all) but code injection and execution developed as a later, more sophisticated exploit of the same vulnerability.
This should definitely get fixed, preferably *before* anybody discovers a way to do more malicious things than DOS with it. (And I have little doubt it will be fixed, probably quite soon, if past history is any indication of future performance.)
> I think history has shown that "better content" has little to do with search engine ranking.
It's not so much _better_ content per se as it is content that many webmasters want to link to.
This is one reason why anything related to computer/technical topics is practically guaranteed to show up before even much more common alternate meanings for the same word. For instance, the word "word" is an *exceedingly* common English word, but the top result on Google is for a software product. (This phenomenon is by no means limited to Microsoft products, either. The word "firebird" makes most of the general population think of automobiles, but the top five Google results are software-related, most of them for a product that has since been renamed.) Most web content, and especially most highly-ranked web content, is created by one brand or another of computer geek, so computer-related stuff rises to the top of the results.
There are other things you can do as well, sure, but nothing is more effective than having stuff on the site that lots of well-ranked web content creators want to link to.
> Please post your banking information here. lol, this am not a phishing atempt!
Sure, I will have done that for you:
Acct. Holder: Jorben M. Sverjoln
Acct. No.: 218-2818-284-59
Central Bank of Molvania
173 Busjbusj, Lutenblag, Molvania
> Jails should be for those who have committed serious crimes.
> Like it or not, sending you a virus or some spam isn't an overly serious crime.
Sending one person malicious code or whatnot is (all else being equal) not a very serious crime; however, releasing a worm that crawls its way around the internet and infects thousands of computers is thousands of times more serious. It's still not a *violent* crime, but it can easily cause (collectively) more dammage than, say, a high-profile embezzlement. In such cases, a prison sentence might very well be commensurate with the seriousness of the crime.
> The same goes for spam.
Again, sending one piece of spam to a dozen people is nothing, but nobody (well, nobody level-headed) is saying we should jail people for that, either. Sending gigabytes of spam per day to millions of people, on the other hand, is at *minimum* a really solid example of making a public nuissance of yourself on a grand scale, and frequently there are rather more serious offenses involved as well. For instance, if a spammer ignores "Don't contact me again" requests and continues to contact you, that's harrassment (the same as it would be if he were calling you on the phone and refused to stop). Fraud is also a popular legally-actionable component of some spamming operations, and there are others. Note that I'm not saying everyone who sends any junk mail at all necessarily engages in all of these crimes, but I don't think it would be in any way inappropriate to prosecute the ones who do and, if their offenses are sufficiently serious, imprison them.
> Please do not anthropromorphize the process of evolution
It's not the process that is being anthropomorphised, but the viruses. As we all know, viruses are computer programs, which, technically, are information. So what you have to ask yourself is, "Does information want to be anthropomorphised?"
> Seriously now, are viruses really evolving or is it just that the techniques used by virus
> writers are evolving?
Sure, nothing a little grammar can't fix. Just settle on it this way: viruses are being evolved. Notice how the passive voice neatly avoids the whole question of who is doing the evolving; the action could equally well be transitive (authors are evolving the viruses) or reflexive (viruses are evolving themselves), since the sentence only states that the evolution is occurring, leaving the question of who or what is performing it to be determined by the reader's own assumptions.
Of course, the statement "viruses are being evolved" concerns the observable present, so it really has little or nothing to do with the intelligent design debate, which centers on the unobservably distant past.
At minimum the court should require Microsoft to send every owner of one of these units a piece of string, with instructions. It wouldn't cost them that much, but it's the principle of the thing, now isn't it?
Of course, at their option, Microsoft could instead offer replacement units (without the problem) instead of the string-fix kit. Their marketing, legal, and financial departments could duke it out over which way to go on that.
> I think Microsoft could get Google's shareholders to agree, given a high enough price.
I don't think Microsoft would be willing to pay a high enough price for that. Bear in mind, Google isn't nearly the only competitor, and Microsoft places a high value on keeping some liquid resources so that they retain the ability to react to situations that arise. They wouldn't want to expend most of their available resources on one acquisition, however big. They could offer Microsoft stock or something along those lines, but think about how much of it they'd have to shell out to get Google's shareholders to agree to the thing; it would have to be quite a lot, enough probably that it would have an impact on the market value of Microsoft's own stock (as releasing too much at once creates a surplus); Microsoft's shareholders might not care for that. (Indeed, just a well-placed rumour to the effect that something like that was *about* to be announced could cause a stock-price sag for Microsoft, although it wouldn't last very long once the rumour turned out to be nothing.)
Anyway, it's moot, because the FTC would be just about as likely to allow a three-way merger between AT&T, Sprint, and Verizon.
> But I think the corporate cultures would clash so much as to make the merger completely
> detrimental to Google's future prospects.
Agreed.
I'm confused about why Microsoft doesn't diversify into some unrelated fields, e.g. open a restaurant chain or something. In software, they're the big dog at the top of the heap, and there's nowhere further to go there. (I don't mean they can't improve their software, but it's their position in the market I'm talking about.) Anybody who's had an economics class knows no company can stay on top in a field forever; you'd think they'd be working on a thirty-year plan to diversify into a dozen other industries, to ensure their continued strength as a company, irrespective of what might happen in any one industry.
> Whoa, whoa. The Vista implementation *sounds* better.
To me, it just sounds more convoluted. YMMV.
> I suppose that there are reasons why Microsoft
> can't just leave an inode in place after unlinking
> it so that processes that use it don't lose it
Microsoft's filesystems, as far as I am aware, do not *have* any such concept as inodes or hard links. Certainly FAT filesystems don't have anything like that. NTFS is rather more complicated, and I don't fully understand it, but if it has any concept of inodes or hard links this is news to me.
> I'm not sure who has money to buy them.
Several corporations have the money, but whether any also would have the desire *and* be permitted to do so is another matter. For instance, Microsoft would want to buy Google, but such a merger would be quite unlikely to be approved, due to antitrust considerations. A company like Ikea might be able to get such an acquisition approved, but Google would be a bad investment for Ikea (for several reasons; among them, Ikea would have to view Google as potentially overvalued now and, with their recent rise, almost certainly not undervalued at this point, so there's plenty to lose and little to gain; the dynamics are different for Microsoft, which has more to gain from such an acquisition, but that's exactly why it wouldn't be approved). There probably is not a company with both the money *and* the desire, except for extremely large and profitable tech firms (cheifly Microsoft), and for them there are big antitrust issues getting in the way.
Then there's the small matter of Google's shareholders needing to approve any such thing in order for it to take place, even if the FTC *does* allow it. Raise your hand if you think Google's current shareholders would vote "yes" to acquisition by Microsoft under any balanced and reasonable terms (i.e., terms Microsoft would potentially also agree to).
> Leaked memory is memory which is still allocated to the leaking process
Only if the operating system keeps track of which process it was that allocated the memory. In general, reasonable modern operating systems do this, of course, but there have been systems that didn't. Another thing that happened on those systems was that if one program had pointer errors, it could end up corrupting the memory of another process, and the OS wouldn't even know, much less prevent it. (That's also possible on systems that do know which process owns the memory but don't protect it from other processes, e.g. because there's no security model or because memory access doesn't have to go through the OS API and any process can execute whatever machine code it wants.)