Leaving the car out there as a tempting target doesn't constitute entrapment. Even having an officer in plain clothes tipping likely thieves off to the fact that the car is easily stolen doesn't count.
I cannot dispute that they have many many talented people working at IBM. I, however, do think that its a negative development that two monoliths are producing their own versions of Linux, if its more than just a branding they run the risk of forking.
Possible, but not likely. The only place there's a real difference between platforms is down a few subtrees in the kernel source. With the exception of the C compiler (which has to be tuned per processor) and a few utilities that are specific to one platform (such as hwclock), everything else can be identical. Name it: emacs, grep, Apache, perl, etc. all come from the same set of sources on every flavor of Linux and a number of other OSes, too. If Apache forks, that's a problem for the Apache community, not the Linux community.
Besides, on the basis of percentage of code developed in-house, RH is just a branding, too.
Besides, there were already working versions of Redhat and I think at least one other distro and now that revenue stream will be gone for those companies. No one will elect to use Redhat's OS/390 version of Linux over IBM's.
I'll give you three guesses who did most of the work getting the kernel to run on the 390 (three letters, very close to H-A-L). If the distributors have their acts together, then their build process is fully automated and retargeting on a platform shouldn't be much more than telling the C compiler what CPU it'll be cross-compiling to.
Its kinda like how ma and pop organizations are effected when a Walmart comes to town.
That's a whole different ball of wax. Wal Mart and mom-and-pop shops sell the exact same roll of toilet paper sold to them by a third party. Wal Mart's advantage is that it buys them in such huge quantities that it gets a deep discount that the M-and-P shops can't match. IBM actually engineers and manufactures products, and for someone to buy any flavor of 390 Linux, IBM must get another of its machines out into the world.
That's not the case for RH, who manufactures a product that runs on commodity Intel boxes which are made by thousands of different manufacturers.
RH is actually has a competitive advantage here because they can adapt their product to any platform they see as being ubiquitous enough to be a commodity and therefore a good revenue stream with comparatively minimal effort compared to what a hardware vendor must do before a new platform sees the light of day.
Don't forget IBM also makes many other architectures, and can stake a claim to having unique insight into everything from the AS/400 down to PowerPC systems, I do not see that as a valid excuse for attempting to crush every other vendor in these areas.
The Intel PC is in IBM's product line, too, but you'll notice that they don't sell an IBM-branded Linux for that, either. If IBM's distributions of Linux for their own products superior to anything else, why shouldn't they win? Nobody screamed bloody murder when HP jumped on the bandwagon.
RH is arguably the most successful shrink-wrapped Linux for Intel on the planet, but I hear very little hew and cry about the small distributors who've gone tits up because of that success.
Lots of times the big guys win, and every once in awhile one of the little guys does something great that propels them into being big. Sun started its life as one of the little guys, too.
Its not all bad news, it does mean that linux has come of age in the enterprise server world.
Yes, it does. And that coming of age means big businesses like IBM, Sun, HP and others will get involved. But it's a free market, and that's how the free market works.
A 1000 processor Cray T3E 1200 would smoke your pathetic little mainframe:)
In some applications, yes, I couldn't agree with you more. Mainframes suck eggs when it comes to number crunching, but even a small mainframe will blow the doors off any supercomputer when it comes to I/O intensive applications such as databases.
The alarming thing is that they are producing their OWN version of Linux, not using Redhat or another company.
IBM has more in-house OS talent in its pinky than any of the Linux distributors. They know the most about their hardware. So why farm it out to some other vendor who's not likely to have a clue about how to make the OS run on their own platform? (And this is a platform thing. Don't assume the z800 is a big box that's binary-compatible with the x86, because it isn't.)
It pizzes me off to no end that people have completely forgotten that the whole purpose of an operating system is to provide a consistent API for software to bang against regardless of what hardware it's running on. If IBM's Linux for the 390 provides a properly-functioning interface identical to that provided by every other flavor of Linux, the whole recertification argument becomes a moot point. If something like Apache builds and runs properly on RH for x86, there's no reason it shouldn't on IBM for the 390.
If the article is correct, then the z800's running zVM emulate Intel x86 architecture in order to run Linux. Heck, even poorly written native compiled code generally has advantages over such a set up.
That's not what IBM is doing at all. The version of Linux that runs on the 390 platform is natively compiled for that system and has been tuned to work with it. This is no different than Linux on any of the dozen or so other platforms it's been designed to run on.
Sun's FUD-slinger got his facts wrong more than half the time in that article, which in most places would get him grade of "F". I've been using and buying Suns for 16 years, and while I really like their products, I hope IBM takes every opportunity to point out what a nitwit he is.
The moral: Just 'cause it says "Linux" on the label doesn't mean it's running on an x86.
Wow! That's a lot more then the EOS-1V...wait that's MSRP, what is the street price?
Haven't priced one, but I think they run about $2,000. On both the F5 (2000/3350) and the 1V (1800/2900), the MSRP is about 65% higher than the street price. So both Nikon and Canon have an overinflated sense of what their products are worth.
Nice camera, pity I can't fit my lenses on it:-) Had one the last place I worked, used it for a few hours, very very nice.
The SAE has a standard called J1850 that integrates all communications between all of the controllers in the car onto a bus that runs over a single piece of copper wire. Saves a huge amount of wire and allows the bus to go all sorts of places you could never dream of reaching with fiber.
What that means is that if the manufacturer wants the remote keyless entry system to be able to start the engine, it's a software upgrade. The Blrflmobile (a 300M) runs on J1850 and has had a couple of software upgrades to improve the air conditioner and other things. When else in history have you been able to benefit from engineering improvements in your care after you've driven it off the lot?
We don't actually administer our routers? Our company has some contract through UUnet and the router is actually property of UUnet we don't even have the password to get in and administer it.
Number one rule of good security: If you have no control over it, assume it's potentially hostile. Number two rule of good security: If you have control over it, assume it's potentially hostile. In short, add one of your own routers directly behind it.
So if it's comprimised, the blame should be placed on UUnet even though the traffic will look like it's coming from our company.
Well, then, tell them to put it on one of their own IP blocks.
Besides, everybody at UUNET knows that because of budget WorldCom's budget cuts, the password on all routers has been changed to "Il0v3Bern1E." Saves money on all of those pesky, expensive databases.:-)
My company is running IIS 5. Perl is running on the system, and I'd like to create a script that will take any requests for default.ida and add the IP to the list of IP addresses the IIS server blocks.
My measly little class C's worth of addresses saw almost 11,000 Code Red attempts yesterday alone. Adding that many blocked hosts to IIS would most certainly bog it down to the point that nobody else would get in, either.
If your server isn't vulnerable, why bother? Just process the request and 404 'em.
If your server is vulnerable, consider getting it fixed instead of finding creative ways to create a denial-of-service attack on yourself.:-)
While the system could be broken by using counters, this could be countered by parsing only certain portion of the mail or counting the frequency of certain words. Would work very well on pure text spam, but not on attachement stuff.
Actually, that technique works reasonably well.
I used to administer the trouble ticket system for a very large ISP that got so many complaints that they became unmanagable. (Not all their fault, but that's another story.) Anyway, we had software that would take the bodies of the emails being complained about, remove whitespace and anything that wasn't in the dictionary, sort it, uniq it and generate an MD5 of the list of words that came out. I never studied it over the long haul, but tests on live data showed a match rate of about 90%.
The real flaw in DCC is that it doesn't protect early recipients of the spam, because it won't have built up enough hits to be considered bulky. The only way to make it work would be to submit the checksum and hold the letter for some amount of time to see how bulky it gets. Most people would probably not like the lag time they'd get on legitimate mail.
This is just what countries like Iraq have been waiting for: standardized, general-purpose computing on cheap, reasonably powerful hardware that isn't embargoed or considered a munition.
Not that I think this project should be stopped. The more Unix there is in the world, the better I like it!
Only if the DIMMs don't degrade further slowly, right?
Actually, building in support for on-the-fly memory testing might not be a bad idea. I've seen it done elsewhere and can't think of a good reason not to add it as an option to Linux. (Or other Unixes. You listening, Sun?) Even good RAM will eventually go south, and being able to prevent the system from using it could prevent critical systems from crashing. It might not be able to prevent every crash, but might prevent a few.
If I had the time to experiment, I'd add software to the Kernel that periodically pulls a page of RAM out of service and uses idle time to test it out, returning it to service or marking it permanently bad.
...tell your performers if they want to make money get on a Bus and tour, recordings are ads...the show is what your promoting and people will pay for, if your a musician your job is to come to my town and entertain me, your recordings are just the way of letting me know your out there and get me excited to see your show.
Hate to tell you this, but artists go on tour to support their albums, not the other way 'round.
I'd bet they wanted to plug it into a windows95 pc at first, (usb or serial) until they thought about unlicensed software sharing. From there it was a short step to a cheap, proprietary hardware only solution.
What good would an unlicensed copy of the software be if you haven't already purchased the sewing machine to go with it?
small_dick said: NetPD was able to scan thousands of computers, obtain information about the users, compile and distribute the information without a warrant or your permission to access your machine.
People providing the material Metallica and others are up in arms about invited others to connect up to their servers by making them part of the Napster network. NetPD didn't do anything nefarious in collecting its list, they used the same mechanisms available to any other Napster user. The only difference is that they found a way to automate the process and kept records of what they found. If you want to prevent NetPD or others from doing something similar to your system, implement access controls and do everything you can to ascertain the identity and intent of those you allow to connect.
In my opinion, all communication between two computers must become legally protected... no monitoring of my communication with other PC users without a warrant or my consent.
What you're railing against has nothing to do with monitoring of others' communications. It has everything to do with the fact that a large number Napster users effectively hung signs on the front of their systems that said "I have others' intellectual property available for download." The owners of that IP took notice and are exercising their legal right to protect their interests.
I'd be real interested to know why people feel people should be beheaded for violations of the GPL but that violating the license terms of non-free things is okay.
This may sound like the kind of corporate BS that most Slashdotters would give the brush-off, but I'm going to say it anyhow, because I've seen it work:
The way to convince your management that you need more people is to give them hard numbers that prove your existing staff can't keep up (Buzzword: Cost-Benefit Analysis). You've got some goals set for how long it takes to service requests (Buzzword: SLAs), right? And a trouble ticket system that can show how hard your staff is working and whether or not you're meeting your goals? If you've got both, you're in business.
If you go to your management with solid evidence and they still won't budge, adjust your service times to match the staff you have. Let the users know about it. If they don't like the new slower service, they'll complain to your management. Managers sometimes don't do its job until there are a dozen people screaming about something.
Slashdot Mirror
Leaving the car out there as a tempting target doesn't constitute entrapment. Even having an officer in plain clothes tipping likely thieves off to the fact that the car is easily stolen doesn't count.
I cannot dispute that they have many many talented people working at IBM. I, however, do think that its a negative development that two monoliths are producing their own versions of Linux, if its more than just a branding they run the risk of forking.
Possible, but not likely. The only place there's a real difference between platforms is down a few subtrees in the kernel source. With the exception of the C compiler (which has to be tuned per processor) and a few utilities that are specific to one platform (such as hwclock), everything else can be identical. Name it: emacs, grep, Apache, perl, etc. all come from the same set of sources on every flavor of Linux and a number of other OSes, too. If Apache forks, that's a problem for the Apache community, not the Linux community.
Besides, on the basis of percentage of code developed in-house, RH is just a branding, too.
Besides, there were already working versions of Redhat and I think at least one other distro and now that revenue stream will be gone for those companies. No one will elect to use Redhat's OS/390 version of Linux over IBM's.
I'll give you three guesses who did most of the work getting the kernel to run on the 390 (three letters, very close to H-A-L). If the distributors have their acts together, then their build process is fully automated and retargeting on a platform shouldn't be much more than telling the C compiler what CPU it'll be cross-compiling to.Its kinda like how ma and pop organizations are effected when a Walmart comes to town.
That's a whole different ball of wax. Wal Mart and mom-and-pop shops sell the exact same roll of toilet paper sold to them by a third party. Wal Mart's advantage is that it buys them in such huge quantities that it gets a deep discount that the M-and-P shops can't match. IBM actually engineers and manufactures products, and for someone to buy any flavor of 390 Linux, IBM must get another of its machines out into the world.
That's not the case for RH, who manufactures a product that runs on commodity Intel boxes which are made by thousands of different manufacturers. RH is actually has a competitive advantage here because they can adapt their product to any platform they see as being ubiquitous enough to be a commodity and therefore a good revenue stream with comparatively minimal effort compared to what a hardware vendor must do before a new platform sees the light of day.
Don't forget IBM also makes many other architectures, and can stake a claim to having unique insight into everything from the AS/400 down to PowerPC systems, I do not see that as a valid excuse for attempting to crush every other vendor in these areas.
The Intel PC is in IBM's product line, too, but you'll notice that they don't sell an IBM-branded Linux for that, either. If IBM's distributions of Linux for their own products superior to anything else, why shouldn't they win? Nobody screamed bloody murder when HP jumped on the bandwagon.
RH is arguably the most successful shrink-wrapped Linux for Intel on the planet, but I hear very little hew and cry about the small distributors who've gone tits up because of that success.
Lots of times the big guys win, and every once in awhile one of the little guys does something great that propels them into being big. Sun started its life as one of the little guys, too.
Its not all bad news, it does mean that linux has come of age in the enterprise server world.
Yes, it does. And that coming of age means big businesses like IBM, Sun, HP and others will get involved. But it's a free market, and that's how the free market works.
A 1000 processor Cray T3E 1200 would smoke your pathetic little mainframe :)
In some applications, yes, I couldn't agree with you more. Mainframes suck eggs when it comes to number crunching, but even a small mainframe will blow the doors off any supercomputer when it comes to I/O intensive applications such as databases.
The alarming thing is that they are producing their OWN version of Linux, not using Redhat or another company.
IBM has more in-house OS talent in its pinky than any of the Linux distributors. They know the most about their hardware. So why farm it out to some other vendor who's not likely to have a clue about how to make the OS run on their own platform? (And this is a platform thing. Don't assume the z800 is a big box that's binary-compatible with the x86, because it isn't.)
It pizzes me off to no end that people have completely forgotten that the whole purpose of an operating system is to provide a consistent API for software to bang against regardless of what hardware it's running on. If IBM's Linux for the 390 provides a properly-functioning interface identical to that provided by every other flavor of Linux, the whole recertification argument becomes a moot point. If something like Apache builds and runs properly on RH for x86, there's no reason it shouldn't on IBM for the 390.
If the article is correct, then the z800's running zVM emulate Intel x86 architecture in order to run Linux. Heck, even poorly written native compiled code generally has advantages over such a set up.
That's not what IBM is doing at all. The version of Linux that runs on the 390 platform is natively compiled for that system and has been tuned to work with it. This is no different than Linux on any of the dozen or so other platforms it's been designed to run on.
Sun's FUD-slinger got his facts wrong more than half the time in that article, which in most places would get him grade of "F". I've been using and buying Suns for 16 years, and while I really like their products, I hope IBM takes every opportunity to point out what a nitwit he is.
The moral: Just 'cause it says "Linux" on the label doesn't mean it's running on an x86.
Haven't priced one, but I think they run about $2,000. On both the F5 (2000/3350) and the 1V (1800/2900), the MSRP is about 65% higher than the street price. So both Nikon and Canon have an overinflated sense of what their products are worth.
Nice camera, pity I can't fit my lenses on it :-) Had one the last place I worked, used it for a few hours, very very nice.
The D1X is very very nicer. :-)
The D1, D1X and D1H are based on the F5, which has a MSRP of US$3,350.
And yes, I love my D1 to pieces.
...since and i have yet to see a fiber optic car.
Fiber? In an automobile? Ick!The SAE has a standard called J1850 that integrates all communications between all of the controllers in the car onto a bus that runs over a single piece of copper wire. Saves a huge amount of wire and allows the bus to go all sorts of places you could never dream of reaching with fiber.
What that means is that if the manufacturer wants the remote keyless entry system to be able to start the engine, it's a software upgrade. The Blrflmobile (a 300M) runs on J1850 and has had a couple of software upgrades to improve the air conditioner and other things. When else in history have you been able to benefit from engineering improvements in your care after you've driven it off the lot?
If you really worked there, you'd know it was spelled "UUNET" and not "UUnet."
We don't actually administer our routers? Our company has some contract through UUnet and the router is actually property of UUnet we don't even have the password to get in and administer it.
Number one rule of good security: If you have no control over it, assume it's potentially hostile. Number two rule of good security: If you have control over it, assume it's potentially hostile. In short, add one of your own routers directly behind it.
So if it's comprimised, the blame should be placed on UUnet even though the traffic will look like it's coming from our company.
Well, then, tell them to put it on one of their own IP blocks.
Besides, everybody at UUNET knows that because of budget WorldCom's budget cuts, the password on all routers has been changed to "Il0v3Bern1E." Saves money on all of those pesky, expensive databases. :-)
So what? DirecTV and Dish Network hardware isn't interchangable either, and neither seems to have a shortage of customers.
My company is running IIS 5. Perl is running on the system, and I'd like to create a script that will take any requests for default.ida and add the IP to the list of IP addresses the IIS server blocks.
My measly little class C's worth of addresses saw almost 11,000 Code Red attempts yesterday alone. Adding that many blocked hosts to IIS would most certainly bog it down to the point that nobody else would get in, either.
If your server isn't vulnerable, why bother? Just process the request and 404 'em.
If your server is vulnerable, consider getting it fixed instead of finding creative ways to create a denial-of-service attack on yourself. :-)
While the system could be broken by using counters, this could be countered by parsing only certain portion of the mail or counting the frequency of certain words. Would work very well on pure text spam, but not on attachement stuff.
Actually, that technique works reasonably well.
I used to administer the trouble ticket system for a very large ISP that got so many complaints that they became unmanagable. (Not all their fault, but that's another story.) Anyway, we had software that would take the bodies of the emails being complained about, remove whitespace and anything that wasn't in the dictionary, sort it, uniq it and generate an MD5 of the list of words that came out. I never studied it over the long haul, but tests on live data showed a match rate of about 90%.
The real flaw in DCC is that it doesn't protect early recipients of the spam, because it won't have built up enough hits to be considered bulky. The only way to make it work would be to submit the checksum and hold the letter for some amount of time to see how bulky it gets. Most people would probably not like the lag time they'd get on legitimate mail.
Not that I think this project should be stopped. The more Unix there is in the world, the better I like it!
How about installing cameras on farms so they could at least prosecute the sheep and cows responsible for spreading hoof-and-mouth disease?
:-)
Only if the DIMMs don't degrade further slowly, right?
Actually, building in support for on-the-fly memory testing might not be a bad idea. I've seen it done elsewhere and can't think of a good reason not to add it as an option to Linux. (Or other Unixes. You listening, Sun?) Even good RAM will eventually go south, and being able to prevent the system from using it could prevent critical systems from crashing. It might not be able to prevent every crash, but might prevent a few.
If I had the time to experiment, I'd add software to the Kernel that periodically pulls a page of RAM out of service and uses idle time to test it out, returning it to service or marking it permanently bad.
I'm going to burn down the building.
Hate to tell you this, but artists go on tour to support their albums, not the other way 'round.
I'd bet they wanted to plug it into a windows95 pc at first, (usb or serial) until they thought about unlicensed software sharing. From there it was a short step to a cheap, proprietary hardware only solution.
What good would an unlicensed copy of the software be if you haven't already purchased the sewing machine to go with it?
A Z80 plus a MC68000 - killer box for 1979, eh?
Dang, there's enough CPU there to run... dare I say it...
Nahh. No need.
People providing the material Metallica and others are up in arms about invited others to connect up to their servers by making them part of the Napster network. NetPD didn't do anything nefarious in collecting its list, they used the same mechanisms available to any other Napster user. The only difference is that they found a way to automate the process and kept records of what they found. If you want to prevent NetPD or others from doing something similar to your system, implement access controls and do everything you can to ascertain the identity and intent of those you allow to connect.
In my opinion, all communication between two computers must become legally protected ... no monitoring of my communication with other PC users without a warrant or my consent.
What you're railing against has nothing to do with monitoring of others' communications. It has everything to do with the fact that a large number Napster users effectively hung signs on the front of their systems that said "I have others' intellectual property available for download." The owners of that IP took notice and are exercising their legal right to protect their interests.
I'd be real interested to know why people feel people should be beheaded for violations of the GPL but that violating the license terms of non-free things is okay.
The way to convince your management that you need more people is to give them hard numbers that prove your existing staff can't keep up (Buzzword: Cost-Benefit Analysis). You've got some goals set for how long it takes to service requests (Buzzword: SLAs), right? And a trouble ticket system that can show how hard your staff is working and whether or not you're meeting your goals? If you've got both, you're in business.
If you go to your management with solid evidence and they still won't budge, adjust your service times to match the staff you have. Let the users know about it. If they don't like the new slower service, they'll complain to your management. Managers sometimes don't do its job until there are a dozen people screaming about something.
IRIDIUM SATELLITE PHONE LEASE