We just got in some multi-million dollar SANS from HP and they threw in a bunch of dual Xeon 3.2 GHz w/HT, 2GB, 136GB U320 Raid 5 Linux servers. HP has Open Source drivers for the Gig cards and even drivers/software for thier HP Lights Out management app for the Linux servers. With Dell you don't get any of that.
Actually, last year we bought a bunch of Dell PowerEdge 2650s with RedHat 9 (and then had to purchase RHEL only six months later because of that end of life bullshit...but that's another story).
Anyway, Dell has a really good installer that asks a couple of questions, then installs RedHat with all the right options for the hardware, including Dell's drivers for their gigabit ethernet card and RAID 5 config. It even included a custom hardware PNP lookup file with identifiers for all the components in the server that aren't in the standard distro.
Dell also have their management interface for linux, which does everything the windows version does.
I was quite impressed with Dell (Not so much with RedHat over that end of life thing)
I also find Google's web and usenet search invaluable to my MS solution searching.
Those not-so-helpful error messages like 'Application error C05482375' you find in the Event Log are great when pumped into Google. Good signal-to-noise ratio with searches like 'C05482375':-)
And be helpful to others and reply to posts, even if they are two years old. Chances are there's 200 other sysadmins with your problem, too.
A major reason for case sensitivity is when naming classes and instances of classes.
A common convention in Java and PHP is to name classes beginning with a capital letter, but name instances of classes beginning with a lowercase letter.
For instance: FooBar is a class, but fooBar is an instance of a class. In general, conventions make code easier to read, and case sensitivity is required for this convention.
Another convention I like is stubblyCaps, although you don't strictly need case sensitivity for that one.
Of course, some conventions are just plain dumb - like that hungarian notation of Microsoft, where they prefix their variables by its type. I thought that was good for a while, but then I had to change a variable's type one day...damn.
Anyway, for my money, I like the precision of case sensitivity. And a good IDE makes it painless.
Has anyone ever thought about the possibility that a Caldera employee put offending code into the kernel source *intentionally* as part of a long-term business strategy to later sue Linux users?
Disclaimer: I'm no laywer...but probably neither are you.
The parent post is the first truly "insightful" post on this topic.
Rather than trying to pass judgement on SCO (that's the Judge's job, anyway), the original post and the parent post both urge us to look at this case differently - lets mitigate the risk that SCO might have something.
Lets hear some discussion on things more pertinent to the original poster's comments.
Things like: - what amount of history does the kernel CVS tree have? - has anyone analysed it with regard to SCO? - which contributors work for IBM? Are they the most likely suspects if a breech has occurred? - etc.
I don't mean to be disrespectful to any of the kernel development team that have built a fantastic product. I'm just being pragmatic, as is the original poster.
I had a CompactFlash card and digital camera in my carry-on luggage in Europe last year, and it came out fine after being through lots of airports in the region.
However, at the end of my trip I put the cards and camera into my check-in luggage, which was scanned at Vienna airport. At the end of that leg of the trip (Melbourne, Australia) my CF card was permanently destroyed.
The patent Automated Sales and Service System contains a sentance that states:
"Organizational hierarchies of data sources are arranged so that an infinite number of sales presentation configurations can be created".
As long as you can ensure your site can't deliver an infinite number of combinations, perhaps you're not in breech after all...
Slashdot Mirror
Actually, last year we bought a bunch of Dell PowerEdge 2650s with RedHat 9 (and then had to purchase RHEL only six months later because of that end of life bullshit...but that's another story).
Anyway, Dell has a really good installer that asks a couple of questions, then installs RedHat with all the right options for the hardware, including Dell's drivers for their gigabit ethernet card and RAID 5 config. It even included a custom hardware PNP lookup file with identifiers for all the components in the server that aren't in the standard distro.
Dell also have their management interface for linux, which does everything the windows version does.
I was quite impressed with Dell (Not so much with RedHat over that end of life thing)
I also find Google's web and usenet search invaluable to my MS solution searching.
:-)
Those not-so-helpful error messages like 'Application error C05482375' you find in the Event Log are great when pumped into Google. Good signal-to-noise ratio with searches like 'C05482375'
And be helpful to others and reply to posts, even if they are two years old. Chances are there's 200 other sysadmins with your problem, too.
A major reason for case sensitivity is when naming classes and instances of classes.
A common convention in Java and PHP is to name classes beginning with a capital letter, but name instances of classes beginning with a lowercase letter.
For instance: FooBar is a class, but fooBar is an instance of a class. In general, conventions make code easier to read, and case sensitivity is required for this convention.
Another convention I like is stubblyCaps, although you don't strictly need case sensitivity for that one.
Of course, some conventions are just plain dumb - like that hungarian notation of Microsoft, where they prefix their variables by its type. I thought that was good for a while, but then I had to change a variable's type one day...damn.
Anyway, for my money, I like the precision of case sensitivity. And a good IDE makes it painless.
I found that this classic works wonders.
Why? Because it's funny. My GF doesn't get my first person shooters, simulators or strategy games. But she like cartoons.
Everyone I've shown loves it, even though it does have chunky graphics for these days.
Go the tentacle!
Yeah, and we can make a reality-TV show out of it. Better still, why don't we just send those Americon/Australian/World Idol contestants?
Has anyone ever thought about the possibility that a Caldera employee put offending code into the kernel source *intentionally* as part of a long-term business strategy to later sue Linux users?
Disclaimer: I'm no laywer...but probably neither are you.
The parent post is the first truly "insightful" post on this topic.
Rather than trying to pass judgement on SCO (that's the Judge's job, anyway), the original post and the parent post both urge us to look at this case differently - lets mitigate the risk that SCO might have something.
Lets hear some discussion on things more pertinent to the original poster's comments.
Things like:
- what amount of history does the kernel CVS tree have?
- has anyone analysed it with regard to SCO?
- which contributors work for IBM? Are they the most likely suspects if a breech has occurred?
- etc.
I don't mean to be disrespectful to any of the kernel development team that have built a fantastic product. I'm just being pragmatic, as is the original poster.
I had a CompactFlash card and digital camera in my carry-on luggage in Europe last year, and it came out fine after being through lots of airports in the region.
However, at the end of my trip I put the cards and camera into my check-in luggage, which was scanned at Vienna airport. At the end of that leg of the trip (Melbourne, Australia) my CF card was permanently destroyed.
The patent Automated Sales and Service System contains a sentance that states: "Organizational hierarchies of data sources are arranged so that an infinite number of sales presentation configurations can be created". As long as you can ensure your site can't deliver an infinite number of combinations, perhaps you're not in breech after all...