This is orthogonal to having it open sourced, though. No-one is using the original K&R C, for example, but its source has been released, and adds to that nostalgic value.
Heck, you can even find source for BCPL (actively maintained even!), and for various ancient Algol-60 implementations from back in the day.
I used both for their stated purpose (RAD, aka quickly duck-tape a bunch of shit together) back when they were popular, and knew a few people who used either.
The learning curve was actually pretty similar for both. Pascal is a more rigid language, but it's also more regular, and so easier to pick up. It also had more verbiage (e.g. you had to explicitly connect handlers to events, whereas in VB it would be implicit based on handler name), but the visual designers took care of all that stuff for you.
On the other hand, once you ventured into more advanced stuff - e.g. anything requiring working directly with Win32 API - Delphi was hands down better. It also had a full-fledged class and object system, unlike VB (which had classes, but no inheritance - only interfaces). Basically, it had way more room to grow into.
Overall, though, the popularity of either depended largely on geography - some markets had VB dominate (e.g. US), others had Delphi dominate (e.g. Europe and Russia). Once there was a critical mass established in either, everyone else just stuck to it as a de facto standard.
Given that VB would happily try to implicitly convert pretty much everything to everything in any context where it was even remotely plausible, those type declarations didn't do as much good as one would expect.
Like I said, your definition simply doesn't conform to practical usage, at least not here in US. The fact that German and English languages are related is completely irrelevant - the exact meaning of the word "protocol" specifically in CS/IT is a recent thing, and does not have to correspond to the past meaning, especially in its details. And, of course, the term "API" is a complete neologism, and so its meaning is purely invented.
I think your problem is that you're talking about API in the context of some language or the other (C, C++, Java etc). Stop for a moment, and think about what language context you would use for a typical RESTful Web API today.
I have to disagree. In my understanding, "you have to call open() before you call read()" is part of an API. Basically, an API is not just a bunch of function declarations - it's also the description of semantics of those functions, their contracts, invariants, dependencies etc.
And I also have to add that this definition is the one that I have seen used pretty much everywhere else.
So I don't know why yours is different - perhaps it's a German thing? - but it's definitely far from universal.
You make it more complicated than it needs to be. The protocol is any set of rules that describe how two components in a system communicate. An API is a subset of a protocol - it's also a set of rules that describe how two components communicate, it just happens to have a more formal language of describing them.
So, for example, if I have an app that allows plugins, the communication between the app and the plugin is a protocol, and in most cases that protocol is an API. There's no way to have "other APIs implement that protocol".
You're also wrong that you can't have plenty of protocols behind one API. There are many libraries that do exactly that - wrap various different protocols that ultimately do similar things, and present a single unified interface to all those things. For example, there are libraries that abstract away various cloud storage protocols (AWS, Azure, Rackspace etc). Or the ultimate example of them all, "everything is a file" on Unix - files (and specifically system calls like open, read, write etc) are an API, but the underlying protocols can involve NFS, SMB, FTP, SFTP and many others.
The distinction between protocols in general and APIs has been getting more blurry of late, too. For example, we talk about REST APIs on the web - but such an API is not tied to any language, and is really just a higher-level protocol on top of HTTP (describing the meaning of the payload).
The problem is the same one that was stated originally - the sheer amount of laws in that area, and the fact that they're written in a way that is very hard to understand and parse (i.e. is not "common sense"), and at times very vague. For gun laws, for example, ATF itself has repeatedly made conflicting rulings on various aspects in the past, literally based on a slight change in the implied meaning of some word (like "possession" or "manufacture").
Also, with cars, we at least force people to learn the rules by licensing the activity and predicating the license on training. With all this other stuff, it is not the case. If you're a buying a bubble pack radio, it is not at all obvious that it requires a license to operate (especially since it's not the case for all such radios, and in some cases depends on which channels you transmit on), and that there's a large body of laws regulating such operation that you need to be well acquainted with.
Your approach would mean that literally every time you engage in some activity - any activity - you need to consult the laws to determine if any apply. Which brings us back to the original point - there are so many laws in effect that rigorously implementing this approach is unfeasible for an individual in a modern society - we'd spend all of our time reading laws. The end result is that many people do break laws unintentionally in the course of their routine activities, and the majority that does not, doesn't do so by accident rather than knowledge. It is not really an acceptable state of affairs.
There are many areas where the laws are extremely convoluted, and apply the moment you step your foot there, even unknowingly.
For example, if you go and buy a GMRS radio on Amazon (where they're readily available and advertised as walkie talkies), and actually try to use it, you're violating FCC regulations, because the use of GMRS requires a license.
Or, say, gun laws. Buying a gun is easy (if you're not a felon already), but installing an innocuously looking gadget on it (for example, a vertical forward grip on a pistol) can instantly turn it into a highly restricted firearm that requires a license or a tax stamp to "manufacture", and violation of that law can land you in prison for 10 years.
Problem is, who determines whether an expert witness is indeed an expert?
I mean, we're currently seeing whole large areas of forensics being demonstrated to be built on outright lies. Yet, before that, plenty of "experts" testified that they were certain that such-and-such has committed a crime because their teeth marks matched, or their hair matched - and juries have delivered guilty verdicts based on such testimony, with no-one the wiser.
Actually, prostitution was often legal throughout history, even in societies where it was reviled. In 19th century, it was frequently regulated, with prostitutes required to register and have a license, for which they had to undergo medical checks. For example, here is such a license (which also doubles as health exam log book) for a Russian prostitute, issued in 1904.
It depends on the level of impairment. Different people require different amounts to become truly drunk. But once you get there, the reaction is universal: truly drunk people don't really understand that they're impaired, and will make decisions based on that incorrect assessment.
Other nations haven't moved to the left nearly to the extent that US has moved to the right. The proof is in the pudding - forget other countries, just take any Republican candidate from 20 years ago, and compare their platform to what GOP peddles today.
you find that the documents do not exist until the encrypted data is combined with the decryption key; that view provides even an even stronger case for fifth amendment protection, as in this view the defendant is being required to _create_ the evidence against him.
It is a potentially interesting angle, but I doubt it would fly. It would mean that any and all laws that make some information illegal would cease to apply the moment it is encrypted, because it is "no longer there" (and later it magically reappears when the key is applied). This could be stretched even further by saying that e.g. compression is also similar, in that the output is not directly usable; and the compression code is the "key".
This would then apply across the board: copyright, national secrets etc. So for example if a guy steals some top secret data, encrypts it, and hands it over to Chinese in two separate transactions - one for the data, and the other for the key - it would seem that nothing illegal has occurred, because the data in its encrypted form is not top secret - only the decryption output would be, and it doesn't exist until encrypted data and key are combined in a very specific way.
Somehow, I doubt that this will work out that way.
A demand to produce the body would still fall under the scope of the Fifth, because knowing where the body is would be incriminating in and of itself.
What wouldn't be is if, say, the police reasonably suspects that a body is locked in a specific place, to demand a key to that place. Surrendering the key is not producing the body - it is only allowing the door to be open. It is not illegal to lock a door, so the fact that one has the key is not illegal. And there is no demand to produce the contents - police will go and obtain it on their own, once they have access to it.
SCOTUS hasn't ruled on this one way or the other, so it remains to be seen.
The problem is that "contempt" is a separate thing. Being held in contempt doesn't mean that you're guilty of anything, so the usual innocent-unless-proven-guilty standard doesn't apply. I'm actually not sure what the standard is for contempt, and in particular, what the checks and balances are (i.e. if he believes that judge is holding him in contempt improperly, can he appeal it, and to whom?).
Per the All Writs Act, they can compel cooperation with the investigation in general. The Fifth says specifically:
"nor shall be compelled in any criminal case to be a witness against himself"
And he is not asked to be a witness against himself (i.e. he is not asked to confess). He is asked to provide a piece of information that, in and of itself, does not testify to his guilt. He's asked to provide information that can then be used to access other information, which may provide evidence of his guilt - but at the point that information is retrieved, he's no longer in the picture, and so it does not involve him witnessing against himself.
Yes, so they must have a reasonable suspicion that there is evidence related to the crime. Which they did (witness accounts that he showed them things off that laptop).
And then they must go to the judge, and get a warrant to search the drive. Which they did.
And now this guy is basically refusing to comply with said legitimate warrant, for which he is held in contempt by the judge.
This is not at all similar to "pick any house at random and search it for whatever they suspect might be in there".
Slashdot Mirror
Do you have any references or citations for that? I tried to search the quoted phrase, but nothing relevant comes up.
This is orthogonal to having it open sourced, though. No-one is using the original K&R C, for example, but its source has been released, and adds to that nostalgic value.
Heck, you can even find source for BCPL (actively maintained even!), and for various ancient Algol-60 implementations from back in the day.
If nothing else, that stuff has historical value.
Not In VB, We'Re Not.
He said "two lines", not "two versions". VB/DOS was the last version in both lines, merging the two.
I used both for their stated purpose (RAD, aka quickly duck-tape a bunch of shit together) back when they were popular, and knew a few people who used either.
The learning curve was actually pretty similar for both. Pascal is a more rigid language, but it's also more regular, and so easier to pick up. It also had more verbiage (e.g. you had to explicitly connect handlers to events, whereas in VB it would be implicit based on handler name), but the visual designers took care of all that stuff for you.
On the other hand, once you ventured into more advanced stuff - e.g. anything requiring working directly with Win32 API - Delphi was hands down better. It also had a full-fledged class and object system, unlike VB (which had classes, but no inheritance - only interfaces). Basically, it had way more room to grow into.
Overall, though, the popularity of either depended largely on geography - some markets had VB dominate (e.g. US), others had Delphi dominate (e.g. Europe and Russia). Once there was a critical mass established in either, everyone else just stuck to it as a de facto standard.
Given that VB would happily try to implicitly convert pretty much everything to everything in any context where it was even remotely plausible, those type declarations didn't do as much good as one would expect.
Like I said, your definition simply doesn't conform to practical usage, at least not here in US. The fact that German and English languages are related is completely irrelevant - the exact meaning of the word "protocol" specifically in CS/IT is a recent thing, and does not have to correspond to the past meaning, especially in its details. And, of course, the term "API" is a complete neologism, and so its meaning is purely invented.
I think your problem is that you're talking about API in the context of some language or the other (C, C++, Java etc). Stop for a moment, and think about what language context you would use for a typical RESTful Web API today.
I have to disagree. In my understanding, "you have to call open() before you call read()" is part of an API. Basically, an API is not just a bunch of function declarations - it's also the description of semantics of those functions, their contracts, invariants, dependencies etc.
And I also have to add that this definition is the one that I have seen used pretty much everywhere else.
So I don't know why yours is different - perhaps it's a German thing? - but it's definitely far from universal.
You make it more complicated than it needs to be. The protocol is any set of rules that describe how two components in a system communicate. An API is a subset of a protocol - it's also a set of rules that describe how two components communicate, it just happens to have a more formal language of describing them.
So, for example, if I have an app that allows plugins, the communication between the app and the plugin is a protocol, and in most cases that protocol is an API. There's no way to have "other APIs implement that protocol".
You're also wrong that you can't have plenty of protocols behind one API. There are many libraries that do exactly that - wrap various different protocols that ultimately do similar things, and present a single unified interface to all those things. For example, there are libraries that abstract away various cloud storage protocols (AWS, Azure, Rackspace etc). Or the ultimate example of them all, "everything is a file" on Unix - files (and specifically system calls like open, read, write etc) are an API, but the underlying protocols can involve NFS, SMB, FTP, SFTP and many others.
The distinction between protocols in general and APIs has been getting more blurry of late, too. For example, we talk about REST APIs on the web - but such an API is not tied to any language, and is really just a higher-level protocol on top of HTTP (describing the meaning of the payload).
And? Do you have problem designing your own APIs instead of starting design with a competitors' APIs and modifying it?
Yes. The name of that problem is "interoperability".
The problem is the same one that was stated originally - the sheer amount of laws in that area, and the fact that they're written in a way that is very hard to understand and parse (i.e. is not "common sense"), and at times very vague. For gun laws, for example, ATF itself has repeatedly made conflicting rulings on various aspects in the past, literally based on a slight change in the implied meaning of some word (like "possession" or "manufacture").
Also, with cars, we at least force people to learn the rules by licensing the activity and predicating the license on training. With all this other stuff, it is not the case. If you're a buying a bubble pack radio, it is not at all obvious that it requires a license to operate (especially since it's not the case for all such radios, and in some cases depends on which channels you transmit on), and that there's a large body of laws regulating such operation that you need to be well acquainted with.
Your approach would mean that literally every time you engage in some activity - any activity - you need to consult the laws to determine if any apply. Which brings us back to the original point - there are so many laws in effect that rigorously implementing this approach is unfeasible for an individual in a modern society - we'd spend all of our time reading laws. The end result is that many people do break laws unintentionally in the course of their routine activities, and the majority that does not, doesn't do so by accident rather than knowledge. It is not really an acceptable state of affairs.
There are many areas where the laws are extremely convoluted, and apply the moment you step your foot there, even unknowingly.
For example, if you go and buy a GMRS radio on Amazon (where they're readily available and advertised as walkie talkies), and actually try to use it, you're violating FCC regulations, because the use of GMRS requires a license.
Or, say, gun laws. Buying a gun is easy (if you're not a felon already), but installing an innocuously looking gadget on it (for example, a vertical forward grip on a pistol) can instantly turn it into a highly restricted firearm that requires a license or a tax stamp to "manufacture", and violation of that law can land you in prison for 10 years.
Problem is, who determines whether an expert witness is indeed an expert?
I mean, we're currently seeing whole large areas of forensics being demonstrated to be built on outright lies. Yet, before that, plenty of "experts" testified that they were certain that such-and-such has committed a crime because their teeth marks matched, or their hair matched - and juries have delivered guilty verdicts based on such testimony, with no-one the wiser.
Actually, prostitution was often legal throughout history, even in societies where it was reviled. In 19th century, it was frequently regulated, with prostitutes required to register and have a license, for which they had to undergo medical checks. For example, here is such a license (which also doubles as health exam log book) for a Russian prostitute, issued in 1904.
Why is it a problem?
It depends on the level of impairment. Different people require different amounts to become truly drunk. But once you get there, the reaction is universal: truly drunk people don't really understand that they're impaired, and will make decisions based on that incorrect assessment.
Other nations haven't moved to the left nearly to the extent that US has moved to the right. The proof is in the pudding - forget other countries, just take any Republican candidate from 20 years ago, and compare their platform to what GOP peddles today.
you find that the documents do not exist until the encrypted data is combined with the decryption key; that view provides even an even stronger case for fifth amendment protection, as in this view the defendant is being required to _create_ the evidence against him.
It is a potentially interesting angle, but I doubt it would fly. It would mean that any and all laws that make some information illegal would cease to apply the moment it is encrypted, because it is "no longer there" (and later it magically reappears when the key is applied). This could be stretched even further by saying that e.g. compression is also similar, in that the output is not directly usable; and the compression code is the "key".
This would then apply across the board: copyright, national secrets etc. So for example if a guy steals some top secret data, encrypts it, and hands it over to Chinese in two separate transactions - one for the data, and the other for the key - it would seem that nothing illegal has occurred, because the data in its encrypted form is not top secret - only the decryption output would be, and it doesn't exist until encrypted data and key are combined in a very specific way.
Somehow, I doubt that this will work out that way.
A demand to produce the body would still fall under the scope of the Fifth, because knowing where the body is would be incriminating in and of itself.
What wouldn't be is if, say, the police reasonably suspects that a body is locked in a specific place, to demand a key to that place. Surrendering the key is not producing the body - it is only allowing the door to be open. It is not illegal to lock a door, so the fact that one has the key is not illegal. And there is no demand to produce the contents - police will go and obtain it on their own, once they have access to it.
SCOTUS hasn't ruled on this one way or the other, so it remains to be seen.
No, since the information that he's asked to provide is not incriminating in and of itself.
The problem is that "contempt" is a separate thing. Being held in contempt doesn't mean that you're guilty of anything, so the usual innocent-unless-proven-guilty standard doesn't apply. I'm actually not sure what the standard is for contempt, and in particular, what the checks and balances are (i.e. if he believes that judge is holding him in contempt improperly, can he appeal it, and to whom?).
He's not incriminating himself by making a statement that he knows the password.
Per the All Writs Act, they can compel cooperation with the investigation in general. The Fifth says specifically:
"nor shall be compelled in any criminal case to be a witness against himself"
And he is not asked to be a witness against himself (i.e. he is not asked to confess). He is asked to provide a piece of information that, in and of itself, does not testify to his guilt. He's asked to provide information that can then be used to access other information, which may provide evidence of his guilt - but at the point that information is retrieved, he's no longer in the picture, and so it does not involve him witnessing against himself.
No, they still require a warrant (although they can - and too often do - get a no-knock warrant, which is a whole different problem).
Yes, so they must have a reasonable suspicion that there is evidence related to the crime. Which they did (witness accounts that he showed them things off that laptop).
And then they must go to the judge, and get a warrant to search the drive. Which they did.
And now this guy is basically refusing to comply with said legitimate warrant, for which he is held in contempt by the judge.
This is not at all similar to "pick any house at random and search it for whatever they suspect might be in there".