The author of Plex86 and Bochs is the same guy who declared that VMWare had "ripped off" his idea and gone commercial after looking at his technology. The failure of Plex86 (and that's what this announcement is, an admission of failure) just goes to show that Kevin is and always was full of shit. He's been claiming that Bochs would have a binary translation system (much like VMWare and VirtualPC use) to speed it up ever since back when he was trying to flog it as shareware. So, in response to your question, there is very little fear that Kevin is going to come up with a product that can compete with VMWare (or VirutalPC for that matter) because he's no good.
Re:Was the movie "Takedown" accurate?
on
Ask Kevin Mitnick
·
· Score: 1
I'm pretty much of the opinion that Takedown (the movie) was as accurate a depiction of Kevin's flight from the fbi as one can expect from a movie. I liked the was Tomu was portrayed as someone "just as bad" as Kevin and the opinions expressed by the fbi agent after him was accurate for the time. Technically, the movie was flawed, but it was more accurate than any hacker/computer movie I have ever seen. If you're after a specific bullshit element of the movie, I can simply point at Contempt. Tomu did not write a "super virus/worm" that he was trying to recover from Kevin for the betterment of society -- unfortunately, the reality is not very sexy, Kevin insulted the ego of Tomu by hacking into his machine (Tomu was supposed to be the super-security-expert who actually did testify to congress), so he chased him, violating basically every tenent of unlawful search along the way and breaking as many laws as Kevin was accused of doing. For example, the movie shows Tomu going to Netcom, the service provider Kevin was using. Actually, Tomu just hacked Netcom, the same way Kevin did and searched the confidential customer records looking for him. Kevin used many other machines and Tomu chased him half way across the net, by, yes, hacking. All this time we're supposed to be watching Tomu and saying that's ok, because he's the "good guy" and it doesn't matter who gets in the way of the good guy because he's always virtuous -- never mind the fact that our hero's day job is doing nuclear explosion simulations for the government. On the other hand, the SAS system hacked by Kevin and Lowe at the start of the movie did exist and was a violation of every southern californian's right to privacy and unlawful search and siezure.
But maybe that's what the movie is all about. There are no heros.
VegaStrike is excellent. I recommend to anyone who liked Elite III to give it a go. Actually read the manual before complaining is a good idea however.
assuming you are correct, why are you so opposed to DRM anyways? IF you want 100% control of content on your computer, just don't buy any DRM controlled content. It's still your choice, right?
I personally am not too impressed with the "configuration seal" parts of the chip. Frankly, I could do without that.
Your technique is no better than using a software key as it still requires Windows to prevent access to the keys (which is hackable). DRM can be done entirely in software, it doesn't mean that software was design for DRM.
Don't just shove TCPA in with Palladium. If you actually did some background reading you would understand the problems that TCPA is trying to solve. Alternatively, you could just listen to what rational people say and think. There are full specifications that tell you exactly what the chip does, go read em. Form your own opinion, and be reasonable.
I take offense to your statement that no-one should ever make hardware that targets the Linux market because the "majority of users don't need it".
no, you mean "normal users of windows" which is actually almost offense to me. Most users of Linux make ssh connections all the time. Some of us have even had the misfortune of having our RSA keys stolen. Meanwhile, "normal users" of both Windows and Linux make thousands and thousands of "trusted" connections every day: SSL. And they send insecure little numbers over them: credit cards. TCPA could be used for a secure digital cash system, but it wont happen unless it is ubiquitous.
why do you need to know the private key? So you can give it to someone else? That's stupid, and completely defeats the purpose of asymetrical encryption. As long as the hardware does what you say then you have access to your private key, and that's all you ever need.
Let's stop thinking about Windows for a second, seeing as IBM has presented a bunch of GPL drivers for Linux. On my Linux box, I choose how to use this chip. Instead of running ssh-keygen I run a client program and tell the chip to generate my keys. Then when I want something encrypted with the private key that it has generated I just send it the data and it encrypts it for me. I'm completely in control.
The most obvious use is to authorize my connection to a remote server. If the private key is safely locked away on the chip then I can be assured that only my machine can connect to the remote server with that identity.
Another use would be to sign emails. Again, I can be assured that any email that is signed with a key that is safely locked on the chip could only have been signed by someone using my machine.
In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?
I've always been amused at the claims of how hardware can solve security problems. The suggestion of how to protect authentication using TCPA and, indeed, all other "smartcard" based solutions, is to make sure the private key never leaves the hardware. The idea being that the attacker cannot access a server from any other machine than the one containing the hardware. This is clearly not the case. Suppose you use SSH to access your server at work and, for added protection, you use TCPA to keep your private key. An attacker hacks your client attempting to access to the server at work. All he/she has to do is use your hardware to access the server. At this point the attacker can bypass the authentication by:
Installing a new key;
Installing a back door; or just
Taking what they want
A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.
A standards body, incompetent? Wow, that's never happened before:)
Powerfull GUI interaction + SVG + XML + XSLT + code generation + reverse engineering.... of course that is the dream tool chain
And we can build it one part at a time with each of the parts serving some useful purpose. Seperate tools with agreed interchange formats is the best way to parallelize work.
The point is that the integrated products don't even do 10% of what I want, and they're flaky and slow. By putting together scripts I can build an array of tools that does 80% of what I want and write that last 20% easily.
Every project has different requirements for tools, the idea that you can write one tool that is going to do everything for you in a particular field is rediculous.
Re:Whatever happened to small tools
on
Umbrello 1.1 Released
·
· Score: 2, Insightful
UML can be used as a visualization tool for existing code. As there is a whole lot of code out there that was written before the UML was even beginning to come together, we have a lot of code that needs design recovery and documentation. This is mainly done manually.
Yep. I use UML for program understanding. That's why I'm talking about it in what you would consider the "reverse" way. That's ok. You should still use small tools to perform forward engineering too. You don't integrate your linker into your compiler, so you shouldn't integrate your UML to SVG compiler into your editor.
Fair enough. I chose class diagrams as an example, but the same goes for all UML diagrams that you might want to re-engineer from source code or generate source code for (I'm primarily interested in the former). However, unlike a giant IDE, you can re-use large parts of the tool chain. Sure, you can extend an IDE to include other diagram types, but it means you have to intergrate you code, and therefore it can only be used in one way. Using a tool chain, the tools can be combined together in n*n ways.
Remember the days when unix development was different to windows development? You had a different way of going about things. Under windows you'd fire up the all singing, all dancing VC++ and hack out everything. You had no choice what editor you wanted to use, it's all integrated with the compiler. Under unix you'd fire up vi or emacs or pico or joe or whatever the hell you wanted to use. Then you'd have a choice of compiler too, gcc, sun cc, intel's compiler. If you wanted to find something you could use grep. If you wanted to count those things you'd found you'd use wc. With a small collection of tools you could join them together and perform large tasks -- that's the unix way.
Now we're recognising the use for UML tools, have we taken the unix path or the integrated windows path? Seems the integrated tools are winning. Oh yeah, and there's thousands of them, all in various states of disrepair.
I know this isn't a very convincing argument, but frankly, I shouldn't have to make it: small tools working together is the unix way and we should strive to make our new tools the same way as our old tools.
I recommend the following small tools:
Parse C++ using a general parser, such as Earley's algorithm or Tomita, generate a readable XML parse tree.
Filter parts of the parse tree that are not used in the UML diagram you want to generate, i.e., you don't need code in class diagrams.
Transform the parse tree into a standard UML exchange language.
Transform the UML into scalable vector graphics (SVG) format.
Use open tools to view the resulting SVG file.
Most of these transformations can be done in XSLT. By maintaining XLinks between each of these documents you can navigate from one SVG to another and even effect changes earlier in the pipeline to create an interactive editor.
Even if you have no interest in reverse engineering C++ code the last 2 steps will be of interest to anyone writing another one of those big ass UML editors.
I'm aware of your ftp server. I'm also aware that it is the only one of its kind. Why don't you write some more software and compete to determine which is better.
cause when it comes to comparing Qt to Java Swing/AWT there is simply no comparison. I'll put it to you straight: code one more graphical application in that dog slow language and I will personally ensure that you eat every word you utter about "java performance not really mattering". A gui should respond to a user request in less than 100ms, anything slower and you have written a dog slow application. I submit to you that EVERYTHING written in Java/Swing that has a graphical user interface element does not meet this requirement. Now, can anyone vouch for SWT?
Slashdot Mirror
ie, he's a monkey.
The author of Plex86 and Bochs is the same guy who declared that VMWare had "ripped off" his idea and gone commercial after looking at his technology. The failure of Plex86 (and that's what this announcement is, an admission of failure) just goes to show that Kevin is and always was full of shit. He's been claiming that Bochs would have a binary translation system (much like VMWare and VirtualPC use) to speed it up ever since back when he was trying to flog it as shareware. So, in response to your question, there is very little fear that Kevin is going to come up with a product that can compete with VMWare (or VirutalPC for that matter) because he's no good.
But maybe that's what the movie is all about. There are no heros.
VegaStrike is excellent. I recommend to anyone who liked Elite III to give it a go. Actually read the manual before complaining is a good idea however.
I personally am not too impressed with the "configuration seal" parts of the chip. Frankly, I could do without that.
Your technique is no better than using a software key as it still requires Windows to prevent access to the keys (which is hackable). DRM can be done entirely in software, it doesn't mean that software was design for DRM.
I take offense to your statement that no-one should ever make hardware that targets the Linux market because the "majority of users don't need it".
actually, all the code is GPL, which you'd know if you read the article.
no, you mean "normal users of windows" which is actually almost offense to me. Most users of Linux make ssh connections all the time. Some of us have even had the misfortune of having our RSA keys stolen. Meanwhile, "normal users" of both Windows and Linux make thousands and thousands of "trusted" connections every day: SSL. And they send insecure little numbers over them: credit cards. TCPA could be used for a secure digital cash system, but it wont happen unless it is ubiquitous.
and I don't want their data, so what's the problem? If I want songs I'll just go and get them from all the people who will continue to rip songs.
why do you need to know the private key? So you can give it to someone else? That's stupid, and completely defeats the purpose of asymetrical encryption. As long as the hardware does what you say then you have access to your private key, and that's all you ever need.
The most obvious use is to authorize my connection to a remote server. If the private key is safely locked away on the chip then I can be assured that only my machine can connect to the remote server with that identity.
Another use would be to sign emails. Again, I can be assured that any email that is signed with a key that is safely locked on the chip could only have been signed by someone using my machine.
In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?
A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.
Give it to Hasselhoff all you want but Shatner's singin' is way better than his acting.
Powerfull GUI interaction + SVG + XML + XSLT + code generation + reverse engineering .... of course that is the dream tool chain
And we can build it one part at a time with each of the parts serving some useful purpose. Seperate tools with agreed interchange formats is the best way to parallelize work.
Every project has different requirements for tools, the idea that you can write one tool that is going to do everything for you in a particular field is rediculous.
UML can be used as a visualization tool for existing code. As there is a whole lot of code out there that was written before the UML was even beginning to come together, we have a lot of code that needs design recovery and documentation. This is mainly done manually.
Yep. I use UML for program understanding. That's why I'm talking about it in what you would consider the "reverse" way. That's ok. You should still use small tools to perform forward engineering too. You don't integrate your linker into your compiler, so you shouldn't integrate your UML to SVG compiler into your editor.
Fair enough. I chose class diagrams as an example, but the same goes for all UML diagrams that you might want to re-engineer from source code or generate source code for (I'm primarily interested in the former). However, unlike a giant IDE, you can re-use large parts of the tool chain. Sure, you can extend an IDE to include other diagram types, but it means you have to intergrate you code, and therefore it can only be used in one way. Using a tool chain, the tools can be combined together in n*n ways.
The point is that you don't get any options for UML tools -- they are all "integrated", meaning they are fucking huge.
sigh
Now we're recognising the use for UML tools, have we taken the unix path or the integrated windows path? Seems the integrated tools are winning. Oh yeah, and there's thousands of them, all in various states of disrepair.
I know this isn't a very convincing argument, but frankly, I shouldn't have to make it: small tools working together is the unix way and we should strive to make our new tools the same way as our old tools.
I recommend the following small tools:
Most of these transformations can be done in XSLT. By maintaining XLinks between each of these documents you can navigate from one SVG to another and even effect changes earlier in the pipeline to create an interactive editor.
Even if you have no interest in reverse engineering C++ code the last 2 steps will be of interest to anyone writing another one of those big ass UML editors.
have you used any of them, or are you just being a smart ass. Yes, I thought so.
I'm aware of your ftp server. I'm also aware that it is the only one of its kind. Why don't you write some more software and compete to determine which is better.
cause when it comes to comparing Qt to Java Swing/AWT there is simply no comparison. I'll put it to you straight: code one more graphical application in that dog slow language and I will personally ensure that you eat every word you utter about "java performance not really mattering". A gui should respond to a user request in less than 100ms, anything slower and you have written a dog slow application. I submit to you that EVERYTHING written in Java/Swing that has a graphical user interface element does not meet this requirement. Now, can anyone vouch for SWT?