Well of course AT&T are involved. Lest anyone forget, AT&T Bell Laboratories were the corporate inventors of Unix. It was while employed there that Kernighan, Richie, Thompson, et. al. did their magic. I *think* (don't quote me) that closest thing in heredity and spirit after all the various acquisitions and spinoffs and splits in AT&T since those days would be Lucent, but I'm not really sure.
The thing they tout as FEAD is basically a load-over-network-on-demand thingy. They haven't actually developed anything that does compression, they're just storing some of the app on a server somewhere to be downloaded on demand. The hype at their site mislead you, like it was meant to do.
True, but starting from something like RH7.x, or Gentoo, or whatever, it really only takes a good linux sysadmin type to create an RH AS equivalent - it doesn't really take any "programming" skills, just "find the right patches and merge them into a kernel and test it out a bit" skills. It doesn't require a good programmer, just a person reasoanbly skillful at linux hacking.
You can get both from standard source on kernel.org as well. I think what the original poster is *really* asking is "What features exist in RH AS 2.1 that are truly unique and worth the money, as opposed to stuff any good linux hacker could've thrown together on his own?". Redhat would do well to answer this.
You could just spend the 30 seconds it takes to work around the problem. Try random user/pass words that frustrated people would register, that's what I do. I usually get in by the 4th try at the latest with something like "privacy/privacy", or "slashdot/slashdot", or "screw/you" or whatever. You don't even have to register these users yourself, just poke around for a few attempts and you'll hit someone else's bullshit registration. Cookie it into your browser so you dont have to do it next time.
Oh yeah, that's right, you can only learn complex theories in a classroom, I forgot. I guess some people need structure in order to learn, but I'm not one of them, thanks.
Oh and aside from the point of the thread, I feel it's important to point out that I haven't taken a compilers course. I've never taken any college course. I operate in the real world. I don't use useless theoretical constructs written by your above-mentioned big fat name-dropping list. Your post is pathetic in it's attempt to feel superior because of your acedemic background.
And writing compilers is every bit as easy as I'd think. Where do you get off thinking you know how I'd think to begin with? I'll code circles around you from asm to java and back again.
Exactly, you backed up my point while trying not to:)
The fact that you cannot see the programmer's style, only the compiler's style, is what makes decompiling source much easier. It's easier to learn the thinking patterns of the compiler by observing its output in various cases than it is to write software that can guess random human patterns.
Where did I say C was a high level language? I used C++ as a reference because like it or not, it is high enough level to have it's own structure. I didn't use C because I well understand that C is basically portable assembler.
Beyond the current OOP language like C++ and Java, the only things higher level are the toy languages for braindead programmers (think VB, Delphi, FoxPro, etc) - and the various real attempts at 4GL, which never seem to work right for general cases, but can be useful in application-specific situations.
When you think about it, the higher level the language is, the easier it should be to "decompile". The closer the original source was to asm, the more the individual coder's style will be reflected in the asm - the higher level it is, the more the obvious patterns the compiler uses every time for given constructs will be present. Reverse engineering a program written in asm to human readale source is a nightmare, but if you knew for instance that the source was C++ and it was compiled by gcc 3.2 (easy enough to tell), it's probably pretty easy to see from the asm patterns the classes and whatnot, to see the structure of the source.. then you just have to comine that with what the program actually does to give human meaning ack to the variale and class names and whatnot.
Yeah, that's a problem I have with this guy's test results. He's taken all the memory parameters which have very different purposes and effects, and rated them all on a scale of percentage increases in memory bandwidth.
The important effect of dropping CAS latency is that it improves memory response time on a small request - it's not meant to really give a big boost to bulk bandwidth.
You can think of the tradeoffs from spending a fixed dollar amount on clock speed boosts vs lowering CAS times as kinda like the difference between going RDRAM and going SDRAM. RDRAM had much higher bandwidth, but the latency sucked. SDRAM had lower bandwidth, but also had lower latency.
So wrap it up - this test is uninteresting because it rated all those parameters based on how they affected bandwidth, when really only the clock speed speed has a significant impact on bandwidth - a lot of the other parameters are really more about latency and responding well to certain patterns of access.
The obvious answer is to drill it out. Since you'll want to be a little careful, you should probably start with an extremely small bit and drill a pinhole into it first, and then work up the bit sizes one by one until the head pretty much falls off the screw. It will destroy both the screw and the mount, but they were crossthreaded anyways.
The obvious issue is of course metal shavings. A small amount of cutting fluid on the bits (or probably any liquid, maybe wd-40) will help to a small degree to keep the shavings from flying around as much (they'll tend to travel up the grooves in the bit instead). More importantly - mask things off. Cut a small 3/4" or so square hole in the center of a large peice of paper. Cover the hole in masking tape. Place the taped hole over the screw, taping the hole down all around it - then cut the circle of tape off the head of the screw where you'll be drilling. You should be able to keep the shavings on the peice of paper instead of on the motherboard shorting out little pins and things.
The important thing here is that it is a corporate issue, and the corporation is very involved no matter what. They want to know, and as an employee you have to tell them so that they can respond to the situation appropriately. It's a reasonable stance to take (legally) to inform HR and allow *them* to contact the police. If they fail to do so and you feel that even HR is violating the law, then perhaps it is your place to call the police.
And I don't keep porn on my work PC either, but I certainly consider it's contents personal. I do read my personal email there, I also pay my bills through my work PC, I do my insurance company stuff through it, I pay my rent through it, I bank through it, etc. If you work 8-5, and most businesses are open 8-5, you end up conducting personal business at work, that's just the nature of things. It used to be on a phone or a long lunch hour, now it's in a browser.
They still took the wrong action, which probably ultimately contributed to their treatment. At any corporation, the proper course of action for anything as serious as child porn is to immediately go to Human Resources. You have two paths there, anonymous reporting to them, or going in on your own name. In either case, going to HR first protects you in a whole bunch of ways - although anonymity is probably the most protected route.
You're perpetuating the "stopping-power" myth perpetuated by companies with a vested interest in larger slower calibers. You want to "stop" the person you're shooting at, no doubt, but that has little to do with the ft/lbs of energy transferred to the target - the greater determinant is the extent of the damage the wound does to the body, and how quickly and severly this causes shock, rendering the target useless and usually dying. The "side effect of causing greater damage" is not "also sometimes an objective" - it is the primary objective. "Stopping power" (ft/lbs of force delivered) is a side effect and sometimes an objective - but you can make up for a lot of ft/lbs with better wounds.
Also, armor piercing is not done by increasing the caliber. You pierce armor by making either the jacket of the bullet or the whole bullet of a stronger material that the usual lead. The most common/cheap/effective method is full metal jacket rounds using a steel jacket over lead. The FMJ rounds used at target ranges have a jacket made of copper or another similarly soft metal, hence FMJ != armor pierce in general, but certain jackets do. Generally to pierce armor you want to get as many ft/lbs of energy as you can into the smallest caliber you can with the strongest outer jacket.
There's some reasoning behind the lack of big interest in distributed filesystems.
1) Obviously, NFS continues to be a passable solution where you dont really need "distributed" so much as "universally network accessible in a simple way".
2) For things where you truly want "distributed" access from multiple machines that are local to each other, there's a somewhat less complicated solution, which is to use shared storage. The idea is to attach all the machines to a SAN-style network (fiber channel, or hey even firewire these days) and use a sharing-aware filesystem that allows simultaneous access to the storage/filesystem from multiple hosts with sane locking and whatnot. One of the better places to look for this is otn.oracle.com - they've released a cluster-filesystem *and* drivers for firewire shared storage (which is cheaper than fiberchannel) for linux.
Of course, that leaves out the case of a distributed filesystem for machines that can't be on a SAN together for distance or economical reasons. In that case you could of course hack something up using cluster-filesystem type of filesystem and SCSI-over-IP or something like that I guess, or use one of the experimental distributed filesystems you mention... but the market just isn't big enough for this yet to drive much.
Agreed, nothing requires you to share. But what about when you crack fermat and apply for a patent, and another guy also cracks fermat on his own, a few days later than you, but before your patent made it public.
Because you discovered it three days before him, he can't use his discovery of the same facts without paying you a royalty now? That's ridiculuous.
IF it violates a patent THEN it could still be innovative, because patents are being granted to very broad situations in which a lot of future innovation still exists.
IF someone patented addition THEN would you come up with an alternative innovative way to do you math instead? What if someone patented modulo arithmetic operations on some prime numbers, which happen to be one of very few feasible public key methods mathematicians have discovered?
There's a basic discovery vs invention argument in there somewhere. If you invent a mathematical algorithm with some very unique properties, have you not just discovered an area of math that was inherent in the system, that someone else would have stumbled upon eventually? Think of all the examples of simultaneous inventions on opposite sides of the globe in history - when the timing is right in history and the groundwork has been laid out, the next steps can and will be discovered by multiple people. What on this planet gives you an inalienable right to charge people money because you think you saw it first?
How bad is this compared to the original and other state super-DMCAs, if anyone knows? I read the linked copy of the bill text (which is rather short), and every definition of an offense seems to be gaurded with the phrase "with the intent to harm or defraud a communications service". Is this just syntactic sugar, in that in any case they'll quickly show some hypothetical way that you could have defrauded or harmed, and consider that good enough for "intent"? I don't see the law as being all that bad (all things considered) if they actually had to adhere to this limitation and only go after people they could prove were defrauding a commercial service provider... kinda sounds like it's aimed at cable theft.
Now of course, in my ideal world, if you can hear and decode a signal, it's yours. That means TV descramblers, scanners with cell-range coverage, etc, etc... should all be legal. If someone doesn't want you to listen to a signal, they should bother to actually encrypt it usefully, rather than resorting to legal crap. I'd even go so far as to say if you can crack their encryption, you're still legal - it was their fault for using something you could crack, like 40-bit DES or something else weak.
But in the big scheme of all the crap modern laws, this Texas one doesn't sound all that bad to me, again depending on the real-world meaning of their "intent" language. Anyone know how this would likely play out?
So X/Open Distributed Transaction Processing is essentially what I was referring to then? Making sure all "sources" are ok before comitting them all, or rolling them all back if any fails? Hardly seems worthy of a designation and a standard, just sounds like logic to me.
Don't forget the inside/outside difference. PLanes have certainly been designed to withstand and shield against a fairly large dose of radiation on the outside of the hull - but 30 years ago I don't think anyone conceived passengers inside the plan having high power RF transmitters onboard. There's no internal shielding between the passenger compartment and the instrumentation.
As for it being too expensive to shield this stuff - don't bother retrofitting shielding on the instruments - just line the passenger cabin in shielding, a much simpler operation. Plus it would likely prevent cellphone use in the passenger cabin anyways.
I'm not a JDBC user, but I assumed "XA Connections" meant standard transactions. Isn't XA short for TransAction? And what exaclty is a distributed transaction? If I were writing an app that needed to do a transaction across multiple seperate databases (well, for one I might think thoses databases need to be one, but suppose that's out of my control...), I would simply open two transactions, and make sure all the statements of both have completed successfully before I commit them both. Is a distributed transaction just an automation of that, or is there something more to it?
Slashdot Mirror
Well of course AT&T are involved. Lest anyone forget, AT&T Bell Laboratories were the corporate inventors of Unix. It was while employed there that Kernighan, Richie, Thompson, et. al. did their magic. I *think* (don't quote me) that closest thing in heredity and spirit after all the various acquisitions and spinoffs and splits in AT&T since those days would be Lucent, but I'm not really sure.
The thing they tout as FEAD is basically a load-over-network-on-demand thingy. They haven't actually developed anything that does compression, they're just storing some of the app on a server somewhere to be downloaded on demand. The hype at their site mislead you, like it was meant to do.
True, but starting from something like RH7.x, or Gentoo, or whatever, it really only takes a good linux sysadmin type to create an RH AS equivalent - it doesn't really take any "programming" skills, just "find the right patches and merge them into a kernel and test it out a bit" skills. It doesn't require a good programmer, just a person reasoanbly skillful at linux hacking.
You can get both from standard source on kernel.org as well. I think what the original poster is *really* asking is "What features exist in RH AS 2.1 that are truly unique and worth the money, as opposed to stuff any good linux hacker could've thrown together on his own?". Redhat would do well to answer this.
Hans,
Do you find it annoying that 75% of the Slashdot questions could be answered by actually reading the opening page of your company's website?
You could just spend the 30 seconds it takes to work around the problem. Try random user/pass words that frustrated people would register, that's what I do. I usually get in by the 4th try at the latest with something like "privacy/privacy", or "slashdot/slashdot", or "screw/you" or whatever. You don't even have to register these users yourself, just poke around for a few attempts and you'll hit someone else's bullshit registration. Cookie it into your browser so you dont have to do it next time.
Oh yeah, that's right, you can only learn complex theories in a classroom, I forgot. I guess some people need structure in order to learn, but I'm not one of them, thanks.
Oh and aside from the point of the thread, I feel it's important to point out that I haven't taken a compilers course. I've never taken any college course. I operate in the real world. I don't use useless theoretical constructs written by your above-mentioned big fat name-dropping list. Your post is pathetic in it's attempt to feel superior because of your acedemic background.
And writing compilers is every bit as easy as I'd think. Where do you get off thinking you know how I'd think to begin with? I'll code circles around you from asm to java and back again.
Exactly, you backed up my point while trying not to
The fact that you cannot see the programmer's style, only the compiler's style, is what makes decompiling source much easier. It's easier to learn the thinking patterns of the compiler by observing its output in various cases than it is to write software that can guess random human patterns.
Where did I say C was a high level language? I used C++ as a reference because like it or not, it is high enough level to have it's own structure. I didn't use C because I well understand that C is basically portable assembler.
Beyond the current OOP language like C++ and Java, the only things higher level are the toy languages for braindead programmers (think VB, Delphi, FoxPro, etc) - and the various real attempts at 4GL, which never seem to work right for general cases, but can be useful in application-specific situations.
When you think about it, the higher level the language is, the easier it should be to "decompile". The closer the original source was to asm, the more the individual coder's style will be reflected in the asm - the higher level it is, the more the obvious patterns the compiler uses every time for given constructs will be present. Reverse engineering a program written in asm to human readale source is a nightmare, but if you knew for instance that the source was C++ and it was compiled by gcc 3.2 (easy enough to tell), it's probably pretty easy to see from the asm patterns the classes and whatnot, to see the structure of the source.. then you just have to comine that with what the program actually does to give human meaning ack to the variale and class names and whatnot.
Yeah, that's a problem I have with this guy's test results. He's taken all the memory parameters which have very different purposes and effects, and rated them all on a scale of percentage increases in memory bandwidth.
The important effect of dropping CAS latency is that it improves memory response time on a small request - it's not meant to really give a big boost to bulk bandwidth.
You can think of the tradeoffs from spending a fixed dollar amount on clock speed boosts vs lowering CAS times as kinda like the difference between going RDRAM and going SDRAM. RDRAM had much higher bandwidth, but the latency sucked. SDRAM had lower bandwidth, but also had lower latency.
So wrap it up - this test is uninteresting because it rated all those parameters based on how they affected bandwidth, when really only the clock speed speed has a significant impact on bandwidth - a lot of the other parameters are really more about latency and responding well to certain patterns of access.
The obvious answer is to drill it out. Since you'll want to be a little careful, you should probably start with an extremely small bit and drill a pinhole into it first, and then work up the bit sizes one by one until the head pretty much falls off the screw. It will destroy both the screw and the mount, but they were crossthreaded anyways.
The obvious issue is of course metal shavings. A small amount of cutting fluid on the bits (or probably any liquid, maybe wd-40) will help to a small degree to keep the shavings from flying around as much (they'll tend to travel up the grooves in the bit instead). More importantly - mask things off. Cut a small 3/4" or so square hole in the center of a large peice of paper. Cover the hole in masking tape. Place the taped hole over the screw, taping the hole down all around it - then cut the circle of tape off the head of the screw where you'll be drilling. You should be able to keep the shavings on the peice of paper instead of on the motherboard shorting out little pins and things.
GPU in the graphics card sense means Graphics Processing Unit.
The important thing here is that it is a corporate issue, and the corporation is very involved no matter what. They want to know, and as an employee you have to tell them so that they can respond to the situation appropriately. It's a reasonable stance to take (legally) to inform HR and allow *them* to contact the police. If they fail to do so and you feel that even HR is violating the law, then perhaps it is your place to call the police.
And I don't keep porn on my work PC either, but I certainly consider it's contents personal. I do read my personal email there, I also pay my bills through my work PC, I do my insurance company stuff through it, I pay my rent through it, I bank through it, etc. If you work 8-5, and most businesses are open 8-5, you end up conducting personal business at work, that's just the nature of things. It used to be on a phone or a long lunch hour, now it's in a browser.
They still took the wrong action, which probably ultimately contributed to their treatment. At any corporation, the proper course of action for anything as serious as child porn is to immediately go to Human Resources. You have two paths there, anonymous reporting to them, or going in on your own name. In either case, going to HR first protects you in a whole bunch of ways - although anonymity is probably the most protected route.
You're perpetuating the "stopping-power" myth perpetuated by companies with a vested interest in larger slower calibers. You want to "stop" the person you're shooting at, no doubt, but that has little to do with the ft/lbs of energy transferred to the target - the greater determinant is the extent of the damage the wound does to the body, and how quickly and severly this causes shock, rendering the target useless and usually dying. The "side effect of causing greater damage" is not "also sometimes an objective" - it is the primary objective. "Stopping power" (ft/lbs of force delivered) is a side effect and sometimes an objective - but you can make up for a lot of ft/lbs with better wounds.
Also, armor piercing is not done by increasing the caliber. You pierce armor by making either the jacket of the bullet or the whole bullet of a stronger material that the usual lead. The most common/cheap/effective method is full metal jacket rounds using a steel jacket over lead. The FMJ rounds used at target ranges have a jacket made of copper or another similarly soft metal, hence FMJ != armor pierce in general, but certain jackets do. Generally to pierce armor you want to get as many ft/lbs of energy as you can into the smallest caliber you can with the strongest outer jacket.
Imagine a beowulf cluster of diamond-coated fractal blades!
There's some reasoning behind the lack of big interest in distributed filesystems.
1) Obviously, NFS continues to be a passable solution where you dont really need "distributed" so much as "universally network accessible in a simple way".
2) For things where you truly want "distributed" access from multiple machines that are local to each other, there's a somewhat less complicated solution, which is to use shared storage. The idea is to attach all the machines to a SAN-style network (fiber channel, or hey even firewire these days) and use a sharing-aware filesystem that allows simultaneous access to the storage/filesystem from multiple hosts with sane locking and whatnot. One of the better places to look for this is otn.oracle.com - they've released a cluster-filesystem *and* drivers for firewire shared storage (which is cheaper than fiberchannel) for linux.
Of course, that leaves out the case of a distributed filesystem for machines that can't be on a SAN together for distance or economical reasons. In that case you could of course hack something up using cluster-filesystem type of filesystem and SCSI-over-IP or something like that I guess, or use one of the experimental distributed filesystems you mention... but the market just isn't big enough for this yet to drive much.
Agreed, nothing requires you to share. But what about when you crack fermat and apply for a patent, and another guy also cracks fermat on his own, a few days later than you, but before your patent made it public.
Because you discovered it three days before him, he can't use his discovery of the same facts without paying you a royalty now? That's ridiculuous.
IF it violates a patent
THEN it could still be innovative, because patents are being granted to very broad situations in which a lot of future innovation still exists.
IF someone patented addition
THEN would you come up with an alternative innovative way to do you math instead? What if someone patented modulo arithmetic operations on some prime numbers, which happen to be one of very few feasible public key methods mathematicians have discovered?
There's a basic discovery vs invention argument in there somewhere. If you invent a mathematical algorithm with some very unique properties, have you not just discovered an area of math that was inherent in the system, that someone else would have stumbled upon eventually? Think of all the examples of simultaneous inventions on opposite sides of the globe in history - when the timing is right in history and the groundwork has been laid out, the next steps can and will be discovered by multiple people. What on this planet gives you an inalienable right to charge people money because you think you saw it first?
How bad is this compared to the original and other state super-DMCAs, if anyone knows? I read the linked copy of the bill text (which is rather short), and every definition of an offense seems to be gaurded with the phrase "with the intent to harm or defraud a communications service". Is this just syntactic sugar, in that in any case they'll quickly show some hypothetical way that you could have defrauded or harmed, and consider that good enough for "intent"? I don't see the law as being all that bad (all things considered) if they actually had to adhere to this limitation and only go after people they could prove were defrauding a commercial service provider... kinda sounds like it's aimed at cable theft.
Now of course, in my ideal world, if you can hear and decode a signal, it's yours. That means TV descramblers, scanners with cell-range coverage, etc, etc... should all be legal. If someone doesn't want you to listen to a signal, they should bother to actually encrypt it usefully, rather than resorting to legal crap. I'd even go so far as to say if you can crack their encryption, you're still legal - it was their fault for using something you could crack, like 40-bit DES or something else weak.
But in the big scheme of all the crap modern laws, this Texas one doesn't sound all that bad to me, again depending on the real-world meaning of their "intent" language. Anyone know how this would likely play out?
So X/Open Distributed Transaction Processing is essentially what I was referring to then? Making sure all "sources" are ok before comitting them all, or rolling them all back if any fails? Hardly seems worthy of a designation and a standard, just sounds like logic to me.
Don't forget the inside/outside difference. PLanes have certainly been designed to withstand and shield against a fairly large dose of radiation on the outside of the hull - but 30 years ago I don't think anyone conceived passengers inside the plan having high power RF transmitters onboard. There's no internal shielding between the passenger compartment and the instrumentation.
As for it being too expensive to shield this stuff - don't bother retrofitting shielding on the instruments - just line the passenger cabin in shielding, a much simpler operation. Plus it would likely prevent cellphone use in the passenger cabin anyways.
I'm not a JDBC user, but I assumed "XA Connections" meant standard transactions. Isn't XA short for TransAction? And what exaclty is a distributed transaction? If I were writing an app that needed to do a transaction across multiple seperate databases (well, for one I might think thoses databases need to be one, but suppose that's out of my control...), I would simply open two transactions, and make sure all the statements of both have completed successfully before I commit them both. Is a distributed transaction just an automation of that, or is there something more to it?