You shouldn't have to run Java to install Java. And given the size of Websphere and the incompatibilities between Java releases, they should include their own.
This is heavily dependent on the DVD player. Everytime a player has notes for this published, the manufacturer very quickly "updates" it to avoid getting in trouble with the DVD vendors and advertisers, and to keep their license for the software that decodes DVD's.
It's a nasty business, and exactly why so many people are willing to do what has been ruled to be illegal and use the libdvdcss library to rip new DVD's, or record the movie from them directly for local viewing. But look for this to fail completely when the "Trusted Computing" tools take hold of hardware management: it will become far more difficult.
Agreed. The closed source community is notorious for doing amazingly brain-dead things and lying about patching it.
But notice that the closed-source/opoen-source involved here has almost nothing to do with the nature of the operating system: it has to do with the development models for rootkits themselves. The rootkit developers are sharing their information, and frankly, they should share it. Otherwise, these holes will remain in place and fester and be passed around behind doors that are barely closed at all: they always have been, since long before the release of the original Morris Worm.
Why write on paper rather than on stone blocks? Because it's cheaper and portable! Seriously, some actual use of USB drives shows how handy they are for storing data in a place where electricity is unreliable and laptops are prone to failure with a repair time of weeks or months. How to protect them from theft is a real problem, of course.
But a $10 USB drive can hold a soldier's email from home, some music to share with their friends, their transfer orders, a map of the local area's targets for the next day, and the combination for the food locker. Like paper and pencil, they're just too useful to deny to the troops: the key is to make sure they're used properly.
Oh, the data access for the laptops is a part of absolutely necessary infrastructure fo the laptops to be useful. It won't be ubiquitous until the infrastructure is expanded, but a few community satellite phones with wireless ports would expand the available network coverage vastly, even if it's only for a few hours a day as someone travels from village to village with the satellite phones on a bicycle.
There are limits: when people start climbing out of poverty, making email and web searching and the ability to handle communications and money and look up things like weather and the price of crops can really help them, in ways that another few bags of food will not.
Don't underestimate the improvement that a laptop, able to store weather reports and store information about medical services and lessons for kids and that ugly green spot on grandpa's foot can help a family in fiscal straits.
Then throw out internationalization: the Unicode support and massive proliferation of useless language add-ons is one of the greatest flaws of the current commercial distributions of Linux.
Take a good look at how many of the available core packages in your favorite distribution are for international language nonsense you don't need and will never use.
The Clipper Chip was discarded by the NSA, partly because of the patent violations they engaged in and were eventually caught at, and partly because having developed it in secret with the only extrernal review being from untrustworthy and insufficiently competent people like Dorothy Denning, they made a big mistake: they used an insufficiently long checksum to verify that the keys used were the ones kept in the never-agreed-upon government-held repository. So it was quite feasible to generate and use your own keys on the device, if you gave them roughly 45 minutes to negotiate new keys.
That made the device usably secure for some of the most important communications, such as trans-Atlantic fiscal operations, which the NSA would love to be able to continue to monitor.
Good! I didn't realize the latest fibers were that fast. So a set of network monitors only capable of logging 100 MHZ links would have to be installed somewhere downstream, where the network connectivity begins to fan out, and wind up distributed among multiple loggers.
I'm not shocked, but suspect that that's still the logical place to put the monitoring. It should be straightforward to force any traffic of interest to pass through the monitoring systems with their control of the routers.
This is irrelevant. AT&T still owns a huge share of the land-lines, and of the trans-continental and trans-oceanic links, which is where such monitoring devices would be place. Just because the phone in your house, or your local ISP, is secure doesn't mean your traffic is safe.
Using Verizon as your ISP is no defense: if your traffic passes over AT&T owned wire, to or from your destination, you are vulnerable to this kind of snooping. This is particularly true for international traffic, much of which is over fiber-optic cable owned by AT&T. The routers connecting to those cables are one of the best possible places for network monitoring, and you'd better believe that the NSA is happy to install it there, with AT&T cooperation.
There are certainly tools that can track and record every byte sent on every port on a saturated 100 MHz link, and write it to local disk. Given that the trans-atlantic links are rarely GigE capable, a rack of such devices should easily monitor and re-assemble all the traffic desired. www.sandstorm.com, for example, sells exactly that sort of monitoring tool called "Netintercept", commercially. There's no reason to think the NSA doesn't use them or hasn't reverse engineered them.
Microsoft's history of violating patent law and copyright law. Famous incidents like the Microsoft Mouse and the theft of VMS code for the creation of NT are the tiniest tip of the iceberg: Microsoft, wisely, prefers to keep these cases quiet, overwhelm the plaintiffs with court expenses if necessary, and settle out of court when they have to.
As they developed, they regularly hired away developers from other companies and stole the copyrighted or patented work those developers did elsewhere: it's why they're so sensitive to the risk of their own employes(TM)eaving.
For a lot of copyrighted material, DRM could have some use. Trusted Computing, for example, could be used to manage DVD's and CD's in a sane way rather than the current and fundamentally insane approach used by RIAA.
However, for patents, it's not reasonable. A patent, even a software patent, is easily implemented in a different way that DRM has no way to detect. Simply write the software in a different computer language and DRM will little or no hope of detecting the violation.
This is actually not a big problem: the Linux kernel, like new editions of encyclopedias and school textbooks, would have new copyrights on new kernel releases. Copyright law is different from patent law: let's not get them too mixed up.
Manuals for hardware, unfortunately, are now deliberately incomplete in order to protect the "secret sauce" of the manufacturers. BIOS's, network chipsets, and CPU's all have numerous hidden features that reveal details of the design. In fact, revelations of the details in design manuals could leave the manufacturers open to patent lawsuits: as companies gather large patent suites, not to enforce patents, but as protective arsenals to protect against lawsuit, it makes it very difficult to innovate without accidentally violating an unrevealed or obscure patent that may be invalid, but a small company or developer may not have the resources to battle in court.
But a microphone with a limited frequency range can often capture interesting waveform phenomonea, although attenuated, at well above that frequency. And the temporal data of precisely when which sound started and ended and changed amplitude is still intact, at a much higher temporal resolution than the frequency of the microphone itself. Digitization destroys much of that information, and creates fascinating uncertainties in the temporal information related to the sampling interval. That is actually noticeable to a good ear.
Yes, I'd like to use that "incorrect" score on your post. The error is early, where you said "as long as the signal does not contain any frequency components above 22.05 kHz". Of courese there is information above that sample rate! It's not critical for speech, but for music the sound extends well above that frequency. While such frequencies are nominally "ultrasonic", they're well within the auditory perception of some people and they do affect the shape of auditory waveforms that reach the ear, and especially of timing information among crisp sounds, like high frequency percussion instruments and the character of especially rich sounds like violins.
The microphones had poor reception at higher frequencies, but the signal is still there to some extent. And let's face it: the microphones being used for modern digital recording are usually a poor substitute for the old microphones used for high-quality LP recordings, just as cheap and ubiquitous digital cameras are not yet a substitute for a good quality old camera, due to the undersampling of the visual field.
I don't begrudge the world preservable digital music, or cheap music players. And certainly CD quality surpasses that of cheap LP's, or of worn out ones that the kids have played with and worn scratches in it. But for the high quality LP's, it really makes a noticeable difference.
"Non-lossy" is not the problem. The extremely limited sample rate of the published standards is not soluble without actually changing the standard, even if compression improves or disk space increases and we have no limit there.
The old LP's recorded quite a bit of both high frequency and low frequency information that digitization invariably throws out due to the pitifully low sample rates. No amount of digital processng or massaging can recover information that is entirely in between the actual sampling moments, without the sound being so long and periodic that its remnants are eventually picked up in the beats with the sampling rate, and the anti-aliasing filters normally wipe that right out.
"Made from scratch from the freshest ingredients" is a problem. It often implies the rash you get when various software components haven't been tested in combination. And you'd better believe that compiler changes affect kernels and components, and that subtle changes in the use of internationalization can break lots of shell scripts, etc. Ask anyone who had to deal with the OpenSSH "privsep" feature when it came to operating systems other than OpenBSD.
That's no problem. The first installation CD could be a Knoppix CD to boot with, go Google hunting, and print out a report on the hardware so you can see if it can hope to boot the target OS.
Don't laugh too hard. I regularly do this with Windows hardware to find and pre-download drivers for it that are not part of the basic OS install, especially the network drivers for newer chipsets, and to run tests for hardware trouble.
I suggest you look into the South African boycotts, and how many shareholders in fact successfully forced their investment companies to participate in the boycott. I also suggest you look into the various non-profit companies, and commercial company charters, to see that the actual goals of the company may not be shareholder profits.
It's a common belief, taught in many early level MBA courses and management training meetings, that shareholder profit is all. But it's simply not true in law, in theory, or in real life.
OpenSSH seems to be the only component of OpenBSD development that most people care about. The old BSD licensing creates a legal problem to port the code over to GPL or another more common modern license. And since so much absolutely essential modern code is GPL, such as gcc and glibc and zlib and bash, and the most commonly used versions of sed and ls and mkdir and rm, there's no support for going to a BSD licensed OS.
Linux has won this market share battle. Take the solid programmers off of OpenBSD and move over to the Linux world where their expertise can be respected and they can actually make a bit of cash doing custom deployments: I know several companies that would have been happy to dump the F-Secure versions of SSH if they could have gotten good support agreements to make customized installations and 6-hour turnaround on support calls. And the tools generated for those would have gone into the public pool of good tools. Integrating SSH properly into Perforce within a month would have been a $50,000 paycheck. An scp server that didn't require users to have valid local shells and used actual chroot cages to prevent clients from being able to probe system files would ahve been another $50,000. (I had the buy-in from management to make an offer: I couldn't get the OpenBSD developers of the time to take my calls, they weren't interested in doing Linux support.)
Instead, they wasted their time on the "privsep" features that destabilized the product, didn't work right on many OS's, didn't fix any existing approaches. And now they're whining about how Sun turned it off in SunSSH? And because they didn't use GPL, Sun can keep their source for SunSSH closed.
If OpenBSD is sputtering, it's time to fork OpenSSH.
Heck, I've patched libraries with sed and edited binaries with Emacs. It's certainly possible, although I did have root priveleges to do it, and this predates SSH. It even predates ddd and X-Windows!
Slashdot Mirror
You shouldn't have to run Java to install Java. And given the size of Websphere and the incompatibilities between Java releases, they should include their own.
This is heavily dependent on the DVD player. Everytime a player has notes for this published, the manufacturer very quickly "updates" it to avoid getting in trouble with the DVD vendors and advertisers, and to keep their license for the software that decodes DVD's.
It's a nasty business, and exactly why so many people are willing to do what has been ruled to be illegal and use the libdvdcss library to rip new DVD's, or record the movie from them directly for local viewing. But look for this to fail completely when the "Trusted Computing" tools take hold of hardware management: it will become far more difficult.
Agreed. The closed source community is notorious for doing amazingly brain-dead things and lying about patching it.
But notice that the closed-source/opoen-source involved here has almost nothing to do with the nature of the operating system: it has to do with the development models for rootkits themselves. The rootkit developers are sharing their information, and frankly, they should share it. Otherwise, these holes will remain in place and fester and be passed around behind doors that are barely closed at all: they always have been, since long before the release of the original Morris Worm.
Why write on paper rather than on stone blocks? Because it's cheaper and portable! Seriously, some actual use of USB drives shows how handy they are for storing data in a place where electricity is unreliable and laptops are prone to failure with a repair time of weeks or months. How to protect them from theft is a real problem, of course.
But a $10 USB drive can hold a soldier's email from home, some music to share with their friends, their transfer orders, a map of the local area's targets for the next day, and the combination for the food locker. Like paper and pencil, they're just too useful to deny to the troops: the key is to make sure they're used properly.
Oh, the data access for the laptops is a part of absolutely necessary infrastructure fo the laptops to be useful. It won't be ubiquitous until the infrastructure is expanded, but a few community satellite phones with wireless ports would expand the available network coverage vastly, even if it's only for a few hours a day as someone travels from village to village with the satellite phones on a bicycle.
There are limits: when people start climbing out of poverty, making email and web searching and the ability to handle communications and money and look up things like weather and the price of crops can really help them, in ways that another few bags of food will not. Don't underestimate the improvement that a laptop, able to store weather reports and store information about medical services and lessons for kids and that ugly green spot on grandpa's foot can help a family in fiscal straits.
Then throw out internationalization: the Unicode support and massive proliferation of useless language add-ons is one of the greatest flaws of the current commercial distributions of Linux.
Take a good look at how many of the available core packages in your favorite distribution are for international language nonsense you don't need and will never use.
No, evolution is a mail client from Novell, which provides a semblance of support for Microsoft Exchange-based Linux clients.
Or did you mean something else?
The Clipper Chip was discarded by the NSA, partly because of the patent violations they engaged in and were eventually caught at, and partly because having developed it in secret with the only extrernal review being from untrustworthy and insufficiently competent people like Dorothy Denning, they made a big mistake: they used an insufficiently long checksum to verify that the keys used were the ones kept in the never-agreed-upon government-held repository. So it was quite feasible to generate and use your own keys on the device, if you gave them roughly 45 minutes to negotiate new keys. That made the device usably secure for some of the most important communications, such as trans-Atlantic fiscal operations, which the NSA would love to be able to continue to monitor.
Good! I didn't realize the latest fibers were that fast. So a set of network monitors only capable of logging 100 MHZ links would have to be installed somewhere downstream, where the network connectivity begins to fan out, and wind up distributed among multiple loggers.
I'm not shocked, but suspect that that's still the logical place to put the monitoring. It should be straightforward to force any traffic of interest to pass through the monitoring systems with their control of the routers.
This is irrelevant. AT&T still owns a huge share of the land-lines, and of the trans-continental and trans-oceanic links, which is where such monitoring devices would be place. Just because the phone in your house, or your local ISP, is secure doesn't mean your traffic is safe.
Using Verizon as your ISP is no defense: if your traffic passes over AT&T owned wire, to or from your destination, you are vulnerable to this kind of snooping. This is particularly true for international traffic, much of which is over fiber-optic cable owned by AT&T. The routers connecting to those cables are one of the best possible places for network monitoring, and you'd better believe that the NSA is happy to install it there, with AT&T cooperation.
There are certainly tools that can track and record every byte sent on every port on a saturated 100 MHz link, and write it to local disk. Given that the trans-atlantic links are rarely GigE capable, a rack of such devices should easily monitor and re-assemble all the traffic desired. www.sandstorm.com, for example, sells exactly that sort of monitoring tool called "Netintercept", commercially. There's no reason to think the NSA doesn't use them or hasn't reverse engineered them.
You have *got* to be kidding.
Microsoft's history of violating patent law and copyright law. Famous incidents like the Microsoft Mouse and the theft of VMS code for the creation of NT are the tiniest tip of the iceberg: Microsoft, wisely, prefers to keep these cases quiet, overwhelm the plaintiffs with court expenses if necessary, and settle out of court when they have to.
As they developed, they regularly hired away developers from other companies and stole the copyrighted or patented work those developers did elsewhere: it's why they're so sensitive to the risk of their own employes(TM)eaving.
For a lot of copyrighted material, DRM could have some use. Trusted Computing, for example, could be used to manage DVD's and CD's in a sane way rather than the current and fundamentally insane approach used by RIAA.
However, for patents, it's not reasonable. A patent, even a software patent, is easily implemented in a different way that DRM has no way to detect. Simply write the software in a different computer language and DRM will little or no hope of detecting the violation.
This is actually not a big problem: the Linux kernel, like new editions of encyclopedias and school textbooks, would have new copyrights on new kernel releases. Copyright law is different from patent law: let's not get them too mixed up.
Manuals for hardware, unfortunately, are now deliberately incomplete in order to protect the "secret sauce" of the manufacturers. BIOS's, network chipsets, and CPU's all have numerous hidden features that reveal details of the design. In fact, revelations of the details in design manuals could leave the manufacturers open to patent lawsuits: as companies gather large patent suites, not to enforce patents, but as protective arsenals to protect against lawsuit, it makes it very difficult to innovate without accidentally violating an unrevealed or obscure patent that may be invalid, but a small company or developer may not have the resources to battle in court.
The result is stifling to innovation.
Please, God. Let Microsoft succeed in invalidating the MPEG patents! Please!
But a microphone with a limited frequency range can often capture interesting waveform phenomonea, although attenuated, at well above that frequency. And the temporal data of precisely when which sound started and ended and changed amplitude is still intact, at a much higher temporal resolution than the frequency of the microphone itself. Digitization destroys much of that information, and creates fascinating uncertainties in the temporal information related to the sampling interval. That is actually noticeable to a good ear.
Yes, I'd like to use that "incorrect" score on your post. The error is early, where you said "as long as the signal does not contain any frequency components above 22.05 kHz". Of courese there is information above that sample rate! It's not critical for speech, but for music the sound extends well above that frequency. While such frequencies are nominally "ultrasonic", they're well within the auditory perception of some people and they do affect the shape of auditory waveforms that reach the ear, and especially of timing information among crisp sounds, like high frequency percussion instruments and the character of especially rich sounds like violins.
The microphones had poor reception at higher frequencies, but the signal is still there to some extent. And let's face it: the microphones being used for modern digital recording are usually a poor substitute for the old microphones used for high-quality LP recordings, just as cheap and ubiquitous digital cameras are not yet a substitute for a good quality old camera, due to the undersampling of the visual field.
I don't begrudge the world preservable digital music, or cheap music players. And certainly CD quality surpasses that of cheap LP's, or of worn out ones that the kids have played with and worn scratches in it. But for the high quality LP's, it really makes a noticeable difference.
"Non-lossy" is not the problem. The extremely limited sample rate of the published standards is not soluble without actually changing the standard, even if compression improves or disk space increases and we have no limit there.
The old LP's recorded quite a bit of both high frequency and low frequency information that digitization invariably throws out due to the pitifully low sample rates. No amount of digital processng or massaging can recover information that is entirely in between the actual sampling moments, without the sound being so long and periodic that its remnants are eventually picked up in the beats with the sampling rate, and the anti-aliasing filters normally wipe that right out.
"Made from scratch from the freshest ingredients" is a problem. It often implies the rash you get when various software components haven't been tested in combination. And you'd better believe that compiler changes affect kernels and components, and that subtle changes in the use of internationalization can break lots of shell scripts, etc. Ask anyone who had to deal with the OpenSSH "privsep" feature when it came to operating systems other than OpenBSD.
That's no problem. The first installation CD could be a Knoppix CD to boot with, go Google hunting, and print out a report on the hardware so you can see if it can hope to boot the target OS.
Don't laugh too hard. I regularly do this with Windows hardware to find and pre-download drivers for it that are not part of the basic OS install, especially the network drivers for newer chipsets, and to run tests for hardware trouble.
My goodness, you're right! I thought it was. OK, substitute "gzip" for "zlib" everywhere I wrote it.
I suggest you look into the South African boycotts, and how many shareholders in fact successfully forced their investment companies to participate in the boycott. I also suggest you look into the various non-profit companies, and commercial company charters, to see that the actual goals of the company may not be shareholder profits.
It's a common belief, taught in many early level MBA courses and management training meetings, that shareholder profit is all. But it's simply not true in law, in theory, or in real life.
OpenSSH seems to be the only component of OpenBSD development that most people care about. The old BSD licensing creates a legal problem to port the code over to GPL or another more common modern license. And since so much absolutely essential modern code is GPL, such as gcc and glibc and zlib and bash, and the most commonly used versions of sed and ls and mkdir and rm, there's no support for going to a BSD licensed OS.
Linux has won this market share battle. Take the solid programmers off of OpenBSD and move over to the Linux world where their expertise can be respected and they can actually make a bit of cash doing custom deployments: I know several companies that would have been happy to dump the F-Secure versions of SSH if they could have gotten good support agreements to make customized installations and 6-hour turnaround on support calls. And the tools generated for those would have gone into the public pool of good tools. Integrating SSH properly into Perforce within a month would have been a $50,000 paycheck. An scp server that didn't require users to have valid local shells and used actual chroot cages to prevent clients from being able to probe system files would ahve been another $50,000. (I had the buy-in from management to make an offer: I couldn't get the OpenBSD developers of the time to take my calls, they weren't interested in doing Linux support.)
Instead, they wasted their time on the "privsep" features that destabilized the product, didn't work right on many OS's, didn't fix any existing approaches. And now they're whining about how Sun turned it off in SunSSH? And because they didn't use GPL, Sun can keep their source for SunSSH closed.
If OpenBSD is sputtering, it's time to fork OpenSSH.
Heck, I've patched libraries with sed and edited binaries with Emacs. It's certainly possible, although I did have root priveleges to do it, and this predates SSH. It even predates ddd and X-Windows!