I agree with what you are saying, but fail to see how Huusker's original point that the split between OS and Apps is going to remedy any of the issues he raised with *SYSTEM* level APIs.
The simple fact is that it won't.
I'm not denying any of the point's you've made, simply saying that none of them affect the fact that an OS/Apps split is not going to solve any of the hassles that system level interoperability requirements need. This is not going to give the Samba team the Kerberos specs, the full NT RPC specs or anything like that - read what the DOJ wrote and you'll see that only API specs between OS and Apps are required to be disclosed.
So, I say that you have a good point and the DOJ solution makes no difference.
Windows integrates VB Script about as much as Unix integrates shell scripts. Basically it is a user level scripting language. I've already said it was bad for having no real security against logged on users, but how many average users do you know that could use NT or Unix to set up a secure system for themselves?
"I'm told that all the user has to do is look at this thing in a viewer pane, and that thier machine will no longer boot" - you should be really careful what you are told. You have to run the script from the email and actually let the system run it when it warns you if you want to open the file (assuming you have the default install). Try not to spread misinformation - it only lowers the signal to noise level and just makes people ignore you.
"People are hammering Microsoft for making a product that can be destroyed so easily just so they can cram stuff down their user's throats." - no. People are hammering MS because they are a good scapegoat at the moment. Windows is no more easily destroyed than me sending you a file that says sudo rm -r/ and asking you to run it. Is it Linux's fault that it is so easily destroyed by a one line command? I think not. It is the user that is the problem here.
"There's nothing more wrong with VB script than, let's say, Lotus script. It's something that can be changed at will by a single company that will not run anywhere else. Keeping up with changes will keep you from learning something usefull. It's a dead end." - except the whole point of this worm is that VB script hasn't and isn't likely to change. In fact, VB script has been a lot less of a moving target than most of the OSS projects I know. If VB Script changed regularly then worms like this would not be possible because they wouldn't execute on most machines.
Do you actually realise the hypocrisy of your statements?
Thanks for the vote of confidence, but I really wasn't going that far in my advocacy of the Win32 API. My basic point was that a breakup of Microsoft into OS and Apps will not force any release of internal APIs that aren't being used for applications. Take all the Office applications, and even IE and I think you'll find they exclusively use Win32 (documented or not) as they run on both 9x and NT/2000. A breakup would force disclosure of the full Win32 API - as Huusker pointed out there are still some areas of doubt such as CreateProcessAsUser - but would probably cement the internal subsystem and NT kernel API firmly into the bounds of NDAs.
I don't think that even the DOJ is claiming such functions as network file sharing, user logons and process/thread/memory management are in the realm of applications so you won't find any necessesity for an OS company to be disclosing any of this information to the public. In fact with well over 90% of the market the OS company would probably continue on with business as usual and keep their secrets to themselves until it became profitable again for the company to interact with other systems.
Win32 functions are not slow, crippled or anything of the sort. Huusker's point was that there is a lower level API available that would make it far easier to implement a Unix like system on NT, to implement interoperable network systems and to generally gain a higher degree of interoperability with less popular systems. In this he is mostly correct. He is blatantly incorrect in his statement that splitting Microsoft will ease this situation at all.
Huusker made some claims that NTLM authentication over a socket was hard to do. I implemented it in a few hours with VC6 and an MSDN CD so it really can't be too bad. Just take the sample code, read the comments, read the API description and it just works. Netscape have probably rejected this as an option as it is very platform specific and ties their code base to a Microsoft technology - something they have tried very hard not to do. I doubt that they are seriously needing anything more than what is readily available to implement it if they felt like it.
I believe one of the big reasons Microsoft has succeeded in the past is that they have played very tough on the business side and have been (relatively) generous to developers on the development side. RAD tools such as VB and technologies like COM cemented their position as the programming platform of the 90s. Things may change now with the maturity of OSS, but that question is yet undecided. The end result of this court case after all appeals have been heard will probably dictate the future direction of computing. Let's all hope it is a good one for industry and consumers alike.
Excuse me for pointing out the blatantly obvious in your post, but none of the APIs you mentioned are used by the Apps team and none of them would require disclosure in a OS/Apps chinese wall.
Remember that applications are written to Win32 and not to the raw NT API hence NTCreateProcessToken(), Subsystem APIs and NTLM RPCs are not part of this.
Also, I've implemented authentication using NTLM over a socket quite happily using the published APIs. Your claim that Netscape cannot do this either implies that the guys at Netscape are fools or they have an alternate agenda. Look at the sample program in MSDN!!
I hate to say it but your post was ill informed, inaccurate and bordering on an outright lie.
Don't forget to make your script run as root and destroy system files!
The trojan did not run as 'root' on any system it infected except where the user was running as root. I think you totally misunderstood the problem here. The point is that Win9x always runs you as root but I don't see anyone hammering 'Bad Windows', just 'Bad VB Script'. That sort of argument is incredibly stupid and naive.
Of course, the fact that it didn't destroy system files makes your argument completely wrong. All it did was add some extra lines to the registry, in what is effectively your.bashrc file. Guess what else? This is entirely possible on Unix when not running as root. Write a shellscript that throws itself in.bashrc and parses all your dotfiles for email addresses, sending it self (in some useful form) to other users. It would probably even work if you could make it do something useful or pretty at the same time...
You are right. This is not a battle. Why are the Linux zealots treating it as one?
You failed to take long enough to let things sink in:
An applications company will necessarily develop for all platforms, since it will not care about the success of a particular one. Office for Mac and Linux is right around the corner. An applications company will seek to maximize profits by making it's product available on all possible platforms.
This is exactly how not to maximise profits. The best way to maximise profits is to minimise the complexity in your code base while targeting the maximum number of users. There will be absolutely zero incentive for the Apps company to change their behaviour. Think about it. 90% of users have Windows. 9% of users have a Mac. Selling Office for Windows only and then the Mac a year later (if at all) gives you the maximum return on your development effort because it means you don't have to maintain a lot of different code bases.
Look at the game industry - most companies there do exactly what the Office and IE division do at MS. They release a Windows version first and then gauge demand for a Mac version. What makes you expect MS/Apps will be any different?
An operating systems company will seek to support as many different applications as it possibly can, to make its product OS(es) as desirable to customers as possible. It will be in the best interest of such a company to make the OS easy to code for, and to make the API available to all application developers.
It may make a difference here, but not a big one. Windows is already easy to code for (through APIs, products like VB etc.) and the API is available to pretty much anyone who wants to download the Platform SDK. This remedy will stop early releases of APIs to MS/Apps only if they can relocate the entire MS/Apps team to somewhere in Miami to stop them talking to people in Seattle. It will not stop Windows to continue to be developed in the way it has before, it will not somehow magically make KDE or Gnome as desirable for apps companies as Windows currently is and will not be an effective remedy.
I am disappointed with the DOJ in suggesting this. They would have been far better splitting into about 4 companies: Win9x, WinNT + Backoffice, Applications and Hardware, but I guess they saw that as even more radical. I know Jackson doesn't like MS and has been leaning to the DOJ and States but BG and SB could only be rubbing their hands with glee saying "That's all they want to do?".
I know it is getting silly carrying on a/. post for this long, but what the
hell. This one is interesting (to me anyhow).
So what if Apple happens to ship their hardware and software together?
They still compete with microsoft for users.
So if 'competing with Micro$oft' is a criteria for systems that should be
OSS, the AIX, IRIX and Solaris should all be open source. Either that or
you have no problems with W2K Enterprise Edition being closed source. My
main point is that quality is not necessarily dependant on OSS at any level of
the market. OSS definitely helps, but any commercial software company can
easily produce stable software *without* releasing the source. OSS nuts
should come down to earth and realise that maybe there are other models that
work.
Instead I buy the hardware that's supported by specs or source-available
drivers. In other words, instead of whining about the problem I vote with my
dollars and actually do something about it. The fact that you want to throw away
twenty years worth of others' efforts just so you can have your binary-only
shitware drivers for hardware you shouldn't have bought in the first place
doesn't mean I should have to pay the price for it.
I personally don't use binary-only shitware drivers. I'll
happily use stable binary-only drivers though. I also vote with my dollars
and feel that OSS is not a necessary condition for good software, backed up by
numerous examples of non-OSS commodity software that is out there. Telling
me I shouldn't have bought hardware that I researched and found to be the best
value for money is the height of arrogance. That is no different to a
doorknocker telling me I need to see things his way before I get to heaven.
That doesn't mean the other architectures receive any less attention, just
that Linus delays putting in the applicable patches.
As Linus controls and owns Linux, all I can say is that if Linus delays
patches for alternate hardware then Linux has less of a focus on that
hardware. Simple.
Well, considering that I've been following the development series since
1.3 and reading more or less every patch, and l-k, and sparclinux, I'm not
really sure what else you think I should be reading. Perhaps the nVidia
marketing drivel that serves as the source of your information?
How about that? What does the nVidia marketing drivel say even? I
certainly haven't been quoting it and if you have to sling strawmen and
misquotes my way to counter my arguments then I'd say you are sounding more and
more like a religious fanatic than a reasoned person. If you believe that
OSS is the one true way to stable software then go and hide in your own corner
and use it. Stop annoying those of us that believe using stable software
from any source is far more rational.
But what you haven't grasped is that in a closed-source model there must
be some motivation for the vendor to provide quality. In a commodity market
heavily influenced by microsoft there is no such motivation. Hence the
closed-source software that gets produced is crap. If you want to talk about
things being a totally different market, I'd say the same about million-dollar
systems. It's a whole new ball game at that level, and source availability isn't
a prerequisite for quality.
The vast majority of commodity computing items are both closed source and
ultra-reliable. How many times has the embedded system in your car
crashed, your digital watch crashed or your microwave thrown an exception.
Claiming that the (small) commodity base of Intel PCs is a reflection on the
state of the industry is foolishness.
Where is the motivation for quality drivers? Simple - if the drivers
don't work then the card doesn't sell. Take for example the Diamond Viper
II which was a great piece of hardware that had absolutely horrific Windows
drivers. The card was a flop. That's your motivation for quality
pure and simple. nVidia has always had it and your assertions to the
contrary have no basis in fact.
Apple chooses to provide poor quality software because they can. Look who
they're competing with...
LinuxPPC and BeOS? I've never seen a Microsoft operating system that
runs on Mac hardware.
Linux is more accepted than the Hurd for several reasons. First to market,
faster, not based on a platform (Mach) that has never really had any success,
not fucking vapourware,... Why it was written is irrelevant.
Not true again. The reason it is not vapourware is the exact reason it
was written: to solve a problem and not to further RMS's personal
religion. Linux is a practical operation system and Linus a practical
person. If that troubles you, ask why the core specs and instruction set
for Crusoe aren't available before you start casting doubt on other companies
for not releasing their specs.
I don't want nVidia to care about Linux. I want them to do The Right Thing
and let people have the damn programmer's manuals for their chips. Linux hasn't
a thing to do with it.
nVidia doesn't have to release their specs to write good drivers. It is
that simple. OSS is no guarantee of quality (as you seem to assert) and if
nVidia chooses to write quality drivers in-house rather than let the OSS
community write them I think it is still a good thing for Linux. If you
think otherwise then you are putting religion before practicality.
You can think what you like, I suppose. But when you turn around and
realize that Linux has become a joke as a Free system don't complain to me.
If that happens, you'll be the last person I complain to. Trust me on
that. On the other hand, if Linux lacks hardware support because the Linux
community can't accept one ounce of close source then you shouldn't complain to
anyone - you made your bed so sleep in it.
Linux is orthogonal to the peecee; anyone who tells you otherwise has been
reading too much marketing hype and not enough source code.
Hmm. I've read the source. Why is it that most kernel changes are
tested first on PC hardware and then on other hardware? Why is it that the
TBD stuff on development kernels always seems to be porting the PC code to other
systems and not the other way around? Maybe Linux is a little more PC
centric than you thought? Perhaps you should read more source code?
And every person who willingly uses a proprietary driver is (at least!) one less sale NVIDIA can only earn by making proper support possible. Not to mention one less potential owner for a SMP or non-x86 box.
Not true. Looking at history, this will not mean one less sale for nVidia but one more sale for Microsoft. If you are so blind to consumer reality that you can't see hardware support being critical to consumer support of an operating system then I suggest you need to wake up a little from your OSS religion and look at the real world some time.
These drivers are good for Linux because it means less people that will need Windows to support the best commodity 3d hardware available. If you can't see that then you have a hidden agenda.
According to Anand, the GF2 comes in AGP and PCI versions. Given that the GF2 does geometry processing on board, it should be a far better solution than the V5 for the slower PCI bus. Naturally you can enjoy FSAA on the GF2 as well and still enjoy X-Plane at higher frame rates than the V5 will give you.
If every hardware vendor offers drivers under the same license, your
once-stable unix-like operating system has become the hell that is AIX and S/390.
Oh, that's right. They are very stable (probably more stable than
Linux) and don't offer source for their drivers. Maybe closed source isn't
quite as bad as you have deluded yourself into believing.
> It is good for Linux users.
No, it is not. See above.
So by your estimation, no drivers is better than some drivers. Don't be
a fool. Of course quality drivers is good for Linux whether they are open
source, closed source or tomato sauce. Get a clue on the real world!!
> It shows that Linux is being treated equally among OSs. nVidia
wouldn't release their source to Microsoft, and they aren't doing it for the OSS
community.
How is this good? The purpose of Free software is not to gain a place in
the proprietary software world as an equal to Microsoft's offerings!!! It's to
be a fundamentally different, and better, way of using computers.
...and I thought it was because Linus didn't like Minix or DOS and so he
wrote a Unix that he did like. Silly me. By your argument it is
better that people stick with Windows because their hardware isn't supported
under Linux than it is to have them use Linux with these drivers. What
sort of a fool statement is that? Do you honestly prefer that people use
Windows to Linux? Are you sure you aren't really a Microsoft plant?
> Ultimately, however, it is their decision, and it is up to them what
they want to do with their work.
On this, at least, you are right. And, in exactly the same way, it is your
choice whether to give them your business. Not me, man.
Yeah. Those people with nVidia cards should use Windows. We don't
want them in our elite group.
> Do any of you care about speed? Voodoo 5 has already shown to be only
moderatly faster than a GeForce but you'd prefer an open Voodoo, rather than a
closed GeForce 2? Doesn't anyone care about SPEEEED!??:)
Your argument makes no sense. Voodoo5 is faster AND more open than
nVidia's offerings...where's the beef?
Actually, the benchmarks that are coming out show the V5 only about on par
with the GF and looking to be substantially slower than GF2. It's your
money though. If you want to buy a slower card for more money then you can
do that. Don't expect anyone else to think you are intelligent though.
Besides, if I really cared about 3d graphics speed, I'd go with either
Sun's new Expert3d or one of many fine offerings from SGI. Sun and SGI may
not offer source either, but at least their stuff is FAST and HIGH QUALITY.
You forgot EXPENSIVE and A COMPLETELY DIFFERENT MARKET. Have you seen
the cost of these things compared to the GeForce?
If SGI ships me a binary IRIX driver for (let's say) an Infinite Reality
Engine, I'm pretty damn sure that it'll work and not crash my system. Do you
really place the same level of faith in nVidia? Coding for a system they most
likely don't understand well? Sure, kid.
Aren't nVidia and SGI sharing technology at the moment? Personally I
have a lot more faith in nVidia than I do in 3dfx as far as drivers go - that's
from experience in Windoze. 3dfx were the company that refused to license
glide to anyone until it because obvious that they were just a bully marketing
inferior chips at over-inflated prices, remember? That's when they decided
the Open-Source idea was a good one.
The one thing this "report" has left out is what the video power of the machine will be. We already knew it would run on a 1GHz+ AMD chip and the rest is pretty easy to guess. The real point is (and always has been) the video processing power of the box.
John Wiltshire
Re:Kernel-mode GUI is single-user only.
on
FreeBSD VM Design
·
· Score: 1
NT has a single-user, kernel mode GUI.
Not true. NT has a kernel mode GUI. Kernel mode (by definition) does not run in the context of any user. The NT GUI actually supports as many users as you want - Terminal Server, Win2000, PC Anywhere, WinFrame and others are great proofs of this.
Since nearly everything you can do in NT needs the GUI...
Again, not true. Most user oriented things require the GUI. Server oriented things can't use a GUI because when running as an NT service you don't have a valid Windows Station or Desktop to draw on to.
In Windows 2000 you can right click any program and 'Run As' any user you want. That very effectively shows there is no problem in NT itself with multiple users simultaneously.
The real problem is named objects created by applications for synchronisation. These cause all sorts of havoc because programmers assumed the single user scenario and never imagined the named objects (event, semaphores etc) may be accessed by multiple users running the same application. Hence the incredibly ugly hack that allows NT to have a different named object space for each user on Terminal Server and Terminal Services in 2000.
Do you really believe that either of these companies could fix an unknown bug in just one day?
Actually, I do. As an example, the "ping of death" bug was fixed in about 4 hours for Linux (IIRC) and about 24 hours for Microsoft (from the announcement on BugTraq). None of these fixes were 'regression tested' and not many of the fixes mentioned are fully tested. In Microsoft-speak that's the difference between 'hotfixes' and 'service packs'.
It is not my interpretation. That was just another interpretation. All I'm saying is that statistics lie and generally the whole thing doesn't come down to a single number (Mindcraft was a great example of that).
If we don't take those vendor-announced bugs into account...
Why shouldn't we take those into account? Is it valid to penalise a vendor for finding bugs themselves? What this set of data was trying to show was the amount of time a cracker was likely to have from discovering the existance of a bug to when the vendor effectively closed the hole. In that context, vendor announced bugs are a good thing - it means the cracker gets no time to penetrate a well managed system.
As I mentioned elsewhere, this is only half the case as non-announced bugs fixed in version upgrades are not taken into account, nor is the severity of the bug taken into account. Overall I think my conclusions were quite valid. MS has better distribution channels and RH has more programming resources.
The time they mention is the time between when the security hole is generally known and when it's fixed- not between when it's first discovered and fixed.
You are correct here and I wasn't disputing the point. I think what article was trying to say though was that there was a smaller time of "real danger" with Red Hat vs Microsoft or Sun. I'm saying that their analysis of statistics by simply looking at averages is flawed.
From their raw data you could also read that Microsoft is by far the worst with 700 odd days of vulnerability (which is quite impressive in the 365 days of last year).
The average time for Microsoft could also be brought down considerably by counting security related bugs in Service Packs that never actually hit the mailing lists - some of the bugs that cause a BSOD could probably be turned into exploits. These bugs (and there are generally several hundred "Q" articles relating to each service pack) would rate a '0' on the scale and bring the average down to somewhere around one or two days for Microsoft.
All I meant to say was that the statistics don't mean a lot without analysis of what the real implication of the bug meant. My take from the raw data was simply that Microsoft had a faster time from announcement to release for simple bugs (including internally discovered ones) which was probably related to their distribution channels while Red Hat had a better record in fixing bugs in an overall sense.
If someone wants to go through all the bugs in the list and figure which ones actually were a serious threat, which related to internet server, which related to clients etc. then the stats would be a lot more meaningful.
Take for example that there are no Netscape bugs listed against Red Hat. Would this skew the stats any? The list goes on.
Don't be too quick to judge based on the statistics Security Focus gave:
Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.
After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.
I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).
Here in Brisbane, Australia. 1am (UTC+10). Windows 2000 beta 2 survived the rollover (I left the computer on). MacOS9 survived the rollover. I still have power. I still have phone. I still have water. We still have civil order. The cat still works. You get the picture.
All I can think of is the horrendous waste of food and water as our Premier (equivalent of State Governer in the US) went on TV last night and told everyone to fill up bathtubs, buckets and water bottles as well as stockpile food for a fortnight. Now everyone is simply going to tip it down the drain.
We have enough problems in Oz with drought and water shortages without idiot politicians telling us how to waste resources. For those in the USA - EVERYTHING IS GOING TO WORK. DON'T WASTE WATER AND FOOD BY STOCKPILING.
Now at last this idiocy can end. Let's make the best of the new year for all of us.
Ok, so we get another look at Linux (which has been developed primarily on single processor machines and started as a test system) compared to NT (developed by a company with effectively infinite hardware resources for its developers) and really expect the SMP scaling to compare?
Let's remember that the 2.2 kernels were just the start of SMP for Linux where NT was written for SMP from the beginning. Ok, so Linux lost this round? So what?
These tests are good for the industry (both Linux and NT) - they show each where they need to improve. Linux needs improvement. It will improve. Lets run the benchmarks every 6 months and watch the way things develop.
Ok, so taking the Linux kernel for an example of a GPLed (or whatever the past participle is) work, if someone distributes a binary only copy of the kernel and refuses to give out source (a clear violation of section 3):
i) Who is the complainant in the trial? As you point out, the kernel is copyright by thousands of people and the scope of this copyright is very blurred (does someone really own the one line of code they changed). Does this mean that the entire group of copyright owners have to sue 'en masse'? ii) Does this mean that you have to give back the binary because they had no right to distribute in the first place (ie you are doing yourself harm by complaining)? iii) What is 'reasonable cost'? Could a company legitamately claim that the cost of production of a one-off CDROM or DVDROM is of the order of $100,000 and charge that for the source? After all, commercially pressed CDs are the norm for software distribution.
I don't want to say that GPL is a bad thing, just wondering what the fine mecahnics of it are.
The C2 rating of NT was without the network connected. The E3 rating was with the network connected.
Different security requirements. Realistically, no business I know has C2 or E3 requirements and the network side for C2 must be sniff-proof. This really means that the C2/E3 ratings mean that NT is securable and nothing more. We knew that anyway.
I've had no problems with BSOD on NT, but that may be because I work with it every day and must have learned how it likes to be treated?
Agree with your comments about 'anecdotal' stories.
Slashdot Mirror
Actually, it is connected directly to the PCI slot. They aren't bootable and need custom drivers for Windows and Linux.
John Wiltshire
Jeremy,
I agree with what you are saying, but fail to see how Huusker's original point that the split between OS and Apps is going to remedy any of the issues he raised with *SYSTEM* level APIs.
The simple fact is that it won't.
I'm not denying any of the point's you've made, simply saying that none of them affect the fact that an OS/Apps split is not going to solve any of the hassles that system level interoperability requirements need. This is not going to give the Samba team the Kerberos specs, the full NT RPC specs or anything like that - read what the DOJ wrote and you'll see that only API specs between OS and Apps are required to be disclosed.
So, I say that you have a good point and the DOJ solution makes no difference.
Regards,
John Wiltshire
Man, lay off the coffee.
Windows integrates VB Script about as much as Unix integrates shell scripts. Basically it is a user level scripting language. I've already said it was bad for having no real security against logged on users, but how many average users do you know that could use NT or Unix to set up a secure system for themselves?
"I'm told that all the user has to do is look at this thing in a viewer pane, and that thier machine will no longer boot" - you should be really careful what you are told. You have to run the script from the email and actually let the system run it when it warns you if you want to open the file (assuming you have the default install). Try not to spread misinformation - it only lowers the signal to noise level and just makes people ignore you.
"People are hammering Microsoft for making a product that can be destroyed so easily just so they can cram stuff down their user's throats." - no. People are hammering MS because they are a good scapegoat at the moment. Windows is no more easily destroyed than me sending you a file that says sudo rm -r / and asking you to run it. Is it Linux's fault that it is so easily destroyed by a one line command? I think not. It is the user that is the problem here.
"There's nothing more wrong with VB script than, let's say, Lotus script. It's something that can be changed at will by a single company that will not run anywhere else. Keeping up with changes will keep you from learning something usefull. It's a dead end." - except the whole point of this worm is that VB script hasn't and isn't likely to change. In fact, VB script has been a lot less of a moving target than most of the OSS projects I know. If VB Script changed regularly then worms like this would not be possible because they wouldn't execute on most machines.
Do you actually realise the hypocrisy of your statements?
John Wiltshire
Thanks for the vote of confidence, but I really wasn't going that far in my advocacy of the Win32 API. My basic point was that a breakup of Microsoft into OS and Apps will not force any release of internal APIs that aren't being used for applications. Take all the Office applications, and even IE and I think you'll find they exclusively use Win32 (documented or not) as they run on both 9x and NT/2000. A breakup would force disclosure of the full Win32 API - as Huusker pointed out there are still some areas of doubt such as CreateProcessAsUser - but would probably cement the internal subsystem and NT kernel API firmly into the bounds of NDAs.
I don't think that even the DOJ is claiming such functions as network file sharing, user logons and process/thread/memory management are in the realm of applications so you won't find any necessesity for an OS company to be disclosing any of this information to the public. In fact with well over 90% of the market the OS company would probably continue on with business as usual and keep their secrets to themselves until it became profitable again for the company to interact with other systems.
Win32 functions are not slow, crippled or anything of the sort. Huusker's point was that there is a lower level API available that would make it far easier to implement a Unix like system on NT, to implement interoperable network systems and to generally gain a higher degree of interoperability with less popular systems. In this he is mostly correct. He is blatantly incorrect in his statement that splitting Microsoft will ease this situation at all.
Huusker made some claims that NTLM authentication over a socket was hard to do. I implemented it in a few hours with VC6 and an MSDN CD so it really can't be too bad. Just take the sample code, read the comments, read the API description and it just works. Netscape have probably rejected this as an option as it is very platform specific and ties their code base to a Microsoft technology - something they have tried very hard not to do. I doubt that they are seriously needing anything more than what is readily available to implement it if they felt like it.
I believe one of the big reasons Microsoft has succeeded in the past is that they have played very tough on the business side and have been (relatively) generous to developers on the development side. RAD tools such as VB and technologies like COM cemented their position as the programming platform of the 90s. Things may change now with the maturity of OSS, but that question is yet undecided. The end result of this court case after all appeals have been heard will probably dictate the future direction of computing. Let's all hope it is a good one for industry and consumers alike.
Hope this helped with the clue stick.
John Wiltshire
Excuse me for pointing out the blatantly obvious in your post, but none of the APIs you mentioned are used by the Apps team and none of them would require disclosure in a OS/Apps chinese wall.
Remember that applications are written to Win32 and not to the raw NT API hence NTCreateProcessToken(), Subsystem APIs and NTLM RPCs are not part of this.
Also, I've implemented authentication using NTLM over a socket quite happily using the published APIs. Your claim that Netscape cannot do this either implies that the guys at Netscape are fools or they have an alternate agenda. Look at the sample program in MSDN!!
I hate to say it but your post was ill informed, inaccurate and bordering on an outright lie.
John Wiltshire
Don't forget to make your script run as root and destroy system files!
The trojan did not run as 'root' on any system it infected except where the user was running as root. I think you totally misunderstood the problem here. The point is that Win9x always runs you as root but I don't see anyone hammering 'Bad Windows', just 'Bad VB Script'. That sort of argument is incredibly stupid and naive.
Of course, the fact that it didn't destroy system files makes your argument completely wrong. All it did was add some extra lines to the registry, in what is effectively your .bashrc file. Guess what else? This is entirely possible on Unix when not running as root. Write a shellscript that throws itself in .bashrc and parses all your dotfiles for email addresses, sending it self (in some useful form) to other users. It would probably even work if you could make it do something useful or pretty at the same time...
You are right. This is not a battle. Why are the Linux zealots treating it as one?
John Wiltshire
You failed to take long enough to let things sink in:
An applications company will necessarily develop for all platforms, since it will not care about the success of a particular one. Office for Mac and Linux is right around the corner. An applications company will seek to maximize profits by making it's product available on all possible platforms.
This is exactly how not to maximise profits. The best way to maximise profits is to minimise the complexity in your code base while targeting the maximum number of users. There will be absolutely zero incentive for the Apps company to change their behaviour. Think about it. 90% of users have Windows. 9% of users have a Mac. Selling Office for Windows only and then the Mac a year later (if at all) gives you the maximum return on your development effort because it means you don't have to maintain a lot of different code bases.
Look at the game industry - most companies there do exactly what the Office and IE division do at MS. They release a Windows version first and then gauge demand for a Mac version. What makes you expect MS/Apps will be any different?
An operating systems company will seek to support as many different applications as it possibly can, to make its product OS(es) as desirable to customers as possible. It will be in the best interest of such a company to make the OS easy to code for, and to make the API available to all application developers.
It may make a difference here, but not a big one. Windows is already easy to code for (through APIs, products like VB etc.) and the API is available to pretty much anyone who wants to download the Platform SDK. This remedy will stop early releases of APIs to MS/Apps only if they can relocate the entire MS/Apps team to somewhere in Miami to stop them talking to people in Seattle. It will not stop Windows to continue to be developed in the way it has before, it will not somehow magically make KDE or Gnome as desirable for apps companies as Windows currently is and will not be an effective remedy.
I am disappointed with the DOJ in suggesting this. They would have been far better splitting into about 4 companies: Win9x, WinNT + Backoffice, Applications and Hardware, but I guess they saw that as even more radical. I know Jackson doesn't like MS and has been leaning to the DOJ and States but BG and SB could only be rubbing their hands with glee saying "That's all they want to do?".
John Wiltshire
I know it is getting silly carrying on a /. post for this long, but what the
hell. This one is interesting (to me anyhow).
So what if Apple happens to ship their hardware and software together? They still compete with microsoft for users.
So if 'competing with Micro$oft' is a criteria for systems that should be OSS, the AIX, IRIX and Solaris should all be open source. Either that or you have no problems with W2K Enterprise Edition being closed source. My main point is that quality is not necessarily dependant on OSS at any level of the market. OSS definitely helps, but any commercial software company can easily produce stable software *without* releasing the source. OSS nuts should come down to earth and realise that maybe there are other models that work.
Instead I buy the hardware that's supported by specs or source-available drivers. In other words, instead of whining about the problem I vote with my dollars and actually do something about it. The fact that you want to throw away twenty years worth of others' efforts just so you can have your binary-only shitware drivers for hardware you shouldn't have bought in the first place doesn't mean I should have to pay the price for it.
I personally don't use binary-only shitware drivers. I'll happily use stable binary-only drivers though. I also vote with my dollars and feel that OSS is not a necessary condition for good software, backed up by numerous examples of non-OSS commodity software that is out there. Telling me I shouldn't have bought hardware that I researched and found to be the best value for money is the height of arrogance. That is no different to a doorknocker telling me I need to see things his way before I get to heaven.
That doesn't mean the other architectures receive any less attention, just that Linus delays putting in the applicable patches.
As Linus controls and owns Linux, all I can say is that if Linus delays patches for alternate hardware then Linux has less of a focus on that hardware. Simple.
Well, considering that I've been following the development series since 1.3 and reading more or less every patch, and l-k, and sparclinux, I'm not really sure what else you think I should be reading. Perhaps the nVidia marketing drivel that serves as the source of your information?
How about that? What does the nVidia marketing drivel say even? I certainly haven't been quoting it and if you have to sling strawmen and misquotes my way to counter my arguments then I'd say you are sounding more and more like a religious fanatic than a reasoned person. If you believe that OSS is the one true way to stable software then go and hide in your own corner and use it. Stop annoying those of us that believe using stable software from any source is far more rational.
John Wiltshire
But what you haven't grasped is that in a closed-source model there must be some motivation for the vendor to provide quality. In a commodity market heavily influenced by microsoft there is no such motivation. Hence the closed-source software that gets produced is crap. If you want to talk about things being a totally different market, I'd say the same about million-dollar systems. It's a whole new ball game at that level, and source availability isn't a prerequisite for quality.
The vast majority of commodity computing items are both closed source and ultra-reliable. How many times has the embedded system in your car crashed, your digital watch crashed or your microwave thrown an exception. Claiming that the (small) commodity base of Intel PCs is a reflection on the state of the industry is foolishness.
Where is the motivation for quality drivers? Simple - if the drivers don't work then the card doesn't sell. Take for example the Diamond Viper II which was a great piece of hardware that had absolutely horrific Windows drivers. The card was a flop. That's your motivation for quality pure and simple. nVidia has always had it and your assertions to the contrary have no basis in fact.
Apple chooses to provide poor quality software because they can. Look who they're competing with...
LinuxPPC and BeOS? I've never seen a Microsoft operating system that runs on Mac hardware.
Linux is more accepted than the Hurd for several reasons. First to market, faster, not based on a platform (Mach) that has never really had any success, not fucking vapourware, ... Why it was written is irrelevant.
Not true again. The reason it is not vapourware is the exact reason it was written: to solve a problem and not to further RMS's personal religion. Linux is a practical operation system and Linus a practical person. If that troubles you, ask why the core specs and instruction set for Crusoe aren't available before you start casting doubt on other companies for not releasing their specs.
I don't want nVidia to care about Linux. I want them to do The Right Thing and let people have the damn programmer's manuals for their chips. Linux hasn't a thing to do with it.
nVidia doesn't have to release their specs to write good drivers. It is that simple. OSS is no guarantee of quality (as you seem to assert) and if nVidia chooses to write quality drivers in-house rather than let the OSS community write them I think it is still a good thing for Linux. If you think otherwise then you are putting religion before practicality.
You can think what you like, I suppose. But when you turn around and realize that Linux has become a joke as a Free system don't complain to me.
If that happens, you'll be the last person I complain to. Trust me on that. On the other hand, if Linux lacks hardware support because the Linux community can't accept one ounce of close source then you shouldn't complain to anyone - you made your bed so sleep in it.
Linux is orthogonal to the peecee; anyone who tells you otherwise has been reading too much marketing hype and not enough source code.
Hmm. I've read the source. Why is it that most kernel changes are tested first on PC hardware and then on other hardware? Why is it that the TBD stuff on development kernels always seems to be porting the PC code to other systems and not the other way around? Maybe Linux is a little more PC centric than you thought? Perhaps you should read more source code?
John Wiltshire
Not true. Looking at history, this will not mean one less sale for nVidia but one more sale for Microsoft. If you are so blind to consumer reality that you can't see hardware support being critical to consumer support of an operating system then I suggest you need to wake up a little from your OSS religion and look at the real world some time.
These drivers are good for Linux because it means less people that will need Windows to support the best commodity 3d hardware available. If you can't see that then you have a hidden agenda.
According to Anand, the GF2 comes in AGP and PCI versions. Given that the GF2 does geometry processing on board, it should be a far better solution than the V5 for the slower PCI bus. Naturally you can enjoy FSAA on the GF2 as well and still enjoy X-Plane at higher frame rates than the V5 will give you.
Listen to your own words changed around a bit:
If every hardware vendor offers drivers under the same license, your
once-stable unix-like operating system has become the hell that is AIX and S/390.
Oh, that's right. They are very stable (probably more stable than
Linux) and don't offer source for their drivers. Maybe closed source isn't
quite as bad as you have deluded yourself into believing.
> It is good for Linux users.
No, it is not. See above.
So by your estimation, no drivers is better than some drivers. Don't be
a fool. Of course quality drivers is good for Linux whether they are open
source, closed source or tomato sauce. Get a clue on the real world!!
> It shows that Linux is being treated equally among OSs. nVidia
wouldn't release their source to Microsoft, and they aren't doing it for the OSS
community.
How is this good? The purpose of Free software is not to gain a place in
the proprietary software world as an equal to Microsoft's offerings!!! It's to
be a fundamentally different, and better, way of using computers.
...and I thought it was because Linus didn't like Minix or DOS and so he
wrote a Unix that he did like. Silly me. By your argument it is
better that people stick with Windows because their hardware isn't supported
under Linux than it is to have them use Linux with these drivers. What
sort of a fool statement is that? Do you honestly prefer that people use
Windows to Linux? Are you sure you aren't really a Microsoft plant?
> Ultimately, however, it is their decision, and it is up to them what
they want to do with their work.
On this, at least, you are right. And, in exactly the same way, it is your
choice whether to give them your business. Not me, man.
Yeah. Those people with nVidia cards should use Windows. We don't
want them in our elite group.
> Do any of you care about speed? Voodoo 5 has already shown to be only :)
moderatly faster than a GeForce but you'd prefer an open Voodoo, rather than a
closed GeForce 2? Doesn't anyone care about SPEEEED!??
Your argument makes no sense. Voodoo5 is faster AND more open than
nVidia's offerings...where's the beef?
Actually, the benchmarks that are coming out show the V5 only about on par
with the GF and looking to be substantially slower than GF2. It's your
money though. If you want to buy a slower card for more money then you can
do that. Don't expect anyone else to think you are intelligent though.
Besides, if I really cared about 3d graphics speed, I'd go with either
Sun's new Expert3d or one of many fine offerings from SGI. Sun and SGI may
not offer source either, but at least their stuff is FAST and HIGH QUALITY.
You forgot EXPENSIVE and A COMPLETELY DIFFERENT MARKET. Have you seen
the cost of these things compared to the GeForce?
If SGI ships me a binary IRIX driver for (let's say) an Infinite Reality
Engine, I'm pretty damn sure that it'll work and not crash my system. Do you
really place the same level of faith in nVidia? Coding for a system they most
likely don't understand well? Sure, kid.
Aren't nVidia and SGI sharing technology at the moment? Personally I
have a lot more faith in nVidia than I do in 3dfx as far as drivers go - that's
from experience in Windoze. 3dfx were the company that refused to license
glide to anyone until it because obvious that they were just a bully marketing
inferior chips at over-inflated prices, remember? That's when they decided
the Open-Source idea was a good one.
John Wiltshire
The one thing this "report" has left out is what the video power of the machine will be. We already knew it would run on a 1GHz+ AMD chip and the rest is pretty easy to guess. The real point is (and always has been) the video processing power of the box.
John Wiltshire
NT has a single-user, kernel mode GUI.
Not true. NT has a kernel mode GUI. Kernel mode (by definition) does not run in the context of any user. The NT GUI actually supports as many users as you want - Terminal Server, Win2000, PC Anywhere, WinFrame and others are great proofs of this.
Since nearly everything you can do in NT needs the GUI...
Again, not true. Most user oriented things require the GUI. Server oriented things can't use a GUI because when running as an NT service you don't have a valid Windows Station or Desktop to draw on to.
In Windows 2000 you can right click any program and 'Run As' any user you want. That very effectively shows there is no problem in NT itself with multiple users simultaneously.
The real problem is named objects created by applications for synchronisation. These cause all sorts of havoc because programmers assumed the single user scenario and never imagined the named objects (event, semaphores etc) may be accessed by multiple users running the same application. Hence the incredibly ugly hack that allows NT to have a different named object space for each user on Terminal Server and Terminal Services in 2000.
Thought I should point this out as the initial post makes it seem like 2 OEMs are considering using the CPU. Remember Diamond bought S3?
John Wiltshire
Do you really believe that either of these companies could fix an unknown bug in just one day?
Actually, I do. As an example, the "ping of death" bug was fixed in about 4 hours for Linux (IIRC) and about 24 hours for Microsoft (from the announcement on BugTraq). None of these fixes were 'regression tested' and not many of the fixes mentioned are fully tested. In Microsoft-speak that's the difference between 'hotfixes' and 'service packs'.
It is not my interpretation. That was just another interpretation. All I'm saying is that statistics lie and generally the whole thing doesn't come down to a single number (Mindcraft was a great example of that).
If we don't take those vendor-announced bugs into account...
Why shouldn't we take those into account? Is it valid to penalise a vendor for finding bugs themselves? What this set of data was trying to show was the amount of time a cracker was likely to have from discovering the existance of a bug to when the vendor effectively closed the hole. In that context, vendor announced bugs are a good thing - it means the cracker gets no time to penetrate a well managed system.
As I mentioned elsewhere, this is only half the case as non-announced bugs fixed in version upgrades are not taken into account, nor is the severity of the bug taken into account. Overall I think my conclusions were quite valid. MS has better distribution channels and RH has more programming resources.
John Wiltshire
The time they mention is the time between when the security hole is generally known and when it's fixed- not between when it's first discovered and fixed.
You are correct here and I wasn't disputing the point. I think what article was trying to say though was that there was a smaller time of "real danger" with Red Hat vs Microsoft or Sun. I'm saying that their analysis of statistics by simply looking at averages is flawed.
From their raw data you could also read that Microsoft is by far the worst with 700 odd days of vulnerability (which is quite impressive in the 365 days of last year).
The average time for Microsoft could also be brought down considerably by counting security related bugs in Service Packs that never actually hit the mailing lists - some of the bugs that cause a BSOD could probably be turned into exploits. These bugs (and there are generally several hundred "Q" articles relating to each service pack) would rate a '0' on the scale and bring the average down to somewhere around one or two days for Microsoft.
All I meant to say was that the statistics don't mean a lot without analysis of what the real implication of the bug meant. My take from the raw data was simply that Microsoft had a faster time from announcement to release for simple bugs (including internally discovered ones) which was probably related to their distribution channels while Red Hat had a better record in fixing bugs in an overall sense.
If someone wants to go through all the bugs in the list and figure which ones actually were a serious threat, which related to internet server, which related to clients etc. then the stats would be a lot more meaningful.
Take for example that there are no Netscape bugs listed against Red Hat. Would this skew the stats any? The list goes on.
John Wiltshire
Don't be too quick to judge based on the statistics Security Focus gave:
Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.
After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.
I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).
John Wiltshire
That's not how its supposed to work? Bugger. Have to RTFM...
Here in Brisbane, Australia. 1am (UTC+10). Windows 2000 beta 2 survived the rollover (I left the computer on). MacOS9 survived the rollover. I still have power. I still have phone. I still have water. We still have civil order. The cat still works. You get the picture.
All I can think of is the horrendous waste of food and water as our Premier (equivalent of State Governer in the US) went on TV last night and told everyone to fill up bathtubs, buckets and water bottles as well as stockpile food for a fortnight. Now everyone is simply going to tip it down the drain.
We have enough problems in Oz with drought and water shortages without idiot politicians telling us how to waste resources. For those in the USA - EVERYTHING IS GOING TO WORK. DON'T WASTE WATER AND FOOD BY STOCKPILING.
Now at last this idiocy can end. Let's make the best of the new year for all of us.
John Wiltshire
Ok, so we get another look at Linux (which has been developed primarily on single processor machines and started as a test system) compared to NT (developed by a company with effectively infinite hardware resources for its developers) and really expect the SMP scaling to compare?
Let's remember that the 2.2 kernels were just the start of SMP for Linux where NT was written for SMP from the beginning. Ok, so Linux lost this round? So what?
These tests are good for the industry (both Linux and NT) - they show each where they need to improve. Linux needs improvement. It will improve. Lets run the benchmarks every 6 months and watch the way things develop.
John Wiltshire
Thanks Bruce.
:-(
Adding shipping, it would probably be reasonable to charge the following (from Australia):
AUD3.00 - CD/R cost
AUD10.00 - Technician (or whatever at a CD Burning ship)
AUD50.00 - International overnight shipping costs.
The pain is that shipping charges here are hideous.
John Wiltshire
Ok, so taking the Linux kernel for an example of a GPLed (or whatever the past participle is) work, if someone distributes a binary only copy of the kernel and refuses to give out source (a clear violation of section 3):
i) Who is the complainant in the trial? As you point out, the kernel is copyright by thousands of people and the scope of this copyright is very blurred (does someone really own the one line of code they changed). Does this mean that the entire group of copyright owners have to sue 'en masse'?
ii) Does this mean that you have to give back the binary because they had no right to distribute in the first place (ie you are doing yourself harm by complaining)?
iii) What is 'reasonable cost'? Could a company legitamately claim that the cost of production of a one-off CDROM or DVDROM is of the order of $100,000 and charge that for the source? After all, commercially pressed CDs are the norm for software distribution.
I don't want to say that GPL is a bad thing, just wondering what the fine mecahnics of it are.
John Wiltshire
Just to clarify:
The C2 rating of NT was without the network connected.
The E3 rating was with the network connected.
Different security requirements. Realistically, no business I know has C2 or E3 requirements and the network side for C2 must be sniff-proof. This really means that the C2/E3 ratings mean that NT is securable and nothing more. We knew that anyway.
I've had no problems with BSOD on NT, but that may be because I work with it every day and must have learned how it likes to be treated?
Agree with your comments about 'anecdotal' stories.
John Wiltshire
Just a quick response:
2 1.pdf
You are actually wrong about the "best comment". NT 4 was rated with ITSEC to be secure with the network connected at E3 level.
http://www.itsec.gov.uk/docs/pdfs/certreps/crp1
The fact still remains that no version of Linux has been certified either with or without networking, even with the source code available!!
John Wiltshire