Re:PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 2
It depends on your enviornment. for money, I work in one where people (read: management) like to have a monitor and keyboard that can get to each and every box.
For fun, I do solaris for another datacenter that's really into serial consoles, with 16 servers per console server.
The nice thing about the high end KVM stuff, is you can get huge numbers of servers on one system, and at least the one at work (CCC) can send sun and pc views to either sun or pc monitor/keyboard sets.
The nice thing about serial console is that you can telnet (well, ssh) into the console, and get to all of them, even on a 2400baud modem.
The down side is that serial consoles don't scale for spit. Most serial concentrators deal with 16 or less ports per. The 'for fun' datacenter has to have 10 or 20 console servers, whereas at work, we have 1 switch (128 port, and you can cascade several together), and however many monitor stations we need for our usage pattern.
The problem with this is that both RI and Conn. are planning on sending taxes to these residences, and BOTH expect to collect. If they don't they will take these people to court in either RI or Conn, where they will be guilty.
What do you do in that case? It certainly will impact you, especially if one state is a tourism state (collects lots of revenue from sales tax) and the other is a property tax state.
--Jason
Re:PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 2
I am a sysadmin in a medium sized, mixed hardware datacenter. You have no idea how often hardware blows out, bios'en need updating, Roms need flashing.....
All of which are below the OS level. With no os, you must have console (or remote console)
We have around 150-200 servers lying around. We're back there almost everyday with SOMETHING, be it an initial OS install, hardware failure, or routine maintance. A good KVM system gives you the win of "few monitors, many servers", and also provides remote access to the console for when you don't need to replace something (say, you need to debug a Sun at the eeprom level)
All of which fall into "when you need console access, nothing else will suffice".
Re:PC Weasels are often better than KVM switches.
on
USB KVMs Compared
·
· Score: 2
As another poster said, you're solving a different problem. Remote manangement (aka a developer needs access to the box) is what PC Weasel is all about.
If you have more than 10 servers, are you planning on getting 10 monitors, 10 keyboards and 10 mice, one set for each server? It's a waste of money, it's a HUGE waste of space, and it can't be made to look professional.
A good KVM let's you throw 1 monitor and keyboard at a bunch of boxes. You don't NEED true console access often; however, when you need it, nothing else will suffice.
In a data center environment, you're going to need both remote management and KVM.
The real answer is to use server class hardware from a real supplier. Both Dell and Compaq have rather solid server offerings with hardware raid built in. No need to worry with MS's implementation. And if you're doing RAID 5, you really should be in hardware anyway, or performance will kill you.
If this is for home use, or for fun, then play all you want. But since you're paying for windows anyway, you might as well poney up for real hardware. Your life will be happier for it.
Advocacy, we never knew thee.
on
Qt vs MFC
·
· Score: 3, Insightful
This guy doesn't seem to understand much of what he's talking about.
The most glaring clue is this:
For example, to swap two variables, the author used the non commented following line:
a ^= b ^= a ^= b;
This is a cool hack which does not belong to a professional product.
If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.
Any time you look at low level libraries, you're going to see things like this. They NEED speed. They NEED low memory impact. These things are going to get called in tight loops with a million iterations. Look at QT's code, and you'll see the same thing.
Also telling is the fact that he has nothing positive to say about MFC. I've run across some VERY talented developers, and while I haven't heard them singing MFC's praises, they do have some nice things to say. Advocacy really needs to show balance. Acknowledging MFC's strong points is important.
When he's talking about an add on library called 'codejack', he mentions that tab views are impossible in MFC, yet codejack provides it. Apparently it is NOT impossible in MFC then. It probably isn't a prebuilt widget for the developer to use (which is unfortunate, I'll admit)
QT is a good library, I have no doubt. But please learn how to find good things in other libraries. It will only make your code better. It will only make your advocacy better.
You could use pam/radius or pam/ldap to talk from freebsd to windows, and do the login thing. You would have to use virtual mailboxes, and no real logins to the freebsd box. You probably want that last bit anyway. Webmail/imap can be good with this kind of setup.
Otherwise, AFAICT, you're going to have to force everyone to change their passwords. Best bet is to take a weekend. Friday, have everyone archive their email, and turn off exchange so incoming mail gets queued. Do your transition, and monday when they come in, they'll use webmail/pop/imap.
No, the really funny bit is that this challenge/response list is now A PART OF PUBLIC RECORD. If (important if) it's true, phreaking could have quite the little renaissance.
Anything put out on the internet should have no important data on it. Period. No connections from the internet (aka untrusted aka hostle) should be allowed to the box with the real data, other than those which are PROVEN to be needed, and secure. So:
internet -> firewall(1) -> web server -> firewall(2) -> database
So, you have 2 firewalls. One internet facing, and one (idealy a different vendor) from the DMZ to the internal world.
Also, you can set up 2 houses for the data. One (the one that the internet can get access too by proxy) should only cache the recent data. Hourly, or nightly, it should then be put into another server, from which the accounting department can run bills. Then this box (for accounting) should have no allowed connection to the rest of the world, save from the accounting department.
Oh, and the important data should be then purged from the internet proxy accessable database.
On increadibly rare occasions, I have written a program or script that has worked 100% right, immediatly. At most, these have topped out at 100 lines or so.
I am always shocked when this happens, and usually dislocate my shoulder patting myself on the back when it does happen.:-)
So, what exactly are the odds that something that is at least a million lines of code will work right the first time?
Good solution in a pinch, but that's what xargs was built for.
Say ls would give
aaa aab aac aad aae aaf...... cqd cqe.... zzz
find . -print | xargs rm
would make a bunch of rm commands, exactly as long as would be permitted (either by line length, or argument numbers). So, instead of 1 rm per file, you have 1 rm per files. Much more effecient.
Deagol said: tar cf - foo | ssh root@host "cd/bar ; tar xvf -"
Toast0 said: why not use scp to copy the stuff instead of tar?
Tar's faster (for large scale directories). NOTE: This is on solaris that I did the following.
We have 1 website with a BLOODY STUPID design. Part of it is that 1 filesystem has 13 MILLION files in it. Some of the directories have 10 or 15 thousand files in them. The idiots should have used a proper database. This is one of the few times under solaris that I wished for reiserFS. Anyway I was tasked to copy this fs over to another box (website migration).
First time, tried rdist. 8 hours later, and about 20% complete, we tried something else (For grins, I did the same command later... rdist ended up taking 28 hours in total).
Second time, rcp. 28 hours again.
Third time, rsync. Took less time (about 10 hours).
Fourth time, tar over rsh. Took 4 hours.
Shlepping filesystems across machines with ssh and tar is really, really nice and quite fast. I highly recommend it.
The slight problem with this (not in this case though) is you have the expense of forking and killing a lot of processes (equal to the number of files +1 for the find). On the mv or cp case, you can't (easily) get around it, but if you were to do:
find . -type f -exec chmod 644 {} \;
vs
find . -type f | xargs chmod 644
you'll find that the second runs amazingly faster, since it will group a lot of the commands together into 1.
I did 'cd/usr/bin ; time find . -type f -exec ls {} \;' and got:
find . -type f -exec ls {} \; 0.98s user 3.28s system 88% cpu 4.831 total
I did 'cd/usr/bin ; time find . -type f | xargs ls -1 ' and got:
find . -type f 0.00s user 0.02s system 31% cpu 0.063 total xargs ls -1 0.03s user 0.04s system 74% cpu 0.094 total
That's a BIG difference, especially when you have a LOT of files.
(NOTE: if I did a bare 'ls' with the xargs, the output would be different due to the way xargs works (man xargs for more details). It may or may not make a difference depending on how you're using the output. If you're shleping the whole line at once, it could make a huge difference... if you're spliting the lines by $IFS or something, then it's probably alright.)
As for my contribution, I find these 3 find | xargs commands, wraped together in a script I call "makereadable" help me a LOT (for example, if you install from source, and the permissions get borked due to forgetting to set root's umask to 022):
The first makes all directories 755. 99.99% of the time, that's what you want... just don't do it with/tmp (sticky bit will get wacked). The second finds all files that are executable by the user owner, and makes them executable to others too. The third finds what is readable to the user, and makes it readable too.
If you want to do this with write permissions, you're probably doing something stupid you will regret later. Figuring out the command to do this is then left as an exercise for the reader.:-)
I'm not sure that I'd spin the story like that, especailly about the "linux buying out egcs.com".
Gcc seamed like it had been stagnant forever at the 2.7.* branch. If you look at the release history, you'll see that 2.7 was first released in June 95, and 2.7.2.3 was released in August of 97. Two years of point releases, with nothing new.
Well, some folks got tired of it, and forked the code. They made something called pgcc, which had more optimizations for the pentium (I) arch. Some of you may remember that the main distinction between redhat and the origional mandrake release was that Mandrake compiled all of redhat's packages with pgcc (except the kernel)
One thing led to another, and the pgcc fork got folded into the egcs versions. People were dismayed that there were 2 competing versions of gcc lying around but only one of them seemed to be moving: the egcs one. Egcs released version 1.*
Finally, the egcs and the gcc folks got to talking, and the egcs board became the gcc steering committee. If you look at the gcc release history, you'll see the egcs versions listed there too, because egcs became gcc 2.95.*
The gcc release history can be found at: http://gcc.gnu.org/releases.html
8. What did you think about the Intel Compiler v6 that came out recently? Did you have time to have a look at it?
Mark Mitchel: I do not have enough information about that compiler to comment on it.
I know that x86 is just 1 arch for gcc, however it is an important one, being the most common. I would think that those heavily involved with gcc (and especially the x86 backend) would be much more interested in how well the other compilers performed since they are 'the competition' as it were.
It's kind of depressing that he 'doesn't have enough information to comment'.
if intel's compiler had been released last month or thereabouts, I could understand, but IIRC, it was released about 6 months ago.
You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose.
Stallman's point:
This prohibits modifications for private use, denying the users a basic right
I'm not 100% sure I see his point. If you make use of the code for any purpose, and Lucent asks you for the changes you made, you have to give it to them. IANAL, but it seems that they just want to be able to see all changes that get made.
The rest of RMS's points make sense, and this clause:
The licenses and rights granted under this Agreement shall terminate automatically if (i) You fail to comply with all of the terms and conditions herein; or (ii) You initiate or participate in any intellectual property action against Original Contributor and/or another Contributor.
is truly awful. See the link from Nathan Myers for a well written explanation of just how bad this is.
The eternal war. Given enough time, you can secure 1000 boxes (turn off all un-needed services for the application(s) that this box needs to run, apply all the patches to those apps, tune the OS tightly...) Takes quite a while.
Or (says the 3com salesperson) you can just spend some money. Central server says this box can only talk on this (short) port|protocol list. Everything else is droped at the interface, doesn't even get to the kernel.
Sure, there are things you can do on a large scale to make securing boxes much easier (jumpstart, kickstart, whatever NT calls it, to get a secure base install, etc), but you still have to deal with patching individual boxes.
If I have to deploy a lot of computers in an activly hostile environment, something like this would be very nice.
* L1-cache: 64 kB 4-way Data, 32 kB 4-way instruction, 2 kB prefetch, 2 kB Write
* L2-cache Tag RAM and controller on-chip to support 1, 2, or 8 MB external
* L2-cache data SRAMs
* Dedicated 256-bit data path for the L2-cache
When you get down to it, the high end chips actually do mirrored cache. So, it's really 16 megs, with parity error checking, mirrored.
Will it play quake well? Probably not. Will it kick butt in hard core dataset analysis? Heck yes.
Yes, I know. I thought I had the correct sequence of new keys in there, however, I had messed up a few of them, and because the first key was the eval key, it didn't fall through to the rest of them.
Had I been inteligent, I would have deleted the eval key at a point when I could test that everything would start normally. However, I didn't understand enough of how veritas worked at the time.
1. 90 day or unlimited trial only with the stupid features turned off.
[poster2 replied:]
In other words, pretty much give it away for free. (90 days apart to uninstall/reinstall or in some cases reformat is not much of a pain in the ass.)
Better: In your registration code, encode the start and end dates of the evaluation. Encrypt and obfuscate it to the far-thee-well, and have done.
If someone's willing to keep the dates on they're computer out of sync, you'll not get money out of them anyway (since they're too small of a shop (or home) for you to bother with.
Though I must strongly agree with the poster who suggested sending email warnings about licenses expiring. Veritas NetBackup does the encode the date thing. We had paid for it, and I thought that I had put the keys in correctly. However, it just quit on me. Something one does NOT want to see in their enterprise backup solution...
Once I read the review, this was my exact question. However, it doesn't seem that Jabber has the promise of not loosing messages that persistant queue's in MQ can give you.
Soneone correct me if I'm wrong.
The promise not to loose a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).
This quote struck me as odd as well, but I got to thinking about it, and I think I see at least where he was going.
We geeks tend to be facinated by "the newest thing", and rush to try it, and then preach it's merits to anyone who will listen. I know I'm generalizing, and there are people still happily running 2.0 kernels, but look at the general trend. We don't mind using version 0.0.7b6 of products that are cool without thinking twice about it.
Once we learn something new, we tend to make great use of it. And we seem to think of little else. That's probably what he was aiming for in that quote.
Sure, it's very interesting that Linux has a system interface that's so straightforward that it can be easily manipulated in sort-of-real-time by a simple scripting language
People have already pointed out the 'application firewall' use, and probably the fantastic debugging uses. It's not just interesting, it's dang useful. Think about how people could use it to chase down possible buffer overflows. Force the system to return something other than what your program expects. How does it respond? Gracefully? Die an ugly death? Maybe I should fix that...:-)
and i'm sure you have to be root to run it
Maybe not. So long as it's enabled in the kernel, you should be able to make use of it. strace and truss and their ilk have been doing the 'trace system calls' thing for years. This is just more powerful.
but somehow the fact that somebody's already put together something like this really makes me less confident about Linux, not more.
Already? I have no clue what you're talking about. Linux has been around for more than a decade. Python's been around for almost a decade too. Unix has been around in some form since the late 60's. Already in the 2.4 kernels? They've been around for more than a year.
Slashdot Mirror
It depends on your enviornment. for money, I work in one where people (read: management) like to have a monitor and keyboard that can get to each and every box.
For fun, I do solaris for another datacenter that's really into serial consoles, with 16 servers per console server.
The nice thing about the high end KVM stuff, is you can get huge numbers of servers on one system, and at least the one at work (CCC) can send sun and pc views to either sun or pc monitor/keyboard sets.
The nice thing about serial console is that you can telnet (well, ssh) into the console, and get to all of them, even on a 2400baud modem.
The down side is that serial consoles don't scale for spit. Most serial concentrators deal with 16 or less ports per. The 'for fun' datacenter has to have 10 or 20 console servers, whereas at work, we have 1 switch (128 port, and you can cascade several together), and however many monitor stations we need for our usage pattern.
The problem with this is that both RI and Conn. are planning on sending taxes to these residences, and BOTH expect to collect. If they don't they will take these people to court in either RI or Conn, where they will be guilty.
What do you do in that case? It certainly will impact you, especially if one state is a tourism state (collects lots of revenue from sales tax) and the other is a property tax state.
--Jason
I am a sysadmin in a medium sized, mixed hardware datacenter. You have no idea how often hardware blows out, bios'en need updating, Roms need flashing.....
All of which are below the OS level. With no os, you must have console (or remote console)
We have around 150-200 servers lying around. We're back there almost everyday with SOMETHING, be it an initial OS install, hardware failure, or routine maintance. A good KVM system gives you the win of "few monitors, many servers", and also provides remote access to the console for when you don't need to replace something (say, you need to debug a Sun at the eeprom level)
All of which fall into "when you need console access, nothing else will suffice".
As another poster said, you're solving a different problem. Remote manangement (aka a developer needs access to the box) is what PC Weasel is all about.
If you have more than 10 servers, are you planning on getting 10 monitors, 10 keyboards and 10 mice, one set for each server? It's a waste of money, it's a HUGE waste of space, and it can't be made to look professional.
A good KVM let's you throw 1 monitor and keyboard at a bunch of boxes. You don't NEED true console access often; however, when you need it, nothing else will suffice.
In a data center environment, you're going to need both remote management and KVM.
The real answer is to use server class hardware from a real supplier. Both Dell and Compaq have rather solid server offerings with hardware raid built in. No need to worry with MS's implementation. And if you're doing RAID 5, you really should be in hardware anyway, or performance will kill you.
If this is for home use, or for fun, then play all you want. But since you're paying for windows anyway, you might as well poney up for real hardware. Your life will be happier for it.
This guy doesn't seem to understand much of what he's talking about.
The most glaring clue is this:
For example, to swap two variables, the author used the non commented following line:
a ^= b ^= a ^= b;
This is a cool hack which does not belong to a professional product.
If you don't recognize this, you probably need to go back to school. It's fast, and it doesn't require a temp variable.
Any time you look at low level libraries, you're going to see things like this. They NEED speed. They NEED low memory impact. These things are going to get called in tight loops with a million iterations. Look at QT's code, and you'll see the same thing.
Also telling is the fact that he has nothing positive to say about MFC. I've run across some VERY talented developers, and while I haven't heard them singing MFC's praises, they do have some nice things to say. Advocacy really needs to show balance. Acknowledging MFC's strong points is important.
When he's talking about an add on library called 'codejack', he mentions that tab views are impossible in MFC, yet codejack provides it. Apparently it is NOT impossible in MFC then. It probably isn't a prebuilt widget for the developer to use (which is unfortunate, I'll admit)
QT is a good library, I have no doubt. But please learn how to find good things in other libraries. It will only make your code better. It will only make your advocacy better.
I guess the first question is:
Do you mind using windows for authentication?
You could use pam/radius or pam/ldap to talk from freebsd to windows, and do the login thing. You would have to use virtual mailboxes, and no real logins to the freebsd box. You probably want that last bit anyway. Webmail/imap can be good with this kind of setup.
Otherwise, AFAICT, you're going to have to force everyone to change their passwords. Best bet is to take a weekend. Friday, have everyone archive their email, and turn off exchange so incoming mail gets queued. Do your transition, and monday when they come in, they'll use webmail/pop/imap.
I know that, you know that, and Sprint Las Vegas now knows that.
How many other telcos do? That's my point.
No, the really funny bit is that this challenge/response list is now A PART OF PUBLIC RECORD. If (important if) it's true, phreaking could have quite the little renaissance.
Monday
Tuesday
Wednesday
Anything put out on the internet should have no important data on it. Period. No connections from the internet (aka untrusted aka hostle) should be allowed to the box with the real data, other than those which are PROVEN to be needed, and secure. So:
internet -> firewall(1) -> web server -> firewall(2) -> database
So, you have 2 firewalls. One internet facing, and one (idealy a different vendor) from the DMZ to the internal world.
Also, you can set up 2 houses for the data. One (the one that the internet can get access too by proxy) should only cache the recent data. Hourly, or nightly, it should then be put into another server, from which the accounting department can run bills. Then this box (for accounting) should have no allowed connection to the rest of the world, save from the accounting department.
Oh, and the important data should be then purged from the internet proxy accessable database.
On increadibly rare occasions, I have written a program or script that has worked 100% right, immediatly. At most, these have topped out at 100 lines or so.
:-)
I am always shocked when this happens, and usually dislocate my shoulder patting myself on the back when it does happen.
So, what exactly are the odds that something that is at least a million lines of code will work right the first time?
Good solution in a pinch, but that's what xargs was built for.
...... cqd cqe .... zzz
Say ls would give
aaa aab aac aad aae aaf
find . -print | xargs rm
would make a bunch of rm commands, exactly as long as would be permitted (either by line length, or argument numbers). So, instead of 1 rm per file, you have 1 rm per files. Much more effecient.
Deagol said: /bar ; tar xvf -"
tar cf - foo | ssh root@host "cd
Toast0 said:
why not use scp to copy the stuff instead of tar?
Tar's faster (for large scale directories). NOTE: This is on solaris that I did the following.
We have 1 website with a BLOODY STUPID design. Part of it is that 1 filesystem has 13 MILLION files in it. Some of the directories have 10 or 15 thousand files in them. The idiots should have used a proper database. This is one of the few times under solaris that I wished for reiserFS. Anyway I was tasked to copy this fs over to another box (website migration).
First time, tried rdist. 8 hours later, and about 20% complete, we tried something else (For grins, I did the same command later... rdist ended up taking 28 hours in total).
Second time, rcp. 28 hours again.
Third time, rsync. Took less time (about 10 hours).
Fourth time, tar over rsh. Took 4 hours.
Shlepping filesystems across machines with ssh and tar is really, really nice and quite fast. I highly recommend it.
The slight problem with this (not in this case though) is you have the expense of forking and killing a lot of processes (equal to the number of files +1 for the find). On the mv or cp case, you can't (easily) get around it, but if you were to do:
/usr/bin ; time find . -type f -exec ls {} \;' and got:
/usr/bin ; time find . -type f | xargs ls -1 ' and got:
/tmp (sticky bit will get wacked). The second finds all files that are executable by the user owner, and makes them executable to others too. The third finds what is readable to the user, and makes it readable too.
:-)
find . -type f -exec chmod 644 {} \;
vs
find . -type f | xargs chmod 644
you'll find that the second runs amazingly faster, since it will group a lot of the commands together into 1.
I did 'cd
find . -type f -exec ls {} \; 0.98s user 3.28s system 88% cpu 4.831 total
I did 'cd
find . -type f 0.00s user 0.02s system 31% cpu 0.063 total
xargs ls -1 0.03s user 0.04s system 74% cpu 0.094 total
That's a BIG difference, especially when you have a LOT of files.
(NOTE: if I did a bare 'ls' with the xargs, the output would be different due to the way xargs works (man xargs for more details). It may or may not make a difference depending on how you're using the output. If you're shleping the whole line at once, it could make a huge difference... if you're spliting the lines by $IFS or something, then it's probably alright.)
As for my contribution, I find these 3 find | xargs commands, wraped together in a script I call "makereadable" help me a LOT (for example, if you install from source, and the permissions get borked due to forgetting to set root's umask to 022):
find . -type d -print | xargs chmod 755
find . -type f -perm +0100 -print | xargs chmod go+x
find . -type f -perm +0200 -print | xargs chmod go+r
The first makes all directories 755. 99.99% of the time, that's what you want... just don't do it with
If you want to do this with write permissions, you're probably doing something stupid you will regret later. Figuring out the command to do this is then left as an exercise for the reader.
I'm not sure that I'd spin the story like that, especailly about the "linux buying out egcs.com".
Gcc seamed like it had been stagnant forever at the 2.7.* branch. If you look at the release history, you'll see that 2.7 was first released in June 95, and 2.7.2.3 was released in August of 97. Two years of point releases, with nothing new.
Well, some folks got tired of it, and forked the code. They made something called pgcc, which had more optimizations for the pentium (I) arch. Some of you may remember that the main distinction between redhat and the origional mandrake release was that Mandrake compiled all of redhat's packages with pgcc (except the kernel)
One thing led to another, and the pgcc fork got folded into the egcs versions. People were dismayed that there were 2 competing versions of gcc lying around but only one of them seemed to be moving: the egcs one. Egcs released version 1.*
Finally, the egcs and the gcc folks got to talking, and the egcs board became the gcc steering committee. If you look at the gcc release history, you'll see the egcs versions listed there too, because egcs became gcc 2.95.*
The gcc release history can be found at: http://gcc.gnu.org/releases.html
8. What did you think about the Intel Compiler v6 that came out recently? Did you have time to have a look at it?
Mark Mitchel: I do not have enough information about that compiler to comment on it.
I know that x86 is just 1 arch for gcc, however it is an important one, being the most common. I would think that those heavily involved with gcc (and especially the x86 backend) would be much more interested in how well the other compilers performed since they are 'the competition' as it were.
It's kind of depressing that he 'doesn't have enough information to comment'.
if intel's compiler had been released last month or thereabouts, I could understand, but IIRC, it was released about 6 months ago.
From the license:
You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose.
Stallman's point:
This prohibits modifications for private use, denying the users a basic right
I'm not 100% sure I see his point. If you make use of the code for any purpose, and Lucent asks you for the changes you made, you have to give it to them. IANAL, but it seems that they just want to be able to see all changes that get made.
The rest of RMS's points make sense, and this clause:
The licenses and rights granted under this Agreement shall terminate automatically if (i) You fail to comply with all of the terms and conditions herein; or (ii) You initiate or participate in any intellectual property action against Original Contributor and/or another Contributor.
is truly awful. See the link from Nathan Myers for a well written explanation of just how bad this is.
The eternal war. Given enough time, you can secure 1000 boxes (turn off all un-needed services for the application(s) that this box needs to run, apply all the patches to those apps, tune the OS tightly...) Takes quite a while.
Or (says the 3com salesperson) you can just spend some money. Central server says this box can only talk on this (short) port|protocol list. Everything else is droped at the interface, doesn't even get to the kernel.
Sure, there are things you can do on a large scale to make securing boxes much easier (jumpstart, kickstart, whatever NT calls it, to get a secure base install, etc), but you still have to deal with patching individual boxes.
If I have to deploy a lot of computers in an activly hostile environment, something like this would be very nice.
By definition, it's external, L3 cache (note that it's packaged within the CPU modules themselves Not another chip on the MB). From:
R C- III/USIIITech.html
http://www.sun.com/products/processors/UltraSPA
it's:
* L1-cache: 64 kB 4-way Data, 32 kB 4-way instruction, 2 kB prefetch, 2 kB Write
* L2-cache Tag RAM and controller on-chip to support 1, 2, or 8 MB external
* L2-cache data SRAMs
* Dedicated 256-bit data path for the L2-cache
When you get down to it, the high end chips actually do mirrored cache. So, it's really 16 megs, with parity error checking, mirrored.
Will it play quake well? Probably not. Will it kick butt in hard core dataset analysis? Heck yes.
Yes, I know. I thought I had the correct sequence of new keys in there, however, I had messed up a few of them, and because the first key was the eval key, it didn't fall through to the rest of them.
Had I been inteligent, I would have deleted the eval key at a point when I could test that everything would start normally. However, I didn't understand enough of how veritas worked at the time.
Oh well. Live and learn.
[poster1 said:]
1. 90 day or unlimited trial only with the stupid features turned off.
[poster2 replied:]
In other words, pretty much give it away for free. (90 days apart to uninstall/reinstall or in some cases reformat is not much of a pain in the ass.)
Better: In your registration code, encode the start and end dates of the evaluation. Encrypt and obfuscate it to the far-thee-well, and have done.
If someone's willing to keep the dates on they're computer out of sync, you'll not get money out of them anyway (since they're too small of a shop (or home) for you to bother with.
Though I must strongly agree with the poster who suggested sending email warnings about licenses expiring. Veritas NetBackup does the encode the date thing. We had paid for it, and I thought that I had put the keys in correctly. However, it just quit on me. Something one does NOT want to see in their enterprise backup solution...
Once I read the review, this was my exact question. However, it doesn't seem that Jabber has the promise of not loosing messages that persistant queue's in MQ can give you.
Soneone correct me if I'm wrong.
The promise not to loose a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).
This quote struck me as odd as well, but I got to thinking about it, and I think I see at least where he was going.
We geeks tend to be facinated by "the newest thing", and rush to try it, and then preach it's merits to anyone who will listen. I know I'm generalizing, and there are people still happily running 2.0 kernels, but look at the general trend. We don't mind using version 0.0.7b6 of products that are cool without thinking twice about it.
Once we learn something new, we tend to make great use of it. And we seem to think of little else. That's probably what he was aiming for in that quote.
And remember, he's knocking his own geeks too.
You're trolling, but I'll bite.
Sure, it's very interesting that Linux has a system interface that's so straightforward that it can be easily manipulated in sort-of-real-time by a simple scripting language
People have already pointed out the 'application firewall' use, and probably the fantastic debugging uses. It's not just interesting, it's dang useful. Think about how people could use it to chase down possible buffer overflows. Force the system to return something other than what your program expects. How does it respond? Gracefully? Die an ugly death? Maybe I should fix that... :-)
and i'm sure you have to be root to run it
Maybe not. So long as it's enabled in the kernel, you should be able to make use of it. strace and truss and their ilk have been doing the 'trace system calls' thing for years. This is just more powerful.
but somehow the fact that somebody's already put together something like this really makes me less confident about Linux, not more.
Already? I have no clue what you're talking about. Linux has been around for more than a decade. Python's been around for almost a decade too. Unix has been around in some form since the late 60's. Already in the 2.4 kernels? They've been around for more than a year.