Redhat are dropping Xen like a hot potato and moving to KVM.
Is there an actual citation to back that up? What a bunch of misinformed FUD. Red Hat is taking a more Hyper-Visor agnostic approach. In other words they are building management tools which will work across all the major Open Source virtualization platforms. Red Hat is not going to dictate whether their customers run KVM, Xen, or QEMU.
Well if you keep separate vendor and site Perl directories then this is an easily amended situation. What is described in the article is one or a few broken Perl modules, with that said, Perl itself is NOT broken.
On the Linux systems I manage, there is a separate 'site' and 'vendor' directory. If a vendor supplied Perl module breaks something I delete or rename the offending module in the vendor directory. Likewise, if a CPAN module breaks something then I can delete or rename the offending module in the site directory.
If you have 'use warnings' and 'use strict' in your Perl applications you should get an error or warning complete with module name, and line number when this sort of thing happens. It sounds to me that Apple might be at fault for rolling back to a previous version of a module. However, whoever initially configured CPAN could have created a separate site directory and avoided this whole mess. So in the big picture, it is not Apple's fault so much as it is the Administrator.
At a university I worked at in the late 80s, the vaxen were named Bilbo, Frodo, and Gandalf.
Our University had a cluster of DEC Alpha Servers, named in a similar fashion. The cluster was named HOBBIT, as a play on the computing term High-Ordered Bit. I believe the individual nodes were named Bilbo, and Frodo. I seem to remember Pippin, Gamgee, and Gandalf nodes, but I could be mistaken.
I really don't know. Ink-jet printer can be left as an example, together with some termal printer. Why not?
The Inkjet cartridges will be either be hard little bricks, or filled with dust in 50 years. I am guessing the cartridges would dry out even if they were packaged in vacuum-packed foil or plastic. Inkjet printers also have an ink well to collect excess ink, if an inkjet is left plugged in, the printer will wake up and clean the heads periodically by disposing ink directly into the ink well. It basically just pisses away the little amount of ink in the inkjet printer, even when you are not using it. Over time, the ink well will solidify and you will have a brick of ink, which jams the printer. So an inkjet probably would not be a good candidate for a time capsule.
Of course it was, it's the GPL, nothing more, nothing less.
No, the Gnu compiler collection does not require that every application compiled with it be licensed under the GPL, that would be absurd.
What you are referring to is a condition of the commercial license, (to prevent you from finally buying 1 single license to release your 20-man-years-application commercially). You are free to accept, reject, or try and renegotiate the conditions of this commercial license. If you don't like them, stick with the GPL, it's your choice.
Qt was already Open Source, of course, under the GPL.
That is not entirely accurate.
Qt was previously dual-licensed by Trolltech with certain restrictions. If you used the GPL version of the Qt development tools and IDE then it was required a viral GPL license be applied to any application developed. You could not use the "Free" version of Qt to develop a closed source application. I may be mistaken but there may have been other restrictions, such as the ability to develop commercial application with the GPL Qt toolset. The GPL version of Qt was intended by Trolltech to only be used for educational, non-commercial, and personal use.
Again, I re-iterate that I may be wrong about the restrictions placed on the Qt developer toolset. Someone, please correct me if I am mistaken. It was certainly not a traditional GPL software development toolkit in the sense of the restrictions placed on the developer. I don't know of any other open-source development environments, or widget toolkits that carry these same type of restrictions.
The non-viral GPL licensed version, on the other hand, costs somewhere in the neighborhood of $1,500 per developer. You could, however, license the resulting application in any which way you pleased. As opposed to being forced into using the GPL toolkit. Which is really not a bad compromise, if your goal is to learn about C++ development with Qt, or it is your intention to develop a snappy looking GPL application. By the way, I used Qt for a "pick your own language" undergrad software development project, the instructor thought I had the best looking GUI. To be honest, I probably spent the least amount of time on the graphical design, since Qt was so intuitive and easy for a beginner to pick up.
Efficient or not, to process 2 million web submits in one shot...
I believe the original poster was using hyperbole. He was suggesting that Kentucky could not have possibly processed 2 million unemployment claims online, seeing as how the the state only has 4 million residents. A really high unemployment rate would be 15-20%, not 50% of the residents.
with a database involved, serving the images, bandwidth, database transactions and locks(big deal here!), etc etc etc...
Which, does not have to be run on the same machine. I would have to argue that even if the state of Kentucky could not afford proper web servers, database servers, storage solutions, competent web developers, and database/system administrators; they CAN certainly afford to outsource it to a reasonably priced local hosting/web development shop. I couldn't get a netcraft report on the uiclaims.des.ky.gov site, but des.ky.gov is running Windows 2000, with IIS 5.0. If that is any indication of the servers age, and the server is 7-8 years old, it is no wonder it crashed or could not handle the load.
Curious, as to whether this was a case of an incompetent hosting provider, or whether the Kentucky state IT department is just that incompetent. I did a whois lookup on the IP of the Kentucky unemployment claims website, the site is indeed hosted by the state of Kentucky, and not a hosting provider.
...will trash many data -centers-, nevermind one machine.
Bullshit! Two million web hits at once, will not crash a data center! It could seriously slow down or crash a server, new or old, it might even put a heavy load on a few load balanced web servers. However, as the original poster pointed out, it is highly unlikely that there were 2 million web hits all at once.
My mistake, I thought the default sudoers access was a little more open on a default Ubuntu install. Of course, I agree that physical access is as good as having root access to a system.
My original point still stands, the original poster was not looking for another way to use sudo. Using su without having to resort to forking it off of sudo is a legitimate concern for an Ubuntu user.
The original poster, to which I replied, was annoyed at using sudo in the first place. The only thing you have offered is yet another way to use sudo. I don't want to get into an argument over which, su or sudo, is better. However, some people, such as the original poster, prefer to do administration tasks with su. In order to do that, the administrator of the system will need to set a root password.
Did you ever consider that some crafty user on a multi-user Ubuntu system may set the root password, and lock you out of sudo?
As for my nomination: I think it would have to be the inability to "su" and run in root mode. I understand the reasoning behind it but stuff like this can get annoying pretty quick:
Behavioral and statistical analysis has been coupled with Intrusion Detection Systems (IDS) do exist. They are known as Anomaly-Based IDS. What I described is a Signature-Based IDS, which is much more common than the Anomaly-Based type. I suspect the reason for the prevalence of Signature-Based is they are easier to design, and require much fewer resources.
In my personal experience, Signature-Based Prevention systems are quite effective against this type of attack. Which is why I pointed it out in the first place. If you have a failed SSH login signature, which hits a certain threshold, that is certainly suspicious behavior. I think it is a moot point to even check whether the userid is in the passwd file. Because, from my point of view, there is no difference between an attacker failing a login from an invalid userid or a login as root, backup, or user666 for that matter. Any way you look at the situation, it is still an attack, and one that can be dropped.
This is sort of how Intrusion Prevention System (IPS) automatic blocking currently works, but not exactly as you describe. If you have an Intrusion Dectection System (IDS) like Snort, you can add on an IPS solution to take care of this. For example, there are SSH brute force detection rules in both, the official Snort and community Bleeding Edge rule sets. You can configure snort-inline to alter iptables rules dynamically, or use third party software, such as SnortSAM to automatically block the traffic at your edge firewalls.
I personally prefer SnortSam to do the blocking. It is fairly easy, with SnortSAM, to set up a distributed network of trusted sensors and firewalls, which can alert one another to threats. The SnortSAM sensor-to-firewall messages are encrypted with TwoFish; it supports whitelisting to prevent Denial-of-Service attacks; you can specify the amount of time to block. You could also crank up threshold in Snort to prevent false positive blocking. However, the last time I used Snort I found that 5 failed SSH logins in 2 minutes, the default threshold for the SSH brute force rules, was dead on accurate.
What is it with large corporations and only creating RPM files for their software? I got the.bin file, but it just extracts to the current directory, without listing where all the files need to be copied to...
The simplest thing you could do, is use the "alien" package to convert it to a.deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.
As for where the Java files go, they usually go under/usr/lib/java or/usr/lib/jre if I recall correctly.
Maybe you should not install the game on your 486 SX, dude.
I tryed later the Steam way - about 4 hours and a half. And I finished that game in about 7 hours.
If you had a decent Internet connection it should not have taken much longer than an hour. Maybe, just maybe, you should think about ditching the 14.4 modem for something faster.
Yeah, you pretty much summed up what I was going to say. Everything you said was accurate except for the DOS thing.
"Half-Life: Source" was done as a proof-of-concept. In other words, Valve made Half-Life: Source, to find out how long it would take a mod-team to port from the GoldSrc/HL engine to the Source/HL2 engine.
If I am not mistaken, the end result of Half-Life: Source is the exact same as the original Half-Life. The only value added is shiny water and rag-doll physics. Which to be quite honest, Half-Life: Source really sucked as a 2004 stand-alone product. For many Half-Life fans, the Source version just did not do justice to the original game. To be fair, if you have never played the original Half-Life, then you are going to get much of the same experience playing the Source version. In summary, Half-Life: Source was like Greedo shooting first.
The Black Mesa team of course, was a group of fans, inspired to re-make the original on the Source engine but do so with modern game play and graphics. Now Valve has merely asked them to drop the "Source" part of their game title, and has not shown any resistance in almost 5 years. It seems to me that Valve has given them an endorsement to continue.
Also calling Mac OS Unix is like calling Windows NT VMS. Sure, you can do Unix stuff on it as that's what it was built on but what makes it Mac OS is all the proprietary stuff Apple have built on top of it.
Mac OS is UNIX: Exhibit A. Anyway, who said UNIX proper couldn't have proprietary components? There are dozens of brands of UNIX with proprietary stuff added, Apple was by no means the first vendor to add their own components to UNIX.
Ubuntu may be Linux, but "Linux" is not Ubuntu.
Is there an actual citation to back that up? What a bunch of misinformed FUD. Red Hat is taking a more Hyper-Visor agnostic approach. In other words they are building management tools which will work across all the major Open Source virtualization platforms. Red Hat is not going to dictate whether their customers run KVM, Xen, or QEMU.
Well if you keep separate vendor and site Perl directories then this is an easily amended situation. What is described in the article is one or a few broken Perl modules, with that said, Perl itself is NOT broken.
On the Linux systems I manage, there is a separate 'site' and 'vendor' directory. If a vendor supplied Perl module breaks something I delete or rename the offending module in the vendor directory. Likewise, if a CPAN module breaks something then I can delete or rename the offending module in the site directory.
If you have 'use warnings' and 'use strict' in your Perl applications you should get an error or warning complete with module name, and line number when this sort of thing happens. It sounds to me that Apple might be at fault for rolling back to a previous version of a module. However, whoever initially configured CPAN could have created a separate site directory and avoided this whole mess. So in the big picture, it is not Apple's fault so much as it is the Administrator.
Our University had a cluster of DEC Alpha Servers, named in a similar fashion. The cluster was named HOBBIT, as a play on the computing term High-Ordered Bit. I believe the individual nodes were named Bilbo, and Frodo. I seem to remember Pippin, Gamgee, and Gandalf nodes, but I could be mistaken.
The Inkjet cartridges will be either be hard little bricks, or filled with dust in 50 years. I am guessing the cartridges would dry out even if they were packaged in vacuum-packed foil or plastic. Inkjet printers also have an ink well to collect excess ink, if an inkjet is left plugged in, the printer will wake up and clean the heads periodically by disposing ink directly into the ink well. It basically just pisses away the little amount of ink in the inkjet printer, even when you are not using it. Over time, the ink well will solidify and you will have a brick of ink, which jams the printer. So an inkjet probably would not be a good candidate for a time capsule.
Nice one.
I am going to blame early morning confusion, prior to the first cup of coffee.
No, the Gnu compiler collection does not require that every application compiled with it be licensed under the GPL, that would be absurd.
No, as I mentioned before, I am referring to the restrictions on the Free edition.
http://en.wikipedia.org/wiki/Q_Public_License
That is not entirely accurate.
Qt was previously dual-licensed by Trolltech with certain restrictions. If you used the GPL version of the Qt development tools and IDE then it was required a viral GPL license be applied to any application developed. You could not use the "Free" version of Qt to develop a closed source application. I may be mistaken but there may have been other restrictions, such as the ability to develop commercial application with the GPL Qt toolset. The GPL version of Qt was intended by Trolltech to only be used for educational, non-commercial, and personal use.
Again, I re-iterate that I may be wrong about the restrictions placed on the Qt developer toolset. Someone, please correct me if I am mistaken. It was certainly not a traditional GPL software development toolkit in the sense of the restrictions placed on the developer. I don't know of any other open-source development environments, or widget toolkits that carry these same type of restrictions.
The non-viral GPL licensed version, on the other hand, costs somewhere in the neighborhood of $1,500 per developer. You could, however, license the resulting application in any which way you pleased. As opposed to being forced into using the GPL toolkit. Which is really not a bad compromise, if your goal is to learn about C++ development with Qt, or it is your intention to develop a snappy looking GPL application. By the way, I used Qt for a "pick your own language" undergrad software development project, the instructor thought I had the best looking GUI. To be honest, I probably spent the least amount of time on the graphical design, since Qt was so intuitive and easy for a beginner to pick up.
I believe the original poster was using hyperbole. He was suggesting that Kentucky could not have possibly processed 2 million unemployment claims online, seeing as how the the state only has 4 million residents. A really high unemployment rate would be 15-20%, not 50% of the residents.
Which, does not have to be run on the same machine. I would have to argue that even if the state of Kentucky could not afford proper web servers, database servers, storage solutions, competent web developers, and database/system administrators; they CAN certainly afford to outsource it to a reasonably priced local hosting/web development shop. I couldn't get a netcraft report on the uiclaims.des.ky.gov site, but des.ky.gov is running Windows 2000, with IIS 5.0. If that is any indication of the servers age, and the server is 7-8 years old, it is no wonder it crashed or could not handle the load.
Curious, as to whether this was a case of an incompetent hosting provider, or whether the Kentucky state IT department is just that incompetent. I did a whois lookup on the IP of the Kentucky unemployment claims website, the site is indeed hosted by the state of Kentucky, and not a hosting provider.
Bullshit! Two million web hits at once, will not crash a data center! It could seriously slow down or crash a server, new or old, it might even put a heavy load on a few load balanced web servers. However, as the original poster pointed out, it is highly unlikely that there were 2 million web hits all at once.
My mistake, I thought the default sudoers access was a little more open on a default Ubuntu install. Of course, I agree that physical access is as good as having root access to a system.
My original point still stands, the original poster was not looking for another way to use sudo. Using su without having to resort to forking it off of sudo is a legitimate concern for an Ubuntu user.
The original poster, to which I replied, was annoyed at using sudo in the first place. The only thing you have offered is yet another way to use sudo. I don't want to get into an argument over which, su or sudo, is better. However, some people, such as the original poster, prefer to do administration tasks with su. In order to do that, the administrator of the system will need to set a root password.
Did you ever consider that some crafty user on a multi-user Ubuntu system may set the root password, and lock you out of sudo?
Funny, as a Linux user, I tend not to sleep with unshaven, unwashed, dirty hippy Mac girls.
There is an easy enough fix for that:
sudo passwd root
Behavioral and statistical analysis has been coupled with Intrusion Detection Systems (IDS) do exist. They are known as Anomaly-Based IDS. What I described is a Signature-Based IDS, which is much more common than the Anomaly-Based type. I suspect the reason for the prevalence of Signature-Based is they are easier to design, and require much fewer resources.
In my personal experience, Signature-Based Prevention systems are quite effective against this type of attack. Which is why I pointed it out in the first place. If you have a failed SSH login signature, which hits a certain threshold, that is certainly suspicious behavior. I think it is a moot point to even check whether the userid is in the passwd file. Because, from my point of view, there is no difference between an attacker failing a login from an invalid userid or a login as root, backup, or user666 for that matter. Any way you look at the situation, it is still an attack, and one that can be dropped.
This is sort of how Intrusion Prevention System (IPS) automatic blocking currently works, but not exactly as you describe. If you have an Intrusion Dectection System (IDS) like Snort, you can add on an IPS solution to take care of this. For example, there are SSH brute force detection rules in both, the official Snort and community Bleeding Edge rule sets. You can configure snort-inline to alter iptables rules dynamically, or use third party software, such as SnortSAM to automatically block the traffic at your edge firewalls.
I personally prefer SnortSam to do the blocking. It is fairly easy, with SnortSAM, to set up a distributed network of trusted sensors and firewalls, which can alert one another to threats. The SnortSAM sensor-to-firewall messages are encrypted with TwoFish; it supports whitelisting to prevent Denial-of-Service attacks; you can specify the amount of time to block. You could also crank up threshold in Snort to prevent false positive blocking. However, the last time I used Snort I found that 5 failed SSH logins in 2 minutes, the default threshold for the SSH brute force rules, was dead on accurate.
Linux just wants to be loved. Windows just wants to be used.
You must be new here.
No that is nihilism, the belief in nothing. Atheism is the belief in no God.
One could define atheism with a Perl one liner as such:
my $God = undef;
The simplest thing you could do, is use the "alien" package to convert it to a .deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.
As for where the Java files go, they usually go under /usr/lib/java or /usr/lib/jre if I recall correctly.
Think about it, I'll call it the "Swedish Problem" wherein the entire country is filled with hot blondes...
I don't know if I would go as far as calling it a "problem".
Maybe you should not install the game on your 486 SX, dude.
If you had a decent Internet connection it should not have taken much longer than an hour. Maybe, just maybe, you should think about ditching the 14.4 modem for something faster.
Yeah, you pretty much summed up what I was going to say. Everything you said was accurate except for the DOS thing.
"Half-Life: Source" was done as a proof-of-concept. In other words, Valve made Half-Life: Source, to find out how long it would take a mod-team to port from the GoldSrc/HL engine to the Source/HL2 engine.
If I am not mistaken, the end result of Half-Life: Source is the exact same as the original Half-Life. The only value added is shiny water and rag-doll physics. Which to be quite honest, Half-Life: Source really sucked as a 2004 stand-alone product. For many Half-Life fans, the Source version just did not do justice to the original game. To be fair, if you have never played the original Half-Life, then you are going to get much of the same experience playing the Source version. In summary, Half-Life: Source was like Greedo shooting first.
The Black Mesa team of course, was a group of fans, inspired to re-make the original on the Source engine but do so with modern game play and graphics. Now Valve has merely asked them to drop the "Source" part of their game title, and has not shown any resistance in almost 5 years. It seems to me that Valve has given them an endorsement to continue.
Mac OS is UNIX: Exhibit A. Anyway, who said UNIX proper couldn't have proprietary components? There are dozens of brands of UNIX with proprietary stuff added, Apple was by no means the first vendor to add their own components to UNIX.