I'm sorry, but this is mistaken. I've probably installed 50 different Linux systems in the last month. Half of them were in stripped down hardware, with no compiler, no software building tools, no unnecessary packages, and no development tools. They're quite bulky and unnecessary for most use: leaving them out helped reduce the software size enough to help ease backup requirements and disk requireements quite a lot.
Now, separating the documents out into -doc packages would make a huge amount of sense. There's a big bundle of user guides and complex documentation that's just not necessary in most installations as well, but should be available to developers.
It's not MSI itself: it's the standards of "put programs in certain places", "put libraries with the programs", and "give your libraries unique locations and names". If you fail to do that, you get reported errors by MSI as it attempts to overwrite another package.
RPM and apt have the same problem with conflicting packages: it's the authors of the packages, not the conflicting packing tools, that create the conflicts.
It's gotten better: the Fedora Core 6 version, with the various plug-ins, is very about as good as apt. Point it to your base repositories and to a good extra package repository like Livna, and it's a match for apt.
Yum was slow for solid technical reasons: the repository information was inefficient, there weren't enough fast RPM mirrors, and the db4 database behind RPM was painful.
Fortunately, db4 seems to be dead: it's been replaced in such lightweight applications by SQLite, there are a lot more and faster mirrors available, and the repository information is stored more effiently, or at least handles a lot faster with faster modern machines. So it's overall gotten a lot better: take a look at the versions of the past year or two to see how good it's gotten.
Older versions of Yum and RPM didn't cleanly handle any RPM operations done at the same time as Yum: this tended to corrupt the database. That said, there are also useful updates to Yum and toe the underlying RPM and database tools you probably want to make sure are updated. And if you're still running Fedoare Core 1 or Fedora Core 2, you're getting what you deserve: do a clean update and I suspect you'll be very pleased with the improvement.
It's not physically possible to resolve management of all the major package types. The reporting of necessary components, and of requirements, and of how new replacing local configuration files are done, post-execution scripting, restarting of active services after replacement, how package components are provided, etc., are all wildly different.
Every dependency system has that, including RPM, pkg, apt, and even Perl's CPAN setup. Resolving dependencies like that is not something bare RPM can do on its own: it needs some sort of knowledge of the various places you might pull software from and resolve the discrepancies, like Yum attempts to do, on top of RPM. Different programs all use common utilities, like modutils and tar and glibc and OpenSSL and popular Perl libraries: updating one of them may mean needing to update the others.
The people who think this is easy to solve are the people who are happy to update 15 packages to fix one program that has a dependency it doesn't even really need on an upgraded version of another, trivial package, and then are surprised when they destabilize their whole OS because the other 1500 packages have never been tested with those new 15.
It runs on almost all OS's, the encryption is good, it supports a good chat client, it doesn't clutter your disk or your desktop or your toolbar with "features" that no one wants, it's easy to install, it's easy to uninstall, and in my expereince the voice client is quite acceptable in its quality, even for international calls. It's certaiinly safer to use than jabber, zephyr, and many other pitifully insecure open source tools, and much friendlier and more available than MSN's or AOL's tools.
It didn't take much advertising, although advertising helped. It's a well-built, workable, robust tool, like a really good screwdriver that's actually comfortable to use.
X is also amazingly bloated and overblown, or at least the tremendous variety of toolkits superglued on top of it are. It's quite painful to make something effective, thorough, and fast enough to support modern games on top of it with any of the X toolkits. And they do tend to conflict with each other in subtle ways: X needs a real cleanup, which Xorg seems to be trying to do in the quiet background behind their feature additions, but it's painful.
Go take a look at http://en.wikipedia.org/wiki/LinuxBIOS. It seems that a huge amount of boot time is wasted in hardware scanning and detection, most of it with proprietary drivers, and much of it designed to work around hardware flaws and API violations which hardware vendors refuse to discuss or publish fixes for: they only provide their own custom "drivers" that the OS is forced to load from customized boot media. The result is a massive layer of often inconsistent and incompatible driver loading and scanning, and a huge waste of time and BIOS resources to find and load these expensive and unreliable workarounds.
Re:What about the rest of the world?
on
HR 5252 Bill Dies
·
· Score: 1
Right now, most backbone network providers would like to be able to provide less quality of service or charge more for things they don't want to carry. This includes VOIP, BitTorrent, and video streaming that people find handy now, and that they can't easily make into second class services. Many of them would like to force such traffic to either cost more, or to only be carried with such high quality if it originates from inside their own network and goes to hteir own network, making their larger networks more valuable and preventing smaller companies from providing such high levels of connectivity.
These companies want to create a high-bandwidth, higher quality infrastructure for which they can charge more but don't have to build the infrastructure to support for everyone, only for those privileged expensive customers. This is even more important with the growth of video streaming, for shows and movies. They don't want to provide enough bandwidth and support for that without charging a premium, and they don't want to provide that bandwidth for small competitors with peering agreements.
I assume you've never practiced with a staff (which admittedly is blunt on both ends), or with some of the more interesting Oriental and medieval weapons. A lightsaber built that way is insane, admittedly, since too much of it is blade that can cut the wielder to ribbons. But staves are surprisingly effective against swords, in practice and in real life, as long as they're tough enough to withstand sword edges.
I've done some staff training: I never got really good, but was very impressed with their effectiveness against even skilled opponents with other, more popular melee weapons. They're especially fun against 2-sword fighters.
And it does happen. Programmers leave themselves emergency back doors to do unauthorized work. Keep an eye open for what the chief sys-admins hide or disconnect when a telephonen survey to detect unauthorized modems is done, and how they carefully watch for the day the survey is happening.
It's really fun to do the survey secretly first, then announce it, then run it again to see which modems get disconnected.
For a good 10-minute lightsaber battle, you need the Darth Maul scene in The Phantom Menace. That quarterstaff wielding lunatic was absolutely fabulous, insanely quick, and clearly a master of his weapon. And he ws having *fun*, not only fighting but actively embarassing his opponents with his wildly superior skill.
The Seven Samurai was also wonderful, and much more faithful to real sword fighting: the swordfights were as faithfully done as you could with the available movie techniques.
The kid didn't have or need special skills. They were around for the hardware being rebooted, and the tools being used provided automatic basic access for dedicated terminals in the data center. That's fairly normal for a dedicated network operations center, or control center for a physical plant, especially early on before enough non-privileged employees are in place to justify setting up security that will interfere with critical work. If you've got keys or access to the room, you're assumed to be trustworthy.
Also, remember that the core designer was a greedy, overwhelmed contractor, and about to steal stuff. He would *deliberately* leave the security a mess to ease his theft, and blame the poor security on being underpaid and not having it on his tasklist. That kind of security hash is unfortunately quite common: How many of your core servers are redundant, with unique passwords, no backdoors, a BIOS password to prevent booting from a USB stick, etc., etc., etc.
I've seen the exact same thing where the IT people fight having hardware management and inventory, because it turns out they're ripping off equipment for home use as a "perk" of the job.
But it would cost them a lot of money, losing their "We have to run Windows, darn it!" monopoly base. Remember that they destroyed Netscape's business model when they bundled Internet Explorer and violated various HTML specs, and pulled similar stunts with their modifications of Kerberos. This discourages other software competitors, and that's a good business move for Microsoft, wven where it's illegal.
The anti-trust fire is simply a cost of doing a highly profitable business for them: they've successfully stalled such cases to death for years now. They're trying to do it even more now with so-called Trusted Computing, to block other software installations and especially software access to CD and DVD drives, and they tried it with their WinFS filesystem which was burdened with a Microsoft patented XML basis, and fortunately seems to have died like the dog it was.
Stapling security on after product release always means a lot less efficient code, and a lot of hand-written checks to fix what should never have been done without breaking advertised features. Couple this with the corporate desire for integral DRM, to authorize software and hardware access against Microsoft's Trusted Computing initiative, and you need considerably faster hardware to support streaming access to video and audio media with the computationally expensive DRMware in the way.
All other feature reasons aside, that's a compelling reason for Microsoft to demand more CPU and bandwidth in your hardware to run Vista.
These are adult stem cells in the body of the diabetic: there is no implantation of new stem cells, so I would think that the cancer risk is not increased by the stem cells. Rather, tweaking the autoimmune system is asking for trouble: it's complex, it's not well understood, and changing one feature often changes others. So an increase in cancer risk is a very real one, one that researchers like Dr. Faustman with her background in auto-immune research directly involving cancer will take very seriously.
The lab animals do not have human diabetes: they have a chemically induced form of Type 1 diabetes. And five years is hardly enough to test the safety of a treatment that is turning on, and off, significant chunks of your immune system. Also, good animal studies cost serious money to do: good human studies cost even more. Even though Type 1 diabetes has serious health risks, expect some caution with this treatment.
If you're paranoid and nasty, you might also look at the influence of companies like Eli Lilly on NIH of medical research: the market for insulin is very profitable, and a very stable market. They'll encourage further study and testing while preparing to see the market shrink by a huge amount.
The Trusted Computing tools are already planned for inclusion in the next generation of both Intel and AMD CPU's. There's no chip to turn off: it will be a CPU feature that may or may not be de-activated on request, but getting the system booted far enough to turn the feature may require access to an authorized software tool itself. And hardware such as DVD's, CD's, USB sticks, and hard drives are clearly planned to include Trusted Computing access control. That can help prevent unauthorized users from using stolen equipment, but also will prevent use of them by non-Microsoft-signed software.
It's worse than you imagine. There is no clear policy on who will obtain the master keys for Palladium or Trusted Computing signature authorities: as things stand, Microsoft will own and sell such authorities. New software signatures must be purchased. This effectively grants Microsoft tremendous access to other company's, or person's trusted keys, and makes installing your own personally created keys prohibitively difficult.
This also provides BIOS and booatable hardware DRM, in order to control over booting systems. While such is good from a security standpoint, it means that with very trivial changes in hardware such as DRM-managed CD and DVD and USB devices, nothing other than a host-designated, signed Windows operating system will be able to boot the machine enough to install new keys and install a new OS. While the designer of such technologies may not envision such abuse, it's certainly within Microsoft's history of anti-competitive behavior to do this.
Unfortunately, a huge percentage of phishing is due to unfortunate Microsoft design decisions that they don't want to reverse. The "you can click on anything, even though it's not actually a URL" and the "we don't actually clearly show the contents of clickable links" decsions in Internet Explorer are key to many phishing scams. And pursuing a few easily prosecuted phishers does nothing to actually reduce phishing: it's easy publicity, but phishing is just too darned easy and too difficult to prosecute.
You don't get out much, do you? Mexican fruit pickers and restaurant staff in Texas and California, Polish construction workers in Germany, the Chinese workers who built much of the US trans-continental railroad, doctors from Cuba and Southeast Asia, etc., all represent actually such imported labor. Plenty of such "import foreign workers" policies exist, wherever local workforces are not unionized to oppose it and are in high demand.
Managers are often paid per head that they manage, and given bonuses for "cost control", not product quality. Hiring cheap foreign workers instead of a more competent, highly paid local engineer who may also know how to oppose their management decions is obviously in their best interests.
Slashdot Mirror
I'm sorry, but this is mistaken. I've probably installed 50 different Linux systems in the last month. Half of them were in stripped down hardware, with no compiler, no software building tools, no unnecessary packages, and no development tools. They're quite bulky and unnecessary for most use: leaving them out helped reduce the software size enough to help ease backup requirements and disk requireements quite a lot.
Now, separating the documents out into -doc packages would make a huge amount of sense. There's a big bundle of user guides and complex documentation that's just not necessary in most installations as well, but should be available to developers.
It's not MSI itself: it's the standards of "put programs in certain places", "put libraries with the programs", and "give your libraries unique locations and names". If you fail to do that, you get reported errors by MSI as it attempts to overwrite another package.
RPM and apt have the same problem with conflicting packages: it's the authors of the packages, not the conflicting packing tools, that create the conflicts.
It's gotten better: the Fedora Core 6 version, with the various plug-ins, is very about as good as apt. Point it to your base repositories and to a good extra package repository like Livna, and it's a match for apt.
Yum was slow for solid technical reasons: the repository information was inefficient, there weren't enough fast RPM mirrors, and the db4 database behind RPM was painful.
Fortunately, db4 seems to be dead: it's been replaced in such lightweight applications by SQLite, there are a lot more and faster mirrors available, and the repository information is stored more effiently, or at least handles a lot faster with faster modern machines. So it's overall gotten a lot better: take a look at the versions of the past year or two to see how good it's gotten.
Older versions of Yum and RPM didn't cleanly handle any RPM operations done at the same time as Yum: this tended to corrupt the database. That said, there are also useful updates to Yum and toe the underlying RPM and database tools you probably want to make sure are updated. And if you're still running Fedoare Core 1 or Fedora Core 2, you're getting what you deserve: do a clean update and I suspect you'll be very pleased with the improvement.
It's not physically possible to resolve management of all the major package types. The reporting of necessary components, and of requirements, and of how new replacing local configuration files are done, post-execution scripting, restarting of active services after replacement, how package components are provided, etc., are all wildly different.
Every dependency system has that, including RPM, pkg, apt, and even Perl's CPAN setup. Resolving dependencies like that is not something bare RPM can do on its own: it needs some sort of knowledge of the various places you might pull software from and resolve the discrepancies, like Yum attempts to do, on top of RPM. Different programs all use common utilities, like modutils and tar and glibc and OpenSSL and popular Perl libraries: updating one of them may mean needing to update the others.
The people who think this is easy to solve are the people who are happy to update 15 packages to fix one program that has a dependency it doesn't even really need on an upgraded version of another, trivial package, and then are surprised when they destabilize their whole OS because the other 1500 packages have never been tested with those new 15.
It runs on almost all OS's, the encryption is good, it supports a good chat client, it doesn't clutter your disk or your desktop or your toolbar with "features" that no one wants, it's easy to install, it's easy to uninstall, and in my expereince the voice client is quite acceptable in its quality, even for international calls. It's certaiinly safer to use than jabber, zephyr, and many other pitifully insecure open source tools, and much friendlier and more available than MSN's or AOL's tools.
It didn't take much advertising, although advertising helped. It's a well-built, workable, robust tool, like a really good screwdriver that's actually comfortable to use.
X is also amazingly bloated and overblown, or at least the tremendous variety of toolkits superglued on top of it are. It's quite painful to make something effective, thorough, and fast enough to support modern games on top of it with any of the X toolkits. And they do tend to conflict with each other in subtle ways: X needs a real cleanup, which Xorg seems to be trying to do in the quiet background behind their feature additions, but it's painful.
Go take a look at http://en.wikipedia.org/wiki/LinuxBIOS. It seems that a huge amount of boot time is wasted in hardware scanning and detection, most of it with proprietary drivers, and much of it designed to work around hardware flaws and API violations which hardware vendors refuse to discuss or publish fixes for: they only provide their own custom "drivers" that the OS is forced to load from customized boot media. The result is a massive layer of often inconsistent and incompatible driver loading and scanning, and a huge waste of time and BIOS resources to find and load these expensive and unreliable workarounds.
Right now, most backbone network providers would like to be able to provide less quality of service or charge more for things they don't want to carry. This includes VOIP, BitTorrent, and video streaming that people find handy now, and that they can't easily make into second class services. Many of them would like to force such traffic to either cost more, or to only be carried with such high quality if it originates from inside their own network and goes to hteir own network, making their larger networks more valuable and preventing smaller companies from providing such high levels of connectivity.
These companies want to create a high-bandwidth, higher quality infrastructure for which they can charge more but don't have to build the infrastructure to support for everyone, only for those privileged expensive customers. This is even more important with the growth of video streaming, for shows and movies. They don't want to provide enough bandwidth and support for that without charging a premium, and they don't want to provide that bandwidth for small competitors with peering agreements.
I assume you've never practiced with a staff (which admittedly is blunt on both ends), or with some of the more interesting Oriental and medieval weapons. A lightsaber built that way is insane, admittedly, since too much of it is blade that can cut the wielder to ribbons. But staves are surprisingly effective against swords, in practice and in real life, as long as they're tough enough to withstand sword edges.
I've done some staff training: I never got really good, but was very impressed with their effectiveness against even skilled opponents with other, more popular melee weapons. They're especially fun against 2-sword fighters.
And it does happen. Programmers leave themselves emergency back doors to do unauthorized work. Keep an eye open for what the chief sys-admins hide or disconnect when a telephonen survey to detect unauthorized modems is done, and how they carefully watch for the day the survey is happening.
It's really fun to do the survey secretly first, then announce it, then run it again to see which modems get disconnected.
For a good 10-minute lightsaber battle, you need the Darth Maul scene in The Phantom Menace. That quarterstaff wielding lunatic was absolutely fabulous, insanely quick, and clearly a master of his weapon. And he ws having *fun*, not only fighting but actively embarassing his opponents with his wildly superior skill.
The Seven Samurai was also wonderful, and much more faithful to real sword fighting: the swordfights were as faithfully done as you could with the available movie techniques.
The kid didn't have or need special skills. They were around for the hardware being rebooted, and the tools being used provided automatic basic access for dedicated terminals in the data center. That's fairly normal for a dedicated network operations center, or control center for a physical plant, especially early on before enough non-privileged employees are in place to justify setting up security that will interfere with critical work. If you've got keys or access to the room, you're assumed to be trustworthy.
Also, remember that the core designer was a greedy, overwhelmed contractor, and about to steal stuff. He would *deliberately* leave the security a mess to ease his theft, and blame the poor security on being underpaid and not having it on his tasklist. That kind of security hash is unfortunately quite common: How many of your core servers are redundant, with unique passwords, no backdoors, a BIOS password to prevent booting from a USB stick, etc., etc., etc.
I've seen the exact same thing where the IT people fight having hardware management and inventory, because it turns out they're ripping off equipment for home use as a "perk" of the job.
But it would cost them a lot of money, losing their "We have to run Windows, darn it!" monopoly base. Remember that they destroyed Netscape's business model when they bundled Internet Explorer and violated various HTML specs, and pulled similar stunts with their modifications of Kerberos. This discourages other software competitors, and that's a good business move for Microsoft, wven where it's illegal.
The anti-trust fire is simply a cost of doing a highly profitable business for them: they've successfully stalled such cases to death for years now. They're trying to do it even more now with so-called Trusted Computing, to block other software installations and especially software access to CD and DVD drives, and they tried it with their WinFS filesystem which was burdened with a Microsoft patented XML basis, and fortunately seems to have died like the dog it was.
Stapling security on after product release always means a lot less efficient code, and a lot of hand-written checks to fix what should never have been done without breaking advertised features. Couple this with the corporate desire for integral DRM, to authorize software and hardware access against Microsoft's Trusted Computing initiative, and you need considerably faster hardware to support streaming access to video and audio media with the computationally expensive DRMware in the way.
All other feature reasons aside, that's a compelling reason for Microsoft to demand more CPU and bandwidth in your hardware to run Vista.
You're using the wrong lab animal:
http://www.i-duck.co.uk/
These are adult stem cells in the body of the diabetic: there is no implantation of new stem cells, so I would think that the cancer risk is not increased by the stem cells. Rather, tweaking the autoimmune system is asking for trouble: it's complex, it's not well understood, and changing one feature often changes others. So an increase in cancer risk is a very real one, one that researchers like Dr. Faustman with her background in auto-immune research directly involving cancer will take very seriously.
The lab animals do not have human diabetes: they have a chemically induced form of Type 1 diabetes. And five years is hardly enough to test the safety of a treatment that is turning on, and off, significant chunks of your immune system. Also, good animal studies cost serious money to do: good human studies cost even more. Even though Type 1 diabetes has serious health risks, expect some caution with this treatment.
If you're paranoid and nasty, you might also look at the influence of companies like Eli Lilly on NIH of medical research: the market for insulin is very profitable, and a very stable market. They'll encourage further study and testing while preparing to see the market shrink by a huge amount.
The Trusted Computing tools are already planned for inclusion in the next generation of both Intel and AMD CPU's. There's no chip to turn off: it will be a CPU feature that may or may not be de-activated on request, but getting the system booted far enough to turn the feature may require access to an authorized software tool itself. And hardware such as DVD's, CD's, USB sticks, and hard drives are clearly planned to include Trusted Computing access control. That can help prevent unauthorized users from using stolen equipment, but also will prevent use of them by non-Microsoft-signed software.
It's worse than you imagine. There is no clear policy on who will obtain the master keys for Palladium or Trusted Computing signature authorities: as things stand, Microsoft will own and sell such authorities. New software signatures must be purchased. This effectively grants Microsoft tremendous access to other company's, or person's trusted keys, and makes installing your own personally created keys prohibitively difficult.
This also provides BIOS and booatable hardware DRM, in order to control over booting systems. While such is good from a security standpoint, it means that with very trivial changes in hardware such as DRM-managed CD and DVD and USB devices, nothing other than a host-designated, signed Windows operating system will be able to boot the machine enough to install new keys and install a new OS. While the designer of such technologies may not envision such abuse, it's certainly within Microsoft's history of anti-competitive behavior to do this.
Unfortunately, a huge percentage of phishing is due to unfortunate Microsoft design decisions that they don't want to reverse. The "you can click on anything, even though it's not actually a URL" and the "we don't actually clearly show the contents of clickable links" decsions in Internet Explorer are key to many phishing scams. And pursuing a few easily prosecuted phishers does nothing to actually reduce phishing: it's easy publicity, but phishing is just too darned easy and too difficult to prosecute.
You don't get out much, do you? Mexican fruit pickers and restaurant staff in Texas and California, Polish construction workers in Germany, the Chinese workers who built much of the US trans-continental railroad, doctors from Cuba and Southeast Asia, etc., all represent actually such imported labor. Plenty of such "import foreign workers" policies exist, wherever local workforces are not unionized to oppose it and are in high demand.
Managers are often paid per head that they manage, and given bonuses for "cost control", not product quality. Hiring cheap foreign workers instead of a more competent, highly paid local engineer who may also know how to oppose their management decions is obviously in their best interests.