I don't see why setting up the RAIDs under any OS should be more time consuming than on other OSs. Certainly if you use the right hardware-based RAID things should be very simple and very fast.
Bang for the buck, you can't beat the Apple Xserve RAID. They are IDE, but almost as fast as the fastest scsi arrays, and seem to be very reliable. The array can be easily partitioned into a variety of raid types with hot spares. The unit can then connect to Windows or Linux via standard fibre channel interface and look like simple scsi drives. The RAID is administered via an ethernet connection using a nice java gui tool.
We set our Xserve RAIDs up such that each array (each Xserve RAID box has 2 arrays with separate controller logic for each) is RAID 5 plus a hot spare, and then the array is mirrored with the other one. This gives is.8 TB or so at a very reasonable price and very reliable. So far it has worked well.
Solar power is very expensive, and there are other things you can do to lower your cooling expenses.
Consider where I grew up in southern Alberta. In the winter temperatures dip frequently to -40. In the summer highs of 100oF are not uncommon. The same insulation that keeps the house warm in the winter keeps it cool in the summer. In fact very few people that I know of have air conditioning. Even in a hot climate, good insulation can knock your cooling bills way down.
Another thing to consider is geothermal heating and cooling. The idea is to pump heat into the ground in the summer, and then pump it back out in the winter (well, it's actually based on temperature exchanges). You can get an amazing amount of cooling in hot summer this way. You will be required to do some digging, though.
Either way, running a standard A/C unit off of solar power seems to be very expensive by itself. These other things I've mentioned could make it approach practicality.
Graphics ceiling? No way. Even today's FPS 3-d graphics look rather bad, really. Too many aritificial-looking polygon edges, obviously flat textures, and so on. Upping the polygon count is helping that, and we sure haven't reached the ceiling on polygon count. Just because an older game doesn't look much better than a modern game doesn't mean we've reached the limit in what we can do. It actually just means our graphics rendering and systems still have a longs ways to go.
Although the traditional GTK file selector is very ugly, it has one hidden killer feature: Tab-completion. That's far faster and easier than any other system to drill-down to a file. If tab-completion is every removed from the GTK file selector, I will be very frustrated. Hopefully we can have something that looks good and works well and supports tab-completion. If the text entry box is indeed hidden, I'll be patching my gtk right away to get that to display automatically. Hiding it is a poor idea, IMHO.
I've seen the mockups for the gtk 2.4 file selector and I must say I don't like it at all. Unfortunately I couldn't see the screeshots in the article, so I don't know if this new gtk 2.4 dialog is the one they use or if gnome made their own dialog box.
There is now a fingerprint in the ClamAV virus definitions that actually can detect the latest bagle pwdzip variants without having to unzip them. So no you don't need to just quarantine all password-protected zips. ClamAV should not be picking it up automatically.
There are much better and more secure ways to send data around. Consider using pgp or some other encryption package. I admit that these measures can cause a lot of inconvenience for users. This is the fault of the spam and virus gangs. They have ruined it for everyone. It is time to replace smtp, no doubt about it.
The ClamAV developers just posted to the clamav-users list and said that the ability to optionally identify (and thus block or quarantine) encrypted zip files has officially been added to the ClamAV source, so very soon you should be able to turn on such blocking in the clam.conf file. Not sure when they will release a new snapshot with this in it. The current anonymous CVS has not quite yet got the patch.
Tomasz Kojm, ClamAV developer, says about it:
You have to enable this feature manually withArchiveDetectEncrypted in clamav.conf and --detect-encrypted inclamscan. Please be careful and WARN YOUR USERS before enabling it.
No server based AV solution I know of will stop the latest wave of random password zip viruses. That is because the AV program cannot scan inside the zip file. I've posted a patch to the clamav-users mailing list that marks all password-encrypted zip files as suspect and thus can be quarantined for manual extaction and scanning if desired.
Right now I'm quarantining (with mimedefang and the patched clamav) all encrypted zip files. So far it's 100% hit rate, with no false positives. Unfortunately, ClamAV developers haven't said how they plan to deal with these password zip files.
Overall, once I patched clamav, I was more than pleased. Over the last 2 months Clamav working through mimedefang has saved us from almost all the viruses coming into our server. Updates are daily or more and I have a cron auto-updating them on the hour.
The beauty of having an open source AV was made clear to me today as I modified ClamAV to detect the encrypted zip files. Even though this is more of a stop-gap measure, with any other closed-source program I would have been completely at the vendor/developer's mercy.
That said, using clamav in conjunction with other AV programs in a stack fashion would give you even more coverage if you were worried.
Since the technology has been patented, full details should now be available in the patent application itself. Despite the company trying to require him to keep the technology secret, since it's in the patent, it can no longer be secret. Seems that legally the most the company could do is require him to license the technology to them exclusively. But to force him to keep it secret is quite absurd.
OnStar cannot currently track you in real time. The GPS measurements not done continuously. In fact an OnStar operator has to send a command to the car's GPS receive to calculate a fix. This can take up to 3 minutes at times. Plus the fix is not that accurate. Certainly the current OnStar system cannot track your speed in real time. Perhaps in the future it will, though.
For many people, OnStar is a great feature, and in fact can sometimes save lives. Personally I would never pay for it, though. I prefer to navigate by myself by dead reckoning. No maps and I certainly won't stop to ask anyone for directions!
Clearly this is a sign that your cat has some serious psychological issues and is asking for help. This is probably your cat's way of letting you know that spending all day every day inside your little apartment with nothing to do but play quake and chase optical mice that don't even taste good is slowly driving it insane. Think of your cat's mental health. Think of your own mental health. Not to mention your wallet. Let your cat go free. It's not worth 300 dollars!
Saying that about qmail is a bit like saying that because no one has broken into your house before it's secure. Although qmail probably is very secure, your statement does not follow.
As you mention, the biggest gripe OpenBSD has is that qmail is not open source.
Also qmail is not industry standard, it doesn't fit well into a standard linux install, and it doesn't play by default with the tools that sendmail regulars rely on like procmail (postfix and exim both do). And it certainly doesn't have a great filtering API. You can tack it on via procmail or some other mechanism, but it does not allow the connection-level control that the sendmail milter api allows (IE custom rejection of the connection during the session).
Although the parent post was moderated as "funny," I think the question is a serious one. I use sendmail exlusively because it is the only mail server that supports the powerful milter API and allows me to use mimedefang, which cannot work with any other mail server. Mimedefang can drive antivirus software and spam filter, not to mention sanitizing of html email and so forth, is a very powerful piece of software.
For many people postfix or exim work very well, and should be used over sendmail. But in a larger environment, sendmail is the standard. Qmail, well, I've never liked it.
If you don't control the mail server to create aliases for yourself, you can also employ RFC-compiliant suffixes to your e-mail address. For example: foobar+dellorders@mydomain.com.
My boss related to me an experience that happened at his previous employment. The company that he worked for produced a very successful system for doing typesetting and layout for newspapers. A few years ago, they decided to put together a mockup of what their product might look several years down the road, and give an example of where their development was heading. So they put together a very convincing demonstration "movie" complete with scripted typos and mistakes. No one who saw the demo ever once thought that the whole thing was faked. They thought this was the real deal. The demo turned out so good that customers immediately dropped any and all demand for their existing product, wanting to wait for the new version. The problem was the new version wasn't even started yet. At best it would be 2 to 3 years down the road. That little demo just about bankrupted the company.
A bit of an extreme example of how a premature demo can really hurt a company. I imagine with games it could be similar, except that gamers are rarely the type to stop buying while they wait for new things.
I would love to see some of the lower-level KDE features made available to gnome through some kind of thunk layer. For example, blending gnome-vfs modules into the KIO subsystem, or blending KIO slaves into the Gnome VFS subsystem would be very very useful to me.
Theming integration is also cool. Right now there is a gtk theme that uses the current KDE theme engine to draw the widgets. I would love to see a QT theme that uses the current GTK engine to draw widgets. Then a program like KDevelop might actually fit into my desktop.
Another pipe dream that is slowly being worked on is a way to call methods on objects from the Gnome framework to the KDE framework and vice versa.
Well, a small nitpick but there are large self-contained projects written under mainly the BSD license. The three examples are actually complete operating systems.
My comment about this has nothing to do with freedom, but the fact that the *BSD's are self contained projects under the BSD license is precisely why companies like IBM won't touch it with a 10 foot pole, as far as adopting and enhancing. The GPL is precisely the reason why IBM is spending so much time and money on Linux. It make business sense. Now this of course has nothing to do with freedom per se.
You're missing the point with regards to the GPL. Having a license that's not compatible with the GPL is fine. It's just that there are ramifications that need to be considered. If a library is licensed in a way that's not GPL compatible, all that means is that GPL'd programs cannot link against it. If that's the design of the author, then that's fine (a la Microsoft's licensing schemes for their WinCE SDK). In the case of XFree86 this is a big deal for distro makers because the majority of their software is GPL'd and under the new licensing terms there's no way to legally link the gpl'd code against the XFree86 libraries. In the case of Apache, there's not really a problem here; Apache has never been GPL compatible. You just have to be aware of the terms when you develop.
As for your falacies regarding freedom and the BSD and GPL licenses, those have been dealt with thoroughly before, except to say that your attitude works well for a small project, but for a large project (especially a large, self-contained project like a whole OS), the GPL offers you the developer more freedom and protection from greedy folks than the BSD would.
No, the GPL isn't the problem here. And it's hardly a virus. Just because Apache is not GPL compatible doesn't mean the Apache foundation is going to be pressured (or mysteriously forced by way of some magical IP beast) to go GPL. Let's end that FUD right here and now.
Actually you're probably closer to the truth than you think. Although later in life Darwin was agnostic, he was never atheist, and in his early years as he formulated his theories, I believe he really did think the things that you quote in jest. In fact, much of the ground work for the theory of evolution was laid by the research of several clergymen/monks who were also scientists.
As a Christian myself, I think there is much truth to your jestful quotes from his "notes" and that you really can see God's work through evolution.
Well, the Saturn RISC processor that powers the venerable HP 48 Calulculator line has 64-bit registers but only a 4-bit data bus. The address bus is 20-bit, however. I have no idea what this processor is considered to be. I doubt they call it a 64-bit processor. Maybe they call it a 4-bit? Anyway, sometimes this whole "x-bit" thing is confusing. Reminds me of the old video game console days when they were all 8-bit processors but the games were considered advertized using the megabits they took up on the cartridge.
yup. fink install gnome-bundle. or fink-install [gnome-package-name] to install individual components. I did this and it took about a day of compiling off and on, but I have a full gnome desktop that I run on top of the normal OS X desktop (turn off nautilus, use quartz-wm). On the left side I have the normal OS X panel, and on the bottom I have a small gnome panel. The best of both worlds.
See the fink home page for more information. But really, it's not hard at all.
No it doesn't require a licensed copy of XP to run wine. But to run any of the drivers that ship with XP, especially ntfs.sys, then yes a licensed copy of XP is required. This is the basis for the captive-ntfs driver also. It requires you have XP already installed, then grabs its ntfs.sys and then uses that to mount the filesystem. If you don't have XP, then you can't legally use the ntfs.sys driver at all.
Slashdot Mirror
I don't see why setting up the RAIDs under any OS should be more time consuming than on other OSs. Certainly if you use the right hardware-based RAID things should be very simple and very fast.
.8 TB or so at a very reasonable price and very reliable. So far it has worked well.
Bang for the buck, you can't beat the Apple Xserve RAID. They are IDE, but almost as fast as the fastest scsi arrays, and seem to be very reliable. The array can be easily partitioned into a variety of raid types with hot spares. The unit can then connect to Windows or Linux via standard fibre channel interface and look like simple scsi drives. The RAID is administered via an ethernet connection using a nice java gui tool.
We set our Xserve RAIDs up such that each array (each Xserve RAID box has 2 arrays with separate controller logic for each) is RAID 5 plus a hot spare, and then the array is mirrored with the other one. This gives is
Solar power is very expensive, and there are other things you can do to lower your cooling expenses.
Consider where I grew up in southern Alberta. In the winter temperatures dip frequently to -40. In the summer highs of 100oF are not uncommon. The same insulation that keeps the house warm in the winter keeps it cool in the summer. In fact very few people that I know of have air conditioning. Even in a hot climate, good insulation can knock your cooling bills way down.
Another thing to consider is geothermal heating and cooling. The idea is to pump heat into the ground in the summer, and then pump it back out in the winter (well, it's actually based on temperature exchanges). You can get an amazing amount of cooling in hot summer this way. You will be required to do some digging, though.
Either way, running a standard A/C unit off of solar power seems to be very expensive by itself. These other things I've mentioned could make it approach practicality.
Graphics ceiling? No way. Even today's FPS 3-d graphics look rather bad, really. Too many aritificial-looking polygon edges, obviously flat textures, and so on. Upping the polygon count is helping that, and we sure haven't reached the ceiling on polygon count. Just because an older game doesn't look much better than a modern game doesn't mean we've reached the limit in what we can do. It actually just means our graphics rendering and systems still have a longs ways to go.
Although the traditional GTK file selector is very ugly, it has one hidden killer feature: Tab-completion. That's far faster and easier than any other system to drill-down to a file. If tab-completion is every removed from the GTK file selector, I will be very frustrated. Hopefully we can have something that looks good and works well and supports tab-completion. If the text entry box is indeed hidden, I'll be patching my gtk right away to get that to display automatically. Hiding it is a poor idea, IMHO.
I've seen the mockups for the gtk 2.4 file selector and I must say I don't like it at all. Unfortunately I couldn't see the screeshots in the article, so I don't know if this new gtk 2.4 dialog is the one they use or if gnome made their own dialog box.
I meant ClamAV should now automatically be properly identifying the virus dispite the encrypted zip file.
There is now a fingerprint in the ClamAV virus definitions that actually can detect the latest bagle pwdzip variants without having to unzip them. So no you don't need to just quarantine all password-protected zips. ClamAV should not be picking it up automatically.
There are much better and more secure ways to send data around. Consider using pgp or some other encryption package. I admit that these measures can cause a lot of inconvenience for users. This is the fault of the spam and virus gangs. They have ruined it for everyone. It is time to replace smtp, no doubt about it.
Tomasz Kojm, ClamAV developer, says about it:
No server based AV solution I know of will stop the latest wave of random password zip viruses. That is because the AV program cannot scan inside the zip file. I've posted a patch to the clamav-users mailing list that marks all password-encrypted zip files as suspect and thus can be quarantined for manual extaction and scanning if desired.
Right now I'm quarantining (with mimedefang and the patched clamav) all encrypted zip files. So far it's 100% hit rate, with no false positives. Unfortunately, ClamAV developers haven't said how they plan to deal with these password zip files.
Overall, once I patched clamav, I was more than pleased. Over the last 2 months Clamav working through mimedefang has saved us from almost all the viruses coming into our server. Updates are daily or more and I have a cron auto-updating them on the hour.
The beauty of having an open source AV was made clear to me today as I modified ClamAV to detect the encrypted zip files. Even though this is more of a stop-gap measure, with any other closed-source program I would have been completely at the vendor/developer's mercy.
That said, using clamav in conjunction with other AV programs in a stack fashion would give you even more coverage if you were worried.
Since the technology has been patented, full details should now be available in the patent application itself. Despite the company trying to require him to keep the technology secret, since it's in the patent, it can no longer be secret. Seems that legally the most the company could do is require him to license the technology to them exclusively. But to force him to keep it secret is quite absurd.
OnStar cannot currently track you in real time. The GPS measurements not done continuously. In fact an OnStar operator has to send a command to the car's GPS receive to calculate a fix. This can take up to 3 minutes at times. Plus the fix is not that accurate. Certainly the current OnStar system cannot track your speed in real time. Perhaps in the future it will, though.
For many people, OnStar is a great feature, and in fact can sometimes save lives. Personally I would never pay for it, though. I prefer to navigate by myself by dead reckoning. No maps and I certainly won't stop to ask anyone for directions!
Hmm. Sounds like that guy who keeps mosting the link to sco's web site. The solution is to give the googlebot a slashdot account and browse at +2!
Clearly this is a sign that your cat has some serious psychological issues and is asking for help. This is probably your cat's way of letting you know that spending all day every day inside your little apartment with nothing to do but play quake and chase optical mice that don't even taste good is slowly driving it insane. Think of your cat's mental health. Think of your own mental health. Not to mention your wallet. Let your cat go free. It's not worth 300 dollars!
No troll here.
Saying that about qmail is a bit like saying that because no one has broken into your house before it's secure. Although qmail probably is very secure, your statement does not follow.
As you mention, the biggest gripe OpenBSD has is that qmail is not open source.
Also qmail is not industry standard, it doesn't fit well into a standard linux install, and it doesn't play by default with the tools that sendmail regulars rely on like procmail (postfix and exim both do). And it certainly doesn't have a great filtering API. You can tack it on via procmail or some other mechanism, but it does not allow the connection-level control that the sendmail milter api allows (IE custom rejection of the connection during the session).
Although the parent post was moderated as "funny," I think the question is a serious one. I use sendmail exlusively because it is the only mail server that supports the powerful milter API and allows me to use mimedefang, which cannot work with any other mail server. Mimedefang can drive antivirus software and spam filter, not to mention sanitizing of html email and so forth, is a very powerful piece of software.
For many people postfix or exim work very well, and should be used over sendmail. But in a larger environment, sendmail is the standard. Qmail, well, I've never liked it.
If you don't control the mail server to create aliases for yourself, you can also employ RFC-compiliant suffixes to your e-mail address. For example:
foobar+dellorders@mydomain.com.
My boss related to me an experience that happened at his previous employment. The company that he worked for produced a very successful system for doing typesetting and layout for newspapers. A few years ago, they decided to put together a mockup of what their product might look several years down the road, and give an example of where their development was heading. So they put together a very convincing demonstration "movie" complete with scripted typos and mistakes. No one who saw the demo ever once thought that the whole thing was faked. They thought this was the real deal. The demo turned out so good that customers immediately dropped any and all demand for their existing product, wanting to wait for the new version. The problem was the new version wasn't even started yet. At best it would be 2 to 3 years down the road. That little demo just about bankrupted the company.
A bit of an extreme example of how a premature demo can really hurt a company. I imagine with games it could be similar, except that gamers are rarely the type to stop buying while they wait for new things.
I would love to see some of the lower-level KDE features made available to gnome through some kind of thunk layer. For example, blending gnome-vfs modules into the KIO subsystem, or blending KIO slaves into the Gnome VFS subsystem would be very very useful to me.
Theming integration is also cool. Right now there is a gtk theme that uses the current KDE theme engine to draw the widgets. I would love to see a QT theme that uses the current GTK engine to draw widgets. Then a program like KDevelop might actually fit into my desktop.
Another pipe dream that is slowly being worked on is a way to call methods on objects from the Gnome framework to the KDE framework and vice versa.
You're missing the point with regards to the GPL. Having a license that's not compatible with the GPL is fine. It's just that there are ramifications that need to be considered. If a library is licensed in a way that's not GPL compatible, all that means is that GPL'd programs cannot link against it. If that's the design of the author, then that's fine (a la Microsoft's licensing schemes for their WinCE SDK). In the case of XFree86 this is a big deal for distro makers because the majority of their software is GPL'd and under the new licensing terms there's no way to legally link the gpl'd code against the XFree86 libraries. In the case of Apache, there's not really a problem here; Apache has never been GPL compatible. You just have to be aware of the terms when you develop.
As for your falacies regarding freedom and the BSD and GPL licenses, those have been dealt with thoroughly before, except to say that your attitude works well for a small project, but for a large project (especially a large, self-contained project like a whole OS), the GPL offers you the developer more freedom and protection from greedy folks than the BSD would.
No, the GPL isn't the problem here. And it's hardly a virus. Just because Apache is not GPL compatible doesn't mean the Apache foundation is going to be pressured (or mysteriously forced by way of some magical IP beast) to go GPL. Let's end that FUD right here and now.
Actually you're probably closer to the truth than you think. Although later in life Darwin was agnostic, he was never atheist, and in his early years as he formulated his theories, I believe he really did think the things that you quote in jest. In fact, much of the ground work for the theory of evolution was laid by the research of several clergymen/monks who were also scientists.
As a Christian myself, I think there is much truth to your jestful quotes from his "notes" and that you really can see God's work through evolution.
Well, the Saturn RISC processor that powers the venerable HP 48 Calulculator line has 64-bit registers but only a 4-bit data bus. The address bus is 20-bit, however. I have no idea what this processor is considered to be. I doubt they call it a 64-bit processor. Maybe they call it a 4-bit? Anyway, sometimes this whole "x-bit" thing is confusing. Reminds me of the old video game console days when they were all 8-bit processors but the games were considered advertized using the megabits they took up on the cartridge.
yup. fink install gnome-bundle. or fink-install [gnome-package-name] to install individual components. I did this and it took about a day of compiling off and on, but I have a full gnome desktop that I run on top of the normal OS X desktop (turn off nautilus, use quartz-wm). On the left side I have the normal OS X panel, and on the bottom I have a small gnome panel. The best of both worlds.
See the fink home page for more information. But really, it's not hard at all.
Michael
Cisco's VPN client is very much panther compatible. I use it every day. Just make sure you have the lastest version (version 4.something I believe).
No it doesn't require a licensed copy of XP to run wine. But to run any of the drivers that ship with XP, especially ntfs.sys, then yes a licensed copy of XP is required. This is the basis for the captive-ntfs driver also. It requires you have XP already installed, then grabs its ntfs.sys and then uses that to mount the filesystem. If you don't have XP, then you can't legally use the ntfs.sys driver at all.