I have several computers at home. One "Windows box". It runs Windows 98se. Its a Compaq PII 400 with 128MB. It runs Microsoft Office, Web browsing, email. Just fine (except for inserting TIFF pictures from the scanner).
You want me to dumpster this, invest in a new box -- and why? Because it doesn't matter. I guess you don't have much of a "green streak". After all, this computer MAY run Windows XP, but I am pretty sure it won't do it well. Besides, I have no need for that upgrade.
In fact, the ONLY software I need "upgraded" on a regular basis on this box is the web browser. As long as this is done, the machine is viable.
"Windows 2003 Server, in fact, led the popular Red Hat Enterprise Linux with nearly 20 percent more annual uptime."
Which part of the sentence is unclear? 20% MORE ANNUAL UPTIME.
To achieve this claim, what would your numbers be?
Note that it DOESN'T say "20% more downtime". It is very clear: "20% MORE ANNUAL UPTIME". The MINIMUM requirement to achieve this is 60 downtime days on the RHEL box.
Note that we ARE being "relative": the 60 downtime days is the MINIMUM. Assuming 100% uptime on the Windows Server. The downtime can only grow.
Conclusions?
Maybe the Yankee Group has some math or writing (or both) problems. Implies that they shouldn't be in the publishing statistics business, which needs both skills.
Maybe the RHEL hardware is very defective. Implies that the Yankee Group is not TECHNICAL enough to do this report.
Maybe RHEL is defective. With that much downtime, I would have called Redhat. Maybe the Yankee Group has a horribly misconfigured system, and is trying to sort it out themselvs. Implies that they are not smart enough to do this report.
Every time: the Yankee Group doesn't have the skills needed. The report should be ignored.
Can't possibly be. At least for any server I control, a 20% INCREASE in uptime is impossible. This implies 80% availability OR LESS for the RHEL box; no more is mathematically possible.
I would throw out RHEL if it performed that badly! That would be, what, around a day outage every week? I would have the hardware diagnosed as well...
I don't know about the closed source difficulties. Not my call, and not my problem. It may be that there isn't a market for it -- which means those user don't want the feature.
It isn't difficult to generate a key: obviously a commercial implementation would add a "pleasant" GUI. Publishing to key servers? Same deal. In my opinion (obviously wrong, because it isn't there), this should be a standard feature of Outlook Express (whatever the default Microsoft mail client is).
Ask Microsoft why it isn't; my point was simply that it IS a standard feature of Redhat 9!
The DEFAULT maile client is Evolution. It has pull-down menus for "sign" and "encrypt". And there you go. If you receive a signed message, it shows a little icon in the message to verify the message.
How much easier could it be?
Ok, now lets cover key generation (the hard part). Yes, it is likely that the user will need some setup help (to generate the key, and send to keyservers). But in normal use? Its dead easy.
Oh bother. I have to go through the "Lost" or "24" model for you.
The producer pitches the show. It is picked up. Episodes are created. And aired. Along with the airing, commercials are added, which pay for the program. Not enough viewers? The people buying the commercials stop, and the show is then cancelled.
If there are sufficient viewers, the show continues. Everything is already payed for. If a show makes it to around 5 seasons, it can go into syndication, which is "free money". But there is no guarantee that the show WILL go into syndication. Sometimes (like Andromeda) a show is extended by a year to allow this to happen.
But, capturing and distributing does NOT affect the production of the show at all. After all, the shows are produced BEFORE they are aired. Suck on this idea for a while. Nothing changes -- the show is payed for by the commercial sponsors who insert commercials on the initial airing.
The only way that this can affect the production is if the audience does NOT watch the aired program, but waits for a commercial free download to become available.
This is mitigated by "product placement" -- Coke and Ford in American Idol, Apple in 24. Still, the people you should be concerned with are the advertisers, NOT the show producers.
Closed source drivers are bad. Eventually interest in keeping drivers current is lost be someone other than a USER of that hardware. Yes, this is FUD...
I have a LOT of backup tapes generated on a Travan TR-1 drive. Some are QIC-80, some QIC-Wide and some TR-1. Yes, its obsolete. But the drives work fine, and I have lots of tapes. Can I have a Vista driver, please?
I have other hardware in a similar category. But, taking the tape drive -- the only reason I can still use it is that the protocol was reverse-engineered, and a driver written for Linux. Some sound cards are in the same category, &etc.
In a nutshell, weak driver support DROVE me to Linux. These days, driver support is so skewed that I purchased and tried Windows XP on a box. After installing, the CD-ROM never appeared (that it just loaded from). Of course the vendor drivers did not fit on a floppy, and the network didn't work without the vendor driver. Gave up on it -- threw Linux on, and everything worked.
Now, I buy hardware based on Linux compatibility, not Windows. Tends to be cheaper (except for wireless networking -- I generally use D-Link DWL-810+ or equivalents, which work for anything ethernet).
1. How to set up and troubleshoot basic Windows XP issues
-- I have never successfully set up Windows XP. I cannot troubleshoot basic Windows XP issues.
2. How to add or remove components (AGP card, PCI cards, etc.)
-- This I can "sort of" do. However, a client recently asked if I could install additional memory into a SUN 4800 (maybe something else?). I had to decline because I don't know where it goes. So I fail at this as well.
3. What ethernet is, what USB is, what bluetooth is, etc.
-- I know ethernet, USB? sort of. bluetooth I am not sure of at all (slow speed radio?)
4. The basics of Microsoft Word + Excel (create new document, save, print, etc.)
-- I guess. Not so good with Excel.
5. Internet searching
-- As long as its Google. My wife uses "academic search engines" which I find terribly confusing.
6. How to manipulate files (move between folders, delete, etc.)
-- As long as its "mc". I have no idea on Windows (unless I go to cmd.exe, but I still have horrible problems finding stuff. I usually have to do "cd \" followed by "dir/s pattern").
So, I'll give myself 50% which really isn't a passing grade.
The issue is design. It is possible, indeed, easy, to have a completely secured computer attached to the internet (with only DoS attacks possible).
Document formats that are secure are known. (ASCII text, limited control sequences). However, people fall prey to convenience. As an example: ANSI text. The only attack known in that format is "escape sequences" which can then program or activate command sequences. The reason this exists? Convenience. The "driver" for the console interprets escape sequences, and the display commands (TYPE and cat) do not filter the sequences.
This convenience leads to interesting applications not forseen by the original authors (in the case of ANSI text - animations, being able to program the keyboard with a simple file, etc.). Which is good (in a hacking sense), but is terrible for security.
It is easily possible to become too secure. The model should be "bits are bits" coupled with a reasonable protection against programming errors. The USER plays a vital part in the security model as well.
As an example: if someone TOLD you to "become root, and execute "cd/; rm -fr *" you wouldn't do that now, would you? If someone said: "don't bother with root, but execute "cd ~; rm -fr *", you wouldn't do that either.
The second command is equivalent to running ANY software downloaded from the internet. But, there should be reasonable expectation that a common display library should defend itself against buffer overruns which could result in inadvertent code execution. If code execution is not expected, we expect it to be denied.
The "monoculture" argument is that if a vector for inadvertent code execution is found, it is naturally contained.
Where your argument fails is the presumption that inadvertent code execution is linked to a data format. It isn't. It is linked to convenience (design) and implementation.
TCP/IP (your example) provides no code execution vector by design. Implementations? May be flawed. MS.doc format? Execution by design. Implementations? May remove the ability. May also be flawed.
Where "execution by design" is permitted, we must examine the implementation carefully. A reasonable implementation can overcome many of the problems.
As an example: Postscript. This is a general programming system, and includes the ability to manipulate files. Why aren't PS files a greater source of trouble? Because the common implementation (Ghostscript) has a "safe" mode that removes these capabilities. Making print files (reasonably) safe.
Presuming that current crypto is secure, public key cryptography provides a solution.
Specifically, the public key is published, but private keys are pretty much unknown. The only thing you really know about your private key is the passphrase needed to use it (note that the computer using an entropy source generated the key in the first place).
The key itself? Should be stored on a flash memory card. Or another easily destroyed medium. If broken, you have NO way of supplying the key to the government.
The issue is key management. If the key doesn't exist, no amount of threatening or torture can cough it up. Sure, the passphrase (at the drop of a hat), but the key?
If the register specs were opened, I WOULD write open-source drivers (and, as to my qualifications, I am currently contracting to improve the performance of one the major vendors drivers).
As to maintaining? I have a problem for you... find a closed source driver for an HP/Colorado Travan TR-1 driver on Windows XP. The driver should do QIC-80 as well (all compatible tapes supported).
FCC regulations for wireless chips? That argument is bunk. Look at the SMC Barricade 802.11b router. It will happily use channels 12,13 and 14 in the US. Without even lying about the location.
I try to stay on top of multimedia related stuff. Its a flood. My original press release from Orb indicated a fee. I have checked the web-site: you are correct, no fee is charged.
"How do I get my back/forward mouse buttons to work in Firefox (like it does in Windows)?"
The question can be reversed. Why doesn't Windows work like Firefox? Or, a different question can be posed: why don't you talk to your mouse vendor?
All in all... you choose to NOT ask those questions. Now, F/OSS is flexible enough to provide you with an answer -- but you don't want to apply it.
Random config files? No, but you may want to pay someone to make the modifications for you. F/OSS doesn't mean "free as in beer". After all, you PAID for the Windows 5 button driver.
Now, let's tackle another problem: how do I get my TRAVAN-1 tape drive (Colorado) working with Windows XP? I have a LOT of backup tapes, dating back 15 years (QIC-80). Sure, works fine on Linux. Is there a "random config file" I can edit for this?
Think on this; the Zen of F/OSS will become apparent.
And, given that Vista will require driver signing, will your 5 button driver be signed? Yes, this is FUD.
Your printer is probably going to be supported in Vista. Or not (Microsoft is going to have to sign all drivers, which means new versions for all products). If it isn't (and some day it won't be), Linux will still support it. Or, you can keep your current Windows... oh, you won't be able to, Eventually, something will die (hardware), REQUIRING XP reauthorization. Since Microsoft will no longer be doing that (at some point) XP *will* die.
Oh well.
But don't worry, that printer is new and shiny right now.
I use it. Not for 3D (couldn't care about that), but because the 5200FX was the least expensive card with quality TV out.
Now, here's the rub. There is a black (or blue) band on the left edge (video overlay). Quite large - its over 8 pixels wide. Can't get rid of it. And I don't have the driver source. I was able to change the video overlay color from blue to black to make it less noticable. But it's still there.
I am going to ditch the driver soon for something open source. Simply because closed source doesn't work.
"Some stuff is currently not doable using only open source software."
I imagine that's true. The converse is also true. "Some stuff is currently not (easily) doable using only closed source software.". Example (off the top of my head): QIC-80 tape support for XP.
So your argument is basically a push, and depends heavily on the user.
Is NT based on VMS? Why does that rumour float around? Mind you, the source for NT *is* available (DEC supplied it on microfiche). BLISS-32.
Now, as to the NT - VMS comparision. VMS has DCL. NT has cmd.exe. No similarity. VMS has HELP NT has/? No similarity. VMS has RMS. NT has ? No similarity. VMS has very fine grained permissions, NT has security on objects. No similarity. VMS doesn't really have threads, but does have good ways of tracking working set size, and tuning I/O. NT?
No, NT comes from the Unix school, with a lot of OS/2 thrown in. At least externally VMS and NT are very different. VMS is NOT a microkernel OS. VMS *did* support multiple personalities (to support migration for PDP-11 users).
The Smalltalk 80 system was an OS, GUI, programming environment &etc. in Smalltalk, using a VM, with complete OOP orientation.
And, yes, there was an OS, and it was run on the VM, and no-one seemed to mind.
Squeak is the descendent of that work. Its portable because the VM can be moved -- the actual Smalltalk code uses the "OS in Smalltalk". Its probably the environment you want for your OS concept exploration.
Sure, I can elaborate. The idea is that drivers are constrained in the interfaces they use. The idea is NOT to produce a "universal" DDI, but to formalize the current driver classing. Indeed, formalize it to the point that a source tool can examine the driver source and determine if it is "compliant" to the class which it belongs in. All such compliant drivers can be considered "class DDI clean" and a kernel change can then be tested against the interface.
Drivers which are not completely "class clean" need to be checked (more) carefully against kernel changes. This encourages drivers to be migrated into the "clean" class. If a kernel change occurs which affects the entire class, it is likely that automated tools can handle the change to the drivers (hopefully, the bulk of the work).
I don't consider the interface to be off limits to kernel developers, but the extra isolation should make things easier from both the driver and the kernel perspective.
Initially, such "DDI layers" should be imposed on isolated parts, where a great deal of abstraction already exists. Later on -- we (Linux) should remain flexible enough to reject such ideas if they don't work, or extend them.
Slashdot Mirror
I have several computers at home. One "Windows box". It runs Windows 98se. Its a Compaq PII 400 with 128MB. It runs Microsoft Office, Web browsing, email. Just fine (except for inserting TIFF pictures from the scanner).
You want me to dumpster this, invest in a new box -- and why? Because it doesn't matter. I guess you don't have much of a "green streak". After all, this computer MAY run Windows XP, but I am pretty sure it won't do it well. Besides, I have no need for that upgrade.
In fact, the ONLY software I need "upgraded" on a regular basis on this box is the web browser. As long as this is done, the machine is viable.
Ratboy
Let me quote the article:
"Windows 2003 Server, in fact, led the popular Red Hat Enterprise Linux with nearly 20 percent more annual uptime."
Which part of the sentence is unclear? 20% MORE ANNUAL UPTIME.
To achieve this claim, what would your numbers be?
Note that it DOESN'T say "20% more downtime". It is very clear: "20% MORE ANNUAL UPTIME". The MINIMUM requirement to achieve this is 60 downtime days on the RHEL box.
Note that we ARE being "relative": the 60 downtime days is the MINIMUM. Assuming 100% uptime on the Windows Server. The downtime can only grow.
Conclusions?
Maybe the Yankee Group has some math or writing (or both) problems. Implies that they shouldn't be in the publishing statistics business, which needs both skills.
Maybe the RHEL hardware is very defective. Implies that the Yankee Group is not TECHNICAL enough to do this report.
Maybe RHEL is defective. With that much downtime, I would have called Redhat. Maybe the Yankee Group has a horribly misconfigured system, and is trying to sort it out themselvs. Implies that they are not smart enough to do this report.
Every time: the Yankee Group doesn't have the skills needed. The report should be ignored.
Ratboy
From the fine article:
"nearly 20 percent more annual uptime."
Can't possibly be. At least for any server I control, a 20% INCREASE in uptime is impossible. This implies 80% availability OR LESS for the RHEL box; no more is mathematically possible.
I would throw out RHEL if it performed that badly! That would be, what, around a day outage every week? I would have the hardware diagnosed as well...
Ratboy.
I don't know about the closed source difficulties. Not my call, and not my problem. It may be that there isn't a market for it -- which means those user don't want the feature.
It isn't difficult to generate a key: obviously a commercial implementation would add a "pleasant" GUI. Publishing to key servers? Same deal. In my opinion (obviously wrong, because it isn't there), this should be a standard feature of Outlook Express (whatever the default Microsoft mail client is).
Ask Microsoft why it isn't; my point was simply that it IS a standard feature of Redhat 9!
YMMV
Ratboy
Stop talking Trash!
If you mean that pgp/gpg is not well-integrated into COMMERICAL CLOSED SOURCE software, you MAY have a point.
But, let's talk the DEFAULT - Redhat 9, Fedora Core &etc.
The DEFAULT maile client is Evolution. It has pull-down menus for "sign" and "encrypt". And there you go. If you receive a signed message, it shows a little icon in the message to verify the message.
How much easier could it be?
Ok, now lets cover key generation (the hard part). Yes, it is likely that the user will need some setup help (to generate the key, and send to keyservers). But in normal use? Its dead easy.
Ratboy.
Oh bother. I have to go through the "Lost" or "24" model for you.
The producer pitches the show. It is picked up. Episodes are created. And aired. Along with the airing, commercials are added, which pay for the program. Not enough viewers? The people buying the commercials stop, and the show is then cancelled.
If there are sufficient viewers, the show continues. Everything is already payed for. If a show makes it to around 5 seasons, it can go into syndication, which is "free money". But there is no guarantee that the show WILL go into syndication. Sometimes (like Andromeda) a show is extended by a year to allow this to happen.
But, capturing and distributing does NOT affect the production of the show at all. After all, the shows are produced BEFORE they are aired. Suck on this idea for a while. Nothing changes -- the show is payed for by the commercial sponsors who insert commercials on the initial airing.
The only way that this can affect the production is if the audience does NOT watch the aired program, but waits for a commercial free download to become available.
This is mitigated by "product placement" -- Coke and Ford in American Idol, Apple in 24. Still, the people you should be concerned with are the advertisers, NOT the show producers.
Ratboy.
And...
..."). If it doesn't, the OS X UI is broken.
"apropos apache"
should tell you how to do it (give the man page reference, then "man
Ratboy.
Closed source drivers are bad. Eventually interest in keeping drivers current is lost be someone other than a USER of that hardware. Yes, this is FUD...
I have a LOT of backup tapes generated on a Travan TR-1 drive. Some are QIC-80, some QIC-Wide and some TR-1. Yes, its obsolete. But the drives work fine, and I have lots of tapes. Can I have a Vista driver, please?
I have other hardware in a similar category. But, taking the tape drive -- the only reason I can still use it is that the protocol was reverse-engineered, and a driver written for Linux. Some sound cards are in the same category, &etc.
In a nutshell, weak driver support DROVE me to Linux. These days, driver support is so skewed that I purchased and tried Windows XP on a box. After installing, the CD-ROM never appeared (that it just loaded from). Of course the vendor drivers did not fit on a floppy, and the network didn't work without the vendor driver. Gave up on it -- threw Linux on, and everything worked.
Now, I buy hardware based on Linux compatibility, not Windows. Tends to be cheaper (except for wireless networking -- I generally use D-Link DWL-810+ or equivalents, which work for anything ethernet).
YMMV
Ratboy
1. How to set up and troubleshoot basic Windows XP issues
-- I have never successfully set up Windows XP. I cannot troubleshoot basic Windows XP issues.
2. How to add or remove components (AGP card, PCI cards, etc.)
-- This I can "sort of" do. However, a client recently asked if I could install additional memory into a SUN 4800 (maybe something else?). I had to decline because I don't know where it goes. So I fail at this as well.
3. What ethernet is, what USB is, what bluetooth is, etc.
-- I know ethernet, USB? sort of. bluetooth I am not sure of at all (slow speed radio?)
4. The basics of Microsoft Word + Excel (create new document, save, print, etc.)
-- I guess. Not so good with Excel.
5. Internet searching
-- As long as its Google. My wife uses "academic search engines" which I find terribly confusing.
6. How to manipulate files (move between folders, delete, etc.)
-- As long as its "mc". I have no idea on Windows (unless I go to cmd.exe, but I still have horrible problems finding stuff. I usually have to do "cd \" followed by "dir
So, I'll give myself 50% which really isn't a passing grade.
YMMV
Ratboy.
The issue is design. It is possible, indeed, easy, to have a completely secured computer attached to the internet (with only DoS attacks possible).
/; rm -fr *" you wouldn't do that now, would you? If someone said: "don't bother with root, but execute "cd ~; rm -fr *", you wouldn't do that either.
.doc format? Execution by design. Implementations? May remove the ability. May also be flawed.
Document formats that are secure are known. (ASCII text, limited control sequences). However, people fall prey to convenience. As an example: ANSI text. The only attack known in that format is "escape sequences" which can then program or activate command sequences. The reason this exists? Convenience. The "driver" for the console interprets escape sequences, and the display commands (TYPE and cat) do not filter the sequences.
This convenience leads to interesting applications not forseen by the original authors (in the case of ANSI text - animations, being able to program the keyboard with a simple file, etc.). Which is good (in a hacking sense), but is terrible for security.
It is easily possible to become too secure. The model should be "bits are bits" coupled with a reasonable protection against programming errors. The USER plays a vital part in the security model as well.
As an example: if someone TOLD you to "become root, and execute "cd
The second command is equivalent to running ANY software downloaded from the internet. But, there should be reasonable expectation that a common display library should defend itself against buffer overruns which could result in inadvertent code execution. If code execution is not expected, we expect it to be denied.
The "monoculture" argument is that if a vector for inadvertent code execution is found, it is naturally contained.
Where your argument fails is the presumption that inadvertent code execution is linked to a data format. It isn't. It is linked to convenience (design) and implementation.
TCP/IP (your example) provides no code execution vector by design. Implementations? May be flawed. MS
Where "execution by design" is permitted, we must examine the implementation carefully. A reasonable implementation can overcome many of the problems.
As an example: Postscript. This is a general programming system, and includes the ability to manipulate files. Why aren't PS files a greater source of trouble? Because the common implementation (Ghostscript) has a "safe" mode that removes these capabilities. Making print files (reasonably) safe.
As always, YMMV
Ratboy.
Does this mean that there will be HD format DVD players available in the North American market that support component video 1080i out?
Do these entertainment boxes support this?
If so, (and I really don't know), I'll buy. As long as there are also movie discs in HD as well.
Ratboy.
Presuming that current crypto is secure, public key cryptography provides a solution.
Specifically, the public key is published, but private keys are pretty much unknown. The only thing you really know about your private key is the passphrase needed to use it (note that the computer using an entropy source generated the key in the first place).
The key itself? Should be stored on a flash memory card. Or another easily destroyed medium. If broken, you have NO way of supplying the key to the government.
The issue is key management. If the key doesn't exist, no amount of threatening or torture can cough it up. Sure, the passphrase (at the drop of a hat), but the key?
Ratboy
I write 3D drivers. Yes, closed source.
If the register specs were opened, I WOULD write open-source drivers (and, as to my qualifications, I am currently contracting to improve the performance of one the major vendors drivers).
As to maintaining? I have a problem for you... find a closed source driver for an HP/Colorado Travan TR-1 driver on Windows XP. The driver should do QIC-80 as well (all compatible tapes supported).
FCC regulations for wireless chips? That argument is bunk. Look at the SMC Barricade 802.11b router. It will happily use channels 12,13 and 14 in the US. Without even lying about the location.
Ratboy
Let me try:
IDA disassembles binaries. Who cares what OS it is run on? It should be just fine chewing OS X Intel.
GCC vs. IDA because its "open source" (rebuild the kernel) vs. "closed source" (disassemble the kernel).
Debugging? You brought that up yourself.
The kext reference was sarcastic.
Did I get that all right?
Ratboy.
I try to stay on top of multimedia related stuff. Its a flood. My original press release from Orb indicated a fee. I have checked the web-site: you are correct, no fee is charged.
I apologize for the mis-information.
Ratboy.
Orb.
1 - $10 per month, $80 per year. To stream YOUR content to YOUR device. Not bad if you can get it.
2 - Binary application. No idea WHAT it does. And I don't trust them.
3 - Limited tuner support.
Within those limitations -- sure go ahead. I don't run rogue-ware on my server, though. Especially a front-facing server.
YMMV
Ratboy
Imagine -- so much malware that there is a REAL TEAM working on the problem of automatically classifying it!
Wow...
Now that I am finished laughing (and it was a good one)...
Ratboy
"How do I get my back/forward mouse buttons to work in Firefox (like it does in Windows)?"
The question can be reversed. Why doesn't Windows work like Firefox? Or, a different question can be posed: why don't you talk to your mouse vendor?
All in all... you choose to NOT ask those questions. Now, F/OSS is flexible enough to provide you with an answer -- but you don't want to apply it.
Random config files? No, but you may want to pay someone to make the modifications for you. F/OSS doesn't mean "free as in beer". After all, you PAID for the Windows 5 button driver.
Now, let's tackle another problem: how do I get my TRAVAN-1 tape drive (Colorado) working with Windows XP? I have a LOT of backup tapes, dating back 15 years (QIC-80). Sure, works fine on Linux. Is there a "random config file" I can edit for this?
Think on this; the Zen of F/OSS will become apparent.
And, given that Vista will require driver signing, will your 5 button driver be signed? Yes, this is FUD.
Ratboy
No union. A REAL worker will stand on her merit.
I see. A libertarian.
And yet... you are begging for your student loans.
I guess that makes sense. In some twisted way. You are the deadwood, and need societies help. Or, we are all suckers. Or something.
Ratboy
Your printer is probably going to be supported in Vista. Or not (Microsoft is going to have to sign all drivers, which means new versions for all products). If it isn't (and some day it won't be), Linux will still support it. Or, you can keep your current Windows... oh, you won't be able to, Eventually, something will die (hardware), REQUIRING XP reauthorization. Since Microsoft will no longer be doing that (at some point) XP *will* die.
Oh well.
But don't worry, that printer is new and shiny right now.
Ratboy.
I will beg to differ on the nVidia driver.
I use it. Not for 3D (couldn't care about that), but because the 5200FX was the least expensive card with quality TV out.
Now, here's the rub. There is a black (or blue) band on the left edge (video overlay). Quite large - its over 8 pixels wide. Can't get rid of it. And I don't have the driver source. I was able to change the video overlay color from blue to black to make it less noticable. But it's still there.
I am going to ditch the driver soon for something open source. Simply because closed source doesn't work.
Ratboy
"Some stuff is currently not doable using only open source software."
I imagine that's true. The converse is also true. "Some stuff is currently not (easily) doable using only closed source software.". Example (off the top of my head): QIC-80 tape support for XP.
So your argument is basically a push, and depends heavily on the user.
Ratboy
Is NT based on VMS? Why does that rumour float around? Mind you, the source for NT *is* available (DEC supplied it on microfiche). BLISS-32.
/? No similarity. VMS has RMS. NT has ? No similarity. VMS has very fine grained permissions, NT has security on objects. No similarity. VMS doesn't really have threads, but does have good ways of tracking working set size, and tuning I/O. NT?
Now, as to the NT - VMS comparision. VMS has DCL. NT has cmd.exe. No similarity. VMS has HELP NT has
No, NT comes from the Unix school, with a lot of OS/2 thrown in. At least externally VMS and NT are very different. VMS is NOT a microkernel OS. VMS *did* support multiple personalities (to support migration for PDP-11 users).
So, why do these rumours persist?
Ratboy.
The Smalltalk 80 system was an OS, GUI, programming environment &etc. in Smalltalk, using a VM, with complete OOP orientation.
And, yes, there was an OS, and it was run on the VM, and no-one seemed to mind.
Squeak is the descendent of that work. Its portable because the VM can be moved -- the actual Smalltalk code uses the "OS in Smalltalk". Its probably the environment you want for your OS concept exploration.
Ratboy.
Sure, I can elaborate. The idea is that drivers are constrained in the interfaces they use. The idea is NOT to produce a "universal" DDI, but to formalize the current driver classing. Indeed, formalize it to the point that a source tool can examine the driver source and determine if it is "compliant" to the class which it belongs in. All such compliant drivers can be considered "class DDI clean" and a kernel change can then be tested against the interface.
Drivers which are not completely "class clean" need to be checked (more) carefully against kernel changes. This encourages drivers to be migrated into the "clean" class. If a kernel change occurs which affects the entire class, it is likely that automated tools can handle the change to the drivers (hopefully, the bulk of the work).
I don't consider the interface to be off limits to kernel developers, but the extra isolation should make things easier from both the driver and the kernel perspective.
Initially, such "DDI layers" should be imposed on isolated parts, where a great deal of abstraction already exists. Later on -- we (Linux) should remain flexible enough to reject such ideas if they don't work, or extend them.
Ratboy.