The normal social mechanism that prevents this sort of thing from happening in the meat world- identity leading to accountability- usually does not exist in the electronic world.
Personally, I despise anonymity, and dislike pseudonimity. Although there are cases where these are desirable, they are usually counterproductive in a forum where sensitive personal issues are not being discussed.
Pseudonimity doesn't really solve the problem, because (1) pseudonyms are usually free, and one can obtain a new one at will and (2) pseudonyms are rarely tied to a strongly identifying piece of information like a non-web email address.
Hmm. Kernel-mode file service has been around forever, and caching (even of objects of differing types) has been popular as well.
Even Microsoft's SWC (Scalable Web Cache) uses this technique. I don't see how this is really anything new.
My question is, would this really be an appropriate service for anything but static pages, considering that an errant CGI script might possibly take down not only the service, but also the server?
BTW, it's lame to say that there's no difference- if the server does anything except serve static pages, there's a real chance for data loss if the kernel panics in the middle of a write to disk, etc.
Actually, in Windows NT, he's talking about the same architectural concept. Threads are pervasive in NT, in kernel mode and user mode. So he IS correct by saying that NT's TCP/IP stack is multi-threaded. In Linux, however, I understand that threading works differently.
My favorite was "That's All", but I also liked "Home by the Sea". I hope they included these. Of course, I would have preferred to send Billy Joel down through the ages.
What? You meant the book from the bible, not the album? Oh. Sorry.
Quote from here: With C#, every object is automatically a COM object. Developers no longer have to explicitly implement IUnknown and other COM interfaces. Instead, those features are built in. Similarly, C# programs can natively use existing COM objects, no matter what language was used to author them.
The compiler handles all the references needed for recursion.
Basically, C# is an attempt to combine the features of Java and C++. C# is fully object-oriented (there are no function definitions except as methods) language with many features to make complex programming easier and faster (a la Java).
However, unlike Java, C# compiles to machine code, not byte code. Therefore C# programs do not take the performance hit that Java programs do.
Some interesting features:
automatic garbage collection (can be overridden with the "unsafe" keyword)
explicit pass-by-reference
variables must be initialized before use
every object is a COM object
even primitive types (int, etc.) are objects and methods can be applied to them
no forward declarations
So, it actually IS something new, and (IMO), actually pretty interesting. Now what we really need is GC#, and we may get it, since it was submitted to a standards body.
Hmmm. Or under NT4 you could just run an AT job to have the system NET STOP IISADMIN, or use SUSS.EXE (the NT SU service in the RK), or in Windows 2000 you could use RunAs...
I am sick and tired of people bashing NT because they are not competent enough to know how to use it. It is DIFFERENT than *nix, but that does not make it inferior.
Well obviously you wrote your database incorrectly. I regularly run programs which are CPU- and resource-intensive on my system, and Windows NT or 2000 ALWAYS stays responsive. Why? Because I bump down the thread priority of the hogging process' threads. The only time you run into this problem is when you boost the priority of a thread above the GUI (which is hard because the foreground app gets a +2 priority boost), or because you've got too many interrupts occurring (which is usually a hardware problem or a bad driver).
Re:Shotgun Stories From the Real World
on
Quickiefest 2000
·
· Score: 1
In our variant of shotgun (the International Shotgun Convention), anyone may call shotgun as soon as the driver's body breaks the plane of the door while exiting the building. This takes away the advantage of people waiting outside.
The most clever shotgun escapade ever, though, was when my evil friend called the driver on his cellphone. The driver and I were going over to pick him up, and called him to let him know. I had shotgun assured. He then called the driver on his cell phone, asked him if we were in the parking lot yet, then asked the driver to hand me the phone, at which time he said "shotgun". Bastard.
With ownership comes a number of responsibilities that don't go along with leasing/renting: maintenance and upkeep.
Why should I spend twice as much per month to buy a car rather than lease it? I intend to change cars as soon as the warranty runs out, so ownership is little advantage if I get favorable lease terms. In the meantime, I get lower payments during the time that the car is under warranty. At the end of that period I get a new car and begin again. I never have to pay for repairs (I have a car with bumper-to-bumper coverge for 3 years including all routine maintenance), so my budget is much more predictable.
Similarly, I'm a homeowner but I don't like having to mow the grass and so forth, and I dread any big repairs and what they'll do to my budget. If I had an apartment I have more restrictions (not many, I'm in a homeowner's assoc) on what I can do but I get more of my free time back and my budget is more predictable.
All I'm saying is that ownership is not a panacea, especially when durable goods are not as durable as they used to be and maintenance costs are astronomical. In many cases I choose to trade ownership for reduced time investment or reduced risk of large expenditures for repairs.
If you read the document, you'll see that they're not charging for access to the API's, they're requesting the right to charge for access to the SOURCE CODE of the API's, and demanding reciprocity. You-can-see-my-source-if-I-can-see-yours. Elsewhere in the document stringent conditions were laid down regarding how source code access would be handled.
The propaganda here about Microsoft requesting the right to inspect source code is a blatant misrepresentation of the truth.
The text says:
In connection with any disclosure of APIs, Communications Interfaces or Technical Information required under this provision, Microsoft may require the persons to whom such disclosures are made to:
i. pay a reasonable royalty to Microsoft for use of its intellectual property; [7]
ii. disclose to Microsoft any APIs or Communication Interfaces that such persons have implemented in their products to permit them to Interoperate with Microsoft Platform Software; [8] and
iii. allow qualified representatives of Microsoft to inspect the source code for such persons' products in a secure facility for the sole purpose of ensuring their compliance with the requirement that Microsoft's source code be used only to enable third-party products to Interoperate with Microsoft Platform Software. [9]
...
[9] This compliance provision is also contained in the undertaking that IBM entered into with the European Commission in 1984. See Undertaking given by IBM, Appendix B, 6, Bulletin of the European Communities, Vol. 17, No. 10 at 102 (1984). If the government believes what it says about the small risk to Microsoft of having its source code studied by competitors under the conditions specified, then the government should have no objection to giving Microsoft the reciprocal right to inspect the source code of competitors' products under the same conditions to confirm that they are not using Microsoft's source code for an improper purpose. Absent such inspection, it would be effectively impossible for Microsoft to determine whether competitors that had access to Microsoft's source code had misappropriated Microsoft's programming methods for use in their own products.
Microsoft is NOT an open source company. Moral issues aside, closed source companies jealously guard their intellectual property. This means that when they license their source code to other companies, they often charge for it, and the license often includes provisions so that they can ensure the other company is not misusing the code.
I read this entire document, and I find myself agreeing with just about every change Microsoft made to it, as well as their reasoning (which is contained in the document itself). I did think that the Microsoft's tone was almost belligerent, though...
When a specification is updated, a new RFC is posted. If a new RFC was written for Kerberos v6 (or whatever Clifford Neuman wants to call it), Microsoft could still (rightfully) claim full compliance with the original Kerberos specification (RFC 1510).
My personal take on this is that it's sour grapes. It appears to me that the other commercial Kerberos implementations are not fully compatible with MIT v5 either, and probably for the same or similar reasons, and where's the righteous indignation about those?
CyberSafe's TrustBroker (Acrobat Reader needed) indicates in it's FAQ that it's compatible "at the protocol layer", and strongly implies that there are interoperability problems or limitations.
DCE Kerberos is not interoperable with MIT's implementation. I don't see anyone screaming about that.
I'd like to see a reasonable discourse on this issue, without all the "Evil Micro$oft" rhetoric. Should standards all be written in such a way that no one is free to innovate?
Here's a side note. Regardless of what OS you use, don't you advocate the spread of Kerberos as an authentication protocol standard? If so, you should probably be grateful. I'll bet more computers have been running Kerberos since February than have ever run it before.
OK everyone. Step back and take a breath. It's obvious that in everyone's righteous indignation about Microsoft's proprietary extensions (PAC) to the Kerberos protocol, that very few people here have actually analyzed this with a critical eye.
First, Microsoft did NOT violate the Kerberos standard. Proprietary or not, secret or not, open source or not, they're using (according to one of the designers of Kerberos) the PAC field EXACTLY as it was intended to be used.
We can debate the morality of proprietary extensions until we're blue in the face, but it DOES NOT break interoperability, because the standard explicitly states that any Kerberos app may ignore the PAC field since it is optional.
Microsoft's implementation does intero perate with other implementations. You just can only get the PAC data from a Windows 2000 KDC, which requires you to have a Windows 2000 KDC in addition to your non-Windows TGS and AS if you want Windows 2000 clients to be able to access Windows 2000 resources such as shares in a Kerberos fashion.
As far as these questions go, most of them are not relevant:
1. How can Microsoft claim proprietary protections for enhancement to an open standard protocol? Microsoft is claiming protection for its own work, not for the Kerberos protocol. The Kerberos standard defines the PAC field but intentionally leaves it's implementation to vendors at this time
2. How can Microsoft use the Kerberos name, which signifies an open standard protocol, in connection with a proprietary protocol?
Very easily. Microsoft is not claiming any rights to the Kerberos name, and is fully complying with the specification. They are not requesting the PAC document be removed for any reason related to copyright of the Kerberos name.
3. How can Microsoft claim trade secrecy for a protocol that is distributed over the Internet At last, a relevant question.
4. What measures has Microsoft taken to protect the trade secrecy of its Kerberos specification beyond the use of a click-wrap license agreement? There is a long legal history of using licensing and contracts to protect trade secrets, and like it or not, it may be a DMCA violation to try to circumvent this license.
5. What measures has Microsoft taken to ensure that its Kerberos specification is only distributed to persons who are capable of entering into a binding contract in jurisdictions where such an agreement would be enforceable? This is another relevant question, but maybe less so than it initially appears, because there may be a copyright infringement issue here.
6. How could posting of the Microsoft Kerberos specification on Slashdot have any detrimental impact on the market for authorized distribution of Microsoft's version of Kerberos? Irrelevant- you allowed to be posted (and have so far failed to remove) information that you did not have the legal right to post.
7. Why wouldn't prospective purchasers of Windows 2000 need to know the contents of Microsoft's Kerberos specification in order to make informed judgments regarding interoperability in connection with their purchasing decisions? This is exactly why the specification was published
8. Why shouldn't Slashdot users and the general public be able to view this protocol for purposes of commentary and criticism in light of its apparent relevance to issues in the government's antitrust litigation? It is completely irrelevant to the antitrust case. That notwithstanding, Slashdot users DO have the right to view the specification, and to comment on it, provided that it is obtained lawfully
Bob Young's "open up the hood" argument is a very eloquent straw man.
The best analogy that illustrates this benefit is with the way we buy cars. Just ask the question, "Would you buy a car with the hood welded shut?" and we all answer an emphatic "No." So ask the follow-up question, "What do you know about modern internal-combustion engines?" and the answer for most of us is, "Not much."
Using closed source software is not analagous to buying a car where you can't open the hood. Using open source is more like requiring that the auto manufacturer hand over the blueprints. Many companies provide aftermarket parts for cars that replace standard parts, such as alloy wheels, seat covers, etc. Likewise, many companies sell software that replaces parts of closed source operating systems that were designed for replacement (biometric authentication companies routinely replace the GINA on Windows NT) or even parts that were not intended for replacement (Novell's NDS Client for Windows). You're not always limited to just the features a closed source vendor provides, and you don't always NEED the source to accomplish a change you want, especially if the closed source product exposes a modular design and mature API.
In my view, open source is not consumer-oriented, but rather hacker-oriented (in the good hacker sense). Many people buy a car and NEVER open the hood, and would probably be quite willing to buy a car with its hood welded shut (trusting trained professionals to do the maintenance for them). Many people are also content to buy computer software and use it as-is. Not everyone is car enthusiast interested in replacing the camshaft; likewise not everyone cares to be able to modify and recompile their kernel.
I just get tired of the endless dogma here. OSS is good. It's great if you're a hacker and want to play with the code. It's great if you can fix your own bugs. But the talent pool with those skills is relatively small, and the desire to hack through the kernel is relatively rare, especially since the average administrator has a million other things to do.
Here's my main point. Just because open source is good, doesn't mean that closed source is bad. Both have their places.
One last point: If you are not a programmer and can't afford to hire one, then there's probably no advantage to open source. You can choose open source and be at the mercy of the development community if you need a specific feature, or you can choose closed source and be at the mercy of the vendor. You're probably going to choose whichever product has the closest feature set to your needs, coupled with the lowest demand on your time for training, ramp-up, installation & configuration time, and ongoing support. It's not a clear-cut win for open source in many cases.
The 840 chipset uses interleaved RAMBUS to effectively halve the latency and double the bandwidth. Even Tom's Hardware reports that it's faster than DDR.
SAIC's Center for Information Security Technology, an authorized TTAP Evaluation Facility, has performed the evaluation of Microsoft's claim that the security features and assurances provided by Windows NT 4.0 with Service Pack 6a and the C2 Update with networking meet the C2 requirements of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) dated December 1985.
It's a common misconception that networked configurations cannot be C2-compliant. That's incorrect. C2 does not address networking. As long as the introduction of networking components does not break anything else that is required for C2 compatibility, then the system is still certifiable as C2.
I for one am tired of this "open source=security" nonsense.
Here are the facts: 1. An open-source operating system lets crackers examine the code and makes finding exploits much simpler.
2. An open-source operating system provides the opportunity for code to be fixed as rapidly as one can secure development resources to do so.
Here are some conclusions which no one is mentioning: 1. Truly elite crackers don't publish their exploits- they just use them until discovered. Therefore the "rapid response time" argument is of little import in many cases. With the additional difficulty level of finding closed-source exploits, open source OS's start looking like a much easier target. As a side note, open source does allow the opportunity for extensive security review, if the effort is made (a la OpenBSD). It usually is NOT.
2. Closed source OS has the advantage of a single point-of-contact and the ability to notify customers quickly. For example, Microsoft has a security alert notification service, which does a servicable job of notifying customers when a security problem is discovered, and where the patch is located.
3. There are trust issues with accepting patched source code from just anyone on the internet. Just because a hacker in the Ukraine or South America happened to be the first person to fix a security problem, doesn't mean that everyone si going to browse to that person's web site, download, compile, and install his or her code (I certainly won't). There may be liability issues as well. These problems can be addressed by open-source vendors such as RedHat, although this introduces the time lag that open source is supposedly going to prevent.
4. In-house fixes, theoretically possible with Open Source, are rarely available- the talent pool for system-level programming on an open-source OS is very small compared to the demand for the skillset, and most companies either can't afford it or can't afford a dedicated staff person just for such duties. Therefore, such a company is stuck with problems (2) and (3).
I'm just tired of all the FUD on both sides. I'm not arguing for security through obscurity, but open source is not a security panacea, as many here are positing.
Slashdot Mirror
The bug was fixed in Windows 95, contrary to a lot of the FUD that is at the lower moderation levels:
Check out this link.
The normal social mechanism that prevents this sort of thing from happening in the meat world- identity leading to accountability- usually does not exist in the electronic world.
Personally, I despise anonymity, and dislike pseudonimity. Although there are cases where these are desirable, they are usually counterproductive in a forum where sensitive personal issues are not being discussed.
Pseudonimity doesn't really solve the problem, because (1) pseudonyms are usually free, and one can obtain a new one at will and (2) pseudonyms are rarely tied to a strongly identifying piece of information like a non-web email address.
Not true- this was just a rumor.
Hmm. Kernel-mode file service has been around forever, and caching (even of objects of differing types) has been popular as well.
Even Microsoft's SWC (Scalable Web Cache) uses this technique. I don't see how this is really anything new.
My question is, would this really be an appropriate service for anything but static pages, considering that an errant CGI script might possibly take down not only the service, but also the server?
BTW, it's lame to say that there's no difference- if the server does anything except serve static pages, there's a real chance for data loss if the kernel panics in the middle of a write to disk, etc.
Actually, in Windows NT, he's talking about the same architectural concept. Threads are pervasive in NT, in kernel mode and user mode. So he IS correct by saying that NT's TCP/IP stack is multi-threaded. In Linux, however, I understand that threading works differently.
My favorite was "That's All", but I also liked "Home by the Sea". I hope they included these. Of course, I would have preferred to send Billy Joel down through the ages.
What? You meant the book from the bible, not the album? Oh. Sorry.
Quote from here:
With C#, every object is automatically a COM object. Developers no longer have to explicitly implement IUnknown and other COM interfaces. Instead, those features are built in. Similarly, C# programs can natively use existing COM objects, no matter what language was used to author them.
The compiler handles all the references needed for recursion.
Basically, C# is an attempt to combine the features of Java and C++. C# is fully object-oriented (there are no function definitions except as methods) language with many features to make complex programming easier and faster (a la Java).
However, unlike Java, C# compiles to machine code, not byte code. Therefore C# programs do not take the performance hit that Java programs do.
Some interesting features:
automatic garbage collection (can be overridden with the "unsafe" keyword)
explicit pass-by-reference
variables must be initialized before use
every object is a COM object
even primitive types (int, etc.) are objects and methods can be applied to them
no forward declarations
So, it actually IS something new, and (IMO), actually pretty interesting. Now what we really need is GC#, and we may get it, since it was submitted to a standards body.
Hmmm. Or under NT4 you could just run an AT job to have the system NET STOP IISADMIN, or use SUSS.EXE (the NT SU service in the RK), or in Windows 2000 you could use RunAs...
I am sick and tired of people bashing NT because they are not competent enough to know how to use it. It is DIFFERENT than *nix, but that does not make it inferior.
Well obviously you wrote your database incorrectly. I regularly run programs which are CPU- and resource-intensive on my system, and Windows NT or 2000 ALWAYS stays responsive. Why? Because I bump down the thread priority of the hogging process' threads. The only time you run into this problem is when you boost the priority of a thread above the GUI (which is hard because the foreground app gets a +2 priority boost), or because you've got too many interrupts occurring (which is usually a hardware problem or a bad driver).
In our variant of shotgun (the International Shotgun Convention), anyone may call shotgun as soon as the driver's body breaks the plane of the door while exiting the building. This takes away the advantage of people waiting outside.
The most clever shotgun escapade ever, though, was when my evil friend called the driver on his cellphone. The driver and I were going over to pick him up, and called him to let him know. I had shotgun assured. He then called the driver on his cell phone, asked him if we were in the parking lot yet, then asked the driver to hand me the phone, at which time he said "shotgun". Bastard.
Evidently Rodona got to cluelessfucks.com- they took the mirror down.
With ownership comes a number of responsibilities that don't go along with leasing/renting: maintenance and upkeep.
Why should I spend twice as much per month to buy a car rather than lease it? I intend to change cars as soon as the warranty runs out, so ownership is little advantage if I get favorable lease terms. In the meantime, I get lower payments during the time that the car is under warranty. At the end of that period I get a new car and begin again. I never have to pay for repairs (I have a car with bumper-to-bumper coverge for 3 years including all routine maintenance), so my budget is much more predictable.
Similarly, I'm a homeowner but I don't like having to mow the grass and so forth, and I dread any big repairs and what they'll do to my budget. If I had an apartment I have more restrictions (not many, I'm in a homeowner's assoc) on what I can do but I get more of my free time back and my budget is more predictable.
All I'm saying is that ownership is not a panacea, especially when durable goods are not as durable as they used to be and maintenance costs are astronomical. In many cases I choose to trade ownership for reduced time investment or reduced risk of large expenditures for repairs.
Just some thoughts.
If you read the document, you'll see that they're not charging for access to the API's, they're requesting the right to charge for access to the SOURCE CODE of the API's, and demanding reciprocity. You-can-see-my-source-if-I-can-see-yours. Elsewhere in the document stringent conditions were laid down regarding how source code access would be handled.
The text says:
i. pay a reasonable royalty to Microsoft for use of its intellectual property; [7]
ii. disclose to Microsoft any APIs or Communication Interfaces that such persons have implemented in their products to permit them to Interoperate with Microsoft Platform Software; [8] and
iii. allow qualified representatives of Microsoft to inspect the source code for such persons' products in a secure facility for the sole purpose of ensuring their compliance with the requirement that Microsoft's source code be used only to enable third-party products to Interoperate with Microsoft Platform Software. [9]
...
[9] This compliance provision is also contained in the undertaking that IBM entered into with the European Commission in 1984. See Undertaking given by IBM, Appendix B, 6, Bulletin of the European Communities, Vol. 17, No. 10 at 102 (1984). If the government believes what it says about the small risk to Microsoft of having its source code studied by competitors under the conditions specified, then the government should have no objection to giving Microsoft the reciprocal right to inspect the source code of competitors' products under the same conditions to confirm that they are not using Microsoft's source code for an improper purpose. Absent such inspection, it would be effectively impossible for Microsoft to determine whether competitors that had access to Microsoft's source code had misappropriated Microsoft's programming methods for use in their own products.
Microsoft is NOT an open source company. Moral issues aside, closed source companies jealously guard their intellectual property. This means that when they license their source code to other companies, they often charge for it, and the license often includes provisions so that they can ensure the other company is not misusing the code.
I read this entire document, and I find myself agreeing with just about every change Microsoft made to it, as well as their reasoning (which is contained in the document itself). I did think that the Microsoft's tone was almost belligerent, though...
Wrong. Microsoft Proxy Server also provides SOCKS.
When a specification is updated, a new RFC is posted. If a new RFC was written for Kerberos v6 (or whatever Clifford Neuman wants to call it), Microsoft could still (rightfully) claim full compliance with the original Kerberos specification (RFC 1510).
My personal take on this is that it's sour grapes. It appears to me that the other commercial Kerberos implementations are not fully compatible with MIT v5 either, and probably for the same or similar reasons, and where's the righteous indignation about those?
CyberSafe's TrustBroker (Acrobat Reader needed) indicates in it's FAQ that it's compatible "at the protocol layer", and strongly implies that there are interoperability problems or limitations.
DCE Kerberos is not interoperable with MIT's implementation. I don't see anyone screaming about that.
I'd like to see a reasonable discourse on this issue, without all the "Evil Micro$oft" rhetoric. Should standards all be written in such a way that no one is free to innovate?
Here's a side note. Regardless of what OS you use, don't you advocate the spread of Kerberos as an authentication protocol standard? If so, you should probably be grateful. I'll bet more computers have been running Kerberos since February than have ever run it before.
OK everyone. Step back and take a breath. It's obvious that in everyone's righteous indignation about Microsoft's proprietary extensions (PAC) to the Kerberos protocol, that very few people here have actually analyzed this with a critical eye.
First, Microsoft did NOT violate the Kerberos standard. Proprietary or not, secret or not, open source or not, they're using (according to one of the designers of Kerberos) the PAC field EXACTLY as it was intended to be used.
We can debate the morality of proprietary extensions until we're blue in the face, but it DOES NOT break interoperability, because the standard explicitly states that any Kerberos app may ignore the PAC field since it is optional.
Microsoft's implementation does intero perate with other implementations. You just can only get the PAC data from a Windows 2000 KDC, which requires you to have a Windows 2000 KDC in addition to your non-Windows TGS and AS if you want Windows 2000 clients to be able to access Windows 2000 resources such as shares in a Kerberos fashion.
As far as these questions go, most of them are not relevant:
1. How can Microsoft claim proprietary protections for enhancement to an open standard protocol?
Microsoft is claiming protection for its own work, not for the Kerberos protocol. The Kerberos standard defines the PAC field but intentionally leaves it's implementation to vendors at this time
2. How can Microsoft use the Kerberos name, which signifies an open standard protocol, in connection with a proprietary protocol?
Very easily. Microsoft is not claiming any rights to the Kerberos name, and is fully complying with the specification. They are not requesting the PAC document be removed for any reason related to copyright of the Kerberos name.
3. How can Microsoft claim trade secrecy for a protocol that is distributed over the Internet
At last, a relevant question.
4. What measures has Microsoft taken to protect the trade secrecy of its Kerberos specification beyond the use of a click-wrap license agreement?
There is a long legal history of using licensing and contracts to protect trade secrets, and like it or not, it may be a DMCA violation to try to circumvent this license.
5. What measures has Microsoft taken to ensure that its Kerberos specification is only distributed to persons who are capable of entering into a binding contract in jurisdictions where such an agreement would be enforceable?
This is another relevant question, but maybe less so than it initially appears, because there may be a copyright infringement issue here.
6. How could posting of the Microsoft Kerberos specification on Slashdot have any detrimental impact on the market for authorized distribution of Microsoft's version of Kerberos?
Irrelevant- you allowed to be posted (and have so far failed to remove) information that you did not have the legal right to post.
7. Why wouldn't prospective purchasers of Windows 2000 need to know the contents of Microsoft's Kerberos specification in order to make informed judgments regarding interoperability in connection with their purchasing decisions?
This is exactly why the specification was published
8. Why shouldn't Slashdot users and the general public be able to view this protocol for purposes of commentary and criticism in light of its apparent relevance to issues in the government's antitrust litigation?
It is completely irrelevant to the antitrust case. That notwithstanding, Slashdot users DO have the right to view the specification, and to comment on it, provided that it is obtained lawfully
Yes, but it would also cause aborted connections if the client happened to have two ACKs on the net at once, and they arrived out of order.
Bob Young's "open up the hood" argument is a very eloquent straw man.
The best analogy that illustrates this benefit is with the way we buy cars. Just ask the question, "Would you buy a car with the hood welded shut?" and we all answer an emphatic "No." So ask the follow-up question, "What do you know about modern internal-combustion engines?" and the answer for most of us is, "Not much."
Using closed source software is not analagous to buying a car where you can't open the hood. Using open source is more like requiring that the auto manufacturer hand over the blueprints. Many companies provide aftermarket parts for cars that replace standard parts, such as alloy wheels, seat covers, etc. Likewise, many companies sell software that replaces parts of closed source operating systems that were designed for replacement (biometric authentication companies routinely replace the GINA on Windows NT) or even parts that were not intended for replacement (Novell's NDS Client for Windows). You're not always limited to just the features a closed source vendor provides, and you don't always NEED the source to accomplish a change you want, especially if the closed source product exposes a modular design and mature API.
In my view, open source is not consumer-oriented, but rather hacker-oriented (in the good hacker sense). Many people buy a car and NEVER open the hood, and would probably be quite willing to buy a car with its hood welded shut (trusting trained professionals to do the maintenance for them). Many people are also content to buy computer software and use it as-is. Not everyone is car enthusiast interested in replacing the camshaft; likewise not everyone cares to be able to modify and recompile their kernel.
I just get tired of the endless dogma here. OSS is good. It's great if you're a hacker and want to play with the code. It's great if you can fix your own bugs. But the talent pool with those skills is relatively small, and the desire to hack through the kernel is relatively rare, especially since the average administrator has a million other things to do.
Here's my main point. Just because open source is good, doesn't mean that closed source is bad. Both have their places.
One last point: If you are not a programmer and can't afford to hire one, then there's probably no advantage to open source. You can choose open source and be at the mercy of the development community if you need a specific feature, or you can choose closed source and be at the mercy of the vendor. You're probably going to choose whichever product has the closest feature set to your needs, coupled with the lowest demand on your time for training, ramp-up, installation & configuration time, and ongoing support. It's not a clear-cut win for open source in many cases.
Dr. Robert Bakker proposed this theory years ago. Here is his book.
The 840 chipset uses interleaved RAMBUS to effectively halve the latency and double the bandwidth. Even Tom's Hardware reports that it's faster than DDR.
WRONG.
P -CSC-EPL-99-001.html
Here's the link:
http://www.radium.ncsc.mil/tpep/epl/entries/TTA
SAIC's Center for Information Security Technology, an authorized TTAP Evaluation Facility, has performed the evaluation of Microsoft's claim that the security features and assurances provided by Windows NT 4.0 with Service Pack 6a and the C2 Update with networking meet the C2 requirements of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) dated December 1985.
It's a common misconception that networked configurations cannot be C2-compliant. That's incorrect. C2 does not address networking. As long as the introduction of networking components does not break anything else that is required for C2 compatibility, then the system is still certifiable as C2.
You forgot two lines:
Take all threats and warning signs seriously.
Talk to a parent, counselor or other adult about my concerns.
I for one am tired of this "open source=security" nonsense.
Here are the facts:
1. An open-source operating system lets crackers examine the code and makes finding exploits much simpler.
2. An open-source operating system provides the opportunity for code to be fixed as rapidly as one can secure development resources to do so.
Here are some conclusions which no one is mentioning:
1. Truly elite crackers don't publish their exploits- they just use them until discovered. Therefore the "rapid response time" argument is of little import in many cases. With the additional difficulty level of finding closed-source exploits, open source OS's start looking like a much easier target. As a side note, open source does allow the opportunity for extensive security review, if the effort is made (a la OpenBSD). It usually is NOT.
2. Closed source OS has the advantage of a single point-of-contact and the ability to notify customers quickly. For example, Microsoft has a security alert notification service, which does a servicable job of notifying customers when a security problem is discovered, and where the patch is located.
3. There are trust issues with accepting patched source code from just anyone on the internet. Just because a hacker in the Ukraine or South America happened to be the first person to fix a security problem, doesn't mean that everyone si going to browse to that person's web site, download, compile, and install his or her code (I certainly won't). There may be liability issues as well. These problems can be addressed by open-source vendors such as RedHat, although this introduces the time lag that open source is supposedly going to prevent.
4. In-house fixes, theoretically possible with Open Source, are rarely available- the talent pool for system-level programming on an open-source OS is very small compared to the demand for the skillset, and most companies either can't afford it or can't afford a dedicated staff person just for such duties. Therefore, such a company is stuck with problems (2) and (3).
I'm just tired of all the FUD on both sides. I'm not arguing for security through obscurity, but open source is not a security panacea, as many here are positing.
Eric