Yep, both Nimda and Code Red are still out there banging away at peoples doors trying to get in.
It looks as if the owners of the computers in question have not noticed that there systems are still compromised. Or if they have noticed, they are in no real position to do anything about. I consider the former to the the most likely situation.
Well I am not pleased, because I own a HP Jornada. I hope that this does not mean that spare parts and upgrades for the HP Jornada are effectively tossed out the window.
Correct me if I am wrong but the iPAQs are really only handhelds, with no keybaord. The models of the Jornadas span from handhelds, to fold out types (with keybaords), to laptop style. I consider the laptop type to be an expensive toy. However I also think that the handheld type is useless for anyone who prefers to type, rather than "be taught to write" with a stylus.
Yeah, you can probably plug a keyboard into the handheld iPAQ just like you can into a Palm devices, but there is a tradoff of sturdiness verses "putting the thing in your pocket".
Maybe a lot of spare parts places will start dumping their HP Jornada bits onto auction sites once they learn about this press release.
A small frog would most likely be a treat for them.
There are several things that Australians found out about "cane toads". For a start the stench when you happen to kill one. Then there is the fact that "cane toads" are "poisonous". Many of the Australian indenginous fauna have been dying off because of their (failed) attempts to actually consume these things. Then there have been the cats and dogs that have died as well.
One good thing that I have heard about durons is that they run at 100% CPU usage at a cool 32 degrees C (sorry I cannot convert that to F)
This is without a huge fan in order to keep the thing cool. Sometimes I have seen people put a large "good" heatsink on the things and get away with it.
Anything else, and you need a lot of "Air Movement Devices" (the IBM name for FANs) to get the airflow happening in the case to ensure that the temp stays down. A PIII 1Ghz will run at a crispy 46 degrees at about 100% CPU.
Besides they still have to put something into their high end systems to work as data storage, and at the moment anything other than "spinning platters with various magnetic coatings" is not as effective.
There have been a lot of different mediums in the past to try and displace Hard Drives. Maybe IBM have decided to distance themselves a little more from the hard drive business so they can set their R&D guys on the next thing to try and take hard drives on.
Either that or the "bean counters" are involved again....
Didn't Linus say something like "He who writes the code get's to choose the license?"
This can be expanded to say "He who owns the code decides who sees it".
This is starting to look more like the hardline GPL supporters and Microsoft Executives lining up to take pot shots at each other.
Now I am not much of an expert on GPL licencing, however I am under the assumption that GPL is not an actual organisation. The problem is that Microsoft are starting to see that some of the GPL products are becoming a real threat (to Microsoft).
What context that the word "threat" is in is not entirely clear. But essentially going after a bunch of individuals to stop them from developing certain projects, which can affect the "bottom line" for Microsoft in many different ways.
I have seen one instance where a former employer of mine had a "client-server" program in the field. Someone went to the trouble of reverse engineering it. The effort was to write a Linux version of the program. However when this was done it revealed that there were some mistakes made when parts were added to the overall system in it's second generation. These "flaws" were identified and the program code itself was put out under GPL. This caused some pain, but overall the damage was minimalised.
The same thing happened with Microsoft and SAMBA. To the point where Microsoft technicians and the SAMBA people talk regularly. They also get stuck into each other on a regular basis. Many flaws with the SMB version 1 operation within many platforms were identified through the development of SAMBA.
With the recent changes in laws in the US, it is now harder for the SAMBA crowd to do what they normally do. This recent addition it makes it harder for the SAMBA people to do anything, without breaking some recent addition in the DCMA in relation to the latest releases of the Microsoft SMB protocol.
The side effects are enourmous, however Microsoft have recently been taking a lot of heat, and in an effort to keep what it is that they have, they are attacking the "opposition" any way that they can. Guess what, Netscape are not Microsoft's main competition anymore. However this recent act only takes care of part of their "problem" with their "opposition" as a whole.
It does not affect all of the projects that cannot be identified as part of the "non commercial" arena.
A lot of credit card fraud is done by Merchants. That is because to deal with a lot of Merchants, you are supplying your credit card number. This is the direction that many banks want ot move away from.
The banks would love it if they could have this information. However there is the possibility for data harvesting of information of their own.
Seperate financial organisations are sort of in there, but they are in the same position as banks and merchants. Just ot have those companies there, has to impose some sort of fee on the transaction going past. Then there is is the potential for data harvesting.
From the point of view of a lot of people at the moment, yes, there should be somewhere central that you can "trust", because many home users cannot keep their systems under control.
However the next generation of children who are growing up right now, are growing up in a world where they are a little more knowledgeable about such things, as well as who they can trust with their information.
Whatever centralised system that we come up with now, which could have severe flaws overtime, due to any number of unforseen circumstances is just going to be ignored, not only by many of the next generation, but also by a significant number of people now.
Each user has a 'contact details' record, a 'financial details' record, and an 'identity' record on their machine, like a cookie, but digitally signed to say that it is actually theirs.
This could work, however there needs to be a uniform standard for this stuff. One of the main problems at the moment is the decision and adoption of the standard, as well as how to upgrade the standard when there is a technical flaw that allows it to leak information.
Then there is the overhead of continously sending 4K of extra HTTP headers with every single request. It will be at the stage where you transmission upstream is more than what you are getting downstream (in the case of 304 "you already have the most recent" responses).
When user visits a site, they get a digitally signed message saying "This is [X corp], we need your financial details to continue. We will destroy this info within 24 hours and will not pass it on. Certified by [Y regulatory body] YES OR NO".
The problem is that the credit card details are still turned over to the merchant. This is a large problem, because a lot of credit card fraud is actually done at the Merchant Level and not at the actual consumer. I seem to recall a figure of approx 90% about 10 years ago, and it appears that it is not that far off the value since. Cases of someone bombarding a merchant with "calculated" credit card numbers, as well as database hacking, does not contribute much to the overall fraud level, because the incidents are not high enough. The reason why it is considered so bad, is that they occur as a result of a "4th" party being involved who has nothing to do with the transaction (1, 2, and 3, being the consumer, merchant and credit card network supplied by a financial instution). Merchant level fraud is difficult to eliminate because the merchant will always be part of the transaction.
If a site wants identification (unified logons) etc.
There are two ways to appoach this from a "centralised" level. To eliminate merchant level fraud (from the perspective of the bank), it would be necessary to setup a mechanism to stop the merchants from directly getting their hands on the credit card numbers (including the expiry date). The other side of this is that it will be a lot worse if a bank would actually retreive the details of what it was that you were purchasing. This is because it would be possible for the bank to actually track the purchases that someone makes for several businesses. The desire then is for the bank to try and get as many merchants using their services, because the amount of tracking that they can perform would also be enourmous. This means that the bank can then construct profiles on people, etc.. It is worse at that level because of the amount of information that can flow past.
No more funny business with Big Evil Corporations knowing everything you do. No worries about people hacking the central repository and getting 10,000 credit card numbers overnight. No worries about people stealing your password, 'cause it's never transmitted - it's just used to encrypt the token to enter the site clientside.
The idea sounds good. However some thought needs to go into it. The idea is that only the financial instutions should be able to read your credit card details, the merchant should not. However having a constant fixed value is not good because it allows for the replay of the transaction (which is one of the aspects of Credit Card fraud that is the largest).
What is needed is something that is more along the lines of "challenge/response". Also it means that the merchant can only process the transaction when there has been an "OK" back from the credit card interface to the local bank. The amount is used as part of the transmission (so it can be verified and not tampered with by the merchant).
Now all we need is a secure method of pin entry, and you can use this system for debit cards as well as credit cards (or even pin verified credit cards). Acceptance of that is a long way off.
Sounds like they are pretty much anywhere in the western/english speaking world.
About October 2000, someone was posting on "aus.jobs" newsgroup talking about being an "Email Processor". When I looked into it even further, it appeared to be a pyramid scheme, designed to have the higher levels dissove over time (turning into a trapezoid). Other than sending the initial email and finding between the lines of the response, I decided not to pursue the matter any further (I was looking for work at the time).
It started to actually take off over time. About the middle of 2001 there was stuff everywhere. However a lot of people realised that it was a scam.
It has not progressed to the same level as this story in the US. If anything it has started to die down recently.
At least there is one current example of this today. There are devices that are used to tap optical fibre lines, that work by actually splicing into the line.
These devices have been around for a number of years now, and I have heard of one such device being able to tap an optical fibre bundle that has 50 individual optical fibres within it. Of course it will leave the optical pathways semi-intact, and detection is only by using complex test gear on either end that will tell you the consistency of the fibre as well as the points where the joins have been made. These things are usefull if you want to wiretap an optical fibre cable.
Of course removing such a device from the optical fibre bundle will effectively break the connection.
The MPAA is getting ready to sue people for having video of their kids on their house computer/server.
To be followed shortly thereafter by Kodak because you have pictures of kids on their house computer/server.
Purely because it takes business away from Kodak photo development shopfronts.
Seriously now... If the pure distinction was that you had files of this type, regardless of their contents, was enough of a reason to pay some industry group money, then they could basically hit just about any major corporation and sue them.
DOS attacks are rarely about sophistication - it's pure destructive potential.
Sometimes you have to wonder about some of the targets of these DOS attacks and how they are organised.
Some of the major ones are obvious, Microsoft, Ebay, Yahoo, etc. But when you start to get to the small to medium sized companies being hit by large DOS attacks, because their systems are sufficiently patched against break-ins, something begins to become worrying.
The questions range from why such a small target for such a large attack, and how the target was selected. Occasionally you get to hear stories about how some small ISP had their lines choked by a huge DDOS, meaning that customers started leaving and going to the competition. There is one other post elsewhere here that identified that a British ISP was put out of business because of the efforts of continous DOS attacks.
Spite sometimes is a factor, but it takes a certain degree of organisation to launch a continous attack such as that. Spite of someone will only get you so far. And there is not that much prestige in taking out a medium sized company. After all within the current climate, medium sized and some large sized companies are finding it harder to remain in business from an economic sense.
Have you looked into using smartcard technology.
I realise it isn't very pratical adding smart card readers to every machine..but im just starting to look into smartcards on *nix and the msucle project seems to suggest that you can roll smartcard verification into your login procedure.
http://www.linuxnet.com/apps.html
There have been smartcard APIs for Windows NT systems since 3.51.
I used to work for a Major Australian Bank that was using smartcards about 10 years ago for use with controlling access and defining access levels for it's Branch banking systems.
There are a lot of practical issues with Smartcards in a physical and logical sence.
For instance the selection of smart card reader is important. "slide on types" will constantly scratch the surface of the smartcard (wearing them out a lot quicker). Although just about every "el cheapo" smartcard reader that I have seen in the last 2-3 years is the "press down type" where the contact is not made until the card is the last millimeter inside the holder (reducing the wear and tear).
Watching what happens to these things when they get left in someones top pocket as their shirt/pants goes through the clothes washer and tumbe drier is fun. The chip is intact, but the plastic around it will make it impossible for you to insert it into a conventional reader again.
Only store minimal a amount of information within the smartcard. It should not make much difference nowdays, but the interface between the chip and the holder is not that fast. When you start storing copious amounts of data, it may be cheaper to issue each staff member with a 1.44Mb floppy disk and have each computer with a capable disk drive than to fork out for a Smartcard with a sizeable chunk of EEPROM storage.
Unless you want to waste smartcards that have been stuffed by someone feeding in an incorrect number of passwords a number of times, think about you reset strategy, etc. A system that enforces "kill this card" after 5 tries a the pin/password could mean that you cannot do anything with the card afterwards. Leading up to the next point...
Think about you Administrative procedures correctly. The plan is to work with multiple computer platforms here.
Then it is always fun to have a smartcard synced with a Windows NT account, UNIX account, etc. that is individual to the card. You either have to create the account manually, or have the software do it for you when it sees the card for the first time. It depends upon the sensitivity of the user data, and not letting another users see it.
Banks are constantly being bombarded by spam asking them to launder money. I have seen many from African and Middle East origins.
I used to work in the IT department of a Major Australian Bank. This has been going on for years.
About 10 years ago the faxes were usually in the form of trying to get people involved in "theft of money" from their employer. Or an investment scheme with the bank account in Nigeria.
This was something that was clamped down on hard by Management within the Australian Banks at the time, to prevent some newly employed teller from being involved (along with drilling it into the staff about any form of fruad, highlighting the fact that anyone partaing will be carted off by the Australian Federal Police).
There was a standard letter that the Nigerian scam at the time used, and it was used as an example within the Internal memos on the subject in general.
Wish I had a copy of that letter from back then. It would be interesting to compare it to what we have now.
My college has a similar set up because it saves an incredible amount of bandwidth. It's not to be mean, or malicious, or spy on your browsing habits, it's just to save bandwidth. And it does (I wish I had numbers to back this up, but I don't run the proxy).
I used to run a proxy server for a major company in Australia, with approx 3,000 users on one system and 1,500 on another.
The 3000 user system were the Administrative departments, of a client, and the 1500 were the outsourcing organisation (the primary reason for the split).
Each system had approx 25Gb of cache storage, and both systems used user authentication. The purpose of authentication was necessary so that Individual Internet access could be revoked by managers, and the system was configured so that the passwords expired every month.
Also both systems were using proxy log scanning mechanisms, with information being reported back to the managers. However this was not reliable in picking up people who were visiting places where they should not, and the policing fell back on the managers.
However the system did provide some wonderful information about how well the proxy cache was being hit. For the Administrative department of 3000 users, the Cache systems only needed to completely download new 'objects' 50% of the time. This was calculated as a 25% bandwidth saving, after through investigation. This was not bad for a service that was consuming about 20Gb of downloaded data a month with the caching turned on. This was despite the large amount of dynamic content that existed at the time.
The 1500 techs were not getting as good figures, more like 25% hit rate, and 12.5% data saved. This was despite the size of the cache storage being the same, and the number of users being less.
It still bugs me that KDE and GNOME still seem to be aspiring to be Win-clones. IMHO, the OS/2 WPS is still way better than Win-anything.
The desire to try and emulate the Windows GUI way of doing things is so people who are used to the Windows GUI don't have a harder time in picking it up.
The Gui that OS/2 originally used, and Windows 3.0 were so alike that it was not that hard to move from one to the other.
Both were expanded to include extra features, but I reckon that both Microsoft and IBM did not want a product that looked and felt like each others.
So there was a redevelopment effort of the GUI on both sides. The changes in the OS/2 GUI were small between versions (I have not had a good look at OS/2 Warp though).
However Microsoft had their "Chicago" project, which was eventually called Windows 95. This was a complete redevelopment of many aspects of the GUI interface, in the pursuit of being more "user friendly". Nowdays the GUIs of Windows 2000, et al, are still referred by some people as the Win95 GUI.
At the time that Windows 95 was released, followed by NT 4.0 later. The GUI was.. a problem for organisations that already had a large number of staff trained on, and using the existing Windows 3.x GUI interface. This meant the use of "Program Manager" and "File Manager" which OS/2 also had, etc. Win95 had the start button, and task bar.
The Windows 95 interface was supposedly easier to get around for a joe bloggs, who knew nothing about computers, and was just dragged off the street. I remember a promotional video shown years ago that showed two complete idiots trying to find and open notepad on a Widnows 3.x and a Windows 95 GUI. It still required prompting for both of these people, but it appeared blatantly obvious at the time that the person helping the idiot #2 using the Windows 95 interface, was being a little more helpful.
However this video meant nothing to the corporate managers out there who had to completely retrain their staff on using the new GUI system. After that Microsoft have made no real effort to try and change away from the start button, and task bar. Besides it makes the GUI look more like an Apple Mac anyway.
I have seen developers trying to port an application originally written for OS/2 to the Windows NT Platform, but running it under "Presentation Manager for NT" (or something like that). It was a programming environment that simulated parts of OS/2 within a Windows environment, which Micorosft left out.
It was expensive from a software licencing perspective, and it required the developers to redevelop the code anyway. The result was that they spent just as much time on the porting to this environment, as it would have been to port the application to a Native Win32 binary.
There was a Legacy HPFS Driver for Windows NT 3.1, and probably 3.50 and 3.51 as well. Just as there is a Legacy FAT16 Driver.
Microsoft dropped the support for the HPFS file system when Windows NT hit version 4.0
The purpose of supplying the driver in the first place was to give people a chance to read the HPFS file systems from OS/2 systems on NT boxes.
Why the support was dropped is debatable. Either Micorosft said that there was not enough market, or IBM said or did something.
I have heard of major corporates continuing to use OS/2 past the point where IBM dropped it completely, because the OS would only run the Apps that they were supposed to, and the users would have trouble loading games onto the systems.
The Harrison clocks, created in the 1700's, are still more accurate than your average digital watch today.
However your adverage digital watch today, would be a lot cheaper...
For that time it would be understandable that a clock would be a useful tool to help you understand where you are. It would have also been invaluable in giving an indication of the time of day.
I say "help" because it alone would not be able to provide the necessary capabilities without the person/people using it referring to other mechanisms and/or observations. It is only when you put all of this together that you have the means to calculate where you are.
This is the same with the GPS receiver. It is useless without the GPS satellite network, even though the device itself contains a fair degree of "number crunching" capabilities.
It would also be cheaper for the GPS receiver unit now than it would have been for the Harrison clocks, when they were constructed.
.. they were also the atomic clocks of their day.
That they certainly were. And with this we can compare to the atomic clocks of today, as far as cost is concerned.
It's not that I think basing a filesystem on a database is a great idea. For one thing, it's a pretty good bet that performance is going to suck because of all the extra DB-related overhead.
The possibility of the system breaking has also increased. Journalling, etc will only get you so far, and it has taken companies such as Microsoft and Oracle years to try and get that one nailed down.
There has been the means to provide index searching within Microsoft products on individual files since Option Pack 4 for Windows NT 4 came out. However it was not the best of index search engines, and there were a ton of problems in regards to maintaining the integrity of the index then. The product was not using SQL as it's database, and it was a real pain to try and make it interact with SQL (had to apply SP x, and then hot fixes, so you would not kill your database with the overload).
One of the issues then, was the ability to search on other file types such as PDF, etc. This was a right royal pain to setup. It is probably no easier now.
The reason for redevelopment of the applications is necessary to that you can have the new "search type fields" in your documents. However this ability exists now (Windows 2000), but the indexing capability is not the best, and still based upon the old system. To make matters worse, the indexing application has to do all of the interpertation itself (by calling a supplied filter DLL).
I guess the real important question is if the thing can be turned on or off, because not every installation of the OS will actually require a feature such as this, and the overheads will be sizeable.
We are slowly going down the path where we have so many features, bells and whistles that we end up confusing the poor users trying to use the damn thing.
It would not be as scary as the amount of memory space it would require for your OS to load !!!
Have you ever seen what SQL does when you decide that you are going to throw a low of activity at it. It will allocate all of the physical RAM that is in your computer and this forces just about everything else (including the OS) out to swap. This is because SQL server gets quite active with its caching in memory.
I guess I should buy shares in memory chip producers. It will be a booming economy if this new operating system is released.
Out of all of the discussions here, this is what I don't understand the most. Why offer backwards compatibility over say, a conversion utility?
I guess it is because of the need for services such as networking, etc. There are a lot of organisations out there that have a mixture of computers and networking them all together. The people who have been developing SAMBA over the years have a nice insight into how the low level communications turns into the Appropriate API Calls necessary to access a file, etc.
It is the retention of that ability that will be important. To some businesses, and some quite large ones at that. Microsoft will shoot themselves in the foot if they cannot provide the means for say a Windows 2000 system, or a Windows XP system to access a Windows "NG" server.
There is also the need to support the older applications that have not been "ported" to the Windows "NG" platform, that were originally written for the earlier Win32 systems.
Offering a Conversion utility is possible. However a Conversion utility will only work with files, and not programs. A Conversion utility is made useless in a Networking environment because you have to be able to connect in the first place.
Writing a completely new File System, or simply hacking new features into an old one, should not get in the way of how people are using computers for perfectly legitimate purposes right now (FileServers, WebServers, et al).
NTFS has its roots in HPFS, which was originally developed for OS/2. NTFS still uses the same concepts as HPFS for the location of the blockmaps. HPFS/NTFS break the disk up into sections of 16Mb or so. Within each 16Mb section you have the blockmap for that section (allocation table) in the middle, with the data distributed on either side. As opposed to FAT (stands for File Allocation Table) which placed the blockmap at the beginning of the partition, and all of the data following. By laying out the BlockMap in sections in the HPFS way the hard disk head did not have that far to move to update the BlockMap data and then the corresponding sector on the disk. This of meant an improvement in performance.
The main differences between HPFS and NTFS was the security (Windows NT 3.1), with compression and encryption added later (Windows NT 3.5x and Windows 2000). This was done by adding extra attributes chains into the system. When the NTFS file system driver was developed for Linux, they took the HPFS file system driver and modified it. Of course the Linux NTFS driver ignored the security attributes completely, and this has been known for some time.
Microsoft originally said the OFS would be part of NT 5, before being renamed to Windows 2000, and the new File System was dropped, probably due to stability, testing and time issues.
You have your old data on partition A with the NTFS, fine - keep it. Your new operating system runs on partition B with the new MSOFS (MS Object File System) and whatever data it produces it saves to the OFS partition.
Probably the cost of having to pay for both licences of software. A workable solution for a single person. However, imagine a large company.....
Why can't these two file systems exist together?
They will probably keep the NTFS support, much like how they used to keep the FAT support. Well.... for at least the next generation or two.
OFS is probably derived from a large amount of the lower levels of NTFS/HPFS anyway, with some sort of replacement for the directory structures. Within Windows 2000, you can already assign extra attributes to a file (such as description, etc). Maybe all that is being added is a new form of Index Search, but Microsoft have had that ability since Windows NT 4, with Option Pack 4, with Site Server loaded on top. The Site Server index search query engine (which replaced parts of the Option Pack 4 one) had the ability to filter it's output according to ACLs on the user, therefore if you had access to the file then you saw it in the results.
However the Micorsoft Web Index search engine relied upon maintaining seperate index files, and it was a real pain when the index file was corrupted, because all of the indexing system stopped. Also the index file tended to grow, and grow and grow, as content was added. If you wanted it to shrink, you had to rebuild it. It is starting to become obvious as to why there was a mention of the SQL engine in this because that has some abilities to maintain it's record reorganisation.
Meanwhile this new operating system is starting to look like an elephant compared to the mouse that is Windows 2000/XP. Imagine the overheads of writing a file and having the index update in realtime.
Slashdot Mirror
It looks as if the owners of the computers in question have not noticed that there systems are still compromised. Or if they have noticed, they are in no real position to do anything about. I consider the former to the the most likely situation.
Correct me if I am wrong but the iPAQs are really only handhelds, with no keybaord. The models of the Jornadas span from handhelds, to fold out types (with keybaords), to laptop style. I consider the laptop type to be an expensive toy. However I also think that the handheld type is useless for anyone who prefers to type, rather than "be taught to write" with a stylus.
Yeah, you can probably plug a keyboard into the handheld iPAQ just like you can into a Palm devices, but there is a tradoff of sturdiness verses "putting the thing in your pocket".
Maybe a lot of spare parts places will start dumping their HP Jornada bits onto auction sites once they learn about this press release.
There are several things that Australians found out about "cane toads". For a start the stench when you happen to kill one. Then there is the fact that "cane toads" are "poisonous". Many of the Australian indenginous fauna have been dying off because of their (failed) attempts to actually consume these things. Then there have been the cats and dogs that have died as well.
This is without a huge fan in order to keep the thing cool. Sometimes I have seen people put a large "good" heatsink on the things and get away with it.
Anything else, and you need a lot of "Air Movement Devices" (the IBM name for FANs) to get the airflow happening in the case to ensure that the temp stays down. A PIII 1Ghz will run at a crispy 46 degrees at about 100% CPU.
Besides they still have to put something into their high end systems to work as data storage, and at the moment anything other than "spinning platters with various magnetic coatings" is not as effective.
There have been a lot of different mediums in the past to try and displace Hard Drives. Maybe IBM have decided to distance themselves a little more from the hard drive business so they can set their R&D guys on the next thing to try and take hard drives on.
Either that or the "bean counters" are involved again....
This can be expanded to say "He who owns the code decides who sees it".
This is starting to look more like the hardline GPL supporters and Microsoft Executives lining up to take pot shots at each other.
Now I am not much of an expert on GPL licencing, however I am under the assumption that GPL is not an actual organisation. The problem is that Microsoft are starting to see that some of the GPL products are becoming a real threat (to Microsoft).
What context that the word "threat" is in is not entirely clear. But essentially going after a bunch of individuals to stop them from developing certain projects, which can affect the "bottom line" for Microsoft in many different ways.
I have seen one instance where a former employer of mine had a "client-server" program in the field. Someone went to the trouble of reverse engineering it. The effort was to write a Linux version of the program. However when this was done it revealed that there were some mistakes made when parts were added to the overall system in it's second generation. These "flaws" were identified and the program code itself was put out under GPL. This caused some pain, but overall the damage was minimalised.
The same thing happened with Microsoft and SAMBA. To the point where Microsoft technicians and the SAMBA people talk regularly. They also get stuck into each other on a regular basis. Many flaws with the SMB version 1 operation within many platforms were identified through the development of SAMBA.
With the recent changes in laws in the US, it is now harder for the SAMBA crowd to do what they normally do. This recent addition it makes it harder for the SAMBA people to do anything, without breaking some recent addition in the DCMA in relation to the latest releases of the Microsoft SMB protocol.
The side effects are enourmous, however Microsoft have recently been taking a lot of heat, and in an effort to keep what it is that they have, they are attacking the "opposition" any way that they can. Guess what, Netscape are not Microsoft's main competition anymore. However this recent act only takes care of part of their "problem" with their "opposition" as a whole.
It does not affect all of the projects that cannot be identified as part of the "non commercial" arena.
I could say more but it would be a spoiler.
It is being distributed by ADVFilms.
For those wondering what it is about, it has something to do with "Noah's Arc".
Is'nt the "Manga" (comic book form) called "Striker" ??
The banks would love it if they could have this information. However there is the possibility for data harvesting of information of their own.
Seperate financial organisations are sort of in there, but they are in the same position as banks and merchants. Just ot have those companies there, has to impose some sort of fee on the transaction going past. Then there is is the potential for data harvesting.
From the point of view of a lot of people at the moment, yes, there should be somewhere central that you can "trust", because many home users cannot keep their systems under control.
However the next generation of children who are growing up right now, are growing up in a world where they are a little more knowledgeable about such things, as well as who they can trust with their information.
Whatever centralised system that we come up with now, which could have severe flaws overtime, due to any number of unforseen circumstances is just going to be ignored, not only by many of the next generation, but also by a significant number of people now.
This could work, however there needs to be a uniform standard for this stuff. One of the main problems at the moment is the decision and adoption of the standard, as well as how to upgrade the standard when there is a technical flaw that allows it to leak information.
Then there is the overhead of continously sending 4K of extra HTTP headers with every single request. It will be at the stage where you transmission upstream is more than what you are getting downstream (in the case of 304 "you already have the most recent" responses).
When user visits a site, they get a digitally signed message saying "This is [X corp], we need your financial details to continue. We will destroy this info within 24 hours and will not pass it on. Certified by [Y regulatory body] YES OR NO".
The problem is that the credit card details are still turned over to the merchant. This is a large problem, because a lot of credit card fraud is actually done at the Merchant Level and not at the actual consumer. I seem to recall a figure of approx 90% about 10 years ago, and it appears that it is not that far off the value since. Cases of someone bombarding a merchant with "calculated" credit card numbers, as well as database hacking, does not contribute much to the overall fraud level, because the incidents are not high enough. The reason why it is considered so bad, is that they occur as a result of a "4th" party being involved who has nothing to do with the transaction (1, 2, and 3, being the consumer, merchant and credit card network supplied by a financial instution). Merchant level fraud is difficult to eliminate because the merchant will always be part of the transaction.
If a site wants identification (unified logons) etc.
There are two ways to appoach this from a "centralised" level. To eliminate merchant level fraud (from the perspective of the bank), it would be necessary to setup a mechanism to stop the merchants from directly getting their hands on the credit card numbers (including the expiry date). The other side of this is that it will be a lot worse if a bank would actually retreive the details of what it was that you were purchasing. This is because it would be possible for the bank to actually track the purchases that someone makes for several businesses. The desire then is for the bank to try and get as many merchants using their services, because the amount of tracking that they can perform would also be enourmous. This means that the bank can then construct profiles on people, etc.. It is worse at that level because of the amount of information that can flow past.
No more funny business with Big Evil Corporations knowing everything you do. No worries about people hacking the central repository and getting 10,000 credit card numbers overnight. No worries about people stealing your password, 'cause it's never transmitted - it's just used to encrypt the token to enter the site clientside.
The idea sounds good. However some thought needs to go into it. The idea is that only the financial instutions should be able to read your credit card details, the merchant should not. However having a constant fixed value is not good because it allows for the replay of the transaction (which is one of the aspects of Credit Card fraud that is the largest).
What is needed is something that is more along the lines of "challenge/response". Also it means that the merchant can only process the transaction when there has been an "OK" back from the credit card interface to the local bank. The amount is used as part of the transmission (so it can be verified and not tampered with by the merchant).
Now all we need is a secure method of pin entry, and you can use this system for debit cards as well as credit cards (or even pin verified credit cards). Acceptance of that is a long way off.
About October 2000, someone was posting on "aus.jobs" newsgroup talking about being an "Email Processor". When I looked into it even further, it appeared to be a pyramid scheme, designed to have the higher levels dissove over time (turning into a trapezoid). Other than sending the initial email and finding between the lines of the response, I decided not to pursue the matter any further (I was looking for work at the time).
It started to actually take off over time. About the middle of 2001 there was stuff everywhere. However a lot of people realised that it was a scam.
It has not progressed to the same level as this story in the US. If anything it has started to die down recently.
At least there is one current example of this today. There are devices that are used to tap optical fibre lines, that work by actually splicing into the line.
These devices have been around for a number of years now, and I have heard of one such device being able to tap an optical fibre bundle that has 50 individual optical fibres within it. Of course it will leave the optical pathways semi-intact, and detection is only by using complex test gear on either end that will tell you the consistency of the fibre as well as the points where the joins have been made. These things are usefull if you want to wiretap an optical fibre cable.
Of course removing such a device from the optical fibre bundle will effectively break the connection.
To be followed shortly thereafter by Kodak because you have pictures of kids on their house computer/server.
Purely because it takes business away from Kodak photo development shopfronts.
Seriously now... If the pure distinction was that you had files of this type, regardless of their contents, was enough of a reason to pay some industry group money, then they could basically hit just about any major corporation and sue them.
Sometimes you have to wonder about some of the targets of these DOS attacks and how they are organised.
Some of the major ones are obvious, Microsoft, Ebay, Yahoo, etc. But when you start to get to the small to medium sized companies being hit by large DOS attacks, because their systems are sufficiently patched against break-ins, something begins to become worrying.
The questions range from why such a small target for such a large attack, and how the target was selected. Occasionally you get to hear stories about how some small ISP had their lines choked by a huge DDOS, meaning that customers started leaving and going to the competition. There is one other post elsewhere here that identified that a British ISP was put out of business because of the efforts of continous DOS attacks.
Spite sometimes is a factor, but it takes a certain degree of organisation to launch a continous attack such as that. Spite of someone will only get you so far. And there is not that much prestige in taking out a medium sized company. After all within the current climate, medium sized and some large sized companies are finding it harder to remain in business from an economic sense.
There have been smartcard APIs for Windows NT systems since 3.51.
I used to work for a Major Australian Bank that was using smartcards about 10 years ago for use with controlling access and defining access levels for it's Branch banking systems.
There are a lot of practical issues with Smartcards in a physical and logical sence.
For instance the selection of smart card reader is important. "slide on types" will constantly scratch the surface of the smartcard (wearing them out a lot quicker). Although just about every "el cheapo" smartcard reader that I have seen in the last 2-3 years is the "press down type" where the contact is not made until the card is the last millimeter inside the holder (reducing the wear and tear).
Watching what happens to these things when they get left in someones top pocket as their shirt/pants goes through the clothes washer and tumbe drier is fun. The chip is intact, but the plastic around it will make it impossible for you to insert it into a conventional reader again.
Only store minimal a amount of information within the smartcard. It should not make much difference nowdays, but the interface between the chip and the holder is not that fast. When you start storing copious amounts of data, it may be cheaper to issue each staff member with a 1.44Mb floppy disk and have each computer with a capable disk drive than to fork out for a Smartcard with a sizeable chunk of EEPROM storage.
Unless you want to waste smartcards that have been stuffed by someone feeding in an incorrect number of passwords a number of times, think about you reset strategy, etc. A system that enforces "kill this card" after 5 tries a the pin/password could mean that you cannot do anything with the card afterwards. Leading up to the next point...
Think about you Administrative procedures correctly. The plan is to work with multiple computer platforms here.
Then it is always fun to have a smartcard synced with a Windows NT account, UNIX account, etc. that is individual to the card. You either have to create the account manually, or have the software do it for you when it sees the card for the first time. It depends upon the sensitivity of the user data, and not letting another users see it.
I used to work in the IT department of a Major Australian Bank. This has been going on for years.
About 10 years ago the faxes were usually in the form of trying to get people involved in "theft of money" from their employer. Or an investment scheme with the bank account in Nigeria.
This was something that was clamped down on hard by Management within the Australian Banks at the time, to prevent some newly employed teller from being involved (along with drilling it into the staff about any form of fruad, highlighting the fact that anyone partaing will be carted off by the Australian Federal Police).
There was a standard letter that the Nigerian scam at the time used, and it was used as an example within the Internal memos on the subject in general.
Wish I had a copy of that letter from back then. It would be interesting to compare it to what we have now.
I used to run a proxy server for a major company in Australia, with approx 3,000 users on one system and 1,500 on another.
The 3000 user system were the Administrative departments, of a client, and the 1500 were the outsourcing organisation (the primary reason for the split).
Each system had approx 25Gb of cache storage, and both systems used user authentication. The purpose of authentication was necessary so that Individual Internet access could be revoked by managers, and the system was configured so that the passwords expired every month.
Also both systems were using proxy log scanning mechanisms, with information being reported back to the managers. However this was not reliable in picking up people who were visiting places where they should not, and the policing fell back on the managers.
However the system did provide some wonderful information about how well the proxy cache was being hit. For the Administrative department of 3000 users, the Cache systems only needed to completely download new 'objects' 50% of the time. This was calculated as a 25% bandwidth saving, after through investigation. This was not bad for a service that was consuming about 20Gb of downloaded data a month with the caching turned on. This was despite the large amount of dynamic content that existed at the time.
The 1500 techs were not getting as good figures, more like 25% hit rate, and 12.5% data saved. This was despite the size of the cache storage being the same, and the number of users being less.
The desire to try and emulate the Windows GUI way of doing things is so people who are used to the Windows GUI don't have a harder time in picking it up.
The Gui that OS/2 originally used, and Windows 3.0 were so alike that it was not that hard to move from one to the other.
Both were expanded to include extra features, but I reckon that both Microsoft and IBM did not want a product that looked and felt like each others.
So there was a redevelopment effort of the GUI on both sides. The changes in the OS/2 GUI were small between versions (I have not had a good look at OS/2 Warp though).
However Microsoft had their "Chicago" project, which was eventually called Windows 95. This was a complete redevelopment of many aspects of the GUI interface, in the pursuit of being more "user friendly". Nowdays the GUIs of Windows 2000, et al, are still referred by some people as the Win95 GUI.
At the time that Windows 95 was released, followed by NT 4.0 later. The GUI was .. a problem for organisations that already had a large number of staff trained on, and using the existing Windows 3.x GUI interface. This meant the use of "Program Manager" and "File Manager" which OS/2 also had, etc. Win95 had the start button, and task bar.
The Windows 95 interface was supposedly easier to get around for a joe bloggs, who knew nothing about computers, and was just dragged off the street. I remember a promotional video shown years ago that showed two complete idiots trying to find and open notepad on a Widnows 3.x and a Windows 95 GUI. It still required prompting for both of these people, but it appeared blatantly obvious at the time that the person helping the idiot #2 using the Windows 95 interface, was being a little more helpful.
However this video meant nothing to the corporate managers out there who had to completely retrain their staff on using the new GUI system. After that Microsoft have made no real effort to try and change away from the start button, and task bar. Besides it makes the GUI look more like an Apple Mac anyway.
It was expensive from a software licencing perspective, and it required the developers to redevelop the code anyway. The result was that they spent just as much time on the porting to this environment, as it would have been to port the application to a Native Win32 binary.
There was a Legacy HPFS Driver for Windows NT 3.1, and probably 3.50 and 3.51 as well. Just as there is a Legacy FAT16 Driver.
Microsoft dropped the support for the HPFS file system when Windows NT hit version 4.0
The purpose of supplying the driver in the first place was to give people a chance to read the HPFS file systems from OS/2 systems on NT boxes.
Why the support was dropped is debatable. Either Micorosft said that there was not enough market, or IBM said or did something.
I have heard of major corporates continuing to use OS/2 past the point where IBM dropped it completely, because the OS would only run the Apps that they were supposed to, and the users would have trouble loading games onto the systems.
However your adverage digital watch today, would be a lot cheaper...
For that time it would be understandable that a clock would be a useful tool to help you understand where you are. It would have also been invaluable in giving an indication of the time of day.
I say "help" because it alone would not be able to provide the necessary capabilities without the person/people using it referring to other mechanisms and/or observations. It is only when you put all of this together that you have the means to calculate where you are.
This is the same with the GPS receiver. It is useless without the GPS satellite network, even though the device itself contains a fair degree of "number crunching" capabilities.
It would also be cheaper for the GPS receiver unit now than it would have been for the Harrison clocks, when they were constructed.
That they certainly were. And with this we can compare to the atomic clocks of today, as far as cost is concerned.
The possibility of the system breaking has also increased. Journalling, etc will only get you so far, and it has taken companies such as Microsoft and Oracle years to try and get that one nailed down.
There has been the means to provide index searching within Microsoft products on individual files since Option Pack 4 for Windows NT 4 came out. However it was not the best of index search engines, and there were a ton of problems in regards to maintaining the integrity of the index then. The product was not using SQL as it's database, and it was a real pain to try and make it interact with SQL (had to apply SP x, and then hot fixes, so you would not kill your database with the overload).
One of the issues then, was the ability to search on other file types such as PDF, etc. This was a right royal pain to setup. It is probably no easier now.
The reason for redevelopment of the applications is necessary to that you can have the new "search type fields" in your documents. However this ability exists now (Windows 2000), but the indexing capability is not the best, and still based upon the old system. To make matters worse, the indexing application has to do all of the interpertation itself (by calling a supplied filter DLL).
I guess the real important question is if the thing can be turned on or off, because not every installation of the OS will actually require a feature such as this, and the overheads will be sizeable.
We are slowly going down the path where we have so many features, bells and whistles that we end up confusing the poor users trying to use the damn thing.
Have you ever seen what SQL does when you decide that you are going to throw a low of activity at it. It will allocate all of the physical RAM that is in your computer and this forces just about everything else (including the OS) out to swap. This is because SQL server gets quite active with its caching in memory.
I guess I should buy shares in memory chip producers. It will be a booming economy if this new operating system is released.
I guess it is because of the need for services such as networking, etc. There are a lot of organisations out there that have a mixture of computers and networking them all together. The people who have been developing SAMBA over the years have a nice insight into how the low level communications turns into the Appropriate API Calls necessary to access a file, etc.
It is the retention of that ability that will be important. To some businesses, and some quite large ones at that. Microsoft will shoot themselves in the foot if they cannot provide the means for say a Windows 2000 system, or a Windows XP system to access a Windows "NG" server.
There is also the need to support the older applications that have not been "ported" to the Windows "NG" platform, that were originally written for the earlier Win32 systems.
Offering a Conversion utility is possible. However a Conversion utility will only work with files, and not programs. A Conversion utility is made useless in a Networking environment because you have to be able to connect in the first place.
Writing a completely new File System, or simply hacking new features into an old one, should not get in the way of how people are using computers for perfectly legitimate purposes right now (FileServers, WebServers, et al).
NTFS has its roots in HPFS, which was originally developed for OS/2. NTFS still uses the same concepts as HPFS for the location of the blockmaps. HPFS/NTFS break the disk up into sections of 16Mb or so. Within each 16Mb section you have the blockmap for that section (allocation table) in the middle, with the data distributed on either side. As opposed to FAT (stands for File Allocation Table) which placed the blockmap at the beginning of the partition, and all of the data following. By laying out the BlockMap in sections in the HPFS way the hard disk head did not have that far to move to update the BlockMap data and then the corresponding sector on the disk. This of meant an improvement in performance.
The main differences between HPFS and NTFS was the security (Windows NT 3.1), with compression and encryption added later (Windows NT 3.5x and Windows 2000). This was done by adding extra attributes chains into the system. When the NTFS file system driver was developed for Linux, they took the HPFS file system driver and modified it. Of course the Linux NTFS driver ignored the security attributes completely, and this has been known for some time.
Microsoft originally said the OFS would be part of NT 5, before being renamed to Windows 2000, and the new File System was dropped, probably due to stability, testing and time issues.
You have your old data on partition A with the NTFS, fine - keep it. Your new operating system runs on partition B with the new MSOFS (MS Object File System) and whatever data it produces it saves to the OFS partition.
Probably the cost of having to pay for both licences of software. A workable solution for a single person. However, imagine a large company.....
Why can't these two file systems exist together?
They will probably keep the NTFS support, much like how they used to keep the FAT support. Well.... for at least the next generation or two.
OFS is probably derived from a large amount of the lower levels of NTFS/HPFS anyway, with some sort of replacement for the directory structures. Within Windows 2000, you can already assign extra attributes to a file (such as description, etc). Maybe all that is being added is a new form of Index Search, but Microsoft have had that ability since Windows NT 4, with Option Pack 4, with Site Server loaded on top. The Site Server index search query engine (which replaced parts of the Option Pack 4 one) had the ability to filter it's output according to ACLs on the user, therefore if you had access to the file then you saw it in the results.
However the Micorsoft Web Index search engine relied upon maintaining seperate index files, and it was a real pain when the index file was corrupted, because all of the indexing system stopped. Also the index file tended to grow, and grow and grow, as content was added. If you wanted it to shrink, you had to rebuild it. It is starting to become obvious as to why there was a mention of the SQL engine in this because that has some abilities to maintain it's record reorganisation.
Meanwhile this new operating system is starting to look like an elephant compared to the mouse that is Windows 2000/XP. Imagine the overheads of writing a file and having the index update in realtime.