R. Bowman also advocates using a nuclear arsinal as a deterrent. Wouldn't the *ultimate* deterrent be a system like THEL or ABL that could neutralize an inbound short or long-range ballistic weapon?
Sure we can continue to build ICBM's and other intermediate range nuclear missles, but the history of warfare is such that once a weapon is found it's only a matter of time before a defensive counter-measure is built. Should the US sit on its thumbs while other countries build these defensive weapons?
Someone will eventually acquire similiar technology that could neutralize an incoming ballistic missle. At that point does the US have the right to pursue development of these defensive weapons?
Of course, maybe then it will be too late to defend ourselves.
Have these lawyers not heard of copyright? You should be able to include licensing information in your code, and if someone does cut & paste you'll have some protection.
Imagine if Stephen King decided to patent a new literary genra, now he is the only one who can author novels in this format. This makes absolutely no sense, especially when the best protection he would have for his new books would be to copyright them and thereby prevent unauthorized copying / redistribution.
It is unimaginable to me that you can patent a creative work. Computer programming is a fairly creative process that anyone with a PC is capable of doing. If I wrote a horror novel, I would not expect to infringe on a patent -- for the same reason that if I wrote a calendaring application I would not expect to be in violation of your patent. How are we suppose to write computer programs if everyone else has a patent on them?
What I don't get is why it takes 10,000+ developers to develop an operating system. Granted, there are a few nifty utilities included, but it seems like a case of an awful lot of cooks.
For comparison, the Empire State Building took a little over a year and had at most 3,400 workers on the project at any one time.
Some of my local merchants are now validating credit card transactions using your zip-code.
While certainly not bullet-proof, there are quite a few postal codes in my area and one can assume the card thief may / may not know all of them.
Of course this doesn't do you much good if your database of CC's gets stolen. Here everything about the customer is available, and even with something like an encrypted PIN it could be fairly easily brute-forced.
While this might not work so well in the public domain, I can see where it could be feasible in an enterprise backup scheme.
Basically, your client can take advantage of peers to discover places to backup your data. Peers can be local (onsite backup) and remote (offsite backup), and when peers come offline can redistribute their data accordingly.
I'm starting to doubt that there really is any compatibility here. Everyone is going to be doing their own thing - which is going to leave plenty of room for innovation but will make.NET as a "platform" an impossibility.
And even more unfortunate is that many of these assemblies must rely on native code. Until Java worked out many of its kinks, there were native method classes used to solve these problems. Until.NET has a certain level of maturity it won't have the same level of portability as the now-mature Java, so while Mono might be a platform the MS.NET implementation won't be a platform for quite some time.
IMHO, MS should have provided a GDI spec that others could plug into. So if someone did decide to implement a Gtk assembly it would be pluggable.
Well, rather than slamming.NET without actually tinkering with it, I thought it might be neat to install it.
On a Linux box with Mono and a W2K server with the.NET framework, my little hello.exe worked perfectly. Granted, less than half the.NET spec is implemented yet in Mono, but performance was quite good. It took approximately 5-6 times longer for the equivalent program to load and execute using the Sun 1.4 JVM (no performance tuning with either).
If they can continue to maintain this edge, Mono will be quite attractive once completed.
With that said, I'm concerned about Windows.Forms being dependent on WINE. While it's great they can leverage another oss project like this, it makes me wonder how solid the MS Windows.Forms assembly specification really is.
I think it depends what you're doing. If you're sending information to customers, then simply export your OpenOffice docs to PDF. You should be doing this anyway, even if you're using MS Word, because the PDF is the only way to ensure your document will be delivered properly. Heck, even MS Word isn't compatible with MS Word!
If you need to collaborate, then encourage everyone on the team to either adopt an open standard (HTML, RDF, etc.) or get them onboard with OO.
After reading all this, it sounds like Houstin opted for SimDesk only because they felt trapped by Microsoft licensing issues.
It's not clear to me they will save money, although it does seem clear that by doing this they can at least quantify the amount of money they need to spend. I wonder if these kinds of MS sales tactics can be argued as entrapment or bait & switch? Customers shouldn't need to feel like they must pay millions to get MS off their back, especially when the amount involved is in dispute.
A greater concern for Houstin is where the data will be stored. It's not clear from the website or the marketing blurbs if the SimDesk apps drop documents locally or remotely to the SimDesk server. At a minimum, the patent-pending Trashbin is purported to be remote - which would give you access to this content from anywhere. I sure hope this system is secure!
Of course, the fact that they are looking to partner with Unisys is reason enough to be concerned. Remember GIF? TBPH, Microsoft doesn't look like a bad alternative here -- if anything this should be a wakeup call for MS that license audits need to be approached with extreme caution.
Well, aside from the fact that SuSE has bundled Crossover - you can now get OpenExchange to manage "enterprise" email in a format that is compatible with MS Outlook and apparantly PDA's as well. Does anyone know if this really works? It claims to be "open" but I'm wondering what that means exactly.
And it looks like they will provide a PCMCIA-style reader device as well. This provides excellent backward compatibility, but the real test will be to get support from a major hardware vendor (Dell, Apple, HP?) and bundle the card reader into new PC's.
Some weirdness in their product description though. "...the StorReader supports a sustained data transfer rate of 5 megabytes per second in the 100 megabyte StorCard, and scales in the 5 gigabyte design".
NT (W2K) also seems to handle serial ports by sending sporadic streams of gunk to them, which could be related to this virtual interrupt handling scheme? We had a headless Sparc connected via serial cable to a W2K box, and for some reason -- every so often -- the Sparc would become unavailable.
It turned out the Windows dumb-terminal wasn't so dumb after all! It would occasionally send garbage characters to the tty and force the Sparc to a PROM prompt. Since the box was headless, we went through a lot of trouble to borrow a monitor and connect it to the Sparc.
Afterwards, we simply dropped the serial cable into a Linux box and accessed the dumb terminal from there. Evidently Windows wasn't up to the task of serving as a dumb terminal.
I had a similiar problem with an APC a few years ago. After receiving my new UPS from CDW, I proceeded to plug it in to my PowerMac and turn it on. Nothing happened so I followed the instructions to make sure everything was setup properly (battery enabled, plugged in, yada yada yada...).
A few minutes later -- POP! and then smoke was coming out of my *computer*.
After returning it to APC, they claimed it had failed because it wasn't designed for a United States voltage. Evidently this unit should have gone to Russia, but somehow it ended up in my lap.
At any rate, it was obviously my fault -- and so I was out a computer. APC was generous enough to replace it with an American model, which gathered dust for quite some time (until I was able to replace my computer). I recommend everyone take a look at Tripp, they make a UPS that won't burst into flames and include excellent software support for a number of operating systems.
LOL. funny -- "List of IDs for the Device Standard Which Must Not Be Named".
At any rate, this is a little out of proportion here. As another poster pointed out, you can't start a site and slap the IBM logo on the top of your page -- you would be infringing on a trademark and presenting consumers with some confusion.
How would someone visiting your version of the IBM page know that they aren't really visiting the IBM page?
You can, however, discuss the IBM corporation, products, etc. without appearing to be a representative of that corporate entity. In this case, that is the concern PCI-SIG and I think it would be perfectly acceptable to remove the logo and proceed using a slightly more newsworthy format.
Of course it might not be a bad idea to consult a lawyer just in case.
TBPH, I think Microsoft is attempting to conquor the elusive remote object invocation problem.
At first, it seemed like some version of RPC might solve this problem. And then a little bit later, developers were promised that CORBA was the future. Somewhere in there OSF/DCE made a lot of promises. And then Microsoft threw COM out there, and tried to spruce up some security issues with COM+...
Eventually EJB took hold, and now we have yet another way to remotely invoke objects via SOAP.
While things are looking up, I think most developers are fairly frustrated at this point. After grappling with IDL's and disparate RPC mechanisms, IUnknown and VisualBasic... I think unless there is a conserted effort by the industry to address remote object invocations (including a robust security model) then all of these attempts will continue to flounder.
What I really don't understand is what MS hopes to accomplish by tweaking their product names only very slightly. So it use to be Windows 2000 Server and now it's going to be Windows Server 2003... big deal.
If.NET was really a bet-the-business proposition, they might as well call the product what it is. Windows Server for.NET Version 1.0. Maybe MS has realized that.NET isn't as much a fundamental paradigm switch as it is a client/server application you run on your computer.
And for that matter, the workstation version could be Windows Workstation for.NET Applications Version 1.0. That might actually help the consumer a little!
Honestly, the users that were suppose to benefit from "consistent" naming conventions (Win 95, Win 98, Win 2000) have been duped with WinME, WinXP and whatever else MS is going to call their next workstation version of NT.
Enough of these naming "conventions" already; call it what it is. IMHO, Apple is doing the most work in this area -- an OS is simply OS # - makes sense to me.
Assuming the padding is coming from other frames on the same ethernet device, then it really seems unlikely that this is a security hole at all. The data has already been transmitted in a properly sequenced form, it would have been a lot easier to pickoff the data by sniffing the other transmission.
Now, if the padding is the result of a semi-random memory location getting written to the end of your packets then that can be considered a fairly significant risk. Another posting on/. seemed to suggest this as a possibility, but based on the CERT advisory I really don't see any evidence of this.
What am I missing here? If we could stop quibbling over the how-much-MS-sucks-today factor maybe we could understand the true scope/nature of this problem. If there really isn't a problem, then perhaps it doesn't belong on CERT.
Since you don't manage your own memory on Java or C#, the concept of buffer overflow doesn't really apply. While the array construct still exists in both languages, you can't overflow an array without going out of bounds.
It is critical that the software industry start to adopt VM's for managing applications, especially code that runs on a server. The emergence of a user-mode kernel for Linux is a critical development in this regard, but ultimately it makes more sense to modernize your codebase to Java, C# or any of the interpretive languages that can intercept/manage memory allocation checks for you.
I couldn't agree more -- I think Lindows is making all the smart business decisions it needs to make in order to ensure the survival of their product.
While you don't have to use Click & Run, I think it's a brilliant marketing ploy -- and it's also something that users can understand. If you want to install more software, as long as you have a subscription to the Lindows Click & Run service you can point & click to install more programs.
Let's face it, the average computer user will benefit from the GUI-ified virtual warehouse of open source software that Lindows has pre-prepared . Running apt-get from a command prompt or launching make from a command prompt or even figuring out how to download an RPM from a command prompt is _not_ something that the _average_ user is going to want to do. While there are GUI's for most of these tools, I have not seen any of them that promote software in a way that consumers can understand.
In other words, if you don't know what you want you're going to be fairly lost. With Click & Run, if you don't know what you want then chances are you can find something that either interests you or remotely meets some requirement you might have. Bottom line; pictures and promotional text help entice average computer users.
As far as the root execution goes, I wasn't too thrilled about that either. Even Windows is getting pretty good with that - although the majority of users just stuff themselves into the local Administrators group anyway. Since the KDE tools are flexible enough to handle a prompt for root password whenever required, I think one can safely assume non-root day-to-day running will be feasible.
I like the Lindows model. While I don't plan to run it myself, I know plenty of people who would be well suited to this platform. Always keep in mind that open source does not mean _free_, open source always means open source and free is your freedom to choose how you want to use that source.
not always. After a bad experience with an MS Exchange server crashing, my fix was not simply an install away. It ultimately involved a variety of Windows registry tweaks to "remind" the W2K AD DC that the Exchange server with the same name was actually a new server.
None of this was documented anywhere. BTW, if you get stuck with this and have to modify the AD forest directly I highly recommend using an LDAP tool rather than the MS ADSI utility. MS hides too much stuff from you and will prevent you from making a complete recovery.
Slashdot Mirror
R. Bowman also advocates using a nuclear arsinal as a deterrent. Wouldn't the *ultimate* deterrent be a system like THEL or ABL that could neutralize an inbound short or long-range ballistic weapon?
Sure we can continue to build ICBM's and other intermediate range nuclear missles, but the history of warfare is such that once a weapon is found it's only a matter of time before a defensive counter-measure is built. Should the US sit on its thumbs while other countries build these defensive weapons?
Someone will eventually acquire similiar technology that could neutralize an incoming ballistic missle. At that point does the US have the right to pursue development of these defensive weapons?
Of course, maybe then it will be too late to defend ourselves.
oh my. I think I'm going to be sick. This is a horrid state of affairs.
Have these lawyers not heard of copyright? You should be able to include licensing information in your code, and if someone does cut & paste you'll have some protection.
Imagine if Stephen King decided to patent a new literary genra, now he is the only one who can author novels in this format. This makes absolutely no sense, especially when the best protection he would have for his new books would be to copyright them and thereby prevent unauthorized copying / redistribution.
It is unimaginable to me that you can patent a creative work. Computer programming is a fairly creative process that anyone with a PC is capable of doing. If I wrote a horror novel, I would not expect to infringe on a patent -- for the same reason that if I wrote a calendaring application I would not expect to be in violation of your patent. How are we suppose to write computer programs if everyone else has a patent on them?
Pure sillyness.
What I don't get is why it takes 10,000+ developers to develop an operating system. Granted, there are a few nifty utilities included, but it seems like a case of an awful lot of cooks.
For comparison, the Empire State Building took a little over a year and had at most 3,400 workers on the project at any one time.
Some of my local merchants are now validating credit card transactions using your zip-code.
While certainly not bullet-proof, there are quite a few postal codes in my area and one can assume the card thief may / may not know all of them.
Of course this doesn't do you much good if your database of CC's gets stolen. Here everything about the customer is available, and even with something like an encrypted PIN it could be fairly easily brute-forced.
While this might not work so well in the public domain, I can see where it could be feasible in an enterprise backup scheme.
Basically, your client can take advantage of peers to discover places to backup your data. Peers can be local (onsite backup) and remote (offsite backup), and when peers come offline can redistribute their data accordingly.
I'm starting to doubt that there really is any compatibility here. Everyone is going to be doing their own thing - which is going to leave plenty of room for innovation but will make .NET as a "platform" an impossibility.
.NET has a certain level of maturity it won't have the same level of portability as the now-mature Java, so while Mono might be a platform the MS .NET implementation won't be a platform for quite some time.
And even more unfortunate is that many of these assemblies must rely on native code. Until Java worked out many of its kinks, there were native method classes used to solve these problems. Until
IMHO, MS should have provided a GDI spec that others could plug into. So if someone did decide to implement a Gtk assembly it would be pluggable.
Well, rather than slamming .NET without actually tinkering with it, I thought it might be neat to install it.
.NET framework, my little hello.exe worked perfectly. Granted, less than half the .NET spec is implemented yet in Mono, but performance was quite good. It took approximately 5-6 times longer for the equivalent program to load and execute using the Sun 1.4 JVM (no performance tuning with either).
On a Linux box with Mono and a W2K server with the
If they can continue to maintain this edge, Mono will be quite attractive once completed.
With that said, I'm concerned about Windows.Forms being dependent on WINE. While it's great they can leverage another oss project like this, it makes me wonder how solid the MS Windows.Forms assembly specification really is.
Oops. My bad - not taken as flame at all - thanks for the correction.
I think it depends what you're doing. If you're sending information to customers, then simply export your OpenOffice docs to PDF. You should be doing this anyway, even if you're using MS Word, because the PDF is the only way to ensure your document will be delivered properly. Heck, even MS Word isn't compatible with MS Word!
If you need to collaborate, then encourage everyone on the team to either adopt an open standard (HTML, RDF, etc.) or get them onboard with OO.
After reading all this, it sounds like Houstin opted for SimDesk only because they felt trapped by Microsoft licensing issues.
It's not clear to me they will save money, although it does seem clear that by doing this they can at least quantify the amount of money they need to spend. I wonder if these kinds of MS sales tactics can be argued as entrapment or bait & switch? Customers shouldn't need to feel like they must pay millions to get MS off their back, especially when the amount involved is in dispute.
A greater concern for Houstin is where the data will be stored. It's not clear from the website or the marketing blurbs if the SimDesk apps drop documents locally or remotely to the SimDesk server. At a minimum, the patent-pending Trashbin is purported to be remote - which would give you access to this content from anywhere. I sure hope this system is secure!
Of course, the fact that they are looking to partner with Unisys is reason enough to be concerned. Remember GIF? TBPH, Microsoft doesn't look like a bad alternative here -- if anything this should be a wakeup call for MS that license audits need to be approached with extreme caution.
Well, aside from the fact that SuSE has bundled Crossover - you can now get OpenExchange to manage "enterprise" email in a format that is compatible with MS Outlook and apparantly PDA's as well. Does anyone know if this really works? It claims to be "open" but I'm wondering what that means exactly.
And it looks like they will provide a PCMCIA-style reader device as well. This provides excellent backward compatibility, but the real test will be to get support from a major hardware vendor (Dell, Apple, HP?) and bundle the card reader into new PC's.
Some weirdness in their product description though. "...the StorReader supports a sustained data transfer rate of 5 megabytes per second in the 100 megabyte StorCard, and scales in the 5 gigabyte design".
I wonder what they mean by "scales".... YMMV?
That was pretty funny -- and oddly enough it might actually work!
NT (W2K) also seems to handle serial ports by sending sporadic streams of gunk to them, which could be related to this virtual interrupt handling scheme? We had a headless Sparc connected via serial cable to a W2K box, and for some reason -- every so often -- the Sparc would become unavailable.
It turned out the Windows dumb-terminal wasn't so dumb after all! It would occasionally send garbage characters to the tty and force the Sparc to a PROM prompt. Since the box was headless, we went through a lot of trouble to borrow a monitor and connect it to the Sparc.
Afterwards, we simply dropped the serial cable into a Linux box and accessed the dumb terminal from there. Evidently Windows wasn't up to the task of serving as a dumb terminal.
Funny -- I thought web browsers and the Internet were the same thing.
I had a similiar problem with an APC a few years ago. After receiving my new UPS from CDW, I proceeded to plug it in to my PowerMac and turn it on. Nothing happened so I followed the instructions to make sure everything was setup properly (battery enabled, plugged in, yada yada yada...).
A few minutes later -- POP! and then smoke was coming out of my *computer*.
After returning it to APC, they claimed it had failed because it wasn't designed for a United States voltage. Evidently this unit should have gone to Russia, but somehow it ended up in my lap.
At any rate, it was obviously my fault -- and so I was out a computer. APC was generous enough to replace it with an American model, which gathered dust for quite some time (until I was able to replace my computer). I recommend everyone take a look at Tripp, they make a UPS that won't burst into flames and include excellent software support for a number of operating systems.
LOL. funny -- "List of IDs for the Device Standard Which Must Not Be Named".
At any rate, this is a little out of proportion here. As another poster pointed out, you can't start a site and slap the IBM logo on the top of your page -- you would be infringing on a trademark and presenting consumers with some confusion.
How would someone visiting your version of the IBM page know that they aren't really visiting the IBM page?
You can, however, discuss the IBM corporation, products, etc. without appearing to be a representative of that corporate entity. In this case, that is the concern PCI-SIG and I think it would be perfectly acceptable to remove the logo and proceed using a slightly more newsworthy format.
Of course it might not be a bad idea to consult a lawyer just in case.
TBPH, I think Microsoft is attempting to conquor the elusive remote object invocation problem.
At first, it seemed like some version of RPC might solve this problem. And then a little bit later, developers were promised that CORBA was the future. Somewhere in there OSF/DCE made a lot of promises. And then Microsoft threw COM out there, and tried to spruce up some security issues with COM+...
Eventually EJB took hold, and now we have yet another way to remotely invoke objects via SOAP.
While things are looking up, I think most developers are fairly frustrated at this point. After grappling with IDL's and disparate RPC mechanisms, IUnknown and VisualBasic... I think unless there is a conserted effort by the industry to address remote object invocations (including a robust security model) then all of these attempts will continue to flounder.
What I really don't understand is what MS hopes to accomplish by tweaking their product names only very slightly. So it use to be Windows 2000 Server and now it's going to be Windows Server 2003... big deal.
.NET was really a bet-the-business proposition, they might as well call the product what it is. Windows Server for .NET Version 1.0. Maybe MS has realized that .NET isn't as much a fundamental paradigm switch as it is a client/server application you run on your computer.
.NET Applications Version 1.0. That might actually help the consumer a little!
If
And for that matter, the workstation version could be Windows Workstation for
Honestly, the users that were suppose to benefit from "consistent" naming conventions (Win 95, Win 98, Win 2000) have been duped with WinME, WinXP and whatever else MS is going to call their next workstation version of NT.
Enough of these naming "conventions" already; call it what it is. IMHO, Apple is doing the most work in this area -- an OS is simply OS # - makes sense to me.
Assuming the padding is coming from other frames on the same ethernet device, then it really seems unlikely that this is a security hole at all. The data has already been transmitted in a properly sequenced form, it would have been a lot easier to pickoff the data by sniffing the other transmission.
/. seemed to suggest this as a possibility, but based on the CERT advisory I really don't see any evidence of this.
Now, if the padding is the result of a semi-random memory location getting written to the end of your packets then that can be considered a fairly significant risk. Another posting on
What am I missing here? If we could stop quibbling over the how-much-MS-sucks-today factor maybe we could understand the true scope/nature of this problem. If there really isn't a problem, then perhaps it doesn't belong on CERT.
Since you don't manage your own memory on Java or C#, the concept of buffer overflow doesn't really apply. While the array construct still exists in both languages, you can't overflow an array without going out of bounds.
It is critical that the software industry start to adopt VM's for managing applications, especially code that runs on a server. The emergence of a user-mode kernel for Linux is a critical development in this regard, but ultimately it makes more sense to modernize your codebase to Java, C# or any of the interpretive languages that can intercept/manage memory allocation checks for you.
I couldn't agree more -- I think Lindows is making all the smart business decisions it needs to make in order to ensure the survival of their product.
While you don't have to use Click & Run, I think it's a brilliant marketing ploy -- and it's also something that users can understand. If you want to install more software, as long as you have a subscription to the Lindows Click & Run service you can point & click to install more programs.
Let's face it, the average computer user will benefit from the GUI-ified virtual warehouse of open source software that Lindows has pre-prepared . Running apt-get from a command prompt or launching make from a command prompt or even figuring out how to download an RPM from a command prompt is _not_ something that the _average_ user is going to want to do. While there are GUI's for most of these tools, I have not seen any of them that promote software in a way that consumers can understand.
In other words, if you don't know what you want you're going to be fairly lost. With Click & Run, if you don't know what you want then chances are you can find something that either interests you or remotely meets some requirement you might have. Bottom line; pictures and promotional text help entice average computer users.
As far as the root execution goes, I wasn't too thrilled about that either. Even Windows is getting pretty good with that - although the majority of users just stuff themselves into the local Administrators group anyway. Since the KDE tools are flexible enough to handle a prompt for root password whenever required, I think one can safely assume non-root day-to-day running will be feasible.
I like the Lindows model. While I don't plan to run it myself, I know plenty of people who would be well suited to this platform. Always keep in mind that open source does not mean _free_, open source always means open source and free is your freedom to choose how you want to use that source.
You know... it sure would be nice if you could eject the tape after running a backup on a Windows box....
This is the easiest way to show your backup probably succeeded (aside from checking the email of the backup results).
not always. After a bad experience with an MS Exchange server crashing, my fix was not simply an install away. It ultimately involved a variety of Windows registry tweaks to "remind" the W2K AD DC that the Exchange server with the same name was actually a new server.
None of this was documented anywhere. BTW, if you get stuck with this and have to modify the AD forest directly I highly recommend using an LDAP tool rather than the MS ADSI utility. MS hides too much stuff from you and will prevent you from making a complete recovery.