for the premium on these "large" scsi drives you can buy several times more space in ATA/SATA drives, connect them to some SMART controller and join them in stripping mode, achieving higher peak as well as continuous bandwidth.
Can I get Tara Reid and Elizabeth Hurley in a stripping mode? This sounds wonderful!
Of course. But the availability differs between distributions.
Naturally. However sites like SlackPacks and LinuxPackages show that Slackware's really not in the minority for package availability.
And Slackware doesn't care much for dependencies.
What's that got to do with what we're talking about?
...Debian feels less commercial to me, and it allows me to customize it without bypassing much of any built-in system mechanisms.
As does any distro -- but you sidestep the internal mechanisms and you end up with a problem where the built-in tools either screw up the configuration when you upgrade, or they fail altogether. Precisely the reason why so many people enjoy Slackware -- there are no internal mechanisms save for very few, very THIN ones used right at install time. There's no "duality" to compete with. And the lack of dependencies helps here, believe it or not.
Some of you may like to compile from source. I think it's tedious, especially when some pieces of software I've attempted to compile want me to spend hours compiling 10 other libraries first.
I agree with you completely. However, I want you to give me some real examples of programs you want and aren't available as Slackware packages, especially any which require "hours compiling 10 other libraries first" -- Slackware has a very decent set of library packages and I'll be very surprised if you can give me some concrete examples where there already exists.debs or even NON-RH RPMs -- A lot of weird software has RedHat packages simply because RH is synonymous with Linux for many companies.
That's all nice... *if* you're using Slackware packages all the way. The fundamental problem doesn't really lie in Slackware's package management. It even has an 'apt' now, named 'slackpkg'. The problem for me lies in the poor availability of packages for Slackware compared to other distributions like RedHat and Debian.
Have you not heard of CheckInstall?! Anything I put on my Slackware box is in package form. If I have to compile something (this includes Perl modules) I build from source and then use CheckInstall to install. For Perl modules it's just a little wrapper script I have that won't eat perllocal.pod. It's trivial to make Slackware packages and it's trivial to keep any Slackware system that the admin has been wise enough to use packages up to date. Seriously. Check it out. I dislike the RPM/DEB package system because of the dependencies. it's too much work to make decent packages. Slackware eliminates this and really, what's so difficult about seeing "libfoo.so not found" and installing the foo package? Not for newbies, granted, but for any admin it's not a big deal. At all.
Only if you don't copy and paste all the commands as listed in the book like I've seen every other LFS pusher do.
Now mind you, I used LFS to create the CF-based firewalls I sell... 16M CF that contains not just the kernel and base set of tools but also OpenS/WAN and even Perl for the various scripts and XML-RPC server for the admin interface. LFS was useful in that it gave me the interdependencies in the base system but beyond that a lot of it went out the window when you used uClibc and BusyBox and discovered interestling little dlopen() inconsistencies between glibc and uClibc.:-)
It's just him. The vast majority of Slack users I've run into use Slackware because it's very easy to manage if you know what you're doing and you don't have a dumbass dependency system in place to second-guess you or cause you grief if you want to make decent third-party packages.
Sorry, I'm a Slackware user (since '96) and you are the one who is wrong here.
Slackware is not 50% faster than the other distros. Sorry, there just isn't enough crap running on FC2 or Gentoo or Suse to slow down the same machine that much. And yes, I'm talking runlevel 3 or 4. I find Slackware zippier than the others, yes, but 50% faster? Give your head a shake.
Also you will find if you take the time to do the critical analysis that having everything in the kernel is not measurably faster than having a lean kernel with modules. I prefer the latter myself and have done the tests -- it's not worth the effort to compile everything into the kernel and then have a kernel that's only usable on a limited subset of machines. Build the kernel as generic as possible, modularize everything and now you have a kernel you can throw on all your machines. Or are you a Gentoo user in disguise and think that a full compiler environment is required on every machine? The package system is there for a reason. Use it. The dependency hell that all the other distros have doesn't exist on Slack, which is one of the bigger reasons I enjoy it.
I have a USB2 hdd with a development-ready version of slack9.1 and slack10.0 on it (since I have both in my environment). If I need to build something I mount it, chroot to the proper environment, build, checkinstall and now I have the package available for all my slack91 and/or slack100 machines, and I save myself the 600 or so megs I need for a proper development environment on every machine and I save myself the problem of keeping the development environments up to date on all the machines. Hell I even have a script that'll make pretty much any Perl module a Slackware package without destroying perllocal.
I don't think anyone outside of US/UK thought this guy was dead, and even with the US/UK that was just wishful thinking... you spend a pile of money to achieve something and surely you must have achieved it, right boys? Where are you getting your info?
The idea is to divorce the database functionality from the email/calendaring functionality. You could use a regular client for the later (such as Outlook) while you'd develop documents dealing with projects inside the Wiki.
Exchange4Linux can get you started very quickly. Everything and I mean everything is in a PostgreSQL database, and it's written in Python. Easy to use, easy to extend. I am currently using it with about 50 Outlook contacts and am doing my part to help make the standards-based IMAP4 server function better.
It probably says more about you than about me that you think that that list of "gotchas" (many of which are no longer valid, or are otherwise insignificant) is somehow difficult to keep in mind.
Your DB truncating numbers, giving invalid results and allowing invalid data is not an issue for you? I dunno but that is not something I will tolerate from my DB. I expect its output to make sense and I expect it not to take artistic license with what I give to it.
Hell, it's tiny compared to the quirks in any desktop GUI environment.
I don't trust my data to a desktop GUI environment. I trust my data to the underlying filesystem and the DBs running on top of that filesystem. I would not accept such quirks from the filesystem or any kind of data archival/backup solution, either, but it seems that you would. You're a more tolerant person than I.
As far as the list being invalid -- it seems that the guy maintaining it is keeping up with the changes/fixes in MySQL as they occur. Do you have specific examples of where he's exaggerating?
250 million pages a day, mean of 9 queries per page, which averages out to about 26,000 queries per second.
I'm calling your bluff. What hardware is this running on? You do no query caching or static pageviews? Every single one of those 250 million pages is dynamically served? Not even the mighty Slashdot does that. You have a table with a hundred million rows in it that's actively manipulated in read and write capacity and it has acceptable performance? How many queries/sec on that one and what kind of queries?
What problems we do have arise when people do things like enable code that lets users do fulltext field searches 20 times a second on tables that have 200,000 rows.
Well, duh.:-) I suppose you think it's acceptable to remove reverse from your transmission since some people accidentally slip into reverse on the way to park?
So you are saying you trust your data to a system that has an unbelievable list of gotchas -- you're saying that you prefer to try and keep all of these in mind when you write apps that use MySQL, and you are saying that you're not concerned about the data integrity issues brought up in this thread?
You PgSQL nazis are just being ignorant. Do you think because MyISAM isn't transactional that the whole database isn't?
I never said that; I have not seen a decent benchmark showing InnoDB having *any* kind of decent performance though. And it still does nothing to address the scalability issues of MySQL with hundreds of users, nor does it address the speed issues of MySQL in general when performing complex queries.
MySQL's InnoDB offers the same level of data integrity as PgSQL does, and about the same performance.
Show me. And I'm not talking "how fast can I do a thousand SELECT * FROM mytable;" -- good, real-life queries with WHERE clauses, maybe cursors and ordering.
Most of PostgreSQL's gains are erased by MySQL 4.1's excellent code when it is combined with those OS's proper threading.
Again, show me. Postgres' performance increases in 7.4.x. are nothing to sneeze at, and certainly have nothing to do with the threading changes between 2.4 and 2.6.
PgSQL will be doomed to a BSDesque life. Touted by too many people with no social skills, nobody will ever be able to see how good it is, because they just get shouted down when asking questions.
That's funny; I see something similar with the general MySQL crowd; it's like watching a bunch of pizza-faced 13 year olds drool over the latest and greatest nVidia card and trying to convince their parents to buy the $500 video card to replace the $250 they bought only 6 months ago so they can play Doom3, when all the parents want to be able to do is balance the checkbook and get some real work done.
Now, when you wish to do a backup, lock out access to the database, and do a snapshot of the logical volume it is on. Then restore access to the database. This won't take very long at all.
Um no. It's not enough to just lock out access and take a snapshot; you need to lock out users, tell the DB to flush to disk and THEN snapshot.
I've never had to do this but your problem interested me. Think about it, how could you possibly make the database spit out a perfectly frozen-in-time set of tables without actually freezing in order to make the set?
I guess it's kind of humorous then that PostgreSQL beats the pants off of MySQL in any kind of moderate DB usage. MySQL can do a damn fine job for simple INSERTs and SELECTs but throw a hundred users at it or a few WHERE or ORDER BY clauses (or all of the above) and MySQL shows its true colours: Made by Fischer-Price. Throw in complex queries including subselects or try using views and... oh right, I forgot... It's not got any kind of real relational power behind it... my mistake!
Even the best caps will die within a few weeks to a month. Besides, it's not the TVs that scare me, it's the microwaves... When I worked at the repair shop we used a pair of huge screwdrivers to short them caps out, and they held a charge, holy shit. spot-weld marks all over those screwdrivers.:-)
I use CBL and RBLDNS -- neither block entire netblocks, the IPs in them are static IPs which either run open proxies or fail other checks. Very, Very effective.
A failure every few weeks? Maybe if you've got a couple hundred systems. For a dozen computers I consider it bad if I have a failure twice a year. And this includes the IDE systems, to boot.
Every few weeks? Good Lord, man, do you work for IBM or something? I haven't seen FUD at +5 insightful in ages.
Even AVR microcontrollers can access external RAM (I know for we sticked 2 MB of SRAM on an ATMega 128 a couple years ago), but of course you can't use this RAM to store Linux. Fortunately the AT91 boards sold by Atmel, which use microcontrollers sporting an ARM core just like these new chips, run uC-Linux just fine, so I don't think there would be much trouble porting it to this new line.
Accessing a static RAM device through I/O is an awful lot different than having it as system RAM; as someone who has done it I am sure you don't need to be told that. As for running uClinux on ARM cores -- of course you'll be able to run it if you give it enough RAM and ROM; throwing it in a core with enough is not at all the same as trying to get it to run on one of these beasts.
Slashdot Mirror
I like having a folder I can get anywhere, but there are better ways.
Better ways to access folders than standard-compliant DAV? Do tell.
for the premium on these "large" scsi drives you can buy several times more space in ATA/SATA drives, connect them to some SMART controller and join them in stripping mode, achieving higher peak as well as continuous bandwidth.
Can I get Tara Reid and Elizabeth Hurley in a stripping mode? This sounds wonderful!
Of course. But the availability differs between distributions.
Naturally. However sites like SlackPacks and LinuxPackages show that Slackware's really not in the minority for package availability.And Slackware doesn't care much for dependencies.
What's that got to do with what we're talking about?
As does any distro -- but you sidestep the internal mechanisms and you end up with a problem where the built-in tools either screw up the configuration when you upgrade, or they fail altogether. Precisely the reason why so many people enjoy Slackware -- there are no internal mechanisms save for very few, very THIN ones used right at install time. There's no "duality" to compete with. And the lack of dependencies helps here, believe it or not.
With Debian, I don't have to compile at all.
If and only if the package already exists for Debian, which is exactly the same with *any* distribution that works with packages, Slackware included.
Some of you may like to compile from source. I think it's tedious, especially when some pieces of software I've attempted to compile want me to spend hours compiling 10 other libraries first.
I agree with you completely. However, I want you to give me some real examples of programs you want and aren't available as Slackware packages, especially any which require "hours compiling 10 other libraries first" -- Slackware has a very decent set of library packages and I'll be very surprised if you can give me some concrete examples where there already exists .debs or even NON-RH RPMs -- A lot of weird software has RedHat packages simply because RH is synonymous with Linux for many companies.
That's all nice... *if* you're using Slackware packages all the way. The fundamental problem doesn't really lie in Slackware's package management. It even has an 'apt' now, named 'slackpkg'. The problem for me lies in the poor availability of packages for Slackware compared to other distributions like RedHat and Debian.
Have you not heard of CheckInstall?! Anything I put on my Slackware box is in package form. If I have to compile something (this includes Perl modules) I build from source and then use CheckInstall to install. For Perl modules it's just a little wrapper script I have that won't eat perllocal.pod. It's trivial to make Slackware packages and it's trivial to keep any Slackware system that the admin has been wise enough to use packages up to date. Seriously. Check it out. I dislike the RPM/DEB package system because of the dependencies. it's too much work to make decent packages. Slackware eliminates this and really, what's so difficult about seeing "libfoo.so not found" and installing the foo package? Not for newbies, granted, but for any admin it's not a big deal. At all.
But the iBrator has already been developed.
Linux From Scratch. the real man's linux.
Only if you don't copy and paste all the commands as listed in the book like I've seen every other LFS pusher do.
Now mind you, I used LFS to create the CF-based firewalls I sell... 16M CF that contains not just the kernel and base set of tools but also OpenS/WAN and even Perl for the various scripts and XML-RPC server for the admin interface. LFS was useful in that it gave me the interdependencies in the base system but beyond that a lot of it went out the window when you used uClibc and BusyBox and discovered interestling little dlopen() inconsistencies between glibc and uClibc. :-)
It's just him. The vast majority of Slack users I've run into use Slackware because it's very easy to manage if you know what you're doing and you don't have a dumbass dependency system in place to second-guess you or cause you grief if you want to make decent third-party packages.
Well, you're wrong. No offense intended.
Sorry, I'm a Slackware user (since '96) and you are the one who is wrong here.
Slackware is not 50% faster than the other distros. Sorry, there just isn't enough crap running on FC2 or Gentoo or Suse to slow down the same machine that much. And yes, I'm talking runlevel 3 or 4. I find Slackware zippier than the others, yes, but 50% faster? Give your head a shake.
Also you will find if you take the time to do the critical analysis that having everything in the kernel is not measurably faster than having a lean kernel with modules. I prefer the latter myself and have done the tests -- it's not worth the effort to compile everything into the kernel and then have a kernel that's only usable on a limited subset of machines. Build the kernel as generic as possible, modularize everything and now you have a kernel you can throw on all your machines. Or are you a Gentoo user in disguise and think that a full compiler environment is required on every machine? The package system is there for a reason. Use it. The dependency hell that all the other distros have doesn't exist on Slack, which is one of the bigger reasons I enjoy it.
I have a USB2 hdd with a development-ready version of slack9.1 and slack10.0 on it (since I have both in my environment). If I need to build something I mount it, chroot to the proper environment, build, checkinstall and now I have the package available for all my slack91 and/or slack100 machines, and I save myself the 600 or so megs I need for a proper development environment on every machine and I save myself the problem of keeping the development environments up to date on all the machines. Hell I even have a script that'll make pretty much any Perl module a Slackware package without destroying perllocal.
I don't think anyone outside of US/UK thought this guy was dead, and even with the US/UK that was just wishful thinking... you spend a pile of money to achieve something and surely you must have achieved it, right boys? Where are you getting your info?
The idea is to divorce the database functionality from the email/calendaring functionality. You could use a regular client for the later (such as Outlook) while you'd develop documents dealing with projects inside the Wiki.
Exchange4Linux can get you started very quickly. Everything and I mean everything is in a PostgreSQL database, and it's written in Python. Easy to use, easy to extend. I am currently using it with about 50 Outlook contacts and am doing my part to help make the standards-based IMAP4 server function better.
It probably says more about you than about me that you think that that list of "gotchas" (many of which are no longer valid, or are otherwise insignificant) is somehow difficult to keep in mind.
Your DB truncating numbers, giving invalid results and allowing invalid data is not an issue for you? I dunno but that is not something I will tolerate from my DB. I expect its output to make sense and I expect it not to take artistic license with what I give to it.
Hell, it's tiny compared to the quirks in any desktop GUI environment.
I don't trust my data to a desktop GUI environment. I trust my data to the underlying filesystem and the DBs running on top of that filesystem. I would not accept such quirks from the filesystem or any kind of data archival/backup solution, either, but it seems that you would. You're a more tolerant person than I.
As far as the list being invalid -- it seems that the guy maintaining it is keeping up with the changes/fixes in MySQL as they occur. Do you have specific examples of where he's exaggerating?
250 million pages a day, mean of 9 queries per page, which averages out to about 26,000 queries per second.
I'm calling your bluff. What hardware is this running on? You do no query caching or static pageviews? Every single one of those 250 million pages is dynamically served? Not even the mighty Slashdot does that. You have a table with a hundred million rows in it that's actively manipulated in read and write capacity and it has acceptable performance? How many queries/sec on that one and what kind of queries?
What problems we do have arise when people do things like enable code that lets users do fulltext field searches 20 times a second on tables that have 200,000 rows.
Well, duh. :-) I suppose you think it's acceptable to remove reverse from your transmission since some people accidentally slip into reverse on the way to park?
So you are saying you trust your data to a system that has an unbelievable list of gotchas -- you're saying that you prefer to try and keep all of these in mind when you write apps that use MySQL, and you are saying that you're not concerned about the data integrity issues brought up in this thread?
What company do you own, again?
You PgSQL nazis are just being ignorant. Do you think because MyISAM isn't transactional that the whole database isn't?
I never said that; I have not seen a decent benchmark showing InnoDB having *any* kind of decent performance though. And it still does nothing to address the scalability issues of MySQL with hundreds of users, nor does it address the speed issues of MySQL in general when performing complex queries.
MySQL's InnoDB offers the same level of data integrity as PgSQL does, and about the same performance.
Show me. And I'm not talking "how fast can I do a thousand SELECT * FROM mytable;" -- good, real-life queries with WHERE clauses, maybe cursors and ordering.
Most of PostgreSQL's gains are erased by MySQL 4.1's excellent code when it is combined with those OS's proper threading.
Again, show me. Postgres' performance increases in 7.4.x. are nothing to sneeze at, and certainly have nothing to do with the threading changes between 2.4 and 2.6.
PgSQL will be doomed to a BSDesque life. Touted by too many people with no social skills, nobody will ever be able to see how good it is, because they just get shouted down when asking questions.
That's funny; I see something similar with the general MySQL crowd; it's like watching a bunch of pizza-faced 13 year olds drool over the latest and greatest nVidia card and trying to convince their parents to buy the $500 video card to replace the $250 they bought only 6 months ago so they can play Doom3, when all the parents want to be able to do is balance the checkbook and get some real work done.
FLUSH TABLES WITH READ LOCK;
Didn't know you could do that. Thanks for the tip! :-)
Now, when you wish to do a backup, lock out access to the database, and do a snapshot of the logical volume it is on. Then restore access to the database. This won't take very long at all.
Um no. It's not enough to just lock out access and take a snapshot; you need to lock out users, tell the DB to flush to disk and THEN snapshot.
I've never had to do this but your problem interested me. Think about it, how could you possibly make the database spit out a perfectly frozen-in-time set of tables without actually freezing in order to make the set?
I dunno, PostgreSQL does a good job. :-)
I guess it's kind of humorous then that PostgreSQL beats the pants off of MySQL in any kind of moderate DB usage. MySQL can do a damn fine job for simple INSERTs and SELECTs but throw a hundred users at it or a few WHERE or ORDER BY clauses (or all of the above) and MySQL shows its true colours: Made by Fischer-Price. Throw in complex queries including subselects or try using views and... oh right, I forgot... It's not got any kind of real relational power behind it... my mistake!
Even the best caps will die within a few weeks to a month. Besides, it's not the TVs that scare me, it's the microwaves... When I worked at the repair shop we used a pair of huge screwdrivers to short them caps out, and they held a charge, holy shit. spot-weld marks all over those screwdrivers. :-)
COMPLETE COPY OF NETSKY VIRUS
Make the mail admin install the qmail-send.mimeheaders patch -- it causes bounces to bounce back only the headers of email with MIME attachments. As google provides, my qmail patchlist is quite long, actually. :-)
I'm moving over to Postfix these days -- it seems to do everything qmail does but without the need to recompile every time I want a change.
I use CBL and RBLDNS -- neither block entire netblocks, the IPs in them are static IPs which either run open proxies or fail other checks. Very, Very effective.
Um... that's exactly what I said...
A failure every few weeks? Maybe if you've got a couple hundred systems. For a dozen computers I consider it bad if I have a failure twice a year. And this includes the IDE systems, to boot.
Every few weeks? Good Lord, man, do you work for IBM or something? I haven't seen FUD at +5 insightful in ages.
Even AVR microcontrollers can access external RAM (I know for we sticked 2 MB of SRAM on an ATMega 128 a couple years ago), but of course you can't use this RAM to store Linux. Fortunately the AT91 boards sold by Atmel, which use microcontrollers sporting an ARM core just like these new chips, run uC-Linux just fine, so I don't think there would be much trouble porting it to this new line.
Accessing a static RAM device through I/O is an awful lot different than having it as system RAM; as someone who has done it I am sure you don't need to be told that. As for running uClinux on ARM cores -- of course you'll be able to run it if you give it enough RAM and ROM; throwing it in a core with enough is not at all the same as trying to get it to run on one of these beasts.