This DNA/RNA combination sounds familiar if you're in Canada and caught the first couple of episodes of ReGenesis.
One of the plotlines of the show deals with a genetically engineered combination of Camel Pox (bacteria/DNA) and Ebola (virus/RNA). Trust the brilliant researchers to claim it as their own "new" idea instead of crediting science fiction...
DNF is finished, but it's been rebundled as an exclusive release for Infineon's Phantom game console. They're waiting for the hardware to ship to customers...;)
A friend of mine runs a file sharing server setup at home that has had Linux boxen running Reiser, XFS, EXT2, EXT3, and JFS. When copying large files from client boxen to a Linux server using SAMBA, an XP box with NTFS spanked Linux every time because XP would pre-allocate the space for the data it expected to receive, while Linux/SAMBA kept expanding the file.
Having done extensive software development under both Linux and various flavours of Windows, I never really found either to consistently outperform the other by much of a margin. What I did find was that a Linux box with a lot of memory would use enough of that memory for disk caching that it didn't keep re-reading the headers during the build and would compile the application faster. If there wasn't enough free memory to keep all the headers cached, it didn't perform all that much better than XP.
My bet is you're seeing the same memory caching advantages, not a huge difference in the actual file system performance.
Your description sounds an awful lot like what the AS400 team used to describe when I worked at companies that had good AS400 techies. It hybridized the mainframe-style contiguous file allocations with an integrated RDBMS that tracked the file information, much as the file information pages do with other file systems.
I find it interesting that so many "advances" other systems are making nowadays sound exactly like what the AS400 developers used to talk about. Using databases to store configuration information. Making the database an integral part of the OS. Virtualizing all storage so the system could shuffle files based on size changes and usage patterns to minimize head thrashing. Using wizards/forms for adding new software, changing configurations, etc.
I guess it's all considered "new" because so few people ever actually learned anything about the AS400 internals -- they just used them and counted on the system to do it's job properly.
I hadn't caught the bit in the article about the "company" that sold the software being shutdown in October 2003 -- a couple of weeks before Symantec and McAfee released detection of the problem.
So my apologies to the people who had current AV software but got burned.
Note also that it's been detected since October 2003, so I really don't have that much sympathy with the victims. The guy who sold this software deserves far worse than arrest and incarceration, but the victims who claim they had current anti-virus software updates installed are full of it.
From the article, he collected all the information that was being sent to his clients. So he didn't just sell the software, he was collecting information that could have been used for identity theft, credit fraud, blackmail, etc.
This wasn't a simple case of selling software with the potential for abuse -- the retailer himself was one of the abusers.
I found the few MP3s that are actually on the site, and it seems that these goofs think you need 128KBit near-CD quality stereo MP3s for someone to talk! 20KBit mono is more than adequate for talk-only MP3s, and would save huge amounts of bandwidth.
Looked to me like a blog, with a bunch of CBC staff babbling about irrelevant trivia like most bloggers do. I can't see why anyone would want to download an audio version of the same inane comments that were in text.
Guess I just must be too old. I still phone people instead of texting, I read forums and news sites instead of blogs, and I expect "news" to have some validity and fact-checking behind it. Guess I'd have to be young and "cool" to understand why downloaded MP3 talk-only audio is a "podcast" instead of just being an MP3.
Unless the POD part stands for "Piece Of Drek" -- then it makes sense.;)
Unfortunately they were serious. The supplier had run out of milspec parts and shipped the black ones rather than delay the whole project.
Everything in that simulated shipboard equipment room was built exactly the same as it would be for the ships, except for the encryption hardware. That was a dummy box because there was no need for real encryption to do our development or testing.
Milspec is picky. I remember code changes being rejected because of spelling mistakes, and having to redo developer redlines with a ruler because it was unacceptable to just stroke things out by hand with a pen.
One thing I do remember from working on milspec projects many years ago was that our project failed an inspection because some pipe valves were black. The part number was identical to milspec, but they weren't painted milspec green.
Spray paint took care of it, and the next inspection was passed.
Seriously, check with someone who knows the requirements. Even though I'd worked on milspec systems, I never knew the security requirements, nor did anyone else I worked with. Those requirements were handled by other specialists on the project, and no one had access to any specs that weren't needed for their part of the project.
Back in high school the military had brought over one of their choppers. The pilot told us one of the "cool" things about the jet turbine engine was that it could run on almost anything in a pinch, including alcohol, diesel, and gasoline.
That being the case, I don't see why you couldn't use biodiesel or methanol/ethanol to fuel a jet engine. There might be issues with the power curve for some models, but that likely just means changing the design parameters for future aircraft.
There are a lot of OSDL projects aside from Mono. It's entirely possible that Microsoft wants to ensure a certain degree of interoperability, and that they'll want to find ways of improving inter-system security.
Microsoft knows they don't own the server space, and they also know that most of the server vendors have partnerships in place to support Linux on their boxen. Therefore Microsoft has no choice but to ensure a certain degree of compatability if they're to maintain their position on the desktop as the front-end to access the servers.
Much as they'd like to win the server space, Microsoft isn't about to sacrifice millions of desktop licenses just to get a few hundred thousand server slots. Right now that means dealing with OSS in the server space.
I was referring to the way that transaction processors provide standardized APIs for configuring and executing the transmission of structured messaging between application objects. In this context, the transactional control is unnecessary overhead.
What is it about COM that you find so unique to it's approach to inter-process communications?
I don't confuse transactions or app servers with an IPC core. It's just that TP monitors build on IPC the same way that DCOM builds on top of COM. Perhaps XDR would have been a better example, as it wouldn't have misled you to think I was talking about the transaction processing aspects of the message bulletin boards and message queueing that TP is built on.
DLL-managed memory was used by many systems (especially data management systems) to provide a shared memory resource accessed by the DLL's APIs.
As I mentioned, this was a kludgy approach to sharing memory and prone to problems. If it's been removed from the "features" of a DLL, I stand corrected and relieved.
DRM is unavoidable if desktops are going to support playback of future media models. If Linux and other OSS systems are to compete for the desktop, there must be a reliable OSS implementation of DRM.
Unfortunately there is a good chance that there will also be a push for "certified" or "approved" DRM, which may well lock out all but the largest OSS distros.
When people say COM lets you embed applications, that is an implementation of using COM. It's no different than using a complex widget from a shared library, it just so happens that you embed the interface for the entire application.
TP monitoring systems including CICS, Tuxedo, and Encina also implemented different approaches to providing functionality similar to COM and D-COM. The earlier implementations of CICS and Tuxedo in particular beared a stronger resemblance to a Unix COM than they do to a more robust interface like CORBA.
DLLs are not just shared libraries, but blend in aspects of process memory that raises hell with shared memory management, especially if a process dies without properly releasing it's resources. A DLL can own resources, while a shared library is only for sharing code and static data. It's far cleaner and safer to have some sort of actual manager process create and manage shared memory and similar resources than it is to put that functionality into a quasi-process like a DLL.
Just because the Microsoft IDEs make it easy to work with COM doesn't mean the solution is at all elegant. While the flat interface it provides is workable in most cases, it also forces some incredibly kludgy interfaces and programming to get around the fact that you can't access sub-objects as you can with something more robust like CORBA.
Yes, I know CORBA hasn't been around as long as Unix IPC, and isn't part of the core system by most people. But in reality it's as much a core part of Unix systems programming as D-COM is to Windows.
As some have pointed out, there are other ways of doing things, and the Unix way isn't necessarily the "best" way for all cases. However, Win32 and NT didn't leverage much of the similar functionality from their VMS heritage, either.
If anything, COM and DLLs bear more resemblance to old DOS TSRs than they do to VMS or Unix. Much cleaner than a TSR, and more structured, but not as clean or safe as the IPC mechanisms used by Unix or VMS.
If you want to see some real elegant solutions to COM/DCOM vs IPC and shared libraries, take a gander at the approaches used by systems like QNX or some of the Smalltalk implementations.
As to a latter poster's comment about "wannabe", you're entitled to your opinion. However, my opinion is based on the guts of how the systems I've worked with are implemented and how reliable they've actually proven in the field. DLLs, COM, and DCOM are barely adequate implementations of technologies that were done better by their predecessors and competitors.
Funny that you'd mention that, as COM and DLLs are just a weird hack for implementing shared libraries and IPC (inter-process communications.) *nix has had that functionality since the mid-eighties.
About five years later, Windows 3.0 was released.:)
Of course it's all different now. Instead of turning to child prostitution, kids join gangs and sell drugs to make money.
Instead of prostitution leading to broken families, it's the 2-3 job parents who are never home leading to broken families.
If you think there is "relatively little severe poverty in the West", I invite you to visit a few inner cities in the US and Canada. You'll find the drugs, the guns, the prostitution, and the property crimes are all high in those areas.
And guess what? Most of those kids can't afford a computer or game console, yet they're the ones most likely to be in gangs and trying to kill each other over turf.
I know this proposed law is for Canada, but we've always taken it for granted that our government is supposed to serve the people. However, many of our politicians have sold out their votes to special interest groups, the same as in the US.
The sad thing is that there are a significant number of them who have fallen prey to the anti-terrorism paranoia, and others are taking advantage of that paranoia to push for changes they know would never be approved in any other political climate.
We need to retain our rights instead of letting them be eroded by a paranoid government as they've been south of the border. Our very right to live, to speak freely, and to engage in political activism is at stake.
Your "privacy" has been sold by the government to corporate interests. The remaining bits of "privacy" are about to be run over by roughshod jackboots in the name of "freedom" and "anti-terrorism."
It is now "government of the people, by the corporation, for the profits."
How can the olympics be trademarked when the term was originated a couple thousand years ago in Greece? Sure, they can trademark the interlocking circle glyph, but the word?
Most of the "professional" porn sites have disclaimers on their main pages, asking for confirmation of age. Many of them use systems like AdultCheck for further verification that it's not a minor surfing their site.
The slimeballs that use hidden/misleading sites aren't likely to start registering "proper".xxx domains any more than they use age check pages now.
Next will come the issue of whether to allow "illegal" porn to be registered as a.xxx. IIRC the Netherlands allows much younger models than are legal in the US or Canada. Japan and other countries don't allow full nudity at all (officially.) Other countries like France might consider simple nude beach shots to be vacation photos, while certain groups in North America would call them pornography.
The.xxx domains are a good idea in concept, but I just don't see them working out very well for resolving the "issue" of pornography on the internet.
Slashdot Mirror
This DNA/RNA combination sounds familiar if you're in Canada and caught the first couple of episodes of ReGenesis.
One of the plotlines of the show deals with a genetically engineered combination of Camel Pox (bacteria/DNA) and Ebola (virus/RNA). Trust the brilliant researchers to claim it as their own "new" idea instead of crediting science fiction...
DNF is finished, but it's been rebundled as an exclusive release for Infineon's Phantom game console. They're waiting for the hardware to ship to customers... ;)
Performance depends a lot on your load patterns.
A friend of mine runs a file sharing server setup at home that has had Linux boxen running Reiser, XFS, EXT2, EXT3, and JFS. When copying large files from client boxen to a Linux server using SAMBA, an XP box with NTFS spanked Linux every time because XP would pre-allocate the space for the data it expected to receive, while Linux/SAMBA kept expanding the file.
Having done extensive software development under both Linux and various flavours of Windows, I never really found either to consistently outperform the other by much of a margin. What I did find was that a Linux box with a lot of memory would use enough of that memory for disk caching that it didn't keep re-reading the headers during the build and would compile the application faster. If there wasn't enough free memory to keep all the headers cached, it didn't perform all that much better than XP.
My bet is you're seeing the same memory caching advantages, not a huge difference in the actual file system performance.
Your description sounds an awful lot like what the AS400 team used to describe when I worked at companies that had good AS400 techies. It hybridized the mainframe-style contiguous file allocations with an integrated RDBMS that tracked the file information, much as the file information pages do with other file systems.
I find it interesting that so many "advances" other systems are making nowadays sound exactly like what the AS400 developers used to talk about. Using databases to store configuration information. Making the database an integral part of the OS. Virtualizing all storage so the system could shuffle files based on size changes and usage patterns to minimize head thrashing. Using wizards/forms for adding new software, changing configurations, etc.
I guess it's all considered "new" because so few people ever actually learned anything about the AS400 internals -- they just used them and counted on the system to do it's job properly.
I hadn't caught the bit in the article about the "company" that sold the software being shutdown in October 2003 -- a couple of weeks before Symantec and McAfee released detection of the problem.
So my apologies to the people who had current AV software but got burned.
McAfee also has detected this issue since 2003, see http://vil.nai.com/vil/content/v_100716.htm
This one was tougher to find. I had to go to McAfee's site and use their virus information database search tool instead of google.
A simple google search for "Lover Spy" included Symantec's reference to it on the first page of results. See http://securityresponse.symantec.com/avcenter/venc /data/spyware.loverspy.html for details.
Note also that it's been detected since October 2003, so I really don't have that much sympathy with the victims. The guy who sold this software deserves far worse than arrest and incarceration, but the victims who claim they had current anti-virus software updates installed are full of it.
From the article, he collected all the information that was being sent to his clients. So he didn't just sell the software, he was collecting information that could have been used for identity theft, credit fraud, blackmail, etc.
This wasn't a simple case of selling software with the potential for abuse -- the retailer himself was one of the abusers.
I found the few MP3s that are actually on the site, and it seems that these goofs think you need 128KBit near-CD quality stereo MP3s for someone to talk! 20KBit mono is more than adequate for talk-only MP3s, and would save huge amounts of bandwidth.
Looked to me like a blog, with a bunch of CBC staff babbling about irrelevant trivia like most bloggers do. I can't see why anyone would want to download an audio version of the same inane comments that were in text.
Guess I just must be too old. I still phone people instead of texting, I read forums and news sites instead of blogs, and I expect "news" to have some validity and fact-checking behind it. Guess I'd have to be young and "cool" to understand why downloaded MP3 talk-only audio is a "podcast" instead of just being an MP3.
Unless the POD part stands for "Piece Of Drek" -- then it makes sense. ;)
Unfortunately they were serious. The supplier had run out of milspec parts and shipped the black ones rather than delay the whole project.
Everything in that simulated shipboard equipment room was built exactly the same as it would be for the ships, except for the encryption hardware. That was a dummy box because there was no need for real encryption to do our development or testing.
Milspec is picky. I remember code changes being rejected because of spelling mistakes, and having to redo developer redlines with a ruler because it was unacceptable to just stroke things out by hand with a pen.
One thing I do remember from working on milspec projects many years ago was that our project failed an inspection because some pipe valves were black. The part number was identical to milspec, but they weren't painted milspec green.
Spray paint took care of it, and the next inspection was passed.
Seriously, check with someone who knows the requirements. Even though I'd worked on milspec systems, I never knew the security requirements, nor did anyone else I worked with. Those requirements were handled by other specialists on the project, and no one had access to any specs that weren't needed for their part of the project.
Back in high school the military had brought over one of their choppers. The pilot told us one of the "cool" things about the jet turbine engine was that it could run on almost anything in a pinch, including alcohol, diesel, and gasoline.
That being the case, I don't see why you couldn't use biodiesel or methanol/ethanol to fuel a jet engine. There might be issues with the power curve for some models, but that likely just means changing the design parameters for future aircraft.
There are a lot of OSDL projects aside from Mono. It's entirely possible that Microsoft wants to ensure a certain degree of interoperability, and that they'll want to find ways of improving inter-system security.
Microsoft knows they don't own the server space, and they also know that most of the server vendors have partnerships in place to support Linux on their boxen. Therefore Microsoft has no choice but to ensure a certain degree of compatability if they're to maintain their position on the desktop as the front-end to access the servers.
Much as they'd like to win the server space, Microsoft isn't about to sacrifice millions of desktop licenses just to get a few hundred thousand server slots. Right now that means dealing with OSS in the server space.
I was referring to the way that transaction processors provide standardized APIs for configuring and executing the transmission of structured messaging between application objects. In this context, the transactional control is unnecessary overhead.
What is it about COM that you find so unique to it's approach to inter-process communications?
I don't confuse transactions or app servers with an IPC core. It's just that TP monitors build on IPC the same way that DCOM builds on top of COM. Perhaps XDR would have been a better example, as it wouldn't have misled you to think I was talking about the transaction processing aspects of the message bulletin boards and message queueing that TP is built on.
DLL-managed memory was used by many systems (especially data management systems) to provide a shared memory resource accessed by the DLL's APIs.
As I mentioned, this was a kludgy approach to sharing memory and prone to problems. If it's been removed from the "features" of a DLL, I stand corrected and relieved.
DRM is unavoidable if desktops are going to support playback of future media models. If Linux and other OSS systems are to compete for the desktop, there must be a reliable OSS implementation of DRM.
Unfortunately there is a good chance that there will also be a push for "certified" or "approved" DRM, which may well lock out all but the largest OSS distros.
When people say COM lets you embed applications, that is an implementation of using COM. It's no different than using a complex widget from a shared library, it just so happens that you embed the interface for the entire application.
TP monitoring systems including CICS, Tuxedo, and Encina also implemented different approaches to providing functionality similar to COM and D-COM. The earlier implementations of CICS and Tuxedo in particular beared a stronger resemblance to a Unix COM than they do to a more robust interface like CORBA.
DLLs are not just shared libraries, but blend in aspects of process memory that raises hell with shared memory management, especially if a process dies without properly releasing it's resources. A DLL can own resources, while a shared library is only for sharing code and static data. It's far cleaner and safer to have some sort of actual manager process create and manage shared memory and similar resources than it is to put that functionality into a quasi-process like a DLL.
Just because the Microsoft IDEs make it easy to work with COM doesn't mean the solution is at all elegant. While the flat interface it provides is workable in most cases, it also forces some incredibly kludgy interfaces and programming to get around the fact that you can't access sub-objects as you can with something more robust like CORBA.
Yes, I know CORBA hasn't been around as long as Unix IPC, and isn't part of the core system by most people. But in reality it's as much a core part of Unix systems programming as D-COM is to Windows.
As some have pointed out, there are other ways of doing things, and the Unix way isn't necessarily the "best" way for all cases. However, Win32 and NT didn't leverage much of the similar functionality from their VMS heritage, either.
If anything, COM and DLLs bear more resemblance to old DOS TSRs than they do to VMS or Unix. Much cleaner than a TSR, and more structured, but not as clean or safe as the IPC mechanisms used by Unix or VMS.
If you want to see some real elegant solutions to COM/DCOM vs IPC and shared libraries, take a gander at the approaches used by systems like QNX or some of the Smalltalk implementations.
As to a latter poster's comment about "wannabe", you're entitled to your opinion. However, my opinion is based on the guts of how the systems I've worked with are implemented and how reliable they've actually proven in the field. DLLs, COM, and DCOM are barely adequate implementations of technologies that were done better by their predecessors and competitors.
Funny that you'd mention that, as COM and DLLs are just a weird hack for implementing shared libraries and IPC (inter-process communications.) *nix has had that functionality since the mid-eighties.
About five years later, Windows 3.0 was released. :)
Of course it's all different now. Instead of turning to child prostitution, kids join gangs and sell drugs to make money.
Instead of prostitution leading to broken families, it's the 2-3 job parents who are never home leading to broken families.
If you think there is "relatively little severe poverty in the West", I invite you to visit a few inner cities in the US and Canada. You'll find the drugs, the guns, the prostitution, and the property crimes are all high in those areas.
And guess what? Most of those kids can't afford a computer or game console, yet they're the ones most likely to be in gangs and trying to kill each other over turf.
I'd rather leave a simpler message:
I know this proposed law is for Canada, but we've always taken it for granted that our government is supposed to serve the people. However, many of our politicians have sold out their votes to special interest groups, the same as in the US.
The sad thing is that there are a significant number of them who have fallen prey to the anti-terrorism paranoia, and others are taking advantage of that paranoia to push for changes they know would never be approved in any other political climate.
We need to retain our rights instead of letting them be eroded by a paranoid government as they've been south of the border. Our very right to live, to speak freely, and to engage in political activism is at stake.
Your "privacy" has been sold by the government to corporate interests. The remaining bits of "privacy" are about to be run over by roughshod jackboots in the name of "freedom" and "anti-terrorism."
It is now "government of the people, by the corporation, for the profits."
How can the olympics be trademarked when the term was originated a couple thousand years ago in Greece? Sure, they can trademark the interlocking circle glyph, but the word?
Most of the "professional" porn sites have disclaimers on their main pages, asking for confirmation of age. Many of them use systems like AdultCheck for further verification that it's not a minor surfing their site.
The slimeballs that use hidden/misleading sites aren't likely to start registering "proper" .xxx domains any more than they use age check pages now.
Next will come the issue of whether to allow "illegal" porn to be registered as a .xxx. IIRC the Netherlands allows much younger models than are legal in the US or Canada. Japan and other countries don't allow full nudity at all (officially.) Other countries like France might consider simple nude beach shots to be vacation photos, while certain groups in North America would call them pornography.
The .xxx domains are a good idea in concept, but I just don't see them working out very well for resolving the "issue" of pornography on the internet.