That would be what we call "anecdote". I can counter by talking about having thirty or so web servers at work running pretty close to capacity (especially during peak times) but it would be pointless. Neither of us have presented anything that would suggest our experience is the common case.
Eh? The Via offerings are a wildly different market segment from the Intel. Bare minimum buy-in cost for a desktop solution is going to be over $300, and that's for a cheap motherboard and absolute bottom barrel Celeron M. You can pick up a full Via solution for around $100, including board, chip, case, and integrated everything - video, tv out, firewire, ethernet, blah blah blah.
And that's just looking at the desktop offering. Via hands Intel it's ass on a platter for embedded solutions. Not only are Intel's Ultra Low Voltage solutions more expensive, they draw more power. A 600MHz Celeron ULV draws 7V typical. A 1GBz Eden-N draws 7W peak.
Who said anything about having sued anyone? And the trademark is on "Fedora", not "Fedora Red Hat". They don't use "Fedora Red Hat" anywhere.
In the future, you might consider actually fact-checking before responding. It's easy enough to go to fedora.redhat.com and scroll down to the bottom of the page and read: "Fedora is a trademark of Red Hat, Inc". Likewise, it's only slightly more difficult to click on "Trademark Guidelines" and discover that Red Hat does, in fact, have specific guidelines they expect you to follow in order to use their trademarks.
They do have a history of protecting their marks, as well. Earliest case I can recall was their warning to Cheap Bytes which resulted in "Pink Tie" linux, and more recently those to CentOS.
I read his site five years ago, when he first announced his "amazing" technology. I also read the analysis of real security experts who examined the so-called nanoprobes, and found nothing but packets assembled by a consumate bullshit artist.
But hey, what can you expect from a project that he's been "working full time on" for five years and still hasn't hit the promised pre-release testing.
It's not a problem of knowing what has changed, it's how, when, and why that are important. Especially when you're dealing with an already forked codebase.
If by "build" you mean blindly accept defaults on virtually everything, and maybe turn on an option or two that someone on a chat group or website said you should, sure.
Having the know how to do a proper kernel build? Not so simple.
That's great if you happen to want one of their five formfactors (12" or 14" iBook, 12" 15" or 17" Powerbook). You're fucked if you want an ultra portable. Or a decent screen resolution, for that matter. WXGA on the 15" and WXGA+ on the 17"?? Those are the value options from Dell.
GP's point was that they didn't make anything. They took an existing product (i.e. Linux) and started to support it. I realize there's much more to it than that, but they essentially do support.
My point is that "Linux" is not a product. Though Red Hat didn't write all portions of their operating system, they did productize it.
Thanks for the info, I didn't know that. Nonetheless, the above point stands: Mandriva didn't make anything.
Same concept as above. Think of the source code as raw materials, because that's essentially all it is.
GP's point still stands: do you think that Sun cares what hardware you run Solaris x86 on? Of course they do. They want you to buy it from them, because they can't make any money from selling just the OS. (Of course, they can't make money doing anything, but that's another discussion)
Just the OS? Of course not, since they're licensing it free. On the other hand, the support business is incredibly lucrative, and is becoming an increasing proportion of their total revenue. The added revenue from a hardware sale is nice, but I seriously doubt they'll be turning down service contracts on third party hardware any time soon.
I was going for snarky, actually. Fact of the matter is that kernel updates are rarely necessitated at all, whereas applications and librarys have a high turnover rate. The sharp readers might note that the "statically compiled binary" suggestion could only be meant tognue in cheek not only because that ignores support files (man pages, config files, blah, blah) but also because in the event of a library update, it would increase the workload.
I've built all of two kernels in the last three years, all because of hardware support not in the vendor provided kernel. (For platform stability reasons we're using a fairly distribution as our base, so new hardware support isn't a priority from the vendor's point of view.)
Even then it's rebuilding one kernel used across a hundred machines, so it's not that much effort.
The main concern there is that technically exploit code can be inserted into the running kernel. Usually this is done to avoid detection - e.g. it causes the kernel not to report all processes or to hide certain files. This is actually just a variation of an old trick - exploits would often try to cover their tracks by dropping modified binarires in place to do the obfuscation. At minimum ls and ps.
The simpler approach has it's flaws though - the md5s on the binaries don't match. Alternate programs/will/ show the data ("echo *" in the directory, for example, will show the "hidden" files0. Hence the attraction of kernel modules, where the actual system calls can be modified.
Of course to get that far, the machine needs to be compromised in the first place. So the best initial defense is to keep on top of general security advisories, avoid running unnecessary daemons, and firewall any ports that you're not using. If it's an option, I always suggest doing remote logging to another machine, so even if local logs are modified you have a record of what's done.
There are also several good tools that will detect the majority of the LKM enhanced rootkits. Frankly, most "hacks" are done by stupid kids running scripts they found on "h4x0r" newsgroups. So even checking for the two or three most common ones is enough to catch the vast majority of cases.
Beyond that, something as simple as not having a compiler available on the box will stymie some portion of attacks. Believe it or not I've done forensics on boxes where they didn't seem to realize they could turn off the version check on the module.
Finally, as a proper Modern solution, you can put an SELinux or LIDS policy in place to disable module loading after initialization. This will prevent dynamic loading for plug and play hardware, but in a server environment it's a reasonable tradeoff. (It may even be possible to allow module loading from a console user but not a remote user, but i've never looked into it because, frankly, I don't care. I don't professionally support desktops, and the level of risk LKM's represent to be too low to bother with at home. If someone manages to get past my firewall, the iptables rules on the machine itself, and find a root exploit, having a static kernel is the least of my worries.
Ummm.. you don't need to recompile a module to turn off pcmcia or bluetooth./sbin/chkconfig pcmcia off/sbin/chkconfig bluetooth off
There's also a GUI tool for this. For that matter, you could not select those services to start in the first place. There's a dialog for it in the installer.
Slashdot Mirror
That would be what we call "anecdote". I can counter by talking about having thirty or so web servers at work running pretty close to capacity (especially during peak times) but it would be pointless. Neither of us have presented anything that would suggest our experience is the common case.
Nice generalization. Do you have anything to back that up other than anecdote and conjecture?
If you go down for a minute every day, but only for a minute, will anyone care?
For those of us with service level agreements? YES. HELL YES.
RHEL 4.0 was released on February 14th.
Typo. :) It'd be kind of daft to sell an "ultra low voltage" chip that draws 7V. It's 7W at 1.004V.
Take a look at the Asus Terminator C3 - $112 and they throw in a CD-ROM and floppy as well. Toss in a 512MB DIMM and a 40GB 7200RPM drive and you've got a system for around $200.
Eh? The Via offerings are a wildly different market segment from the Intel. Bare minimum buy-in cost for a desktop solution is going to be over $300, and that's for a cheap motherboard and absolute bottom barrel Celeron M. You can pick up a full Via solution for around $100, including board, chip, case, and integrated everything - video, tv out, firewire, ethernet, blah blah blah.
And that's just looking at the desktop offering. Via hands Intel it's ass on a platter for embedded solutions. Not only are Intel's Ultra Low Voltage solutions more expensive, they draw more power. A 600MHz Celeron ULV draws 7V typical. A 1GBz Eden-N draws 7W peak.
Who said anything about having sued anyone? And the trademark is on "Fedora", not "Fedora Red Hat". They don't use "Fedora Red Hat" anywhere.
In the future, you might consider actually fact-checking before responding. It's easy enough to go to fedora.redhat.com and scroll down to the bottom of the page and read: "Fedora is a trademark of Red Hat, Inc". Likewise, it's only slightly more difficult to click on "Trademark Guidelines" and discover that Red Hat does, in fact, have specific guidelines they expect you to follow in order to use their trademarks.
They do have a history of protecting their marks, as well. Earliest case I can recall was their warning to Cheap Bytes which resulted in "Pink Tie" linux, and more recently those to CentOS.
"This lawsuit is a load of codswallop," said Mr. Young. "Nobody and no company should have the exclusive use of the word 'tiger.'"
A company should however have the exclusive use of, say, the word 'fedora'.
Frankly, even though Tiger has always struck me as a vaguely sleazy company, they do have something of a point.
Ummm... Go actually price LCDs. You can get a basic 15" for $150. Dell regularly does a free upgrade to LCD as a promotion.
There's still a price premium, but it's a lot lower now.
I read his site five years ago, when he first announced his "amazing" technology. I also read the analysis of real security experts who examined the so-called nanoprobes, and found nothing but packets assembled by a consumate bullshit artist.
But hey, what can you expect from a project that he's been "working full time on" for five years and still hasn't hit the promised pre-release testing.
It's not a problem of knowing what has changed, it's how, when, and why that are important. Especially when you're dealing with an already forked codebase.
If by "build" you mean blindly accept defaults on virtually everything, and maybe turn on an option or two that someone on a chat group or website said you should, sure.
Having the know how to do a proper kernel build? Not so simple.
Woo, malformed SYN packets. Cool technology there.
That's great if you happen to want one of their five formfactors (12" or 14" iBook, 12" 15" or 17" Powerbook). You're fucked if you want an ultra portable. Or a decent screen resolution, for that matter. WXGA on the 15" and WXGA+ on the 17"?? Those are the value options from Dell.
If I were you, I'd have done find . -name \*.c | xargs cat | wc -l. That'd avoid getting back "Argument list too long" if there'd been more files. :)
GP's point was that they didn't make anything. They took an existing product (i.e. Linux) and started to support it. I realize there's much more to it than that, but they essentially do support.
My point is that "Linux" is not a product. Though Red Hat didn't write all portions of their operating system, they did productize it.
Thanks for the info, I didn't know that. Nonetheless, the above point stands: Mandriva didn't make anything.
Same concept as above. Think of the source code as raw materials, because that's essentially all it is.
GP's point still stands: do you think that Sun cares what hardware you run Solaris x86 on? Of course they do. They want you to buy it from them, because they can't make any money from selling just the OS. (Of course, they can't make money doing anything, but that's another discussion)
Just the OS? Of course not, since they're licensing it free. On the other hand, the support business is incredibly lucrative, and is becoming an increasing proportion of their total revenue. The added revenue from a hardware sale is nice, but I seriously doubt they'll be turning down service contracts on third party hardware any time soon.
I'd rather see a stable module interface. :) And yes, binary drivers. (With source available.)
Oh, I'm sure 80 years down everyone will build their kernels from scratch, just like people today build their own engines for their cars.
I was going for snarky, actually. Fact of the matter is that kernel updates are rarely necessitated at all, whereas applications and librarys have a high turnover rate. The sharp readers might note that the "statically compiled binary" suggestion could only be meant tognue in cheek not only because that ignores support files (man pages, config files, blah, blah) but also because in the event of a library update, it would increase the workload.
Ergh, that many machines even.
I've built all of two kernels in the last three years, all because of hardware support not in the vendor provided kernel. (For platform stability reasons we're using a fairly distribution as our base, so new hardware support isn't a priority from the vendor's point of view.)
Even then it's rebuilding one kernel used across a hundred machines, so it's not that much effort.
The main concern there is that technically exploit code can be inserted into the running kernel. Usually this is done to avoid detection - e.g. it causes the kernel not to report all processes or to hide certain files. This is actually just a variation of an old trick - exploits would often try to cover their tracks by dropping modified binarires in place to do the obfuscation. At minimum ls and ps.
/will/ show the data ("echo *" in the directory, for example, will show the "hidden" files0. Hence the attraction of kernel modules, where the actual system calls can be modified.
The simpler approach has it's flaws though - the md5s on the binaries don't match. Alternate programs
Of course to get that far, the machine needs to be compromised in the first place. So the best initial defense is to keep on top of general security advisories, avoid running unnecessary daemons, and firewall any ports that you're not using. If it's an option, I always suggest doing remote logging to another machine, so even if local logs are modified you have a record of what's done.
There are also several good tools that will detect the majority of the LKM enhanced rootkits. Frankly, most "hacks" are done by stupid kids running scripts they found on "h4x0r" newsgroups. So even checking for the two or three most common ones is enough to catch the vast majority of cases.
Beyond that, something as simple as not having a compiler available on the box will stymie some portion of attacks. Believe it or not I've done forensics on boxes where they didn't seem to realize they could turn off the version check on the module.
Finally, as a proper Modern solution, you can put an SELinux or LIDS policy in place to disable module loading after initialization. This will prevent dynamic loading for plug and play hardware, but in a server environment it's a reasonable tradeoff. (It may even be possible to allow module loading from a console user but not a remote user, but i've never looked into it because, frankly, I don't care. I don't professionally support desktops, and the level of risk LKM's represent to be too low to bother with at home. If someone manages to get past my firewall, the iptables rules on the machine itself, and find a root exploit, having a static kernel is the least of my worries.
If you've got that machine machines, and you don't have a simple package upgrade mechanism, I really really pity you.
:P
Do you statically compile every binary on your system as well, to avoid having to roll out a "distribution of files" for application updates?
Ummm.. you don't need to recompile a module to turn off pcmcia or bluetooth. /sbin/chkconfig pcmcia off /sbin/chkconfig bluetooth off
There's also a GUI tool for this. For that matter, you could not select those services to start in the first place. There's a dialog for it in the installer.