*Sigh* . . . It seems that no one really does much research into CPU and computer system design anymore. All the major archetectures are pretty homogenized, they are either full RISC machines (probably a tad bloated with too many instructions) or RISC machines emulating a CISC instruction set (x86). RISC seems the last fundemental change in hardware design, the processors get smaller and faster but not much really changes.
One thing that I like, at least as a concept, is the IBM S/390. The IBM Mainframe and its customers have been living in a pretty insular world over the last 20 years and the hardware/software that runs on this beast is just, different. Some things are goofy, IIRC it boots off an emulated punch card reader (!!), or nifty, like the magic migrating storage system.
Re:high-class SMP on x86? but *why?*
on
Emergence of SMT
·
· Score: 2
While in many senses you are right I think you are pointing to the wrong issue. It is not something inherent in the x86 arch that causes problems in scaling it is mostly Intel's SMP bus design. Having all the CPU's share a single, shared, bus between each other and system memory is the bottleneck. I mean, look at the Athalon, it isn't riding on an Intel designed bus, it rides on a DEC desigend EV6, originally made for the Alpha.
While Beowulf is a nifty technology, it does not solve all the scaling problems as you might think. Beowulf clusters are only useful for a specific subset of available problems, stuff that can be easily split up and sent to many, semi-independent, processing nodes. Beowulf clusters are generally connected together with 1Gb or 100Mb Ethernet which does not have high bandwidth or low latency compared to the CPU-Memory bus in even the cheapest computers. I would take a single 128 CPU box over 64 dual proc boxes connected via 1Gb Ethernet (or even Myrinet) any day.
IIRC SuSE is already turning a profit, RedHat (if current trends continue) should be turning a profit by next year. While this isn't the goldrush of last year, and there probably isn't currently room for a lot of large Linux-only players, there is plenty of money to be had.
Argh. They are not introducing a new species here, only a sterile variant of the existing species. And since the new moths are sterile they can't produce offspring. In other words, no 50ft mutant moths are going to be moving in next door anytime soon.
Hey, if the killer bees suck in cold weather, won't that naturally prevent them from encroaching very far north? If they are less capable as bees then shouldn't they (eventually) be beat out by the existing bee population. This may take several hundred years to fix but, hey, live and learn.
While you don't have to trust my opinion on the matter you should at least try to make a reasonable argument. These genetic engineers didn't just fall off the turnip truck yesterday, also they are all not Dr. Frankenstien. This isn't some random tampering (think radiation) this is a limited modification to a reasonably simple organism. And I will repeat, the resulting moths are sterile, they cannot reproduce so there is no realistic chance that they could get out of control.
Argh. So many people hear the phrase "Genetic Engineering" and immediately think "Attack of the Killer 50ft Spitting Wombat!" instead of actually thinking.
I know bioengineering holds great promise...but releasing genertically engineered insects into the wild (I'm assuming they will do that after this test...) is a crapshoot. There are an infinite number of variables in the ecosystem, there is just no way to account for them all.
No, no, no. There are an infinite number of variables everywhere, if we had to wait for perfect understanding of the universe before any experiment we would never expiriment (chickent and egg). I think that you are improperly assigning risk to the different methods of genetic engineering. You have:
Breeding, since the days of Mendel
Irradiation, now this is potentially more dangerous but until now was the accepted way to generate sterile insects
Direct Genetic Engineering, very careful and selective editing of genes to:
Make specific and limited change
Tag organisim so it can be easily identified in wild for tracking purposes
Make sure organism is absolutely sterile, and optionally has a shorter lifespan
Wasn't it just last summer that the we had a problem with some type of genetically enhanced corn that was being tested but decided to spread itself via the wind all across the midwestern US? I think hundreds of farmers were financially ruined because their "infected" corn was not FDA approved for human consumption...
This does not appear to be accurate at all. The corn was engineered to have a naturally occuring toxin taken from annother plant, so that farmers would not have to use noxious, persistant pesticides on their crops. Unfortunately the toxin also was produced in the pollen and could poison insects that didn't actually try to eat the corn, ie. Monarch Butterflies eating pollen-dust covered milkweed near cornfields. Also the use of the word "infected" to describe the engineered corn is completely inaccurate and way off base.
Note that the genetically engineered corn was sterile, so there was no way for its pollen to cross breed with nearby, non-GE, corn. And no having the corn be sterile is not some evil Monsanto plot to rip everybody off, although that may be a fortunate side-effect. The reason is that when one has unforseen consequences such as this one can stop shipping the product and everything will return to normal. Also note that there are many commercial hybrid seeds, produced by normal cross-breeding, that produce sterile plants, think seedless grapes.
In short please leave your FUD (buzzword of the day!) at home, it has little place here.
Oh, well then, you are right and truly screwed. Looks like you are going to have to recompile XFree86 or install a binary package with freetype2 support in it. You still shouldn't have to recomple Qt and I am certain that you won't have to recompile KDE as it knows nothing about the anti-aliasing happening in Qt/XRender
While I can't confirm this right now I think you are over-thinking this upgrade. AFAIK all you need to do is upgrade the libqt.so library to 2.3.0 (rpm -U, apt-get) and set an environment variable (QT_XFT, or something). If your XFree 4.0.2 was compiled with XRender (xdpyinfo to make sure) then it should "Just Work"(tm).
That's not entirely true, if you didn't intend to run FTP or NFS services, they shouldn't be enabled. Random Joe Cracker can't break into a service that isn't running. Joe Newbie isn't going to know that running any version of wu-ftpd is probably a bad idea let alone keep up with the security fixes.
There isn't one single point of failure but a common trait to many of these boxes is that they are running an unmodified, out-of-the-box install of RedHat. Giving Joe Newbie what is in effect a loaded weapon, instead of a safe unloaded weapon, is bad netizenship. Having your cracked box used to ping flood my network is as much your fault as the crackers, and is detrimental to me in any case.
As far as competent versus incompetent admins go, a good distribution should handle those details much like current distributions handle making things like "ping" setuid root. In short, it should (mostly) transparently cut down on the exposure level of various security compromises.
If that is going to be the case then we are all doomed, doomed!! If major commercial Unix vendors took security seriously there wouldn't be a need for post-install hardning scripts like Bastille. If "Out of the Box Experience" wasn't perceived to be so important things like the Ramen worm would never happen, the machine would be tight by default.
That may be, but we've surpassed the security of their implementations long ago. (Security model on paper != security model actually in NT).
Hopefully we can get around the management problem of ACLs some time soon. Every OS where I have seen them implemented they were always too complicated to actually use. This lead to overly permissive ACLs being required because it would have been a mangement nightmare to do it the right way.
Re:What would we do differently in computing?
on
Rebooting The World?
·
· Score: 2
I wonder how much of this stuff kinda-sorta works with existing hardware. For example I am aware that many CPU's have more than two permissions contexts in their MMU but since UNIX only has kernelspace/userspace and root/non-root as its security these extra MMU bits aren't used (correct me if I am wrong, please). I am not aware what kind of stuff you can do on, for example, an x86 box when using ring 1-4 but I bet you could do something useful. Then again, maybe not, the hardware support probably only exists for backwards compatability purposes and isn't actually useful because of some unknown (to me) caveat.
While a registry system seems good on paper, the MS Windows implementation should be seen as a skull on a pike for anyone else wishing to implement similar functionality.
Should be human readable, at some point somebody is going to have read it and with today's CPU speeds there is no excuse for obtuse config options.
Should also be machine readable, most of the time it will be edited with full-featured tools. File should be in a standard format (XML?) and should have all the meta-data required to understand it accessable. Anyone remember IBM MCA.cfg files?
Should be _very_ lightweight and the absolute rock bottom, lowest common denominator of tools should be able to edit it. Can't fix a configuration when all the config tools require the system to be up and functional to work. (Even a journaling FS has fsck!)
System should scale from single machines to huge networks. The network is the computer (or some such, look at Plan 9 for ideas on network/computer relationships).
I think the point is to push the state of the art ahead, not fiddle with existing systems. I mean your analogy is similar to "Would you rather take a bicycle or a skateboard to fly to the moon" instead of researching how to make rockets.
Damn good point, you know there is still a small underground industry for things like hardcore wargames that only sell a few thousand or tens of thousands of copies. Going back to shareware would definitely be an improvement.
And for the truly paranoid, are you sure that in the 20 minutes they had your NRF ID they weren't analyzing it trying to make a copy. I'm sure the Russkies have a vast network of women's lingerie stores around potential military targets. And they are floridating the water 8^).
In my mind, it's not so much the notion of inventing something new, but rather to take these wonderful technologies to the realms of artists, writers, and designers to give them depth that goes WAY beyond the media constraints of TV or movies.
My idea, games should be about fun, not technology. No, I don't run around with my DEC PDP-1 saying "Spacewar is it, all other games are just derivitave trash", but gameplay must come first. Look at the store shelves sometime, most games are "Foo II" or "Bar 3 Ultra" or some such jazz, same gameplay, rehashed graphics. The last new genre that I can remember is the real-time stragety, and it has been published to death.
I'm using the RH6.2 binary packages for KDE 2.1beta2 and have experienced the same problems throughout my the kde2 releases. Very likely much of the core components were compiled without sufficient optimization but that can't really explain all of it. I noticed that URL type autodetection appears to be obscenely slow, specifying "kfmclient openURL http://slashdot.org text/html" appears to be faster.
Well then it's easy, an embedded Linux vendor can put their nads on the line (for $$$) when they sell you the product, of you wish. It's all the same, really.
I thought that I should just mention, to all those people recommending software solutions, they don't mean squat to someone willing to have the drive analysed by a professional data-recovery service. Mondern drives are getting harder and harder to erase this way and modern OS's don't help either, both abstract the actual physical data so much that you can't be abusolutely sure about anything.
Take ext2fs for example, to prevent fragmentation it stores files all over the surface of the disk, if a file grows in a way that would fragment it the entire file is moved to annother location on disk to prevent this fragmentation. That means you now have two copies of the file on disk.
There are also stupid bugs possible in this software (well, any software has bugs but . . . ). For example a couple of months ago someone on Bugtraq noted that shread (or wipe, I can't remember) truncated the file to 0 bytes before it overwrote it, this had the effect of creating a new file on disk and doing _nothing_ to the existing data, which can be recovered by a simple grep of the raw disk device.
Even if your wipe software works the hard disk itself abstracts the actual structure of the disk with things like automatic bad block relocation and such, making it impossible to know for certain that your sensitive data doesn't exist in a backup area of the hard drive.
I guess the important consideration is who are you trying to keep the data from, people who are going to use:
Software: If you expect that your attacker will be limited to accessing the disk using only normal software than dd if=/dev/zero of=/dev/hda would work fine.
Hardware: If someone is going to take apart the drive (business rival, military foe) then nothing short of melting your drive into slag (Blowtorching for Fun and Profit!) will help you, anything less is a waste of time.
now, if i remember correctly, there's an exception in the linux license to allow binary-only loadable modules, but i'm not too clear on that part.
This is a very important point, Linus has made it clear that he intends for people to be able to make binary-only LKM's. See 4Front, makers of the OSS sound drivers, for an example. I also believe that some hardware vendors have done this, but I don't have examples handy.
In any event, worst case you have to GPL the code that you put in the kernel, but you only have to provide it to people that you have sold units to. Of course they can distribute it to anyone they want. More likely you talk to the copyright holder of the code you have changed and hammer out an a different license between the two parties.
Oh, and the GPL is good for business. One should open up their code to their customers, but there is no reason to allow your competitors to take your code without giving back. It's a standoff, you have your code, your competitor has your code. Any change they distribute they have to share with you, and as the owner you can do anything you please with the code.
Personally I have never seen software that had a warranty. If you build a critical component (heart monitor, brake system, etc.) on, say, VxWorks would the liability be any different. I imagine that VxWorks has the same "not fit for any particular purpose" clause as every other piece of software I've seen, and if you build something important out of it it is your liability.
I had the same experience. For my 6th grade science fair I made a demonstration on how chemical batteries work. It did not involve me making a battery, I only drew a poster describing how they worked. I did the entire project the morning of the science fair and I got this big First Place trophy. It was no fun because it was meaningless, it was also the last science fair that I attended.
SecurePipe Communications does this kind of thing. We provide a managed firewall service, just drop in our box. The firewall is maintained remotely from our NOC either over the network or via a POTS dialup. We also provide VPN's between firewalls and VPN's between roaming clients and internal networks, our latest software version also supports IPSec.
As to non-firewall solutions, we offer virtual mail and web hosting as well as managed mail servers with virus scanning. We can also host your DNS zones for you. many of our customers are small businesses, often without any full-time IT staff, which is why we offer such a complete set of non-firewall services.
Best of all we are an all Linux shop, from the Product to our Desktops. Several people in our staff have even contributed to open source projects. We also use OSS for all our core business software and will continue to do so for the forseeable future. Our shop is committed to the spirit of the GPL and will continue to do what we can to better the community.
Slashdot Mirror
*Sigh* . . . It seems that no one really does much research into CPU and computer system design anymore. All the major archetectures are pretty homogenized, they are either full RISC machines (probably a tad bloated with too many instructions) or RISC machines emulating a CISC instruction set (x86). RISC seems the last fundemental change in hardware design, the processors get smaller and faster but not much really changes.
One thing that I like, at least as a concept, is the IBM S/390. The IBM Mainframe and its customers have been living in a pretty insular world over the last 20 years and the hardware/software that runs on this beast is just, different. Some things are goofy, IIRC it boots off an emulated punch card reader (!!), or nifty, like the magic migrating storage system.
While in many senses you are right I think you are pointing to the wrong issue. It is not something inherent in the x86 arch that causes problems in scaling it is mostly Intel's SMP bus design. Having all the CPU's share a single, shared, bus between each other and system memory is the bottleneck. I mean, look at the Athalon, it isn't riding on an Intel designed bus, it rides on a DEC desigend EV6, originally made for the Alpha.
While Beowulf is a nifty technology, it does not solve all the scaling problems as you might think. Beowulf clusters are only useful for a specific subset of available problems, stuff that can be easily split up and sent to many, semi-independent, processing nodes. Beowulf clusters are generally connected together with 1Gb or 100Mb Ethernet which does not have high bandwidth or low latency compared to the CPU-Memory bus in even the cheapest computers. I would take a single 128 CPU box over 64 dual proc boxes connected via 1Gb Ethernet (or even Myrinet) any day.
IIRC SuSE is already turning a profit, RedHat (if current trends continue) should be turning a profit by next year. While this isn't the goldrush of last year, and there probably isn't currently room for a lot of large Linux-only players, there is plenty of money to be had.
KDE uses .xvpics as well and is compatable with XV, the best and fastest image viewer that I have used.
Argh. They are not introducing a new species here, only a sterile variant of the existing species. And since the new moths are sterile they can't produce offspring. In other words, no 50ft mutant moths are going to be moving in next door anytime soon.
Hey, if the killer bees suck in cold weather, won't that naturally prevent them from encroaching very far north? If they are less capable as bees then shouldn't they (eventually) be beat out by the existing bee population. This may take several hundred years to fix but, hey, live and learn.
While you don't have to trust my opinion on the matter you should at least try to make a reasonable argument. These genetic engineers didn't just fall off the turnip truck yesterday, also they are all not Dr. Frankenstien. This isn't some random tampering (think radiation) this is a limited modification to a reasonably simple organism. And I will repeat, the resulting moths are sterile, they cannot reproduce so there is no realistic chance that they could get out of control.
Argh. So many people hear the phrase "Genetic Engineering" and immediately think "Attack of the Killer 50ft Spitting Wombat!" instead of actually thinking.
No, no, no. There are an infinite number of variables everywhere, if we had to wait for perfect understanding of the universe before any experiment we would never expiriment (chickent and egg). I think that you are improperly assigning risk to the different methods of genetic engineering. You have:
This does not appear to be accurate at all. The corn was engineered to have a naturally occuring toxin taken from annother plant, so that farmers would not have to use noxious, persistant pesticides on their crops. Unfortunately the toxin also was produced in the pollen and could poison insects that didn't actually try to eat the corn, ie. Monarch Butterflies eating pollen-dust covered milkweed near cornfields. Also the use of the word "infected" to describe the engineered corn is completely inaccurate and way off base.
Note that the genetically engineered corn was sterile, so there was no way for its pollen to cross breed with nearby, non-GE, corn. And no having the corn be sterile is not some evil Monsanto plot to rip everybody off, although that may be a fortunate side-effect. The reason is that when one has unforseen consequences such as this one can stop shipping the product and everything will return to normal. Also note that there are many commercial hybrid seeds, produced by normal cross-breeding, that produce sterile plants, think seedless grapes.
In short please leave your FUD (buzzword of the day!) at home, it has little place here.
Oh, well then, you are right and truly screwed. Looks like you are going to have to recompile XFree86 or install a binary package with freetype2 support in it. You still shouldn't have to recomple Qt and I am certain that you won't have to recompile KDE as it knows nothing about the anti-aliasing happening in Qt/XRender
While I can't confirm this right now I think you are over-thinking this upgrade. AFAIK all you need to do is upgrade the libqt.so library to 2.3.0 (rpm -U, apt-get) and set an environment variable (QT_XFT, or something). If your XFree 4.0.2 was compiled with XRender (xdpyinfo to make sure) then it should "Just Work"(tm).
That's not entirely true, if you didn't intend to run FTP or NFS services, they shouldn't be enabled. Random Joe Cracker can't break into a service that isn't running. Joe Newbie isn't going to know that running any version of wu-ftpd is probably a bad idea let alone keep up with the security fixes.
There isn't one single point of failure but a common trait to many of these boxes is that they are running an unmodified, out-of-the-box install of RedHat. Giving Joe Newbie what is in effect a loaded weapon, instead of a safe unloaded weapon, is bad netizenship. Having your cracked box used to ping flood my network is as much your fault as the crackers, and is detrimental to me in any case.
If that is going to be the case then we are all doomed, doomed!! If major commercial Unix vendors took security seriously there wouldn't be a need for post-install hardning scripts like Bastille. If "Out of the Box Experience" wasn't perceived to be so important things like the Ramen worm would never happen, the machine would be tight by default.
That may be, but we've surpassed the security of their implementations long ago. (Security model on paper != security model actually in NT).
Hopefully we can get around the management problem of ACLs some time soon. Every OS where I have seen them implemented they were always too complicated to actually use. This lead to overly permissive ACLs being required because it would have been a mangement nightmare to do it the right way.
I wonder how much of this stuff kinda-sorta works with existing hardware. For example I am aware that many CPU's have more than two permissions contexts in their MMU but since UNIX only has kernelspace/userspace and root/non-root as its security these extra MMU bits aren't used (correct me if I am wrong, please). I am not aware what kind of stuff you can do on, for example, an x86 box when using ring 1-4 but I bet you could do something useful. Then again, maybe not, the hardware support probably only exists for backwards compatability purposes and isn't actually useful because of some unknown (to me) caveat.
While a registry system seems good on paper, the MS Windows implementation should be seen as a skull on a pike for anyone else wishing to implement similar functionality.
Uh, I'm all out of rant. Move along. 8^)
I think the point is to push the state of the art ahead, not fiddle with existing systems. I mean your analogy is similar to "Would you rather take a bicycle or a skateboard to fly to the moon" instead of researching how to make rockets.
Damn good point, you know there is still a small underground industry for things like hardcore wargames that only sell a few thousand or tens of thousands of copies. Going back to shareware would definitely be an improvement.
And for the truly paranoid, are you sure that in the 20 minutes they had your NRF ID they weren't analyzing it trying to make a copy. I'm sure the Russkies have a vast network of women's lingerie stores around potential military targets. And they are floridating the water 8^).
Kidding
My idea, games should be about fun, not technology. No, I don't run around with my DEC PDP-1 saying "Spacewar is it, all other games are just derivitave trash", but gameplay must come first. Look at the store shelves sometime, most games are "Foo II" or "Bar 3 Ultra" or some such jazz, same gameplay, rehashed graphics. The last new genre that I can remember is the real-time stragety, and it has been published to death.
Bagh! Enough ranting for now.
I'm using the RH6.2 binary packages for KDE 2.1beta2 and have experienced the same problems throughout my the kde2 releases. Very likely much of the core components were compiled without sufficient optimization but that can't really explain all of it. I noticed that URL type autodetection appears to be obscenely slow, specifying "kfmclient openURL http://slashdot.org text/html" appears to be faster.
Well then it's easy, an embedded Linux vendor can put their nads on the line (for $$$) when they sell you the product, of you wish. It's all the same, really.
I thought that I should just mention, to all those people recommending software solutions, they don't mean squat to someone willing to have the drive analysed by a professional data-recovery service. Mondern drives are getting harder and harder to erase this way and modern OS's don't help either, both abstract the actual physical data so much that you can't be abusolutely sure about anything.
Take ext2fs for example, to prevent fragmentation it stores files all over the surface of the disk, if a file grows in a way that would fragment it the entire file is moved to annother location on disk to prevent this fragmentation. That means you now have two copies of the file on disk.
There are also stupid bugs possible in this software (well, any software has bugs but . . . ). For example a couple of months ago someone on Bugtraq noted that shread (or wipe, I can't remember) truncated the file to 0 bytes before it overwrote it, this had the effect of creating a new file on disk and doing _nothing_ to the existing data, which can be recovered by a simple grep of the raw disk device.
Even if your wipe software works the hard disk itself abstracts the actual structure of the disk with things like automatic bad block relocation and such, making it impossible to know for certain that your sensitive data doesn't exist in a backup area of the hard drive.
I guess the important consideration is who are you trying to keep the data from, people who are going to use:
This is a very important point, Linus has made it clear that he intends for people to be able to make binary-only LKM's. See 4Front, makers of the OSS sound drivers, for an example. I also believe that some hardware vendors have done this, but I don't have examples handy.
In any event, worst case you have to GPL the code that you put in the kernel, but you only have to provide it to people that you have sold units to. Of course they can distribute it to anyone they want. More likely you talk to the copyright holder of the code you have changed and hammer out an a different license between the two parties.
Oh, and the GPL is good for business. One should open up their code to their customers, but there is no reason to allow your competitors to take your code without giving back. It's a standoff, you have your code, your competitor has your code. Any change they distribute they have to share with you, and as the owner you can do anything you please with the code.
HTML should have a ramble tag . . .
Personally I have never seen software that had a warranty. If you build a critical component (heart monitor, brake system, etc.) on, say, VxWorks would the liability be any different. I imagine that VxWorks has the same "not fit for any particular purpose" clause as every other piece of software I've seen, and if you build something important out of it it is your liability.
I had the same experience. For my 6th grade science fair I made a demonstration on how chemical batteries work. It did not involve me making a battery, I only drew a poster describing how they worked. I did the entire project the morning of the science fair and I got this big First Place trophy. It was no fun because it was meaningless, it was also the last science fair that I attended.
SecurePipe Communications does this kind of thing. We provide a managed firewall service, just drop in our box. The firewall is maintained remotely from our NOC either over the network or via a POTS dialup. We also provide VPN's between firewalls and VPN's between roaming clients and internal networks, our latest software version also supports IPSec.
As to non-firewall solutions, we offer virtual mail and web hosting as well as managed mail servers with virus scanning. We can also host your DNS zones for you. many of our customers are small businesses, often without any full-time IT staff, which is why we offer such a complete set of non-firewall services.
Best of all we are an all Linux shop, from the Product to our Desktops. Several people in our staff have even contributed to open source projects. We also use OSS for all our core business software and will continue to do so for the forseeable future. Our shop is committed to the spirit of the GPL and will continue to do what we can to better the community.
--Mark Tinberg
Network Security Engineer
SecurePipe Communications