Have you read the previous story about that? Stealing a TV series from a store can get you one year and a max fine of 100,000$. Downloading and sharing the second season of Alias, all 22 episodes, can get you that plus around 3,300,000$ because of various laws related to distribution and filesharing, like the NET act.
Well, I believe that for "enrichment crimes" (economical crimes? please excuse my poor English) the fine should be:
profit*2 ---------------------- chance of discovery
And no prison time. But then I am one of those crazy people who don't believe people should speed and so forth.
I never bought the argument that nobody is deprived of anything. If you think somebody is deprived of something when you are downloading a movie, then it is theft.
I do admit that determining when somebody is deprived of something is not easy. If I, eh, appropriate a hat from a headless person, did I steal the hat? (Example intentionally silly)
But that's not the point. The point is that MQseries fans will tell you that "MQSeries will either deliver you message or give an error", which is only correct if "delivered" includes delivery to the dead letters queue. Which is no great feat, IMHO. Strike that phrase, and MQSeries is just another bloated messaging suite. But at least it would be an honest system, and probably the only one that can run on Z/OS in MVS mode.
I can store-and-forward. Don't get me wrong: It's a fine product, for a commercial one, but it's not THAT fantastic. The delivery garantee is, e.g., worthless. It only states that if it can, it will deliver. Much as with sendmail and friends.
<sarcasm>Really hard to do, if it is meant in the MQSeries way.</sarcasm> If MQSeries can't deliver a message, it puts it on a dead.letters.queue. I am not impressed.
So in essence you are saying that whenever someone creates anything with the intent of creating art, that something would be art, and vice versa.
Let us say that I come across an painting by someone who is now dead, and never expressed if that painting was meant to be art or not. By your definition, there would be no way to know if that painting was art. How unfortunate:)
But if you can create something that has meaning - even if that meaning is not immediately obvious) -, or that grabs the audience's attention (and you intended doing that), you create art.
That would seem to include a baby wailing to me:-P
Has meaning?
Yes. The meaning is "I'm unhappy", obviously.
Grabs audience attention
Yes. Hard to ignore
Intentional
You bet!
Offhand, a siren (not the seamen luress) an exploding bomb and fireworks all would fall into this definition
An illustration of a flower, e.g., would fail the "grab audience attention" and certianly the "has meaning" criteria.
I hereby officially fail this definition by invoking the principle of least surprise.
TCPA is the simplest system imaginable. The OS has nothing to do except throw a flag when a binary loads. That's it. Everything else is handled by the Nexus (security co-processor). Literally, it's the simplest possible design.
And how do I know that the OS does not load a malicious program? The OS itself is untrustworthy, if that bit is the entire protection. So the security nexus would have to keep a checksum of the trusted programs or use a similar technique. Who updates those checksums?
No, the only way to do what you suggest (and what is in the articles) is for the entire application chain to be valid, forming a trusted chain all the way back: The CPU->BIOS->Bootloader->OS->drivers->(trusted) application. And that is a really complex, bug-prone system.
A TCPA enabled program and other programs can seemlessly co-exisit (though no co-mingle data and memory, like typically is seen now), without modification.
True enough, if rather irrelevant.
You can argue this all day, up and down the river, but you'll still be wrong. TCPA is good in that it insulates the software developer from worrying about bugs in the operating system or other applications or even firmware. When your data *really* needs to be secure you can't trust MS, or a linux distro or Solaris or even AIX. It's an added expense.
Even AIX? You've got to be pulling my tail.
Anyway, don't take it from me. Read some of the other comments, search the net, check your sources. You will reach the same conclusions.
If you rely only on software for your heavy duty security needs you will be disappointed. A bug, a flaw in the software at any point will render the system open to attack. A simple hardware co-processor that transparently encrypts and seperates "marked" binaries and data into seperate virtual "slots" is a very simple design, with a mathematically provable end-point. An operating system with 5-10 million lines of code - like a trimmed down linux box cannot even provide that.
But that design will yield you nothing at all. You still will need to communicate with this coprocessor, which will open your little coprocessor like a can of sardines.
If you don't believe me, write me a usecase, and I will break you design.
At best you add another layer, and a layer that is hard to upgrade when security flaws are found. Even the cryptopgraphy itself is complex enough that you will have bugs. And a simple cryptographic coprocessor (like the one on the IBM Z-series) is but a little piece of the misnamed "trusted" computing.
You would be creating a hugely complex, user-unfriendly system which would not help against the most common ways to harvest passwords (which I assume would be the keyloggers job, if we are taking software keyloggers.)
Much simpler to look in command histories for mistypes, creating fake websites, social engineering a so forth.
And not trusting the admin can be handled in software --- e.g. by sudo+friend and no root users at all. Simpler, tried and true. You would have all the protection a TCPA system would give, except simpler system=fewer bugs.
I'm sorry if the idea of a keylogger doesn't freak you out, but it should.
It should, indeed. And you precious "Trusted" (by who?) computing will not help you. Current keyloggers do not change one bit of software. It would be rather difficult to design a keyboard that would be proof against recording the keystrokes.
One obvious kind of tampering that this keyboard should be able to resist would be to install a small camera and a storage device, to be picked up later.
From a consumer angle, trusted computing is only good for two things as far as I can see:
providing a storage facility for keys and the like, which then have 1 (one) additional layer of security.
preventing viral infection of the OS.
2. is, as you might know, a non-issue for all operating systems currently in use in PC, bar Windows and DOS. 1. is just plain silly: It would be dead-easy to provide the same functionality with a small network-enabled device, with less complexity=fewer bugs.
bug won't exist forever in Linux since linux programmer aren't CEO like in M$ where money is their main motivation (which makes their programmer spend more time on features than fixing bugs, leading to bugs not fixed for months). they WILL patch a system asap so this won't be an issue.
I have seen repeatedly that this just isn't the case. Often bugs get ignored until it is released into the public, after which it is quickly closed. If you doubt me, try searching the Mozilla bug database after security bugs. Their policy was 3 months before the bug was made public.
Openness is the only way. It is my uncomfortable experince. Sorry.
Depends on your Karma, or something. Every month I encounter a blue screen of death sitting by one of my colleagues. (Windows experience (good name!) and 2000 (poor name!) ). And in just under a year of using windows on my working computer, the thing refused to boot --- safe mode or no.
Well, I have no time for fighting the OS. Installed first SuSE (which was crappy), then Debian (which needed a crucial package, libc6.1 or something) and finally stuck with Mandrake. NOW it works. The things we have to do...:)
Unfortunately, I cannot dig up the change rate in murders for either country. Perhaps you have a source?
Remember, the crime rates says nothing about the impact. Guns or no guns have little bearing on thieving, embezzling and common violence. In fact, I would expect an increase in violence since the violent people beat each other up instead of shooting them:)
Also, it takes a lot of time before gun bans works for the positive side. In the beginning, there is still plenty loose guns in the hands of the shady folk. It takes a lot of time before those guns disappears.
All in all, this is not a simple issue. But in my little country, there are so few guns that they are restricted to the sort of criminal activity that generates a lot of money --- drug import and distribution, that sort of thing. This means that when people get shot, it is usually with paint guns or other toys. I prefer it that way.
How about outlawing guns to stop people from committing murder? Not only is in ineffective in its goal, but it takes rights away from the innocent
Try to look up murders/population for a gun-ban country and a non-ditto. You might learn something:)
Then check on the accident rate of gun owners and their children. You might learn something.
In fairness, most gun-ban countries do not ban gun as such. They require you to hold a license, which you have to apply for. I do not think it is very difficult to obtain such a license, but I believe you have to go through some formal training in handling your firearms.
Guns are dangerous tools, and should be treated as such. Just like explosives, radioactive substances, planes, container ships... the list goes on. Could I, in the US, legally stack a few tonnes of dynamite in my apartment? Should I be allowed to?
True, I thought you meant strings as in string objects.
Still, the above limitation is not a serious one, and it is a small price for not being bound to a single string implementation.
It would be nice, though, to have support for some type for compiler-time generated objects. As a special case, that would fix the above (and so much else)
Not to mention cleaning core dumps if you ever touch a lego the wrong way. *Smile* Yes, I am afraid I wouldn't be a programmer if either of these languages were my first experience. If "good "+"day" doesn't append two strings, there is just something unhealthy about it.
Ah, you want C++ string (std::string) then. Or rather, you want operator overloading then, so that you can add, multiply or whatever anything you like.
Sorry, just couldn't resist:)
(And to stop the flames: C standard strings are severely broken, I agree. Consider them legacy and forget about them.)
First, let me make it crystal clear that I have always used the separate.cpp and.h files for C++ (and C) since the beginning, and still do.
Why have the.h files? Several reasons. First off- if you #include the code directly, you end up with multiple copies of functions in your executable. In big projects this can be significant space.
Good argument, but completely wrong:) There would be only one compile unit, and the header guards would remove any duplicates. This is why it works with templates, BTW.
Secondly, it allows you to hide implementation details. You have some things declared in the.h and some in the.c. The.c things are similar to private class members- the outside files can't access them directly. There is no way to do this with a directly include the source method.
If the methods are declared private, then that's it. If not, nothing prevents you from calling them, though you may have to steal the prototype from the implementation file. The only exception is global function that are declared static --- those can't be called outside the compilation unit. Not exactly a huge impact.
Third, its cleaner and easier to read. If I want to knopw what functionality a module implements, I read a.h or two. Parsing that info from the.c file would be difficult and time consuming.
That is very true, though the difference between two separate files and having the implementation at the bottom of the header file is rather minimal. Also, interestingly, the Java people have always inlined the entire thing in the "class" file, and I haven't heard them complaining. So maybe it is just habit (?).
As for your other thought- why would you want to do that? Writing the class declaration takes maybe.1% of the time writing the functionality takes. And writing the declaration usually gives you time to think things through and make sure you have things the way you want them, as well as serving as documentation of the interface. A script that auto generated it would be very little to no gain, and in many ways a loss.
Well, I write the class definition, press a key and have XEmacs generate the implementation file stub. So I don't get time to think, and I get annoyed at having to sync the two files whenever I change something. I believe it is the latter that annoys people, not the initial work, which most IDE can do automatically anyway.
Interestingly, you didn't touch on another point: With multiple compile units, you don't have to recompile the entire thing every time you touch anything. As a KDE developer, I can certainly appreciate that!
Also, having two classes depend on each other would certainly be harder (though not impossible).
Slashdot Mirror
You mean, way to go KDE, thanks Apple for contributing. Konqueror is not half bad, even if it's scripting speed is poor, as confirmed by the article.
Well, I believe that for "enrichment crimes" (economical crimes? please excuse my poor English) the fine should be:
And no prison time. But then I am one of those crazy people who don't believe people should speed and so forth.
I never bought the argument that nobody is deprived of anything. If you think somebody is deprived of something when you are downloading a movie, then it is theft.
I do admit that determining when somebody is deprived of something is not easy. If I, eh, appropriate a hat from a headless person, did I steal the hat? (Example intentionally silly)
I believe most people do think that killing and pillaging is not right.
I even think most people think that stealing movies online is not right.
In those cases it could give an error.
But that's not the point. The point is that MQseries fans will tell you that "MQSeries will either deliver you message or give an error", which is only correct if "delivered" includes delivery to the dead letters queue. Which is no great feat, IMHO. Strike that phrase, and MQSeries is just another bloated messaging suite. But at least it would be an honest system, and probably the only one that can run on Z/OS in MVS mode.
I can store-and-forward. Don't get me wrong: It's a fine product, for a commercial one, but it's not THAT fantastic. The delivery garantee is, e.g., worthless. It only states that if it can, it will deliver. Much as with sendmail and friends.
<sarcasm>Really hard to do, if it is meant in the MQSeries way.</sarcasm> If MQSeries can't deliver a message, it puts it on a dead.letters.queue. I am not impressed.
So in essence you are saying that whenever someone creates anything with the intent of creating art, that something would be art, and vice versa.
Let us say that I come across an painting by someone who is now dead, and never expressed if that painting was meant to be art or not. By your definition, there would be no way to know if that painting was art. How unfortunate :)
That would seem to include a baby wailing to me :-P
Has meaning? Yes. The meaning is "I'm unhappy", obviously. Grabs audience attention Yes. Hard to ignore Intentional You bet!Offhand, a siren (not the seamen luress) an exploding bomb and fireworks all would fall into this definition
An illustration of a flower, e.g., would fail the "grab audience attention" and certianly the "has meaning" criteria.
I hereby officially fail this definition by invoking the principle of least surprise.
And how do I know that the OS does not load a malicious program? The OS itself is untrustworthy, if that bit is the entire protection. So the security nexus would have to keep a checksum of the trusted programs or use a similar technique. Who updates those checksums?
No, the only way to do what you suggest (and what is in the articles) is for the entire application chain to be valid, forming a trusted chain all the way back: The CPU->BIOS->Bootloader->OS->drivers->(trusted) application. And that is a really complex, bug-prone system.
True enough, if rather irrelevant.
Even AIX? You've got to be pulling my tail.
Anyway, don't take it from me. Read some of the other comments, search the net, check your sources. You will reach the same conclusions.
But that design will yield you nothing at all. You still will need to communicate with this coprocessor, which will open your little coprocessor like a can of sardines.
If you don't believe me, write me a usecase, and I will break you design.
At best you add another layer, and a layer that is hard to upgrade when security flaws are found. Even the cryptopgraphy itself is complex enough that you will have bugs. And a simple cryptographic coprocessor (like the one on the IBM Z-series) is but a little piece of the misnamed "trusted" computing.
You would be creating a hugely complex, user-unfriendly system which would not help against the most common ways to harvest passwords (which I assume would be the keyloggers job, if we are taking software keyloggers.)
Much simpler to look in command histories for mistypes, creating fake websites, social engineering a so forth.
And not trusting the admin can be handled in software --- e.g. by sudo+friend and no root users at all. Simpler, tried and true. You would have all the protection a TCPA system would give, except simpler system=fewer bugs.
It should, indeed. And you precious "Trusted" (by who?) computing will not help you. Current keyloggers do not change one bit of software. It would be rather difficult to design a keyboard that would be proof against recording the keystrokes.
One obvious kind of tampering that this keyboard should be able to resist would be to install a small camera and a storage device, to be picked up later.
From a consumer angle, trusted computing is only good for two things as far as I can see:
2. is, as you might know, a non-issue for all operating systems currently in use in PC, bar Windows and DOS. 1. is just plain silly: It would be dead-easy to provide the same functionality with a small network-enabled device, with less complexity=fewer bugs.
I have seen repeatedly that this just isn't the case. Often bugs get ignored until it is released into the public, after which it is quickly closed. If you doubt me, try searching the Mozilla bug database after security bugs. Their policy was 3 months before the bug was made public.
Openness is the only way. It is my uncomfortable experince. Sorry.
It's allegedly quite common among the blind....
If I recall correctly, this is the same as MySQL, at least for TCP/IP connections --- you have to explicitly grant access for anything to connect.
Locally, I can't remember how the root user is created. But I remember the repeated "Please set your MySQL root password now" after emerging :)
Yeah, the Debian thing could probably be fixed, probably by using some unofficial package source or something. I needed it to install db2.
I just didn't want to go there. Going for unofficial sources is just asking for trouble.
Me, too :) I was very impressed with the time it took to compile KDE.
Depends on your Karma, or something. Every month I encounter a blue screen of death sitting by one of my colleagues. (Windows experience (good name!) and 2000 (poor name!) ). And in just under a year of using windows on my working computer, the thing refused to boot --- safe mode or no.
Well, I have no time for fighting the OS. Installed first SuSE (which was crappy), then Debian (which needed a crucial package, libc6.1 or something) and finally stuck with Mandrake. NOW it works. The things we have to do... :)
Wish it could have been Gentoo.
Unfortunately, I cannot dig up the change rate in murders for either country. Perhaps you have a source?
Remember, the crime rates says nothing about the impact. Guns or no guns have little bearing on thieving, embezzling and common violence. In fact, I would expect an increase in violence since the violent people beat each other up instead of shooting them :)
Also, it takes a lot of time before gun bans works for the positive side. In the beginning, there is still plenty loose guns in the hands of the shady folk. It takes a lot of time before those guns disappears.
All in all, this is not a simple issue. But in my little country, there are so few guns that they are restricted to the sort of criminal activity that generates a lot of money --- drug import and distribution, that sort of thing. This means that when people get shot, it is usually with paint guns or other toys. I prefer it that way.
Try to look up murders/population for a gun-ban country and a non-ditto. You might learn something :)
Then check on the accident rate of gun owners and their children. You might learn something.
In fairness, most gun-ban countries do not ban gun as such. They require you to hold a license, which you have to apply for. I do not think it is very difficult to obtain such a license, but I believe you have to go through some formal training in handling your firearms.
Guns are dangerous tools, and should be treated as such. Just like explosives, radioactive substances, planes, container ships... the list goes on. Could I, in the US, legally stack a few tonnes of dynamite in my apartment? Should I be allowed to?
While sound advice (I'd put "Don't go below 512Mb memory in there, too) there is a common exception on Slashdot.
compiling (especially C++)
I was rather impressed by the Athlon64 compiling speed.
True, I thought you meant strings as in string objects.
Still, the above limitation is not a serious one, and it is a small price for not being bound to a single string implementation.
It would be nice, though, to have support for some type for compiler-time generated objects. As a special case, that would fix the above (and so much else)
Then, for heavens sake, go find a decent C string library. There are a few :-D
Or use some other language than C. Like C++. Or python ;-)
Ah, you want C++ string (std::string) then. Or rather, you want operator overloading then, so that you can add, multiply or whatever anything you like.
Sorry, just couldn't resist :)
(And to stop the flames: C standard strings are severely broken, I agree. Consider them legacy and forget about them.)
First, let me make it crystal clear that I have always used the separate .cpp and .h files for C++ (and C) since the beginning, and still do.
Good argument, but completely wrong :) There would be only one compile unit, and the header guards would remove any duplicates. This is why it works with templates, BTW.
If the methods are declared private, then that's it. If not, nothing prevents you from calling them, though you may have to steal the prototype from the implementation file. The only exception is global function that are declared static --- those can't be called outside the compilation unit. Not exactly a huge impact.
That is very true, though the difference between two separate files and having the implementation at the bottom of the header file is rather minimal. Also, interestingly, the Java people have always inlined the entire thing in the "class" file, and I haven't heard them complaining. So maybe it is just habit (?).
Well, I write the class definition, press a key and have XEmacs generate the implementation file stub. So I don't get time to think, and I get annoyed at having to sync the two files whenever I change something. I believe it is the latter that annoys people, not the initial work, which most IDE can do automatically anyway.
Interestingly, you didn't touch on another point: With multiple compile units, you don't have to recompile the entire thing every time you touch anything. As a KDE developer, I can certainly appreciate that!
Also, having two classes depend on each other would certainly be harder (though not impossible).