Also, is it possible that guys like Amazon.com and Yahoo have nothing more than poorly configured firewalls?
With a DDoS attack a firewall becomes just another box to get choked on traffic. And even if it is able to filter out the attack, it can't do anything to unclog routers upstream.
When Amazon, Yahoo!, and so on say that there is no guaranteed way to prevent such attacks, they're not just trying to cover their asses. All they can do is have the routers upstream of an attack configured to filter it out-- which generally means blocking some legitimate traffic along that route as well. The latter is why they are limited in the precautions they can take beforehand.
Theories based on burning dust have already been rejected because such combustion doesn't yield enough energy for ball lightning's luminance and (sometimes) longevity. I don't think binding particles into microchains, as this article proposes, changes this problem. There are reports of ball lightning boiling water, melting glass, exploding with enough force to cause structural damage--all phenomena which require far more energy than combustion of the small amount of material that can be supported by the buoyancy of its own heated gas.
This doesn't even mention ball lightning's occurance inside airplanes, its tendency to be attracted to conductors, its occurance without any nearby lightning strikes, or its similarity to other electrical plasma phenomena, such as ball plasmas observed near high-current switches (like on electrically-powered submarines).
Just because you come up with a hypothesis that explains a few of ball lightning's characteristics doesn't mean anything until you can explain all of them.
I didn't say that there was no correlation between SAT's and college performance. What I implied was that there is room for improvement.
I'm old enough to be well along in my career, and I've been fairly successful at it. The challenges I've faced have had little to do with what's tested in the SAT. Granted, the challenges I had in college were more like the SAT--specifically, the multiple-choice exams I had to take. But those wound up being less that half of my grades, and an even smaller--much smaller--part of what I now find valuable from my college experience.
Standardized tests are a multi-billion-dollar industry, an industry with a lot of political clout and a large marketing budget. I won't deny that such tests have a useful correlation with future success (though I think there is at least some element of self-fulfilling prophecy in that fact). At this point in time trying to come up with something better is a courageous act, in my opinion. I wish them luck.
BOF's go back to the earliest days of USENIX (the original Unix gathering, started in the early '80's long before commercial Unix even existed), though the term was probably "borrowed" from some still older source. So in a sense, both definitions are the correct ones! The BOF's are the ones most likely to know what BOF's are...
As in "reading the article." Looking over comments, here are a couple of things most posters seem to have missed:
The lego test is only one of a series of twelve workshop tests performed.
The schools are looking for tests that are better predictors of college success. These workshop-based tests are an experiment to find such tests--they are only being used for a highly limited number of admissions, with the outcome carefully tracked. Maybe they'll work, maybe they won't.
As alluded to in the article, the dirty little secret of standardized tests is that they correlate better with socioeconomic background than they do with ultimate college success. And that's to be expected--kids from more affluent families went to better schools, got more help from their (usually) college-educated parents, and so forth. Most of us who have been through college know people who aced their SAT's but royally screwed up their coursework. These schools are looking for something better, somthing that measures ability to succeed as well as general knowledge.
The margin on a PC is tiny. It would be impossible for someone to enter the market and achive significant market share. Investors wouldn't support them, since they'd just lose money to the Dell's, Gateway's, and others who have:
achived enormous economies of scale,
still aren't making much money, and
aren't likely to come up with a product new and different enough to raise profit margins.
None of these limitations apply in the portable/wireless Internet market. Any number of killer, high-margin products remain to be developed and sold. It's a new market, not a "mature" one. TI (and Motorola, and...) are right to focus on it.
Desktop and portable PC's aren't going away any time soon--they still be made in the tens of millions for years to come. But that's not where money is to be made.
Is TI trying to pump up this new market with this sort of PR? Of course! And as well they should. Trying to start something new in the PC market would be a colossal waste of money.
Like the 1997 procfs issue, this one involves improper control over a file descriptor opened on/proc/[pid]/mem. The difference is that, instead of modifying the memory of a priviledged process, we coerce a priviledged process into modifying its own memory. An obvious way of doing this is by opening/proc/[pid]/mem on stderr, seeking to the area of memory you wish to modify, then exec()'ing the priviledged program and causing it to log a "message" to stderr that allows you to hijack control via the overwritten memory.
This is harder than the original exploit (process Afork()'s B, grabs access to B's memory, then Bexec()'s a priviledged process where A can still write its memory and thus hijack control). But it still involves writing the process memory file. As much as I like the Unix "everything-is-a-file" concept, these two exploits show just how much it complicates security.
Read their press release here; note that this is hardly their first Linux-based project. In fact, they've been using Linux since 1997, back when SlashDot was little more than a gleam in Rob's eye...
Although some elements could have been a bit clearer (you have to figure out just what "BSS" is from context unless you already know the appropriate Unixese), Matt has the most lucid explanation of page coloring I've ever read. Skip down to the bottom of the article to read it. It's a good example of why even wholly compute-bound programs can differ in performance under different OSes with the exact same hardware and compiler.
People have been commenting on the death of civility long before the Internet phenomenon (since the end of the Victorian age, at least). Each generation bemoans the brashness of the one that follows.
The phenomena Katz notes aren't restricted to online, and are hardly related to anonymity. Remember "Talk Radio?" "Trash TV?" People on Jerry Springer are hardly anonymous, but that probably makes them less rather than more civil. The fact is that some people are mean and/or crude, and always have been. Technology just widens our view so we see more of what's been there all along.
I think Katz is seeing differences where none exist. Bullies have always gotten the "reward" of hollow respect from their peers. Anonymity actually makes them easier, not harder, to ignore--they're just annoying noise, not some menancing presence threatening physical violence.
Katz obviously has some issues with various social behaviors, and some insights (and I would argue misconceptions) concerning them. But when he tries to show some technological connection, he rarely hits the mark. He still belongs here, since his stuff certainly qualifies as "news for nerds." But he should back off from these failed attempts at techno-hipness and focus on the more general issues in his in-group/out-group social commentary.
Don't know about yours, but my tar preserves permissions. Admittedly, using tar in this way is idiomatic--one of those arcane Unixisms (though it goes back 30 years). Perhaps you'd prefer cpio which was explicitly created to facilitate pipelined use, and has a more intuitive name.
As for configuration, if you don't understand what something is in a BSD config file, just leave it alone. If you know just what POSIX scheduling or syscall compliance mean, the configuration you quoted from "LINT" makes perfect sense. If you don't know just what these things are, one-paragraph Linux-style help isn't going to be nearly enough--except that it might say "you probably want this" or "you probably don't want this." In BSD-land the attitude of "don't touch what you don't understand yet" will pull you through as least as well, though perhaps without the personal touch of the computer addressing you in the second person. In either case, a good session of RTFM is called for.
You keep defensively referring to "You" and "Your" in your post; who are you speaking of? Me? I use both FreeBSD and Linux, and see no need to defend one side against the other. Yahoo! uses Solaris, Linux, and WinNT--whatever is appropriate for a task--and not just FreeBSD (though the latter does all the heavy lifting).
FreeBSD wouldn't be my choice, either, for a scientific computation server. I'm curious, though, why you chose Intel P-III's for a platform. Most science codes aren't written for SMP (often the algorithms used don't adapt to concurrency in any case) so you're limiting them to the speed of a single P-III, which has pretty anemic floating-point performance. Why not use Alpha, which runs Linux very well and has world-class FP performance, both SMP and UP? Scientific computing is one of the few areas where Alpha is still cost-effective compared to Intel.
Like I said, whatever is appropriate for a task...
The BSD toolset tends to be a little less user-friendly than the equivalent tools from Gnu. Eg, with Gnu tools, you can decide after the fact to add the switches, and they work
If by "user-friendly" you mean "lots of sometimes-confusing options" then, yes, the GNU tools tend to have more features, and you can arrange your command-line arguments twelve different ways from Sunday. That's not necessarily a good thing, though I admit it's a matter of personal taste. Taking your example:
cp -Rv
there is no direct BSD equivalent, but I'd tend to use something like:
tar cf - src | (cd dst;tar xvf -)
in any case. cp has entirely too many options as it is. It's easier for me to remember the tar pipeline than the two dozen options that GNU cp supports. It's the Unix way--combining tools into pipelines and sequences like LEGO blocks--while the GNU way has tended more towards the all-in-one approach. So when you say "there's no equivalent for *BSD" you really meant "there's no equivalent command." It's not impossible or even necessarily harder to do in BSD-land (though I admit it's more typing, and less intuitive to folks used to DOS-land).
You also say that:
Kernel compilation is more like the Bad Old Days under commercial Unixes.
I couldn't disagree more! Doing a "make config" (or its curses or X11 equivalent) in Linux is a tremendous leap of faith compared to configuring a BSD kernel. There are over a hundred questions to be answered, and a wrong answer to any one of them can torpedo your chances at a working kernel. You're no more vulnerable editing a BSD config file, and in fact if you have a listing of the LINT config you usually know just what you need to know to enable/disable any given option or driver. I've experienced the Bad Old Days (having edited SunOS config files more times than I'd like to admit) and I have to say that BSD configuration has improved a lot, both in terms of documentation and of things you can leave for the kernel to figure out itself.
You also mention:
Performance differences--FreeBSD SMP is noticeably slower than under Linux on the same hardware.
I agree (as would a fair amount of the BSD community) that Linux is getting an edge in SMP. The fact is that this is often of limited importance for well-designed server installations. It's actually an advantage (if you can architect it) to distribute load over n entirely separate hardware entities than some n-CPU entity. That way, a failure won't take out n units of capacity, just 1. Harder to do? Sure, in some ways it is. A bunch of processors sharing memory allow solutions that isolated processors connected only via an LAN cannot. But this hasn't been that much of a limitation for my employer, Yahoo!. Your mileage, of course, might vary.
I've run both Linux and FreeBSD for several years, now, both at work and at home. They both have their strengths. As a "Fundamentalist" Unix person, BSD seems a bit more like "home" to me. But I'm typing this into my home Linux box (a foot from my home FreeBSD box), and I have to admit that there is greater breadth and depth in the current Linux scene--in general, though not necessarily in specific areas. And sometimes the Linux folks seem to be adding legs to the [painted] snake (to use a Zen aphorism). But I see nothing but "synergy" (what a polluted word at this point, but I know of none better) between BSD and Linux, or even between the GNU and Unix (non-commercial and commercial) camps. (And you though the "Gnu's Not Unix" acronym was merely cute.) I'll likely be using both of these great systems for a long time--until something better comes along. (Not likely:-).
Anyway, what's up with that two week freeze period? Isn't that a little short?
FreeBSD does things a bit differently than Linux. All code is in a CVS server. Every day (more or less) many developers bring their code up-to-date (with "cvsup" or equivalent) and do a "make world," perhaps after reviewing that day's changes first (which are posted automatically to a mailing list). Then they run their favorite tests and/or applications. So you can say that the FreeBSD system (not just the kernel--everything needed to run a FreeBSD system) is under continuous integration and testing. Everything is known to more-or-less work and play together before the freeze. The 15-day shakedown is thus a time to focus on finding issues that somehow got missed during the continuous develop/integrate/test process.
This is different from Linux; in some ways it's slower and more restrictive, but I rather like it. Although 4.0 has a lot of improvements over the 3.x series, most of them are evolutionary, especially compared to some of the wholesale reworkings of kernel mechanisms between major Linux releases (1.2, 2.0, 2.2, 2.4...). This, combined with the FreeBSD development methodology, mean that instead of a mad scramble to get everything integrated for a final release, it's more a matter of dotting i's and crossing t's until the system passes muster with the core team and the CVS tree is labeled RELEASE.
As to just what is new and/or different in 4.0, there are folks here who know much better than I do...
I think the issue here is that a post based on misinformation has been moderated upward twice as "Informative" while a post providing correct information languishes at zero. The facts here shouldn't be controversial: even if the Big Bang Theory is a Big Bust, or even if the cosmic background radiation is a measurement error (doubtful, but for the sake of argument let's say it is), such radiation is in the microwave region, not X-ray. So this new discovery has nothing to do with the background radiation claims of the Big Bang Theory.
I don't want to be hard on the original poster-- many is the time that I've had this kind of an "Aha!," then further information shows me to be embarrassingly mistaken. And I'm sure the two moderators made exactly the same mistake the poster did. This happens all the time on Slashdot where something seems insightful/interesting/informative at first glance and gets moderated up (moderators are busy people, after all), with a correcting post coming some time later when there is so much else competing for moderators' attention that the correction lays untouched at 0 or 1.
Even though this offends my sense of justice a bit--misinformation getting marked as "informative" isn't one of moderation's finest hours--moderation works well enough that cases like this only call for its imporvement, not its abolition.
As for whether the original article being "news:" Hell, yes! The cosmos proves more wondrously strange each time we expand the "eyes" and "ears" we use to examine it. There is a good chance that there will be far more questions than answers generated in astrophysics during our lifetimes, given the new technologies we'll be able to point "out there," but that makes it all the more interesting and inspiring.
So, RedHat is using its stock valuation to increase future profitibility by merging with compatible companies with good earnings potential? Sounds like they're doing the right thing, then. Think of it as a positive feedback loop--a higher valuation enables a company to increase its earnings via appropriate mergers, which of course helps justify the high valuation.
In other words, RedHat's investors are in effect giving RedHat money to invest and manage for them. If all RedHat did with the money was make lots of expensive CDROMs with a middling-quality Linux distro on them, I doubt if investors would stay with them very long.
You seem to have missed the fact that RedHat has never claimed that those distro CDROMs would be their major revenue source in the future--rather that services and other products would be the growth areas. Their stock valuation makes them even less reliant on income from their distribution, since they now can pursue partnerships and products that they could hardly have dreamed of pre-IPO.
For example, the *BSD community already accepts, enthusiastically, the prospect of binary-only proprietary versions of their OSes being shipped, so I assume convincing a vendor to do a driver for a *BSD OS would be much less likely to help Linux programmers "bring it over" than vice-versa.
I'm sorry, but this just doesn't wash. First of all, proprietary binary-only Linux drivers are easy to produce, and many of them already exist for sound cards, video cards, and the like. How is this better than the situation with BSD? Second of all, you present a wholly misleading picture of the BSD community's attitude toward proprietary use. A tradition of sharing among BSD developers is as old as BSD itself (three times as long as Linux has existed). Closed development is hardly encouraged--to say it is accepted "enthusiastically" is grossly misleading. But unlike Linux, it is permitted, and open contributions from developers who also produce closed products from BSD are warmly accepted. At least in some cases this results in more of a contribution than the all-or-nothing approach Linux espouses. Of course, it can go the other way, too. But I don't find your presentation at all balanced.
Regardless of this, I agree with you that Linux makes the most sense because of its mindshare, momentum, and volume. I think the original point was that open drivers don't need to be limited to Linux (as they would be if released solely under GPL--forgetting about Hurd for the moment).
you're an old-timer like me, so you may remember the use of that on some versions of PDP-11 UNIX and various PDP-11 OSes from Digital)
Yes, 2.4 BSD allowed for overlays, as did RSX/11. This was a matter of the OS reloading some segmentation registers on request. Pentia could do similar things via the page table, should someone care to add the necessary OS calls. But it was yucky even back then. I've recomitted those brain cells to other tasks these days.
Since the Pentium Pro, there has been the ability on Intel chips to address more than 4GB of ram.
P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques. At any one moment, only 4GB can be addressed because that's all 32 bits allow. You can't mmap in a 5GB file, or use an array of 550 million doubles. A 64-bit processor can access many petabytes-- directly. Not something useful on most app servers, but the database, video and science folks sure like it.
Getting a patent is only 1 step...it has to hold up in court as well. There is no way this would ever hold up, and I don't think the amazon patent will either.
Unfortunately, a court has already found enough merit in Amazon's case to slap Barnes & Noble with a restraining order. This means that at least that court felt that there was a good chance that Amazon would prevail.
The big danger in these cases--and especially the Date Window case--is that if they ultimately hold up (and there is a significant chance that one or both might), it will become even easier to obtain and enforce trivial software patents. And here we thought it couldn't get any worse...
Heh. The question is whether Yahoo! is dropping Real Media or not. They don't have much reason to lie to you about that one. Now as to why they're doing it--you can save the conspiracy theory questions for the end of the call. Perhaps you'll get lucky.
Oh, and one thing you might not have noticed: Yahoo! and MSN are direct competitors. Yahoo! has little reason to be doing Microsoft any favors.
Then take the News for Nerds out of the masthead. Change it to Unattributed Rumors for Nerds.
People who post stories are editors, whatever they call themselves. Those newfound millionaires that run this site aren't just "some guys who post stuff they find interesting." Like it or not, they've achieved a fair amount of importance and influence. A rumor can gain an enormous amount of momentum just because they found it "interesting" enough to post, whatever the responses. And as for moderation, I've seen stuff that I knew to be untrue moderated up while someone who actually posts the facts languishes at Score 1 because they signed in too late. Moderation is heavily biased toward reasonable- sounding posts that are submitted early to the neglect of better posts that are submitted a couple of hours later.
I've gotta agree. The frequency with which a rumor is repeated has little to do with its truth or falsehood. What's sad is that it's not that hard to pick up the phone and check out a rumor like this. Yahoo's phone number is (408)731-3300, as a call to LD information (or a visit to their site) would quickly reveal. Just ask to speak to their "Public Information Department." Even if they don't have one, this will get you pointed in the right direction.
If the spokesperson you reach says that they can't reveal such plans, then put that in your report. If they say they don't know, ask them to find out and call you back. If they don't call back, call them again. Finally, if they're still evasive, put that in your report. Take notes. Be friendly, especially if you're asking for a favor (like a call back).
This is Journalism 101, I know, and it's a shame that someone even needs to suggest it.
The article wasn't specific as to hardware, but since they said it was "much like the Avalon cluster" they might well be using Alphas, not Pentia. $5k/box would be a good price if they are using the newer Alpha boxes based on the 21264 chip (which is better than twice as fast, on average, than the 21164's used in Avalon, even at the same MHz).
However, the fact that Linux is an Open Source OS means, that parts of it and information gained from reading its source code will be used elsewhere, so even if one day it stops being popular, these things will still be around.
This is precisely the power of open-source. Closed-source software generally has little legacy; when the company that produced it goes under, or merely cancels the product, it dies. On the other hand, open-source software doesn't get buried and forgotten based on the failure of other business efforts or the whim of some project manager. Tools, libraries, even individual routines, get stripped out, cleaned off, and reused.
HURD may or may not be successful. But one interesting thing about its architecture is that it will be much easier to "strip for parts" than the Linux kernel. So after both Linux and HURD are long gone, the latter may wind up with the most impact even if it doesn't achieve Linux's popularity.
Slashdot Mirror
With a DDoS attack a firewall becomes just another box to get choked on traffic. And even if it is able to filter out the attack, it can't do anything to unclog routers upstream.
When Amazon, Yahoo!, and so on say that there is no guaranteed way to prevent such attacks, they're not just trying to cover their asses. All they can do is have the routers upstream of an attack configured to filter it out-- which generally means blocking some legitimate traffic along that route as well. The latter is why they are limited in the precautions they can take beforehand.
Theories based on burning dust have already been rejected because such combustion doesn't yield enough energy for ball lightning's luminance and (sometimes) longevity. I don't think binding particles into microchains, as this article proposes, changes this problem. There are reports of ball lightning boiling water, melting glass, exploding with enough force to cause structural damage--all phenomena which require far more energy than combustion of the small amount of material that can be supported by the buoyancy of its own heated gas.
This doesn't even mention ball lightning's occurance inside airplanes, its tendency to be attracted to conductors, its occurance without any nearby lightning strikes, or its similarity to other electrical plasma phenomena, such as ball plasmas observed near high-current switches (like on electrically-powered submarines).
Just because you come up with a hypothesis that explains a few of ball lightning's characteristics doesn't mean anything until you can explain all of them.
I didn't say that there was no correlation between SAT's and college performance. What I implied was that there is room for improvement.
I'm old enough to be well along in my career, and I've been fairly successful at it. The challenges I've faced have had little to do with what's tested in the SAT. Granted, the challenges I had in college were more like the SAT--specifically, the multiple-choice exams I had to take. But those wound up being less that half of my grades, and an even smaller--much smaller--part of what I now find valuable from my college experience.
Standardized tests are a multi-billion-dollar industry, an industry with a lot of political clout and a large marketing budget. I won't deny that such tests have a useful correlation with future success (though I think there is at least some element of self-fulfilling prophecy in that fact). At this point in time trying to come up with something better is a courageous act, in my opinion. I wish them luck.
BOF's go back to the earliest days of USENIX (the original Unix gathering, started in the early '80's long before commercial Unix even existed), though the term was probably "borrowed" from some still older source. So in a sense, both definitions are the correct ones! The BOF's are the ones most likely to know what BOF's are...
As in "reading the article." Looking over comments, here are a couple of things most posters seem to have missed:
- The lego test is only one of a series of twelve workshop tests performed.
- The schools are looking for tests that are better predictors of college success. These workshop-based tests are an experiment to find such tests--they are only being used for a highly limited number of admissions, with the outcome carefully tracked. Maybe they'll work, maybe they won't.
As alluded to in the article, the dirty little secret of standardized tests is that they correlate better with socioeconomic background than they do with ultimate college success. And that's to be expected--kids from more affluent families went to better schools, got more help from their (usually) college-educated parents, and so forth. Most of us who have been through college know people who aced their SAT's but royally screwed up their coursework. These schools are looking for something better, somthing that measures ability to succeed as well as general knowledge.It's worth a try, in any case.
The margin on a PC is tiny. It would be impossible for someone to enter the market and achive significant market share. Investors wouldn't support them, since they'd just lose money to the Dell's, Gateway's, and others who have:
None of these limitations apply in the portable/wireless Internet market. Any number of killer, high-margin products remain to be developed and sold. It's a new market, not a "mature" one. TI (and Motorola, and ...) are right to focus on it.
Desktop and portable PC's aren't going away any time soon--they still be made in the tens of millions for years to come. But that's not where money is to be made.
Is TI trying to pump up this new market with this sort of PR? Of course! And as well they should. Trying to start something new in the PC market would be a colossal waste of money.
Like the 1997 procfs issue, this one involves improper control over a file descriptor opened on /proc/[pid]/mem. The difference is that, instead of modifying the memory of a priviledged process, we coerce a priviledged process into modifying its own memory. An obvious way of doing this is by opening /proc/[pid]/mem on stderr, seeking to the area of memory you wish to modify, then exec()'ing the priviledged program and causing it to log a "message" to stderr that allows you to hijack control via the overwritten memory.
This is harder than the original exploit (process A fork()'s B, grabs access to B's memory, then B exec()'s a priviledged process where A can still write its memory and thus hijack control). But it still involves writing the process memory file. As much as I like the Unix "everything-is-a-file" concept, these two exploits show just how much it complicates security.
Read their press release here; note that this is hardly their first Linux-based project. In fact, they've been using Linux since 1997, back when SlashDot was little more than a gleam in Rob's eye...
Pretty impressive.
Although some elements could have been a bit clearer (you have to figure out just what "BSS" is from context unless you already know the appropriate Unixese), Matt has the most lucid explanation of page coloring I've ever read. Skip down to the bottom of the article to read it. It's a good example of why even wholly compute-bound programs can differ in performance under different OSes with the exact same hardware and compiler.
People have been commenting on the death of civility long before the Internet phenomenon (since the end of the Victorian age, at least). Each generation bemoans the brashness of the one that follows.
The phenomena Katz notes aren't restricted to online, and are hardly related to anonymity. Remember "Talk Radio?" "Trash TV?" People on Jerry Springer are hardly anonymous, but that probably makes them less rather than more civil. The fact is that some people are mean and/or crude, and always have been. Technology just widens our view so we see more of what's been there all along.
I think Katz is seeing differences where none exist. Bullies have always gotten the "reward" of hollow respect from their peers. Anonymity actually makes them easier, not harder, to ignore--they're just annoying noise, not some menancing presence threatening physical violence.
Katz obviously has some issues with various social behaviors, and some insights (and I would argue misconceptions) concerning them. But when he tries to show some technological connection, he rarely hits the mark. He still belongs here, since his stuff certainly qualifies as "news for nerds." But he should back off from these failed attempts at techno-hipness and focus on the more general issues in his in-group/out-group social commentary.
Don't know about yours, but my tar preserves permissions. Admittedly, using tar in this way is idiomatic--one of those arcane Unixisms (though it goes back 30 years). Perhaps you'd prefer cpio which was explicitly created to facilitate pipelined use, and has a more intuitive name.
As for configuration, if you don't understand what something is in a BSD config file, just leave it alone. If you know just what POSIX scheduling or syscall compliance mean, the configuration you quoted from "LINT" makes perfect sense. If you don't know just what these things are, one-paragraph Linux-style help isn't going to be nearly enough--except that it might say "you probably want this" or "you probably don't want this." In BSD-land the attitude of "don't touch what you don't understand yet" will pull you through as least as well, though perhaps without the personal touch of the computer addressing you in the second person. In either case, a good session of RTFM is called for.
You keep defensively referring to "You" and "Your" in your post; who are you speaking of? Me? I use both FreeBSD and Linux, and see no need to defend one side against the other. Yahoo! uses Solaris, Linux, and WinNT--whatever is appropriate for a task--and not just FreeBSD (though the latter does all the heavy lifting).
FreeBSD wouldn't be my choice, either, for a scientific computation server. I'm curious, though, why you chose Intel P-III's for a platform. Most science codes aren't written for SMP (often the algorithms used don't adapt to concurrency in any case) so you're limiting them to the speed of a single P-III, which has pretty anemic floating-point performance. Why not use Alpha, which runs Linux very well and has world-class FP performance, both SMP and UP? Scientific computing is one of the few areas where Alpha is still cost-effective compared to Intel.
Like I said, whatever is appropriate for a task...
A few comments:
If by "user-friendly" you mean "lots of sometimes-confusing options" then, yes, the GNU tools tend to have more features, and you can arrange your command-line arguments twelve different ways from Sunday. That's not necessarily a good thing, though I admit it's a matter of personal taste. Taking your example:there is no direct BSD equivalent, but I'd tend to use something like:
in any case. cp has entirely too many options as it is. It's easier for me to remember the tar pipeline than the two dozen options that GNU cp supports. It's the Unix way--combining tools into pipelines and sequences like LEGO blocks--while the GNU way has tended more towards the all-in-one approach. So when you say "there's no equivalent for *BSD" you really meant "there's no equivalent command." It's not impossible or even necessarily harder to do in BSD-land (though I admit it's more typing, and less intuitive to folks used to DOS-land).
You also say that:
I couldn't disagree more! Doing a "make config" (or its curses or X11 equivalent) in Linux is a tremendous leap of faith compared to configuring a BSD kernel. There are over a hundred questions to be answered, and a wrong answer to any one of them can torpedo your chances at a working kernel. You're no more vulnerable editing a BSD config file, and in fact if you have a listing of the LINT config you usually know just what you need to know to enable/disable any given option or driver. I've experienced the Bad Old Days (having edited SunOS config files more times than I'd like to admit) and I have to say that BSD configuration has improved a lot, both in terms of documentation and of things you can leave for the kernel to figure out itself.
You also mention:
I agree (as would a fair amount of the BSD community) that Linux is getting an edge in SMP. The fact is that this is often of limited importance for well-designed server installations. It's actually an advantage (if you can architect it) to distribute load over n entirely separate hardware entities than some n -CPU entity. That way, a failure won't take out n units of capacity, just 1 . Harder to do? Sure, in some ways it is. A bunch of processors sharing memory allow solutions that isolated processors connected only via an LAN cannot. But this hasn't been that much of a limitation for my employer, Yahoo!. Your mileage, of course, might vary.
I've run both Linux and FreeBSD for several years, now, both at work and at home. They both have their strengths. As a "Fundamentalist" Unix person, BSD seems a bit more like "home" to me. But I'm typing this into my home Linux box (a foot from my home FreeBSD box), and I have to admit that there is greater breadth and depth in the current Linux scene--in general, though not necessarily in specific areas. And sometimes the Linux folks seem to be adding legs to the [painted] snake (to use a Zen aphorism). But I see nothing but "synergy" (what a polluted word at this point, but I know of none better) between BSD and Linux, or even between the GNU and Unix (non-commercial and commercial) camps. (And you though the "Gnu's Not Unix" acronym was merely cute.) I'll likely be using both of these great systems for a long time--until something better comes along. (Not likely :-).
FreeBSD does things a bit differently than Linux. All code is in a CVS server. Every day (more or less) many developers bring their code up-to-date (with "cvsup" or equivalent) and do a "make world," perhaps after reviewing that day's changes first (which are posted automatically to a mailing list). Then they run their favorite tests and/or applications. So you can say that the FreeBSD system (not just the kernel--everything needed to run a FreeBSD system) is under continuous integration and testing. Everything is known to more-or-less work and play together before the freeze. The 15-day shakedown is thus a time to focus on finding issues that somehow got missed during the continuous develop/integrate/test process.
This is different from Linux; in some ways it's slower and more restrictive, but I rather like it. Although 4.0 has a lot of improvements over the 3.x series, most of them are evolutionary, especially compared to some of the wholesale reworkings of kernel mechanisms between major Linux releases (1.2, 2.0, 2.2, 2.4...). This, combined with the FreeBSD development methodology, mean that instead of a mad scramble to get everything integrated for a final release, it's more a matter of dotting i's and crossing t's until the system passes muster with the core team and the CVS tree is labeled RELEASE.
As to just what is new and/or different in 4.0, there are folks here who know much better than I do...
I think the issue here is that a post based on misinformation has been moderated upward twice as "Informative" while a post providing correct information languishes at zero. The facts here shouldn't be controversial: even if the Big Bang Theory is a Big Bust, or even if the cosmic background radiation is a measurement error (doubtful, but for the sake of argument let's say it is), such radiation is in the microwave region, not X-ray. So this new discovery has nothing to do with the background radiation claims of the Big Bang Theory.
I don't want to be hard on the original poster-- many is the time that I've had this kind of an "Aha!," then further information shows me to be embarrassingly mistaken. And I'm sure the two moderators made exactly the same mistake the poster did. This happens all the time on Slashdot where something seems insightful/interesting/informative at first glance and gets moderated up (moderators are busy people, after all), with a correcting post coming some time later when there is so much else competing for moderators' attention that the correction lays untouched at 0 or 1.
Even though this offends my sense of justice a bit--misinformation getting marked as "informative" isn't one of moderation's finest hours--moderation works well enough that cases like this only call for its imporvement, not its abolition.
As for whether the original article being "news:" Hell, yes! The cosmos proves more wondrously strange each time we expand the "eyes" and "ears" we use to examine it. There is a good chance that there will be far more questions than answers generated in astrophysics during our lifetimes, given the new technologies we'll be able to point "out there," but that makes it all the more interesting and inspiring.
So, RedHat is using its stock valuation to increase future profitibility by merging with compatible companies with good earnings potential? Sounds like they're doing the right thing, then. Think of it as a positive feedback loop--a higher valuation enables a company to increase its earnings via appropriate mergers, which of course helps justify the high valuation.
In other words, RedHat's investors are in effect giving RedHat money to invest and manage for them. If all RedHat did with the money was make lots of expensive CDROMs with a middling-quality Linux distro on them, I doubt if investors would stay with them very long.
You seem to have missed the fact that RedHat has never claimed that those distro CDROMs would be their major revenue source in the future--rather that services and other products would be the growth areas. Their stock valuation makes them even less reliant on income from their distribution, since they now can pursue partnerships and products that they could hardly have dreamed of pre-IPO.
I'm sorry, but this just doesn't wash. First of all, proprietary binary-only Linux drivers are easy to produce, and many of them already exist for sound cards, video cards, and the like. How is this better than the situation with BSD? Second of all, you present a wholly misleading picture of the BSD community's attitude toward proprietary use. A tradition of sharing among BSD developers is as old as BSD itself (three times as long as Linux has existed). Closed development is hardly encouraged--to say it is accepted "enthusiastically" is grossly misleading. But unlike Linux, it is permitted, and open contributions from developers who also produce closed products from BSD are warmly accepted. At least in some cases this results in more of a contribution than the all-or-nothing approach Linux espouses. Of course, it can go the other way, too. But I don't find your presentation at all balanced.
Regardless of this, I agree with you that Linux makes the most sense because of its mindshare, momentum, and volume. I think the original point was that open drivers don't need to be limited to Linux (as they would be if released solely under GPL--forgetting about Hurd for the moment).
Yes, 2.4 BSD allowed for overlays, as did RSX/11. This was a matter of the OS reloading some segmentation registers on request. Pentia could do similar things via the page table, should someone care to add the necessary OS calls. But it was yucky even back then. I've recomitted those brain cells to other tasks these days.
P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques. At any one moment, only 4GB can be addressed because that's all 32 bits allow. You can't mmap in a 5GB file, or use an array of 550 million doubles. A 64-bit processor can access many petabytes-- directly. Not something useful on most app servers, but the database, video and science folks sure like it.
Unfortunately, a court has already found enough merit in Amazon's case to slap Barnes & Noble with a restraining order. This means that at least that court felt that there was a good chance that Amazon would prevail.
The big danger in these cases--and especially the Date Window case--is that if they ultimately hold up (and there is a significant chance that one or both might), it will become even easier to obtain and enforce trivial software patents. And here we thought it couldn't get any worse...
Heh. The question is whether Yahoo! is dropping Real Media or not. They don't have much reason to lie to you about that one. Now as to why they're doing it--you can save the conspiracy theory questions for the end of the call. Perhaps you'll get lucky.
Oh, and one thing you might not have noticed: Yahoo! and MSN are direct competitors. Yahoo! has little reason to be doing Microsoft any favors.
Then take the News for Nerds out of the masthead. Change it to Unattributed Rumors for Nerds.
People who post stories are editors, whatever they call themselves. Those newfound millionaires that run this site aren't just "some guys who post stuff they find interesting." Like it or not, they've achieved a fair amount of importance and influence. A rumor can gain an enormous amount of momentum just because they found it "interesting" enough to post, whatever the responses. And as for moderation, I've seen stuff that I knew to be untrue moderated up while someone who actually posts the facts languishes at Score 1 because they signed in too late. Moderation is heavily biased toward reasonable- sounding posts that are submitted early to the neglect of better posts that are submitted a couple of hours later.
As for credibility--is it too much to ask for?
I've gotta agree. The frequency with which a rumor is repeated has little to do with its truth or falsehood. What's sad is that it's not that hard to pick up the phone and check out a rumor like this. Yahoo's phone number is (408)731-3300, as a call to LD information (or a visit to their site) would quickly reveal. Just ask to speak to their "Public Information Department." Even if they don't have one, this will get you pointed in the right direction.
If the spokesperson you reach says that they can't reveal such plans, then put that in your report. If they say they don't know, ask them to find out and call you back. If they don't call back, call them again. Finally, if they're still evasive, put that in your report. Take notes. Be friendly, especially if you're asking for a favor (like a call back).
This is Journalism 101, I know, and it's a shame that someone even needs to suggest it.
Slashdot, whither goest thou?
The article wasn't specific as to hardware, but since they said it was "much like the Avalon cluster" they might well be using Alphas, not Pentia. $5k/box would be a good price if they are using the newer Alpha boxes based on the 21264 chip (which is better than twice as fast, on average, than the 21164's used in Avalon, even at the same MHz).
This is precisely the power of open-source. Closed-source software generally has little legacy; when the company that produced it goes under, or merely cancels the product, it dies. On the other hand, open-source software doesn't get buried and forgotten based on the failure of other business efforts or the whim of some project manager. Tools, libraries, even individual routines, get stripped out, cleaned off, and reused.
HURD may or may not be successful. But one interesting thing about its architecture is that it will be much easier to "strip for parts" than the Linux kernel. So after both Linux and HURD are long gone, the latter may wind up with the most impact even if it doesn't achieve Linux's popularity.
"Houyhnhnm."