I remember Oracle advocating a "three-tier" network in the '90s. This was essentially a thin-client/server with workstations for power users only model. So, the engineering department might have several beefy dual cpu workstations with gigabit ethernet, but the business users would have thin clients with an office suite, web browser, and email client. Any enterprise apps could run on an intranet with a web front end so that thin clients would have access to them without the need for additional processing power.
This seemed like a pretty good model to me at the time, and still does. I've never encountered it in any real environment that I have been in (Admittedly, I've mostly worked for small to medium sized companies, so there may be someone out there actually doing this without my knowledge.) The fact that it is not in widespread use may have something to do with Windows. Windows does not make an especially attractive thin client, and the licensing costs for Windows software coupled with the maintenance requirements make thin client use economically infeasible as well (Essentially Windows PC users take on a lot of the responsibility of maintaining their own local environment just by virtue of the way Windows operates. Plus it doesn't make a lot of sense to spend $100+ on the OS plus a couple hundred on office software and not spend at least as much on hardware that will run it well.)
In a typical environment some apps may be on the intranet, some may be client server; some files may live on a file server, some on a local drive; some setting may be in AD, some on the local registery or in the user's settings folder on the local drive, etc. Essentially this is the bastard son of client/server and thin client/server methodologies.
I think Linux is much more attractive for a three tier system for the following reasons:
Linux software is cheap or free.
Linux runs well on cheap hardware and can easily function as a thin client on yesterday's middle of the road PCs.
The Linux environment can be managed by a system administrator and all settings can be kept in a single location on the network rather than on the local machine. This seems to be true in principle for Windows as well, but in practice a lot of stuff is still local.
Linux interoperates very well with other OSes. Essentially this allows for a separation of concerns between the three tiers. Thin clients could run Linux, workstations could run Solaris (Or whatever floats your boat), and servers could run some combination of Linux/Unix/Windows all quite manageably.
Bill Gates took a two week vacation and cost the company twice as much in billable hours.
Seriously, why does Microsoft care about a $521 million payout? At that rate blatant patent fraud is still amazingly profitable for them. The only way Microsoft will ever stop acting like Microsoft is if they are broken up and their execs put in jail.
I've had enough of this crap. Software patents should be abolished. period. All of the real innovation takes place in the code, and that is covered by copyright. Beyond that, it is the business model that makes software valuable, not the "IP." If you have to have broad sweeping patents and pay more in legal fees than payroll in order to turn a profit then you have already failed as a business and are just depending on the idiots in Washington being idiots in order for you to make payroll.
Angry robot with guns Sumo wrestler on his ass Two bunny rabits eating guts Batman's crotch Two green berets with black eyes Football shoulder pads Fairy frog wearing an apron Two sheep heads crapped on by a butterfly Rocket propelled chicken on a golden throne Hawkman with jetpack
AsSsTsBhTsFsFnTyReHk
It is interesting that we both saw comic book heroes even though I did this before reading your post.
I think that those of us who strongly advocate privacy rights do tend to have a knee-jerk reaction to this kind of stuff. The problem is, that as law enforcement's ability to collect intelligence increases at an alarming rate, their ability to use that information in a non-intrusive way, and even more importantly their ability to solve the criminal problem don't seem to be improving AT ALL. If we can use DNA to identify a criminal with almost perfect accuracy, then we need an appropriate way to deal with them. We've all been brainwashed into believing that putting them in jail for a long time will "rehabilitate" them, but this has actually NEVER HAPPENED. I know that I am a bit radical on this subject, but I would rather have a mass murderer as my neighbor than put anyone through our criminal justice system as it currently exists. It just doesn't do anything useful, IMO. The only reason it works at all is through a kind of FUD - The majority of people who ARE NOT criminals will avoid doing certain things for fear of going to prison. Those who actually end up in prison are not susceptable to this same FUD, so they keep on commiting crimes. We need to start looking at real solutions to crime not just shoving people in jail and forgetting about them until the get out and commit a crime again (Very often on the same day.)
We need to allow private citizens to arm themselves. This will make violent crime more dangerous to the criminal, reducing the numbers of such crimes and the numbers of such criminals.
We need to end the war on drugs taking the largest revenue stream away from organized crime, and decriminalizing victimless recreation. Those who are addicted to drugs can and should be treated for that addiction, not locked up where they are introduced to stronger better drugs and taught how to be real criminals.
In those instances where real crimes that do real harm are still committed we need to look at remedies that actually seek to rehabilitate as much as if not more than punish. Our current penalties are: fines, imprisonment, probation, and execution. Crap, crap, crap, and super crap. We need a system that more heavily favors community service and public accountability, and we should revisit an old favorite of our ancestors - banishment. If you are a repeat offender who cannot stop committing crimes then you need to get the hell out and go bug someone else. We'll see if they are as nice to you as we were.
Ironically, a ruling which finds RCU to not be a derived work of Sys V helps IBM but weakens the GPL by narrowing what must be considered a derived work. A ruling which holds RCU to be a derived work of Sys V hurts IBM, but helps the GPL by setting an expansive definition of what constitutes a derived work.
I don't think that a more expansive definition of derivitive works "helps" the GPL. If anything, it contributes to the perception that GPL has a "viral nature" as claimed by Microsoft. If I am a company with commercial interests and I also want to make use of GPL software, I want to be very clear about what constitutes a derivative work so that my commercial interests are not affected. If something that I do using GPL software is not currently considered a derivative work, and then suddenly someone like SCO comes along, wins a suit, and expands the definition of a derivative work to include the type of work I am doing, then my commercial interests can be severely impacted. That is why SCO CANNOT win this case if we ever want to see widespread use of GPL software by the business community.
I've worked on open source projects and I've also worked in commercial development shops. I think that their findings are accurate but misleading:
In my experience there are generally less bugs in pre-release code on a commercial project because there is a stronger culture of code ownership, and most if not all code is independently reviewed before being committed.
There are generally a high number of defects in pre-release open source code, because developers commit early and commit often. Independent review happens more often in open source projects, but it usually happens after the code has already been committed to the dev branch (Before that, the geographically dispersed dev team has no access to it.)
The quality of code released to production in a commercial environment is usually very similar to the quality of code in the development branch. Once it is reviewed and committed it enters a QA cycle where an independent team tries to find any bugs. At this point there is invariably strong pressure to release. So, bug fixes happen quickly and quality suffers (I've always found it ironic that we called this "Quality Assurance.")
Once an open source project has been completed (Meaning all of the features have been developed) it enters a much longer period of code review, bug hunting, and alpha release. For a project like Apache it was over a year before anyone started to use 2.0 in production. Most commercial companies can't afford nearly that much "QA" time, because they are spending money to make money.
First I thought black box testing was testing specifically without knowledge of the internals of the system ie. you provide input after independently calculating the answer and then see if the output is the same as your expected answer. If you do it enough times and the answers are the same as your calcs then you can rely on the black box.
You are correct for the most part. What I was talking about was the circumvention of copy protection for the purpose of performing testing. I suppose it would have been more correct to refer to grey box testing because you are more likely to have to do this then. However, there are times where some circumvention of copy protection which would violate the DMCA is necessary even for black box testing. (In order to do white box testing you have to actually have the source code, which means you would have to completely reverse engineer the whole app. At that point it is usually easier to write your own.)
Second, you may have missed the bit in the standard warranty and EULA that says the vendor accepts no responsibility if the software doesn't do what they say it will do let alone what you expect. Whether they stand up in court or not the vendor probably sees more l;oss in pirates than in claims for faulty software.
No, I didn't miss that. One of the reasons that EULAs don't always hold up in court is that this type of clause (e.g. "It doesn't actually have to do what you paid for it to do.") doesn't fool judges very often. The more likely reason that software companies aren't afraid of litigation is that they are so rich from peddling their vaporware that they can afford to hold such litigation up with motion after motion while simultaneously lobbying for crap like the DMCA, but that is just my opinion.
Interesting that this doesn't include a provision for circumventing protection for the purpose of black box testing. It seems to me that one of the most practical uses of reverse engineering in industry is to verify that the software does what you need it to do reliably and predictably. Such a legitimate use of reverse engineering is good for the supplier, the customer, and the end user, because it ensures the efficacy of the product for a particular use. For the end user, this ensures that the product performs as advertised. In some cases safety might even be at stake. For the corporate user risk is significantly reduced when you buy a product knowing that it will do what you need it to. For the original author, the loss of revenue due to piracy is probably less of a risk that the litigation that arrises from selling a product that doesn't do what it says it does.
And it's about time we revisited this issue. The Tenth Ammendment is extremely relevant here. If the federal government is hell bent on ignoring the other nine it is up to "The States respectively, [and] the People" to tell them where they can shove it.
I was unaware of the use of the term spam with regards to buffer overflow. If this is accurate (And the jargon file is a pretty good source) then it could predate the use I am familiar with.
The description of spam as content "unfit for human consumption" is something that I heard a very long time ago as an explanation of its use on the BBS. There are a couple of possibilities:
The connection to Monty Python was discovered after the term began to be used in which case my origin is correct and other uses came about later.
The description as "unfit for human consumption" appeared after the term was already in use and the Monty Python derived meaning is older (I think this is likely. To be fair, though I first heard that it was related to Monty Python YEARS after I heard it described in the other context.)
Or, both uses of the term are equally valid and have converged. This may sound implausible, but I think it is likely, because in the BBS days the term was often used to refer to a single OT or otherwise useless post whereas the description in the jargon file depends on a plurality of useless data, thus the Monty Python connection.
This is totally wrong. The term "Spam" originated in the BBS days when lamers would post stuff that was OT or otherwise useless. The resulting traffic was "unfit for human consumption." Some people started referring to this as "Spam" which rapidly evolved into a verb (e.g. "Spamming") When mailing lists started to take over idiots would still post (or even cross-post) useless stuff which was referred to as "Spamming the list." This crap would accumulate in your inbox. Email advertisments had similar properties, not to mention that ad spammers started using mailing lists as a cheap and easy way to get a wide distribution. Thus the term "Spam" began to refer exclusively to unsolicited advertisments.
Spam is indeed quite popular not only in Hawaii, but throughout the Pacific islands.
Importing food to Hawaii, Micronesia, etc...
It also doesn't hurt that pork is a very traditional food in Polynesian culture. It is usually slow roasted in a pit for a whole day. The result is a very tender juicy meat that is not entirely unlike spam (Although 100,000 times better, IMO.)
What about client side XSLT? Microsoft added that to IE. That is a pretty big step. Maybe its not so visible because what the end user sees doesn't change, but it has a pretty big impact on the way websites can be developed.
From the abstract it is clear that this book is intended to describe the Perl 6 project including the reasons for rewriting the language, the desing philosophy, some of the roadblocks along the way, etc. It sounds like a real interesting read for those who are interested in the process of designing and implementing a full scale computer language, regardless of how you feel about the particular results.
Yeah, many people who have not tried it say that. Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.
The problem with that is that a lot of developers like myself have grown up with Fortran -> C -> C++ -> Perl -> Java, or some similar progression. We don't have a problem matching parenthesis. In fact, any decent text editor or IDE will help us match parens and get the indents looking the way we want them to. Hell, even vi can do that if used correctly!!
It's not like there is nothing else in modern scripting languages that the python folks could have tried to fix. Why go back to the archaic practice of giving whitespace semantic meaning??
If it were communism, then the entire economy would be controlled by a single entity without even the illusion of competition. Fascism is significantly more dangerous, because its economic policies are driven by a central government which controls industry through legislation. Competition still exists, in theory, but the government gets to decide who competes and who doesn't. Sound familiar?
As I mentioned before, my point was that there is rarely a compelling reason to have to port J2EE code, thus "Have you ever tried..." meaning have you ever had a reason to. Now, java code in general is a different issue. If you are writing GUI apps or Applets then there is a good reason to want your code to be portable. However, my experience in recent years has been that most of the Java programmers out there are doing things where "portability" does not properly belong on the list of non-functional requirements.
It is quite doable. That wasn't actually my point. My point is that you rarely need to do it. Certainly Java code can be portable. And it can be ported very easily if you plan for portability up front. The same is true for C/C++, Perl, Python, and numerous others. My point is that Sun harps about portability all day long, but when it comes down to it the many thousands of programmers who use Java probably do so for other reasons. If portability is a factor it is certainly not the most important one.
In fact, I would go as far as to say that there are only two situations where portability is infeasible in any modern language:
You are using a language or API that is specifically designed not to be portable (Such as C#, VB, old fashioned MFC, etc.)
It is so important to do as much as possible as quickly as possible under repeatable conditions that you forego good object oriented design in favor of a mess of inline assembly and otherwise optimized object code. It is very unlikely - though not impossible - that this will be portable to another architecture.
And microsoft seems to have gotten out of the java game anyway, so their corruption isn't much of an issue...
C# was in large part a move to get Java programmers to come over to the.NET platform. The number of wagon jumpers wasn't as high as Microsoft wanted so they reinvented J++ as J#.NET. I bought the C++.NET 2003 edition recently, and I had a good laugh at the back of the J#.NET package on the next shelf over at CompUSA. They actually mention "familiar Java syntax."
For all of you.NET evangelists out there (I know you're listening) I actually like C++.NET. Managed extensions give me a lot of the same capabilities that I get with container services in J2EE. However, I refuse to learn a new language just so that I can do things the Microsoft Way (TM). Portability is really not as big of an issue as Sun would like us to believe (Have you ever actually tried to port a J2EE app from one app server to another? Let alone one system architecture to another!?!) Still, J2EE offers some things that.NET doesn't (i.e. better support for persistence, distributed apps that don't rely on web services, distributed transaction support that doesn't rely on proprietary database server technologies, JSP Model 2 for web apps is a much stronger separation of concerns than ASP provides - XML/XSLT is not always the best solutions, etc.)
Perhaps instead it is the process. There doesn't tend to be as much Big Design Up Front (BDUF) in open source projects as in many commercial projects. The development process for OSS is either driven primarily by a single project lead or a small group of committers rather than a requirements gathering/business analysis team like at many software firms. Thus the process is more fluid and code oriented. If design flaws occur it is usually due to lack of vision of the project as a whole and not due to programmers misunderstanding business people's requirement documents (Which often seem written explicitly to elicit misunderstanding, IMO)
Cops are grunts, servants of the law. They enforce the rules that they are told to enforce the way that they are told to enforce them. Most of them are ex-military with few other career prospects. They start out with a legitimate desire to help people, but end up consoling themselves with the fact that they do more good then harm and working real hard for meager promotions and eventually a good pension if they live that long.
Don't blame the cops. Some are good, some are bad - just like everyone else. They are not the problem. The problem is the lawmakers and administrations who try to create rules to dictate morality and/or earn extra cash. Neither of these is a good use for the law. Laws should mitigate the risk of harm to the general public, and/or seek restitution for actual harm done to persons or institutions through intentional action or inaction. Very few laws do these things. Most just waste our time, take from the poor and give to the rich, enforce someone else's standard of morality (Such as the good old "war on drugs" or censorship.) If lawmakers would stop stealing our money and wasting our time with frivilous rulemongering then the cops might actually have an opportunity to "protect and serve" rather than acting as glorified paramilitary drug enforcers.
In short tax dollars should not be used to _create_ GPL'd software, IMHO.
I suppose I agree to a point, but I am not sure how much of a problem this actually is. First, if government software is derived from GPL software then it must be GPL software. Doing this may actually save a lot of money in some cases. Second, if government employees are collaborating with GPL project committers to make that GPL software work for their needs then I don't see a problem. This may save a lot of money as well. So, the only case where I see this as being relevant is when ORIGINAL government works are released as GPL. I am not sure how often this happens, but I can see the argument for government created works being public domain (or purely closed source for security reasons, but even that excuse is often dubious.)
Slashdot Mirror
This seemed like a pretty good model to me at the time, and still does. I've never encountered it in any real environment that I have been in (Admittedly, I've mostly worked for small to medium sized companies, so there may be someone out there actually doing this without my knowledge.) The fact that it is not in widespread use may have something to do with Windows. Windows does not make an especially attractive thin client, and the licensing costs for Windows software coupled with the maintenance requirements make thin client use economically infeasible as well (Essentially Windows PC users take on a lot of the responsibility of maintaining their own local environment just by virtue of the way Windows operates. Plus it doesn't make a lot of sense to spend $100+ on the OS plus a couple hundred on office software and not spend at least as much on hardware that will run it well.)
In a typical environment some apps may be on the intranet, some may be client server; some files may live on a file server, some on a local drive; some setting may be in AD, some on the local registery or in the user's settings folder on the local drive, etc. Essentially this is the bastard son of client/server and thin client/server methodologies.
I think Linux is much more attractive for a three tier system for the following reasons:
Ben Asslick, star of the critically abashed Gigli, in Johnny Mnemonic 2.
Bill Gates took a two week vacation and cost the company twice as much in billable hours.
Seriously, why does Microsoft care about a $521 million payout? At that rate blatant patent fraud is still amazingly profitable for them. The only way Microsoft will ever stop acting like Microsoft is if they are broken up and their execs put in jail.
I've had enough of this crap. Software patents should be abolished. period. All of the real innovation takes place in the code, and that is covered by copyright. Beyond that, it is the business model that makes software valuable, not the "IP." If you have to have broad sweeping patents and pay more in legal fees than payroll in order to turn a profit then you have already failed as a business and are just depending on the idiots in Washington being idiots in order for you to make payroll.
Angry robot with guns
Sumo wrestler on his ass
Two bunny rabits eating guts
Batman's crotch
Two green berets with black eyes
Football shoulder pads
Fairy frog wearing an apron
Two sheep heads crapped on by a butterfly
Rocket propelled chicken on a golden throne
Hawkman with jetpack
AsSsTsBhTsFsFnTyReHk
It is interesting that we both saw comic book heroes even though I did this before reading your post.
I don't think that a more expansive definition of derivitive works "helps" the GPL. If anything, it contributes to the perception that GPL has a "viral nature" as claimed by Microsoft. If I am a company with commercial interests and I also want to make use of GPL software, I want to be very clear about what constitutes a derivative work so that my commercial interests are not affected. If something that I do using GPL software is not currently considered a derivative work, and then suddenly someone like SCO comes along, wins a suit, and expands the definition of a derivative work to include the type of work I am doing, then my commercial interests can be severely impacted. That is why SCO CANNOT win this case if we ever want to see widespread use of GPL software by the business community.
You are correct for the most part. What I was talking about was the circumvention of copy protection for the purpose of performing testing. I suppose it would have been more correct to refer to grey box testing because you are more likely to have to do this then. However, there are times where some circumvention of copy protection which would violate the DMCA is necessary even for black box testing. (In order to do white box testing you have to actually have the source code, which means you would have to completely reverse engineer the whole app. At that point it is usually easier to write your own.)
Second, you may have missed the bit in the standard warranty and EULA that says the vendor accepts no responsibility if the software doesn't do what they say it will do let alone what you expect. Whether they stand up in court or not the vendor probably sees more l;oss in pirates than in claims for faulty software.
No, I didn't miss that. One of the reasons that EULAs don't always hold up in court is that this type of clause (e.g. "It doesn't actually have to do what you paid for it to do.") doesn't fool judges very often. The more likely reason that software companies aren't afraid of litigation is that they are so rich from peddling their vaporware that they can afford to hold such litigation up with motion after motion while simultaneously lobbying for crap like the DMCA, but that is just my opinion.
Cygwin has strace
Interesting that this doesn't include a provision for circumventing protection for the purpose of black box testing. It seems to me that one of the most practical uses of reverse engineering in industry is to verify that the software does what you need it to do reliably and predictably. Such a legitimate use of reverse engineering is good for the supplier, the customer, and the end user, because it ensures the efficacy of the product for a particular use. For the end user, this ensures that the product performs as advertised. In some cases safety might even be at stake. For the corporate user risk is significantly reduced when you buy a product knowing that it will do what you need it to. For the original author, the loss of revenue due to piracy is probably less of a risk that the litigation that arrises from selling a product that doesn't do what it says it does.
And it's about time we revisited this issue. The Tenth Ammendment is extremely relevant here. If the federal government is hell bent on ignoring the other nine it is up to "The States respectively, [and] the People" to tell them where they can shove it.
This is totally wrong. The term "Spam" originated in the BBS days when lamers would post stuff that was OT or otherwise useless. The resulting traffic was "unfit for human consumption." Some people started referring to this as "Spam" which rapidly evolved into a verb (e.g. "Spamming") When mailing lists started to take over idiots would still post (or even cross-post) useless stuff which was referred to as "Spamming the list." This crap would accumulate in your inbox. Email advertisments had similar properties, not to mention that ad spammers started using mailing lists as a cheap and easy way to get a wide distribution. Thus the term "Spam" began to refer exclusively to unsolicited advertisments.
Spam is indeed quite popular not only in Hawaii, but throughout the Pacific islands.
Importing food to Hawaii, Micronesia, etc...
It also doesn't hurt that pork is a very traditional food in Polynesian culture. It is usually slow roasted in a pit for a whole day. The result is a very tender juicy meat that is not entirely unlike spam (Although 100,000 times better, IMO.)
What about client side XSLT? Microsoft added that to IE. That is a pretty big step. Maybe its not so visible because what the end user sees doesn't change, but it has a pretty big impact on the way websites can be developed.
From the abstract it is clear that this book is intended to describe the Perl 6 project including the reasons for rewriting the language, the desing philosophy, some of the roadblocks along the way, etc. It sounds like a real interesting read for those who are interested in the process of designing and implementing a full scale computer language, regardless of how you feel about the particular results.
The problem with that is that a lot of developers like myself have grown up with Fortran -> C -> C++ -> Perl -> Java, or some similar progression. We don't have a problem matching parenthesis. In fact, any decent text editor or IDE will help us match parens and get the indents looking the way we want them to. Hell, even vi can do that if used correctly!!
It's not like there is nothing else in modern scripting languages that the python folks could have tried to fix. Why go back to the archaic practice of giving whitespace semantic meaning??
If it were communism, then the entire economy would be controlled by a single entity without even the illusion of competition. Fascism is significantly more dangerous, because its economic policies are driven by a central government which controls industry through legislation. Competition still exists, in theory, but the government gets to decide who competes and who doesn't. Sound familiar?
As I mentioned before, my point was that there is rarely a compelling reason to have to port J2EE code, thus "Have you ever tried..." meaning have you ever had a reason to. Now, java code in general is a different issue. If you are writing GUI apps or Applets then there is a good reason to want your code to be portable. However, my experience in recent years has been that most of the Java programmers out there are doing things where "portability" does not properly belong on the list of non-functional requirements.
In fact, I would go as far as to say that there are only two situations where portability is infeasible in any modern language:
For all of you .NET evangelists out there (I know you're listening) I actually like C++ .NET. Managed extensions give me a lot of the same capabilities that I get with container services in J2EE. However, I refuse to learn a new language just so that I can do things the Microsoft Way (TM). Portability is really not as big of an issue as Sun would like us to believe (Have you ever actually tried to port a J2EE app from one app server to another? Let alone one system architecture to another!?!) Still, J2EE offers some things that .NET doesn't (i.e. better support for persistence, distributed apps that don't rely on web services, distributed transaction support that doesn't rely on proprietary database server technologies, JSP Model 2 for web apps is a much stronger separation of concerns than ASP provides - XML/XSLT is not always the best solutions, etc.)
Perhaps instead it is the process. There doesn't tend to be as much Big Design Up Front (BDUF) in open source projects as in many commercial projects. The development process for OSS is either driven primarily by a single project lead or a small group of committers rather than a requirements gathering/business analysis team like at many software firms. Thus the process is more fluid and code oriented. If design flaws occur it is usually due to lack of vision of the project as a whole and not due to programmers misunderstanding business people's requirement documents (Which often seem written explicitly to elicit misunderstanding, IMO)
Don't blame the cops. Some are good, some are bad - just like everyone else. They are not the problem. The problem is the lawmakers and administrations who try to create rules to dictate morality and/or earn extra cash. Neither of these is a good use for the law. Laws should mitigate the risk of harm to the general public, and/or seek restitution for actual harm done to persons or institutions through intentional action or inaction. Very few laws do these things. Most just waste our time, take from the poor and give to the rich, enforce someone else's standard of morality (Such as the good old "war on drugs" or censorship.) If lawmakers would stop stealing our money and wasting our time with frivilous rulemongering then the cops might actually have an opportunity to "protect and serve" rather than acting as glorified paramilitary drug enforcers.
I suppose I agree to a point, but I am not sure how much of a problem this actually is. First, if government software is derived from GPL software then it must be GPL software. Doing this may actually save a lot of money in some cases. Second, if government employees are collaborating with GPL project committers to make that GPL software work for their needs then I don't see a problem. This may save a lot of money as well. So, the only case where I see this as being relevant is when ORIGINAL government works are released as GPL. I am not sure how often this happens, but I can see the argument for government created works being public domain (or purely closed source for security reasons, but even that excuse is often dubious.)