Nope, sorry... I don't buy the Richard Stallman line of bullshit regarding Software Communism.
Microsoft is right, Open Source is a threat to the software industry and as a result to our US Economy.
I don't see how you could deny that, considering that's the admitted point of your revolution. You just don't care what the perimiter consequences are to your bread and butter.
Well by that argument someone could replace everything in/usr/lib with bash scripts and kill Unix. Yep, you replace system files with nonsense and things won't work.
How do you prevent this from happening on Unix? Well the files are only writeable by someone with root access.
This is also true of Win2k, the files are only writeable by someone with Administrator.
Without having different types of user security access, or by burning everything to ROM, I'm not quite sure how you suggest resolving this issue.
Ok, I don't think you understand at all what DLL Hell is on Windows. Your assumptions as flawed at any rate.
The problem with DLL Hell under Windows has nothing to do with a lack of versioning. DLLs do have versioning, and Microsoft has tried to always be careful in leaving old interfaces compatible so as not to break upward compatibility. In cases where they clearly have to break compatibility they do the same thing as Unix... they create new files with new names.
VSVBVM60.DLL was a replacement for VSVBVM50.DLL which left the 5.0 functionality intact. However there have been like half a dozen versions of VSVBVM60.DLL released which fix bugs internally without breaking external interfaces.
With COM you don't even care about the filename since all interactions with the component are through the ClassID. You can create a new file, with a new name that registers the same ClassIDs as the old component and redirects them internally as appropriate.
There are differences between COM and classic DLLs and I'm going to talk about classic DLLs primarily because that's where the DLL Hell problem has occured primarily.
Now one problem with classic DLLs is that only one copy of a DLL is ever loaded into memory, and this has created many problems. This isn't completely true under Windows 2000 which has additional new features I'll mention later.
Where DLL essentially comes into play is from REALLY STUPID BRAINDEAD INSTALL PROGRAMS! Not to mention Microsoft's lack of attention to this problem existing and unwillingness to do anything about it, even if it was just education.
As an example, let's say you have version 4.1 of generic.DLL installed on your machine by application X.
Application X works fine.
Now you install application Y. This install program installs a copy of generic.DLL version 4.0.
Now application Y's install program is broken, it either does two stupid things, it installs this old copy of generic.DLL over the top of the newer copy already in windows\system. Or it places it in the application directory.
In the latter case, if you run app X before app Y everything works fine. But if you run app Y, when the system searches for the DLL it finds one in the app path first and loads that. All subsequent requests for this shared DLL are passed the pointer to the one already in memory.
In the former case, app X is never going to work if it relies on functionality which existed only in the newer copy of the DLL that it had installed. app Y broke it permanently by stupidly overwriting a newer DLL.
Similarly with COM DLLs one could overwrite a newer version of a control with an older version which breaks assumed functionality.
The solution is actually really quite obvious in 95% of all cases. Most of these DLL problems result from shared DLLs as part of the OS or distributed with the MS Development tools. The solution therefore is to only allow Microsoft to distribute and update these via Service Packs. This is the path they have finally gone down in Win2k.
That is to say these MS shared system DLLs should never be deployed with an application. If your app needs a certain version then you should specify that you need Service Pack 4 or whatever.
We'll see if this happens with say Office XP.
You then only have an issue with shared third party controls. Now this can be solved by using Win2k's ability to localize DLLs to the application and thus load multiple different versions.
Anyway, that's basically a definition of the problem.
BTW, as to your signature line... Linux/BSD is not my main server/workstation and I'm pretty certain I'm far less ignorant than yourself on topics regarding Windows as a result.:-)
If you have a server on the internet which you want people to connect to, it's got to be advertised somehow.
Won't be hard to locate them.
If the RIAA can get Congress to pass a law which places a substantial fine on those convicted of running internet services for the purpose of piracy... Which isn't that unlikely. The DMCA places something like a $1 million fine on creating tools to subvert copy protection.
Who will be able to afford to risk running said service? Bill Gates, maybe Larry Ellison. Doubt that'll happen.
Ok, but now OpenNap basically just utilizes the Napster paradigm and therefore puts into place Index servers.
If the RIAA succeeds in suing Napster and blocking their service, which seems very likely at this point. It is not at all far fetched that they will easily be able to receive court orders against anyone else running the same time of service.
So your OpenNap is not a replacement service because every index server is liable for a court ordered shutdown.
That and the index server requires bandwidth, bandwidth costs money and how many people are going to donate full T3 lines to this? Thus the service is capped in terms of the number of connected users based on bandwidth available.
Once Napster is dead, there will be nothing else to replace it at the same scale unless it is operated with the blessing of the RIAA.
1) If you can stomach the way the Mac treats you, hey that's great!
2) Ok, first you have to realize that Apple did not invent the GUI. Windows copied the Amiga, GEM and other systems just as much if not more than the Mac. Actually besides the fact that they both use a mouse and a graphics card, I find very few other similarities.
3) Didn't say Windows users... I said Windows programmers and other people supporting the product. Without support, the OS is dead.
It may be one of the Mac's strengths... But it has also been one of the reasons why the Mac has been a failure.
Those of us who are adept with computers do not appreciate the way the Mac treats everybody as an idiot. I've found the Mac incredibly frustrating to use over the years, but that's not to say I wouldn't recommend it to a friend I didn't want calling me for help. Thus the problem is the adept people who might actually support and write software for the Mac universally despise it, which can't help it's marketing.
Granted, Windows started down the path of everybody is an idiot. But then most people are. But Windows also provides you with the other tools one needs to actually dig down in deep and do your work. So it's simple enough for idiots, powerful enough for programmers.
Now Unix on the other hand has the unique distinction of being the OS for everybody but idiots. It's elitist, but it works for some people.
So we have a different OS for everybody, and obviously the one which has taken the middle ground is the most popular.
The problem I see is that if Unix starts going down the path of Windows, it will simply become Windows.
And at that point, why not just save a lot of effort and use and improve Windows to begin with?
I've never been a big fan of the Linux everywhere argument, I think it's silly.
Interesting. But then that pretty much kills the Write-Once Run-Anywhere paradigm, since the minute I take advantage of a Mac specific feature... it won't run anywhere else.
So now you have a case that if you want a cross-platform solution you have to write your code to be portable.
Which makes Java just like any other language, just with a lot more overhead.
I am by no means an expert on.Net, but I have been reading quite a bit..Net is a marketing term which covers a whole lot. There are various pieces, and I believe you are focused solely on C# and the CLR.
But as to your question. It's hard to say since there isn't a Unix implementation yet.
But the GUI elements of C# seem to me to be quite portable.
Your write something like:
private Button button1 = new Button();
button1.Location = new Point(10,10);
button1.Size = new Size(50,25);
button1.Text = "OK"
button1.Click += new System.EventHandler(button1_Click):
and so forth...
That and the other GUI primitives seem to me to be quite portable.
Now there are obviously going to be things that you can do on Windows easily that you won't be able to do on Unix simply because Windows supports the functionality and Unix does not.
And vice versa.
From what I have seen Java limits you to the lowest common denominator. Microsoft didn't want to make that mistake, and thus C# is far more flexible in what it will allow you to do.
That's my Advanced Server. My machine on the other hand is a Gateway P6-200, which makes it a known quantity.
Your problem sounds like hardware. I've had machines lock up before for a variety of reasons. Bad power supplies, bad fans, bad drives, etc.
In fact I just had such a problem with the CDROM on my home computer. Long story, but even though the computer would freeze periodically, Win2k never crashed on me.
".NET seems to drag along a signifigant part of the Windows API. "
You seem to be considerably confused over what.Net is. That's not unsurprising, as I think Microsoft has not communicated that well.
.Net encompasses a great deal of change for the Windows platform. But in this case, the piece of.Net being discussed between Microsoft and Sun is SOAP, or essentially XML based RPC over HTTP.
That is standardized, it has nothing to do with Windows API, and it is the key to interoperability between systems.
It's amazing to me the number of people who complain about.Net and just don't get it, primarily because they aren't willing to sit down and learn about it.:(
Yes, and I heard Bill Gates mother is a member of the Costa Nostra.
It's funny. There's no shred of evidence that Microsoft engages in these practices today so therefore they must be true.
But while I was talking about the application division using undocumented calls in Win3.1, you were talking about third party companies supposedly having access to undocumented calls which are only documented if you give MS money.
Which seems rather loopy to me.
Look, not everybody in the world is conspiring to get you. Just remember that and live your life.
Could you please provide substantiation for your facts.
I would like to see evidence that Microsoft is providing undocumented API calls to soundcard manufacturers.
Microsoft understands that it is in the best interests of them and their consumers that all available hardware operates on their OS. As such they do not purposefully make it difficult for one company over another. This hardware agnosticism is the secret of Microsoft's success.
There was an allegation that about 7 years ago Microsoft did use undocumented API calls in their only internal software. This came out during the court case which resulted in the consent decree of 1995.
That's a long time and many things have since changed. But it does nobody any good for people to distort the record to try to claim their pet conspiracy theories are reality.
For someone who keeps falsely claiming that CDs cost $20 when in reality they are in the $12-15 range, I find it hard to understand why you are accusing someone of inflating ticket/t-shirt prices.
Ok, first of all mp3 sales are absymal because they sound like crap and nobody is willing to pay for them. The existence of mp3's is a side effect of the initial CD purchase.
So I don't believe MP3 will ever replace CD as a purchase mechanism.
Furthermore, MP3 is only a stopgap in the middle of the technology evolution.
Consider storage requirements. Why do you need MP3? A 80 Gig harddrive can be purchased for just under $300. That will hold around 125 CD's, not at MP3 quality, but at full ripped bitstream.
Consider also a DVD. Right now a CD-R holds like maybe 10 CDs ripped as MP3 files. But a DVD-R could contain the same amount of full CD quality WAV files.
The only thing holding back things right now is internet bandwidth. As technology advances in that realm... then who cares?
But still the initial sale is going to be in the form of CD or something similar.
At least for now, perhaps in the future I'll have access to 5 terabytes of reliable storage in my wristwatch with a Gigabit wireless ethernet interface and I'll refactor my opinion.
The sad truth(for your argument) is that we, as consumers, really do have a great deal of control of what is foisted upon us by Hollywood.
DivX comes as the most recent example. Minidiscs are another one, or do you not remember when Sony first introduced them you were going to buy your pre-recorded music on MD's instead of CD's?
All it takes to kill a technology is lack of consumer acceptance. If people don't buy it, it won't sell. And companies are not stupid enough to put themselves in a position where they have no product consumers want to buy.
Slashdot Mirror
I don't appreciate it when obviously uninformed people try to claim I'm wrong.
I verified this fact before posting my original message. The system files are not world writeable on Windows 2000.
Not even by default.
You had better go reevaluate your preconceived notions because it seems the world has turned upside down on you.
Heh.
Nope, sorry... I don't buy the Richard Stallman line of bullshit regarding Software Communism.
Microsoft is right, Open Source is a threat to the software industry and as a result to our US Economy.
I don't see how you could deny that, considering that's the admitted point of your revolution. You just don't care what the perimiter consequences are to your bread and butter.
I commend Jim Allchin for bringing up a point that a lot of us have been saying for years.
Only we get moderated down as trollbait on slashdot.org. Mr. Allchin on the other hand isn't going to be kept quiet before government discussion.
I think that's a good thing, start putting some of these inflated assumptions to the fire.
Well by that argument someone could replace everything in /usr/lib with bash scripts and kill Unix. Yep, you replace system files with nonsense and things won't work.
How do you prevent this from happening on Unix? Well the files are only writeable by someone with root access.
This is also true of Win2k, the files are only writeable by someone with Administrator.
Without having different types of user security access, or by burning everything to ROM, I'm not quite sure how you suggest resolving this issue.
Ok, I don't think you understand at all what DLL Hell is on Windows. Your assumptions as flawed at any rate.
:-)
The problem with DLL Hell under Windows has nothing to do with a lack of versioning. DLLs do have versioning, and Microsoft has tried to always be careful in leaving old interfaces compatible so as not to break upward compatibility. In cases where they clearly have to break compatibility they do the same thing as Unix... they create new files with new names.
VSVBVM60.DLL was a replacement for VSVBVM50.DLL which left the 5.0 functionality intact. However there have been like half a dozen versions of VSVBVM60.DLL released which fix bugs internally without breaking external interfaces.
With COM you don't even care about the filename since all interactions with the component are through the ClassID. You can create a new file, with a new name that registers the same ClassIDs as the old component and redirects them internally as appropriate.
There are differences between COM and classic DLLs and I'm going to talk about classic DLLs primarily because that's where the DLL Hell problem has occured primarily.
Now one problem with classic DLLs is that only one copy of a DLL is ever loaded into memory, and this has created many problems. This isn't completely true under Windows 2000 which has additional new features I'll mention later.
Where DLL essentially comes into play is from REALLY STUPID BRAINDEAD INSTALL PROGRAMS! Not to mention Microsoft's lack of attention to this problem existing and unwillingness to do anything about it, even if it was just education.
As an example, let's say you have version 4.1 of generic.DLL installed on your machine by application X.
Application X works fine.
Now you install application Y. This install program installs a copy of generic.DLL version 4.0.
Now application Y's install program is broken, it either does two stupid things, it installs this old copy of generic.DLL over the top of the newer copy already in windows\system. Or it places it in the application directory.
In the latter case, if you run app X before app Y everything works fine. But if you run app Y, when the system searches for the DLL it finds one in the app path first and loads that. All subsequent requests for this shared DLL are passed the pointer to the one already in memory.
In the former case, app X is never going to work if it relies on functionality which existed only in the newer copy of the DLL that it had installed. app Y broke it permanently by stupidly overwriting a newer DLL.
Similarly with COM DLLs one could overwrite a newer version of a control with an older version which breaks assumed functionality.
The solution is actually really quite obvious in 95% of all cases. Most of these DLL problems result from shared DLLs as part of the OS or distributed with the MS Development tools. The solution therefore is to only allow Microsoft to distribute and update these via Service Packs. This is the path they have finally gone down in Win2k.
That is to say these MS shared system DLLs should never be deployed with an application. If your app needs a certain version then you should specify that you need Service Pack 4 or whatever.
We'll see if this happens with say Office XP.
You then only have an issue with shared third party controls. Now this can be solved by using Win2k's ability to localize DLLs to the application and thus load multiple different versions.
Anyway, that's basically a definition of the problem.
BTW, as to your signature line... Linux/BSD is not my main server/workstation and I'm pretty certain I'm far less ignorant than yourself on topics regarding Windows as a result.
If you have a server on the internet which you want people to connect to, it's got to be advertised somehow.
Won't be hard to locate them.
If the RIAA can get Congress to pass a law which places a substantial fine on those convicted of running internet services for the purpose of piracy... Which isn't that unlikely. The DMCA places something like a $1 million fine on creating tools to subvert copy protection.
Who will be able to afford to risk running said service? Bill Gates, maybe Larry Ellison. Doubt that'll happen.
Ok, but now OpenNap basically just utilizes the Napster paradigm and therefore puts into place Index servers.
If the RIAA succeeds in suing Napster and blocking their service, which seems very likely at this point. It is not at all far fetched that they will easily be able to receive court orders against anyone else running the same time of service.
So your OpenNap is not a replacement service because every index server is liable for a court ordered shutdown.
That and the index server requires bandwidth, bandwidth costs money and how many people are going to donate full T3 lines to this? Thus the service is capped in terms of the number of connected users based on bandwidth available.
Once Napster is dead, there will be nothing else to replace it at the same scale unless it is operated with the blessing of the RIAA.
The same virus could be written in ECMAScript, aka Javascript, aka JScript.
1) If you can stomach the way the Mac treats you, hey that's great!
2) Ok, first you have to realize that Apple did not invent the GUI. Windows copied the Amiga, GEM and other systems just as much if not more than the Mac. Actually besides the fact that they both use a mouse and a graphics card, I find very few other similarities.
3) Didn't say Windows users... I said Windows programmers and other people supporting the product. Without support, the OS is dead.
It may be one of the Mac's strengths... But it has also been one of the reasons why the Mac has been a failure.
Those of us who are adept with computers do not appreciate the way the Mac treats everybody as an idiot. I've found the Mac incredibly frustrating to use over the years, but that's not to say I wouldn't recommend it to a friend I didn't want calling me for help. Thus the problem is the adept people who might actually support and write software for the Mac universally despise it, which can't help it's marketing.
Granted, Windows started down the path of everybody is an idiot. But then most people are. But Windows also provides you with the other tools one needs to actually dig down in deep and do your work. So it's simple enough for idiots, powerful enough for programmers.
Now Unix on the other hand has the unique distinction of being the OS for everybody but idiots. It's elitist, but it works for some people.
So we have a different OS for everybody, and obviously the one which has taken the middle ground is the most popular.
The problem I see is that if Unix starts going down the path of Windows, it will simply become Windows.
And at that point, why not just save a lot of effort and use and improve Windows to begin with?
I've never been a big fan of the Linux everywhere argument, I think it's silly.
Your band doesn't seem to exist on mp3.com.
Besides, you would never be able to tell the quality of the produced music using an MP3 since the format is so incredibly lossy.
Sometime try listening to your MP3 music with a pair of cheap Grado SR-80 headphones and see if you can stomach it.
How incredibly predictable.
An article about rebates for software purchased includes a rip on some unrelated Microsoft thing.
Where else but slashdot.org would you ever find people stupid enough to link the two together?
Interesting. But then that pretty much kills the Write-Once Run-Anywhere paradigm, since the minute I take advantage of a Mac specific feature... it won't run anywhere else.
So now you have a case that if you want a cross-platform solution you have to write your code to be portable.
Which makes Java just like any other language, just with a lot more overhead.
Why would SuSE send you a price list?
All you have to do is go buy one copy and redistribute it as many times as you like with no charge.
Seems like for the price of mailing you a pricelist they could just send you that CD instead.
I am by no means an expert on .Net, but I have been reading quite a bit. .Net is a marketing term which covers a whole lot. There are various pieces, and I believe you are focused solely on C# and the CLR.
But as to your question. It's hard to say since there isn't a Unix implementation yet.
But the GUI elements of C# seem to me to be quite portable.
Your write something like:
private Button button1 = new Button();
button1.Location = new Point(10,10);
button1.Size = new Size(50,25);
button1.Text = "OK"
button1.Click += new System.EventHandler(button1_Click):
and so forth...
That and the other GUI primitives seem to me to be quite portable.
Now there are obviously going to be things that you can do on Windows easily that you won't be able to do on Unix simply because Windows supports the functionality and Unix does not.
And vice versa.
From what I have seen Java limits you to the lowest common denominator. Microsoft didn't want to make that mistake, and thus C# is far more flexible in what it will allow you to do.
http://www.sodablue.org/computers/windows2000/reli ability.asp
That's my Advanced Server. My machine on the other hand is a Gateway P6-200, which makes it a known quantity.
Your problem sounds like hardware. I've had machines lock up before for a variety of reasons. Bad power supplies, bad fans, bad drives, etc.
In fact I just had such a problem with the CDROM on my home computer. Long story, but even though the computer would freeze periodically, Win2k never crashed on me.
".NET seems to drag along a signifigant part of the Windows API. "
.Net is. That's not unsurprising, as I think Microsoft has not communicated that well.
.Net being discussed between Microsoft and Sun is SOAP, or essentially XML based RPC over HTTP.
.Net and just don't get it, primarily because they aren't willing to sit down and learn about it. :(
You seem to be considerably confused over what
.Net encompasses a great deal of change for the Windows platform. But in this case, the piece of
That is standardized, it has nothing to do with Windows API, and it is the key to interoperability between systems.
It's amazing to me the number of people who complain about
Win2k doesn't crash regularly, it crashes hardly at all.
Win2k embedded is unlikely to be $500/unit, but more like a 1/10th that cost.
You don't seem to know what WinCE is either.
There are also other options in the embedded market such as Coherent, OS/9, etc.
But the ultimate sign of ignorance was when you claim that Windows is just a gaming machine.
Do you even know what Windows NT or 2000 is?
Yes, and I heard Bill Gates mother is a member of the Costa Nostra.
It's funny. There's no shred of evidence that Microsoft engages in these practices today so therefore they must be true.
But while I was talking about the application division using undocumented calls in Win3.1, you were talking about third party companies supposedly having access to undocumented calls which are only documented if you give MS money.
Which seems rather loopy to me.
Look, not everybody in the world is conspiring to get you. Just remember that and live your life.
Could you please provide substantiation for your facts.
I would like to see evidence that Microsoft is providing undocumented API calls to soundcard manufacturers.
Microsoft understands that it is in the best interests of them and their consumers that all available hardware operates on their OS. As such they do not purposefully make it difficult for one company over another. This hardware agnosticism is the secret of Microsoft's success.
There was an allegation that about 7 years ago Microsoft did use undocumented API calls in their only internal software. This came out during the court case which resulted in the consent decree of 1995.
That's a long time and many things have since changed. But it does nobody any good for people to distort the record to try to claim their pet conspiracy theories are reality.
"BTW, do Americans really believe that left-handed people can't drive stick-shifts?"
I doubt most Americans think that. Instead their response would be "What is a stick-shift?"
For someone who keeps falsely claiming that CDs cost $20 when in reality they are in the $12-15 range, I find it hard to understand why you are accusing someone of inflating ticket/t-shirt prices.
Ok, first of all mp3 sales are absymal because they sound like crap and nobody is willing to pay for them. The existence of mp3's is a side effect of the initial CD purchase.
So I don't believe MP3 will ever replace CD as a purchase mechanism.
Furthermore, MP3 is only a stopgap in the middle of the technology evolution.
Consider storage requirements. Why do you need MP3? A 80 Gig harddrive can be purchased for just under $300. That will hold around 125 CD's, not at MP3 quality, but at full ripped bitstream.
Consider also a DVD. Right now a CD-R holds like maybe 10 CDs ripped as MP3 files. But a DVD-R could contain the same amount of full CD quality WAV files.
The only thing holding back things right now is internet bandwidth. As technology advances in that realm... then who cares?
But still the initial sale is going to be in the form of CD or something similar.
At least for now, perhaps in the future I'll have access to 5 terabytes of reliable storage in my wristwatch with a Gigabit wireless ethernet interface and I'll refactor my opinion.
The sad truth(for your argument) is that we, as consumers, really do have a great deal of control of what is foisted upon us by Hollywood.
DivX comes as the most recent example. Minidiscs are another one, or do you not remember when Sony first introduced them you were going to buy your pre-recorded music on MD's instead of CD's?
All it takes to kill a technology is lack of consumer acceptance. If people don't buy it, it won't sell. And companies are not stupid enough to put themselves in a position where they have no product consumers want to buy.
"Don't be obtuse. "
Yes, I forgot... In order for a conspiracy theory to have any validity one must ignore all facts to the contrary.
Kook