Tom 7 Radar:
all comments
[ next 25 ]
4491. Kirima/mm (45.124.79.83.cust.bluewin.ch) –
28 Apr 2006 19:42:10
[ UPD: Escape Beta 3 ]
You guys?
(-; |
| |
4490. Anonymous (adsl-75-2-210-46.dsl.mrdnct.sbcglobal.net) –
28 Apr 2006 10:38:26
[ CT Info ]
New Haven CT is the 9th ring of hell. Proof? GWB, the Antichrist, was born here. I rest my case. Beyond that, there is no middle class, the poorest are being gentrified, and all of our elected officials are going to jail for outrageous corruption-related scandals, such as stealing money from state coffers, molesting children or dealing with the mob. Oh yeah, what a wonderful place. Connecticut: More Than Just a Pit Stop On I-95 Between Boston and New York!!!
God, I hate it here.
-From a life-long resident. |
| |
4489. Steve in Oklahoma (adsl-70-142-44-159.dsl.tul2ok.sbcglobal.net) –
27 Apr 2006 14:13:09
[ Bathroom? Mushroom! ]
Good news for me. It was the seal on the toliet, also my toliet had been running some, which provided a source for the mushroom to grow. I called a plumber, he replaced the seal, and put a $2 part in the tank of the toilet. I had no permanent water damage under the toilet. My advice is if you see any kind of mushroom in your bathroom that means you have a problem. Call a plumber and get it fixed asap, and never eat anything that grows in your bathroom. |
| |
Ah, I see. That makes sense since unicode embeds ASCII; I was just surprised that ESCAPE would be a unicode character, for instance, but I wasn't thinking carefully.
I guess I'll try it and you guys can tell me how it works! |
| |
I guess, all ASCIIs 1-127 should be properly handled with unicode. Equality of sym and uni depends on the keyboard-layout and the mapping of course.
F.e. the parentheses on QWERTZ-keyboards (or only on german?) are <shift>-<8> and <shift>-<9>, brackets are <r-alt>-<8> and <r-alt>-<9> and the sym will be 8 or 9 for each. But unicode is set to the correct ASCII value. Sorry, i said that wrong before.
unicode even handles the numbers right with AZERTY-mappings (french), where they are reached with <shift>. |
| |
Thanks wowei and welcome! This sounds like a good solution. How can I tell what SDLK_ constants work for both unicode and sym? Is that documented somewhere? I'd love to fix this since Escape players are quite geographically diverse.
BTW, I just uploaded a new source archive yesterday, so the [d] key should be there now. |
| |
hi tom,
i found this board for the first time (blush), I always thought this feedback-thingy would pop up a mailto-link.
I read here, you are working on the prob with different keyboard-mappings. I think, that only a minor change is needed for that, because SDL comes with all the translation-stuff within. For my german-keymap I successfully changed the keyboard-event-handler stuff in edit.cpp and play.cpp like this:
split the event.key.keysym switch into two parts, where you can look at the keysym.unicode in one part and the keysym.sym in the other:
switch(event.key.keysym.unicode) {
/* here goes everything that is identical for unicode and sym */
case SDLK_ESCAPE:
...
/* and the only important part for a _german_ keymapping is this */
case SDLK_LEFTBRACKET:
...
}
switch(event.key.keysym.sym) {
/* here goes everything else that isnt handled properly by unicode
that should be only cursor-keys, f-keys or */
case SDLK_DOWN:
...
}
it's working fine here with a small drwaback: the <d>-key-"cheat" isnt included in the sources of 2005-10-13 yet, and so i have to decide, if i want to zoom or wanna see destinations while playing. ;) (switching the keymapping is the alternative and is fast to do in linux, but its annoying anyway)
greetz, and thanks for a really great game
|
| |
Bummer. This is with the binary distribution, or are you trying to compile it yourself? Adam and I worked this out in a way so it is "supposed" to work on all systems. Urgh. I suck at linux too. Why is it so hard to make binary distributions of software for linux? |
| |
Hey Tom!
I suck at Linux, so I was maybe wondering if you could tell me why I can't get Escpe to work on my box. Here is the message I get:
bash-3.00$ ./escape.exe: /usr/local/libexec/gcc-3.2.3/lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.5)
I tried finding out what version of GCC I had, but it said I had a newer version than 3.3. (3.4.2) I'm on a facilitized machine though so maybe I cannot be helped. :( |
| |
dc-dc: Okay, well I am glad you mostly agree with me. I don't understand what it is about my style that offends you, but honestly with comments like "go back to your proof toys" (etc.) I'm not sure I want advice on this subject from you.
I agree that C still has its niche, and wasn't suggesting that we have any good replacement for it today. The same methods, like type systems, that we use to ensure the safety of high-level languages also apply to low-level languages, and there is plenty of research into low-level languages with no more memory or disk usage than C.
But for the vast majority of its applications and the the vast majority of its users, C is an inappropriate language. This is especially true if the project's foremost goal is security.
Using C++ for Escape was probably a mistake; it is very painful to use and often keeps me from getting around to adding features that I want to add. The reason was that at the time I started the project, it was not easy to link to the SDL graphics library using mlton nor compile for platforms other than linux. I hope that I get the time to rewrite it in ML some day.
I disagree with point #3, especially in the case of SML. SML is the most formally defined real-world language that I know of, and the only one for which people have proved properties about the language itself in a mechanized way. C changes (like with the C99 standard) from time to time like any language (SML was revised in 1997 and is undergoing another revision process right now). C is a much broader target in the first place because of all of the stuff that is implementation defined. (In fact, I would claim that the implementation- and un- defined behavior is really at the heart of the security issue.)
Additionally, the licensing argument is a canard because I'm suggesting switching away from gcc (which is GPL, of course) to compilers that are BSD licensed. Thus the situation is exactly the opposite of what you say.
You're right that a compiler like any program is subject to the same arguments. Proving a compiler correct would mean stating its behavior as a proposition, which means defining the source language formally and formalizing some subset of the architecture. Xavier Leroy is working on something rather like this for a simple language. We also have compilers like TILT that produce typed assembly language, certifying that the binary that is produced is at least memory safe.
As for things we can do today, it's totally possible to write compilers in safe languages and enjoy memory safety and other properties for them as a result. Every SML compiler I know of (at least 5) is written in SML, but that's mostly just because ML is a great language for writing compilers.
I have a feeling this argument is coming to a close, so let me just summarize my position again:
1. Since code reviews don't catch all bugs, but security relies on catching all bugs, we want methods that are more infalliable.
2. Some methods are available today (like safe programming languages) that would instantly make applications for which they're appropriate more secure. In particular they'd make the largest classes of security problems in unix software impossible.
3. Looking towards the future, it's important to not be dismissive of technology that can make programmer's jobs easier. Technology is nearing that would make formal analysis practical for a wider variety of programs and properties. Formal analysis is less falliable, scales better, and is more maintainable (because it does not require a human to look at the entire code every time more code is introduced). Like high-level langauges, getting a computer's help is easier and works better, but that doesn't make it a toy. OpenBSD's charter should be about security, not suffering. |
| |
4481. Anonymous (71-10-253-54.dhcp.oxfr.ma.charter.com) –
24 Apr 2006 20:57:41
[ BAD SAT SCORES ]
i got a 2340 is that good? jk its great in all of our faces
|
| |
Looks like Mr. Anonymous has some personal interest in OpenBSD and defends it by attacking its critics. Not very scientific, but it's often effective in the real world, just ask George "you're either with me or against me" Bsh. Such behavior has no right to claim high ground...
|
| |
|
|
| |
4478. Anonymous (h197.131.28.71.ip.alltel.net) –
24 Apr 2006 11:15:41
[ BAD SAT SCORES ]
I got a 1730 too |
| |
I think it's funny that this entry is called "Question and Answer Session" |
| |
4476. Carolyn (toronto-hse-ppp4247246.sympatico.ca) –
23 Apr 2006 00:49:24
[ Bathroom? Mushroom! ]
HAHAHHA O my GOodness! From the angle where i sit on the toilet i noticed this bulge comming from the side of the wall underneith the wall paper beside the shower. Lately i have seen a water puddle near my shower as well. Earlier today my mother noticed it too and she pealed it back and saw 3 mushrooms. We were so discusted. I nearly vomited on the spot. But its so cool! We laughed so hard. But, the mushrooms do not look like the one in the picture above. They look like actual long mushrooms with a hat on the top. Are these edible? Not that i want to eat them. But really, are they edible?
and WHAT DO I DO ABOUT THEM? haha
Thanks
Carolyn |
| |
|
|
| |
Mr Tom7, have yourd heard of The Unicorns? They are great, and head in the same direction of your album a day. It's a tom7 must ;) |
| |
OMG LOL
That's my comment on the above back-and-forth. :) |
| |
It's supposed to be a cool stunt that may yield interesting results, just like the whole AAD thing in the first place.
I mostly agree with the substance of your points, but you offend me with style. Your general tone seems to be that people who are doing real-world stuff are drawing with crayons and should grow up.
I've experimented a little bit with Scheme and Haskell (not SML), so I am not allergic to higher-level languages. Here are a few reasons they may not be in wider use:
1. Performance, disk space, memory usage, etc. I know it's trendy nowadays to suggest that these are no longer concerns, and for us rich kids with new PCs, maybe they're not. But OpenBSD (for example) builds and runs on a lot of older machines that you would consider pretty slow. There's also embedded usage to consider, and small machines -- OpenBSD runs on the Zaurus, a handheld machine too small to fit libraries with debugging symbols -- and there's donated computers in third-world nations, and so on.
True, you can write just your most performance-critical code in C, but that doesn't save you from the disk and RAM requirements.
2. Operating system kernels have to do a lot of low-level stuff. That really calls for a low-level language. There's microkernels, but they're only beginning to get past the research-project stage.
3. These languages are moving targets. C has essentially been the same since 1989, and there's something to be said for that.
Even if the high-level languages are fairly old, like Lisp which has been around half a century, they've only been put to limited real-world use. The best way of doing such-and-such a thing may still be in the process of being hashed out. The libraries and implementations are less mature, in other words.
4. The implementations are big, and OS project leaders may see them as clunky, poorly designed, etc. In particular, OpenBSD has a very high standard for code quality in its base system, and these high-level language implementations, being relatively immature, may have hackish parts to them. There may also be licensing issues, since a lot of language implementations are unfortunately under the GPL/LGPL or worse. (Not SBCL, GHC, MLton, SML/NJ, or TILT, though.)
It's worth pointing out that not too long ago, OpenBSD rewrote their package management tools in Perl, partly to avoid having to worry about buffer overflows. I'm not saying Perl was the best choice, but there you go. I've also noticed you wrote Escape in C++; why is that?
By the way, why can't you run your compiler through your proof checker? I can understand the issues with proving correct the runtime system or the proof checker itself, but the compiler? There shouldn't be any problem checking that.
|
| |
|
|
| |
I want to keep this above the belt, but I feel the need to respond to these unfair remarks:
"... please look up 'argument from authority.'" I mentioned my credentials only in response to your accusation that I am "commenting on something [I] know nothing about." It's simply not true that I am ignorant. This is not argument by authority, because I never claim that my arguments follow from my expertise, just that they are informed by it.
Second, you are misrepresenting my remarks. I never said that there exists a more secure operating system today than OpenBSD. I never said OpenBSD is a waste of time. You seem to inrepret my remarks as insisting that people should drop what they're doing and switch to a magical solution that is not yet available outside of research communities. How could I insist that? I'm running linux this very second. But I do think it makes sense to own up to problems with the way we build software, and be open to new techniques for solving them.
So, let me say again what I am actually claiming. I'll number them so that if you'd like to say I'm saying something, you can just point to the number and respond.
1. Even if OpenBSD is the most secure practical operating system available, it is not secure. I am completely confident that there will continue to be security patches for your installation of the OS over the next year.
2. Observe that these bugs resulted (as far as I know) from accidental mistakes. Therefore, code review does not catch all accidental mistakes.
3. This contest reminds us that it's easy to maliciously embed bugs. Anything we can do by accident we can do on purpose, and I'm assuming that maliciously hidden bugs are harder to find than accidental ones, which I hope is not controversial. So if this is true, code review finds even fewer maliciously hidden bugs than accidental ones.
4. Formal techniques are superior because the intention of the coder is irrelevant, and the attention of the reviewer is unlimited. Whether he makes a mistake or deliberately tries to hide devious behavior, the proof-checking problem is just as easy. Computers are supremely patient, and thus can do a much more thorough job, much more often, than people.
5. Because the codebase is getting larger, and the contributors more diverse, we can expect more accidental bugs and more malicious bugs. So, not only are current techniques unable to find all bugs, the problem is getting harder. We need new techniques!
This is all I was saying in my original post. Some things have come up since then that I'd like to clarify my position on.
A. I stick by my statement that the countermeasures that we listed make it "more difficult (but seldom impossible) to exploit the bug." (Note this doesn't imply that it never makes them impossible, as you seem to claim I was saying (?)) Techniques based on randomization are not impossible to exploit (StackGuard, ProPolice, randomized malloc/mmap), nor do they address all kinds of bugs. W^X (and the analogous part of PaX) does absolutely protect against code injection, which is great, but not against returning to parts of code that already exist and might implement the malicious behavior for you. You know this, naturally; people on bugtraq have demonstrated attacks and the documentation for the software admits to the fact that the protection is not perfect.
B. Even though they are not perfect, the existence of these countermeasures does increase security. I hope that vendors of all operating systems start turning them on by default, the speed penalty be damned.
C. Nonetheless, I think the focus looking to the future is wrong. By accepting that some programs have almost completely unpredictable behavior under bug conditions (ie., most C/C++ programs, ie., most BSD/Linux/Windows programs) and then attempting to limit the damage that can be caused by that wild behavior, we're giving ourselves a much harder security problem than we need. Instead, I maintain that we should use formal techniques to guarantee that such "undefined behavior" can't arise in the first place. The great thing about these techniques is that the protection is automatic and absolute (up to bugs in the implementation of the proof checker or compiler, which are limited to a single source rather than every application, and which C/C++ programmers already have to live with anyway).
D. Some formal techniques, like static typing, are available today in practical form for many applications. If you want to write applications that can't have buffer overflows, integer overflows, heap corruption, double-free, format-string vulnerabilities, etc., are easier to write (and review) than their C counterparts, and have very competitive performance, you can download an SML or O'caml compiler today and go for it. I write almost all my software in SML, and it's perfectly practical for real applications today. It doesn't give you a proof of correctness, but it does give you a guarantee of memory safety. That's enough to exclude with certainty a large class of security problems that we have to patch our BSDs and Linuxes several times a year for. It also addresses other problems of large software programming (like debugging and blame assignment); it's really a win on many fronts.
I can't predict when we'll have practical tools for writing applications and proving them correct. There are lots of people working on it. I'm even less optimistic for near-term mainstream acceptance. One of the reasons is that communities like OpenBSD's are very closed to the possibility of using new languages. ML is over 30 years old; just in the last decade have we seen some small fraction of the ideas there make it into mainstream languages like Java. (PS. I don't think Java is a good language or representative of what I'm arguing for.) I wish I knew how to reach slashdot kind of folks with these languages, because I genuinely believe that they would be appealing to exactly the same kind of person who chooses Linux or BSD because they are better than Windows, despite being less popular. Unfortunately from my perspective there is a kind of Zeitgeist that it is better to suffer through writing painfully low-level C code, carefully avoiding its many dangers--that somehow through suffering one produces a better product. I think that the OpenBSD folks are especially guilty of this. Suffering is not virtuous. We have better ways already--especially if security is your #1 goal--and your original post is a good example of the kind of allergic reaction that many people from the "hacker" community have when faced with languages more modern than C. I don't really understand this, and I wish I did. Perhaps you have some insight. Academics absolutely do have the responsibility to make their work accessible, but "real world" programmers also have the responsibility to then try that stuff out and make concrete criticisms--or at least not demand to see futuristic stuff if they have not yet looked at stuff that's 10 or 20 years old. The mainstream should not flow only one way.
As for your challenge, I'm not really sure I understand the point. I'm not saying that writing correct code and proving it is fast, so the 1-day time limit seems undue. I also think the cost of errors in sound synthesis isn't very high, so the challenge of proving it correct also seems undue. But I will say that if I were to write some procedural music software (which is actually high on my list, so it may happen) today I would definitely use SML. Can you explain what it's supposed to demonstrate, or propose an alternate challenge?
|
| |
To "make a lot of attacks impossible" is precisely to make it more difficult, but not impossible, to exploit a bug. It is impossible to exploit a bug if and only if all attacks based on it are made impossible. |
| |
Sorry, if that message sounded dismissive it wasn't at all intentional. =) I appreciate all bug reports! Thanks! |
| |
4467. sylvia (194.42.43.134) –
21 Apr 2006 08:51:00
[ B & S? ]
It goes on Portugal tv, all twesdays,6 p.m. In my childwood..it was the best cartoons of ever...it always made me cry....
Congratulations to who did that story...it should exist some more cartoons at the same type...not wars...only happy storyes...
|
| |
[ next 25 ]
|