There was a series of articles on Security Focus (which seems to be down ATM) recently on LIDS. Although it isn't really a comparison with anything else, it might give you an idea of what it can and can't do.
I had a friend who visited Thailand about 18 months ago. Apparently they use electronic calculators over there to haggle. The seller puts in the price he wants into the calculator, the (potential) buyer looks at it, presses clear and puts in the price he wants to pay. The seller will look aghast as if he's being robbed and probably put in a number slightly lower than his initial 'bid' and so things progress until either the buyer walks away or a deal is struck.
what you probably want for an animation lab is an SGI machine which is still what a lot of people use.
That said, Solaris isn't a bad skill to learn, and it might be worth playing around with for a learning experience. Bear in mind that an Ultra 60 will only be equivalent to something like a Pentium 600-ish (dependant on what kind of CPU or CPUs are installed) for most tasks unless its been optimised for a SPARC based architecture.
It certainly seems that for DVD drives, you're rather stuck with IDE; there are very few SCSI DVD reader reader drives, far less writers. This has left me with an IDE DVD drive while I have a SCSI CD-RW.
There's also a performance hit in having 2000+ files in one directory, at least in some filesystems (notably UFS in Solaris). As a result, having a packed directory means that it takes longer to find a file in that directory.
On the other hand, having a $PATH with a gazillion entries just makes for faster searches, but you have to perform more of them. If the application you want is early in the PATH, it will be faster than with the 2000+ files in/bin. If the app is in the last item in your PATH, it will be slower.
Re:good job mozilla, way to break everyone's stats
on
Mozilla 0.9.6 Released
·
· Score: 2
Yes, it caches them, at least for bookmarked sites. It's also a pain to get it to update them, as I discovered when I was working on my website.
FWIW, I actually like the icons; it gives me a visual clue to what I'm looking for in a list of 20 bookmarks/favourites.
Yup, the breaking of the numbering scheme was dumb, especially done at the last minute as it was (ISTR the announcement of the change was about 2-4 weeks before the release). However, while I can forgive '2.7' as it was called that during Beta, there has never been a Solaris 2.8.
Having never bothered that much with MU packs (I just tended to get the patches I needed individually) I dunno about bash appearing in one. If it did appear, I completely missed it and I've tended to find stuff like that on newsgroups. Solaris 7 wasn't too bad in any case; it was a heck of a lot better than 2.6 in any case (UFS logging, pkill, 64-bit kernel etc).
Yup, the/bin/usr/bin nitpick was probably being silly, but it was meant as a joke.
ksh is available on stock IRIX, AIX, Solaris and HP-UX. Even linux/FreeBSD can now have it for free after some fairly recent license loosening.
On the other hand, bash is standard on linux, FreeBSD and Solaris 8 (maybe even AIX 5L? haven't seen that yet). Hrm, let me see which is more widespread?:)
Personally I prefer zsh for interactive stuff and it's as good as bash/ksh for most scripting stuff. I say most, because otherwise someone will come back with some whiz-bang feature of bash/ksh to prove a point. Most of my scripting works fine in sh; that's the stock sh that comes with most versions of Unix, but then I don't do very much fancy stuff.
As others have pointed out, the quality was lowered to gain faster frame rates. However, you also say that "They just chose to optimize for the common case".
I'm not so sure Q3 is the common case, except in benchmarks. I believe the main reason Q3 is used is that there is a reproducable method of testing, done by running the demos. Other 3D games often don't have that feature, making it harder to do benchmarks. As Q3 is easy to benchmark, people use it as such even if Half-Life or UT are more common (Note: I have no idea which is most common).
The only time I ever led an open source project was for the Solaris plugin for XMMS. I got zero flames during the duration of doing it, and plenty compliments (thanks for writing this, etc). Other people came along with problems, but they were generally valid complaints. Very few people had stupid questions; those I just pointed to the FAQ.
Of course, mine was a fairly small project with less visibility, but I was still getting over 1000 downloads (as per the web logs) of each new version, so there were a significant number of users. Actually, the number of downloads helped give me a nice warm fuzzy feeling; "look at all these people using something I helped write!".
In the end, I passed control to the central XMMS team as I moved jobs and didn't have a SPARC at my desk. However, that was always my end goal, to have it in such a state that it could be integrated.
Beware of DIY security if you're angling for cheaper insurance. Some companies will only give this for approved installations by professionals, not some DIY geek... Nothing against you personally, but there's probably quite a few other numpties around who couldn't install a lock, far less a complex security system properly who would try to claim the discount. As such, your efforts would probably get lumped in with those.
As a general recommendation I heard once, your load average shouldn't get more that 2xnumber of CPUs. i.e. on a single CPU box, it shouldn't get higher than 2, for a 64-CPU high-powered server, it shouldn't get above 128.
I've found it a reasonably good guide to when there's an issue on Solaris boxes; I think linux uses similar numbers to calculate run queue averages, but other OS's (eg, IRIX) use different formulas to calcualte it so you might need to tweak this recommendation.
You don't have to use maildir; I used it fine with mbox style files.
One of the major problems with qmail is its author; his holier-than-thou attitude is a pain to deal with. Just try setting up anti-relay rules in a sane manner, for example; you need to patch it. In fact, there's an insane number of patches for qmail to get it to do things you need to.
Even if the serial stuff was written years ago, is that such a problem? What difference is there between a serial port 10 years ago and a serial port now? My guess is not a lot, other than perhaps faster baud rates, but I don't think even that has changed in about 5 years (how long have we had UART 16550?).
Worst case scenario, put all the serial code into one file and use functions like open_serial_socket(), read_serial_data which call the underlying OS functions. When you move to Unix, swap out the file for the new version.
Ok, I'll give you a counter-example. We've just installed an IBM server and there's a problem with a couple of bits in it (I won't give details as I don't know if I'll get into trouble for it...). As everything is IBM (hardware, OS and the software), we can get support on it to the extent that two groups in the US are working on ironing out the problem.
Would we have had this if the software package was from Sun? Well, Sun might have blamed IBM, IBM might have blamed Sun and we'd be left with something which doesn't work. We've been lucky in that IBM want this to work to secure future business, and that is the carrot you can use to 'bribe' vendors to fix bugs.
While open source allows you to track down the bugs and fix them yourself, it relies on you hiring programmers and/or smart admins. Many companies don't want to do that, particularly when you can get the people who wrote the code to fix it (whether you can get them to fix it or not is a different matter; managers' perception is that you can and that's what affects buying decisions).
As for suing, it depends on the terms of the contract. A large enough business should be able to negotiate special terms with vendors to secure business (don't play ball with us, you don't get our money). If a company wants to be bullish enough, it can negotiate terms that do allow it to sue the company, even with UCITA and DCMA. Unless I'm mistaken, those acts mean that vendors are allowed to put horrible restrictions on sale of software etc. It doesn't say that individual purchasers can't negotiate a better deal.
One final point. I'm not saying this to say "linux is doomed, it's never going to make it". I have great hopes for linux (in my last job, I made a lot of use of open source software to good effect), but there are still a few things to be ironed out before big companies are going to adopt it in a large scale. Half of what I'm doing here is playing devil's advocate because I like a good argument (NB: argument != flame-fest!).
Certainly what I've found is that there's a momentum in whatever platform is currently in use. I've been trying to persuade someone to move from IBM to Sun for their Oracle DB since the new V880 is a damn good deal and would fit their needs. However, I detected a certain reluctance to move from an IBM solution as that's what their systems are now.
Aside from this, much of the main databases (including almost all the mission critical stuff) here are on HP systems. Despite HP's uncertain future (having ditched PA-RISC), I doubt they'll move from HP in the near future.
Now take this reluctance to move between mainstream Unix vendors and apply this to linux, the upstart on the block. Quite aside from the "free" nature of linux and perceived lack of accountability, there's a further issue. Even when sticking with mainstream ventors, there's a reluctance to mix vendors; i.e. there's a desire to use IBM software on an AIX box, simply to avoid the finger pointing that can ensue. IBM have even had ad campaigns based on this. There's a certain comfort factor in knowing that you can go to one vendor and say "fix this" which you don't get with linux on Intel. IBM, HP and Sun all make the hardware and OS; you don't get that with linux (with the potential exception of some IBM kit like the S/390).
To get over this, there need to be vendors willing to support the software and hardware side of a linux solution. Hopefully IBM will pave the way with things like S/390 and the zSeries server.
Slashdot Mirror
Yes, I'm replying to my own post. SF is back up, and here's the index of IDS stuff, including the LIDS articles.
There was a series of articles on Security Focus (which seems to be down ATM) recently on LIDS. Although it isn't really a comparison with anything else, it might give you an idea of what it can and can't do.
See this story over at the Register
The unfortunate side-effect is that you might get locked up for dealing an illegal substance...
BTW, this nugget is in the Netcraft FAQ
A 19" monitor probably equates to 17.5 - 18" viewable; a 21" LCD is 21" viewable, which is what many people forget.
I had a friend who visited Thailand about 18 months ago. Apparently they use electronic calculators over there to haggle. The seller puts in the price he wants into the calculator, the (potential) buyer looks at it, presses clear and puts in the price he wants to pay. The seller will look aghast as if he's being robbed and probably put in a number slightly lower than his initial 'bid' and so things progress until either the buyer walks away or a deal is struck.
Mebbe they really needed a v880 or summat before they started getting posted on /. :)
What? You mean you don't have a computer in the toilet for browsing the web while on your porcelain throne?
That said, Solaris isn't a bad skill to learn, and it might be worth playing around with for a learning experience. Bear in mind that an Ultra 60 will only be equivalent to something like a Pentium 600-ish (dependant on what kind of CPU or CPUs are installed) for most tasks unless its been optimised for a SPARC based architecture.
It certainly seems that for DVD drives, you're rather stuck with IDE; there are very few SCSI DVD reader reader drives, far less writers. This has left me with an IDE DVD drive while I have a SCSI CD-RW.
On the other hand, having a $PATH with a gazillion entries just makes for faster searches, but you have to perform more of them. If the application you want is early in the PATH, it will be faster than with the 2000+ files in /bin. If the app is in the last item in your PATH, it will be slower.
FWIW, I actually like the icons; it gives me a visual clue to what I'm looking for in a list of 20 bookmarks/favourites.
Yup, the breaking of the numbering scheme was dumb, especially done at the last minute as it was (ISTR the announcement of the change was about 2-4 weeks before the release). However, while I can forgive '2.7' as it was called that during Beta, there has never been a Solaris 2.8.
Having never bothered that much with MU packs (I just tended to get the patches I needed individually) I dunno about bash appearing in one. If it did appear, I completely missed it and I've tended to find stuff like that on newsgroups. Solaris 7 wasn't too bad in any case; it was a heck of a lot better than 2.6 in any case (UFS logging, pkill, 64-bit kernel etc).
Yup, the /bin /usr/bin nitpick was probably being silly, but it was meant as a joke.
On the other hand, bash is standard on linux, FreeBSD and Solaris 8 (maybe even AIX 5L? haven't seen that yet). Hrm, let me see which is more widespread? :)
Personally I prefer zsh for interactive stuff and it's as good as bash/ksh for most scripting stuff. I say most, because otherwise someone will come back with some whiz-bang feature of bash/ksh to prove a point. Most of my scripting works fine in sh; that's the stock sh that comes with most versions of Unix, but then I don't do very much fancy stuff.
- There is no such thing as Solaris 2.8, and 2.7 only exists in some places. I assume you meant 7 and 8.
- bash was only introduced into Solaris as of Solaris 8 along with zsh, apache, gzip and some other GPL stuff.
- /bin is actually a symlink to
/usr/bin, so technically it doesn't put it under /bin
Oops, better put on the asbestos nowI'm not so sure Q3 is the common case, except in benchmarks. I believe the main reason Q3 is used is that there is a reproducable method of testing, done by running the demos. Other 3D games often don't have that feature, making it harder to do benchmarks. As Q3 is easy to benchmark, people use it as such even if Half-Life or UT are more common (Note: I have no idea which is most common).
Of course, mine was a fairly small project with less visibility, but I was still getting over 1000 downloads (as per the web logs) of each new version, so there were a significant number of users. Actually, the number of downloads helped give me a nice warm fuzzy feeling; "look at all these people using something I helped write!".
In the end, I passed control to the central XMMS team as I moved jobs and didn't have a SPARC at my desk. However, that was always my end goal, to have it in such a state that it could be integrated.
Beware of DIY security if you're angling for cheaper insurance. Some companies will only give this for approved installations by professionals, not some DIY geek... Nothing against you personally, but there's probably quite a few other numpties around who couldn't install a lock, far less a complex security system properly who would try to claim the discount. As such, your efforts would probably get lumped in with those.
- Always accept mail to a certain domain (i.e. the local domain for staff/students)
- Allow machines within our local network to relay mail to the outside world
- Not allow external sites to relay mail to other outside sites
I'm pretty sure that I couldn't get 2 and 3 working together without the 'relayclients' patch.I've found it a reasonably good guide to when there's an issue on Solaris boxes; I think linux uses similar numbers to calculate run queue averages, but other OS's (eg, IRIX) use different formulas to calcualte it so you might need to tweak this recommendation.
One of the major problems with qmail is its author; his holier-than-thou attitude is a pain to deal with. Just try setting up anti-relay rules in a sane manner, for example; you need to patch it. In fact, there's an insane number of patches for qmail to get it to do things you need to.
Worst case scenario, put all the serial code into one file and use functions like open_serial_socket(), read_serial_data which call the underlying OS functions. When you move to Unix, swap out the file for the new version.
Would we have had this if the software package was from Sun? Well, Sun might have blamed IBM, IBM might have blamed Sun and we'd be left with something which doesn't work. We've been lucky in that IBM want this to work to secure future business, and that is the carrot you can use to 'bribe' vendors to fix bugs.
While open source allows you to track down the bugs and fix them yourself, it relies on you hiring programmers and/or smart admins. Many companies don't want to do that, particularly when you can get the people who wrote the code to fix it (whether you can get them to fix it or not is a different matter; managers' perception is that you can and that's what affects buying decisions).
As for suing, it depends on the terms of the contract. A large enough business should be able to negotiate special terms with vendors to secure business (don't play ball with us, you don't get our money). If a company wants to be bullish enough, it can negotiate terms that do allow it to sue the company, even with UCITA and DCMA. Unless I'm mistaken, those acts mean that vendors are allowed to put horrible restrictions on sale of software etc. It doesn't say that individual purchasers can't negotiate a better deal.
One final point. I'm not saying this to say "linux is doomed, it's never going to make it". I have great hopes for linux (in my last job, I made a lot of use of open source software to good effect), but there are still a few things to be ironed out before big companies are going to adopt it in a large scale. Half of what I'm doing here is playing devil's advocate because I like a good argument (NB: argument != flame-fest!).
Aside from this, much of the main databases (including almost all the mission critical stuff) here are on HP systems. Despite HP's uncertain future (having ditched PA-RISC), I doubt they'll move from HP in the near future.
Now take this reluctance to move between mainstream Unix vendors and apply this to linux, the upstart on the block. Quite aside from the "free" nature of linux and perceived lack of accountability, there's a further issue. Even when sticking with mainstream ventors, there's a reluctance to mix vendors; i.e. there's a desire to use IBM software on an AIX box, simply to avoid the finger pointing that can ensue. IBM have even had ad campaigns based on this. There's a certain comfort factor in knowing that you can go to one vendor and say "fix this" which you don't get with linux on Intel. IBM, HP and Sun all make the hardware and OS; you don't get that with linux (with the potential exception of some IBM kit like the S/390).
To get over this, there need to be vendors willing to support the software and hardware side of a linux solution. Hopefully IBM will pave the way with things like S/390 and the zSeries server.