1) djbdns uses separate IP addresses for caching and content-serving for security. Google on BIND and cache poisoning.
2) The timestamps are in machine-readable form for good reason--they are easier to parse in, e.g., a statistics package. If you want to see what your system "is doing" right now, why do you need a human-readable timestamp? If you need to see what your system "is doing" over time, what better way than a statistics package? You "don't have time" to pipe "tail -f/var/log/dnscache/current" through tai64nlocal to get a human-readable timestamp... yet you have time to post silly arguments to/.?
Besides, if you were all that hot and bothered about it, why not just switch from multilog (the logging daemon, which is NOT a part of djbdns) to splogger and send your log messages to syslog (or into oblivion, same difference sometimes)?
3) I've never had this problem. Of course, if everyone else used djbdns instead of the Buggy Internet Name Daemon, axfrdns would be obsolete. rsync+ssh is the way to go.;-) But honestly, I find your comment to be unmoving: "I did something wrong, and axfrdns broke. Therefore, axfrdns sucks." Whatever.
4a) Of course BIND's zone files are more readable. Like the timestamps in the log files, the zone files are meant to be machine-readable to encourage web or script frontends.
4b) You are NOT forced to name your authoritative servers anything. You obviously did not read the Fine Manual. (Hint: it's right here.)
5) What's wrong with daemontools? Unlike inetd, I've NEVER had exhaustion attacks with programs managed by daemontools. I find it all quite elegant.
I will NEVER go back to the monstrosity that is BIND. djbdns is so much more flexible, intelligent in its design, and it just RUNS. We're approaching 20k DNS records in our database... may not be much, but djbdns handles it all without blinking.
And somehow, it didn't make it into his work like it did Heinlein's. Frankly, I don't care (nor do I accept your claim outright) what he was like in person. We're talking about his writing.
If I complained about every writer who was a jerkoff IRL, I wouldn't have much reading material.
Good post, though I must take umbrage to the position to which you've relegated Asimov. He was far more prolific than Heinlein, far less cranky, far more creative in his subject matter, and more influential to RL than Heinlein. He was a much better storyteller than Heinlein as well, offering some of the most important SF extended works ever (the Foundation and Robot novels, with the Empire novels getting an honorable mention).
Of course, it's all a matter of opinion and taste. I just got tired of Heinlein after reading so many stories chalked full of (what seems to be an obsession with) sex, especially involving young girls.
Oh yea, there happens to be these guys called Beethoven, Mozart, and Bach. Beethoven -- some 200 pieces. Mozart -- some 600. Bach -- some 1,200 pieces. That's a hell of alot of very popular non-infringing music (all of which is better than the best of the modern crap that you can get now).
Actually, that's not quite right. Those performances are copyrighted works, even if the particular pieces are not. Still infringing... unless you had some REALLY old performances there...:-)
Personally, I don't care much about snail-mail spam. I figure if they're paying for it, the more the merrier. Gives me the chance to use that big, shiny dumpster right by the mailbox.
If we're talking about high trafficked sites, I'm pretty sure our sites in my last job would qualify: around 80M-90M page views per month. Granted it isn't ``upwards of 100 million imp/mo.'' but I don't expect to get into a d*cksize war about that.:-) (Also, the great majority of these were PHP pages doing various things against our MySQL database.)
Right, and the slave goes down. So I have to manually intervene to fix it. That is unacceptable.
I'm not really sure what you mean here. The only replication problem that would require manual intervention is in a multi-master setting where MySQL gets confused about which query comes first. (And they don't even officially support such a config.) In a typical failover setting, if a slave dies, goes down, whatever, it rebuilds itself when it comes back up, no intervention required.
As for just quitting and saying 'oops', I think that was a problem with MySQL's replication a number of versions ago, probably one of the first versions it was officially in the source (complete with dire warnings, of course).
Finally, as for Yahoo!'s total MySQL traffic, we actually outran that by quite a bit at my last job. We were seeing sustained averages (over a number of months) of nearly 180 queries per second, with a maximum of 1000 concurrent. Is that worth writing home about?;-)
Correct, knowing what your filesystem does is your problem...
Maybe I'm misunderstanding, but this REALLY doesn't seem like it's MySQL's job. If you want a database to be O_SYNC'd, `chattr +S the_directory`. (Granted you cannot do that on a per-table level.) Want the whole thing sync? `mount -o sync the_filesystem/`.
Ok, so I have to now get another boxen set up just to backup my database?
Yep. Or you can get one box that acts as a slave for all five/ten/whatever of your MySQL pools and back them ALL up from one box, rather than five/ten/whatever.
...pausing replication...
No no no no no. You don't have to pause replication. Really. I promise.
etc. etc.
No, there is no etc. etc. You described it just fine in a few simple steps. At least in our application, this eliminates any need whatsoever for hot backups. YMMV, use the right tool if you determine that to be something else. But to say that is doesn't work is simply false. I can demonstrate that it does work, and it works well, even in a production environment with a healthy bit of traffic.
P.S. If you are still really bent on this hot backup business, check out `perldoc/path/to/mysqlhotcopy`.
Question: why are you doing lookups on a table that is in the process of being loaded? Do you do lookups on a table while you are restoring it from backup? Aren't you running the risk of getting bad data out in any case? Yes, you do have to wait for the operation. No, that does not mean that you have to do 4 million serialized INSERTs.
Yes I've read the manual and seen the slow-query-log portion. However the log does not log the currently running SQL...
Okay, if that's what you want, use SHOW FULL PROCESSLIST from the MySQL monitor. Done.
As for some of the data cache issues, I still don't purport to know much about that, but ISTR a lot of talk from Monty and the other MySQL team at OSCON about this sort of thing in 4.x and 5.x. We'll see over the coming months...
As for the optimizer, you're right, I can't see it either. Neither have I ever needed to, since it just doesn't come up. At least in our application, MySQL seems to get it right every time. (No, this isn't a proof. Yes, it's anecdotally helpful to the OP, I think.)
We don't use MySQL in a production environment, so I'm certainly not going to pay or waste my time coding. (regarding vague Changelog entries)
Okay, maybe the Changelog could be more verbose. (Personally, I'm happy with the amount of information in the Changelog.) But those who write and manage large applications, if they are truly concerned about this sort of thing, should have the expertise (either in-house or via a MySQL support contract) to squeeze every last ounce of performance out of the database. In the same way, they should be able to track changes in a more specific way. Maybe not you, since you don't run MySQL in production, but those who *do*, *can*.
InnoDB does provide row locking, but at a cost of performance and memory.
I'd be interested to see the application that provides row locking for free.:-)
If you *NEED* those features (note that need does not just depend on the size of an application), use them, either in another package, or when MySQL gets them. I've seen plenty of non-trivial applications that run just fine on MySQL in production and high-trafficked environments. Size and volume do not constitute a feature need.
Wow, a shining example of someone firmly planting their foot in their mouth on Slashdot. What a surprise. It's nice that the post was moderated up to 4 as ``Informative''... too bad most of the information was useless or wrong.
The overarching problem in your comment was your opening statement:
'Let me repeat the same things I say every time'
The problem there, which is obvious to anyone remotely understanding of what active development means, is that MySQL is sort of a moving target. Your statements are erroneous is so many ways, but most of them can be boiled down to this: you are arguing against something that no longer exists. MySQL, as you attack it, is no more, and has been replaced by something far better. So let's just take some of your arguments (unlike you, I refuse to speak on those things that I *DON'T* know, so I'll skip a few with which I'm not familiar) and see how they stand up, shall we?
Argument: Replication in MySQL is a joke for 'mission critical' use. Rebuttal: Somehow that fact doesn't impede Yahoo!'s extensive use of it. (See Jeremy Zawodny's presentations at the recently-held OSCON.) If the query hangs on the slave halfway through, it isn't marked on the slave as having completed. When the slave becomes available again, it notes its pointer in the transaction log and catches up automatically. Oh, and replication (at least in 4.x, possibly also in 3.23.x) is transaction-safe.
Argument: Filesystem buffered writes. Rebuttal: As another poster wrote, leave the OS out of this. If you cannot properly configure your OS to not buffer writes, you probably shouldn't be running a 'mission critical' ANYTHING.
Argument: On-line backups [are not there] Rebuttal: So set up a dedicated slave for backups. Turn off the slave while backups are running, it catches up when backups are done and it is brought back up. A *simple* solution to a *simple* problem. If you really feel the need to do a hot backup of your live server, you can check into using InnoDB's tool at http://www.innodb.com/hotbackup.html.
Argument: Backups to something other than CSV files. Rebuttal: You mean like backing up the raw MyISAM files? Of course, that doesn't work with InnoDB databases, so you can use their hot backup tool for that as well, if this is a REAL (rather than IMAGINED) problem.
Argument: I have to wait for 4 million INSERTs to be performed... Rebuttal: RTFM. No you don't.
Argument: [No] Ability to specify the number of files to dump to Rebuttal: Again, is this a real or imagined problem? It's likely that whatever you are trying to do, there's a better way. Unfamiliarity with a particular tool usually results in this type of problem.
Argument: Cleaner way to view query plans of statements Rebuttal: So because YOU don't like the output of EXPLAIN you're saying MySQL isn't ready for production? WTF are you talking about?! As for a more *in-depth* EXPLAIN, I agree there, and I found PostgreSQL's mechanism kind of cool. Of course, in four years of running MySQL in a production environment, I'm not sure I would have used it more than once or twice; MySQL's EXPLAIN has always been sufficient, if you actually know what you're doing.
Argument: Ability to delve deeply into performance of the system... Currently MySQL gives you meaningless info like 'slow queries' Rebuttal: RTFM. You are obviously unfamiliar with the slow queries log where MySQL gives you EXACTLY the information you are looking for. As for the data cache and whatnot, I don't know if that is actually available or not.
Argument: MySQL's query optimizer is PISS POOR Rebuttal: And your evidence? Oh wait, you didn't actually provide any. You just brought up a tangential issue...
Argument: If I see another changelog entry... Rebuttal: If you are that concerned, you have some good options here. (a) Pay the developers to hold your hand and explain to you what has happened. (b) Use the source and do your own friggin' diff. This is Unix; stop acting so helpless.
Argument: [a laundry list of disinformation] Rebuttal: Dude, have you not even looked at MySQL since 3.21 or something? Row locking is available in InnoDB, as are transactions. Stored procedures and triggers are planned for 5.x IIRC, but so many applications DON'T need them that the MySQL folks simply haven't cared to add them. Ditto for views (which are also slated for 5.x).
I think a good peaceful, yet effective, thing to organize would be to calmly take whatever they are handing out at their booth (software, etc.) and organize a bonfire later in the conference. Sort of a BOF session---"Really want to burn Microsoft? Come to our bonfile at such-and-such-a-place at 10pm. Don't bring an attitude, but do bring plenty of Microsoft wares!"
Don't rush into anything, be it college, working as a sysadmin, etc. You have your entire life to work, to go to school and learn. I frequently suggest people take a year off between high school and college and just travel. You will have a hard time matching that experience, and you will be far better off for it. (Especially since you are an American, and have probably not seen much of the world.)
If you really want to get going on school, my suggestion would be to take classes purely out of interest and diversity. Don't worry about taking CS courses right away. (In fact, I'd recommend NOT majoring in CS at all...) Take a foreign language, take TV and film classes, do a semester abroad (back to traveling!). IOW, don't ``grow up'' too quickly, 'cause it's awfully hard to go back once you have.
As for me: I got married at 18, my wife had our first child soon after, and I ended up having to work full-time and put myself through school (also full-time). Three schools, two MAJOR changes in my major, 5.5 years, and one cross-country move later and I have a BACS. In terms of my day-to-day job, it's pretty worthless. I rarely use stuff I learned in CS courses to fulfill my job as a senior sysadmin. Often I wish I had majored in Linguistics or something *interesting*, rather than what I thought would be profitable.
I'm all in favor of a full meritocracy myself, but I'm just saying how it is for better or worse.
Someone with a degree has achieved something in a meritocracy. Certainly it isn't enough to stop with the degree and expect the world to bow at your feet, but it is a step beyond not having a degree.
Math is not intended to teach specific math skills, most of the time. Rather, math is intended to teach critical thinking skills.
Math exists irrespective of practical applications; it is a tragedy if it is taught only in the context of how to build a better mousetrap or how to apply it to your day-to-day job.
Hot swap doesn't even require RAID. It involves plugging the device in and making the SCSI bus aware of the change, via the tickling of some/proc/ values. Also, the documentation suggests that it is possible to hot-swap with software RAID as well as hardware RAID.
Bottom line: it has little/nothing to do with the question of RAID or not; it has to do with your SCSI setup.
> Linux seems to be inherently less secure than > xBSD because it contains more software from more > sources. If you run BSD you get your packages > from the BSD team, not from a third party > developer.
I get all non-standard packages for the Redhat systems from redhat.com--I'm not sure what you mean by "third party developer". After all, the ports stuff in FreeBSD fetches source from third party sites...how is this different from what you mention above?
> Getting everything from one place makes it easy. > In BSD, ls is ls - not part of the fileutils. > Basically, BSD is packaged better than Linux is.
I don't necessarily agree, though I do understand your frustration at 'ls' being by itself. However, this is much more a GNU construct than anything; they are actually the ones who grouped all file utilities in a package called 'fileutils'. Plus, one can always do 'rpm -qf `which ls`'...
As for your criticism of installing (and maintaining) Linux: I wholeheartedly disagree. Not that *BSD is worse than Linux (Redhat, specifically) but that you don't do Redhat justice. I just started installing our servers using the Redhat kickstart utility; I go from POSTing to a running server in about 7 minutes. The details:
All services were fully configured, including closing all inetd ports (but leaving inetd running for amanda backups and telnet w/tcpd allowing only my IP address)
I had a personal ID created on the system with password correctly set
I intervened *ONE* time at approximately six minutes into the installation to specify network information.
I'd say that's pretty easy to install. Maintenance is rather easy with RPMs (including those I make myself), especially in doing things like keeping software versions identical across 2-15 servers.
That said, I'm in the middle of setting up a FreeBSD box for us to beat on for a while. My FreeBSD partition at home convinced me after a bit of FS benchmarking...heh...
In fact, you don't even need to edit a few lines in the kernel; just apply the latest 2.0.37pre patch; large memory configuration (up to 2GB, I think) is part of that patch.
As for the other bit about the swap, I'd LOVE to see Windows (not) working without a swap/virtual memory...hehe...
How much time does it take?
on
Why Work Sucks
·
· Score: 1
> Do you really think this is accurate?
Not to be too blunt, but you don't have a family to support and relate with, do you? If you did, you wouldn't be asking this question. It takes quite a bit of time and effort...I'm just lucky I get to learn everything I want at work.:)
Slashdot Mirror
If you were going to completely rip off someone else's comment (like this one) you could have at least linked to it or referenced it.
Not flamebait, just ill-informed.
1) djbdns uses separate IP addresses for caching and content-serving for security. Google on BIND and cache poisoning.
2) The timestamps are in machine-readable form for good reason--they are easier to parse in, e.g., a statistics package. If you want to see what your system "is doing" right now, why do you need a human-readable timestamp? If you need to see what your system "is doing" over time, what better way than a statistics package? You "don't have time" to pipe "tail -f /var/log/dnscache/current" through tai64nlocal to get a human-readable timestamp... yet you have time to post silly arguments to /.?
Besides, if you were all that hot and bothered about it, why not just switch from multilog (the logging daemon, which is NOT a part of djbdns) to splogger and send your log messages to syslog (or into oblivion, same difference sometimes)?
3) I've never had this problem. Of course, if everyone else used djbdns instead of the Buggy Internet Name Daemon, axfrdns would be obsolete. rsync+ssh is the way to go. ;-) But honestly, I find your comment to be unmoving: "I did something wrong, and axfrdns broke. Therefore, axfrdns sucks." Whatever.
4a) Of course BIND's zone files are more readable. Like the timestamps in the log files, the zone files are meant to be machine-readable to encourage web or script frontends.
4b) You are NOT forced to name your authoritative servers anything. You obviously did not read the Fine Manual. (Hint: it's right here.)
5) What's wrong with daemontools? Unlike inetd, I've NEVER had exhaustion attacks with programs managed by daemontools. I find it all quite elegant.
I will NEVER go back to the monstrosity that is BIND. djbdns is so much more flexible, intelligent in its design, and it just RUNS. We're approaching 20k DNS records in our database... may not be much, but djbdns handles it all without blinking.
...would be measuring the battery life of my laptop. (Stupid APM kernel oopses.) Just think: using a battery tester to... test... a battery!
I got a divorce from the only woman I have ever loved, my wife of 10 years, and found out that she was having an affair. Merry Christmas indeed.
And somehow, it didn't make it into his work like it did Heinlein's. Frankly, I don't care (nor do I accept your claim outright) what he was like in person. We're talking about his writing.
If I complained about every writer who was a jerkoff IRL, I wouldn't have much reading material.
Good post, though I must take umbrage to the position to which you've relegated Asimov. He was far more prolific than Heinlein, far less cranky, far more creative in his subject matter, and more influential to RL than Heinlein. He was a much better storyteller than Heinlein as well, offering some of the most important SF extended works ever (the Foundation and Robot novels, with the Empire novels getting an honorable mention).
Of course, it's all a matter of opinion and taste. I just got tired of Heinlein after reading so many stories chalked full of (what seems to be an obsession with) sex, especially involving young girls.
Remember that many glibc2 "overloads" crypt() to be able to deal with MD5 hashes. I wonder how many MD5 hashes they can generate...
Actually, that's not quite right. Those performances are copyrighted works, even if the particular pieces are not. Still infringing... unless you had some REALLY old performances there... :-)
Personally, I don't care much about snail-mail spam. I figure if they're paying for it, the more the merrier. Gives me the chance to use that big, shiny dumpster right by the mailbox.
If we're talking about high trafficked sites, I'm pretty sure our sites in my last job would qualify: around 80M-90M page views per month. Granted it isn't ``upwards of 100 million imp/mo.'' but I don't expect to get into a d*cksize war about that. :-) (Also, the great majority of these were PHP pages doing various things against our MySQL database.)
;-)
...pausing replication...
/path/to/mysqlhotcopy`.
:-)
Right, and the slave goes down. So I have to manually intervene to fix it. That is unacceptable.
I'm not really sure what you mean here. The only replication problem that would require manual intervention is in a multi-master setting where MySQL gets confused about which query comes first. (And they don't even officially support such a config.) In a typical failover setting, if a slave dies, goes down, whatever, it rebuilds itself when it comes back up, no intervention required.
As for just quitting and saying 'oops', I think that was a problem with MySQL's replication a number of versions ago, probably one of the first versions it was officially in the source (complete with dire warnings, of course).
Finally, as for Yahoo!'s total MySQL traffic, we actually outran that by quite a bit at my last job. We were seeing sustained averages (over a number of months) of nearly 180 queries per second, with a maximum of 1000 concurrent. Is that worth writing home about?
Correct, knowing what your filesystem does is your problem...
Maybe I'm misunderstanding, but this REALLY doesn't seem like it's MySQL's job. If you want a database to be O_SYNC'd, `chattr +S the_directory`. (Granted you cannot do that on a per-table level.) Want the whole thing sync? `mount -o sync the_filesystem/`.
Ok, so I have to now get another boxen set up just to backup my database?
Yep. Or you can get one box that acts as a slave for all five/ten/whatever of your MySQL pools and back them ALL up from one box, rather than five/ten/whatever.
No no no no no. You don't have to pause replication. Really. I promise.
etc. etc.
No, there is no etc. etc. You described it just fine in a few simple steps. At least in our application, this eliminates any need whatsoever for hot backups. YMMV, use the right tool if you determine that to be something else. But to say that is doesn't work is simply false. I can demonstrate that it does work, and it works well, even in a production environment with a healthy bit of traffic.
P.S. If you are still really bent on this hot backup business, check out `perldoc
Question: why are you doing lookups on a table that is in the process of being loaded? Do you do lookups on a table while you are restoring it from backup? Aren't you running the risk of getting bad data out in any case? Yes, you do have to wait for the operation. No, that does not mean that you have to do 4 million serialized INSERTs.
Yes I've read the manual and seen the slow-query-log portion. However the log does not log the currently running SQL...
Okay, if that's what you want, use SHOW FULL PROCESSLIST from the MySQL monitor. Done.
As for some of the data cache issues, I still don't purport to know much about that, but ISTR a lot of talk from Monty and the other MySQL team at OSCON about this sort of thing in 4.x and 5.x. We'll see over the coming months...
As for the optimizer, you're right, I can't see it either. Neither have I ever needed to, since it just doesn't come up. At least in our application, MySQL seems to get it right every time. (No, this isn't a proof. Yes, it's anecdotally helpful to the OP, I think.)
We don't use MySQL in a production environment, so I'm certainly not going to pay or waste my time coding. (regarding vague Changelog entries)
Okay, maybe the Changelog could be more verbose. (Personally, I'm happy with the amount of information in the Changelog.) But those who write and manage large applications, if they are truly concerned about this sort of thing, should have the expertise (either in-house or via a MySQL support contract) to squeeze every last ounce of performance out of the database. In the same way, they should be able to track changes in a more specific way. Maybe not you, since you don't run MySQL in production, but those who *do*, *can*.
InnoDB does provide row locking, but at a cost of performance and memory.
I'd be interested to see the application that provides row locking for free.
If you *NEED* those features (note that need does not just depend on the size of an application), use them, either in another package, or when MySQL gets them. I've seen plenty of non-trivial applications that run just fine on MySQL in production and high-trafficked environments. Size and volume do not constitute a feature need.
Wow, a shining example of someone firmly planting their foot in their mouth on Slashdot. What a surprise. It's nice that the post was moderated up to 4 as ``Informative''... too bad most of the information was useless or wrong.
.
... Currently MySQL gives you meaningless info like 'slow queries'
The overarching problem in your comment was your opening statement:
'Let me repeat the same things I say every time'
The problem there, which is obvious to anyone remotely understanding of what active development means, is that MySQL is sort of a moving target. Your statements are erroneous is so many ways, but most of them can be boiled down to this: you are arguing against something that no longer exists. MySQL, as you attack it, is no more, and has been replaced by something far better. So let's just take some of your arguments (unlike you, I refuse to speak on those things that I *DON'T* know, so I'll skip a few with which I'm not familiar) and see how they stand up, shall we?
Argument: Replication in MySQL is a joke for 'mission critical' use.
Rebuttal: Somehow that fact doesn't impede Yahoo!'s extensive use of it. (See Jeremy Zawodny's presentations at the recently-held OSCON.) If the query hangs on the slave halfway through, it isn't marked on the slave as having completed. When the slave becomes available again, it notes its pointer in the transaction log and catches up automatically. Oh, and replication (at least in 4.x, possibly also in 3.23.x) is transaction-safe.
Argument: Filesystem buffered writes.
Rebuttal: As another poster wrote, leave the OS out of this. If you cannot properly configure your OS to not buffer writes, you probably shouldn't be running a 'mission critical' ANYTHING.
Argument: On-line backups [are not there]
Rebuttal: So set up a dedicated slave for backups. Turn off the slave while backups are running, it catches up when backups are done and it is brought back up. A *simple* solution to a *simple* problem. If you really feel the need to do a hot backup of your live server, you can check into using InnoDB's tool at http://www.innodb.com/hotbackup.html
Argument: Backups to something other than CSV files.
Rebuttal: You mean like backing up the raw MyISAM files? Of course, that doesn't work with InnoDB databases, so you can use their hot backup tool for that as well, if this is a REAL (rather than IMAGINED) problem.
Argument: I have to wait for 4 million INSERTs to be performed...
Rebuttal: RTFM. No you don't.
Argument: [No] Ability to specify the number of files to dump to
Rebuttal: Again, is this a real or imagined problem? It's likely that whatever you are trying to do, there's a better way. Unfamiliarity with a particular tool usually results in this type of problem.
Argument: Cleaner way to view query plans of statements
Rebuttal: So because YOU don't like the output of EXPLAIN you're saying MySQL isn't ready for production? WTF are you talking about?! As for a more *in-depth* EXPLAIN, I agree there, and I found PostgreSQL's mechanism kind of cool. Of course, in four years of running MySQL in a production environment, I'm not sure I would have used it more than once or twice; MySQL's EXPLAIN has always been sufficient, if you actually know what you're doing.
Argument: Ability to delve deeply into performance of the system
Rebuttal: RTFM. You are obviously unfamiliar with the slow queries log where MySQL gives you EXACTLY the information you are looking for. As for the data cache and whatnot, I don't know if that is actually available or not.
Argument: MySQL's query optimizer is PISS POOR
Rebuttal: And your evidence? Oh wait, you didn't actually provide any. You just brought up a tangential issue...
Argument: If I see another changelog entry...
Rebuttal: If you are that concerned, you have some good options here. (a) Pay the developers to hold your hand and explain to you what has happened. (b) Use the source and do your own friggin' diff. This is Unix; stop acting so helpless.
Argument: [a laundry list of disinformation]
Rebuttal: Dude, have you not even looked at MySQL since 3.21 or something? Row locking is available in InnoDB, as are transactions. Stored procedures and triggers are planned for 5.x IIRC, but so many applications DON'T need them that the MySQL folks simply haven't cared to add them. Ditto for views (which are also slated for 5.x).
I think a good peaceful, yet effective, thing to organize would be to calmly take whatever they are handing out at their booth (software, etc.) and organize a bonfire later in the conference. Sort of a BOF session---"Really want to burn Microsoft? Come to our bonfile at such-and-such-a-place at 10pm. Don't bring an attitude, but do bring plenty of Microsoft wares!"
This already happened on Usenet, some years ago...
Don't rush into anything, be it college, working as a sysadmin, etc. You have your entire life to work, to go to school and learn. I frequently suggest people take a year off between high school and college and just travel. You will have a hard time matching that experience, and you will be far better off for it. (Especially since you are an American, and have probably not seen much of the world.)
If you really want to get going on school, my suggestion would be to take classes purely out of interest and diversity. Don't worry about taking CS courses right away. (In fact, I'd recommend NOT majoring in CS at all...) Take a foreign language, take TV and film classes, do a semester abroad (back to traveling!). IOW, don't ``grow up'' too quickly, 'cause it's awfully hard to go back once you have.
As for me: I got married at 18, my wife had our first child soon after, and I ended up having to work full-time and put myself through school (also full-time). Three schools, two MAJOR changes in my major, 5.5 years, and one cross-country move later and I have a BACS. In terms of my day-to-day job, it's pretty worthless. I rarely use stuff I learned in CS courses to fulfill my job as a senior sysadmin. Often I wish I had majored in Linguistics or something *interesting*, rather than what I thought would be profitable.
I'm all in favor of a full meritocracy myself, but I'm just saying how it is for better or worse.
Someone with a degree has achieved something in a meritocracy. Certainly it isn't enough to stop with the degree and expect the world to bow at your feet, but it is a step beyond not having a degree.
Math is not intended to teach specific math skills, most of the time. Rather, math is intended to teach critical thinking skills.
Math exists irrespective of practical applications; it is a tragedy if it is taught only in the context of how to build a better mousetrap or how to apply it to your day-to-day job.
Hot swap doesn't even require RAID. It involves plugging the device in and making the SCSI bus aware of the change, via the tickling of some /proc/ values. Also, the documentation suggests that it is possible to hot-swap with software RAID as well as hardware RAID.
Bottom line: it has little/nothing to do with the question of RAID or not; it has to do with your SCSI setup.
> Linux seems to be inherently less secure than
> xBSD because it contains more software from more
> sources. If you run BSD you get your packages
> from the BSD team, not from a third party
> developer.
I get all non-standard packages for the Redhat systems from redhat.com--I'm not sure what you mean by "third party developer". After all, the ports stuff in FreeBSD fetches source from third party sites...how is this different from what you mention above?
> Getting everything from one place makes it easy.
> In BSD, ls is ls - not part of the fileutils.
> Basically, BSD is packaged better than Linux is.
I don't necessarily agree, though I do understand your frustration at 'ls' being by itself. However, this is much more a GNU construct than anything; they are actually the ones who grouped all file utilities in a package called 'fileutils'. Plus, one can always do 'rpm -qf `which ls`' ...
As for your criticism of installing (and maintaining) Linux: I wholeheartedly disagree. Not that *BSD is worse than Linux (Redhat, specifically) but that you don't do Redhat justice. I just started installing our servers using the Redhat kickstart utility; I go from POSTing to a running server in about 7 minutes. The details:
I'd say that's pretty easy to install. Maintenance is rather easy with RPMs (including those I make myself), especially in doing things like keeping software versions identical across 2-15 servers.
That said, I'm in the middle of setting up a FreeBSD box for us to beat on for a while. My FreeBSD partition at home convinced me after a bit of FS benchmarking...heh...
In fact, you don't even need to edit a few lines in the kernel; just apply the latest 2.0.37pre patch; large memory configuration (up to 2GB, I think) is part of that patch.
As for the other bit about the swap, I'd LOVE to see Windows (not) working without a swap/virtual memory...hehe...
> Do you really think this is accurate?
:)
Not to be too blunt, but you don't have a family to support and relate with, do you? If you did, you wouldn't be asking this question. It takes quite a bit of time and effort...I'm just lucky I get to learn everything I want at work.
WORK RULES!